Hi. Thanks for continuing to provide helpful info. I have some
replies and hope for your confirmation that we're taking the right
approach.
Gunnar Wolf writes ("Re: Bug#1102125: debian-keyring: Please add tag2upload
oracle service key"):
> I do think including the t2u key could be in place in the role-keys
> keyring. Not so much because of the generated package (again, I see very
> little value in it), but because it enables Debian infrastructure to check
> it via rsync.
I don't think debian-role-keys.gpg is a good way to make the key
available to programs, because of the need to further identify the
specific key, as I wrote. The right approach is a separate keyring.
That separate keyring needs to be made available to:
1. Debian infrastructure systems (git.dgit.debian.org, dak, etc.)
2. User systems (for programs like dscverify).
To achieve 2, we need it in a binary package. The sensible options
for that are:
1. The debian-keyring package
2. A bespoke binary package
As I understand Noodles, he's saying he thinks it should be 2.
I don't understand all the constraints and reasons for that
(Noodles has explained them a bit) but I respect the decision.
And AFAICT Noodles doesn't think that new .deb ought to come from the
keyring source package, either.
So we will make a bespoke binary package.
The Debian infrastructure system which has this key already is
git.dgit.d.o, and it has the key through us having committed it to the
service's configuration git repo. Other services could do likewise.
I think it's just queued and dak.
It's possible that distributing this key to infrastructure systems via
the .deb is a good way, but that's not how it's done for
debian-keyring.gpg which makes me think it may not be a good way for
this key either.
If we're putting it in a separate .deb I don't think it makes much
sense to put it in debian-role-keys.gpg too.
> But ultimately, I am not familiar with the processing that will be done
> once the other involved teams do the necessary footing to get t2u
> working.
I'm going to explain this because I hope it will improve the quality
of the advice you'll give me in response to what I wrote above:
As far as computers go:
Most systems need to treat this key the same way they would a key in
debian-keyring.gpg. (That's because most systems that use
debian-keyring.gpg are verifying source packages, or maybe developer
git tags.)
Systems in this category include git.dgit.debian.org, the ftp upload
queue daemon, dscverify(1) and similar programs on on user syustems,
and possibly dak on fasolo[1].
Systems that should definitely *not* treat it that way are, I think,
just vote.debian.org.
Systems where it would be better not to treat it like a DD key, but it
doesn't matter very much, are things like the PGP-signature based list
moderation, and the the tag2upload service itself.
Humans should also be able to find the key, obviously, but publishing
it in a .deb for use by software achieves that purpose too.
> Again, my stance is not to stand in your way, but to resolve
> things as they are made available.
Right.
Thanks,
Ian.
[1] Precisely how dak should handle this key is contested, but both my
idea of the best design, and our 2024 agreement with ftpmaster,
would have it in its own category.
Treating it like a DD key is the way to deploy it without code changes
to dak; everyone except ftpmaster thinks this would be OK, but I would
also regard it as less than iodeal - for example, there is no reason
for dak to accept binaries signed by tag2upload, so in a perfect
world, it wouldl not.
--
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.
