On Sun, Apr 06, 2025 at 12:16:16AM +0100, Ian Jackson wrote:
Jonathan McDowell writes ("Re: Bug#1102125: debian-keyring: Please add
tag2upload oracle service key"):
It's not clear to me why this key should fall under the remit of the
keyring team. Is it substantially different to a buildd key, which we
also take no involvement with? It seems like it's managed by
DSA/tag2upload and only consumed by ftp-master, so adding in
keyring-maint seems like unnecessary overhead?
This is a sensible question. The answer is as follows:
Unlike a buildd key, the tag2upload oracle signs source packages and
git tags. These signatures are then verified by the ftp archive, and
by the dgit git server, respectively, but they are then *also*
transferred and republished, unaltered.
That means that these signatures appear on .dscs found in the archive,
and on git tags from dgit.debian.org. tag2upload .dscs, and the
normalised dgit view git tags, are not signed by the uploading
developers, but the tag2upload conversion service.
Tools like dscverify and git-verify-tag, used by humans and maybe
robots, will need to use this key to verify those signatures.
Contrast this to a buildd key: the signatures on .changes are verified
by dak, but the .changes are not then republished in the archivw.[1]
So published artefacts do not carry sigantures from buildd keys.
(Probably, those files and their signatures *should* be published, as
part of auditing for eg reproducible builds, but that's a whole other
question...)
I hope this helps explain things.
So your argument is that this is a key others will want easy access to
for validation of signatures produced by tag2upload? I still think it's
closer to something like an archive key (managed by a team, doesn't need
the web of trust or replacement pieces that keyring-maint get involved
with), but equally we already have other role keys present.
Is there a good reason why it can't go in the role-keys keyring and
instead needs it's own keyring?
J.
--
/-\ | Evil is as evil does, but evil
|@/ Debian GNU/Linux Developer | doesn't wear shoes.
\- |
