From tgc at jupiterrise.com Wed Mar 2 17:41:19 2016 From: tgc at jupiterrise.com (Tom G. Christensen) Date: Wed, 2 Mar 2016 17:41:19 +0100 Subject: libgpg-error: build error on Solaris 9 Message-ID: <56D717AF.2000501@jupiterrise.com> Hello, I was unable to build libgpg-error HEAD on Solaris 9: libtool: link: gcc -g -O2 -Wall -Wpointer-arith -Wno-psabi -fvisibility=hidden -o .libs/gpg-error gpg_error-strsource-sym.o gpg_error-strerror-sym.o gpg_error-gpg-error.o -L/usr/tgcware/lib ./.libs/libgpg-error.so -lintl -R/tmp/libgpg-error/lib -R/usr/tgcware/lib Undefined first referenced symbol in file sched_yield ./.libs/libgpg-error.so ld: fatal: Symbol referencing errors. No output written to .libs/gpg-error collect2: error: ld returned 1 exit status make[3]: *** [gpg-error] Error 1 make[3]: Leaving directory `/export/home/tgc/tmp/libgpg-error/src' Configure detects that librt is needed: ... checking for library containing sched_yield... -lrt ... However the makefiles do not actually use the value of LIB_SCHED_YIELD for anything so -lrt is missing at link time. -tgc From gniibe at fsij.org Thu Mar 3 08:59:26 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 3 Mar 2016 16:59:26 +0900 Subject: libgpg-error: build error on Solaris 9 In-Reply-To: <56D717AF.2000501@jupiterrise.com> References: <56D717AF.2000501@jupiterrise.com> Message-ID: <56D7EEDE.3090909@fsij.org> Hello, Thank you for testing on Solaris. On 03/03/2016 01:41 AM, Tom G. Christensen wrote: > However the makefiles do not actually use the value of LIB_SCHED_YIELD > for anything so -lrt is missing at link time. My badness. I was looking NPTH library and changed wrongly. I believe that following patch can fix. We also need to change src/gen-posix-lock-obj.c, so that USE_DOUBLE_FOR_ALIGNMENT macro is defined 1. I code: #if defined(__solaris__) && !defined (__LP64__) && !defined(_LP64) But it is reported it doesn't work. https://bugs.gnupg.org/gnupg/issue2144 If you can figure out how to fix this, please let us know, too. Thanks in advance. diff --git a/configure.ac b/configure.ac index 9882d02..6d25b51 100644 --- a/configure.ac +++ b/configure.ac @@ -408,18 +408,13 @@ config_libs="-lgpg-error" # # Check for other libraries (now only for -lrt). # -# Save and restore LIBS so e.g., -lrt, isn't added to it. Otherwise, *all* -# programs in the package would end up linked with that potentially-shared -# library, inducing unnecessary run-time overhead. LIB_SCHED_YIELD= AC_SUBST([LIB_SCHED_YIELD]) -gl_saved_libs=$LIBS AC_SEARCH_LIBS([sched_yield], [rt posix4], [if test "$ac_cv_search_sched_yield" != "none required"; then LIB_SCHED_YIELD=$ac_cv_search_sched_yield config_libs="$config_libs $LIB_SCHED_YIELD" fi]) -LIBS=$gl_saved_libs # # Prepare building of estream -- From tgc at jupiterrise.com Thu Mar 3 16:13:31 2016 From: tgc at jupiterrise.com (Tom G. Christensen) Date: Thu, 3 Mar 2016 16:13:31 +0100 Subject: libgpg-error: build error on Solaris 9 In-Reply-To: <56D7EEDE.3090909@fsij.org> References: <56D717AF.2000501@jupiterrise.com> <56D7EEDE.3090909@fsij.org> Message-ID: <56D8549B.30103@jupiterrise.com> On 03/03/16 08:59, NIIBE Yutaka wrote: > On 03/03/2016 01:41 AM, Tom G. Christensen wrote: >> However the makefiles do not actually use the value of LIB_SCHED_YIELD >> for anything so -lrt is missing at link time. > > My badness. I was looking NPTH library and changed wrongly. I believe > that following patch can fix. > Yes, that works fine. Tested on Solaris 9/x86 and Solaris 10/SPARC (32bit & 64bit). > We also need to change src/gen-posix-lock-obj.c, so that > USE_DOUBLE_FOR_ALIGNMENT macro is defined 1. > > I code: > > #if defined(__solaris__) && !defined (__LP64__) && !defined(_LP64) > To detect Solaris you must look for __sun instead of __solaris__. A reference for pre-defined compiler macros can be found here: https://sourceforge.net/p/predef/wiki/Home/ It also covers SunOS/Solaris. > If you can figure out how to fix this, please let us know, too. > Thanks in advance. > I replaced __solaris__ with __sun and now the test passes. Tested on Solaris 9/x86 and Solaris 10/SPARC (32bit & 64bit). -tgc From aheinecke at intevation.de Thu Mar 3 17:00:30 2016 From: aheinecke at intevation.de (Andre Heinecke) Date: Thu, 03 Mar 2016 17:00:30 +0100 Subject: Secret key import results and GnuPG 2.1 Message-ID: <2643166.6X3et3vtOJ@esus> Hi, (I think this was mentioned on this list earlier but I couldn't find a thread for this) With 2.1 the importing a scret key leads to the following result: gpg: key 6CFBC912: public key "Test UserA " imported gpg: key 6CFBC912: secret key imported gpg: Total number processed: 2 gpg: imported: 1 gpg: secret keys read: 2 gpg: secret keys imported: 1 With 1.4 (and afaik with 2.0) it was: gpg: key 6CFBC912: public key "Test UserA " imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) gpg: secret keys read: 1 gpg: secret keys imported: 1 I think it means that two subkeys are processed / read. But then the output should differentiate between subkey and primary key. Otherwise the "secret keys imported" is confusing because both subkeys were imported. It appears to me that in one line of that output the word keys has a different meaning as in the next line. As this result is also passed through gpgme API leading to problems for me in Kleopatra where a result is now shown as: http://files.intevation.de/users/aheinecke/kleo-import.png Which is confusing. I'm not sure how I should change this in Kleo. Is this output change even intentional or was it just a side effect? 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: 648 bytes Desc: This is a digitally signed message part. URL: From beebe at math.utah.edu Thu Mar 3 16:32:35 2016 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Thu, 3 Mar 2016 08:32:35 -0700 Subject: libgpg-error: build error on Solaris 9 In-Reply-To: <56D8549B.30103@jupiterrise.com> Message-ID: Paul Koning writes on Thu, 3 Mar 2016 10:14:35 -0500: >> A reference for pre-defined compiler macros can be found here: >> https://sourceforge.net/p/predef/wiki/Home/ Thanks for that useful reference! To display a sorted list of all of the symbols predefined by many Unix compilers, try this script: http://www.math.utah.edu/~beebe/cc-defs For example: % cc-defs pcc #define _LP64 1 #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ #define __DATE__ "Mar 3 2016" ... #define __PCC_MINORMINOR__ 0 #define __PCC_MINOR__ 2 #define __PCC__ 1 ... #define __VERSION__ "Portable C Compiler 1.2.0.DEVEL 20160108 for x86_64-unknown-linux-gnu" #define __x86_64 1 #define __x86_64__ 1 Extensions to that script to support more compilers are always welcome. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From gniibe at fsij.org Fri Mar 4 01:06:21 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 4 Mar 2016 09:06:21 +0900 Subject: libgpg-error: build error on Solaris 9 In-Reply-To: <56D8549B.30103@jupiterrise.com> References: <56D717AF.2000501@jupiterrise.com> <56D7EEDE.3090909@fsij.org> <56D8549B.30103@jupiterrise.com> Message-ID: <56D8D17D.6080700@fsij.org> Hello, Thanks a lot for your testing and suggestion. It was fixed by the commits f7a77c5 and f9fc565. On 03/04/2016 12:13 AM, Tom G. Christensen wrote: > Yes, that works fine. > > Tested on Solaris 9/x86 and Solaris 10/SPARC (32bit & 64bit). Good. > To detect Solaris you must look for __sun instead of __solaris__. > > A reference for pre-defined compiler macros can be found here: > https://sourceforge.net/p/predef/wiki/Home/ > It also covers SunOS/Solaris. Thank you for useful link. -- From dashohoxha at gmail.com Fri Mar 4 07:48:45 2016 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Fri, 4 Mar 2016 07:48:45 +0100 Subject: Automated testing of scripts that use GnuPG Message-ID: Hi, I am trying to develop some wrapper shell scripts that try to simplify the process of using GnuPG: https://github.com/dashohoxha/egpg I am also trying to write some automated tests for these scripts (based on Sharness): https://github.com/dashohoxha/egpg/tree/master/tests But I am having problems because `gpg` has a "nasty" behaviour, it always pops up a window for getting the passphrase. Maybe this is a nice feature for the normal operation of the scripts, but for automatic testing it breaks the 'automatic' part. Is there any way to solve or work around this problem? I know about "--passphrase-fd=0" and then passing the passphrase from the stdin. But, first, it does not always work, and second, I would like to override that behaviour only for the case of testing, not for the normal operation. Maybe it can be some configuration or some environment variable, that I can change during testing. Thanks, Dashamir P.s. Maybe I should have posted this message to the list of users, not to developers. Please let me know if this is the case. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Fri Mar 4 09:38:29 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 04 Mar 2016 09:38:29 +0100 Subject: default keyid format In-Reply-To: <87lh78ld9w.fsf@vigenere.g10code.de> References: <87egd37cpz.fsf@alice.fifthhorseman.net> <87mvrrto8l.fsf@vigenere.g10code.de> <877fiu66y8.fsf@alice.fifthhorseman.net> <87lh78ld9w.fsf@vigenere.g10code.de> Message-ID: <87si06ocxm.fsf@alice.fifthhorseman.net> On Fri 2016-01-29 14:35:07 +0100, Werner Koch wrote: > "none" is a problem becuase the keyid is also used at other places and > wheere we do not have a fingerprint available. Thus your original plan > to make "long" the default seems to be better. > > Let me do this along with --with-fingerprint being the default and a new > option --without-fingerprint. What's the plan on this change? Should i record it in https://bugs.gnupg.org/ ? --dkg From astieger at suse.com Fri Mar 4 10:18:24 2016 From: astieger at suse.com (Andreas Stieger) Date: Fri, 4 Mar 2016 10:18:24 +0100 Subject: Automated testing of scripts that use GnuPG In-Reply-To: References: Message-ID: <56D952E0.9010807@suse.com> Hi, On 03/04/2016 07:48 AM, Dashamir Hoxha wrote: > [...] develop some wrapper shell scripts [...] > But I am having problems because `gpg` has a "nasty" behaviour, it > always pops up a window for getting the passphrase. Maybe this is a nice > feature for the normal operation of the scripts, but for automatic > testing it breaks the 'automatic' part. You may want to use a configuration that causes GnuPG to use different pinentry flavour that works in your test rig: the tty one, or a mock implementation of the simple pinentry protocol, possibly written in Sharness itself if it can do IPC. Andreas -- Andreas Stieger Project Manager Security SUSE Linux GmbH, GF: Felix Imend?rffer, Jane Smithard, Graham Norton, HRB 21284 (AG N?rnberg) From dashohoxha at gmail.com Fri Mar 4 11:12:10 2016 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Fri, 4 Mar 2016 11:12:10 +0100 Subject: Automated testing of scripts that use GnuPG In-Reply-To: <56D952E0.9010807@suse.com> References: <56D952E0.9010807@suse.com> Message-ID: On Fri, Mar 4, 2016 at 10:18 AM, Andreas Stieger wrote: > Hi, > > On 03/04/2016 07:48 AM, Dashamir Hoxha wrote: > > [...] develop some wrapper shell scripts [...] > > But I am having problems because `gpg` has a "nasty" behaviour, it > > always pops up a window for getting the passphrase. Maybe this is a nice > > feature for the normal operation of the scripts, but for automatic > > testing it breaks the 'automatic' part. > > You may want to use a configuration that causes GnuPG to use different > pinentry flavour that works in your test rig: the tty one, or a mock > implementation of the simple pinentry protocol, possibly written in > Sharness itself if it can do IPC. >From your answer I understand that it has something to do with pinentry, and I will search more on this direction. By the way, Sharness is just a library of bash functions: https://github.com/dashohoxha/egpg/blob/master/tests/sharness.sh Thanks, Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From justus at g10code.com Fri Mar 4 11:10:47 2016 From: justus at g10code.com (Justus Winter) Date: Fri, 04 Mar 2016 11:10:47 +0100 Subject: Automated testing of scripts that use GnuPG In-Reply-To: <56D952E0.9010807@suse.com> References: <56D952E0.9010807@suse.com> Message-ID: <20160304101047.4486.49@thinkbox.jade-hamburg.de> Quoting Andreas Stieger (2016-03-04 10:18:24) > Hi, > > On 03/04/2016 07:48 AM, Dashamir Hoxha wrote: > > [...] develop some wrapper shell scripts [...] > > But I am having problems because `gpg` has a "nasty" behaviour, it > > always pops up a window for getting the passphrase. Maybe this is a nice > > feature for the normal operation of the scripts, but for automatic > > testing it breaks the 'automatic' part. > > You may want to use a configuration that causes GnuPG to use different > pinentry flavour that works in your test rig: the tty one, or a mock > implementation of the simple pinentry protocol, possibly written in > Sharness itself if it can do IPC. Exactly. See e.g. tests/openpgp/pinentry.sh for such a mock implementation. Justus From quentin at bourgeois.eu Sat Mar 5 01:02:38 2016 From: quentin at bourgeois.eu (Quentin Bourgeois) Date: Sat, 5 Mar 2016 01:02:38 +0100 Subject: Exporting secret keys does not honor s2k* options on gnupg-modern Message-ID: <20160305000238.GB27735@totoro.intra.bourgeois.eu> Hi, After playing with two different versions of gnupg I can't understand why I have different results while exporting secret key. Used version: * GnuPG "modern" (2.1.11): from gnupg.org, archlinux package or debian sid packages * GnuPG "stable" (2.0.26): from debian jessie packages While on the stable version exporting a secret key will use the s2k variable from the gpg.conf file in order to encrypt the data, this is not done on the modern version. * An example, my gpg.conf file contains at least the following s2k-cipher-algo AES256 s2k-digest-algo SHA512 s2k-mode 3 s2k-count 65011712 * On the stable, after exporting a secret key the used algorithms are AES256 and SHA512 gpg-stable$ gpg2 --output key_stable.asc --export-secret-key 0xA705288CC4B10159 gpg-stable$ gpg2 --list-packets key_stable.asc :secret key packet: [...] iter+salt S2K, algo: 9, SHA1 protection, hash: 10, salt: c8fb14ee7e02109d [...] * Whereas on the modern, the exported key only used the AES128 regardless my configuration gpg-modern$ ./g10/gpg2 --output key_modern.asc --export-secret-keys 0x0A07DCA573AC5B12 gpg-modern$ ./g10/gpg2 --list-packets key_modern.asc :secret key packet: [...] iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: 893E1125967FBDAC [...] Note that i modify the key before exporting it. After looking some code of the of gnupg 2.11.1 the following line from g10/export.c:995 could explain /* Prepare a cipher context. */ err = gcry_cipher_open (&cipherhd, GCRY_CIPHER_AES128, GCRY_CIPHER_MODE_AESWRAP, 0); My questions: * Does having this difference is what the dev wants ? * Is there is anyway to choose how I can protected my exported secret key ? * Does I miss something ? I will be glad to provide more information on my setup / problem if needed. Thanks ! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From stargrave at stargrave.org Sun Mar 6 12:02:55 2016 From: stargrave at stargrave.org (Sergey Matveev) Date: Sun, 06 Mar 2016 14:02:55 +0300 Subject: [PATCH] doc: Official name of RIPE message digest is RIPEMD-160 Message-ID: <20160306110255.5IGonou4I%stargrave@stargrave.org> According to RIPEMD-160 digest specification: http://homes.esat.kuleuven.be/~bosselae/ripemd160.html and ECRYPT eHash wiki entry: http://ehash.iaik.tugraz.at/wiki/RIPEMD-160 this function is known as "RIPEMD", not "RIPE-MD". -- Signed-off-by: Sergey Matveev --- configure.ac | 2 +- doc/gpg-agent.texi | 2 +- g10/rmd160.c | 6 +++--- g10/sig-check.c | 2 +- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/configure.ac b/configure.ac index 003e509..61fd504 100644 --- a/configure.ac +++ b/configure.ac @@ -293,7 +293,7 @@ GNUPG_GPG_DISABLE_ALGO([camellia256],[CAMELLIA256 cipher]) GNUPG_GPG_DISABLE_ALGO([md5],[MD5 hash]) # SHA1 is a MUST algorithm -GNUPG_GPG_DISABLE_ALGO([rmd160],[RIPE-MD160 hash]) +GNUPG_GPG_DISABLE_ALGO([rmd160],[RIPEMD-160 hash]) GNUPG_GPG_DISABLE_ALGO([sha224],[SHA-224 hash]) # SHA256 is a MUST algorithm for GnuPG. GNUPG_GPG_DISABLE_ALGO([sha384],[SHA-384 hash]) diff --git a/doc/gpg-agent.texi b/doc/gpg-agent.texi index 5a387d4..fbddc3a 100644 --- a/doc/gpg-agent.texi +++ b/doc/gpg-agent.texi @@ -932,7 +932,7 @@ The SHA-1 hash algorithm @item sha256 The SHA-256 hash algorithm @item rmd160 -The RIPE-MD160 hash algorithm +The RIPEMD-160 hash algorithm @item md5 The old and broken MD5 hash algorithm @item tls-md5sha1 diff --git a/g10/rmd160.c b/g10/rmd160.c index 8eb005f..ca835d0 100644 --- a/g10/rmd160.c +++ b/g10/rmd160.c @@ -1,4 +1,4 @@ -/* rmd160.c - RIPE-MD160 +/* rmd160.c - RIPEMD-160 * Copyright (C) 1998, 1999, 2000, 2001, 2008 Free Software Foundation, Inc. * * This file is part of GnuPG. @@ -17,7 +17,7 @@ * along with this program; if not, see . */ -/* For historic reasons gpg uses RIPE-MD160 to to identify names in +/* For historic reasons gpg uses RIPEMD-160 to to identify names in the trustdb. It would be better to change that to SHA-1, to take advantage of a SHA-1 hardware operation provided by some CPUs. This would break trustdb compatibility and thus we don't want to do @@ -54,7 +54,7 @@ rol (u32 x, int n) #define rol(x,n) ( ((x) << (n)) | ((x) >> (32-(n))) ) #endif -/* Structure holding the context for the RIPE-MD160 computation. */ +/* Structure holding the context for the RIPEMD-160 computation. */ typedef struct { u32 h0, h1, h2, h3, h4; diff --git a/g10/sig-check.c b/g10/sig-check.c index ee0ebcb..03e2ed9 100644 --- a/g10/sig-check.c +++ b/g10/sig-check.c @@ -179,7 +179,7 @@ check_signature2 (PKT_signature *sig, gcry_md_hd_t digest, u32 *r_expiredate, * one second. Some remote batch processing applications might * like this feature here. * - * Note that before 2.0.10, we used RIPE-MD160 for the hash + * Note that before 2.0.10, we used RIPEMD-160 for the hash * and accidentally didn't include the timestamp and algorithm * information in the hash. Given that this feature is not * commonly used and that a replay attacks detection should -- 2.6.4 From stargrave at stargrave.org Sun Mar 6 13:04:37 2016 From: stargrave at stargrave.org (Sergey Matveev) Date: Sun, 06 Mar 2016 15:04:37 +0300 Subject: [PATCH] doc: CMS (RFC 3852) is cryptographic message syntax (not standard) Message-ID: <20160306120437.Wfb3bS-mL%stargrave@stargrave.org> -- Signed-off-by: Sergey Matveev --- doc/glossary.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/glossary.texi b/doc/glossary.texi index 1c72e50..c331344 100644 --- a/doc/glossary.texi +++ b/doc/glossary.texi @@ -22,7 +22,7 @@ online check of the certificate status. The chain model is required by the German signature law. See also @emph{Shell model}. @item CMS - The @emph{Cryptographic Message Standard} describes a message + The @emph{Cryptographic Message Syntax} describes a message format for encryption and digital signing. It is closely related to the X.509 certificate format. @acronym{CMS} was formerly known under the name @code{PKCS#7} and is described by @code{RFC3369}. -- 2.6.4 From chdiza at gmail.com Mon Mar 7 18:41:43 2016 From: chdiza at gmail.com (Charles Diza) Date: Mon, 7 Mar 2016 12:41:43 -0500 Subject: Broken configure script on OS X for pinentry Message-ID: Hello, I noticed the following error messages while building pinentry on OS X 10.11.3. Building continues and pinentry appears to work OK, but probably there's something wrong with the configure script. It appears to be calling `no` as a command. See paste below. -Charles ---------------8<--------------------------- checking for Qt5Core >= 5.0.0 Qt5Gui >= 5.0.0 Qt5Widgets >= 5.0.0... ./configure: line 9744: no: command not found ./configure: line 9752: no: command not found no ./configure: line 9770: no: command not found checking for QtCore >= 4.4.0 QtGui >= 4.4.0... ./configure: line 10123: no: command not found ./configure: line 10131: no: command not found no checking that generated files are newer than configure... done -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at minton.name Tue Mar 8 18:08:19 2016 From: brian at minton.name (Brian Minton) Date: Tue, 8 Mar 2016 12:08:19 -0500 Subject: is Gnupg.org's git server down? Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 $ git clone git://git.gnupg.org/gnupg.git Cloning into 'gnupg'... fatal: read error: Connection reset by peer I tried from two different clients with the same results. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EARYIAAYFAlbfBvYACgkQN7lQes/yAW67SwEA4uq7hKjNbH3I5YD+RZfIQW5S Mv6N4tjvixJfRvtBHPUBALKhXe6EhSsgT4/C4/VdpB7nsfw2B9cdcOY6zW3BX/ML =UEGG -----END PGP SIGNATURE----- From kristian.fiskerstrand at sumptuouscapital.com Tue Mar 8 21:21:49 2016 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 8 Mar 2016 21:21:49 +0100 Subject: is Gnupg.org's git server down? In-Reply-To: References: Message-ID: <56DF345D.2060704@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 03/08/2016 06:08 PM, Brian Minton wrote: > $ git clone git://git.gnupg.org/gnupg.git Cloning into 'gnupg'... > fatal: read error: Connection reset by peer > > I tried from two different clients with the same results. Can reproduce here - -- - ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Aquila non capit muscas The eagle does not hunt flies -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJW3zRWAAoJECULev7WN52FOu0IAJepqpxB/oo7k6AGltS3470S +97ShRdPQjxLvx2YMpl3yRM6FtzfTnoVZoQnJpSpVGf0Y3zYqJL//wj7PRAhbGl6 5QxLFQNmaeN008cJtbhnfS4S4aT6EfkqkFEwvvQFb0HXVB8Fgxw3zmt9LdYgATLD TG42FAyZonhb8hlymYbTQw2xbAEyzEf0xOUAg6JPDbWEnDN0CdV30KIbhvEnNSvb Zr4SN3jnkXbahfDo0TWrSTMS0IF8cCIT46pqunUSfM4z8SgoljyO9pEka9zK21nG x/kQpd7XR/OcSI1/xOqnzThhxJWWGIwQ0Voyw4WUgoWF/NeJ5zLPOqXfgazB1MA= =EPGS -----END PGP SIGNATURE----- From pnathan at alumni.uidaho.edu Tue Mar 8 20:03:47 2016 From: pnathan at alumni.uidaho.edu (Paul Nathan) Date: Tue, 8 Mar 2016 11:03:47 -0800 Subject: is Gnupg.org's git server down? In-Reply-To: References: Message-ID: On Tue, Mar 8, 2016 at 9:08 AM, Brian Minton wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > $ git clone git://git.gnupg.org/gnupg.git > Cloning into 'gnupg'... > fatal: read error: Connection reset by peer > > I tried from two different clients with the same results. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iF4EARYIAAYFAlbfBvYACgkQN7lQes/yAW67SwEA4uq7hKjNbH3I5YD+RZfIQW5S > Mv6N4tjvixJfRvtBHPUBALKhXe6EhSsgT4/C4/VdpB7nsfw2B9cdcOY6zW3BX/ML > =UEGG > -----END PGP SIGNATURE----- > I am sorry to report that I can independently confirm this error. _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From somasissounds at gmail.com Wed Mar 9 03:40:33 2016 From: somasissounds at gmail.com (Kylie McClain) Date: Tue, 8 Mar 2016 21:40:33 -0500 Subject: [PATCH] syscfg: Add lock-obj-pub files for {armv5, armv6, x86_64}-musl targets Message-ID: <1457491233-22883-1-git-send-email-somasissounds@gmail.com> From: Kylie McClain This patch adds three new precompiled lock-obj-pub files: - armv5-unknown-linux-musleabi - armv6-unknown-linux-musleabihf - x86_64-pc-linux-musl --- .../lock-obj-pub.armv5-unknown-linux-musleabi.h | 23 ++++++++++++++++++++ .../lock-obj-pub.armv6-unknown-linux-musleabihf.h | 23 ++++++++++++++++++++ src/syscfg/lock-obj-pub.x86_64-pc-linux-musl.h | 25 ++++++++++++++++++++++ 3 files changed, 71 insertions(+) create mode 100644 src/syscfg/lock-obj-pub.armv5-unknown-linux-musleabi.h create mode 100644 src/syscfg/lock-obj-pub.armv6-unknown-linux-musleabihf.h create mode 100644 src/syscfg/lock-obj-pub.x86_64-pc-linux-musl.h diff --git a/src/syscfg/lock-obj-pub.armv5-unknown-linux-musleabi.h b/src/syscfg/lock-obj-pub.armv5-unknown-linux-musleabi.h new file mode 100644 index 0000000..c7b6165 --- /dev/null +++ b/src/syscfg/lock-obj-pub.armv5-unknown-linux-musleabi.h @@ -0,0 +1,23 @@ +## lock-obj-pub.armv5-unknown-linux-musleabi.h +## File created by gen-posix-lock-obj - DO NOT EDIT +## To be included by mkheader into gpg-error.h + +typedef struct +{ + long _vers; + union { + volatile char _priv[24]; + long _x_align; + long *_xp_align; + } u; +} gpgrt_lock_t; + +#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0}}} +## +## Local Variables: +## mode: c +## buffer-read-only: t +## End: +## diff --git a/src/syscfg/lock-obj-pub.armv6-unknown-linux-musleabihf.h b/src/syscfg/lock-obj-pub.armv6-unknown-linux-musleabihf.h new file mode 100644 index 0000000..6535a9b --- /dev/null +++ b/src/syscfg/lock-obj-pub.armv6-unknown-linux-musleabihf.h @@ -0,0 +1,23 @@ +## lock-obj-pub.armv6-unknown-linux-musleabihf.h +## File created by gen-posix-lock-obj - DO NOT EDIT +## To be included by mkheader into gpg-error.h + +typedef struct +{ + long _vers; + union { + volatile char _priv[24]; + long _x_align; + long *_xp_align; + } u; +} gpgrt_lock_t; + +#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0}}} +## +## Local Variables: +## mode: c +## buffer-read-only: t +## End: +## diff --git a/src/syscfg/lock-obj-pub.x86_64-pc-linux-musl.h b/src/syscfg/lock-obj-pub.x86_64-pc-linux-musl.h new file mode 100644 index 0000000..1b059f4 --- /dev/null +++ b/src/syscfg/lock-obj-pub.x86_64-pc-linux-musl.h @@ -0,0 +1,25 @@ +## lock-obj-pub.x86_64-pc-linux-musl.h +## File created by gen-posix-lock-obj - DO NOT EDIT +## To be included by mkheader into gpg-error.h + +typedef struct +{ + long _vers; + union { + volatile char _priv[40]; + long _x_align; + long *_xp_align; + } u; +} gpgrt_lock_t; + +#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0}}} +## +## Local Variables: +## mode: c +## buffer-read-only: t +## End: +## -- 2.7.2 From kevin at 8t8.us Wed Mar 9 22:15:17 2016 From: kevin at 8t8.us (Kevin J. McCarthy) Date: Wed, 9 Mar 2016 13:15:17 -0800 Subject: [PATCH] Silence "using xxx as default secret key" message with --quiet flag Message-ID: <20160309211517.GC29751@zaogao.lan> Sorry for the drive-by patch. I've recently started using gpg 2.1, and now every time I sign a message in mutt, gpg generates the output gpg: using "xxxx" as default secret key for signing despite passing the --quiet flag. It looks like just adding a check for opt.quiet inside parse_def_secret_key() should silence this message. I can't seem to clone the git repos right now, so I'm attaching a simple diff. Would it be possible to have this committed? Thank you, -Kevin -------------- next part -------------- --- g10/getkey.c.orig 2016-03-09 13:00:19.591723827 -0800 +++ g10/getkey.c 2016-03-09 13:00:34.175092828 -0800 @@ -1676,11 +1676,11 @@ print_reported_error (err, GPG_ERR_NO_SECKEY); } } else { - if (! warned) + if (! warned && ! opt.quiet) log_info (_("using \"%s\" as default secret key for signing\n"), t->d); break; } } -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From gnupg-devel at spodhuis.org Thu Mar 10 07:50:00 2016 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Thu, 10 Mar 2016 06:50:00 +0000 Subject: is Gnupg.org's git server down? In-Reply-To: References: Message-ID: <20160310065000.GA96464@tower.spodhuis.org> On 2016-03-08 at 12:08 -0500, Brian Minton wrote: > $ git clone git://git.gnupg.org/gnupg.git > Cloning into 'gnupg'... > fatal: read error: Connection reset by peer > > I tried from two different clients with the same results. Daily automatic pulls (03:49 UTC + random seconds) hit a snag on Sunday, I remember investigating either Sunday or Monday and the problem was gone, I could pull all the repos I mirror. That was: gnupg-doc gpa gpg4win gpgex The updates starting Tuesday morning have completely failed on all gnupg.org repos which I mirror: geam gnupg gnupg-doc gpa gpg4win gpgex gpgme gpgol gsti libassuan libgcrypt libgpg-error libksba npth ntbtls pinentry pinentry-qt poldi scute tgpg wk-misc My mirror is for personal use, not guaranteed to be available, should not be put in any install systems as a backup, yada yada, but if you need the repos right now, they're at: https://git.spodhuis.org/gnupg.org/ My mirroring also snapshots the before/after state of the heads etc, so while corruption will propagate, I can roll back to the old ref if ever needed, to recover. -Phil From cannon at cannon-ciota.info Thu Mar 10 07:40:33 2016 From: cannon at cannon-ciota.info (CANNON NATHANIEL CIOTA) Date: Thu, 10 Mar 2016 00:40:33 -0600 Subject: Random Data String to protect from input correlation Message-ID: <57f4b9e577fed1ded1d013b102dcf804@cannon-ciota.info> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Subject: Random Data String to protect from input correlation Date: 2016-03-10T05:37:17+00:00 I have a question in regards to GnuPG. In my inquiry I shall refer to the data being encrypted as the input, and result of the encrypted data being the output. And so I question if data encrypted to my public key has the same output each time when provided with the same input. If not is there any way the output can be proven to have been the result of a suspected input? Reason I am curious of such, is the theory of an adversary intercepting data encrypted to my public key. Then after such interception attempting to deduce the data destined for me by confirming if the intercepted output was a result of what they suspect to be the input. If such correlation is possible, then my proposal would be to have included with the input before encryption a randomized string denoted by a tag interpretable to GnuPG which would then be excluded upon decryption. Cannon C. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJW4RW3AAoJEAYDai9lH2mwU9UQAJYn9jiBGYmqwOAX7+h1L7rZ 5+Doma1KXbVJr2G5dmiB6gtRAu3G/D4Bbfxjgj9sUG7J1llGtDLDPjgw01HQPKOM sd3TTOVJ007WeOQzIIKVO2I7kRO01zTUsRT2A41iRMVdVhp9LZAi0+YS7Aokx33R D2u8WCo+6uIp1po8wKDZ8rbeiRq0tSy+Kjb/AZ8l+Lwa7CeGrYr/nnWBGNBC8vox v6N+qFSLKoFsnBCGvIcw8fooy7PznGV/v+dlMIn7XQJESCiz8XDbhU1A166d2ODM hDQoKQPAJ2E7NiHy4CI8VwUdLnY1iJ+I8h87L/U2JdYNfOmQkh8rlLA/WopN7oVP ZQMJGLb2iAcR5H1W8e4/C0fEsaZSwWE6/AlsSkAUyRMloJSi1TPhDD10ftmku/BR F2ipegoeFfNCilBqnxsOq5YhsaB7kakiFY/mr/J5CjrLdtsDHA2TbDuCjQPtqtD8 ONaCPH9Bq3LYYxecnIkYjArp2G5D7jYTHQXJJuZ3+JMdsXEWnPI9aR5VdIxqtceU KN3pXiFByLefMbLKY0Gi3Rd0BK6AiTIYObDLZ/t6uO55MFNeC2GKLJKEBebGFi42 /uZekVt8kUL8dh0hSLHWZRIW7oi8yXX9rNEzd6Qz0pQHJ2hahqJXILkGZ2VCr0ln 69Tsu0dSAqO/4QJF21Q+ =+Cy3 -----END PGP SIGNATURE----- -- Cannon N. Ciota Digital Identity (namecoin): id/cannon Website: www.cannon-ciota.info Email: cannon at cannon-ciota.info PGP Fingerprint: E7FB 0605 1BD4 8B88 B7BC 91A4 7DF7 76C7 25A6 AEE2 From neal at walfield.org Thu Mar 10 11:22:01 2016 From: neal at walfield.org (Neal H. Walfield) Date: Thu, 10 Mar 2016 11:22:01 +0100 Subject: Random Data String to protect from input correlation In-Reply-To: <57f4b9e577fed1ded1d013b102dcf804@cannon-ciota.info> References: <57f4b9e577fed1ded1d013b102dcf804@cannon-ciota.info> Message-ID: <87mvq68wfq.wl-neal@walfield.org> On Thu, 10 Mar 2016 07:40:33 +0100, CANNON NATHANIEL CIOTA wrote: > If such correlation is possible, then my proposal would be to have > included with the input before encryption a randomized string denoted > by a tag interpretable to GnuPG which would then be excluded upon > decryption. What you describe is basically how OpenPGP works. :) Neal From wk at gnupg.org Thu Mar 10 12:39:12 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 10 Mar 2016 12:39:12 +0100 Subject: is Gnupg.org's git server down? In-Reply-To: (Brian Minton's message of "Tue, 8 Mar 2016 12:08:19 -0500") References: Message-ID: <87bn6mr28v.fsf@wheatstone.g10code.de> On Tue, 8 Mar 2016 18:08, brian at minton.name said: > $ git clone git://git.gnupg.org/gnupg.git > Cloning into 'gnupg'... > fatal: read error: Connection reset by peer Should work again. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From justus at g10code.com Thu Mar 10 12:44:17 2016 From: justus at g10code.com (Justus Winter) Date: Thu, 10 Mar 2016 12:44:17 +0100 Subject: [PATCH] Silence "using xxx as default secret key" message with --quiet flag In-Reply-To: <20160309211517.GC29751@zaogao.lan> References: <20160309211517.GC29751@zaogao.lan> Message-ID: <20160310114417.4648.59575@thinkbox.jade-hamburg.de> Quoting Kevin J. McCarthy (2016-03-09 22:15:17) > Sorry for the drive-by patch. No need to apologize, merged, thanks! Justus From rjh at sixdemonbag.org Thu Mar 10 17:46:42 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 10 Mar 2016 11:46:42 -0500 Subject: Random Data String to protect from input correlation In-Reply-To: <57f4b9e577fed1ded1d013b102dcf804@cannon-ciota.info> References: <57f4b9e577fed1ded1d013b102dcf804@cannon-ciota.info> Message-ID: <56E1A4F2.40202@sixdemonbag.org> > And so I question if data encrypted to my public key has the same > output each time when provided with the same input. No. Your input is encrypted with a randomly generated AES256 key. That AES256 key is encrypted with your recipient's public key. The encrypted session key and the encrypted message are given to your recipient. > If not is there any way the output can be proven to have been the > result of a suspected input? No. Randomly generated keys are never reused, so there's no way to get enough of a corpus of different texts to start applying known-plaintext techniques. Even if an attacker did, output feedback mode is generally considered resistant to this sort of cryptanalysis. > If such correlation is possible, then my proposal would be to have This wouldn't be the place for it. You'd be talking about modifying the RFC. Take that talk to the OpenPGP working group, please. :) From bernhard at intevation.de Thu Mar 10 17:17:04 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 10 Mar 2016 17:17:04 +0100 Subject: Proposal: config for weak, normal, strong algos Message-ID: <201603101717.12165.bernhard@intevation.de> Hi, attached a proposal to help dealing with environments where a crypto policy strongly prefers or rejects some algos. It is an idea of generalisation of what we (Intevation and g10code) may need for the https://wiki.gnupg.org/Gpg4vsnfd2015 contract. What do you think? AdTHANKSvance for your feedback, Bernhard **DRAFT** (ber20160310-1) Goal of the proposal: How to improve the configuration mechanism in GnuPG v>2.1 to enable admins and users to define and deal with less and more preferred sets of algorithms. == Why? to support different policies This is useful to assist users that want (or have) to follow a stronger policy towards a group of communication partners. One example is when dealing with documents that are classified as restricted by a government organization. Each federation or organization is likely to have their own variant of technical policies. In addition it will change over this. Therefore, the algorithms shall be configurable, so that the same product revision can work in several settings. == Stay inter-operable and usable There are a number OpenPGP and CMS installations with already existing asymmetric keys out there, so it desirable to stay interoperable as much as possible. Usually a user that has to use a stronger crypto policy with some users also wants to communicate with many others that do not have this requirement. In order for a crypto application to say usable, it has to support sending to both groups well. For a trained user it will be good enough if she sees a noticeable warning when trying to use something that is not strong. So GnuPG has to know which algorithms are considered strong and has to give this information to the frontends interacting with the user. == What needs to be configured All algorithms that are used cryptographically are subject of a crypto policy, especially: # Random numbers # Symmetric ciphers # Asymmetric ciphers # Digest algorithms (crypto hash functions) # Trust model # Key derivation function Not necessary for GnuPG v>2.1 to configure is the block chain mode CFB as the OpenPGP standard (RFC4880) only allow this one. == making a difference for reading, writing and creating The use of algorithms may be considered different when # an encrypted document is coming in. The software could decrypt, even if less desirable algorithms were used. # If a document is signed or encrypted, here a minimum strength of algorithms should be used, though still tolerable for interoperability with old installations. # When creating a key-pair for asymmetric crypto use in the future, a higher minimum strength must be used. == Proposed model: weak, normal and strong sets Right now GnuPG (v=2.1.11) already as two sets of algorithms: weak and normal. For example the option {{{--weak-digest}}} can be mark digest algorithms as //weak//. We propose to add options for {{{--strong-digest}}} and similar {{{weak}}} and {{{strong}}} options similar for all algorithms that need configuration. All non-mentioned algorithms are considered to be in //normal// set. === Bitlength Just like the [[https://gnupg.org/faq/whats-new-in-2.1.html#keylist|new format of keylistings in 2.1]] we propose to specify an greater or lesser bit length for the algorithms with a '+' or '-' where this is appropriate, e.g. {{{--strong-cipher-algo=rsa3072+}}} or {{{--weak-cipher-algo=rsa1024-}}}. == Disallowing use or force warnings GnuPG (v=2.1.11) can already allow and disallow the use of weak digest algorithms with the option {{{--allow-weak-digest-algos}}}. If any strong algorithms are configured by the options outlined above, we propose that they are prefered by default and that the application MUST issue a noticeable warning if a //normal// algorithm is to be used. These warnings can be avoided by not configuring //strong// algorithms. (Optional) GnuPG should also check that at least one working combination of strong algorithms is configured if one is configured at all. Algorithms can be disallowed by declaring them //weak// and a proposed {{{--disallow-weak-algos}}}. == Admin ability to restrict user choice Many crypto policies will allow the user to still send out encrypted documents with normal but not strong settings, if they do not desire the strong settings for this communications. However they will want to force that weak algorithms may not be used as all and the warning are mandatory. In addition the set of algorithms considered strong may be fixed. This there must be a configuration option that can only be changed by the administrator of the computer and cannot overridden by the user. We propose do use a file protected by the administration rights of the operating system, e.g. {{{/etc/gnupg/gpg.conf}}} or {{{/etc/gnupg/gpg-agent.conf}}}. That is read additionally to the users configuration file. An exclamation mark ("!") in front of the configuration line could be used to mark this configuration as fixed for the user. If there is no mark a user can override a system wide configuration entry with her own settings. == weak set defaults MD5 is an compiled in weak digest algorithm. == default strong set Default could be an empty strong set. Organizations could provide a set of configuration files to their admins that matches their policy. -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by 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 Mon Mar 14 14:28:09 2016 From: wk at gnupg.org (Werner Koch) Date: Mon, 14 Mar 2016 14:28:09 +0100 Subject: libgpg-error MinGW compile error In-Reply-To: (me@nerade.de's message of "Wed, 24 Feb 2016 11:42:19 +0100") References: Message-ID: <87wpp5nq8m.fsf@wheatstone.g10code.de> On Wed, 24 Feb 2016 11:42, me at nerade.de said: > Secondly my attempt to compile the libgpg-error on Windows 7 (64bit) > with MinGW fails with error in estream.c "EWOULDBLOCK undeclared" You can't compile libgpg-error _on_ Windows but you need to build it _for_ Windows; i.e. using a cross-compiler and in particualr by using ./autogen.sh --build-w32 Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dashohoxha at gmail.com Tue Mar 15 04:27:40 2016 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Tue, 15 Mar 2016 04:27:40 +0100 Subject: Automated testing of scripts that use GnuPG In-Reply-To: <56D952E0.9010807@suse.com> References: <56D952E0.9010807@suse.com> Message-ID: On Fri, Mar 4, 2016 at 10:18 AM, Andreas Stieger wrote: > Hi, > > On 03/04/2016 07:48 AM, Dashamir Hoxha wrote: > > [...] develop some wrapper shell scripts [...] > > But I am having problems because `gpg` has a "nasty" behaviour, it > > always pops up a window for getting the passphrase. Maybe this is a nice > > feature for the normal operation of the scripts, but for automatic > > testing it breaks the 'automatic' part. > > You may want to use a configuration that causes GnuPG to use different > pinentry flavour that works in your test rig: the tty one, or a mock > implementation of the simple pinentry protocol, possibly written in > Sharness itself if it can do IPC. > FYI, a mock implementation of the pinentry protocol could be a solution, like this one: - https://github.com/dashohoxha/egpg/blob/master/utils/autopin.sh But for automatic testing purposes I find that using keys without a passphrase is a better solution (no passphrase, no pinentry needed). Why did I not think about this earlier? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dashohoxha at gmail.com Tue Mar 15 21:59:09 2016 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Tue, 15 Mar 2016 21:59:09 +0100 Subject: How to silence gpg-agent? Message-ID: Hi, I am writting some wrapper shell scripts around gpg, trying to make it a bit more user-friendly for beginners: https://github.com/dashohoxha/egpg I have a problem that time after time I get output like this, which is somewhat unrelated to the operation performed and a bit confusing: ---------- gpg: checking the trustdb gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 1 signed: 3 trust: 0-, 0q, 0n, 0m, 0f, 1u gpg: depth: 1 valid: 3 signed: 0 trust: 2-, 0q, 0n, 0m, 1f, 0u gpg: next trustdb check due at 2017-01-05 ---------- I believe that it comes from gpg-agent. I have tried to silence it, using the option '--quiet', but it seems not to work. Any idea what else I can try? Thanks, Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From free10pro at gmail.com Wed Mar 16 00:35:21 2016 From: free10pro at gmail.com (Paul R. Ramer) Date: Tue, 15 Mar 2016 16:35:21 -0700 Subject: How to silence gpg-agent? In-Reply-To: References: Message-ID: <56E89C39.9030205@gmail.com> On 03/15/2016 01:59 PM, Dashamir Hoxha wrote: > I am writting some wrapper shell scripts around gpg, trying to make it a > bit more user-friendly for beginners: https://github.com/dashohoxha/egpg > I have a problem that time after time I get output like this, which is > somewhat unrelated to the operation performed and a bit confusing: > > ---------- > gpg: checking the trustdb > gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model > gpg: depth: 0 valid: 1 signed: 3 trust: 0-, 0q, 0n, 0m, 0f, 1u > gpg: depth: 1 valid: 3 signed: 0 trust: 2-, 0q, 0n, 0m, 1f, 0u > gpg: next trustdb check due at 2017-01-05 > ---------- > > I believe that it comes from gpg-agent. I have tried to silence it, using > the option '--quiet', but it seems not to work. Any idea what else I can > try? Please don't post to two lists for the same problem. I see that you posted to both gnupg-users and gnupg-devel. This will create two threads for the same problem instead of one. Would you please give us an excerpt of the part of the shell script that shows how you are calling gpg? Cheers, -Paul From gniibe at fsij.org Wed Mar 16 04:00:16 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 16 Mar 2016 12:00:16 +0900 Subject: DELETE_KEY for stub Message-ID: <56E8CC40.3080502@fsij.org> Hello, I saw posts to gnupg-users who want to move key from a card to another. Perhaps, it would not be common use cases, but it should be supported. Currently, gpg --delete-secret-key is not supported for stub. For gpg-agent, DELETE_KEY is not supported for stub. For the latter, I think that it should be supported. Are there any reasons to inhibit this? I mean, is it OK to apply following patch? diff --git a/agent/findkey.c b/agent/findkey.c index c5e7ae7..3cf8d0c 100644 --- a/agent/findkey.c +++ b/agent/findkey.c @@ -1311,7 +1311,7 @@ agent_delete_key (ctrl_t ctrl, const char *desc_text, break; case PRIVATE_KEY_SHADOWED: - err = gpg_error (GPG_ERR_KEY_ON_CARD); + err = remove_key_file (grip); break; default: -- From wk at gnupg.org Wed Mar 16 17:57:09 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 16 Mar 2016 17:57:09 +0100 Subject: DELETE_KEY for stub In-Reply-To: <56E8CC40.3080502@fsij.org> (NIIBE Yutaka's message of "Wed, 16 Mar 2016 12:00:16 +0900") References: <56E8CC40.3080502@fsij.org> Message-ID: <87egbamkd6.fsf@wheatstone.g10code.de> On Wed, 16 Mar 2016 04:00, gniibe at fsij.org said: > For the latter, I think that it should be supported. Are there any > reasons to inhibit this? I mean, is it OK to apply following patch? I think it makes sense to delete the shadow key on user requests (--delete-key). After all it is just a convenience thing and does not carry important information. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Thu Mar 17 00:24:04 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 17 Mar 2016 08:24:04 +0900 Subject: DELETE_KEY for stub In-Reply-To: <87egbamkd6.fsf@wheatstone.g10code.de> References: <56E8CC40.3080502@fsij.org> <87egbamkd6.fsf@wheatstone.g10code.de> Message-ID: <56E9EB14.8000204@fsij.org> On 03/17/2016 01:57 AM, Werner Koch wrote: > On Wed, 16 Mar 2016 04:00, gniibe at fsij.org said: > >> For the latter, I think that it should be supported. Are there any >> reasons to inhibit this? I mean, is it OK to apply following patch? > > I think it makes sense to delete the shadow key on user requests > (--delete-key). After all it is just a convenience thing and does not > carry important information. Yes. I think that it's just OK to remove it when asked (it's easily regenerated automatically given a user has the card). I'm going to push the change of gpg-agent as a first step, as I don't think it makes sense for gpg-agent to inhibit the removal. I'll support deleting the shadow key by --delete-key. Please note that this is another issue. In the context of moving secret key from a card to another, the issue is deleting the shadow key (the connection between key and the particular card), itself. A user wouldn't want to remove entire GPG key in this case. -- From dkg at fifthhorseman.net Thu Mar 17 01:03:12 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 16 Mar 2016 20:03:12 -0400 Subject: g13 with DM-Crypt and suspend/remove In-Reply-To: <87oab75v9w.fsf@wheatstone.g10code.de> References: <87oab75v9w.fsf@wheatstone.g10code.de> Message-ID: <87bn6ekm2n.fsf@alice.fifthhorseman.net> On Tue 2016-02-23 09:57:47 -0500, Werner Koch wrote: > Just in case you like the high risk of losing all your data and actually > want to play with the new g13 code, you also need a patch for dmsetup > which I attach. Ask here if you have any questions. Have you submitted this dmsetup patch upstream? It seems generally useful to me. --dkg From wk at gnupg.org Thu Mar 17 08:19:22 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 17 Mar 2016 08:19:22 +0100 Subject: g13 with DM-Crypt and suspend/remove In-Reply-To: <87bn6ekm2n.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 16 Mar 2016 20:03:12 -0400") References: <87oab75v9w.fsf@wheatstone.g10code.de> <87bn6ekm2n.fsf@alice.fifthhorseman.net> Message-ID: <87vb4llgg5.fsf@wheatstone.g10code.de> On Thu, 17 Mar 2016 01:03, dkg at fifthhorseman.net said: > Have you submitted this dmsetup patch upstream? It seems generally > useful to me. Yes I did: From: Werner Koch Subject: [dm-devel] [PATCH] dmsetup: improve message command To: dm-devel at redhat.com Date: Fri, 26 Feb 2016 12:42:33 +0100 but have not received any response. I need to follow up on it. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From joerg.krause at embedded.rocks Sun Mar 20 23:06:31 2016 From: joerg.krause at embedded.rocks (=?ISO-8859-1?Q?J=F6rg?= Krause) Date: Sun, 20 Mar 2016 23:06:31 +0100 Subject: libgpg-error: Replace syscfg Message-ID: <1458511591.1998.59.camel@embedded.rocks> Hi, the current mechanism to figure out platform specific properties when cross-compiling brings a lot of maintenance?burden to package management systems. For example Buildroot manages the build of a package and its dependencies in terms of other packages, available architecuteres, toolchains, etc. The current mechanism of running gen-posix-lock-obj on a remote target for unsupported architectures is not suitable for building libgpg-error with Buildroot.? Furthermore, we have to add a dependency of the architecture to the package libgpg-error to disallow building on non-supported platforms. The drawback is that many packages depends directly or indirectly on libgpg-error, so that this dependency has to be propageted recursively. AFAIK, libgpg-error has no limitations to not run on a target not specified on syscfg. I had a look on?gen-posix-lock-obj and I am quite sure the logic can be put into gpg-error.h itself. All necessary information are available at compile time. This way, there would be no need for syscfg and gen- posix-lock-obj anymore! I used a simplified test main to cross-compile for ARM with musl libc: #include #include #include typedef struct { ? long _vers; ? union { ????volatile char _priv[SIZEOF_PTHREAD_MUTEX_T]; ????long _x_align; ????long *_xp_align; ? } u; } gpgrt_lock_t; #define GPGRT_LOCK_DEFINE(name) \ ? static gpgrt_lock_t name??= { LOCK_ABI_VERSION, PTHREAD_MUTEX_INITIALIZER } GPGRT_LOCK_DEFINE (simple_lock); int main() { ? int i; ? gpgrt_lock_t *p; ? p = &simple_lock; ? for (i=0; i < SIZEOF_PTHREAD_MUTEX_T; i++) ????{ ??????if (i && !(i % 8)) ????????putchar ('\n'); ??????printf ("%u", p->u._priv[i]); ??????if (i < SIZEOF_PTHREAD_MUTEX_T - 1) ????????putchar (','); ????} ? putchar ('\n'); } I'm quite sure syscfg and?gen-posix-lock-obj can be replaced, but maybe I missed something important here. Best regards J?rg Krause From wk at gnupg.org Mon Mar 21 10:11:01 2016 From: wk at gnupg.org (Werner Koch) Date: Mon, 21 Mar 2016 10:11:01 +0100 Subject: libgpg-error: Replace syscfg In-Reply-To: <1458511591.1998.59.camel@embedded.rocks> (=?utf-8?Q?=22J?= =?utf-8?Q?=C3=B6rg?= Krause"'s message of "Sun, 20 Mar 2016 23:06:31 +0100") References: <1458511591.1998.59.camel@embedded.rocks> Message-ID: <877fgw6vru.fsf@wheatstone.g10code.de> On Sun, 20 Mar 2016 23:06, joerg.krause at embedded.rocks said: > The current mechanism of running gen-posix-lock-obj on a remote target > for unsupported architectures is not suitable for building libgpg-error > with Buildroot. I don't know what Buildroot is but in any case gen-posix-lock-obj is just an example and you can of course also come up with the required snippet by other means. It usuallay depends only on -lc and -lpthread. > I had a look on?gen-posix-lock-obj and I am quite sure the logic can be > put into gpg-error.h itself. All necessary information are available at This would make it a part of the ABI which we do not want. The whole point with syscfg is to guarantee a stable ABI of libgpg-error so that an internal change to libgpg-error does not introduce a long chain of required ABI changes to all software dependent on libgpg-error. So, this is a one time effort for a new platform which I think is justified. Recall that a new platform also requires updates config.{sub.guess} and more. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From joerg.krause at embedded.rocks Mon Mar 21 12:43:42 2016 From: joerg.krause at embedded.rocks (=?ISO-8859-1?Q?J=F6rg?= Krause) Date: Mon, 21 Mar 2016 12:43:42 +0100 Subject: libgpg-error: Replace syscfg In-Reply-To: <877fgw6vru.fsf@wheatstone.g10code.de> References: <1458511591.1998.59.camel@embedded.rocks> <877fgw6vru.fsf@wheatstone.g10code.de> Message-ID: <1458560622.13321.21.camel@embedded.rocks> On Mo, 2016-03-21 at 10:11 +0100, Werner Koch wrote: > On Sun, 20 Mar 2016 23:06, joerg.krause at embedded.rocks said: > > > > > The current mechanism of running gen-posix-lock-obj on a remote > > target > > for unsupported architectures is not suitable for building libgpg- > > error? > > with Buildroot. > I don't know what Buildroot is but in any case gen-posix-lock-obj is > just an example and you can of course also come up with the required > snippet by other means.??It usuallay depends only on -lc and > -lpthread. All the information?gen-posix-lock-obj provides are available at compile-time, so I do not see the necessity for a runtime tool to fetch the same information. > > > > I had a look on?gen-posix-lock-obj and I am quite sure the logic > > can be > > put into gpg-error.h itself. All necessary information are > > available at > This would make it a part of the ABI which we do not want. The current mechanism lets gen-posix-lock-obj generate a lock object definition which is copied right into gpg-error.h before compilation. It does not make any difference if the data are copied into gpg-error.h before compilation or generated by compilation. The result is the same. > The whole > point with syscfg is to guarantee a stable ABI of libgpg-error so > that > an internal change to libgpg-error does not introduce a long chain of > required ABI changes to all software dependent on libgpg-error. I understand! However, as I said, there is no difference in the end between using gen-posix-lock-obj/syscfg/mkheader generating the lock part of gpg-error.h and defining the lock object directly in gpg- error.h. Both produces the same compilation unit. > So, this is a one time effort for a new platform which I think is > justified.??Recall that a new platform also requires updates > config.{sub.guess} and more. Yes, but there are gazillions of possible triplets, which has to be added to libgpg-error before it can be compiled. Best regards J?rg Krause From bernhard at intevation.de Mon Mar 21 16:18:05 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 21 Mar 2016 16:18:05 +0100 Subject: Proposal: config for weak, normal, strong algos In-Reply-To: <201603101717.12165.bernhard@intevation.de> References: <201603101717.12165.bernhard@intevation.de> Message-ID: <201603211618.10148.bernhard@intevation.de> On Thursday 10 March 2016 at 17:17:04, Bernhard Reiter wrote: > attached a proposal to help dealing with environments > where a crypto policy strongly prefers or rejects some algos. > It is an idea of generalisation of what we (Intevation and g10code) > may need for the https://wiki.gnupg.org/Gpg4vsnfd2015 contract. > > What do you think? No feedback so far, but Werner told me, that he a) does not like wording "strong" because it somehow implies the algorithms in the "normal" group are less strong. As a generalisation we could coin this "restricted" group or "policy" group. b) prefers one option that defines a fixed set of algos for the "restricted" group, instead of too many configuration options that would allow to combine algos that do go well togethers. Maybe hardcoding is the way to go, so the "restricted" group could be defined by an option like "--vs-nfd" for what the German government things is in their "restricted" group. In addition I think: c) if we go with more configuration options and thus being more general, we could add an options to name the group like {{{--algo-policy-name=VS-NfD}}} . Best Regards, Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by 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 Mon Mar 21 16:33:34 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 21 Mar 2016 16:33:34 +0100 Subject: axolotl, OMEMO vs OpenPGP Message-ID: <201603211633.39220.bernhard@intevation.de> Hi Friends of GnuPG, right now I am thinking about the properties and use cases for OpenPGP compared to axolotl [1] and OMEMO [2]. The advertisment page for Conversation's OMEMO support [3] claims that it is superior to OpenPGP: | OMEMO not only gives you a better encryption features than OpenPGP and OTR | but is also much easier to setup. And I wonder in which situations this is true. OMEMO says it does the trick of being "forward secret" and offline capable. Is this even possible while being end-to-end, e.g. not trusting a service provider? If I am offline I could not create ephemeral session keys or does this depend on previously exchanged keys? Any thoughts? Does somebody has pointer to in depth analysis? Best, Bernhard [1] https://en.wikipedia.org/wiki/Axolotl_%28protocol%29 [2] https://en.wikipedia.org/wiki/OMEMO [3] https://conversations.im/omemo/ -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by 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 Mon Mar 21 17:03:36 2016 From: wk at gnupg.org (Werner Koch) Date: Mon, 21 Mar 2016 17:03:36 +0100 Subject: axolotl, OMEMO vs OpenPGP In-Reply-To: <201603211633.39220.bernhard@intevation.de> (Bernhard Reiter's message of "Mon, 21 Mar 2016 16:33:34 +0100") References: <201603211633.39220.bernhard@intevation.de> Message-ID: <87h9fz4y3r.fsf@wheatstone.g10code.de> On Mon, 21 Mar 2016 16:33, bernhard at intevation.de said: > Does somebody has pointer to in depth analysis? I have not looked at it but there is indeed an offline, or better store-and-forward, protocol which provides forward secrecy: Matthey D. Green and Ian Miers. Forward Secure Asynchronous Messaging from Puncturable Encryption. 2015 IEEE Symposium on Security and Privacy. Sorry, I do not have an URL handy. The major problem I see with this protocol is the huge key. Thus is can't be easily added to OpenPGP or CMS. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernhard at intevation.de Mon Mar 21 17:10:52 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 21 Mar 2016 17:10:52 +0100 Subject: axolotl, OMEMO vs OpenPGP In-Reply-To: <201603211633.39220.bernhard@intevation.de> References: <201603211633.39220.bernhard@intevation.de> Message-ID: <201603211710.58221.bernhard@intevation.de> On Monday 21 March 2016 at 16:33:34, Bernhard Reiter wrote: > OMEMO says it does the trick of being "forward secret" and > offline capable. Is this even possible while being end-to-end, > e.g. not trusting a service provider? > > If I am offline I could not create ephemeral session keys > or does this depend on previously exchanged keys? In https://github.com/Flowdalic/xeps/blob/master/xep-openpgp-im/xep-openpgp-im.xml Dominik, Vincent and Florian write

Unlike similar XEPs, e.g. OMEMO, this XEP does not provide Perfect Forward Secrecy (PFS), but as an advantage in return, allows users to read their archived conversations (respectively their encrypted data) later on. Of course, only as long as they still possess the according secret key. PFS and being able to decrypt archived messages are mutually exclusive, i.e. one can not have both. We therefore consider this XEP complementary to similar ones which also provide end-to-end encryption but with a different feature set.

-- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by 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 ben at adversary.org Tue Mar 22 19:36:17 2016 From: ben at adversary.org (Ben McGinnes) Date: Wed, 23 Mar 2016 05:36:17 +1100 Subject: axolotl, OMEMO vs OpenPGP In-Reply-To: <201603211633.39220.bernhard@intevation.de> References: <201603211633.39220.bernhard@intevation.de> Message-ID: <20160322183617.GA757@adversary.org> On Mon, Mar 21, 2016 at 04:33:34PM +0100, Bernhard Reiter wrote: > Hi Friends of GnuPG, > > right now I am thinking about the properties and use cases > for OpenPGP compared to axolotl [1] and OMEMO [2]. > > The advertisment page for Conversation's OMEMO support [3] > claims that it is superior to OpenPGP: > > | OMEMO not only gives you a better encryption features than OpenPGP > | and OTR but is also much easier to setup. I just had a quick look at that page and it looks like they're playing a little fast and loose with the truth. With the link to an (obsolete) XMPP Foundation document and reading through that as well; what they're actually saying is specifically within the context of past attempts to implement encryption for XMPP using OpenPGP. Apparently this was what some developers tried before developing OTR. Now specifically within the context of implementing OpenPGP compliant features with XMPP, the current claim is probably correct. What they decided not to mention was that this statement refers to that attempted implementation and not, for example, to GPG. Nor do they do anything else to discourage misinterpretation of the statements by anyone else. The only bit that's unclear is whether this is intentional ow whether they're just so wrapped up in the focus on solutions for XMPP that they haven't realised how their statements could be read. > And I wonder in which situations this is true. > OMEMO says it does the trick of being "forward secret" and > offline capable. Is this even possible while being end-to-end, > e.g. not trusting a service provider? The Confidant Mail project has already achieved something similar with GPG as the base for it (by rotating encryption subkeys). Though it sticks with the UID model rather than the device ID (and I wonder how that model would handle something like cloning a smartphone). > If I am offline I could not create ephemeral session keys > or does this depend on previously exchanged keys? There still needs to be some form of secure key exchange, either via previously established master keys or a real time exchange (with out of band confirmation). > Any thoughts? > Does somebody has pointer to in depth analysis? Personally I suspect this will turn out to be a bit like the OpenPGP statement; it will be true within a very specific context which sounds more impressive than the technical details will allow. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: not available URL: From dgouttegattat at incenp.org Wed Mar 23 09:35:46 2016 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Wed, 23 Mar 2016 09:35:46 +0100 Subject: [PATCH] scute: Remove prepended nul byte in signature data Message-ID: <1458722146-5471-1-git-send-email-dgouttegattat@incenp.org> * src/agent.c (pksign_parse_result): Check for nul byte prepended by the agent to the signature value. -- GPG Agent may prepend a nul byte in the signature value if the first byte of the signature has its most significant bit set, to prevent it from being interpreted as a sign bit (see the function agent_pksign_do, in GnuPG's agent/pksign.c file). The current sexp parser in Scute does not expect this extra nul byte, and will reject any signature containing it with a GPG_ERR_INV_LENGTH error. This patch checks for an initial nul byte in the signature data, and removes it. Signed-off-by: Damien Goutte-Gattat --- src/agent.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/src/agent.c b/src/agent.c index 7e968c0..ac5a30f 100644 --- a/src/agent.c +++ b/src/agent.c @@ -1025,6 +1025,13 @@ pksign_parse_result (const struct signature *sig, if (! n) return gpg_error (GPG_ERR_INV_SEXP); + /* Remove nul byte prepended by gpg-agent. */ + if (*s == 0) + { + n -= 1; + s += 1; + } + if (*len < (unsigned int) n) return gpg_error (GPG_ERR_INV_LENGTH); -- 2.7.3 From justus at g10code.com Wed Mar 23 11:26:03 2016 From: justus at g10code.com (Justus Winter) Date: Wed, 23 Mar 2016 11:26:03 +0100 Subject: [PATCH] scute: Remove prepended nul byte in signature data In-Reply-To: <1458722146-5471-1-git-send-email-dgouttegattat@incenp.org> References: <1458722146-5471-1-git-send-email-dgouttegattat@incenp.org> Message-ID: <20160323102603.2708.44691@thinkbox.jade-hamburg.de> Quoting Damien Goutte-Gattat (2016-03-23 09:35:46) > * src/agent.c (pksign_parse_result): Check for nul byte prepended > by the agent to the signature value. Merged, thanks! Justus From wk at gnupg.org Wed Mar 23 12:42:27 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 23 Mar 2016 12:42:27 +0100 Subject: [PATCH] scute: Remove prepended nul byte in signature data In-Reply-To: <20160323102603.2708.44691@thinkbox.jade-hamburg.de> (Justus Winter's message of "Wed, 23 Mar 2016 11:26:03 +0100") References: <1458722146-5471-1-git-send-email-dgouttegattat@incenp.org> <20160323102603.2708.44691@thinkbox.jade-hamburg.de> Message-ID: <871t71zaho.fsf@wheatstone.g10code.de> On Wed, 23 Mar 2016 11:26, justus at g10code.com said: > Merged, thanks! I have also committed a minor change for robustness: /* Remove nul byte prepended by gpg-agent. */ - if (*s == 0) + if (!*s && n > 1) { n -= 1; BTW, the Makefile in manual uses gmake extensions. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From chris at hippiehacker.org Wed Mar 23 16:16:00 2016 From: chris at hippiehacker.org (Chris McClimans) Date: Wed, 23 Mar 2016 10:16:00 -0500 Subject: libpam-poldi + OpenPGP_card documentation Message-ID: I am trying to use gpg smart cards to locally authenticate logging into my laptop (running arch). I'm using several yubikeys, and several smartcards that suppport OpenPGP_card standard but I've yet to see clearly how to configure it enough to get any logs created. My reading so far on poldi 0.4.1(-8 on arch): I've looked at the info files and readme's distributed with arch: # pacman -Ql poldi | grep -v /$ poldi /etc/logrotate.d/poldi poldi /etc/pam.d/system-auth-poldi poldi /etc/poldi/poldi.conf poldi /usr/bin/pam-test-poldi poldi /usr/bin/poldi-ctrl poldi /usr/lib/security/pam_poldi.so poldi /usr/share/info/poldi.info.gz poldi /usr/share/poldi/localdb/keys/README poldi /usr/share/poldi/localdb/users poldi /usr/share/poldi/poldi.conf >From a while back: https://www.schiessle.org/howto/poldi.php poldi-ctrl --register-card doesn't seem to work any more >From 2006: http://blogs.fsfe.org/greve/?p=64 Doesn't have enough info for me to replicate for systemd based console logins. >From 2012: http://walter.silvergeeks.com/rechner/howto/how-to-anmeldung-mit-smart-card-oder-usb-token-am-lokalen-linux-system Has some info, but it may be that I've lost some details in the google translation. pam-test-poldi is shipped with the arch package, and I've tried looking for poldi.log but it never seems to get created. From chris at hippiehacker.org Wed Mar 23 15:49:18 2016 From: chris at hippiehacker.org (Chris McClimans) Date: Wed, 23 Mar 2016 09:49:18 -0500 Subject: FSFE GPG Smartcard seems to fry when trying to use 4096 keysize Message-ID: While it's probably documented somewhere, I had issues tracking down definitive information. I received an FSFE Fellowship Smartcard and had the card working fine, then I thought I read that it supported a 4096 keysize... Apparrently that setting fries the card. 8( $ gpg --card-status gpg: selecting openpgp failed: Card error gpg: OpenPGP card not available: Card error That seems to happen even after reboots. How we got here: Card status just before trying to generate a new auth key with 4096 keysize: $ gpg --card-status Reader ...........: 058F:9540:X:0 Application ID ...: D276000124010200000500002C100000 Version ..........: 2.0 Manufacturer .....: ZeitControl Serial number ....: 00002C10 Name of cardholder: hippiehacker Language prefs ...: en Sex ..............: male URL of public key : [not set] Login data .......: hh Private DO 2 .....: [3488] hippiehacker CA fingerprint 1 .: C485 A6CD 7EC6 6E9E EC33 65F2 70F2 75E4 C32F 6CA5 Signature PIN ....: forced Key attributes ...: rsa2048 rsa2048 rsa2048 Max. PIN lengths .: 32 32 32 PIN retry counter : 3 0 3 Signature counter : 1 Signature key ....: 21C2 1F17 CEF9 5452 E321 BFC3 93DC A1AB 03E1 77D4 created ....: 2016-03-16 15:16:26 Encryption key....: 52D3 FFBA 76A1 36EF DC37 5503 9C33 2D18 4827 1D2D created ....: 2016-03-16 15:18:01 Authentication key: 2325 0B96 AD01 2CF8 EB8A 0E95 EE57 D2BF 7492 837D created ....: 2016-03-16 15:18:29 General key info..: sub rsa2048/03E177D4 2016-03-16 Chris McClimans (The Hippie Hacker) sec dsa1024/DCE709AE created: 2008-11-13 expires: never ssb elg2048/71729B86 created: 2008-11-13 expires: never ssb rsa2048/73B41336 created: 2011-07-23 expires: never ssb> rsa2048/03E177D4 created: 2016-03-16 expires: never card-no: 0005 00002C10 ssb> rsa2048/48271D2D created: 2016-03-16 expires: never card-no: 0005 00002C10 ssb> rsa2048/7492837D created: 2016-03-16 expires: never card-no: 0005 00002C10 The --edit-key with the changing of the keysize. $ gpg --edit-key DCE709AE gpg (GnuPG) 2.1.11; Copyright (C) 2016 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Secret key is available. sec dsa1024/DCE709AE created: 2008-11-13 expires: never usage: SC trust: ultimate validity: ultimate ssb elg2048/71729B86 created: 2008-11-13 expires: never usage: E ssb rsa2048/73B41336 created: 2011-07-23 expires: never usage: A ssb rsa2048/03E177D4 created: 2016-03-16 expires: never usage: S card-no: 0005 00002C10 ssb rsa2048/48271D2D created: 2016-03-16 expires: never usage: E card-no: 0005 00002C10 ssb rsa2048/7492837D created: 2016-03-16 expires: never usage: A card-no: 0005 00002C10 [ultimate] (1). Chris McClimans (The Hippie Hacker) gpg> addcardkey Signature key ....: 21C2 1F17 CEF9 5452 E321 BFC3 93DC A1AB 03E1 77D4 Encryption key....: 52D3 FFBA 76A1 36EF DC37 5503 9C33 2D18 4827 1D2D Authentication key: 2325 0B96 AD01 2CF8 EB8A 0E95 EE57 D2BF 7492 837D Please select the type of key to generate: (1) Signature key (2) Encryption key (3) Authentication key Your selection? 3 gpg: WARNING: such a key has already been stored on the card! Replace existing key? (y/N) y What keysize do you want for the Authentication key? (2048) 4096 The card will now be re-configured to generate a key of 4096 bits Note: There is no guarantee that the card supports the requested size. If the key generation does not succeed, please check the documentation of your card to see what sizes are allowed. Please specify how long the key should be valid. 0 = key does not expire = key expires in n days w = key expires in n weeks m = key expires in n months y = key expires in n years Key is valid for? (0) Key does not expire at all Is this correct? (y/N) y Really create? (y/N) y gpg: key generation failed: Card error gpg: Key generation failed: Card error gpg: error setting forced signature PIN flag: Input/output error gpg> quit From wk at gnupg.org Wed Mar 23 17:49:12 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 23 Mar 2016 17:49:12 +0100 Subject: FSFE GPG Smartcard seems to fry when trying to use 4096 keysize In-Reply-To: (Chris McClimans's message of "Wed, 23 Mar 2016 09:49:18 -0500") References: Message-ID: <87lh59w35j.fsf@wheatstone.g10code.de> On Wed, 23 Mar 2016 15:49, chris at hippiehacker.org said: > Reader ...........: 058F:9540:X:0 That Alcor Micro reader _might_ be the cause for the problem with 4k keys. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From peter at lekensteyn.nl Wed Mar 23 17:47:03 2016 From: peter at lekensteyn.nl (Peter Wu) Date: Wed, 23 Mar 2016 17:47:03 +0100 Subject: [PATCH] Add function gpgrt_annotate_leaked_object. Message-ID: <1458751623-23763-1-git-send-email-peter@lekensteyn.nl> * src/gpg-error.h.in: add gpgrt_annotate_leaked_object to support marking memory as non-leaked. -- This annotation can be used to mark objects as explicitly leaked such that it can be ignored in tools like LeakSanitizer. The GPGRT_HAVE_LEAK_SANITIZER macro is explicitly not undefined to support -fsanitize=leak, a user or configure script could then decide to add this macro when just -fsanitize=leak is given. Signed-off-by: Peter Wu --- Hi, This is a follow-up of an earlier version that was proposed last year for libgcrypt (https://lists.gnupg.org/pipermail/gcrypt-devel/2015-July/003471.html). Previously a macro was used, this version proposes an inline function for type checking and keeps the door open for supporting other tools in the future (Valgrind's memcheck?). This patch was tested on libgcrypt by applying the same change to mputil.c as before. Other references: - GCC post showing that -fsanitize=leak only affects the linker options: https://gcc.gnu.org/ml/gcc-patches/2013-11/msg01874.html - GCC documentation on __SANITIZE_ADDRESS__: https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html - Clang documentation on __has_feature(address_sanitizer): http://clang.llvm.org/docs/AddressSanitizer.html#id10 - Earlier question on detecting LSan (no good solution unfortunately): http://stackoverflow.com/q/31273016 Kind regards, Peter --- src/gpg-error.h.in | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/src/gpg-error.h.in b/src/gpg-error.h.in index b32b4c4..d031925 100644 --- a/src/gpg-error.h.in +++ b/src/gpg-error.h.in @@ -246,10 +246,36 @@ typedef unsigned int gpg_error_t; # define GPGRT_HAVE_PRAGMA_GCC_PUSH 1 #endif +/* Detect LeakSanitizer (LSan) support for GCC and Clang based on + whether AddressSanitizer (ASAN) is enabled via -fsanitize=address). + Note that -fsanitize=leak just affect the linker options which cannot + be detected here. In that case you have to define the + GPGRT_HAVE_LEAK_SANITIZER macro manually. */ +#ifdef __SANITIZE_ADDRESS__ +# define GPGRT_HAVE_LEAK_SANITIZER +#elif defined(__has_feature) +# if __has_feature(address_sanitizer) +# define GPGRT_HAVE_LEAK_SANITIZER +# endif +#endif + /* The new name for the inline macro. */ #define GPGRT_INLINE GPG_ERR_INLINE +#ifdef GPGRT_HAVE_LEAK_SANITIZER +# include +#endif + +/* Mark heap objects as non-leaked memory. */ +static GPGRT_INLINE void +gpgrt_annotate_leaked_object(const void *p) +{ +#ifdef GPGRT_HAVE_LEAK_SANITIZER + __lsan_ignore_object(p); +#endif +} + /* Initialization function. */ -- 2.7.4 From wk at gnupg.org Wed Mar 23 19:35:42 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 23 Mar 2016 19:35:42 +0100 Subject: [PATCH] Add function gpgrt_annotate_leaked_object. In-Reply-To: <1458751623-23763-1-git-send-email-peter@lekensteyn.nl> (Peter Wu's message of "Wed, 23 Mar 2016 17:47:03 +0100") References: <1458751623-23763-1-git-send-email-peter@lekensteyn.nl> Message-ID: <87bn65vy81.fsf@wheatstone.g10code.de> On Wed, 23 Mar 2016 17:47, peter at lekensteyn.nl said: > * src/gpg-error.h.in: add gpgrt_annotate_leaked_object to support > marking memory as non-leaked. Cool. > +#ifdef __SANITIZE_ADDRESS__ > +# define GPGRT_HAVE_LEAK_SANITIZER > +#elif defined(__has_feature) > +# if __has_feature(address_sanitizer) > +# define GPGRT_HAVE_LEAK_SANITIZER > +# endif > +#endif Can you change this to explicitly detect gcc or clang? I fear that other compilers may use __SANITIZE_ADDRESS__ too. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dgouttegattat at incenp.org Wed Mar 23 23:09:45 2016 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Wed, 23 Mar 2016 23:09:45 +0100 Subject: [PATCH] scute: Update required libgpg-error version. Message-ID: <1458770985-8239-1-git-send-email-dgouttegattat@incenp.org> * configure.ac: Set required version of libgpg-error to 1.14. * README: Update documentation accordingly. * doc/manual/scute.texi: Likewise. * doc/website/download.xhtml: Likewise. -- Since commit 097a29f, Scute needs the gpgrt_*printf functions, which were introduced in libgpg-error-1.14. Signed-off-by: Damien Goutte-Gattat --- README | 2 +- configure.ac | 2 +- doc/manual/scute.texi | 2 +- doc/website/download.xhtml | 4 ++-- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/README b/README index aab45b7..5483062 100644 --- a/README +++ b/README @@ -34,7 +34,7 @@ Prerequisites ============= For the compilation: -* libgpg-error 1.4 +* libgpg-error 1.14 * libassuan 2.0.0 At runtime: diff --git a/configure.ac b/configure.ac index 598f437..1e4137d 100644 --- a/configure.ac +++ b/configure.ac @@ -73,7 +73,7 @@ LIBSCUTE_LT_REVISION=2 VERSION_MAJOR=1 VERSION_MINOR=0 -NEED_GPG_ERROR_VERSION=1.4 +NEED_GPG_ERROR_VERSION=1.14 NEED_LIBASSUAN_VERSION=2.0.0 NEED_GPGSM_VERSION=1.9.6 # Some status variables to give feedback at the end of a configure run. diff --git a/doc/manual/scute.texi b/doc/manual/scute.texi index 42078a8..35e0af2 100644 --- a/doc/manual/scute.texi +++ b/doc/manual/scute.texi @@ -241,7 +241,7 @@ following packages at build time: @table @code @item libgpg-error Scute uses the GnuPG 2.0 framework for error handling, so it depends on -the GPG error library. The minimum version required is 1.4. +the GPG error library. The minimum version required is 1.14. @item libassuan Scute uses the GnuPG 2.0 framework for communication with the GPG Agent, diff --git a/doc/website/download.xhtml b/doc/website/download.xhtml index 311d41c..457b5b9 100644 --- a/doc/website/download.xhtml +++ b/doc/website/download.xhtml @@ -145,9 +145,9 @@ Compile-time dependencies of Scute PackageMin. Version libgpg-error0.7 + href="http://www.gnupg.org/related_software/libgpg-error/">libgpg-error1.14 libassuan0.6.10 + href="http://www.gnupg.org/related_software/libassuan/">libassuan2.0.0

Scute also requires the following packages to run: -- 2.7.3 From peter at lekensteyn.nl Wed Mar 23 23:23:06 2016 From: peter at lekensteyn.nl (Peter Wu) Date: Wed, 23 Mar 2016 23:23:06 +0100 Subject: [PATCH v2] Add function gpgrt_annotate_leaked_object. In-Reply-To: <87bn65vy81.fsf@wheatstone.g10code.de> References: <87bn65vy81.fsf@wheatstone.g10code.de> Message-ID: <1458771786-15028-1-git-send-email-peter@lekensteyn.nl> * src/gpg-error.h.in: add gpgrt_annotate_leaked_object to support marking memory as non-leaked for Clang and GCC. -- This annotation can be used to mark objects as explicitly leaked such that it can be ignored in tools like LeakSanitizer. The GPGRT_HAVE_LEAK_SANITIZER macro is explicitly not undefined to support -fsanitize=leak, a user or configure script could then decide to add this macro when just -fsanitize=leak is given. Signed-off-by: Peter Wu --- Hi, I doubt that other compilers set __SANITIZE_ADDRESS__, but have added the __GNUC__ guard just to be sure. (This patch is tested with both GCC 5.3 and Clang 3.7.1 against mpitests from libgcrypt with -fsanitize=address.) Kind regards, Peter --- src/gpg-error.h.in | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/src/gpg-error.h.in b/src/gpg-error.h.in index b32b4c4..5138d0e 100644 --- a/src/gpg-error.h.in +++ b/src/gpg-error.h.in @@ -246,10 +246,36 @@ typedef unsigned int gpg_error_t; # define GPGRT_HAVE_PRAGMA_GCC_PUSH 1 #endif +/* Detect LeakSanitizer (LSan) support for GCC and Clang based on + whether AddressSanitizer (ASAN) is enabled via -fsanitize=address). + Note that -fsanitize=leak just affect the linker options which cannot + be detected here. In that case you have to define the + GPGRT_HAVE_LEAK_SANITIZER macro manually. */ +#if defined (__GNUC__) && defined( __SANITIZE_ADDRESS__) +# define GPGRT_HAVE_LEAK_SANITIZER +#elif defined(__has_feature) +# if __has_feature(address_sanitizer) +# define GPGRT_HAVE_LEAK_SANITIZER +# endif +#endif + /* The new name for the inline macro. */ #define GPGRT_INLINE GPG_ERR_INLINE +#ifdef GPGRT_HAVE_LEAK_SANITIZER +# include +#endif + +/* Mark heap objects as non-leaked memory. */ +static GPGRT_INLINE void +gpgrt_annotate_leaked_object(const void *p) +{ +#ifdef GPGRT_HAVE_LEAK_SANITIZER + __lsan_ignore_object(p); +#endif +} + /* Initialization function. */ -- 2.7.4 From wk at gnupg.org Thu Mar 24 10:19:58 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 24 Mar 2016 10:19:58 +0100 Subject: [PATCH v2] Add function gpgrt_annotate_leaked_object. In-Reply-To: <1458771786-15028-1-git-send-email-peter@lekensteyn.nl> (Peter Wu's message of "Wed, 23 Mar 2016 23:23:06 +0100") References: <87bn65vy81.fsf@wheatstone.g10code.de> <1458771786-15028-1-git-send-email-peter@lekensteyn.nl> Message-ID: <87fuvguta9.fsf@wheatstone.g10code.de> On Wed, 23 Mar 2016 23:23, peter at lekensteyn.nl said: > I doubt that other compilers set __SANITIZE_ADDRESS__, but have added > the __GNUC__ guard just to be sure. That was my idea. I slightly chnaged it to but the __GNUC__ guard around the entire block and I also added a void marker for P: static GPGRT_INLINE void gpgrt_annotate_leaked_object (const void *p) { #ifdef GPGRT_HAVE_LEAK_SANITIZER __lsan_ignore_object(p); #else (void)p; #endif } commit 52c3606. Thanks, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Mar 24 10:23:51 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 24 Mar 2016 10:23:51 +0100 Subject: [PATCH] scute: Update required libgpg-error version. In-Reply-To: <1458770985-8239-1-git-send-email-dgouttegattat@incenp.org> (Damien Goutte-Gattat's message of "Wed, 23 Mar 2016 23:09:45 +0100") References: <1458770985-8239-1-git-send-email-dgouttegattat@incenp.org> Message-ID: <87bn64ut3s.fsf@wheatstone.g10code.de> > Since commit 097a29f, Scute needs the gpgrt_*printf functions, > which were introduced in libgpg-error-1.14. Pushed. Thanks. Salam-Shalom, Werner ps. Please do not use scute: foo bar baz but [scute] foo bar baz as the subject. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From guilhem at fripost.org Thu Mar 24 11:26:19 2016 From: guilhem at fripost.org (Guilhem Moulin) Date: Thu, 24 Mar 2016 11:26:19 +0100 Subject: [PATCH] Fix subkey curve names in --with-colons' output. In-Reply-To: <1454434791-31608-1-git-send-email-guilhem@fripost.org> References: <1454434791-31608-1-git-send-email-guilhem@fripost.org> Message-ID: <20160324102619.GA11198@localhost.localdomain> On Tue, 02 Feb 2016 at 18:39:51 +0100, Guilhem Moulin wrote: > `gpg --with-colons --list-keys` incorrectly shows the master key's curve > name (or the empty string for non EC master keys) in the 17th field of > "sub" records. Looks like this didn't make its way into master. Since the patch fixes what is obviously a typo I guess it simply remained unnoticed. -- Guilhem. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From bernhard at intevation.de Thu Mar 24 21:18:18 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 24 Mar 2016 21:18:18 +0100 Subject: Proposal: config for weak, normal, strong algos In-Reply-To: <201603211618.10148.bernhard@intevation.de> References: <201603101717.12165.bernhard@intevation.de> <201603211618.10148.bernhard@intevation.de> Message-ID: <8637302.o0aYqfdjuc@kymo.gruen> Am Montag, 21. M?rz 2016, 16:18:05 schrieb Bernhard Reiter: > On Thursday 10 March 2016 at 17:17:04, Bernhard Reiter wrote: > > attached a proposal to help dealing with environments > > where a crypto policy strongly prefers or rejects some algos. > > It is an idea of generalisation of what we (Intevation and g10code) > > may need for the https://wiki.gnupg.org/Gpg4vsnfd2015 contract. d) for CMS we may need an option to select which of the CAs are allowed for being conform to the policy. I think the option should allow for several root or intermedia CAs as there may be root CAs that issue intermediate CAs that are not conforming to policy while other are. -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From ineiev at gnu.org Fri Mar 25 08:38:17 2016 From: ineiev at gnu.org (Ineiev) Date: Fri, 25 Mar 2016 03:38:17 -0400 Subject: [STABLE-BRANCH-1-4 PATCH] gpg: Using ngettext Message-ID: <20160325073816.GC10432@gnu.org> Hello, The attached patch ports 437965e5622 from 2.1 to 1.4. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Use-ngettext-for-some-strings.patch Type: text/x-diff Size: 12178 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From wk at gnupg.org Fri Mar 25 12:24:48 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 25 Mar 2016 12:24:48 +0100 Subject: [admin] Mail problems yesterday Message-ID: <87mvpmre9r.fsf@wheatstone.g10code.de> Hi! There was a small problem with the mailing list server yesterday [1]. In case your MTA is sending or receiving via an IPv6 address you may have missed some mails or posted mails may have get lost. If they don't show up today, please resent your mail or check the mail archives. Sorry for that. Salam-Shalom, Werner [1] I added a v6 address for gnutls.org to the server but forgot to explicitly set the v6 address to be used by Exim. Thus mails were wrongly sent from the gnutls.org v6 address which does not match lists.gnupg.org. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 bytes Desc: not available URL: From ben at adversary.org Fri Mar 25 18:38:37 2016 From: ben at adversary.org (Ben McGinnes) Date: Sat, 26 Mar 2016 04:38:37 +1100 Subject: GPGME XML schemas Message-ID: <20160325173837.GF2963@adversary.org> Hello, For those only sporadically reading gnupg-users and who may not have seen this, there are XML schemas in all four major XML schema formats for the GPGME keylist XML output on git.gnupg.org in the GPGME repo and the ben/xml branch. They were generated from the XML output produced by gpgme-tool. If I recall correctly the .rnc and the .dtd were generated from the .rng rather than the XML itself. I can also generate documentation from the .xsd file and I'll add the results of that a bit later. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: not available URL: From ineiev at gnu.org Sat Mar 26 10:43:38 2016 From: ineiev at gnu.org (Ineiev) Date: Sat, 26 Mar 2016 05:43:38 -0400 Subject: [GPA] option->description in confdialog.c Message-ID: <20160326094338.GA21716@gnu.org> Hello, I was testing i18n in GPA and noticed that some group labels are truncated; I cheched confdialog.c and found out that there is a 80-character limit for them: ... { if (option->flags & GPGME_CONF_GROUP) { char name[80]; ... Now, if we use Cyrillics it's only 40 letters, which tends to be insufficient for Slavic languages; I'd suggest allocating memory dynamically. Then, I saw that commas in the labels are shown as '%2c', in other words, the descriptions should be unescaped (this also applies to other pieces of confdialog.c). (I used current GPGME HEAD.) At last, there is a bug in the percent_unescape function itself: the resulting string is not closed by '\0' in its end, and when the unescaping is not trivial, the the string shows a duplicate tail. Thank you! -------------- next part -------------- A non-text attachment was scrubbed... Name: gpa-description-and-unescape.diff Type: text/x-diff Size: 3282 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From joerg.krause at embedded.rocks Mon Mar 28 11:13:35 2016 From: joerg.krause at embedded.rocks (=?UTF-8?q?J=C3=B6rg=20Krause?=) Date: Mon, 28 Mar 2016 11:13:35 +0200 Subject: [PATCH] [RFC] Define lock-obj in gpg-error.h Message-ID: <1459156415-18423-1-git-send-email-joerg.krause@embedded.rocks> The current mechanism for cross-compiling libgpg-error uses a cross-compiled gen-posix-lock-obj on the target to create a lock-obj file which has to be placed in the syscfg directory afterwards. Depending on the toolchain triplet name the corresponding lock-obj file is used to in the configuration step by the mkheader tool to insert the lock-obj file into gpg-error.h before compilation. This mechanism has some drawbacks: 1) It relies on the toolchains triplet. The toolchain triplet has to match a triplet in syscfg otherwise libgpg-error cannot be build. This means that using toolchains like armv6-rpi-linux-gnueabi, arm-none-linux-gnueabi, aarch64-linux-gnu, or arm-buildroot-linux-uclibcgnueabihf are not supported by default. 2) A toolchains triplet does not tell us about the builtin features. Consider a uClibc based toolchain named arm-unknown-linux-gnueabi was configured without thread support. Using the lock-obj file from syscfg will produce a wrong threads based lock-obj instead of a dummy lock-obj. 3) Cross-compiling gen-posix-lock-obj and run it on the target to output a lock-obj file is an unnecessary step and can be easily avoided. The first issue might be bypassed by adding every possible triplet to syscfg, but might up end in having a vast number of triplets. However, the second issue cannot be avoided when using syscfg, but can be with this patch. Cross-compiling gen-posix-lock-obj, running it on the target to output a lock-obj defined at compile-time, copying this lock-obj file to syscfg and have mkheader insert this information into gpg-error.h before compilation does the same as defining the lock-obj in gpg-error.h directly. The compilation units and so the build binaries are totally equal. This patch was tested with three targets: 1) ARM Cortex A9 with musl based toolchain from Buildroot 2) AARCH64 (little endian) with glibc based toolchain from Linaro 3) i686 with glibc based toolchain from Sourcery CodeBench for the x86/x86_64 The following symlinks were created to allow building with the unsupported toolchain triples: 1) arm-buildroot-linux-musleabihf -> arm-unknown-linux-gnuabihf 2) aarch64-linux-gnu -> aarch64-unknown-linux-gnu 3) no symlink required All three tests build exactly the same binary with and without patch applied, e.g ..: diff libgpg-error/aarch64/orig/libgpg-error.so.0.17.0 libgpg-error/aarch64/patched/libgpg-error.so.0.17.0 .. does not output any difference. Note that the patch was only tested for Linux targets, so further tests for Windows and other Unixes may be required. Signed-off-by: J?rg Krause --- src/gpg-error.h.in | 63 +++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 62 insertions(+), 1 deletion(-) diff --git a/src/gpg-error.h.in b/src/gpg-error.h.in index f0043f3..46958a0 100644 --- a/src/gpg-error.h.in +++ b/src/gpg-error.h.in @@ -22,10 +22,24 @@ #ifndef GPG_ERROR_H #define GPG_ERROR_H 1 +#if HAVE_CONFIG_H +#include +#endif + #include #include #include +#ifdef USE_POSIX_THREADS +#include +#endif + +#ifdef HAVE_W32_SYSTEM +#include "w32-lock-obj.h" +#else +#include "posix-lock-obj.h" +#endif + /* The version string of this header. */ #define GPG_ERROR_VERSION @version@ #define GPGRT_VERSION @version@ @@ -429,7 +443,54 @@ gpg_error_from_syserror (void) /* Lock functions. */ - at include:lock-obj@ +/* Special requirements for certain platforms. */ +#if defined(__sun) && !defined (__LP64__) && !defined(_LP64) +/* Solaris on 32-bit architecture. */ +# define USE_DOUBLE_FOR_ALIGNMENT 1 +#else +# define USE_DOUBLE_FOR_ALIGNMENT 0 +#endif +#if defined(__hppa__) +# define USE_LONG_DOUBLE_FOR_ALIGNMENT 1 +#else +# define USE_LONG_DOUBLE_FOR_ALIGNMENT 0 +#endif + +#ifdef USE_POSIX_THREADS + +/* Check that configure did its job. */ +#if SIZEOF_PTHREAD_MUTEX_T < 4 +# error sizeof pthread_mutex_t is not known. +#endif + +typedef struct +{ + long _vers; + union { + volatile char _priv[SIZEOF_PTHREAD_MUTEX_T]; +# if USE_DOUBLE_FOR_ALIGNMENT + double _xd_align; +# elif USE_LONG_DOUBLE_FOR_ALIGNMENT + long double _xld_align; +# endif + long _x_align; + long *_xp_align; + } u; +} gpgrt_lock_t; + +#define GPGRT_LOCK_INITIALIZER { LOCK_ABI_VERSION, PTHREAD_MUTEX_INITIALIZER } + +#else /* USE_POSIX_THREADS */ + +/* Dummy object - no locking available. */ +typedef struct +{ + long _vers; +} gpgrt_lock_t; + +#define GPGRT_LOCK_INITIALIZER { LOCK_ABI_VERSION } + +#endif /* USE_POSIX_THREADS */ #define GPGRT_LOCK_DEFINE(name) \ static gpgrt_lock_t name = GPGRT_LOCK_INITIALIZER -- 2.7.4 From wk at gnupg.org Tue Mar 29 12:22:09 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 29 Mar 2016 12:22:09 +0200 Subject: libgpg-error: Replace syscfg In-Reply-To: <1458560622.13321.21.camel@embedded.rocks> (=?utf-8?Q?=22J?= =?utf-8?Q?=C3=B6rg?= Krause"'s message of "Mon, 21 Mar 2016 12:43:42 +0100") References: <1458511591.1998.59.camel@embedded.rocks> <877fgw6vru.fsf@wheatstone.g10code.de> <1458560622.13321.21.camel@embedded.rocks> Message-ID: <87mvphmvn2.fsf@wheatstone.g10code.de> On Mon, 21 Mar 2016 12:43, joerg.krause at embedded.rocks said: > All the information?gen-posix-lock-obj provides are available at > compile-time, so I do not see the necessity for a runtime tool to fetch It is a compile time tool and not a runtime tool >> an internal change to libgpg-error does not introduce a long chain of >> required ABI changes to all software dependent on libgpg-error. > > I understand! However, as I said, there is no difference in the end > between using gen-posix-lock-obj/syscfg/mkheader generating the lock > part of gpg-error.h and defining the lock object directly in gpg- > error.h. Both produces the same compilation unit. That is true for the current implementaion. However, this defines a specific ABI which independent of the actual implementation. Thus we can add any time change the internal implementation without affecting the ABI. > Yes, but there are gazillions of possible triplets, which has to be Nope. config.sub canonicalizes the triplet. See "Getting the Canonical System Type" in the autoconf manual. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Mar 29 12:31:20 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 29 Mar 2016 12:31:20 +0200 Subject: [PATCH] [RFC] Define lock-obj in gpg-error.h In-Reply-To: <1459156415-18423-1-git-send-email-joerg.krause@embedded.rocks> (=?utf-8?Q?=22J=C3=B6rg?= Krause"'s message of "Mon, 28 Mar 2016 11:13:35 +0200") References: <1459156415-18423-1-git-send-email-joerg.krause@embedded.rocks> Message-ID: <87io05mv7r.fsf@wheatstone.g10code.de> On Mon, 28 Mar 2016 11:13, joerg.krause at embedded.rocks said: > 1) It relies on the toolchains triplet. The toolchain triplet has to match a Right. You need to use a recent config.sub to canonicalize the triplet. For certain host values it is also possible to use the alias list in mkheader.c > 2) A toolchains triplet does not tell us about the builtin > features. Consider a uClibc based toolchain named > arm-unknown-linux-gnueabi was configured without thread support. Using Thread support is part of the ABI. > lock-obj instead of a dummy lock-obj. 3) Cross-compiling > gen-posix-lock-obj and run it on the target to output a lock-obj file > is an unnecessary step and can be easily avoided. You are free to come up with the info by other means. > lock-obj defined at compile-time, copying this lock-obj file to syscfg and have > mkheader insert this information into gpg-error.h before compilation does the > same as defining the lock-obj in gpg-error.h directly. The compilation units See my reply to your other mail. > src/gpg-error.h.in | 63 > +#if HAVE_CONFIG_H > +#include > +#endif You MUST NOT put a config.h into a public header. > +# define USE_DOUBLE_FOR_ALIGNMENT 1 This macro name is not in libgpg-error's name space. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dgouttegattat at incenp.org Tue Mar 29 16:44:36 2016 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Tue, 29 Mar 2016 16:44:36 +0200 Subject: [PATCH 0/3] scute: Implement C_GenerateRandom function. Message-ID: <1459262679-16490-1-git-send-email-dgouttegattat@incenp.org> Hi GnuPG developers, The following set of patches for Scute implements the C_GenerateRandom function from PKCS#11. Mozilla's NSS library uses that function to provide 32 bytes bytes of entropy to its own PRNG, when the token is first inserted. Damien Goutte-Gattat (3): Implement C_GenerateRandom. Check whether the card has a RNG. Add test for C_GenerateRandom. src/agent.c | 28 +++++++++++++ src/agent.h | 5 +++ src/p11-generaterandom.c | 28 ++++++++++--- src/p11-gettokeninfo.c | 7 +++- src/slots.c | 9 ++++ src/slots.h | 3 ++ tests/Makefile.am | 2 +- tests/t-generaterandom.c | 105 +++++++++++++++++++++++++++++++++++++++++++++++ 8 files changed, 179 insertions(+), 8 deletions(-) create mode 100644 tests/t-generaterandom.c -- 2.7.4 From dgouttegattat at incenp.org Tue Mar 29 16:44:38 2016 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Tue, 29 Mar 2016 16:44:38 +0200 Subject: [PATCH 2/3] Check whether the card has a RNG. In-Reply-To: <1459262679-16490-1-git-send-email-dgouttegattat@incenp.org> References: <1459262679-16490-1-git-send-email-dgouttegattat@incenp.org> Message-ID: <1459262679-16490-3-git-send-email-dgouttegattat@incenp.org> * src/agent.c (learn_status_cb): Learn from the agent whether the card supports GET CHALLENGE. * src/agent.h (struct agent_card_info_s): New member rng_available. * src/p11-gettokeninfo (C_GetTokenInfo): Set CKF_RNG flag. * src/slots.c (slot_token_has_rng): New function. * src/slots.h (slot_token_has_rng): New prototype. -- Now that C_GenerateRandom is implemented, we can inform the client application that a RNG is available on the token. But support for the GET CHALLENGE operation does not seem to be mandatory as per the OpenPGP Card specification, so we should first make sure that the inserted token does support it. Signed-off-by: Damien Goutte-Gattat --- src/agent.c | 6 ++++++ src/agent.h | 2 ++ src/p11-gettokeninfo.c | 7 +++++-- src/slots.c | 9 +++++++++ src/slots.h | 3 +++ 5 files changed, 25 insertions(+), 2 deletions(-) diff --git a/src/agent.c b/src/agent.c index 4306f93..9a75bf8 100644 --- a/src/agent.c +++ b/src/agent.c @@ -846,6 +846,12 @@ learn_status_cb (void *opaque, const char *line) } } } + else if (keywordlen == 6 && !memcmp (keyword, "EXTCAP", keywordlen)) + { + /* FIXME: Should we parse the line properly instead of assuming + that the gc capability will always be at the beginning? */ + sscanf (line, "gc=%d", &(parm->rng_available)); + } return 0; } diff --git a/src/agent.h b/src/agent.h index 6f3f6df..0d6bb30 100644 --- a/src/agent.h +++ b/src/agent.h @@ -73,6 +73,8 @@ struct agent_card_info_s char grip1[41]; char grip2[41]; char grip3[41]; + int rng_available; /* True if the GET CHALLENGE operation + is supported. */ }; diff --git a/src/p11-gettokeninfo.c b/src/p11-gettokeninfo.c index 88d77be..c0a2417 100644 --- a/src/p11-gettokeninfo.c +++ b/src/p11-gettokeninfo.c @@ -72,8 +72,11 @@ CK_DEFINE_FUNCTION(CK_RV, C_GetTokenInfo) pInfo->flags = CKF_TOKEN_INITIALIZED | CKF_PROTECTED_AUTHENTICATION_PATH | CKF_WRITE_PROTECTED | CKF_USER_PIN_INITIALIZED; - /* FIXME: Support this later: CKF_RNG. - FIXME: CKF_USER_PIN_INITIALIZED only if PIN is not default pin? + + if (slot_token_has_rng (slot)) + pInfo->flags |= CKF_RNG; + + /* FIXME: CKF_USER_PIN_INITIALIZED only if PIN is not default pin? FIXME: CKF_LOGIN_REQUIRED needed? We could implement login via the "SCD CHECKPIN" command. I am not sure how this mixes with CKF_PROTECTED_AUTHENTICATION_PATH. diff --git a/src/slots.c b/src/slots.c index 136d64e..810be0b 100644 --- a/src/slots.c +++ b/src/slots.c @@ -657,6 +657,15 @@ slot_get_id (slot_iterator_t slot) return slot; } +/* Return true if the token supports the GET CHALLENGE operation. */ +bool +slot_token_has_rng (slot_iterator_t id) +{ + struct slot *slot = scute_table_data (slots, id); + + return slot->info.rng_available; +} + /* Mechanism management. */ diff --git a/src/slots.h b/src/slots.h index e36be27..3624c55 100644 --- a/src/slots.h +++ b/src/slots.h @@ -116,6 +116,9 @@ void slot_token_pincount (slot_iterator_t id, int *max, int *len); /* Return the ID of slot SLOT. */ CK_SLOT_ID slot_get_id (slot_iterator_t slot); +/* Return true if the token supports the GET CHALLENGE operation. */ +bool slot_token_has_rng (slot_iterator_t id); + /* Begin iterating over the list of mechanisms. If succeeds, will be followed up by a slot_iterate_end. */ -- 2.7.4 From dgouttegattat at incenp.org Tue Mar 29 16:44:37 2016 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Tue, 29 Mar 2016 16:44:37 +0200 Subject: [PATCH 1/3] Implement C_GenerateRandom. In-Reply-To: <1459262679-16490-1-git-send-email-dgouttegattat@incenp.org> References: <1459262679-16490-1-git-send-email-dgouttegattat@incenp.org> Message-ID: <1459262679-16490-2-git-send-email-dgouttegattat@incenp.org> * src/agent.c (scute_agent_get_random, get_challenge_data_cb): New functions. * src/agent.h (scute_agent_get_random): New prototype. * src/p11-generaterandom.c (C_GenerateRandom): Implement feature. Signed-off-by: Damien Goutte-Gattat --- src/agent.c | 22 ++++++++++++++++++++++ src/agent.h | 3 +++ src/p11-generaterandom.c | 28 +++++++++++++++++++++++----- 3 files changed, 48 insertions(+), 5 deletions(-) diff --git a/src/agent.c b/src/agent.c index b51dc7e..4306f93 100644 --- a/src/agent.c +++ b/src/agent.c @@ -1281,6 +1281,28 @@ scute_agent_get_cert (int no, struct cert *cert) return 0; } +gpg_error_t +get_challenge_data_cb (void *opaque, const void *line, size_t len) +{ + memcpy (opaque, line, len); + + return 0; +} + +gpg_error_t +scute_agent_get_random (unsigned char *data, size_t len) +{ + char command[16]; + gpg_error_t err; + + snprintf (command, sizeof(command), "SCD RANDOM %lu", len); + + err = assuan_transact (agent_ctx, command, get_challenge_data_cb, + data, NULL, NULL, NULL, NULL); + + return err; +} + void scute_agent_finalize (void) diff --git a/src/agent.h b/src/agent.h index 6ac479f..6f3f6df 100644 --- a/src/agent.h +++ b/src/agent.h @@ -113,4 +113,7 @@ gpg_error_t scute_agent_is_trusted (char *fpr, bool *is_trusted); /* Try to get certificate for key numer NO. */ gpg_error_t scute_agent_get_cert (int no, struct cert *cert); +/* Get random bytes from the card. */ +gpg_error_t scute_agent_get_random (unsigned char *data, size_t len); + #endif /* AGENT_H */ diff --git a/src/p11-generaterandom.c b/src/p11-generaterandom.c index f192e9d..e8b20d9 100644 --- a/src/p11-generaterandom.c +++ b/src/p11-generaterandom.c @@ -33,14 +33,32 @@ #include "cryptoki.h" +#include "locking.h" +#include "slots.h" +#include "agent.h" +#include "error-mapping.h" + CK_DEFINE_FUNCTION(CK_RV, C_GenerateRandom) (CK_SESSION_HANDLE hSession, CK_BYTE_PTR pRandomData, CK_ULONG ulRandomLen) { - /* FIXME: Implement me. */ - (void) hSession; - (void) pRandomData; - (void) ulRandomLen; - return CKR_FUNCTION_NOT_SUPPORTED; + CK_RV err; + slot_iterator_t slot; + session_iterator_t session; + + if (pRandomData == NULL_PTR) + return CKR_ARGUMENTS_BAD; + + err = scute_global_lock (); + if (err) + return err; + + err = slots_lookup_session (hSession, &slot, &session); + if (!err) + err = scute_gpg_err_to_ck (scute_agent_get_random (pRandomData, + ulRandomLen)); + + scute_global_unlock (); + return err; } -- 2.7.4 From dgouttegattat at incenp.org Tue Mar 29 16:44:39 2016 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Tue, 29 Mar 2016 16:44:39 +0200 Subject: [PATCH 3/3] Add test for C_GenerateRandom. In-Reply-To: <1459262679-16490-1-git-send-email-dgouttegattat@incenp.org> References: <1459262679-16490-1-git-send-email-dgouttegattat@incenp.org> Message-ID: <1459262679-16490-4-git-send-email-dgouttegattat@incenp.org> * tests/Makefile.am (TESTS): Add t-generaterandom test. * tests/t-generaterandom.c: New file. Signed-off-by: Damien Goutte-Gattat --- tests/Makefile.am | 2 +- tests/t-generaterandom.c | 105 +++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 106 insertions(+), 1 deletion(-) create mode 100644 tests/t-generaterandom.c diff --git a/tests/Makefile.am b/tests/Makefile.am index 644eeb0..6c19071 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -33,7 +33,7 @@ noinst_HEADERS = t-support.h TESTS = t-link t-getfunctionlist t-initialize t-getinfo t-getslotlist \ t-getslotinfo t-gettokeninfo t-getmechanismlist t-getmechanisminfo \ t-opensession t-closeallsessions t-getsessioninfo \ - t-findobjects t-getattribute t-auth + t-findobjects t-getattribute t-auth t-generaterandom noinst_PROGRAMS = $(TESTS) diff --git a/tests/t-generaterandom.c b/tests/t-generaterandom.c new file mode 100644 index 0000000..675138d --- /dev/null +++ b/tests/t-generaterandom.c @@ -0,0 +1,105 @@ +/* t-generaterandom.c - Regression test. + Copyright (C) 2016 g10 Code GmbH + + This file is part of Scute. + + Scute 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. + + Scute 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 + General Public License for more details. + + You should have received a copy of the GNU General Public License + along with Scute; if not, write to the Free Software Foundation, + Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + + In addition, as a special exception, g10 Code GmbH gives permission + to link this library: with the Mozilla Foundation's code for + Mozilla (or with modified versions of it that use the same license + as the "Mozilla" code), and distribute the linked executables. You + must obey the GNU General Public License in all respects for all of + the code used other than "Mozilla". If you modify this file, you + may extend this exception to your version of the file, but you are + not obligated to do so. If you do not wish to do so, delete this + exception statement from your version. */ + +#include +#include + +#include "t-support.h" + + +int +main (int argc, char *argv[]) +{ + CK_RV err; + CK_SLOT_ID_PTR slots; + CK_ULONG slots_count; + unsigned int i; + + (void) argc; + (void) argv; + + init_cryptoki (); + + err = C_GetSlotList (true, NULL, &slots_count); + fail_if_err (err); + + if (slots_count == 0) + { + printf ("Skipping test because no token is present.\n"); + return 77; + } + + printf ("Number of slots with tokens: %lu\n", slots_count); + slots = malloc (sizeof (CK_SLOT_ID) * slots_count); + if (!slots) + fail_if_err (CKR_HOST_MEMORY); + + err = C_GetSlotList (true, slots, &slots_count); + fail_if_err (err); + + for (i = 0; i < slots_count; i++) + { + CK_TOKEN_INFO info; + + printf ("%2i. Slot ID %lu\n", i, slots[i]); + + err = C_GetTokenInfo (slots[i], &info); + fail_if_err (err); + + if ((info.flags & CKF_RNG) > 0) + { + CK_SESSION_HANDLE session; + unsigned char buffer[16]; + unsigned int j; + + printf(" RNG available\n"); + + err = C_OpenSession (slots[i], CKF_SERIAL_SESSION, NULL, NULL, + &session); + fail_if_err (err); + + printf (" Session ID: %lu\n", session); + + err = C_GenerateRandom (session, buffer, sizeof(buffer)); + fail_if_err (err); + + printf (" Random bytes: 0x"); + for (j = 0; j < sizeof(buffer); j++) + printf ("%02x", buffer[j]); + printf ("\n"); + + err = C_CloseSession (session); + fail_if_err (err); + } + else + printf (" No RNG available on token\n"); + } + + return 0; +} -- 2.7.4 From dkg at fifthhorseman.net Tue Mar 29 17:54:25 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 29 Mar 2016 11:54:25 -0400 Subject: building gpgv 2.1 statically for win32 -- finding wrong iconv Message-ID: <87shz9mg9a.fsf@alice.fifthhorseman.net> I'm trying to build gpgv 2.1 statically for the windows platform from a debian system. I want it to be static because i'd like to distribute it in the debian installer's win32-loader, and i don't want to have to ship extra .dll files with the .exe. Instead of using full gcc libiconv (which isn't packaged separately from libc on debian), i'm using the lighter-weight win-iconv. debian's win-iconv-mingw-w64-dev ships these files: /usr/i686-w64-mingw32/lib/libiconv.dll.a /usr/i686-w64-mingw32/lib/libiconv.a /usr/i686-w64-mingw32/bin/iconv.dll /usr/i686-w64-mingw32/include/iconv.h The problem i'm having is that the configure process decides that the LDFLAGS for libiconv are: -L/usr/i686-w64-mingw32/lib /usr/i686-w64-mingw32/lib/libiconv.dll.a If i build like this, then the supposedly "statically-built" gpgv2.exe that gets created still needs to find a copy of libiconv.dll. If i replace the above with: -L/usr/i686-w64-mingw32/lib -liconv then gpgv2.exe is correctly statically built. How do i get ./configure to choose the latter approach instead of the former? I'm having a hard time wading through the ./configure scripts generated by autoconf + m4/iconv.m4 to figure out what needs to change, but it looks to me like the fact that $acl_library_names_spec is '$libname.dll.a $libname.lib' is what's causing autoconf to select the .dll.a instead of just using -liconv, but i don't know how that's set, or how to override it. any suggestions? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From achim at pietig.com Tue Mar 29 17:37:05 2016 From: achim at pietig.com (Achim Pietig) Date: Tue, 29 Mar 2016 17:37:05 +0200 Subject: [PATCH 2/3] Check whether the card has a RNG. In-Reply-To: <1459262679-16490-3-git-send-email-dgouttegattat@incenp.org> References: <1459262679-16490-1-git-send-email-dgouttegattat@incenp.org> <1459262679-16490-3-git-send-email-dgouttegattat@incenp.org> Message-ID: <56FAA121.10808@pietig.com> Hi, the announcement of the gc function is always in the first byte (b7) of EXTCAP. For downward compatibility I do not plan to change that. Regards Achim Am 29.03.2016 um 16:44 schrieb Damien Goutte-Gattat: > + else if (keywordlen == 6 && !memcmp (keyword, "EXTCAP", keywordlen)) > + { > + /* FIXME: Should we parse the line properly instead of assuming > + that the gc capability will always be at the beginning? */ > + sscanf (line, "gc=%d", &(parm->rng_available)); > + } From dkg at fifthhorseman.net Wed Mar 30 08:09:18 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 30 Mar 2016 02:09:18 -0400 Subject: building gpgv 2.1 statically for win32 -- finding wrong iconv In-Reply-To: <87shz9mg9a.fsf@alice.fifthhorseman.net> References: <87shz9mg9a.fsf@alice.fifthhorseman.net> Message-ID: <87k2kkzecx.fsf@alice.fifthhorseman.net> On Tue 2016-03-29 11:54:25 -0400, Daniel Kahn Gillmor wrote: > The problem i'm having is that the configure process decides that the > LDFLAGS for libiconv are: > > -L/usr/i686-w64-mingw32/lib /usr/i686-w64-mingw32/lib/libiconv.dll.a > > If i build like this, then the supposedly "statically-built" gpgv2.exe > that gets created still needs to find a copy of libiconv.dll. > > If i replace the above with: > > -L/usr/i686-w64-mingw32/lib -liconv > > then gpgv2.exe is correctly statically built. > > How do i get ./configure to choose the latter approach instead of the > former? fwiw, the answer to this appears to be to add --without-libiconv-prefix to the arguments to ./configure. If anyone sees a problem with this approach, or has a suggestion for an improvement, please let me know. --dkg From dkg at fifthhorseman.net Wed Mar 30 16:53:20 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 30 Mar 2016 10:53:20 -0400 Subject: GPG_NAME vs. --gpg2-is-gpg vs. documentation vs. installation Message-ID: <87bn5wyq3j.fsf@alice.fifthhorseman.net> hi GnuPG folks-- i'm looking at what it would take to ship the GnuPG "modern" (2.1) branch as /usr/bin/gpg and /usr/bin/gpgv. configure.ac defines a GPG_NAME variable that determines what we call gpg. it also offers a --gpg2-is-gpg option, which sets the config variable NAME_OF_INSTALLED_GPG. These can be set independently from one another, which is a little confusing, and NAME_OF_INSTALLED_GPG does *not* set GPG_NAME if it is not otherwise set. In addition to this, much of the documentation hard-codes "gpg2" or "gpgv2", as do some embedded strings and help messages. g10/Makefile.am also contains explicit mentions of gpg2 and gpgv2, and even provides an install-exec-hook for WinCE to rename gpg2 to gpg (but not gpgv2), but that install-exec-hook doesn't trigger on other platforms when --gpg2-is-gpg is set. This seems a bit scattershot; is there some reason for it to be so? I'd prefer to consolidate all of these choices into a single boolean, set once at ./configure time (--gpg2-is-gpg seems like a good place for this), which could then propagate to the rest of the code and documentation, covering both gpg and gpgv. Any thoughts about making this sort of change? I can supply a few patches in this direction that should improve things, but i don't know whether i'll be able to address every last piece. Is the GnuPG project be interested in this kind of work? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From wk at gnupg.org Wed Mar 30 17:03:09 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 30 Mar 2016 17:03:09 +0200 Subject: GPG_NAME vs. --gpg2-is-gpg vs. documentation vs. installation In-Reply-To: <87bn5wyq3j.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 30 Mar 2016 10:53:20 -0400") References: <87bn5wyq3j.fsf@alice.fifthhorseman.net> Message-ID: <87io04j9ea.fsf@wheatstone.g10code.de> On Wed, 30 Mar 2016 16:53, dkg at fifthhorseman.net said: > configure.ac defines a GPG_NAME variable that determines what we call > gpg. it also offers a --gpg2-is-gpg option, which sets the config GPG_NAME allow to re-brand GnuPG. Here it is not due to trademark problems but simply because I had a customer who wanted GnUPG but under a different name. Thus I generalized this. I can't remember the origin of --gpg2-is-gpg option but it was either due to our old and unmaintained port to WindowsCE 3.5 or for Windows. > In addition to this, much of the documentation hard-codes "gpg2" or > "gpgv2", as do some embedded strings and help messages. Ooops. > once at ./configure time (--gpg2-is-gpg seems like a good place for That is probably the easiest to do. > Any thoughts about making this sort of change? I can supply a few > patches in this direction that should improve things, but i don't know Yes, it should indeed be done. Given that I did all the work for re-branding it is likely easier if I go and fix that. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Wed Mar 30 17:51:03 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 30 Mar 2016 11:51:03 -0400 Subject: [PATCH 3/3] move installed gpg and gpgv when --enable-gpg2-is-gpg In-Reply-To: <1459353063-6898-1-git-send-email-dkg@fifthhorseman.net> References: <1459353063-6898-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <1459353063-6898-3-git-send-email-dkg@fifthhorseman.net> * configure.ac: introduce an automake conditional GPG2_IS_GPG, test for WinCE there. * g10/Makefile.am: re-use the WinCE install-exec-hook to move the files into the right location when GPG2_IS_GPG is set --- configure.ac | 14 +++++++++++--- g10/Makefile.am | 5 +++-- 2 files changed, 14 insertions(+), 5 deletions(-) diff --git a/configure.ac b/configure.ac index 003e509..30a89cc 100644 --- a/configure.ac +++ b/configure.ac @@ -211,10 +211,18 @@ test -n "$GNUPG_DIRMNGR_LDAP_PGM" \ # installed name of gpg. This option sets "gpg2"'s installed name to # just "gpg". Note that it might be required to rename gpg2 to gpg # manually after the build process. -# + AC_ARG_ENABLE(gpg2-is-gpg, AC_HELP_STRING([--enable-gpg2-is-gpg],[Set installed name of gpg2 to gpg]), - gpg2_is_gpg=$enableval) + gpg2_is_gpg=$enableval, + # There has never been a gpg for WindowsCE, so this should default + # to true on that platform. + [case "${host}" in + *-mingw32ce*) + gpg2_is_gpg=yes + ;; + esac] + ) if test "$gpg2_is_gpg" = "yes"; then name_of_installed_gpg=gpg else @@ -222,7 +230,7 @@ else fi AC_DEFINE_UNQUOTED(NAME_OF_INSTALLED_GPG, "$name_of_installed_gpg", [The name of the installed GPG tool]) - +AM_CONDITIONAL([GPG2_IS_GPG], [test x$name_of_installed_gpg = xgpg]) # SELinux support includes tracking of sensitive files to avoid # leaking their contents through processing these files by gpg itself diff --git a/g10/Makefile.am b/g10/Makefile.am index 473a3ac..e16a2c2 100644 --- a/g10/Makefile.am +++ b/g10/Makefile.am @@ -199,9 +199,10 @@ uninstall-local: - at rm $(DESTDIR)$(pkgdatadir)/distsigkey.gpg -# There has never been a gpg for WindowsCE, thus we don't need a gpg2 here -if HAVE_W32CE_SYSTEM +if GPG2_IS_GPG install-exec-hook: mv -f $(DESTDIR)$(bindir)/gpg2$(EXEEXT) \ $(DESTDIR)$(bindir)/gpg$(EXEEXT) + mv -f $(DESTDIR)$(bindir)/gpgv2$(EXEEXT) \ + $(DESTDIR)$(bindir)/gpgv$(EXEEXT) endif -- 2.8.0.rc3 From dkg at fifthhorseman.net Wed Mar 30 17:51:02 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 30 Mar 2016 11:51:02 -0400 Subject: [PATCH 2/3] avoid hardcoded use of gpg2 in gpgcompose documentation In-Reply-To: <1459353063-6898-1-git-send-email-dkg@fifthhorseman.net> References: <1459353063-6898-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <1459353063-6898-2-git-send-email-dkg@fifthhorseman.net> * g10/gpgcompose.c: use GPG_NAME configure variable instead of hardcoded string "gpg2" in example output. --- g10/gpgcompose.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/g10/gpgcompose.c b/g10/gpgcompose.c index 55d3ae2..badbcac 100644 --- a/g10/gpgcompose.c +++ b/g10/gpgcompose.c @@ -553,7 +553,7 @@ static struct option user_id_options[] = { "\"Name (comment) \"" }, { NULL, NULL, "Example:\n\n" - " $ gpgcompose --user-id \"USERID\" | gpg2 --list-packets" } + " $ gpgcompose --user-id \"USERID\" | " GPG_NAME " --list-packets" } }; static int @@ -662,7 +662,7 @@ static struct option pk_options[] = { { NULL, NULL, "Example:\n\n" " $ gpgcompose --public-key $KEYID --user-id \"USERID\" \\\n" - " | gpg2 --list-packets" } + " | " GPG_NAME " --list-packets" } }; static int @@ -1554,7 +1554,7 @@ static struct option sig_options[] = { "Example:\n\n" " $ gpgcompose --public-key $KEYID --user-id USERID \\\n" " --signature --class 0x10 --issuer $KEYID --issuer-keyid self \\\n" - " | gpg2 --list-packets"} + " | " GPG_NAME " --list-packets"} }; static int @@ -2146,12 +2146,12 @@ static struct option sk_esk_options[] = { "password. The session key may be prefaced with an integer and a colon " "to indicate the cipher to use for the SED packet (making --sed-cipher " "unnecessary and allowing the direct use of the result of " - "\"gpg2 --show-session-key\")." }, + "\"" GPG_NAME " --show-session-key\")." }, { "", sk_esk_password, "The password." }, { NULL, NULL, "Example:\n\n" " $ gpgcompose --sk-esk foobar --encrypted \\\n" - " --literal --value foo | gpg2 --list-packets" } + " --literal --value foo | " GPG_NAME " --list-packets" } }; static int @@ -2388,14 +2388,14 @@ static struct option pk_esk_options[] = { "then a new session key is generated. The session key may be " "prefaced with an integer and a colon to indicate the cipher to use " "for the SED packet (making --sed-cipher unnecessary and allowing the " - "direct use of the result of \"gpg2 --show-session-key\")." }, + "direct use of the result of \"" GPG_NAME " --show-session-key\")." }, { "--throw-keyid", pk_esk_throw_keyid, "Throw the keyid." }, { "", pk_esk_keyid, "The key id." }, { NULL, NULL, "Example:\n\n" " $ gpgcompose --pk-esk $KEYID --encrypted --literal --value foo \\\n" - " | gpg2 --list-packets"} + " | " GPG_NAME " --list-packets"} }; static int @@ -2494,14 +2494,14 @@ static struct option encrypted_options[] = { "string. If this is not given or is \"auto\", then the last session key " "is used. If there was none, then an error is raised. The session key " "must be prefaced with an integer and a colon to indicate the cipher " - "to use (this is format used by \"gpg2 --show-session-key\")." }, + "to use (this is format used by \"" GPG_NAME " --show-session-key\")." }, { NULL, NULL, "After creating the packet, this command clears the current " "session key.\n\n" "Example: nested encryption packets:\n\n" " $ gpgcompose --sk-esk foo --encrypted-mdc \\\n" " --sk-esk bar --encrypted-mdc \\\n" - " --literal --value 123 --encrypted-pop --encrypted-pop | gpg2 -d" } + " --literal --value 123 --encrypted-pop --encrypted-pop | " GPG_NAME " -d" } }; static int @@ -2743,7 +2743,7 @@ static struct option literal_options[] = { "The literal's name." }, { NULL, NULL, "Example:\n\n" - " $ gpgcompose --literal --value foobar | gpg2 -d"} + " $ gpgcompose --literal --value foobar | " GPG_NAME " -d"} }; static int -- 2.8.0.rc3 From dkg at fifthhorseman.net Wed Mar 30 17:51:01 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 30 Mar 2016 11:51:01 -0400 Subject: [PATCH 1/3] use GPG_NAME in how_to_fix_the_trustdb() Message-ID: <1459353063-6898-1-git-send-email-dkg@fifthhorseman.net> * g10/trustdb.c: (how_to_fix_the_trustdb) use GPG_NAME explicitly instead of hardcoding gpg2 --- g10/trustdb.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/g10/trustdb.c b/g10/trustdb.c index 8f2b2cb..81d0a1a 100644 --- a/g10/trustdb.c +++ b/g10/trustdb.c @@ -421,13 +421,13 @@ how_to_fix_the_trustdb () log_info (_("You may try to re-create the trustdb using the commands:\n")); log_info (" cd %s\n", default_homedir ()); - log_info (" gpg2 --export-ownertrust > otrust.tmp\n"); + log_info (" " GPG_NAME " --export-ownertrust > otrust.tmp\n"); #ifdef HAVE_W32_SYSTEM log_info (" del %s\n", name); #else log_info (" rm %s\n", name); #endif - log_info (" gpg2 --import-ownertrust < otrust.tmp\n"); + log_info (" " GPG_NAME " --import-ownertrust < otrust.tmp\n"); log_info (_("If that does not work, please consult the manual\n")); } -- 2.8.0.rc3 From dkg at fifthhorseman.net Wed Mar 30 17:58:36 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 30 Mar 2016 11:58:36 -0400 Subject: GPG_NAME vs. --gpg2-is-gpg vs. documentation vs. installation In-Reply-To: <87io04j9ea.fsf@wheatstone.g10code.de> References: <87bn5wyq3j.fsf@alice.fifthhorseman.net> <87io04j9ea.fsf@wheatstone.g10code.de> Message-ID: <878u10yn2r.fsf@alice.fifthhorseman.net> On Wed 2016-03-30 11:03:09 -0400, Werner Koch wrote: >> Any thoughts about making this sort of change? I can supply a few >> patches in this direction that should improve things, but i don't know > > Yes, it should indeed be done. Given that I did all the work for > re-branding it is likely easier if I go and fix that. Thanks! I've just sent a series of three patches that start down this path. Ideally, they would affect the names and the content of the generated manpages and info documentation as well -- for the experimental debian packaging i'm doing at the moment, i'm just manually renaming the documentation and leaving its contents untouched, which is probably suboptimal.. If we can confirm this approach for the "modern" branch, i'm inclined to try to produce a similar approach for the "classic" branch: something like ./configure --enable-gpg1-is-gpg (it would default to "yes" for now). If the classic branch was configured with --disable-gpg1-is-gpg, it would try to install /usr/bin/gpg1 and /usr/bin/gpgv1 instead of /usr/bin/gpg. This would encourage distros that ship the modern branch as /usr/bin/gpg to have a canonical place to find the classic branch if people want it co-installed. Does that seem like a sensible approach? Regards, --dkg From wk at gnupg.org Thu Mar 31 13:12:40 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 31 Mar 2016 13:12:40 +0200 Subject: [Announce] GnuPG 2.0.29 released Message-ID: <871t6qj3yv.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG-2.0 release: Version 2.0.30. This is a maintenance release which fixes a couple of bugs. The GNU Privacy Guard (GnuPG) is a complete and free implementation of the OpenPGP standard as defined by RFC-4880 and better known as PGP. GnuPG, also known as GPG, 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. Since version 2 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. Three different versions of GnuPG are actively maintained: - GnuPG "modern" (2.1) is the latest development with a lot of new features including support for ECC. All new installations should use that version. - GnuPG "stable" (2.0) - which this is about - is the current stable version for general use. This is what most users are currently using. - GnuPG "classic" (1.4) is the old standalone version which is most suitable for older or embedded platforms. You may not install "modern" (2.1) and "stable" (2.0) at the same time. However, it is possible to install "classic" (1.4) along with any of the other versions. What's New in 2.0.30 ==================== * gpg: Avoid too early timeout during key generation with 2.1 cards. * agent: Fixed printing of ssh fingerprints for 384 bit ECDSA keys. * agent: Fixed an alignment bug related to the passphrase confirmation. * scdaemon: Fixed a "conflicting usage" bug. * scdaemon: Fixed usb card reader removal problem on Windows 8 and later. * Fixed a problem on AIX due to peculiarity with RLIMIT_NOFILE. * Updated the Japanese and Dutch translations. * Fixed a few other bugs. Getting the Software ==================== Please follow the instructions found at https://gnupg.org/download/ or read on: 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: ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.0.30.tar.bz2 (4311k) ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.0.30.tar.bz2.sig or here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.0.30.tar.bz2 (4311k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.0.30.tar.bz2.sig Note, that we don't distribute gzip compressed tarballs for GnuPG-2. A Windows version will soon be released at . If you are new to GnuPG please use the "modern" version 2.1.11. 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.0.30.tar.bz2 you would use this command: gpg --verify gnupg-2.0.30.tar.bz2.sig gnupg-2.0.30.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 below 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.0.29.tar.bz2, you would run the command like this: sha1sum gnupg-2.0.30.tar.bz2 and check that the output matches the next line: a9f024588c356a55e2fd413574bfb55b2e18794a gnupg-2.0.30.tar.bz2 Release Signing Keys ==================== To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: 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) You may retrieve these files from the keyservers using this command gpg --recv-keys 249B39D24F25E3B6 04376F3EE0856959 \ 2071B08A33BD3F06 8A861B1C7EFD60D9 using an already installed version of gpg. Remeber to check the fingerprints against the above list (which you also find on the flip side of our printed visit cards). The keys are also available at and in the released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed using my standard PGP key. Documentation ============= The file gnupg.info has the complete user manual of the system. Separate man pages are included as well; however they have not all the details available in the manual. It is also possible to read the complete manual online in HTML format at https://www.gnupg.org/documentation/manuals/gnupg-2.0/ or in Portable Document Format at https://www.gnupg.org/documentation/manuals/gnupg-2.0.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. 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 . For commercial support requests we keep a list of known service companies at: https://gnupg.org/service.html 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. We currently employ 3 full-time developers, one part-timer, and one contractor. They all work on GnuPG and closely related software like Enigmail. Please see https://gnupg.org/donate/ on how you can help. 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, and answering questions on the mailing lists. Maintenance and development of GnuPG is possible due to many individual and corporate donations; for a list of non-anonymous donors see . For the GnuPG hackers, Werner p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users 'at' gnupg.org mailing list. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce