From david at djsp.eu Wed Mar 1 21:34:25 2023 From: david at djsp.eu (=?UTF-8?Q?David_Joaqu=C3=ADn_Shourabi_Porcel?=) Date: Wed, 01 Mar 2023 21:34:25 +0100 Subject: Management of background services with systemd Message-ID: <5ae3d1f5-0b93-45d5-ba10-ef034b28f909@app.fastmail.com> I am researching GnuPG for my employer. We will stick with the old release series 2.2 at first, because few Linux distributions package 2.3 or 2.4 yet. However, I'm studying newer versions and recent developments to ease our future upgrades. In doing so, a question has arisen: should background services like the agent not be managed with systemd? Daniel Kahn Gillmor [introduced][1] and maintained systemd unit files and also implemented `--supervised` for the [agent][2] and [dirmngr][3] as part of version 2.1.16. However, `--supervised` has been [deprecated][4] since version 2.3.6 and Werner recently [removed the systemd unit files][5] altogether. In fact, he commented the following on [task T6336][6] about two months ago: > Actually, the entire systemd based launching is deprecated and thus the logged warning [about `--supervised`] is on purpose. > > The problem with the systemd launched gpg-agent is that it creates a race: gpg launches gpg-agent as needed and to avoid concurrent launching by other gpg or gpgsm processes, it takes a file system lock during the launch process. systemd does not know about this and we end up with sometimes end up with two gpg-agent processes. Eventually one of those processes detects that it does not own the socket and terminates itself. No real harm here but you may see smart card lockups or a flushed password cache. For what it's worth, the systemd setup (as packaged with series 2.2) works very well for me. In particular: - background services are managed through a common interface (that of systemd); - logs are centralized; and - the agent starts whenever OpenSSH needs it, thanks to socket activation. I have experienced only one limitation: there is no convenient way for systemd to manage background processes for [ephemeral home directories][7], which I have been using extensively for my research & testing. [1]: https://dev.gnupg.org/rG57e95f5413e21cfcb957af2346b292686a5647b7 [2]: https://dev.gnupg.org/rG9f92b62a51d2d60f038fdbe01602865c5933fa95 [3]: https://dev.gnupg.org/rG75f8aaf5bc2dc7fcffe2987a572d489155c91eb9 [4]: https://dev.gnupg.org/rGca5d5142c6d6eaba4572a086f8473e4aebdd3f9e [5]: https://dev.gnupg.org/rGeae28f1bd4a5632e8f8e85b7248d1c4d4a10a5ed [6]: https://dev.gnupg.org/T6336 [7]: https://www.gnupg.org/documentation/manuals/gnupg/Ephemeral-home-directories.html From guanx.bac at gmail.com Thu Mar 2 02:01:32 2023 From: guanx.bac at gmail.com (Guan Xin) Date: Thu, 2 Mar 2023 09:01:32 +0800 Subject: Management of background services with systemd In-Reply-To: <5ae3d1f5-0b93-45d5-ba10-ef034b28f909@app.fastmail.com> References: <5ae3d1f5-0b93-45d5-ba10-ef034b28f909@app.fastmail.com> Message-ID: On Thu, Mar 2, 2023 at 5:31?AM David Joaqu?n Shourabi Porcel wrote: > > //snip > > I have experienced only one limitation: there is no convenient way for systemd to manage background processes for [ephemeral home directories][7], which I have been using extensively for my research & testing. > So it would be helpful if someone steps up to add systemd interface, as long as it's cleanly decoupled from other parts of gnupg, so that no extra effort is necessary from other developers, and nothing is lost when gnupg is used on systems with service and log management interfaces other than systemd. > > [1]: https://dev.gnupg.org/rG57e95f5413e21cfcb957af2346b292686a5647b7 > [2]: https://dev.gnupg.org/rG9f92b62a51d2d60f038fdbe01602865c5933fa95 > [3]: https://dev.gnupg.org/rG75f8aaf5bc2dc7fcffe2987a572d489155c91eb9 > [4]: https://dev.gnupg.org/rGca5d5142c6d6eaba4572a086f8473e4aebdd3f9e > [5]: https://dev.gnupg.org/rGeae28f1bd4a5632e8f8e85b7248d1c4d4a10a5ed > [6]: https://dev.gnupg.org/T6336 > [7]: https://www.gnupg.org/documentation/manuals/gnupg/Ephemeral-home-directories.html > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-users Guan From mcr at sandelman.ca Thu Mar 2 03:24:35 2023 From: mcr at sandelman.ca (Michael Richardson) Date: Wed, 01 Mar 2023 21:24:35 -0500 Subject: Management of background services with systemd In-Reply-To: <5ae3d1f5-0b93-45d5-ba10-ef034b28f909@app.fastmail.com> References: <5ae3d1f5-0b93-45d5-ba10-ef034b28f909@app.fastmail.com> Message-ID: <11318.1677723875@localhost> David Joaqu?n Shourabi Porcel wrote: > I am researching GnuPG for my employer. We will stick with the old > release series 2.2 at first, because few Linux distributions package > 2.3 or 2.4 yet. However, I'm studying newer versions and recent > developments to ease our future upgrades. In doing so, a question has > arisen: should background services like the agent not be managed with > systemd? Please no. It's bad enough as it is when you have multiple personalities you are trying to support (signing as me, vs signing code with an offline key)... having systemd (the userland one) popping off new copies would be horrible. Combined with SSH access to the machine, and the passphrase/pin popup shows up in the wrong place. (And many of us do not trust systemd and do not run it on important machines) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 511 bytes Desc: not available URL: From gnupg at raf.org Thu Mar 2 07:13:38 2023 From: gnupg at raf.org (raf) Date: Thu, 2 Mar 2023 17:13:38 +1100 Subject: Management of background services with systemd In-Reply-To: <11318.1677723875@localhost> References: <5ae3d1f5-0b93-45d5-ba10-ef034b28f909@app.fastmail.com> <11318.1677723875@localhost> Message-ID: On Wed, Mar 01, 2023 at 09:24:35PM -0500, Michael Richardson wrote: > > David Joaqu?n Shourabi Porcel wrote: > > I am researching GnuPG for my employer. We will stick with the old > > release series 2.2 at first, because few Linux distributions package > > 2.3 or 2.4 yet. However, I'm studying newer versions and recent > > developments to ease our future upgrades. In doing so, a question has > > arisen: should background services like the agent not be managed with > > systemd? > > Please no. > > It's bad enough as it is when you have multiple personalities you are trying > to support (signing as me, vs signing code with an offline key)... having > systemd (the userland one) popping off new copies would be horrible. > > Combined with SSH access to the machine, and the passphrase/pin popup shows > up in the wrong place. > > (And many of us do not trust systemd and do not run it on important machines) Having systemd control gpg-agent can be a huge problem even with a single personality. If you want a user to login via ssh to start an agent to temporarily store a passphrase, and then the same user logs in separately via ssh to make use of it, systemd treats them as different user sessions, each with their own gpg-agent, and the second one has no access to the passphrase setup for it by the first one. Presumably, this isn't a problem for most use cases, but it really spoiled things for me. cheers, raf From wk at gnupg.org Thu Mar 2 17:53:21 2023 From: wk at gnupg.org (Werner Koch) Date: Thu, 02 Mar 2023 17:53:21 +0100 Subject: Management of background services with systemd In-Reply-To: <11318.1677723875@localhost> (Michael Richardson's message of "Wed, 01 Mar 2023 21:24:35 -0500") References: <5ae3d1f5-0b93-45d5-ba10-ef034b28f909@app.fastmail.com> <11318.1677723875@localhost> Message-ID: <87mt4vgkn2.fsf@wheatstone.g10code.de> On Wed, 1 Mar 2023 21:24, Michael Richardson said: > Combined with SSH access to the machine, and the passphrase/pin popup shows > up in the wrong place. Talking about ssh: Yes, you need to make sure that gpg-agent has been launched. But once that has been done ssh works nicely. The major problem with ssh is that ssh has no way to pass environment variables to gpg-agent via the ssh-agent protocol. gpg-agent needs the envvars to pop up pinentry on the right tty/display. I once posted patches to the ssh list to extend ssh in this way but the interest was not high and I had no time to starting convincing them to apply these patches. Actually it would also be possible to tell ssh to autostart gpg-agent, similar to what gpg does. This could be done as a generic pre-connect extension to ssh. 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: 227 bytes Desc: not available URL: From roam at ringlet.net Fri Mar 3 11:36:09 2023 From: roam at ringlet.net (Peter Pentchev) Date: Fri, 3 Mar 2023 12:36:09 +0200 Subject: Management of background services with systemd In-Reply-To: <87mt4vgkn2.fsf@wheatstone.g10code.de> References: <5ae3d1f5-0b93-45d5-ba10-ef034b28f909@app.fastmail.com> <11318.1677723875@localhost> <87mt4vgkn2.fsf@wheatstone.g10code.de> Message-ID: On Thu, Mar 02, 2023 at 05:53:21PM +0100, Werner Koch via Gnupg-users wrote: > On Wed, 1 Mar 2023 21:24, Michael Richardson said: > > > Combined with SSH access to the machine, and the passphrase/pin popup shows > > up in the wrong place. > > Talking about ssh: Yes, you need to make sure that gpg-agent has been > launched. But once that has been done ssh works nicely. > > The major problem with ssh is that ssh has no way to pass environment > variables to gpg-agent via the ssh-agent protocol. gpg-agent needs the > envvars to pop up pinentry on the right tty/display. I once posted > patches to the ssh list to extend ssh in this way but the interest was > not high and I had no time to starting convincing them to apply these > patches. > > Actually it would also be possible to tell ssh to autostart gpg-agent, > similar to what gpg does. This could be done as a generic pre-connect > extension to ssh. FWIW, there is also the keychain tool that may be invoked in shell startup scripts (which also provides the ability to differentiate - if needed - between interactive and non-interactive shells): - the tool itself: https://www.funtoo.org/Keychain - a couple of patches that we apply to the Debian packaging: - https://salsa.debian.org/debian/keychain/-/blob/debian/master/debian/patches/malformed-ssh-key.patch - https://salsa.debian.org/debian/keychain/-/blob/debian/master/debian/patches/empty-ssh-askpass.patch G'luck, Peter -- Peter Pentchev roam at ringlet.net roam at debian.org pp at storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From efeizbudak at disroot.org Fri Mar 3 13:09:09 2023 From: efeizbudak at disroot.org (efeizbudak) Date: Fri, 3 Mar 2023 07:09:09 -0500 Subject: Confusion about gpg-preset-passphrase Message-ID: <20230303120909.fhi4wcria3u7muvf@localhost> Hi all, So I'm trying to use gpg-preset-passphrase but for some reason I keep having to enter the passphrase all the same. I run /usr/libexec/gpg-preset-passphrase --preset $KEYGRIP and then paste the passphrase (I've also tried this with the keygrip for the [E] subkey as opposed to the [SC]). But then when I try to decrypt a file encrypted for this key I still face pinentry. I also tried running the decryption command with the --pinentry loopback --batch which just fails with gpg: Sorry, we are in batchmode - can't get input And I already have in my gpg-agent.conf the following: allow-preset-passphrase max-cache-ttl 2147483647 Am I misunderstanding something here? Can someone please point me in the right direction? Thank you! -- All the best, Efe The funny quote of this email is trivial and left as an exercise. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From kloecker at kde.org Fri Mar 3 15:09:16 2023 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Fri, 03 Mar 2023 15:09:16 +0100 Subject: Confusion about gpg-preset-passphrase In-Reply-To: <20230303120909.fhi4wcria3u7muvf@localhost> References: <20230303120909.fhi4wcria3u7muvf@localhost> Message-ID: <5816457.MhkbZ0Pkbq@daneel> On Freitag, 3. M?rz 2023 13:09:09 CET efeizbudak via Gnupg-users wrote: > So I'm trying to use gpg-preset-passphrase but for some reason I keep > having to enter the passphrase all the same. I run > > /usr/libexec/gpg-preset-passphrase --preset $KEYGRIP Works for me (with the current development version). I did the following (after adding `allow-preset-passphrase` to gpg-agent.conf and restarting gpg-agent): $ gpg -K --with-keygrip A151BC5817C228CF sec ed25519 2021-02-26 [SC] 69C701A436FDD496FAE5580AA151BC5817C228CF Keygrip = 382BC7C2C4E13EF7D40870B7EB9CDE4AE0232B4E uid [ultimate] foo at example.net ssb cv25519 2021-02-26 [E] Keygrip = B9386D3E742597E532C6BD0978192517A09B41C3 $ echo bla | gpg --armor --encrypt -r A151BC5817C228CF | gpg --decrypt -> pinentry pops up; I click Cancel gpg: encrypted with cv25519 key, ID 14AC6E5C812B91E1, created 2021-02-26 "foo at example.net" gpg: public key decryption failed: Operation cancelled gpg: decryption failed: Operation cancelled $ /opt/gnupg/master/libexec/gpg-preset-passphrase --preset \ B9386D3E742597E532C6BD0978192517A09B41C3 test $ echo bla | gpg --armor --encrypt -r A151BC5817C228CF | gpg --decrypt -> no pinentry pops up gpg: encrypted with cv25519 key, ID 14AC6E5C812B91E1, created 2021-02-26 "foo at example.net" bla Are you sure that you used the keygrip of the encryption subkey and not its fingerprint? Does caching work if you enter the passphrase in pinentry? (I'm asking because I'm wondering whether your max-cache-ttl could be the problem.) Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From efeizbudak at disroot.org Fri Mar 3 15:50:05 2023 From: efeizbudak at disroot.org (Efe =?utf-8?Q?=C4=B0zbudak?=) Date: Fri, 3 Mar 2023 09:50:05 -0500 Subject: Confusion about gpg-preset-passphrase In-Reply-To: <5816457.MhkbZ0Pkbq@daneel> References: <20230303120909.fhi4wcria3u7muvf@localhost> <5816457.MhkbZ0Pkbq@daneel> Message-ID: <20230303145005.abz3a7xijjgnlaq6@localhost> On 23/03/03 03:09PM, Ingo Kl?cker wrote: > On Freitag, 3. M?rz 2023 13:09:09 CET efeizbudak via Gnupg-users wrote: > > So I'm trying to use gpg-preset-passphrase but for some reason I keep > > having to enter the passphrase all the same. I run > > > > /usr/libexec/gpg-preset-passphrase --preset $KEYGRIP > > Works for me (with the current development version). I did the following > (after adding `allow-preset-passphrase` to gpg-agent.conf and restarting > gpg-agent): > > $ gpg -K --with-keygrip A151BC5817C228CF > sec ed25519 2021-02-26 [SC] > 69C701A436FDD496FAE5580AA151BC5817C228CF > Keygrip = 382BC7C2C4E13EF7D40870B7EB9CDE4AE0232B4E > uid [ultimate] foo at example.net > ssb cv25519 2021-02-26 [E] > Keygrip = B9386D3E742597E532C6BD0978192517A09B41C3 > > $ echo bla | gpg --armor --encrypt -r A151BC5817C228CF | gpg --decrypt > -> pinentry pops up; I click Cancel > gpg: encrypted with cv25519 key, ID 14AC6E5C812B91E1, created 2021-02-26 > "foo at example.net" > gpg: public key decryption failed: Operation cancelled > gpg: decryption failed: Operation cancelled > > $ /opt/gnupg/master/libexec/gpg-preset-passphrase --preset \ > B9386D3E742597E532C6BD0978192517A09B41C3 > test > > $ echo bla | gpg --armor --encrypt -r A151BC5817C228CF | gpg --decrypt > -> no pinentry pops up > gpg: encrypted with cv25519 key, ID 14AC6E5C812B91E1, created 2021-02-26 > "foo at example.net" > bla > > Are you sure that you used the keygrip of the encryption subkey and not its > fingerprint? Does caching work if you enter the passphrase in pinentry? (I'm > asking because I'm wondering whether your max-cache-ttl could be the problem.) > > Regards, > Ingo After seeing your example, I thought, why don't I test this with a simpler password and it turns out that the problem was with my very complicated auto-generated password which I believe have contained some characters that were "illegal." Everything works fine with the simpler password. Thank you for spending time on this. Sorry for not noticing it earlier. -- All the best, Efe The funny quote of this email is trivial and left as an exercise. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From avemilia at protonmail.com Sat Mar 4 18:18:07 2023 From: avemilia at protonmail.com (Ave Milia) Date: Sat, 04 Mar 2023 17:18:07 +0000 Subject: Optimal workflow with GPG signatures from multiple parties Message-ID: Hi list, We have a build server, it stores a private key and is capable of signing the resulting build artifact. The artifact then gets verified in the target environment during installation. There are multiple issues with current approach: 1. A random developer cannot trigger a build on the server from a random branch that they pushed. Therefore, if a random developer wants to test something they wrote and build a clean artifact, it has to go through the build server admin, who has an account on the build server, and ask him to build and sign something manually. This is a huge bottleneck. 2. The build server is the single source of truth, since it has the private key. Which is also the reason, why a random developer shouldn't get an account on the build server. If the private key is leaked, anybody can sign anything and run it in the target environment. 3. The build server is only a single computer. We also want to build on different hardware, e.g. a cluster that spins up Docker containers, where every random developer has their own running container, is able to build and sign the artifacts. So, everyone interested should be able to build, sign and deploy the artifacts. At the same time, it is important to not share direct access to the private key between everyone. Additionally, the solution should be scalable and flexible: the developer should be able to build and sign something locally on their laptop, if they so desire. The problem can also be described in terms of "production" and "development" builds. Currently, the build server only issues "production" builds, and everyone who wants to build and test their artifacts has to either wait for a nightly build, or ask the build server admin to do it manually. What we want is to also introduce "development" builds, artifacts quickly hacked together for testing purposes, that many developers can build and sign as they wish. Logically, it probably should not be as simple as the developer deploying their personal public key into the target environment and then signing their artifact, for two reasons: the target environment gets wiped, and it practically cannot account for all personal keys of all the developers; and then there is not much difference versus giving the developer direct access to the main private key. What are some available solutions? How would you suggest to organize the keys? Maybe, there should be some signing server in-place, that the developers sends an artifact to? Thanks, ave From jcb62281 at gmail.com Sun Mar 5 02:17:40 2023 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Sat, 04 Mar 2023 19:17:40 -0600 Subject: Optimal workflow with GPG signatures from multiple parties In-Reply-To: References: Message-ID: <6403EDB4.2090300@gmail.com> Ave Milia via Gnupg-users wrote: > Logically, it probably should not be as simple as the developer deploying their personal public key into the target environment and then signing their artifact, for two reasons: the target environment gets wiped, and it practically cannot account for all personal keys of all the developers; and then there is not much difference versus giving the developer direct access to the main private key. > Er, I may be mistaken here, but I understand that if any of the code you distribute is GPLv3, installing a personal public key into the target environment is exactly what you are required to permit. (Or the "Installation Instructions" required under section 6 of the GPLv3 can include the main private key, your choice.) The only way you get out of this is if you are not actually distributing code and this whole scenario is internal to some organization. > What are some available solutions? How would you suggest to organize the keys? Maybe, there should be some signing server in-place, that the developers sends an artifact to? > Since you are asking on a list for GPG users, I suspect you are likely using GPG to verify artifacts in the target environment, and therefore need to comply with GPLv3... addressing that first may solve your problem. -- Jacob From andrewg at andrewg.com Mon Mar 6 12:28:58 2023 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 6 Mar 2023 11:28:58 +0000 Subject: Optimal workflow with GPG signatures from multiple parties In-Reply-To: References: Message-ID: <767d9be0-d11a-bac9-ab67-c33bd555b3ad@andrewg.com> On 04/03/2023 17:18, Ave Milia via Gnupg-users wrote: > What are some available solutions? How would you suggest to organize the keys? Maybe, there should be some signing server in-place, that the developers sends an artifact to? I built something similar for $WORK. You lock down the signing server and use your preferred form of authentication to allow only your developers (and the build server) to submit an artifact for signature. This could be done using a simple REST API. Once you have this in place, it would be easy to extend it with a second signing key for development purposes only, and make sure that only the production public key is distributed with your production artifacts. That way all your developers can get their dev builds signed, but only your build server and maybe your release manager have the credentials to sign with the production key. This could be done by linking the signing key to the user credentials, or by having two signing servers. A From mgcyung at gmail.com Sat Mar 18 21:23:43 2023 From: mgcyung at gmail.com (yung mgc) Date: Sun, 19 Mar 2023 04:23:43 +0800 Subject: Error on gpg key exported from linux to Mac Message-ID: I have exported a gpg key from linux to Mac. Exporting commands on linux are as follows ``` gpg --export-secret-keys -a test_01.asc gpg --export -a test_01_pub.asc ``` Importing commands on Mac are as follows ``` gpg --import test_01.asc gpg --import test_01_pub.asc ``` But when decrypting with the imported key, ``` gpg -d -vvv test_01.gpg ``` gpg said ``` gpg: using character set 'utf-8' gpg: enabled compatibility flags: # off=0 ctb=85 tag=1 hlen=3 plen=268 :pubkey enc packet: version 3, algo 1, keyid XXXXXXXXXXXXXXXX data: [2048 bits] gpg: public key is XXXXXXXXXXXXXXXX # off=271 ctb=d2 tag=18 hlen=2 plen=62 new-ctb :encrypted data packet: length: 62 mdc_method: 2 gpg: using subkey XXXXXXXXXXXXXXXX instead of primary key XXXXXXXXXXXXXXXX gpg: encrypted with rsa2048 key, ID XXXXXXXXXXXXXXXX, created xxxx-xx-xx "xxx " gpg: public key decryption failed: Bad secret key gpg: decryption failed: Bad secret key ``` And when I tried to change its passwd, gpg said ``` error getting keyinfo from agent: System error w/o errno pKey has only stub or on-card key items - no passphrase to change. ``` The versions of gpgs on Linux and Mac are 2.2.41 and 2.4.0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kloecker at kde.org Sun Mar 19 09:02:01 2023 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sun, 19 Mar 2023 09:02:01 +0100 Subject: Error on gpg key exported from linux to Mac In-Reply-To: References: Message-ID: <12175192.O9o76ZdvQC@daneel> On Samstag, 18. M?rz 2023 21:23:43 CET yung mgc via Gnupg-users wrote: > I have exported a gpg key from linux to Mac. Exporting commands on linux > are as follows [...] > And when I tried to change its passwd, gpg said > > ``` > error getting keyinfo from agent: System error w/o errno > pKey has only stub or on-card key items - no passphrase to change. > ``` > > The versions of gpgs on Linux and Mac are 2.2.41 and 2.4.0 What does `gpg -K ` output on Linux and Mac? Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From xeyrion at gmail.com Wed Mar 22 21:16:30 2023 From: xeyrion at gmail.com (xeyrion at gmail.com) Date: Wed, 22 Mar 2023 16:16:30 -0400 Subject: gpg-preset-passphrase and extra agent socket Message-ID: Hello, I am trying to set up agent forwarding as per https://wiki.gnupg.org/AgentForwarding. Everything is generally working, but the remote gpg is prompting for passphrases despite gpg-preset-passphrase having been used against local agent. Forwarding normal socket (instead of extra socket) makes the prompt go away. Is there a way to preset passphrase for extra socket as well? If not, what are the implications of forwarding the normal socket? The wiki page just says "extra socket is more restricted" without going into any details. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From xeyrion at gmail.com Wed Mar 22 22:22:11 2023 From: xeyrion at gmail.com (xeyrion at gmail.com) Date: Wed, 22 Mar 2023 17:22:11 -0400 Subject: gpg-preset-passphrase and extra agent socket Message-ID: I am trying to set up agent forwarding as per https://wiki.gnupg.org/AgentForwarding. Everything is generally working, but the remote gpg is prompting for passphrases despite gpg-preset-passphrase having been used against local gpg agent. Forwarding normal socket (instead of extra socket) makes the prompt go away. Is there a way to preset passphrase for extra socket as well? If not, what are the implications of forwarding the normal socket? The wiki page just says "extra socket is more restricted" without going into any details. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Fri Mar 24 10:18:30 2023 From: wk at gnupg.org (Werner Koch) Date: Fri, 24 Mar 2023 10:18:30 +0100 Subject: gpg-preset-passphrase and extra agent socket In-Reply-To: (xeyrion's message of "Wed, 22 Mar 2023 16:16:30 -0400") References: Message-ID: <87mt42tsm1.fsf@wheatstone.g10code.de> On Wed, 22 Mar 2023 16:16, xeyrion--- said: > Forwarding normal socket (instead of extra socket) makes the prompt go > away. Is there a way to preset passphrase for extra socket as well? The caching behavior does not depend on the connection type. Thus this should not be an issue. I assume you are using 2.4.0 which has a couple of fixes for remote use. I am almost always using the extra-socket with cards and thus I unloch the card before I start working (using "gpg-card" and its "verify" command). I would suggest to add debug ipc,cache log-file /foo/somefile to your local gpg-agent.conf (or use watchgnupg and "socket://" as file for live watching) to see what's going on. You should see some error message "Forbidden" when the remote site issues certain commands. > If not, what are the implications of forwarding the normal socket? The wiki > page just says "extra socket is more restricted" without going into any For example the remote site can't list the keys on the local site. This is sometimes required and thus you can allow this on per private key base by adding Remote-list: true to the private key file (which you figure out using gpg -K --with-keygrip). But that might not be your problem. 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: 227 bytes Desc: not available URL: From xeyrion at gmail.com Sat Mar 25 23:56:57 2023 From: xeyrion at gmail.com (xeyrion at gmail.com) Date: Sat, 25 Mar 2023 18:56:57 -0400 Subject: gpg-preset-passphrase and extra agent socket In-Reply-To: <87mt42tsm1.fsf@wheatstone.g10code.de> References: <87mt42tsm1.fsf@wheatstone.g10code.de> Message-ID: On Fri, Mar 24, 2023 at 5:20?AM Werner Koch wrote: > On Wed, 22 Mar 2023 16:16, xeyrion--- said: > > > Forwarding normal socket (instead of extra socket) makes the prompt go > > away. Is there a way to preset passphrase for extra socket as well? > > The caching behavior does not depend on the connection type. Thus this > should not be an issue. I assume you are using 2.4.0 which has a couple > of fixes for remote use. > > I am almost always using the extra-socket with cards and thus I unloch > the card before I start working (using "gpg-card" and its "verify" > command). > > I would suggest to add > > debug ipc,cache > log-file /foo/somefile > > to your local gpg-agent.conf (or use watchgnupg and "socket://" as file > for live watching) to see what's going on. You should see some error > message "Forbidden" when the remote site issues certain commands. > Thanks for the debugging tips. I collected more info using those. Caching behavior does indeed seem to depend on connection type based on what I am seeing in the logs: Call to gpg-preset-passphrase for : DBG: chan_8 <- PRESET_PASSPHRASE -1 DBG: agent_put_cache ''.0 (mode 1) requested ttl=-1 DBG: chan_8 -> OK Asking to decrypt using normal socket: DBG: chan_8 <- PKDECRYPT DBG: chan_8 -> S INQUIRE_MAXLEN 4096 DBG: chan_8 -> INQUIRE CIPHERTEXT DBG: chan_8 <- [ 00 00 00 ...(105 byte(s) skipped) ] DBG: chan_8 <- END DBG: agent_get_cache ''.0 (mode 2) ... DBG: ... hit Asking to decrypt using extra socket: DBG: chan_8 <- PKDECRYPT DBG: chan_8 -> S INQUIRE_MAXLEN 4096 DBG: chan_8 -> INQUIRE CIPHERTEXT DBG: chan_8 <- [ 00 00 00 ...(105 byte(s) skipped) ] DBG: chan_8 <- END DBG: agent_get_cache ''.1 (mode 2) ... DBG: ... miss DBG: agent_get_cache ''.1 (mode 2) (stored cache key) ... DBG: ... miss starting a new PIN Entry The difference seems to be that normal socket uses ".0" as cache key while extra socket uses ".1" and therefore misses? This is using GnuPG 2.4.0 both on local and remote. Ideas? Is this a designed behavior? Or do I have something misconfigured? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Mon Mar 27 11:57:40 2023 From: wk at gnupg.org (Werner Koch) Date: Mon, 27 Mar 2023 11:57:40 +0200 Subject: gpg-preset-passphrase and extra agent socket In-Reply-To: (xeyrion's message of "Sat, 25 Mar 2023 18:56:57 -0400") References: <87mt42tsm1.fsf@wheatstone.g10code.de> Message-ID: <87cz4utt2j.fsf@wheatstone.g10code.de> On Sat, 25 Mar 2023 18:56, xeyrion--- said: > The difference seems to be that normal socket uses ".0" as cache key while > extra socket uses ".1" and therefore misses? You are right. I forgot about this. You need to wait for the next version or apply the attached patch and run gpg-preset-passphrase with the option --restricted to address the other cache. 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: 0001-agent-New-option-restricted-for-PRESET_PASSPHRASE.patch Type: text/x-diff Size: 4461 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From andrewg at andrewg.com Mon Mar 27 19:47:00 2023 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 27 Mar 2023 18:47:00 +0100 Subject: Flooding attack against synchronising keyservers Message-ID: <1560A136-39D1-4052-AF35-AEEE89BDCD3D@andrewg.com> Hi, everyone. The synchronising keyserver network has been under an intermittent flooding attack for the past five days, resulting in the addition of approximately 3 million obviously-fake OpenPGP keys to the SKS dataset. The fake keys are currently being submitted multiple times per second via a large number of Tor exit relays, making them difficult to block using normal abuse mitigations. If unaddressed, this will eventually fill up the disk of all public synchronising servers. Effective immediately, pgpkeys.eu has been temporarily disconnected from all its peers, and is blocking all key submissions. It will remain available for key lookups but will not allow key updates while the flooding attack continues. I strongly recommend that other keyserver operators take similar measures, until a more permanent solution can be deployed. A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From xeyrion at gmail.com Mon Mar 27 21:27:15 2023 From: xeyrion at gmail.com (xeyrion at gmail.com) Date: Mon, 27 Mar 2023 15:27:15 -0400 Subject: gpg-preset-passphrase and extra agent socket In-Reply-To: <87cz4utt2j.fsf@wheatstone.g10code.de> References: <87mt42tsm1.fsf@wheatstone.g10code.de> <87cz4utt2j.fsf@wheatstone.g10code.de> Message-ID: On Mon, Mar 27, 2023 at 5:58?AM Werner Koch wrote: > You are right. I forgot about this. > > You need to wait for the next version or apply the attached patch and > run gpg-preset-passphrase with the option --restricted to address the > other cache. > Great, thanks for confirming and the patch! -------------- next part -------------- An HTML attachment was scrubbed... URL: From dirk at computer42.org Tue Mar 28 13:44:18 2023 From: dirk at computer42.org (H.-Dirk Schmitt) Date: Tue, 28 Mar 2023 13:44:18 +0200 Subject: Flooding attack against synchronising keyservers In-Reply-To: <1560A136-39D1-4052-AF35-AEEE89BDCD3D@andrewg.com> References: <1560A136-39D1-4052-AF35-AEEE89BDCD3D@andrewg.com> Message-ID: <06be88229fff72091ea5ff63ec1a6a13f78932d0.camel@computer42.org> As adviced I temporarily disabled the peers on keyserver{1,2}.computer42.org. Waiting for a better solution ? Best regards, H.-Dirk -- H.-Dirk Schmitt Dipl.Math. eMail:dirk.schmitt at computer42.org mobile:+49 177 616 8564 phone: +49 2642 99 41 14 fax: +49 2642 99 41 15 Schillerstr. 42, D-53489 Sinzig pgp: http://www.computer42.org/~dirk/OpenPGP-fingerprint.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From iarenaza at escomposlinux.org Tue Mar 28 23:25:13 2023 From: iarenaza at escomposlinux.org (=?utf-8?Q?I=C3=B1aki_Arenaza?=) Date: Tue, 28 Mar 2023 23:25:13 +0200 Subject: Flooding attack against synchronising keyservers In-Reply-To: <06be88229fff72091ea5ff63ec1a6a13f78932d0.camel@computer42.org> (H.'s message of "Tue, 28 Mar 2023 13:44:18 +0200") References: <1560A136-39D1-4052-AF35-AEEE89BDCD3D@andrewg.com> <06be88229fff72091ea5ff63ec1a6a13f78932d0.camel@computer42.org> Message-ID: <87lejgefgm.fsf@escomposlinux.org> On mar, mar 28 2023, H.-Dirk Schmitt wrote: > As adviced I temporarily disabled the peers on > keyserver{1,2}.computer42.org. Same for keys.escomposlinux.org > Waiting for a better solution ? Let's hope there is one... Best regards, I?aki. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 264 bytes Desc: not available URL: From 400thecat at gmx.ch Wed Mar 29 12:20:08 2023 From: 400thecat at gmx.ch (Fourhundred Thecat) Date: Wed, 29 Mar 2023 12:20:08 +0200 Subject: encryption failed: No dirmngr Message-ID: <275ab941-be38-6d5d-4ab1-a5052c3ed187@gmx.ch> Hello, I am getting this error: $ gpg --lock-never --no-verbose --batch --yes --pinentry-mode loopback -e -r 'name at domain.com' -o zz.gpg zz gpg: failed to start the dirmngr '/usr/bin/dirmngr': No such file or directory gpg: connecting dirmngr at '/var/lib/asterisk/.gnupg/S.dirmngr' failed: No such file or directory gpg: error retrieving 'name at domain.com' via WKD: No dirmngr ogpg: name at domain.com: skipped: No dirmngr gpg: zz: encryption failed: No dirmngr . this is on a server where gpg worked before without problems. I don't want to use any dirmanager, they encryption key is stored locally, and is trusted (I can see it with gpg --list-public-keys) I just need to simply encrypt a file with given public key. Without any daemons, without any external servers or services, without checking any revocation certificates. From kloecker at kde.org Wed Mar 29 14:42:59 2023 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Wed, 29 Mar 2023 14:42:59 +0200 Subject: encryption failed: No dirmngr In-Reply-To: <275ab941-be38-6d5d-4ab1-a5052c3ed187@gmx.ch> References: <275ab941-be38-6d5d-4ab1-a5052c3ed187@gmx.ch> Message-ID: <5663716.DvuYhMxLoT@daneel> On Mittwoch, 29. M?rz 2023 12:20:08 CEST Fourhundred Thecat via Gnupg-users wrote: > I am getting this error: > > $ gpg --lock-never --no-verbose --batch --yes --pinentry-mode loopback -e -r > 'name at domain.com' -o zz.gpg zz gpg: failed to start the dirmngr > '/usr/bin/dirmngr': No such file or directory gpg: connecting dirmngr at > '/var/lib/asterisk/.gnupg/S.dirmngr' failed: No such file or directory gpg: > error retrieving 'name at domain.com' via WKD: No dirmngr > ogpg: name at domain.com: skipped: No dirmngr > gpg: zz: encryption failed: No dirmngr > . > this is on a server where gpg worked before without problems. Could it be that the used key has expired? This would explain why all of the sudden gpg tries to look for the key via WKD. It should only do this if the local lookup failed. To prevent automatic remote key lookup add no-auto-key-locate to your gpg.conf. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: