#
707717e8 |
|
28-Dec-2016 |
Axel Dörfler <axeld@pinc-software.de> |
keystore_server: Use path as dummy checksum. * Slighty better than nothing.
|
#
d3b8b801 |
|
25-Jun-2012 |
Michael Lotz <mmlr@mlotz.ch> |
Fix missing write of the keystore database on app removal.
|
#
4a0460a9 |
|
25-Jun-2012 |
Michael Lotz <mmlr@mlotz.ch> |
Add generic unlock key setting and removal. * 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.
|
#
a82011ff |
|
25-Jun-2012 |
Michael Lotz <mmlr@mlotz.ch> |
Introduce keyring unlock key concept. * 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.
|
#
bec02d0c |
|
25-Jun-2012 |
Michael Lotz <mmlr@mlotz.ch> |
Store each keyring in a message under a common keyrings field. * 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.
|
#
d4d6d123 |
|
25-Jun-2012 |
Michael Lotz <mmlr@mlotz.ch> |
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.
|
#
a59169de |
|
24-Jun-2012 |
Michael Lotz <mmlr@mlotz.ch> |
Add the access string to the app access request dialog. This way the user can see what operation the application tries to do.
|
#
ee834720 |
|
24-Jun-2012 |
Michael Lotz <mmlr@mlotz.ch> |
Accumulate the app access flags instead of replacing them. Before, each permanently granted access flag would overwrite the previously granted flag, causing the dialog to come up whenever the operation was changed.
|
#
a2f27987 |
|
24-Jun-2012 |
Michael Lotz <mmlr@mlotz.ch> |
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.
|
#
a5a5f4ca |
|
24-Jun-2012 |
Michael Lotz <mmlr@mlotz.ch> |
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.
|
#
c8ae843f |
|
24-Jun-2012 |
Michael Lotz <mmlr@mlotz.ch> |
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.
|
#
b31a707a |
|
07-Feb-2012 |
Michael Lotz <mmlr@mlotz.ch> |
Implement the application enumeration and removal commands.
|
#
cfa81315 |
|
07-Feb-2012 |
Michael Lotz <mmlr@mlotz.ch> |
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.
|
#
76df966e |
|
07-Feb-2012 |
Michael Lotz <mmlr@mlotz.ch> |
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.
|
#
aef629f2 |
|
07-Feb-2012 |
Michael Lotz <mmlr@mlotz.ch> |
Only clear the keystore database when prepartion worked.
|
#
1b3bb46a |
|
07-Feb-2012 |
Michael Lotz <mmlr@mlotz.ch> |
Restructure how keyrings are stored/restored. * 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.
|
#
97b3abf1 |
|
07-Feb-2012 |
Michael Lotz <mmlr@mlotz.ch> |
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.
|
#
90013c82 |
|
07-Jan-2012 |
Michael Lotz <mmlr@mlotz.ch> |
Let the KeyRequestWindow return a flattened BPasswordKey. Also provide the keyring string separately instead of abusing the output key message.
|
#
f16fef70 |
|
07-Jan-2012 |
Michael Lotz <mmlr@mlotz.ch> |
Implement adding/removing keyrings from/to master.
|
#
1dd765c9 |
|
07-Jan-2012 |
Michael Lotz <mmlr@mlotz.ch> |
Store the key message from access/creation. * Allow creating a Keyring with a key message. * Store the key message when accessing. * Add a few missing consts.
|
#
ac9b28f0 |
|
06-Jan-2012 |
Michael Lotz <mmlr@mlotz.ch> |
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.
|
#
95eee1a3 |
|
04-Jan-2012 |
Michael Lotz <mmlr@mlotz.ch> |
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.
|
#
0dfaf59d |
|
04-Jan-2012 |
Michael Lotz <mmlr@mlotz.ch> |
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.
|
#
8d9bc9e0 |
|
04-Jan-2012 |
Michael Lotz <mmlr@mlotz.ch> |
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.
|
#
d3b8b801a8cef1fad01cb2f1a3b28c552712bb00 |
|
25-Jun-2012 |
Michael Lotz <mmlr@mlotz.ch> |
Fix missing write of the keystore database on app removal.
|
#
4a0460a9bc02ca100b7b7de2f7b04e77ee75593f |
|
25-Jun-2012 |
Michael Lotz <mmlr@mlotz.ch> |
Add generic unlock key setting and removal. * 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.
|
#
a82011ff964f4e27f38d0d8ebbc1e04fdf9db22e |
|
25-Jun-2012 |
Michael Lotz <mmlr@mlotz.ch> |
Introduce keyring unlock key concept. * 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.
|
#
bec02d0c2f483a804eb0b833d099b85b3660cdb0 |
|
25-Jun-2012 |
Michael Lotz <mmlr@mlotz.ch> |
Store each keyring in a message under a common keyrings field. * 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.
|
#
d4d6d1239322eeb4c100489eb76ed63afde449d6 |
|
25-Jun-2012 |
Michael Lotz <mmlr@mlotz.ch> |
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.
|
#
a59169de6f5fd92ba06d5d3836a4223b22cb8b6e |
|
24-Jun-2012 |
Michael Lotz <mmlr@mlotz.ch> |
Add the access string to the app access request dialog. This way the user can see what operation the application tries to do.
|
#
ee834720429a09b6727b310c46a464064c159a82 |
|
24-Jun-2012 |
Michael Lotz <mmlr@mlotz.ch> |
Accumulate the app access flags instead of replacing them. Before, each permanently granted access flag would overwrite the previously granted flag, causing the dialog to come up whenever the operation was changed.
|
#
a2f279870c158dd81005c29ade41dc976e2892f2 |
|
24-Jun-2012 |
Michael Lotz <mmlr@mlotz.ch> |
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.
|
#
a5a5f4ca70b67a24c1a0666b8bde040748e0c3ae |
|
24-Jun-2012 |
Michael Lotz <mmlr@mlotz.ch> |
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.
|
#
c8ae843f3dcba6c16eda5d2b5db1f981ee69f448 |
|
24-Jun-2012 |
Michael Lotz <mmlr@mlotz.ch> |
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.
|
#
b31a707a95add749b375eb8f29fd294507ce3f42 |
|
07-Feb-2012 |
Michael Lotz <mmlr@mlotz.ch> |
Implement the application enumeration and removal commands.
|
#
cfa813152623734173149bfb57c236d276729f67 |
|
07-Feb-2012 |
Michael Lotz <mmlr@mlotz.ch> |
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.
|
#
76df966ee6a656a9b51896653b3c411a53688fe4 |
|
07-Feb-2012 |
Michael Lotz <mmlr@mlotz.ch> |
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.
|
#
aef629f2006ee84735dedd3fa8c92460b1272183 |
|
07-Feb-2012 |
Michael Lotz <mmlr@mlotz.ch> |
Only clear the keystore database when prepartion worked.
|
#
1b3bb46aed33bd68bf5e4dba1625ad3211b31adc |
|
07-Feb-2012 |
Michael Lotz <mmlr@mlotz.ch> |
Restructure how keyrings are stored/restored. * 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.
|
#
97b3abf1624641d7d6f14a7657ae572fa2a6ab2e |
|
07-Feb-2012 |
Michael Lotz <mmlr@mlotz.ch> |
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.
|
#
90013c82e83a7a25e5d012daff40e38db5d5f741 |
|
07-Jan-2012 |
Michael Lotz <mmlr@mlotz.ch> |
Let the KeyRequestWindow return a flattened BPasswordKey. Also provide the keyring string separately instead of abusing the output key message.
|
#
f16fef70bee3877ed2b72e9b5714bc6b4f93b4bd |
|
07-Jan-2012 |
Michael Lotz <mmlr@mlotz.ch> |
Implement adding/removing keyrings from/to master.
|
#
1dd765c92c41aeebcc877371e90a795ed4a78703 |
|
07-Jan-2012 |
Michael Lotz <mmlr@mlotz.ch> |
Store the key message from access/creation. * Allow creating a Keyring with a key message. * Store the key message when accessing. * Add a few missing consts.
|
#
ac9b28f058fe4671b5034f6a3ed3f85091f53c5f |
|
06-Jan-2012 |
Michael Lotz <mmlr@mlotz.ch> |
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.
|
#
95eee1a36302940cff0bcf81d943b9d59c60bac2 |
|
04-Jan-2012 |
Michael Lotz <mmlr@mlotz.ch> |
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.
|
#
0dfaf59dbbc5319b1a52ef4108ea3ab64f8d2729 |
|
04-Jan-2012 |
Michael Lotz <mmlr@mlotz.ch> |
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.
|
#
8d9bc9e0eea57d70aee87c11b82603c69ae3eb53 |
|
04-Jan-2012 |
Michael Lotz <mmlr@mlotz.ch> |
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.
|