* HttpAuthentication.cpp wasn't in ssl grist
resulting in unmet dependencies. #9523
* md5.c only being used when ssl wasn't available
was kind of spaghetti logic. These changes make
this more obvious.
Added the optional package for system sounds that
were collected for GCI 2012. Also added the demo
packges to the "contents" at the top of OptionalPackages.
The standard states that F_GETLK should check whether given lock would be
blocked by another one and return description of the conflicting one (or
set l_type to F_UNLCK if there is no collision).
Current implementation of F_GETLK performs completely different actions, it
"Retrieves the first lock that has been set by the current team". Moreover,
if there are no locks (advisory_locking == NULL) an error is returned
instead of l_type set to F_UNLCK.
Recently enabled variable range propagation enables GCC to among others analyze
whether array subscript is in a valid range. While being quite useful this
particular feature also happens to produce false positives. This is merely
a workaround to make compiler happy.
The actual reason why compiler is reporting false positive is that array is
indexed with a signed integer and it is not clear for compiler what value it may
have due to it being a member of the class and and external procedure being
invoked between its initialization and usage.
* This can be done from the command line using the new "-open" option.
* When the application is invoked via Tracker, ie. by double clicking
on an image, then it's being used implicitly.
* For LVDS output, the sync parameters aren't really used which is why the mode
set from the BIOS might not be valid if the PLL hardware would actually be
used.
* Therefore, we sanitize this mode to make sure it's within allowed parameters
so that intel_set_mode() will accept it.
* This should fix at least #8132, and #8796.
* Sorry for looking into this so late! I obviously messed up testing this
before, as my EeePC 900 was actually affected by this, too.
* Replace {Set|Remove}MasterKey() by generic {Set|Remove}UnlockKey()
that works on a keyring.
* Implement {Set|Remove}MasterUnlockKey() on top of that.
* Rename the commands and constants accrodingly.
* Implement setting and removing keyring unlock keys.
* Rename fKeyMessage to fUnlockKey and the KeyMessage() getter to
UnlockKey().
* Keep track of whether the keyring has an unlock key set.
* Store and restore that info separately.
* En- and decryption will depend on unlock key presence later.
* Add functions to set and remove an unlock key and query for it.
* Each keyring is now stored in a proper message which allows it to
contain additional meta data along side the flat data.
* Adding all keyring messages under a common field also allows to add
meta data to the keystore, as the keyrings don't use up random field
names anymore.
* Treat the master keyring as any other keyring and just add it to the
list. This allows to write/read the keystore database without special
casing the master keyring.
As there aren't any more generic meta data containers inside BKey,
there's no real way to distinguish different instances with the same
identifiers. This may be added later, for example the same index system
as used in BMessage could apply.
Before, each permanently granted access flag would overwrite the
previously granted flag, causing the dialog to come up whenever the
operation was changed.
The application access concept is on the keyring level only for now.
Generally it probably would get pretty complicated and therefore harder
to use when application access needs to be granted on a per key basis.
Also add a well defined name ("Master") for the master keyring so it is
easier to understand what this keyring does instead of displaying an
empty string.
* Using Unset() initializes the BKey to default values.
* Also set fCreationTime to 0 for now. It is still unused but needs to
have a stable value for the exact matches when comparing keys.
Alexander von Gluck IV