Hi.

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.

Thanks,
Ian.

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?

(Compare, for example, the general requirement for DDs/DMs to be able to
replace their keys easily for all project use.)

J.

Jonathan McDowell writes ("Re: Bug#1102125: debian-keyring: Please add tag2upload oracle service key"):

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.

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.

Jonathan McDowell writes ("Re: Bug#1102125: debian-keyring: Please add tag2upload oracle service key"):

Yes.

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'm not sure precisely what you mean about the web of trust.  The key
does bear my signature.  But it won't be signing other keys, and if it
does that's an anomaly and ought not to be trusted.

There is much software which should to treat this key the same way
that it treats keys in debian-keyring.gpg. [1]

For example, dscverify.  Assuming this change to the keyring
package is accepted, I will be sending a patch to dscverify to look in
this keyring when it's verifying signatures on source packages.

If we put this key in debian-role-keys.gpg, things get more
complicated.  Systems (like dscverify) which should trust the
tag2upload key, should *not* trust every key in role-keys the same
way.  For example, if the CD signing key, or DAM's key, were to sign a
source package, that would be an anomaly, and ought not to be trusted.

So then we'd have to somehow teach all of those systems to trust only
*this particular* key out of debian-role-keys.gpg.  That would involve
either hardcoding the key's name in all that software, using the key
name as the security-load-bearing identifier, or separately publishing
the fingerprint of the tag2upload key (presumably also in
debian-keyring.deb) and teaching all the software to check it.

Those options seem considerably worse than a keyring specifically for
this key.

Ian.

[1] Ultimately, modulo some wrinkles, everything that verifies
signatures on source packages (or normalised archive/ git tags).

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 think you want your own keyring package then, much like the archive
keyring (debian-archive-keyring).

The way your key(s) should be treated is specific to those keys, with no
direct equivalent to any other keys in the project (albeit with some
overlap).

There's no added benefit provided by involving keyring-maint here; the
tag2upload team and DSA are the people who know what keys should be
present. There is no equivalent of the human level key replacement that
keyring-maint curate for the DD/DM keyrings. As such I think we'd only
be adding unnecessary overhead.

J.

Jonathan McDowell writes ("Re: Bug#1102125: debian-keyring: Please add tag2upload oracle service key"):

OK.

Hi all,

Jonathan McDowell dijo [Mon, Apr 07, 2025 at 01:59:13PM +0100]:

I agree with Jonathan here. At some point we in fact discussed whether we
could stop distributing the keyring as a package (but decided against it);
Jonathan usually updates it, but AFAICT neither John or I do (each of us
does the "keyring dance" in a slightly different way).

FWIW, in my earlier replies I also supposed the request was to add the key
to the role-keys keyring; you do mention several oddities of the t2u key,
but we can see similar oddities in all of the keys in that keyring. And
yes, we don't want to ever find CD images signed by the Debian Account
Managers or security uploads signed by the Community Team. Special-purpose
keys... must somehow be special-cased.

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.

   – Gunnar.

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.

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.

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 dijo [Mon, Apr 07, 2025 at 05:36:15PM +0100]:

I agree, the reason we provide debian-keyring is mostly for users to be
able to verify or find keys. The downside is that the package is often
severely outdated (even more so if the user uses a stable release, of
course). Right, the package should hold the truth _roughly at the moment of
its inclusion_, but i.e. keys in it will probably expire by the time a user
wants to verify a given package.

Right. I have no strong opinion on this, but I think that you providing
your own package will free you from having to go through us (only for
dscverify), and will enable you to do some creative uses we have not yet
even thought of (i.e. shipping multiple keys, so that users can run
dscverify on packges that were uploaded long time ago, before a given
hypothetical key rotation... or whatever)

This is because distributing via a .deb would require all DSA systems to
always install the latest version. If a given key is compromised or lost,
we can usually react in a matter of a couple of hours after the key owner
notifies us. We just have to replace the key in keyring.debian.org, and the
user systems will use the new version immediately.

Of course.

Thanks.
#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"):

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.

Mmmm.

This particular key is not likely to need to change very often.  We
might choose to roll it over.  A more likely scenario is that we want
to do postquantum (but I believe that would need a new hardware
token).

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.

Thanks,
Ian.

Ian Jackson dijo [Mon, Apr 07, 2025 at 06:59:36PM +0100]:

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 😕

It makes sense IMO.

Makes sense FWIW. There are always further complications that can be added,
but one must know when to say "that's enough".