-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor Storage Layer #106
Conversation
a0fa280
to
fc4fb00
Compare
Note, this commit also drops the special use code available only in tests that was disabling encryption as it turns out that now that we do not decrypt every object on search but only on explicit fetch the test are not that slow anymore. Or rather the slow tests are gated behind the "slow" feature, so it is not a big deal if thy are really slow. |
Let me know if you think this is too slow:
I think it is fine given:
|
13daba9
to
5a45744
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mostly nits on the first read through
2762dd4
to
6d7c29c
Compare
This splits out the storage spefcific knowledge from the token to the actual storage backend. The storage backend is restructured so that multiple storage types can use a common information organizational schema for non standardized objects like user pins and token info and non standardized authenticationand encryption layers for the actual data. This is in preparation for adding code to read databases written by other software tokens that follow different storage philosophies. While woring on this refactoring a few minor issues with how pin/login were handled was found and have been fixed. Additionally the code now uses a common Key encryption Key that both the Ueer and SO Pins can unlock allowing recovery of the database via SO pin if the user pin is lost. This means the SO pin needs to be set to a non-default value on initialization to maintain the confidentaility of the token. It can be set to a random value if recovery is never desired. Signed-off-by: Simo Sorce <simo@redhat.com>
Signed-off-by: Simo Sorce <simo@redhat.com>
6d7c29c
to
12bf43c
Compare
b6ffb01
to
aabc432
Compare
Using 0 as the default slot number was masking cases when the configuration may not be correctly imported. By using an "invalid" value by default we ensure that a slot number has been properly assigned, and better check that there are no duplicate (same backing database) tokens loaded in different slots. Signed-off-by: Simo Sorce <simo@redhat.com>
aabc432
to
eef0d7c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
Thank you! |
This splits out the storage spefcific knowledge from the token to the actual storage backend.
The storage backend is restructured so that multiple storage types can use a common information organizational schema for non standardized objects like user pins and token info and non standardized authenticationand encryption layers for the actual data.
This is in preparation for adding code to read databases written by other software tokens that follow different storage philosophies.
While woring on this refactoring a few minor issues with how pin/login were handled was found and have been fixed.
Additionally the code now uses a common Key encryption Key that both the Ueer and SO Pins can unlock allowing recovery of the database via SO pin if the user pin is lost. This means the SO pin needs to be set to a non-default value on initialization to maintain the confidentaility of the token.
It can be set to a random value if recovery is never desired.