You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This patch refactors the SSlibSigner signing implementation, akin to #585,
which refactored signature verification (see PR for details about
legacy code and rationale).
Unlike, #585 this patch does not only condense and move the code for
singing, but creates a new hierarchy of signers to achieve two
additional goals:
1. Provide tiny rsa, ecdsa and ed25519 pyca/cryptography Signer
implementations, which are independent of private key serialization
formats, above all, of the proprietary legacy keydict format. This is
particularly interesting, when refactoring existing or designing new key
generation or import interfaces, where it would be annoying to move back
and forth over the legacy keydict.
2. Preserve SSlibSigner including its internal legacy keydict data
structure. SSlibSigner is and remains a backwards-compatibility
crutch. Breaking its existing users to make it a little less awkward
would defeat that purpose. And even though the Signer API doc says that
the internal data structure is not part of the public API, users may
rely on it (python-tuf actually does so at least in tests and demos).
To achieve these goals, SSlibSigner becomes a container for the newly
added CryptoSigner class, whose implementations can also be used as
independent Signers, and above all created or imported, with very few
lines of pyca/cryptography code.
**Caveat:**
Latest python-tuf tests pass against this patch, except for one, which
expects a keydict deserialization failure in `sign`, which now happens
in `__init__` initialization time. This seems feasible to fix in
python-tuf.
Also note that private key format errors are now ValueErrors and no
longer unreliably either FormatErrors or sometimes
UnsupportedAlgorithmErrors.
**Future work (will ticketize):**
- Signing schemes strings should not be hardcoded all over the place but
defined once in constants for all of securesystemslib.
- There is some duplicate code for scheme string dissection and
algorithm selection, which could be unified for all signers and public
keys.
- (bonus) #585 considered creating separate RSAKey, ECDSAKey, ED25519Key
classes, but ended up putting everything into SSlibKey. Now that we
have separate signers for each of these key types, which have a field
for the corresponding public key object, it might make sense to
reconsider this separation. This would give us a more robust data model,
where e.g. allowed signing schemes are only validated once in the public
key constructor and are thus validated implicitly in the signer
constructor.
Signed-off-by: Lukas Puehringer <[email protected]>
0 commit comments