Further to mailing list discussions, please would you add the
tag2upload Oracle key to the debian-keyring package.
As discussed on-list, this key will be signing normalised git tags and
source packages, and it should therefore be properly public and
discoverable.
I think this should be in a separate keyring, debian-tag2upload.gpg,
because automated systems need to use it for verification. Having it
as a separate keyring, rather than treating it as a role key, means
not having to add additional access control / key identification
machinery to those systems.
I have prepared a git branch containing what I think are the necessary >changes to the debian-keyring source:
https://salsa.debian.org/iwj/debian-keyring/-/tree/t2u?ref_type=heads
git revision
8147605fb502ee458f861d9789df892771fb44b8
Management of the key is currently shared between the tag2upload team
and DSA. I created the key on the hardware token, so no human has
ever had access to the key material. The key bears my signature.
I hope this is a convenient way to convey this request.
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?
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?
Jonathan McDowell writes ("Re: Bug#1102125: debian-keyring: Please add tag2upload oracle service key"):
So your argument is that this is a key others will want easy access to
for validation of signatures produced by tag2upload?
Yes.
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.
The key definitely wants to be published officially by Debian.
I think debian-keyring.deb is the way we do that for GPG keys that we
esxpect humans and computers to use.
Its replacement should be managed the same way as some other keys used
by systems - I think much like the archive key which you mention.
I think you want your own keyring package then, much like the archive
keyring (debian-archive-keyring).
So your argument is that this is a key others will want easy access to >>>for validation of signatures produced by tag2upload?
Yes.
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.
The key definitely wants to be published officially by Debian.
I think debian-keyring.deb is the way we do that for GPG keys that we >>esxpect humans and computers to use.
debian-keyring.deb is a terrible thing I wish didn't exist.
The keyrings the Debian infrastructure cares about are distributed via
rsync, with validation of the checksums being signed by a member of the >keyring-maint team. The in-archive package file is purely convenience for >folk who want to get hold of it, with no guarantee it's up to date (and,
in fact, a guarantee it's not up to date in stable once we release,
because we don't do volatile updates for it).
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.
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.
Again, my stance is not to stand in your way, but to resolve
things as they are made available.
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 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.
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.
I am a bit biased against distributing keys via .deb packages. Of course,
it makes sense to have Debian systems' verification self-contained for our castaway on their deserted islands, but it brings its host of issues with
it.
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.
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?
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.
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 483 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 81:12:08 |
| Calls: | 9,576 |
| Calls today: | 7 |
| Files: | 13,666 |
| Messages: | 6,143,066 |
| Posted today: | 2 |