E: cannot read /etc/apt/trusted.gpg.d/ #27

Closed
opened 2022-09-11 15:30:15 +00:00 by zkemwjcy · 14 comments

mmdebstrap 1.2.1 on debian bookworm

I don't have the directory /etc/apt/trusted.gpg.d/ and mmdebstrap fails with the error E: cannot read /etc/apt/trusted.gpg.d/

The reason why I don't have that directory is because I define the signing keys in the deb822-style debian.sources directly.

If I simply create that directory, but keep it empty, mmdebstrap works.

mmdebstrap should not assume that that directory exists.

`mmdebstrap 1.2.1` on debian bookworm I don't have the directory `/etc/apt/trusted.gpg.d/` and `mmdebstrap` fails with the error `E: cannot read /etc/apt/trusted.gpg.d/` The reason why I don't have that directory is because I define the signing keys in the deb822-style debian.sources directly. If I simply create that directory, but keep it empty, mmdebstrap works. mmdebstrap should not assume that that directory exists.
Owner

I'm a bit puzzled. Does this mean you do not have the debian-archive-keyring package installed on your system??

I'm a bit puzzled. Does this mean you do not have the `debian-archive-keyring` package installed on your system??
Author

I have debian-archive-keyring installed, and the keys are in /usr/share/keyrings/

This is how my /etc/apt/sources.list.d/bullseye.sources looks like:

Types: deb
URIs: https://deb.debian.org/debian
Suites: bullseye
Components: main contrib non-free
Signed-By: /usr/share/keyrings/debian-archive-bullseye-stable.gpg

Types: deb
URIs: https://deb.debian.org/debian
Suites: bullseye-updates bullseye-backports
Components: main contrib non-free
Signed-By: /usr/share/keyrings/debian-archive-bullseye-automatic.gpg

Types: deb
URIs: https://deb.debian.org/debian-security
Suites: bullseye-security
Components: main contrib non-free
Signed-By: /usr/share/keyrings/debian-archive-bullseye-security-automatic.gpg
I have `debian-archive-keyring` installed, and the keys are in `/usr/share/keyrings/` This is how my `/etc/apt/sources.list.d/bullseye.sources` looks like: ``` Types: deb URIs: https://deb.debian.org/debian Suites: bullseye Components: main contrib non-free Signed-By: /usr/share/keyrings/debian-archive-bullseye-stable.gpg Types: deb URIs: https://deb.debian.org/debian Suites: bullseye-updates bullseye-backports Components: main contrib non-free Signed-By: /usr/share/keyrings/debian-archive-bullseye-automatic.gpg Types: deb URIs: https://deb.debian.org/debian-security Suites: bullseye-security Components: main contrib non-free Signed-By: /usr/share/keyrings/debian-archive-bullseye-security-automatic.gpg ```
Owner

Then you just messed up your debian-archive-keyring package:

$ dpkg -L debian-archive-keyring | grep trusted.gpg.d/
/etc/apt/trusted.gpg.d/debian-archive-bullseye-automatic.gpg
/etc/apt/trusted.gpg.d/debian-archive-bullseye-security-automatic.gpg
/etc/apt/trusted.gpg.d/debian-archive-bullseye-stable.gpg
/etc/apt/trusted.gpg.d/debian-archive-buster-automatic.gpg
/etc/apt/trusted.gpg.d/debian-archive-buster-security-automatic.gpg
/etc/apt/trusted.gpg.d/debian-archive-buster-stable.gpg
/etc/apt/trusted.gpg.d/debian-archive-stretch-automatic.gpg
/etc/apt/trusted.gpg.d/debian-archive-stretch-security-automatic.gpg
/etc/apt/trusted.gpg.d/debian-archive-stretch-stable.gpg

You deleted files that were owned by a package. This is bad practice and you should not do that. On the next update of your debian-archive-keyring package, these files will be back so your deletion doesn't even have a lasting effect. Why would you want the directory deleted?

