Open
Description
Hello, I noticed this project uses PGP signatures and wanted to make you all aware of my proposed PEP for deprecating PGP signatures in future Python versions. Please take a look and leave questions in the discussion thread.
Hello, I noticed this project uses PGP signatures and wanted to make you all aware of my proposed PEP for deprecating PGP signatures in future Python versions. Please take a look and leave questions in the discussion thread.
Activity
tianon commentedon Oct 9, 2024
Oof, not ideal, but something we can/will adapt to if it's adopted.
Thank you so much for the proactive heads up! It's really, really appreciated. ❤️
tianon commentedon Oct 9, 2024
The more I look at the details, the more concerned I am about this --
sigstore
clients are not super generally available (doesn't appear to have pre-existing Debian or Alpine packages, for example, and definitely not in bookworm/stable), especially before we've built/installed Python (which we need to verify before we do 😬), but even if it weren't, installing new packages from PyPI during our build is not something we're comfortable with (we just got away from installingpip
from PyPI 😅). 🤔To put that another way, this creates a new verification problem for us in that we need to somehow fetch/verify/trust a
sigstore
client as well. 😞We'll also need to maintain a mapping of release to release manager + OIDC Issuer (https://www.python.org/downloads/metadata/sigstore/), which is similar to what we already maintain for PGP, so not a huge burden but definitely not easier for us. 😅
(Already addressed explicitly in https://discuss.python.org/t/pep-761-deprecating-pgp-signatures-for-cpython-artifacts/67180/6 though, which is nice ❤️)
(Some variant of this might belong in the upstream discussion thread, but I'm mostly trying to write down ideation about how we would implement this, so for now I'm keeping it local. I do not mind if I get quoted in the upstream thread if something here is useful there, though -- I'm "tianon" there too if that happens and the quoter wants to @ me.)
tianon commentedon Oct 9, 2024
We could use
sigstore-go
, as suggested by the upstream documentation, but we'd have to compile it ourselves because (somewhat ironically) that project doesn't publish precompiled binaries (and solving the "verification" problem there is an interesting/fun case of chicken-and-egg).tianon commentedon Oct 9, 2024
As an affected downstream, it would honestly be more useful to us to have a published checksum that's stronger than MD5 and more machine-readable than what's listed in the HTML table on https://www.python.org/downloads/release/python-3130/ (I don't think that value lives anywhere under https://www.python.org/ftp/python/3.13.0/, for example, that we could easily scrape it from).
tianon commentedon Oct 9, 2024
(Yes, checksum and signature verify different things -- however, the different things they verify are valuable separately, and the checksum is a stronger verification for our purposes than the signatures are.)
sethmlarson commentedon Oct 9, 2024
@tianon That's good to know that stronger checksum value would be useful, there's an open issue for it and I plan to tackle it myself (upgrading to SHA256). Also: a feature that's different than PGP is that Sigstore can verify a checksum value and signature against an identity (rather than requiring the original binary blob).
tianon commentedon Oct 9, 2024
Very nice, that would be awesome! I dug a little more and found that the SPDX files published do include a checksum of the published artifacts too, but it's really buried so it'll require some finagling to extract. 😅
tianon commentedon Oct 9, 2024
Exploration of this thought gave me a simpler solution:
(extracting the SHA256 straight from the sigstore bundles, which lets me get values further back than the 3.12 that added SPDX files 👀)
tianon commentedon Oct 9, 2024
... SHA256 verification based on that is now implemented in #978 😄
tianon commentedon Oct 9, 2024
To reiterate for the avoidance of doubt, I don't think this solves the same problem as actually verifying the provenance of the builds too, but it does make it feel less urgent for us to find a good solution to the chicken-and-egg problem that getting a suitable
sigstore
client during our builds is (and ultimately we'd like to be verifying both).sspans-sbp commentedon Oct 18, 2024
Gave sigstore verification a first shot in #983
Only other option would be to do the download/check in a separate stage first (not pretty).
tianon commentedon Oct 18, 2024
Indeed, getting an appropriate sigstore client here (either one of the direct sigstore options or cosign) in a secure and verifiable way is going to be our biggest hurdle, especially since none of them are packaged in Debian yet (and it'd be years before we'd see them in a stable release even if we start that work today).
We could download and/or build one of them from source in our
Dockerfile
, but then we have the same chicken-and-egg problem with verifying those, and if we're still trusting them with just a checksum, then we might as well only use the checksums from Python (now that we've got them, thanks to #978).As noted in #983 (comment), it's great that Alpine Edge has
cosign
, but that unfortunately won't help us until Alpine 3.21 (and that's assuming it does successfully land in 3.21 - packages in Edge often don't). Additionally, as discussed in #980 (comment), I've been looking at python/cpython#90548 again recently and the fact that Alpine (slash musl) isn't actually a supported upstream platform, and contemplating what we should do about our Alpine builds in the future, with not maintaining them anymore being one option that's on the table.tianon commentedon Oct 18, 2024
To put that more succinctly, I'm currently questioning whether we get enough value out of verifying the signatures to make it worth doing something here, especially since there's no straightforward short-term answer to the supply chain / "root of trust" problems. 😞