cd: re-enable release signing

Description of issue or feature request: https://github.com/theupdateframework/python-tuf/pull/1946 adds a CD workflow to release build artifacts on PyPI and GH upon successful completion of the CI workflow for a pushed release tag.

The PR also removes instructions from RELEASE.md to gpg sign release artifacts and add them to the GitHub release assets as part of the previously manual release process. However, the installation docs still mention release signatures.

Current behavior: No instructions / release process integration to sign release artifacts

Expected behavior: Add instructions to sign release artifacts and integrate with release process

Ideas:

• quick-fix 1: sign in GitHub CD action
• quick-fix 2: sign locally and upload signatures to release assets manually (bonus: integrate signing/uploading with verify_release script)
• long-term fix: e.g. in-toto (https://github.com/theupdateframework/python-tuf/issues/529)

[jku]

Maybe time to discuss this one again? sigstore-python now does attestations with slsa-github-generator (this is the generic “provenance only” generator): https://github.com/sigstore/sigstore-python/blob/main/.github/workflows/release.yml#L82

I understand that that does not cover all the bases this PR does (as explained in previous comment)… but their approach seems more approachable and easier to integrate. python-tuf project obviously has the expertise to do whatever intoto magic we want but… I would like to be able to show python-tuf as an example for others who won’t have that expertise: in this regard the slsa-github-generator approach seems nice.

I think I would benefit from an interactive session where we go through the various attestations we need (and the ones we want); what is provided by the slsa-github-generator approach, what isn’t; what is the verification story for these different attestations, and how they affect the maintainer workflows

Maybe we can catch up on slack next week and choose a time to discuss?

[lukpueh]

Thanks for posting this summary!

IMO there are two things that make the hand-crafted in-toto solution so hard to understand/verify:

1. Key management and metadata distribution (issue summary here) – This is arguably easier with a sigstore-based approach with their ephemeral keys, OIDC-providers, identity/signature logs, etc.

2. Signed Policy (i.e. attestation requirements, artifact interrelation, individual signer authentication, thresholds; see example policy document here ) – This is simply not considered by the other approaches, which of course makes their verification comparably easier.

Wrt (1) in-toto could learn from the other approaches, about (2) it should probably inspire them.