From wk at gnupg.org Sun May 1 20:05:38 2016 From: wk at gnupg.org (Werner Koch) Date: Sun, 01 May 2016 20:05:38 +0200 Subject: The loopback pinentry In-Reply-To: <8760va1zal.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 21 Apr 2016 16:29:06 -0400") References: <87ega00y7u.fsf@alice.fifthhorseman.net> <8760va1zal.fsf@alice.fifthhorseman.net> Message-ID: <87inyx8xhp.fsf@wheatstone.g10code.de> On Thu, 21 Apr 2016 22:29, dkg at fifthhorseman.net said: > Here's an attempt at writing a short description of the goals of an > isolated cryptographic agent: Thanks for the text. I copied it as a comment to gpg-agent.texi for later use. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Sun May 1 20:07:47 2016 From: wk at gnupg.org (Werner Koch) Date: Sun, 01 May 2016 20:07:47 +0200 Subject: The loopback pinentry In-Reply-To: (Bjarni Runar Einarsson's message of "Thu, 21 Apr 2016 22:31:49 -0000") References: <8760va1zal.fsf@alice.fifthhorseman.net> Message-ID: <87eg9l8xe4.fsf@wheatstone.g10code.de> On Fri, 22 Apr 2016 00:31, bre at pagekite.net said: > per long-lived session) credentials (per-app passphrases for > example, or per-key pinentry policies). Does the current agent > support such things? Can an app request pinentry authentication Not yet. But Justus' recent work for an extended private key format sets the groundwork to implement such things. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Tue May 3 11:03:18 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 3 May 2016 18:03:18 +0900 Subject: Missing Npth test In-Reply-To: References: Message-ID: <57286956.6030808@fsij.org> Hello, Thank you for your bug report. I also see your bug report 2260. On 02/11/2016 10:19 PM, Uldis An?mits wrote: > I believe, npth project is missing test for resource locking after for. > Please see patch at the end of message. > > gnupg-2.1.11 tests fail on AIX. gpg-agent fails on semaphore operations > during startup. > > Following important npth library functions are executed by gpg-agent on > startup: > 1. npth_init > 2. npth_unportect > 3. npth_protect > 4. fork > 5. npth_pselect <- here things go wrong I understand the issue. Here, the unnamed semaphore created by a parent with sem_init(pshared=0) is used by its children. POSIX-wise, this usage of semaphore is undefined. In GNU/Linux (and possibly GNU/Hurd), it just works, but I think that we rely on undefined behaviour. > For reason unknown to me, on last machine child receives SIGHUP soon > after fork. > Workaround for this is to set signal handler right after fork but this > is nothing to do with Npth. > > npth test output: > PASS: t-mutex > PASS: t-thread > Assertion failed: __EX, file ../../npth-1.2/src/npth.c, line 123 > FAIL: t-fork > > If i change sem_init(,pshared=1,) in npth_init, semaphore operations works. I think that we only create the unnamed semaphore with pshared=0 for know system (I'd say: a system with fork-safe semaphore). POSIX-wise, it is completely valid not to allow access to the semaphore object after fork (even SIGHUP after fork would be valid because of the existence of such a shared object between parent and child). For other systems, it sounds better to create the unnamed semaphore with pshared=1. I don't think sem_open is good when we have another option, because such a semaphore can be accessed by other processes (while unnamed semaphre can only share among a process and its descendants). > Please consider following patch for testing Npth behaviour after fork. > > diff --git a/tests/Makefile.am b/tests/Makefile.am > index 0dd436e..4b39ff6 100644 > --- a/tests/Makefile.am > +++ b/tests/Makefile.am > @@ -28,7 +28,7 @@ > > ## Process this file with automake to produce Makefile.in > > -TESTS = t-mutex t-thread > +TESTS = t-mutex t-thread t-fork Thanks for your suggestion. I think that because fork is only available on Unix systems (not on Windows), it is better to conditionalize it. Inspired by your work, here is my attempt to improve current situation. I don't change the behavior of GNU/Linux and GNU/Hurd. It keeps current behavior of using pshared=0. I call it HAVE_FORK_SAFE_SEMAPHORE. I don't think AIX has "broken" semaphore implementation, it is completely valid. I'd avoid runtime test in configure (my concern is cross compiling). I believe it is determined by host operating system. How do you think? diff --git a/configure.ac b/configure.ac index 84d34ff..e5c5049 100644 --- a/configure.ac +++ b/configure.ac @@ -118,9 +118,11 @@ have_ld_version_script=no case "${host}" in *-*-linux*) have_ld_version_script=yes + have_fork_safe_semaphore=yes ;; *-*-gnu*) have_ld_version_script=yes + have_fork_safe_semaphore=yes ;; *-apple-darwin*) AC_DEFINE(_XOPEN_SOURCE, 500, Activate POSIX interface on MacOS X) @@ -128,6 +130,9 @@ case "${host}" in esac AM_CONDITIONAL(HAVE_LD_VERSION_SCRIPT, test "$have_ld_version_script" = "yes") +if test "$have_fork_safe_semaphore" = yes; then + AC_DEFINE(HAVE_FORK_SAFE_SEMAPHORE, 1, [Defined if we have fork-safe semaphore]) +fi # Set some default values config_libs="-lnpth" diff --git a/src/npth.c b/src/npth.c index 7de6c9d..37a60d6 100644 --- a/src/npth.c +++ b/src/npth.c @@ -61,6 +61,31 @@ static sem_t sceptre_buffer; static sem_t *sceptre = &sceptre_buffer; +/* Configure defines HAVE_FORK_SAFE_SEMAPHORE if child process can + access non-shared unnamed semaphore. It doesn't define it if not. + + We use unnamed semaphore (if available) for the global lock. The + specific semaphore is only valid for those threads in a process, + and it is no use by other processes. Thus, PSHARED argument for + sem_init is naturally 0. + + However, there are daemon-like applications which use fork after + npth_init. In this case, a child process uses the semaphore which + was created by its parent process. In some system (e.g. AIX), + access by child process to non-shared unnamed semaphore is + prohibited. For such a system, HAVE_FORK_SAFE_SEMAPHORE should be + undefined, so that unnamed semaphore will be created with PSHARED = + 1. The purpose of the setting of PSHARED = 1 is only for accessing + of the lock by child process. For NPTH, it does not mean any other + interactions between processes. + + */ +#ifdef HAVE_FORK_SAFE_SEMAPHORE +#define NPTH_SEMAPHORE_PSHARED 0 +#else +#define NPTH_SEMAPHORE_PSHARED 1 +#endif + /* The main thread is the active thread at the time pth_init was called. As of now it is only useful for debugging. The volatile make sure the compiler does not eliminate this set but not used @@ -181,8 +206,8 @@ npth_init (void) sem_init. */ errno = 0; - /* The semaphore is not shared and binary. */ - res = sem_init (sceptre, 0, 1); + /* The semaphore is binary. */ + res = sem_init (sceptre, NPTH_SEMAPHORE_PSHARED, 1); if (res < 0) { /* Mac OSX and some AIX versions have sem_init but return diff --git a/tests/Makefile.am b/tests/Makefile.am index 0dd436e..2a0542b 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -40,6 +40,7 @@ else AM_CPPFLAGS = -I../src -D_POSIX_C_SOURCE=200112L AM_LDFLAGS = LDADD = ../src/libnpth.la $(LIBSOCKET) $(LIB_CLOCK_GETTIME) +TESTS += t-fork endif noinst_HEADERS = t-support.h diff --git a/tests/t-fork.c b/tests/t-fork.c new file mode 100644 index 0000000..c6331dc --- /dev/null +++ b/tests/t-fork.c @@ -0,0 +1,49 @@ +/* t-fork.c + * Copyright 2016 g10 Code GmbH + * + * This file is free software; as a special exception the author gives + * unlimited permission to copy and/or distribute it, with or without + * modifications, as long as this notice is preserved. + * + * This file is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY, to the extent permitted by law; without even the + * implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + */ + +#include +#include +#include +#include "t-support.h" + + +int +main (int argc, const char *argv[]) +{ + int rc; + pid_t pid; + + if (argc >= 2 && !strcmp (argv[1], "--verbose")) + opt_verbose = 1; + + rc = npth_init (); + fail_if_err (rc); + + pid = fork (); + if (pid == (pid_t)-1) + fail_msg ("fork failed"); + else if (pid) + { + int status; + + info_msg ("forked"); + wait (&status); + fail_if_err (status); + } + else + { + info_msg ("child exit"); + npth_usleep (1000); /* Let NPTH enter, sleep, and leave. */ + } + + return 0; +} -- From bernhard at intevation.de Tue May 3 17:53:37 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 3 May 2016 17:53:37 +0200 Subject: Building a user experience vision of future GnuPG (as part of EasyGpg2016) Message-ID: <201605031753.41980.bernhard@intevation.de> Hi friends of GnuPG, as part of the EasyGPg2016 contract, we have started to build a vision and some user archetypes and stories of how GnuPG could evolve within the contract. The documentation of a first meeting can be found here: https://wiki.gnupg.org/EasyGpg2016/VisionAndStories Feedback appreciated, either to gnupg-devel@ or the channels listed on https://wiki.gnupg.org/EasyGpg2016 Best Regards, Bernhard -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Tue May 3 19:36:30 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 03 May 2016 19:36:30 +0200 Subject: Missing Npth test In-Reply-To: <57286956.6030808@fsij.org> (NIIBE Yutaka's message of "Tue, 3 May 2016 18:03:18 +0900") References: <57286956.6030808@fsij.org> Message-ID: <878tzr2gdd.fsf@wheatstone.g10code.de> On Tue, 3 May 2016 11:03, gniibe at fsij.org said: > I understand the issue. Here, the unnamed semaphore created by a > parent with sem_init(pshared=0) is used by its children. POSIX-wise, > this usage of semaphore is undefined. In GNU/Linux (and possibly We need to distinguish between the two cases: - fork and exec - only fork In the former case there should be no problem because the semaphore is destroyed with the exec. In the latter case, where we only fork, we have a copy of the semaphore and it is not clear whether we need to re-initialize it (sem_init) or should not do so (or use sem_destroy followed by sem_init). It seems we rely on undefined behaviour after the fork (this is similar to Pthread's mutex problem after fork) Each nPth enabled process requires its own semaphore (the sceptre variable in npth.c) and this one must not be shared. If we would share a semaphore between processes, we can run into a deadlock. Thus I doubt that setting pshared=1 and using fork is a valid solution. Although the specs say that a shared memory mechanism needs to be used with pshared=1 it does not guarantee that the semaphore is local to the process and that the forked process indeed has a separate copy of the semaphore. > For other systems, it sounds better to create the unnamed semaphore with > pshared=1. I would we more conservative and do a fix only for AIX. > I don't think sem_open is good when we have another option, because > such a semaphore can be accessed by other processes (while unnamed > semaphre can only share among a process and its descendants). Agreed. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernhard at intevation.de Wed May 4 08:48:52 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 4 May 2016 08:48:52 +0200 Subject: gpgv: timestamps, validity, expiration, and revocation In-Reply-To: <87a8klxzjy.fsf@alice.fifthhorseman.net> References: <87a8klxzjy.fsf@alice.fifthhorseman.net> Message-ID: <201605040848.57282.bernhard@intevation.de> Am Freitag, 22. April 2016 20:34:41 schrieb Daniel Kahn Gillmor: > I think gpgv should check for revoked or expired keys; if it assumes > that all keys in the keyring are trustworthy, then why would it not be > willing to rely on those keys' stated (and self-certified) expiration > dates or revocation certificates? FWIW: I agree that gpgv -- if it exists -- should behave consistently, check for expiration and revokation. My wild guess is that technically the current checks are done in a different place, this is why they are done. They are an indicator that something is not fully okay with the signatures. > I'm particularly worried about this because i'm hoping that apt (and > other package managers) will move to using gpgv for verification -- > there's no reason for a verification-only context (like verifying signed > package manifests) to need to bundle in all the complexity that goes > with secret key handling. I'm unsure about this, the extra burden of maintaining a verification only version may be higher than what you win by having it in some contexts. So a valid solution could be to just remove gpgv completly. > If gpgv doesn't handle these timestamp issues > correctly, then package managers relying on gpgv can be subject to > archive "freezing", slowing, or replay attacks. > > Is there a reason to keep the earlier, inconsistent behavior, or should > i file a bug report tracking a fix for this? I guess you should file a report, just to be able to refer to and track the issue. Best, Bernhard -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Wed May 4 09:38:49 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 4 May 2016 09:38:49 +0200 Subject: A new test framework: request for comments and testing In-Reply-To: <20160421151334.2180.54568@thinkbox.jade-hamburg.de> References: <20160421151334.2180.54568@thinkbox.jade-hamburg.de> Message-ID: <201605040938.54300.bernhard@intevation.de> Hello Justus, Hello GnuPG-people, Am Donnerstag, 21. April 2016 17:13:34 schrieb Justus Winter: > I have been working on a new test framework at the beginning of the > year. We perceived two main problems with the current Bourne > shell-based test framework: > > * we cannot run it on Windows > * writing shell scripts that are portable even across POSIXish systems > is a challenge > (* the language is not very nice, leading to brittle code with a lot > of copying) I agree with the problems, especially the portability question is important. > So we sat down at the Chaos Communication Congress and came up with > the idea of using TinySCHEME, a very small and self-contained > interpreter. My task was to evaluate the feasibility of that > approach. One of the concerns was that choosing Scheme over Bourne > shell will be an higher barrier to writing tests. I've looked up https://en.wikipedia.org/wiki/TinyScheme http://tinyscheme.sourceforge.net/home.html and I share that concern of a higher barrier. If we want to have more people improving and writing automatic tests, they should be especially easy to unterstand and write. The problem with an exotic language dialect is: * No good documentation, no tutorial. * Small community, often not well maintained. * Lacking functions and libraries. Checking this for TinyScheme: * It does not appear somewhere near the top in popular rankings https://en.wikipedia.org/wiki/Measuring_programming_language_popularity (even with all the problems considered it can be called an exootic dialect scheme itself of course appears in the top 50 in a number of rankings.) * The manual in the tinyscheme-1.41.tar.gz only seems to be directred at people already knowing some other scheme things. No tutorial. * Last release from April 2013, 3 years ago. Three commits in 2016, five commits in 2015 to head branch. * There is a regular expression library (useful for testing frameworks), but not that many others. So why not using a small-footprint interpreter for a more popular language? Lua may be a candidate. (There are small print C interpreters https://github.com/zsaleeba/picoc, but they are probably even more exotic.) Personally I would not mind using a larger popular language for testing, like Python. To me clarity and approachability of the language would be more important than the small footfront and direct integration. > I have tested the code on Hurd, Linux, and Windows. Please test this > patch series on any weird and wonderful platform that you have access > to. Using it is easy, just do make check. > > I pushed my work periodically to the GnuPG repository at > git.gnupg.org. The latest iteration is in the branch 'justus/scm-9'. It would be cool to have a wiki.gnupg.org page with instructions how to test this. Thanks for working on improving the test framework of GnuPG! Best Regards, Bernhard -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From gniibe at fsij.org Wed May 4 12:56:06 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 04 May 2016 19:56:06 +0900 Subject: Missing Npth test In-Reply-To: <878tzr2gdd.fsf@wheatstone.g10code.de> References: <57286956.6030808@fsij.org> <878tzr2gdd.fsf@wheatstone.g10code.de> Message-ID: <5729D546.8060804@fsij.org> On 05/04/2016 02:36 AM, Werner Koch wrote: > We need to distinguish between the two cases: > > - fork and exec > - only fork I see. In general, the concept of "fork" is difficult to be defined (or to be implemented rationally) with threads. I think that it is wise to avoid use of fork in threaded applications if possible. Good practice in general is to use fork for limited specific cases like fork+exec, if not avoidable. I think that this practice of avoinding fork is also applied to applications with nPth. The use of fork is not encouraged at all. It is only done in a specific use case like fork+exec. Daemonize would be another use case. It would be best for us to ask users no-use of fork in their applications and to suggest fork before npth_init and use of posix_spawn. > In the former case there should be no problem because the semaphore is > destroyed with the exec. Yes. In this case, it is a child which does exec. > In the latter case, where we only fork, we have a copy of the > semaphore and it is not clear whether we need to re-initialize it > (sem_init) or should not do so (or use sem_destroy followed by > sem_init). It seems we rely on undefined behaviour after the fork > (this is similar to Pthread's mutex problem after fork) If it's a parent process, keep using the non-shared unnamed semaphore (which is created by pshread=0) is no problem on any POSIX systems, I suppose. However, in the particular use case of ours, fork is done to daemonize, and thus, it is a child process which tries to keep using the semaphore. In GNU/Linux, it works, but I think that it's just we are lucky. It is completely natural for an implementation of thread library on some POSIX system not to inherit the resource of non-shared unnamed semaphore to a child process (because by its definition of non-shared). I suspect AIX does this (no inherit of the resource). > Each nPth enabled process requires its own semaphore (the sceptre > variable in npth.c) and this one must not be shared. If we would share > a semaphore between processes, we can run into a deadlock. Thus I doubt > that setting pshared=1 and using fork is a valid solution. Although the > specs say that a shared memory mechanism needs to be used with pshared=1 > it does not guarantee that the semaphore is local to the process and > that the forked process indeed has a separate copy of the semaphore. I understand your point. I don't assume the forked process has a separate copy of the semaphore with pshared=1. Rather, I assume there should be no nPth application which uses fork in the literal meaning of duplicating the process (including threads and threads resources). The limited use cases of fork are: fork+exec, daemonize, or similar (soon exec or soon exit). >> For other systems, it sounds better to create the unnamed semaphore with >> pshared=1. > > I would we more conservative and do a fix only for AIX. I understand. Let me see if it works on AIX or not. -- From wk at gnupg.org Wed May 4 15:28:44 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 04 May 2016 15:28:44 +0200 Subject: A new test framework: request for comments and testing In-Reply-To: <201605040938.54300.bernhard@intevation.de> (Bernhard Reiter's message of "Wed, 4 May 2016 09:38:49 +0200") References: <20160421151334.2180.54568@thinkbox.jade-hamburg.de> <201605040938.54300.bernhard@intevation.de> Message-ID: <87y47qx88j.fsf@wheatstone.g10code.de> On Wed, 4 May 2016 09:38, bernhard at intevation.de said: > and I share that concern of a higher barrier. Not really; only for those who are used to write tests for GnuPG - not that many ;-) > * No good documentation, no tutorial. The Wizard Book (SICP) is an excellent tutorial and generations of hackers have grown up with it. > * Small community, often not well maintained. The Scheme community small - my experience is different (see above) > * Lacking functions and libraries. Right, I want the test framework to be part of GnuPG proper and not rely on some external stuff. We do not need more than what we can expect on a standard pre-POSIX Unix system. > So why not using a small-footprint interpreter for a more popular language? > Lua may be a candidate. Yet another fashionable language - too large. > Personally I would not mind using a larger popular language for testing, > like Python. To me clarity and approachability of the language would be more We considered to use Guile as a full fledged Scheme system but for obvious reasons we can't include it in GnuPG. > It would be cool to have a wiki.gnupg.org page with instructions how > to test this. "make check" as always. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernhard at intevation.de Wed May 4 16:11:56 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 4 May 2016 16:11:56 +0200 Subject: A new test framework: request for comments and testing In-Reply-To: <87y47qx88j.fsf@wheatstone.g10code.de> References: <20160421151334.2180.54568@thinkbox.jade-hamburg.de> <201605040938.54300.bernhard@intevation.de> <87y47qx88j.fsf@wheatstone.g10code.de> Message-ID: <201605041612.00544.bernhard@intevation.de> Am Mittwoch, 4. Mai 2016 15:28:44 schrieb Werner Koch: > On Wed, 4 May 2016 09:38, bernhard at intevation.de said: > > and I share that concern of a higher barrier. > > Not really; only for those who are used to write tests for GnuPG - not > that many ;-) The smiley indicates that you know that I mean new potential test writers compared to the language choice. Right now many will have the learn TinyScheme or at least the details of TinyScheme compared to other scheme schemes. (SCNR). You are restating the problem. > > * No good documentation, no tutorial. > > The Wizard Book (SICP) is an excellent tutorial and generations of > hackers have grown up with it. Okay, it is online here https://mitpress.mit.edu/sicp/, but sorry this is not a modern tutorial nor a good documentation of TinyScheme. > > * Small community, often not well maintained. > > The Scheme community small - my experience is different (see above) I am refering to TinyScheme in particular, I know that there is a significant community in Scheme dialects. However when writing tests I will probably rely on some of the finer details of this particular implementation. > > * Lacking functions and libraries. > > Right, I want the test framework to be part of GnuPG proper and not rely > on some external stuff. We do not need more than what we can expect on > a standard pre-POSIX Unix system. > > > So why not using a small-footprint interpreter for a more popular > > language? Lua may be a candidate. > > Yet another fashionable language - too large. Created 1993, from https://www.lua.org/about.html //The tarball for Lua 5.3.2, which contains source code and documentation, takes 282K compressed and 1.1M uncompressed. The source contains around 24000 lines of C. Under 64-bit Linux, the Lua interpreter built with all standard Lua libraries takes 245K and the Lua library takes 419K. // Compare this to TinyScheme, to be fair I include the reg exp and date extensions: 54k Mai 4 15:56 re-1.3.tar.gz 62k Mai 4 09:00 tinyscheme-1.41.tar.gz 8,5k Mai 4 15:55 tsx-1.1.tgz okay, that is ~125k, half the size of the lua tarball. sloccount gives me almost 10k lines of code, so lua is only about a factor of 1.4 as large as TinyScheme. > > Personally I would not mind using a larger popular language for testing, > > like Python. To me clarity and approachability of the language would be > > more > > We considered to use Guile as a full fledged Scheme system but for > obvious reasons we can't include it in GnuPG. You mean because guile-2.0.11.tar.gz is 7.3 MiByte large? Yes, that is ~25 times as large as lua. Or because it it too young and fasionable (created 1995)? :) > > It would be cool to have a wiki.gnupg.org page with instructions how > > to test this. > > "make check" as always. Doing an example command session, including the git checkout and separation against potential existing gnupg installations will really enable some more testers. -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From Alexander.Strobel at giepa.de Wed May 4 15:21:36 2016 From: Alexander.Strobel at giepa.de (Alexander Strobel) Date: Wed, 4 May 2016 15:21:36 +0200 Subject: Libgcrypt 1.7 in GnuPG Message-ID: <5729F760.6050705@giepa.de> Hi everyone Since there is still an issue in GnuPG 2.1.11 that makes me unable to create an ECC subkey with Curve 25519, I wanted to ask, if the new libgcrypt version 1.7 will be included in the next GnuPG releases? Thanks and best regards Alex Strobel www.gpg4o.com From wk at gnupg.org Wed May 4 17:15:51 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 04 May 2016 17:15:51 +0200 Subject: [Announce] GnuPG 2.1.12 released Message-ID: <87eg9hyhug.fsf@wheatstone.g10code.de> Hello! The GnuPG team is pleased to announce the availability of a new release of GnuPG modern: Version 2.1.12. See below for new features and bug fixes. The GNU Privacy Guard (GnuPG) is a complete and free implementation of the OpenPGP standard which is commonly abbreviated as PGP. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries making use of GnuPG are available. 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 branches of GnuPG are actively maintained: - GnuPG "modern" (2.1) is the latest development with a lot of new features. This announcement is about this branch. - GnuPG "stable" (2.0) is the current stable version for general use. This is what most users are still 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. Noteworthy changes in version 2.1.12 ==================================== * gpg: New --edit-key sub-command "change-usage" for testing purposes. * gpg: Out of order key-signatures are now systematically detected and fixed by --edit-key. * gpg: Improved detection of non-armored messages. * gpg: Removed the extra prompt needed to create Curve25519 keys. * gpg: Improved user ID selection for --quick-sign-key. * gpg: Use the root CAs provided by the system with --fetch-key. * gpg: Add support for the experimental Web Key Directory key location service. * gpg: Improve formatting of Tofu messages and emit new Tofu specific status lines. * gpgsm: Add option --pinentry-mode to support a loopback pinentry. * gpgsm: A new pubring.kbx is now created with the header blob so that gpg can detect that the keybox format needs to be used. * agent: Add read support for the new private key protection format openpgp-s2k-ocb-aes. * agent: Add read support for the new extended private key format. * agent: Default to --allow-loopback-pinentry and add option --no-allow-loopback-pinentry. * scd: Changed to use the new libusb 1.0 API for the internal CCID driver. * dirmngr: The dirmngr-client does now auto-detect the PEM format. * g13: Add experimental support for dm-crypt. * w32: Tofu support is now available with the Speedo build method. * w32: Removed the need for libiconv.dll. * The man pages for gpg and gpgv are now installed under the correct name (gpg2 or gpg - depending on a configure option). * Lots of internal cleanups and bug fixes. A detailed description of the changes found in the 2.1 branch can be found at . Please be aware that there are still known bugs which we are working on. Check https://bugs.gnupg.org, https://wiki.gnupg.org, and the mailing list archives for known problems and workarounds. Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.1.12 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.12.tar.bz2 (5381k) ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.12.tar.bz2.sig or here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.12.tar.bz2 (5381k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.12.tar.bz2.sig An installer for Windows without any graphical frontend except for a basic Pinentry tool is available here: ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.12_20160504.exe (3477k) ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.12_20160504.exe.sig or here https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.12_20160504.exe (3477k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.12_20160504.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. This Windows installer comes with Tofu support, translations, and support for Tor and the Tor browser. It is still missing HKPS support, though. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.1.12.tar.bz2 you would use this command: gpg --verify gnupg-2.1.12.tar.bz2.sig gnupg-2.1.12.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.1.12.tar.bz2, you run the command like this: sha1sum gnupg-2.1.12.tar.bz2 and check that the output matches the next line: 3b01a35ac04277ea31cc01b4ac4e230e54b5480c gnupg-2.1.12.tar.bz2 0195d8b551e35b958f5efb4b678c3a178ba1ecb7 gnupg-w32-2.1.12_20160504.exe 2bad63245431a67fb4f076ec2b95f24b1ea1da0f gnupg-w32-2.1.12_20160504.tar.xz 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 keys from a keyserver using this command gpg --keyserver hkp://keys.gnupg.net --recv-keys \ 249B39D24F25E3B6 04376F3EE0856959 \ 2071B08A33BD3F06 8A861B1C7EFD60D9 The keys are also available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese, Czech, French, German, Japanese, Russian, and Ukrainian being almost completely translated (2166 different strings). Documentation ============= If you used GnuPG in the past you should read the description of changes and new features at doc/whats-new-in-2.1.txt or online at https://gnupg.org/faq/whats-new-in-2.1.html The file gnupg.info has the complete user manual of the system. Separate man pages are included as well but they have not all the details available as are the manual. It is also possible to read the complete manual online in HTML format at https://gnupg.org/documentation/manuals/gnupg/ or in Portable Document Format at https://gnupg.org/documentation/manuals/gnupg.pdf . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. You may also want search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. You may also want to follow our postings at . 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. As of today we employ 3 full-time developers, one part-timer, and one contractor. They all work on GnuPG and closely related software like Libgcrypt and GPA. Please consider to donate via: https://gnupg.org/donate/ Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, answering questions on the mailing lists, and donating money. 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 From bernhard at intevation.de Wed May 4 17:51:46 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 4 May 2016 17:51:46 +0200 Subject: EasyGpg2016/CertDistributionConcept work in progress Message-ID: <201605041751.51371.bernhard@intevation.de> Hi, there is a new wiki page which starts to document some of the design reasoning behind a proposed new way how to distribute, find and (somewhat) validate public OpenPGP keys. While it is not complete nor polished, you have early access to be able to comment: https://wiki.gnupg.org/EasyGpg2016/CertDistributionConcept Best Regards, Bernhard -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Wed May 4 17:53:58 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 04 May 2016 17:53:58 +0200 Subject: A new test framework: request for comments and testing In-Reply-To: <201605041612.00544.bernhard@intevation.de> (Bernhard Reiter's message of "Wed, 4 May 2016 16:11:56 +0200") References: <20160421151334.2180.54568@thinkbox.jade-hamburg.de> <201605040938.54300.bernhard@intevation.de> <87y47qx88j.fsf@wheatstone.g10code.de> <201605041612.00544.bernhard@intevation.de> Message-ID: <878tzpyg2x.fsf@wheatstone.g10code.de> On Wed, 4 May 2016 16:11, bernhard at intevation.de said: > Okay, it is online here https://mitpress.mit.edu/sicp/, > but sorry this is not a modern tutorial nor a good documentation > of TinyScheme. You do not need a documentation for TinyScheme but for our test framework. There has been none for the current /bin/sh based tests and thus the switch does not change the status of the documentation for those new to the code. > Compare this to TinyScheme, to be fair I include the reg exp and date > extensions: > 54k Mai 4 15:56 re-1.3.tar.gz We don't need them. > sloccount gives me almost 10k lines of code, 5000 lines. >> We considered to use Guile as a full fledged Scheme system but for >> obvious reasons we can't include it in GnuPG. > > You mean because guile-2.0.11.tar.gz is 7.3 MiByte large? > Yes, that is ~25 times as large as lua. Which is even larger then the bzip2 compressed gnupg tarball (which contains a _lot_ of translation stuff) >> "make check" as always. > > Doing an example command session, including the git checkout and separation > against potential existing gnupg installations will really enable some more > testers. I have some doubts that a tester not being able to git clone URL && cd gnupg && ./autogen.sh && ./configure && make check can write proper reports. And in fact the git repo is for development and bug reports should not be files against it. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed May 4 20:02:31 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 04 May 2016 20:02:31 +0200 Subject: A new test framework: request for comments and testing In-Reply-To: <20160421151334.2180.54568@thinkbox.jade-hamburg.de> (Justus Winter's message of "Thu, 21 Apr 2016 17:13:34 +0200") References: <20160421151334.2180.54568@thinkbox.jade-hamburg.de> Message-ID: <87futxvgzs.fsf@wheatstone.g10code.de> On Thu, 21 Apr 2016 17:13, justus at g10code.com said: > * it is completely self-contained, doesn't rely on e.g. cmp FWIW, while preparing 2.1.12 I had to remove your migrations test cases because there were problems with missing files after "make distcheck" and at least two portability problems: - mktemp is not portable; it is even not Posix. - basename(1) is not availabale on older Unices while gcc can be used there to have limited to support for C-99. BTW, instead of using "basename $x .asc" it is easier to use "${x%.asc}". Thus gpgscm will actually make it easier to write portable code. > Please accept my apologies for not communicating earlier what I was > doing and where we want to go. We plan to merge this after the 2.1.12 > release. Release done; now is the time to let McCarthy test our code. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From guilhem at fripost.org Wed May 4 21:43:49 2016 From: guilhem at fripost.org (Guilhem Moulin) Date: Wed, 4 May 2016 21:43:49 +0200 Subject: [Announce] GnuPG 2.1.12 released In-Reply-To: <87eg9hyhug.fsf@wheatstone.g10code.de> References: <87eg9hyhug.fsf@wheatstone.g10code.de> Message-ID: <20160504194349.GA12447@localhost.localdomain> Hi there, On Wed, 04 May 2016 at 17:15:51 +0200, Werner Koch wrote: > * gpg: Out of order key-signatures are now systematically detected > and fixed by --edit-key. This a great patch, but right now the user has to explicitly modify the key (for instance with ?clean? or ?adduid?) to execute that code. As I argued in [msg7913] (where I proposed a fix), it's desirable to have the ?check? save the reordered key too. Cheers, -- Guilhem. [msg7913] https://bugs.gnupg.org/gnupg/issue2236 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From wk at gnupg.org Fri May 6 10:22:48 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 06 May 2016 10:22:48 +0200 Subject: Web Key Directory In-Reply-To: <87eg9hyhug.fsf@wheatstone.g10code.de> (Werner Koch's message of "Wed, 04 May 2016 17:15:51 +0200") References: <87eg9hyhug.fsf@wheatstone.g10code.de> Message-ID: <871t5ftx2f.fsf@wheatstone.g10code.de> Hi! It has not been mentioned in the 2.1.12 announcement because it is still an experimental feature, but you may want to check it out anyway: The Web Key Directory is an experimental feature to retrieve a key via https. It is similar to OpenPGP DANE but also uses an encryption to reveal less information about a key lookup. For example the URI to lookup the key for Joe.Doe at Example.ORG is: https://example.org/.well-known/openpgpkey/ hu/example.org/iy9q119eutrkn8s1mk4r39qejnbu3n5q (line has been wrapped for rendering purposes). The hash is a z-Base-32 encoded SHA-1 hash of the mail address' local-part. The address wk at gnupg.org can be used for testing. (The published Windows installer does not yet support this due to its lack of TLS support). Here is an example: $ gpg --auto-key-locate clear,wkd,local --locate-key wk at gnupg.org gpg: key F2AD85AC1E42B367: "Werner Koch " not changed gpg: Total number processed: 1 gpg: unchanged: 1 gpg: automatically retrieved 'wk at gnupg.org' via WKD pub dsa2048/F2AD85AC1E42B367 2007-12-31 [SC] [expires: 2018-12-31] uid [ full ] Werner Koch [...] "clear" is used to override what I have in my gpg.conf, "wkd" is the new method, and "local" (i.e. the pubring.kbx) would we used if a key could not be found via wkd. Because a hash of the local-part is used there is also a new gpg option: $ gpg --with-wkd-hash -k F2AD85AC1E42B367 pub dsa2048/F2AD85AC1E42B367 2007-12-31 [SC] [expires: 2018-12-31] uid [ full ] Werner Koch nq6t9teux7edsnwdksswydu4o9i5es3f at gnupg.org [...] A draft specification can be found at https://tools.ietf.org/id/draft-koch-openpgp-webkey-service-00.txt This specification describes a service to locate OpenPGP keys by mail address using a Web service and the HTTPS protocol. It also provides a method for secure communication between the key owner and the mail provider to publish and revoke the public key. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri May 6 11:01:30 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 06 May 2016 11:01:30 +0200 Subject: [Announce] GnuPG 2.1.12 released In-Reply-To: <20160504194349.GA12447@localhost.localdomain> (Guilhem Moulin's message of "Wed, 4 May 2016 21:43:49 +0200") References: <87eg9hyhug.fsf@wheatstone.g10code.de> <20160504194349.GA12447@localhost.localdomain> Message-ID: <87mvo3sgph.fsf@wheatstone.g10code.de> On Wed, 4 May 2016 21:43, guilhem at fripost.org said: > key (for instance with ?clean? or ?adduid?) to execute that code. As I > argued in [msg7913] (where I proposed a fix), it's desirable to have the > ?check? save the reordered key too. It is a lot of new code and fear that we have introduced bugs which may inhibit the users ability to import certain keys. Thus I asked Neal to run this code only from --edit-key for now. As soon as we have some real world experience we will run it during import as well. Note that --edit-key will always run the code for self-signatures in any case. A warning will be printed if errors where found to remind the user to give the check command. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ag4ve.us at gmail.com Fri May 6 12:01:47 2016 From: ag4ve.us at gmail.com (shawn wilson) Date: Fri, 6 May 2016 06:01:47 -0400 Subject: dm-crypt feature In-Reply-To: References: Message-ID: I noticed this in the changelog: * g13: Add experimental support for dm-crypt. So what is this? What can I do with it? What documentation is there? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Fri May 6 13:57:11 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 06 May 2016 13:57:11 +0200 Subject: dm-crypt feature In-Reply-To: (shawn wilson's message of "Fri, 6 May 2016 06:01:47 -0400") References: Message-ID: <87bn4jqu08.fsf@wheatstone.g10code.de> On Fri, 6 May 2016 12:01, ag4ve.us at gmail.com said: > * g13: Add experimental support for dm-crypt. > > So what is this? What can I do with it? What documentation is there? Here is what Neal wrote in his blog entry from October: Werner has been working on g13. g13 is part of the GnuPG suite of tools. It provides support for working with DM-Crypt devices with OpenPGP keys and takes advantage of the existing GnuPG infrastructure. Currently, DM-Crypt is primarily used with LUKS. A LUKS encrypted volume has a small header at the start of the volume, which includes the master key encrypted with a passphrase. The passphrase is a weak point of the system as it is often vulnerable to a brute-force attack. A more secure approach is to encrypt the master key with a secret key stored on a smart card. Further, it should be possible to use existing keys. GnuPG, of course, has long had good support for interacting with smartcards and working with OpenPGP keys. I use it for my everyday work but we have no real documentation. Suspend/remove technically works but there are a couple of problems and non-implemented features. I have some things on my todo list, like the ability to run scripts (e.g. to start/stop dovecot), adding new encryption keys to the existing ones, making use of the extra copies of the encrypted session keys in case of problems. You need to create a file /etc/gnupg/g13tab which may look like this: # g13tab - Mount definitions for g13 # [