From evan at eklitzke.org Tue Aug 1 07:26:03 2017 From: evan at eklitzke.org (Evan Klitzke) Date: Tue, 01 Aug 2017 05:26:03 +0000 Subject: Reading Passwords From /dev/tty Message-ID: Hi all, I have a question about something I've seen in the GnuPG source code, and I hope someone here knows the answer. Many Unix programs, including GPG, read from /dev/tty when reading a password. In GnuPG the code for this lives in common/ttyio.c, in particular via tty_get_hidden() which calls do_get(). As I understand it, you get a pseudo-TTY (pty) file descriptor when you open /dev/tty, and then that fd is put into no echo mode before reading the password. This is also how sudo reads passwords (by default anyway, it has a mode to fall back to stdin). I have seen some other projects that read passwords by putting stdin into no echo mode, and then literally just reading from stdin. This *does* seem to work (assuming you make sure to restore echoing after reading the password!), but I am curious why projects like GPG and sudo prefer using /dev/tty. Does anyone know what the argument is for using a pseudo-TTY? Thanks, Evan -- Evan Klitzke https://eklitzke.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From aheinecke at intevation.de Tue Aug 1 08:55:51 2017 From: aheinecke at intevation.de (Andre Heinecke) Date: Tue, 01 Aug 2017 08:55:51 +0200 Subject: libreoffice uses gpgme to sign In-Reply-To: <201707311552.53403.bernhard@intevation.de> References: <201707311552.53403.bernhard@intevation.de> Message-ID: <2843686.UTuAnJEKWB@esus> Hi, On Monday, July 31, 2017 3:52:48 PM CEST Bernhard Reiter wrote: > https://wiki.documentfoundation.org/ReleaseNotes/5.4 > announces the ability to sign documents under GNU/Linux. I find it very nice that Libreoffice is starting to get support for GnuPG / OpenPGP. I'm really looking forward to encryption of documents because even I failed to get Libreoffice really working with my S/MIME certificates through Firefox. So this might be a real boost for crypto if it is more user friendly. But [1], I tried this out and I found this is more of a proof of concept or prototype. OpenPGP Keys are "faked" to be S/MIME certs with fields like issuer etc. shown which is not a very nice user interface and there are big bugs in there. E.g. if you switch the signing key the GUI will show a different key then the Key which was acutally used for Signing even if you hit show signatures etc. I would not have considered the current state to be "production ready". What I find mostly disappointing is that while there is the option to launch Kleopatra they have their own "Certificate Details" Dialog which is very ugly and does things like showing the Fingerprint in decimal notation. Using Kleopatra for Certificate Details is as easy as calling Kleopatra with the Fingerprint of the certificate. I would happily accept Patches to Kleopatra if Libreoffice would need some features there that are currently not offered. On Monday, July 31, 2017 3:52:48 PM CEST Bernhard Reiter wrote: > The notes link the following commit > https://cgit.freedesktop.org/libreoffice/core/commit/? id=3e3b37ca4cbc881628a71715b67ac172018cf9f2 > which show some gpgme use. It's nice to know that they use GPGME, even GpgME++, which shows that it was a good move to put the language binding into GPGME imo because I doubt that it would have been used otherwise. :-) Regards, Andre 1: Disclaimer: My employer also bid on that project and we did not get it so take my criticism with a grain of salt because it's always easy to find fault with others ;-) -- 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 aheinecke at intevation.de Tue Aug 1 09:10:49 2017 From: aheinecke at intevation.de (Andre Heinecke) Date: Tue, 01 Aug 2017 09:10:49 +0200 Subject: libreoffice uses gpgme to sign In-Reply-To: <2843686.UTuAnJEKWB@esus> References: <201707311552.53403.bernhard@intevation.de> <2843686.UTuAnJEKWB@esus> Message-ID: <3915521.DZR047Tg1d@esus> On Tuesday, August 1, 2017 8:55:51 AM CEST Andre Heinecke wrote: > there are big bugs in there. E.g. if you switch the signing key the GUI > will show a different key then the Key which was acutally used for > Signing even if you hit show > signatures etc. I would not have considered the current state to be > "production ready". Have to roll back on this one a bit. There is some confusing behavior if you switch signing keys, but I had a problem in my test setup that caused my to think a signature could not be made when in fact it did. So I don't think anymore that it showed me wrong signature information. 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 dkg at fifthhorseman.net Tue Aug 1 16:58:45 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 01 Aug 2017 10:58:45 -0400 Subject: Reading Passwords From /dev/tty In-Reply-To: References: Message-ID: <87wp6n72sa.fsf@fifthhorseman.net> Hi Evan-- On Tue 2017-08-01 05:26:03 +0000, Evan Klitzke wrote: > I have seen some other projects that read passwords by putting stdin into > no echo mode, and then literally just reading from stdin. This *does* seem > to work (assuming you make sure to restore echoing after reading the > password!), but I am curious why projects like GPG and sudo prefer using > /dev/tty. Does anyone know what the argument is for using a pseudo-TTY? gpg might be used in a pipeline from within a terminal. In that case, the program might want to know the "controlling terminal" for the process (see the manpage tty(4) e.g. via "man 4 tty"), and it might choose to prompt the user there, even if stdin, stdout, and stderr are all pointing somewhere else. does that make sense? Consider the following program: /* controlling-terminal.c */ #include #include #include #include #include #include #include int main(int argc, const char * argv[]) { int fd = open("/dev/tty", O_RDWR); if (fd != -1) { fprintf(stderr, "opened as fd %d\n", fd); write(fd, "abc123\n", 7); } else { fprintf(stderr, "did not open: (%d) %s", errno, strerror(errno)); } return 0; } /* end controlling-terminal.c */ If you compile and then run it in a shell pipeline like this: echo test | ./controlling-terminal 2>/dev/null | cat > /dev/null the result is that -- even though the process has no file descriptor open that is associated with the tty -- it still manages to print "abc123\n" to the tty. That's useful output for a password prompt. And input (e.g. for reading a password from the user) works the same way. hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From Katarina.Behrens at cib.de Tue Aug 1 22:43:23 2017 From: Katarina.Behrens at cib.de (Katarina Behrens) Date: Tue, 1 Aug 2017 20:43:23 +0000 Subject: libreoffice uses gpgme to sign In-Reply-To: <201707311552.53403.bernhard@intevation.de> References: <201707311552.53403.bernhard@intevation.de> Message-ID: Hello world, > https://wiki.documentfoundation.org/ReleaseNotes/5.4 > announces the ability to sign documents under GNU/Linux. I'm a Libreoffice developer and I've been lurking on this ML for a while already (although I didn't have much to say so far :)) I was involved (together with my awesome colleagues Thorsten and Samuel) in implementing this feature. So ye, in Libreoffice we're using gpgme (its C++ interface) and xmlsec to sign ODF documents, so far only on Linux (Windows support proved to be extremely tough nut to crack). For Libreoffice 6.0, PoC of encryption w/ gpgme is planned. I'd like to encourage you people (should you feel like trying this Libreoffice feature for yourself) to file any issues you find into Document Foundation Bugzilla [1]. And if you could please tag them with "gpg4libre" keyword, it'd be helpful as it makes it easier for us to find those tickets ... thank you. I'm most happy to listen and incorporate any other feedback you might have, anything that may help us to make this feature even better ... But now, holiday time, so back to the swimming pool ? > Background: > That is probably is a result of the public tender > https://www.evergabe-online.de/tenderdetails.html?id=133672 It is a result of that tender indeed. Bubli .oO [1] https://bugs.documentfoundation.org/ -- Katarina Behrens Softwareentwicklerin LibreOffice ??? CIB software GmbH Gesch?ftsstelle Hamburg Flachsland 10 22083 Hamburg ??? T +49 (40) / 28 48 42 -235 F +49 (40) / 28 48 42 -100 Katarina.Behrens at cib.de www.cib.de ??? Sitz: M?nchen Registergericht M?nchen, HRB 123286 Gesch?ftsf?hrer: Dipl.-Ing. Ulrich Brandner From dkg at fifthhorseman.net Wed Aug 2 08:44:05 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 02 Aug 2017 02:44:05 -0400 Subject: [PATCH] only document --faked-system-time for gpg 2.1 and later In-Reply-To: <87wq9kg2m4.fsf@vigenere.g10code.de> References: <1409754037-22421-1-git-send-email-dkg@fifthhorseman.net> <87wq9kg2m4.fsf@vigenere.g10code.de> Message-ID: <871soueafe.fsf@fifthhorseman.net> On Wed 2014-09-03 17:12:03 +0200, Werner Koch wrote: > On Wed, 3 Sep 2014 16:20, dkg at fifthhorseman.net said: > >> (The other way to resolve the problem would be to backport the >> faked-system-time call to earlier branches of gpg) > > Oh no, no backports for such changes. The risk of breaking stuff is too > high. > > I will wait a few days before I apply your patch in case you find some > more of these tiny things. it's been a few years :) Is this patch to fix documentation of faked-system-time something that we don't want applied for some reason, or is there a better way to clean this up for the classic branch? --dkg From caro at nymph.paranoici.org Wed Aug 2 16:11:09 2017 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Wed, 2 Aug 2017 14:11:09 +0000 (UTC) Subject: [PATCH] only document --faked-system-time for gpg 2.1 and later References: <1409754037-22421-1-git-send-email-dkg@fifthhorseman.net> <87wq9kg2m4.fsf@vigenere.g10code.de> <871soueafe.fsf@fifthhorseman.net> Message-ID: <20170802141109.F2F9E100E570@remailer.paranoici.org> On Wed, 02 Aug 2017 02:44:05 -0400, Daniel Kahn Gillmor wrote: >On Wed 2014-09-03 17:12:03 +0200, Werner Koch wrote: >> On Wed, 3 Sep 2014 16:20, dkg at fifthhorseman.net said: >> >>> (The other way to resolve the problem would be to backport the >>> faked-system-time call to earlier branches of gpg) >> >> Oh no, no backports for such changes. The risk of breaking stuff is too >> high. >> >> I will wait a few days before I apply your patch in case you find some >> more of these tiny things. > >it's been a few years :) Is this patch to fix documentation of >faked-system-time something that we don't want applied for some reason, >or is there a better way to clean this up for the classic branch? In case anyone else needs to keep the date of data processing a secret, the OmniMix package v2.4.0 ff. (MS Windows) comes with a patched GnuPG 1.4.21 version, which allows to predefine the signature timestamp with a --sig-date parameter (e.g. '--sig-date 20170801T120000'). Diff file included. http://www.danner-net.de/om.htm Kind regards Caro From wk at gnupg.org Thu Aug 3 17:46:43 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 03 Aug 2017 17:46:43 +0200 Subject: [PATCH] only document --faked-system-time for gpg 2.1 and later In-Reply-To: <871soueafe.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 02 Aug 2017 02:44:05 -0400") References: <1409754037-22421-1-git-send-email-dkg@fifthhorseman.net> <87wq9kg2m4.fsf@vigenere.g10code.de> <871soueafe.fsf@fifthhorseman.net> Message-ID: <873798vel8.fsf@wheatstone.g10code.de> On Wed, 2 Aug 2017 08:44, dkg at fifthhorseman.net said: > it's been a few years :) Is this patch to fix documentation of > faked-system-time something that we don't want applied for some reason, I can't remember that. Do we have a bug number for this? Documentation fixes are of course still welcome for 2.2. Note that --faked-system-time is mostly a debug option and should not be consider part of the stable API. In fact it may trigger certain bugs which are not easy to fix. Salam-Shalom, Werner -- 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 Aug 3 17:53:46 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 03 Aug 2017 17:53:46 +0200 Subject: Reading Passwords From /dev/tty In-Reply-To: (Evan Klitzke's message of "Tue, 01 Aug 2017 05:26:03 +0000") References: Message-ID: <87y3r0tzp1.fsf@wheatstone.g10code.de> On Tue, 1 Aug 2017 07:26, evan at eklitzke.org said: > password!), but I am curious why projects like GPG and sudo prefer using > /dev/tty. Does anyone know what the argument is for using a pseudo-TTY? dkg already explained the primary reason. Another reason why we don't use stdin is to avoid extra buffer in the stdio layer. Well, that can also be disabled but then using read(2) directly is easier. Shalom-Salam, Werner -- 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 alon.barlev at gmail.com Thu Aug 3 20:41:35 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Thu, 3 Aug 2017 21:41:35 +0300 Subject: [PATCH GPGME] python: Support parallel build in tests Message-ID: <20170803184135.8464-1-alon.barlev@gmail.com> * lang/python/tests/Makefile.am: Depend xcheck with all which was lost due to the check hack. Signed-off-by: Alon Bar-Lev --- lang/python/tests/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lang/python/tests/Makefile.am b/lang/python/tests/Makefile.am index d0dde1d3..beb5a309 100644 --- a/lang/python/tests/Makefile.am +++ b/lang/python/tests/Makefile.am @@ -71,7 +71,7 @@ check: xcheck .PHONY: xcheck -xcheck: +xcheck: all $(TESTS_ENVIRONMENT) $(PYTHON) $(srcdir)/run-tests.py \ --interpreters="$(PYTHONS)" --srcdir=$(srcdir) $(TESTFLAGS) \ $(XTESTS) -- 2.13.0 From evan at eklitzke.org Fri Aug 4 08:55:23 2017 From: evan at eklitzke.org (Evan Klitzke) Date: Thu, 3 Aug 2017 23:55:23 -0700 Subject: Reading Passwords From /dev/tty In-Reply-To: <87wp6n72sa.fsf@fifthhorseman.net> References: <87wp6n72sa.fsf@fifthhorseman.net> Message-ID: On Tue, Aug 1, 2017 at 7:58 AM, Daniel Kahn Gillmor wrote: > > Hi Evan-- > > On Tue 2017-08-01 05:26:03 +0000, Evan Klitzke wrote: > > I have seen some other projects that read passwords by putting stdin into > > no echo mode, and then literally just reading from stdin. This *does* seem > > to work (assuming you make sure to restore echoing after reading the > > password!), but I am curious why projects like GPG and sudo prefer using > > /dev/tty. Does anyone know what the argument is for using a pseudo-TTY? > > gpg might be used in a pipeline from within a terminal. In that case, > the program might want to know the "controlling terminal" for the > process (see the manpage tty(4) e.g. via "man 4 tty"), and it might > choose to prompt the user there, even if stdin, stdout, and stderr are > all pointing somewhere else. Hi Daniel, That does make sense. I've also noticed that it is easier to interact with programs that use /dev/tty, as it's a lot simpler for the parent process to detect and interact with the password prompt (especially in the case where the program prints non-prompt data to stdout). I wanted to send out a few patches to programs that don't already use /dev/tty, and having this answer will surely help. Thanks, Evan P.S. Thanks Werner as well, your answer also made a lot of sense. From dkg at fifthhorseman.net Fri Aug 4 18:24:25 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 04 Aug 2017 12:24:25 -0400 Subject: [PATCH] only document --faked-system-time for gpg 2.1 and later In-Reply-To: <873798vel8.fsf@wheatstone.g10code.de> References: <1409754037-22421-1-git-send-email-dkg@fifthhorseman.net> <87wq9kg2m4.fsf@vigenere.g10code.de> <871soueafe.fsf@fifthhorseman.net> <873798vel8.fsf@wheatstone.g10code.de> Message-ID: <87d18bwbba.fsf@fifthhorseman.net> On Thu 2017-08-03 17:46:43 +0200, Werner Koch wrote: > On Wed, 2 Aug 2017 08:44, dkg at fifthhorseman.net said: > >> it's been a few years :) Is this patch to fix documentation of >> faked-system-time something that we don't want applied for some reason, > > I can't remember that. Do we have a bug number for this? we do now: https://dev.gnupg.org/T3329 > Documentation fixes are of course still welcome for 2.2. i would hope that documentation fixes are still welcome on any maintained branch. > Note that --faked-system-time is mostly a debug option and should not > be consider part of the stable API. In fact it may trigger certain > bugs which are not easy to fix. How is the user supposed to know this? --dkg From wk at gnupg.org Sat Aug 5 19:03:04 2017 From: wk at gnupg.org (Werner Koch) Date: Sat, 05 Aug 2017 19:03:04 +0200 Subject: [PATCH] only document --faked-system-time for gpg 2.1 and later In-Reply-To: <87d18bwbba.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 04 Aug 2017 12:24:25 -0400") References: <1409754037-22421-1-git-send-email-dkg@fifthhorseman.net> <87wq9kg2m4.fsf@vigenere.g10code.de> <871soueafe.fsf@fifthhorseman.net> <873798vel8.fsf@wheatstone.g10code.de> <87d18bwbba.fsf@fifthhorseman.net> Message-ID: <87r2wqrlpz.fsf@wheatstone.g10code.de> On Fri, 4 Aug 2017 18:24, dkg at fifthhorseman.net said: > i would hope that documentation fixes are still welcome on any > maintained branch. Sure. > How is the user supposed to know this? Reading the (updated) documentation ;-) Shalom-Salam, Werner -- 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 dirkx at webweaving.org Sun Aug 6 19:53:14 2017 From: dirkx at webweaving.org (Dirk-Willem van Gulik) Date: Sun, 6 Aug 2017 19:53:14 +0200 Subject: Bridging the airgap Message-ID: <78021E33-C0CE-462E-8DC4-F0BF1C6326DE@webweaving.org> Peter, Werber, As per the IRC discussion - below is a slightly hacked testscript of ours that allows you to abuse a suitable chipcart or yubico PGP card with x509 functionality to `bridge' an airgap during generation where one *also* wants the public key to be transported of the secure initial generation (or renewal of the expiry of the subkeys) by means of a smartcart itself (which you sort of axiomatically need to be able to trust they airgap). I've stripped the test case down somewhat - i.e. the bit that initialises the PGP applet, generates the master and 3 subkeys, moves them to smart cards, etc, etc. Dw. # Reset the card or key; and let it generate a public/private key # pair (as some do not allow the loading of a (ca or signed cert) # without it containing a private key. # #TMPDIR=${TMPDIR:-/tmp} DIR="${TMPDIR}/test-y-0012.$$" mkdir -p "$DIR" || exit 1 ( set -e cd "$DIR" chmod 700 . # Reset the card and generate a small public/private pair. # Then export a CSR we can import again signed. # # We do this as some cards do *not* accept (import) an x509 which is # not related to their own public key (and only acccept the CA key in # a later slot if you work your way up the chain from leaf to top). # yubico-piv-tool -a reset yubico-piv-tool -s 9a -A ECCP256 -a generate > pub.pem yubico-piv-tool -s 9a -S '/CN=foo/' -P 123456 -a verify -a request < pub.pem > pub.csr # Generate a defaultish public/private test pair. # gpg2 --homedir . --batch --passphrase 123456 --quick-generate-key test at test.com gpg2 --homedir . --export test at test.com > gpg.pub.raw # We create a raw OCTED string (sequence of 8 bit values) # of a given lengt. For length we need long form - as # it will be over 127 bytes. We sort of cheat and assume # that 4 bytes will always cut it. # OIDVAL=$( set `wc -c gpg.pub.raw` S=$(printf "%08x" $2 | sed -e 's/\(..\)/:\1/g') # Octed string (raw 8 bit bytes), of given length. # /bin/echo -n DER:04:84$S od -t x1 gpg.pub.raw | while read skip line do if [ ! -z "$line" ]; then set $line for i in $* do /bin/echo -n :$i done fi done ) # We need to provide the OIDs for each of our private # extensions. # cat < oids 1.3.6.1.4.1.2692.99.1 geo Location (WGS84) 1.3.6.1.4.1.2692.99.1.1 geoLa Latitude (WGS84) 1.3.6.1.4.1.2692.99.1.2 geoLon Longitude (WGS84) 1.3.6.1.4.1.2692.99.3 imgSHA1 SHA1 of the image 1.3.6.1.4.1.2692.99.4 imgURL URL of the image 1.3.6.1.4.1.2692.99.5 screenURL URL of a medical DICOM screen 1.3.6.1.4.1.2692.99.6 rawPGP raw (byte) PGP public key file. 2.16.528.1.1003.1.3.2.4.1.1 uziZorgverlenerCA UZI-register, Zorgverlener CA, Royal Kingdom of the Netherlands EOM cat < openssl.tmp [default] oid_file=oids [gpgraw] 1.3.6.1.4.1.2692.99.6=$OIDVAL EOM # Create myself a miniature CA. openssl req -new -x509 -out ca.pem -subj /CN=moi/ -nodes # And use that to sign the CSR; and give the signed cert # an extension with our PGP public key. # openssl x509 -req -in pub.csr -CA ca.pem -CAkey privkey.pem -set_serial 01 \ -outform DER -out pub.der \ -extfile openssl.tmp -extensions gpgraw yubico-piv-tool -s 9a -a import-certificate -K DER < pub.der # Now fake an removal of the smart card for 5 seconds. Specifically # for platforms like OSX that can cache things. # set `lsusb | grep Yu | head -1` usbpowerctrl $3 down sleep 5 usbpowerctrl $3 up # Extract again # As we have se the Serial to '01' -- we know what to ask for here. pkcs15-tool --read-certificate 01 | openssl asn1parse -oids oids | grep HEX # ... and pipe it back into GPG. ) E=$? rm -rf "${DIR}" exit $E From dkg at fifthhorseman.net Mon Aug 7 09:23:35 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 07 Aug 2017 03:23:35 -0400 Subject: using two inotify sockets Message-ID: <877eyfvo20.fsf@fifthhorseman.net> hey folks-- I've noticed that gpg-agent is now using two inotify sockets instead of one, as of this commit: 1ead1ca818bddabc3bca22c195be667993eb3e2e agent: Shutdown on removal of the home directory. * common/sysutils.c (gnupg_inotify_watch_delete_self): New. * agent/gpg-agent.c (handle_connections): Rename my_inotify_fd to sock_inotify_fd. (handle_connections): Add home_inotify_fd to watch the home directory. -- GnuPG-bug-id: 3218 Note that we should add this also to dirmngr. And for non-Linux systems a stat in ticker should be implemented. Signed-off-by: Werner Koch It's not clear to me what the advantage is of having two inotify sockets instead of having a single inotify socket which is watching multiple locations. I'm inclined to write a patch to simplify it to use only one inotify socket, but if there's a reason to use two that i'm unaware of i'd rather hear about it before i make the changes. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From dkg at fifthhorseman.net Mon Aug 7 09:29:28 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 07 Aug 2017 03:29:28 -0400 Subject: gpg-agent self-termination when private-keys-v1.d goes away In-Reply-To: <87ink0f34b.fsf@wheatstone.g10code.de> References: <87k24gpk8f.fsf@fifthhorseman.net> <87bmpskvxc.fsf@thinkbox.jade-hamburg.de> <87ink0f34b.fsf@wheatstone.g10code.de> Message-ID: <873793vns7.fsf@fifthhorseman.net> On Tue 2017-06-13 15:07:00 +0200, Werner Koch wrote: > On Tue, 13 Jun 2017 12:45, justus at g10code.com said: > >> For the other platforms, we can periodically stat the directory in the >> thread that manually watches the sockets. > > Which I think is anyway the better solution than the non-portable > inotify. But we also need to consider the implications that we need to > use stat in contrast to fstat; the directory entry might have already > gone while gpg-agent still has a connection and is working fine on the > inode. for those following this thread, this was reported and resolved in https://dev.gnupg.org/T3218 (and shipped in 2.1.22). --dkg From neal at walfield.org Mon Aug 7 12:13:49 2017 From: neal at walfield.org (Neal H. Walfield) Date: Mon, 07 Aug 2017 12:13:49 +0200 Subject: Bridging the airgap In-Reply-To: <78021E33-C0CE-462E-8DC4-F0BF1C6326DE@webweaving.org> References: <78021E33-C0CE-462E-8DC4-F0BF1C6326DE@webweaving.org> Message-ID: <87y3qvit2a.wl-neal@walfield.org> On Sun, 06 Aug 2017 19:53:14 +0200, Dirk-Willem van Gulik wrote: > As per the IRC discussion - below is a slightly hacked testscript of > ours that allows you to abuse a suitable chipcart or yubico PGP card > with x509 functionality to `bridge' an airgap during generation > where one *also* wants the public key to be transported of the > secure initial generation (or renewal of the expiry of the subkeys) > by means of a smartcart itself (which you sort of axiomatically need > to be able to trust they airgap). This is a neat idea. Did you try using OpenPGP private DOs (data objects) to store this data? See 4.4.3.1 of the OpenPGP card spec: https://gnupg.org/ftp/specs/OpenPGP-smart-card-application-3.3.pdf I'd be interested to hear what cards have enough space for this. :) Neal From dirkx at webweaving.org Mon Aug 7 13:18:17 2017 From: dirkx at webweaving.org (Dirk-Willem van Gulik) Date: Mon, 7 Aug 2017 13:18:17 +0200 Subject: Bridging the airgap In-Reply-To: <87y3qvit2a.wl-neal@walfield.org> References: <78021E33-C0CE-462E-8DC4-F0BF1C6326DE@webweaving.org> <87y3qvit2a.wl-neal@walfield.org> Message-ID: <5E350E7B-4366-4B52-9921-B8662C63DE03@webweaving.org> > On 7 Aug 2017, at 12:13, Neal H. Walfield wrote: > > On Sun, 06 Aug 2017 19:53:14 +0200, > Dirk-Willem van Gulik wrote: >> As per the IRC discussion - below is a slightly hacked testscript of >> ours that allows you to abuse a suitable chipcart or yubico PGP card >> with x509 functionality to `bridge' an airgap during generation >> where one *also* wants the public key to be transported of the >> secure initial generation (or renewal of the expiry of the subkeys) >> by means of a smartcart itself (which you sort of axiomatically need >> to be able to trust they airgap). > > This is a neat idea. Did you try using OpenPGP private DOs (data > objects) to store this data? Yes ! > See 4.4.3.1 of the OpenPGP card spec: > > https://gnupg.org/ftp/specs/OpenPGP-smart-card-application-3.3.pdf > > I'd be interested to hear what cards have enough space for this. We?ve never used/seen cards newer than 2.1 (or have any which respond to DO 7F66); on those 2.1 applets ? I think that 101 et.al. is just shy of 255 bytes. We?ve been using mixed x509 and openpgp cards/usb-sticks. Any suggestions for pure open-pgp cards that are newer ? Dw. From neal at walfield.org Mon Aug 7 13:28:54 2017 From: neal at walfield.org (Neal H. Walfield) Date: Mon, 07 Aug 2017 13:28:54 +0200 Subject: Bridging the airgap In-Reply-To: <5E350E7B-4366-4B52-9921-B8662C63DE03@webweaving.org> References: <78021E33-C0CE-462E-8DC4-F0BF1C6326DE@webweaving.org> <87y3qvit2a.wl-neal@walfield.org> <5E350E7B-4366-4B52-9921-B8662C63DE03@webweaving.org> Message-ID: <87inhz39c9.wl-neal@walfield.org> Hi, On Mon, 07 Aug 2017 13:18:17 +0200, Dirk-Willem van Gulik wrote: > > On 7 Aug 2017, at 12:13, Neal H. Walfield wrote: > > > > On Sun, 06 Aug 2017 19:53:14 +0200, > > Dirk-Willem van Gulik wrote: > >> As per the IRC discussion - below is a slightly hacked testscript of > >> ours that allows you to abuse a suitable chipcart or yubico PGP card > >> with x509 functionality to `bridge' an airgap during generation > >> where one *also* wants the public key to be transported of the > >> secure initial generation (or renewal of the expiry of the subkeys) > >> by means of a smartcart itself (which you sort of axiomatically need > >> to be able to trust they airgap). > > > > This is a neat idea. Did you try using OpenPGP private DOs (data > > objects) to store this data? > > Yes ! > > > See 4.4.3.1 of the OpenPGP card spec: > > > > https://gnupg.org/ftp/specs/OpenPGP-smart-card-application-3.3.pdf > > > > I'd be interested to hear what cards have enough space for this. > > We?ve never used/seen cards newer than 2.1 (or have any which respond to DO 7F66); on those 2.1 applets ? I think that 101 et.al. is just shy of 255 bytes. > > We?ve been using mixed x509 and openpgp cards/usb-sticks. > > Any suggestions for pure open-pgp cards that are newer ? Sorry. It sounds like you know a lot more about OpenPGP smartcards than I do. (I've only ever glanced at the spec, but I've never tried to do anything advanced with the cards.) But, I think it would be great if the smartcards at least had enough information to recovery the public key. I've added Achim Pietig in cc. Perhaps he can comment on whether it is possible to add it to the spec. :) Neal From dirkx at webweaving.org Mon Aug 7 13:38:09 2017 From: dirkx at webweaving.org (Dirk-Willem van Gulik) Date: Mon, 7 Aug 2017 13:38:09 +0200 Subject: Bridging the airgap In-Reply-To: <87inhz39c9.wl-neal@walfield.org> References: <78021E33-C0CE-462E-8DC4-F0BF1C6326DE@webweaving.org> <87y3qvit2a.wl-neal@walfield.org> <5E350E7B-4366-4B52-9921-B8662C63DE03@webweaving.org> <87inhz39c9.wl-neal@walfield.org> Message-ID: <56707849-42C1-411A-867E-8D0736DB2EB1@webweaving.org> > On 7 Aug 2017, at 13:28, Neal H. Walfield wrote: ?.snip... > to do anything advanced with the cards.) But, I think it would be > great if the smartcards at least had enough information to recovery > the public key. I've added Achim Pietig in cc. Perhaps he can > comment on whether it is possible to add it to the spec. Yes - we find it useful. As this lets us extend the expiry of cards with relative ease - while keeping the compliance and infosec load managable (airgapped, not having to argue you do not have broad footprint, and with an `axiomatic? need to have the thing (3 subkeys) that crossed the airgap already have cross that gap already). Dw. From dkg at fifthhorseman.net Mon Aug 7 14:36:34 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 07 Aug 2017 08:36:34 -0400 Subject: running all the tests Message-ID: <87zibbtuzx.fsf@fifthhorseman.net> hello GnuPG folks-- This morning i noticed b0112dbca91e720a4ff622ad0e88d99eba56203a on master: tests: Do not run all tests unless in maintainer mode. * configure.ac: Leak the maintainer mode flag into 'config.h'. * tests/gpgscm/ffi.c: Pass it into the scheme environment. * tests/openpgp/all-tests.scm: Only run tests against non-default configurations (keyring, extended-key-format) in maintainer mode. -- Werner is concerned that the tests do take up too much time and asked me to reduce the runtime of the tests for normal users. Signed-off-by: Justus Winter I sympathize with Werner's concern: the test suite does currently take a long time. But I'm a little worried about this resolution, because it means we'll be less likely to get alerts about failure in many places (including the debian build daemon network, which tests over a dozen platforms but does not run the tests with --maintainer-mode). I took a look at the timing of test suite with --maintainer-mode enabled. I built all the binaries, and then i ran all the tests while timing them. I ran this on a machine with 4 cores of Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz. Here's what i saw: $ make -j4 check && time make -j4 check [ ... all tests pass ... ] real 7m7.513s user 1m56.696s sys 0m14.821s $ python3 -c 'print(1-(60+56.696+14.821)/(7*60+7.513))' 0.6923672496508878 $ So 69% of the time that the user is waiting for the test suite, the test suite is not using any CPU. If we could profile what the test suite is waiting on and fix those waits, then we could shave off over 2/3rds of the time without losing any test coverage. It also looked to me like the test suite wasn't running jobs in parallel. If the test suite could be parallelized (i don't know whether that's possible or if there's ) then on most modern computers it could run significantly faster as well. Do we know what the test suite is waiting on? if the waits are in the test suite, fixing them would let us run more tests in more places. If the waits are in GnuPG itself, then fixing them would give all GnuPG users lower latency. Either one seems like a good win. Is there any prospect of doing that profiling work instead of just disabling the tests? I think the expanded and more extensive test suite has been one of the major improvements in the modern branch of GnuPG and i'd hate to lose its reach and coverage. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From wk at gnupg.org Mon Aug 7 17:04:56 2017 From: wk at gnupg.org (Werner Koch) Date: Mon, 07 Aug 2017 17:04:56 +0200 Subject: using two inotify sockets In-Reply-To: <877eyfvo20.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 07 Aug 2017 03:23:35 -0400") References: <877eyfvo20.fsf@fifthhorseman.net> Message-ID: <87y3qvo1uv.fsf@wheatstone.g10code.de> On Mon, 7 Aug 2017 09:23, dkg at fifthhorseman.net said: > It's not clear to me what the advantage is of having two inotify sockets > instead of having a single inotify socket which is watching multiple > locations. - First, because it is easier to implement and is less likely to break working things. - Second, inotify may fail in certain cases. In particular for the socket removal detection we need to read the events (gnupg_inotify_has_name) and that is not fully free of races on the kernel level. OTOH, the homedir notification is much easier. There will be only one event and so we immeditely know when the directory has been removed. Shalom-Salam, Werner -- 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 Aug 7 17:23:54 2017 From: wk at gnupg.org (Werner Koch) Date: Mon, 07 Aug 2017 17:23:54 +0200 Subject: running all the tests In-Reply-To: <87zibbtuzx.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 07 Aug 2017 08:36:34 -0400") References: <87zibbtuzx.fsf@fifthhorseman.net> Message-ID: <87tw1jo0z9.fsf@wheatstone.g10code.de> On Mon, 7 Aug 2017 14:36, dkg at fifthhorseman.net said: > But I'm a little worried about this resolution, because it means we'll > be less likely to get alerts about failure in many places (including the > debian build daemon network, which tests over a dozen platforms but does The extra tests we don't let the user run are combinations of non-default options. In particular keyring/keybox things. However, we run them on our Jenkins and by testing them on 32 and 64 bit Unices, 32 bit Windows, and macOS it is very likely that we catch such rare errors and are able to fix them before we do a release. It does not help the user to detect a programming error. The user initiated "make check" is to assure that the build was correct. Note that for Libgcrypt we are even not running some tests on Jenkins but only run them by hand before a major release. They take several hours. I expect that we will get even more tests in GnuPG and thus we need to decide which tests can be run how often and what the benefits of these tests are. There is a way to run the checks in parallel but that is not the default because we like to have comparable test runs and don't depend on the order of execution. And they help only on multi-core CPUs. Maybe we should enable parallel tests in --enable-maintainer-mode by default, though. Salam-Shalom, Werner -- 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 justus at g10code.com Mon Aug 7 18:53:43 2017 From: justus at g10code.com (Justus Winter) Date: Mon, 07 Aug 2017 18:53:43 +0200 Subject: running all the tests In-Reply-To: <87zibbtuzx.fsf@fifthhorseman.net> References: <87zibbtuzx.fsf@fifthhorseman.net> Message-ID: <87inhzjp48.fsf@europa.jade-hamburg.de> Daniel Kahn Gillmor writes: > hello GnuPG folks-- > > This morning i noticed b0112dbca91e720a4ff622ad0e88d99eba56203a on master: > > tests: Do not run all tests unless in maintainer mode. > > * configure.ac: Leak the maintainer mode flag into 'config.h'. > * tests/gpgscm/ffi.c: Pass it into the scheme environment. > * tests/openpgp/all-tests.scm: Only run tests against non-default > configurations (keyring, extended-key-format) in maintainer mode. > -- > > Werner is concerned that the tests do take up too much time and asked > me to reduce the runtime of the tests for normal users. > > Signed-off-by: Justus Winter I'm saddened by this change as well. > It also looked to me like the test suite wasn't running jobs in > parallel. If the test suite could be parallelized (i don't know whether > that's possible or if there's ) then on most modern computers it could > run significantly faster as well. Yes. make check-all TESTFLAGS=--parallel. There is documentation in tests/openpgp/README. Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From wk at gnupg.org Mon Aug 7 20:32:11 2017 From: wk at gnupg.org (Werner Koch) Date: Mon, 07 Aug 2017 20:32:11 +0200 Subject: running all the tests In-Reply-To: <87inhzjp48.fsf@europa.jade-hamburg.de> (Justus Winter's message of "Mon, 07 Aug 2017 18:53:43 +0200") References: <87zibbtuzx.fsf@fifthhorseman.net> <87inhzjp48.fsf@europa.jade-hamburg.de> Message-ID: <87lgmvmdp0.fsf@wheatstone.g10code.de> Hi! Let's get some facts: My development box is an X220 with 8 GiB RAM, an SSD, and a i5-2410M CPU @ 2.30GHz. configure run not timed, "make clean" between tests, no other large jobs running. With the default --disable-maintainer-mode: $ time make -j3 check [...] real 3m40.110s user 3m0.320s sys 0m10.076s With --enable-maintainer-mode: $ time make -j3 check [...] real 8m47.108s user 4m31.216s sys 0m17.540s With --enable-maintainer-mode and parallel: $ time make -j3 check TESTFLAGS=--parallel [...] real 1m35.127s user 3m13.272s sys 0m9.728s Sure, that is pretty fast. But a quick wc shows 90 gpgscm processes and three dozen gpg-agents. I'd call that a resource hog - which might be acceptable for a developer but I doubt that build daemons like that. Shalom-Salam, Werner -- 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 dkg at fifthhorseman.net Mon Aug 7 23:12:54 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 07 Aug 2017 17:12:54 -0400 Subject: running all the tests In-Reply-To: <87lgmvmdp0.fsf@wheatstone.g10code.de> References: <87zibbtuzx.fsf@fifthhorseman.net> <87inhzjp48.fsf@europa.jade-hamburg.de> <87lgmvmdp0.fsf@wheatstone.g10code.de> Message-ID: <8760dzt73d.fsf@fifthhorseman.net> On Mon 2017-08-07 20:32:11 +0200, Werner Koch wrote: > Let's get some facts: My development box is an X220 with 8 GiB RAM, an > SSD, and a i5-2410M CPU @ 2.30GHz. mine is also an x220 with an ssd, but with 16GiB of RAM and only a marginally faster CPU (i5-2450M CPU @ 2.50GHz). > configure run not timed, "make clean" between tests, no other large > jobs running. did you run "make check" before you ran "time make -j3 check" ? if not, that would account for your higher level of CPU usage -- you'd be measuring building the code (both the actual production suite, as well as the test binaries), not just running the tests. I figure since this is a discussion about the cost of the test suite, we should focus on the test suite specifically -- we don't expect anything else to change as a result of this change. > Sure, that is pretty fast. But a quick wc shows 90 gpgscm processes and > three dozen gpg-agents. I'd call that a resource hog - which might be > acceptable for a developer but I doubt that build daemons like that. the build daemons have seen so much worse than you don't even want to know about it. Try looking at the thunderbird build, or at libreoffice if you're into this sort of thing ;) This is the work that build daemons are made to do. If it means better coverage for an important suite like GnuPG, i don't think anyone would begrudge their use. I'm pretty curious about the differences in our timings, though, and i'd like to understand why they're different. To rule out the effect of the disk, i've re-run my test in a tmpfs, with swap disabled, and in a newly empty directory. so that looks like, starting from scratch: git clone https://dev.gnupg.org/source/gnupg.git cd gnupg ./autogen.sh ./configure --sysconfdir=/etc --enable-maintainer-mode make make check time make check TESTFLAGS=--parallel time make check (i realized that the -jN argument for make is irrelevant here, that TESTFLAGS=--parallel will try to consume all your CPU if you let it regardless of how you set -j) During most of the parallel build, my CPU was pegged -- 0 for id,wa,st in vmstat, all the time spent in us,sy The timings i saw were: parallel: real 1m11.491s user 2m6.226s sys 0m8.157s On the other hand, the non-parallel build left my quad-core CPU between 75% and 94% idle. non-parallel: real 7m10.321s user 2m0.721s sys 0m16.063s Note that "time" claims both runs used about 135 seconds of CPU time. However, i suspect that gpg-agent is daemonizing itself, and therefore escaping the purview of the shell's "time" builtin. And a large chunk of the CPU consumed by the test is probably in gpg-agent itself, though i'm not sure. But the wall clock numbers don't lie, nor does the CPU idle statistics. If the concern is that the tests are too slow, it sounds like we should just encourage the use of TESTFLAGS=parallel, rather than disabling the tests. Alternately, we could figure out why the non-parallel test doesn't at least peg *one* of the CPU cores continuously. That'll probably improve user experience latency as well :) Werner, i'm surprised that the stats from your tests were so different from mine. can you try the approach i've outlined above and report back? I'm running debian testing/unstable. happy hacking, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From wk at gnupg.org Tue Aug 8 09:58:08 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 08 Aug 2017 09:58:08 +0200 Subject: running all the tests In-Reply-To: <8760dzt73d.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 07 Aug 2017 17:12:54 -0400") References: <87zibbtuzx.fsf@fifthhorseman.net> <87inhzjp48.fsf@europa.jade-hamburg.de> <87lgmvmdp0.fsf@wheatstone.g10code.de> <8760dzt73d.fsf@fifthhorseman.net> Message-ID: <877eyemqy7.fsf@wheatstone.g10code.de> On Mon, 7 Aug 2017 23:12, dkg at fifthhorseman.net said: > did you run "make check" before you ran "time make -j3 check" ? if not, I did a "make clean" between all tests, so that the "make check" had to build the software. I also use --enable-gpgtar --enable-g13 --enable-wks-tools with configure, but that does not make a substantial difference. gcc 6.4. Pure build times are (I did new test runs): $ make -j3 real 0m59.515s user 2m33.732s sys 0m6.852s > the build daemons have seen so much worse than you don't even want to > know about it. Try looking at the thunderbird build, or at libreoffice > if you're into this sort of thing ;) I recall discussion about problems on Amiga and other low-end platforms ;-). As you know, I really take care about portability. Running the new long make check on my Soekris box is not going to work. Also, my CA laptop is a T770 which already takes ages to run even the old "make check". I recall complaints from SuSE about too long running regression checks as well as from customers on non-Linux Unices. GNU software is known to have a uniform build system so that there is no need for an admin to read long and complicated build instructions. The usual triple jump plus a final make install is very well known and also documented in many internal company documents. Thus this should be the default. > This is the work that build daemons are made to do. If it means better > coverage for an important suite like GnuPG, i don't think anyone would > begrudge their use. The thing is that we run a Jenkins with a lot of configurations to run all tests on a lot of platforms - that catches the majority of standard configurations. Those which we do not catch are either hard to test (e.g. network), in non-standard environments, with interesting combinations of private and public keys, or which exhibit themselves only by manual tests and inspections. > I'm pretty curious about the differences in our timings, though, and i'd > like to understand why they're different. They are not that different after subtracting the build time. > make > make check > time make check TESTFLAGS=--parallel > time make check I did not do that first make check to condition the box, and I rand the non-parallel check first. > parallel: > real 1m11.491s > user 2m6.226s > sys 0m8.157s $ make -j3 check TESTFLAGS=--parallel real 1m16.963s user 1m58.316s sys 0m8.816s So that is basically the same. > non-parallel: > real 7m10.321s > user 2m0.721s > sys 0m16.063s $ make -j3 check real 7m47.714s user 1m55.772s sys 0m10.828s Ditto. FWIW, I also run the same thing without maintainer mode (also after having build the whole thing): $ make -j3 check TESTFLAGS=--parallel real 0m35.281s user 0m39.604s sys 0m3.024s $ make -j3 check real 2m46.663s user 0m40.568s sys 0m3.868s > But the wall clock numbers don't lie, nor does the CPU idle statistics. > If the concern is that the tests are too slow, it sounds like we should > just encourage the use of TESTFLAGS=parallel, rather than disabling the > tests. Alternately, we could figure out why the non-parallel test Still, I doubt that users will catch and report make check failures from testing a bunch of combinations of non-standard configurations. It is unlikely that the extra tests run at the user site we will catch bugs due to certain combinations later used at the user site. There will be bugs, and we help the users to find the. The obvious method then will be to run the build again with extensive test enabled. Given that --enable-maintainer-mode has its own problems and may fail when run by a user, I propose to add a separate configure option to run the extensive test suite. For the very long running tests in Libgcrypt we anyway use separate option --enable-large-data-tests. Using a make target instead of an configure option does not seem to be a good idea because there are already several check targets (e.g. check and installcheck). Such an option should then also default to parallel test builds. I would prefer if build systems, which are based on some kind of configure script, could agree on a name for enabling such tests. --enable-extensive-tests or --enable-all-tests might be good candidate names. Thus it is up the the user to decide whether to run those tests. Shalom-Salam, Werner -- 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 kristian.fiskerstrand at sumptuouscapital.com Tue Aug 8 10:12:51 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 8 Aug 2017 10:12:51 +0200 Subject: running all the tests In-Reply-To: <877eyemqy7.fsf@wheatstone.g10code.de> References: <87zibbtuzx.fsf@fifthhorseman.net> <87inhzjp48.fsf@europa.jade-hamburg.de> <87lgmvmdp0.fsf@wheatstone.g10code.de> <8760dzt73d.fsf@fifthhorseman.net> <877eyemqy7.fsf@wheatstone.g10code.de> Message-ID: <6b0a708d-a4d4-6a98-1389-04179c3b85b6@sumptuouscapital.com> On 08/08/2017 09:58 AM, Werner Koch wrote: > > Still, I doubt that users will catch and report make check failures from > testing a bunch of combinations of non-standard configurations. Gentoo's tinderboxes running various use flag combinations has a relatively good chance to find issues of this sort. > > I would prefer if build systems, which are based on some kind of > configure script, could agree on a name for enabling such tests. > --enable-extensive-tests or --enable-all-tests might be good candidate > names. Thus it is up the the user to decide whether to run those tests. > We can make that work. -- ---------------------------- 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 ---------------------------- Nil satis nisi optimum Nothing but the best is good enough -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From bernhard at intevation.de Tue Aug 8 15:10:11 2017 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 8 Aug 2017 15:10:11 +0200 Subject: wiki migration planning Message-ID: <201708081510.15354.bernhard@intevation.de> April 2013 we've started wiki.gnupg.org to support the Free Software Initatives [1] and communities behind GnuPG and Gpg4win. Up to now it has grown to 124 pages of various sizes and history. Overall I consider it a success. The wiki made some documentation and development processes faster, more approachable and more transparent. Wiki.gnupg.org is hosted by Intevation and runs https://moinmo.in . Now that GnuPG has started using Phabricator at dev.gnupg.org which also offers a wiki. The question is, shall we move? Or what kind of contents shall we move? See https://dev.gnupg.org/T3043 for the discussion, where we shall collect the various options, pros and cons. Best Regards, Bernhard == The target audience of wiki.gnupg.org was: "This wiki targets everyone that is interested in GnuPG, related Free Software initiatives and their products. (Just like stated on the front page.) It is a resource open for all skill and knowledge levels. Technical some say "users" and "developers". This is what we can call the community. " [1] I prefer to call neverending endevour "initiative" to tell it apart from "project". Werner prefers "GnuPG Project", though. :) http://blogs.fsfe.org/bernhard/2012/03/lets-end-all-free-software-projects-quickly/ -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 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: 473 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Tue Aug 8 15:50:38 2017 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 8 Aug 2017 15:50:38 +0200 Subject: running all the tests In-Reply-To: <877eyemqy7.fsf@wheatstone.g10code.de> References: <87zibbtuzx.fsf@fifthhorseman.net> <8760dzt73d.fsf@fifthhorseman.net> <877eyemqy7.fsf@wheatstone.g10code.de> Message-ID: <201708081550.42034.bernhard@intevation.de> Am Dienstag 08 August 2017 09:58:08 schrieb Werner Koch: > I propose to add a separate configure option to run > the extensive test suite. FWIW: I agree that users should be able to decide how many tests to run. Many tests are not useful to run each time. They will not find much and thus just waste time and energy in 99,999% of cases. In my experience if a default build setting offers too many tests, the chance is higher that people will disable them all. The end result would be less testing than more. > I would prefer if build systems, which are based on some kind of > configure script, could agree on a name for enabling such tests. > --enable-extensive-tests or --enable-all-tests might be good candidate > names. ?Thus it is up the the user to decide whether to run those tests. Yes, it is a good idea to standardise selections and naming of different levels of automated tests. A recommendation should be there, e.g. if Debian wants to do a in-depth test, it would be okay to run this on their build servers. So the docs could say: Packages, please run the intensive test suite at least for each release. Best Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 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: 473 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Tue Aug 8 18:03:59 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 08 Aug 2017 18:03:59 +0200 Subject: running all the tests In-Reply-To: <877eyemqy7.fsf@wheatstone.g10code.de> (Werner Koch's message of "Tue, 08 Aug 2017 09:58:08 +0200") References: <87zibbtuzx.fsf@fifthhorseman.net> <87inhzjp48.fsf@europa.jade-hamburg.de> <87lgmvmdp0.fsf@wheatstone.g10code.de> <8760dzt73d.fsf@fifthhorseman.net> <877eyemqy7.fsf@wheatstone.g10code.de> Message-ID: <874ltikpw0.fsf@wheatstone.g10code.de> On Tue, 8 Aug 2017 09:58, wk at gnupg.org said: > Given that --enable-maintainer-mode has its own problems and may fail > when run by a user, I propose to add a separate configure option to run > the extensive test suite. For the very long running tests in Libgcrypt To move on with this I just pushed a change with adds the option --enable-all-tests to gnupg's configure. Only if this option is used the full range of tests is done. Thus --enable-maintainer-mode is not used to decide on this. Further, --enable-all-tests is always used for "make distcheck". As before adding TESTFLAGS=--parallel to the "make check" or "make distcheck" will speed up things. I greped codesearch.debian.org for that new option and only Haskell things use this string but outside of configure. Thus in theory Debian could add --enable-all-tests to all configure invocations and we start to advertise this is a standard option for running, well, all available tests. Salam-Shalom, Werner -- 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 dkg at fifthhorseman.net Tue Aug 8 19:30:41 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 08 Aug 2017 13:30:41 -0400 Subject: explanation for phabricator labels "Bug Report" and "Feature Request"? Message-ID: <87mv7armpq.fsf@fifthhorseman.net> hey folks-- i've submitted a few tasks to phabricator recently (e.g. T3345, T3323), where i mis-applied the labels "bug report" and "feature request". i thought i was submitting sensible labels, but clearly i don't understand the semantics of the labels as they're intended to be used on phabricator. Is there documentation for how we should use those labels so i can get it right in the future? --dkg From wk at gnupg.org Tue Aug 8 21:20:38 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 08 Aug 2017 21:20:38 +0200 Subject: explanation for phabricator labels "Bug Report" and "Feature Request"? In-Reply-To: <87mv7armpq.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 08 Aug 2017 13:30:41 -0400") References: <87mv7armpq.fsf@fifthhorseman.net> Message-ID: <87tw1hkgs9.fsf@wheatstone.g10code.de> On Tue, 8 Aug 2017 19:30, dkg at fifthhorseman.net said: > i've submitted a few tasks to phabricator recently (e.g. T3345, T3323), > where i mis-applied the labels "bug report" and "feature request". i > thought i was submitting sensible labels, but clearly i don't understand > the semantics of the labels as they're intended to be used on They are also new to us and we need to find a way to work with them. T3345 is about too noisy diagnostics so a certain command. I don't consider this a bug because it does what it shall do but displays a bit too many information in the presence of --quiet. For that reason I changed that to a Feature request (ie. "please make import-export" more quiet). It is not a bug because there are no hard rules on what --quiet does. There is also the priority "Whishlist" which is similar to a Feature tag but different in that it is on a list of items we need to decide whether to implement. For example T3323. I am nort sure whether we want this in the GPGME API because it may lead to API bloat and GPGME's intention is not to wrap all esoteric gpg features. > Is there documentation for how we should use those labels so i can get > it right in the future? Unfortunately not. I usualay ask Marcus on Jabber what to do ;-). Some hints: tags ("projects" in Phrabicator parlance) like "gnupg", "gpgme", "libgcrypt" specify the relevant component. "macOS" would tag this as a macOS specific bug. "Need Info" is a flag to mark a report as waiting for info form someone else (in most cases the original poster). "gnupg (gpg22)" puts that gnupg related bug on the workboard. The "gpg22" here indicates a milestone. @marcus: Do you have other hints? Can we add a wiki page to describe their use, like we did with the help page on roundup? Shalom-Salam, Werner -- 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 dkg at fifthhorseman.net Wed Aug 9 01:03:30 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 08 Aug 2017 19:03:30 -0400 Subject: explanation for phabricator labels "Bug Report" and "Feature Request"? In-Reply-To: <87tw1hkgs9.fsf@wheatstone.g10code.de> References: <87mv7armpq.fsf@fifthhorseman.net> <87tw1hkgs9.fsf@wheatstone.g10code.de> Message-ID: <871solslvh.fsf@fifthhorseman.net> On Tue 2017-08-08 21:20:38 +0200, Werner Koch wrote: > It is not a bug because there are no hard rules on what --quiet does. I'd considered it a bug because gpg(1) says that --quiet means "Try to be as quiet as possible", and it clearly wasn't even trying :) > There is also the priority "Whishlist" which is similar to a Feature > tag but different in that it is on a list of items we need to decide > whether to implement. For example T3323. I am nort sure whether we > want this in the GPGME API because it may lead to API bloat and > GPGME's intention is not to wrap all esoteric gpg features. OK, i get that wishlist priority means "we might not even get to it, ever" -- does that make something not a feature request, though? We have a user of GnuPG (Robert J. Hansen), who clearly needed the feature and was avoiding using GPGME because it didn't have it. I consider that a feature request (whether we decide to do it or not is a separate question). > Some hints: tags ("projects" in Phrabicator parlance) like "gnupg", > "gpgme", "libgcrypt" specify the relevant component. "macOS" would tag > this as a macOS specific bug. "Need Info" is a flag to mark a report as > waiting for info form someone else (in most cases the original poster). > > "gnupg (gpg22)" puts that gnupg related bug on the workboard. The > "gpg22" here indicates a milestone. cool, thanks for these hints, and the above explanation. this is super useful to me. > @marcus: Do you have other hints? Can we add a wiki page to describe > their use, like we did with the help page on roundup? That would be great! Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From wk at gnupg.org Wed Aug 9 11:43:53 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 09 Aug 2017 11:43:53 +0200 Subject: explanation for phabricator labels "Bug Report" and "Feature Request"? In-Reply-To: <871solslvh.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 08 Aug 2017 19:03:30 -0400") References: <87mv7armpq.fsf@fifthhorseman.net> <87tw1hkgs9.fsf@wheatstone.g10code.de> <871solslvh.fsf@fifthhorseman.net> Message-ID: <87tw1hhy92.fsf@wheatstone.g10code.de> On Wed, 9 Aug 2017 01:03, dkg at fifthhorseman.net said: > I'd considered it a bug because gpg(1) says that --quiet means "Try to > be as quiet as possible", and it clearly wasn't even trying :) I expected that you would say this ;-) > OK, i get that wishlist priority means "we might not even get to it, > ever" -- does that make something not a feature request, though? We > have a user of GnuPG (Robert J. Hansen), who clearly needed the feature I used Wishlist here in the sense of "we should consider this". Feature request is to me an item which clearly is useful. Shalom-Salam, Werner -- 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 Aug 9 17:12:58 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 09 Aug 2017 17:12:58 +0200 Subject: [Announce] GnuPG 2.1.23 released Message-ID: <877eycixl1.fsf@wheatstone.g10code.de> Hello! The GnuPG team is pleased to announce the availability of a new release of GnuPG: version 2.1.23. See below for a list of new features and bug fixes. This a release candidate for 2.2.0. 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.1.23 ==================================== * gpg: "gpg" is now installed as "gpg" and not anymore as "gpg2". If needed, the new configure option --enable-gpg-is-gpg2 can be used to revert this. * gpg: Options --auto-key-retrieve and --auto-key-locate "local,wkd" are now used by default. Note: this enables keyserver and Web Key Directory operators to notice when a signature from a locally non-available key is being verified for the first time or when you intend to encrypt to a mail address without having the key locally. This new behaviour will eventually make key discovery much easier and mostly automatic. Disable this by adding no-auto-key-retrieve auto-key-locate local to your gpg.conf. * agent: Option --no-grab is now the default. The new option --grab allows to revert this. * gpg: New import option "show-only". * gpg: New option --disable-dirmngr to entirely disable network access for gpg. * gpg,gpgsm: Tweaked DE-VS compliance behaviour. * New configure flag --enable-all-tests to run more extensive tests during "make check". * gpgsm: The keygrip is now always printed in colon mode as documented in the man page. * Fixed connection timeout problem under Windows. A detailed description of the changes found in this 2.1 branch can be found at . Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.1.23 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.1.23.tar.bz2 (6374k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.23.tar.bz2.sig or via FTP: ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.23.tar.bz2 ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.23.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.1.23_20170809.exe (3794k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.23_20170809.exe.sig or via FTP: ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.23_20170809.exe ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.23_20170809.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. The Windows installer comes with TOFU support, many translations, support for Tor, and support for HKPS and the Web Key Directory. 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.1.23.tar.bz2 you would use this command: gpg --verify gnupg-2.1.23.tar.bz2.sig gnupg-2.1.23.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.1.23.tar.bz2, you run the command like this: sha1sum gnupg-2.1.23.tar.bz2 and check that the output matches the next line: c470777eaa9657ef3258068507065c9a7caef9eb gnupg-2.1.23.tar.bz2 c95f1c2dc3aa06dda2a58ba5aefb362511f666e3 gnupg-w32-2.1.23_20170809.exe 90a692391f1e314cffa1d54fa9c28855c24ecda6 gnupg-w32-2.1.23_20170809.tar.xz Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese, Czech, French, German, Japanese, Norwegian, Russian, and Ukrainian being almost completely translated. We are now in string freeze for 2.2 and updated translations are very welcome. Documentation ============= 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 user manual of the system. Separate man pages are included as well but they have not all the details available as are the manual. It is also possible to read the complete manual online in HTML format at https://gnupg.org/documentation/manuals/gnupg/ or in Portable Document Format 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 search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. You may also want to follow our postings at and . Support ======== 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. Maintenance and development of GnuPG is mostly financed by donations. The GnuPG project employs 4 full-time developers, one part-timer, and one contractor. They all work exclusivly on GnuPG and closely related software like Libgcrypt, GPGME, and GPA. Please consider to donate via: https://gnupg.org/donate/ Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, answering questions on the mailing lists, and donating money. Happy hacking, Your GnuPG Team 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 five keys: 2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 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/33BD3F06 2014-10-29 [expires: 2016-10-28] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31] Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 Werner Koch (Release Signing Key) rsa3072/4B092E28 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) You may retrieve these keys from a keyserver using this command gpg --keyserver hkp://keys.gnupg.net --recv-keys \ 249B39D24F25E3B6 04376F3EE0856959 \ 2071B08A33BD3F06 8A861B1C7EFD60D9 BCEF7E294B092E28 The keys are also available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 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 dkg at fifthhorseman.net Fri Aug 11 17:34:48 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 11 Aug 2017 11:34:48 -0400 Subject: running all the tests In-Reply-To: <874ltikpw0.fsf@wheatstone.g10code.de> References: <87zibbtuzx.fsf@fifthhorseman.net> <87inhzjp48.fsf@europa.jade-hamburg.de> <87lgmvmdp0.fsf@wheatstone.g10code.de> <8760dzt73d.fsf@fifthhorseman.net> <877eyemqy7.fsf@wheatstone.g10code.de> <874ltikpw0.fsf@wheatstone.g10code.de> Message-ID: <87a836p17r.fsf@fifthhorseman.net> On Tue 2017-08-08 18:03:59 +0200, Werner Koch wrote: > To move on with this I just pushed a change with adds the option > --enable-all-tests to gnupg's configure. Only if this option is used > the full range of tests is done. Thus --enable-maintainer-mode is not > used to decide on this. Thanks for making this change. I'm using --enable-all-tests and TESTFLAGS=--parallel on debian builds as of 2.1.23-1 (which i'll upload to debian unstable shortly). --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From dkg at fifthhorseman.net Sat Aug 12 01:53:50 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 11 Aug 2017 19:53:50 -0400 Subject: GnuPG defaults: changing back to --no-auto-key-retrieve Message-ID: <87shgxmzjl.fsf@fifthhorseman.net> hey folks-- Werner and i spoke yesterday about the choice of defaults for auto-key-retrieve and auto-key-locate, which were updated in 2.1.23. Summary ------- GnuPG will revert the default of -retrieve for now so that the default is --no-auto-key-retrieve. The default for --auto-key-locate will remain as local,wkd. I pushed this change to upstream in commit https://dev.gnupg.org/rGe6f84116abca2ed49bf14b2e28c3c811a3717227, and it will be in the next released version. I also just pushed 2.1.23-1 to debian unstable, with a patch that includes this change. What follows is my own notes from the discussion, i hope Werner will chime in if his recollection is different. --auto-key-retrieve vs. --auto-key-locate ----------------------------------------- i hadn't fully understood this bit, hopefully it helps others: --auto-key-retrieve (henceforth "AKR" here) governs whether or not to retrieve unknown keys during signature verification. It does lookups by long key ID or by full fingerprint only. It is a boolean flag (the "false" value is --no-auto-key-retrieve). --auto-key-locate ("AKL") governs the list of mechanisms used to find keys when the user wants to find them based on an e-mail address. It is a list of "locate" mechanisms, including among other things "local", "wkd", "keyserver", "ldap", etc. This happens only when encrypting messages. So, AKR is for signature verification, and AKL is for encryption. Trouble with --auto-key-retrieve -------------------------------- During signature verification in an e-mail context, AKR is likely to present a mechanism for "web bug" or "return reciept" functionality, something most MUA developers are (justifiably) wary of. This could potentially happen even without the user's knowledge (e.g. if a MUA tried to check signatures on mail as it was retrieved from the mailserver, before the user sees it) During signature verification in non-email contexts, AKR presents even more troubling implications. Consider a software distribution mechanism that uses a curated keyring to indicate which keys' signatures are acceptable. If a malicious party managed to place their own signature on the update server, and the system used AKR, it might pollute the curated keyring with the malicious party's key, leading to further compromise in the future. Because of these risks, we're moving the default back to --no-auto-key-retrieve. MUAs that want to provide the user with a smooth experience, where they understand the consequences can of course use --auto-key-retrieve explicitly for their own invocations, in situations where the user expects network activity. Frontends like enigmail and notmuch already offer the user such an option when a signature from an unknown key is found. But --auto-key-retrieve was not a safe option for a toolkit like gpg to have by default, so it has been reverted. Note also that polite MUAs that want their messages to be easily-verified can also just ensure that their user's OpenPGP certificate is included with every signed message. This introduces no additional network side-channels, and has latency benefits as well compared to the post-hoc network lookup. Why --auto-key-locate is different ---------------------------------- We left AKL alone, with the new default of local,wkd. This situation is different, because it is the user explicitly invoking GnuPG, asking for encryption to an e-mail address. If the user's local keyring doesn't have the key, it's sensible to try to fetch a key for the user if there's a way that we think is better-than-cleartext. wkd is the only non-local option automatically enabled. Note that if the user does not try to encrypt a message, then this lookup won't happen, because gnupg should not be invoked anyway. So the network activity is only happening as a consequence of user activity, and only when no local key is already present. Sensible MUAs should probably indicate to the user whether a local key is present for each user anyway while the message is composed, before it is encrypted and sent. So when the user has elected to send an encrypted message, they should already have some indication of whether a key lookup will be necessary or not. And of course, users who prefer to have their encryption fail when there is no local key rather than making an extra network lookup can always set --no-auto-key-locate. Hopefully these explanations are useful. If you see concerns with the reasoning or explanations, or (even better) if you havesuggestions for further improvements, please don't hesitate. happy hacking, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From patrick at enigmail.net Sat Aug 12 12:17:48 2017 From: patrick at enigmail.net (Patrick Brunschwig) Date: Sat, 12 Aug 2017 12:17:48 +0200 Subject: GnuPG defaults: changing back to --no-auto-key-retrieve In-Reply-To: <87shgxmzjl.fsf@fifthhorseman.net> References: <87shgxmzjl.fsf@fifthhorseman.net> Message-ID: On 12.08.17 01:53, Daniel Kahn Gillmor wrote: > hey folks-- > > Werner and i spoke yesterday about the choice of defaults for > auto-key-retrieve and auto-key-locate, which were updated in 2.1.23. > > Summary > ------- > > GnuPG will revert the default of -retrieve for now so that the default > is --no-auto-key-retrieve. The default for --auto-key-locate will > remain as local,wkd. > > I pushed this change to upstream in commit > https://dev.gnupg.org/rGe6f84116abca2ed49bf14b2e28c3c811a3717227, and it > will be in the next released version. I also just pushed 2.1.23-1 to > debian unstable, with a patch that includes this change. > > What follows is my own notes from the discussion, i hope Werner will > chime in if his recollection is different. Thanks Daniel! I fully agree with your remarks. I'd like to add that immediately after I read the release announcement - because I had the same concerns that you you raised here - I implemented functionality in Enigmail to add --no-auto-key-retrieve to all commands if gpg 2.1.23 or newer is detected (and the user did not explicitly opt in to auto-key-retrieve). -Patrick From dkg at fifthhorseman.net Fri Aug 18 02:50:58 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 17 Aug 2017 20:50:58 -0400 Subject: [PATCH GPGME] python: Support parallel build in tests In-Reply-To: <20170803184135.8464-1-alon.barlev@gmail.com> References: <20170803184135.8464-1-alon.barlev@gmail.com> Message-ID: <87h8x5itql.fsf@fifthhorseman.net> On Thu 2017-08-03 21:41:35 +0300, Alon Bar-Lev wrote: > * lang/python/tests/Makefile.am: Depend xcheck with all which was lost > due to the check hack. I've added this to the bug tracker as: https://dev.gnupg.org/T3352 --dkg From deloptes at gmail.com Sun Aug 20 02:33:49 2017 From: deloptes at gmail.com (deloptes) Date: Sun, 20 Aug 2017 02:33:49 +0200 Subject: pinentry Message-ID: Hi, I have a request to the pinentry developers. Where is the right place to ask? thanks in advance regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From dgouttegattat at incenp.org Sun Aug 20 17:19:51 2017 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sun, 20 Aug 2017 17:19:51 +0200 Subject: pinentry In-Reply-To: References: Message-ID: <26f6889f-dd4f-0547-bdbd-7dc68a02987b@incenp.org> On 08/20/2017 02:33 AM, deloptes wrote: > I have a request to the pinentry developers. Where is the right place to > ask? Well, you found it. :) This list is for development-related discussions about GnuPG and most of its components, including Pinentries (except Libgcrypt, which has its own dedicated mailing-list gcrypt-devel). Alternatively, if you already have a precise feature request in mind, you may open a new ticket (tagged with the "Pinentry" label) in the GnuPG bug tracker [1]. But it is usually best to discuss it here beforehand. Damien [1] https://bugs.gnupg.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From justus at g10code.com Mon Aug 21 11:16:14 2017 From: justus at g10code.com (Justus Winter) Date: Mon, 21 Aug 2017 11:16:14 +0200 Subject: [PATCH GPGME] python: Support parallel build in tests In-Reply-To: <20170803184135.8464-1-alon.barlev@gmail.com> References: <20170803184135.8464-1-alon.barlev@gmail.com> Message-ID: <87k21xl1r5.fsf@europa.jade-hamburg.de> Alon Bar-Lev writes: > * lang/python/tests/Makefile.am: Depend xcheck with all which was lost > due to the check hack. Merged, many thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From justus at g10code.com Mon Aug 21 13:12:56 2017 From: justus at g10code.com (Justus Winter) Date: Mon, 21 Aug 2017 13:12:56 +0200 Subject: running all the tests In-Reply-To: <874ltikpw0.fsf@wheatstone.g10code.de> References: <87zibbtuzx.fsf@fifthhorseman.net> <87inhzjp48.fsf@europa.jade-hamburg.de> <87lgmvmdp0.fsf@wheatstone.g10code.de> <8760dzt73d.fsf@fifthhorseman.net> <877eyemqy7.fsf@wheatstone.g10code.de> <874ltikpw0.fsf@wheatstone.g10code.de> Message-ID: <878tiddvif.fsf@europa.jade-hamburg.de> Werner Koch writes: > On Tue, 8 Aug 2017 09:58, wk at gnupg.org said: > >> Given that --enable-maintainer-mode has its own problems and may fail >> when run by a user, I propose to add a separate configure option to run >> the extensive test suite. For the very long running tests in Libgcrypt > > To move on with this I just pushed a change with adds the option > --enable-all-tests to gnupg's configure. Only if this option is used > the full range of tests is done. Thus --enable-maintainer-mode is not > used to decide on this. I'm still bewildered by this discussion and the resulting changes. For the record, running all GPGME tests with C++ and 2x Python takes about 1min25s: .../gpgme/obj $ time make check [...] make check 4.68s user 1.06s system 6% cpu 1:25.24 total Whereas running all GnuPG tests with --enable-all-tests and (!!!) including all the GPGME tests takes just 8 (eight) seconds longer on my very humble machine: .../gnupg/obj $ time make check-all [...] =================== 266 tests run, 266 succeeded, 0 failed, 0 failed expectedly, 0 succeeded unexpectedly, 0 skipped. =================== make check-all 164.97s user 5.12s system 182% cpu 1:33.35 total One interpretation is that the GnuPG test framework is so efficient at running the GPGME tests, that you get all the other 206 tests essentially for free (or for 8 seconds). I don't know where to go from here. Either 90 seconds is an acceptable run time for the test suite, or it is not. In the former case, all the recent test suite changes aimed at reducing the runtime seem moot. In the latter, we need to disable some GPGME tests. Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From dgouttegattat at incenp.org Mon Aug 21 15:05:14 2017 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Mon, 21 Aug 2017 15:05:14 +0200 Subject: [PATCH v2 0/4] Add tests for the PGP trust model In-Reply-To: <20170719201730.4339-1-dgouttegattat@incenp.org> References: <87a840aebq.fsf@europa.jade-hamburg.de> <20170719201730.4339-1-dgouttegattat@incenp.org> Message-ID: Hi GnuPG developers, On 07/19/2017 10:17 PM, Damien Goutte-Gattat wrote: > On 07/19/2017 12:52 PM, Justus Winter wrote: >> Why not move the common definitions to a separate file, and >> split this test into four. > > OK, I have done just that. Thanks for the suggestion, I believe > it is indeed much cleaner this way. > > For convenience, here is the whole patchset again. Ping! Any news about the fate of this patchset? Does it need more work before it can be merged? It still applies cleanly on top of the current master. I can re-send it if it's easier than going back to the mailing-list archives. Or do you prefer I submit it through the Phabricator interface? Best, Damien > Damien Goutte-Gattat (4): > gpgconf: Make WoT settings configurable by gpgconf. > gpg,tests: Move some functions into a common module. > gpg,tests: Add tests for the PGP trust model. > gpg: Fix regexp sanitization. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From justus at g10code.com Mon Aug 21 17:06:45 2017 From: justus at g10code.com (Justus Winter) Date: Mon, 21 Aug 2017 17:06:45 +0200 Subject: [PATCH v2 0/4] Add tests for the PGP trust model In-Reply-To: References: <87a840aebq.fsf@europa.jade-hamburg.de> <20170719201730.4339-1-dgouttegattat@incenp.org> Message-ID: <87378ldkoq.fsf@europa.jade-hamburg.de> Damien Goutte-Gattat writes: > Hi GnuPG developers, > > On 07/19/2017 10:17 PM, Damien Goutte-Gattat wrote: >> On 07/19/2017 12:52 PM, Justus Winter wrote: >>> Why not move the common definitions to a separate file, and >>> split this test into four. >> >> OK, I have done just that. Thanks for the suggestion, I believe >> it is indeed much cleaner this way. >> >> For convenience, here is the whole patchset again. > > Ping! Any news about the fate of this patchset? Does it need more work > before it can be merged? No, it is fine. I'm going to merge it right now, modulo the last patch. Thanks, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From muelli at cryptobitch.de Tue Aug 22 17:48:25 2017 From: muelli at cryptobitch.de (Tobias Mueller) Date: Tue, 22 Aug 2017 17:48:25 +0200 Subject: [PATCH] python: Default whence argument for Data() to SEEK_SET. Message-ID: <1503416905.23294.52.camel@cryptobitch.de> * lang/python/gpgme.i: copied signature from gpgme.h and defaulted the value to SEEK_SET. * lang/python/tests/t-data.py: Added a test for no second argument -- Having to import the os package when wanting to read a Data object is a slight annoyance. With SWIG, we can define default parameters. This change defaults the whence argument to SEEK_SET which is how StringIO and BytesIO behave. Signed-off-by: Tobias Mueller --- lang/python/gpgme.i | 5 +++++ lang/python/tests/t-data.py | 6 ++++++ 2 files changed, 11 insertions(+) diff --git a/lang/python/gpgme.i b/lang/python/gpgme.i index 58148b3..3fa2e0b 100644 --- a/lang/python/gpgme.i +++ b/lang/python/gpgme.i @@ -557,6 +557,11 @@ gpgme_error_t gpgme_op_keylist_start (gpgme_ctx_t ctx, const char *pattern="", int secret_only=0); +/* The whence argument is surprising in Python-land, + because BytesIO or StringIO objects do not require it. + It defaults to SEEK_SET. Let's do that for Data objects, too */ +off_t gpgme_data_seek (gpgme_data_t dh, off_t offset, int whence=SEEK_SET); + /* Include the unmodified for cc, and the cleaned-up local version for SWIG. We do, however, want to hide certain fields on some structs, which we provide prior to including the version for diff --git a/lang/python/tests/t-data.py b/lang/python/tests/t-data.py index 3301319..5cf074c 100755 --- a/lang/python/tests/t-data.py +++ b/lang/python/tests/t-data.py @@ -51,6 +51,12 @@ data.write(b'Hello world!') data.seek(0, os.SEEK_SET) assert data.read() == b'Hello world!' +data = gpg.Data() +data.write(b'Hello world!') +# We expect the second argument to default to SEEK_SET +data.seek(0) +assert data.read() == b'Hello world!' + binjunk = bytes(range(256)) data = gpg.Data() data.write(binjunk) -- 2.7.4 From muelli at cryptobitch.de Tue Aug 22 17:57:12 2017 From: muelli at cryptobitch.de (Tobias Mueller) Date: Tue, 22 Aug 2017 17:57:12 +0200 Subject: [PATCH] python: Add more python import and export functions. Message-ID: <1503417432.23294.53.camel@cryptobitch.de> * lang/python/gpg/core.py (Context): Added import_ and export * lang/python/tests/t-export.py: New test for export function * lang/python/tests/t-import.py: New test for import function * lang/python/tests/t-op-export.py: Renamed from t-export.py * lang/python/tests/t-op-import.py: Renamed from t-import.py -- gpgme's op_import and op_export functions return an error code rather than a result. In Python, exceptions are thrown if any of those functions returned an error code. This change gives a more natural import and export function which return the result object or throw on error. Signed-off-by: Tobias Mueller --- lang/python/src/core.py | 44 ++++++++++++++++++++++ lang/python/tests/t-export.py | 36 ++++++++++++------ lang/python/tests/t-import.py | 8 ++-- lang/python/tests/t-op-export.py | 40 ++++++++++++++++++++ lang/python/tests/t-op-import.py | 79 ++++++++++++++++++++++++++++++++++++++++ 5 files changed, 190 insertions(+), 17 deletions(-) mode change 100755 => 100644 lang/python/tests/t-export.py create mode 100755 lang/python/tests/t-op-export.py create mode 100644 lang/python/tests/t-op-import.py diff --git a/lang/python/src/core.py b/lang/python/src/core.py index bd95d23..453f12e 100644 --- a/lang/python/src/core.py +++ b/lang/python/src/core.py @@ -509,6 +509,50 @@ class Context(GpgmeWrapper): return results + def import_(self, bytes): + """Import data + + Imports given bytes into the Context. + + Returns: + result -- information about the imported data + + Raises: + GPGMEError -- as signaled by the underlying library + + """ + self.op_import(bytes) + import_result = self.op_import_result() + return import_result + + # Hrm. A constants.EXPORT_MODE_NORMAL does not seem to exist + def export(self, pattern, mode=0, sink=None): + """Export data + + Exports key for the given pattern under the given mode. + + Keyword arguments: + mode -- export mode. See constants.EXPORT_MODE. + (default: 0 which should be "normal") + sink -- write result to sink instead of returning it + + Returns: + exported_data -- the bytes of your key(s) of your desire + + Raises: + GPGMEError -- as signaled by the underlying library + + """ + data = sink if sink else Data() + self.op_export(pattern, mode, data) + if data and not sink: + data.seek(0, os.SEEK_SET) + exported_bytes = data.read() + else: + exported_bytes = None + return exported_bytes + + def keylist(self, pattern=None, secret=False, mode=constants.keylist.mode.LOCAL, source=None): diff --git a/lang/python/tests/t-export.py b/lang/python/tests/t-export.py old mode 100755 new mode 100644 index b9d5204..5aa2e32 --- a/lang/python/tests/t-export.py +++ b/lang/python/tests/t-export.py @@ -1,6 +1,6 @@ #!/usr/bin/env python -# Copyright (C) 2016 g10 Code GmbH +# Copyright (C) 2016 Tobias Mueller # # This file is part of GPGME. # @@ -20,20 +20,32 @@ from __future__ import absolute_import, print_function, unicode_literals del absolute_import, print_function, unicode_literals +import os + import gpg -import support c = gpg.Context() -c.set_armor(True) +# We just want to get any existing key +fpr = next(c.keylist()).fpr -sink = gpg.Data() -c.op_export_ext(['Alpha', 'Bob'], 0, sink) -support.print_data(sink) +# We test the export() function for a pattern +bytes = c.export(fpr) +assert bytes -# Again. Now using a key array. -keys = [] -keys.append(c.get_key("0x68697734", False)) # Alpha -keys.append(c.get_key("0xA9E3B0B2", False)) # Bob +# The export function also takes a mode argument +minimal = c.export(fpr, mode=gpg.constants.EXPORT_MODE_MINIMAL) +assert len(minimal) < len(bytes) + +# We can also provide a sink of our liking sink = gpg.Data() -c.op_export_keys(keys, 0, sink) -support.print_data(sink) +c.export(fpr, sink=sink) +sink.seek(0, os.SEEK_SET) +data = sink.read() +assert data + +try: + nonexisting_mode = 9999 + c.export(fpr, mode=nonexisting_mode) + assert False, "Export should raise!" +except gpg.errors.GPGMEError as e: + pass diff --git a/lang/python/tests/t-import.py b/lang/python/tests/t-import.py index e2edf5a..1520e94 100755 --- a/lang/python/tests/t-import.py +++ b/lang/python/tests/t-import.py @@ -1,6 +1,6 @@ #!/usr/bin/env python -# Copyright (C) 2016 g10 Code GmbH +# Copyright (C) 2016 Tobias Mueller # # This file is part of GPGME. # @@ -69,10 +69,8 @@ def check_result(result, fpr, secret): c = gpg.Context() -c.op_import(gpg.Data(file=support.make_filename("pubkey-1.asc"))) -result = c.op_import_result() +result = c.import_(open(support.make_filename("pubkey-1.asc"), 'rb').read()) check_result(result, "ADAB7FCC1F4DE2616ECFA402AF82244F9CD9FD55", False) -c.op_import(gpg.Data(file=support.make_filename("seckey-1.asc"))) -result = c.op_import_result() +result = c.import_(open(support.make_filename("seckey-1.asc"), 'rb').read()) check_result(result, "ADAB7FCC1F4DE2616ECFA402AF82244F9CD9FD55", True) diff --git a/lang/python/tests/t-op-export.py b/lang/python/tests/t-op-export.py new file mode 100755 index 0000000..4927beb --- /dev/null +++ b/lang/python/tests/t-op-export.py @@ -0,0 +1,40 @@ +#!/usr/bin/env python + +# Copyright (C) 2016 g10 Code GmbH +# +# This file is part of GPGME. +# +# GPGME is free software; you can redistribute it and/or modify it +# under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# GPGME is distributed in the hope that it will be useful, but WITHOUT +# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY +# or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General +# Public License for more details. +# +# You should have received a copy of the GNU Lesser General Public +# License along with this program; if not, see . + +from __future__ import absolute_import, print_function, unicode_literals +del absolute_import, print_function, unicode_literals + +import gpg +import support + +support.init_gpgme(gpg.constants.protocol.OpenPGP) +c = gpg.Context() +c.set_armor(True) + +sink = gpg.Data() +c.op_export_ext(['Alpha', 'Bob'], 0, sink) +support.print_data(sink) + +# Again. Now using a key array. +keys = [] +keys.append(c.get_key("0x68697734", False)) # Alpha +keys.append(c.get_key("0xA9E3B0B2", False)) # Bob +sink = gpg.Data() +c.op_export_keys(keys, 0, sink) +support.print_data(sink) diff --git a/lang/python/tests/t-op-import.py b/lang/python/tests/t-op-import.py new file mode 100644 index 0000000..5b0576f --- /dev/null +++ b/lang/python/tests/t-op-import.py @@ -0,0 +1,79 @@ +#!/usr/bin/env python + +# Copyright (C) 2016 g10 Code GmbH +# +# This file is part of GPGME. +# +# GPGME is free software; you can redistribute it and/or modify it +# under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# GPGME is distributed in the hope that it will be useful, but WITHOUT +# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY +# or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General +# Public License for more details. +# +# You should have received a copy of the GNU Lesser General Public +# License along with this program; if not, see . + +from __future__ import absolute_import, print_function, unicode_literals +del absolute_import, print_function, unicode_literals + +import gpg +import support + +def check_result(result, fpr, secret): + assert result.considered == 1 or (secret and result.considered == 3) + assert result.no_user_id == 0 + assert not ((secret and result.imported != 0) + or (not secret and (result.imported != 0 + and result.imported != 1))) + assert result.imported_rsa == 0 + assert not ((secret and (result.unchanged != 0 and result.unchanged != 1)) + or (not secret and ((result.imported == 0 + and result.unchanged != 1) + or (result.imported == 1 + and result.unchanged != 0)))) + assert result.new_user_ids == 0 + assert result.new_sub_keys == 0 + assert not ((secret + and ((result.secret_imported == 0 + and result.new_signatures != 0) + or (result.secret_imported == 1 + and result.new_signatures > 1))) + or (not secret and result.new_signatures != 0)) + assert result.new_revocations == 0 + assert not ((secret and result.secret_read != 1 and result.secret_read != 3) + or (not secret and result.secret_read != 0)) + assert not ((secret and result.secret_imported != 0 + and result.secret_imported != 1 + and result.secret_imported != 2) + or (not secret and result.secret_imported != 0)) + assert not ((secret + and ((result.secret_imported == 0 + and result.secret_unchanged != 1 + and result.secret_unchanged != 2) + or (result.secret_imported == 1 + and result.secret_unchanged != 0))) + or (not secret and result.secret_unchanged != 0)) + assert result.not_imported == 0 + if secret: + assert not (len(result.imports) in (0, 3)) + else: + assert not (len(result.imports) in (0, 2)) + + assert fpr == result.imports[0].fpr + assert len(result.imports) == 1 or fpr == result.imports[1].fpr + assert result.imports[0].result == 0 + +support.init_gpgme(gpg.constants.protocol.OpenPGP) +c = gpg.Context() + +c.op_import(gpg.Data(file=support.make_filename("pubkey-1.asc"))) +result = c.op_import_result() +check_result(result, "ADAB7FCC1F4DE2616ECFA402AF82244F9CD9FD55", False) + +c.op_import(gpg.Data(file=support.make_filename("seckey-1.asc"))) +result = c.op_import_result() +check_result(result, "ADAB7FCC1F4DE2616ECFA402AF82244F9CD9FD55", True) -- 2.7.4 From wk at gnupg.org Wed Aug 23 16:16:48 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 23 Aug 2017 16:16:48 +0200 Subject: [PATCH v2 0/4] Add tests for the PGP trust model In-Reply-To: <87378ldkoq.fsf@europa.jade-hamburg.de> (Justus Winter's message of "Mon, 21 Aug 2017 17:06:45 +0200") References: <87a840aebq.fsf@europa.jade-hamburg.de> <20170719201730.4339-1-dgouttegattat@incenp.org> <87378ldkoq.fsf@europa.jade-hamburg.de> Message-ID: <87o9r6s71r.fsf@wheatstone.g10code.de> On Mon, 21 Aug 2017 17:06, justus at g10code.com said: > No, it is fine. I'm going to merge it right now, modulo the last patch. Hmmm, somehow that merge was bogus: + trust-pgp-2.scm \ + trust-pgp-3.scm \ + trust-pgp-4.scm! \ gpgtar.scm \ There is an extra '!'. I fixed that to make "make distcheck" work but the test failed. Maybe due to "gpg: Fix regexp sanitization" not being applied. I disabled the test for now because we are in freeze for 2.2. Salam-Shalom, Werner -- 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 Aug 23 16:28:51 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 23 Aug 2017 16:28:51 +0200 Subject: GnuPG defaults: changing back to --no-auto-key-retrieve In-Reply-To: <87shgxmzjl.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 11 Aug 2017 19:53:50 -0400") References: <87shgxmzjl.fsf@fifthhorseman.net> Message-ID: <87k21us6ho.fsf@wheatstone.g10code.de> On Sat, 12 Aug 2017 01:53, dkg at fifthhorseman.net said: > --auto-key-retrieve (henceforth "AKR" here) governs whether or not to > retrieve unknown keys during signature verification. It does > lookups by long key ID or by full fingerprint only. It is a If "wkd" is part of the --auto-key-locate (AKL) list and a signer's UID is part of the signature the Web key directory is also tried. > So, AKR is for signature verification, and AKL is for encryption. In general this is true, but the AKL is also used to decide on how to do the AKR. See above. > potentially happen even without the user's knowledge (e.g. if a MUA > tried to check signatures on mail as it was retrieved from the > mailserver, before the user sees it) Good point. > Note also that polite MUAs that want their messages to be > easily-verified can also just ensure that their user's OpenPGP > certificate is included with every signed message. This introduces no This requires changes to the MUA. AKR retrieve Just Works (tm) - for us and also for the TLAs. So indeed we must make it explicit. The best way forward is to provide an option or GPGME to explicitly enable this. This also requires chnages to the MUA, but iff a MUA author really wants it the required change will be trivial. Shalom-Salam, Werner -- 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 arnaud.fontaine at ssi.gouv.fr Wed Aug 23 14:53:10 2017 From: arnaud.fontaine at ssi.gouv.fr (Arnaud Fontaine) Date: Wed, 23 Aug 2017 14:53:10 +0200 Subject: [PATCH] scd: correct length for RSA public key response Message-ID: --- scd/app-openpgp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index 365f24649..381a9d747 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -944,7 +944,7 @@ determine_rsa_response (app_t app, int keyno) size = 2 + 3 /* header */ + 4 /* tag+len */ + app->app_local->keyattr[keyno].rsa.n_bits/8 - + 2 /* tag+len */ + app->app_local->keyattr[keyno].rsa.e_bits/8; + + 2 /* tag+len */ + (app->app_local->keyattr[keyno].rsa.e_bits + 7)/8; return size; } -- 2.14.1 From dgouttegattat at incenp.org Wed Aug 23 21:19:08 2017 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Wed, 23 Aug 2017 21:19:08 +0200 Subject: [PATCH v2 0/4] Add tests for the PGP trust model In-Reply-To: <87o9r6s71r.fsf@wheatstone.g10code.de> References: <87a840aebq.fsf@europa.jade-hamburg.de> <20170719201730.4339-1-dgouttegattat@incenp.org> <87378ldkoq.fsf@europa.jade-hamburg.de> <87o9r6s71r.fsf@wheatstone.g10code.de> Message-ID: On 08/23/2017 04:16 PM, Werner Koch wrote: > Hmmm, somehow that merge was bogus: > > + trust-pgp-2.scm \ > + trust-pgp-3.scm \ > + trust-pgp-4.scm! \ > gpgtar.scm \ > > There is an extra '!'. I fixed that to make "make distcheck" work but > the test failed. Maybe due to "gpg: Fix regexp sanitization" not being > applied. I think Justus appended the '!' on purpose to mark the test as being a test expected to fail ("XFAIL"). This test is indeed expected to fail due to issue 2923. But I had not noticed that marking XFAIL tests that way caused "make distcheck" to fail. > I disabled the test for now because we are in freeze for 2.2. I am fine with that. It could be re-enabled after we fix issue 2923. Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed Aug 23 21:32:42 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 23 Aug 2017 21:32:42 +0200 Subject: [PATCH v2 0/4] Add tests for the PGP trust model In-Reply-To: (Damien Goutte-Gattat's message of "Wed, 23 Aug 2017 21:19:08 +0200") References: <87a840aebq.fsf@europa.jade-hamburg.de> <20170719201730.4339-1-dgouttegattat@incenp.org> <87378ldkoq.fsf@europa.jade-hamburg.de> <87o9r6s71r.fsf@wheatstone.g10code.de> Message-ID: <87y3qaqdut.fsf@wheatstone.g10code.de> On Wed, 23 Aug 2017 21:19, dgouttegattat at incenp.org said: > I think Justus appended the '!' on purpose to mark the test as being a > test expected to fail ("XFAIL"). This test is indeed expected to fail That does work because it is a list of files to be processed by make. It does not known about gpgscm syntax. > I am fine with that. It could be re-enabled after we fix issue 2923. ok. Shalom-Salam, Werner -- 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 Thu Aug 24 04:31:00 2017 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 24 Aug 2017 11:31:00 +0900 Subject: ECC changes Message-ID: <87shghhf2z.fsf@iwagami.gniibe.org> Hello, When I visited Cologne last year, I addressed that we could improve ECC implementation of libgcrypt. This summer, I created a ticket for one thing: field specific methods. https://dev.gnupg.org/T3358 And I did some work for 25519. (We also can do for other curves.) https://dev.gnupg.org/source/libgcrypt/history/gniibe-T3358/ While it's faster than current implementation, please note that this is still much slower than the original implementation of Ed25519/X25519. The original implementation doesn't use MPI, but uses its own field element representation. Introducing different field element representations should be done in future. I think that some restructuring is needed for libgcrypt to do that. -- From wk at gnupg.org Fri Aug 25 13:01:29 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 25 Aug 2017 13:01:29 +0200 Subject: [PATCH] scd: correct length for RSA public key response In-Reply-To: (Arnaud Fontaine's message of "Wed, 23 Aug 2017 14:53:10 +0200") References: Message-ID: <871snzoqra.fsf@wheatstone.g10code.de> > - + 2 /* tag+len */ + app->app_local->keyattr[keyno].rsa.e_bits/8; > + + 2 /* tag+len */ + (app->app_local->keyattr[keyno].rsa.e_bits + 7)/8; Would you mind to explain your test setting? Shalom-Salam, Werner -- 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 arnaud.fontaine at ssi.gouv.fr Fri Aug 25 13:23:50 2017 From: arnaud.fontaine at ssi.gouv.fr (Arnaud Fontaine) Date: Fri, 25 Aug 2017 13:23:50 +0200 Subject: [PATCH] scd: correct length for RSA public key response In-Reply-To: <871snzoqra.fsf@wheatstone.g10code.de> References: <871snzoqra.fsf@wheatstone.g10code.de> Message-ID: <952c30cd-390d-1b67-d858-fb1793c4d388@ssi.gouv.fr> For example, with an exponent of 17 bits (e.g. 0x010001 which is commonly used on smartcards), 3 bytes are needed to encode it, not 2. When the conversion from bits to bytes is done with integer division, the value is truncated: 17/8 = 2.125 which is truncated to 2. The "(x+7)/8" trick permits to obtain the correct conversion; it is already used at several places in the code, but it is missing there. Actually, when the incorrect expected response length (i.e. Le field) is transmitted to the card, the card's answer is missing a byte (i.e. ... 6101) so an additional command has to be sent to the card to retrieve the last byte. Using the correct length avoids to send the additional command to retrieve the missing byte, when the computed length is wrong. Le 25/08/2017 ? 13:01, Werner Koch a ?crit : > >> - + 2 /* tag+len */ + app->app_local->keyattr[keyno].rsa.e_bits/8; >> + + 2 /* tag+len */ + (app->app_local->keyattr[keyno].rsa.e_bits + 7)/8; > > Would you mind to explain your test setting? > > > Shalom-Salam, > > Werner > From wk at gnupg.org Sun Aug 27 16:37:03 2017 From: wk at gnupg.org (Werner Koch) Date: Sun, 27 Aug 2017 16:37:03 +0200 Subject: [PATCH] scd: correct length for RSA public key response In-Reply-To: <952c30cd-390d-1b67-d858-fb1793c4d388@ssi.gouv.fr> (Arnaud Fontaine's message of "Fri, 25 Aug 2017 13:23:50 +0200") References: <871snzoqra.fsf@wheatstone.g10code.de> <952c30cd-390d-1b67-d858-fb1793c4d388@ssi.gouv.fr> Message-ID: <87o9r1krg0.fsf@wheatstone.g10code.de> On Fri, 25 Aug 2017 13:23, arnaud.fontaine at ssi.gouv.fr said: > For example, with an exponent of 17 bits (e.g. 0x010001 which is > commonly used on smartcards), 3 bytes are needed to encode it, not 2. Sure, I just wondered why it seemed to work in the past. > Actually, when the incorrect expected response length (i.e. Le field) is > transmitted to the card, the card's answer is missing a byte (i.e. ... > 6101) so an additional command has to be sent to the card to retrieve > the last byte. Using the correct length avoids to send the additional Okay, that explains it. >>> - + 2 /* tag+len */ + app->app_local->keyattr[keyno].rsa.e_bits/8; >>> + + 2 /* tag+len */ + (app->app_local->keyattr[keyno].rsa.e_bits + 7)/8; Also odd lengths are not that common for N, I will do the same for N_BITS too. Thanks for figuring this out. Shalom-Salam, Werner -- 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 Aug 28 13:51:11 2017 From: wk at gnupg.org (Werner Koch) Date: Mon, 28 Aug 2017 13:51:11 +0200 Subject: [Announce] GnuPG 2.2.0 released Message-ID: <87r2vvkj0w.fsf@wheatstone.g10code.de> Hello! Arguing that you don't care about the right to privacy because you have nothing to hide is no different from saying you don't care about free speech because you have nothing to say. - Edward Snowden The GnuPG team is pleased to announce the availability of a new release of GnuPG: version 2.2.0. See below for a list of new features and bug fixes. This release marks the start of a new long term support series to replace the 2.0.x series which will reach end-of-life on 2017-12-31. 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.0 =================================== This is the new long term stable branch. This branch will only see bug fixes and no new features. * gpg: Reverted change done in 2.1.23 so that --no-auto-key-retrieve is again the default. * Fixed a few minor bugs. This release incorporates all changes from the 2.1 series including these from the release candidate 2.1.23: * gpg: "gpg" is now installed as "gpg" and not anymore as "gpg2". If needed, the new configure option --enable-gpg-is-gpg2 can be used to revert this. * gpg: Option --auto-key-locate "local,wkd" is now used by default. Note: this enables keyserver and Web Key Directory operators to notice when you intend to encrypt to a mail address without having the key locally. This new behaviour will eventually make key discovery much easier and mostly automatic. Disable this by adding auto-key-locate local to your gpg.conf. [This description has been adjusted to include the above mentioned change in 2.2.0] * agent: Option --no-grab is now the default. The new option --grab allows to revert this. * gpg: New import option "show-only". * gpg: New option --disable-dirmngr to entirely disable network access for gpg. * gpg,gpgsm: Tweaked DE-VS compliance behaviour. * New configure flag --enable-all-tests to run more extensive tests during "make check". * gpgsm: The keygrip is now always printed in colon mode as documented in the man page. * Fixed connection timeout problem under Windows. A detailed description of the changes in the 2.2 (formerly 2.1) branch can be found at . Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.2.0 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.0.tar.bz2 (6379k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.0.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.0_20170828.exe (3797k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.0_20170828.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. A new release candidate for Gpg4win featuring this version of GnuPG will be available in a few days. 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.0.tar.bz2 you would use this command: gpg --verify gnupg-2.2.0.tar.bz2.sig gnupg-2.2.0.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.0.tar.bz2, you run the command like this: sha1sum gnupg-2.2.0.tar.bz2 and check that the output matches the next line: 36ee693d0b2ec529ecf53dd6d397cc38ba71c0a7 gnupg-2.2.0.tar.bz2 7b0cf3912b86a6bd7655026276984a34a248e625 gnupg-w32-2.2.0_20170828.exe 0997499bdc6edfa43e2ce3d2cda9de00ecbc369d gnupg-w32-2.2.0_20170828.tar.xz 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 ============= 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 user manual of the system. Separate man pages are included as well but they have not all the details available as are the manual. It is also possible to read the complete manual online in HTML format at https://gnupg.org/documentation/manuals/gnupg/ or in Portable Document Format 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 search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. You may also want to follow our postings at and . Support ======== 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. Maintenance and development of GnuPG is mostly financed by donations. The GnuPG project employs 4 full-time developers, one part-timer, and one contractor. They all work exclusivly on GnuPG and closely related software like Libgcrypt, GPGME, and GPA. Please consider to donate via: https://gnupg.org/donate/ Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, answering questions on the mailing lists, and for financing the project. Special thanks to Neal and Justus for all their valuable work. Happy hacking, Your GnuPG Team 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 five keys: 2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 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/33BD3F06 2014-10-29 [expires: 2016-10-28] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31] Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 Werner Koch (Release Signing Key) rsa3072/4B092E28 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) You may retrieve these keys from a keyserver using this command gpg --keyserver hkp://keys.gnupg.net --recv-keys \ 249B39D24F25E3B6 04376F3EE0856959 \ 2071B08A33BD3F06 8A861B1C7EFD60D9 BCEF7E294B092E28 The keys are also available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 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 vollkorn at cryptobitch.de Tue Aug 29 17:50:34 2017 From: vollkorn at cryptobitch.de (Jan Girlich) Date: Tue, 29 Aug 2017 17:50:34 +0200 Subject: GPGME: Invalid value when trying to encrypt with certain keys Message-ID: <6d78003f-fd33-35c2-b2a9-0d336f0b6e78@cryptobitch.de> Hi, I encountered something I believe to be a bug in libgpgme 1.8.0, but I'm not sure, so I thought to write here to discuss my problem before submitting a bug report. One specific key (available on the key servers as 0xDC3E9C95) causes an "Invalid value" error, but this key is in use since 1996 and works fine when used directly with gpg or enigmail. Something notable: This key does not have any email addresses associated with it. I used the Python bindings as in the following bit of minimal sample code: #!/usr/bin/env python import gpg with gpg.Context(armor=True) as c: c.set_keylist_mode(gpg.constants.keylist.mode.EXTERN) recipient_key = c.get_key('0xDC3E9C95') c.op_import_keys([recipient_key]) encrypted_body, _, _ = c.encrypt( 'T?st'.encode(), recipients=[recipient_key], always_trust=True) print(encrypted_body.decode('utf-8')) encrypt() throws an Exception which IMHO only shows that the error originates from behind the function wrapper of the Python bindings: Traceback (most recent call last): File "/usr/share/pycharm/helpers/pydev/pydevd.py", line 1599, in globals = debugger.run(setup['file'], None, None, is_module) File "/usr/share/pycharm/helpers/pydev/pydevd.py", line 1026, in run pydev_imports.execfile(file, globals, locals) # execute the script File "/usr/share/pycharm/helpers/pydev/_pydev_imps/_pydev_execfile.py", line 18, in execfile exec(compile(contents+"\n", file, 'exec'), glob, loc) File "/home/jan/Projekte/AA/gpg_test.py", line 13, in always_trust=True) File "/home/jan/Projekte/AA/env/lib/python3.5/site-packages/gpg/core.py", line 269, in encrypt self.op_encrypt_sign(recipients, flags, plaintext, ciphertext) File "/home/jan/Projekte/AA/env/lib/python3.5/site-packages/gpg/core.py", line 151, in wrapper return _funcwrap(self, *args) File "/home/jan/Projekte/AA/env/lib/python3.5/site-packages/gpg/core.py", line 135, in _funcwrap return errorcheck(result, "Invocation of " + name) File "/home/jan/Projekte/AA/env/lib/python3.5/site-packages/gpg/errors.py", line 62, in errorcheck raise GPGMEError(retval, extradata) gpg.errors.GPGMEError: Invocation of gpgme_op_encrypt_sign: GPGME: Invalid value Well, does this look like a bug to you? Cheers vollkorn From peter at digitalbrains.com Tue Aug 29 21:51:28 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 29 Aug 2017 21:51:28 +0200 Subject: GPGME: Invalid value when trying to encrypt with certain keys In-Reply-To: <6d78003f-fd33-35c2-b2a9-0d336f0b6e78@cryptobitch.de> References: <6d78003f-fd33-35c2-b2a9-0d336f0b6e78@cryptobitch.de> Message-ID: On 29/08/17 17:50, Jan Girlich wrote: > One specific key (available on the key servers as 0xDC3E9C95) causes an > "Invalid value" error, but this key is in use since 1996 and works fine > when used directly with gpg or enigmail. It's an ancient key that should not be used anymore for anything more than curiosity value, and recent versions of OpenPGP software might well deny to use it. For instance, my GnuPG 2.1.18 (Debian stretch) refuses it with "skipped PGP-2 keys": $ gpg -vv --recv-keys 0xDC3E9C95 gpg: data source: http://keys.jhcloos.com:11371 gpg: armor: BEGIN PGP PUBLIC KEY BLOCK gpg: armor header: Version: SKS 1.1.6 gpg: armor header: Comment: Hostname: keys.jhcloos.com # off=0 ctb=99 tag=6 hlen=3 plen=269 gpg: packet(6) with obsolete version 3 :key packet: [obsolete version 3] # off=272 ctb=b4 tag=13 hlen=2 plen=8 :user ID packet: "birkmair" # off=282 ctb=89 tag=2 hlen=3 plen=277 :signature packet: algo 1, keyid 0780F54BDC3E9C95 version 3, created 849795725, md5len 5, sigclass 0x10 digest algo 1, begin of digest c6 53 data: [2042 bits] # off=562 ctb=b4 tag=13 hlen=2 plen=14 :user ID packet: "birkmair frank" # off=578 ctb=89 tag=2 hlen=3 plen=277 :signature packet: algo 1, keyid 0780F54BDC3E9C95 version 3, created 888724556, md5len 5, sigclass 0x10 digest algo 1, begin of digest 40 9d data: [2048 bits] # off=858 ctb=88 tag=2 hlen=2 plen=149 :signature packet: algo 1, keyid 44B8DDD6BB1D9F6D version 3, created 922794522, md5len 5, sigclass 0x10 digest algo 1, begin of digest 55 17 data: [1024 bits] # off=1009 ctb=88 tag=2 hlen=2 plen=70 :signature packet: algo 17, keyid 61A6C208B75F3105 version 4, created 1002273638, md5len 0, sigclass 0x10 digest algo 2, begin of digest 5b 45 hashed subpkt 2 len 4 (sig created 2001-10-05) subpkt 16 len 8 (issuer key ID 61A6C208B75F3105) data: [160 bits] data: [159 bits] gpg: Total number processed: 1 gpg: skipped PGP-2 keys: 1 These keys are not safe anymore, and haven't been for a while. If the key was a car, you'd not be allowed on the public road anymore, but hey, drive in your backyard all you want :-). 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 vollkorn at cryptobitch.de Wed Aug 30 06:55:39 2017 From: vollkorn at cryptobitch.de (Jan Girlich) Date: Wed, 30 Aug 2017 06:55:39 +0200 Subject: GPGME: Invalid value when trying to encrypt with certain keys In-Reply-To: References: <6d78003f-fd33-35c2-b2a9-0d336f0b6e78@cryptobitch.de> Message-ID: Am 29.08.2017 um 21:51 schrieb Peter Lebbing: > On 29/08/17 17:50, Jan Girlich wrote: >> One specific key (available on the key servers as 0xDC3E9C95) causes an >> "Invalid value" error, but this key is in use since 1996 and works fine >> when used directly with gpg or enigmail. > > It's an ancient key that should not be used anymore for anything more > than curiosity value, and recent versions of OpenPGP software might well > deny to use it. For instance, my GnuPG 2.1.18 (Debian stretch) refuses > it with "skipped PGP-2 keys": fair enough, but then I expect gpgme to reject it with a proper error stating so and not an opaque "invalid value". This behavior makes me believe there is some inner logic making assumptions about how keys are structured, which does not hold true. My gpg 1.4.20 does accept the key (but not it's md5 signatures) % LANG="C" gpg -vv --recv-keys 0xDC3E9C95 gpg: requesting key DC3E9C95 from hkp server keys.gnupg.net gpg: armor: BEGIN PGP PUBLIC KEY BLOCK gpg: armor header: Version: SKS 1.1.6 gpg: armor header: Comment: Hostname: pgpkeys.co.uk :public key packet: version 3, algo 1, created 849795723, expires 0 pkey[0]: [2048 bits] pkey[1]: [5 bits] keyid: 0780F54BDC3E9C95 :user ID packet: "birkmair" :signature packet: algo 1, keyid 0780F54BDC3E9C95 version 3, created 849795725, md5len 5, sigclass 0x10 digest algo 1, begin of digest c6 53 data: [2042 bits] :user ID packet: "birkmair frank" :signature packet: algo 1, keyid 0780F54BDC3E9C95 version 3, created 888724556, md5len 5, sigclass 0x10 digest algo 1, begin of digest 40 9d data: [2048 bits] :signature packet: algo 1, keyid 44B8DDD6BB1D9F6D version 3, created 922794522, md5len 5, sigclass 0x10 digest algo 1, begin of digest 55 17 data: [1024 bits] :signature packet: algo 17, keyid 61A6C208B75F3105 version 4, created 1002273638, md5len 0, sigclass 0x10 digest algo 2, begin of digest 5b 45 hashed subpkt 2 len 4 (sig created 2001-10-05) subpkt 16 len 8 (issuer key ID 61A6C208B75F3105) data: [160 bits] data: [159 bits] gpg: pub 2048R/DC3E9C95 1996-12-05 birkmair gpg: Note: signatures using the MD5 algorithm are rejected gpg: key DC3E9C95: invalid self-signature on user ID "birkmair" gpg: key DC3E9C95: invalid self-signature on user ID "birkmair frank" gpg: key DC3E9C95: skipped user ID "birkmair" gpg: key DC3E9C95: skipped user ID "birkmair frank" gpg: key DC3E9C95: no valid user IDs gpg: this may be caused by a missing self-signature gpg: Total number processed: 1 gpg: w/o user IDs: 1 Cheers vollkorn From bernhard at intevation.de Wed Aug 30 12:53:30 2017 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 30 Aug 2017 12:53:30 +0200 Subject: LTS policy? (was: GnuPG 2.2.0 released) In-Reply-To: <87r2vvkj0w.fsf@wheatstone.g10code.de> References: <87r2vvkj0w.fsf@wheatstone.g10code.de> Message-ID: <201708301253.36962.bernhard@intevation.de> Werner, @all, Am Montag 28 August 2017 13:51:11 schrieb Werner Koch: > Noteworthy changes in version 2.2.0 congratulations for releasing 2.2.0. :) > ? This is the new long term stable branch. ?This branch will only see > ? bug fixes and no new features. Can you explain more what you mean by "no new features"? Sometimes is hard to say if a change is necessary and thus a fix or if it optional. And fixes could break something as well. Will you create a 2.3.0 branch for all new features or only for those that break some compatibility? Best, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 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: 473 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Thu Aug 31 14:51:17 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 31 Aug 2017 14:51:17 +0200 Subject: LTS policy? In-Reply-To: <201708301253.36962.bernhard@intevation.de> (Bernhard Reiter's message of "Wed, 30 Aug 2017 12:53:30 +0200") References: <87r2vvkj0w.fsf@wheatstone.g10code.de> <201708301253.36962.bernhard@intevation.de> Message-ID: <8760d3gat5.fsf@wheatstone.g10code.de> On Wed, 30 Aug 2017 12:53, bernhard at intevation.de said: > Can you explain more what you mean by "no new features"? > Sometimes is hard to say if a change is necessary and thus a fix or if it > optional. And fixes could break something as well. Example for new features would be support for the v5 key format or a new symmetric encryption mode. This will not go into 2.2.0. However, if it will be easy to implement and does not require major changes to existing code paths it may happen that read-only support for such things will be backported to 2.2. This depends on our future release schedule and on whether a backport would help to deploy new algorithms or protocol extension. In general we will push our activity more into the direction of integrating gpg into other applications. If this requires tweaking things in 2.2 and a stable 2.4 is not yet on the horizon, we will do that in the 2.2 branch. But there won't be any disruptive things in 2.2. If major changes are required they will be tested in a 2.3 branch and then released with 2.4. > Will you create a 2.3.0 branch for all new features or only for those that > break some compatibility? To get forward with RFC4880bis we need to write some code, it is likely that this will happen in a 2.3 branch (i.e. in master). Salam-Shalom, Werner -- 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 Aug 31 15:48:47 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 31 Aug 2017 15:48:47 +0200 Subject: [Announce] Libgcrypt 1.8.1 and 1.7.9 to fix CVE-2017-0379 Message-ID: <87wp5jetkw.fsf@wheatstone.g10code.de> Hi! The GnuPG Project is pleased to announce the availability of Libgcrypt versions 1.7.9 and 1.8.1. These releases fix a local side-channel attack on our implementation of Curve25519 based encryption. 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.1 (2017-08-27) ================================================ - Mitigate a local side-channel attack on Curve25519 dubbed "May the Fourth be With You". [CVE-2017-0379] - Add more extra bytes to the pool after reading a seed file. - Add the OID SHA384WithECDSA from RFC-7427 to SHA-384. - Fix build problems with the Jitter RNG - Fix assembler code build problems on Rasbian (ARMv8/AArch32-CE). We also released a new version of the older 1.7 branch: Noteworthy changes in version 1.7.9 (2017-08-27) ================================================ - Mitigate a local side-channel attack on Curve25519 dubbed "May the Fourth be With You". [CVE-2017-0379] Comments on the vulnerability ============================= Details on this attack can be found in the paper May the Fourth Be With You: A Microarchitectural Side Channel Attack on Real-World Applications of Curve25519 by Daniel Genkin, Luke Valenta, and Yuval Yarom https://eprint.iacr.org/2017/806. Note that this side-channel attack requires that the attacker can run arbitrary software on the hardware where the private Curve25519 encryption key is used. In GnuPG a Curve25519 key used for encryption is shown as "cv25519". Signature keys based on Curve25519 (in GnuPG "ed25519") are not affected. Allowing other users to run software on a machine with private keys should be considered a full security compromise of that machine, anyway. Thus in practice there are easier ways to access the private keys than to mount this side-channel attack. However, on boxes with virtual machines this attack may be used by one VM to steal private keys from another VM. We received a draft of that research paper on August 18th and published these releases last Sunday (August 27th). The Windows installer for GnuPG 2.2.0, as released on Monday, has already been build with the fixed Libgcrypt 1.8.1. The actually used fix can be found as commit bf76acbf0da6b0f245e491bec12c0f0a1b5be7c9 in the Libgcrypt Git repo. Niibe-san is currently working on improving our Curve25519 support for the next major Libgcrypt release. This will give us an additional protection method against this class of attacks. 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.1.tar.bz2 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.1.tar.bz2.sig or gzip compressed: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.1.tar.gz https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.1.tar.gz.sig The URLS for the older 1.7 branch are: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.9.tar.bz2 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.9.tar.bz2.sig https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.9.tar.gz https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.9.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.1.tar.bz2 you would use this command: gpg --verify libgcrypt-1.8.1.tar.bz2.sig libgcrypt-1.8.1.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.1.tar.bz2, you run the command like this: sha1sum libgcrypt-1.8.1.tar.bz2 and check that the output matches the first line from the this list: dd35f00da45602afe81e01f4d60c40bbdd826fe6 libgcrypt-1.8.1.tar.bz2 1256e3981258c07c7c77884409c4cbb30cf7b55c libgcrypt-1.8.1.tar.gz 04126cdca54074d8768dea4287493a5b338a9a98 libgcrypt-1.7.9.tar.bz2 7bfec30457e4daeaf131ba9fae0bdd3b2a185a1b libgcrypt-1.7.9.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. Maintenance and development of Libgcrypt is mostly financed by donations; see . We currently employ 4 full-time developers, one part-timer, and one contractor to work on GnuPG and closely related software like Libgcrypt. Thanks ====== We like to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Also many thanks to all our donors [3]. Happy hacking, The GnuPG Team [1] https://lists.gnupg.org/mailman/listinfo/gcrypt-devel [2] https://www.gnupg.org/service.html [3] https://gnupg.org/donate/kudos.html p.s. This is an announcement only mailing list. Please send replies only to the gcrypt-devel '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 five keys: 2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 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/33BD3F06 2014-10-29 [expires: 2016-10-28] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31] Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 Werner Koch (Release Signing Key) rsa3072/4B092E28 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) You may retrieve these keys from a keyserver using this command gpg --keyserver hkp://keys.gnupg.net --recv-keys \ 249B39D24F25E3B6 04376F3EE0856959 \ 2071B08A33BD3F06 8A861B1C7EFD60D9 BCEF7E294B092E28 The keys are also available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- 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