Then you just messed up your `debian-archive-keyring` package: ``` $ dpkg -L debian-archive-keyring | grep trusted.gpg.d/ /etc/apt/trusted.gpg.d/debian-archive-bullseye-automatic.gpg /etc/apt/trusted.gpg.d/debian-archive-bullseye-security-automatic.gpg /etc/apt/trusted.gpg.d/debian-archive-bullseye-stable.gpg /etc/apt/trusted.gpg.d/debian-archive-buster-automatic.gpg /etc/apt/trusted.gpg.d/debian-archive-buster-security-automatic.gpg /etc/apt/trusted.gpg.d/debian-archive-buster-stable.gpg /etc/apt/trusted.gpg.d/debian-archive-stretch-automatic.gpg /etc/apt/trusted.gpg.d/debian-archive-stretch-security-automatic.gpg /etc/apt/trusted.gpg.d/debian-archive-stretch-stable.gpg ``` You deleted files that were owned by a package. This is bad practice and you should not do that. On the next update of your `debian-archive-keyring` package, these files will be back so your deletion doesn't even have a lasting effect. Why would you want the directory deleted?
Author

Note that debian is on track for making these changes:

  1. Moving away from using /etc/apt/sources.list and instead using deb822-style debian.sources

  2. Moving away from using /etc/apt/trusted.gpg file (already done in bookworm) and /etc/apt/trusted.gpg.d/ directory, in preference to specifying the keys directly in the sources file.

  3. Using a new directory for user-supplied 3rd party keyrings, /etc/apt/keyrings/ instead of asking users to put them in /etc/apt/trusted.gpg.d/ (where they could sign any packages) or /usr/share/keyrings/ (which interferes with package management). This is already done in ubuntu.

All of this was discussed at debconf 2022, and there probably is a writeup of this somewhere on the debian wiki, but I can't find it right now. I also remember the speaker having a blogpost about it.

Note that debian is on track for making these changes: 1) Moving away from using `/etc/apt/sources.list` and instead using deb822-style debian.sources 2) Moving away from using `/etc/apt/trusted.gpg` file (already done in bookworm) and `/etc/apt/trusted.gpg.d/` directory, in preference to specifying the keys directly in the sources file. 3) Using a new directory for user-supplied 3rd party keyrings, `/etc/apt/keyrings/` instead of asking users to put them in `/etc/apt/trusted.gpg.d/` (where they could sign any packages) or `/usr/share/keyrings/` (which interferes with package management). This is already done in ubuntu. All of this was discussed at debconf 2022, and there probably is a writeup of this somewhere on the debian wiki, but I can't find it right now. I also remember the speaker having a blogpost about it.
Owner

You are right. I'm not arguing that mmdebstrap shouldn't make this change.

But the reasons you gave initially are the wrong ones. The ones you gave now are the ones you should've listed in your initial report.

You are right. I'm not arguing that mmdebstrap shouldn't make this change. But the reasons you gave initially are the wrong ones. The ones you gave now are the ones you should've listed in your initial report.
Author

On the next update of your debian-archive-keyring package, these files will be back so your deletion doesn't even have a lasting effect.

dpkg-statoverride is used to prevent writing to that directory so that no package will accidentally drop a keyring that will be trusted to sign all packages.

> On the next update of your `debian-archive-keyring` package, these files will be back so your deletion doesn't even have a lasting effect. `dpkg-statoverride` is used to prevent writing to that directory so that no package will accidentally drop a keyring that will be trusted to sign all packages.
Author

Additionally, package updates do not replace config files in /etc/ if it detects that they have been deleted by the user.

dpkg --force-confmiss <package> would be needed to reinstall these config files

