Ian Jackson dijo [Mon, Apr 07, 2025 at 06:59:36PM +0100]:
Gunnar Wolf writes ("Re: Bug#1102125: debian-keyring: Please add tag2upload oracle
service key"):
If you are building a new package, take note: we are currently discussing
#1101418, and one of the things that's on our roadmap is to rename *.gpg to
*.pgp (because... reasons...), so I invite you to use such nomenclature for
the proposed package.
Just to make sure I've understood correctly.
You're saying we should ship this filename
/usr/share/keyrings/debian-tag2upload.pgp
But still presumably containing the keyring in the gnupg-genereated
format we have it?
Yes. GnuPG generates OpenPGP-compliant keyrings. At some point we _did_
have blahblah-keyring.pgp and blahblah-keyring.gpg, because the v3 and v4
formats for pgp differed, and when v3 was purged (around the time I joined
the team), we stayed only with the *.gpg files. We should not be linking to
a specific implementation (GnuPG), but to the standard it uses
(OpenPGP). Specially now, as the GnuPG project is behaving in a roguish
way 😕
The package would be debian-tag2upload-keyring.deb, which devscripts
(the home of dscverify) would need to to Recommend.
I've chatted with Sean a bit and I think we probably want this to be
its own source package.
It makes sense IMO.
However, yes, having a .deb makes it somewhat easier to check for
signatures made at a given point in time, even if the relevant key is no
longer in use. For your suggested uses, I think finding a way to encode
validity periods for a given key via ways other than its expiration date
might be important.
These issues afflict dscverify(1) already. I think we are happy if we
can achieve parity there with the situation for other source packages.
(In fact I think we'll do better in practice because this key changes
less.)
Perhaps we should consider if we want to extend the validity period on
the key, as published in this new .deb, before the trixie release.
But ISTM that key lifetime extension could be done via stable updates
(and even via LTS) but we probably want to minimise the amount of
churn.
Makes sense FWIW. There are always further complications that can be added,
but one must know when to say "that's enough".
