Hi,

Quoting Mike Hommey (2021-02-03 02:27:12)
> Running `mmdebstrap --variant=extract jessie` fails with
> ```
> E: The repository 'http://deb.debian.org/debian jessie Release' is not signed.
> ```
> after multiple GPG warnings.
> 
> Adding `--keyring /usr/share/keyrings/debian-archive-removed-keys.gpg`
> works around it, but a cursory look at the code suggests this is supposed to
> happen automatically.

yes, I do not have a good solution for this. Given a string of a distribution
like "jessie" or "xenial" -- how do we figure out which keyring to use so that
apt can successfully run?

The problem is not trivial, because there is no way to ask apt in a machine
readable way whether an "apt-get update" run failed because of a missing key or
because of another reason. See:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778357#28

So what is currently done is to look up in /usr/share/distro-info/*.csv and in
/usr/share/debootstrap/scripts/ which vendor the suite name belongs to. Then we
ask Dpkg::Vendor for for the value archive-keyrings or
archive-keyrings-historic -- which of the two is being used depends on the EOL
value that was found in the distro-info data. In case of Jessie, EOL was
reached, so we use archive-keyrings-historic which resolves to
/usr/share/keyrings/debian-archive-removed-keys.gpg and is wrong.

The reason it works with --keyring is because that option sets the
Dir::Etc::trusted value but keeps Dir::Etc::trustedparts as it is. The jessie
key is *not* in debian-archive-removed-keys.gpg but it is probably in
/etc/apt/trusted.gpg.d/ which is the default value for Dir::Etc::trustedparts.

Any ideas of how to improve the situation is welcome.

It would be great if we somehow would somewhere maintain a mapping from suite
name to keyring.

Thanks!

cheers, josch

Attachment: signature.asc
Description: signature

Reply via email to