(I'm not 100% sure about this though)

Additionally, package updates do not replace config files in `/etc/` if it detects that they have been deleted by the user. `dpkg --force-confmiss <package>` would be needed to reinstall these config files (I'm not 100% sure about this though)
Owner

But why do you need the directory deleted?

But why do you need the directory deleted?
Author

I don't need it deleted, I simply noted surprising behavior that mmdebstrap gives a hard error if it can't find that directory, but it doesn't even need any contents of that directory.

My workaround of creating that directory and keeping it empty allowed mmdebstrap to proceed.

I don't need it deleted, I simply noted surprising behavior that `mmdebstrap` gives a hard error if it can't find that directory, but it doesn't even need any contents of that directory. My workaround of creating that directory and keeping it empty allowed mmdebstrap to proceed.
Owner

Fixed in 2f27eccad4

Fixed in 2f27eccad4edc76bac04da3e4fdbdbf5ed3d0c9b
josch closed this issue 2022-09-11 19:12:42 +00:00
Author

I've done some testing with mmdebstrap from git, on debian bookworm.

/etc/apt/sources.list file doesn't exist
/etc/apt/trusted.gpg.d/ directory doesn't exist
/etc/apt/sources.list.d/bookworm.sources exists with the following content:

Types: deb
URIs: https://deb.debian.org/debian
Suites: bookworm
Components: main
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Running this command (mmdebstrap in current directory):
./mmdebstrap --dry-run bookworm /bookworm-chroot https://deb.debian.org/debian

Produces this output:

I: automatically chosen mode: root
W: cannot mount because CAP_SYS_ADMIN is not in the effective set
W: cannot mount because CAP_SYS_ADMIN is not in the bounding set
unshare: unshare failed: Operation not permitted
W: cannot mount because unshare --mount failed
I: chroot architecture amd64 is equal to the host's architecture
W: /etc/apt/trusted.gpg.d/ doesn't exist
I: automatically chosen format: directory
I: running apt-get update...
done
Get:1 https://deb.debian.org/debian bookworm InRelease [157 kB]
Err:1 https://deb.debian.org/debian bookworm InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 648ACFD622F3D138 NO_PUBKEY 0E98404D386FA1D9
Reading package lists...
W: GPG error: https://deb.debian.org/debian bookworm InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 648ACFD622F3D138 NO_PUBKEY 0E98404D386FA1D9
E: The repository 'https://deb.debian.org/debian bookworm InRelease' is not signed.
E: apt-get update --error-on=any -oAPT::Status-Fd=<$fd> -oDpkg::Use-Pty=false failed
W: listening on child socket failed:
E: mmdebstrap failed to run

Now if I do:
mkdir /etc/apt/trusted.gpg.d/ && rm -r /bookworm-chroot

And run the same command as before:
./mmdebstrap --dry-run bookworm /bookworm-chroot https://deb.debian.org/debian

I get this output:

I: automatically chosen mode: root
W: cannot mount because CAP_SYS_ADMIN is not in the effective set
W: cannot mount because CAP_SYS_ADMIN is not in the bounding set
unshare: unshare failed: Operation not permitted
W: cannot mount because unshare --mount failed
I: chroot architecture amd64 is equal to the host's architecture
I: automatically chosen format: directory
I: running apt-get update...
done
I: simulate downloading packages with apt...
done
I: skip extracting packages because of --dry-run
I: no essential packages -- skipping...
I: simulate installing remaining packages inside the chroot...
done
I: cleaning package lists and apt cache...
done
done
I: simulate creating tarball...
I: success in 7.2435 seconds

So something somewhere in the code still relies on existence of /etc/apt/trusted.gpg.d/ despite it having no contents.

I've done some testing with mmdebstrap from git, on debian bookworm. `/etc/apt/sources.list` file doesn't exist `/etc/apt/trusted.gpg.d/` directory doesn't exist `/etc/apt/sources.list.d/bookworm.sources` exists with the following content: ``` Types: deb URIs: https://deb.debian.org/debian Suites: bookworm Components: main Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg ``` Running this command (mmdebstrap in current directory): `./mmdebstrap --dry-run bookworm /bookworm-chroot https://deb.debian.org/debian` Produces this output: ``` I: automatically chosen mode: root W: cannot mount because CAP_SYS_ADMIN is not in the effective set W: cannot mount because CAP_SYS_ADMIN is not in the bounding set unshare: unshare failed: Operation not permitted W: cannot mount because unshare --mount failed I: chroot architecture amd64 is equal to the host's architecture W: /etc/apt/trusted.gpg.d/ doesn't exist I: automatically chosen format: directory I: running apt-get update... done Get:1 https://deb.debian.org/debian bookworm InRelease [157 kB] Err:1 https://deb.debian.org/debian bookworm InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 648ACFD622F3D138 NO_PUBKEY 0E98404D386FA1D9 Reading package lists... W: GPG error: https://deb.debian.org/debian bookworm InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 648ACFD622F3D138 NO_PUBKEY 0E98404D386FA1D9 E: The repository 'https://deb.debian.org/debian bookworm InRelease' is not signed. E: apt-get update --error-on=any -oAPT::Status-Fd=<$fd> -oDpkg::Use-Pty=false failed W: listening on child socket failed: E: mmdebstrap failed to run ``` Now if I do: `mkdir /etc/apt/trusted.gpg.d/ && rm -r /bookworm-chroot` And run the same command as before: `./mmdebstrap --dry-run bookworm /bookworm-chroot https://deb.debian.org/debian` I get this output: ``` I: automatically chosen mode: root W: cannot mount because CAP_SYS_ADMIN is not in the effective set W: cannot mount because CAP_SYS_ADMIN is not in the bounding set unshare: unshare failed: Operation not permitted W: cannot mount because unshare --mount failed I: chroot architecture amd64 is equal to the host's architecture I: automatically chosen format: directory I: running apt-get update... done I: simulate downloading packages with apt... done I: skip extracting packages because of --dry-run I: no essential packages -- skipping... I: simulate installing remaining packages inside the chroot... done I: cleaning package lists and apt cache... done done I: simulate creating tarball... I: success in 7.2435 seconds ``` So something somewhere in the code still relies on existence of `/etc/apt/trusted.gpg.d/` despite it having no contents.
Author

Perhaps my bad, this invocation indeed works perfectly:
./mmdebstrap --dry-run bookworm /bookworm-chroot /etc/apt/sources.list.d/bookworm.sources

Thank you for the quick fix, everything works now.

Perhaps my bad, this invocation indeed works perfectly: `./mmdebstrap --dry-run bookworm /bookworm-chroot /etc/apt/sources.list.d/bookworm.sources` Thank you for the quick fix, everything works now.
Owner

Running this command (mmdebstrap in current directory):
./mmdebstrap --dry-run bookworm /bookworm-chroot https://deb.debian.org/debian

If you just want to verify whether it succeeds or not, you can pass /dev/null instead of a directory.

I: automatically chosen mode: root
W: cannot mount because CAP_SYS_ADMIN is not in the effective set
W: cannot mount because CAP_SYS_ADMIN is not in the bounding set
unshare: unshare failed: Operation not permitted
W: cannot mount because unshare --mount failed

What platform are you running this in??

I: chroot architecture amd64 is equal to the host's architecture
W: /etc/apt/trusted.gpg.d/ doesn't exist
I: automatically chosen format: directory
I: running apt-get update...
done
Get:1 https://deb.debian.org/debian bookworm InRelease [157 kB]
Err:1 https://deb.debian.org/debian bookworm InRelease
The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 648ACFD622F3D138 NO_PUBKEY 0E98404D386FA1D9
Reading package lists...
W: GPG error: https://deb.debian.org/debian bookworm InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 648ACFD622F3D138 NO_PUBKEY 0E98404D386FA1D9
E: The repository 'https://deb.debian.org/debian bookworm InRelease' is not signed.
E: apt-get update --error-on=any -oAPT::Status-Fd=<$fd> -oDpkg::Use-Pty=false failed
W: listening on child socket failed:
E: mmdebstrap failed to run

Yes, because you didn't tell mmdebstrap which keys to use. By default it searches for keys in the location that your local apt knows as Dir::Etc::trustedparts which is /etc/apt/trusted.gpg.d/ if you didn't set it to a different directory.

Now if I do:
mkdir /etc/apt/trusted.gpg.d/ && rm -r /bookworm-chroot

And run the same command as before:
./mmdebstrap --dry-run bookworm /bookworm-chroot https://deb.debian.org/debian

I get this output:

I: automatically chosen mode: root
W: cannot mount because CAP_SYS_ADMIN is not in the effective set
W: cannot mount because CAP_SYS_ADMIN is not in the bounding set
unshare: unshare failed: Operation not permitted
W: cannot mount because unshare --mount failed
I: chroot architecture amd64 is equal to the host's architecture
I: automatically chosen format: directory
I: running apt-get update...
done
I: simulate downloading packages with apt...
done
I: skip extracting packages because of --dry-run
I: no essential packages -- skipping...
I: simulate installing remaining packages inside the chroot...
done
I: cleaning package lists and apt cache...
done
done
I: simulate creating tarball...
I: success in 7.2435 seconds

So something somewhere in the code still relies on existence of /etc/apt/trusted.gpg.d/ despite it having no contents.

It relies on whatever Dir::Etc::trustedparts points to in case you did not pass an alternative keyring via Signed-By. If you don't want that, then tell your local apt to look into a different directory but this is not up to mmdebstrap.

> Running this command (mmdebstrap in current directory): > `./mmdebstrap --dry-run bookworm /bookworm-chroot https://deb.debian.org/debian` If you just want to verify whether it succeeds or not, you can pass `/dev/null` instead of a directory. > I: automatically chosen mode: root > W: cannot mount because CAP_SYS_ADMIN is not in the effective set > W: cannot mount because CAP_SYS_ADMIN is not in the bounding set > unshare: unshare failed: Operation not permitted > W: cannot mount because unshare --mount failed What platform are you running this in?? > I: chroot architecture amd64 is equal to the host's architecture > W: /etc/apt/trusted.gpg.d/ doesn't exist > I: automatically chosen format: directory > I: running apt-get update... > done > Get:1 https://deb.debian.org/debian bookworm InRelease [157 kB] > Err:1 https://deb.debian.org/debian bookworm InRelease > The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 648ACFD622F3D138 NO_PUBKEY 0E98404D386FA1D9 > Reading package lists... > W: GPG error: https://deb.debian.org/debian bookworm InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 648ACFD622F3D138 NO_PUBKEY 0E98404D386FA1D9 > E: The repository 'https://deb.debian.org/debian bookworm InRelease' is not signed. > E: apt-get update --error-on=any -oAPT::Status-Fd=<$fd> -oDpkg::Use-Pty=false failed > W: listening on child socket failed: > E: mmdebstrap failed to run Yes, because you didn't tell mmdebstrap which keys to use. By default it searches for keys in the location that your local apt knows as `Dir::Etc::trustedparts` which is `/etc/apt/trusted.gpg.d/` if you didn't set it to a different directory. > Now if I do: > `mkdir /etc/apt/trusted.gpg.d/ && rm -r /bookworm-chroot` > > And run the same command as before: > `./mmdebstrap --dry-run bookworm /bookworm-chroot https://deb.debian.org/debian` > > I get this output: > ``` > I: automatically chosen mode: root > W: cannot mount because CAP_SYS_ADMIN is not in the effective set > W: cannot mount because CAP_SYS_ADMIN is not in the bounding set > unshare: unshare failed: Operation not permitted > W: cannot mount because unshare --mount failed > I: chroot architecture amd64 is equal to the host's architecture > I: automatically chosen format: directory > I: running apt-get update... > done > I: simulate downloading packages with apt... > done > I: skip extracting packages because of --dry-run > I: no essential packages -- skipping... > I: simulate installing remaining packages inside the chroot... > done > I: cleaning package lists and apt cache... > done > done > I: simulate creating tarball... > I: success in 7.2435 seconds > ``` > > So something somewhere in the code still relies on existence of `/etc/apt/trusted.gpg.d/` despite it having no contents. It relies on whatever `Dir::Etc::trustedparts` points to in case you did not pass an alternative keyring via `Signed-By`. If you don't want that, then tell your local apt to look into a different directory but this is not up to mmdebstrap.
Author

What platform are you running this in??

podman

It relies on whatever Dir::Etc::trustedparts points to in case you did not pass an alternative keyring via Signed-By. If you don't want that, then tell your local apt to look into a different directory but this is not up to mmdebstrap.

Indeed using:

Dir::Etc::trusted "";
Dir::Etc::trustedparts "";

fixes everything. Thank you once again.

> What platform are you running this in?? podman > It relies on whatever Dir::Etc::trustedparts points to in case you did not pass an alternative keyring via Signed-By. If you don't want that, then tell your local apt to look into a different directory but this is not up to mmdebstrap. Indeed using: ``` Dir::Etc::trusted ""; Dir::Etc::trustedparts ""; ``` fixes everything. Thank you once again.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: josch/mmdebstrap#27
No description provided.