From jw at raven.inka.de Sun Feb 2 09:22:37 2025 From: jw at raven.inka.de (Josef Wolf) Date: Sun, 2 Feb 2025 09:22:37 +0100 Subject: Please help verify signature within Dockerfile In-Reply-To: <20250130231518.GX30202@raven.inka.de> References: <20250130231518.GX30202@raven.inka.de> Message-ID: <20250202082237.GZ30202@raven.inka.de> Although I got a solution for the initial problem to use gpgv, I am still curious why all the other methods fail. Any ideas? On Fri, Jan 31, 2025 at 12:15:18AM +0100, Josef Wolf wrote: > Hello all, > > I am trying to verify signature of downloaded files when creating a docker > container. This is what I am trying to do within the Dockerfile: > > RUN gpg -v --status-fd 1 --no-keyring \ > --trust-model always \ > --recipient-file /pubkes/release-key.txt \ > --verify sigfile.asc foo.tar.gz > > This errors with "gpg: Can't check signature: No public key". Using strace, I > can see that gpg won't even try to open /pubkeys/release-key.txt > > I also tried to de-armor the pubkey file and pass it as > > RUN gpg --yes -o release-key.gpg --dearmor release-key.txt > RUN gpg -v --status-fd 1 --no-keyring \ > --trust-model always \ > --no-keyring --keyring /pubkes/release-key.gpg \ > --verify sigfile.asc foo.tar.gz > > with exactly the same result: gpg won't even try to open the keyfile. > > I also tried to import the pubkey and verify using the default keyring: > > RUN gpg --import ql/release-key.txt > RUN gpg --verify --trust-model always ql/quicklisp.lisp.asc ql/quicklisp.lisp > > but this one tries to start and connect to gpg-agent, which fails: > > [1/2] STEP 17/21: RUN gpg --verify --trust-model always ql/quicklisp.lisp.asc ql/quicklisp.lisp > gpg: Signature made Wed Jan 28 21:13:26 2015 UTC > gpg: using RSA key 307965AB028B5FF7 > gpg: Note: database_open 134217901 waiting for lock (held by 3) ... > gpg: Note: database_open 134217901 waiting for lock (held by 3) ... > gpg: Note: database_open 134217901 waiting for lock (held by 3) ... > gpg: Note: database_open 134217901 waiting for lock (held by 3) ... > gpg: Note: database_open 134217901 waiting for lock (held by 3) ... > gpg: keydb_search failed: Operation timed out > gpg: Can't check signature: No public key > Error: building at STEP "RUN gpg --verify --trust-model always ql/quicklisp.lisp.asc ql/quicklisp.lisp": while running runtime: exit status 2 > > BTW: I create an empty ~/.gnupg directory before the very first gpg invocation > to prevent use-keyboxd option to be set. > > Does it really need to be that hard to verify signature with a given pubkey? > > Any help? > > -- > Josef Wolf > jw at raven.inka.de > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-users -- Josef Wolf jw at raven.inka.de From ametzler at bebt.de Sun Feb 2 12:02:19 2025 From: ametzler at bebt.de (Andreas Metzler) Date: Sun, 2 Feb 2025 12:02:19 +0100 Subject: Please help verify signature within Dockerfile In-Reply-To: <20250202082237.GZ30202@raven.inka.de> References: <20250130231518.GX30202@raven.inka.de> <20250202082237.GZ30202@raven.inka.de> Message-ID: On 2025-02-02 Josef Wolf wrote: > Although I got a solution for the initial problem to use gpgv, I am still > curious why all the other methods fail. > Any ideas? See below: > On Fri, Jan 31, 2025 at 12:15:18AM +0100, Josef Wolf wrote: > > Hello all, > > > > I am trying to verify signature of downloaded files when creating a docker > > container. This is what I am trying to do within the Dockerfile: > > > > RUN gpg -v --status-fd 1 --no-keyring \ > > --trust-model always \ > > --recipient-file /pubkes/release-key.txt \ > > --verify sigfile.asc foo.tar.gz > > > > This errors with "gpg: Can't check signature: No public key". Using strace, I > > can see that gpg won't even try to open /pubkeys/release-key.txt Looking at te manpage we find: --recipient-file file -f This option is similar to --recipient except that it encrypts to a key stored in the given file. file must be the name of a file containing exactly one key. gpg assumes that the key in this file is fully valid. So this has clearly nothing to do with specifying a keyring to check against. > > I also tried to de-armor the pubkey file and pass it as > > > > RUN gpg --yes -o release-key.gpg --dearmor release-key.txt > > RUN gpg -v --status-fd 1 --no-keyring \ > > --trust-model always \ > > --no-keyring --keyring /pubkes/release-key.gpg \ > > --verify sigfile.asc foo.tar.gz > > > > with exactly the same result: gpg won't even try to open the keyfile. --no-keyring Do not use any keyring at all. This overrides the default and all options which specify keyrings. So --no-keyring should take care of ignoring --keyring /pubkes/release-key.gpg. :-( > > I also tried to import the pubkey and verify using the default keyring: > > > > RUN gpg --import ql/release-key.txt > > RUN gpg --verify --trust-model always ql/quicklisp.lisp.asc ql/quicklisp.lisp This should work. [...] > > BTW: I create an empty ~/.gnupg directory before the very first gpg > > invocation to prevent use-keyboxd option to be set. > > Does it really need to be that hard to verify signature with a given > > pubkey? (I would use a temporary directory with --homedir). cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From wk at gnupg.org Mon Feb 3 09:05:18 2025 From: wk at gnupg.org (Werner Koch) Date: Mon, 03 Feb 2025 09:05:18 +0100 Subject: Please help verify signature within Dockerfile In-Reply-To: <20250202082237.GZ30202@raven.inka.de> (Josef Wolf's message of "Sun, 2 Feb 2025 09:22:37 +0100") References: <20250130231518.GX30202@raven.inka.de> <20250202082237.GZ30202@raven.inka.de> Message-ID: <874j1bmp1d.fsf@jacob.g10code.de> On Sun, 2 Feb 2025 09:22, Josef Wolf said: >> Does it really need to be that hard to verify signature with a given pubkey? That is for what gpgv was created for. Use it. Or use the newer gpg option --assert-signer fpr_or_file This option checks whether at least one valid signature on a file has been made with the specified key. The key is either specified as a fingerprint or a file listing fingerprints. The fingerprint must be given or listed in compact format (no colons or spaces in between). This option can be given multiple times and each fingerprint is checked against the signing key as well as the corresponding primary key. If fpr_or_file specifies a file, empty lines are ignored as well as all lines starting with a hash sign. With this option gpg is guaranteed to return with an exit code of 0 if and only if a signature has been encountered, is valid, and the key matches one of the fingerprints given by this option. But here you need to import the keys first. But you need to store them anyway and have a way to update them. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From wk at gnupg.org Mon Feb 3 09:08:17 2025 From: wk at gnupg.org (Werner Koch) Date: Mon, 03 Feb 2025 09:08:17 +0100 Subject: Error generating subkey in gpg's batch mode using curve brainpoolP512r1 In-Reply-To: (sgh@erghfe.com's message of "Sat, 1 Feb 2025 01:01:54 +0800") References: Message-ID: <87zfj3laby.fsf@jacob.g10code.de> Hi! Thanks for the report. Andre meanwhile looked in more detail at the bug; see https://dev.gnupg.org/T7506 Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From gpg at samoverton.dev Sat Feb 8 03:45:17 2025 From: gpg at samoverton.dev (Sam Overton) Date: Sat, 8 Feb 2025 03:45:17 +0100 Subject: Maniphest account request Message-ID: <700debd9-64d9-4dea-b9a2-9d0bfe0169c4@samoverton.dev> Hello, I would like to file an issue in Maniphest prior to proposing a patch to the gnupg-devel list. Could I please get an account on https://dev.gnupg.org ? Preferred username: samoverton email: gpg (at) samoverton (dot) dev If you would prefer me to detail the report in a mail directly to gnupg-devel, I'm happy to do that instead. Thanks, Sam Overton From wk at gnupg.org Sat Feb 8 13:04:38 2025 From: wk at gnupg.org (Werner Koch) Date: Sat, 08 Feb 2025 13:04:38 +0100 Subject: Maniphest account request In-Reply-To: <700debd9-64d9-4dea-b9a2-9d0bfe0169c4@samoverton.dev> (Sam Overton via Gnupg-users's message of "Sat, 8 Feb 2025 03:45:17 +0100") References: <700debd9-64d9-4dea-b9a2-9d0bfe0169c4@samoverton.dev> Message-ID: <87v7tkfxrd.fsf@jacob.g10code.de> Hi! > to the gnupg-devel list. Could I please get an account on > https://dev.gnupg.org ? Sure. Confirmation mail is on the way. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From jay.kayes at posteo.com Sat Feb 8 17:51:29 2025 From: jay.kayes at posteo.com (jay.kayes at posteo.com) Date: Sat, 08 Feb 2025 16:51:29 +0000 Subject: Pinentry with flatpak applications Message-ID: Hi all, I've been debugging using gpg in flatpak apps. Particularly, I use Evolution as a flatpak for email. The issue I am having is that gpg private key operations only work if the card pin or key passphrase is already in the agent cache. Pinentry does not work when triggered by a gpg operation from a flatpak sandboxed app. I can only decrypt email when I've done a gpg operation outside the sandbox to get the pin entered. The following debugging/demonstration notes are with Kleopatra for ease of testing gpg operations, but I observe the same behavior and results with Evolution. The following are notes as I verified the behavior in a fresh VM (Fedora 41 Workstation) environment. System GPG version: gpg (GnuPG) 2.4.5 libgcrypt 1.11.0-unknown Flatpak sandbox GPG version: gpg (GnuPG) 2.5.1 libgcrypt 1.11.0 Agent configuration: $ cat ~/.gnupg/gpg-agent.conf pinentry-program /usr/bin/pinentry-gnome3 debug-level basic With a freshly started agent process, I open Kleopatra and attempt to sign some text in the Notepad view. This fails. The error message in Kleopatra's diagnostics: gpg: WARNING: server 'gpg-agent' is older than us (2.4.5 < 2.5.1) gpg: Note: Outdated servers may lack important security fixes. gpg: Note: Use the command "gpgconf --kill all" to restart them. gpg: signing failed: pinentry error gpg: -&48: sign+encrypt failed: pinentry error Looking at the output of gpg-agent, I see this line: DBG: chan_6 <- OPTION putenv=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/flatpak/bus I think this is the smoking gun. If I understand correctly, Kleopatra is telling the agent where it thinks the DBUS socket is and the agent attempts to use this value when launching pinentry. This of course fails, as there is no dbus socket at that location from gpg-agent's perspective. This value is what Flatpak sets up when it starts the sandbox, from Kleopatra's perspective this the correct value. For gpg-agent, the correct value is of course `DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus`. I now do a GPG operation outside the sandbox so that the passphrase gets prompted and cached. Once the passphrase is cached, I can switch back to Kleopatra, and the signing operation (or any other using the private key) succeeds. If I restart the agent, Kleopatra will fail to sign/decrypt again until I get the passphrase cached. Another interesting demonstration is to modify DBUS_SESSION_BUS_ADDRESS before starting Kleopatra from a shell inside the sandbox. If I first open a shell in the sandbox and launch Kleopatra, I do not get a pinentry prompt and operation fails. Same as above. $ flatpak run --command=bash org.kde.kleopatra [? org.kde.kleopatra ~]$ echo $DBUS_SESSION_BUS_ADDRESS unix:path=/run/flatpak/bus [? org.kde.kleopatra ~]$ kleopatra If I modify DBUS_SESSION_BUS_ADDRESS in the sandbox shell before launching Kleopatra as per below, everything works as expected. I get a pinentry prompt and private key operations are successful. Interestingly `$XDG_RUNTIME_DIR/bus` is symlinked to `/run/flatpak/bus`, but flatpak must have it's reasons for using `DBUS_SESSION_BUS_ADDRESS=/run/flatpak/bus`. [? org.kde.kleopatra ~]$ export DBUS_SESSION_BUS_ADDRESS=unix:path=$XDG_RUNTIME_DIR/bus [? org.kde.kleopatra ~]$ ls -l $XDG_RUNTIME_DIR/bus lrwxrwxrwx. 1 jay jay 17 Feb 8 15:14 /run/user/1000/bus -> ../../flatpak/bus [? org.kde.kleopatra ~]$ kleopatra In summary, steps to reproduce: 1. Restart agent or otherwise clear cache 2. Attempt to use private key in Flatpak app, pinentry fails 3. Use gnupg outside sandbox so that the pin gets entered and cached 3. Repeat in Flatpak app, using the private key now works In the notes above with a clean environment, I only tested with Kleopatra. Kleopatra gets access to the gpg socket by a filesystem permission - `$XDG_RUNTIME_DIR/gnupg` is mapped into the sandbox. On my production environment, Evolution gets access using Flatpak's socket portal mechanism (`--socket=gpg-agent` permission). This does not seem to be significant, the same behavior happens in both cases. Both options are just making the socket available inside the sandbox. I imagine there are relevant uses for the calling gpg process to communicate variables from it's environment to the agent process (e.g. PINENTRY_GEOM_HINT?). But this also means that the calling gpg process can unintentionally cause the pinentry process to fail. I haven't thought about this further, but could a malicious program compromise the agent somehow by setting some unexpected values? I wonder if it would be useful to either blocklist some specific variables (e.g. DBUS_SESSION_BUS_ADDRESS) from being set through the socket. Or better yet, perhaps the agent should only accept values for allowlisted variables? BR Jay From gpg at samoverton.dev Sat Feb 8 20:50:50 2025 From: gpg at samoverton.dev (Sam Overton) Date: Sat, 8 Feb 2025 20:50:50 +0100 Subject: Pinentry with flatpak applications In-Reply-To: References: Message-ID: On 08/02/2025 17:51, jay.kayes--- via Gnupg-users wrote: > Hi all, > > I've been debugging using gpg in flatpak apps.? Particularly, I use > Evolution as a flatpak for email.? The issue I am having is that gpg > private key operations only work if the card pin or key passphrase is > already in the agent cache.? Pinentry does not work when triggered by a > gpg operation from a flatpak sandboxed app.? I can only decrypt email > when I've done a gpg operation outside the sandbox to get the pin entered. Hi Jay, I was about to file the same issue in the bug tracker, except in my case the flatpak in question is Thunderbird, which exhibits the same behavior that you detailed. I also traced the issue to the same cause - that gpg running in the flatpak is sending its DBUS_SESSION_BUS_ADDRESS to the agent which then passes it to pinentry. I have a proposed patch which I am preparing to send which adds a gpg-agent configuration parameter to specify which environment variables sent by the client should be *ignored* by the agent. This solves the problem in my case, by filtering out DBUS_SESSION_BUS_ADDRESS ensuring that the agent's environment is used by pinentry (for that specific env-var). In the meantime, the workaround I have been using is to configure gpg-agent to use a custom pinentry command (~/.gnupg/gpg-agent.conf): pinentry-program /home/sam/bin/pinentry-wrap which then sets the correct environment for pinentry (pinentry-wrap): #!/bin/bash PINENTRY="/usr/bin/pinentry-gnome3" export DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1001/bus" ${PINENTRY} "$@" > I haven't thought about this further, but could a malicious program > compromise the agent somehow by setting some unexpected values? AFAIK the agent only accepts a specific list of environment variables from the client which can be listed using: $ gpg-connect-agent 'getinfo std_env_names' /bye Best Regards, Sam From jay.kayes at posteo.com Sat Feb 8 22:29:21 2025 From: jay.kayes at posteo.com (jay.kayes at posteo.com) Date: Sat, 08 Feb 2025 21:29:21 +0000 Subject: Pinentry with flatpak applications In-Reply-To: References:

Message-ID: <6fd64186b9a36e7a77ddd17ae9d16188@posteo.com> On 2025-02-08 20:50, Sam Overton via Gnupg-users wrote: > I have a proposed patch which I am preparing to send which adds a > gpg-agent configuration parameter to specify which environment > variables sent by the client should be *ignored* by the agent. This > solves the problem in my case, by filtering out > DBUS_SESSION_BUS_ADDRESS ensuring that the agent's environment is used > by pinentry (for that specific env-var). Looking forward to it. Are you proposing to ignore by default, or give the possibility to ignore DBUS_SESSION_BUS_ADDRESS? With the popularity of Flatpak apps, ignoring DBUS_SESSION_BUS_ADDRESS by default feels like it would be better UX overall. On the other hand, there must be a usecase for passing through the dbus address to pinentry which I'm not seeing. > In the meantime, the workaround I have been using is to configure > gpg-agent to use a custom pinentry command (~/.gnupg/gpg-agent.conf): > > pinentry-program /home/sam/bin/pinentry-wrap > > which then sets the correct environment for pinentry (pinentry-wrap): Ingenious hack, obvious in hindsight! Cheers for the idea, I'll implement this while waiting for your patch to trickle through the supply chain ;) > AFAIK the agent only accepts a specific list of environment variables > from the client which can be listed using: > > $ gpg-connect-agent 'getinfo std_env_names' /bye Ah the wonderful niche commands that are available... if one only knew. BR Jay From mcepl at cepl.eu Sat Feb 8 21:45:52 2025 From: mcepl at cepl.eu (=?utf-8?q?Mat=C4=9Bj_Cepl?=) Date: Sat, 08 Feb 2025 21:45:52 +0100 Subject: Pinentry with flatpak applications In-Reply-To: References: Message-ID: On Sat Feb 8, 2025 at 7:10 PM CET, jay.kayes--- via Gnupg-users wrote: > Pinentry does not work when triggered by a gpg operation from a > flatpak sandboxed app. Wait? Why do you need to run pinentry from flatpak app? Isn?t it run on the host system? Mat?j -- http://matej.ceplovi.cz/blog/, @mcepl at en.osm.town GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Think of how stupid the average person is, and realize half of them are stupider than that. -- George Carlin -------------- next part -------------- A non-text attachment was scrubbed... Name: E09FEF25D96484AC.asc Type: application/pgp-keys Size: 3102 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 216 bytes Desc: not available URL: From gpg at samoverton.dev Sun Feb 9 05:13:51 2025 From: gpg at samoverton.dev (Sam Overton) Date: Sun, 9 Feb 2025 05:13:51 +0100 Subject: Pinentry with flatpak applications In-Reply-To: <6fd64186b9a36e7a77ddd17ae9d16188@posteo.com> References:

