Re: Hard Rust requirements from May onward
Hi,
On 11/10/25 19:51, Simon Josefsson wrote:
Is there a need for a file format that supports hierarchical
structures, or would deb822 work better?
I'm not sure anyone has answers, at least I don't.
My main concern here is that it would be another file format, and one
that is very annoying to parse. The debian/watch file just moved to
deb822, which is great because it reduces the number of formats.
Maybe we could list design considerations?
- Nice to have: reduce today's complexity with PGP to only be in one
file -- I think we could stop publishing Release+Release.gpg and fix
whatever tooling breaks as a result (apt is mostly fine), relying only
on InRelease. This would also drop the number of PGP sig operations.
It might be possible to reuse the same signature for both Release.gpg
and InRelease.
- Nice to have: don't add round-trip latency fetching multiple files.
This one argues for putting everyhing in one file, such as extending
InRelease.
We could also create an extra file, maybe "SigRelease" that uses an
extensible format that allows multiple signatures.
A slightly horrible idea would be to define that Release files can only
contain one section (as they currently do), and anything following the
first empty line would be a bunch of signatures:
Origin: Debian
Label: Debian
…
SHA256:
e8609eb584c1b5bc3ec3447d3f4ea3e0dd837a20ccf2100c474ee24c549db7d5
161424 main/binary-amd64/Packages
…
4fd96936b8de008884516d2697182aff180ff970a98d1acadb1bab9a8218b4db
156 main/source/Release
Signature-PGP:
-----BEGIN PGP SIGNATURE-----
.
iQIzBAEBCgAdFiEEAYnKNKjrMd9ufR/5+Oo214ORXA4FAmkCZD4ACgkQ+Oo214OR
…
-----END PGP SIGNATURE-----
Signature-Sigstore:
…
Signature-Signum:
…
A variant that is also horrible, but in a different way, would be to
pack the signatures at the top, as the first paragraph, and treat
everything from the second paragraph onwards as the payload, this will
allow multi-section Release files in the future if we find a use for them.
This could even be a general thing: deb822-files beginning with
"Signature-" have inline signatures -- this could be extended to dsc and
changes files, for example (not that it's a good idea to move away from
web of trust for those).
Maybe this could be achieved through some other mean? Having a
per-aptsource configuration indicating the protection method, and then
only fetch that file? Such as Release.sigsum or Release.sigstore. I
think supporting more than one mechanism isn't entirely unreasonable,
so this adds two files that needs to be fetched, which isn't optimal.
I wonder if apt could be taught to cache 404s for a while. Container
builders would retry, but I'd argue that the problem with container
builders hitting the archive isn't the extra request for a signature file.
- Critical: a migration plan for how the trixie->forky(->duke)
transition should work.
Add new file, old clients ignore it, new clients fall back on old files
for a few releases.
Simon
Reply to: