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.
The application is resolved and then looked up in the keyring. If the
keyring doesn't provide a matching entry, an application access request
is triggered. The mechanism doesn't yet do any actual checksums, but
has provisions for differentiating between new and changed/updated
applications.
This will have to be reworked though, as by using the roster only
BApplications can be resolved, as plain cli apps aren't registered with
the registrar.
* Pass them through a flat buffer that can later be encrypted and
decrypted in a central place.
* Remove the data argument from the constructor as keyrings are
now reading their data on their own.
* Prepare for additional application info storage in the keyring.
The type is relevant and required as it determines the type of the
handed in key. The purpose however isn't actually needed and rather
inconvenient to get by depending on the situation.
* The keyring needs to be made accessible before allowing any
operation.
* Before executing commands the keyring is made accessible if
possible (the command is aborted as needed).
* Accessing a keyring opens up a preliminary key request dialog.
* If the default keyring is accessible and a keyring key for the
requested keyring is found, that key will be used to automatically
make the requested keyring accessible.
* Implement adding/removing passwords and keyrings.
* Implement enumerating passwords and keyrings.
* Implement preliminary accessibility status check for keyrings.
* Move the *Key() functions into a Keyring class.
* Retrieve and select the right keyring for various commands.
* Implement adding/removing/enumerating keyrings.
* Rework the keystore database read/write to work with keyrings.
* Sync BKeyStore::IsKeyringAccessible() with the changed message.
* Remove leftover template code from registrar.
* Add reading/writing a yet unprotected flat BMessage as the storage
backend for the keys.
* Factor out the identifier based lookup logic into _FindKey() and use
that from _AddKey() to detect duplicates.
* Add _FindKey() variant that does the lookup based on given type and
purpose constraints.
* The keystore backend will (at least for the time being) reside in a
separate server. This one can be reached via normal messaging, so use
a BMessenger for sending key messages.
* Move the message constants from RegistrarDefs.h into a new
KeyStoreDefs.h that also contains the server signature.
* Update the message constants to reflect the new situation.
* Add all relevant message constants.
* Implement the messaging to send/retrieve key info.
* Implement _Flatten/_Unflatten for sending flat BKey objects.
* Remove application list from BKey, the key can't only differ by
allowed applications as the identifiers would still collide, so the
comparison isn't needed to uniquely identify the key. The applications
can be enumerated via the BKeyStore instead.
* Modified the API greatly to be based on BKey* instead of BPassword*.
* Added BKeyPurpose and used it instead of BKeyType. It is supposed to
indicate the purpose of a key so that an app can look up keys on a
more granular level. The BKeyType on the other hand actually
identifies the type (i.e. subclass of BKey) so an app knows how to
handle a given key or may only enumerate/use keys it is compatible
with.
* Made everything based on a raw data buffer for now, only BPasswordKey
is implemented yet which stores the (0 terminated) string into that
data buffer.
* Removed the additional data BMessage as I don't yet see where it fits
in. While I could imagine adding meta data to a key may be nice it
might be an interoperability concern when keys are shared by
different apps.
* Moved the app functions to the keystore as per the TODO, but not sure
how to actually implement them.
