[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: EC SRM key for bookworm?



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                                      jmw@debian.org
Debian Developer                         http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1


Reply to: