Bug#1031800: mmdebstrap: --keyring doesn't work properly

[Dima Kogan]

Package: mmdebstrap
Version: 1.3.1-2
Severity: normal
X-Debbugs-Cc: none, Dima Kogan <dko...@debian.org>


Hi. I'm using mmdebstrap to bootstrap an install that uses the normal
Debian repos AND my own repo. My repo is signed with a key that lives in
$PWD/keys/something.gpg. I pass --keyring=$PWD/keys as suggested in the
docs, but this doesn't work for some mysterious reason. No clear
diagnostics are avaible, with --verbose saying nothing extra. This is
what I see:

$ sudo mmdebstrap \
--architectures=arm64 \
--keyring=$PWD/keys \
--aptopt 'Acquire::https::MY_REPO_DOMAIN::Verify-Peer "false"' \
bookworm \
bookworm-tst \
http://deb.debian.org/debian \
http://MY_REPO_DOMAIN/public/debian/bookworm

I: automatically chosen mode: root
I: arm64 cannot be executed natively, but transparently using qemu-user binfmt emulation
I: finding correct signed-by value...
I: automatically chosen format: directory
I: running apt-get update...
Get:1 https://MY_REPO_DOMAIN/public/debian/bookworm bookworm InRelease [5136 B]
Get:2 http://deb.debian.org/debian bookworm InRelease [177 kB]
Err:1 https://MY_REPO_DOMAIN/public/debian/bookworm bookworm InRelease
The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 221CA67104340B68
Get:3 http://deb.debian.org/debian bookworm/main arm64 Packages [8909 kB]
Reading package lists...
W: GPG error: https://MY_REPO_DOMAIN/public/debian/bookworm bookworm InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 221CA67104340B68
E: The repository 'http://MY_REPO_DOMAIN/public/debian/bookworm bookworm InRelease' is not signed.
E: apt-get update --error-on=any -oAPT::Status-Fd=<$fd> -oDpkg::Use-Pty=false failed
I: main() received signal PIPE: waiting for setup...
E: mmdebstrap failed to run

This should work, but it doesn't. I used sysdig to confirm that
something is indeed looking in $PWD/keys/ and something is indeed
calling read() on the relevant key. I have also confirmed that if I copy
my keys to /etc/apt/trusted.gpg.d/ then it does work properly. But I
don't want to do that. Ideally I'd like mmdebstrap to grab all the keys
in $PWD/keys and add them to /etc/apt/trusted.gpg.d/ in the chroot, but
NOT on the host machine. Any clear way to do that? Any debugging tricks
I'm missing?

Thanks!

-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (800, 'unstable'), (700, 'testing'), (500, 'unstable-debug'), (500, 'stable')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: armhf, armel

Kernel: Linux 6.1.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mmdebstrap depends on:
ii apt 2.5.2
ii perl 5.36.0-4
ii python3 3.10.6-1

Versions of packages mmdebstrap recommends:
pn arch-test <none>
pn fakechroot <none>
ii fakeroot 1.29-1
ii gpg 2.2.35-3
ii libdistro-info-perl 1.1
ii libdpkg-perl 1.21.19
ii mount 2.38.1-1
pn uidmap <none>

Versions of packages mmdebstrap suggests:
pn apt-transport-tor <none>
ii apt-utils 2.5.2
ii binfmt-support 2.2.2-1
ii ca-certificates 20211016
ii debootstrap 1.0.127
ii distro-info-data 0.54
ii dpkg-dev 1.21.19
pn genext2fs <none>
ii perl-doc 5.36.0-4
pn qemu-user <none>
ii qemu-user-static 1:7.0+dfsg-7+b1
pn squashfs-tools-ng <none>

-- no debconf information

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Dima Kogan (2023-02-23 00:45:37)

> This should work, but it doesn't. I used sysdig to confirm that
> something is indeed looking in $PWD/keys/ and something is indeed
> calling read() on the relevant key. I have also confirmed that if I copy
> my keys to /etc/apt/trusted.gpg.d/ then it does work properly. But I
> don't want to do that. Ideally I'd like mmdebstrap to grab all the keys
> in $PWD/keys and add them to /etc/apt/trusted.gpg.d/ in the chroot, but
> NOT on the host machine. Any clear way to do that? Any debugging tricks
> I'm missing?

