History log of /haiku/headers/os/app/Key.h
Revision Date Author Comments
# 94f897de 07-Jan-2012 Michael Lotz <mmlr@mlotz.ch>

Make Flatten/Unflatten public and remove IsRegistered().

The BKey doesn't know anything about the keyring concept, so the
registered info isn't really useful. May be re-added later with
keyring info as well.


# d962e210 04-Jan-2012 Michael Lotz <mmlr@mlotz.ch>

Add B_KEY_PURPOSE_KEYRING for keyring keys.


# c494c061 04-Jan-2012 Michael Lotz <mmlr@mlotz.ch>

Add B*Key::PrintToStream() method for debugging convenience.


# 1c399649 03-Jan-2012 Michael Lotz <mmlr@mlotz.ch>

Implement all KeyStore methods except for password generation.

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


# dc1acef8 22-Dec-2011 Michael Lotz <mmlr@mlotz.ch>

Flesh out the API and implement stubs.

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


# 3b3884d9 16-Nov-2011 Michael Lotz <mmlr@mlotz.ch>

KeyStore and Key interface/stubs draft per Axel Dörfler.

A draft API and (mostly) stubs to back it up. Initial import of yet
unmodified sources.


# 94f897deeaa6eda4b7982a958287c5c8fa2ce435 07-Jan-2012 Michael Lotz <mmlr@mlotz.ch>

Make Flatten/Unflatten public and remove IsRegistered().

The BKey doesn't know anything about the keyring concept, so the
registered info isn't really useful. May be re-added later with
keyring info as well.


# d962e21058c76cbd80f1deda9e5b3cbf855dfc99 04-Jan-2012 Michael Lotz <mmlr@mlotz.ch>

Add B_KEY_PURPOSE_KEYRING for keyring keys.


# c494c06109579891eacfd6f63506b0047963fde0 04-Jan-2012 Michael Lotz <mmlr@mlotz.ch>

Add B*Key::PrintToStream() method for debugging convenience.


# 1c3996496b06a2da3ae25c358336302dfbce7ddb 03-Jan-2012 Michael Lotz <mmlr@mlotz.ch>

Implement all KeyStore methods except for password generation.

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


# dc1acef865f290e8d565f078fc78be69991b5c10 22-Dec-2011 Michael Lotz <mmlr@mlotz.ch>

Flesh out the API and implement stubs.

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


# 3b3884d9eec9b931efab12d5b2b47d7e33827a65 16-Nov-2011 Michael Lotz <mmlr@mlotz.ch>

KeyStore and Key interface/stubs draft per Axel Dörfler.

A draft API and (mostly) stubs to back it up. Initial import of yet
unmodified sources.