Transitive build backend dependency on uv

[woodruffw]

Hi! Just a quick side-note from a Debian packager: python-sigstore-protobuf-specs is packaged in Debian but sigstore-models appears to be problematic to package because it uses the UV build system which is rust-based with a lot of dependencies. People have worked for a year to add it to Debian and it is still not finished. So making sigstore-models a required dependency may cause some friction for us... so I would be happy if at least during some time window both would be supported. I have no idea if this is feasible from a code point of view, just trying to share my view as a Debian packager.

Originally posted by @jas4711 in #1470 (comment)

[woodruffw]

@jas4711 thanks again for raising this. I think there are two aspects worth discussing:

1. I think our plan on sigstore-python is to have a major release (4.x) done relatively soon, at which point we'd begin to depend on sigstore-models instead of sigstore-protobuf-specs. I don't think we have a firm timeline for that but @jku might have opinions.
2. In terms of temporarily ameliorating this: I'm the maintainer of sigstore-models, so I can change the build backend there to something that would work for you (I assume setuptools or flit would be fine?). However, that would likely not be a permanent change, so ideally I'd have a sense of when Debian expects to have uv's build backend packaged.

TL;DR: This is something we can work around here by changing the build backend on sigstore-models, but I'd like to get a good sense of Debian's timeline for packaging the uv build backend since it's likely not a change we'd keep permanently. Plus, I expect that we'll eventually have deps adopt the uv build backend that we don't have control over 🙂

[jas4711]

Thanks for caring about this aspect!

Indeed changing the build system, if only temporary, would help me to get sigstore-models into Debian relatively quickly.

The work on packaging UV in Debian is tracked here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069776

I asked about this on the Debian list:

https://lists.debian.org/debian-python/2025/08/threads.html#00055

Earlier discussion:

https://lists.debian.org/debian-python/2024/11/threads.html#00073

With conclusion to move this to the Debian Rust team:

https://lists.debian.org/debian-python/2024/12/msg00000.html

There is recent progress on some dependencies: https://salsa.debian.org/rust-team/debcargo-conf/-/issues/78

Debian doesn't make timeline predictions, but judging from the state of discussions, I think this is in the timeframe of months but requires that somebody step up and work on adding UV.

Btw, the rfc3161-client is also challenging, with its combination of Rust and Python. I haven't started analyzing how much of that package is really required, and if we can split things up into smaller pieces that are easy to package in Debian and is sufficient for python-sigstore. Any insight from you as upstream is appreciated, but I also understand and sympathize that solving Debian's problems aren't really your main priority.

[woodruffw]

Btw, the rfc3161-client is also challenging, with its combination of Rust and Python. I haven't started analyzing how much of that package is really required, and if we can split things up into smaller pieces that are easy to package in Debian and is sufficient for python-sigstore. Any insight from you as upstream is appreciated, but I also understand and sympathize that solving Debian's problems aren't really your main priority.

Yeah, this is unfortunately less trivial than changing the build backend in sigstore-models: rfc3161-client needs its Rust components for its core operations, and those operations aren't easily devolvable into separate pieces.

(In terms of how important that dep is: it's not mandatory in sigstore-python 3.x, but it becomes de facto mandatory in 4.x because of changes in the Rekor service that sigstore-python connects to. But there will be a long deprecation period for the current Rekor service, to my understanding.)

[jku]

This is a good discussion to have and something we really need to make clear in release notes etc...

On the rfc3161-client issue

• Sometime in the near future (~months), the public good Sigstore instance sigstore.dev will enable first verification and then signing with rekor v2 transparency log (like the staging instance has already done): creating and verifying these signature bundles will require a client that understands timestamps (for sigstore-python this means the dependency on rfc3161-client)
• rekor v1 remains available on sigstore.dev so older clients will keep working, however that has caveats...
• clients are generally recommended to sign with rekor v2 when it is available and the client has the ability, meaning there will be new style signature bundles out in the world

So yes, there is a deprecation period but the reality is that clients deal with data that is not under their own control: Once sigstore.dev recommends signing with rekorv2, sigstore-python 3.x clients will start encountering signature bundles with rekorv2 entries and timestamps and will not be able to verify them.

On release:

I think our plan on sigstore-python is to have a major release (4.x) done relatively soon

Yes I'd prefer to get something out soon -- my only concern at the moment is issues like the one we're discussing right now, but I don't think delaying this release improves things: The real decision is enabling rekorv2 signing on sigstore.dev and that probably should take into account questions like when will Debian clients be compatible with these signature bundles?

[jku]

the rfc3161-client is also challenging, with its combination of Rust and Python. I haven't started analyzing how much of that package is really required, and if we can split things up into smaller pieces that are easy to package in Debian

just so you don't do unnecessary work: the heavy lifting in rfc3161-client is done by the rust code, it's not feasible to remove the rust build dependency there in case you were thinking of trying that.

[jas4711]

the rfc3161-client is also challenging, with its combination of Rust and Python. I haven't started analyzing how much of that package is really required, and if we can split things up into smaller pieces that are easy to package in Debian

just so you don't do unnecessary work: the heavy lifting in rfc3161-client is done by the rust code, it's not feasible to remove the rust build dependency there in case you were thinking of trying that.

Excellent! It was really hard to tell for someone who doesn't understand all of the technology and interactions here.

Btw, I appreciate the general discussion about releases and dependencies. I will ask for more help within Debian but my experience is that there isn't a lot of enthusiasm around transparency technology among Debian folks (I consider myself member of a minority pushing for this). I'm happy to help on the Debian packaging side, but I'm an old-timer who prefers C and knows too little of the Python, Rust and Go ecosystems even though I work with them too, so I often get stuck on some language-specific issue that is probably trivial for anyone more familiar with the Rust/Python/Go ecosystems.