there unfortunately exists no way to ask apt for more information about why
"apt-get update" fails. So lets try to figure out whether this is an apt
problem or an mmdebstrap problem. At the end of the mmdebstrap man page you
find a small shell script:

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"
APT_CONFIG="$2/apt.conf" apt-get update
APT_CONFIG="$2/apt.conf" apt-get --yes --download-only install '?essential'
for f in "$2"/var/cache/apt/archives/*.deb; do dpkg-deb --extract "$f" "$2"; done
chroot "$2" sh -c "dpkg --install --force-depends /var/cache/apt/archives/*.deb"

This script sets up a chroot in the same way as mmdebstrap does. But now you
can directly change some values like Dir::Etc::TrustedParts which you can now
explicitly set to your keyring directory. If you do that (and also put your
mirror into the sources.list), what happens?

Thanks!

cheers, josch

[Dima Kogan]

Hi josch. Thanks for replying!

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?


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?

Thanks

[Johannes Schauer Marin Rodrigues]

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

[Dima Kogan]

Johannes Schauer Marin Rodrigues <jo...@debian.org> writes:

> you were now able to reproduce the problem without mmdebstrap but with
> plain apt. This suggests that your problem is not an mmdebstrap
> problem.

OK. Good to know.

>> 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.

Thanks.

> 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?

This looks exactly like my problem, yes.

> 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?

Doesn't work for me. I exported the public key both in binary and ascii
formats, put them both in the keys/ directory (given to --keyring), and
I get the same error as before. The keys are there:

$ file keys/KEY.{asc,gpg}

keys/KEY.asc: PGP public key block Public-Key (old)
keys/KEY.gpg: OpenPGP Public Key Version 4, Created Wed Feb 22 22:07:13 2023, RSA (Encrypt or Sign, 4096 bits); User ID; Signature; OpenPGP Certificate

And once again, I can confirm that the keys are right because copying
them (or just one) to /etc/apt/trusted.gpg.d/ makes it happy. Is there
no way to ask apt for diagnostics? Should I reassign this bug report to
apt?

Thanks

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Dima Kogan (2023-02-24 06:31:03)

There may be some apt debugging options for this but one usually has to read
the apt sources to find the name of those options. Since you are able to
reproduce your problem without mmdebstrap but with apt only using the script
above, this problem is definitely not due to mmdebstrap but is either an apt
problem or a problem of how you try using apt. Either way, I think it's best to
get the apt maintainers involved.

The weirdest thing about your bug is that copying your key to
/etc/apt/trusted.gpg.d/ makes it work for you because when you changed the
location of Dir::Etc::TrustedParts it just pointed to a different directory.
Apt should not treat keys differently just because the path to them looks
different...

Thanks!

cheers, josch

[Dima Kogan]

Johannes Schauer Marin Rodrigues <jo...@debian.org> writes:

> The weirdest thing about your bug is that copying your key to
> /etc/apt/trusted.gpg.d/ makes it work for you because when you changed the
> location of Dir::Etc::TrustedParts it just pointed to a different directory.
> Apt should not treat keys differently just because the path to them looks
> different...

Hi Josch. Thanks for looking into this. You're right, it sounds weird
that apt would care about the name of the directory, so I just poked at
it again.

It's not actually that weird; I just wasn't looking at the error
messages closely enough. The /etc/apt/sources.list has two repos:

- main bookworm repo. Signed with the Debian keys
- my repo. Signed with its own key

If I "mmdebstrap --keyring MY-KEY-DIRECTORY" then apt actually does find
the keys to my repo, and it's happy about it. The problem is that it
then doesn't look in /etc/apt/trusted.gpg.d and it thinks the main
bookworm repo is unverifiable. So there's no mystery here, but my use
case still doesn't work. Some questions, if I may:

- By default apt has /etc/apt/trusted.gpg and /etc/apt/trusted.gpg.d/*.
Which of these is expected to contain the keys for Debian?

- I want mmdebstrap to use the extra repo and the keys, so what's the
right way to do that? I guess I need to:

- Create new key directory

- Copy /etc/apt/trusted.gpg and /etc/apt/trusted.gpg.d/* and my new
keys into it

- Pass that to mmdebstrap --keyring

- Add my new keys into the chroot with an mmdebstrap hook so that
these are available inside the chroot

Is that right? If so, can we make this explicit in the manpage?

Thank you very much!

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Dima Kogan (2023-02-28 22:56:26)

> It's not actually that weird; I just wasn't looking at the error messages
> closely enough. The /etc/apt/sources.list has two repos:
>
> - main bookworm repo. Signed with the Debian keys
> - my repo. Signed with its own key
>
> If I "mmdebstrap --keyring MY-KEY-DIRECTORY" then apt actually does find
> the keys to my repo, and it's happy about it. The problem is that it
> then doesn't look in /etc/apt/trusted.gpg.d and it thinks the main
> bookworm repo is unverifiable. So there's no mystery here, but my use case
> still doesn't work.

ah yes, that makes sense. :)

> Some questions, if I may:
>
> - By default apt has /etc/apt/trusted.gpg and /etc/apt/trusted.gpg.d/*.
> Which of these is expected to contain the keys for Debian?

It seems that /etc/apt/trusted.gpg is a historic relic and keys from it are
removed by the postinst of debian-archive-keyring with the following code
comment next to it:

# remove keys from the trusted.gpg file as they are now shipped in fragment
# files in trusted.gpg.d

> - I want mmdebstrap to use the extra repo and the keys, so what's the right
> way to do that? I guess I need to:
>
> - Create new key directory
>
> - Copy /etc/apt/trusted.gpg and /etc/apt/trusted.gpg.d/* and my new
> keys into it
>
> - Pass that to mmdebstrap --keyring
>
> - Add my new keys into the chroot with an mmdebstrap hook so that
> these are available inside the chroot
>
> Is that right? If so, can we make this explicit in the manpage?

I probably never should've added the --keyring argument. Its documentation
already states:

> Since apt only supports a single keyring file and directory, respectively,
> you can not use this option to pass multiple files and/or directories.

You can create a directory and copy your keys into it, yes. But the docs for
--keyring also suggest that you use signed-by instead. Is that not a better
solution than copying keys from debian-archive-keyring around? If you use
signed-by you also do not need the --keyring argument anymore.

Though I agree that I should also add some more information to the --keyring
argument. What do you think about the following patch? If that patch does not
answer the questions you've had, please tell me and I improve the patch.
Thanks!

t a/mmdebstrap b/mmdebstrap
index 01d9954..f450049 100755
--- a/mmdebstrap
+++ b/mmdebstrap
@@ -6366,13 +6366,22 @@ Example: Minimizing the number of packages installed from experimental

=item B<--keyring>=I<file>|I<directory>

-Change the default keyring to use by apt. By default, F</etc/apt/trusted.gpg>
-and F</etc/apt/trusted.gpg.d> are used. Depending on whether a file or
-directory is passed to this option, the former and latter default can be
-changed, respectively. Since apt only supports a single keyring file and
-directory, respectively, you can B<not> use this option to pass multiple files
-and/or directories. Using the C<--keyring> argument in the following way is
-equal to keeping the default:
+Change the default keyring to use by apt during the initial setup. This is
+similar to setting B<Dir::Etc::Trusted> and B<Dir::Etc::TrustedParts> using
+B<--aptopt> except that the latter setting will be permanently stored in the
+chroot while the keyrings passed via <--keyring> will only be visible to apt as
+run by B<mmdebstrap>. Do not use B<--keyring> if apt inside the chroot needs to
+know about your keys after the initial chroot creation by B<mmdebstrap>.
+
+By default, the local setting of B<Dir::Etc::Trusted> and
+B<Dir::Etc::TrustedParts> are used to choose the keyring used by apt as run by
+B<mmdebstrap>. These two locations are set to F</etc/apt/trusted.gpg> and
+F</etc/apt/trusted.gpg.d> by default. Depending on whether a file or directory
+is passed to this option, the former and latter default can be changed,
+respectively. Since apt only supports a single keyring file and directory,
+respectively, you can B<not> use this option to pass multiple files and/or
+directories. Using the C<--keyring> argument in the following way is equal to
+keeping the default:

--keyring=/etc/apt/trusted.gpg --keyring=/etc/apt/trusted.gpg.d

@@ -6381,6 +6390,10 @@ specifying the mirror like this:

mmdebstrap mysuite out.tar "deb [signed-by=/path/to/key.gpg] http://..."

+Another reason to use C<signed-by> instead of B<--keyring> is if apt inside the
+chroot needs to know by what key the repository is signed even after the
+initial chroot creation.
+
The C<signed-by> option will automatically be added to the final
C<sources.list> if the keyring required for the selected I<SUITE> is not yet
trusted by apt. Automatically adding the C<signed-by> option in these cases
@@ -6392,6 +6405,13 @@ installed, then you can create a Ubuntu Bionic chroot on Debian like this:
The resulting chroot will have a C<source.list> with a C<signed-by> option
pointing to F</usr/share/keyrings/ubuntu-archive-keyring.gpg>.

+You do not need to use B<--keyring> or C<signed-by> if you placed the keys that
+apt needs to know about into F</etc/apt/trusted.gpg.d> in the B<--setup-hook>
+(which is before C<apt update> runs), for example by using the <copy-in>
+special hook. You also need to copy your keys into the chroot explicitly if the
+key you passed via C<signed-by> points to a location that is not otherwise
+populated during chroot creation (for example by installing a keyring package).
+
=item B<--dpkgopt>=I<option>|I<file>

Pass arbitrary I<option>s to dpkg. Will be permanently added to

[Dima Kogan]

Hi.

Johannes Schauer Marin Rodrigues <jo...@debian.org> writes:

> It seems that /etc/apt/trusted.gpg is a historic relic and keys from it are
> removed by the postinst of debian-archive-keyring with the following code
> comment next to it:
>
> # remove keys from the trusted.gpg file as they are now shipped in fragment
> # files in trusted.gpg.d

OK. Good to know. Thanks for looking it up

> I probably never should've added the --keyring argument. Its documentation
> already states:
>
>> Since apt only supports a single keyring file and directory, respectively,
>> you can not use this option to pass multiple files and/or directories.

I did see that note. But for most other stuff in /etc the main config
lives in /etc/thing, and optional extra stuff lives in /etc/thing.d/ so
my (incorrect!) assumption was that the main keys live in
/etc/apt/trusted.gpg and if I added my extra thing to
/etc/apt/trusted.gpg.d/ then I'd have the full set of stuff. If we
transitioned to /etc/apt/trusted.gpg.d/ being the main set of keys, we
REALLY should delete /etc/apt/trusted.gpg to avoid any confusion.

I do think --keyring can be useful if we change what it does. mmdebstrap
can gather all the keys in all the --keyring arguments, put them all
into a new directory, feed that to Dir::Etc::TrustedParts, and put that
into /etc/apt/trusted.gpg.d/ in the final chroot. You can say that
without any --keyring arguments it uses /etc/apt/trusted.gpg and
/etc/apt/trusted.gpg.d/, but with any --keyring you have to specify them
all explicitly, including /etc/apt/....

> You can create a directory and copy your keys into it, yes. But the docs for
> --keyring also suggest that you use signed-by instead. Is that not a better
> solution than copying keys from debian-archive-keyring around? If you use
> signed-by you also do not need the --keyring argument anymore.

I saw that too. I had a reason to not do that, but I now think that
reason is wrong. I was concerned that I could have different keys for
signing the repository (InRelease file) and for signing the various
packages inside it. But the only key I care about here is the
repo-signing key, so that signed-by would have been just fine, I think.

I like your documentation patch. And now that I realize that the
repository key is the main one to care about, maybe --keyring isn't
needed most of the time, as you say.

Thanks for looking at this.

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Dima Kogan (2023-03-02 07:00:13)

> >> Since apt only supports a single keyring file and directory, respectively,
> >> you can not use this option to pass multiple files and/or directories.
>
> I did see that note. But for most other stuff in /etc the main config
> lives in /etc/thing, and optional extra stuff lives in /etc/thing.d/ so
> my (incorrect!) assumption was that the main keys live in
> /etc/apt/trusted.gpg and if I added my extra thing to
> /etc/apt/trusted.gpg.d/ then I'd have the full set of stuff. If we
> transitioned to /etc/apt/trusted.gpg.d/ being the main set of keys, we
> REALLY should delete /etc/apt/trusted.gpg to avoid any confusion.

if I remember discussions in #debian-apt correctly, then moving away from
/etc/apt/trusted.gpg is indeed the plan.

> I do think --keyring can be useful if we change what it does. mmdebstrap can
> gather all the keys in all the --keyring arguments, put them all into a new
> directory, feed that to Dir::Etc::TrustedParts, and put that into
> /etc/apt/trusted.gpg.d/ in the final chroot. You can say that without any
> --keyring arguments it uses /etc/apt/trusted.gpg and /etc/apt/trusted.gpg.d/,
> but with any --keyring you have to specify them all explicitly, including
> /etc/apt/....

But that is not how --keyring works in debootstrap. As I mentioned in my last
mail, I probably should never have added the --keyring argument. After this
bug, I'm thinking about deprecating this option and printing a warning if
somebody uses it. mmdebstrap tries to be a 90% debootstrap drop-in replacement
and debootstrap has the --keyring argument which allows you to pass a keyring
that will be used to verify the downloaded Release file but which will *not* be
permanently stored in the chroot. That's why the mmdebstrap --keyring argument
doesn't store the keys permanently either. So the --keyring argument is only a
convenience option and indeed its functionality can be achieved using other
options as well. Its main reason for existance is to make debootstrap users
happy. In your case, since you have multiple repositories, you cannot use
debootstrap but that's also why the limitation that only one keyring can be
passed is not a problem for people who use the --keyring argument as they would
with debootstrap because they do not use multiple repositories anyways.

If you do use multiple repositories, don't use keyring but signed-by as the
documentation of --keyring now points out.

> > You can create a directory and copy your keys into it, yes. But the docs
> > for --keyring also suggest that you use signed-by instead. Is that not a
> > better solution than copying keys from debian-archive-keyring around? If
> > you use signed-by you also do not need the --keyring argument anymore.
>
> I saw that too. I had a reason to not do that, but I now think that
> reason is wrong. I was concerned that I could have different keys for
> signing the repository (InRelease file) and for signing the various
> packages inside it. But the only key I care about here is the
> repo-signing key, so that signed-by would have been just fine, I think.
>
> I like your documentation patch. And now that I realize that the
> repository key is the main one to care about, maybe --keyring isn't needed
> most of the time, as you say.

If you think that there is no more to handle in this bug, please close it.

Thanks!

cheers, josch