Comment 4 for bug 646499

Steve Langasek (vorlon) wrote :

> Thinking about this, the problem is presumably that the pointed-to apt config
> does not have any keys available.

Confirmed. I can avoid this error in one of two ways:
 - Add "-o Dir::Etc::Trusted=/etc/apt/trusted.gpg" to the apt commandline, to point at the system keyring
 - pre-populate the etc/apt/trusted.gpg in the chroot target directory before calling apt-get.

> This makes me wonder how this worked with older versions of apt.

I suspect (but have not confirmed) that in older versions of apt, the Dir::Etc::Trusted value did not inherit from Dir::Etc and therefore always used /etc/apt. Regardless of the details of the previous behavior, I don't see any way that the current behavior should be considered a bug.

> So, to go back to first principles: If we are trying to install a set of packages
> into an empty chroot, what does apt need in the pointed-to config in order
> to be satisfied about authentication? Does any tool doing this need to
> pre-download the necessary archive keyrings (or otherwise get the necessary
> keys) and then run apt-key add using the pointed-at apt config?

It needs to be pointed at a keyring containing the public keys for the archives you're trying to install. In the debootstrap case this is not an issue, because debootstrap doesn't invoke apt but instead wgets all of the files and verifies signatures and checksums internally. Multistrap, because it composes a new apt config for the initial bootstrapping, needs to have apt handle this itself.

So I don't think there's an actionable bug here; closing this report.