Acknowledgement sent
to Guillem Jover <[email protected]>:
New Bug report received and forwarded. Copy sent to Debian Keyring Maintainers <[email protected]>.
(Thu, 27 Mar 2025 09:15:02 GMT) (full text, mbox, link).
Package: debian-keyring
Version: 2025.03.23
Severity: wishlist
Tags: patch
Hi!
The attached patches cleans up the OpenPGP nomenclature usage (and some
other minor lateral cleanups), in package documentation and in the
keyring filenames, while providing backward compatibility symlinks for
the old names so that people can transition easily. (I'd like for
example to be able to extend the filename refs to the keyrings in the
dpkg codebase for example. :)
This should also fix multiple pedantic lintian tags. :D
When looking into this, I realized that there might be a need to
perhaps update the keyring.debian.org and dsa-puppet side of this,
because I'm not sure if these changes will break that. But from a
quick scan over dsa-puppet, it was not immediately clear, and I don't
have visibility over keyring.debian.org. I'm happy to try to implement
any needed changes there, but if you can afford it, some minor hand
holding or assistance/guidance would be appreciated!
On the last attached patch I trimmed the git --stat output and replaced
it with a --shortstat one to avoid the bloat. And compressed the last
two patches to also reduce their size.
Thanks,
Guillem
Acknowledgement sent
to Gunnar Wolf <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Keyring Maintainers <[email protected]>.
(Mon, 07 Apr 2025 17:03:02 GMT) (full text, mbox, link).
Hello Guillem,
Thanks for this bug report!
I have applied patches 0001, 0002 and 0003 to our working tree, and should
include them by the next keyring push. But, of course, patch 0004 is the
most significative of them all.
I reviewed it, and find the renaming/editing thorough. However, due to the
indirect uses, I would like a further review of the code. I see your patch
is taking care of providing the symlinks in the packages only, but not in
the generated output/ directory we push to keyring.debian.org; given the
way this system is used (keys are used via rsync), I think adding symlinks
there would be enough (but I don't want to create that wide breakage
without another pair of eyes confirming so!).
Anyway, it would be even better (of course, it would be a future step) to
get a listing of what actually uses the keyrings, and push to update said
programs as well.
Thank you very much for pushing in this direction!
– Gunnar.
Acknowledgement sent
to Guillem Jover <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Keyring Maintainers <[email protected]>.
(Thu, 10 Apr 2025 02:33:02 GMT) (full text, mbox, link).
Hi!
[ Sorry, as mentioned on IRC I only noticed the reply when I checked
on the web UI, due to the missing CC. :) ]
On Mon, 2025-04-07 at 11:00:59 -0600, Gunnar Wolf wrote:
> I have applied patches 0001, 0002 and 0003 to our working tree, and should
> include them by the next keyring push. But, of course, patch 0004 is the
> most significative of them all.
Perfect thanks!
> I reviewed it, and find the renaming/editing thorough. However, due to the
> indirect uses, I would like a further review of the code. I see your patch
> is taking care of providing the symlinks in the packages only, but not in
> the generated output/ directory we push to keyring.debian.org; given the
> way this system is used (keys are used via rsync), I think adding symlinks
> there would be enough (but I don't want to create that wide breakage
> without another pair of eyes confirming so!).
As mentioned on IRC as well, this was the part I initially mentioned I
had concerns with. And thanks for pointing out the omission in the
output directory.
I've now reworked a bit the build system, and created those symlinks
there as well. I've not switched to copying them into the packaging,
because AFAIR debhelper might turn them into actual files on copy (?),
so left the dh_link handling as is. (Updated patches attached, with
the last patch stats summary trimmed and patch compressed again.)
As you mentioned, having more eyes on this from the Keyring Team, and
probably from DSA might be best, before merging and deploying this to
avoid potentially obvious breakage.
(I'm still happy to rework or change anything here or elsewhere that
might be necessary! :)
> Anyway, it would be even better (of course, it would be a future step) to
> get a listing of what actually uses the keyrings, and push to update said
> programs as well.
Yes, this was on my plan, but in my mind, only after this change hits
the archive, and then ideally I'd only start sending such patches after
the Debian trixie release, so that no versioned dependency is required.
For the filesystem part through the .deb packages this seems easier to
deal with. My concern has been with the rsync side, where I'm not sure
how such a deprecation process can be handled (if this was an HTTP
thing, then a permanent redirect would be an obvious solution, f.ex.).
Perhaps an announcement with a timeline would be enough (dunno)?
Thanks,
Guillem
Acknowledgement sent
to Guillem Jover <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Keyring Maintainers <[email protected]>.
(Fri, 11 Apr 2025 00:03:01 GMT) (full text, mbox, link).
Subject: [PATCH dsa-puppet] Add keyrings symlinks with pgp extension
Date: Fri, 11 Apr 2025 01:59:22 +0200
These keyrings contain OpenPGP certificates, and are not vendor specific,
so naming them with an extension after GnuPG in detriment to the other
multiple OpenPGP implementations does not promote the interoperability
one would expect from that ecosystem.
Given that these files are API, and will have external references,
we add new symlinks with the .pgp extension using the .gpg ones as
targets, and leaving the keyrings with .gpg extension as is, which
should then be considered deprecated, but should stay until its clear
they are not being used from the Debian infrastructure, and potentially
a transition has been coordinated or announced about their fate for
the rsync endpoints.
This matches the intent after the changes being discussed as part
of <https://bugs.debian.org/1101418>. Where after those changes in
debian-keyring and ones being prepared for userdir-ldap have been
deployed, the symlink targets in dsa-puppet can be changed to use the
canonical .pgp pathnames, with a subsequent patch.
---
modules/roles/manifests/keyring_debian_org_mirror.pp | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/modules/roles/manifests/keyring_debian_org_mirror.pp b/modules/roles/manifests/keyring_debian_org_mirror.pp
index ca3c633be..6fddb3a50 100644
--- a/modules/roles/manifests/keyring_debian_org_mirror.pp
+++ b/modules/roles/manifests/keyring_debian_org_mirror.pp
@@ -6,14 +6,26 @@ class roles::keyring_debian_org_mirror {
ensure => 'link',
target => '/var/lib/misc/thishost/debian-keyring.gpg'
}
+ file { '/srv/keyring.debian.org/keyrings/debian-keyring.pgp':
+ ensure => 'link',
+ target => '/var/lib/misc/thishost/debian-keyring.gpg'
+ }
file { '/srv/keyring.debian.org/keyrings/debian-maintainers.gpg':
ensure => 'link',
target => '/var/lib/misc/thishost/debian-maintainers.gpg'
}
+ file { '/srv/keyring.debian.org/keyrings/debian-maintainers.pgp':
+ ensure => 'link',
+ target => '/var/lib/misc/thishost/debian-maintainers.gpg'
+ }
file { '/srv/keyring.debian.org/keyrings/debian-nonupload.gpg':
ensure => 'link',
target => '/var/lib/misc/thishost/debian-nonupload.gpg'
}
+ file { '/srv/keyring.debian.org/keyrings/debian-nonupload.pgp':
+ ensure => 'link',
+ target => '/var/lib/misc/thishost/debian-nonupload.gpg'
+ }
file { '/srv/keyring.debian.org/keyrings/buildd-keyrings':
ensure => 'link',
--
2.49.0
Acknowledgement sent
to Gunnar Wolf <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Keyring Maintainers <[email protected]>.
(Mon, 21 Apr 2025 19:42:01 GMT) (full text, mbox, link).
Hello DSA,
I am writing to you to help us decide whether it is pertinent to do a move
right now, or whether we should wait for you to implement anything.
Bug #1101418 (for which you have been Cc:d already) requests renaming the
Debian keyrings from *.gpg to *.pgp, as we are dealing with OpenPGP
objects, and are not tied to a GnuPG install; the reason *.gpg was chosen
over 15 years ago is mostly historic, and should be reverted, particularly
given the hostility of the GnuPG upstream development towards the OpenPGP
community.
Guillem kindly prepared some patches to do this, and after some discussion,
added the creation of some symlinks. The result of the patch in question
will be that the keyrings published in kaufmann.debian.org will be renamed
from *.gpg to *.pgp, and that symlinks will be created preserving the
original names; in the future, we might work towards removing the symlinks.
We need input from DSA to make sure we can perform this change. some
specific points we discussed on IRC are:
- ftp-master processing
- Email address to db.debian.org
- vote.debian.org
- Validation of mails sent to signed-only lists
But, of course, other subsystems might also need it. We believe everything
will work transparently if rsync is properly set to mirror symlinks.
I intend to do a keyring push by Thursday or Friday, and it would be great
if we could deploy the patch by then. But, as we agreed in the
keyring-maint channel, I won't do the move unless we get your go-ahead
Greeetings!
Acknowledgement sent
to "Adam D. Barratt" <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Keyring Maintainers <[email protected]>.
(Mon, 21 Apr 2025 21:03:01 GMT) (full text, mbox, link).
Subject: Re: Please help confirm: Does #1101418 sound like it will break
havoc?
Date: Mon, 21 Apr 2025 22:00:09 +0100
Hi,
On Mon, 2025-04-21 at 13:39 -0600, Gunnar Wolf wrote:
> I am writing to you to help us decide whether it is pertinent to do a
> move right now, or whether we should wait for you to implement
> anything.
>
> Bug #1101418 (for which you have been Cc:d already) requests renaming
> the Debian keyrings from *.gpg to *.pgp
[...]
> Guillem kindly prepared some patches to do this, and after some
> discussion, added the creation of some symlinks. The result of the
> patch in question will be that the keyrings published in
> kaufmann.debian.org will be renamed from *.gpg to *.pgp, and that
> symlinks will be created preserving the original names; in the
> future, we might work towards removing the ymlinks.
>
> We need input from DSA to make sure we can perform this change. some
> specific points we discussed on IRC are:
>
> - ftp-master processing
> - Email address to db.debian.org
> - vote.debian.org
> - Validation of mails sent to signed-only lists
>
> But, of course, other subsystems might also need it. We believe
> everything will work transparently if rsync is properly set to mirror
> symlinks.
This is primarily my personal thoughts rather than an official DSA ack.
To start from the beginning, as it were, the method by which debian.org
systems receive updated keyrings is userdir-ldap. The script which
pulls the current active keyrings from keyring.d.o to db.d.o (so that
they can be deployed by ud-ldap) is
https://salsa.debian.org/dsa-team/mirror/dsa-misc/-/blob/master/scripts/sync-keyring?ref_type=heads
That script runs from cron every 15 minutes on the db.d.o host.
This appears to be the primary point at which rsync's behaviour with
respect to symlinks is relevant. The various copy steps each use
rsync's "-a" option, so should preserve the symlinks.
The final stage of the sync - to "keyring-final" - copies only the
files listed in sha512sums.txt, so you would need to ensure that both
the .gpg and .pgp files / symlinks are included there.
userdir-ldap maintains its own list of keyrings which are deployed to
those hosts requesting them (e.g. ftp-master). While the keyrings are
copied from db.d.o to each host via rsync, the preparation of the rsync
source area uses Python's shutil.copy(), so AFAICS would follow the new
symlinks and continue to deploy *.gpg to var/lib/misc/thishost/ on
relevant hosts as real files. That should mean that things would
continue to work, but does mean that the rename would *not* propagate
to client hosts.
Regards,
Adam
Acknowledgement sent
to Guillem Jover <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Keyring Maintainers <[email protected]>.
(Wed, 23 Apr 2025 00:27:02 GMT) (full text, mbox, link).
Hi!
On Mon, 2025-04-21 at 22:00:09 +0100, Adam D. Barratt wrote:
> On Mon, 2025-04-21 at 13:39 -0600, Gunnar Wolf wrote:
> > I am writing to you to help us decide whether it is pertinent to do a
> > move right now, or whether we should wait for you to implement
> > anything.
> >
> > Bug #1101418 (for which you have been Cc:d already) requests renaming
> > the Debian keyrings from *.gpg to *.pgp
> [...]
> > Guillem kindly prepared some patches to do this, and after some
> > discussion, added the creation of some symlinks. The result of the
> > patch in question will be that the keyrings published in
> > kaufmann.debian.org will be renamed from *.gpg to *.pgp, and that
> > symlinks will be created preserving the original names; in the
> > future, we might work towards removing the ymlinks.
> >
> > We need input from DSA to make sure we can perform this change. some
> > specific points we discussed on IRC are:
> >
> > - ftp-master processing
> > - Email address to db.debian.org
> > - vote.debian.org
> > - Validation of mails sent to signed-only lists
> >
> > But, of course, other subsystems might also need it. We believe
> > everything will work transparently if rsync is properly set to mirror
> > symlinks.
>
> This is primarily my personal thoughts rather than an official DSA ack.
Thanks for the context on how this all ties together! I tried to look
into this, but having no access to the systems involved made it a bit
hard to follow what stuff was doing what or when, etc.
> To start from the beginning, as it were, the method by which debian.org
> systems receive updated keyrings is userdir-ldap. The script which
> pulls the current active keyrings from keyring.d.o to db.d.o (so that
> they can be deployed by ud-ldap) is
> https://salsa.debian.org/dsa-team/mirror/dsa-misc/-/blob/master/scripts/sync-keyring?ref_type=heads
>
> That script runs from cron every 15 minutes on the db.d.o host.
>
> This appears to be the primary point at which rsync's behaviour with
> respect to symlinks is relevant. The various copy steps each use
> rsync's "-a" option, so should preserve the symlinks.
Ok, that sounds good then. :)
> The final stage of the sync - to "keyring-final" - copies only the
> files listed in sha512sums.txt, so you would need to ensure that both
> the .gpg and .pgp files / symlinks are included there.
Ah! Ok, I had changed the sha512sums.txt call to only list the *.pgp,
so that would break stuff. Attached an amended patch (the last one in
the previous series), to restore doing the digest on all files under
«output/keyrings/*» as was being done before.
> userdir-ldap maintains its own list of keyrings which are deployed to
> those hosts requesting them (e.g. ftp-master). While the keyrings are
> copied from db.d.o to each host via rsync, the preparation of the rsync
> source area uses Python's shutil.copy(), so AFAICS would follow the new
> symlinks and continue to deploy *.gpg to var/lib/misc/thishost/ on
> relevant hosts as real files. That should mean that things would
> continue to work, but does mean that the rename would *not* propagate
> to client hosts.
Ah, then this would seem to be safe to deploy now, and the file types
problem could be fixed later on. I have had several changes for
userdir-ldap pending submission, but not this one about shutil.copy(),
thanks. Will see how to improve that, and then send patches for
userdir-ldap to DSA (I think I already sent out patches for
userdir-ldap-cgi).
I think though, the other related patch I sent for dsa-puppet, might
self-heal the symlinks?
Also, (I'm not sure whether I mentioned this before, besides Gunnar),
something I noticed while trying to make sense how this all works was
that:
* At least on usper.debian.org, the
/srv/keyring.debian.org/keyrings/ directory contains a non-symlink
debian-maintainer.gpg file (missing final «s»).
* On keyring.debian.org there's an extra-keys.pgp leftover(?) file,
perhaps as part of some old transition?
$ rsync keyring.debian.org::keyrings/keyrings/
drwxrwsr-x 4,096 2025/03/23 20:19:28 .
-rw-rw-r-- 30,705,085 2025/03/23 20:18:27 debian-keyring.gpg
-rw-rw-r-- 2,950,971 2025/03/23 20:18:27 debian-maintainers.gpg
-rw-rw-r-- 1,076,680 2025/03/23 20:18:27 debian-nonupload.gpg
-rw-rw-r-- 26,383 2025/03/23 20:18:27 debian-role-keys.gpg
-rw-rw-r-- 2,722,836 2025/03/23 20:18:27 emeritus-keyring.gpg
-rw-rw-r-- 25,015 2018/05/21 19:22:45 extra-keys.pgp
Thanks,
Guillem
Acknowledgement sent
to "Adam D. Barratt" <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Keyring Maintainers <[email protected]>.
(Wed, 23 Apr 2025 16:15:01 GMT) (full text, mbox, link).
Subject: Re: Please help confirm: Does #1101418 sound like it will break
havoc?
Date: Wed, 23 Apr 2025 17:13:07 +0100
On Wed, 2025-04-23 at 02:24 +0200, Guillem Jover wrote:
> Hi!
>
> On Mon, 2025-04-21 at 22:00:09 +0100, Adam D. Barratt wrote:
>
[...]
> > userdir-ldap maintains its own list of keyrings which are deployed
> > to those hosts requesting them (e.g. ftp-master). While the
> > keyrings are copied from db.d.o to each host via rsync, the
> > preparation of the rsync source area uses Python's shutil.copy(),
> > so AFAICS would follow the new symlinks and continue to deploy
> > *.gpg to var/lib/misc/thishost/ on relevant hosts as real files.
> > That should mean that things would continue to work, but does mean
> > that the rename would *not* propagate to client hosts.
>
> Ah, then this would seem to be safe to deploy now, and the file types
> problem could be fixed later on. I have had several changes for
> userdir-ldap pending submission, but not this one about
> shutil.copy(), thanks. Will see how to improve that, and then send
> patches for userdir-ldap to DSA (I think I already sent out patches
> for userdir-ldap-cgi).
"Probably". If it doesn't work for some reason, however, the effects
could include things such as dak no longer accepting any uploads from
DDs because it can no longer find their public keys.
I'd therefore be tempted to disable both the "pull" and "push" sides on
db.d.o shortly before the keyring side is deployed, and test them by
hand afterwards.
I can't personally guarantee being around at any particular time this
week though I'm afraid.
> I think though, the other related patch I sent for dsa-puppet, might
> self-heal the symlinks?
Unless I missed a patch, I think it only adds symlinks in the new
names, to the existing .gpg files? If so then it still relies on the
files shipped by ud-ldap being named .gpg.
> Also, (I'm not sure whether I mentioned this before, besides Gunnar),
> something I noticed while trying to make sense how this all works was
> that:
>
> * At least on usper.debian.org, the
> /srv/keyring.debian.org/keyrings/ directory contains a non-
> symlink
> debian-maintainer.gpg file (missing final «s»).
I think that was me fat-fingering something when testing a while back;
removed.
> * On keyring.debian.org there's an extra-keys.pgp leftover(?) file,
> perhaps as part of some old transition?
That I'd have to defer to keyring-maint on.
Regards,
Adam
Acknowledgement sent
to Gunnar Wolf <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Keyring Maintainers <[email protected]>.
(Wed, 23 Apr 2025 17:21:01 GMT) (full text, mbox, link).
Adam D. Barratt dijo [Wed, Apr 23, 2025 at 05:13:07PM +0100]:
>> Ah, then this would seem to be safe to deploy now, and the file types
>> problem could be fixed later on. I have had several changes for
>> userdir-ldap pending submission, but not this one about
>> shutil.copy(), thanks. Will see how to improve that, and then send
>> patches for userdir-ldap to DSA (I think I already sent out patches
>> for userdir-ldap-cgi).
>
>"Probably". If it doesn't work for some reason, however, the effects
>could include things such as dak no longer accepting any uploads from
>DDs because it can no longer find their public keys.
>
>I'd therefore be tempted to disable both the "pull" and "push" sides on
>db.d.o shortly before the keyring side is deployed, and test them by
>hand afterwards.
>
>I can't personally guarantee being around at any particular time this
>week though I'm afraid.
..It makes sense to make sure we have a DSA person available to fix things
in case it all bursts up in flames.
I was planning on doing this push this Friday, 2025.04.25, in the morning
(say, anywhere between 09:00–14:00 GMT-6). Can a DSA member be available in
case this messes up something?
Otherwise, I think it's better to listen to Adam's instinct and delay the
move. It does not necessarily have to be aligned with a "full" keyring
push.
>> Also, (I'm not sure whether I mentioned this before, besides Gunnar),
>> something I noticed while trying to make sense how this all works was
>> that:
>>
>> * At least on usper.debian.org, the
>> /srv/keyring.debian.org/keyrings/ directory contains a non-
>> symlink
>> debian-maintainer.gpg file (missing final «s»).
>
>I think that was me fat-fingering something when testing a while back;
>removed.
>
>> * On keyring.debian.org there's an extra-keys.pgp leftover(?) file,
>> perhaps as part of some old transition?
>
>That I'd have to defer to keyring-maint on.
Oops, this file looks completely fat-fingered as well. It was last touched
in May 2018 by keyring:keyring. Inspecting the file with Sequoia treats it
as a keyring with 17 mostly malformed certs:
$ sq keyring list /tmp/extra-keys.pgp
0. Unsupported Cert: Unsupported primary key: Malformed packet: unknown version
1. Unsupported Cert: Unsupported primary key: Malformed packet: unknown version
2. Unsupported Cert: Unsupported primary key: Malformed packet: unknown version
3. Unsupported Cert: Unsupported primary key: Malformed packet: unknown version
4. Unsupported Cert: Unsupported primary key: Malformed packet: unknown version
5. 04D5A231C5CC3B9CA2B06FC24AFC280200F2B9F3 Andreas Schuldei (home account) <[email protected]>
6. Unsupported Cert: Unsupported primary key: Malformed packet: unknown version
7. Unsupported Cert: Unsupported primary key: Malformed packet: unknown version
8. Unsupported Cert: Unsupported primary key: Malformed packet: unknown version
9. Unsupported Cert: Unsupported primary key: Malformed packet: unknown version
10. Unsupported Cert: Unsupported primary key: Malformed packet: unknown version
11. Unsupported Cert: Unsupported primary key: Malformed packet: unknown version
12. Unsupported Cert: Unsupported primary key: Malformed packet: unknown version
13. Unsupported Cert: Unsupported primary key: Malformed packet: unknown version
14. Unsupported Cert: Unsupported primary key: Malformed packet: unknown version
15. Unsupported Cert: Unsupported primary key: Malformed packet: unknown version
16. Unsupported Cert: Unsupported primary key: Malformed packet: unknown version
17. Unsupported Cert: Unsupported primary key: Malformed packet: unknown version
Oddly, I have gpg-from-sq installed, but gpg --list-packets works. Still,
it yields too much output for posting here, but with 18 instances of
«:public key packet: [invalid]». The included keys sport signatures created
between 1996 and 2003.
Oh, I see -- Running gpg --list-packets from kaufmann (which is "true"
GnuPG) yields «:key packet: [obsolete version 3]», which I guess is not
suppoted in Sequoia.
The reported userIDs are:
Filip Van Raemdonck
Rick Younie
Marc Brockschmidt
Jarno Elonen
Michael Weber
Andreas Schuldei
Ryan Murray
Siggy Brentrup
Jonathan Hall
Jonathan J. Hall
Torsten Werner
Gerd Knorr
Mattia Monga
Detlev Zundel
Timshel Knoll
Patrick Patterson
Jeremy M. Malcolm
Jean Pierre LeJacq
Thomas Bushnell, BSG
So, it's a list of PGPv3 keys from mostly retired DDs (and I don't know why
it was touched on 2018.05.21).
Anyway, according to our changelog, I _did_ upload a keyring on said date,
so that file is my mistake. I am moving it to my home directory in
kaufmann, just to be sure, but I really doubt we will miss it.
Thanks for the sharp eye! :-)
Acknowledgement sent
to Philipp Kern <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Keyring Maintainers <[email protected]>.
(Wed, 23 Apr 2025 19:27:02 GMT) (full text, mbox, link).
Subject: Re: Please help confirm: Does #1101418 sound like it will break
havoc?
Date: Wed, 23 Apr 2025 21:23:20 +0200
On 2025-04-23 19:17, Gunnar Wolf wrote:
> Adam D. Barratt dijo [Wed, Apr 23, 2025 at 05:13:07PM +0100]:
>>> Ah, then this would seem to be safe to deploy now, and the file types
>>> problem could be fixed later on. I have had several changes for
>>> userdir-ldap pending submission, but not this one about
>>> shutil.copy(), thanks. Will see how to improve that, and then send
>>> patches for userdir-ldap to DSA (I think I already sent out patches
>>> for userdir-ldap-cgi).
>>
>> "Probably". If it doesn't work for some reason, however, the effects
>> could include things such as dak no longer accepting any uploads from
>> DDs because it can no longer find their public keys.
>>
>> I'd therefore be tempted to disable both the "pull" and "push" sides
>> on
>> db.d.o shortly before the keyring side is deployed, and test them by
>> hand afterwards.
>>
>> I can't personally guarantee being around at any particular time this
>> week though I'm afraid.
>
> ..It makes sense to make sure we have a DSA person available to fix
> things
> in case it all bursts up in flames.
>
> I was planning on doing this push this Friday, 2025.04.25, in the
> morning
> (say, anywhere between 09:00–14:00 GMT-6). Can a DSA member be
> available in
> case this messes up something?
>
> Otherwise, I think it's better to listen to Adam's instinct and delay
> the
> move. It does not necessarily have to be aligned with a "full" keyring
> push.
Can we push .gpg and .pgp files with identical content for a while?
That'd decouple necessary realtime interactions. I realize that this
does not fix the fact that we might break stuff once we replace .gpg
files with a symlink - but it also opens up the opportunity that we can
also replace the references instead.
Kind regards
Philipp Kern
Acknowledgement sent
to Guillem Jover <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Keyring Maintainers <[email protected]>.
(Wed, 23 Apr 2025 21:21:02 GMT) (full text, mbox, link).
Subject: Re: Please help confirm: Does #1101418 sound like it will break
havoc?
Date: Wed, 23 Apr 2025 23:16:49 +0200
Hi!
On Wed, 2025-04-23 at 21:23:20 +0200, Philipp Kern wrote:
> On 2025-04-23 19:17, Gunnar Wolf wrote:
> > Adam D. Barratt dijo [Wed, Apr 23, 2025 at 05:13:07PM +0100]:
> > > > Ah, then this would seem to be safe to deploy now, and the file types
> > > > problem could be fixed later on. I have had several changes for
> > > > userdir-ldap pending submission, but not this one about
> > > > shutil.copy(), thanks. Will see how to improve that, and then send
> > > > patches for userdir-ldap to DSA (I think I already sent out patches
> > > > for userdir-ldap-cgi).
> > >
> > > "Probably". If it doesn't work for some reason, however, the effects
> > > could include things such as dak no longer accepting any uploads from
> > > DDs because it can no longer find their public keys.
> > >
> > > I'd therefore be tempted to disable both the "pull" and
> > > "push" sides on
> > > db.d.o shortly before the keyring side is deployed, and test them by
> > > hand afterwards.
> > >
> > > I can't personally guarantee being around at any particular time this
> > > week though I'm afraid.
> >
> > ..It makes sense to make sure we have a DSA person available to
> > fix things
> > in case it all bursts up in flames.
> >
> > I was planning on doing this push this Friday, 2025.04.25, in
> > the morning
> > (say, anywhere between 09:00–14:00 GMT-6). Can a DSA member be
> > available in
> > case this messes up something?
> >
> > Otherwise, I think it's better to listen to Adam's instinct and
> > delay the
> > move. It does not necessarily have to be aligned with a "full" keyring
> > push.
>
> Can we push .gpg and .pgp files with identical content for a while?
> That'd decouple necessary realtime interactions. I realize that this
> does not fix the fact that we might break stuff once we replace .gpg
> files with a symlink - but it also opens up the opportunity that we
> can also replace the references instead.
I was thinking something along those lines (as in decouple the archive
switch from the infra switch), as my current main interest right now
would be for the changes to hit Debian trixie, via the .deb in the
archive. But it's true that just duplicating the files might be safer,
and as you mention then we can just simply flip the infra users, and
then later on whether it's a symlink or not will not matter as much I
guess.
I'll try to come up with an updated patch for debian-keyring trying to
decouple the package generation from the infra syncing, hopefully by
tomorrow (Thu), or maybe later today.
Thanks,
Guillem
Acknowledgement sent
to Guillem Jover <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Keyring Maintainers <[email protected]>.
(Thu, 24 Apr 2025 01:48:01 GMT) (full text, mbox, link).
Hi!
On Wed, 2025-04-23 at 23:16:51 +0200, Guillem Jover wrote:
> On Wed, 2025-04-23 at 21:23:20 +0200, Philipp Kern wrote:
> > Can we push .gpg and .pgp files with identical content for a while?
> > That'd decouple necessary realtime interactions. I realize that this
> > does not fix the fact that we might break stuff once we replace .gpg
> > files with a symlink - but it also opens up the opportunity that we
> > can also replace the references instead.
>
> I was thinking something along those lines (as in decouple the archive
> switch from the infra switch), as my current main interest right now
> would be for the changes to hit Debian trixie, via the .deb in the
> archive. But it's true that just duplicating the files might be safer,
> and as you mention then we can just simply flip the infra users, and
> then later on whether it's a symlink or not will not matter as much I
> guess.
>
> I'll try to come up with an updated patch for debian-keyring trying to
> decouple the package generation from the infra syncing, hopefully by
> tomorrow (Thu), or maybe later today.
So this ended up being trivial, as I had already split the logic and
was creating the symlinks for the packaging independently from the
previous symlinks for the infra, which I've now switched to being
hardlinks. This seems safe, because even if they end up being copied
as new files, then we at most just lose some space, but should have no
other consequence given that they are going to be proper files. (If
there's still concern about this I guess I could switch that to a
«cp -a» call?). Attached updated patch.
Thanks,
Guillem
Acknowledgement sent
to Gunnar Wolf <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Keyring Maintainers <[email protected]>.
(Sat, 26 Apr 2025 06:54:02 GMT) (full text, mbox, link).
Philipp Kern dijo [Wed, Apr 23, 2025 at 09:23:20PM +0200]:
>Can we push .gpg and .pgp files with identical content for a while?
>That'd decouple necessary realtime interactions. I realize that this
>does not fix the fact that we might break stuff once we replace .gpg
>files with a symlink - but it also opens up the opportunity that we
>can also replace the references instead.
Thanks for this simple but brilliant idea, Philipp! That's what we did —
and, at least for a couple of hours, no part of the project has come down
crashing and burning over us ☺
Acknowledgement sent
to "Adam D. Barratt" <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Keyring Maintainers <[email protected]>.
(Sat, 26 Apr 2025 08:54:01 GMT) (full text, mbox, link).
Subject: Re: Bug#1101418: Please help confirm: Does #1101418 sound like it
will break havoc?
Date: Sat, 26 Apr 2025 09:52:01 +0100
On Sat, 2025-04-26 at 00:50 -0600, Gunnar Wolf wrote:
> Philipp Kern dijo [Wed, Apr 23, 2025 at 09:23:20PM +0200]:
> > Can we push .gpg and .pgp files with identical content for a while?
> > That'd decouple necessary realtime interactions. I realize that
> > this does not fix the fact that we might break stuff once we
> > replace .gpg files with a symlink - but it also opens up the
> > opportunity that we can also replace the references instead.
>
> Thanks for this simple but brilliant idea, Philipp! That's what we
> did — and, at least for a couple of hours, no part of the project has
> come down crashing and burning over us ☺
Yay. :-)
Just for completeness, the complete set of files was synced from
kaufmann to db.d.o:
-rw-rw-r-- 1 keyring-sync keyring-sync 2722836 Apr 26 01:25 emeritus-keyring.pgp
-rw-rw-r-- 1 keyring-sync keyring-sync 2722836 Apr 26 01:25 emeritus-keyring.gpg
-rw-rw-r-- 1 keyring-sync keyring-sync 26383 Apr 26 01:25 debian-role-keys.pgp
-rw-rw-r-- 1 keyring-sync keyring-sync 26383 Apr 26 01:25 debian-role-keys.gpg
-rw-rw-r-- 1 keyring-sync keyring-sync 1100581 Apr 26 01:25 debian-nonupload.pgp
-rw-rw-r-- 1 keyring-sync keyring-sync 1100581 Apr 26 01:25 debian-nonupload.gpg
-rw-rw-r-- 1 keyring-sync keyring-sync 2928260 Apr 26 01:25 debian-maintainers.pgp
-rw-rw-r-- 1 keyring-sync keyring-sync 2928260 Apr 26 01:25 debian-maintainers.gpg
-rw-rw-r-- 1 keyring-sync keyring-sync 30786413 Apr 26 01:25 debian-keyring.pgp
-rw-rw-r-- 1 keyring-sync keyring-sync 30786413 Apr 26 01:25 debian-keyring.gpg
with ud-ldap then shipping on just the .gpg files to consuming systems
(e.g. ftp-master) as before.
Regards,
Adam
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.