From kookie at spacekookie.de Fri Jun 1 00:04:25 2018 From: kookie at spacekookie.de (kookie at spacekookie.de) Date: Fri, 1 Jun 2018 00:04:25 +0200 (CEST) Subject: Problem signing git commits with smartcard key In-Reply-To: <876033d4g5.fsf@wheatstone.g10code.de> References: <393566227.63640.1527775976783@office.mailbox.org> <87po1bd8o7.fsf@wheatstone.g10code.de> <892150189.14799.1527792389874@office.mailbox.org> <876033d4g5.fsf@wheatstone.g10code.de> Message-ID: <446572470.15550.1527804265561@office.mailbox.org> > On 31 May 2018 at 21:12 Werner Koch wrote: > > You are signing with the second key of the token. This is an encryption > key and thus not able to sign. If you do a "gpg -card-status" can you > see an Signature key (In the log "OpenPGP.1")? Hmmm...this is the output of gpg2 --card-status ```````````````````````````````````````````````````````````````````````` Reader ...........: 1050:0407:X:0 --- snip --- Signature key ....: 555F 2E4B 6F87 F91A 4110 669E 9073 4A9E 619C 8A6C created ....: 2018-05-30 14:51:48 Encryption key....: 61C3 62BB 16DD E6D4 12CF D886 02B4 A3CD CBFF 6776 created ....: 2018-05-30 15:06:41 Authentication key: 0451 14E6 0E98 AF5A 977B 3550 EA31 A1BF 4D0C 4706 created ....: 2018-05-30 15:07:10 General key info..: pub rsa4096/90734A9E619C8A6C 2018-05-30 Katharina Fey sec> rsa4096/90734A9E619C8A6C created: 2018-05-30 expires: never card-no: 0006 07319482 ssb> rsa4096/02B4A3CDCBFF6776 created: 2018-05-30 expires: never card-no: 0006 07319482 ssb> rsa4096/EA31A1BF4D0C4706 created: 2018-05-30 expires: never card-no: 0006 07319482 ```````````````````````````````````````````````````````````````````````` Cross-referencing that with the output of gpg2 --list-secret-keys ```````````````````````````````````````````````````````````````````````` sec> rsa4096 2018-05-30 [SC] 555F2E4B6F87F91A4110669E90734A9E619C8A6C --- snip --- uid [ultimate] Katharina Fey ssb> rsa4096 2018-05-30 [SEA] ssb> rsa4096 2018-05-30 [A] ```````````````````````````````````````````````````````````````````````` So the first sub-key should be able to do signature, encryption and auth. But then again I'm also new to the whole yubikey thing so I don't know how exactly this is supposed to work ;) ~ Katharina From wk at gnupg.org Fri Jun 1 01:41:33 2018 From: wk at gnupg.org (Werner Koch) Date: Fri, 01 Jun 2018 01:41:33 +0200 Subject: Problem signing git commits with smartcard key In-Reply-To: <446572470.15550.1527804265561@office.mailbox.org> (kookie@spacekookie.de's message of "Fri, 1 Jun 2018 00:04:25 +0200 (CEST)") References: <393566227.63640.1527775976783@office.mailbox.org> <87po1bd8o7.fsf@wheatstone.g10code.de> <892150189.14799.1527792389874@office.mailbox.org> <876033d4g5.fsf@wheatstone.g10code.de> <446572470.15550.1527804265561@office.mailbox.org> Message-ID: <87vab3bdg2.fsf@wheatstone.g10code.de> On Fri, 1 Jun 2018 00:04, kookie at spacekookie.de said: > ssb> rsa4096 2018-05-30 [SEA] Remove the S capability from that key. gpg prefers a signing subkey over the primary key but that happens to be an encryption key on the card. You should also be able to specify the key as signingkey = 555F2E4B6F87F91A4110669E90734A9E619C8A6C! in .gitconfig this forces the use of that subkey (well, here it is the primary key). Note the exclamation mark at the end. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From gniibe at fsij.org Fri Jun 1 04:57:26 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 01 Jun 2018 11:57:26 +0900 Subject: Problem signing git commits with smartcard key In-Reply-To: <446572470.15550.1527804265561@office.mailbox.org> References: <393566227.63640.1527775976783@office.mailbox.org> <87po1bd8o7.fsf@wheatstone.g10code.de> <892150189.14799.1527792389874@office.mailbox.org> <876033d4g5.fsf@wheatstone.g10code.de> <446572470.15550.1527804265561@office.mailbox.org> Message-ID: <87muwfp621.fsf@iwagami.gniibe.org> Hello, If I understand correctly, you put: your primary key to the OPENPGP.1 on card. your subkey of SEA capability to the OPENPGP.2 on card. your subkey of A capability to the OPENPGP.3 on card. In this configuration, the OPENPGP.2 key on card is only for decryption. You can't sign with that, even if its capability is specified Sign, Encryption, and Authentication. In OpenPGP card specification, three keys are different. You can have a subkey with Sign capability and put it to OPENPGP.1 key on card. -- From kookie at spacekookie.de Fri Jun 1 22:10:15 2018 From: kookie at spacekookie.de (kookie at spacekookie.de) Date: Fri, 1 Jun 2018 22:10:15 +0200 (CEST) Subject: Problem signing git commits with smartcard key In-Reply-To: <87vab3bdg2.fsf@wheatstone.g10code.de> References: <393566227.63640.1527775976783@office.mailbox.org> <87po1bd8o7.fsf@wheatstone.g10code.de> <892150189.14799.1527792389874@office.mailbox.org> <876033d4g5.fsf@wheatstone.g10code.de> <446572470.15550.1527804265561@office.mailbox.org> <87vab3bdg2.fsf@wheatstone.g10code.de> Message-ID: <506509193.20698.1527883816401@office.mailbox.org> > On 01 June 2018 at 01:41 Werner Koch wrote: > > > On Fri, 1 Jun 2018 00:04, kookie at spacekookie.de said: > > > ssb> rsa4096 2018-05-30 [SEA] > > Remove the S capability from that key. gpg prefers a signing subkey > over the primary key but that happens to be an encryption key on the > card. You should also be able to specify the key as Aaah! Perfect, thanks :) I changed the capabilities of the first sub-key and now it works perfectly. Thanks for the quick replies and help <3 Have a wonderful weekend, Katharina From tookmund at gmail.com Fri Jun 1 22:02:07 2018 From: tookmund at gmail.com (Jacob Adams) Date: Fri, 1 Jun 2018 16:02:07 -0400 Subject: Pinentry: Permission Denied Message-ID: <95bc89a0-14c2-4cbb-782d-40872005c216@gmail.com> I've been getting the occasional "Pinentry: Permission Denied" error when generating new keys with GPGME and leaving pinentry to get the password instead of passing it directly (passphrase=True with the python bindings). Typically a reboot will fix it but it's rather odd. I've attached a couple logs. If there's something else I should be logging to catch this error, please let me know. Any ideas on what might be causing this? A reboot usually fixes it but it's quite annoying. Thanks, Jacob -------------- next part -------------- A non-text attachment was scrubbed... Name: gpg-agent.log Type: text/x-log Size: 2421 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gpgme.log Type: text/x-log Size: 27106 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From gnupg at raf.org Mon Jun 4 01:22:33 2018 From: gnupg at raf.org (gnupg at raf.org) Date: Mon, 4 Jun 2018 09:22:33 +1000 Subject: Pinentry: Permission Denied In-Reply-To: <95bc89a0-14c2-4cbb-782d-40872005c216@gmail.com> References: <95bc89a0-14c2-4cbb-782d-40872005c216@gmail.com> Message-ID: <20180603232233.ewmnykp5vtbkjjas@raf.org> Jacob Adams wrote: > I've been getting the occasional "Pinentry: Permission Denied" error > when generating new keys with GPGME and leaving pinentry to get the > password instead of passing it directly (passphrase=True with the python > bindings). Typically a reboot will fix it but it's rather odd. > > I've attached a couple logs. If there's something else I should be > logging to catch this error, please let me know. > > Any ideas on what might be causing this? > A reboot usually fixes it but it's quite annoying. > > Thanks, > Jacob it might be permissions on /dev/tty (which looks to be /dev/tty1 from the debugging output). did you su/sudo to another user? From steffen at sdaoden.eu Mon Jun 4 15:44:13 2018 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 04 Jun 2018 15:44:13 +0200 Subject: v1.4.22: re--importing --export'ed key from --export-secret-subkeys dir cannot --encrypt Message-ID: <20180604134413.SlJyg%steffen@sdaoden.eu> Hello. Last saturday i search/stumbled over an interesting Debian page (Subkey.html) which describes how to generate a dedicated siging subkeys, and how to create a new key pool via --export-secret-subkeys which does not contain (all parts of) the real private key, so that the secret key can be stored "somewhere else" but the newly reimported secret (sub)key can still be used for signing purposes. I did not know about that yet, unfortunately, and have started to use the "normal" key, so that possible users will have to reimport the updated key. But because it is a really great thing to be able to move the complete private key somewhere else, and to have the remains with a different password at hand, i did that. So despite the fact that noone is interested in that long story (sorry), i cannot find a bug in the bug-db that corresponds to the behaviour i see, and that is that i neither can --export the public key from that mutilated private key and use that one for --encrypt'ion, nor can use the key itself for that (the encryption key seems "hidden", but if i "toggle" --edit-key then i can see it still). But i can use it for signing purposes. My question: is this a bug that --export does not yield a valid public key that can be used for --encrypt'ion, and that the key as such cannot be used for that, too? Shall i open a bug report. Thanks! --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From benjamin.kircher at gmail.com Mon Jun 4 20:44:19 2018 From: benjamin.kircher at gmail.com (Benjamin Kircher) Date: Mon, 4 Jun 2018 20:44:19 +0200 Subject: Forward gpg-agent to container Message-ID: Hello, I want to forward my host gpg-agent to an OCI container so that I can use a secret key that is available on the host to sign some packages inside the container. For this I create a bind mount of agent-extra-socket to /gpg-agent inside the container and start the container with $ docker run --volume $(gpgconf --list-dirs agent-extra-socket):/gpg-agent --entrypoint=sh -ti fedora:latest Now inside the container I can see my socket # ls -l /gpg-agent srwx------ 1 root root 0 Jun 4 17:45 /gpg-agent From here on, I am kind of stuck. I fail to somehow make gpg-agent inside the container ?use? the extra-socket. Here is what I am doing: # mkdir ~/.gnupg && chmod 700 ~/.gnupg # ln -s /gpg-agent ~/.gnupg/S.gpg-agent # ls -l ~/.gnupg/ total 0 lrwxrwxrwx 1 root root 10 Jun 4 18:29 S.gpg-agent -> /gpg-agent However, as soon as I start the agent explicitly, the symlink to the socket is overwritten. # gpg-connect-agent "keyinfo --list" /bye # ls -l ~/.gnupg/ total 8 srwx------ 1 root root 0 Jun 4 18:31 S.gpg-agent srwx------ 1 root root 0 Jun 4 18:31 S.gpg-agent.browser srwx------ 1 root root 0 Jun 4 18:31 S.gpg-agent.extra srwx------ 1 root root 0 Jun 4 18:31 S.gpg-agent.ssh -rw-r--r-- 1 root root 96 Jun 4 18:31 gpg-agent.conf drwx------ 2 root root 4096 Jun 4 18:31 private-keys-v1.d # cat ~/.gnupg/gpg-agent.conf default-cache-ttl 600 max-cache-ttl 7200 debug-level guru debug-all log-file /tmp/gpg-agent.log # cat /tmp/gpg-agent.log 2018-06-04 18:31:58 gpg-agent[12] listening on socket '/root/.gnupg/S.gpg-agent' 2018-06-04 18:31:58 gpg-agent[12] listening on socket '/root/.gnupg/S.gpg-agent.extra' 2018-06-04 18:31:58 gpg-agent[12] listening on socket '/root/.gnupg/S.gpg-agent.browser' 2018-06-04 18:31:58 gpg-agent[12] listening on socket '/root/.gnupg/S.gpg-agent.ssh' 2018-06-04 18:31:58 gpg-agent[13] gpg-agent (GnuPG) 2.2.6 started 2018-06-04 18:31:58 gpg-agent[13] DBG: chan_10 -> OK Pleased to meet you, process 10 2018-06-04 18:31:58 gpg-agent[13] DBG: chan_10 <- RESET 2018-06-04 18:31:58 gpg-agent[13] DBG: chan_10 -> OK 2018-06-04 18:31:58 gpg-agent[13] DBG: chan_10 <- OPTION ttyname=/dev/pts/0 2018-06-04 18:31:58 gpg-agent[13] DBG: chan_10 -> OK 2018-06-04 18:31:58 gpg-agent[13] DBG: chan_10 <- OPTION ttytype=xterm 2018-06-04 18:31:58 gpg-agent[13] DBG: chan_10 -> OK 2018-06-04 18:31:58 gpg-agent[13] DBG: chan_10 <- OPTION lc-ctype=C 2018-06-04 18:31:58 gpg-agent[13] DBG: chan_10 -> OK 2018-06-04 18:31:58 gpg-agent[13] DBG: chan_10 <- OPTION lc-messages=C 2018-06-04 18:31:58 gpg-agent[13] DBG: chan_10 -> OK 2018-06-04 18:31:58 gpg-agent[13] DBG: chan_10 <- keyinfo --list 2018-06-04 18:31:58 gpg-agent[13] DBG: chan_10 -> OK 2018-06-04 18:31:58 gpg-agent[13] DBG: chan_10 <- [eof] 2018-06-04 18:32:02 gpg-agent[13] DBG: agent_cache_housekeeping GnuPG version on the host: 2.2.7 GnuPG version in the container: 2.2.6 Also note that I neither use SSH nor socat to connect. Just that bind mount of the socket. I am aware that I need to fetch my public key before I can ?see? and use the secret key. But from what I can see, it fails earlier. Any pointers heavily appreciated. BK From gniibe at fsij.org Tue Jun 5 02:37:19 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 05 Jun 2018 09:37:19 +0900 Subject: STM32F103 flash ROM read-out service Message-ID: <87o9gqf4qo.fsf@iwagami.gniibe.org> Hello, While learning Chinese language, I found this service (in Chinese): http://www.pcbcopy.com/2016/ic_1128/1928.html IIUC, It's a company in ShenZhen, which offers a service reading out from protected STM32F103, even if it uses anti-tamper feature with a battery. I was aware of similar services for PIC18 or ATmega (in different country). This is new for me, specifically for STM32F103. I don't know the detail of this service, but it seems that it's not that expensive (from not-confirmed information by my friend). Well, I encourage Gnuk users to new use KDF-DO feature with newer GnuPG. -- From andrewg at andrewg.com Tue Jun 5 08:56:54 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 5 Jun 2018 07:56:54 +0100 Subject: Forward gpg-agent to container In-Reply-To: References: Message-ID: <84333D24-6E95-4A2C-BD6B-9EE2B10CC2E2@andrewg.com> > On 4 Jun 2018, at 19:44, Benjamin Kircher wrote: > > Now inside the container I can see my socket > > # ls -l /gpg-agent > srwx------ 1 root root 0 Jun 4 17:45 /gpg-agent > > From here on, I am kind of stuck. I fail to somehow make gpg-agent inside the container ?use? the extra-socket. Here is what I am doing: This sounds overly complicated. Once you have the extra socket visible inside the container, it should be sufficient to set the environment variable GPG_AGENT_SOCK. You don?t need to start an extra agent inside the container. Andrew From benjamin.kircher at gmail.com Tue Jun 5 10:54:18 2018 From: benjamin.kircher at gmail.com (Benjamin Kircher) Date: Tue, 5 Jun 2018 10:54:18 +0200 Subject: Forward gpg-agent to container In-Reply-To: <84333D24-6E95-4A2C-BD6B-9EE2B10CC2E2@andrewg.com> References: <84333D24-6E95-4A2C-BD6B-9EE2B10CC2E2@andrewg.com> Message-ID: > On 5. Jun 2018, at 08:56, Andrew Gallagher wrote: > >> >> On 4 Jun 2018, at 19:44, Benjamin Kircher wrote: >> >> Now inside the container I can see my socket >> >> # ls -l /gpg-agent >> srwx------ 1 root root 0 Jun 4 17:45 /gpg-agent >> >> From here on, I am kind of stuck. I fail to somehow make gpg-agent inside the container ?use? the extra-socket. Here is what I am doing: > > This sounds overly complicated. Once you have the extra socket visible inside the container, it should be sufficient to set the environment variable GPG_AGENT_SOCK. You don?t need to start an extra agent inside the container. Andrew, thanks for looking into this. Is this documented somewhere? I can?t find this environment variable in the man-pages and a quick code search over gnupg, libassuan, gpgme, and friends shows no such environment variable. BK From benjamin.kircher at gmail.com Tue Jun 5 18:02:53 2018 From: benjamin.kircher at gmail.com (Benjamin Kircher) Date: Tue, 5 Jun 2018 18:02:53 +0200 Subject: Forward gpg-agent to container In-Reply-To: References: <84333D24-6E95-4A2C-BD6B-9EE2B10CC2E2@andrewg.com> Message-ID: > On 5. Jun 2018, at 10:54, Benjamin Kircher wrote: > > > >> On 5. Jun 2018, at 08:56, Andrew Gallagher wrote: >> >>> >>> On 4 Jun 2018, at 19:44, Benjamin Kircher wrote: >>> >>> Now inside the container I can see my socket >>> >>> # ls -l /gpg-agent >>> srwx------ 1 root root 0 Jun 4 17:45 /gpg-agent >>> >>> From here on, I am kind of stuck. I fail to somehow make gpg-agent inside the container ?use? the extra-socket. Here is what I am doing: >> >> This sounds overly complicated. Once you have the extra socket visible inside the container, it should be sufficient to set the environment variable GPG_AGENT_SOCK. You don?t need to start an extra agent inside the container. > > Andrew, thanks for looking into this. > > Is this documented somewhere? I can?t find this environment variable in the man-pages and a quick code search over gnupg, libassuan, gpgme, and friends shows no such environment variable. Sorry, but GPG_AGENT_SOCK doesn?t work at all. $ docker run --volume $(gpgconf --list-dirs agent-extra-socket):/gpg-agent --env GPG_AGENT_SOCK=/gpg-agent --entrypoint=sh -ti fedora:latest # env HOSTNAME=26e366f60fc8 PWD=/ HOME=/root FBR=f28 DISTTAG=f28container FGC=f28 GPG_AGENT_SOCK=/gpg-agent TERM=xterm SHLVL=1 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin _=/usr/bin/env # gpg2 --keyserver pgp.uni-mainz.de --recv 325F3B76 # gpg2 --list-secret-keys BK From wk at gnupg.org Tue Jun 5 16:50:54 2018 From: wk at gnupg.org (Werner Koch) Date: Tue, 05 Jun 2018 16:50:54 +0200 Subject: Forward gpg-agent to container In-Reply-To: <84333D24-6E95-4A2C-BD6B-9EE2B10CC2E2@andrewg.com> (Andrew Gallagher's message of "Tue, 5 Jun 2018 07:56:54 +0100") References: <84333D24-6E95-4A2C-BD6B-9EE2B10CC2E2@andrewg.com> Message-ID: <87po1570dt.fsf@wheatstone.g10code.de> On Tue, 5 Jun 2018 08:56, andrewg at andrewg.com said: > This sounds overly complicated. Once you have the extra socket visible > inside the container, it should be sufficient to set the environment > variable GPG_AGENT_SOCK. You don?t need to start an extra agent inside The envvar GPG_AGENT_INFO is not more supported since 2.1. I don't know how to best convey and share the socket using the file system. I have always used ssh features for this. Actually I am also using ssh to connect to other accounts on my box (autmates xauth handling :-). Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From benjamin.kircher at gmail.com Tue Jun 5 18:47:46 2018 From: benjamin.kircher at gmail.com (Benjamin Kircher) Date: Tue, 5 Jun 2018 18:47:46 +0200 Subject: Forward gpg-agent to container In-Reply-To: <87po1570dt.fsf@wheatstone.g10code.de> References: <84333D24-6E95-4A2C-BD6B-9EE2B10CC2E2@andrewg.com> <87po1570dt.fsf@wheatstone.g10code.de> Message-ID: <13B95B61-244A-4AA6-B5AE-865C420D8C9B@gmail.com> Hello Werner, > On 5. Jun 2018, at 16:50, Werner Koch wrote: > > The envvar GPG_AGENT_INFO is not more supported since 2.1. I saw that, too. Andrew was mentioning GPG_AGENT_SOCK, not GPG_AGENT_INFO however. > I don't know how to best convey and share the socket using the file > system. I have always used ssh features for this. Actually I am also > using ssh to connect to other accounts on my box (autmates xauth > handling :-). I see. I usually don?t have a SSH daemon running inside a container. BK From peter at digitalbrains.com Tue Jun 5 20:18:34 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 5 Jun 2018 20:18:34 +0200 Subject: Forward gpg-agent to container In-Reply-To: References: Message-ID: On 04/06/18 20:44, Benjamin Kircher wrote: > For this I create a bind mount of agent-extra-socket to /gpg-agent inside the container Have you tried by hand whether the concept of communicating over a socket to a container works at all? You could use socat to create a socket and communicate, one socat on your host system and one inside the container. I have no experience with it, but it wouldn't surprise me at all if you can't cross the container boundary given how local UNIX stream sockets are. Then again, maybe I'm dead wrong. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From al-gnupg_users at none.at Tue Jun 5 22:53:19 2018 From: al-gnupg_users at none.at (Aleksandar Lazic) Date: Tue, 5 Jun 2018 22:53:19 +0200 Subject: Forward gpg-agent to container In-Reply-To: References: <84333D24-6E95-4A2C-BD6B-9EE2B10CC2E2@andrewg.com> Message-ID: <20180605205319.GA8948@aleks-PC> Hi. On 05/06/2018 18:02, Benjamin Kircher wrote: > > >> On 5. Jun 2018, at 10:54, Benjamin Kircher wrote: >> >> >> >>> On 5. Jun 2018, at 08:56, Andrew Gallagher wrote: >>> >>>> >>>> On 4 Jun 2018, at 19:44, Benjamin Kircher wrote: >>>> >>>> Now inside the container I can see my socket >>>> >>>> # ls -l /gpg-agent >>>> srwx------ 1 root root 0 Jun 4 17:45 /gpg-agent >>>> >>>> From here on, I am kind of stuck. I fail to somehow make gpg-agent >>>> inside the container ?use? the extra-socket. Here is what I am >>>> doing: >>> >>> This sounds overly complicated. Once you have the extra socket >>> visible inside the container, it should be sufficient to set the >>> environment variable GPG_AGENT_SOCK. You don?t need to start an >>> extra agent inside the container. >> >> Andrew, thanks for looking into this. >> >> Is this documented somewhere? I can?t find this environment variable >> in the man-pages and a quick code search over gnupg, libassuan, >> gpgme, and friends shows no such environment variable. > >Sorry, but GPG_AGENT_SOCK doesn?t work at all. > > $ docker run --volume $(gpgconf --list-dirs agent-extra-socket):/gpg-agent --env GPG_AGENT_SOCK=/gpg-agent --entrypoint=sh -ti fedora:latest > > # env > HOSTNAME=26e366f60fc8 > PWD=/ > HOME=/root > FBR=f28 > DISTTAG=f28container > FGC=f28 > GPG_AGENT_SOCK=/gpg-agent > TERM=xterm > SHLVL=1 > PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin > _=/usr/bin/env > ># gpg2 --keyserver pgp.uni-mainz.de --recv 325F3B76 ># gpg2 --list-secret-keys Please can you try to run this from none /root dir. For example use the /tmp/gpg-dir and put all files there, just for testing. In the past I had some troubles to mount files in /root from `docker run ...` Do you have selinux in place? >BK BR Aleks From gnupg-users at spodhuis.org Tue Jun 5 23:17:10 2018 From: gnupg-users at spodhuis.org (Phil Pennock) Date: Tue, 5 Jun 2018 17:17:10 -0400 Subject: Forward gpg-agent to container In-Reply-To: References: Message-ID: <20180605211710.GA27486@breadbox.private.spodhuis.org> On 2018-06-05 at 20:18 +0200, Peter Lebbing wrote: > Have you tried by hand whether the concept of communicating over a > socket to a container works at all? You could use socat to create a > socket and communicate, one socat on your host system and one inside the > container. > > I have no experience with it, but it wouldn't surprise me at all if you > can't cross the container boundary given how local UNIX stream sockets > are. Then again, maybe I'm dead wrong. Bind volume mounts work on sockets, you just bind-mount the socket into the container. This is how you can have a Docker client inside a Docker container control the parent Docker setup. The issue to beware of is uids and the uid inside vs outside. $ docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock alpine / # apk update && apk add --no-cache docker [...] / # docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 86775493ab23 alpine "/bin/sh" 50 seconds ago Up 49 seconds boring_heyrovsky That worked because "root inside container"; I've custom images which are just careful with group permissions and can do the same thing when non-root inside the container, which is "unprivileged but with access to one socket". It should be easy enough to manage the same thing with GnuPG assuming that you're running Linux and so the Docker is local. When Docker is remote and you need to also get the socket available on that machine, it's a little more involved. For me, where I run macOS and use docker-machine, debugging this to write this email was ... educational. To forward: * Use `gpgconf --list-dir agent-ssh-socket` inside a container to see where the socket needs to end up for the build of GnuPG used by the OS userland inside that container. This will vary by OS. I'm using alpine below. * The biggest stumbling block is that OpenSSH daemon side doesn't unlink an existing socket by default, so you'll need to modify sshd_config inside the boot2docker environment first. * You'll need to be using a graphical pinentry program, for hopefully obvious reasons. `brew install pinentry-mac`. Prep: $ docker-machine ssh default $ vi /mnt/sda1/var/lib/boot2docker/ssh/sshd_config add: StreamLocalBindUnlink yes $ kill -1 $(cat /var/run/sshd.pid ) Shell 1: $ docker-machine ssh default -R /var/run/pdp.gnupg:$HOME/.gnupg/S.gpg-agent.extra [ leave this window open, this is your login on the VM; when this closes, you stop forwarding GnuPG's socket ] Shell 2: $ docker run -it --rm -v /var/run/pdp.gnupg:/root/.gnupg/S.gpg-agent.ssh alpine / # chmod 0700 /root/.gnupg && chown root:root /root/.gnupg/S.gpg-agent / # apk update && apk add --no-cache gnupg Shell 3: $ docker ps $ docker cp something-encrypted.asc thirsty_shaw:/tmp/foo.asc Shell 2 (docker container): / # gpg --list-packets From gnupg-users at spodhuis.org Wed Jun 6 02:27:11 2018 From: gnupg-users at spodhuis.org (Phil Pennock) Date: Tue, 5 Jun 2018 20:27:11 -0400 Subject: Forward gpg-agent to container In-Reply-To: <20180605211710.GA27486@breadbox.private.spodhuis.org> References: <20180605211710.GA27486@breadbox.private.spodhuis.org> Message-ID: <20180606002710.GA31129@breadbox.private.spodhuis.org> On 2018-06-05 at 17:17 -0400, Phil Pennock wrote: > Shell 2: > $ docker run -it --rm -v /var/run/pdp.gnupg:/root/.gnupg/S.gpg-agent.ssh alpine > / # chmod 0700 /root/.gnupg && chown root:root /root/.gnupg/S.gpg-agent > / # apk update && apk add --no-cache gnupg I apologise, I missed fixing one glitch in review before sending. The correct command to invoke Docker here is: docker run -it --rm -v /var/run/pdp.gnupg:/root/.gnupg/S.gpg-agent alpine Don't use the `.ssh` name, that speaks an entirely different protocol and was a mental glitch when I first wrote the above, fixed in testing but not repaired in the email. The command-line if you're running on Linux should thus be (untested): docker run -it --rm -v $HOME/.gnupg/S.gpg-agent.extra:/root/.gnupg/S.gpg-agent alpine Adjust as appropriate for other images. -Phil -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 996 bytes Desc: Digital signature URL: From patrick at enigmail.net Wed Jun 6 09:01:47 2018 From: patrick at enigmail.net (Patrick Brunschwig) Date: Wed, 6 Jun 2018 09:01:47 +0200 Subject: Invitation to the 4th OpenPGP Email Summit Message-ID: <1d5b7612-cf0e-d482-eeb8-5f4307aed91d@enigmail.net> I'm happy to announce the 4th OpenPGP Email Summit which will take place Saturday, October 20 until Sunday, October 21, 2018 in Brussles (Belgium). This is an event open for anybody involved in the development of email clients using OpenPGP for encryption, and related software. In 2015 and 2016 we already had tree OpenPGP Email Summits. These are meetings by technical experts of projects and tools dealing with OpenPGP with a focus on email encryption. The goals are to better get to know each other, and to discuss and work on several technical issues that hopefully improve certain aspects of OpenPGP-based email encryption. For details, see https://wiki.gnupg.org/OpenPGPEmailSummits REGISTRATION ============ If you want to attend, please *send an informal email* to: patrick at enigmail.net I will then let you know more details about the location, hotel, etc. If you need funding for your travel/hotel expenses, then please also get in contact with me. NOTES ===== This is a meeting of those who develop software. Thus, we will have a lot of tech talk about key servers, key exchange, subject encryption, password recovery, etc. If you just are interested in these topics as a user, you probably will be bored to death ;-). Thus, feel free to join us if you are working in the area of - TECHNICAL DETAILS - for SENDING or PROCESSING ENCRYPTED EMAILS - with OpenPGP - in a project or product. Note however, that due to capacity reasons we cannot have more than 1-2 people from each project. We can host about 30 attendees. Note that this is still neither a well-organized conference nor a commercial meeting. The agenda will be driven by the attendees. Anyone may propose any topic for discussion, as long as he/she is ready to lead the discussion. More details are/will be available on the web site: https://wiki.gnupg.org/OpenPGPEmailSummit201810 Looking forward to meet you in Brussels -Patrick -- Patrick Brunschwig mailto:patrick at enigmail.net PGP fingerprint: 4F9F 89F5 505A C1D1 A260 631C DB11 87B9 DD5F 693B -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed Jun 6 08:55:58 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 06 Jun 2018 08:55:58 +0200 Subject: end-of-life announcements (was: Breaking changes) In-Reply-To: (Dan Kegel's message of "Wed, 23 May 2018 04:56:46 -0700") References: <5B037595.2070607@signal100.com> <8a3c6066-e7ae-023c-9352-ebd2f3e908f5@monksofcool.net> <8FBA922FC32DF64382BB16C6D8A1A00B0445FD08BB@MASTER.hq.novosec.intern> <2ECE9D9EEF1F524185270138AE23265955B7C886@S0MSMAIL112.arc.local> Message-ID: <87sh605rpd.fsf_-_@wheatstone.g10code.de> On Wed, 23 May 2018 13:56, dank at kegel.com said: >> So when talking about EOL, gpg community should consider writing down a consistent EOL strategy, similar to those of Ubuntu, Linux kernel or others or something like I tried to argue for in the middle of https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060539.html > > Yes, exactly! We announce EOL early. Check the AUTHOR file of each package. For example Libgcrypt 1.7: Library: Libgcrypt [...] End-of-life: 2019-06-30 That was set with the last release (1.7.9) on 2017-08-27. Two years are pretty long given that even the new branches are ABI and API compatible. For GnuPG 2.2 the things are not that easy. We knew that we would need a longer transition period, thus despite that 2.1.0 would have been a development version, we urged people to start using 2.1 asap. This was due to the fact that many distributions still used the legacy 1.4 and not the stable 2.0. > To be kind to enterprise customers, GnuPG could pick one of > those two dates as the EOL for 1.4. Matching 16.04's EOL There is no EOL planned for 1.4 but 1.4 shall not be used except when you need compatiblity for the broken PGP 2 or you have a very exotic and ancient platform. But in the latter case you have all kind of other problems than to care about gpg versions. > Also, gnupg.org should add a web page like > https://www.gnupg.org/release-end-of-life Good idea. However, I think it is better to add it to the download page. Which I just did: Package Branch Birth End-of-life EOL ------------------------------------------------- GnuPG 1.0 1999-09-07 2002-09-07 yes 1.2 2002-09-21 2005-01-01 yes 1.4 2004-12-16 (1) 2.0 2006-11-11 2017-12-31 yes 2.2 2014-11-06 tba Libgcrypt 1.5 2011-06-29 2016-12-31 yes 1.6 2013-12-16 2017-06-30 yes 1.7 2016-04-15 2019-06-30 1.8 2017-07-18 tba tba: To be announced. (1): Legacy version; see remarks above. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Wed Jun 6 09:04:05 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 06 Jun 2018 09:04:05 +0200 Subject: Breaking changes In-Reply-To: <584ae73a-d6dd-e88e-3fbc-9e62ac0a8330@monksofcool.net> (Ralph Seichter's message of "Wed, 23 May 2018 15:45:04 +0200") References: <584ae73a-d6dd-e88e-3fbc-9e62ac0a8330@monksofcool.net> Message-ID: <87o9go5rbu.fsf@wheatstone.g10code.de> On Wed, 23 May 2018 15:45, m16+gnupg at monksofcool.net said: > 1. GPG is maintained by volunteers. If you have any complaint about how > this maintenance is progressing, get off your behind and be a volunteer That is fortunately not true. I work full time on GnuPG and related software, Gniibe is working at least half-time on it, Ben started to work half-time and Andre spends most of his paid time on Gpg4win and also GnuPG. This is possible due to our generous donors as well as from a few successful projects we did in the last 3 years. > 2. GPG 1.4 will not suddenly vanish if it is no longer maintained. > People can still use it like before. Maybe they shouldn't, but they can. Right; we keep it - it is important to have a way to decrypt old data. Some minor changes will be done over time but for example, mitigation's against side-channel attacks and such won't happen. It does not require a lot of resources. > What I percieve a lot in this thread are variations of "I wanna stay in > bed for five more minutes mommy". I wonder if Werner and Robert should :-) Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Wed Jun 6 10:04:59 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 06 Jun 2018 10:04:59 +0200 Subject: efail is imho only a html rendering bug In-Reply-To: <747ecd91b86c59750e7cca6c66de93c0@monkeyblade.net> (Robert J. Hansen's message of "Mon, 21 May 2018 13:11:16 -0400") References: <0FFC25A6-3B08-4B00-A14E-8C678D241391@glsys.de> <747ecd91b86c59750e7cca6c66de93c0@monkeyblade.net> Message-ID: <878t7s5oic.fsf@wheatstone.g10code.de> On Mon, 21 May 2018 19:11, rjh at sixdemonbag.org said: > Efail is not just an HTML rendering bug. It includes very real > attacks against S/MIME as it's used by thousands of corporations. I have not yet seen any hints on how a back-channel within the S/MIME protocol can work. There are claims that this can be done with CRLs and OCSP but that all requires substantial implementaion bugs in the S/MIME engines. The paper presents only vague ideas. Did I miss something? Note that when talking about S/MIME I actually mean the CMS/X.509 part and not the MIME part of it. For sure the same MIME parser bugs a few OpenPGP MUAs showed will also work with S/MIME - and even easier due to the missing intgerity protection at the crypto level. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Wed Jun 6 17:28:02 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 06 Jun 2018 17:28:02 +0200 Subject: doc patches: spelling errors In-Reply-To: <20180520021058.GA24210@x2.esmtp.org> (Claus Assmann's message of "Sat, 19 May 2018 19:10:58 -0700") References: <20180520021058.GA24210@x2.esmtp.org> Message-ID: <87vaaw2av1.fsf@wheatstone.g10code.de> Hi! Thanks for the fixes. I applied them to master and 2.2 > +++ gnupg.info-1 Sat May 19 19:02:04 2018 Noet that this is a generated file. The source is one of the *texi files. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From tomli at tomli.me Wed Jun 6 17:49:07 2018 From: tomli at tomli.me (tomli at tomli.me) Date: Wed, 6 Jun 2018 23:49:07 +0800 Subject: [NIIBE Yutaka] STM32F103 flash ROM read-out service In-Reply-To: <87vaawslfg.fsf@iwagami.gniibe.org> References: <87vaawslfg.fsf@iwagami.gniibe.org> Message-ID: <20180606154907.GA73725@x220> > While learning Chinese language, I found this service (in Chinese): > > http://www.pcbcopy.com/2016/ic_1128/1928.html > > IIUC, It's a company in ShenZhen, which offers a service reading out > from protected STM32F103, even if it uses anti-tamper feature with a > battery. > > I was aware of similar services for PIC18 or ATmega (in different > country). This is new for me, specifically for STM32F103. > > I don't know the detail of this service, but it seems that it's not that > expensive (from not-confirmed information by my friend). ----- These services have came into existence as early as 2012. It is a main way used to create cheap clones by rogue competitors of products on the existing market. It's commonly believed STM32F1 is easy to crack, both through physical IC decapping, or by mounting a fault injection attack to disable the flash readout protection, or exploting the bootloader, who knows... You can search the keywords "STM32F1 ??" (STM32F1 Crack) in Chinese and you'll find many advertisements and victims of copycat complaining in EE forums. While GD32 seems to include more countermeasures in the chip, relatively obscure and have a higher cost of attack, I can only find one company or two cracking GD32, compared to lots of companies for STM32. BTW, BasicCard and JavaCard seemed even more obscure and I cannot find any public service of cracking. See: [1] http://blog.sina.com.cn/s/blog_770bd2000100zssn.html [2] http://www.stmcu.org/module/forum/thread-608097-1-6.html [3] http://www.pcbhf.com/xinpianjiemi/icxinghaopanding/320.html [4] https://blog.csdn.net/sinat_36568888/article/details/52984056 ----- Common countermeasures in the industry vaires, including... 1. Use high voltage to destroy most I/O pins to render most inputs useless, creating a smaller attack surface. 2. Hardcode chip UUID, using "security through obscurity" to refuse program execution if a unknown ID has been detected. 3. Use proprietary secure chips that come with NDAs. But it does not solve any real problem in the perspective of cryptography. They are all "security through obscurity" at best, just driving out script kiddies (or equipment kiddies?) at worst. As I have said in the gnuk-users list, the only way to solve this problem is using something like a secure chip, a TPM, or a cryptography coprocessor. It is very important, but the free software community never trusted these devices, because they can be used to carry out "trusted computing" vendor lock-in, implement DRM, implant backdoors, etc. My point is, if these hardware is instructed exclusively by Free Software, the ultimate master of these devices are their users, and none of these will be a problem. So, we need to find a security chip that comes with OPEN, PUBLIC specs, so we can develop free software for it. ----- In the beginning of this year, I have done some researches for this project, I've found... Thanks to the emergence of the "Internet-of-Trash", security of embedded devices have became a real demand, so many manufacturers now have simple security chips that do not require any NDA nor subject to any cryptographic regulations, yet, they are basic versions of secure chips that can seal keys. They may not as temper-proof as a proprietary ST31 chip, but is a huge improvement compared to generic microcontrollers. Now I have plans to experiment with the ATECC508A chip by Atmel, if I have time. It looks like a simple security chip with full specs, and suitable to be used with Gnuk. The datasheet is interesting, see [5] http://ww1.microchip.com/downloads/en/DeviceDoc/20005927A.pdf Also, the TPM chips found on x86 systems are really underestimated by the Free Software community, since it's a mass-produced commodity chip with full spec available. ----- To prevent the chip becoming a single point of failure, we can implement "split-secret" or "double-encryption" scheme. This allows us to use the security chip in a trustless manner - a offline attacker needs to break both STM32F1 and the security chip, before getting access to the key material. No matter what have happened to the chip, the key is still as secure as the original STM32F1 + KDF-DO. For example, if a security chip allows us to encrypt and decrypt data with its internal key, but only after a correct PIN code is provided, a simple scheme can be: 1. Enter PIN 2. PIN = KDF(PIN) 3. K1 = HMAC-256(PIN, sqrt_2) 4. K2 = KMAC-256(PIN, sqrt_3) So K1 and K2 is now two independent keys. It's just an example for simplicity, a secure system should use standard, proven cryptography, like the "Expand" stage of the "Extract-and-Expand" KDF specified in RFC5869. [6] https://tools.ietf.org/html/rfc5869 5. (chip) Reset chip 6. (chip) Set security chip PIN to K2 7. (chip) Generate a new secret key on chip When storing our secret, 8. Encrypt key material with K1 on STM32, output known as C1 9. Encrypt key material with K2 on chip, output known as C2 10. Save C2 to STM32 ROM. Reverse this process for decryption. Essentially, we encrypt our data twice, first by ourselves on STM32, then by the chip with its internal key. The two keys are both derived from the User PIN on-the-fly during runtime, cryptographically independent of each other. As soon as power is removed, the attacker is forced to break the security chip, the STM32 chip, and our original encryption, three times in a row. ----- > Well, I encourage Gnuk users to new use KDF-DO feature with newer GnuPG. Yes, KDF-DO should be an essential protection. A six-word diceware passphrase is also recommended. All to be said, we don't really know if the "STM32 Cracking" service really works. Perhaps we can launch a funding campaign to accept donations, and find one company to actually pay them to attack our existing Gnuk systems, and see if they can recover the encrypted data from ROM. Happy Hacking, Tom Li Beijing GNU/Linux User Group. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 851 bytes Desc: Digital signature URL: From ndk.clanbo at gmail.com Wed Jun 6 18:56:29 2018 From: ndk.clanbo at gmail.com (NdK) Date: Wed, 6 Jun 2018 18:56:29 +0200 Subject: [NIIBE Yutaka] STM32F103 flash ROM read-out service In-Reply-To: <20180606154907.GA73725@x220> References: <87vaawslfg.fsf@iwagami.gniibe.org> <20180606154907.GA73725@x220> Message-ID: <3f347da5-13c6-da21-0b44-3c2801fde5cd@gmail.com> Il 06/06/2018 17:49, Tom Li via Gnuk-users ha scritto: > BTW, BasicCard and JavaCard seemed even more obscure and I cannot find > any public service of cracking. Because those are (at least should be) based on secure chips. > But it does not solve any real problem in the perspective of cryptography. > They are all "security through obscurity" at best, just driving out script > kiddies (or equipment kiddies?) at worst. The only secure (even against decapping attacks) device I know of is a very old parallel-port "key" a friend described me ~25y ago. It was made of 3 silicon layers: the outer ones only contained interface circuits and 'randomness' while the keys and the logic were in the central layer. Trying to remove the outer layers destroyed the random patterns that were used as 'internal master key', rendering the rest completely useless. IIRC some recent chips reused (partially) that idea, rebranded under "Physically Unclonable" something. Yep... Found: https://community.cadence.com/cadence_blogs_8/b/breakfast-bytes/posts/secret-key-generation-with-physically-unclonable-functions (but looking for "physically unclonable chip" returns lots of results). Those chips work on the same principle: decapping alters the silicon layers and the 'random id' changes before the attacker have a chance to read it. > As I have said in the gnuk-users list, the only way to solve this problem > is using something like a secure chip, a TPM, or a cryptography coprocessor. > It is very important, but the free software community never trusted these > devices, because they can be used to carry out "trusted computing" vendor > lock-in, implement DRM, implant backdoors, etc. Then we should all use RISC-V chips :) > Now I have plans to experiment with the ATECC508A chip by Atmel, if I have time. > It looks like a simple security chip with full specs, and suitable to be used with > Gnuk. The datasheet is interesting, see > [5] http://ww1.microchip.com/downloads/en/DeviceDoc/20005927A.pdf Too bad neither ETECC508A nor ATECC608A support curve25519 :( Only some NIST ones. > Also, the TPM chips found on x86 systems are really underestimated by the > Free Software community, since it's a mass-produced commodity chip with full > spec available. Well, at least some TPM 1.2 chips have already been cracked. > To prevent the chip becoming a single point of failure, we can implement > "split-secret" or "double-encryption" scheme. This allows us to use the security > chip in a trustless manner - a offline attacker needs to break both STM32F1 > and the security chip, before getting access to the key material. No matter > what have happened to the chip, the key is still as secure as the original > STM32F1 + KDF-DO. Yes, but you risk having very long delays, that could even be unacceptable. Unless there's a way to parallelize the operations (say 'do more KDF iterations while the chip is decoding'). > All to be said, we don't really know if the "STM32 Cracking" service really > works. Perhaps we can launch a funding campaign to accept donations, and > find one company to actually pay them to attack our existing Gnuk systems, > and see if they can recover the encrypted data from ROM. I'd bet it works as described in the offers. BYtE, Diego From schinzel at fh-muenster.de Wed Jun 6 17:11:54 2018 From: schinzel at fh-muenster.de (Sebastian Schinzel) Date: Wed, 6 Jun 2018 17:11:54 +0200 Subject: efail is imho only a html rendering bug In-Reply-To: <878t7s5oic.fsf@wheatstone.g10code.de> References: <0FFC25A6-3B08-4B00-A14E-8C678D241391@glsys.de> <747ecd91b86c59750e7cca6c66de93c0@monkeyblade.net> <878t7s5oic.fsf@wheatstone.g10code.de> Message-ID: Am 06.06.2018 um 10:04 schrieb Werner Koch: > On Mon, 21 May 2018 19:11, rjh at sixdemonbag.org said: > >> Efail is not just an HTML rendering bug. It includes very real >> attacks against S/MIME as it's used by thousands of corporations. > > I have not yet seen any hints on how a back-channel within the S/MIME > protocol can work. There are claims that this can be done with CRLs and > OCSP but that all requires substantial implementaion bugs in the S/MIME > engines. The paper presents only vague ideas. Did I miss something? A backchannel in a technology is not a vulnerability per se. At its core, the Efail CBC/CFB gadget attack modifies a ciphertext in a way that it *exfiltrates its own plaintext* when opened. The paper shows that this is practical for HTML email clients. The generic concept of the CBC/CFB gadget attack, however, is neither limited to HTML, nor to emails. It is plausible to transform the attack to other data formats supporting backchannels. It's up to the creativity of the attacker to come up with other scenarios. Adam Langley touched another scenario already in 2014: https://www.imperialviolet.org/2014/06/27/streamingencryption.html The central flaws for CBC/CFB gadgets to work are (a) missing authenticated encryption in S/MIME and (b) not properly enforced integrity protection in OpenPGP. We won't fix malleable encryption by tinkering with HTML, x509 and MIME parsers. Best, Sebastian From tomli at tomli.me Wed Jun 6 18:10:11 2018 From: tomli at tomli.me (tomli at tomli.me) Date: Thu, 7 Jun 2018 00:10:11 +0800 Subject: STM32F103 flash ROM read-out service Message-ID: <20180606161011.GA83743@x220> Relevant discussion is moved to [gnuk-users], but in case someone has seen the first mail in [gnupg-users] but missed other mails, I've reposted the mail, sorry for the double post. Follow-up discussion should be sent to [gnuk-users]. ----- > While learning Chinese language, I found this service (in Chinese): > > http://www.pcbcopy.com/2016/ic_1128/1928.html > > IIUC, It's a company in ShenZhen, which offers a service reading out > from protected STM32F103, even if it uses anti-tamper feature with a > battery. > > I was aware of similar services for PIC18 or ATmega (in different > country). This is new for me, specifically for STM32F103. > > I don't know the detail of this service, but it seems that it's not that > expensive (from not-confirmed information by my friend). ----- These services have came into existence as early as 2012. It is a main way used to create cheap clones by rogue competitors of products on the existing market. It's commonly believed STM32F1 is easy to crack, both through physical IC decapping, or by mounting a fault injection attack to disable the flash readout protection, or exploting the bootloader, who knows... You can search the keywords "STM32F1 ??" (STM32F1 Crack) in Chinese and you'll find many advertisements and victims of copycat complaining in EE forums. While GD32 seems to include more countermeasures in the chip, relatively obscure and have a higher cost of attack, I can only find one company or two cracking GD32, compared to lots of companies for STM32. BTW, BasicCard and JavaCard seemed even more obscure and I cannot find any public service of cracking. See: [1] http://blog.sina.com.cn/s/blog_770bd2000100zssn.html [2] http://www.stmcu.org/module/forum/thread-608097-1-6.html [3] http://www.pcbhf.com/xinpianjiemi/icxinghaopanding/320.html [4] https://blog.csdn.net/sinat_36568888/article/details/52984056 ----- Common countermeasures in the industry vaires, including... 1. Use high voltage to destroy most I/O pins to render most inputs useless, creating a smaller attack surface. 2. Hardcode chip UUID, using "security through obscurity" to refuse program execution if a unknown ID has been detected. 3. Use proprietary secure chips that come with NDAs. But it does not solve any real problem in the perspective of cryptography. They are all "security through obscurity" at best, just driving out script kiddies (or equipment kiddies?) at worst. As I have said in the gnuk-users list, the only way to solve this problem is using something like a secure chip, a TPM, or a cryptography coprocessor. It is very important, but the free software community never trusted these devices, because they can be used to carry out "trusted computing" vendor lock-in, implement DRM, implant backdoors, etc. My point is, if these hardware is instructed exclusively by Free Software, the ultimate master of these devices are their users, and none of these will be a problem. So, we need to find a security chip that comes with OPEN, PUBLIC specs, so we can develop free software for it. ----- In the beginning of this year, I have done some researches for this project, I've found... Thanks to the emergence of the "Internet-of-Trash", security of embedded devices have became a real demand, so many manufacturers now have simple security chips that do not require any NDA nor subject to any cryptographic regulations, yet, they are basic versions of secure chips that can seal keys. They may not as temper-proof as a proprietary ST31 chip, but is a huge improvement compared to generic microcontrollers. Now I have plans to experiment with the ATECC508A chip by Atmel, if I have time. It looks like a simple security chip with full specs, and suitable to be used with Gnuk. The datasheet is interesting, see [5] http://ww1.microchip.com/downloads/en/DeviceDoc/20005927A.pdf Also, the TPM chips found on x86 systems are really underestimated by the Free Software community, since it's a mass-produced commodity chip with full spec available. ----- To prevent the chip becoming a single point of failure, we can implement "split-secret" or "double-encryption" scheme. This allows us to use the security chip in a trustless manner - a offline attacker needs to break both STM32F1 and the security chip, before getting access to the key material. No matter what have happened to the chip, the key is still as secure as the original STM32F1 + KDF-DO. For example, if a security chip allows us to encrypt and decrypt data with its internal key, but only after a correct PIN code is provided, a simple scheme can be: 1. Enter PIN 2. PIN = KDF(PIN) 3. K1 = HMAC-256(PIN, sqrt_2) 4. K2 = KMAC-256(PIN, sqrt_3) So K1 and K2 is now two independent keys. It's just an example for simplicity, a secure system should use standard, proven cryptography, like the "Expand" stage of the "Extract-and-Expand" KDF specified in RFC5869. [6] https://tools.ietf.org/html/rfc5869 5. (chip) Reset chip 6. (chip) Set security chip PIN to K2 7. (chip) Generate a new secret key on chip When storing our secret, 8. Encrypt key material with K1 on STM32, output known as C1 9. Encrypt key material with K2 on chip, output known as C2 10. Save C2 to STM32 ROM. Reverse this process for decryption. Essentially, we encrypt our data twice, first by ourselves on STM32, then by the chip with its internal key. The two keys are both derived from the User PIN on-the-fly during runtime, cryptographically independent of each other. As soon as power is removed, the attacker is forced to break the security chip, the STM32 chip, and our original encryption, three times in a row. ----- > Well, I encourage Gnuk users to new use KDF-DO feature with newer GnuPG. Yes, KDF-DO should be an essential protection. A six-word diceware passphrase is also recommended. All to be said, we don't really know if the "STM32 Cracking" service really works. Perhaps we can launch a funding campaign to accept donations, and find one company to actually pay them to attack our existing Gnuk systems, and see if they can recover the encrypted data from ROM. Happy Hacking, Tom Li Beijing GNU/Linux User Group. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 851 bytes Desc: Digital signature URL: From wk at gnupg.org Wed Jun 6 20:19:26 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 06 Jun 2018 20:19:26 +0200 Subject: efail is imho only a html rendering bug In-Reply-To: (Sebastian Schinzel's message of "Wed, 6 Jun 2018 17:11:54 +0200") References: <0FFC25A6-3B08-4B00-A14E-8C678D241391@glsys.de> <747ecd91b86c59750e7cca6c66de93c0@monkeyblade.net> <878t7s5oic.fsf@wheatstone.g10code.de> Message-ID: <87lgbr3hht.fsf@wheatstone.g10code.de> Hi! Thanks for responding. However, my question was related to the claims in the paper about using CRL and OCSP as back channels. This created the impression that, for example, the certificates included in an encrypted CMS object could be modified in a way that, say, the DP could be change in the same was a a HTML img tag or to confuse the MIME parser. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From pkk at spth.de Wed Jun 6 21:50:41 2018 From: pkk at spth.de (Philipp Klaus Krause) Date: Wed, 6 Jun 2018 21:50:41 +0200 Subject: STM32F103 flash ROM read-out service In-Reply-To: <87o9gqf4qo.fsf@iwagami.gniibe.org> References: <87o9gqf4qo.fsf@iwagami.gniibe.org> Message-ID: <96ac7533-3bd1-1db3-6af9-ba66971469e6@spth.de> Am 05.06.2018 um 02:37 schrieb NIIBE Yutaka: > Hello, > > While learning Chinese language, I found this service (in Chinese): > > http://www.pcbcopy.com/2016/ic_1128/1928.html > > IIUC, It's a company in ShenZhen, which offers a service reading out > from protected STM32F103, even if it uses anti-tamper feature with a > battery. > > I was aware of similar services for PIC18 or ATmega (in different > country). This is new for me, specifically for STM32F103. > > I don't know the detail of this service, but it seems that it's not that > expensive (from not-confirmed information by my friend). > > Well, I encourage Gnuk users to new use KDF-DO feature with newer GnuPG. > See https://www.aisec.fraunhofer.de/en/FirmwareProtection.html for some research on breaking STM32 readout protection published in January. Philipp -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From dgouttegattat at incenp.org Thu Jun 7 00:08:09 2018 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Wed, 6 Jun 2018 23:08:09 +0100 Subject: STM32F103 flash ROM read-out service In-Reply-To: <96ac7533-3bd1-1db3-6af9-ba66971469e6@spth.de> References: <87o9gqf4qo.fsf@iwagami.gniibe.org> <96ac7533-3bd1-1db3-6af9-ba66971469e6@spth.de> Message-ID: <2a0155cd-8c78-32c5-5e49-f23f802a7c5c@incenp.org> On 06/06/2018 08:50 PM, Philipp Klaus Krause wrote: > See https://www.aisec.fraunhofer.de/en/FirmwareProtection.html for > some research on breaking STM32 readout protection published in > January. For what it's worth, STMicroelectronics claims that the attack described in this paper "affects only the STM32F0 and is not successful in all other series" [1]. Whether you believe them or not is up to you. Of note, the authors of that paper themselves do not claim the attack works on anything else than the STM32F0. (But of course, just because *this* attack (presumably) does not work on the STM32F103, it does not mean that nobody can ever come up with a successful attack on that chip...) Damien [1] https://community.st.com/thread/46432-hacking-readout-protection-on-stm32#comment-181542 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From gnupg at leo.gaspard.ninja Thu Jun 7 02:01:34 2018 From: gnupg at leo.gaspard.ninja (Leo Gaspard) Date: Thu, 7 Jun 2018 02:01:34 +0200 Subject: [NIIBE Yutaka] STM32F103 flash ROM read-out service In-Reply-To: <3f347da5-13c6-da21-0b44-3c2801fde5cd@gmail.com> References: <87vaawslfg.fsf@iwagami.gniibe.org> <20180606154907.GA73725@x220> <3f347da5-13c6-da21-0b44-3c2801fde5cd@gmail.com> Message-ID: <93d6affa-e113-1ccc-3d76-bdd1358962dc@leo.gaspard.ninja> On 06/06/2018 06:56 PM, NdK wrote: > Il 06/06/2018 17:49, Tom Li via Gnuk-users ha scritto: > >> BTW, BasicCard and JavaCard seemed even more obscure and I cannot find >> any public service of cracking. > Because those are (at least should be) based on secure chips. > >> But it does not solve any real problem in the perspective of cryptography. >> They are all "security through obscurity" at best, just driving out script >> kiddies (or equipment kiddies?) at worst. > The only secure (even against decapping attacks) device I know of is a > very old parallel-port "key" a friend described me ~25y ago. > It was made of 3 silicon layers: the outer ones only contained interface > circuits and 'randomness' while the keys and the logic were in the > central layer. Trying to remove the outer layers destroyed the random > patterns that were used as 'internal master key', rendering the rest > completely useless. Some people do reverse-engineering based on photons emitted by transistors switching. These would get through this shielding. Unfortunately, I can't find again the link to the conference talk where I heard people explaining they did that? sorry. Another kind of attack would be EM pulses / lasers for error-ing a crypto computation, that would get through this shielding too. There are defenses against these attacks (well, for the transistors-emitting-photons attack I'm not really sure), that are deployed in secure elements. Attacks like this are tested by CC/EAL evaluation laboratories. All that to say: hardware security, to me, is a way to increase the cost of the attacker to perform an attack. All devices are eventually vulnerable, given the right price, the point is to make attack more costly than the benefit from breaking the card and/or than finding a way around the card. (I'm not going to extend this point to software security, but I'd think it most likely holds there too) Oh, and also to say: choosing between a non-secure-element open-source token and a secure-element NDA-ed-and-thus-non-open-source token is not an obvious choice. HTH, Leo From oub at mat.ucm.es Thu Jun 7 10:48:14 2018 From: oub at mat.ucm.es (Uwe Brauer) Date: Thu, 07 Jun 2018 10:48:14 +0200 Subject: gpgsm 2 valid certificates Message-ID: <87po137zjl.fsf@mat.ucm.es> Hi I now posses 2 valid X509 certifcates for the same email address. In thunderbird I can import them both and select which I want to use. I hesitate to import the second one to gpgsm since it is not clear to me which will then be chosen by gnus/emacs/epa. I will also ask in the emacs mailing list Thanks Uwe Brauer From dirk.gottschalk1980 at googlemail.com Thu Jun 7 11:06:27 2018 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Thu, 07 Jun 2018 11:06:27 +0200 Subject: gpgsm 2 valid certificates In-Reply-To: <87po137zjl.fsf@mat.ucm.es> References: <87po137zjl.fsf@mat.ucm.es> Message-ID: <77E563FF-3ADC-4DA1-B032-3B0979BC99ED@googlemail.com> You can set a default certificate in gpgsm.conf,which will be used, when no cert is specified by the calling Software. Thunderbird should ask you, at least once, which Cert should be used, I think. Am 7. Juni 2018 10:48:14 MESZ schrieb Uwe Brauer : >Hi > >I now posses 2 valid X509 certifcates for the same email address. In >thunderbird I can import them both and select which I want to use. > >I hesitate to import the second one to gpgsm since it is not clear to >me >which will then be chosen by gnus/emacs/epa. > >I will also ask in the emacs mailing list > >Thanks > >Uwe Brauer > >_______________________________________________ >Gnupg-users mailing list >Gnupg-users at gnupg.org >http://lists.gnupg.org/mailman/listinfo/gnupg-users -- Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 902 bytes Desc: not available URL: From matthew561 at aol.com Thu Jun 7 12:31:16 2018 From: matthew561 at aol.com (Mark Drew) Date: Thu, 7 Jun 2018 01:31:16 -0900 Subject: No subject Message-ID: <1528367484.QsCPfyHJtGxmdQsCSfDhc3@mf-smf-ucb029c3> http://score.sacredpath4vitality.com Mark Drew -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndk.clanbo at gmail.com Thu Jun 7 14:16:22 2018 From: ndk.clanbo at gmail.com (NdK) Date: Thu, 7 Jun 2018 14:16:22 +0200 Subject: [NIIBE Yutaka] STM32F103 flash ROM read-out service In-Reply-To: <93d6affa-e113-1ccc-3d76-bdd1358962dc@leo.gaspard.ninja> References: <87vaawslfg.fsf@iwagami.gniibe.org> <20180606154907.GA73725@x220> <3f347da5-13c6-da21-0b44-3c2801fde5cd@gmail.com> <93d6affa-e113-1ccc-3d76-bdd1358962dc@leo.gaspard.ninja> Message-ID: Il 07/06/2018 02:01, Leo Gaspard via Gnupg-users ha scritto: >> The only secure (even against decapping attacks) device I know of is a >> very old parallel-port "key" a friend described me ~25y ago. >> It was made of 3 silicon layers: the outer ones only contained interface >> circuits and 'randomness' while the keys and the logic were in the >> central layer. Trying to remove the outer layers destroyed the random >> patterns that were used as 'internal master key', rendering the rest >> completely useless. > Some people do reverse-engineering based on photons emitted by > transistors switching. These would get through this shielding. > Unfortunately, I can't find again the link to the conference talk where > I heard people explaining they did that? sorry. I think I've seen it. But IIRC it does not work with such a big slice (whole depth of the silicon slice, ~200micron IIRC). But now that you made me think about it, I remember I've seen another article where the attack was carried out from "behind" the chip. > Another kind of attack would be EM pulses / lasers for error-ing a > crypto computation, that would get through this shielding too. Fault-injection. But for cheap chips it's probably way easier to "just" use FIB (or a laser) to change the state of the protection fluses (usually just normal flash cells) then read the whole contents. > There are defenses against these attacks (well, for the > transistors-emitting-photons attack I'm not really sure), that are > deployed in secure elements. Attacks like this are tested by CC/EAL > evaluation laboratories. Hope so :) But I stay cautious when trusting certification. See the ROCA vulnerability in Infineon "secure" (smartcard) chips. > All that to say: hardware security, to me, is a way to increase the cost > of the attacker to perform an attack. All devices are eventually > vulnerable, given the right price, the point is to make attack more > costly than the benefit from breaking the card and/or than finding a way > around the card. (I'm not going to extend this point to software > security, but I'd think it most likely holds there too) Then, instead of "this chip is secure" they should just say "this chip can be cracked spending X in equipement (una tantum) and Y for every chip"... Marketing would never allow that :) > Oh, and also to say: choosing between a non-secure-element open-source > token and a secure-element NDA-ed-and-thus-non-open-source token is not > an obvious choice. As always it depends on the attack scenario. GnuK IIUC targets all those users who think a targeted attack is quite improbable or that rubber-hose cryptanalysis is end of game. If I know that extracting my key from the token costs $500, then I can choose what to do. But with a non-secure and open chip it's easier to estimate that cost (being easier and cheaper, it's more probable it gets used in universities by security students for their first attacks, usually the most fantasious ones). Quite surely it will be lower than the cost of attacking a secure chip, but probably by not that much. BYtE, Diego From calestyo at scientia.net Thu Jun 7 14:50:43 2018 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Thu, 07 Jun 2018 14:50:43 +0200 Subject: better passphrase hashing with gnupg? Message-ID: <0c8892b8b58d35000ceda9c9998809ba4798f303.camel@scientia.net> Hey. I have the following scenario: I'd like to archive private data to e.g. some cloud storage for backup reasons. Basically I'd see two ways to move on from here: 1) Put the data in on or more disk images which are encrypted with dm- crypt/LUKS (e.g. using aes-xts-plain64) 2) Put the data in one or more tar or dar archive files, which I think is a bit more flexible. With (2) I'd guess gnupg would be the tool of choice (or is there anything else well-maintained?) and using e.g. AES256 should provide adequate security. In both cases, I'd want to put the actual key alongside the archive (i.e. also backing it up the the remote storage, as I'd be screwed it I loose the key when I just store it locally). For both (LUKS/OpenPGP), the actual symmetric key is anyway alongside the image/archive encrypted by some passphrase (respectively the pubkey, in case of asymmetric encryption with gpg). Now here's the question/problem: - LUKS/cryptsetup, at least in it's more recent version already support Argon2 and even for the older version there was a noticeable effect when increasing the hashing iterations (like taking several minutes for cryptsetup to actually "open" the device). For gpg there is --s2k-* especially --s2k-count, but even when setting this to the max value of 65011712... passphrase hashing seems super fast. I'd be totally happy if a single passphrase try (for an attacker) takes like 10 minutes (just to be on the safe side)... but that doesn't seem possible with OpenPGP/gpg right now? What would you guys suggest in my scenario? Is there a way to chain Argon2 with current gpg versions (not having to wait until this gets integrated in a new RFC in some future)? Thanks, Chris. From przeklasa9 at gmail.com Thu Jun 7 15:49:40 2018 From: przeklasa9 at gmail.com (Piotr Przeklasa) Date: Thu, 7 Jun 2018 15:49:40 +0200 Subject: How in Windows batch script generate Unattended key? option --batch Message-ID: How in Windows batch script generate Unattended key? option --batch Please help me From schinzel at fh-muenster.de Thu Jun 7 17:36:53 2018 From: schinzel at fh-muenster.de (Sebastian Schinzel) Date: Thu, 7 Jun 2018 17:36:53 +0200 Subject: Backchannels via OCSP and CRL in S/MIME (Was: efail is imho only a html rendering bug) In-Reply-To: <87lgbr3hht.fsf@wheatstone.g10code.de> References: <0FFC25A6-3B08-4B00-A14E-8C678D241391@glsys.de> <747ecd91b86c59750e7cca6c66de93c0@monkeyblade.net> <878t7s5oic.fsf@wheatstone.g10code.de> <87lgbr3hht.fsf@wheatstone.g10code.de> Message-ID: Am 06.06.2018 um 20:19 schrieb Werner Koch: > Thanks for responding. However, my question was related to the claims > in the paper about using CRL and OCSP as back channels. This created the > impression that, for example, the certificates included in an encrypted > CMS object could be modified in a way that, say, the DP could be change > in the same was a a HTML img tag or to confuse the MIME parser. Table 5 shows that CRL and OCSP work as a backchannel in some clients, see I_1, I_2, I_3 in the PKI column. It is unclear if they can be used to exfiltrate plaintext in reality because changing them should break the signature. The caIssuer field (intermediate certificates) seems more appropriate for plaintext exfiltration. See the discussion in section 6.2. Note that we didn't analyze X.509v3 extensions for further backchannels. Again, whether CRL/OCSP/caIssuer can or cannot be used for plaintext exfiltration doesn't affect the overall security of S/MIME much. The central flaw remains malleable encryption. Best, Sebastian From aheinecke at intevation.de Thu Jun 7 18:10:32 2018 From: aheinecke at intevation.de (Andre Heinecke) Date: Thu, 07 Jun 2018 18:10:32 +0200 Subject: How in Windows batch script generate Unattended key? option --batch In-Reply-To: References: Message-ID: <76423644.uF6TITVWnU@esus> Hi, On Thursday 7 June 2018 15:49:40 CEST Piotr Przeklasa wrote: > How in Windows batch script generate Unattended key? option --batch The new "quick-gen-key" command is more conveniant then the old batch gen key mechanism. E.g. to create a key without passphrase for "foo at bar.baz" you can run: gpg --yes --pinentry-mode loopback --passphrase '' --quick-gen-key foo at bar.baz Best Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- 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 andrew at fsf.org Thu Jun 7 18:22:42 2018 From: andrew at fsf.org (Andrew Engelbrecht) Date: Thu, 7 Jun 2018 12:22:42 -0400 Subject: EFAIL countermeasure recommendations on your site Message-ID: <681bc5c0-41c1-5d6a-b24f-d766c7522857@fsf.org> Hello GNUPG mailing list, Would it be possible for you to make recommendations about how to respond to the EFAIL vulnerability on your site? I see that you link to emailselfdefense.org, which encourages users to use the latest version of enigmail. However I see that there are mentions of enigmail here: https://www.gnupg.org/software/swlist.html https://www.gnupg.org/howtos/en/GPGMiniHowto-6.html https://www.gnupg.org/faq/gnupg-faq.html https://www.gnupg.org/faq/gnupg-faq.txt https://wiki.gnupg.org/EMailClients https://wiki.gnupg.org/E-Mail%20Format%20Preferences Would you please consider adding comments about using the latest version on these pages, for the sake of user security? Thanks, :) Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From ben at adversary.org Fri Jun 8 01:26:26 2018 From: ben at adversary.org (Ben McGinnes) Date: Fri, 8 Jun 2018 09:26:26 +1000 Subject: Forward gpg-agent to container In-Reply-To: <20180605211710.GA27486@breadbox.private.spodhuis.org> References: <20180605211710.GA27486@breadbox.private.spodhuis.org> Message-ID: <20180607232626.hex22m5gy7gdenfb@adversary.org> On Tue, Jun 05, 2018 at 05:17:10PM -0400, Phil Pennock wrote: > > Shell 1: > $ docker-machine ssh default -R /var/run/pdp.gnupg:$HOME/.gnupg/S.gpg-agent.extra > [ leave this window open, this is your login on the VM; when this > closes, you stop forwarding GnuPG's socket ] A suggestion: for those parts of this which need to be kept open, like this one, I recommend using autossh in place of ssh. That way even if the link is flakey and drops out, it'll reconnect for you. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From mangocats at gmail.com Fri Jun 8 06:36:38 2018 From: mangocats at gmail.com (Mike Inman) Date: Fri, 8 Jun 2018 00:36:38 -0400 Subject: gpgme_key_t or gpgme_op_export_keys keydata to gcry_sexp_t Message-ID: Hi, I'm trying to work with gpgme to manage public/private key pairs on a keyring, but also use these keys with libgcrypt for signing, verifying signatures, etc. without interacting with gpg or the keyring... I've found and used the functions like: https://www.gnupg.org/documentation/manuals/gpgme/Listing-Keys.html#Listing-Keys and https://www.gnupg.org/documentation/manuals/gpgme/Exporting-Keys.html#Exporting-Keys, and I see in libgcrypt what it's expecting: https://www.gnupg.org/documentation/manuals/gcrypt/Cryptographic-Functions.html but I don't feel like I have enough information to make a bridge between the two. For instance, when I create an ECDSA key with the brainpoolP256r1 curve, then I gpgme_op_export() that key in GPGME_EXPORT_MODE_MINIMAL mode, I get 413 bytes in the keydata - is the X9.62 encoded key in there anywhere? If so, how can I reliably get it out? Thanks, -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Fri Jun 8 10:15:08 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 8 Jun 2018 04:15:08 -0400 Subject: EFAIL countermeasure recommendations on your site In-Reply-To: <681bc5c0-41c1-5d6a-b24f-d766c7522857@fsf.org> References: <681bc5c0-41c1-5d6a-b24f-d766c7522857@fsf.org> Message-ID: <1a500ab1-f715-afeb-1137-dd318258623a@sixdemonbag.org> > Would it be possible for you to make recommendations about how to > respond to the EFAIL vulnerability on your site? This is the sort of thing better addressed to email plugin authors. Efail had very limited applicability to GnuPG itself. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 821 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Fri Jun 8 15:40:55 2018 From: wk at gnupg.org (Werner Koch) Date: Fri, 08 Jun 2018 15:40:55 +0200 Subject: [Announce] [security fix] GnuPG 2.2.8 released (CVE-2018-12020) Message-ID: <874lidz994.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: version 2.2.8. This version fixes a critical security bug and comes with some other minor changes. Impact ====== All current GnuPG versions are affected on all platforms. All mail clients and other applications which make use of GPG but are not utilizing the GPGME library might be affected. The OpenPGP protocol allows to include the file name of the original input file into a signed or encrypted message. During decryption and verification the GPG tool can display a notice with that file name. The displayed file name is not sanitized and as such may include line feeds or other control characters. This can be used inject terminal control sequences into the out and, worse, to fake the so-called status messages. These status messages are parsed by programs to get information from gpg about the validity of a signature and an other parameters. Status messages are created with the option "--status-fd N" where N is a file descriptor. Now if N is 2 the status messages and the regular diagnostic messages share the stderr output channel. By using a made up file name in the message it is possible to fake status messages. Using this technique it is for example possible to fake the verification status of a signed mail. Although GnuPG takes great care to sanitize all diagnostic and status output, the case at hand was missed but finally found and reported by Marcus Brinkmann. CVE-2018-12020 was assigned to this bug; GnuPG tracks it at . Solution ======== If your application uses GPGME your application is safe. Fortunately most modern mail readers use GPGME, including GpgOL and KMail. Mutt users should make sure to use "set crypt_use_gpgme". If you are parsing GnuPG status output and you use a dedicated file descriptor with --status-fd you are safe. A dedicated file descriptor is one that is not shared with the log output. The log output defaults to stderr (2) but may be a different if the option --logger-fd is used. If you are not using --verbose you are safe. But take care: --verbose might be specified in the config file. As a short term mitigation or if you can't immediately upgrade to the latest versions, you can add --no-verbose to the invocation of gpg. Another short term mitigation is to redirect the log output to a different file: For example "--log-file /dev/null". The suggested solution is to update to GnuPG 2.2.8 or a vendor provided update of their GnuPG version. To check whether the bug has been fixed you may use the simple test at the end of this mail [1]. About GnuPG =========== The GNU Privacy Guard (GnuPG) is a complete and free implementation of the OpenPGP standard which is commonly abbreviated as PGP. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries making use of GnuPG are available. As an Universal Crypto Engine GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Noteworthy changes in version 2.2.8 =================================== * gpg: Decryption of messages not using the MDC mode will now lead to a hard failure even if a legacy cipher algorithm was used. The option --ignore-mdc-error can be used to turn this failure into a warning. Take care: Never use that option unconditionally or without a prior warning. * gpg: The MDC encryption mode is now always used regardless of the cipher algorithm or any preferences. For testing --rfc2440 can be used to create a message without an MDC. * gpg: Sanitize the diagnostic output of the original file name in verbose mode. [#4012,CVE-2018-12020] * gpg: Detect suspicious multiple plaintext packets in a more reliable way. [#4000] * gpg: Fix the duplicate key signature detection code. [#3994] * gpg: The options --no-mdc-warn, --force-mdc, --no-force-mdc, --disable-mdc and --no-disable-mdc have no more effect. * agent: Add DBUS_SESSION_BUS_ADDRESS and a few other envvars to the list of startup environment variables. [#3947] Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.2.8 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.8.tar.bz2 (6477k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.8.tar.bz2.sig An installer for Windows without any graphical frontend except for a very minimal Pinentry tool is available here: https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.8_20180608.exe (3916k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.8_20180608.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. A new Gpg4win installer featuring this version of GnuPG will be available soon. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.2.8.tar.bz2 you would use this command: gpg --verify gnupg-2.2.8.tar.bz2.sig gnupg-2.2.8.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See the end of this mail for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.2.8.tar.bz2, you run the command like this: sha1sum gnupg-2.2.8.tar.bz2 and check that the output matches the next line: d87553a125832ea90e8aeb3ceeecf24f88de56fb gnupg-2.2.8.tar.bz2 3126ec2b7005063cbff95792208796dfa42c2a22 gnupg-w32-2.2.8_20180608.tar.xz 231b29631647328934a35f8c6baa483e7594e26a gnupg-w32-2.2.8_20180608.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese, Czech, French, German, Japanese, Norwegian, Russian, and Ukrainian being almost completely translated. Documentation and Support ========================= If you used GnuPG in the past you should read the description of changes and new features at doc/whats-new-in-2.1.txt or online at https://gnupg.org/faq/whats-new-in-2.1.html The file gnupg.info has the complete reference manual of the system. Separate man pages are included as well but they miss some of the details availabale only in thee manual. The manual is also available online at https://gnupg.org/documentation/manuals/gnupg/ or can be downloaded as PDF at https://gnupg.org/documentation/manuals/gnupg.pdf . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. You may also want to search the GnuPG mailing list archives or ask on the gnupg-users mailing list for advise on how to solve problems. Most of the new features are around for several years and thus enough public experience is available. Please consult the archive of the gnupg-users mailing list before reporting a bug: . We suggest to send bug reports for a new release to this list in favor of filing a bug at . If you need commercial support check out . If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== Maintenance and development of GnuPG is mostly financed by donations. The GnuPG project currently employs one full-time developer and one contractor. Both work exclusively on GnuPG and closely related software like Libgcrypt, GPGME, and GPA. We are planning to extend our team again and to help developers to improve integration of crypto in their applications. We have to thank all the people who helped the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Many thanks to our numerous financial supporters, both corporate and individuals. Without you it would not be possible to keep GnuPG in a good shape and address all the small and larger requests made by our users. Thanks. Happy hacking, Your GnuPG hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users'at'gnupg.org mailing list. p.p.s List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: rsa2048 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048 2014-10-29 [expires: 2020-10-30] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa3072 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) The keys are available at and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. =========== [1] If you want to test whether you are affected by this bug, remove the indentation from the following block -----BEGIN PGP MESSAGE----- jA0EBwMC1pW2pqoYvbXl0p4Bo5z/v7PXy7T1BY/KQxWaE9uTBRbf4no64/+5YYzX +BVNqP+82aBFYXEsD9x1vGuYwofQ4m/q/WcQDEPXhRyzU+4yiT3EOuG7sTTaQR3b 8xAn2Qtpyq5tO7k9CN6dasaXKSduXVmFUqzgU+W9WaTLOKNDFw6FYV3lnOoPtFcX rzhh2opkX9Oh/5DUkZ6YmUIX3j/A0z+59/qNO1i2hQ== =zswl -----END PGP MESSAGE----- and pass to this pipeline gpg --no-options -vd 2>&1 | grep '^\[GNUPG:] INJECTED' If you get some output you are using a non-fixed version. -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From aheinecke at intevation.de Fri Jun 8 17:03:07 2018 From: aheinecke at intevation.de (Andre Heinecke) Date: Fri, 08 Jun 2018 17:03:07 +0200 Subject: [Announce] [security fix] GnuPG 2.2.8 released (CVE-2018-12020) In-Reply-To: <874lidz994.fsf@wheatstone.g10code.de> References: <874lidz994.fsf@wheatstone.g10code.de> Message-ID: <10473226.T89b4ZZxY3@esus> Hi, I have a problem with the test On Friday 8 June 2018 15:40:55 CEST Werner Koch wrote: > [1] If you want to test whether you are affected by this bug, remove the > indentation from the following block > > -----BEGIN PGP MESSAGE----- > > jA0EBwMC1pW2pqoYvbXl0p4Bo5z/v7PXy7T1BY/KQxWaE9uTBRbf4no64/+5YYzX > +BVNqP+82aBFYXEsD9x1vGuYwofQ4m/q/WcQDEPXhRyzU+4yiT3EOuG7sTTaQR3b > 8xAn2Qtpyq5tO7k9CN6dasaXKSduXVmFUqzgU+W9WaTLOKNDFw6FYV3lnOoPtFcX > rzhh2opkX9Oh/5DUkZ6YmUIX3j/A0z+59/qNO1i2hQ== > =zswl > -----END PGP MESSAGE----- > > and pass to this pipeline > > gpg --no-options -vd 2>&1 | grep '^\[GNUPG:] INJECTED' > > If you get some output you are using a non-fixed version. It asks me for a symetric passphrase. I leave that blank. Then I get "No secret key" error. The command with the grep will of course return nothing Example: $ cat cve201812020 -----BEGIN PGP MESSAGE----- jA0EBwMC1pW2pqoYvbXl0p4Bo5z/v7PXy7T1BY/KQxWaE9uTBRbf4no64/+5YYzX +BVNqP+82aBFYXEsD9x1vGuYwofQ4m/q/WcQDEPXhRyzU+4yiT3EOuG7sTTaQR3b 8xAn2Qtpyq5tO7k9CN6dasaXKSduXVmFUqzgU+W9WaTLOKNDFw6FYV3lnOoPtFcX rzhh2opkX9Oh/5DUkZ6YmUIX3j/A0z+59/qNO1i2hQ== =zswl -----END PGP MESSAGE----- $ gpg --no-options -vd cve201812020 gpg: AES encrypted data gpg: gcry_kdf_derive failed: Invalid data gpg: encrypted with 1 passphrase gpg: decryption failed: No secret key $ gpg --version gpg (GnuPG) 2.2.8-beta1 Which should be affected. Best regards and thanks for your quick fix for this. Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- 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 dkg at fifthhorseman.net Fri Jun 8 20:29:52 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 08 Jun 2018 14:29:52 -0400 Subject: [Announce] [security fix] GnuPG 2.2.8 released (CVE-2018-12020) In-Reply-To: <10473226.T89b4ZZxY3@esus> References: <874lidz994.fsf@wheatstone.g10code.de> <10473226.T89b4ZZxY3@esus> Message-ID: <87in6t6sin.fsf@fifthhorseman.net> On Fri 2018-06-08 17:03:07 +0200, Andre Heinecke wrote: > I have a problem with the test > It asks me for a symetric passphrase. I'm having the same problem. Werner, what is the passphrase for this test example? --dkg From dkg at fifthhorseman.net Fri Jun 8 21:01:52 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 08 Jun 2018 15:01:52 -0400 Subject: [Announce] [security fix] GnuPG 2.2.8 released (CVE-2018-12020) In-Reply-To: <87in6t6sin.fsf@fifthhorseman.net> References: <874lidz994.fsf@wheatstone.g10code.de> <10473226.T89b4ZZxY3@esus> <87in6t6sin.fsf@fifthhorseman.net> Message-ID: <87fu1x6r1b.fsf@fifthhorseman.net> On Fri 2018-06-08 14:29:52 -0400, Daniel Kahn Gillmor wrote: > On Fri 2018-06-08 17:03:07 +0200, Andre Heinecke wrote: > >> I have a problem with the test >> It asks me for a symetric passphrase. > > I'm having the same problem. Werner, what is the passphrase for this > test example? ah, the passphrase is "abc" --dkg the mad haxx0r From wk at gnupg.org Fri Jun 8 21:54:38 2018 From: wk at gnupg.org (Werner Koch) Date: Fri, 08 Jun 2018 21:54:38 +0200 Subject: [Announce] [security fix] GnuPG 2.2.8 released (CVE-2018-12020) In-Reply-To: <87in6t6sin.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 08 Jun 2018 14:29:52 -0400") References: <874lidz994.fsf@wheatstone.g10code.de> <10473226.T89b4ZZxY3@esus> <87in6t6sin.fsf@fifthhorseman.net> Message-ID: <87lgbpxddt.fsf@wheatstone.g10code.de> On Fri, 8 Jun 2018 20:29, dkg at fifthhorseman.net said: > I'm having the same problem. Werner, what is the passphrase for this > test example? abc Sorry. I guess i rushed this thing out a bit too fast. Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From aajaxx at gmail.com Fri Jun 8 22:21:14 2018 From: aajaxx at gmail.com (Ajax) Date: Fri, 8 Jun 2018 20:21:14 +0000 Subject: Is something not right with my ~/.gnupg/pubring.kbx Message-ID: Most gpg commands give me something like this: $ gpg -Kv gpg: using classic trust model gpg: keydb_search failed: Invalid value gpg: Oops: keyid_from_fingerprint: no pubkey ~/.gnupg/pubring.kbx Followed by what appears to me to be normal output. I also see: $ kbxutil --stats ~/.gnupg/pubring.kbx Total number of blobs: 600 header: 1 empty: 0 openpgp: 599 x509: 0 non flagged: 599 secret flagged: 0 ephemeral flagged: 0 What should I do to clear the Invalid value and no pubkey? I only saw this problem after upgrading from gpg 1 to gpg2 and using the given script to migrate from pubring.gpg to pubring.kbx. These outputs seem to throw a monkey wrench into some scripts such as, for example, with pass generate -i This is gpg 2.1.18 atop Debian stretch and Linux 4.9.0-6-amd64, Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin.kircher at gmail.com Sun Jun 10 18:05:55 2018 From: benjamin.kircher at gmail.com (Benjamin Kircher) Date: Sun, 10 Jun 2018 18:05:55 +0200 Subject: Forward gpg-agent to container In-Reply-To: <20180606002710.GA31129@breadbox.private.spodhuis.org> References: <20180605211710.GA27486@breadbox.private.spodhuis.org> <20180606002710.GA31129@breadbox.private.spodhuis.org> Message-ID: <93F43A71-CBB4-4873-9C98-AF84D0149EDA@gmail.com> > On 6. Jun 2018, at 02:27, Phil Pennock wrote: > > On 2018-06-05 at 17:17 -0400, Phil Pennock wrote: >> Shell 2: >> $ docker run -it --rm -v /var/run/pdp.gnupg:/root/.gnupg/S.gpg-agent.ssh alpine >> / # chmod 0700 /root/.gnupg && chown root:root /root/.gnupg/S.gpg-agent >> / # apk update && apk add --no-cache gnupg > > I apologise, I missed fixing one glitch in review before sending. > > The correct command to invoke Docker here is: > > docker run -it --rm -v /var/run/pdp.gnupg:/root/.gnupg/S.gpg-agent alpine > > Don't use the `.ssh` name, that speaks an entirely different protocol > and was a mental glitch when I first wrote the above, fixed in testing > but not repaired in the email. > > The command-line if you're running on Linux should thus be (untested): > > docker run -it --rm -v $HOME/.gnupg/S.gpg-agent.extra:/root/.gnupg/S.gpg-agent alpine > > Adjust as appropriate for other images. This gives me gpg: can't connect to the agent: IPC connect call failed from within the container. Command lines that led to this output are: $ docker run --volume $(gpgconf --list-dirs agent-extra-socket):/root/.gnupg/S.gpg-agent --entrypoint=sh -ti --rm fedora:latest And the inside the container: # chmod 700 ~/.gnupg # gpg2 --keyserver pgp.uni-mainz.de --recv-keys # gpg2 --list-secret-keys BK From benjamin.kircher at gmail.com Sun Jun 10 18:23:50 2018 From: benjamin.kircher at gmail.com (Benjamin Kircher) Date: Sun, 10 Jun 2018 18:23:50 +0200 Subject: Forward gpg-agent to container In-Reply-To: <93F43A71-CBB4-4873-9C98-AF84D0149EDA@gmail.com> References: <20180605211710.GA27486@breadbox.private.spodhuis.org> <20180606002710.GA31129@breadbox.private.spodhuis.org> <93F43A71-CBB4-4873-9C98-AF84D0149EDA@gmail.com> Message-ID: <9E181DD0-ACA8-4066-A315-467A5883C5F0@gmail.com> > On 10. Jun 2018, at 18:05, Benjamin Kircher wrote: > > > >> On 6. Jun 2018, at 02:27, Phil Pennock wrote: >> >> On 2018-06-05 at 17:17 -0400, Phil Pennock wrote: >>> Shell 2: >>> $ docker run -it --rm -v /var/run/pdp.gnupg:/root/.gnupg/S.gpg-agent.ssh alpine >>> / # chmod 0700 /root/.gnupg && chown root:root /root/.gnupg/S.gpg-agent >>> / # apk update && apk add --no-cache gnupg >> >> I apologise, I missed fixing one glitch in review before sending. >> >> The correct command to invoke Docker here is: >> >> docker run -it --rm -v /var/run/pdp.gnupg:/root/.gnupg/S.gpg-agent alpine >> >> Don't use the `.ssh` name, that speaks an entirely different protocol >> and was a mental glitch when I first wrote the above, fixed in testing >> but not repaired in the email. >> >> The command-line if you're running on Linux should thus be (untested): >> >> docker run -it --rm -v $HOME/.gnupg/S.gpg-agent.extra:/root/.gnupg/S.gpg-agent alpine >> >> Adjust as appropriate for other images. > > This gives me > > gpg: can't connect to the agent: IPC connect call failed > > from within the container. > > Command lines that led to this output are: > > $ docker run --volume $(gpgconf --list-dirs agent-extra-socket):/root/.gnupg/S.gpg-agent --entrypoint=sh -ti --rm fedora:latest > > And the inside the container: > > # chmod 700 ~/.gnupg > # gpg2 --keyserver pgp.uni-mainz.de --recv-keys > # gpg2 --list-secret-keys To amend last message, reported errors and logs are: # gpg-connect-agent "keyinfo --list" /bye gpg-connect-agent: no running gpg-agent - starting '/usr/bin/gpg-agent' gpg-connect-agent: waiting for the agent to come up ... (5s) gpg-connect-agent: waiting for the agent to come up ... (4s) gpg-connect-agent: waiting for the agent to come up ... (3s) gpg-connect-agent: waiting for the agent to come up ... (1s) gpg-connect-agent: can't connect to the agent: IPC connect call failed gpg-connect-agent: error sending standard options: No agent running sh-4.4# cat /tmp/gpg-agent.log 2018-06-10 16:21:15 gpg-agent[10] error binding socket to '/root/.gnupg/S.gpg-agent': Address already in use 2018-06-10 16:21:15 gpg-agent[10] random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 2018-06-10 16:21:15 gpg-agent[10] rndjent stat: collector=0x0000000000000000 calls=0 bytes=0 2018-06-10 16:21:15 gpg-agent[10] secmem usage: 0/65536 bytes in 0 blocks BK From juergen at bruckner.tk Sun Jun 10 19:25:16 2018 From: juergen at bruckner.tk (Juergen Bruckner) Date: Sun, 10 Jun 2018 19:25:16 +0200 Subject: [Announce] [security fix] GnuPG 2.2.8 released (CVE-2018-12020) In-Reply-To: <874lidz994.fsf@wheatstone.g10code.de> References: <874lidz994.fsf@wheatstone.g10code.de> Message-ID: <4008285d-82cd-6b84-8d23-aa23851dccad@bruckner.tk> Hello Werner, i Use Linux Mint 18.3 with GnuPG 2.1.11; which is the easiest way to Update it to 2.2.8? I'm pretty new to the Linux-World, but as far i know i have NOT included a "own" GnuPG Repo in my Repo-List. best regards Juergen Am 2018-06-08 um 15:40 schrieb Werner Koch: > Hello! > > We are pleased to announce the availability of a new GnuPG release: > version 2.2.8. This version fixes a critical security bug and comes > with some other minor changes. > > > Impact > ====== > > All current GnuPG versions are affected on all platforms. > > All mail clients and other applications which make use of GPG but are > not utilizing the GPGME library might be affected. > > The OpenPGP protocol allows to include the file name of the original > input file into a signed or encrypted message. During decryption and > verification the GPG tool can display a notice with that file name. The > displayed file name is not sanitized and as such may include line feeds > or other control characters. This can be used inject terminal control > sequences into the out and, worse, to fake the so-called status > messages. These status messages are parsed by programs to get > information from gpg about the validity of a signature and an other > parameters. Status messages are created with the option "--status-fd N" > where N is a file descriptor. Now if N is 2 the status messages and the > regular diagnostic messages share the stderr output channel. By using a > made up file name in the message it is possible to fake status messages. > Using this technique it is for example possible to fake the verification > status of a signed mail. > > Although GnuPG takes great care to sanitize all diagnostic and status > output, the case at hand was missed but finally found and reported by > Marcus Brinkmann. CVE-2018-12020 was assigned to this bug; GnuPG tracks > it at . > > > Solution > ======== > > If your application uses GPGME your application is safe. Fortunately > most modern mail readers use GPGME, including GpgOL and KMail. Mutt > users should make sure to use "set crypt_use_gpgme". > > If you are parsing GnuPG status output and you use a dedicated file > descriptor with --status-fd you are safe. A dedicated file descriptor > is one that is not shared with the log output. The log output defaults > to stderr (2) but may be a different if the option --logger-fd is used. > > If you are not using --verbose you are safe. But take care: --verbose > might be specified in the config file. As a short term mitigation or if > you can't immediately upgrade to the latest versions, you can add > --no-verbose to the invocation of gpg. > > Another short term mitigation is to redirect the log output to a > different file: For example "--log-file /dev/null". > > The suggested solution is to update to GnuPG 2.2.8 or a vendor provided > update of their GnuPG version. > > To check whether the bug has been fixed you may use the simple test at > the end of this mail [1]. > > > About GnuPG > =========== > > The GNU Privacy Guard (GnuPG) is a complete and free implementation > of the OpenPGP standard which is commonly abbreviated as PGP. > > GnuPG allows to encrypt and sign data and communication, features a > versatile key management system as well as access modules for public key > directories. GnuPG itself is a command line tool with features for easy > integration with other applications. A wealth of frontend applications > and libraries making use of GnuPG are available. As an Universal Crypto > Engine GnuPG provides support for S/MIME and Secure Shell in addition to > OpenPGP. > > GnuPG is Free Software (meaning that it respects your freedom). It can > be freely used, modified and distributed under the terms of the GNU > General Public License. > > > Noteworthy changes in version 2.2.8 > =================================== > > * gpg: Decryption of messages not using the MDC mode will now lead > to a hard failure even if a legacy cipher algorithm was used. The > option --ignore-mdc-error can be used to turn this failure into a > warning. Take care: Never use that option unconditionally or > without a prior warning. > > * gpg: The MDC encryption mode is now always used regardless of the > cipher algorithm or any preferences. For testing --rfc2440 can be > used to create a message without an MDC. > > * gpg: Sanitize the diagnostic output of the original file name in > verbose mode. [#4012,CVE-2018-12020] > > * gpg: Detect suspicious multiple plaintext packets in a more > reliable way. [#4000] > > * gpg: Fix the duplicate key signature detection code. [#3994] > > * gpg: The options --no-mdc-warn, --force-mdc, --no-force-mdc, > --disable-mdc and --no-disable-mdc have no more effect. > > * agent: Add DBUS_SESSION_BUS_ADDRESS and a few other envvars to the > list of startup environment variables. [#3947] > > > Getting the Software > ==================== > > Please follow the instructions found at or > read on: > > GnuPG 2.2.8 may be downloaded from one of the GnuPG mirror sites or > direct from its primary FTP server. The list of mirrors can be found at > . Note that GnuPG is not > available at ftp.gnu.org. > > The GnuPG source code compressed using BZIP2 and its OpenPGP signature > are available here: > > https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.8.tar.bz2 (6477k) > https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.8.tar.bz2.sig > > An installer for Windows without any graphical frontend except for a > very minimal Pinentry tool is available here: > > https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.8_20180608.exe (3916k) > https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.8_20180608.exe.sig > > The source used to build the Windows installer can be found in the same > directory with a ".tar.xz" suffix. A new Gpg4win installer featuring > this version of GnuPG will be available soon. > > > Checking the Integrity > ====================== > > In order to check that the version of GnuPG which you are going to > install is an original and unmodified one, you can do it in one of > the following ways: > > * If you already have a version of GnuPG installed, you can simply > verify the supplied signature. For example to verify the signature > of the file gnupg-2.2.8.tar.bz2 you would use this command: > > gpg --verify gnupg-2.2.8.tar.bz2.sig gnupg-2.2.8.tar.bz2 > > This checks whether the signature file matches the source file. > You should see a message indicating that the signature is good and > made by one or more of the release signing keys. Make sure that > this is a valid key, either by matching the shown fingerprint > against a trustworthy list of valid release signing keys or by > checking that the key has been signed by trustworthy other keys. > See the end of this mail for information on the signing keys. > > * If you are not able to use an existing version of GnuPG, you have > to verify the SHA-1 checksum. On Unix systems the command to do > this is either "sha1sum" or "shasum". Assuming you downloaded the > file gnupg-2.2.8.tar.bz2, you run the command like this: > > sha1sum gnupg-2.2.8.tar.bz2 > > and check that the output matches the next line: > > d87553a125832ea90e8aeb3ceeecf24f88de56fb gnupg-2.2.8.tar.bz2 > 3126ec2b7005063cbff95792208796dfa42c2a22 gnupg-w32-2.2.8_20180608.tar.xz > 231b29631647328934a35f8c6baa483e7594e26a gnupg-w32-2.2.8_20180608.exe > > > Internationalization > ==================== > > This version of GnuPG has support for 26 languages with Chinese, Czech, > French, German, Japanese, Norwegian, Russian, and Ukrainian being almost > completely translated. > > > Documentation and Support > ========================= > > If you used GnuPG in the past you should read the description of > changes and new features at doc/whats-new-in-2.1.txt or online at > > https://gnupg.org/faq/whats-new-in-2.1.html > > The file gnupg.info has the complete reference manual of the system. > Separate man pages are included as well but they miss some of the > details availabale only in thee manual. The manual is also available > online at > > https://gnupg.org/documentation/manuals/gnupg/ > > or can be downloaded as PDF at > > https://gnupg.org/documentation/manuals/gnupg.pdf . > > The chapters on gpg-agent, gpg and gpgsm include information on how to > set up the whole thing. You may also want to search the GnuPG mailing > list archives or ask on the gnupg-users mailing list for advise on how > to solve problems. Most of the new features are around for several > years and thus enough public experience is available. > > Please consult the archive of the gnupg-users mailing list before > reporting a bug: . > We suggest to send bug reports for a new release to this list in favor > of filing a bug at . If you need commercial > support check out . > > If you are a developer and you need a certain feature for your project, > please do not hesitate to bring it to the gnupg-devel mailing list for > discussion. > > > Thanks > ====== > > Maintenance and development of GnuPG is mostly financed by donations. > The GnuPG project currently employs one full-time developer and one > contractor. Both work exclusively on GnuPG and closely related software > like Libgcrypt, GPGME, and GPA. We are planning to extend our team > again and to help developers to improve integration of crypto in their > applications. > > We have to thank all the people who helped the GnuPG project, be it > testing, coding, translating, suggesting, auditing, administering the > servers, spreading the word, and answering questions on the mailing > lists. > > Many thanks to our numerous financial supporters, both corporate and > individuals. Without you it would not be possible to keep GnuPG in a > good shape and address all the small and larger requests made by our > users. Thanks. > > > Happy hacking, > > Your GnuPG hackers > > > > p.s. > This is an announcement only mailing list. Please send replies only to > the gnupg-users'at'gnupg.org mailing list. > > p.p.s > List of Release Signing Keys: > > To guarantee that a downloaded GnuPG version has not been tampered by > malicious entities we provide signature files for all tarballs and > binary versions. The keys are also signed by the long term keys of > their respective owners. Current releases are signed by one or more > of these four keys: > > rsa2048 2011-01-12 [expires: 2019-12-31] > Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 > Werner Koch (dist sig) > > rsa2048 2014-10-29 [expires: 2019-12-31] > Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 > David Shaw (GnuPG Release Signing Key) > > rsa2048 2014-10-29 [expires: 2020-10-30] > Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 > NIIBE Yutaka (GnuPG Release Key) > > rsa3072 2017-03-17 [expires: 2027-03-15] > Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 > Andre Heinecke (Release Signing Key) > > The keys are available at and > in any recently released GnuPG tarball in the file g10/distsigkey.gpg . > Note that this mail has been signed by a different key. > =========== > > [1] If you want to test whether you are affected by this bug, remove the > indentation from the following block > > -----BEGIN PGP MESSAGE----- > > jA0EBwMC1pW2pqoYvbXl0p4Bo5z/v7PXy7T1BY/KQxWaE9uTBRbf4no64/+5YYzX > +BVNqP+82aBFYXEsD9x1vGuYwofQ4m/q/WcQDEPXhRyzU+4yiT3EOuG7sTTaQR3b > 8xAn2Qtpyq5tO7k9CN6dasaXKSduXVmFUqzgU+W9WaTLOKNDFw6FYV3lnOoPtFcX > rzhh2opkX9Oh/5DUkZ6YmUIX3j/A0z+59/qNO1i2hQ== > =zswl > -----END PGP MESSAGE----- > > and pass to this pipeline > > gpg --no-options -vd 2>&1 | grep '^\[GNUPG:] INJECTED' > > If you get some output you are using a non-fixed version. > > > > _______________________________________________ > Gnupg-announce mailing list > Gnupg-announce at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-announce > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- Juergen M. Bruckner juergen at bruckner.tk -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3894 bytes Desc: S/MIME Cryptographic Signature URL: From jeandavid8 at verizon.net Sun Jun 10 22:50:23 2018 From: jeandavid8 at verizon.net (Jean-David Beyer) Date: Sun, 10 Jun 2018 16:50:23 -0400 Subject: [Announce] [security fix] GnuPG 2.2.8 released (CVE-2018-12020) In-Reply-To: <4008285d-82cd-6b84-8d23-aa23851dccad@bruckner.tk> References: <874lidz994.fsf@wheatstone.g10code.de> <4008285d-82cd-6b84-8d23-aa23851dccad@bruckner.tk> Message-ID: <48ea8cd8-01d8-838f-7ad1-543e869e6771@verizon.net> On 06/10/2018 01:25 PM, Juergen Bruckner wrote: > Hello Werner, > > i Use Linux Mint 18.3 with GnuPG 2.1.11; which is the easiest way to > Update it to 2.2.8? > > > I'm pretty new to the Linux-World, but as far i know i have NOT included > a "own" GnuPG Repo in my Repo-List. > > best regards > Juergen > > Am 2018-06-08 um 15:40 schrieb Werner Koch: >> Hello! >> >> We are pleased to announce the availability of a new GnuPG release: >> version 2.2.8. This version fixes a critical security bug and comes >> with some other minor changes. >> >> >> Impact >> ====== >> >> All current GnuPG versions are affected on all platforms. >> >> All mail clients and other applications which make use of GPG but are >> not utilizing the GPGME library might be affected. >> >> The OpenPGP protocol allows to include the file name of the original >> input file into a signed or encrypted message. During decryption and >> verification the GPG tool can display a notice with that file name. The >> displayed file name is not sanitized and as such may include line feeds >> or other control characters. This can be used inject terminal control >> sequences into the out and, worse, to fake the so-called status >> messages. These status messages are parsed by programs to get >> information from gpg about the validity of a signature and an other >> parameters. Status messages are created with the option "--status-fd N" >> where N is a file descriptor. Now if N is 2 the status messages and the >> regular diagnostic messages share the stderr output channel. By using a >> made up file name in the message it is possible to fake status messages. >> Using this technique it is for example possible to fake the verification >> status of a signed mail. >> >> Although GnuPG takes great care to sanitize all diagnostic and status >> output, the case at hand was missed but finally found and reported by >> Marcus Brinkmann. CVE-2018-12020 was assigned to this bug; GnuPG tracks >> it at . >> >> >> Solution >> ======== >> >> If your application uses GPGME your application is safe. Fortunately >> most modern mail readers use GPGME, including GpgOL and KMail. Mutt >> users should make sure to use "set crypt_use_gpgme". >> >> If you are parsing GnuPG status output and you use a dedicated file >> descriptor with --status-fd you are safe. A dedicated file descriptor >> is one that is not shared with the log output. The log output defaults >> to stderr (2) but may be a different if the option --logger-fd is used. >> >> If you are not using --verbose you are safe. But take care: --verbose >> might be specified in the config file. As a short term mitigation or if >> you can't immediately upgrade to the latest versions, you can add >> --no-verbose to the invocation of gpg. >> >> Another short term mitigation is to redirect the log output to a >> different file: For example "--log-file /dev/null". >> >> The suggested solution is to update to GnuPG 2.2.8 or a vendor provided >> update of their GnuPG version. >> >> To check whether the bug has been fixed you may use the simple test at >> the end of this mail [1]. >> >> >> About GnuPG >> =========== >> >> The GNU Privacy Guard (GnuPG) is a complete and free implementation >> of the OpenPGP standard which is commonly abbreviated as PGP. >> >> GnuPG allows to encrypt and sign data and communication, features a >> versatile key management system as well as access modules for public key >> directories. GnuPG itself is a command line tool with features for easy >> integration with other applications. A wealth of frontend applications >> and libraries making use of GnuPG are available. As an Universal Crypto >> Engine GnuPG provides support for S/MIME and Secure Shell in addition to >> OpenPGP. >> >> GnuPG is Free Software (meaning that it respects your freedom). It can >> be freely used, modified and distributed under the terms of the GNU >> General Public License. >> >> >> Noteworthy changes in version 2.2.8 >> =================================== >> >> * gpg: Decryption of messages not using the MDC mode will now lead >> to a hard failure even if a legacy cipher algorithm was used. The >> option --ignore-mdc-error can be used to turn this failure into a >> warning. Take care: Never use that option unconditionally or >> without a prior warning. >> >> * gpg: The MDC encryption mode is now always used regardless of the >> cipher algorithm or any preferences. For testing --rfc2440 can be >> used to create a message without an MDC. >> >> * gpg: Sanitize the diagnostic output of the original file name in >> verbose mode. [#4012,CVE-2018-12020] >> >> * gpg: Detect suspicious multiple plaintext packets in a more >> reliable way. [#4000] >> >> * gpg: Fix the duplicate key signature detection code. [#3994] >> >> * gpg: The options --no-mdc-warn, --force-mdc, --no-force-mdc, >> --disable-mdc and --no-disable-mdc have no more effect. >> >> * agent: Add DBUS_SESSION_BUS_ADDRESS and a few other envvars to the >> list of startup environment variables. [#3947] >> >> >> Getting the Software >> ==================== >> >> Please follow the instructions found at or >> read on: >> >> GnuPG 2.2.8 may be downloaded from one of the GnuPG mirror sites or >> direct from its primary FTP server. The list of mirrors can be found at >> . Note that GnuPG is not >> available at ftp.gnu.org. >> >> The GnuPG source code compressed using BZIP2 and its OpenPGP signature >> are available here: >> >> https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.8.tar.bz2 (6477k) >> https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.8.tar.bz2.sig >> >> An installer for Windows without any graphical frontend except for a >> very minimal Pinentry tool is available here: >> >> https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.8_20180608.exe (3916k) >> https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.8_20180608.exe.sig >> >> The source used to build the Windows installer can be found in the same >> directory with a ".tar.xz" suffix. A new Gpg4win installer featuring >> this version of GnuPG will be available soon. >> >> >> Checking the Integrity >> ====================== >> >> In order to check that the version of GnuPG which you are going to >> install is an original and unmodified one, you can do it in one of >> the following ways: >> >> * If you already have a version of GnuPG installed, you can simply >> verify the supplied signature. For example to verify the signature >> of the file gnupg-2.2.8.tar.bz2 you would use this command: >> >> gpg --verify gnupg-2.2.8.tar.bz2.sig gnupg-2.2.8.tar.bz2 >> >> This checks whether the signature file matches the source file. >> You should see a message indicating that the signature is good and >> made by one or more of the release signing keys. Make sure that >> this is a valid key, either by matching the shown fingerprint >> against a trustworthy list of valid release signing keys or by >> checking that the key has been signed by trustworthy other keys. >> See the end of this mail for information on the signing keys. >> >> * If you are not able to use an existing version of GnuPG, you have >> to verify the SHA-1 checksum. On Unix systems the command to do >> this is either "sha1sum" or "shasum". Assuming you downloaded the >> file gnupg-2.2.8.tar.bz2, you run the command like this: >> >> sha1sum gnupg-2.2.8.tar.bz2 >> >> and check that the output matches the next line: >> >> d87553a125832ea90e8aeb3ceeecf24f88de56fb gnupg-2.2.8.tar.bz2 >> 3126ec2b7005063cbff95792208796dfa42c2a22 gnupg-w32-2.2.8_20180608.tar.xz >> 231b29631647328934a35f8c6baa483e7594e26a gnupg-w32-2.2.8_20180608.exe >> >> >> Internationalization >> ==================== >> >> This version of GnuPG has support for 26 languages with Chinese, Czech, >> French, German, Japanese, Norwegian, Russian, and Ukrainian being almost >> completely translated. >> >> >> Documentation and Support >> ========================= >> >> If you used GnuPG in the past you should read the description of >> changes and new features at doc/whats-new-in-2.1.txt or online at >> >> https://gnupg.org/faq/whats-new-in-2.1.html >> >> The file gnupg.info has the complete reference manual of the system. >> Separate man pages are included as well but they miss some of the >> details availabale only in thee manual. The manual is also available >> online at >> >> https://gnupg.org/documentation/manuals/gnupg/ >> >> or can be downloaded as PDF at >> >> https://gnupg.org/documentation/manuals/gnupg.pdf . >> >> The chapters on gpg-agent, gpg and gpgsm include information on how to >> set up the whole thing. You may also want to search the GnuPG mailing >> list archives or ask on the gnupg-users mailing list for advise on how >> to solve problems. Most of the new features are around for several >> years and thus enough public experience is available. >> >> Please consult the archive of the gnupg-users mailing list before >> reporting a bug: . >> We suggest to send bug reports for a new release to this list in favor >> of filing a bug at . If you need commercial >> support check out . >> >> If you are a developer and you need a certain feature for your project, >> please do not hesitate to bring it to the gnupg-devel mailing list for >> discussion. >> >> >> Thanks >> ====== >> >> Maintenance and development of GnuPG is mostly financed by donations. >> The GnuPG project currently employs one full-time developer and one >> contractor. Both work exclusively on GnuPG and closely related software >> like Libgcrypt, GPGME, and GPA. We are planning to extend our team >> again and to help developers to improve integration of crypto in their >> applications. >> >> We have to thank all the people who helped the GnuPG project, be it >> testing, coding, translating, suggesting, auditing, administering the >> servers, spreading the word, and answering questions on the mailing >> lists. >> >> Many thanks to our numerous financial supporters, both corporate and >> individuals. Without you it would not be possible to keep GnuPG in a >> good shape and address all the small and larger requests made by our >> users. Thanks. >> >> >> Happy hacking, >> >> Your GnuPG hackers >> >> >> >> p.s. >> This is an announcement only mailing list. Please send replies only to >> the gnupg-users'at'gnupg.org mailing list. >> >> p.p.s >> List of Release Signing Keys: >> >> To guarantee that a downloaded GnuPG version has not been tampered by >> malicious entities we provide signature files for all tarballs and >> binary versions. The keys are also signed by the long term keys of >> their respective owners. Current releases are signed by one or more >> of these four keys: >> >> rsa2048 2011-01-12 [expires: 2019-12-31] >> Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 >> Werner Koch (dist sig) >> >> rsa2048 2014-10-29 [expires: 2019-12-31] >> Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 >> David Shaw (GnuPG Release Signing Key) >> >> rsa2048 2014-10-29 [expires: 2020-10-30] >> Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 >> NIIBE Yutaka (GnuPG Release Key) >> >> rsa3072 2017-03-17 [expires: 2027-03-15] >> Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 >> Andre Heinecke (Release Signing Key) >> >> The keys are available at and >> in any recently released GnuPG tarball in the file g10/distsigkey.gpg . >> Note that this mail has been signed by a different key. >> =========== >> >> [1] If you want to test whether you are affected by this bug, remove the >> indentation from the following block >> >> -----BEGIN PGP MESSAGE----- >> >> jA0EBwMC1pW2pqoYvbXl0p4Bo5z/v7PXy7T1BY/KQxWaE9uTBRbf4no64/+5YYzX >> +BVNqP+82aBFYXEsD9x1vGuYwofQ4m/q/WcQDEPXhRyzU+4yiT3EOuG7sTTaQR3b >> 8xAn2Qtpyq5tO7k9CN6dasaXKSduXVmFUqzgU+W9WaTLOKNDFw6FYV3lnOoPtFcX >> rzhh2opkX9Oh/5DUkZ6YmUIX3j/A0z+59/qNO1i2hQ== >> =zswl >> -----END PGP MESSAGE----- >> >> and pass to this pipeline >> >> gpg --no-options -vd 2>&1 | grep '^\[GNUPG:] INJECTED' >> >> If you get some output you are using a non-fixed version. >> >> >> >> _______________________________________________ >> Gnupg-announce mailing list >> Gnupg-announce at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-announce >> >> >> >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users >> > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > It says part of your message to me was encrypted and prompted me for my passphrase, but it must not have been encrypted with my public key. -- .~. Jean-David Beyer Registered Linux User 85642. /V\ PGP-Key:166D840A 0C610C8B Registered Machine 1935521. /( )\ Shrewsbury, New Jersey http://linuxcounter.net ^^-^^ 16:45:01 up 19 days, 21:28, 2 users, load average: 6.09, 5.31, 4.80 From ben+freesoftware at benfinney.id.au Fri Jun 8 21:47:15 2018 From: ben+freesoftware at benfinney.id.au (Ben Finney) Date: Sat, 09 Jun 2018 05:47:15 +1000 Subject: [security fix] GnuPG 2.2.8 released (CVE-2018-12020) In-Reply-To: <874lidz994.fsf__20247.2633020536$1528475654$gmane$org@wheatstone.g10code.de> (Werner Koch's message of "Fri, 08 Jun 2018 15:40:55 +0200") References: <874lidz994.fsf__20247.2633020536$1528475654$gmane$org@wheatstone.g10code.de> Message-ID: <85muw5giws.fsf@benfinney.id.au> Werner Koch writes: > Although GnuPG takes great care to sanitize all diagnostic and status > output, the case at hand was missed but finally found and reported by > Marcus Brinkmann. CVE-2018-12020 was assigned to this bug; GnuPG tracks > it at . Thank you to Marcus, Werner, and all involved in tracking, describing for an audience, fixing this bug, and releasing the fix. -- \ ?You don't change the world by placidly finding your bliss ? | `\ you do it by focusing your discontent in productive ways.? | _o__) ?Paul Z. Myers, 2011-08-31 | Ben Finney From jmtechwork at gmail.com Sat Jun 9 19:08:16 2018 From: jmtechwork at gmail.com (Jeff Martin) Date: Sat, 9 Jun 2018 12:08:16 -0500 Subject: Hard to find alternate source of checksums Message-ID: For a fresh install of GnuPG, I was following the integrity check directions. I have no prior version for GnuPG. https://gnupg.org/download/integrity_check.html They read "...find the announcement on several other websites and make sure the checksum is consistent." This task is difficult to accomplish using search engines such a DuckDuckGo or Google. The search terms that yielded the best results were merely the full file name enclosed in double quotes. I eventually found an alternate source of the checksums solely from search results for all files except "ntbtls-0.1.2.tar.bz2", oddly. I'm not sure what makes that one special. Also, I felt I was relying too much on www.linuxfromscratch.org as my alternate source. Do you have any specific tips for how to find alternate checksum sources? Thanks. -- Jeff Martin From marco.maggi-ipsu at poste.it Mon Jun 11 08:31:58 2018 From: marco.maggi-ipsu at poste.it (Marco Maggi) Date: Mon, 11 Jun 2018 08:31:58 +0200 Subject: [Announce] [security fix] GnuPG 2.2.8 released (CVE-2018-12020) In-Reply-To: marco.maggi-ipsu@poste.it "Fri\, 08 Jun 2018 15\:40\:55 +0200") References: <874lidz994.fsf@wheatstone.g10code.de> Message-ID: <878t7lomu9.fsf@poste.it> Ciao, running "make" fails with undeclared symbol. On my x86_64-pc-linux-gnu (Slackware) I downloaded: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.8.tar.bz2 configured with: configure --prefix=/usr/local --libdir=/usr/local/lib64 CFLAGS=-O3 I get this report: GnuPG v2.2.8 has been configured as follows: Revision: cd9aaa786 (52634) Platform: GNU/Linux (x86_64-pc-linux-gnu) OpenPGP: yes S/MIME: yes Agent: yes Smartcard: yes G13: no Dirmngr: yes Gpgtar: yes WKS tools: no Protect tool: (default) LDAP wrapper: (default) Default agent: (default) Default pinentry: (default) Default scdaemon: (default) Default dirmngr: (default) Dirmngr auto start: yes Readline support: yes LDAP support: yes TLS support: gnutls TOFU support: yes Tor support: yes when running make I get: gcc -DHAVE_CONFIG_H -I. -I.. -DLOCALEDIR=\"/usr/local/share/locale\" -DGNUPG_BINDIR="\"/usr/local/bin\"" -DGNUPG_LIBEXECDIR="\"/usr/local/libexec\"" -DGNUPG_LIBDIR="\"/usr/local/lib64/gnupg\"" -DGNUPG_DATADIR="\"/usr/local/share/gnupg\"" -DGNUPG_SYSCONFDIR="\"/usr/local/etc/gnupg\"" -DGNUPG_LOCALSTATEDIR="\"/usr/local/var\"" -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -Wall -Wno-pointer-sign -Wpointer-arith -O3 -MT mainproc.o -MD -MP -MF .deps/mainproc.Tpo -c -o mainproc.o mainproc.c mainproc.c: In function 'proc_encrypted': mainproc.c:686:14: error: 'GPGRT_LOGLVL_INFO' undeclared (first use in this function); did you mean 'GPGRT_LOG_INFO'? (GPGRT_LOGLVL_INFO, ^~~~~~~~~~~~~~~~~ GPGRT_LOG_INFO mainproc.c:686:14: note: each undeclared identifier is reported only once for each function it appears in Makefile:875: recipe for target 'mainproc.o' failed and: $ grep GPGRT_LOGLVL_INFO * --recursive g10/mainproc.c: (GPGRT_LOGLVL_INFO, I cannot believe that I am the only one getting this error. TIA -- Marco Maggi From bernhard at intevation.de Mon Jun 11 09:53:35 2018 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 11 Jun 2018 09:53:35 +0200 Subject: [Announce] [security fix] GnuPG 2.2.8 released (CVE-2018-12020) In-Reply-To: <874lidz994.fsf@wheatstone.g10code.de> References: <874lidz994.fsf@wheatstone.g10code.de> Message-ID: <201806110953.39761.bernhard@intevation.de> Hello, two fixes for the anouncement: >CVE-2018-12020 was assigned to this bug; GnuPG tracks > it at . https://dev.gnupg.org/T4012 > and pass to this pipeline > > gpg --no-options -vd 2>&1 | grep '^\[GNUPG:] INJECTED' enter the needed passphrase 'abc' in your pinentry. Regards, Bernhard -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From marco.maggi-ipsu at poste.it Mon Jun 11 10:06:25 2018 From: marco.maggi-ipsu at poste.it (Marco Maggi) Date: Mon, 11 Jun 2018 10:06:25 +0200 Subject: [Announce] [security fix] GnuPG 2.2.8 released (CVE-2018-12020) In-Reply-To: marco.maggi-ipsu@poste.it 2018 08:31:58 +0200") References: <874lidz994.fsf@wheatstone.g10code.de> <878t7lomu9.fsf@poste.it> Message-ID: <8736xtoigu.fsf@poste.it> "Marco Maggi" wrote: >mainproc.c:686:14: error: 'GPGRT_LOGLVL_INFO' undeclared (first use in this function); did you mean 'GPGRT_LOG_INFO'? I fixed this by upgrading to the latest libgpg-error. This means the gnupg package does not detect the installed libgpg-error version correctly? -- Marco Maggi From ndk.clanbo at gmail.com Mon Jun 11 09:38:19 2018 From: ndk.clanbo at gmail.com (NdK) Date: Mon, 11 Jun 2018 09:38:19 +0200 Subject: Hard to find alternate source of checksums In-Reply-To: References: Message-ID: <145842c2-f05e-f952-6c3b-b7d8c1507e07@gmail.com> Il 09/06/2018 19:08, Jeff Martin ha scritto: > For a fresh install of GnuPG, I was following the integrity check > directions. I have no prior version for GnuPG. Why not fetch some (unrelated) live distributions, possibly some older ones and some newer ones? GPG is usually included and you can use it to check the signatures. BYtE, Diego From peter at digitalbrains.com Mon Jun 11 11:07:58 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 11 Jun 2018 11:07:58 +0200 Subject: [Announce] [security fix] GnuPG 2.2.8 released (CVE-2018-12020) In-Reply-To: <48ea8cd8-01d8-838f-7ad1-543e869e6771@verizon.net> References: <874lidz994.fsf@wheatstone.g10code.de> <4008285d-82cd-6b84-8d23-aa23851dccad@bruckner.tk> <48ea8cd8-01d8-838f-7ad1-543e869e6771@verizon.net> Message-ID: (Could you please trim your quotes? Incidentally, this would have prevented the problem in the first place, both on the first and on your reply). On 10/06/18 22:50, Jean-David Beyer wrote: > It says part of your message to me was encrypted and prompted me for my > passphrase, but it must not have been encrypted with my public key. It would appear that at least Enigmail (mine is from Debian stable/stretch) ignores an inline encrypted block if it is indented, but interprets it if it is quoted *and* indented. So while there was no attempt to decrypt the block in the first message by Werner, as soon as it was part of a quote, starting with "> ", Enigmail will try to process it. Type in the passphrase "abc" without quotes, and you'll decrypt the test message part of the announcement. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From juergen at bruckner.tk Mon Jun 11 11:43:37 2018 From: juergen at bruckner.tk (Juergen Bruckner) Date: Mon, 11 Jun 2018 11:43:37 +0200 Subject: [Announce] [security fix] GnuPG 2.2.8 released (CVE-2018-12020) In-Reply-To: References: <874lidz994.fsf@wheatstone.g10code.de> <4008285d-82cd-6b84-8d23-aa23851dccad@bruckner.tk> <48ea8cd8-01d8-838f-7ad1-543e869e6771@verizon.net> Message-ID: > (Could you please trim your quotes? Incidentally, this would have > prevented the problem in the first place, both on the first and on your > reply). > Thanks for the hint > It would appear that at least Enigmail (mine is from Debian > stable/stretch) ignores an inline encrypted block if it is indented, but > interprets it if it is quoted *and* indented. So while there was no > attempt to decrypt the block in the first message by Werner, as soon as > it was part of a quote, starting with "> ", Enigmail will try to > process it. Type in the passphrase "abc" without quotes, and you'll > decrypt the test message part of the announcement. > and thanks again for the info regards Juergen -- Juergen M. Bruckner juergen at bruckner.tk -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3894 bytes Desc: S/MIME Cryptographic Signature URL: From max-julian at pogner.at Mon Jun 11 10:30:23 2018 From: max-julian at pogner.at (Max-Julian Pogner) Date: Mon, 11 Jun 2018 10:30:23 +0200 Subject: Expire a single UID Message-ID: Hello there! I have quite a problem with properly bisecting a UID from my key. Maybe someone can help me? Here's the situation: This is currently my GnuPG-Key, and will remain my primar key: https://pgp.mit.edu/pks/lookup?op=get&search=0x2D40BDB44401A8AA https://pogner.at/gnupg/0x2D40BDB44401A8AA.gpg However, my contract with OpenResearch changes from freelancer to hired-employee. As a consequence, i will stop using my own Infrastructure but using their pc. Therefore, i will also read and write emails from the new work-pc. But i do not want to copy my secret key 0x2D40BDB44401A8AA to the new work-pc (which is very much their property and not under my full administrative control but under their company-it administrative control). Therefore, my current plan is to simply generate a completely new secret key with UID max-julian.pogner at openresearch.com. This also will not be a problem with the customers where gnupg is actually in use (less than 5 persons to be honest). Now there is a problem: Then there will be two keys published for max-julian.pogner at openresearch.com! This surely will cause confusion. *) should i revoke the uid on the old key? => However, as far as i know, the secret key is not / was never compromised. *) the UIDs were certified by me and by other persons without expiration dates. => I can change the expiration date of the primary key and subkeys using "gpg2 --edit-key" and "expire", but the UID remains valid forever. *) Also, other persons have signed the UID max-julian.pogner at openresearch.com at key 0x2D40BDB44401A8AA without expiration date. What should they do? Thanks for any hints! Max -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From juergen at bruckner.tk Mon Jun 11 11:07:37 2018 From: juergen at bruckner.tk (Juergen Bruckner) Date: Mon, 11 Jun 2018 11:07:37 +0200 Subject: [Announce] [security fix] GnuPG 2.2.8 released (CVE-2018-12020) In-Reply-To: <48ea8cd8-01d8-838f-7ad1-543e869e6771@verizon.net> References: <874lidz994.fsf@wheatstone.g10code.de> <4008285d-82cd-6b84-8d23-aa23851dccad@bruckner.tk> <48ea8cd8-01d8-838f-7ad1-543e869e6771@verizon.net> Message-ID: <047772a4-9575-8ab1-765b-3a553c4d2ca7@bruckner.tk> I did NOT encrypt the Message, just signed it with my PGP-Key - This message is now without sign or encrypt Am 2018-06-10 um 22:50 schrieb Jean-David Beyer: > On 06/10/2018 01:25 PM, Juergen Bruckner wrote: >> Hello Werner, >> >> i Use Linux Mint 18.3 with GnuPG 2.1.11; which is the easiest way to >> Update it to 2.2.8? >> >> >> I'm pretty new to the Linux-World, but as far i know i have NOT included >> a "own" GnuPG Repo in my Repo-List. >> >> best regards >> Juergen >> >> Am 2018-06-08 um 15:40 schrieb Werner Koch: >>> Hello! >>> >>> We are pleased to announce the availability of a new GnuPG release: >>> version 2.2.8. This version fixes a critical security bug and comes >>> with some other minor changes. >>> >>> >>> Impact >>> ====== >>> >>> All current GnuPG versions are affected on all platforms. >>> >>> All mail clients and other applications which make use of GPG but are >>> not utilizing the GPGME library might be affected. >>> >>> The OpenPGP protocol allows to include the file name of the original >>> input file into a signed or encrypted message. During decryption and >>> verification the GPG tool can display a notice with that file name. The >>> displayed file name is not sanitized and as such may include line feeds >>> or other control characters. This can be used inject terminal control >>> sequences into the out and, worse, to fake the so-called status >>> messages. These status messages are parsed by programs to get >>> information from gpg about the validity of a signature and an other >>> parameters. Status messages are created with the option "--status-fd N" >>> where N is a file descriptor. Now if N is 2 the status messages and the >>> regular diagnostic messages share the stderr output channel. By using a >>> made up file name in the message it is possible to fake status messages. >>> Using this technique it is for example possible to fake the verification >>> status of a signed mail. >>> >>> Although GnuPG takes great care to sanitize all diagnostic and status >>> output, the case at hand was missed but finally found and reported by >>> Marcus Brinkmann. CVE-2018-12020 was assigned to this bug; GnuPG tracks >>> it at . >>> >>> >>> Solution >>> ======== >>> >>> If your application uses GPGME your application is safe. Fortunately >>> most modern mail readers use GPGME, including GpgOL and KMail. Mutt >>> users should make sure to use "set crypt_use_gpgme". >>> >>> If you are parsing GnuPG status output and you use a dedicated file >>> descriptor with --status-fd you are safe. A dedicated file descriptor >>> is one that is not shared with the log output. The log output defaults >>> to stderr (2) but may be a different if the option --logger-fd is used. >>> >>> If you are not using --verbose you are safe. But take care: --verbose >>> might be specified in the config file. As a short term mitigation or if >>> you can't immediately upgrade to the latest versions, you can add >>> --no-verbose to the invocation of gpg. >>> >>> Another short term mitigation is to redirect the log output to a >>> different file: For example "--log-file /dev/null". >>> >>> The suggested solution is to update to GnuPG 2.2.8 or a vendor provided >>> update of their GnuPG version. >>> >>> To check whether the bug has been fixed you may use the simple test at >>> the end of this mail [1]. >>> >>> >>> About GnuPG >>> =========== >>> >>> The GNU Privacy Guard (GnuPG) is a complete and free implementation >>> of the OpenPGP standard which is commonly abbreviated as PGP. >>> >>> GnuPG allows to encrypt and sign data and communication, features a >>> versatile key management system as well as access modules for public key >>> directories. GnuPG itself is a command line tool with features for easy >>> integration with other applications. A wealth of frontend applications >>> and libraries making use of GnuPG are available. As an Universal Crypto >>> Engine GnuPG provides support for S/MIME and Secure Shell in addition to >>> OpenPGP. >>> >>> GnuPG is Free Software (meaning that it respects your freedom). It can >>> be freely used, modified and distributed under the terms of the GNU >>> General Public License. >>> >>> >>> Noteworthy changes in version 2.2.8 >>> =================================== >>> >>> * gpg: Decryption of messages not using the MDC mode will now lead >>> to a hard failure even if a legacy cipher algorithm was used. The >>> option --ignore-mdc-error can be used to turn this failure into a >>> warning. Take care: Never use that option unconditionally or >>> without a prior warning. >>> >>> * gpg: The MDC encryption mode is now always used regardless of the >>> cipher algorithm or any preferences. For testing --rfc2440 can be >>> used to create a message without an MDC. >>> >>> * gpg: Sanitize the diagnostic output of the original file name in >>> verbose mode. [#4012,CVE-2018-12020] >>> >>> * gpg: Detect suspicious multiple plaintext packets in a more >>> reliable way. [#4000] >>> >>> * gpg: Fix the duplicate key signature detection code. [#3994] >>> >>> * gpg: The options --no-mdc-warn, --force-mdc, --no-force-mdc, >>> --disable-mdc and --no-disable-mdc have no more effect. >>> >>> * agent: Add DBUS_SESSION_BUS_ADDRESS and a few other envvars to the >>> list of startup environment variables. [#3947] >>> >>> >>> Getting the Software >>> ==================== >>> >>> Please follow the instructions found at or >>> read on: >>> >>> GnuPG 2.2.8 may be downloaded from one of the GnuPG mirror sites or >>> direct from its primary FTP server. The list of mirrors can be found at >>> . Note that GnuPG is not >>> available at ftp.gnu.org. >>> >>> The GnuPG source code compressed using BZIP2 and its OpenPGP signature >>> are available here: >>> >>> https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.8.tar.bz2 (6477k) >>> https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.8.tar.bz2.sig >>> >>> An installer for Windows without any graphical frontend except for a >>> very minimal Pinentry tool is available here: >>> >>> https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.8_20180608.exe (3916k) >>> https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.8_20180608.exe.sig >>> >>> The source used to build the Windows installer can be found in the same >>> directory with a ".tar.xz" suffix. A new Gpg4win installer featuring >>> this version of GnuPG will be available soon. >>> >>> >>> Checking the Integrity >>> ====================== >>> >>> In order to check that the version of GnuPG which you are going to >>> install is an original and unmodified one, you can do it in one of >>> the following ways: >>> >>> * If you already have a version of GnuPG installed, you can simply >>> verify the supplied signature. For example to verify the signature >>> of the file gnupg-2.2.8.tar.bz2 you would use this command: >>> >>> gpg --verify gnupg-2.2.8.tar.bz2.sig gnupg-2.2.8.tar.bz2 >>> >>> This checks whether the signature file matches the source file. >>> You should see a message indicating that the signature is good and >>> made by one or more of the release signing keys. Make sure that >>> this is a valid key, either by matching the shown fingerprint >>> against a trustworthy list of valid release signing keys or by >>> checking that the key has been signed by trustworthy other keys. >>> See the end of this mail for information on the signing keys. >>> >>> * If you are not able to use an existing version of GnuPG, you have >>> to verify the SHA-1 checksum. On Unix systems the command to do >>> this is either "sha1sum" or "shasum". Assuming you downloaded the >>> file gnupg-2.2.8.tar.bz2, you run the command like this: >>> >>> sha1sum gnupg-2.2.8.tar.bz2 >>> >>> and check that the output matches the next line: >>> >>> d87553a125832ea90e8aeb3ceeecf24f88de56fb gnupg-2.2.8.tar.bz2 >>> 3126ec2b7005063cbff95792208796dfa42c2a22 gnupg-w32-2.2.8_20180608.tar.xz >>> 231b29631647328934a35f8c6baa483e7594e26a gnupg-w32-2.2.8_20180608.exe >>> >>> >>> Internationalization >>> ==================== >>> >>> This version of GnuPG has support for 26 languages with Chinese, Czech, >>> French, German, Japanese, Norwegian, Russian, and Ukrainian being almost >>> completely translated. >>> >>> >>> Documentation and Support >>> ========================= >>> >>> If you used GnuPG in the past you should read the description of >>> changes and new features at doc/whats-new-in-2.1.txt or online at >>> >>> https://gnupg.org/faq/whats-new-in-2.1.html >>> >>> The file gnupg.info has the complete reference manual of the system. >>> Separate man pages are included as well but they miss some of the >>> details availabale only in thee manual. The manual is also available >>> online at >>> >>> https://gnupg.org/documentation/manuals/gnupg/ >>> >>> or can be downloaded as PDF at >>> >>> https://gnupg.org/documentation/manuals/gnupg.pdf . >>> >>> The chapters on gpg-agent, gpg and gpgsm include information on how to >>> set up the whole thing. You may also want to search the GnuPG mailing >>> list archives or ask on the gnupg-users mailing list for advise on how >>> to solve problems. Most of the new features are around for several >>> years and thus enough public experience is available. >>> >>> Please consult the archive of the gnupg-users mailing list before >>> reporting a bug: . >>> We suggest to send bug reports for a new release to this list in favor >>> of filing a bug at . If you need commercial >>> support check out . >>> >>> If you are a developer and you need a certain feature for your project, >>> please do not hesitate to bring it to the gnupg-devel mailing list for >>> discussion. >>> >>> >>> Thanks >>> ====== >>> >>> Maintenance and development of GnuPG is mostly financed by donations. >>> The GnuPG project currently employs one full-time developer and one >>> contractor. Both work exclusively on GnuPG and closely related software >>> like Libgcrypt, GPGME, and GPA. We are planning to extend our team >>> again and to help developers to improve integration of crypto in their >>> applications. >>> >>> We have to thank all the people who helped the GnuPG project, be it >>> testing, coding, translating, suggesting, auditing, administering the >>> servers, spreading the word, and answering questions on the mailing >>> lists. >>> >>> Many thanks to our numerous financial supporters, both corporate and >>> individuals. Without you it would not be possible to keep GnuPG in a >>> good shape and address all the small and larger requests made by our >>> users. Thanks. >>> >>> >>> Happy hacking, >>> >>> Your GnuPG hackers >>> >>> >>> >>> p.s. >>> This is an announcement only mailing list. Please send replies only to >>> the gnupg-users'at'gnupg.org mailing list. >>> >>> p.p.s >>> List of Release Signing Keys: >>> >>> To guarantee that a downloaded GnuPG version has not been tampered by >>> malicious entities we provide signature files for all tarballs and >>> binary versions. The keys are also signed by the long term keys of >>> their respective owners. Current releases are signed by one or more >>> of these four keys: >>> >>> rsa2048 2011-01-12 [expires: 2019-12-31] >>> Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 >>> Werner Koch (dist sig) >>> >>> rsa2048 2014-10-29 [expires: 2019-12-31] >>> Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 >>> David Shaw (GnuPG Release Signing Key) >>> >>> rsa2048 2014-10-29 [expires: 2020-10-30] >>> Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 >>> NIIBE Yutaka (GnuPG Release Key) >>> >>> rsa3072 2017-03-17 [expires: 2027-03-15] >>> Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 >>> Andre Heinecke (Release Signing Key) >>> >>> The keys are available at and >>> in any recently released GnuPG tarball in the file g10/distsigkey.gpg . >>> Note that this mail has been signed by a different key. >>> =========== >>> >>> [1] If you want to test whether you are affected by this bug, remove the >>> indentation from the following block >>> >>> -----BEGIN PGP MESSAGE----- >>> >>> jA0EBwMC1pW2pqoYvbXl0p4Bo5z/v7PXy7T1BY/KQxWaE9uTBRbf4no64/+5YYzX >>> +BVNqP+82aBFYXEsD9x1vGuYwofQ4m/q/WcQDEPXhRyzU+4yiT3EOuG7sTTaQR3b >>> 8xAn2Qtpyq5tO7k9CN6dasaXKSduXVmFUqzgU+W9WaTLOKNDFw6FYV3lnOoPtFcX >>> rzhh2opkX9Oh/5DUkZ6YmUIX3j/A0z+59/qNO1i2hQ== >>> =zswl >>> -----END PGP MESSAGE----- >>> >>> and pass to this pipeline >>> >>> gpg --no-options -vd 2>&1 | grep '^\[GNUPG:] INJECTED' >>> >>> If you get some output you are using a non-fixed version. >>> >>> >>> >>> _______________________________________________ >>> Gnupg-announce mailing list >>> Gnupg-announce at gnupg.org >>> http://lists.gnupg.org/mailman/listinfo/gnupg-announce >>> >>> >>> >>> _______________________________________________ >>> Gnupg-users mailing list >>> Gnupg-users at gnupg.org >>> http://lists.gnupg.org/mailman/listinfo/gnupg-users >>> >> >> >> >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users >> > It says part of your message to me was encrypted and prompted me for my > passphrase, but it must not have been encrypted with my public key. > -- Juergen M. Bruckner juergen at bruckner.tk From wk at gnupg.org Mon Jun 11 13:33:56 2018 From: wk at gnupg.org (Werner Koch) Date: Mon, 11 Jun 2018 13:33:56 +0200 Subject: [Announce] [security fix] GnuPG 2.2.8 released (CVE-2018-12020) In-Reply-To: <8736xtoigu.fsf@poste.it> (Marco Maggi's message of "Mon, 11 Jun 2018 10:06:25 +0200") References: <874lidz994.fsf@wheatstone.g10code.de> <878t7lomu9.fsf@poste.it> <8736xtoigu.fsf@poste.it> Message-ID: <87efhdftgb.fsf@wheatstone.g10code.de> On Mon, 11 Jun 2018 10:06, marco.maggi-ipsu at poste.it said: > I fixed this by upgrading to the latest libgpg-error. This means the > gnupg package does not detect the installed libgpg-error version > correctly? Merge fault, sorry. See https://dev.gnupg.org/T4012 for a fix. Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Mon Jun 11 13:31:20 2018 From: wk at gnupg.org (Werner Koch) Date: Mon, 11 Jun 2018 13:31:20 +0200 Subject: [Announce] [security fix] GnuPG 2.2.8 released (CVE-2018-12020) In-Reply-To: (Peter Lebbing's message of "Mon, 11 Jun 2018 11:07:58 +0200") References: <874lidz994.fsf@wheatstone.g10code.de> <4008285d-82cd-6b84-8d23-aa23851dccad@bruckner.tk> <48ea8cd8-01d8-838f-7ad1-543e869e6771@verizon.net> Message-ID: <87in6pftkn.fsf@wheatstone.g10code.de> On Mon, 11 Jun 2018 11:07, peter at digitalbrains.com said: > attempt to decrypt the block in the first message by Werner, as soon as > it was part of a quote, starting with "> ", Enigmail will try to > process it. Type in the passphrase "abc" without quotes, and you'll I'd call that a TB bug. There was a reason why I indented that PGP block. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dgouttegattat at incenp.org Mon Jun 11 14:04:20 2018 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Mon, 11 Jun 2018 13:04:20 +0100 Subject: Expire a single UID In-Reply-To: References: Message-ID: <069b4d89-5951-0196-9fc7-5320624cb072@incenp.org> Hi, On 06/11/2018 09:30 AM, Max-Julian Pogner wrote: > *) should i revoke the uid on the old key? => However, as far as i > know, the secret key is not / was never compromised. This is probably the best option in my opinion, since you will no longer use that key with this email address. Revoking a UID is not the same as revoking a key, and does not imply that the associated secret key has been compromised (if a key has been compromised you should revoke the key itself, not the UID). Most often it simply means "I no longer use that UID". Note that when revoking the UID you will have the option of specifying a reason for the revocation. > *) Also, other persons have signed the UID > max-julian.pogner at openresearch.com at key 0x2D40BDB44401A8AA without > expiration date. What should they do? With regard to your old key, they don't have anything to do. Your revocation of the UID takes precedence over their signatures. With regard to your new key, you might want to ask them if they could sign it. One way to do that is to send them an email signed by both the old key and the new key, so that they know you control both keys. > Thanks for any hints! Here's another possibility: Have you considered using an OpenPGP card? This would allow you to keep your private keys under your control, even when you use them on your employer-provided system. Hope that helps, Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From steffen at sdaoden.eu Mon Jun 11 16:32:34 2018 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 11 Jun 2018 16:32:34 +0200 Subject: v1.4.22: re--importing --export'ed key from --export-secret-subkeys dir cannot --encrypt In-Reply-To: <20180604134413.SlJyg%steffen@sdaoden.eu> References: <20180604134413.SlJyg%steffen@sdaoden.eu> Message-ID: <20180611143234.noxmg%steffen@sdaoden.eu> A nice Monday afternoon i wish, i have a post scriptum. Steffen Nurpmeso wrote in <20180604134413.SlJyg%steffen at sdaoden.eu>: |Last saturday i search/stumbled over an interesting Debian page |(Subkey.html) which describes how to generate a dedicated siging |subkeys, and how to create a new key pool via |--export-secret-subkeys which does not contain (all parts of) the |real private key, so that the secret key can be stored "somewhere |else" but the newly reimported secret (sub)key can still be used |for signing purposes. ... |(sorry), i cannot find a bug in the bug-db that corresponds to the |behaviour i see, and that is that i neither can --export the |public key from that mutilated private key and use that one for |--encrypt'ion, nor can use the key itself for that (the encryption |key seems "hidden", but if i "toggle" --edit-key then i can see it |still). But i can use it for signing purposes. So i ended up with two directories, pgp-backup.git without secring.gpg and only the public key which can encrypt, and pgp.git, which is ~/.gnupg, has the mutilated private key, and can sign. Just ten minutes ago however i have found out that if i --export the key from pgp-backup.git and --import it into pgp.git, then the latter gains encryption capabilities again! I thought i had tried that with the GNUPGHOME which has the full private key, and failed, but maybe i was in a state of confusion by then (already). Anyway, this new --import mysteriously said Reading passphrase from file descriptor 4 gpg: key ... 2 new signatures gpg: key .. 1 new subkey gpg: Total number processed: 1 gpg: new subkeys: 1 gpg: new signatures: 2 and i now have the signature for the newly created signing subkey two times, and encryption works. ~/.gnupg is now fully functional again! Ciao from within the Greyness, --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From ler762 at gmail.com Mon Jun 11 16:14:26 2018 From: ler762 at gmail.com (Lee) Date: Mon, 11 Jun 2018 10:14:26 -0400 Subject: Hard to find alternate source of checksums In-Reply-To: <145842c2-f05e-f952-6c3b-b7d8c1507e07@gmail.com> References: <145842c2-f05e-f952-6c3b-b7d8c1507e07@gmail.com> Message-ID: On 6/11/18, NdK wrote: > Il 09/06/2018 19:08, Jeff Martin ha scritto: >> For a fresh install of GnuPG, I was following the integrity check >> directions. I have no prior version for GnuPG. > Why not fetch some (unrelated) live distributions, possibly some older > ones and some newer ones? > > GPG is usually included and you can use it to check the signatures. If you're not trusting the checksums listed on the website you're not trusting the signing key fingerprints listed on the site either. So you still need to find a release announcement on 2 or 3 different sites to check the signing key fingerprints. And know enough to make sure the auto key retrieval function in GPG is turned off in your live distro Lee From gnupg-users at spodhuis.org Tue Jun 12 00:43:33 2018 From: gnupg-users at spodhuis.org (Phil Pennock) Date: Mon, 11 Jun 2018 18:43:33 -0400 Subject: Forward gpg-agent to container In-Reply-To: <93F43A71-CBB4-4873-9C98-AF84D0149EDA@gmail.com> References: <20180605211710.GA27486@breadbox.private.spodhuis.org> <20180606002710.GA31129@breadbox.private.spodhuis.org> <93F43A71-CBB4-4873-9C98-AF84D0149EDA@gmail.com> Message-ID: <20180611224332.GA12474@osmium.lan> On 2018-06-10 at 18:05 +0200, Benjamin Kircher wrote: > This gives me > > gpg: can't connect to the agent: IPC connect call failed > > from within the container. > > Command lines that led to this output are: > > $ docker run --volume $(gpgconf --list-dirs agent-extra-socket):/root/.gnupg/S.gpg-agent --entrypoint=sh -ti --rm fedora:latest Did you do something to start the agent in the parent Linux host before trying to forward the socket? I can run that Docker image just fine, using the same approach, and things work for me. But once you're isolating processes between different virtual operating systems, none of GnuPG's facilities for auto-launching processes will help you. Run: gpg-connect-agent /bye in the non-Docker environment before starting the Docker commands. That command will ensure that the agent is running, then disconnect from the running agent. It might be that you have SELinux preventing the volume mount; if tacking ':z' onto the end of the volume spec works, that would be the cause. docker run -it --rm \ --volume $(gpgconf --list-dirs agent-extra-socket):/root/.gnupg/S.gpg-agent:z \ --entrypoint=sh fedora:latest I am not using Linux with SELinux to run Docker anywhere, so can't be of any further help in debugging if this is the cause; warning notes online suggest extreme caution is warranted when using the `z` mount option, you'll need to test carefully to make sure that GnuPG _outside_ of Docker still works afterwards. (If not ... `gpgconf --kill gpg-agent` and continue on). -Phil From dkg at fifthhorseman.net Tue Jun 12 09:21:54 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 12 Jun 2018 03:21:54 -0400 Subject: Stripping expired subkey during export? In-Reply-To: <87a8924uaa.fsf@wheatstone.g10code.de> References: <20170303062138.GA32472@breadbox.private.spodhuis.org> <87a8924uaa.fsf@wheatstone.g10code.de> Message-ID: <87efhc5v1p.fsf@fifthhorseman.net> dredging this up from the past: On Fri 2017-03-03 08:51:57 +0100, Werner Koch wrote: > As a compatible hack we could add an 'expired' property to the > export-filter's drop-subkey method. Just did this: > > gpg --export-options export-clean \ > --export-filter drop-subkey='expired -t' \ > --export 1e42b367 > > removes all my expired subkeys. This is just a first step; we also need > a properties for the key capability. This is now underway, and will hopefully make it into the next release: https://dev.gnupg.org/T4019 --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jerry at seibercom.net Tue Jun 12 16:05:20 2018 From: jerry at seibercom.net (Jerry) Date: Tue, 12 Jun 2018 10:05:20 -0400 Subject: Problem refreshing keys Message-ID: <20180612100520.0000230c@seibercom.net> I don't know if this is the right place to ask this, but it is a start. Kleopatra Version 3.1.1-gpg4win-3.1.1 Trying to refresh the keys, produces this error message: Starting C:\Program Files (x86)\GnuPG\bin\gpg.exe --display-charset utf-8 --refresh-keys... gpg: refreshing 387 keys from hkps://hkps.pool.sks-keyservers.net gpg: keyserver refresh failed: Server indicated a failure This is happening on a Windows 10 PRO / amd64 machine. This has been occurring for several days now. Is there something wrong with the server? -- Jerry From max-julian at pogner.at Tue Jun 12 18:39:21 2018 From: max-julian at pogner.at (Max-Julian Pogner) Date: Tue, 12 Jun 2018 18:39:21 +0200 Subject: Expire a single UID In-Reply-To: <069b4d89-5951-0196-9fc7-5320624cb072@incenp.org> References: <069b4d89-5951-0196-9fc7-5320624cb072@incenp.org> Message-ID: <6f0172d4-9b82-7bec-fe43-2f95885c29c7@pogner.at> Hi, -----?In?Reply?to?Original?Message?----- <069b4d89-5951-0196-9fc7-5320624cb072 at incenp.org> From:?Damien Goutte-Gattat via Gnupg-users To:?gnupg-users ?;? Sent:?Mon, 11 Jun 2018 13:04:20 +0100 Subject:?Expire a single UID > On 06/11/2018 09:30 AM, Max-Julian Pogner wrote: >> *) should i revoke the uid on the old key? => However, as far as i >> know, the secret key is not / was never compromised. > Revoking a UID is not the same as revoking a key, and does not imply > that the associated secret key has been compromised Then i'll revoke the uid. >> Thanks for any hints! > Here's another possibility: Have you considered using an OpenPGP card? > This would allow you to keep your private keys under your control, even > when you use them on your employer-provided system. That would be actually a very good solution. However, due to lacking my experience and lacking general acceptance, I have to postpone this until some other day. Thanks for the help! lg, Max -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From tookmund at gmail.com Tue Jun 12 19:03:52 2018 From: tookmund at gmail.com (Jacob Adams) Date: Tue, 12 Jun 2018 13:03:52 -0400 Subject: Pinentry: Permission Denied In-Reply-To: <20180603232233.ewmnykp5vtbkjjas@raf.org> References: <95bc89a0-14c2-4cbb-782d-40872005c216@gmail.com> <20180603232233.ewmnykp5vtbkjjas@raf.org> Message-ID: On 06/03/2018 07:22 PM, gnupg at raf.org wrote: > Jacob Adams wrote: > >> I've been getting the occasional "Pinentry: Permission Denied" error >> when generating new keys with GPGME and leaving pinentry to get the >> password instead of passing it directly (passphrase=True with the python >> bindings). Typically a reboot will fix it but it's rather odd. >> >> I've attached a couple logs. If there's something else I should be >> logging to catch this error, please let me know. >> >> Any ideas on what might be causing this? >> A reboot usually fixes it but it's quite annoying. >> >> Thanks, >> Jacob > > it might be permissions on /dev/tty (which looks to be /dev/tty1 > from the debugging output). did you su/sudo to another user? That seems to be it. I was overriding getty and launching my own service as a non-root user and tty1 was still owned by root I've fixed permissions on the tty in ExecPreStart and haven't seen a pinentry error since. https://salsa.debian.org/tookmund-guest/pgpcr/blob/master/debian/pgp-clean-room.service Thanks, Jacob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From gnupg-users at spodhuis.org Tue Jun 12 22:42:25 2018 From: gnupg-users at spodhuis.org (Phil Pennock) Date: Tue, 12 Jun 2018 16:42:25 -0400 Subject: Problem refreshing keys In-Reply-To: <20180612100520.0000230c@seibercom.net> References: <20180612100520.0000230c@seibercom.net> Message-ID: <20180612204224.GA13636@osmium.lan> On 2018-06-12 at 10:05 -0400, Jerry wrote: > Starting C:\Program Files (x86)\GnuPG\bin\gpg.exe --display-charset utf-8 --refresh-keys... > gpg: refreshing 387 keys from hkps://hkps.pool.sks-keyservers.net > gpg: keyserver refresh failed: Server indicated a failure > > This is happening on a Windows 10 PRO / amd64 machine. This has been occurring > for several days now. Is there something wrong with the server? Seems likely, but there's not enough information there to track it down. hkps.pool.sks-keyservers.net is a collection of servers, run by different people, with management software tracking their status and updating DNS as needed. I've no idea how to use Kleopatra to ask for more debugging details to get the IP, sorry. You can see some of what's going on with: gpg-connect-agent --dirmngr 'KEYSERVER --hosttable' /bye (if Windows doesn't like that quoting, then press enter after --dirmngr and then enter each of the next strings as a command at the prompt) Eg, I see: % gpg-connect-agent --dirmngr 'KEYSERVER --hosttable' /bye S # hosttable (idx, ipv6, ipv4, dead, name, time): S # 0 hkps.pool.sks-keyservers.net S # . hkps.pool.sks-keyservers.net S # . --> 4 9* 3 2 1 8 7 6 5 S # 1 4 216.66.15.2 S # 2 4 193.224.163.43 (hufu.ki.iif.hu) S # 3 4 193.164.133.100 (mail.b4ckbone.de) S # 4 4 176.9.147.41 (mail.ntzwrk.org) S # 5 4 92.43.111.21 (oteiza.siccegge.de) S # 6 4 68.187.0.77 (stlhs.archreactor.org) S # 7 4 51.15.53.138 (ams.sks.heypete.com) S # 8 4 37.191.226.104 (host-37-191-226-104.lynet.no) S # 9 4 18.191.65.131 (ec2-18-191-65-131.us-east-2.compute.amazonaws.com) OK So the "." lines are because the previous item is a pool, so they provide more information, and AFAICT the "-->" line is "the order we'll try them in, with the currently active server marked with "*"; this shows me that the second item is active. This makes sense, since the first retrieval took a long time, but the second was very quick: the first keyserver failed to give something sane back, so dirmngr fell over to the next item, which responded, and dirmngr has remembered that one as "good" so it will use it again in future. Given the failure you see, the "blind stabbing in the dark" approach would be to use: KEYSERVER --dead IP.ADD.RE.SS to mark the one with a "*" as "bad" and see what happens. If that fixes it, then you know that the IP address which was "responding" and so selected was actually failing. You can drop a note to sks-devel at nongnu.org with details if you manage to extract that much information from the tooling. -Phil, whose keyserver is in the pool and, coincidentally, is #9 above, the one which worked and was selected. From jerry at seibercom.net Wed Jun 13 00:23:40 2018 From: jerry at seibercom.net (Jerry) Date: Tue, 12 Jun 2018 18:23:40 -0400 Subject: Problem refreshing keys In-Reply-To: <20180612204224.GA13636@osmium.lan> References: <20180612100520.0000230c@seibercom.net> <20180612204224.GA13636@osmium.lan> Message-ID: <20180612182340.00005bdc@seibercom.net> On Tue, 12 Jun 2018 16:42:25 -0400, Phil Pennock stated: >On 2018-06-12 at 10:05 -0400, Jerry wrote: >> Starting C:\Program Files (x86)\GnuPG\bin\gpg.exe --display-charset utf-8 >> --refresh-keys... gpg: refreshing 387 keys from >> hkps://hkps.pool.sks-keyservers.net gpg: keyserver refresh failed: Server >> indicated a failure >> >> This is happening on a Windows 10 PRO / amd64 machine. This has been >> occurring for several days now. Is there something wrong with the server? > >Seems likely, but there's not enough information there to track it down. > >hkps.pool.sks-keyservers.net is a collection of servers, run by >different people, with management software tracking their status and >updating DNS as needed. > >I've no idea how to use Kleopatra to ask for more debugging details to >get the IP, sorry. > >You can see some of what's going on with: > > gpg-connect-agent --dirmngr 'KEYSERVER --hosttable' /bye > >(if Windows doesn't like that quoting, then press enter after --dirmngr >and then enter each of the next strings as a command at the prompt) > >Eg, I see: > >% gpg-connect-agent --dirmngr 'KEYSERVER --hosttable' /bye >S # hosttable (idx, ipv6, ipv4, dead, name, time): >S # 0 hkps.pool.sks-keyservers.net >S # . hkps.pool.sks-keyservers.net >S # . --> 4 9* 3 2 1 8 7 6 5 >S # 1 4 216.66.15.2 >S # 2 4 193.224.163.43 (hufu.ki.iif.hu) >S # 3 4 193.164.133.100 (mail.b4ckbone.de) >S # 4 4 176.9.147.41 (mail.ntzwrk.org) >S # 5 4 92.43.111.21 (oteiza.siccegge.de) >S # 6 4 68.187.0.77 (stlhs.archreactor.org) >S # 7 4 51.15.53.138 (ams.sks.heypete.com) >S # 8 4 37.191.226.104 (host-37-191-226-104.lynet.no) >S # 9 4 18.191.65.131 >(ec2-18-191-65-131.us-east-2.compute.amazonaws.com) OK > >So the "." lines are because the previous item is a pool, so they >provide more information, and AFAICT the "-->" line is "the order we'll >try them in, with the currently active server marked with "*"; this >shows me that the second item is active. This makes sense, since the >first retrieval took a long time, but the second was very quick: the >first keyserver failed to give something sane back, so dirmngr fell over >to the next item, which responded, and dirmngr has remembered that one >as "good" so it will use it again in future. > >Given the failure you see, the "blind stabbing in the dark" approach >would be to use: > > KEYSERVER --dead IP.ADD.RE.SS > >to mark the one with a "*" as "bad" and see what happens. If that fixes >it, then you know that the IP address which was "responding" and so >selected was actually failing. You can drop a note to >sks-devel at nongnu.org with details if you manage to extract that much >information from the tooling. > >-Phil, whose keyserver is in the pool and, coincidentally, is #9 above, > the one which worked and was selected. This is what I am getting: gpg-connect-agent --dirmngr 'KEYSERVER --hosttable' /bye gpg-connect-agent: Note: '--hosttable'' is not considered an option ERR 167772435 Unknown IPC command ERR 167772435 Unknown IPC command -- Jerry From wk at gnupg.org Wed Jun 13 15:25:04 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 13 Jun 2018 15:25:04 +0200 Subject: Problem refreshing keys In-Reply-To: <20180612182340.00005bdc@seibercom.net> (jerry@seibercom.net's message of "Tue, 12 Jun 2018 18:23:40 -0400") References: <20180612100520.0000230c@seibercom.net> <20180612204224.GA13636@osmium.lan> <20180612182340.00005bdc@seibercom.net> Message-ID: <87po0ubyz3.fsf@wheatstone.g10code.de> On Wed, 13 Jun 2018 00:23, jerry at seibercom.net said: > gpg-connect-agent --dirmngr 'KEYSERVER --hosttable' /bye The common problem on Windows: You can't use ' to quote; we Unix folks always forget about that. Use gpg-connect-agent --dirmngr "KEYSERVER --hosttable" /bye Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Wed Jun 13 15:21:51 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 13 Jun 2018 15:21:51 +0200 Subject: Problem refreshing keys In-Reply-To: <20180612204224.GA13636@osmium.lan> (Phil Pennock's message of "Tue, 12 Jun 2018 16:42:25 -0400") References: <20180612100520.0000230c@seibercom.net> <20180612204224.GA13636@osmium.lan> Message-ID: <87tvq6bz4g.fsf@wheatstone.g10code.de> On Tue, 12 Jun 2018 22:42, gnupg-users at spodhuis.org said: > provide more information, and AFAICT the "-->" line is "the order we'll > try them in, with the currently active server marked with "*"; this They are not tried in this order but they are picked randomly until one worked. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jerry at seibercom.net Wed Jun 13 15:52:39 2018 From: jerry at seibercom.net (Jerry) Date: Wed, 13 Jun 2018 09:52:39 -0400 Subject: Problem refreshing keys In-Reply-To: <87po0ubyz3.fsf@wheatstone.g10code.de> References: <20180612100520.0000230c@seibercom.net> <20180612204224.GA13636@osmium.lan> <20180612182340.00005bdc@seibercom.net> <87po0ubyz3.fsf@wheatstone.g10code.de> Message-ID: <20180613095239.00006e1b@seibercom.net> On Wed, 13 Jun 2018 15:25:04 +0200, Werner Koch stated: >On Wed, 13 Jun 2018 00:23, jerry at seibercom.net said: > >> gpg-connect-agent --dirmngr 'KEYSERVER --hosttable' /bye > >The common problem on Windows: You can't use ' to quote; we Unix folks >always forget about that. Use > > gpg-connect-agent --dirmngr "KEYSERVER --hosttable" /bye > > >Salam-Shalom, > > Werner OK, now this is what I am receiving: gpg-connect-agent --dirmngr "KEYSERVER --hosttable" /bye S # hosttable (idx, ipv6, ipv4, dead, name, time): S # 0 hkps.pool.sks-keyservers.net (216.66.15.2) OK Is that what it should be reporting? -- Jerry From dkg at fifthhorseman.net Wed Jun 13 15:43:14 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 13 Jun 2018 09:43:14 -0400 Subject: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction] In-Reply-To: References: <1268467b-1add-eb1c-4856-a1cb30f64463@sixdemonbag.org> <24d32263-7b8a-9bad-beb4-5d42d7b8d909@gaspard.io> <20180115173652.14f43a5d@iria.my-fqdn.de> <545A5DDC-3846-414C-8F15-3CE49993593D@andrewg.com> <8de7b9ab-2586-4c70-278a-3ce649b4691b@mail.ru> <3de247cc-a008-f415-07fe-a12b17cb6872@sixdemonbag.org> <87zi5dwst7.fsf@fifthhorseman.net> <0d49da6c-01d7-ef3d-af50-75764fd5a961@sumptuouscapital.com> <87efmpwd26.fsf@fifthhorseman.net> Message-ID: <87vaam4xal.fsf@fifthhorseman.net> On Wed 2018-01-17 08:57:12 +0100, Kristian Fiskerstrand wrote: > On 01/17/2018 01:20 AM, Daniel Kahn Gillmor wrote: >> On Tue 2018-01-16 22:56:58 +0100, Kristian Fiskerstrand wrote: >>> thanks for this post Daniel, my primary question would be what advantage >>> is gained by this verification being done by an arbitrary third party >>> rather by a trusted client running locally, which is the current modus >>> operandus. Any keyserver action doing this would just shift >>> responsibilities to a third party for something better served (and >>> already happens) locally. >> >> the advantage is spam-abatement -- the keyservers have to keep track of >> what is attached to each blob they transport/persist. if all signatures >> that they transport for a given blob are cryptographically certified, >> then only the original uploader of that blob can make assertions about >> it; other people can't spam the blob to make it untransportable. > > All the certificates used in trollwot are technically correct. You can > still use the same mechanisms as you control the other key material, and > can use intentionally weak key material if wanting to speed things up. sorry for the blast from the past here, but in re-reading this thread, i thought i'd follow up on this. the proposed revocation distribution network wouldn't allow any user IDs or third-party certifications, so most of the "trollwot" would not be relevant. if someone wants to upload their own key and make it unfetchable by appending garbage to it, that's probably OK (at least, it's a strict improvement than the current situation, which is that they can append garbage to *any* key). and if they use weak key material (or publish the secret someplace), then sure it's a noisy blob that anyone can append to. But no one will care, because they aren't likely to be relying on that key. does that make sense as to why this proposal is potentially useful? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Wed Jun 13 16:17:13 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 13 Jun 2018 16:17:13 +0200 Subject: Pinentry: Permission Denied In-Reply-To: (Jacob Adams's message of "Tue, 12 Jun 2018 13:03:52 -0400") References: <95bc89a0-14c2-4cbb-782d-40872005c216@gmail.com> <20180603232233.ewmnykp5vtbkjjas@raf.org> Message-ID: <87lgbibwk6.fsf@wheatstone.g10code.de> On Tue, 12 Jun 2018 19:03, tookmund at gmail.com said: > That seems to be it. I was overriding getty and launching my own service > as a non-root user and tty1 was still owned by root If you run gpg with -v with the next released pinentry you will see a line like this (wrapped) gpg: pinentry launched (17122 gtk2 1.1.1-beta7 \ /dev/pts/6 xterm localhost:11.0 20620/1000/5 1000/1000) ! ! ! device mode/uid/gid euid/egid of device of caller Maybe this helps in the future to track down such problems easier (mode and euid etc are new). Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Wed Jun 13 18:28:31 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 13 Jun 2018 18:28:31 +0200 Subject: [Announce] Libgcrypt 1.8.3 and 1.7.10 to fix CVE-2018-0495 Message-ID: <87efhabqhc.fsf@wheatstone.g10code.de> Hi! The GnuPG Project is pleased to announce the availability of Libgcrypt versions 1.8.3 and 1.7.10. These releases mitigate a novel side-channel attack on ECDSA signatures and also bring fixes for a few other bugs. Libgcrypt is a general purpose library of cryptographic building blocks. It is originally based on code used by GnuPG. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required to use Libgcrypt. Noteworthy changes in version 1.8.3 =================================== - Use blinding for ECDSA signing to mitigate a novel side-channel attack. [#4011,CVE-2018-0495] - Fix incorrect counter overflow handling for GCM when using an IV size other than 96 bit. [#3764] - Fix incorrect output of AES-keywrap mode for in-place encryption on some platforms. - Fix the gcry_mpi_ec_curve_point point validation function. - Fix rare assertion failure in gcry_prime_check. Release info at . We also released a new version of the older 1.7 branch with similar fixes. Comments on the attack ====================== Details on CVE-2018-0495 can be found in the paper "Return of the Hidden Number Problem" which can be downloaded from the advisory page . See for a timeline. One user of Libgcrypt is GnuPG, thus a quick comment: GnuPG does not use the vulenrable ECDSA signatures by default. Further, it is much harder to mount such an attack against an offline protocol like OpenPGP than against online protocols like TLS. Anyway, we also released a new Windows installer for GnuPG 2.2.8 featuring the fixed Libgcrypt version. That installer is linked from the usual download page and a new Gpg4win version will be released soon. Download ======== Source code is hosted at the GnuPG FTP server and its mirrors as listed at . On the primary server the source tarball and its digital signature are: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.3.tar.bz2 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.3.tar.bz2.sig or gzip compressed: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.3.tar.gz https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.3.tar.gz.sig The URLs for the older 1.7 branch are: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.10.tar.bz2 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.10.tar.bz2.sig https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.10.tar.gz https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.10.tar.gz.sig In order to check that the version of Libgcrypt you downloaded is an original and unmodified file please follow the instructions found at . In short, you may use one of the following methods: - Check the supplied OpenPGP signature. For example to check the signature of the file libgcrypt-1.8.3.tar.bz2 you would use this command: gpg --verify libgcrypt-1.8.3.tar.bz2.sig libgcrypt-1.8.3.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See the end of this mail for information on the signing keys. - If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file libgcrypt-1.8.3.tar.bz2, you run the command like this: sha1sum libgcrypt-1.8.3.tar.bz2 and check that the output matches the first line from the this list: 13bd2ce69e59ab538e959911dfae80ea309636e3 libgcrypt-1.8.3.tar.bz2 3b4d23db99ef13e6e305f536f009d9de8f5d0535 libgcrypt-1.8.3.tar.gz 66902603f7b6ad62c72db868d93b1772ac2a1afa libgcrypt-1.7.10.tar.bz2 a0aaea0c514c62de8533a955631134bc57f2e552 libgcrypt-1.7.10.tar.gz You should also verify that the checksums above are authentic by matching them with copies of this announcement. Those copies can be found at other mailing lists, web sites, and search engines. Copying ======= Libgcrypt is distributed under the terms of the GNU Lesser General Public License (LGPLv2.1+). The helper programs as well as the documentation are distributed under the terms of the GNU General Public License (GPLv2+). The file LICENSES has notices about contributions that require that these additional notices are distributed. Support ======= For help on developing with Libgcrypt you should read the included manual and optional ask on the gcrypt-devel mailing list [1]. A listing with commercial support offers for Libgcrypt and related software is available at the GnuPG web site [2]. If you are a developer and you may need a certain feature for your project, please do not hesitate to bring it to the gcrypt-devel mailing list for discussion. Thanks ====== Maintenance and development of GnuPG is mostly financed by donations. The GnuPG project currently employs one full-time developer and two contractors. They all work exclusively on GnuPG and closely related software like Libgcrypt, GPGME, and GPA. We have to thank all the people who helped the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Special thanks to Keegan Ryan of NCC Group for his proper handling of the disclosure. Many thanks to our numerous financial supporters, both corporate and individuals. Without you it would not be possible to keep GnuPG in a good shape and address all the small and larger requests made by our users. Thanks. Happy hacking, Your GnuPG hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users'at'gnupg.org mailing list. p.p.s List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: rsa2048 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048 2014-10-29 [expires: 2020-10-30] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa3072 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) The keys are available at and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From gnupg-users at spodhuis.org Thu Jun 14 05:22:19 2018 From: gnupg-users at spodhuis.org (Phil Pennock) Date: Wed, 13 Jun 2018 23:22:19 -0400 Subject: Problem refreshing keys In-Reply-To: <20180613095239.00006e1b@seibercom.net> References: <20180612100520.0000230c@seibercom.net> <20180612204224.GA13636@osmium.lan> <20180612182340.00005bdc@seibercom.net> <87po0ubyz3.fsf@wheatstone.g10code.de> <20180613095239.00006e1b@seibercom.net> Message-ID: <20180614032218.GA40449@osmium.lan> On 2018-06-13 at 09:52 -0400, Jerry wrote: > On Wed, 13 Jun 2018 15:25:04 +0200, Werner Koch stated: > >The common problem on Windows: You can't use ' to quote; we Unix folks > >always forget about that. Use Bah, I just didn't know. :D I suspected though, which is why I mentioned typing interactively as a fallback. > gpg-connect-agent --dirmngr "KEYSERVER --hosttable" /bye > S # hosttable (idx, ipv6, ipv4, dead, name, time): > S # 0 hkps.pool.sks-keyservers.net (216.66.15.2) > OK > > Is that what it should be reporting? What version is it? Is there a newer version available? gpg-connect-agent --dirmngr "GETINFO version" /bye There have been a bunch of fixes for various DNS issues with dirmngr, I would expect to see something showing that it's a pool. You're talking to zimmermann.mayfirst.org, which works fine; I just overrode DNS for the pool and made sure that hkps.pool.sks-keyservers.net only reached that IP (/etc/hosts override) and I was able to retrieve a key fine, after which: > KEYSERVER --hosttable S # hosttable (idx, ipv6, ipv4, dead, name, time): S # 0 hkps.pool.sks-keyservers.net S # . hkps.pool.sks-keyservers.net S # . --> 1* S # 1 4 216.66.15.2 (hkps.pool.sks-keyservers.net) OK I suspect that you have an old dirmngr and the problems are fixed with a newer release of gpg4win. -Phil From jerry at seibercom.net Thu Jun 14 12:24:00 2018 From: jerry at seibercom.net (Jerry) Date: Thu, 14 Jun 2018 06:24:00 -0400 Subject: Problem refreshing keys In-Reply-To: <20180614032218.GA40449@osmium.lan> References: <20180612100520.0000230c@seibercom.net> <20180612204224.GA13636@osmium.lan> <20180612182340.00005bdc@seibercom.net> <87po0ubyz3.fsf@wheatstone.g10code.de> <20180613095239.00006e1b@seibercom.net> <20180614032218.GA40449@osmium.lan> Message-ID: <20180614062400.0000155f@seibercom.net> On Wed, 13 Jun 2018 23:22:19 -0400, Phil Pennock stated: >On 2018-06-13 at 09:52 -0400, Jerry wrote: >> On Wed, 13 Jun 2018 15:25:04 +0200, Werner Koch stated: >> >The common problem on Windows: You can't use ' to quote; we Unix folks >> >always forget about that. Use > >Bah, I just didn't know. :D I suspected though, which is why I >mentioned typing interactively as a fallback. > >> gpg-connect-agent --dirmngr "KEYSERVER --hosttable" /bye >> S # hosttable (idx, ipv6, ipv4, dead, name, time): >> S # 0 hkps.pool.sks-keyservers.net (216.66.15.2) >> OK >> >> Is that what it should be reporting? > >What version is it? Is there a newer version available? > > gpg-connect-agent --dirmngr "GETINFO version" /bye > >There have been a bunch of fixes for various DNS issues with dirmngr, I >would expect to see something showing that it's a pool. > >You're talking to zimmermann.mayfirst.org, which works fine; I just >overrode DNS for the pool and made sure that >hkps.pool.sks-keyservers.net only reached that IP (/etc/hosts override) >and I was able to retrieve a key fine, after which: > >> KEYSERVER --hosttable >S # hosttable (idx, ipv6, ipv4, dead, name, time): >S # 0 hkps.pool.sks-keyservers.net >S # . hkps.pool.sks-keyservers.net >S # . --> 1* >S # 1 4 216.66.15.2 (hkps.pool.sks-keyservers.net) >OK > >I suspect that you have an old dirmngr and the problems are fixed with a >newer release of gpg4win. > >-Phil gpg-connect-agent --dirmngr "GETINFO version" /bye gpg-connect-agent: no running Dirmngr - starting 'C:\Program Files (x86)\Gpg4win\..\GnuPG\bin\dirmngr.exe' gpg-connect-agent: waiting for the dirmngr to come up ... (5s) gpg-connect-agent: waiting for the dirmngr to come up ... (4s) gpg-connect-agent: connection to the dirmngr established D 2.2.7 OK I have Gpg4win Version 3.1.1 (2018-05-03) installed. That is supposed to be the latest version. -- Jerry From aajaxx at gmail.com Thu Jun 14 13:50:14 2018 From: aajaxx at gmail.com (Ajax) Date: Thu, 14 Jun 2018 11:50:14 +0000 Subject: Is something not right with my ~/.gnupg/pubring.kbx In-Reply-To: References: Message-ID: On Fri, Jun 8, 2018 at 8:21 PM, Ajax wrote: > Most gpg commands give me something like this: > > $ gpg -Kv > gpg: using classic trust model > gpg: keydb_search failed: Invalid value > gpg: Oops: keyid_from_fingerprint: no pubkey > ~/.gnupg/pubring.kbx > > Followed by what appears to me to be normal output. > > I also see: > > $ kbxutil --stats ~/.gnupg/pubring.kbx > Total number of blobs: 600 > header: 1 > empty: 0 > openpgp: 599 > x509: 0 > non flagged: 599 > secret flagged: 0 > ephemeral flagged: 0 > > What should I do to clear the Invalid value and no pubkey? > > I only saw this problem after upgrading from gpg 1 to gpg2 and using the > given script to migrate from pubring.gpg to pubring.kbx. > > These outputs seem to throw a monkey wrench into some scripts such as, for > example, with pass generate -i > > This is gpg 2.1.18 atop Debian stretch and Linux 4.9.0-6-amd64, > > Thank you. > Are there no sugestions on how I should try to eliminate the indication of no pub key althoug gpg -k shows my public keys? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralph at inputplus.co.uk Thu Jun 14 13:56:05 2018 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Thu, 14 Jun 2018 12:56:05 +0100 Subject: Silencing MDC Warning with gnupg 2.2.8. Message-ID: <20180614115605.4FD1F1FC0C@orac.inputplus.co.uk> Hi, With the arrival of gnupg 2.2.8-1 on Arch Linux this command applied to members of an archive of files on read-only media fails because they old enough not to have Modification Detection Codes. gpg -q --batch --no-mdc-warning -d --passphrase-fd 0 foo.gpg I see that --ignore-mdc-error downgrades the error to a warning allowing the decrypted content to appear on stdout, but unfortunately for me --no-mdc-warning is now a no-op and so doesn't work in concert with --ignore-mdc-error to silence the warning. It seems from skimming the source that my only option is to expect and remove the MDC warning from stderr, allowing the rest of stderr's content to pass? Downstream of this command is unhappy otherwise. gpg(1) still documents --force-mdc and --disable-mdc, saying they're now no-ops, but --no-mdc-warning is undocumented despite still being accepted and also a no-op. This hampers investigating why --no-mdc-warning isn't working. BTW, 2.2.8's `NEWS' has `--no-mdc-warn', but the option ends in `warning' and so my searches didn't find the news item. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy From wk at gnupg.org Thu Jun 14 17:20:43 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 14 Jun 2018 17:20:43 +0200 Subject: Silencing MDC Warning with gnupg 2.2.8. In-Reply-To: <20180614115605.4FD1F1FC0C@orac.inputplus.co.uk> (Ralph Corderoy's message of "Thu, 14 Jun 2018 12:56:05 +0100") References: <20180614115605.4FD1F1FC0C@orac.inputplus.co.uk> Message-ID: <87wov18kdw.fsf@wheatstone.g10code.de> On Thu, 14 Jun 2018 13:56, ralph at inputplus.co.uk said: > I see that --ignore-mdc-error downgrades the error to a warning allowing Right, this is the suggest method to decrypt old mails. > --no-mdc-warning is now a no-op and so doesn't work in concert with Right, this is on purpose. The warning is important to educate users. > remove the MDC warning from stderr, allowing the rest of stderr's > content to pass? Downstream of this command is unhappy otherwise. Why do you need stderr at all? These are diagnositics for human consumption. And, as I said, we want that the warning show ups if the override option is enabled. > gpg(1) still documents --force-mdc and --disable-mdc, saying they're now > no-ops, but --no-mdc-warning is undocumented despite still being > accepted and also a no-op. This hampers investigating why There is no reason to document a dummy option which never affected the behaviour of gpg. This is in contrast to the other mentioned NOPs. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From konstantin at linuxfoundation.org Thu Jun 14 20:10:56 2018 From: konstantin at linuxfoundation.org (Konstantin Ryabitsev) Date: Thu, 14 Jun 2018 14:10:56 -0400 Subject: buildroot INSTALL_PREFIX and hardcoded paths Message-ID: <20180614181056.GA18132@chatter> Hello: I'm trying to package a static build of gnupg22 so I don't have to copy things manually to each CentOS-7 system where I need ECC crypto support. I'm using the following to build gnupg-2.2.8 inside the RPM: make -f build-aux/speedo.mk STATIC=1 CUSTOM_SWDB=1 \ INSTALL_PREFIX=%{buildroot}/opt/gnupg22 this-native RPM needs to "install" things into a buildroot, so in the above case, %{buildroot} is /buildroot/build/BUILDROOT/gnupg22-static-2.2.8-2.x86_64. Of course, this means that gpg and other binaries expect to call gpg-agent, dirmngr, and other auxiliary programs in /buildroot/build/BUILDROOT/gnupg22-static-2.2.8-2.x86_64/opt/gnupg22/bin instead of just /opt/gnupg22. Is there a simple solution to this? I know it's not the intended purpose of speedo.mk, but it's convenient to use it in my case, if only I could teach it to distinguish between where things are during build and where they will be after installation. Currently, I work around this by setting agent-program and dirmngr-program in gpg.conf. Thanks for any suggestions! Best, Konstantin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From ralph at inputplus.co.uk Fri Jun 15 12:23:56 2018 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Fri, 15 Jun 2018 11:23:56 +0100 Subject: Silencing MDC Warning with gnupg 2.2.8. In-Reply-To: <87wov18kdw.fsf@wheatstone.g10code.de> References: <20180614115605.4FD1F1FC0C@orac.inputplus.co.uk> <87wov18kdw.fsf@wheatstone.g10code.de> Message-ID: <20180615102356.D757B200E9@orac.inputplus.co.uk> Hi Werner, > > remove the MDC warning from stderr, allowing the rest of stderr's > > content to pass? Downstream of this command is unhappy otherwise. > > Why do you need stderr at all? These are diagnositics for human > consumption. But stderr shouldn't be ignored. Perhaps something unexpected appears on it without affecting the exit status thus downstream of the program using gpg doesn't just ignore stderr; it expects it to be empty and checks it is. Now it's not and downstream shouldn't know about a gpg-specific stderr warning so I'll modify the script calling gpg to delete one instance of that warning from stderr. Thanks for confirming there's no other way. > > gpg(1) still documents --force-mdc and --disable-mdc, saying they're > > now no-ops, but --no-mdc-warning is undocumented despite still being > > accepted and also a no-op. This hampers investigating why > > There is no reason to document a dummy option which never affected the > behaviour of gpg. It clearly did affect the behaviour else I wouldn't have needed to use it, but I've raised the point so I'll let the matter rest, along with the NEWS error. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy From gnupg-users at spodhuis.org Fri Jun 15 23:45:21 2018 From: gnupg-users at spodhuis.org (Phil Pennock) Date: Fri, 15 Jun 2018 17:45:21 -0400 Subject: dirmngr Windows DNS resolution of pools (Re: Problem refreshing keys) In-Reply-To: <20180614062400.0000155f@seibercom.net> References: <20180612100520.0000230c@seibercom.net> <20180612204224.GA13636@osmium.lan> <20180612182340.00005bdc@seibercom.net> <87po0ubyz3.fsf@wheatstone.g10code.de> <20180613095239.00006e1b@seibercom.net> <20180614032218.GA40449@osmium.lan> <20180614062400.0000155f@seibercom.net> Message-ID: <20180615214521.GA68832@osmium.lan> On 2018-06-14 at 06:24 -0400, Jerry wrote: > gpg-connect-agent --dirmngr "GETINFO version" /bye > gpg-connect-agent: no running Dirmngr - starting 'C:\Program Files (x86)\Gpg4win\..\GnuPG\bin\dirmngr.exe' > gpg-connect-agent: waiting for the dirmngr to come up ... (5s) > gpg-connect-agent: waiting for the dirmngr to come up ... (4s) > gpg-connect-agent: connection to the dirmngr established > D 2.2.7 > OK Oh dear. Sounds like there may be an issue with DNS resolution on Windows and dealing with pool hostnames. gpg-connect-agent --dirmngr KILLDIRMNGR /bye gpg-connect-agent --dirmngr > KEYSERVER --hosttable > KEYSERVER hkps://hkps.pool.sks-keyservers.net > KS_GET 0x4D1E900E14C1CC04 [warning: lots of output] > KEYSERVER --hosttable > /bye There should be around five to nine IPs returned from the last "KEYSERVER --hosttable"; if you only see one, could you also use whatever tools are used for DNS resolution at the Windows command-prompt and see what that tooling says? I can't help any further, I don't use Windows and so just can't help more (pragmatic backing out, not philosophical). In the meantime, look through and see if there's any you recognize as belonging to anyone you personally trust; look for a green box in the hkps column, it's "highly likely" (but not certain) that you can use https/hkps with just the hostname shown in that table. Configure a keyserver which works for you until such time as GnuPG's DNS resolution on Windows manages to handle pools correctly. Werner? -Phil From jmtechwork at gmail.com Sat Jun 16 19:48:41 2018 From: jmtechwork at gmail.com (Jeff Martin) Date: Sat, 16 Jun 2018 12:48:41 -0500 Subject: Hard to find alternate source of checksums In-Reply-To: <145842c2-f05e-f952-6c3b-b7d8c1507e07@gmail.com> References: <145842c2-f05e-f952-6c3b-b7d8c1507e07@gmail.com> Message-ID: NdK wrote: > GPG is usually included I'm not on Linux. I'm on macOS, which does not come with any built-in GPG. I must build GPG from source files. The only way to verify the source files in this situation (I think) is by checksum. On Mon, Jun 11, 2018 at 2:38 AM, NdK wrote: > Il 09/06/2018 19:08, Jeff Martin ha scritto: >> For a fresh install of GnuPG, I was following the integrity check >> directions. I have no prior version for GnuPG. > Why not fetch some (unrelated) live distributions, possibly some older > ones and some newer ones? > > GPG is usually included and you can use it to check the signatures. > > BYtE, > Diego -- Jeff Martin iOS Developer From jmtechwork at gmail.com Sat Jun 16 19:47:31 2018 From: jmtechwork at gmail.com (Jeff Martin) Date: Sat, 16 Jun 2018 12:47:31 -0500 Subject: Hard to find alternate source of checksums In-Reply-To: References: <145842c2-f05e-f952-6c3b-b7d8c1507e07@gmail.com> Message-ID: Lee wrote: > So you still need to find a release announcement on 2 or 3 different > sites to check the signing key fingerprints. You have hit the heart of my problem. I cannot find these 2 or 3 different sites That is why I came to this mailing list: for hints on how to find these other sites. My DDG & Goole searches were not enough. On Mon, Jun 11, 2018 at 9:14 AM, Lee wrote: > On 6/11/18, NdK wrote: >> Il 09/06/2018 19:08, Jeff Martin ha scritto: >>> For a fresh install of GnuPG, I was following the integrity check >>> directions. I have no prior version for GnuPG. >> Why not fetch some (unrelated) live distributions, possibly some older >> ones and some newer ones? >> >> GPG is usually included and you can use it to check the signatures. > > If you're not trusting the checksums listed on the website you're not > trusting the signing key fingerprints listed on the site either. So > you still need to find a release announcement on 2 or 3 different > sites to check the signing key fingerprints. And know enough to make > sure the auto key retrieval function in GPG is turned off in your live > distro > > Lee -- Jeff Martin iOS Developer From ndk.clanbo at gmail.com Sun Jun 17 10:31:49 2018 From: ndk.clanbo at gmail.com (NdK) Date: Sun, 17 Jun 2018 10:31:49 +0200 Subject: Hard to find alternate source of checksums In-Reply-To: References: <145842c2-f05e-f952-6c3b-b7d8c1507e07@gmail.com> Message-ID: <6b10135b-25e7-6099-25ed-340babb0ab02@gmail.com> Il 16/06/2018 19:48, Jeff Martin ha scritto: > I'm not on Linux. I'm on macOS, which does not come with any built-in > GPG. I must build GPG from source files. The only way to verify the > source files in this situation (I think) is by checksum. You can just fire up a VM booting with an "old enough" distro that you can assume has not been tampered with. Maybe one from an old CD. Once you've bootstrapped the system, it all becomes easy :) BYtE, Diego From felix at crowfix.com Mon Jun 18 00:20:23 2018 From: felix at crowfix.com (felix at crowfix.com) Date: Sun, 17 Jun 2018 15:20:23 -0700 Subject: Upgrading 2.0.20 to 2.2.24 Message-ID: <20180617222023.GA8473@crowfix.com> I have a seldom-used need to encrypt a few files, and the last time I did was on a gentoo system running 2.0.20. gpg -e dest -r felix at crowfix.com I have migrated the .gnupg dir to an Ubuntu 18.04 system running 2.2.24, and the gpg command seems to have mutated. The gentoo 2.0.20 command can decrypt what the Ubuntu 2.2.24 command encrypts. But the Ubuntu 2.2.24 command will not decrypt either what it just encrypted or what the gentoo 2.0.20 command encrypted: gpg: encrypted with 2048-bit ELG key, ID 18DCDD20A3362105, created yyyy-mm-dd "Felix Finch (Scarecrow Repairman) " gpg: decryption failed: No secret key The enceyption command also seems pickier: gpg: 18DCDD20A3362105: There is no assurance this key belongs to the named user sub elg2048/18DCDD20A3362105 1999-12-06 Felix Finch (Scarecrow Repairman) Primary key fingerprint: E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 Subkey fingerprint: 1A59 C8A1 81FB 6780 641C D17E 18DC DD20 A336 2105 It is NOT certain that the key belongs to the person named in the user ID. If you *really* know what you are doing, you may answer the next question with yes. Use this key anyway? (y/N) Can someone offer an explanation so I don't have to dredge through a zillion changelogs to see why 2.2.24 is pickier? What does it mean to say there is no secret key? -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman & wood chipper / felix at crowfix.com GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o From ralph at inputplus.co.uk Mon Jun 18 07:40:02 2018 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Mon, 18 Jun 2018 06:40:02 +0100 Subject: Upgrading 2.0.20 to 2.2.24 In-Reply-To: <20180617222023.GA8473@crowfix.com> References: <20180617222023.GA8473@crowfix.com> Message-ID: <20180618054002.6FBF6200E7@orac.inputplus.co.uk> Hi Felix, > gpg -e dest -r felix at crowfix.com ... > gpg: encrypted with 2048-bit ELG key, ID 18DCDD20A3362105, created yyyy-mm-dd > "Felix Finch (Scarecrow Repairman) " > gpg: decryption failed: No secret key The key for recipient felix at crowfix.com that was used to encrypt is not on the machine that's decrypting. See the --list*keys options in gpg(1). --export and --import could also be useful. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy From skquinn at rushpost.com Mon Jun 18 07:44:14 2018 From: skquinn at rushpost.com (Shawn K. Quinn) Date: Mon, 18 Jun 2018 00:44:14 -0500 Subject: Upgrading 2.0.20 to 2.2.24 In-Reply-To: <20180617222023.GA8473@crowfix.com> References: <20180617222023.GA8473@crowfix.com> Message-ID: On 06/17/2018 05:20 PM, felix at crowfix.com wrote: > gpg: encrypted with 2048-bit ELG key, ID 18DCDD20A3362105, created yyyy-mm-dd > "Felix Finch (Scarecrow Repairman) " > gpg: decryption failed: No secret key The format secret keys are stored in changed between 2.0.x and 2.1.x. It is possible that 2.2.x no longer has the code in it to migrate to the new format, in which case you might need to import secring.gpg manually and set the trust to ultimate manually as well. -- Shawn K. Quinn http://www.rantroulette.com http://www.skqrecordquest.com From wk at gnupg.org Mon Jun 18 08:36:38 2018 From: wk at gnupg.org (Werner Koch) Date: Mon, 18 Jun 2018 08:36:38 +0200 Subject: Upgrading 2.0.20 to 2.2.24 In-Reply-To: (Shawn K. Quinn's message of "Mon, 18 Jun 2018 00:44:14 -0500") References: <20180617222023.GA8473@crowfix.com> Message-ID: <87wouweh3d.fsf@wheatstone.g10code.de> On Mon, 18 Jun 2018 07:44, skquinn at rushpost.com said: > The format secret keys are stored in changed between 2.0.x and 2.1.x. It > is possible that 2.2.x no longer has the code in it to migrate to the 2.2 still has the migration code. However, once a migration is done it will not be done again. Thus adding a new key with an old version of gpg at least the secret key won't show up in a newer gpg version. > new format, in which case you might need to import secring.gpg manually > and set the trust to ultimate manually as well. Right. The official way to do this is to run gpg --export-secret-key KEYID >FILE using the old version of gpg and then to run gpg --import From felix at crowfix.com Mon Jun 18 15:06:22 2018 From: felix at crowfix.com (felix at crowfix.com) Date: Mon, 18 Jun 2018 06:06:22 -0700 Subject: Upgrading 2.0.20 to 2.2.24 In-Reply-To: <87wouweh3d.fsf@wheatstone.g10code.de> References: <20180617222023.GA8473@crowfix.com> <87wouweh3d.fsf@wheatstone.g10code.de> Message-ID: <20180618130622.GB8473@crowfix.com> On Mon, Jun 18, 2018 at 08:36:38AM +0200, Werner Koch wrote: > On Mon, 18 Jun 2018 07:44, skquinn at rushpost.com said: > > > The format secret keys are stored in changed between 2.0.x and 2.1.x. It > > is possible that 2.2.x no longer has the code in it to migrate to the > > 2.2 still has the migration code. However, once a migration is done it > will not be done again. Thus adding a new key with an old version of gpg > at least the secret key won't show up in a newer gpg version. > > > new format, in which case you might need to import secring.gpg manually > > and set the trust to ultimate manually as well. > > Right. The official way to do this is to run > gpg --export-secret-key KEYID >FILE > using the old version of gpg and then to run > gpg --import using the new version of gpg. It is also possible to delete the file > ~/.gnupg/.gpg-v21-migrated so that a migration will be triggered again. Thanks -- but that didn't do the trick. $ gpg --list-secret-keys gpg: starting migration from earlier GnuPG versions gpg: porting secret keys from '/home/felix/.gnupg/secring.gpg' to gpg-agent gpg: key 783876E9182E8151: secret key imported gpg: key 44752F7C4D3D351A: secret key imported gpg: migration succeeded $ gpg --list-secret-keys $ Says it imported the secret keys, but doesn't show them. Don't think it's permissions; the only read-only files are options, gpg-agent.conf, and .gpg-agent-info. Killed gpg-agent; it restarted fine, but gpg still doesn't show the secret keys. I'll have to try the export-import angle later; the old machine is old enough that physically copying files requires some legwork. -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman & wood chipper / felix at crowfix.com GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o From kristian.fiskerstrand at sumptuouscapital.com Mon Jun 18 15:19:53 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Mon, 18 Jun 2018 15:19:53 +0200 Subject: Upgrading 2.0.20 to 2.2.24 In-Reply-To: <20180618130622.GB8473@crowfix.com> References: <20180617222023.GA8473@crowfix.com> <87wouweh3d.fsf@wheatstone.g10code.de> <20180618130622.GB8473@crowfix.com> Message-ID: On 06/18/2018 03:06 PM, felix at crowfix.com wrote: > Says it imported the secret keys, but doesn't show them. Any chance they are expired? Try playing with --list-options, in particular the show-unusable-* variants Are they listed with --list-keys ? Try importing the public keyring separately, in case there is sync issue and that has been updated without secring being updated. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "Excellence is not a singular act but a habit. You are what you do repeatedly." (Shaquille O'Neal) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From felix at crowfix.com Mon Jun 18 15:49:02 2018 From: felix at crowfix.com (felix at crowfix.com) Date: Mon, 18 Jun 2018 06:49:02 -0700 Subject: Upgrading 2.0.20 to 2.2.24 In-Reply-To: References: <20180617222023.GA8473@crowfix.com> <87wouweh3d.fsf@wheatstone.g10code.de> <20180618130622.GB8473@crowfix.com> Message-ID: <20180618134902.GD8473@crowfix.com> On Mon, Jun 18, 2018 at 03:19:53PM +0200, Kristian Fiskerstrand wrote: > On 06/18/2018 03:06 PM, felix at crowfix.com wrote: > > Says it imported the secret keys, but doesn't show them. > > Any chance they are expired? Try playing with --list-options, in > particular the show-unusable-* variants > > Are they listed with --list-keys ? >From the 2.0.20 machiine: $ gpg --list-secret-keys /home/felix/.gnupg/secring.gpg ------------------------------ sec 1024D/182E8151 1999-12-06 uid Felix Finch (Scarecrow Repairman) ssb 2048g/A3362105 1999-12-06 sec 1024D/4D3D351A 1999-12-06 uid Felix Finch (Remote Access) ssb 1024g/C2422DAD 1999-12-06 $ gpg --list-keys /home/felix/.gnupg/pubring.gpg ------------------------------ pub 1024D/182E8151 1999-12-06 uid Felix Finch (Scarecrow Repairman) sub 2048g/A3362105 1999-12-06 pub 1024D/4D3D351A 1999-12-06 uid Felix Finch (Remote Access) sub 1024g/C2422DAD 1999-12-06 $ ls -al .gnupg total 38 drwx------ 4 felix users 360 Jun 18 05:48 . drwx------ 68 felix users 5744 Jun 18 00:00 .. -r-------- 1 felix users 42 Sep 3 2008 gpg-agent.conf -r-------- 1 felix users 51 Sep 3 2008 .gpg-agent-info -r-------- 1 felix users 2844 Nov 26 2004 options drwx------ 2 felix users 48 Jun 7 2007 private-keys-v1.d -rw------- 1 felix users 2088 Jun 7 2012 pubring.gpg -rw------- 1 felix users 2072 Dec 5 1999 pubring.gpg~ -rw------- 1 felix users 600 Jun 17 15:08 random_seed drwx------ 2 felix users 152 Sep 3 2008 RCS -rw------- 1 felix users 2836 Dec 5 1999 secring.gpg -rw------- 1 felix users 1280 Jun 7 2012 trustdb.gpg $ >From the 2.2.24 machine: $ gpg --list-secret-keys $ gpg --list-keys /home/felix/.gnupg/pubring.kbx ------------------------------ pub dsa1024 1999-12-06 [SCA] E9874493C860246C3B1E6477783876E9182E8151 uid [ unknown] Felix Finch (Scarecrow Repairman) sub elg2048 1999-12-06 [E] pub dsa1024 1999-12-06 [SCA] 7689998F39D1EA2F37AECF5844752F7C4D3D351A uid [ unknown] Felix Finch (Remote Access) sub elg1024 1999-12-06 [E] $ ls -al .gnupg total 192 drwx------ 4 felix felix 4096 Jun 18 05:52 . drwx------ 75 felix felix 32768 Jun 17 12:37 .. -r-------- 1 felix felix 42 Sep 3 2008 gpg-agent.conf -r-------- 1 felix felix 51 Sep 3 2008 .gpg-agent-info -rw------- 1 felix felix 0 Jun 18 05:52 .gpg-v21-migrated -r-------- 1 felix felix 2844 Nov 26 2004 options drwx------ 2 felix felix 4096 Oct 22 2017 private-keys-v1.d -rw------- 1 root root 12226 Oct 22 2017 pubring.gpg -rw------- 1 root root 12226 Oct 22 2017 pubring.gpg~ -rw------- 1 felix felix 2484 Jun 17 13:44 pubring.kbx -rw------- 1 felix felix 1385 Jun 17 13:44 pubring.kbx~ -rw------- 1 felix felix 600 Jun 17 15:17 random_seed drwx------ 2 felix felix 4096 Sep 3 2008 RCS -rw------- 1 felix felix 2836 Dec 5 1999 secring.gpg -rw------- 1 felix felix 1280 Jun 17 14:54 trustdb.gpg $ -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman & wood chipper / felix at crowfix.com GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o From juergen at bruckner.tk Mon Jun 18 18:23:50 2018 From: juergen at bruckner.tk (Juergen BRUCKNER) Date: Mon, 18 Jun 2018 18:23:50 +0200 Subject: gnupg.org Listserver maybe misconfigured? Message-ID: <7ad19890-d349-e0fc-04af-538b45116a43@bruckner.tk> Hello guys, could it be happen that the Server for the GnuPG.org Mailinglists is kinda misconfigured? My weekly DMARC-Report says that gnupg.org sent in sum 477 Mails in the name of the Domain 'bruckner.tk' last week. ---snip--- gnupg.org 217.69.76.57 Total SPF Aligned DKIM Aligned 251 0% 0% 2001:aa8:fff1:2100::57 Total SPF Aligned DKIM Aligned 226 0% 0% ---snip--- Any Ideas? best regards Juergen -- Juergen M. Bruckner juergen at bruckner.tk -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3894 bytes Desc: S/MIME Cryptographic Signature URL: From markr at signal100.com Mon Jun 18 19:18:36 2018 From: markr at signal100.com (Mark Rousell) Date: Mon, 18 Jun 2018 18:18:36 +0100 Subject: gnupg.org Listserver maybe misconfigured? In-Reply-To: <7ad19890-d349-e0fc-04af-538b45116a43@bruckner.tk> References: <7ad19890-d349-e0fc-04af-538b45116a43@bruckner.tk> Message-ID: <5B27E96C.4010301@signal100.com> On 18/06/2018 17:23, Juergen BRUCKNER wrote: > Hello guys, > > could it be happen that the Server for the GnuPG.org Mailinglists is > kinda misconfigured? > > My weekly DMARC-Report says that gnupg.org sent in sum 477 Mails in the > name of the Domain 'bruckner.tk' last week. > > ---snip--- > gnupg.org > 217.69.76.57 > Total SPF Aligned DKIM Aligned > 251 0% 0% > > 2001:aa8:fff1:2100::57 > > > Total SPF Aligned DKIM Aligned > 226 0% 0% > ---snip--- > > Any Ideas? Isn't that expected and correct behaviour? You post to the list and the list server forwards your messages (as well as the messages of all other posters) to list members. The From address of your forwarded emails is quite correctly shown as the From address of the emails as you sent them. This is exactly how mail lists have worked for decades and is entirely normal and correct. However, due to problems with domains that advertise p=reject DMARC policies, more and more mail lists are now choosing to munge From addresses to show messages as being sent from the list address (e.g. "From: Juergen BRUCKNER via GnuPG Users " instead of the correct "From: Juergen BRUCKNER ") but this list does not do this. If this was done, it would prevent your list-forwarded emails showing up in your DMARC report. I note that your bruckner.tk domain appears to have a p=none policy so, if I understand all this correctly, it should not matter to you. In short, there is nothing to worry about (as far as I can see). Everything is working as it should. -- Mark Rousell -------------- next part -------------- An HTML attachment was scrubbed... URL: From juergen at bruckner.tk Mon Jun 18 19:24:50 2018 From: juergen at bruckner.tk (Juergen BRUCKNER) Date: Mon, 18 Jun 2018 19:24:50 +0200 Subject: gnupg.org Listserver maybe misconfigured? In-Reply-To: <5B27E96C.4010301@signal100.com> References: <7ad19890-d349-e0fc-04af-538b45116a43@bruckner.tk> <5B27E96C.4010301@signal100.com> Message-ID: Hello Mark! Thank you very much for your answer and clarificattion. Am 2018-06-18 um 19:18 schrieb Mark Rousell: > I note that your bruckner.tk domain appears to have a p=none policy so, > if I understand all this correctly, it should not matter to you. > > In short, there is nothing to worry about (as far as I can see). > Everything is working as it should. best regards Juergen -- Juergen M. Bruckner juergen at bruckner.tk -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3894 bytes Desc: S/MIME Cryptographic Signature URL: From markr at signal100.com Mon Jun 18 20:39:32 2018 From: markr at signal100.com (Mark Rousell) Date: Mon, 18 Jun 2018 19:39:32 +0100 Subject: gnupg.org Listserver maybe misconfigured? In-Reply-To: References: <7ad19890-d349-e0fc-04af-538b45116a43@bruckner.tk> <5B27E96C.4010301@signal100.com> Message-ID: <5B27FC64.1010607@signal100.com> On 18/06/2018 18:24, Juergen BRUCKNER wrote: > Hello Mark! > > Thank you very much for your answer and clarificattion. My pleasure. -- Mark Rousell -------------- next part -------------- An HTML attachment was scrubbed... URL: From mangocats at gmail.com Tue Jun 19 03:34:09 2018 From: mangocats at gmail.com (Mike Inman) Date: Mon, 18 Jun 2018 21:34:09 -0400 Subject: gpgme_op_delete_ext flag GPGME_DELETE_FORCE not working? Message-ID: Hi, I've been trying to use the GPGME_DELETE_FORCE flag in gpgme_op_delete_ext, but I'm still getting not one, but two "Do you really want to delete..." prompts popping up, one for the secret key, one for the sub-key. I am using GPGme version 1.11.1 in combination with gpg 2.2.8 (as confirmed by runtime query of the versions) built from the git repos by checking out the following tags:git checkout npth-1.5 git checkout libgpg-error-1.31 git checkout libgcrypt-1.8.2 git checkout libksba-1.3.5 git checkout libassuan-2.5.1 git checkout gnupg-2.2.8 git checkout gpgme-1.11.1 I found this reference in the gpgme 1.10.0 changelog: *src/engine-gpg.c (gpg_delete): Likewise. Implement GPGME_DELETE_FORCE.* * the key deletes from the keyring as expected, but the behavior is as if the flag has not been implemented in 1.11.1. Should I expect the GPGME_DELETE_FORCE flag to work as described here? *gpgme_op_delete_ext* *(gpgme_ctx_t ctx, const gpgme_key_t key, unsigned int flags)* SINCE: 1.9.1 The function gpgme_op_delete_ext deletes the key key from the key ring of the crypto engine used by ctx. flags can be set to the bit-wise OR of the following flags: GPGME_DELETE_ALLOW_SECRET SINCE: 1.9.1 If not set, only public keys are deleted. If set, secret keys are deleted as well, if that is supported. GPGME_DELETE_FORCE SINCE: 1.9.1 If set, the user is not asked to confirm the deletion. Thanks, -------------- next part -------------- An HTML attachment was scrubbed... URL: From felix at crowfix.com Tue Jun 19 22:31:58 2018 From: felix at crowfix.com (felix at crowfix.com) Date: Tue, 19 Jun 2018 13:31:58 -0700 Subject: Upgrading 2.0.20 to 2.2.24 In-Reply-To: <87wouweh3d.fsf@wheatstone.g10code.de> References: <20180617222023.GA8473@crowfix.com> <87wouweh3d.fsf@wheatstone.g10code.de> Message-ID: <20180619203158.GF8473@crowfix.com> On Mon, Jun 18, 2018 at 08:36:38AM +0200, Werner Koch wrote: > On Mon, 18 Jun 2018 07:44, skquinn at rushpost.com said: > > > The format secret keys are stored in changed between 2.0.x and 2.1.x. It > > is possible that 2.2.x no longer has the code in it to migrate to the > > 2.2 still has the migration code. However, once a migration is done it > will not be done again. Thus adding a new key with an old version of gpg > at least the secret key won't show up in a newer gpg version. > > > new format, in which case you might need to import secring.gpg manually > > and set the trust to ultimate manually as well. > > Right. The official way to do this is to run > gpg --export-secret-key KEYID >FILE > using the old version of gpg and then to run > gpg --import using the new version of gpg. It is also possible to delete the file > ~/.gnupg/.gpg-v21-migrated so that a migration will be triggered again. I tried both these steps, and neither changed anything. Import said it imported, but I have a saved copy of .gnupg, and there was no difference after the import. The re-migration recreated the .gpg-v21-migrated file, but also made no difference. Still can't see the secret keys or decrypt anything. -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman & wood chipper / felix at crowfix.com GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o From psusi at ubuntu.com Tue Jun 19 21:05:15 2018 From: psusi at ubuntu.com (Phillip Susi) Date: Tue, 19 Jun 2018 15:05:15 -0400 Subject: Won't recognize my secret key Message-ID: <17b90844-163a-f4bd-223b-65665b576c39@ubuntu.com> gpg keeps telling me that I have no secret key. Even after I deleted the .gnupg directory and copied the pubring and secring from another computer where it works, this system keeps saying I have no secret keys. Why does it keep throwing out my secret keys? Working system: C:\Users\psusi\AppData\Roaming\gnupg>gpg --version gpg (GnuPG) 2.0.28 (Gpg4win 2.2.5) C:\Users\psusi\AppData\Roaming\gnupg>gpg -K C:/Users/psusi/AppData/Roaming/gnupg/secring.gpg ------------------------------------------------ sec# 2048R/A70FB705 2011-12-13 uid Phillip Susi uid Phillip Susi ssb 2048R/51FEF1C9 2011-12-13 ssb 2048R/FA9EEEF9 2011-12-14 ssb 2048R/3348AAF0 2013-11-26 ssb 2048R/BDCC7F92 2013-11-26 ssb 2048R/9C8E5E51 2014-10-29 ssb 2048R/93A02CCD 2014-10-29 ssb 2048R/5CBBA516 2015-10-05 ssb 2048R/10850B71 2015-10-05 ssb 2048R/6100FE84 2017-01-06 ssb 2048R/0F60068B 2017-01-06 Broken system: psusi at devserv:~$ gpg --version gpg: WARNING: unsafe permissions on homedir '/home/psusi/.gnupg' gpg (GnuPG) 2.2.4 psusi at devserv:~$ gpg -K gpg: WARNING: unsafe permissions on homedir '/home/psusi/.gnupg' /home/psusi/.gnupg/pubring.kbx ------------------------------ sec# rsa2048 2011-12-13 [SCA] 1B49F933916A37A3F45A1812015F4DD4A70FB705 uid [ultimate] Phillip Susi uid [ultimate] Phillip Susi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From mangocats at gmail.com Tue Jun 19 23:43:32 2018 From: mangocats at gmail.com (Mike Inman) Date: Tue, 19 Jun 2018 17:43:32 -0400 Subject: gpgme_op_delete_ext flag GPGME_DELETE_FORCE not working? Message-ID: As a followup: I have done some tracing of the code, found that the GPGME_DELETE_FORCE flag to gpgme_op_delete_ext causes a --yes option to be added to the gpg command. I confirmed on command line that the behavior is the same there: --yes does not suppress the "are you sure" graphic dialog boxes when deleting keys. I was able to suppress the Terminal prompts by going to --batch mode, but never the graphic dialogs when using gpg2, both the 2.2.8 which I compiled from git, nor the 2.1.11 that apparently ships with Ubuntu 16.04 by default. gpg 1.4.20 seems to never request graphic confirmation to delete keys from command line, though a --batch was required to suppress the terminal prompt. I dug a little deeper into the gpg code and found that the --yes command line flag seems to be translated to a --force option on the DELETE_KEY command passed to assuan_transact(). I found this hint in gnupg/agent/command.c: DELETE_KEY [--force|--stub-only] Delete a secret key from the key store. If --force is used and a loopback pinentry is allowed, the agent will not ask the user for confirmation. and a further breadcrumb in gpg-agent.texi @opindex no-allow-loopback-pinentry @opindex allow-loopback-pinentry Disallow or allow clients to use the loopback pinentry features; see the option @option{pinentry-mode} for details. Allow is the default. The @option{--force} option of the Assuan command @command{DELETE_KEY} is also controlled by this option: The option is ignored if a loopback pinentry is disallowed. but, I'm struggling with how to get the allow-loopback-pinentry option to the gpg-agent? It is supposed to be the default, but something seems to be defeating that in gpg2? All of this raises a related system setup question: apparently, replacing gpg 1.4.20 with gpg 2.x (as happens when building gpg from the git sources into /usr/local/lib) breaks the apt-get package management system in Ubuntu. What is the commonly practiced method (installation folders, paths, etc.) for an up-to-date build of gpg that keeps it from breaking apt-get? Thanks, -------------- next part -------------- An HTML attachment was scrubbed... URL: From 2017-r3sgs86x8e-lists-groups at riseup.net Wed Jun 20 00:55:52 2018 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Tue, 19 Jun 2018 23:55:52 +0100 Subject: gnupg.org Listserver maybe misconfigured? In-Reply-To: <5B27E96C.4010301@signal100.com> References: <7ad19890-d349-e0fc-04af-538b45116a43@bruckner.tk> <5B27E96C.4010301@signal100.com> Message-ID: <91717054.20180619235552@my_localhost_LG> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Monday 18 June 2018 at 6:18:36 PM, in , Mark Rousell wrote:- > However, due to problems with domains that > advertise p=reject > DMARC policies, more and more mail lists are now > choosing to > munge From addresses to show messages as being > sent from the > list address (e.g. "From: Juergen BRUCKNER via > GnuPG Users > " instead of the correct > "From: Juergen > BRUCKNER ") I'm glad this list doesn't follow that irritating route. One of the lists I subscribe to is a Yahoo Group that does it that way. When I view the message, the from line is:- "Member Name member_email at example.com [group_name]" but in the message list my mail client just displays group_name at yahoogroups.com. The other bit is discarded "to address the Mailsploit issues." - -- Best regards MFPA Another person's secret is like another person's money: you are not as careful with it as you are with your own -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCWymJ+F8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju +hGBAP9u2eAKIis8c/paTEA80ldsY1sRkmguRhkscwJyzNY0VQD/ZdpWpdJhPKAo uEoVHU4cwdUTajfm+jW6xwoZ7oKW3wCJApMEAQEKAH0WIQRSX6konxd5jbM7JygT DfUWES/A/wUCWymJ+F8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/0FjEACVq+r3vU2R+yKoh8tE4jKDPcD0 HmWsMHaes1yjWgBs6W3xdtzZlId7M6bujWHTmsrs93Hhakwu2CUiedFiIPwGocaG zOvVomkB9jxb8xzPikx0N/tnMdHBQpE56u3xRqj6iPvl/zgoFeApcvTrA6PoFboS QpLkMJtgEwWsE3pif0OPeH1EHYV6udRgKMhyo06MpXIiR9mhfOO152X6Bg1lRWpR PucY5nr3z18TyguDFNLORTnU1kKdAg/grCa+TLVLHPday6TBqs/diQLwMr+Jklqx JZWUaRUKu9fauZsDHPoCdAwJ9Sym6f8I0O08qKdUApzGDxoBrsbKWwaaTJ9Ay3WF cNX63Ou7SVQZGqvwhWH0BXKkEe0MXNnvydQ5KMcNxcfha5mMdwAZDfSX1Sj6yfqH vcJ9poJLkAklhGMM4UJDknOndpEfYj7f/Z+vXgD1x0nI0vjZujfWhXnF9V/Jmhvd 16jDAPGKVY/bMjTG9JiRPs8wbw36URc/mkUv2oAeiPvhYsYsm3dFKvTEPbYPEiVn 2cPLvRbMK8+DjOii4K4gHedn1eRpQmgUYOMaCg99lIwgzrA4r3zEUV8VEKN3j6LR jK2oTYsV8uN5bZ1/RNmalsRe0Z9wSauS268Kv6Qbf8+axb6stXmcng3uzCUimQqp blo1iv0Yl1bjy7IXJQ== =xOQp -----END PGP SIGNATURE----- From damien at cassou.me Wed Jun 20 11:14:28 2018 From: damien at cassou.me (Damien Cassou) Date: Wed, 20 Jun 2018 11:14:28 +0200 Subject: [paperkey] Always output "interrupt" Message-ID: <87bmc5om4r.fsf@cassou.me> Hi, The output of paperkey is just "interrupt" instead of being a printable output. I've tried to use paperkey on 2 different main private keys and failed twice. I tried with both the Fedora package and from paperkey's source. Same result in every case. System: - Fedora 28 - gpg (GnuPG) 2.2.8, libgcrypt 1.8.3 Keys: - key1: ed25519 - key2: rsa4096 Command: $ gpg2 --export-secret-key "FooBar" | paperkey -vvvv interrupt $ Best -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill From dshaw at jabberwocky.com Wed Jun 20 13:01:31 2018 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 20 Jun 2018 07:01:31 -0400 Subject: [paperkey] Always output "interrupt" In-Reply-To: <87bmc5om4r.fsf@cassou.me> References: <87bmc5om4r.fsf@cassou.me> Message-ID: On Jun 20, 2018, at 5:14 AM, Damien Cassou wrote: > > Hi, > > The output of paperkey is just "interrupt" instead of being a printable > output. I've tried to use paperkey on 2 different main private keys and > failed twice. I tried with both the Fedora package and from paperkey's > source. Same result in every case. > > System: > - Fedora 28 > - gpg (GnuPG) 2.2.8, libgcrypt 1.8.3 > > Keys: > - key1: ed25519 > - key2: rsa4096 > > Command: > $ gpg2 --export-secret-key "FooBar" | paperkey -vvvv > interrupt > $ Hi Damien, Which version of paperkey is this? The latest is 1.5 (and support for EdDSA keys was only added in that version), so if you're using an old version can you try the latest? If that doesn't resolve your problem, can you send me a sample secret key (not your real secret key, of course - just generate a dummy one) that exhibits the problem? I'll make it work. David From damien at cassou.me Wed Jun 20 17:28:00 2018 From: damien at cassou.me (Damien Cassou) Date: Wed, 20 Jun 2018 17:28:00 +0200 Subject: [paperkey] Always output "interrupt" In-Reply-To: References: <87bmc5om4r.fsf@cassou.me> Message-ID: <8736xho4u7.fsf@cassou.me> David Shaw writes: > Which version of paperkey is this? both the version from source and from Fedora package are 1.5. > If that doesn't resolve your problem, can you send me a sample secret > key (not your real secret key, of course - just generate a dummy one) > that exhibits the problem? I'll make it work. Please find attached the very secret key :-). I got it using: $ gpg2 --export-secret-key "FooBar" > /tmp/foo.key if you need it, the passphrase is "iletaitunpetithomme1". -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill -------------- next part -------------- A non-text attachment was scrubbed... Name: foo.key Type: application/octet-stream Size: 1386 bytes Desc: not available URL: From psusi at ubuntu.com Wed Jun 20 19:52:04 2018 From: psusi at ubuntu.com (Phillip Susi) Date: Wed, 20 Jun 2018 13:52:04 -0400 Subject: git repo won't build for lack of source files? Message-ID: <4dd9a7e5-ba14-b0ee-413c-271519b941bb@ubuntu.com> I cloned the git repo and checked out gnupg-2.2.4, ran ./autogen.sh, ./configure, then when I try to make, it is apparently missing some files: make[2]: Entering directory '/home/psusi/gnupg/common' make[2]: *** No rule to make target 'audit-events.h', needed by 'all'. Stop. What gives? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From psusi at ubuntu.com Wed Jun 20 20:45:44 2018 From: psusi at ubuntu.com (Phillip Susi) Date: Wed, 20 Jun 2018 14:45:44 -0400 Subject: git repo won't build for lack of source files? In-Reply-To: <4dd9a7e5-ba14-b0ee-413c-271519b941bb@ubuntu.com> References: <4dd9a7e5-ba14-b0ee-413c-271519b941bb@ubuntu.com> Message-ID: <131934c6-8e2d-5729-3057-29aec4dd29fd@ubuntu.com> On 6/20/2018 1:52 PM, Phillip Susi wrote: > I cloned the git repo and checked out gnupg-2.2.4, ran ./autogen.sh, > ./configure, then when I try to make, it is apparently missing some files: > > make[2]: Entering directory '/home/psusi/gnupg/common' > make[2]: *** No rule to make target 'audit-events.h', needed by 'all'. > Stop. > > > What gives? Apparently you have to configure with --enable-maintainer-mode to avoid this. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From psusi at ubuntu.com Wed Jun 20 21:00:27 2018 From: psusi at ubuntu.com (Phillip Susi) Date: Wed, 20 Jun 2018 15:00:27 -0400 Subject: Won't recognize my secret key In-Reply-To: <17b90844-163a-f4bd-223b-65665b576c39@ubuntu.com> References: <17b90844-163a-f4bd-223b-65665b576c39@ubuntu.com> Message-ID: On 6/19/2018 3:05 PM, Phillip Susi wrote: > gpg keeps telling me that I have no secret key. Even after I deleted > the .gnupg directory and copied the pubring and secring from another > computer where it works, this system keeps saying I have no secret keys. > Why does it keep throwing out my secret keys? I have built gnupg-2.0.31 from source and found it to work. gnupg-2.2.4 refuses to import my private keys ( but will import a newly created test key ). So something broke somewhere between 2.0 and 2.2, but apparently 2.1 was a development branch, and it likes to yell at you that you shouldn't be using production keys and refuses to import any private keys, so I can't test to see where it lost the ability to import *my* private key. Is there a way to turn off this damn protection so I can continue to bisect? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Wed Jun 20 21:17:51 2018 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 20 Jun 2018 15:17:51 -0400 Subject: [paperkey] Always output "interrupt" In-Reply-To: <8736xho4u7.fsf@cassou.me> References: <87bmc5om4r.fsf@cassou.me> <8736xho4u7.fsf@cassou.me> Message-ID: On Jun 20, 2018, at 11:28 AM, Damien Cassou wrote: > > David Shaw writes: >> Which version of paperkey is this? > > both the version from source and from Fedora package are 1.5. > >> If that doesn't resolve your problem, can you send me a sample secret >> key (not your real secret key, of course - just generate a dummy one) >> that exhibits the problem? I'll make it work. > > Please find attached the very secret key :-). I tested this on my regular development box and it worked fine. Just for completeness, I spun up a Fedora 28 VM and it worked fine there as well. It occurs to me that given the pipeline you were using, the "interrupt" error may have come from gpg2 rather than paperkey: > $ gpg2 --export-secret-key "FooBar" | paperkey -vvvv What happens if you do this: $ gpg2 --export-secret-key "FooBar" > /tmp/foo.key $ paperkey < /tmp/foo.key David From mangocats at gmail.com Thu Jun 21 00:21:54 2018 From: mangocats at gmail.com (Mike Inman) Date: Wed, 20 Jun 2018 18:21:54 -0400 Subject: git repo won't build for lack of source files? Message-ID: Are you also building the required support libraries? I have recently build 2.2.8 successfully using this set of support libs: git checkout npth-1.5 git checkout libgpg-error-1.31 git checkout libgcrypt-1.8.2 git checkout libksba-1.3.5 git checkout libassuan-2.5.1 git checkout gnupg-2.2.8 then run the following commands in each of the lib folders (in the order shown above): ./autogen.sh --force ./configure --enable-maintainer-mode make -j make check sudo make install make check is optional, but if you want to be extra sure, you can also add a --enable-all-tests to the configure of gnupg (but not the others...) It doesn't take too long to build and check them all. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mangocats at gmail.com Thu Jun 21 00:30:33 2018 From: mangocats at gmail.com (Mike Inman) Date: Wed, 20 Jun 2018 18:30:33 -0400 Subject: git repo won't build for lack of source files? Message-ID: Sorry, forgot a critical trick or maybe 2, should have just pasted the script in the first place: #!/bin/bash # # https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=README set -e export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH pushd npth ./autogen.sh --force ./configure --enable-maintainer-mode make -j make check sudo make install popd pushd libgpg-error ./autogen.sh --force ./configure --enable-maintainer-mode make -j make check sudo make install popd pushd libgcrypt ./autogen.sh --force ./configure --enable-maintainer-mode make -j make check sudo make install popd pushd libksba ./autogen.sh --force ./configure --enable-maintainer-mode make -j make check sudo make install popd pushd libassuan ./autogen.sh --force ./configure --enable-maintainer-mode make -j make check sudo make install popd pushd gnupg ./autogen.sh --force ./configure --enable-maintainer-mode --enable-all-tests --enable-gpg-is-gpg2 make -j make check sudo make install popd pushd gpgme ./autogen.sh --force ./configure --enable-maintainer-mode make -j make check sudo make install popd -------------- next part -------------- An HTML attachment was scrubbed... URL: From damien at cassou.me Thu Jun 21 07:57:19 2018 From: damien at cassou.me (Damien Cassou) Date: Thu, 21 Jun 2018 07:57:19 +0200 Subject: [paperkey] Always output "interrupt" In-Reply-To: References: <87bmc5om4r.fsf@cassou.me> <8736xho4u7.fsf@cassou.me> Message-ID: <87lgb8hebk.fsf@cassou.me> David Shaw writes: > On Jun 20, 2018, at 11:28 AM, Damien Cassou wrote: >> $ gpg2 --export-secret-key "FooBar" | paperkey -vvvv > > What happens if you do this: > > $ gpg2 --export-secret-key "FooBar" > /tmp/foo.key > $ paperkey < /tmp/foo.key You are right, paperkey works fine. The problem comes from EShell's (Emacs shell-like command interpreter) implementation of pipe apparently. Sorry for the noise. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill From wk at gnupg.org Thu Jun 21 09:55:28 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 21 Jun 2018 09:55:28 +0200 Subject: git repo won't build for lack of source files? In-Reply-To: <131934c6-8e2d-5729-3057-29aec4dd29fd@ubuntu.com> (Phillip Susi's message of "Wed, 20 Jun 2018 14:45:44 -0400") References: <4dd9a7e5-ba14-b0ee-413c-271519b941bb@ubuntu.com> <131934c6-8e2d-5729-3057-29aec4dd29fd@ubuntu.com> Message-ID: <87in6cshe7.fsf@wheatstone.g10code.de> On Wed, 20 Jun 2018 20:45, psusi at ubuntu.com said: > Apparently you have to configure with --enable-maintainer-mode to avoid > this. autogen.sh actually told you this .-) Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Thu Jun 21 10:06:23 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 21 Jun 2018 10:06:23 +0200 Subject: Upgrading 2.0.20 to 2.2.24 In-Reply-To: <20180619203158.GF8473@crowfix.com> (felix@crowfix.com's message of "Tue, 19 Jun 2018 13:31:58 -0700") References: <20180617222023.GA8473@crowfix.com> <87wouweh3d.fsf@wheatstone.g10code.de> <20180619203158.GF8473@crowfix.com> Message-ID: <87efh0sgw0.fsf@wheatstone.g10code.de> On Tue, 19 Jun 2018 22:31, felix at crowfix.com said: > I tried both these steps, and neither changed anything. Import said it > imported, but I have a saved copy of .gnupg, and there was no difference after Did it say that an secret key was imported? You check your secret keys using gpg -K [USERIDs] if you add --debug=ipc you will how gpg asks gpg-agent whether a secret key is available for a given public key. Here the so-called keygrips are used and not the fingerprints of the key. In the directory ".gnupg/private-keys-v1.d" you should find files of the form "KEYGRIP.key. These store the private keys. Do you have some? To see the keygrips of a key you used gpg --with-keygrip -k [USERIDs] Youy can used --debug=ipc also with --import which then shows how gpg sends the private keys to gpg-agent. Does it all look fine or do you see "ERR" lines? Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From psusi at ubuntu.com Thu Jun 21 17:27:05 2018 From: psusi at ubuntu.com (Phillip Susi) Date: Thu, 21 Jun 2018 11:27:05 -0400 Subject: Won't recognize my secret key In-Reply-To: References: <17b90844-163a-f4bd-223b-65665b576c39@ubuntu.com> Message-ID: <40310048-bc8d-ff65-f9f5-d3cb931ab981@ubuntu.com> Ok, so if I checkout and build 2.0.31, remove ~/.gnupg, and import my keyring, all of my private keys show up. If I check out and build 2.1.1 and run /usr/local/bin/gpg -K, it upgrades to the new key format and throws out my private keys: gpg: starting migration from earlier GnuPG versions gpg: porting secret keys from '/home/psusi/.gnupg/secring.gpg' to gpg-agent gpg: key A70FB705: secret key imported gpg: migration succeeded /home/psusi/.gnupg/pubring.gpg ------------------------------ sec# rsa2048/A70FB705 2011-12-13 uid [ unknown] Phillip Susi uid [ unknown] Phillip Susi Any suggestions on how to further debug this? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From psusi at ubuntu.com Thu Jun 21 17:32:43 2018 From: psusi at ubuntu.com (Phillip Susi) Date: Thu, 21 Jun 2018 11:32:43 -0400 Subject: Won't recognize my secret key In-Reply-To: <40310048-bc8d-ff65-f9f5-d3cb931ab981@ubuntu.com> References: <17b90844-163a-f4bd-223b-65665b576c39@ubuntu.com> <40310048-bc8d-ff65-f9f5-d3cb931ab981@ubuntu.com> Message-ID: <052c6585-15b7-7054-7a2b-2628058ee81f@ubuntu.com> I just noticed that I do have a bunch of key files in ~/.gnupg/private-keys-v1.d, even though gpg -K does not show them. Ahah, gpg -K -v shows them... it seems to think they are all expired. It lists the expiration date on my current key as 2018-1-6. I believe that was the *original* expiration date, but then I extended it. gpg 2.1 seems to be failing to recognize the extension. On 6/21/2018 11:27 AM, Phillip Susi wrote: > Ok, so if I checkout and build 2.0.31, remove ~/.gnupg, and import my > keyring, all of my private keys show up. If I check out and build 2.1.1 > and run /usr/local/bin/gpg -K, it upgrades to the new key format and > throws out my private keys: > > gpg: starting migration from earlier GnuPG versions > gpg: porting secret keys from '/home/psusi/.gnupg/secring.gpg' to gpg-agent > gpg: key A70FB705: secret key imported > gpg: migration succeeded > /home/psusi/.gnupg/pubring.gpg > ------------------------------ > sec# rsa2048/A70FB705 2011-12-13 > uid [ unknown] Phillip Susi > uid [ unknown] Phillip Susi > > Any suggestions on how to further debug this? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From felix at crowfix.com Thu Jun 21 17:49:21 2018 From: felix at crowfix.com (felix at crowfix.com) Date: Thu, 21 Jun 2018 08:49:21 -0700 Subject: Upgrading 2.0.20 to 2.2.24 -- WORKING NOW In-Reply-To: <87efh0sgw0.fsf@wheatstone.g10code.de> References: <20180617222023.GA8473@crowfix.com> <87wouweh3d.fsf@wheatstone.g10code.de> <20180619203158.GF8473@crowfix.com> <87efh0sgw0.fsf@wheatstone.g10code.de> Message-ID: <20180621154921.GA25144@crowfix.com> Well I'll be that crazy monkey's crazy uncle! I started from scratch -- copied the 2.0.20 .gnupg dir to the 2.2.24 machine, and imported the secret key as the very first operation: $ gpg --import <182E8151.exported gpg: starting migration from earlier GnuPG versions gpg: porting secret keys from '/home/felix/.gnupg/secring.gpg' to gpg-agent gpg: key 783876E9182E8151: secret key imported gpg: key 44752F7C4D3D351A: secret key imported gpg: migration succeeded gpg: key 783876E9182E8151: "Felix Finch (Scarecrow Repairman) " not changed gpg: key 783876E9182E8151: secret key imported gpg: Total number processed: 1 gpg: unchanged: 1 gpg: secret keys read: 1 gpg: secret keys unchanged: 1 $ gpg --list-secret-keys /home/felix/.gnupg/pubring.gpg ------------------------------ sec dsa1024 1999-12-06 [SCA] E9874493C860246C3B1E6477783876E9182E8151 uid [ultimate] Felix Finch (Scarecrow Repairman) ssb elg2048 1999-12-06 [E] sec dsa1024 1999-12-06 [SCA] 7689998F39D1EA2F37AECF5844752F7C4D3D351A uid [ unknown] Felix Finch (Remote Access) ssb elg1024 1999-12-06 [E] Of course this confused me, why would it matter that I imported and migrated together? So I started from scratch again with just --list-secret-keys, no import, and it worked too. I can only guess that the original copy of .gnupg was not copied correctly, or got corrupted somehow. And thanks to everyone who had the patience to deal with my problem. -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman & wood chipper / felix at crowfix.com GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o From lian.sebe at virusbulletin.com Thu Jun 21 11:40:23 2018 From: lian.sebe at virusbulletin.com (Lian Sebe) Date: Thu, 21 Jun 2018 11:40:23 +0200 Subject: uncompressing failed: Unknown compression algorithm Message-ID: <905b43fb-c93f-8791-dc94-b47dc46e9c6f@virusbulletin.com> Hi all, I have a python script that ran very well, each day decrypting files. Few days ago the script has stopped at a certain encrypted archive and the process was hanging since. I have drilled down and what happens is that gnupg is actually tripping on a encrypted file. Trying the decryption outside python, just with the regular command line: gpg -vv --decrypt 2018-06-14.tbz.gpg > 2018-06-14.tbz after requesting for the passphrase it says: gpg: 3DES encrypted data :compressed packet: algo=1 :literal data packet: ??? mode b (62), created 1528912641, name="", ??? raw data: unknown length gpg: original file name='' gpg: block_filter 0x186f090: read error (size=13002,a->size=13002) :compressed packet: algo=42 gpg: uncompressing failed: Unknown compression algorithm and then it hangs like this for days! Now, it might be a defective encryption with this file, I don't care much. I'd just like gnupg to move over the errors, i.e. exit after finishing processing or after unsuccessfuly trying to process the file. So, 2 questions: 1. Is it "normal" to hang like this or it is a bug ? 2. Is there any option I can pass to gnupg in command line so that it goes on in case of errors instead of hanging? I use this version on CentOS 7: /gpg (GnuPG) 2.0.22// //libgcrypt 1.5.3// //Copyright (C) 2013 Free Software Foundation, Inc.// //License GPLv3+: GNU GPL version 3 or later // //This is free software: you are free to change and redistribute it.// //There is NO WARRANTY, to the extent permitted by law.// // //Home: ~/.gnupg// //Supported algorithms:// //Pubkey: RSA, ?, ?, ELG, DSA// //Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,// //??????? CAMELLIA128, CAMELLIA192, CAMELLIA256// //Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224// //Compression: Uncompressed, ZIP, ZLIB, BZIP2// / Thanks, Lian -- Virus Bulletin Ltd, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, Oxon, United Kingdom. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kloecker at kde.org Thu Jun 21 21:33:07 2018 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Thu, 21 Jun 2018 21:33:07 +0200 Subject: Won't recognize my secret key In-Reply-To: <40310048-bc8d-ff65-f9f5-d3cb931ab981@ubuntu.com> References: <17b90844-163a-f4bd-223b-65665b576c39@ubuntu.com> <40310048-bc8d-ff65-f9f5-d3cb931ab981@ubuntu.com> Message-ID: <2427507.TWN2Dx7KeJ@thufir> On Donnerstag, 21. Juni 2018 17:27:05 CEST Phillip Susi wrote: > Ok, so if I checkout and build 2.0.31, remove ~/.gnupg, and import my > keyring, all of my private keys show up. If I check out and build 2.1.1 > and run /usr/local/bin/gpg -K, it upgrades to the new key format and > throws out my private keys: > > gpg: starting migration from earlier GnuPG versions > gpg: porting secret keys from '/home/psusi/.gnupg/secring.gpg' to gpg-agent > gpg: key A70FB705: secret key imported > gpg: migration succeeded > /home/psusi/.gnupg/pubring.gpg > ------------------------------ > sec# rsa2048/A70FB705 2011-12-13 > uid [ unknown] Phillip Susi > uid [ unknown] Phillip Susi > > Any suggestions on how to further debug this? I have imported your key 015F4DD4A70FB705 (btw, you should really enable "keyid-format long" in your gpg.conf because there are two keys with short key ID A70FB705 and uid "Phillip Susi "). $ gpg --list-keys --verbose 015F4DD4A70FB705 gpg: using classic trust model gpg: Note: signature key 9AC13A54FA9EEEF9 expired Fr 13 Dez 2013 06:00:00 CET gpg: Note: signature key 8E45A0223348AAF0 expired Mi 26 Nov 2014 05:28:21 CET gpg: Note: signature key D455AF0D9C8E5E51 expired Do 29 Okt 2015 02:29:24 CET gpg: Note: signature key 107951615CBBA516 expired Fr 30 Sep 2016 00:11:23 CEST pub rsa2048/015F4DD4A70FB705 2011-12-13 [SCA] 1B49F933916A37A3F45A1812015F4DD4A70FB705 uid [ unknown] Phillip Susi uid [ unknown] Phillip Susi sub rsa2048/D1FDDE0451FEF1C9 2011-12-13 [E] [expired: 2013-12-13] sub rsa2048/9AC13A54FA9EEEF9 2011-12-14 [S] [expired: 2013-12-13] sub rsa2048/8E45A0223348AAF0 2013-11-26 [S] [expired: 2014-11-26] sub rsa2048/1B6CD765BDCC7F92 2013-11-26 [E] [expired: 2014-11-26] sub rsa2048/D455AF0D9C8E5E51 2014-10-29 [S] [expired: 2015-10-29] sub rsa2048/BF0C615393A02CCD 2014-10-29 [E] [expired: 2015-10-29] sub rsa2048/107951615CBBA516 2015-10-05 [S] [expired: 2016-09-29] sub rsa2048/EBD87E9510850B71 2015-10-05 [E] [expired: 2016-09-29] sub rsa2048/DB2EC3B96100FE84 2017-01-06 [S] [expires: 2019-01-06] sub rsa2048/0E33D4FE0F60068B 2017-01-06 [E] [expires: 2019-01-06] That's with $ gpg --version gpg (GnuPG) 2.2.7 libgcrypt 1.8.2 So, with respect to your public key everything looks good. Are you sure you are trying to migrate the most recent version of your key? Which expiration dates does the "working system" list? Try importing your public key from a keyserver. Regards, Ingo From gniibe at fsij.org Fri Jun 22 04:41:38 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 22 Jun 2018 11:41:38 +0900 Subject: Won't recognize my secret key In-Reply-To: <052c6585-15b7-7054-7a2b-2628058ee81f@ubuntu.com> References: <17b90844-163a-f4bd-223b-65665b576c39@ubuntu.com> <40310048-bc8d-ff65-f9f5-d3cb931ab981@ubuntu.com> <052c6585-15b7-7054-7a2b-2628058ee81f@ubuntu.com> Message-ID: <87y3f7v8yl.fsf@iwagami.gniibe.org> Hello, Thank you for your report. I think I located the issue of migration. Phillip Susi wrote: > I just noticed that I do have a bunch of key files in > ~/.gnupg/private-keys-v1.d, even though gpg -K does not show them. > > Ahah, gpg -K -v shows them... it seems to think they are all expired. > It lists the expiration date on my current key as 2018-1-6. I believe > that was the *original* expiration date, but then I extended it. gpg > 2.1 seems to be failing to recognize the extension. For the problem of importing secring.gpg directly, we have a task: https://dev.gnupg.org/T3101 Basically, secring.gpg only has the information of expiration when it's created. After changing expiration, it is only recorded in pubring.gpg. So, it is recommended to do somthing like: $ gpg --homedir ~/.gnupg.old --export-secret-keys | \ gpg --homedir ~/.gnupg --import (instead of doing --import ~/.gnupg/secring.gpg directly.) However, in gnupg/g10/migrate.c, GnuPG itself does that (!). This should be fixed. -- From gallawyer at live.com Fri Jun 22 03:45:58 2018 From: gallawyer at live.com (Master Lion) Date: Fri, 22 Jun 2018 01:45:58 +0000 Subject: Paper backup of all keys Message-ID: Linux -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristian.fiskerstrand at sumptuouscapital.com Fri Jun 22 12:47:58 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 22 Jun 2018 12:47:58 +0200 Subject: Won't recognize my secret key In-Reply-To: <87y3f7v8yl.fsf@iwagami.gniibe.org> References: <17b90844-163a-f4bd-223b-65665b576c39@ubuntu.com> <40310048-bc8d-ff65-f9f5-d3cb931ab981@ubuntu.com> <052c6585-15b7-7054-7a2b-2628058ee81f@ubuntu.com> <87y3f7v8yl.fsf@iwagami.gniibe.org> Message-ID: On 06/22/2018 04:41 AM, NIIBE Yutaka wrote: > Hello, .. > However, in gnupg/g10/migrate.c, GnuPG itself does that (!). This > should be fixed. > Isn't the presumption that auto-migration happens in current homedir, and in this case pubring.gpg would exist anyways, i.e it is only the secring that needs converting to the new format to begin with. I don't see any benefit in changing the method here -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "There is no urge so great as for one man to edit another man's work." (Mark Twain) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From psusi at ubuntu.com Fri Jun 22 14:50:15 2018 From: psusi at ubuntu.com (Phillip Susi) Date: Fri, 22 Jun 2018 08:50:15 -0400 Subject: Won't recognize my secret key In-Reply-To: <87y3f7v8yl.fsf@iwagami.gniibe.org> References: <17b90844-163a-f4bd-223b-65665b576c39@ubuntu.com> <40310048-bc8d-ff65-f9f5-d3cb931ab981@ubuntu.com> <052c6585-15b7-7054-7a2b-2628058ee81f@ubuntu.com> <87y3f7v8yl.fsf@iwagami.gniibe.org> Message-ID: <709edcba-e23b-a41a-0398-fe857cac5831@ubuntu.com> On 6/21/2018 10:41 PM, NIIBE Yutaka wrote: > Basically, secring.gpg only has the information of expiration when it's > created. After changing expiration, it is only recorded in pubring.gpg. > So, it is recommended to do somthing like: Makes sense. > $ gpg --homedir ~/.gnupg.old --export-secret-keys | \ > gpg --homedir ~/.gnupg --import > > (instead of doing --import ~/.gnupg/secring.gpg directly.) > > However, in gnupg/g10/migrate.c, GnuPG itself does that (!). This > should be fixed. The first thing I did was delete ~/.gnupg.old and re-import just like that ( which of course, did not work ). I re-imported only the public key today with --recv-keys and that got the updated selfsig. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Sun Jun 24 10:52:45 2018 From: wk at gnupg.org (Werner Koch) Date: Sun, 24 Jun 2018 10:52:45 +0200 Subject: uncompressing failed: Unknown compression algorithm In-Reply-To: <905b43fb-c93f-8791-dc94-b47dc46e9c6f@virusbulletin.com> (Lian Sebe's message of "Thu, 21 Jun 2018 11:40:23 +0200") References: <905b43fb-c93f-8791-dc94-b47dc46e9c6f@virusbulletin.com> Message-ID: <87h8lspnvm.fsf@wheatstone.g10code.de> On Thu, 21 Jun 2018 11:40, lian.sebe at virusbulletin.com said: > 1. Is it "normal" to hang like this or it is a bug ? No, that should not happen. Compression 42 is clearly an indication for a corrupt file. > 2. Is there any option I can pass to gnupg in command line so that it > goes on in case of errors instead of hanging? No, the above looks like a bug which needs to be fixed. > /gpg (GnuPG) 2.0.22// That version is close to 5 years old and its 2.0 branch reached end-of-life half a year ago. We might have fixed such a bug already in current versions. Please let us know if you can replicate this with a current GnuPG version and we will dig into it. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From johndoe65534 at mail.com Mon Jun 25 10:50:09 2018 From: johndoe65534 at mail.com (john doe) Date: Mon, 25 Jun 2018 10:50:09 +0200 Subject: dirmngr cygwin resolv.conf Message-ID: <2668e804-4468-774b-702f-62a3695e0e9a@mail.com> Hi, I'm using gpg2/dirmngr on Cygwin: $ gpg2 --version gpg (GnuPG) 2.2.8-unknown libgcrypt 1.8.2 $ dirmngr --version dirmngr (GnuPG) 2.2.8-unknown On Cygwin '/etc/resolv.conf' is not needed, as ilustrated by the below log dirmngr requires 'resolv.conf': I used the commands from: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854359 $ dirmngr --server --homedir $PWD -v dirmngr[7576]: error opening '/home/john/try/dirmngr-test/dirmngr_ldapservers.conf': No such file or directory dirmngr[7576.0]: permanently loaded certificates: 134 dirmngr[7576.0]: runtime cached certificates: 0 dirmngr[7576.0]: trusted certificates: 134 (133,0,0,1) # Home: /home/john/try/dirmngr-test # Config: [none] OK Dirmngr 2.2.8-unknown at your service KS_GET -- 0x6C6ACD6417B3ACB1 dirmngr[7576.0]: stat'ing '/etc/resolv.conf' failed: No such file or directory dirmngr[7576.0]: stat'ing '/etc/resolv.conf' failed: No such file or directory dirmngr[7576.0]: failed to load '/etc/resolv.conf': No such file or directory dirmngr[7576.0]: command 'KS_GET' failed: No such file or directory ERR 167805009 No such file or directory If I populate /etc/resolv.conf with my DNS nameserver it works. This is not practical because everytime my DNS changes I would need to modify that file manually. Could dirmngr use the DNS provided by windows or is there a way to bypass the use of 'resolv.conf'? -- John Doe From wiktor at metacode.biz Tue Jun 26 12:31:53 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Tue, 26 Jun 2018 12:31:53 +0200 Subject: gpg show default / effective options Message-ID: Hello, Is it possible to print default or effective options used by GnuPG? I'm in the process of slimming down gpg.conf and see that many options are either redundant (because gpg uses them by default) or no-ops. I would like to see which options are used to safely remove obsolete settings. While it is kind-of possible to infer defaults from the source (e.g. [0]) I wondered if there is a command that would print all settings that are default or effective at the moment. Thank you in advance! Kind regards, Wiktor [0]: https://dev.gnupg.org/source/gnupg/browse/master/g10/gpg.c;592deeddb9bf4ae9b3e236b439e2f39644eb6d46$2403 -- */metacode/* -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue Jun 26 21:04:04 2018 From: wk at gnupg.org (Werner Koch) Date: Tue, 26 Jun 2018 21:04:04 +0200 Subject: gpg show default / effective options In-Reply-To: (Wiktor Kwapisiewicz via Gnupg-users's message of "Tue, 26 Jun 2018 12:31:53 +0200") References: Message-ID: <87muvhmkt7.fsf@wheatstone.g10code.de> On Tue, 26 Jun 2018 12:31, gnupg-users at gnupg.org said: > Is it possible to print default or effective options used by GnuPG? You can run gpgconf --list-options gpg which prints the options and their current values in a format described in the gpgconf man page. Frontends like Kleopatra and GPA use this to provide a GUI page with options. However, this does only include a subset of all options. In theory the man page should list the actual defaults but I am pretty sure that some(tm) are missing. If you find such flaws, please let me know and I'll add them to the docs. Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wiktor at metacode.biz Tue Jun 26 21:16:36 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Tue, 26 Jun 2018 21:16:36 +0200 Subject: gpg show default / effective options In-Reply-To: <87muvhmkt7.fsf@wheatstone.g10code.de> References: <87muvhmkt7.fsf@wheatstone.g10code.de> Message-ID: <19c1ed2c-ec17-da00-7895-90d85347ab31@metacode.biz> Wow, that is exactly what I needed. I will walk through them soon and report any problems directly to you. Thanks Werner! Kind regards, Wiktor W dniu 26.06.2018 o?21:04, Werner Koch pisze: > On Tue, 26 Jun 2018 12:31, gnupg-users at gnupg.org said: > >> Is it possible to print default or effective options used by GnuPG? > > You can run > > gpgconf --list-options gpg > > which prints the options and their current values in a format described > in the gpgconf man page. Frontends like Kleopatra and GPA use this to > provide a GUI page with options. > > However, this does only include a subset of all options. In theory the > man page should list the actual defaults but I am pretty sure that > some(tm) are missing. If you find such flaws, please let me know and > I'll add them to the docs. > > > Salam-Shalom, > > Werner > -- */metacode/* -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From aarontovo at gmail.com Wed Jun 27 05:10:54 2018 From: aarontovo at gmail.com (Aaron Tovo) Date: Tue, 26 Jun 2018 22:10:54 -0500 Subject: gpg2 Message-ID: <86d18954-e8cd-d67c-8507-4591469b3ecf@gmail.com> 'gpg2 -k' gives me the following error: $ gpg2 -k gpg: invalid item 'BZIP2' in preference string gpg: invalid default preferences But 'gpg -k' works fine. However, I to use gpg2 in my Thunderbird-with-Enigmail email client because I've read in a few places that gpg2 is better for desktop purposes . Also, Enigmail rejects gpg because /usr/bin/gpg is 'out of date' (meaning it's not gpg2, I think) and seems to REALLY want gpg2. The error message makes it sound like the problem is in my gpg2 configuration. I don't see any zip settings in .gnupg2/gpg.conf nor do I see a 'preferences string'. I'm not sure when this started happening because I've been going without Enigmail for a while on this computer. How can I correct the preference string? Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From johndoe65534 at mail.com Wed Jun 27 07:26:37 2018 From: johndoe65534 at mail.com (john doe) Date: Wed, 27 Jun 2018 07:26:37 +0200 Subject: gpg2 In-Reply-To: <86d18954-e8cd-d67c-8507-4591469b3ecf@gmail.com> References: <86d18954-e8cd-d67c-8507-4591469b3ecf@gmail.com> Message-ID: <15ee1762-f5d8-8eca-e243-925d3152bb1a@mail.com> On 6/27/2018 5:10 AM, Aaron Tovo wrote: > 'gpg2 -k' gives me the following error: > > $ gpg2 -k > gpg: invalid item 'BZIP2' in preference string > gpg: invalid default preferences > > But 'gpg -k' works fine. However, I to use gpg2 in my > Thunderbird-with-Enigmail email client because I've read in a few places > that gpg2 is better for desktop purposes > . Also, Enigmail rejects gpg because > /usr/bin/gpg is 'out of date' (meaning it's not gpg2, I think) and seems > to REALLY want gpg2. > > The error message makes it sound like the problem is in my gpg2 > configuration. I don't see any zip settings in .gnupg2/gpg.conf nor do I > see a 'preferences string'. > > I'm not sure when this started happening because I've been going without > Enigmail for a while on this computer. > > How can I correct the preference string? > Some hints: 1) Do you have 'BZIP2' in .gnupg/gpg.conf in the preference string? $ grep -n 'BZIP2' .gnupg/gpg.conf If the above grep command prints something to the screen try removing 'BZIP2' from the file. 2) If you do: $ gpg2 --version look at the gpg.conf found in the directory specified by the line 'Home: ...'. 3) If you pass the option '--homedir' to gpg2 you should look in the gpg.conf found in that directory. -- John Doe From rjh at sixdemonbag.org Wed Jun 27 06:55:50 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 27 Jun 2018 00:55:50 -0400 Subject: gpg2 In-Reply-To: <86d18954-e8cd-d67c-8507-4591469b3ecf@gmail.com> References: <86d18954-e8cd-d67c-8507-4591469b3ecf@gmail.com> Message-ID: > $ gpg2 -k > gpg: invalid item 'BZIP2' in preference string > gpg: invalid default preferences Try "gpg2 --version" and look for a line like: Compression: Uncompressed, ZIP, ZLIB, BZIP2 ... I suspect you'll discover whoever compiled your GnuPG 2 neglected to include support for the BZIP2 algorithm. From rjh at sixdemonbag.org Wed Jun 27 08:58:58 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 27 Jun 2018 02:58:58 -0400 Subject: gpg2 In-Reply-To: <15ee1762-f5d8-8eca-e243-925d3152bb1a@mail.com> References: <86d18954-e8cd-d67c-8507-4591469b3ecf@gmail.com> <15ee1762-f5d8-8eca-e243-925d3152bb1a@mail.com> Message-ID: > Some hints: Please *don't* do this. BZIP2 compression is common enough that if a GnuPG build doesn't have it, the best course of action is to get a properly-done build. Removing BZIP2 from the preference list will hide the problem (no support for BZIP2), not address it! From sebastian at karotte.org Wed Jun 27 09:42:08 2018 From: sebastian at karotte.org (Sebastian Wiesinger) Date: Wed, 27 Jun 2018 09:42:08 +0200 Subject: Pinentry does not show "please insert smartcard" dialog Message-ID: <20180627074208.dpn2z2mi3agswev3@danton.fire-world.de> Hello, I'm using pinentry (GTK2) on my Xubuntu. My authentication key is saved on a Yubikey4. Pinentry does work when the key is inserted and displays the PIN entry dialog just fine. What doesn't work is the "please insert smartcard" dialog when the key is not plugged in. I manually added the correct keygrip to the sshcontrol file but this does not work. On my MacOS the same config does display the "insert smartcard" dialog. Any idea why it doesn't work on my Linux system or how to find out? I already tried multiple debug options but no helpful info showed up in the logs. Version: Xubuntu 17.10 ii pinentry-gtk2 1.0.0-2 amd64 $ gpg --version gpg (GnuPG) 2.1.15 libgcrypt 1.7.8 Kind Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant From aarontovo at gmail.com Wed Jun 27 18:33:34 2018 From: aarontovo at gmail.com (aarontovo) Date: Wed, 27 Jun 2018 11:33:34 -0500 Subject: gpg2 In-Reply-To: Message-ID: <5b33bc60.1c69fb81.442e1.0ff0@mx.google.com> There are no references to anything about zip in my gpg.conf file. There also is no mention of preferences in gpg.conf. So it I'll rebuild gpg2 with the proper bzip2 library this evening. Thanks! -------- Original message --------From: "Robert J. Hansen" Date: 6/27/18 1:58 AM (GMT-06:00) To: gnupg-users at gnupg.org Subject: Re: gpg2 > Some hints: Please *don't* do this.? BZIP2 compression is common enough that if a GnuPG build doesn't have it, the best course of action is to get a properly-done build. Removing BZIP2 from the preference list will hide the problem (no support for BZIP2), not address it! _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From tookmund at gmail.com Wed Jun 27 22:50:25 2018 From: tookmund at gmail.com (Jacob Adams) Date: Wed, 27 Jun 2018 16:50:25 -0400 Subject: Pinentry: Inappropriate ioctl for device when getting smartcard PIN Message-ID: <733b219b-86c0-d177-4999-15da2a285930@gmail.com> I've got another pinentry problem unfortunately. The tty is owned by the correct user this time and $GPG_TTY is set correctly. I have two gpgme contexts, one for openpgp and another for assuan commands to the smartcard. Pinentry triggered by the openpgp context works perfectly, but any pinentry launched in service of the assuan context fails with the error in the subject. They're both using the same gpg-agent launched shortly after the creation of the openpgp context with gpgconf --launch gpg-agent. The relevant logs are available at: https://salsa.debian.org/tookmund-guest/pgpcr/issues/10 I'm really not sure what's going wrong here and any insight would be much appreciated. Thanks, Jacob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed Jun 27 18:51:59 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 27 Jun 2018 18:51:59 +0200 Subject: dirmngr cygwin resolv.conf In-Reply-To: <2668e804-4468-774b-702f-62a3695e0e9a@mail.com> (john doe's message of "Mon, 25 Jun 2018 10:50:09 +0200") References: <2668e804-4468-774b-702f-62a3695e0e9a@mail.com> Message-ID: <87zhzgkw9c.fsf@wheatstone.g10code.de> On Mon, 25 Jun 2018 10:50, johndoe65534 at mail.com said: > On Cygwin '/etc/resolv.conf' is not needed, as ilustrated by the > below log dirmngr requires 'resolv.conf': Cygwin is Unix emulation on Windows and thus GnuPG considers the platform to be unix. In turn /etc/resolv.conf is required. > Could dirmngr use the DNS provided by windows or is there a way to > bypass the use of 'resolv.conf'? Use the standard Windows GnuPG and you get Windows features. Or, well, use the Tor support which redirects all DNS over Tor. Just install the Tor Browser and GnuPG will use that. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From johndoe65534 at mail.com Thu Jun 28 11:54:27 2018 From: johndoe65534 at mail.com (john doe) Date: Thu, 28 Jun 2018 11:54:27 +0200 Subject: dirmngr cygwin resolv.conf In-Reply-To: <87zhzgkw9c.fsf@wheatstone.g10code.de> References: <2668e804-4468-774b-702f-62a3695e0e9a@mail.com> <87zhzgkw9c.fsf@wheatstone.g10code.de> Message-ID: <4b9eb287-7ef3-ff97-6838-943af8a92ca7@mail.com> Hi Werner, thanks for your answer. On 6/27/2018 6:51 PM, Werner Koch wrote: > On Mon, 25 Jun 2018 10:50, johndoe65534 at mail.com said: > >> On Cygwin '/etc/resolv.conf' is not needed, as ilustrated by the >> below log dirmngr requires 'resolv.conf': > > Cygwin is Unix emulation on Windows and thus GnuPG considers the > platform to be unix. In turn /etc/resolv.conf is required. > Fair enough. >> Could dirmngr use the DNS provided by windows or is there a way to >> bypass the use of 'resolv.conf'? > > Use the standard Windows GnuPG and you get Windows features. Or, well, > use the Tor support which redirects all DNS over Tor. Just install the > Tor Browser and GnuPG will use that. > Can you elaborate on how I would let "Cygwin dirmngr" use "Tor Browser for Windows"? -- John Doe From wk at gnupg.org Thu Jun 28 13:25:28 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 28 Jun 2018 13:25:28 +0200 Subject: dirmngr cygwin resolv.conf In-Reply-To: <4b9eb287-7ef3-ff97-6838-943af8a92ca7@mail.com> (john doe's message of "Thu, 28 Jun 2018 11:54:27 +0200") References: <2668e804-4468-774b-702f-62a3695e0e9a@mail.com> <87zhzgkw9c.fsf@wheatstone.g10code.de> <4b9eb287-7ef3-ff97-6838-943af8a92ca7@mail.com> Message-ID: <871scr17br.fsf@wheatstone.g10code.de> On Thu, 28 Jun 2018 11:54, johndoe65534 at mail.com said: > Can you elaborate on how I would let "Cygwin dirmngr" use "Tor Browser > for Windows"? I have not tested it but given that the Tor browser is listening on localhost, TCP port 9150, I see no reason why a native Windows Tor Browser can't work with the Cygwinized GnuPG. Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From johndoe65534 at mail.com Thu Jun 28 17:05:15 2018 From: johndoe65534 at mail.com (john doe) Date: Thu, 28 Jun 2018 17:05:15 +0200 Subject: dirmngr cygwin resolv.conf In-Reply-To: <871scr17br.fsf@wheatstone.g10code.de> References: <2668e804-4468-774b-702f-62a3695e0e9a@mail.com> <87zhzgkw9c.fsf@wheatstone.g10code.de> <4b9eb287-7ef3-ff97-6838-943af8a92ca7@mail.com> <871scr17br.fsf@wheatstone.g10code.de> Message-ID: <5f12448e-fab6-6eba-325b-7273677cf822@mail.com> On 6/28/2018 1:25 PM, Werner Koch wrote: > On Thu, 28 Jun 2018 11:54, johndoe65534 at mail.com said: > >> Can you elaborate on how I would let "Cygwin dirmngr" use "Tor Browser >> for Windows"? > > I have not tested it but given that the Tor browser is listening on > localhost, TCP port 9150, I see no reason why a native Windows Tor > Browser can't work with the Cygwinized GnuPG. > For testing purposes I have configured Firefox to use socks5 proxy "localhost:9150", as you suggested, it is working. Now, the next step is to configure dirmngr to do the same!: dirmngr.conf: use-tor http-proxy socks5://localhost:9150 gives the following error: ERR 219 Server indicated a failure How can I use socks5 with dirmngr? -- John Doe From gniibe at fsij.org Fri Jun 29 09:30:37 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 29 Jun 2018 16:30:37 +0900 Subject: dirmngr cygwin resolv.conf In-Reply-To: <5f12448e-fab6-6eba-325b-7273677cf822@mail.com> References: <2668e804-4468-774b-702f-62a3695e0e9a@mail.com> <87zhzgkw9c.fsf@wheatstone.g10code.de> <4b9eb287-7ef3-ff97-6838-943af8a92ca7@mail.com> <871scr17br.fsf@wheatstone.g10code.de> <5f12448e-fab6-6eba-325b-7273677cf822@mail.com> Message-ID: <87wouim4ma.fsf@iwagami.gniibe.org> john doe wrote: > Now, the next step is to configure dirmngr to do the same!: > > dirmngr.conf: > > use-tor > http-proxy socks5://localhost:9150 Only "use-tor" is needed, then, dirmngr connects to localhost:9150 for Tor. -- From damien at cassou.me Fri Jun 29 09:36:39 2018 From: damien at cassou.me (Damien Cassou) Date: Fri, 29 Jun 2018 09:36:39 +0200 Subject: Choice of ECC curve on usb token Message-ID: <87wouioxh4.fsf@cassou.me> Hi, I would like to get a usb token to secure my keys. My use case is protection of 3 GnuPG keys that I will be using 10 times per day at least. I plan to create a new key ring from scratch. Because ECC seems more future-oriented than RSA, this is what I chose to use. I'm wondering which usb token to choose as well as which curve. On https://www.gnupg.org/(it)/faq/whats-new-in-2.1.html 2 it is said that many people think NIST and Brainpool have a doubtful origin therefore they recommend the non-standardized Bernstein?s Curve 25519. On https://support.nitrokey.com/t/choice-of-curves-on-the-storage-2/1192/3, the author says that (1) he is not aware of profound critic on Brainpool curves and (2) Bernstein?s Curve 25519 is hard to protect against side channel attacks when being implemented in embedded devices. As a result, I'm a bit lost in what key/curve to choose. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill From johndoe65534 at mail.com Fri Jun 29 12:57:31 2018 From: johndoe65534 at mail.com (john doe) Date: Fri, 29 Jun 2018 12:57:31 +0200 Subject: dirmngr cygwin resolv.conf In-Reply-To: <87wouim4ma.fsf@iwagami.gniibe.org> References: <2668e804-4468-774b-702f-62a3695e0e9a@mail.com> <87zhzgkw9c.fsf@wheatstone.g10code.de> <4b9eb287-7ef3-ff97-6838-943af8a92ca7@mail.com> <871scr17br.fsf@wheatstone.g10code.de> <5f12448e-fab6-6eba-325b-7273677cf822@mail.com> <87wouim4ma.fsf@iwagami.gniibe.org> Message-ID: On 6/29/2018 9:30 AM, NIIBE Yutaka wrote: > john doe wrote: >> Now, the next step is to configure dirmngr to do the same!: >> >> dirmngr.conf: >> >> use-tor >> http-proxy socks5://localhost:9150 > > Only "use-tor" is needed, then, dirmngr connects to localhost:9150 for > Tor. > Looks like the issue isDNS name resolving: $ dirmngr --homedir ~/try --use-tor -vvvvv --debug-all --server OK Dirmngr 2.2.8-unknown at your service KS_GET -- 0x6C6ACD6417B3ACB1 dirmngr[6496.0]: DBG: chan_3 <- KS_GET -- 0x6C6ACD6417B3ACB1 dirmngr[6496.0]: DBG: dns: libdns initialized (tor mode) dirmngr[6496.0]: DBG: dns: getsrv(_pgpkey-https._tcp.hkps.pool.sks-keyservers.net): Server indicated a failure dirmngr[6496.0]: command 'KS_GET' failed: Server indicated a failure dirmngr[6496.0]: DBG: chan_3 -> ERR 219 Server indicated a failure ERR 219 Server indicated a failure I'm not sure how to go about it? Any hints/... is much appriciated. -- John Doe From gniibe at fsij.org Fri Jun 29 13:28:14 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 29 Jun 2018 20:28:14 +0900 Subject: Choice of ECC curve on usb token In-Reply-To: <87wouioxh4.fsf@cassou.me> References: <87wouioxh4.fsf@cassou.me> Message-ID: <877emhn86p.fsf@fsij.org> Hello, Why not Curve25519, if you use ECC? Damien Cassou wrote: > curves and (2) Bernstein?s Curve 25519 is hard to protect against side > channel attacks when being implemented in embedded devices. Quite interesting opinion. I wonder what kinds of side channel attacks are discussed there. Well, it's the first time for me to hear such an opinion. Are there some confusions? Curve25519 is designed against side channel attacks in mind. Also, it comes with a reference implementation. Even if an implementation doesn't use the methodology directly, it is a bit harder to write weaker implementation (against side channel attack), if an implementer understands Curve25519 correctly. <-- this is my own opinion. I wrote Curve25519 implementation for libgcrypt. So far, libgcrypt doesn't have field specific methods, but libgcrypt 1.9.x will have those for Curve25519. If we compare curves in libgcrypt, I think that Curve25519 is good one. I also wrote Curve25519 implementation for Gnuk. Well, I also wrote ones of NIST P-256 and secp256k1 for Gnuk. I believe Curve25519 is the best among those (and RSA). Gnuk runs on STM32F103 @ 72MHz (or GD32F103 @ 96MHz). This is an embedded device, of my daily use. -- From gniibe at fsij.org Fri Jun 29 13:40:52 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 29 Jun 2018 20:40:52 +0900 Subject: dirmngr cygwin resolv.conf In-Reply-To: References: <2668e804-4468-774b-702f-62a3695e0e9a@mail.com> <87zhzgkw9c.fsf@wheatstone.g10code.de> <4b9eb287-7ef3-ff97-6838-943af8a92ca7@mail.com> <871scr17br.fsf@wheatstone.g10code.de> <5f12448e-fab6-6eba-325b-7273677cf822@mail.com> <87wouim4ma.fsf@iwagami.gniibe.org> Message-ID: <874lhln7ln.fsf@fsij.org> Hello, Sorry, my explanation was not accurate. In the Tor-mode of dirmngr, it uses the port 9050 at first. And there is some code to fallback to the port 9150. It's like: libdns_switch_port_p (gpg_error_t err) { if (tor_mode && gpg_err_code (err) == GPG_ERR_ECONNREFUSED && libdns_tor_port == TOR_PORT) { /* Switch port and try again. */ if (opt_debug) log_debug ("dns: switching from SOCKS port %d to %d\n", TOR_PORT, TOR_PORT2); libdns_tor_port = TOR_PORT2; libdns_reinit_pending = 1; return 1; } return 0; } I suspect the error detection is not working well. If it works, you should see the debug message of "dns: switching from SOCKS port...". I tested with the port 9050, my dirmngr works fine. -- From dirk.gottschalk1980 at googlemail.com Fri Jun 29 14:44:29 2018 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Fri, 29 Jun 2018 14:44:29 +0200 Subject: dirmngr cygwin resolv.conf In-Reply-To: <87wouim4ma.fsf@iwagami.gniibe.org> References: <2668e804-4468-774b-702f-62a3695e0e9a@mail.com> <87zhzgkw9c.fsf@wheatstone.g10code.de> <4b9eb287-7ef3-ff97-6838-943af8a92ca7@mail.com> <871scr17br.fsf@wheatstone.g10code.de> <5f12448e-fab6-6eba-325b-7273677cf822@mail.com> <87wouim4ma.fsf@iwagami.gniibe.org> Message-ID: <59d269a4c9c7e66cf11f89eaad0275173880db3d.camel@googlemail.com> Hello. Am Freitag, den 29.06.2018, 16:30 +0900 schrieb NIIBE Yutaka: > john doe wrote: > > Now, the next step is to configure dirmngr to do the same!: > > > > dirmngr.conf: > > > > use-tor > > http-proxy socks5://localhost:9150 > > Only "use-tor" is needed, then, dirmngr connects to localhost:9150 > for Tor. I'm running a local server with a Squid/privoxy/TOR chain. This works fine for keyserver and crl queries, but only for this. Is there any way to tell dirmngr on my workstation to use the socks port of TOR on my server, which I configured to listen also on the NIC. Regards, Dirk -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen Tel.: +49 1573 1152350 -------------- 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 dirk.gottschalk1980 at googlemail.com Fri Jun 29 16:12:20 2018 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Fri, 29 Jun 2018 16:12:20 +0200 Subject: gpg2 --refresh-keys does not talk to dirmngr? Message-ID: <99e966302e0c9db4c169414ea3b8753f4fc7ae96.camel@googlemail.com> Hello. I have set up a local proxy server with a squid/privoxy/TOR chain and set it up in dirmngr.conf. Now, after deleting the keyserver line from gpg.conf, I found out that gpg2 seems not to talk to dirmngr when using gpg2 --refresh keys. Is there something I have to set up in one of the configs, especially gpg.conf and gpg-agent.conf? All the docs tell that dirmngr should be used automatically, if I read them right. Thanks vor your Patience. Regards, Dirk -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen Tel.: +49 1573 1152350 -------------- 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 damien at cassou.me Fri Jun 29 18:07:19 2018 From: damien at cassou.me (Damien Cassou) Date: Fri, 29 Jun 2018 18:07:19 +0200 Subject: Choice of ECC curve on usb token In-Reply-To: <877emhn86p.fsf@fsij.org> References: <87wouioxh4.fsf@cassou.me> <877emhn86p.fsf@fsij.org> Message-ID: <87lgax7f0o.fsf@cassou.me> NIIBE Yutaka writes: > Why not Curve25519, if you use ECC? I'm not sure I want ECC after reading this: https://crypto.stackexchange.com/a/60394/60027 Moreover, Nitrokey Storage only supports NIST and Brainpool, nothing else. > Quite interesting opinion. [...] thank you for the information. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill From wk at gnupg.org Fri Jun 29 16:24:51 2018 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 Jun 2018 16:24:51 +0200 Subject: dirmngr cygwin resolv.conf In-Reply-To: <5f12448e-fab6-6eba-325b-7273677cf822@mail.com> (john doe's message of "Thu, 28 Jun 2018 17:05:15 +0200") References: <2668e804-4468-774b-702f-62a3695e0e9a@mail.com> <87zhzgkw9c.fsf@wheatstone.g10code.de> <4b9eb287-7ef3-ff97-6838-943af8a92ca7@mail.com> <871scr17br.fsf@wheatstone.g10code.de> <5f12448e-fab6-6eba-325b-7273677cf822@mail.com> Message-ID: <87lgaxzn4c.fsf@wheatstone.g10code.de> On Thu, 28 Jun 2018 17:05, johndoe65534 at mail.com said: > dirmngr.conf: > > use-tor > http-proxy socks5://localhost:9150 Nobody said that you should configure a proxy ;-) Dirmngr has integrated Tor support which will be used automatically when Tor or the Tor Browser is up and running. --use-tor merely enforces the use of Tor and inhibits any network access without going over Tor. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From johndoe65534 at mail.com Fri Jun 29 18:40:51 2018 From: johndoe65534 at mail.com (john doe) Date: Fri, 29 Jun 2018 18:40:51 +0200 Subject: dirmngr cygwin resolv.conf In-Reply-To: <87lgaxzn4c.fsf@wheatstone.g10code.de> References: <2668e804-4468-774b-702f-62a3695e0e9a@mail.com> <87zhzgkw9c.fsf@wheatstone.g10code.de> <4b9eb287-7ef3-ff97-6838-943af8a92ca7@mail.com> <871scr17br.fsf@wheatstone.g10code.de> <5f12448e-fab6-6eba-325b-7273677cf822@mail.com> <87lgaxzn4c.fsf@wheatstone.g10code.de> Message-ID: On 6/29/2018 4:24 PM, Werner Koch wrote: > On Thu, 28 Jun 2018 17:05, johndoe65534 at mail.com said: > >> dirmngr.conf: >> >> use-tor >> http-proxy socks5://localhost:9150 > > Nobody said that you should configure a proxy ;-) > > Dirmngr has integrated Tor support which will be used automatically when > Tor or the Tor Browser is up and running. --use-tor merely enforces the > use of Tor and inhibits any network access without going over Tor. > Ok, "proxy" is a red herring -- I used the option '--use-tor' to be sure tor will be used to furder isolate the issue. In an earlier sent e-mail: https://lists.gnupg.org/pipermail/gnupg-users/2018-June/060740.html As you can see no command proxy option is being used. Some how I'm stuck at DNS name resolving if I'm not mistaking? Any help is welcome. -- John Doe From juergen at bruckner.tk Fri Jun 29 21:14:44 2018 From: juergen at bruckner.tk (Juergen Bruckner) Date: Fri, 29 Jun 2018 21:14:44 +0200 Subject: Choice of ECC curve on usb token In-Reply-To: <87lgax7f0o.fsf@cassou.me> References: <87wouioxh4.fsf@cassou.me> <877emhn86p.fsf@fsij.org> <87lgax7f0o.fsf@cassou.me> Message-ID: <7b2a8275-16f1-04c2-66f9-17a1288b4e76@bruckner.tk> Hello Damien, Am 2018-06-29 um 18:07 schrieb Damien Cassou: > Moreover, Nitrokey Storage only supports NIST and Brainpool, nothing > else. Im not fully sure but i guess for your purposes you would need Nitrokey Pro[1] best regards Juergen [1] https://shop.nitrokey.com/de_DE/shop/product/nitrokey-pro-3 -- Juergen M. Bruckner juergen at bruckner.tk -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3894 bytes Desc: S/MIME Cryptographic Signature URL: From johndoe65534 at mail.com Fri Jun 29 22:03:32 2018 From: johndoe65534 at mail.com (john doe) Date: Fri, 29 Jun 2018 22:03:32 +0200 Subject: dirmngr cygwin resolv.conf In-Reply-To: References: <2668e804-4468-774b-702f-62a3695e0e9a@mail.com> <87zhzgkw9c.fsf@wheatstone.g10code.de> <4b9eb287-7ef3-ff97-6838-943af8a92ca7@mail.com> <871scr17br.fsf@wheatstone.g10code.de> <5f12448e-fab6-6eba-325b-7273677cf822@mail.com> <87lgaxzn4c.fsf@wheatstone.g10code.de> Message-ID: <641a84ad-6bd9-0732-2509-9b3b35b210d5@mail.com> On 6/29/2018 6:40 PM, john doe wrote: > On 6/29/2018 4:24 PM, Werner Koch wrote: >> On Thu, 28 Jun 2018 17:05, johndoe65534 at mail.com said: >> >>> dirmngr.conf: >>> >>> use-tor >>> http-proxy socks5://localhost:9150 >> >> Nobody said that you should configure a proxy ;-) >> >> Dirmngr has integrated Tor support which will be used automatically when >> Tor or the Tor Browser is up and running.? --use-tor merely enforces the >> use of Tor and inhibits any network access without going over Tor. >> > > Ok, "proxy" is a red herring -- I used the option '--use-tor' to be sure > tor will be used to furder isolate the issue. > > In an earlier sent e-mail: > > https://lists.gnupg.org/pipermail/gnupg-users/2018-June/060740.html > > As you can see no command proxy option is being used. > > Some how I'm stuck at DNS name resolving if I'm not mistaking? > > Any help is welcome. > Ok -- I think I got it: If I start Tor Browser as usual by clicking on "Start Tor Browser" it does not work. But if I start "Browser\TorBrowser\Tor\tor.exe" it works like a charm. How can I socks5 dirmngr connections to "Tor Browser"? -- John Doe From tookmund at gmail.com Fri Jun 29 22:07:00 2018 From: tookmund at gmail.com (Jacob Adams) Date: Fri, 29 Jun 2018 16:07:00 -0400 Subject: Generating NIST/Brainpool subkeys with GPGME Message-ID: It appears that one cannot currently generate NIST or Brainpool subkeys with GPGME. Using GPG itself works fine with --expert, so am I missing an option or is this simply not possible yet? I've attached a simple test program and the output I get on my machine is below: ./eccsubkeys rsa1024 GPGME Version: 1.11.1 GPG Version: 2.2.8 Master: 2D14FBF15919954E4334D451C67CB3237C3CFFF4 Signing: A8B50168D9051846A570445A5DD5249F5CD0825F Encryption: F8D8B9A453E5A7E98F44CC029F8450A1638414BE Authentication: 866E75EDC8BDEB4B5A4DBD62865FAF7AB6DE6367 ./eccsubkeys nistp384 GPGME Version: 1.11.1 GPG Version: 2.2.8 Master: 27A05F867C37442B675CFC1B9C647EA952B0D156 GPGME: General error ./eccsubkeys brainpoolP384r1 GPGME Version: 1.11.1 GPG Version: 2.2.8 Master: 26B2C8D94AD12A160262C82FED06C709E119D584 GPGME: General error Thanks, Jacob -------------- next part -------------- A non-text attachment was scrubbed... Name: eccsubkeys.c Type: text/x-csrc Size: 1905 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From tookmund at gmail.com Sat Jun 30 01:45:16 2018 From: tookmund at gmail.com (Jacob Adams) Date: Fri, 29 Jun 2018 19:45:16 -0400 Subject: Pinentry: Inappropriate ioctl for device when getting smartcard PIN In-Reply-To: <733b219b-86c0-d177-4999-15da2a285930@gmail.com> References: <733b219b-86c0-d177-4999-15da2a285930@gmail.com> Message-ID: <5341d22f-2234-88ab-3655-d305ee92d334@gmail.com> On 06/27/2018 04:50 PM, Jacob Adams wrote: > I've got another pinentry problem unfortunately. > The tty is owned by the correct user this time and $GPG_TTY is set > correctly. > > I have two gpgme contexts, one for openpgp and another for assuan > commands to the smartcard. Pinentry triggered by the openpgp context > works perfectly, but any pinentry launched in service of the assuan > context fails with the error in the subject. They're both using the same > gpg-agent launched shortly after the creation of the openpgp context > with gpgconf --launch gpg-agent. > > The relevant logs are available at: > https://salsa.debian.org/tookmund-guest/pgpcr/issues/10 > I've now done a bit of poking around into this. Attached is the patch I used to try and get some information out of pinentry-curses. It appears that tty_name is not being set, despite the fact that GPG_TTY is set and thus gpg-agent has this information from the previous Context. > I'm really not sure what's going wrong here and any insight would be > much appreciated. The above is still definitely true. Thanks, Jacob -------------- next part -------------- --- a/pinentry/pinentry-curses.c +++ b/pinentry/pinentry-curses.c @@ -26,6 +26,7 @@ #include #include #include +#include #include #include #include @@ -820,6 +821,16 @@ dialog_run (pinentry_t pinentry, const char *tty_name, const char *tty_type) { int confirm_mode = !pinentry->pin; + FILE *log = fopen("/tmp/pinentry-curses.log", "a"); + if (log == NULL) + { + pinentry->specific_err = gpg_error_from_syserror (); + pinentry->specific_err_loc = "log_setup"; + return confirm_mode? 0 : -1; + } + fputs("Pinentry\n", log); + fprintf(log, "TTY Name: %s\nTTY Type: %s\n", tty_name, tty_type); + fprintf(log, "Title: %s\nDescription: %s\n", pinentry->title, pinentry->description); struct dialog diag; FILE *ttyfi = NULL; FILE *ttyfo = NULL; @@ -853,6 +864,7 @@ pinentry->specific_err_loc = "open_tty_for_read"; return confirm_mode? 0 : -1; } + fputs("Open TTY for reading\n", log); ttyfo = fopen (tty_name, "w"); if (!ttyfo) { @@ -863,15 +875,19 @@ pinentry->specific_err_loc = "open_tty_for_write"; return confirm_mode? 0 : -1; } + fputs("Open TTY for writing\n", log); screen = newterm (tty_type, ttyfo, ttyfi); set_term (screen); + fputs("Setup screen\n", log); } else { if (!init_screen) { + fputs("No init screen\n", log); if (!(isatty(fileno(stdin)) && isatty(fileno(stdout)))) { + fputs("ENOTTY\n", log); errno = ENOTTY; pinentry->specific_err = gpg_error_from_syserror (); pinentry->specific_err_loc = "isatty"; @@ -879,6 +895,7 @@ } init_screen = 1; initscr (); + fputs("Setup ncurses\n", log); } else clear (); @@ -921,10 +938,11 @@ } } refresh (); - +fputs("Create dialog\n", log); /* Create the dialog. */ if (dialog_create (pinentry, &diag)) { + fputs("Failed to create dialog\n", log); /* Note: pinentry->specific_err has already been set. */ endwin (); if (screen) @@ -951,6 +969,7 @@ do { + fputs("Made it to event loop\n", log); int c; c = wgetch (stdscr); /* Refresh, accept single keystroke of input. */ --- a/curses/pinentry-curses.c +++ b/curses/pinentry-curses.c @@ -34,8 +34,17 @@ int main (int argc, char *argv[]) { + FILE *log = fopen("/tmp/pinentry-args.log", "a"); + if (log == NULL) + { + return 1; + } + fputs("Begin Pinentry\n", log); pinentry_init ("pinentry-curses"); - + for (int i = 0; i < argc; i++) + { + fprintf(log, "%d: %s\n", i, argv[i]); + } pinentry_parse_opts (argc, argv); if (pinentry_loop ()) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From gnupg-users at spodhuis.org Sat Jun 30 01:51:07 2018 From: gnupg-users at spodhuis.org (Phil Pennock) Date: Fri, 29 Jun 2018 19:51:07 -0400 Subject: Choice of ECC curve on usb token In-Reply-To: <87lgax7f0o.fsf@cassou.me> References: <87wouioxh4.fsf@cassou.me> <877emhn86p.fsf@fsij.org> <87lgax7f0o.fsf@cassou.me> Message-ID: <20180629235106.GA23508@osmium.lan> On 2018-06-29 at 18:07 +0200, Damien Cassou wrote: > NIIBE Yutaka writes: > > Why not Curve25519, if you use ECC? > > I'm not sure I want ECC after reading this: > https://crypto.stackexchange.com/a/60394/60027 Curve25519 is not NIST ECC. It is ECC. "ECC" = "Elliptic Curve Cryptography", it covers an entire class of "how public/private pairs are related and calculated". There are various different algorithms within ECC. Some of those are published by NIST, with input from various agencies, and there is reasonable concern as to the provenance of the specifications, as that page notes. The IETF, amongst other groups, has been moving towards Curve25519 for public key cryptography because it is ECC and it's not NIST. It currently looks, with a wet finger in the air and an array of chicken entrails before us, from every known species of chicken, as though Curve25519 is likely to be good for a while to come; up until the much heralded practical quantum computers one day arrive and possibly change everything. So for new deployments today, where interoperability with ancient OpenPGP implementations (such as GnuPG v1) is not a concern, you're probably looking at Curve25519 and, if eager, keeping half an eye on the news about post-quantum cryptography for the next step after that. If you need more specific guidance than that, pay a professional cryptographer to analyse your requirements and make a recommendation. -Phil From dirk.gottschalk1980 at googlemail.com Sat Jun 30 13:20:55 2018 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Sat, 30 Jun 2018 13:20:55 +0200 Subject: Pinentry does not show "please insert smartcard" dialog In-Reply-To: <20180627074208.dpn2z2mi3agswev3@danton.fire-world.de> References: <20180627074208.dpn2z2mi3agswev3@danton.fire-world.de> Message-ID: <7caacdf33f7192a5d41752816544a0dfab70ee7c.camel@googlemail.com> Hello. Am Mittwoch, den 27.06.2018, 09:42 +0200 schrieb Sebastian Wiesinger: > What doesn't work is the "please insert smartcard" dialog when the > key > is not plugged in. I manually added the correct keygrip to the > sshcontrol file but this does not work. On my MacOS the same config > does display the "insert smartcard" dialog. > > Any idea why it doesn't work on my Linux system or how to find out? I > already tried multiple debug options but no helpful info showed up in > the logs. There is no card reader available, when yubikey is not plugged in. I use the smartcard with a external reader. I also do not see this dialof when the Reader is not connected. I think, there is a dependence to a connected reader to schow this dialog. Regards, Dirk -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen Tel.: +49 1573 1152350 -------------- 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 johndoe65534 at mail.com Sat Jun 30 21:26:13 2018 From: johndoe65534 at mail.com (john doe) Date: Sat, 30 Jun 2018 21:26:13 +0200 Subject: dirmngr cygwin resolv.conf In-Reply-To: <874lhln7ln.fsf@fsij.org> References: <2668e804-4468-774b-702f-62a3695e0e9a@mail.com> <87zhzgkw9c.fsf@wheatstone.g10code.de> <4b9eb287-7ef3-ff97-6838-943af8a92ca7@mail.com> <871scr17br.fsf@wheatstone.g10code.de> <5f12448e-fab6-6eba-325b-7273677cf822@mail.com> <87wouim4ma.fsf@iwagami.gniibe.org> <874lhln7ln.fsf@fsij.org> Message-ID: <6d5be269-6474-f829-c3d0-7bd9d278aeb0@mail.com> Hi Niibe, On 6/29/2018 1:40 PM, NIIBE Yutaka wrote: > Hello, > > Sorry, my explanation was not accurate. In the Tor-mode of dirmngr, it > uses the port 9050 at first. And there is some code to fallback to the > port 9150. It's like: > > libdns_switch_port_p (gpg_error_t err) > { > if (tor_mode && gpg_err_code (err) == GPG_ERR_ECONNREFUSED > && libdns_tor_port == TOR_PORT) > { > /* Switch port and try again. */ > if (opt_debug) > log_debug ("dns: switching from SOCKS port %d to %d\n", > TOR_PORT, TOR_PORT2); > libdns_tor_port = TOR_PORT2; > libdns_reinit_pending = 1; > return 1; > } > return 0; > } > > I suspect the error detection is not working well. If it works, > you should see the debug message of "dns: switching from SOCKS port...". > > I tested with the port 9050, my dirmngr works fine. > Appologies for not answering sooner. The issue is that in the case of "Tor Browser" it listens only for socks5 connection on port 9150.: https://lists.torproject.org/pipermail/tor-community-team/2018-June/000188.html How can I force dirmngr to use port "9150"? Sorry again for my late answer, I had overlooked your e-mail. I really appriciate any help/input! :) -- John Doe