-
Notifications
You must be signed in to change notification settings - Fork 50
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
Consolidate key interface password handling and general overhaul #288
Merged
SantiagoTorres
merged 13 commits into
secure-systems-lab:master
from
lukpueh:misc-interface-enhancements
Nov 6, 2020
Merged
Changes from 1 commit
Commits
Show all changes
13 commits
Select commit
Hold shift + click to select a range
9ee6998
Add and adopt decryption password interface helper
lukpueh a8508ee
Add and adopt encryption password interface helper
lukpueh bc62907
Adopt password helper in ecdsa interface functions
lukpueh 7d00ecb
Clean up interface function bodies
lukpueh 2379b7f
Reformat, update and clean-up interface docstrings
lukpueh 7d37d55
Adopt recent interface changes in README.rst
lukpueh 698f54f
Add generic import_privatekey_from_file function
lukpueh 1db7f21
Fix docstring and rename junk vars in interface
lukpueh fae4ebc
Add blank lines and minor doc fixes in interface
lukpueh dd2c5fc
Make interface.generate_*_keypair funcs protected
lukpueh edcf74e
Add thin interface._generate_*_keypair wrappers
lukpueh 1cb5bcd
Fix interface encryption password helper call time
lukpueh 9a74f30
Refine interface helper docstrings
lukpueh File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
I imagine encoding the error messages in multiple tests can make later improvements annoying. Is it really useful?
(I see this is the style already -- so this is just a question, not a suggestion to modify this commit)
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.
I agree that it's annoying and prone to break. As a matter of fact I'm pretty sure that it will break in the next build... I just skimmed through the latest
cryptography
release and saw that they changed an error message that we check for here.That said, I think there is merit in more granular error test assertions that go beyond the type. I've seen tests in the past, which meant to check for one error and passed although a different error was raised, because they had the same type.
So I think it's a fair trade-off to update the expected error strings in tests every now and then, if it gives us stronger tests. And once we have a more solid exception taxonomy (see #191), I'm happy to remove the message assertions. What do you think?
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.
FYI: Looks like I was wrong about the
cryptography
update breaking our build. That particular error message is raised by ourselves.securesystemslib/securesystemslib/rsa_keys.py
Line 1062 in d05dc6a
So no need for action for now... :)