<6fd64186b9a36e7a77ddd17ae9d16188@posteo.com> Message-ID: <86a24a26-63ab-4feb-bd27-348301eacd59@samoverton.dev> On 08/02/2025 22:29, jay.kayes at posteo.com wrote: > Looking forward to it. Are you proposing to ignore by default, or give > the possibility to ignore DBUS_SESSION_BUS_ADDRESS? With the popularity > of Flatpak apps, ignoring DBUS_SESSION_BUS_ADDRESS by default feels like > it would be better UX overall. On the other hand, there must be a > usecase for passing through the dbus address to pinentry which I'm not > seeing. The task in the issue tracker is here if you wish to follow it: https://dev.gnupg.org/T7522 The default in my patch is to maintain the current behavior, since otherwise this would break existing deployments which rely on it (eg. https://dev.gnupg.org/T3947 ). Regards, From dkg at fifthhorseman.net Mon Feb 10 05:53:45 2025 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 09 Feb 2025 23:53:45 -0500 Subject: Pinentry with flatpak applications In-Reply-To: References: Message-ID: <87pljqjt7q.fsf@fifthhorseman.net> On Sat 2025-02-08 21:45:52 +0100, Mat?j Cepl via Gnupg-users wrote: > Wait? Why do you need to run pinentry from flatpak app? Isn?t it > run on the host system? I think that's the point. pinentry is run from the host system, but the invocation of gpg (which talks to gpg-agent, which in turn invokes pinentry) happens within the flatpak environment. Since gpg passes the environment as a string (well, several strings) to gpg-agent, which uses that to set up the environment in which to invoke pinentry, pinentry ends up with the flatpak environment. I see the proposed patch at T7522, to make yet another configuration variable which one of the hops along the chain would use to filter out specific environment variables, leaving the user to figure it out for themselves. I'm pretty sure most desktop users have no idea what the "right" DBus session address is in any given context (even less than they knew what $DISPLAY was supposed to be under X11), so it looks to me like the whole process here is just giving the user enough rope to hang themselves with :( Have you considered pointing flatpak at gpg-agent's --extra-socket, which i think is more constrained than the standard gpg-agent socket? Does that help? What if, in a FreeDesktop environment, the overall policy was just: - gpg-agent decides where to display the pinentry, *not* the gpg invocation which talks to gpg-agent - by default, gpg-agent should know how to display the pinentry in the main running desktop session. - if you want something fancier, you need to design and maintain it yourself. This overall would suggest that passing through *any* environment variables originating from gpg all the way through the gpg?gpg-agent?pinentry chain would be a mistake, and argues for the allowlisting approach proposed by ikloecker in T7522. The only issue here is if gpg-agent somehow gets launched before the DBUS_SESSION_BUS_ADDRESS variable is initially set for the login; in that case, any D-Bus-based pinentry would simply fail each time gpg-agent tried to launch it. So we'd need to ensure that DBUS_SESSION_BUS_ADDRESS is set correctly before launching gpg-agent. This is made more confusing by the myriad pinentries, not all of which care about DBUS or other environment variables anyway. --dkg PS I also note that this whole process is starting to smell like something that lets a flatpak app smuggle a directive to something outside the flatpak environment -- which, as i understand it, is something that flatpak is supposed to limit. I don't know whether anyone with a background in the flatpak security model has tried to analyze this situation. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: