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.
Thanks,
Ian.
[1] Perhaps .changes files are published somewhere but if so I don't
know where. They don't seem to be on archive mirrors.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
