Don't require a key when creating a new keyring.

There will be key setting/removal functions so the step of adding the
keyring and setting a key on it can be done individually.

Add the access string to the app access request dialog.

This way the user can see what operation the application tries to do.

Add strings that explain an access operation.

May be used in the app access request dialog later on to show what
privilege is actually requested.

Rename "default" to "master" keyring as that's what it is.

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.

Rename keyring "access/revoke" to "unlock/lock".

The unlock/lock concept just seems easier to grasp and is used in
various similar tools as well.

Resolve/validate the calling application, request if needed.

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.

Add a preliminary way to resolve the calling application.

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.

Add access flags to fine tune application access.

Not sure if these will actually be used, as they might just be a little
overkill and not easily usable.

Let the KeyRequestWindow return a flattened BPasswordKey.

Also provide the keyring string separately instead of abusing the
output key message.

Implement basic keyring access logic and key request dialog.

* 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.

Make the keystore_server keyring aware.

* 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.

Implement basic storage and lookup functions.

* 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.

Add a skeleton keystore_server.

It will handle the BKeyStore messages but is yet relatively empty. It
only returns an error to two messages right now.

Don't require a key when creating a new keyring.

There will be key setting/removal functions so the step of adding the
keyring and setting a key on it can be done individually.

Add the access string to the app access request dialog.

This way the user can see what operation the application tries to do.

Add strings that explain an access operation.

May be used in the app access request dialog later on to show what
privilege is actually requested.

Rename "default" to "master" keyring as that's what it is.

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.

Rename keyring "access/revoke" to "unlock/lock".

The unlock/lock concept just seems easier to grasp and is used in
various similar tools as well.

Resolve/validate the calling application, request if needed.

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.

Add a preliminary way to resolve the calling application.

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.

Add access flags to fine tune application access.

Not sure if these will actually be used, as they might just be a little
overkill and not easily usable.

Let the KeyRequestWindow return a flattened BPasswordKey.

Also provide the keyring string separately instead of abusing the
output key message.

Implement basic keyring access logic and key request dialog.

* 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.

Make the keystore_server keyring aware.

* 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.

Implement basic storage and lookup functions.

* 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.

Add a skeleton keystore_server.

It will handle the BKeyStore messages but is yet relatively empty. It
only returns an error to two messages right now.