[BUG] Versions > 75.1.0 do not have a signed tag, preventing upgrade

[dvzrv]

setuptools version

75.1.1

Python version

3.12

OS

Arch Linux

Additional environment information

No response

Description

For upstream source validation in systems packaging on Arch Linux we rely on pinned OpenPGP certificates.
For this project we have pinned the OpenPGP certificate with the fingerprint CE380CF3044959B8F377DA03708E6CB181B4C47E, held by @jaraco.

We tried upgrading to setuptools > 75.1.0 and validate the tags using the above OpenPGP certificate but noticed that tags newer than 75.1.0 are no longer signed.

The tags 75.1.1, 75.2.0 and 75.3.0 can not be validated and we are not able to use them.

cc @polyzen @felixonmars

Expected behavior

Tags are signed by the OpenPGP key with the fingerprint CE380CF3044959B8F377DA03708E6CB181B4C47E.

How to Reproduce

1. git clone https://github.com/pypa/setuptools && cd setuptools
2. curl https://github.com/jaraco.gpg |gpg --import
3. git verify-tag 75.1.0
4. git verify-tag 75.1.1

Output

git clone https://github.com/pypa/setuptools && cd setuptools
Cloning into 'setuptools'...
remote: Enumerating objects: 74280, done.
remote: Counting objects: 100% (2191/2191), done.
remote: Compressing objects: 100% (1057/1057), done.
remote: Total 74280 (delta 1419), reused 1723 (delta 1125), pack-reused 72089 (from 1)
Receiving objects: 100% (74280/74280), 45.60 MiB | 23.30 MiB/s, done.
Resolving deltas: 100% (43865/43865), done.
curl https://github.com/jaraco.gpg |gpg --import
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  3922  100  3922    0     0  51059      0 --:--:-- --:--:-- --:--:-- 51605
gpg: key 708E6CB181B4C47E: "Jason R. Coombs <[email protected]>" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1

git verify-tag v75.1.0
gpg: Signature made 2024-09-16T14:38:27 CEST
gpg:                using RSA key CE380CF3044959B8F377DA03708E6CB181B4C47E
gpg: Good signature from "Jason R. Coombs <[email protected]>" [unknown]
gpg:                 aka "Jason R. Coombs <[email protected]>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: CE38 0CF3 0449 59B8 F377  DA03 708E 6CB1 81B4 C47E
git verify-tag v75.1.1
error: no signature found

[abravalheri]

Hi @dvzrv, I am not sure this is a bug. It probably looks like an invalid assumption from the Arch tools.

setuptools releases are done via the CI and you can read exactly which commands are used in:

https://github.com/pypa/setuptools/blob/v75.3.0/.github/workflows/main.yml#L249-L269
https://github.com/pypa/setuptools/blob/v75.3.0/tox.ini#L93-L112

I recommend not relying on any assumption that is not documented in https://setuptools.pypa.io/en/latest/development/releases.html.

[jaraco]

Thanks for reporting the issue. As Anderson says, it's not a guarantee that tags are signed. Perhaps it could be, but right now it's a best-effort, as-available behavior.

I'm also unsure I want to commit to having signed commits for tagged releases. It would be nice, but unfortunately, GPG signing of commits is brittle. I've found it difficult to get configured reliably on my Windows machine, and I've found the documentation and support for doing it to be so poor and daunting that I'm reluctant to ask anyone else to do it.

@abravalheri Are you interested in getting started with signing commits (including tagged commits)? If so, I'd be happy to provide some tips about getting started. What OS do you use typically?

[jaraco]

we rely on pinned OpenPGP certificates

If there were multiple certificates used to sign Setuptools releases, would that satisfy Arch, or does it require there to be a single certificate (that would be shared by multiple release managers)?

[dvzrv]

Thanks for the replies and clarifications!

For posterity: It appears as if the OpenPGP validation has been added during the Python 3.12 rebuild without clarifying with you whether this project would uphold a trust path (between release managers) going forward, or would even agree to always sign tags.

Disclaimer: We believe it is valuable to sign tags so that downstreams can validate them.
However, this is also only really useful if the project (e.g. you) can guarantee to uphold a trust path between whoever signs those tags (e.g. by third-party certifications (aka. "signing someone's key") between the relevant signatures, or by having a dedicated file in this repository in which the fingerprints of the OpenPGP certificates used for signed tags are listed and are only ever modified by commits signed by already introduced OpenPGP certificates).
Otherwise there would be no cryptographic link between the releases (or none at all for the currently described situation).

I recommend not relying on any assumption that is not documented in https://setuptools.pypa.io/en/latest/development/releases.html.

Yes, that document or you should have been consulted first.

I'm also unsure I want to commit to having signed commits for tagged releases. It would be nice, but unfortunately, GPG signing of commits is brittle. I've found it difficult to get configured reliably on my Windows machine, and I've found the documentation and support for doing it to be so poor and daunting that I'm reluctant to ask anyone else to do it.

I understand and whether or not you want to do this is up to you.
However, I would like to also point at several alternatives for OpenPGP signing (if you are using a hardware token - e.g. a yubikey or a nitrokey - for your cryptographic key):

• oct-git: OpenPGP signing with OpenPGP cards (without GnuPG)
• openpgp-card-tools: tool for handling OpenPGP cards (without GnuPG)
• openpgp-card-ssh-agent: for an OpenPGP card based SSH agent (without GnuPG)

I found the above dedicated tools to be much easier to understand and use than GnuPG.

Alter-alternatively, some people are also using SSH signing for their projects now (FWIW, we currently don't support the validation of this in an integrated way for our package maintainers yet, which is not to say it can not or should not be used!).

If there were multiple certificates used to sign Setuptools releases, would that satisfy Arch, or does it require there to be a single certificate (that would be shared by multiple release managers)?

No, having several is fine :)
However, this would also only make sense, if we (or any downstream really) can verify the trust path between those certificates (as mentioned in the "Disclaimer" above).

Closing, I think we can for now remove the OpenPGP validation on our side until you have come to a conclusion for yourselves etc.

Thanks again for the prompt replies and clarifications! 🙏

[abravalheri]

Are you interested in getting started with signing commits (including tagged commits)? If so, I'd be happy to provide some tips about getting started. What OS do you use typically?

Umm... that sound like a bit of overhead 😅. I can try to give it a try as a best effort kind of thing.
I usually rely on Windows (both native and WSL1/2) and Linux.

@dvzrv, is there any alternative that relies on doing some process at the CI stage instead of having to run locally at the dev's computer?

[dvzrv]

@dvzrv, is there any alternative that relies on doing some process at the CI stage instead of having to run locally at the dev's computer?

None that I know of, that is meaningfully safe and actually useful in the context of allowing downstreams to authenticate individuals (e.g. you).

Generally, I'd always advice against doing tags in CI, as that way releases are created without any form of project owner oversight and are entirely dependent on the safety of the CI system (which is a substantial vendor lock-in as well).