Hi,

Debian CI is switching away from lxc containers in favor of incus Containers.
This is motivated by security concerns from us; incus is based on lxc, but
orchestrates containers substantially different: containers are not privileged
(so root in the container is not uid 0 outside of it, and incus imposes a
stricter isolation from the host system.

gnupg2 passes its tests under lxc, but fails under incus.
The relevant part of the failure is (hopefully):
The full autokpgtest logs are available at:
https://ci.debian.net/experiments/8/regressions/
(please beware of pagination)

Common types of failure and suggested fixes are being documented at:
https://wiki.debian.org/ContinuousIntegration/LxcToIncus

Note that for the time being, gnupg2 is still being tested under lxc to
avoid disturbing its testing migration test results.

If you decide to add the `isolation-machine` restriction to get this package
tested under qemu, please mention that explicitly when closing this bug (it's
fine to do that only in the package changelog entry that closes the bug) so
that we can configure your package for qemu on ci.debian.net.

[...]
[...]

Hello Antonio,

does the incus virtualisation provide /run/user/nnn? gpg-agent requires
it.

(I tried the QnD reproduction steps on the linked wiki page, but DNF
since debci setup failed at the sudo step with "ametzler is not in the
sudoers file.")

cu Andreas

Andreas Metzler wrote:

I want to assert that, if this were the culprit, it's still wrong for our autopkgtest to fail, and this failure may be pointing out a genuine issue to us.

If Incus—or any container/virtual environment, for that matter—didn't provide /run/user/$UID, I don't see how that would be the caller's error. At the very least, GnuPG needs to provide a better error message in this case. It is a legitimate problem for our users if they're stuck with "General error" when GnuPG doesn't work in their legitimate environment.

Second, a web search tells me that /run/user/$UID is an invention of pam_systemd. This is intended to be used as $XDG_RUNTIME_DIR (an environment variable that GnuPG intentionally does not use; see the comments in the source code). If that isn't set and /run/user/$UID doesn't exist, the standard advice at https://specifications.freedesktop.org/basedir/latest/#variables ought to apply. In particular, we should arrange for gpg-agent to put its stuff into $AUTOPKGTEST_TMP, try to make /run/user/$UID ourselves with the right permissions, or else—if using gpg-agent outside of a PAM+systemd session is not supported—make libpam-systemd a hard dependency of gpg-agent, make the test run "skippable", and skip it when we're not in such a session and unable to make one.

Neither the Filesystem Hierarchy Standard nor Debian Policy require /run/user/$UID, so the test shouldn't fail in such a legitimate configuration.

It seems likely to me that /run/user/nnn is provided if only because the
debian/tests/simple-tests seems to succeed, and that test requires key
generation and signing, both of which should use gpg-agent at least.

Indeed, gpg is brittle, and we might be able to identify some additional
brittleness, regardless of whoever's (good!) idea produced /run/user/nnn
If we can diagnose it, we should report back to upstream.  If
https://dev.gnupg.org/ is back up by then, opening an issue in the issue
tracker would be good.  otherwise, it's probably worth mailing
gnupg-devel@gnupg.org

I haven't been able to replicate the failure myself, but maybe someone
who can replicate it with incus could try it by increasing the logging
of the agent in that script and then looking at the artifact directory
produced by the failing test.

With the following patch to the gnupg2 package:

--- a/debian/tests/verify-openpgp
+++ b/debian/tests/verify-openpgp
@@ -126,6 +126,11 @@ librepgp() {
     local GNUPGHOME="$WORKDIR/librepgp-$profile"
     export GNUPGHOME
     mkdir -p -m 0700 "$GNUPGHOME"
+    cat > "$GNUPGHOME/gpg-agent.conf" <<EOF
+debug-level guru
+debug-all
+log-file $GNUPGHOME/gpg-agent.log
+EOF
     if [[ "$profile" =~ default ]]; then
         algo="$profile"
         # this is a dummy placeholder:


Then the debug logs should be visible in the CI artifact directory as:

   workdir/librepgp-*/gpg-agent.log

If anyone manages to get any results (even if you don't know how to
interpret the gpg-agent logs), please follow up on this debian issue.

Thanks!