On Fri, Mar 10, 2023 at 12:30:15PM +0200, Adrian Bunk wrote:
On Fri, Mar 10, 2023 at 09:27:30AM +0000, Adam D. Barratt wrote:
On Sat, 2023-03-04 at 16:03 +0200, Adrian Bunk wrote:
On Sat, Mar 04, 2023 at 01:33:13PM +0000, Adam D. Barratt wrote:
SRM is considering using an ed25519 GPG key for bookworm. Does
anyone
see any issues with that?
...
We know that GPG(V) 1.X can't handle EC keys,
...
in all releases from stretch to bookworm:
Package: apt
Depends: ..., gpgv | gpgv2 | gpgv1, ...
This has to become only[1] "gpgv" in at least bullseye and bookworm, otherwise there would be users running into problems - even in
unstable "apt-get remove gpgv" works and installs "gpgv1" instead.
FWIW I can't replicate that on bullseye:
$ sudo apt-get remove gpgv
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
[...]
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
apt apt-utils debian.org debian.org-recommended debian.org- recommended-bullseye devscripts gnupg gpgv
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
apt gpgv (due to apt)
...
Using fresh chroots created with
debootstrap bullseye bullseye
and
debootstrap sid sid
as testcases, apt in unstable does find the solution of installing gpgv1
when removing gpgv but apt in bullseye does not.
But the following should always work:
# apt-get install gpgv1
# apt-get remove gpgv
And something like this might have happened for various odd reasons in
the past years.
I ran upgrade tests of a standard system from jessie onwards (wheezy's dpkg enjoyed segfaulting reliably for me and it's not important for this test).
In jessie apt does not have the alternative Depends line, and debian-archive-keyring (d-a-k) has Depends: gpgv.
In stretch apt gains the alternatives, and d-a-k continues to Depends:
gpgv. gpgv becomes version 2 and the gpgv1 package is introduced.
From buster onwards d-a-k drops its dependency.
Thus a standard system without any fiddling *must* have gained gpgv(2)
along the way and will be able to verify the new signature. We don't
support release skipping.
I did not succeed in tricking apt to give me that solution in any of these releases, so it only appears to be an issue in sid.
apt with *only* gpgv1 installed does fall back onto it automatically, so
it's true that if a user set that situation up they wouldn't know until the signature failed to validate. The two packages can happily co-exist.
I think a release note to that effect ("make sure you have gpgv installed")
is sufficient and we're otherwise safe to do this, unless anyone has found other problems.
--
Jonathan Wiltshire
[email protected]
Debian Developer
http://people.debian.org/~jmw
4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)