Cannot install sigstore-python 3.6.3 together with cryptography 45.0.3

[carstencodes]

Description

My application uses cryptography 45 due to export of HashAlgorithmOID. I also have sigstore currently as a dev-dependency.

Installing all runtime dependencies and dev-dependencies into the same venv - even with the latest version published some days ago - fails as sigstore refuses to work with cryptography version 45.x or later.

The latest version on the main branch has already been updated. What has to be done to support cryptography 45 on a released package?

Version

sigstore-python 3.6.3
cryptography 45.0.3

[woodruffw]

Hi @carstencodes, thanks for the report!

Out of curiosity, what do you use sigstore for as a dev-dep? We typically expect people to use it either as an API (in which case it's part of the global resolution) or as a CLI (in which case they should install it in a fully isolated manner, e.g. pipx). Using it via a dev-dep causes these kinds of issues, since we conservatively pin cryptography as part of avoiding breakages (but in turn make ourselves more brittle against conflicting global resolutions).

(I think a dep group instead would address this, but I'm not sure how mature the overall tooling is for those.)

In this particular case we should probably do a patch release that supports cryptography 45 as well. But I'd like to make sure I understand the proximate cause here so that we can hopefully soften/smooth this path in the future too 🙂

[woodruffw]

CC @jku for opinions as well 🙂

(As part of this, we'll probably need to make sure our dependencies admit cryptography 45 too -- thinking in particular of rfc3161-client.)

Edit: rfc3161-client should admit 45: https://github.com/trailofbits/rfc3161-client/blob/d36c86945e6db081e00af94c40a9b3aaa70d1bfc/pyproject.toml#L20

[carstencodes]

Hi @woodruffw,

Thanks for answering: I am currently working a pre-built-hook that uses the sigstore to create a signature for the METADATA RECORD file of the resulting python wheel and add it to the resulting wheel as METADATA.p7s RECORD.p7s.

This way, I can provide a signed python-wheel.

Next step would be to create a wheel for this using x509/pycryptography or sigstore as backend.

[woodruffw]

Thanks for answering: I am currently working a pre-built-hook that uses the sigstore to create a signature for the METADATA file of the resulting python wheel and add it to the resulting wheel as METADATA.p7s.

This way, I can provide a signed python-wheel.

Okay, this raises more questions 😅 -- could you say a bit more about why you're doing this? To my knowledge nobody is really signing or verifying just the METADATA from wheel distributions; the Python ecosystem as a whole is encouraging people to adopt signatures/attestations via PEP 740, which gh-action-pypi-publish and PyPI itself have already adopted.

(That's not to say we won't unblock you here, but I'm curious what the long-term goal is compared to what the packaging standards are encouraging.)

[carstencodes]

Sorry, please replace in my answer METADATA by RECORDS

[carstencodes]

And I was not aware of the "new" approach. I was using PEP 427 instead as storage format ...

[woodruffw]

And I was not aware of the "new" approach. I was using PEP 427 instead as storage format ...

Ah, gotcha! That makes more sense but yeah, I don't believe PEP 427-style wheel signing was ever widely adopted (from a scan I did a while back it was a very distant second to PGP-style dist signing, which itself was only a small percentage at its peak). I'm going to open a d.p.o discussion about whether it makes sense to formally discourage these -- there might be widespread use that I'm not aware of, so I don't want to confidently but incorrectly assert anything here 😅

[carstencodes]

Well, I have seen, that there is no such tool for it. And if there is no tooling, how can there be usage.

And supply-chain-security has risen over the last years, so I think the urge is about to come...

[woodruffw]

Well, I have seen, that there is no such tool for it. And if there is no tooling, how can there be usage.

Agreed; another piece of context here is that both wheel signatures and PGP signatures require out-of-band trust establishment, which is a non-starter for a lot of users. So it's half a lack of tooling and half a lack of defaultable functionality -- even if there were tools, users wouldn't have an easy way to engage with them.

And supply-chain-security has risen over the last years, so I think the urge is about to come...

This is exactly the motivation behind PEP 740 -- one of PEP 427's constraints is that it defines wheel files and signatures therefore, but not sdists, whereas PEP 740 is generic over any distribution format accepted by Python packaging as a whole.

[carstencodes]

And if I see it correctly, PEP720 requires a lot of infrastructural changes, which might not be available in third party registries like github, gitlab, forgejo/gitea, jfrog artifactory or nexus repository. Especially, when mirroring these packages. I have not yet read the entire discourse thread so far, but I am not quite sure, if this can be achieved apart from pypi packages...

[carstencodes]

And I don't see RFC3161 support in this.

[woodruffw]

I have not yet read the entire discourse thread so far, but I am not quite sure, if this can be achieved apart from pypi packages...

The PEP does require index changes, but they're index-agnostic: in theory, any index provider that implements either PEP 503 (the HTML index) or PEP 691 (the JSON index) can provide attestations.

But yes, it's more intrusive than an attached signature. But the upside to that it that it works on sdists as well (besides the actual cryptography/misuse-resistance advantages).

And I don't see RFC3161 support in this.

Sorry, this being PEP 740 or sigstore-python? sigstore-python supports RFC 3161 as a source of signed time, although it isn't the default yet since the Sigstore ecosystem as a whole hasn't fully adopted it.

PEP 740 mirrors Sigstore in this aspect and allows implementors to require a source of signed time. At the moment PyPI and other verifiers require signed time via a signed inclusion promise from a transparency log, but in the future this will permit RFC 3161 signed timestamps as well.

[carstencodes]

Yes, I ment PEP 740.

Thanks for explaining this.

[jku]

In this particular case we should probably do a patch release that supports cryptography 45 as well.

This would probably be a useful policy to follow in future for cryptography specifically -- I think the pinning is a reasonable thing to do but since sigstore is also a library, it's also a annoying to downstreams.

I wish I had thought of it last week.