New release

[jku]

I don't think there is a need to rush a release but:

• the next release contains API breaks: we should build a good changelog
• we should make a conscious decision on what is a release blocker

For the changelog, I think the commit messages from python-tuf PR theupdateframework/python-tuf#2165 are probably a good start for documenting the signer API changes

As release blocker proposals:

• Add Google Cloud KMS signing capability #442, Add HSMSigner #472 Signer implementations would be good to have to verify the signer API design
• Design key import/generation for the signer API #466 I don't think private key generation/import/storage needs to be fully implemented, but we should have the story ready
• signer API: review exceptions #468 likewise, at least a high level description of "this is how exceptions should work in signer API, and this is the current situation" would be helpful

[jku]

Status

• GCPSigner and HSMSigner are merged
• import_() has been implemented for both of those
• GPGSigner.sign now returns Signatures

Possible open issues:

• Misc fixes in dependency definitions #493: needs a reviewer but looks good to me
• Design key import/generation for the signer API #466: we don't have "key import/creation" implementations for SSlibSigner yet... my thoughts in the last comment. I think releasing without them is acceptable... but also writing a simple import methods (to import existing securesystemslib keydict) would not be difficult.
• Also in the same issue/comment: We could still change to EnvVarSigner and FileSigner instead of SSlibSigner -- an API change for sure but I want to make the idea visible now before the release
• signer API: review exceptions #468: Maybe we could add a note in Signer docs about the possibility of random exceptions but otherwise I don't think we can or should do anything else

[lukpueh]

• Misc fixes in dependency definitions #493: needs a reviewer but looks good to me

👍 merged

• Design key import/generation for the signer API #466: we don't have "key import/creation" implementations for SSlibSigner yet... my thoughts in the last comment. I think releasing without them is acceptable... but also writing a simple import methods (to import existing securesystemslib keydict) would not be difficult.
• Also in the same issue/comment: We could still change to EnvVarSigner and FileSigner instead of SSlibSigner -- an API change for sure but I want to make the idea visible now before the release

I lean towards releasing SSlibSigner as is, and make another release with above suggestions soon. If we we replace SSlibSigner now, it will break existing users (i.e. python-tuf tests and examples). But if we let users transition to Signer.from_priv_key_uri first, we might be able to replace SSlibSigner later without disruption.

• signer API: review exceptions #468: Maybe we could add a note in Signer docs about the possibility of random exceptions but otherwise I don't think we can or should do anything else

👍 let me create a patch

[lukpueh]

• signer API: review exceptions #468: Maybe we could add a note in Signer docs about the possibility of random exceptions but otherwise I don't think we can or should do anything else

👍 let me create a patch

Oh wait, that note already exists in the Signer class docstring:

securesystemslib/securesystemslib/signer/_signer.py

Lines 34 to 38 in 289965d

	Note that signer implementations may raise errors (during both
	Signer.from_priv_key_uri() and Signer.sign()) that are not documented here:
	examples could include network errors or file read errors. Applications
	should use generic try-except here if unexpected raises are not an option.

[jku]

All sounds good to me, thanks for checking.

I will note that python-tuf users cannot really start start using Signer.from_priv_key_uri() before python-tuf transitions to using securesystemslib Key (because we do checks like isinstance(public_key, SSlibKey) which the python-tuf keys will fail) but I guess that's not a problem or even unexpected.