-
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
CryptoSigner: support init from PrivateKeyTypes #675
Merged
lukpueh
merged 2 commits into
secure-systems-lab:main
from
lukpueh:refactor-crytposigner
Nov 22, 2023
Merged
CryptoSigner: support init from PrivateKeyTypes #675
lukpueh
merged 2 commits into
secure-systems-lab:main
from
lukpueh:refactor-crytposigner
Nov 22, 2023
Conversation
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
Previously CryptoSigner instances could only be created via `from_priv_key_uri` factory method, because: - CryptoSigner was abstract - Subclass implmentations were protected This change makes the CryptoSigner constructor usable directly, so that signers can be created directly from pyca/cryptography private key objects. If a public key is not passed along, it is created from the private key, with default keyid and signing scheme for key type. *Details* Internally, this now (1) uses composition instead of inheritance, and (2) eliminates one level of abstraction: (1) CryptoSigner is no longer an abstract base class for protected rsa, ecdsa and ed25519 "signer" subclasses. It only made creation more difficult, without advantage. Instead CryptoSigner holds references to the "signers" (2) There is no more abstraction over individual pyca/cryptography rsa, ecdsa and ed25519 private key types. cryptography provides a common "PrivateKeyTypes" interface with sign method, which we can use directly. The different additional sign args for the different key types are managed in new internal data classes. Signed-off-by: Lukas Puehringer <[email protected]>
lukpueh
added a commit
to lukpueh/in-toto
that referenced
this pull request
Nov 20, 2023
Blocks on secure-systems-lab/securesystemslib#675 Signed-off-by: Lukas Puehringer <[email protected]>
lukpueh
added a commit
to lukpueh/in-toto
that referenced
this pull request
Nov 20, 2023
Blocks on secure-systems-lab/securesystemslib#675 Signed-off-by: Lukas Puehringer <[email protected]>
lukpueh
added a commit
to lukpueh/in-toto
that referenced
this pull request
Nov 20, 2023
Blocks on secure-systems-lab/securesystemslib#675 Signed-off-by: Lukas Puehringer <[email protected]>
lukpueh
added a commit
to lukpueh/in-toto
that referenced
this pull request
Nov 20, 2023
Blocks on secure-systems-lab/securesystemslib#675 Signed-off-by: Lukas Puehringer <[email protected]>
lukpueh
added a commit
to lukpueh/in-toto
that referenced
this pull request
Nov 21, 2023
Blocks on secure-systems-lab/securesystemslib#675 Signed-off-by: Lukas Puehringer <[email protected]>
jku
approved these changes
Nov 22, 2023
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.
Looks good to me, I find this quite readable now.
|
||
|
||
class CryptoSigner(Signer): | ||
"""PYCA/cryptography Signer implementations.""" |
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.
a bit of detail on how to get an instance of CryptoSigner could be useful. I guess something like:
- if you have a privkeyuri for a private key stored in a file, use the generic
Signer.from_priv_key_uri()
- if you just want to create a completely new private key, use
CryptoSigner.generate_*()
(orCryptoSigner()
for even more control over key details) - if you want to use an existing cryptography private key, use
CryptoSigner()
Signed-off-by: Lukas Puehringer <[email protected]>
lukpueh
added a commit
to lukpueh/in-toto
that referenced
this pull request
Nov 24, 2023
Blocks on secure-systems-lab/securesystemslib#675 Signed-off-by: Lukas Puehringer <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
closes #664 (see #664 (comment))
Previously CryptoSigner instances could only be created via
from_priv_key_uri
factory method, because:This change makes the CryptoSigner constructor usable directly, so that
signers can be created directly from pyca/cryptography private key
objects.
If a public key is not passed along, it is created from the private key,
with default keyid and signing scheme for key type.
Details
Internally, this now (1) uses composition instead of inheritance, and (2)
eliminates one level of abstraction:
(1) CryptoSigner is no longer an abstract base class for protected
rsa, ecdsa and ed25519 "signer" subclasses. It only made creation more
difficult, without advantage. Instead CryptoSigner holds references to
the "signers"
(2) There is no more abstraction over individual pyca/cryptography rsa,
ecdsa and ed25519 private key types. cryptography provides a common
"PrivateKeyTypes" interface with sign method, which we can use directly.
The different additional sign args for the different key types are
managed in new internal dataclasses.
Otherwise code is mostly moved around:
_get_rsa_padding
and_get_hash_algorithm
helpers are moved unchanged to module scope (these might move out altogether with signer: deduplicate signing scheme dissection #594)from_securesystemslib_key
can now pretty much directly use the constructor, thus no longer requires thefrom_pem
helper