Hi, Quoting Dima Kogan (2023-02-23 18:55:01) > I just ran your script up to the "apt update", having the shell substitute $1 > <- "bookworm" and $2 <- "DIRECTORY_FOR_CHROOT", and adding my new repo: > > mkdir -p "$2/etc/apt" "$2/var/cache" "$2/var/lib" > cat << END > "$2/apt.conf" > Apt::Architecture "$(dpkg --print-architecture)"; > Apt::Architectures "$(dpkg --print-architecture)"; > Dir "$(cd "$2" && pwd)"; > Dir::Etc::Trusted "$(eval "$(apt-config shell v Dir::Etc::Trusted/f)"; > printf "$v")"; > Dir::Etc::TrustedParts "$(eval "$(apt-config shell v > Dir::Etc::TrustedParts/d)"; printf "$v")"; > END > echo "deb http://deb.debian.org/debian/ $1 main" > > "$2/etc/apt/sources.list" > echo "deb http://MYREPO $1 main" >> > "$2/etc/apt/sources.list" > > After I do this, DIRECTORY_FOR_CHROOT/apt.conf contains: > > Apt::Architecture "amd64"; > Apt::Architectures "amd64"; > Dir "/home/dima/cadre/packaging/bookworm2-tst"; > Dir::Etc::Trusted "/etc/apt/trusted.gpg"; > Dir::Etc::TrustedParts "/etc/apt/trusted.gpg.d/"; > > Note that the Trusted keys are in the host, NOT in the chroot, so > naturally the "apt update" complains about the missing keys. If I change > the last line to > > Dir::Etc::TrustedParts "MY_KEYRING_DIRECTORY"; > > then "apt update" still complains. And once again sysdig tells me that > it IS actually finding and using my keys. Suggestions?
you were now able to reproduce the problem without mmdebstrap but with plain apt. This suggests that your problem is not an mmdebstrap problem. > And I have another related question. I can workaround this by copying my keys > to /etc/apt/trusted.gpg.d/ on the host. This makes mmdebstrap happy, but the > resulting chroot doesn't have my keys in ITS /etc/apt/trusted.gpg.d. So an > "apt update" inside the chroot has the same problem as before: complaining > that my repo is unverifiable. The docs aren't clear on whether those keys are > supposed to be copied or not. Are they? If not, am I supposed to do that > manually via an mmdebstrap hook? mmdebstrap will not automatically copy the keys it needs to some location into the chroot. If your chroot needs extra key material for later "apt update" runs it's up to you to copy the keys into the chroot at a location you like. I also think I found the source of your problem. I reproduced your issue locally like this: sq key generate --userid "<jul...@example.org>" --export juliet.key.pgp sq key extract-cert --output juliet.cert.pgp juliet.key.pgp apt-ftparchive release . > Release sq sign --signer-key juliet.key.pgp --cleartext-signature --output=InRelease Release mmdebstrap --keyring=/home/josch/repo/ --variant=apt unstable /dev/null http://deb.debian.org/debian "deb copy:///home/josch/repo ./" [...] I: running apt-get update... done Get:1 copy:/home/josch/repo ./ InRelease [1190 B] Get:2 http://deb.debian.org/debian unstable InRelease [180 kB] Err:1 copy:/home/josch/repo ./ InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY FC8F3FACCD368D66 Get:3 http://deb.debian.org/debian unstable/main arm64 Packages [9282 kB] Reading package lists... W: GPG error: copy:/home/josch/repo ./ InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY FC8F3FACCD368D66 E: The repository 'copy:/home/josch/repo ./ InRelease' is not signed. This is your problem, right? To fix it, I did this: mv juliet.cert.pgp juliet.cert.asc The clue can be found in the man page of apt-key: Alternatively, if all systems which should be using the created keyring have at least apt version >= 1.4 installed, you can use the ASCII armored format with the "asc" extension instead which can be created with gpg --armor --export. Can you confirm that you also had a ASCII armored key stored with the .gpg extension instead of .asc and that changing the extension makes apt happy? Thanks! cheers, josch
