From gniibe at fsij.org Sat Oct 1 10:33:29 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Sat, 1 Oct 2016 17:33:29 +0900 Subject: [NPTH] npth and fork Message-ID: Hello, This summer, for AIX, I put a workaround for the issue 2260. That's basically, we have fork(2) inside GnuPG (gpg-agent, scdaemon), but it fails on AIX because of semaphore. After that, I learned that macOS also has an issue with unnamed semaphore. This week, I examined the code again, and concluded that current workaround for AIX and macOS is not that good, in fact. I have a new proposal. You can skip to PROPOSAL. * DETAIL of current implementation of nPth in master In nPth, we have a semaphore to control threads execution so that only a single thread can run at a time. On GNU/Linux, FreeBSD, etc., it is a unnamed semaphore which is private to a process. According to POSIX specification and OS manuals, it is not clear if fork(2) is safe or not for the use of such semaphore, but it works well on those systems. On AIX, it is explicitly addressed in the OS manual and unnamed private semaphore is not safe in a child process (access is prohibited by child process). So, I added a workaorund to allocate a unnamed semaphore which is shareable among processes. On macOS, unnamed semaphore doesn't work well (although we have a defined symbol in the library), and it falls back to a named semaphore at runtime. This week, I realized that nPth with a named/shareable semaphore runs not that correctly. Let's see how it goes. (1) npth_init A semaphore is allocated by npth_init function. (2) fork When a thread calls fork(2), new child process is created. The semaphore is shared between a parent process and newly created child process. Here, both of parent and child consider they "own" the resource. For the specific use cases in GnuPG, it is to be a daemon, there is no problem; It is only a single side of process among two processes which continues to run as nPth application program. If both processes try to keep running as nPth application program, each process goes wrong because of shared semaphore: two threads can run simultaneously in a process. * PROPOSAL It is better to use unnamed private semaphore for all OSes. For macOS, I think that the semaphore in "Grand Central Dispatch" instead of POSIX named semaphore is good. Note that Grand Central Dispatch implementation also prohibits use of semaphore after fork. For those OSes which prohibits use of already-allocated-semaphore-by-parent after fork, we call pthread_atfork at npth_init; We setup a callback for child. In the callback for child, the child process initializes a unnamed semaphore, so that threads can be controlled by the semaphore. -- From gniibe at fsij.org Mon Oct 3 03:13:20 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 3 Oct 2016 10:13:20 +0900 Subject: [NPTH] npth and fork In-Reply-To: References: Message-ID: On 10/01/2016 05:33 PM, NIIBE Yutaka wrote: > * PROPOSAL > > It is better to use unnamed private semaphore for all OSes. For > macOS, I think that the semaphore in "Grand Central Dispatch" instead > of POSIX named semaphore is good. > > Note that Grand Central Dispatch implementation also prohibits use of > semaphore after fork. > > For those OSes which prohibits use of > already-allocated-semaphore-by-parent after fork, we call > pthread_atfork at npth_init; We setup a callback for child. In the > callback for child, the child process initializes a unnamed semaphore, > so that threads can be controlled by the semaphore. Considering again, it is best to document in nPth that fork is only allowed in a way that child will soon exec another program under the condition of no nPth access. The specific use case of fork to daemonize a program should be done _before_ calling npth_init, ideally. I'm going to examine code of gpg-agent and scdaemon if fix is easy. -- From gniibe at fsij.org Mon Oct 3 05:44:30 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 3 Oct 2016 12:44:30 +0900 Subject: [NPTH] npth and fork In-Reply-To: References: Message-ID: On 10/03/2016 10:13 AM, NIIBE Yutaka wrote: > The specific use case of fork to daemonize a program should be done > _before_ calling npth_init, ideally. > > I'm going to examine code of gpg-agent and scdaemon if fix is easy. Here is the change. We also have dirmngr. This change may be fragile. No call/access should be done before npth_init and I tried to do so, but possibly, I missed. diff --git a/agent/gpg-agent.c b/agent/gpg-agent.c index 15202ac..f56e29e 100644 --- a/agent/gpg-agent.c +++ b/agent/gpg-agent.c @@ -718,6 +718,16 @@ finalize_rereadable_options (void) } +static void +initialize_modules (void) +{ + npth_init (); + initialize_module_cache (); + initialize_module_call_pinentry (); + initialize_module_call_scd (); + initialize_module_trustlist (); +} + /* The main entry point. */ int @@ -765,8 +775,6 @@ main (int argc, char **argv ) i18n_init (); init_common_subsystems (&argc, &argv); - npth_init (); - malloc_hooks.malloc = gcry_malloc; malloc_hooks.realloc = gcry_realloc; malloc_hooks.free = gcry_free; @@ -1080,11 +1088,6 @@ main (int argc, char **argv ) exit (1); } - initialize_module_cache (); - initialize_module_call_pinentry (); - initialize_module_call_scd (); - initialize_module_trustlist (); - /* Try to create missing directories. */ create_directories (); @@ -1196,6 +1199,8 @@ main (int argc, char **argv ) /* This is the simple pipe based server */ ctrl_t ctrl; + initialize_modules (); + ctrl = xtrycalloc (1, sizeof *ctrl); if (!ctrl) { @@ -1403,6 +1408,8 @@ main (int argc, char **argv ) This is the child */ + initialize_modules (); + /* Detach from tty and put process into a new session */ if (!nodetach ) { diff --git a/dirmngr/dirmngr.c b/dirmngr/dirmngr.c index 64d93b7..621c2bb 100644 --- a/dirmngr/dirmngr.c +++ b/dirmngr/dirmngr.c @@ -647,6 +647,22 @@ pid_suffix_callback (unsigned long *r_suffix) #endif /*!HAVE_W32_SYSTEM*/ +static void +thread_init (void) +{ + npth_init (); + + /* Now with NPth running we can set the logging callback. Our + windows implementation does not yet feature the NPth TLS + functions. */ +#ifndef HAVE_W32_SYSTEM + if (npth_key_create (&my_tlskey_current_fd, NULL) == 0) + if (npth_setspecific (my_tlskey_current_fd, NULL) == 0) + log_set_pid_suffix_cb (pid_suffix_callback); +#endif /*!HAVE_W32_SYSTEM*/ +} + + int main (int argc, char **argv) { @@ -680,8 +696,6 @@ main (int argc, char **argv) i18n_init (); init_common_subsystems (&argc, &argv); - npth_init (); - gcry_control (GCRYCTL_DISABLE_SECMEM, 0); /* Check that the libraries are suitable. Do it here because @@ -722,15 +736,6 @@ main (int argc, char **argv) if (shell && strlen (shell) >= 3 && !strcmp (shell+strlen (shell)-3, "csh") ) csh_style = 1; - /* Now with NPth running we can set the logging callback. Our - windows implementation does not yet feature the NPth TLS - functions. */ -#ifndef HAVE_W32_SYSTEM - if (npth_key_create (&my_tlskey_current_fd, NULL) == 0) - if (npth_setspecific (my_tlskey_current_fd, NULL) == 0) - log_set_pid_suffix_cb (pid_suffix_callback); -#endif /*!HAVE_W32_SYSTEM*/ - /* Reset rereadable options to default values. */ parse_rereadable_options (NULL, 0); @@ -981,6 +986,7 @@ main (int argc, char **argv) ldap_wrapper_launch_thread (); #endif /*USE_LDAP*/ + thread_init (); cert_cache_init (); crl_cache_init (); start_command_handler (ASSUAN_INVALID_FD); @@ -1179,6 +1185,7 @@ main (int argc, char **argv) ldap_wrapper_launch_thread (); #endif /*USE_LDAP*/ + thread_init (); cert_cache_init (); crl_cache_init (); handle_connections (fd); @@ -1206,6 +1213,7 @@ main (int argc, char **argv) #if USE_LDAP ldap_wrapper_launch_thread (); #endif /*USE_LDAP*/ + thread_init (); cert_cache_init (); crl_cache_init (); if (!argc) @@ -1231,6 +1239,7 @@ main (int argc, char **argv) #if USE_LDAP ldap_wrapper_launch_thread (); #endif /*USE_LDAP*/ + thread_init (); cert_cache_init (); crl_cache_init (); rc = crl_fetch (&ctrlbuf, argv[0], &reader); diff --git a/scd/scdaemon.c b/scd/scdaemon.c index bf54d95..3571e66 100644 --- a/scd/scdaemon.c +++ b/scd/scdaemon.c @@ -422,8 +422,6 @@ main (int argc, char **argv ) i18n_init (); init_common_subsystems (&argc, &argv); - npth_init (); - ksba_set_malloc_hooks (gcry_malloc, gcry_realloc, gcry_free); malloc_hooks.malloc = gcry_malloc; @@ -724,6 +722,8 @@ main (int argc, char **argv ) } #endif + npth_init (); + /* If --debug-allow-core-dump has been given we also need to switch the working directory to a place where we can actually write. */ @@ -861,6 +861,8 @@ main (int argc, char **argv ) /* This is the child. */ + npth_init (); + /* Detach from tty and put process into a new session. */ if (!nodetach ) { -- From gniibe at fsij.org Mon Oct 3 09:06:29 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 3 Oct 2016 16:06:29 +0900 Subject: [PINENTRY PATCH] tty button-related fixes and refinements In-Reply-To: <20160927040242.GM30569@gnu.org> References: <20160408174738.GA26817@gnu.org> <20160927040242.GM30569@gnu.org> Message-ID: <4806cab2-483e-48f2-7807-9866d81ab1d2@fsij.org> On 09/27/2016 01:02 PM, Ineiev wrote: > On Fri, Apr 08, 2016 at 01:47:38PM -0400, Ineiev wrote: >> >> I attach some fixes I've come up with when playing with non-ASCII >> texts in buttons. >> >> The first one simplifies key checking code a little bit; the second >> one fixes a few bugs in underscore processing; the third one lets >> the user see the localized message even if the pinentry doesn't >> support its accelerators (by the way, I think that pinentry >> should localize the messages that aren't customized from the agent, >> like "Press any key to continue."); the last one adds a default >> message to a call of button() so that pinentry won't skip a button >> when its text is localized. > > I've fixed a few typos in comments and log messages. Thank you for your fixes. I applied three bug fixes, with commit message edit by me. 0001-tty-Refactor-usage-of-tolower.patch 0002-tty-Fix-underscore-processing-in-accelerators.patch 0004-tty-Avoid-using-button-with-NULL-default-text.patch For 0001, I modified your change a bit to keep the output for input key is as same as before. The patch: 0003-tty-Show-supplied-message-when-using-default.patch is introducing a new feature. Let me have (more) time to review this closely. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From ineiev at gnu.org Mon Oct 3 17:49:52 2016 From: ineiev at gnu.org (Ineiev) Date: Mon, 3 Oct 2016 11:49:52 -0400 Subject: [PINENTRY PATCH] tty button-related fixes and refinements In-Reply-To: <4806cab2-483e-48f2-7807-9866d81ab1d2@fsij.org> References: <20160408174738.GA26817@gnu.org> <20160927040242.GM30569@gnu.org> <4806cab2-483e-48f2-7807-9866d81ab1d2@fsij.org> Message-ID: <20161003154952.GK30569@gnu.org> On Mon, Oct 03, 2016 at 04:06:29PM +0900, NIIBE Yutaka wrote: > > I applied three bug fixes, with commit message edit by me. > > 0001-tty-Refactor-usage-of-tolower.patch > 0002-tty-Fix-underscore-processing-in-accelerators.patch > 0004-tty-Avoid-using-button-with-NULL-default-text.patch Thank you! > For 0001, I modified your change a bit to keep the output for input > key is as same as before. Indeed, I could have written that part more carefully. > The patch: > > 0003-tty-Show-supplied-message-when-using-default.patch > > is introducing a new feature. Let me have (more) time to review this > closely. It may be thought of as a new feature, but I think it's essential for making pinentry work reliably, especially when the translator doesn't care of pinentry-tty. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From gniibe at fsij.org Tue Oct 4 02:49:11 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 4 Oct 2016 09:49:11 +0900 Subject: [NPTH] npth and fork In-Reply-To: References: Message-ID: On 10/03/2016 12:44 PM, NIIBE Yutaka wrote: > On 10/03/2016 10:13 AM, NIIBE Yutaka wrote: >> The specific use case of fork to daemonize a program should be done >> _before_ calling npth_init, ideally. >> >> I'm going to examine code of gpg-agent and scdaemon if fix is easy. > > Here is the change. We also have dirmngr. > > This change may be fragile. No call/access should be done before /\ of npth_* > npth_init and I tried to do so, but possibly, I missed. For gpg-agent, I found npth_* calls through assuan_connect, and fixed by deferring call of assuan_set_system_hooks. Also for gpg-agent, I found gnupg_sleep calls npth_*. It is fixed by introducing thread_init_once. Then, I pushed the change to master. Now, I would like to change nPth for macOS. Currently, it uses named semaphore detecting the failure of sem_init at runtime. I think that use of unnamed semaphore of Grand Central Dispatch is better. -- From wk at gnupg.org Tue Oct 4 10:41:56 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 04 Oct 2016 10:41:56 +0200 Subject: [PINENTRY PATCH v2 1/2] gnome3: drop unnecessary use of gtk In-Reply-To: <20160909084346.27394-1-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 9 Sep 2016 10:43:45 +0200") References: <20160829235548.17173-1-dkg@fifthhorseman.net> <20160909084346.27394-1-dkg@fifthhorseman.net> Message-ID: <87fuocpktn.fsf@wheatstone.g10code.de> On Fri, 9 Sep 2016 10:43, dkg at fifthhorseman.net said: > pinentry-gnome3 really just uses gcr and libsecret -- there is no > direct use of gtk at all. By linking only to the minimal gcr-base-3 > and avoiding gcr-3 itself, we remove many unnecessary library > dependencies from pinentry-gnome3. Pushed. Thanks. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From wk at gnupg.org Tue Oct 4 10:54:21 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 04 Oct 2016 10:54:21 +0200 Subject: [PINENTRY PATCH v2 2/2] pinentry-gnome3: fall back to curses if gcr prompt creation fails In-Reply-To: <20160909084346.27394-2-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 9 Sep 2016 10:43:46 +0200") References: <20160829235548.17173-1-dkg@fifthhorseman.net> <20160909084346.27394-1-dkg@fifthhorseman.net> <20160909084346.27394-2-dkg@fifthhorseman.net> Message-ID: <87bmz0pk8y.fsf@wheatstone.g10code.de> On Fri, 9 Sep 2016 10:43, dkg at fifthhorseman.net said: > In some cases, the user is running in a session that has an active > D-Bus session, but that session is not attached to a graphical desktop > environment (e.g. sshing into a machine whose login stack initializes > a D-Bus session). In that case, gcr can be reached over dbus, but it > will complain that it does not know how to prompt the user. This happens also if you have not a full GNOME installation, which is the case for me. The problems I see witch your patch is that the fallback to curses 1. could also triggered by other errors 2. that it may happen during a running pinentry session in case the SystemPromper gets removed of installed during the session. That would be pretty suprising. I would prefer to return a better error message instead of the auto fallback. The idea with the auto fallback is that it is used if a user switches between a plain tty and an Xsession. But not to resolve configuration errors. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From fabio.coatti at gmail.com Tue Oct 4 15:15:05 2016 From: fabio.coatti at gmail.com (Fabio Coatti) Date: Tue, 04 Oct 2016 15:15:05 +0200 Subject: scdaemon (possible?) lockup Message-ID: <7455218.qWm7FkoZvf@calvin> Hi All, I'm experiencing some lockups on scdaemon and searching around yelded no hints. Description: (gnupg 2.1.15) I have a HP laptop with a smartcard reader - identified as Alcor AU9540 that I use with a gnupgcard. I have power settings for the reader set to "auto", that means that it gets powered off by the kernel when not in use (kernel 4.7.6) What happens can be summarized as if follows: - card inserted cova at calvin ~ $ gpg --card-status gpg: selecting openpgp failed: Errore della scheda gpg: OpenPGP card not available: Errore della scheda (basically, card error) If I remove the card I get the same error instead of "Card not present". If I kill scdaemon, cova at calvin ~ $ killall scdaemon then I get the (correct) message cova at calvin ~ $ gpg --card-status gpg: selecting openpgp failed: Scheda non presente gpg: OpenPGP card not available: Scheda non presente Inserting the card again, I'm back to "Card error" situation. So it seems thaat scdaemon gets stuck in "card not present" situation and it takes a kill to fix it. It seems likely that this issue can be related to scdaemon. Next, forcing the smartcard reader to be always powered and not suspended the behaviour is different: starting from a "card error" status, like cova at calvin ~ $ gpg --card-status gpg: selecting openpgp failed: Errore della scheda gpg: OpenPGP card not available: Errore della scheda if I kill scdaemon and then issue a gpg --card-status, everyting works with no issues. So my questions are: 1) is it possible that when scdaemon enters the "card error" status it is not able to exit it unless killed and restarted? 2) is it possible that with kernel turning on and off the power for the reader, the reader itself requires more time to become operational that allowed by scdaemon, that then enters into error condition and so behaving like described in 1?) Many thanks for any answer. If anything above seems reasonable, I can try to have a look at the code, even if I'm not, by any means, an expert. -- Fabio From wk at gnupg.org Tue Oct 4 17:23:06 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 04 Oct 2016 17:23:06 +0200 Subject: [PATCH v3 3/5] gpg-agent: Implement --supervised command (for systemd, etc). In-Reply-To: <1470980281-2675-4-git-send-email-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 12 Aug 2016 01:37:59 -0400") References: <87vaz7rq1k.fsf@alice.fifthhorseman.net> <1470980281-2675-1-git-send-email-dkg@fifthhorseman.net> <1470980281-2675-4-git-send-email-dkg@fifthhorseman.net> Message-ID: <87oa30jfz9.fsf@wheatstone.g10code.de> Hi! I have applied your patch as well as a few other updates regarding that new feature. For example it is now required that getsockopt works and returns a valid socket name. I have done a few cursory tests by creating a few sockets inside gpg-agent to test the map_supervised_sockets functions but not much more. I would appreciate if you can test this with systemd; I would then use the same code for dirmngr. I would like to do a 2.1.16 this week. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From dkg at fifthhorseman.net Tue Oct 4 17:45:19 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 04 Oct 2016 11:45:19 -0400 Subject: [PINENTRY PATCH v2 2/2] pinentry-gnome3: fall back to curses if gcr prompt creation fails In-Reply-To: <87bmz0pk8y.fsf@wheatstone.g10code.de> References: <20160829235548.17173-1-dkg@fifthhorseman.net> <20160909084346.27394-1-dkg@fifthhorseman.net> <20160909084346.27394-2-dkg@fifthhorseman.net> <87bmz0pk8y.fsf@wheatstone.g10code.de> Message-ID: <871szw9kz4.fsf@alice.fifthhorseman.net> On Tue 2016-10-04 04:54:21 -0400, Werner Koch wrote: > On Fri, 9 Sep 2016 10:43, dkg at fifthhorseman.net said: > >> In some cases, the user is running in a session that has an active >> D-Bus session, but that session is not attached to a graphical desktop >> environment (e.g. sshing into a machine whose login stack initializes >> a D-Bus session). In that case, gcr can be reached over dbus, but it >> will complain that it does not know how to prompt the user. > > This happens also if you have not a full GNOME installation, which is > the case for me. > > The problems I see witch your patch is that the fallback to curses > > 1. could also triggered by other errors I'd be happy to narrowly target some specific error message if you would rather do that, by testing error->code and/or error->domain. What specific error case do you think is acceptable to handle? > 2. that it may happen during a running pinentry session in case the > SystemPromper gets removed of installed during the session. That > would be pretty suprising. gpg and gpg-agent and pinentry probably have more of these sorts of race conditions, especially around package installation or removal. I think a surprise during package removal would be be bad, but i think it would be outweighed by the good of having pinentry-gnome3 actually provide a prompt when dbus is running but no graphical session is in place. > I would prefer to return a better error message instead of the auto > fallback. The idea with the auto fallback is that it is used if a user > switches between a plain tty and an Xsession. But not to resolve > configuration errors. I'm not sure it's a configuration error. Consider a machine where the configuration is that pinentry should be pinentry-gnome3. I log in on the graphical console and get gnome3-style prompts. then i log out of the graphical console, and i log in on the text-mode virtual terminal. I should now get curses prompts. right? except that doesn't currently work, because i have a dbus session but no graphical session. What is the "configuration error" in this case? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From dkg at fifthhorseman.net Tue Oct 4 19:00:04 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 04 Oct 2016 13:00:04 -0400 Subject: [PATCH v3 3/5] gpg-agent: Implement --supervised command (for systemd, etc). In-Reply-To: <87oa30jfz9.fsf@wheatstone.g10code.de> References: <87vaz7rq1k.fsf@alice.fifthhorseman.net> <1470980281-2675-1-git-send-email-dkg@fifthhorseman.net> <1470980281-2675-4-git-send-email-dkg@fifthhorseman.net> <87oa30jfz9.fsf@wheatstone.g10code.de> Message-ID: <87pong82y3.fsf@alice.fifthhorseman.net> On Tue 2016-10-04 11:23:06 -0400, Werner Koch wrote: > I have applied your patch as well as a few other updates regarding that > new feature. For example it is now required that getsockopt works and > returns a valid socket name. I have done a few cursory tests by > creating a few sockets inside gpg-agent to test the > map_supervised_sockets functions but not much more. I would appreciate > if you can test this with systemd; I would then use the same code for > dirmngr. great! I'll take a look at the code and try it out and get back to you with a report. > I would like to do a 2.1.16 this week. that would be a good thing. thanks for this work! --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From dkg at fifthhorseman.net Tue Oct 4 20:41:41 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 04 Oct 2016 14:41:41 -0400 Subject: python-gnupg uses "gpg --with-fingerprint --with-colons FILENAME" -- is this supported? Message-ID: <87mvik7y8q.fsf@alice.fifthhorseman.net> Hi GnuPG folks, in the python-gnupg module maintained by Vinay Sajip (cc'ed here), it tries to scan a file containing keys by using the following command line: gpg --with-fingerprint --with-colons FILENAME https://bitbucket.org/vinay.sajip/python-gnupg/src/13e347b44785dd0ace0e9101b8940466b271fc08/gnupg.py?at=default#gnupg.py-1198 """ List details of an ascii armored or binary key file without first importing it to the local keyring. The function achieves this by running: $ gpg --with-fingerprint --with-colons filename """ Is this a supported use case? This appears to be using no explicit command, which means it's taking advantage of the following section in gpg(1): gpg may be run with no commands, in which case it will perform a rea? sonable action depending on the type of file it is given as input (an encrypted message is decrypted, a signature is verified, a file con? taining keys is listed). If the desired action is "a file containing keys is listed", maybe it would make more sense to explicitly provide a command that does this? I don't see a way to make an explicit command for it -- it seems to be handled inside the aListPackets: clause of switch(cmd) in main() in g10/gpg.c, but it is distinct from --list-packets because packet_list_mode is not set. Making matters worse, the output of this non-command actually differs between gpg 1.4 and 2.1, even when 1.4 is using --fixed-list-mode: 0 dkg at alice:/tmp/cdtemp.uaInIQ$ diff -u <(gpg1 --homedir $(pwd) --fixed-list-mode --with-colons dkg-test.asc ) <(gpg --homedir $(pwd) --with-colons dkg-test.asc ) --- /dev/fd/63 2016-10-04 14:27:05.473568896 -0400 +++ /dev/fd/62 2016-10-04 14:27:05.473568896 -0400 @@ -1,2 +1,3 @@ -pub:-:4096:1:CCD2ED94D21739E9:1180812858:1483512006::-:Daniel Kahn Gillmor : +pub:-:4096:1:CCD2ED94D21739E9:1180812858:1483512006::-: +uid:::::::::Daniel Kahn Gillmor : uid:::::::::Daniel Kahn Gillmor : 1 dkg at alice:/tmp/cdtemp.uaInIQ$ (the test file i used is attached if you want to try to replicate this) I'm not sure of the proper way to approach this situation. is it: * a bug in --fixed-list-mode in 1.4? * a bug in the output of 2.1, since it is effectively an API break from previous versions? * an unsupported mode for programmatic use, since the behavior will vary depending on the contents of FILENAME (thus making it a bug that python-gnupg even tries to use this)? * something else? Any thoughts or pointers welcome, --dkg -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dkg-test.asc URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From dkg at fifthhorseman.net Tue Oct 4 20:50:34 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 04 Oct 2016 14:50:34 -0400 Subject: python-gnupg uses "gpg --with-fingerprint --with-colons FILENAME" -- is this supported? In-Reply-To: <87mvik7y8q.fsf@alice.fifthhorseman.net> References: <87mvik7y8q.fsf@alice.fifthhorseman.net> Message-ID: <87k2do7xtx.fsf@alice.fifthhorseman.net> fwiw, the scan_keys() function in python-gnupg isn't actually used by anything in debian which depends on python-gnupg, according to: https://codesearch.debian.net/search?q=scan_keys&perpkg=1 so from debian's overall system perspective, we could just go with this "solution", as sad as it is: On Tue 2016-10-04 14:41:41 -0400, Daniel Kahn Gillmor wrote: > * an unsupported mode for programmatic use, since the behavior will > vary depending on the contents of FILENAME (thus making it a bug that > python-gnupg even tries to use this)? This might make some people sad who are relying on this python API for their private code, however. Does PyME have a mechanism that would perform the same functionality? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From wk at gnupg.org Tue Oct 4 21:04:32 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 04 Oct 2016 21:04:32 +0200 Subject: python-gnupg uses "gpg --with-fingerprint --with-colons FILENAME" -- is this supported? In-Reply-To: <87mvik7y8q.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 04 Oct 2016 14:41:41 -0400") References: <87mvik7y8q.fsf@alice.fifthhorseman.net> Message-ID: <878tu4j5q7.fsf@wheatstone.g10code.de> On Tue, 4 Oct 2016 20:41, dkg at fifthhorseman.net said: > * a bug in --fixed-list-mode in 1.4? Yes. > * an unsupported mode for programmatic use, since the behavior will > vary depending on the contents of FILENAME (thus making it a bug that > python-gnupg even tries to use this)? It is not good to use this with unknown data because the default action depends on the data. With 2.1 it is possible to use --with-colons --always-trust \ --dry-run --import-options import-show --import to list a key w/o changing any state. For an example see gnupg/tools/gpg-wks-server.c Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From wk at gnupg.org Tue Oct 4 21:08:31 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 04 Oct 2016 21:08:31 +0200 Subject: python-gnupg uses "gpg --with-fingerprint --with-colons FILENAME" -- is this supported? In-Reply-To: <87k2do7xtx.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 04 Oct 2016 14:50:34 -0400") References: <87mvik7y8q.fsf@alice.fifthhorseman.net> <87k2do7xtx.fsf@alice.fifthhorseman.net> Message-ID: <874m4sj5jk.fsf@wheatstone.g10code.de> On Tue, 4 Oct 2016 20:50, dkg at fifthhorseman.net said: > their private code, however. Does PyME have a mechanism that would > perform the same functionality? I can imagine a special key listing mode for gpgme (and thus pyme) using the --import-options import-show feature I mentioned in the other mail. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From dkg at fifthhorseman.net Tue Oct 4 22:17:57 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 04 Oct 2016 16:17:57 -0400 Subject: avoiding long trustdb updates Message-ID: <878tu398cq.fsf@alice.fifthhorseman.net> Hi GnuPG folks-- I noticed this in git master: commit de67055aff916455cec89fab1d95177d3b383008 Author: Werner Koch Date: Fri Sep 30 16:58:10 2016 +0200 wks: Avoid long trustdb checks. * tools/wks-receive.c (verify_signature): Use --always-trust. Signed-off-by: Werner Koch diff --git a/tools/wks-receive.c b/tools/wks-receive.c index 0deca9b..7292cff 100644 --- a/tools/wks-receive.c +++ b/tools/wks-receive.c @@ -164,6 +164,7 @@ verify_signature (receive_ctx_t ctx) ccparray_put (&ccp, "--verbose"); ccparray_put (&ccp, "--enable-special-filenames"); ccparray_put (&ccp, "--status-fd=2"); + ccparray_put (&ccp, "--always-trust"); /* To avoid trustdb checks. */ ccparray_put (&ccp, "--verify"); ccparray_put (&ccp, "--"); ccparray_put (&ccp, "-&@INEXTRA@"); Is there a reason to use --always-trust here instead of --no-auto-check-trustdb ? --always-trust seems like it should have more side effects in terms of how gpg operates, and if the goal is just "to avoid trustdb checks" then it seems like we might prefer --no-auto-check-trustdb. what do you think? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From kristian.fiskerstrand at sumptuouscapital.com Tue Oct 4 22:55:47 2016 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 4 Oct 2016 22:55:47 +0200 Subject: avoiding long trustdb updates In-Reply-To: <878tu398cq.fsf@alice.fifthhorseman.net> References: <878tu398cq.fsf@alice.fifthhorseman.net> Message-ID: <52e05f20-3125-1c80-b179-b4a78d19898e@sumptuouscapital.com> On 10/04/2016 10:17 PM, Daniel Kahn Gillmor wrote: > Is there a reason to use --always-trust here instead of > --no-auto-check-trustdb ? --always-trust seems like it should have more > side effects in terms of how gpg operates, and if the goal is just "to > avoid trustdb checks" then it seems like we might prefer > --no-auto-check-trustdb. > > what do you think? Presumably wks doesn't depend on any trust checks as it doesn't have WoT and only requires to verify for the keyblock in question. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "The power of accurate observation is commonly called cynicism by those who have not got it." George Bernard Shaw -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Wed Oct 5 01:33:05 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 5 Oct 2016 08:33:05 +0900 Subject: scdaemon (possible?) lockup In-Reply-To: <7455218.qWm7FkoZvf@calvin> References: <7455218.qWm7FkoZvf@calvin> Message-ID: <74054ad8-d6d9-4243-3190-7f4ac6073b72@fsij.org> Hello, On 10/04/2016 10:15 PM, Fabio Coatti wrote: > If I kill scdaemon, > cova at calvin ~ $ killall scdaemon This doesn't kill scdaemon because scdaemon has a signal handler for SIGTERM (If you really want to do this way, you need sending signal at least two times to scdaemon). Instead, please do this: $ gpgconf --reload scdaemon -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Wed Oct 5 06:23:11 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 5 Oct 2016 00:23:11 -0400 Subject: [PATCH] agent: Fix error handling in map_supervised_sockets Message-ID: <20161005042311.10085-1-dkg@fifthhorseman.net> * agent/gpg-agent.c (map_supervised_sockets): the file descriptor to close on error is fd, not i. Signed-off-by: Daniel Kahn Gillmor --- agent/gpg-agent.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/agent/gpg-agent.c b/agent/gpg-agent.c index 1696e5a..9c7b8fc 100644 --- a/agent/gpg-agent.c +++ b/agent/gpg-agent.c @@ -758,14 +758,14 @@ map_supervised_sockets (gnupg_fd_t *r_fd, { log_error ("cannot listen on fd %d for %s socket\n", fd, tbl[j].label); - close (i); + close (fd); } } else { log_error ("cannot listen on more than one %s socket\n", tbl[j].label); - close (i); + close (fd); } break; } -- 2.9.3 From dkg at fifthhorseman.net Wed Oct 5 06:51:25 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 05 Oct 2016 00:51:25 -0400 Subject: [PATCH v3 3/5] gpg-agent: Implement --supervised command (for systemd, etc). In-Reply-To: <87oa30jfz9.fsf@wheatstone.g10code.de> References: <87vaz7rq1k.fsf@alice.fifthhorseman.net> <1470980281-2675-1-git-send-email-dkg@fifthhorseman.net> <1470980281-2675-4-git-send-email-dkg@fifthhorseman.net> <87oa30jfz9.fsf@wheatstone.g10code.de> Message-ID: <87vax7760i.fsf@alice.fifthhorseman.net> Hi Werner et al-- On Tue 2016-10-04 11:23:06 -0400, Werner Koch wrote: > I have applied your patch as well as a few other updates regarding that > new feature. For example it is now required that getsockopt works and > returns a valid socket name. I have done a few cursory tests by > creating a few sockets inside gpg-agent to test the > map_supervised_sockets functions but not much more. I would appreciate > if you can test this with systemd; I would then use the same code for > dirmngr. I've tested this and there are a few problems still aside from the patch i've sent to the list. 0) when running --supervised with a logfile directive, gpg-agent aborts at startup. Removing the logfile directive allows the agent to start up fine. I haven't diagnosed this further, because i ran into the next problem ? 1) when running --supervised, i see regular hangs of the agent which are not seen when it is auto-launched. When using gpg-agent not under systemd supervision (auto-launched), strace on the main process looks like the following (we see several select()-based timeouts, followed by a few quick forks, followed by more select()s etc): ?more pselect6()'s? pselect6(8, [3 4 5 6 7], NULL, NULL, {2, 1762}, {[], 8}) = 0 (Timeout) pselect6(8, [3 4 5 6 7], NULL, NULL, {2, 1204}, {[], 8}) = 0 (Timeout) clone(child_stack=0x7f933435bff0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f933435c9d0, tls=0x7f933435c700, child_tidptr=0x7f933435c9d0) = 10593 futex(0x7f9334cff200, FUTEX_WAKE_PRIVATE, 1) = 1 pselect6(8, [3 4 5 6 7], NULL, NULL, {2, 217785}, {[], 8}) = 1 (in [3], left {2, 211320}) accept(3, {sa_family=AF_LOCAL, NULL}, [2]) = 9 mmap(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f933335b000 mprotect(0x7f933335b000, 4096, PROT_NONE) = 0 clone(child_stack=0x7f9333b5aff0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f9333b5b9d0, tls=0x7f9333b5b700, child_tidptr=0x7f9333b5b9d0) = 10594 futex(0x7f9334cff200, FUTEX_WAKE_PRIVATE, 1) = 1 pselect6(8, [3 4 5 6 7], NULL, NULL, {1, 999208864}, {[], 8}) = 0 (Timeout) pselect6(8, [3 4 5 6 7], NULL, NULL, {2, 1184}, {[], 8}) = 0 (Timeout) ?more pselect6()'s? I suspect this is the whole "check if my socket is reachable" business. But when running --supervised, the self-triggered timeout does several different different syscalls, and then hangs in a futex: ?more pselect6()'s? pselect6(8, [3 4 5 6 7], NULL, NULL, {2, 1806}, {[], 8}) = 0 (Timeout) pselect6(8, [3 4 5 6 7], NULL, NULL, {2, 1802}, {[], 8}) = 0 (Timeout) getuid() = 1000 stat("/run/user/1000", {st_mode=S_IFDIR|0700, st_size=180, ...}) = 0 getuid() = 1000 stat("/run/user/1000/gnupg", {st_mode=S_IFDIR|0700, st_size=140, ...}) = 0 getuid() = 1000 clone(child_stack=0x7fb4bfd25ff0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7fb4bfd269d0, tls=0x7fb4bfd26700, child_tidptr=0x7fb4bfd269d0) = 10473 futex(0x7fb4c06c9200, FUTEX_WAKE_PRIVATE, 1) = 1 pselect6(8, [3 4 5 6 7], NULL, NULL, {2, 761217}, {[], 8}) = 1 (in [5], left {2, 723370}) futex(0x7fb4c06c9200, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, ffffffff When it's hung in this state, i see the following backtrace: 0x00007fdf1586c577 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x7fdf15c7e200) at ../sysdeps/unix/sysv/linux/futex-internal.h:205 205 ../sysdeps/unix/sysv/linux/futex-internal.h: No such file or directory. (gdb) bt #0 0x00007fdf1586c577 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x7fdf15c7e200) at ../sysdeps/unix/sysv/linux/futex-internal.h:205 #1 do_futex_wait (sem=sem at entry=0x7fdf15c7e200, abstime=0x0) at sem_waitcommon.c:111 #2 0x00007fdf1586c624 in __new_sem_wait_slow (sem=0x7fdf15c7e200, abstime=0x0) at sem_waitcommon.c:181 #3 0x00007fdf15a7bcf9 in ?? () from /usr/lib/x86_64-linux-gnu/libnpth.so.0 #4 0x00007fdf15a7c303 in npth_pselect () from /usr/lib/x86_64-linux-gnu/libnpth.so.0 #5 0x000055ff7d27d3c2 in handle_connections (listen_fd=, listen_fd_extra=, listen_fd_browser=, listen_fd_ssh=) at ../../agent/gpg-agent.c:2920 #6 0x000055ff7d27a43e in main (argc=, argv=) at ../../agent/gpg-agent.c:1501 (sorry, these line numbers aren't the same as git master, i'm working From slightly modified source). I'm using npth 1.2-3 in debian, fwiw. Any thoughts about what might be going wrong here? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From wk at gnupg.org Wed Oct 5 08:14:25 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 05 Oct 2016 08:14:25 +0200 Subject: [PATCH] agent: Fix error handling in map_supervised_sockets In-Reply-To: <20161005042311.10085-1-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 5 Oct 2016 00:23:11 -0400") References: <20161005042311.10085-1-dkg@fifthhorseman.net> Message-ID: <87y423iapq.fsf@wheatstone.g10code.de> On Wed, 5 Oct 2016 06:23, dkg at fifthhorseman.net said: > * agent/gpg-agent.c (map_supervised_sockets): the file descriptor to > close on error is fd, not i. Thanks. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From wk at gnupg.org Wed Oct 5 08:16:18 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 05 Oct 2016 08:16:18 +0200 Subject: avoiding long trustdb updates In-Reply-To: <878tu398cq.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 04 Oct 2016 16:17:57 -0400") References: <878tu398cq.fsf@alice.fifthhorseman.net> Message-ID: <87twcriaml.fsf@wheatstone.g10code.de> On Tue, 4 Oct 2016 22:17, dkg at fifthhorseman.net said: > Is there a reason to use --always-trust here instead of > --no-auto-check-trustdb ? --always-trust seems like it should have more > side effects in terms of how gpg operates, and if the goal is just "to Right, that is exactly the effect I want. We do not need any gpg internal key validation there but just the fingerprint of the keys. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From gniibe at fsij.org Wed Oct 5 08:45:56 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 5 Oct 2016 15:45:56 +0900 Subject: [PATCH v3 3/5] gpg-agent: Implement --supervised command (for systemd, etc). In-Reply-To: <87vax7760i.fsf@alice.fifthhorseman.net> References: <87vaz7rq1k.fsf@alice.fifthhorseman.net> <1470980281-2675-1-git-send-email-dkg@fifthhorseman.net> <1470980281-2675-4-git-send-email-dkg@fifthhorseman.net> <87oa30jfz9.fsf@wheatstone.g10code.de> <87vax7760i.fsf@alice.fifthhorseman.net> Message-ID: <1797b0f2-a4de-c98c-e02d-4784879c7357@fsij.org> On 10/05/2016 01:51 PM, Daniel Kahn Gillmor wrote: > 1) when running --supervised, i see regular hangs of the agent which are > not seen when it is auto-launched. Sorry, my change of eda1764 * agent, dirmngr, scd: npth_init must be after fork. interferes, I suppose. My patch is trying to clean up use of nPth with daemonizing. It makes gpg-agent not initialize nPth before fork to be daemon, so that we can avoid unclear semantics of forked child of threaded application. I think that in the code path of --supervised, initialize_module is missing. I'm writing this without testing. I'll commit this after test. diff --git a/agent/gpg-agent.c b/agent/gpg-agent.c index 9c7b8fc..dcc9bb6 100644 --- a/agent/gpg-agent.c +++ b/agent/gpg-agent.c @@ -1456,6 +1456,8 @@ main (int argc, char **argv ) #ifndef HAVE_W32_SYSTEM gnupg_fd_t fd, fd_extra, fd_browser, fd_ssh; + initialize_modules (); + /* when supervised and sending logs to stderr, the process supervisor should handle log entry metadata (pid, name, timestamp) */ -- From fabio.coatti at gmail.com Wed Oct 5 09:07:52 2016 From: fabio.coatti at gmail.com (Fabio Coatti) Date: Wed, 05 Oct 2016 09:07:52 +0200 Subject: scdaemon (possible?) lockup In-Reply-To: <74054ad8-d6d9-4243-3190-7f4ac6073b72@fsij.org> References: <7455218.qWm7FkoZvf@calvin> <74054ad8-d6d9-4243-3190-7f4ac6073b72@fsij.org> Message-ID: <1608676.0hxiHEBEbY@calvin> In data mercoled? 5 ottobre 2016 08:33:05 CEST, NIIBE Yutaka ha scritto: > Hello, > > On 10/04/2016 10:15 PM, Fabio Coatti wrote: > > If I kill scdaemon, > > cova at calvin ~ $ killall scdaemon > > This doesn't kill scdaemon because scdaemon has a signal handler for > SIGTERM (If you really want to do this way, you need sending signal at > least two times to scdaemon). > > Instead, please do this: > > $ gpgconf --reload scdaemon You are right, and in fact I was issuing the command twice (redacted for clarity in the mail above, but that wasn't a good idea :) ) Anyway, I made the same tests again using reload. The behaviour can be summarized like this: Case A: power management set to auto Card already IN: -> status: card error scdaemon reloaded -> status: card error Card pulled out: -> status: card error Card plugged in: -> status: card error card plugged out, scd reload, card in and status immediately requested: card OK card plugged out, scd reload, card in, wait a couple of seconds: card error. basically: no way to came out from error condition (besides reload) and error is triggered every time, unless the card is read just after being inserted. Case B: power management set to ON starting from a card error condition, reloading scd makes the card to work correctly: card not present when plugged out, card OK and read correctly when plugged. No other card errors. So a possible explanation could be: 1. for some reason, when scd enters the "card error status" he can't get off until reloaded. 2. for some other reason, the card reader takes too much to wake up when powered off (or scd has a too short timeout), scd enters error condition and triggers behaviour described to in 1. Maybe there could also be an error in power management of card reader and he can't be woke up by scd but only inserting the card. Those hypotesis can explain the behaviour... but there can also be a host of different explanations, I fear. Given that, a try would be to look a the code of scd to check the behaviour when an error occurs and if the error state can be exited in some way, and look at timeouts/retries to read the card. What do you think? -- Fabio From wk at gnupg.org Wed Oct 5 09:20:20 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 05 Oct 2016 09:20:20 +0200 Subject: [PATCH v3 3/5] gpg-agent: Implement --supervised command (for systemd, etc). In-Reply-To: <87vax7760i.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 05 Oct 2016 00:51:25 -0400") References: <87vaz7rq1k.fsf@alice.fifthhorseman.net> <1470980281-2675-1-git-send-email-dkg@fifthhorseman.net> <1470980281-2675-4-git-send-email-dkg@fifthhorseman.net> <87oa30jfz9.fsf@wheatstone.g10code.de> <87vax7760i.fsf@alice.fifthhorseman.net> Message-ID: <87ponfi7nv.fsf@wheatstone.g10code.de> On Wed, 5 Oct 2016 06:51, dkg at fifthhorseman.net said: > I've tested this and there are a few problems still aside from the > patch i've sent to the list. My fault. I had to rebase my commits before pushing. This required some manual edits and although I recall that I added initialize_modules to the supervised mode, that somehow got lost. I pushed a fix. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From gniibe at fsij.org Wed Oct 5 09:32:02 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 5 Oct 2016 16:32:02 +0900 Subject: scdaemon (possible?) lockup In-Reply-To: <1608676.0hxiHEBEbY@calvin> References: <7455218.qWm7FkoZvf@calvin> <74054ad8-d6d9-4243-3190-7f4ac6073b72@fsij.org> <1608676.0hxiHEBEbY@calvin> Message-ID: <0add0c76-e801-844d-a27f-314f3172fb01@fsij.org> On 10/05/2016 04:07 PM, Fabio Coatti wrote: > Given that, a try would be to look a the code of scd to check the behaviour > when an error occurs and if the error state can be exited in some way, and > look at timeouts/retries to read the card. Yes. > 1. for some reason, when scd enters the "card error status" he can't > get off until reloaded. Perhaps related somehow, scdaemon had a bug about card removal handling. It was fixed in: f9e49c80e706a27d5e30d4b3237ff26367a67130 Author: NIIBE Yutaka AuthorDate: Sat Sep 3 15:27:30 2016 +0900 It will be included in the next release (2.1.16). I don't know how the power management of the card reader works. If it's in USB layer (it causes USB error), I think that scdaemon can detect an error correctly. If it's card communication layer, it is likely something wrong may happen with scdaemon in version 2.1.15, and the scdaemon continues until reload. Are there any specification or explanation about the power management of the reader? -- From wk at gnupg.org Wed Oct 5 09:26:13 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 05 Oct 2016 09:26:13 +0200 Subject: Kludge to test the --supervised feature Message-ID: <87lgy3i7e2.fsf@wheatstone.g10code.de> Hi, find below the kludge I use to briefly test the --supervised mode of gpg-agent w/o resorting to installingsystemd or writing dedicated test tool. LISTEN_PID=$$ LISTEN_FDNAMES=ssh:browser:extra:foo \ GNUPGHOME=$(pwd) gpg-agent --supervised -v Then use gpg-connect-agent -S /tmp/foo-bar to connect to the agent. Salam-Shalom, Werner ======== diff --git a/agent/gpg-agent.c b/agent/gpg-agent.c index dcc9bb6..58329c3 100644 --- a/agent/gpg-agent.c +++ b/agent/gpg-agent.c @@ -958,6 +958,66 @@ initialize_modules (void) } + +static int +set_sockaddr_un (const char *fname, struct sockaddr *addr) +{ + struct sockaddr_un *unaddr = (struct sockaddr_un *)addr; + struct stat statbuf; + + if (strlen (fname)+1 >= sizeof unaddr->sun_path) + { + gpg_err_set_errno (ENAMETOOLONG); + return -1; + } + + memset (unaddr, 0, sizeof *unaddr); + unaddr->sun_family = AF_LOCAL; + strncpy (unaddr->sun_path, fname, sizeof unaddr->sun_path - 1); + unaddr->sun_path[sizeof unaddr->sun_path - 1] = 0; + + return 0; +} + + +static void +create_dummy_socket (const char *name) +{ + int x; + struct sockaddr *addr; + struct sockaddr_un *unaddr; + socklen_t len; + + unaddr = malloc (sizeof *unaddr); + if (!unaddr) + abort (); + addr = (struct sockaddr*)unaddr; + + x = socket (AF_UNIX, SOCK_STREAM, 0); + if (x == -1) + { + fprintf (stderr, "can't create socket: %s\n", strerror (errno)); + abort (); + } + set_sockaddr_un (name, addr); + fprintf (stderr,"created socket with fd %d\n", x); + len = SUN_LEN (unaddr); + if (bind (x, addr, len) == -1) + { + fprintf (stderr, "error binding socket: %s\n", strerror (errno)); + abort (); + } + + if (listen (x, 5) == -1) + { + fprintf (stderr, "listen() failed: %s\n", strerror (errno)); + abort (); + } + + free (unaddr); +} + + /* The main entry point. */ int main (int argc, char **argv ) @@ -981,6 +1041,12 @@ main (int argc, char **argv ) gpg_error_t err; struct assuan_malloc_hooks malloc_hooks; + create_dummy_socket ("/tmp/wk1-dummy-1"); + create_dummy_socket ("/tmp/wk1-dummy-2"); + create_dummy_socket ("/tmp/wk1-dummy-3"); + create_dummy_socket ("/tmp/wk1-dummy-4"); + + early_system_init (); /* Before we do anything else we save the list of currently open -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From fabio.coatti at gmail.com Wed Oct 5 09:40:39 2016 From: fabio.coatti at gmail.com (Fabio Coatti) Date: Wed, 05 Oct 2016 09:40:39 +0200 Subject: scdaemon (possible?) lockup In-Reply-To: <0add0c76-e801-844d-a27f-314f3172fb01@fsij.org> References: <7455218.qWm7FkoZvf@calvin> <1608676.0hxiHEBEbY@calvin> <0add0c76-e801-844d-a27f-314f3172fb01@fsij.org> Message-ID: <2895786.MrMUTlrYWz@calvin> In data mercoled? 5 ottobre 2016 16:32:02 CEST, NIIBE Yutaka ha scritto: > On 10/05/2016 04:07 PM, Fabio Coatti wrote: > > Given that, a try would be to look a the code of scd to check the > > behaviour > > when an error occurs and if the error state can be exited in some way, and > > look at timeouts/retries to read the card. > > Yes. > > > 1. for some reason, when scd enters the "card error status" he can't > > get off until reloaded. > > Perhaps related somehow, scdaemon had a bug about card removal > handling. It was fixed in: > > f9e49c80e706a27d5e30d4b3237ff26367a67130 > Author: NIIBE Yutaka > AuthorDate: Sat Sep 3 15:27:30 2016 +0900 > > It will be included in the next release (2.1.16). > I will be happy to test it, maybe when the new version will be ready or even before, if I find the time to install it. > I don't know how the power management of the card reader works. If > it's in USB layer (it causes USB error), I think that scdaemon can > detect an error correctly. If it's card communication layer, it is > likely something wrong may happen with scdaemon in version 2.1.15, and > the scdaemon continues until reload. > > Are there any specification or explanation about the power management of > the reader? I'm a bit out of my groud here, anyway I can provide the lsusb -v output (it is a USB device) and also perform some debug, maybe looking at scdaemon/agent debug logs... or some other USB debugging, if this can be useful. -- Fabio From dkg at fifthhorseman.net Wed Oct 5 15:58:57 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 05 Oct 2016 09:58:57 -0400 Subject: gpg-agent shell variable output Message-ID: <87shsa7v8e.fsf@alice.fifthhorseman.net> hi all-- gpg-agent's --sh and --csh commands suggest that they'll emit some sort of shell variables (and indeed they used to). With the new use of standard socket in 2.1.x, it's not clear how to get these variables to stdout. for example, the old mechanism of: $(gpg-agent --enable-ssh-support --daemon --sh) now does nothing to the parent shell. Are we explicitly deprecating the feature of writing variables to stdout? If so, the documentation should be cleaned up and those arguments should be explicitly deprecated. If not, how can we support it better? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From ineiev at gnu.org Wed Oct 5 16:29:30 2016 From: ineiev at gnu.org (Ineiev) Date: Wed, 5 Oct 2016 10:29:30 -0400 Subject: [PATCH HEAD] i18n fixes Message-ID: <20161005142930.GO30569@gnu.org> Hello, Please find some i18n fixes (ngettext usage plus one string needing i18n) attached. Thank you! -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-i18n.patch Type: text/x-diff Size: 3453 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 ineiev at gnu.org Wed Oct 5 16:36:17 2016 From: ineiev at gnu.org (Ineiev) Date: Wed, 5 Oct 2016 10:36:17 -0400 Subject: [PATCH HEAD] a typo in a message Message-ID: <20161005143617.GP30569@gnu.org> --- a/g10/tofu.c +++ b/g10/tofu.c @@ -3048,7 +3048,7 @@ tofu_register_encryption (ctrl_t ctrl, free_user_id_list = 1; if (! user_id_list) - log_info (_("WARNING: Encrypting to %s, which has no" + log_info (_("WARNING: Encrypting to %s, which has no " "non-revoked user ids.\n"), keystr (pk->keyid)); } -------------- 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 Wed Oct 5 16:35:17 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 05 Oct 2016 16:35:17 +0200 Subject: gpg-agent shell variable output In-Reply-To: <87shsa7v8e.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 05 Oct 2016 09:58:57 -0400") References: <87shsa7v8e.fsf@alice.fifthhorseman.net> Message-ID: <87k2dmhniy.fsf@wheatstone.g10code.de> On Wed, 5 Oct 2016 15:58, dkg at fifthhorseman.net said: > With the new use of standard socket in 2.1.x, it's not clear how to get > these variables to stdout. for example, the old mechanism of: > > $(gpg-agent --enable-ssh-support --daemon --sh) > > now does nothing to the parent shell. They still work: $ GNUPGHOME=$(pwd) gpg-agent --options /dev/null \ --daemon --enable-ssh-support >out $ cat out SSH_AUTH_SOCK=/FOO/S.gpg-agent.ssh; export SSH_AUTH_SOCK; or for csh: $ GNUPGHOME=$(pwd) gpg-agent --options /dev/null \ --daemon --enable-ssh-support --csh >out $ cat out setenv SSH_AUTH_SOCK /FOO/S.gpg-agent.ssh; and they are also set in the environment of a spawned program $ GNUPGHOME=$(pwd) gpg-agent --options /dev/null \ --daemon --enable-ssh-support /bin/sh $ echo $SSH_AUTH_SOCK /FOO/S.gpg-agent.ssh > Are we explicitly deprecating the feature of writing variables to > stdout? If so, the documentation should be cleaned up and those > arguments should be explicitly deprecated. Yes, we should deprecate that and favor of SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)" A problem with gpgconf is that it does only know about the standard socket names which are determined based on $GNUPGHOME. That is fine for ssh but the --extra-socket and the --browser-socket may have been set to a different name. --supervised may also set them to arbitrary names and - worse - could do that also for the standard socket. A --supervised based installation should never do the latter of course to avoid the catch-22. For the other 3 sockets it would be possible to ask gpg-agent for the right socket but that also means that gpg-agent would be launched just t know the sockets. My conclusion is that we should stick to the default socket names as printed by gpgconf and not try to make them configurable. Thus a warning about the use of --extra-socket and --browser socket would be appropriate. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From ineiev at gnu.org Wed Oct 5 17:24:17 2016 From: ineiev at gnu.org (Ineiev) Date: Wed, 5 Oct 2016 11:24:17 -0400 Subject: [PATCH HEAD] i18n fixes In-Reply-To: <20161005142930.GO30569@gnu.org> References: <20161005142930.GO30569@gnu.org> Message-ID: <20161005152417.GQ30569@gnu.org> By the way, current lines 1569-1578 of g10/tofy.c also look problematic. --- >8 --- if ((binding->flags & BINDING_REVOKED)) { es_fprintf (fp, _("revoked")); es_fprintf (fp, _(", ")); } else if ((binding->flags & BINDING_EXPIRED)) { es_fprintf (fp, _("expired")); es_fprintf (fp, _(", ")); } --- 8< --- I really think this is where context should be used with the messages joined, like es_fprintf (fp, pgettext ("key binding", "revoked, ")); You can't have the same translation of "revoked" for "key" and "binding", they have different grammatical genders. Yes, this means including a copy of gettext.h in the distribution. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From dkg at fifthhorseman.net Wed Oct 5 17:34:40 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 05 Oct 2016 11:34:40 -0400 Subject: permissions required on /run/user//gnupg Message-ID: <87pone7qsv.fsf@alice.fifthhorseman.net> Hi GnuPG devs-- I've noticed that the permissions set on /run/user//gnupg have an effect on the choice of standard socket. This means, for example, that if that directory is created mode 0755, the standard socket will be created and looked for in ~/.gnupg/ instead. Is this restriction the right choice? The rationale for it from gpg-agent's side is presumably that you don't want to expose the socket to other users on the machine. And from gpg's side, of course, it wants to use the socket that gpg-agent is actually offering. But consider the use case of an isolated agent, run by one user account and deliberately exposed (on the same machine) to another user account. In that case, the permissions shouldn't be so strict. Would it make sense to think about the logic from the two sides separately? for example: gpg-agent startup (in default mode): a) if /run/user//gnupg is owned by me and mode 0700, then listen on S.gpg-agent in that directory. b) If not, then listen on ~/.gnupg/S.gpg-agent gpg (and other clients of gpg-agent): a) look for /run/user//gnupg/S.gpg-agent -- if it's a socket and i can connect to it, use it. b) if not, look for ~/.gnupg/S.gpg-agent -- if it's a socket and i can connect to it, use it. c) if not, spawn gpg-agent, and go back to (a) (you'd want to add some sort of loop avoidance mechanism in the client logic, of course) Alternately, is there a way to explicitly instruct gpg (and other clients of gpg-agent) to use a specific socket somewhere else? We've deprecated GPG_AGENT_INFO, of course, but is there a problem with the idea of pointing gpg at a different socket if it's already present? I'm curious to hear any thoughts on this, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From wk at gnupg.org Wed Oct 5 18:55:51 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 05 Oct 2016 18:55:51 +0200 Subject: [PATCH HEAD] a typo in a message In-Reply-To: <20161005143617.GP30569@gnu.org> (ineiev@gnu.org's message of "Wed, 5 Oct 2016 10:36:17 -0400") References: <20161005143617.GP30569@gnu.org> Message-ID: <87zimig2g8.fsf@wheatstone.g10code.de> On Wed, 5 Oct 2016 16:36, ineiev at gnu.org said: > - log_info (_("WARNING: Encrypting to %s, which has no" > + log_info (_("WARNING: Encrypting to %s, which has no " > "non-revoked user ids.\n"), Although "no non-" is technically correct, it is hard to grok. Should be re-worded. And we do not print dots at the end. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From dkg at fifthhorseman.net Wed Oct 5 19:14:45 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 05 Oct 2016 13:14:45 -0400 Subject: gpg-agent shell variable output In-Reply-To: <87k2dmhniy.fsf@wheatstone.g10code.de> References: <87shsa7v8e.fsf@alice.fifthhorseman.net> <87k2dmhniy.fsf@wheatstone.g10code.de> Message-ID: <87fuoa7m62.fsf@alice.fifthhorseman.net> On Wed 2016-10-05 10:35:17 -0400, Werner Koch wrote: > They still work: > > $ GNUPGHOME=$(pwd) gpg-agent --options /dev/null \ > --daemon --enable-ssh-support >out > $ cat out > SSH_AUTH_SOCK=/FOO/S.gpg-agent.ssh; export SSH_AUTH_SOCK; > > or for csh: > > $ GNUPGHOME=$(pwd) gpg-agent --options /dev/null \ > --daemon --enable-ssh-support --csh >out > $ cat out > setenv SSH_AUTH_SOCK /FOO/S.gpg-agent.ssh; > > and they are also set in the environment of a spawned program > > $ GNUPGHOME=$(pwd) gpg-agent --options /dev/null \ > --daemon --enable-ssh-support /bin/sh > $ echo $SSH_AUTH_SOCK > /FOO/S.gpg-agent.ssh These only work in the event that gpg-agent is actually launched. If, instead, gpg-agent just detects that it is already running, nothing is printed to stdout. Why not? >> Are we explicitly deprecating the feature of writing variables to >> stdout? If so, the documentation should be cleaned up and those >> arguments should be explicitly deprecated. > > Yes, we should deprecate that and favor of > > SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)" > > A problem with gpgconf is that it does only know about the standard > socket names which are determined based on $GNUPGHOME. That is fine for > ssh but the --extra-socket and the --browser-socket may have been set to > a different name. --supervised may also set them to arbitrary names and > - worse - could do that also for the standard socket. A --supervised > based installation should never do the latter of course to avoid the > catch-22. For the other 3 sockets it would be possible to ask gpg-agent > for the right socket but that also means that gpg-agent would be > launched just t know the sockets. > > My conclusion is that we should stick to the default socket names as > printed by gpgconf and not try to make them configurable. Thus a > warning about the use of --extra-socket and --browser socket would be > appropriate. --browser-socket has never been a documented option in a released version. We could replace it entirely with --disable-browser-socket and not break any documented interfaces. For symmetry, we could also introduce --disable-restricted-socket and explicitly deprecate --extra-socket (if the socket is going to be named S.gpg-agent.rstrd then we should refer to it consistently as "restricted socket", not as "extra", as long as we're doing an interface deprecation and cleanup) thanks for thinking these through with me, --dkg From wk at gnupg.org Wed Oct 5 19:22:11 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 05 Oct 2016 19:22:11 +0200 Subject: permissions required on /run/user//gnupg In-Reply-To: <87pone7qsv.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 05 Oct 2016 11:34:40 -0400") References: <87pone7qsv.fsf@alice.fifthhorseman.net> Message-ID: <87vax6g18c.fsf@wheatstone.g10code.de> On Wed, 5 Oct 2016 17:34, dkg at fifthhorseman.net said: > I've noticed that the permissions set on /run/user//gnupg have an > effect on the choice of standard socket. I implemented it this way to cope with the case that other software already used a directory under this name and does not guarantee the same permissions GnuPG needs. I know, this is highly unlikely but after all this socket allows access to the private keys. Thus better fallback to the old standard name if something smelss fishy. > Is this restriction the right choice? The rationale for it from > gpg-agent's side is presumably that you don't want to expose the socket > to other users on the machine. And from gpg's side, of course, it wants These are the same restrictions we have for ~/.gnupg . Thus the move to /run/user didn't changed anything regarding permissions. > But consider the use case of an isolated agent, run by one user account > and deliberately exposed (on the same machine) to another user account. > In that case, the permissions shouldn't be so strict. I think it would be okay to relax the permissions to allow group RW for the socket file. I am not sure about the directory. > a) if /run/user//gnupg is owned by me and mode 0700, then listen > on S.gpg-agent in that directory. > b) If not, then listen on ~/.gnupg/S.gpg-agent I fact, would like to entirely get rid of sockets in the homedir. We still need them for compatibility reasons but in the long term they should go away. The logic you propose makes things even more complicate than they are right now. Shouldn't we discuss this based on a concrete proposal? For isolating gpg-agent and gpg, what about using a separate sub-directory with permissions suitable for this? > Alternately, is there a way to explicitly instruct gpg (and other > clients of gpg-agent) to use a specific socket somewhere else? We've I have seen such a feature request / bug report. Before we do a quick hack here, we should evaluate the use case in more detail before we come up with a solution. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From wk at gnupg.org Wed Oct 5 19:37:42 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 05 Oct 2016 19:37:42 +0200 Subject: [PATCH HEAD] i18n fixes In-Reply-To: <20161005152417.GQ30569@gnu.org> (ineiev@gnu.org's message of "Wed, 5 Oct 2016 11:24:17 -0400") References: <20161005142930.GO30569@gnu.org> <20161005152417.GQ30569@gnu.org> Message-ID: <87r37ug0ih.fsf@wheatstone.g10code.de> On Wed, 5 Oct 2016 17:24, ineiev at gnu.org said: > I really think this is where context should be used > with the messages joined, like Right. We usuallay do this with ad-hoc methods instead of the non-portable pgettext. Anyway, many texts in tofu.c are not suitable for translation because they split strings and translate only parts. Instead of providing lot of contexts and a bulk of very similar strings, we should rework the texts to be better translatable. That may require that we resort to some table-like texts, like "number of keys associated with address \"%s\": %d\n" Agreed, this is stylistic not pretty. But after having seen these diagnostics a few time, the provided information is easier to grok because you know where to look and do not need to parse the sentence. This is why I hesitate to apply your patches - they fix only some parts with the problem but grow the number of strings too translate a lot. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From wk at gnupg.org Wed Oct 5 19:56:58 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 05 Oct 2016 19:56:58 +0200 Subject: gpg-agent shell variable output In-Reply-To: <87fuoa7m62.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 05 Oct 2016 13:14:45 -0400") References: <87shsa7v8e.fsf@alice.fifthhorseman.net> <87k2dmhniy.fsf@wheatstone.g10code.de> <87fuoa7m62.fsf@alice.fifthhorseman.net> Message-ID: <87lgy2fzmc.fsf@wheatstone.g10code.de> On Wed, 5 Oct 2016 19:14, dkg at fifthhorseman.net said: > If, instead, gpg-agent just detects that it is already running, nothing > is printed to stdout. Why not? Because it needs to connect to the running gpg-agent and fetch the socket name. Using gpgconf is easier. Or the portable way: $ gpg-connect-agent '/datafile -' 'getinfo socket_name' /echo /bye /run/user/1000/gnupg/S.gpg-agent (In a script I would suggest to replace "/bye" by " --browser-socket has never been a documented option in a released > version. We could replace it entirely with --disable-browser-socket and > not break any documented interfaces. Already done: Use "none" or "/dev/null" to -e-xtra or --browser socket. > For symmetry, we could also introduce --disable-restricted-socket and > explicitly deprecate --extra-socket (if the socket is going to be named > S.gpg-agent.rstrd then we should refer to it consistently as "restricted The option name is in use for quite some time, thus we can't really change it anymore. Yes, an alias for the option would be possible but then we need to restart the discussion on whether "restricted" is a good term :-(. I hoped we had found a compromise by keeping the option name but naming the socket file "S.gpg-agent.rstrd" Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From dkg at fifthhorseman.net Wed Oct 5 19:41:38 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 05 Oct 2016 13:41:38 -0400 Subject: permissions required on /run/user//gnupg In-Reply-To: <87vax6g18c.fsf@wheatstone.g10code.de> References: <87pone7qsv.fsf@alice.fifthhorseman.net> <87vax6g18c.fsf@wheatstone.g10code.de> Message-ID: <878tu27kx9.fsf@alice.fifthhorseman.net> On Wed 2016-10-05 13:22:11 -0400, Werner Koch wrote: > On Wed, 5 Oct 2016 17:34, dkg at fifthhorseman.net said: > >> I've noticed that the permissions set on /run/user//gnupg have an >> effect on the choice of standard socket. > > I implemented it this way to cope with the case that other software > already used a directory under this name and does not guarantee the same > permissions GnuPG needs. I know, this is highly unlikely but after all > this socket allows access to the private keys. is the concern here about "hijacking" like what gpg-agent did? > Thus better fallback to the old standard name if something smelss > fishy. sorry, i don't understand whether you mean this about the decisions made during socket creation/listening (gpg-agent's perspective) or socket connection (gpg's perspective). Writing the e-mail earlier made me realize that these are really two distinct sets of choices and despite wanting to reuse code where possible, i think we might need to make the two decisions differently. >> Is this restriction the right choice? The rationale for it from >> gpg-agent's side is presumably that you don't want to expose the socket >> to other users on the machine. And from gpg's side, of course, it wants > > These are the same restrictions we have for ~/.gnupg . Thus the move to > /run/user didn't changed anything regarding permissions. so if the permissions on ~/.gnupg are too loose, the agent won't listen on a socket there -- is that right? >> But consider the use case of an isolated agent, run by one user account >> and deliberately exposed (on the same machine) to another user account. >> In that case, the permissions shouldn't be so strict. > > I think it would be okay to relax the permissions to allow group RW for > the socket file. I am not sure about the directory. For Linux, i believe that permissions on sockets are meaningful. iirc, there are other unix-es that ignore permissions on unix-domain sockets, so the directory permissions are the most important. >> a) if /run/user//gnupg is owned by me and mode 0700, then listen >> on S.gpg-agent in that directory. >> b) If not, then listen on ~/.gnupg/S.gpg-agent > > I fact, would like to entirely get rid of sockets in the homedir. We > still need them for compatibility reasons but in the long term they > should go away. I'd love for them to go away as well! how should we cope with non-standard homedirs, though? I'm thinking about test suites, or projects that want to use gpg with an isolated set of keys. > The logic you propose makes things even more complicate than they are > right now. > > Shouldn't we discuss this based on a concrete proposal? well, i tried to make a concrete proposal, though i grant that it's more complicated than the current situation :) > For isolating gpg-agent and gpg, what about using a separate > sub-directory with permissions suitable for this? if the parent directory is mode 0700, then any subdirectory won't be accessible to a different user, right? >> Alternately, is there a way to explicitly instruct gpg (and other >> clients of gpg-agent) to use a specific socket somewhere else? We've > > I have seen such a feature request / bug report. could you point me to it? I'd like to follow up on https://0xacab.org/monkeysphere/monkeysign/issues/9#note_10491 > Before we do a quick hack here, we should evaluate the use case in > more detail before we come up with a solution. There are several different use cases for clients of gpg-agent to use a distinct agent. Where would you like me to document them? Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From dkg at fifthhorseman.net Wed Oct 5 20:23:20 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 05 Oct 2016 14:23:20 -0400 Subject: gpg-agent shell variable output In-Reply-To: <87lgy2fzmc.fsf@wheatstone.g10code.de> References: <87shsa7v8e.fsf@alice.fifthhorseman.net> <87k2dmhniy.fsf@wheatstone.g10code.de> <87fuoa7m62.fsf@alice.fifthhorseman.net> <87lgy2fzmc.fsf@wheatstone.g10code.de> Message-ID: <87zimi64fb.fsf@alice.fifthhorseman.net> On Wed 2016-10-05 13:56:58 -0400, Werner Koch wrote: > On Wed, 5 Oct 2016 19:14, dkg at fifthhorseman.net said: > >> If, instead, gpg-agent just detects that it is already running, nothing >> is printed to stdout. Why not? > > Because it needs to connect to the running gpg-agent and fetch the > socket name. Using gpgconf is easier. Or the portable way: > > $ gpg-connect-agent '/datafile -' 'getinfo socket_name' /echo /bye > /run/user/1000/gnupg/S.gpg-agent > > (In a script I would suggest to replace "/bye" by "> For symmetry, we could also introduce --disable-restricted-socket and >> explicitly deprecate --extra-socket (if the socket is going to be named >> S.gpg-agent.rstrd then we should refer to it consistently as "restricted > > The option name is in use for quite some time, thus we can't really > change it anymore. ...and here you seem to be saying that we can't change options at all because they'll break scripts. If we're doing a hard cut (some might call this an "API break") then we should make the changes so that post-cutover we have as clean and normalized an API as possible. If we're trying to do a gradual transition (not a hard cut), we should still add the newer, normalized options as soon as possible, so that they are available to people who want to use them. [ out of order quoting, sorry? ] >> --browser-socket has never been a documented option in a released >> version. We could replace it entirely with --disable-browser-socket and >> not break any documented interfaces. > > Already done: Use "none" or "/dev/null" to -e-xtra or --browser socket. I'm aware of this, but to a person setting up GnuPG, it's bewildering to have --enable-ssh-socket but then --extra-socket FILENAME. If we're deprecating things and tuning the interface, we should aim for as regular and predictable an interface as possible. > Yes, an alias for the option would be possible but then we need to > restart the discussion on whether "restricted" is a good term :-(. I > hoped we had found a compromise by keeping the option name but naming > the socket file "S.gpg-agent.rstrd" Upon reflection, I sort of think this is the worst of all possible worlds: * "rstrd" is hard to read unless you already know that it's supposed to be "restricted" -- could it be "restored" or "restrained" or "rastered" or "roistered" or "reconstructed" or "restarted"? * "rstrd" is a another 5 full characters toward the already-tight 108-char sun_path limit. * neither "restricted" nor "rstrd" matches the actual command-line or config file option "--extra-socket" * "--extra-socket" still doesn't suggest to the user what they're signing up for If we can settle on the term "restricted" (including moving to "--disable-restricted-socket" with a deprecation of "--extra-socket"), what about "S.restricted" or "S.gpg.restricted" or "S.gpg-agent.R". If we settle on the term "extra", then maybe "S.extra" or "S.gpg.extra" or "S.gpg-agent.X" I'm open to other suggestions. But using a combination that only makes sense if you've been following gnupg-devel for years is not going to help users or developers make the right choices when using gpg in the future. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From ineiev at gnu.org Thu Oct 6 08:43:41 2016 From: ineiev at gnu.org (Ineiev) Date: Thu, 6 Oct 2016 02:43:41 -0400 Subject: [PATCH HEAD] a typo in a message In-Reply-To: <87zimig2g8.fsf@wheatstone.g10code.de> References: <20161005143617.GP30569@gnu.org> <87zimig2g8.fsf@wheatstone.g10code.de> Message-ID: <20161006064340.GR30569@gnu.org> On Wed, Oct 05, 2016 at 06:55:51PM +0200, Werner Koch wrote: > On Wed, 5 Oct 2016 16:36, ineiev at gnu.org said: > > > - log_info (_("WARNING: Encrypting to %s, which has no" > > + log_info (_("WARNING: Encrypting to %s, which has no " > > "non-revoked user ids.\n"), > > Although "no non-" is technically correct, it is hard to grok. Should > be re-worded. And we do not print dots at the end. Just a try: diff --git a/g10/tofu.c b/g10/tofu.c index 1bd8ce2..9fb70c1 100644 --- a/g10/tofu.c +++ b/g10/tofu.c @@ -3052,8 +3052,8 @@ tofu_register_encryption (ctrl_t ctrl, free_user_id_list = 1; if (! user_id_list) - log_info (_("WARNING: Encrypting to %s, which has no" - "non-revoked user ids.\n"), + log_info (_("WARNING: Encrypting to %s, " + "a key with all user IDs revoked\n"), keystr (pk->keyid)); } -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From justus at g10code.com Thu Oct 6 11:05:43 2016 From: justus at g10code.com (Justus Winter) Date: Thu, 06 Oct 2016 11:05:43 +0200 Subject: gpg-agent shell variable output In-Reply-To: <87zimi64fb.fsf@alice.fifthhorseman.net> References: <87shsa7v8e.fsf@alice.fifthhorseman.net> <87k2dmhniy.fsf@wheatstone.g10code.de> <87fuoa7m62.fsf@alice.fifthhorseman.net> <87lgy2fzmc.fsf@wheatstone.g10code.de> <87zimi64fb.fsf@alice.fifthhorseman.net> Message-ID: <8760p5yhi0.fsf@europa.jade-hamburg.de> Daniel Kahn Gillmor writes: > I'm aware of this, but to a person setting up GnuPG, it's bewildering to > have --enable-ssh-socket but then --extra-socket FILENAME. If we're > deprecating things and tuning the interface, we should aim for as > regular and predictable an interface as possible. I have a pet bug for such things, feel free to add notes to it: https://bugs.gnupg.org/gnupg/issue2700 >> Yes, an alias for the option would be possible but then we need to >> restart the discussion on whether "restricted" is a good term :-(. I >> hoped we had found a compromise by keeping the option name but naming >> the socket file "S.gpg-agent.rstrd" > > Upon reflection, I sort of think this is the worst of all possible > worlds: > > * "rstrd" is hard to read unless you already know that it's supposed > to be "restricted" -- could it be "restored" or "restrained" or > "rastered" or "roistered" or "reconstructed" or "restarted"? That was me, thoug I'm not happy with it either. For the record, I did the unix thing, remove all vowels and then continue to remove letters until it is short enough (whatever that means). > * "rstrd" is a another 5 full characters toward the already-tight > 108-char sun_path limit. About that, I believe there is a workaround: chdir(dirname(socket)), then connect(basename(socket)). Fiddling with the cwd is not the nicest thing, but we only need to do this at initialization time and I believe it can be done safely using fchdir to return to the original wd. > * neither "restricted" nor "rstrd" matches the actual command-line or > config file option "--extra-socket" > > * "--extra-socket" still doesn't suggest to the user what they're > signing up for Agreed :( Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From justus at g10code.com Thu Oct 6 11:17:57 2016 From: justus at g10code.com (Justus Winter) Date: Thu, 06 Oct 2016 11:17:57 +0200 Subject: permissions required on /run/user//gnupg In-Reply-To: <878tu27kx9.fsf@alice.fifthhorseman.net> References: <87pone7qsv.fsf@alice.fifthhorseman.net> <87vax6g18c.fsf@wheatstone.g10code.de> <878tu27kx9.fsf@alice.fifthhorseman.net> Message-ID: <8737k9ygxm.fsf@europa.jade-hamburg.de> Daniel Kahn Gillmor writes: >> I fact, would like to entirely get rid of sockets in the homedir. We >> still need them for compatibility reasons but in the long term they >> should go away. > > I'd love for them to go away as well! Oh? What about all the people not using systemd? Fwiw, I do not like that GnuPG automagically uses /run/users/X if it exists, because everytime I accidentally install some package that pulls in the systemd component that creates these directories, my gnupg setup breaks. Yes, it is my fault for expecting the sockets to be created in ~/.gnupg, and yes, there is gpgconf that I should ask instead, but I still consider it very surprising that installing a seemingly unrelated package changes GnuPGs behavior like that. Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From dkg at fifthhorseman.net Thu Oct 6 16:21:06 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 06 Oct 2016 10:21:06 -0400 Subject: permissions required on /run/user//gnupg In-Reply-To: <8737k9ygxm.fsf@europa.jade-hamburg.de> References: <87pone7qsv.fsf@alice.fifthhorseman.net> <87vax6g18c.fsf@wheatstone.g10code.de> <878tu27kx9.fsf@alice.fifthhorseman.net> <8737k9ygxm.fsf@europa.jade-hamburg.de> Message-ID: <878tu15zjh.fsf@alice.fifthhorseman.net> On Thu 2016-10-06 05:17:57 -0400, Justus Winter wrote: > Daniel Kahn Gillmor writes: > >>> I fact, would like to entirely get rid of sockets in the homedir. We >>> still need them for compatibility reasons but in the long term they >>> should go away. >> >> I'd love for them to go away as well! > > Oh? What about all the people not using systemd? there's nothing that makes /run/user// systemd-specific. having an ephemeral chunk of the local filesystem that only your user can write to that *isn't* your homedir is useful for lots of reasons, not least of which are: * people with NFS-mounted homedirs, who can't effectively use the same socket in ~/.gnupg on two different machins * accounts with read-only home directories * accounts with no home directories at all Consider it a chunk of working space that you can use to coordinate processes on the same machine without needing to touch the disks, without worrying about access by other users, and without worrying about cleanup after poweroff. If your operating system supports ephemeral, in-ram filesystems (An OS with the Linux kernel would call it "tmpfs", i dunno what it's called on other kernels), why *not* have such a mountpoint? On the Linux kernel since version 2.2, we do have another such option, which would be to use the abstract sockets namespace, but that would require an entirely different permissions model, and would be a chunk of non-portable code. > Fwiw, I do not like that GnuPG automagically uses /run/users/X if it > exists, because everytime I accidentally install some package that pulls > in the systemd component that creates these directories, my gnupg setup > breaks. Yes, it is my fault for expecting the sockets to be created in > ~/.gnupg, and yes, there is gpgconf that I should ask instead, but I > still consider it very surprising that installing a seemingly unrelated > package changes GnuPGs behavior like that. I agree with you that this behavior change is frustrating. You can avoid the behavior change by just keeping /run/user// around in perpetuity ;) --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From dkg at fifthhorseman.net Thu Oct 6 16:29:57 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 06 Oct 2016 10:29:57 -0400 Subject: [PATCH HEAD] a typo in a message In-Reply-To: <20161006064340.GR30569@gnu.org> References: <20161005143617.GP30569@gnu.org> <87zimig2g8.fsf@wheatstone.g10code.de> <20161006064340.GR30569@gnu.org> Message-ID: <8737k95z4q.fsf@alice.fifthhorseman.net> On Thu 2016-10-06 02:43:41 -0400, Ineiev wrote: > On Wed, Oct 05, 2016 at 06:55:51PM +0200, Werner Koch wrote: >> On Wed, 5 Oct 2016 16:36, ineiev at gnu.org said: >> >> > - log_info (_("WARNING: Encrypting to %s, which has no" >> > + log_info (_("WARNING: Encrypting to %s, which has no " >> > "non-revoked user ids.\n"), >> >> Although "no non-" is technically correct, it is hard to grok. Should >> be re-worded. And we do not print dots at the end. > > Just a try: > > diff --git a/g10/tofu.c b/g10/tofu.c > index 1bd8ce2..9fb70c1 100644 > --- a/g10/tofu.c > +++ b/g10/tofu.c > @@ -3052,8 +3052,8 @@ tofu_register_encryption (ctrl_t ctrl, > free_user_id_list = 1; > > if (! user_id_list) > - log_info (_("WARNING: Encrypting to %s, which has no" > - "non-revoked user ids.\n"), > + log_info (_("WARNING: Encrypting to %s, " > + "a key with all user IDs revoked\n"), > keystr (pk->keyid)); > } I'm not sure about this. The other case could be a key that has no user IDs at all, right? Maybe we need a different message for the two cases? --dkg From ca+gnupg-devel at esmtp.org Thu Oct 6 16:36:42 2016 From: ca+gnupg-devel at esmtp.org (Claus Assmann) Date: Thu, 6 Oct 2016 07:36:42 -0700 Subject: permissions required on /run/user//gnupg In-Reply-To: <878tu15zjh.fsf@alice.fifthhorseman.net> References: <87pone7qsv.fsf@alice.fifthhorseman.net> <87vax6g18c.fsf@wheatstone.g10code.de> <878tu27kx9.fsf@alice.fifthhorseman.net> <8737k9ygxm.fsf@europa.jade-hamburg.de> <878tu15zjh.fsf@alice.fifthhorseman.net> Message-ID: <20161006143642.GA3756@x2.esmtp.org> On Thu, Oct 06, 2016, Daniel Kahn Gillmor wrote: > On Thu 2016-10-06 05:17:57 -0400, Justus Winter wrote: > > Fwiw, I do not like that GnuPG automagically uses /run/users/X if it > > exists, because everytime I accidentally install some package that pulls > I agree with you that this behavior change is frustrating. You can Maybe there should be a config option to turn that "magic" off? [Reply-to is set, please don't Cc me.] From justus at g10code.com Thu Oct 6 16:55:28 2016 From: justus at g10code.com (Justus Winter) Date: Thu, 06 Oct 2016 16:55:28 +0200 Subject: permissions required on /run/user//gnupg In-Reply-To: <878tu15zjh.fsf@alice.fifthhorseman.net> References: <87pone7qsv.fsf@alice.fifthhorseman.net> <87vax6g18c.fsf@wheatstone.g10code.de> <878tu27kx9.fsf@alice.fifthhorseman.net> <8737k9ygxm.fsf@europa.jade-hamburg.de> <878tu15zjh.fsf@alice.fifthhorseman.net> Message-ID: <87wphlwmqn.fsf@europa.jade-hamburg.de> Daniel Kahn Gillmor writes: > On Thu 2016-10-06 05:17:57 -0400, Justus Winter wrote: >> Daniel Kahn Gillmor writes: >> >>>> I fact, would like to entirely get rid of sockets in the homedir. We >>>> still need them for compatibility reasons but in the long term they >>>> should go away. >>> >>> I'd love for them to go away as well! >> >> Oh? What about all the people not using systemd? > > there's nothing that makes /run/user// systemd-specific. ... other than the fact that only systemd creates these directories. > having an > ephemeral chunk of the local filesystem that only your user can write to > that *isn't* your homedir is useful for lots of reasons, not least of > which are: I understand, and I don't necessarily disagree with the features/changes that systemd brings. I have a problem with how they do it. The systemd/Linux crowd keeps making up interfaces. They no longer need to care about compatibility, anyone who wants to be compatible has to do whatever systemd/Linux happens to do. > If your operating system supports ephemeral, in-ram filesystems (An OS > with the Linux kernel would call it "tmpfs", i dunno what it's called on > other kernels), why *not* have such a mountpoint? My operating system (Debian/Linux) happens to use this "tmpfs" feature to provide an ephemeral /run without systemd, and has been for years ;) > On the Linux kernel since version 2.2, we do have another such option, > which would be to use the abstract sockets namespace, but that would > require an entirely different permissions model, and would be a chunk of > non-portable code. No standardization for 17 years? Yes, that sounds like a Linux interface :/ >> Fwiw, I do not like that GnuPG automagically uses /run/users/X if it >> exists, because everytime I accidentally install some package that pulls >> in the systemd component that creates these directories, my gnupg setup >> breaks. Yes, it is my fault for expecting the sockets to be created in >> ~/.gnupg, and yes, there is gpgconf that I should ask instead, but I >> still consider it very surprising that installing a seemingly unrelated >> package changes GnuPGs behavior like that. > > I agree with you that this behavior change is frustrating. You can > avoid the behavior change by just keeping /run/user// around in > perpetuity ;) Well, with /run being a tmpfs it is doable, but not trivial. Cheers, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From ineiev at gnu.org Thu Oct 6 17:49:18 2016 From: ineiev at gnu.org (Ineiev) Date: Thu, 6 Oct 2016 11:49:18 -0400 Subject: [PATCH HEAD] a typo in a message In-Reply-To: <8737k95z4q.fsf@alice.fifthhorseman.net> References: <20161005143617.GP30569@gnu.org> <87zimig2g8.fsf@wheatstone.g10code.de> <20161006064340.GR30569@gnu.org> <8737k95z4q.fsf@alice.fifthhorseman.net> Message-ID: <20161006154918.GX30569@gnu.org> On Thu, Oct 06, 2016 at 10:29:57AM -0400, Daniel Kahn Gillmor wrote: > > - log_info (_("WARNING: Encrypting to %s, which has no" > > - "non-revoked user ids.\n"), > > + log_info (_("WARNING: Encrypting to %s, " > > + "a key with all user IDs revoked\n"), > > keystr (pk->keyid)); > > } > > I'm not sure about this. The other case could be a key that has no user > IDs at all, right? Maybe we need a different message for the two cases? I agree that the degenerate case may not be intuitive, at the very least. -------------- 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 Thu Oct 6 20:25:04 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 06 Oct 2016 20:25:04 +0200 Subject: [PATCH HEAD] a typo in a message In-Reply-To: <20161006064340.GR30569@gnu.org> (ineiev@gnu.org's message of "Thu, 6 Oct 2016 02:43:41 -0400") References: <20161005143617.GP30569@gnu.org> <87zimig2g8.fsf@wheatstone.g10code.de> <20161006064340.GR30569@gnu.org> Message-ID: <877f9le3nj.fsf@wheatstone.g10code.de> On Thu, 6 Oct 2016 08:43, ineiev at gnu.org said: > + log_info (_("WARNING: Encrypting to %s, " > + "a key with all user IDs revoked\n"), Actually there should be no such message. Gpg should never allow to encrypt to a revoked key. "Can't encrypted because of a revoked key" (or "...due to a key with no valid user ids") Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From dkg at fifthhorseman.net Fri Oct 7 00:31:04 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 06 Oct 2016 18:31:04 -0400 Subject: [PATCH v3 3/5] gpg-agent: Implement --supervised command (for systemd, etc). In-Reply-To: <87ponfi7nv.fsf@wheatstone.g10code.de> References: <87vaz7rq1k.fsf@alice.fifthhorseman.net> <1470980281-2675-1-git-send-email-dkg@fifthhorseman.net> <1470980281-2675-4-git-send-email-dkg@fifthhorseman.net> <87oa30jfz9.fsf@wheatstone.g10code.de> <87vax7760i.fsf@alice.fifthhorseman.net> <87ponfi7nv.fsf@wheatstone.g10code.de> Message-ID: <87oa2x3yaf.fsf@alice.fifthhorseman.net> On Wed 2016-10-05 03:20:20 -0400, Werner Koch wrote: > On Wed, 5 Oct 2016 06:51, dkg at fifthhorseman.net said: > >> I've tested this and there are a few problems still aside from the >> patch i've sent to the list. > > My fault. I had to rebase my commits before pushing. This required > some manual edits and although I recall that I added initialize_modules > to the supervised mode, that somehow got lost. > > I pushed a fix. Thanks. with these fixes, i now consistently get the abort, regardless of the valud of the log-file directive :) the backtrace on the abort is: Program received signal SIGABRT, Aborted. __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58 58 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58 #1 0x00007fd5d80f240a in __GI_abort () at abort.c:89 #2 0x00007fd5d812ebd0 in __libc_message (do_abort=do_abort at entry=2, fmt=fmt at entry=0x7fd5d8223c10 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175 #3 0x00007fd5d8134fa6 in malloc_printerr (action=3, str=0x7fd5d822080b "malloc(): memory corruption", ptr=, ar_ptr=) at malloc.c:5046 #4 0x00007fd5d8136f79 in _int_malloc (av=av at entry=0x7fd5d8456b00 , bytes=bytes at entry=720) at malloc.c:3509 #5 0x00007fd5d81399ab in __libc_calloc (n=, elem_size=) at malloc.c:3271 #6 0x00007fd5d88872cc in parse_format (max_argspecs=5, r_argspecs_count=, argspecs_addr=, format=0x5603f0738562 "02d ") at ../../src/estream-printf.c:672 #7 _gpgrt_estream_format (outfnc=outfnc at entry=0x7fd5d8882fd0 , outfncarg=outfncarg at entry=0x5603f0fc2d40, format=0x5603f0738548 "%04d-%02d-%02d %02d:%02d:%02d ", vaargs=0x7ffe45981e90, vaargs at entry=0x7ffe45981e80) at ../../src/estream-printf.c:1506 #8 0x00007fd5d8885508 in es_print (ap=ap at entry=0x7ffe45981e80, format=, stream=0x5603f0fc2d40) at ../../src/estream.c:2939 #9 _gpgrt_vfprintf_unlocked (stream=0x5603f0fc2d40, format=, ap=ap at entry=0x7ffe45981e90) at ../../src/estream.c:4382 #10 0x00007fd5d8889b34 in gpgrt_fprintf_unlocked (stream=, format=format at entry=0x5603f0738548 "%04d-%02d-%02d %02d:%02d:%02d ") at ../../src/visibility.c:570 #11 0x00005603f071baa6 in do_logv (level=level at entry=2, ignore_arg_ptr=ignore_arg_ptr at entry=0, fmt=0x5603f072fec8 "using fd %d for %s socket (%s)\n", arg_ptr=arg_ptr at entry=0x7ffe45981fd0) at ../../common/logging.c:673 #12 0x00005603f071c943 in log_info (fmt=) at ../../common/logging.c:817 #13 0x00005603f06f6525 in map_supervised_sockets (r_fd_ssh=, r_fd_browser=, r_fd_extra=, r_fd=) at ../../agent/gpg-agent.c:755 #14 main (argc=, argv=) at ../../agent/gpg-agent.c:1484 (gdb) --dkg From gniibe at fsij.org Fri Oct 7 04:35:22 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 7 Oct 2016 11:35:22 +0900 Subject: [PATCH v3 3/5] gpg-agent: Implement --supervised command (for systemd, etc). In-Reply-To: <87oa2x3yaf.fsf@alice.fifthhorseman.net> References: <87vaz7rq1k.fsf@alice.fifthhorseman.net> <1470980281-2675-1-git-send-email-dkg@fifthhorseman.net> <1470980281-2675-4-git-send-email-dkg@fifthhorseman.net> <87oa30jfz9.fsf@wheatstone.g10code.de> <87vax7760i.fsf@alice.fifthhorseman.net> <87ponfi7nv.fsf@wheatstone.g10code.de> <87oa2x3yaf.fsf@alice.fifthhorseman.net> Message-ID: <4d223a1f-f236-5d7d-6be3-71b40b8fba47@fsij.org> On 10/07/2016 07:31 AM, Daniel Kahn Gillmor wrote: > Program received signal SIGABRT, Aborted. > #3 0x00007fd5d8134fa6 in malloc_printerr (action=3, str=0x7fd5d822080b "malloc(): memory corruption", ptr=, ar_ptr=) at malloc.c:5046 > #4 0x00007fd5d8136f79 in _int_malloc (av=av at entry=0x7fd5d8456b00 , bytes=bytes at entry=720) at malloc.c:3509 > #5 0x00007fd5d81399ab in __libc_calloc (n=, elem_size=) at malloc.c:3271 [...] > #12 0x00005603f071c943 in log_info (fmt=) at ../../common/logging.c:817 > #13 0x00005603f06f6525 in map_supervised_sockets (r_fd_ssh=, r_fd_browser=, r_fd_extra=, r_fd=) at ../../agent/gpg-agent.c:755 > #14 main (argc=, argv=) at ../../agent/gpg-agent.c:1484 I fixed another part. This is possibly related to this SIGABRT. The commit is: fc0b392e766af8127094e8b529d25abb84ad1d65 Before this fix, npth_protect/npth_unprotect was called with uninitialized semaphore by libgpg-error. -- From dkg at fifthhorseman.net Fri Oct 7 06:42:39 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 07 Oct 2016 00:42:39 -0400 Subject: [PATCH v3 3/5] gpg-agent: Implement --supervised command (for systemd, etc). In-Reply-To: <4d223a1f-f236-5d7d-6be3-71b40b8fba47@fsij.org> References: <87vaz7rq1k.fsf@alice.fifthhorseman.net> <1470980281-2675-1-git-send-email-dkg@fifthhorseman.net> <1470980281-2675-4-git-send-email-dkg@fifthhorseman.net> <87oa30jfz9.fsf@wheatstone.g10code.de> <87vax7760i.fsf@alice.fifthhorseman.net> <87ponfi7nv.fsf@wheatstone.g10code.de> <87oa2x3yaf.fsf@alice.fifthhorseman.net> <4d223a1f-f236-5d7d-6be3-71b40b8fba47@fsij.org> Message-ID: <87y4203h34.fsf@alice.fifthhorseman.net> Hi Niibe-- On Thu 2016-10-06 22:35:22 -0400, NIIBE Yutaka wrote: > On 10/07/2016 07:31 AM, Daniel Kahn Gillmor wrote: >> Program received signal SIGABRT, Aborted. >> #3 0x00007fd5d8134fa6 in malloc_printerr (action=3, str=0x7fd5d822080b "malloc(): memory corruption", ptr=, ar_ptr=) at malloc.c:5046 >> #4 0x00007fd5d8136f79 in _int_malloc (av=av at entry=0x7fd5d8456b00 , bytes=bytes at entry=720) at malloc.c:3509 >> #5 0x00007fd5d81399ab in __libc_calloc (n=, elem_size=) at malloc.c:3271 > [...] >> #12 0x00005603f071c943 in log_info (fmt=) at ../../common/logging.c:817 >> #13 0x00005603f06f6525 in map_supervised_sockets (r_fd_ssh=, r_fd_browser=, r_fd_extra=, r_fd=) at ../../agent/gpg-agent.c:755 >> #14 main (argc=, argv=) at ../../agent/gpg-agent.c:1484 > > I fixed another part. This is possibly related to this SIGABRT. > The commit is: fc0b392e766af8127094e8b529d25abb84ad1d65 > > Before this fix, npth_protect/npth_unprotect was called with > uninitialized semaphore by libgpg-error. thanks for this, but even with this patch applied, i still see the SIGABRT. any suggestions for what else i should try to debug? :/ --dkg From ineiev at gnu.org Fri Oct 7 08:06:42 2016 From: ineiev at gnu.org (Ineiev) Date: Fri, 7 Oct 2016 02:06:42 -0400 Subject: [PATCH HEAD] a typo in a message In-Reply-To: <877f9le3nj.fsf@wheatstone.g10code.de> References: <20161005143617.GP30569@gnu.org> <87zimig2g8.fsf@wheatstone.g10code.de> <20161006064340.GR30569@gnu.org> <877f9le3nj.fsf@wheatstone.g10code.de> Message-ID: <20161007060642.GA30569@gnu.org> On Thu, Oct 06, 2016 at 08:25:04PM +0200, Werner Koch wrote: > On Thu, 6 Oct 2016 08:43, ineiev at gnu.org said: > > + log_info (_("WARNING: Encrypting to %s, " > > + "a key with all user IDs revoked\n"), > > Actually there should be no such message. Gpg should never allow to > encrypt to a revoked key. "Can't encrypted because of a revoked key" > (or "...due to a key with no valid user ids") Like this? diff --git a/g10/tofu.c b/g10/tofu.c index c100c43..858cde6 100644 --- a/g10/tofu.c +++ b/g10/tofu.c @@ -3052,9 +3052,13 @@ tofu_register_encryption (ctrl_t ctrl, free_user_id_list = 1; if (! user_id_list) - log_info (_("WARNING: Encrypting to %s, which has no" - "non-revoked user ids.\n"), - keystr (pk->keyid)); + { + log_error (_("error encrypting to %s: the key has no " + "usable user IDs.\n"), + keystr (pk->keyid)); + rc = gpg_error (GPG_ERR_UNUSABLE_PUBKEY); + goto die; + } } fingerprint = hexfingerprint (pk, NULL, 0); -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From ineiev at gnu.org Fri Oct 7 08:25:53 2016 From: ineiev at gnu.org (Ineiev) Date: Fri, 7 Oct 2016 02:25:53 -0400 Subject: [PATCH HEAD] a typo in a message In-Reply-To: <20161007060642.GA30569@gnu.org> References: <20161005143617.GP30569@gnu.org> <87zimig2g8.fsf@wheatstone.g10code.de> <20161006064340.GR30569@gnu.org> <877f9le3nj.fsf@wheatstone.g10code.de> <20161007060642.GA30569@gnu.org> Message-ID: <20161007062552.GB30569@gnu.org> On Fri, Oct 07, 2016 at 02:06:42AM -0400, Ineiev wrote: > > Like this? > > diff --git a/g10/tofu.c b/g10/tofu.c > index c100c43..858cde6 100644 > --- a/g10/tofu.c > +++ b/g10/tofu.c > @@ -3052,9 +3052,13 @@ tofu_register_encryption (ctrl_t ctrl, > free_user_id_list = 1; > > if (! user_id_list) > - log_info (_("WARNING: Encrypting to %s, which has no" > - "non-revoked user ids.\n"), > - keystr (pk->keyid)); > + { > + log_error (_("error encrypting to %s: the key has no " > + "usable user IDs.\n"), > + keystr (pk->keyid)); > + rc = gpg_error (GPG_ERR_UNUSABLE_PUBKEY); > + goto die; > + } > } > > fingerprint = hexfingerprint (pk, NULL, 0); Sorry, diff --git a/g10/tofu.c b/g10/tofu.c index c100c43..9a55ed8 100644 --- a/g10/tofu.c +++ b/g10/tofu.c @@ -3052,9 +3052,13 @@ tofu_register_encryption (ctrl_t ctrl, free_user_id_list = 1; if (! user_id_list) - log_info (_("WARNING: Encrypting to %s, which has no" - "non-revoked user ids.\n"), - keystr (pk->keyid)); + { + log_error (_("error encrypting to %s: the key has no " + "usable user IDs\n"), + keystr (pk->keyid)); + rc = gpg_error (GPG_ERR_UNUSABLE_PUBKEY); + goto die; + } } fingerprint = hexfingerprint (pk, NULL, 0); From wk at gnupg.org Fri Oct 7 08:39:07 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 07 Oct 2016 08:39:07 +0200 Subject: [adming[ MFT and Reply-to (was: permissions required on /run/user//gnupg) In-Reply-To: <20161006143642.GA3756@x2.esmtp.org> (Claus Assmann's message of "Thu, 6 Oct 2016 07:36:42 -0700") References: <87pone7qsv.fsf@alice.fifthhorseman.net> <87vax6g18c.fsf@wheatstone.g10code.de> <878tu27kx9.fsf@alice.fifthhorseman.net> <8737k9ygxm.fsf@europa.jade-hamburg.de> <878tu15zjh.fsf@alice.fifthhorseman.net> <20161006143642.GA3756@x2.esmtp.org> Message-ID: <87bmywbr3o.fsf_-_@wheatstone.g10code.de> On Thu, 6 Oct 2016 16:36, ca+gnupg-devel at esmtp.org said: > [Reply-to is set, please don't Cc me.] Please do not set Reply-To or MFT for an existing thread. You can't know whether the recipients in CC are subscribed to the list. MFT may only be set for the initial mail or if only the mailing list is the only recipient. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From wk at gnupg.org Fri Oct 7 08:35:31 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 07 Oct 2016 08:35:31 +0200 Subject: permissions required on /run/user//gnupg In-Reply-To: <8737k9ygxm.fsf@europa.jade-hamburg.de> (Justus Winter's message of "Thu, 06 Oct 2016 11:17:57 +0200") References: <87pone7qsv.fsf@alice.fifthhorseman.net> <87vax6g18c.fsf@wheatstone.g10code.de> <878tu27kx9.fsf@alice.fifthhorseman.net> <8737k9ygxm.fsf@europa.jade-hamburg.de> Message-ID: <87fuo8br9o.fsf@wheatstone.g10code.de> On Thu, 6 Oct 2016 11:17, justus at g10code.com said: > Oh? What about all the people not using systemd? The problem here is that Debian or systemd change long existing properties of the /var partition. Right, they now call it /run but it is nevertheless symlinked from /var/run. /var has a persistent directory structure for good reasons. It is also the most important partition for regular system backup. All things which are subject to regular change are stored under /var but entire directory structures should not be removed at init time or even logout time. What needs to be removed are stale lock files and PID stuff but only at the init time when they are not anymore valid. Some OSes take a simple approach to the latter by using a tmpfs for /var/run. However, the directory structure should in general be saved over shutdown/init because it carries important permission settings. > Fwiw, I do not like that GnuPG automagically uses /run/users/X if it > exists, because everytime I accidentally install some package that pulls > in the systemd component that creates these directories, my gnupg setup That happens only due to the defects mention above. What needs to be fixed is to save/restore the layout of /var/run during shutdown/init and only selectively unlink files or directories which are invalid after shutdown. The other option would be to let GnuPG create the /var/run/user/UID directory on the fly. However this requires configuration of userv and complicates the GnuPG code for no good reason. The session startup code could create that directory. GnuPG will already creates the gnupg subdirectory iff /var/run/user/UID exists. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From ineiev at gnu.org Fri Oct 7 08:44:46 2016 From: ineiev at gnu.org (Ineiev) Date: Fri, 7 Oct 2016 02:44:46 -0400 Subject: [PATCH HEAD] i18n fixes In-Reply-To: <87r37ug0ih.fsf@wheatstone.g10code.de> References: <20161005142930.GO30569@gnu.org> <20161005152417.GQ30569@gnu.org> <87r37ug0ih.fsf@wheatstone.g10code.de> Message-ID: <20161007064446.GC30569@gnu.org> On Wed, Oct 05, 2016 at 07:37:42PM +0200, Werner Koch wrote: > On Wed, 5 Oct 2016 17:24, ineiev at gnu.org said: > > > I really think this is where context should be used > > with the messages joined, like > > Right. We usuallay do this with ad-hoc methods instead of the > non-portable pgettext. I wonder if pgettext is really non-portable. > Anyway, many texts in tofu.c are not suitable for translation because > they split strings and translate only parts. Instead of providing lot > of contexts and a bulk of very similar strings, we should rework the > texts to be better translatable. That may require that we resort to > some table-like texts, like Indeed, the number of fragments can be dramatically reduced in this message, with more context provided. the drawback is that the total volume of msgids increases because the new strings share more parts. diff --git a/g10/tofu.c b/g10/tofu.c index c100c43..bd47eb0 100644 --- a/g10/tofu.c +++ b/g10/tofu.c @@ -1556,7 +1556,6 @@ ask_about_binding (ctrl_t ctrl, key = stats_iter->fingerprint; this_key = strcmp (key, fingerprint) == 0; key_pp = format_hexfingerprint (key, NULL, 0); - es_fprintf (fp, " %s (", key_pp); /* Find the associated binding. */ for (binding = conflict_set; @@ -1567,22 +1566,15 @@ ask_about_binding (ctrl_t ctrl, log_assert (binding); if ((binding->flags & BINDING_REVOKED)) - { - es_fprintf (fp, _("revoked")); - es_fprintf (fp, _(", ")); - } + es_fprintf (fp, " %s (binding revoked, ", key_pp); else if ((binding->flags & BINDING_EXPIRED)) - { - es_fprintf (fp, _("expired")); - es_fprintf (fp, _(", ")); - } + es_fprintf (fp, " %s (binding expired, ", key_pp); if (this_key) - es_fprintf (fp, _("this key")); + es_fprintf (fp, _("this key):\n")); else - es_fprintf (fp, _("policy: %s"), + es_fprintf (fp, _("policy: %s):\n"), tofu_policy_str (stats_iter->policy)); - es_fputs ("):\n", fp); xfree (key_pp); seen_in_past = 0; -------------- 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 Oct 7 09:05:08 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 07 Oct 2016 09:05:08 +0200 Subject: permissions required on /run/user//gnupg In-Reply-To: <878tu27kx9.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 05 Oct 2016 13:41:38 -0400") References: <87pone7qsv.fsf@alice.fifthhorseman.net> <87vax6g18c.fsf@wheatstone.g10code.de> <878tu27kx9.fsf@alice.fifthhorseman.net> Message-ID: <877f9kbpwb.fsf@wheatstone.g10code.de> On Wed, 5 Oct 2016 19:41, dkg at fifthhorseman.net said: > is the concern here about "hijacking" like what gpg-agent did? No, it is just a general precaution concerting private keys. Maybe I am a bit too over-conservative here. > wanting to reuse code where possible, i think we might need to make the > two decisions differently. No. The original idea we had for agent/gpg separation was the use --extra-socket. Now, that we create --extra-socket by default in the standard socket directory, the original assumption changed because --extra socket is not anymore configured external to GnuPG and now needs to live with the same permissions as the standard socket. That change, although quite convenient, made thye extra socket feature less flexible. Maybe we should revert this default again. > so if the permissions on ~/.gnupg are too loose, the agent won't listen > on a socket there -- is that right? The effect is that gpg prints a warning and disables the execution of external programs. The agent was only recently fixed to restrict the permissions on the socket file: commit 8127043d549a5843ea1ba2dc6da4906fc2258d53 Date: Wed Jun 8 16:18:02 2016 +0200 Explicitly restrict socket permissions. * agent/gpg-agent.c (create_server_socket): Call chmod before listen. * scd/scdaemon.c (create_server_socket): Ditto. * dirmngr/dirmngr.c (main): Ditto. -- This is just in case of a improperly set umask. Note that a connect requires a write permissions. > I'd love for them to go away as well! how should we cope with > non-standard homedirs, though? I'm thinking about test suites, or "gpgconf --create-socketdir" creates a socket directory for any homedir. It is not done automatically so not to clutter /run/user/UID/gnupg with lots of dedicated socket directories. >> Shouldn't we discuss this based on a concrete proposal? > > well, i tried to make a concrete proposal, though i grant that it's more > complicated than the current situation :) I meant a use case on how to use gnupg. > if the parent directory is mode 0700, then any subdirectory won't be > accessible to a different user, right? Right, but only as long as you don't have an fd for such a subdirectory. As long as it is not required otherwise better also restrict the permissions of the subdirectories. > could you point me to it? I'd like to follow up on > https://0xacab.org/monkeysphere/monkeysign/issues/9#note_10491 Bug#839115: gpg and "sudo -E gpg" use different agent sockets and can't talk to each other The use case is backup/restore and Josh asked for an option to tell gpg a different agent socket. > There are several different use cases for clients of gpg-agent to use a > distinct agent. Where would you like me to document them? Frankly, I doubt that we can achieve that before 2.2 or the Debian freeze. Thus we should now direct our discussions to not introduce road blockers for the future but not come up with full proposals. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From wk at gnupg.org Fri Oct 7 11:12:05 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 07 Oct 2016 11:12:05 +0200 Subject: [PATCH HEAD] a typo in a message In-Reply-To: <20161007062552.GB30569@gnu.org> (ineiev@gnu.org's message of "Fri, 7 Oct 2016 02:25:53 -0400") References: <20161005143617.GP30569@gnu.org> <87zimig2g8.fsf@wheatstone.g10code.de> <20161006064340.GR30569@gnu.org> <877f9le3nj.fsf@wheatstone.g10code.de> <20161007060642.GA30569@gnu.org> <20161007062552.GB30569@gnu.org> Message-ID: <87y420a5ga.fsf@wheatstone.g10code.de> On Fri, 7 Oct 2016 08:25, ineiev at gnu.org said: >> Like this? Yes, but this duplicates a check we will do later anyway. We need to think this through. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From wk at gnupg.org Fri Oct 7 11:18:37 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 07 Oct 2016 11:18:37 +0200 Subject: [PATCH HEAD] i18n fixes In-Reply-To: <20161007064446.GC30569@gnu.org> (ineiev@gnu.org's message of "Fri, 7 Oct 2016 02:44:46 -0400") References: <20161005142930.GO30569@gnu.org> <20161005152417.GQ30569@gnu.org> <87r37ug0ih.fsf@wheatstone.g10code.de> <20161007064446.GC30569@gnu.org> Message-ID: <87twcoa55e.fsf@wheatstone.g10code.de> On Fri, 7 Oct 2016 08:44, ineiev at gnu.org said: > I wonder if pgettext is really non-portable. The gettext checks try to make use of other gettext implemntations. pgettext is not available on non GNU systems and anyway pretty new. > Indeed, the number of fragments can be dramatically reduced in this > message, with more context provided. the drawback is that the total > volume of msgids increases because the new strings share more parts. Let me quote from the gettext manual: Translatable strings should be entire sentences. It is often not possible to translate single verbs or adjectives in a substitutable way. [...] Entire sentences are also important because in many languages, the declination of some word in a sentence depends on the gender or the number (singular/plural) of another part of the sentence. There are usually more interdependencies between words than in English. The consequence is that asking a translator to translate two half-sentences and then combining these two half-sentences through dumb string concatenation will not work, for many languages, even though it would work for English. That?s why translators need to handle entire sentences. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From gniibe at fsij.org Fri Oct 7 12:11:43 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 7 Oct 2016 19:11:43 +0900 Subject: [PATCH v3 3/5] gpg-agent: Implement --supervised command (for systemd, etc). In-Reply-To: <87y4203h34.fsf@alice.fifthhorseman.net> References: <87vaz7rq1k.fsf@alice.fifthhorseman.net> <1470980281-2675-1-git-send-email-dkg@fifthhorseman.net> <1470980281-2675-4-git-send-email-dkg@fifthhorseman.net> <87oa30jfz9.fsf@wheatstone.g10code.de> <87vax7760i.fsf@alice.fifthhorseman.net> <87ponfi7nv.fsf@wheatstone.g10code.de> <87oa2x3yaf.fsf@alice.fifthhorseman.net> <4d223a1f-f236-5d7d-6be3-71b40b8fba47@fsij.org> <87y4203h34.fsf@alice.fifthhorseman.net> Message-ID: On 10/07/2016 01:42 PM, Daniel Kahn Gillmor wrote: > thanks for this, but even with this patch applied, i still see the > SIGABRT. any suggestions for what else i should try to debug? :/ Apparently, it's some problem around allocated memory. Well, in for a penny... Here is one more fix: fb3b3e1e7a4219f61a834fd07809898918611c2f I believe that this fix the memory corruption issue. -- From dkg at fifthhorseman.net Fri Oct 7 14:34:15 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 07 Oct 2016 08:34:15 -0400 Subject: [PATCH v3 3/5] gpg-agent: Implement --supervised command (for systemd, etc). In-Reply-To: References: <87vaz7rq1k.fsf@alice.fifthhorseman.net> <1470980281-2675-1-git-send-email-dkg@fifthhorseman.net> <1470980281-2675-4-git-send-email-dkg@fifthhorseman.net> <87oa30jfz9.fsf@wheatstone.g10code.de> <87vax7760i.fsf@alice.fifthhorseman.net> <87ponfi7nv.fsf@wheatstone.g10code.de> <87oa2x3yaf.fsf@alice.fifthhorseman.net> <4d223a1f-f236-5d7d-6be3-71b40b8fba47@fsij.org> <87y4203h34.fsf@alice.fifthhorseman.net> Message-ID: <87vax42v94.fsf@alice.fifthhorseman.net> On Fri 2016-10-07 06:11:43 -0400, NIIBE Yutaka wrote: > On 10/07/2016 01:42 PM, Daniel Kahn Gillmor wrote: >> thanks for this, but even with this patch applied, i still see the >> SIGABRT. any suggestions for what else i should try to debug? :/ > > Apparently, it's some problem around allocated memory. > > Well, in for a penny... > > Here is one more fix: fb3b3e1e7a4219f61a834fd07809898918611c2f > > I believe that this fix the memory corruption issue. It does, thanks! I've tested this and it works for gpg-agent running in socket-activated mode under systemd supervision. For debian folks following along, i've uploaded 2.1.15-4 to debian unstable with a bunch of upstream patches, and with tuned/improved user .service and .socket files for gpg-agent. They're not enabled by default, but instructions for setup can be found in /usr/share/doc/gnupg-agent/README.Debian . I welcome any tests and reports of issues! --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From meno.abels at adviser.com Fri Oct 7 16:07:24 2016 From: meno.abels at adviser.com (Meno Abels) Date: Fri, 7 Oct 2016 16:07:24 +0200 Subject: gpg2 2.1.5 exports non existing private keys Message-ID: <80740880-D99D-48E7-9E3A-9CFC8417A149@adviser.com> Hello, i have on my system no private keys and 2.0.30_2 does this: /usr/local/Cellar/gnupg2/2.0.30_2/bin/gpg2 --export-secret-keys -a xxxxxBEEF gpg: WARNING: nothing exported if i do this with 2.1.15 i get: -----BEGIN PGP PRIVATE KEY BLOCK----- Comment: GPGTools - http://gpgtools.org lDsEV02MJBYJKwYBBAHaRw8BAQdAHBS1e25+m5QZw7zU0giU6pNotiW7wj2boJzg 5bAKXV//?.. ?. is this the right behaviour? thx in advance meno From ml at filippo.io Fri Oct 7 17:48:19 2016 From: ml at filippo.io (Filippo Valsorda) Date: Fri, 07 Oct 2016 11:48:19 -0400 Subject: sshcontrol, confirm flag and smartcards Message-ID: <1475855299.3053076.749036441.7A479EB4@webmail.messagingengine.com> Hello, I'm using a smartcard to hold my SSH key. Everything is functional out of the box. From the man page: > Note that keys available > through a OpenPGP smartcard in the active smartcard reader are > implicitly added to this list; i.e. there is no need to list them. However, I want to enable the "confirm" flag. So I added a line with the keygrip to sshcontrol. Now I see two keys over the ssh-agent with identical fingerprints (so I didn't get the keygrip wrong): ssh-add -l 2048 SHA256:[REDACTED] cardno:[REDACTED] (RSA) 2048 SHA256:[REDACTED] (none) (RSA) Which gets annoying because all operations are attempted twice (for example if authentication fails), and I suspect it also allows a "confirm" bypass. I suspect gnupg should deduplicate them automatically. I'm on gpg (GnuPG) 2.1.15 on OS X. Thanks [Please keep me CC'd] From dkg at fifthhorseman.net Fri Oct 7 18:23:34 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 07 Oct 2016 12:23:34 -0400 Subject: gpg2 2.1.5 exports non existing private keys In-Reply-To: <80740880-D99D-48E7-9E3A-9CFC8417A149@adviser.com> References: <80740880-D99D-48E7-9E3A-9CFC8417A149@adviser.com> Message-ID: <87d1jc2kmx.fsf@alice.fifthhorseman.net> Hi Meno-- On Fri 2016-10-07 10:07:24 -0400, Meno Abels wrote: > i have on my system no private keys and 2.0.30_2 does this: > > /usr/local/Cellar/gnupg2/2.0.30_2/bin/gpg2 --export-secret-keys -a xxxxxBEEF > gpg: WARNING: nothing exported how do you know that you have no private keys? do you have anything in ~/.gnupg/private-keys-v1.d/ ? > if i do this with 2.1.15 i get: > > -----BEGIN PGP PRIVATE KEY BLOCK----- > Comment: GPGTools - http://gpgtools.org > > lDsEV02MJBYJKwYBBAHaRw8BAQdAHBS1e25+m5QZw7zU0giU6pNotiW7wj2boJzg > 5bAKXV//?.. > ?. > > is this the right behaviour? versions of GnuPG before 2.1 kept their OpenPGP secret key material in ~/.gnupg/secring.gpg. since 2.1, secret key material is stored in the gpg-agent itself, which by default will manage them in ~/.gnupg/private-keys-v1.d/. hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From meno.abels at adviser.com Fri Oct 7 19:13:43 2016 From: meno.abels at adviser.com (Meno Abels) Date: Fri, 07 Oct 2016 17:13:43 +0000 Subject: gpg2 2.1.5 exports non existing private keys In-Reply-To: <87d1jc2kmx.fsf@alice.fifthhorseman.net> References: <80740880-D99D-48E7-9E3A-9CFC8417A149@adviser.com> <87d1jc2kmx.fsf@alice.fifthhorseman.net> Message-ID: Hi my keys should be in a smartcard and the card is not attached meno On Fri, Oct 7, 2016, 18:23 Daniel Kahn Gillmor wrote: > Hi Meno-- > > On Fri 2016-10-07 10:07:24 -0400, Meno Abels wrote: > > > i have on my system no private keys and 2.0.30_2 does this: > > > > /usr/local/Cellar/gnupg2/2.0.30_2/bin/gpg2 --export-secret-keys -a > xxxxxBEEF > > gpg: WARNING: nothing exported > > how do you know that you have no private keys? do you have anything in > ~/.gnupg/private-keys-v1.d/ ? > > > if i do this with 2.1.15 i get: > > > > -----BEGIN PGP PRIVATE KEY BLOCK----- > > Comment: GPGTools - http://gpgtools.org > > > > lDsEV02MJBYJKwYBBAHaRw8BAQdAHBS1e25+m5QZw7zU0giU6pNotiW7wj2boJzg > > 5bAKXV//?.. > > ?. > > > > is this the right behaviour? > > versions of GnuPG before 2.1 kept their OpenPGP secret key material in > ~/.gnupg/secring.gpg. since 2.1, secret key material is stored in the > gpg-agent itself, which by default will manage them in > ~/.gnupg/private-keys-v1.d/. > > hth, > > --dkg > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Fri Oct 7 22:52:46 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 07 Oct 2016 16:52:46 -0400 Subject: [pkg-gnupg-maint] Bug#839991: gnupg-agent: 'allow-emacs-pinentry' setting in agent conf makes gpg2 respond no secret key In-Reply-To: <87shs84n5t.fsf@fsfe.org> References: <87shs84n5t.fsf@fsfe.org> Message-ID: <87a8ef2869.fsf@alice.fifthhorseman.net> Control: found 839991 2.1.15-4 Control: affects 839991 src:pinentry Hi Kevin! (i'm cc'ing the upstream mailing list about this, hope that's OK) On Fri 2016-10-07 03:46:06 -0400, Kevin Brubeck Unhammer wrote: > Package: gnupg-agent > Version: 2.1.11-6ubuntu2 hm, this isn't a debian version number. I've just tried to replicate in debian, though, and found the same behavior in 2.1.15-4. > and then I tried "gpg --decrypt ~/.authinfo.gpg" from a regular > terminal (not inside Emacs). This gave me the confusing message "no > secret key", where before it had worked just fine (with a gtk2 > pinentry dialog asking for my password). > > Removing the "allow-emacs-pinentry" and doing "gpgconf --reload > gpg-agent" makes regular "gpg --decrypt ~/.authinfo.gpg" work again. here's what i'm seeing in gpg-agent's log when i have "debug-pinentry" turned on: Oct 07 16:39:10 alice gpg-agent[20025]: starting a new PIN Entry Oct 07 16:39:10 alice gpg-agent[20025]: DBG: chan_9 <- OK Pleased to meet you, process 20025 Oct 07 16:39:10 alice gpg-agent[20025]: DBG: connection to PIN entry established Oct 07 16:39:10 alice gpg-agent[20025]: DBG: chan_9 -> OPTION grab Oct 07 16:39:10 alice gpg-agent[20025]: DBG: chan_9 <- OK Oct 07 16:39:10 alice gpg-agent[20025]: DBG: chan_9 -> OPTION ttytype=rxvt Oct 07 16:39:10 alice gpg-agent[20025]: DBG: chan_9 <- OK Oct 07 16:39:10 alice gpg-agent[20025]: DBG: chan_9 -> OPTION allow-emacs-prompt Oct 07 16:39:10 alice gpg-agent[20025]: DBG: chan_9 <- ERR 83886140 Not supported Oct 07 16:39:10 alice gpg-agent[20025]: DBG: error calling pinentry: Not supported Oct 07 16:39:10 alice gpg-agent[20025]: DBG: chan_9 -> BYE Oct 07 16:39:10 alice gpg-agent[20025]: failed to unprotect the secret key: Not supported Oct 07 16:39:10 alice gpg-agent[20025]: failed to read the secret key Oct 07 16:39:10 alice gpg-agent[20025]: command 'PKSIGN' failed: Not supported Oct 07 16:39:10 alice gpg-agent[20025]: DBG: chan_8 -> ERR 83886140 Not supported Oct 07 16:39:10 alice gpg-agent[20025]: DBG: chan_8 <- [eof] Oct 07 16:39:10 alice gpg-agent[20025]: handler 0x7fc8e9a95700 for fd 8 terminated > If Debian needs to remove Emacs pinentry support from gnupg, it should > probably still have a better error message. I think the bug here is that gpg-agent shouldn't choke if it asks for allow-emacs-prompt but it's not available. The relevant code is in agent/call-pinentry.c: ------------ if (opt.allow_external_cache) { /* Indicate to the pinentry that it may read from an external cache. It is essential that the pinentry respect this. If the cached password is not up to date and retry == 1, then, using a version of GPG Agent that doesn't support this, won't issue another pin request and the user won't get a chance to correct the password. */ rc = assuan_transact (entry_ctx, "OPTION allow-external-password-cache", NULL, NULL, NULL, NULL, NULL, NULL); if (rc && gpg_err_code (rc) != GPG_ERR_UNKNOWN_OPTION) return unlock_pinentry (rc); } if (opt.allow_emacs_pinentry) { /* Indicate to the pinentry that it may read passphrase through Emacs minibuffer, if possible. */ rc = assuan_transact (entry_ctx, "OPTION allow-emacs-prompt", NULL, NULL, NULL, NULL, NULL, NULL); if (rc && gpg_err_code (rc) != GPG_ERR_UNKNOWN_OPTION) return unlock_pinentry (rc); } ------------ I don't think i understand the logic of the comment in the first stanza. should "a version of GPG Agent that doesn't support this" be "a version of pinentry that doesn't support this" ? Even so, i don't see why the pinentry should hard-fail here. In any case, even if the logic of the first stanza is correct and it should be terminating if that option isn't available, it's not clear that the same logic applies to allow-emacs-prompt. Some pinentries that we ship in debian *do* support an external passphrase cache, and others do not (as a way to minimize dependencies on systems that will never run a passphrase cache like gnome-keyring). Does that mean that all those minimal pinentries must never work? No debian pinentries currently support emacs mode, fwiw. But whether they should or not is probably a different bug report than this one. --dkg From dkg at fifthhorseman.net Fri Oct 7 22:28:47 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 07 Oct 2016 16:28:47 -0400 Subject: gpg2 2.1.5 exports non existing private keys In-Reply-To: References: <80740880-D99D-48E7-9E3A-9CFC8417A149@adviser.com> <87d1jc2kmx.fsf@alice.fifthhorseman.net> Message-ID: <87fuo729a8.fsf@alice.fifthhorseman.net> On Fri 2016-10-07 13:13:43 -0400, Meno Abels wrote: > Hi my keys should be in a smartcard and the card is not attached is it possible that 2.1.15 is emitting "private keys" with a dummy value? can you run the output of the export through pgpdump or "gpg --list-packets" or "hot dump" (from hOpenPGP-tools) and report on what it says? --dkg PS i just noticed that your subject says 2.1.5, but the body of your mail said 2.1.15 -- i'm assuming that 2.1.5 is a typo. From wk at gnupg.org Sat Oct 8 10:56:52 2016 From: wk at gnupg.org (Werner Koch) Date: Sat, 08 Oct 2016 10:56:52 +0200 Subject: [pkg-gnupg-maint] Bug#839991: gnupg-agent: 'allow-emacs-pinentry' setting in agent conf makes gpg2 respond no secret key In-Reply-To: <87a8ef2869.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 07 Oct 2016 16:52:46 -0400") References: <87shs84n5t.fsf@fsfe.org> <87a8ef2869.fsf@alice.fifthhorseman.net> Message-ID: <87ponb5icr.fsf@wheatstone.g10code.de> Hi! [CCing Ueno-san as Emacs Pinentry author] On Fri, 7 Oct 2016 22:52, dkg at fifthhorseman.net said: > Oct 07 16:39:10 alice gpg-agent[20025]: DBG: chan_9 <- OK Pleased to meet you, process 20025 Note to self: We should really print the type and version of the Pinentry here. > Oct 07 16:39:10 alice gpg-agent[20025]: DBG: chan_9 -> OPTION allow-emacs-prompt > Oct 07 16:39:10 alice gpg-agent[20025]: DBG: chan_9 <- ERR 83886140 Not supported Okay, so pinentry knows about this option but opts to tell the caller that it does not support it. In gpg-agent we > rc = assuan_transact (entry_ctx, "OPTION allow-emacs-prompt", > NULL, NULL, NULL, NULL, NULL, NULL); > if (rc && gpg_err_code (rc) != GPG_ERR_UNKNOWN_OPTION) > return unlock_pinentry (rc); bail out on this error because the Pinentry told us that it knows about the option. So it was a Pinentry choice to return that error. > No debian pinentries currently support emacs mode, fwiw. But whether > they should or not is probably a different bug report than this one. The interesting part is in Pinentry: else if (!strcmp (key, "allow-emacs-prompt") && !*value) { #ifdef INSIDE_EMACS pinentry_enable_emacs_cmd_handler (); #else return gpg_error (GPG_ERR_NOT_SUPPORTED); #endif } Thus pinentry always tells us that it is not supported unless it is a Pinentry which was build with Emacs support. Alrthough we could handle this in gpg-agent, I consider it better to fix this in Pinentry. The name "allow-emacs-prompt" means to me that Emacs support is optional and thus Pinentry should just return OK. A new Pinentry version is anyway due. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From lists at ssl-mail.com Sun Oct 9 17:43:03 2016 From: lists at ssl-mail.com (lists at ssl-mail.com) Date: Sun, 09 Oct 2016 08:43:03 -0700 Subject: gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)" Message-ID: <1476027783.1522252.750391089.07374952@webmail.messagingengine.com> I've installed gpg2 --version gpg (GnuPG) 2.1.15 libgcrypt 1.7.3 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: /home/test/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 I can generate key pairs and rev certs OK. But when I try to upload/retrieve from any keyserver, I get "ERR 167772346 No keyserver available ". Here's an attempt with keyserver == pool @ hkps://hkps.pool.sks-keyservers.net gpg -v --debug-all --recv-keys 0x673A03E4C1DB921F gpg: reading options from '/home/test/.gnupg/gpg.conf' gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing cardio ipc clock lookup extprog gpg: DBG: [not enabled in the source] start gpg: DBG: chan_3 <- # Home: /home/test/.gnupg gpg: DBG: chan_3 <- # Config: /home/test/.gnupg/dirmngr.conf gpg: DBG: chan_3 <- OK Dirmngr 2.1.15 at your service gpg: DBG: connection to the dirmngr established gpg: DBG: chan_3 -> GETINFO version gpg: DBG: chan_3 <- D 2.1.15 gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> KEYSERVER --clear hkps://hkps.pool.sks-keyservers.net gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> KS_GET -- 0x673A03E4C1DB921F gpg: DBG: chan_3 <- ERR 167772346 No keyserver available gpg: keyserver receive failed: No keyserver available gpg: DBG: chan_3 -> BYE gpg: DBG: [not enabled in the source] stop gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 gpg: secmem usage: 0/65536 bytes in 0 blocks I've tried a bunch of different keyservers with always the same result. I added logging to dirmgr.conf + log-file /var/log/gnupg/dirmngr.log On the failed attempt this is the log tail 2016-10-09 08:27:02 dirmngr[32460.0] permanently loaded certificates: 0 2016-10-09 08:27:02 dirmngr[32460.0] runtime cached certificates: 0 2016-10-09 08:27:03 dirmngr[32460.0] DNS query returned an error or no records: No such domain (nxdomain) 2016-10-09 08:27:03 dirmngr[32460.0] DNS query failed: System error w/o errno 2016-10-09 08:27:03 dirmngr[32460.0] resolving 'hkps.pool.sks-keyservers.net' failed: System error w/o errno 2016-10-09 08:27:03 dirmngr[32460.0] DNS query failed: System error w/o errno 2016-10-09 08:27:03 dirmngr[32460.0] resolving 'hkps.pool.sks-keyservers.net' failed: System error w/o errno 2016-10-09 08:27:03 dirmngr[32460.0] can't connect to 'hkps.pool.sks-keyservers.net': host not found 2016-10-09 08:27:03 dirmngr[32460.0] error connecting to 'https://hkps.pool.sks-keyservers.net:443': Unknown host 2016-10-09 08:27:03 dirmngr[32460.0] marking host 'hkps.pool.sks-keyservers.net' as dead 2016-10-09 08:27:03 dirmngr[32460.0] host 'hkps.pool.sks-keyservers.net' marked as dead 2016-10-09 08:27:03 dirmngr[32460.0] command 'KS_GET' failed: No keyserver available This DNS query returned an error or no records: No such domain (nxdomain) looks like a (R)DNS lookup problem from WITHIN dirmngr/gnupg Here, from cmd line host hkps.pool.sks-keyservers.net hkps.pool.sks-keyservers.net has address 92.43.111.21 hkps.pool.sks-keyservers.net has address 209.135.211.141 hkps.pool.sks-keyservers.net has address 104.236.209.43 hkps.pool.sks-keyservers.net has address 178.62.203.205 hkps.pool.sks-keyservers.net has address 212.12.48.27 hkps.pool.sks-keyservers.net has address 18.9.60.141 hkps.pool.sks-keyservers.net has address 193.164.133.100 hkps.pool.sks-keyservers.net has address 140.211.169.202 hkps.pool.sks-keyservers.net has address 37.97.129.189 hkps.pool.sks-keyservers.net has address 94.142.242.225 hkps.pool.sks-keyservers.net has IPv6 address 2a03:b0c0:2:d0::6e3:a001 hkps.pool.sks-keyservers.net has IPv6 address 2606:9500:201:1::141 hkps.pool.sks-keyservers.net has IPv6 address 2a02:898:31:0:48:4558:73:6b73 hkps.pool.sks-keyservers.net has IPv6 address 2a01:7c8:aabc:45a:5054:ff:fe9b:59a3 hkps.pool.sks-keyservers.net has IPv6 address 2604:a880:800:10::163:b001 hkps.pool.sks-keyservers.net has IPv6 address 2a02:c205:3001:3626::1 hkps.pool.sks-keyservers.net has IPv6 address 2a00:14b0:4200:3000:27::27 hkps.pool.sks-keyservers.net has IPv6 address 2a01:4a0:59:1000:223:9eff:fe00:100f dig A hkps.pool.sks-keyservers.net ; <<>> DiG 9.10.3-P4 <<>> A hkps.pool.sks-keyservers.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18016 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 10, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;hkps.pool.sks-keyservers.net. IN A ;; ANSWER SECTION: hkps.pool.sks-keyservers.net. 12 IN A 92.43.111.21 hkps.pool.sks-keyservers.net. 12 IN A 18.9.60.141 hkps.pool.sks-keyservers.net. 12 IN A 178.62.203.205 hkps.pool.sks-keyservers.net. 12 IN A 104.236.209.43 hkps.pool.sks-keyservers.net. 12 IN A 209.135.211.141 hkps.pool.sks-keyservers.net. 12 IN A 37.97.129.189 hkps.pool.sks-keyservers.net. 12 IN A 212.12.48.27 hkps.pool.sks-keyservers.net. 12 IN A 140.211.169.202 hkps.pool.sks-keyservers.net. 12 IN A 193.164.133.100 hkps.pool.sks-keyservers.net. 12 IN A 94.142.242.225 ;; Query time: 0 msec ;; SERVER: 10.19.2.100#53(10.19.2.100) ;; WHEN: Sun Oct 09 08:28:06 PDT 2016 ;; MSG SIZE rcvd: 217 From lists at ssl-mail.com Mon Oct 10 00:47:29 2016 From: lists at ssl-mail.com (lists at ssl-mail.com) Date: Sun, 09 Oct 2016 15:47:29 -0700 Subject: gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)" In-Reply-To: <20161009223833.GA4309@tower.spodhuis.org> References: <1476027783.1522252.750391089.07374952@webmail.messagingengine.com> <20161009223833.GA4309@tower.spodhuis.org> Message-ID: <1476053249.1594379.750625153.58F21EF5@webmail.messagingengine.com> hi On Sun, Oct 9, 2016, at 03:38 PM, Phil Pennock wrote: > What do you see? gpg-connect-agent --dirmngr > GETINFO dnsinfo OK - ADNS w/o Tor support > GETINFO tor ERR 167772416 False - Tor mode is NOT enabled > just fyi, more here @ https://bugs.gnupg.org/gnupg/issue2745 > If you're configured for tor mode I'm not ... I've tried specifying -- no nameserver, using the default -- an external, 3rd-party NS (google @ 8.8.8.8) -- my own bind ns on my lan All three cases show the same failure reported :-/ From gnupg-devel at spodhuis.org Mon Oct 10 00:38:33 2016 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Sun, 9 Oct 2016 22:38:33 +0000 Subject: gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)" In-Reply-To: <1476027783.1522252.750391089.07374952@webmail.messagingengine.com> References: <1476027783.1522252.750391089.07374952@webmail.messagingengine.com> Message-ID: <20161009223833.GA4309@tower.spodhuis.org> On 2016-10-09 at 08:43 -0700, lists at ssl-mail.com wrote: > I've installed > > gpg2 --version > But when I try to upload/retrieve from any keyserver, I get "ERR 167772346 No keyserver available ". Connect to the dirmngr and ask it about its DNS setup with two GETINFO commands: % gpg-connect-agent --dirmngr > GETINFO dnsinfo OK - ADNS w/o Tor support > GETINFO tor ERR 167772416 False - Tor mode is NOT enabled What do you see? Pure speculation: If you're configured for tor mode and using the default tor nameserver (8.8.8.8) perhaps that's now rejecting tor exit nodes when under load? -Phil From kristian.fiskerstrand at sumptuouscapital.com Mon Oct 10 02:33:16 2016 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Mon, 10 Oct 2016 02:33:16 +0200 Subject: gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)" In-Reply-To: <1476053249.1594379.750625153.58F21EF5@webmail.messagingengine.com> References: <1476027783.1522252.750391089.07374952@webmail.messagingengine.com> <20161009223833.GA4309@tower.spodhuis.org> <1476053249.1594379.750625153.58F21EF5@webmail.messagingengine.com> Message-ID: <2e4dc439-b882-83db-24a0-aa2e8e09b815@sumptuouscapital.com> On 10/10/2016 12:47 AM, lists at ssl-mail.com wrote: > hi .. > All three cases show the same failure reported :-/ > We need more info on what kind of system this is -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Ad astra per aspera To the stars through thorns -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From lists at ssl-mail.com Mon Oct 10 05:29:17 2016 From: lists at ssl-mail.com (lists at ssl-mail.com) Date: Sun, 09 Oct 2016 20:29:17 -0700 Subject: gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)" In-Reply-To: <2e4dc439-b882-83db-24a0-aa2e8e09b815@sumptuouscapital.com> References: <1476027783.1522252.750391089.07374952@webmail.messagingengine.com> <20161009223833.GA4309@tower.spodhuis.org> <1476053249.1594379.750625153.58F21EF5@webmail.messagingengine.com> <2e4dc439-b882-83db-24a0-aa2e8e09b815@sumptuouscapital.com> Message-ID: <1476070157.2434594.750764377.69D339B1@webmail.messagingengine.com> hi On Sun, Oct 9, 2016, at 05:33 PM, Kristian Fiskerstrand wrote: > > All three cases show the same failure reported :-/ > > > We need more info on what kind of system this is Not sure exactly what info you want. If more than this, just let me know specifics. lsb_release -rd Description: openSUSE Leap 42.1 (x86_64) Release: 42.1 uname -rm 4.8.1-2.g4861355-default x86_64 gpg2 --version gpg (GnuPG) 2.1.15 libgcrypt 1.7.3 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: /home/test/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 dirmngr --version dirmngr (GnuPG) 2.1.15 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. rpm -qa | egrep -i gpg gpg2-2.1.15-197.1.x86_64 gpg2-lang-2.1.15-197.1.noarch gpgme-1.7.0-100.1.x86_64 gpgmepp5-16.04.3-24.1.x86_64 libgpg-error0-1.24-74.1.x86_64 libgpg-error-devel-1.24-74.1.x86_64 libgpgme11-1.7.0-100.1.x86_64 libgpgme-devel-1.7.0-100.1.x86_64 libKF5QGpgme5-16.04.3-24.1.x86_64 From ueno at gnu.org Mon Oct 10 10:39:13 2016 From: ueno at gnu.org (Daiki Ueno) Date: Mon, 10 Oct 2016 10:39:13 +0200 Subject: [pkg-gnupg-maint] Bug#839991: gnupg-agent: 'allow-emacs-pinentry' setting in agent conf makes gpg2 respond no secret key In-Reply-To: <87ponb5icr.fsf@wheatstone.g10code.de> (Werner Koch's message of "Sat, 08 Oct 2016 10:56:52 +0200") References: <87shs84n5t.fsf@fsfe.org> <87a8ef2869.fsf@alice.fifthhorseman.net> <87ponb5icr.fsf@wheatstone.g10code.de> Message-ID: Werner Koch writes: > Alrthough we could handle this in gpg-agent, I consider it better to fix > this in Pinentry. The name "allow-emacs-prompt" means to me that Emacs > support is optional and thus Pinentry should just return OK. A new > Pinentry version is anyway due. That makes sense. How about this trivial patch? Regards, -- Daiki ueno -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-core-Don-t-report-error-on-setting-option.patch Type: text/x-patch Size: 958 bytes Desc: not available URL: From justus at g10code.com Mon Oct 10 12:47:09 2016 From: justus at g10code.com (Justus Winter) Date: Mon, 10 Oct 2016 12:47:09 +0200 Subject: sshcontrol, confirm flag and smartcards In-Reply-To: <1475855299.3053076.749036441.7A479EB4@webmail.messagingengine.com> References: <1475855299.3053076.749036441.7A479EB4@webmail.messagingengine.com> Message-ID: <87r37ozdjm.fsf@europa.jade-hamburg.de> Hello, Filippo Valsorda writes: > I'm using a smartcard to hold my SSH key. Everything is functional out > of the box. From the man page: > >> Note that keys available >> through a OpenPGP smartcard in the active smartcard reader are >> implicitly added to this list; i.e. there is no need to list them. > > However, I want to enable the "confirm" flag. So I added a line with the > keygrip to sshcontrol. I believe you can configure your smartcard to require a confirmation, not sure though. > Now I see two keys over the ssh-agent with identical fingerprints (so I > didn't get the keygrip wrong): > > ssh-add -l > 2048 SHA256:[REDACTED] cardno:[REDACTED] (RSA) > 2048 SHA256:[REDACTED] (none) (RSA) > > Which gets annoying because all operations are attempted twice (for > example if authentication fails), and I suspect it also allows a > "confirm" bypass. > > I suspect gnupg should deduplicate them automatically. Thanks for reporting. I created a bug report for this issue: https://bugs.gnupg.org/gnupg/issue2746 Cheers, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From thomas at glanzmann.de Mon Oct 10 15:10:36 2016 From: thomas at glanzmann.de (Thomas Glanzmann) Date: Mon, 10 Oct 2016 15:10:36 +0200 Subject: gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)" In-Reply-To: <1476053249.1594379.750625153.58F21EF5@webmail.messagingengine.com> References: <1476027783.1522252.750391089.07374952@webmail.messagingengine.com> <20161009223833.GA4309@tower.spodhuis.org> <1476053249.1594379.750625153.58F21EF5@webmail.messagingengine.com> Message-ID: <20161010131036.GC17876@glanzmann.de> Hello, > -- no nameserver, using the default > -- an external, 3rd-party NS (google @ 8.8.8.8) > -- my own bind ns on my lan since it is SuSE I suspect apparmor. Have you tried to disable it and try again? Cheers, Thomas From lists at ssl-mail.com Mon Oct 10 15:19:01 2016 From: lists at ssl-mail.com (lists at ssl-mail.com) Date: Mon, 10 Oct 2016 06:19:01 -0700 Subject: gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)" In-Reply-To: <20161010131036.GC17876@glanzmann.de> References: <1476027783.1522252.750391089.07374952@webmail.messagingengine.com> <20161009223833.GA4309@tower.spodhuis.org> <1476053249.1594379.750625153.58F21EF5@webmail.messagingengine.com> <20161010131036.GC17876@glanzmann.de> Message-ID: <1476105541.3317580.751181353.553BB041@webmail.messagingengine.com> On Mon, Oct 10, 2016, at 06:10 AM, Thomas Glanzmann wrote: > since it is SuSE I suspect apparmor. Have you tried to disable it and > try again? No, AppArmor is not it use here; never has been ... From wk at gnupg.org Mon Oct 10 21:36:35 2016 From: wk at gnupg.org (Werner Koch) Date: Mon, 10 Oct 2016 21:36:35 +0200 Subject: [pkg-gnupg-maint] Bug#839991: gnupg-agent: 'allow-emacs-pinentry' setting in agent conf makes gpg2 respond no secret key In-Reply-To: (Daiki Ueno's message of "Mon, 10 Oct 2016 10:39:13 +0200") References: <87shs84n5t.fsf@fsfe.org> <87a8ef2869.fsf@alice.fifthhorseman.net> <87ponb5icr.fsf@wheatstone.g10code.de> Message-ID: <874m4k3sjg.fsf@wheatstone.g10code.de> On Mon, 10 Oct 2016 10:39, ueno at gnu.org said: > That makes sense. How about this trivial patch? Fine. Justus, can you please apply it? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From justus at g10code.com Tue Oct 11 10:39:52 2016 From: justus at g10code.com (Justus Winter) Date: Tue, 11 Oct 2016 10:39:52 +0200 Subject: [pkg-gnupg-maint] Bug#839991: gnupg-agent: 'allow-emacs-pinentry' setting in agent conf makes gpg2 respond no secret key In-Reply-To: References: <87shs84n5t.fsf@fsfe.org> <87a8ef2869.fsf@alice.fifthhorseman.net> <87ponb5icr.fsf@wheatstone.g10code.de> Message-ID: <877f9fqnxj.fsf@europa.jade-hamburg.de> Daiki Ueno writes: > Werner Koch writes: > >> Alrthough we could handle this in gpg-agent, I consider it better to fix >> this in Pinentry. The name "allow-emacs-prompt" means to me that Emacs >> support is optional and thus Pinentry should just return OK. A new >> Pinentry version is anyway due. > > That makes sense. How about this trivial patch? Merged, thanks! Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From lists at ssl-mail.com Tue Oct 11 16:21:40 2016 From: lists at ssl-mail.com (lists at ssl-mail.com) Date: Tue, 11 Oct 2016 07:21:40 -0700 Subject: gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)" In-Reply-To: <1476105541.3317580.751181353.553BB041@webmail.messagingengine.com> References: <1476027783.1522252.750391089.07374952@webmail.messagingengine.com> <20161009223833.GA4309@tower.spodhuis.org> <1476053249.1594379.750625153.58F21EF5@webmail.messagingengine.com> <20161010131036.GC17876@glanzmann.de> <1476105541.3317580.751181353.553BB041@webmail.messagingengine.com> Message-ID: <1476195700.945573.752442825.4C7CDE8B@webmail.messagingengine.com> What specific additional diagnostic info from my end can help with a fix? From michael.blumenkrantz at gmail.com Tue Oct 11 17:19:38 2016 From: michael.blumenkrantz at gmail.com (Mike Blumenkrantz) Date: Tue, 11 Oct 2016 15:19:38 +0000 Subject: pinentry patch? Message-ID: Hi, I've written an EFL-based (https://www.enlightenment.org/) frontend for pinentry that I would like to contribute. I could not find any process for submitting patches; should I just attach it in a mail to this list or is there somewhere I should be posting it? Thanks, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From justus at g10code.com Tue Oct 11 19:07:37 2016 From: justus at g10code.com (Justus Winter) Date: Tue, 11 Oct 2016 19:07:37 +0200 Subject: pinentry patch? In-Reply-To: References: Message-ID: <874m4irezq.fsf@europa.jade-hamburg.de> Mike Blumenkrantz writes: > I've written an EFL-based (https://www.enlightenment.org/) frontend for > pinentry that I would like to contribute. Cool! > I could not find any process for submitting patches; should I just > attach it in a mail to this list or is there somewhere I should be > posting it? The preferred way is using git send-email to this list. Cheers, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From dkg at fifthhorseman.net Tue Oct 11 19:09:11 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 11 Oct 2016 13:09:11 -0400 Subject: pinentry patch? In-Reply-To: References: Message-ID: <87shs2zubs.fsf@alice.fifthhorseman.net> On Tue 2016-10-11 11:19:38 -0400, Mike Blumenkrantz wrote: > I've written an EFL-based (https://www.enlightenment.org/) frontend for > pinentry that I would like to contribute. I could not find any process for > submitting patches; should I just attach it in a mail to this list or is > there somewhere I should be posting it? I've submitted patches for pinentry to this list via e-mail ("git send-email", when configured and used correctly, works nicely for this) and, after some feedback and useful suggestions, had them merged upstream. Please try it out :) Thanks for writing a pinentry for EFL! --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From kristian.fiskerstrand at sumptuouscapital.com Tue Oct 11 21:57:18 2016 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 11 Oct 2016 21:57:18 +0200 Subject: pinentry patch? In-Reply-To: References: Message-ID: <361feda2-35bc-48cf-590d-1a13999c5226@sumptuouscapital.com> On 10/11/2016 05:19 PM, Mike Blumenkrantz wrote: > Hi, > > I've written an EFL-based (https://www.enlightenment.org/) frontend for > pinentry that I would like to contribute. I could not find any process > for submitting patches; should I just attach it in a mail to this list > or is there somewhere I should be posting it? > git format-patch / send-email as suggested by others, but keep in mind [doc/HACKING] when it comes to commit log requirements etc while doing so References: [doc/HACKING] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/HACKING -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "Don't be afraid to go out on a limb. That's where the fruit is." (H. Jackson Browne) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Tue Oct 11 22:36:45 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 11 Oct 2016 16:36:45 -0400 Subject: [pkg-gnupg-maint] Bug#839991: gnupg-agent: 'allow-emacs-pinentry' setting in agent conf makes gpg2 respond no secret key In-Reply-To: <87ponb5icr.fsf@wheatstone.g10code.de> References: <87shs84n5t.fsf@fsfe.org> <87a8ef2869.fsf@alice.fifthhorseman.net> <87ponb5icr.fsf@wheatstone.g10code.de> Message-ID: <87twciy65e.fsf@alice.fifthhorseman.net> Control: reassign 839991 pinentry Control: affects 839991 + gpg-agent Control: found 839991 0.9.7-5 Control: fixed 839991 0.9.7-6 On Sat 2016-10-08 04:56:52 -0400, Werner Koch wrote: > bail out on this error because the Pinentry told us that it knows about > the option. So it was a Pinentry choice to return that error. > >> No debian pinentries currently support emacs mode, fwiw. But whether >> they should or not is probably a different bug report than this one. > > The interesting part is in Pinentry: > > else if (!strcmp (key, "allow-emacs-prompt") && !*value) > { > #ifdef INSIDE_EMACS > pinentry_enable_emacs_cmd_handler (); > #else > return gpg_error (GPG_ERR_NOT_SUPPORTED); > #endif > } > > Thus pinentry always tells us that it is not supported unless it is a > Pinentry which was build with Emacs support. So a pinentry implementation is expected to say something other than "GPG_ERR_UNKNOWN_OPTION" when it sees an option it recognizes, but knows it will have no way of implementing. is that right? That seems to be the logic for allow-external-password-cache, fwiw. Is this sort of expectation documented somewhere? Would an implementer of a new pinentry (or someone trying to use pinentry directly) be expected to know this? > Alrthough we could handle this in gpg-agent, I consider it better to fix > this in Pinentry. The name "allow-emacs-prompt" means to me that Emacs > support is optional and thus Pinentry should just return OK. A new > Pinentry version is anyway due. I've applied Daiki Ueno's proposed patch to debian unstable in pinentry 0.9.7-6. hopefully it will resolve the issue here. Kevin, can you report back whether it resolves things for you? (there will still be no prompts in emacs, but at least access to the pinentry shouldn't automatically abort). I'm closing the issue now because i believe it's resolved in 0.9.7-6, but feel free to reopen if you think it is still wrong. ---- fwiw, i still don't really understand the logic behind gpg-agent's strictness around allow-external-passphrase-cache: /* Indicate to the pinentry that it may read from an external cache. It is essential that the pinentry respect this. If the cached password is not up to date and retry == 1, then, using a version of GPG Agent that doesn't support this, won't issue another pin request and the user won't get a chance to correct the password. */ Consider pinentry-tty, which is compiled *without* libsecret on debian, but can be co-installed with pinentry-gnome3 (which is compiled *with* libsecret on debian). Neither of these pinentry implementations will report GPG_ERR_UNKNOWN_OPTION, but only one of them will actually "respect" the flag in the sense of querying the secret service. Is this logic correct? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From dkg at fifthhorseman.net Wed Oct 12 02:49:32 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 11 Oct 2016 20:49:32 -0400 Subject: generic and flexible bindings for gpg without race conditions Message-ID: <87a8eaxug3.fsf@alice.fifthhorseman.net> hi all-- I'm trying to clean up the GnuPG::Interface perl bindings and i want to make it work independently of whether the user has the classic, stable, or modern suite installed. GnuPG::Interface has traditionally offered a mode for users to provide the password programmatically, and then passed the password to the gpg process. I will probably urge the GnuPG::Interface maintainer to discourage this use pattern in favor of delegating access decisions to the agent or a custom pinentry, but they will likely want to support this mode for some time into the future. With modern GnuPG, using this "send the password explicitly" mode requires --pinentry-mode=loopback, but neither classic nor stable supports this argument. As a result, i don't know how to decide what to send: either i supply --pinentry-mode=loopback (and fail on classic and stable because of "Invalid option") or i don't supply it (and the passphrase doesn't get seen by modern at all). I could test the version of gpg, at the not-insignificant expense of an additional subprocess ("gpg --version"), and a possible race condition (the subsequent call to gpg could hit a different installed gpg process than the one tested with --version if there was an upgrade in between invocations). One way to resolve this would be to add --pinentry-mode=loopback as a dummy no-op parameter to classic and modern. This doesn't help for old installations, of course, but if someone can upgrade within a given series, it would at least let the bindings work. Are there other solutions to this conundrum? The upgrade path here is tricky and kind of fraught :/ --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From dkg at fifthhorseman.net Wed Oct 12 06:20:52 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 12 Oct 2016 00:20:52 -0400 Subject: gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)" In-Reply-To: <1476195700.945573.752442825.4C7CDE8B@webmail.messagingengine.com> References: <1476027783.1522252.750391089.07374952@webmail.messagingengine.com> <20161009223833.GA4309@tower.spodhuis.org> <1476053249.1594379.750625153.58F21EF5@webmail.messagingengine.com> <20161010131036.GC17876@glanzmann.de> <1476105541.3317580.751181353.553BB041@webmail.messagingengine.com> <1476195700.945573.752442825.4C7CDE8B@webmail.messagingengine.com> Message-ID: <87twciw63f.fsf@alice.fifthhorseman.net> On Tue 2016-10-11 10:21:40 -0400, lists at ssl-mail.com wrote: > What specific additional diagnostic info from my end can help with a fix? can you try capturing a trace of all DNS packets (udp port 53) that come out of your machine during this query? For example, something like (untested, please use with caution): gpgconf --kill dirmngr sudo tcpdump -s 1024 -w dns-from-dirmngr.pcap 'udp port 53' & gpg --recv 0x0EE5BE979282D80B9F7540F1CCD2ED94D21739E9 kill %1 (or just do the "sudo tcpdump" from a separate shell with the appropriate privileges at the right time) You should be able to examine that .pcap file with wireshark or tshark to see what queries are going out at what times. If you're not sure how to make sense of it, you can send me the created .pcap file either privately (please encrypt to my OpenPGP key, fingerprint in the example above) or publicly (to this list if you're convinced there's nothing you need to hide in there and it's not insanely large). hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From lists at ssl-mail.com Wed Oct 12 15:28:05 2016 From: lists at ssl-mail.com (lists at ssl-mail.com) Date: Wed, 12 Oct 2016 06:28:05 -0700 Subject: gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)" In-Reply-To: <87twciw63f.fsf@alice.fifthhorseman.net> References: <1476027783.1522252.750391089.07374952@webmail.messagingengine.com> <20161009223833.GA4309@tower.spodhuis.org> <1476053249.1594379.750625153.58F21EF5@webmail.messagingengine.com> <20161010131036.GC17876@glanzmann.de> <1476105541.3317580.751181353.553BB041@webmail.messagingengine.com> <1476195700.945573.752442825.4C7CDE8B@webmail.messagingengine.com> <87twciw63f.fsf@alice.fifthhorseman.net> Message-ID: <1476278885.2082508.753599713.74736041@webmail.messagingengine.com> Hi On Tue, Oct 11, 2016, at 09:20 PM, Daniel Kahn Gillmor wrote: > On Tue 2016-10-11 10:21:40 -0400, lists at ssl-mail.com wrote: > > What specific additional diagnostic info from my end can help with a fix? > > can you try capturing a trace of all DNS packets (udp port 53) that come > out of your machine during this query? > > For example, something like (untested, please use with caution): > > gpgconf --kill dirmngr > sudo tcpdump -s 1024 -w dns-from-dirmngr.pcap 'udp port 53' & > gpg --recv 0x0EE5BE979282D80B9F7540F1CCD2ED94D21739E9 > kill %1 gpgconf --kill dirmngr sudo tcpdump -s 1024 -w dns-from-dirmngr.pcap 'udp port 53' & gpg --recv 0x0EE5BE979282D80B9F7540F1CCD2ED94D21739E9 kill %1 2 packets captured 2 packets received by filter 0 packets dropped by kernel Here's the 2 packets' export as text: ---------------------------------------- No. Time Source Destination Protocol Length Info 1 0.000000 10.19.2.7 10.19.2.100 DNS 98 Standard query 0x311f SRV _hkp._tcp.hkps.pool.sks-keyservers.net Frame 1: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) Ethernet II, Src: AsustekC_19:c3:26 (00:26:18:19:c3:26), Dst: Trendnet_c4:11:d9 (d8:eb:97:c4:11:d9) Internet Protocol Version 4, Src: 10.19.2.7, Dst: 10.19.2.100 User Datagram Protocol, Src Port: 51597, Dst Port: 53 Domain Name System (query) No. Time Source Destination Protocol Length Info 2 0.544341 10.19.2.100 10.19.2.7 DNS 148 Standard query response 0x311f No such name SRV _hkp._tcp.hkps.pool.sks-keyservers.net SOA ns2.kfwebs.net Frame 2: 148 bytes on wire (1184 bits), 148 bytes captured (1184 bits) Ethernet II, Src: Trendnet_c4:11:d9 (d8:eb:97:c4:11:d9), Dst: AsustekC_19:c3:26 (00:26:18:19:c3:26) Internet Protocol Version 4, Src: 10.19.2.100, Dst: 10.19.2.7 User Datagram Protocol, Src Port: 53, Dst Port: 51597 Domain Name System (response) ---------------------------------------- From dkg at fifthhorseman.net Wed Oct 12 15:56:29 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 12 Oct 2016 09:56:29 -0400 Subject: [GPGME PATCH] install cmake files without executable bit set Message-ID: <20161012135629.30886-1-dkg@fifthhorseman.net> * lang/cpp/src/Makefile.am, lang/qt/src/Makefile.am: set permissions on installed cmake files to 644. --- cmake is exciting but it's not *that* exciting, and besides lintian complains: W: libgpgme-dev: executable-not-elf-or-script usr/lib/x86_64-linux-gnu/cmake/Gpgmepp/QGpgmeConfig.cmake none of the other cmake files on a debian system appear to be intalled with executable provisiona either. Signed-off-by: Daniel Kahn Gillmor --- lang/cpp/src/Makefile.am | 4 ++-- lang/qt/src/Makefile.am | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/lang/cpp/src/Makefile.am b/lang/cpp/src/Makefile.am index 0500dbf..342bdf8 100644 --- a/lang/cpp/src/Makefile.am +++ b/lang/cpp/src/Makefile.am @@ -82,9 +82,9 @@ GpgmeppConfig.cmake: GpgmeppConfig.cmake.in install-cmake-files: GpgmeppConfig.cmake GpgmeppConfigVersion.cmake -$(INSTALL) -d $(DESTDIR)$(libdir)/cmake/Gpgmepp - $(INSTALL) GpgmeppConfig.cmake \ + $(INSTALL) -m 644 GpgmeppConfig.cmake \ $(DESTDIR)$(libdir)/cmake/Gpgmepp/GpgmeppConfig.cmake - $(INSTALL) GpgmeppConfigVersion.cmake \ + $(INSTALL) -m 644 GpgmeppConfigVersion.cmake \ $(DESTDIR)$(libdir)/cmake/Gpgmepp/GpgmeppConfigVersion.cmake uninstall-cmake-files: diff --git a/lang/qt/src/Makefile.am b/lang/qt/src/Makefile.am index e09e0d9..dde8e83 100644 --- a/lang/qt/src/Makefile.am +++ b/lang/qt/src/Makefile.am @@ -233,9 +233,9 @@ $(camelcase_headers): Makefile.am install-cmake-files: QGpgmeConfig.cmake QGpgmeConfigVersion.cmake -$(INSTALL) -d $(DESTDIR)$(libdir)/cmake/Gpgmepp - $(INSTALL) QGpgmeConfig.cmake \ + $(INSTALL) -m 644 QGpgmeConfig.cmake \ $(DESTDIR)$(libdir)/cmake/Gpgmepp/QGpgmeConfig.cmake - $(INSTALL) QGpgmeConfigVersion.cmake \ + $(INSTALL) -m 644 QGpgmeConfigVersion.cmake \ $(DESTDIR)$(libdir)/cmake/Gpgmepp/QGpgmeConfigVersion.cmake uninstall-cmake-files: -- 2.9.3 From dkg at fifthhorseman.net Wed Oct 12 16:33:30 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 12 Oct 2016 10:33:30 -0400 Subject: gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)" In-Reply-To: <1476278885.2082508.753599713.74736041@webmail.messagingengine.com> References: <1476027783.1522252.750391089.07374952@webmail.messagingengine.com> <20161009223833.GA4309@tower.spodhuis.org> <1476053249.1594379.750625153.58F21EF5@webmail.messagingengine.com> <20161010131036.GC17876@glanzmann.de> <1476105541.3317580.751181353.553BB041@webmail.messagingengine.com> <1476195700.945573.752442825.4C7CDE8B@webmail.messagingengine.com> <87twciw63f.fsf@alice.fifthhorseman.net> <1476278885.2082508.753599713.74736041@webmail.messagingengine.com> Message-ID: <87pon5vdqd.fsf@alice.fifthhorseman.net> Hi lists-- tanks for the packet grab! On Wed 2016-10-12 09:28:05 -0400, lists at ssl-mail.com wrote: > gpgconf --kill dirmngr > sudo tcpdump -s 1024 -w dns-from-dirmngr.pcap 'udp port 53' & > gpg --recv 0x0EE5BE979282D80B9F7540F1CCD2ED94D21739E9 > kill %1 > > 2 packets captured > 2 packets received by filter > 0 packets dropped by kernel > > Here's the 2 packets' export as text: > ---------------------------------------- > No. Time Source Destination Protocol Length Info > 1 0.000000 10.19.2.7 10.19.2.100 DNS 98 Standard query 0x311f SRV _hkp._tcp.hkps.pool.sks-keyservers.net > > Frame 1: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) > Ethernet II, Src: AsustekC_19:c3:26 (00:26:18:19:c3:26), Dst: Trendnet_c4:11:d9 (d8:eb:97:c4:11:d9) > Internet Protocol Version 4, Src: 10.19.2.7, Dst: 10.19.2.100 > User Datagram Protocol, Src Port: 51597, Dst Port: 53 > Domain Name System (query) > > No. Time Source Destination Protocol Length Info > 2 0.544341 10.19.2.100 10.19.2.7 DNS 148 Standard query response 0x311f No such name SRV _hkp._tcp.hkps.pool.sks-keyservers.net SOA ns2.kfwebs.net > > Frame 2: 148 bytes on wire (1184 bits), 148 bytes captured (1184 bits) > Ethernet II, Src: Trendnet_c4:11:d9 (d8:eb:97:c4:11:d9), Dst: AsustekC_19:c3:26 (00:26:18:19:c3:26) > Internet Protocol Version 4, Src: 10.19.2.100, Dst: 10.19.2.7 > User Datagram Protocol, Src Port: 53, Dst Port: 51597 > Domain Name System (response) > ---------------------------------------- so it looks like you're doing an SRV lookup for the server in question. do you see anything other than an NXDOMAIN when you query for this same SRV from the command line? fwiw, i'm seeing NXDOMAIN for this as well from my network perspective: >> ; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> -t srv _hkp._tcp.hkps.pool.sks-keyservers.net >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 48410 >> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 4096 >> ;; QUESTION SECTION: >> ;_hkp._tcp.hkps.pool.sks-keyservers.net. IN SRV >> >> ;; AUTHORITY SECTION: >> sks-keyservers.net. 60 IN SOA ns2.kfwebs.net. kf.kfwebs.net. 3161012162 600 14400 172800 60 >> >> ;; Query time: 368 msec >> ;; SERVER: 192.168.XXX.YYY#53(192.168.XXX.YYY) >> ;; WHEN: Wed Oct 12 10:31:08 EDT 2016 >> ;; MSG SIZE rcvd: 117 Kristian, are you expecting the SRV records to be published at this point in the DNS? I wonder why my dirmngr (also 2.1.15 using stock adns) requests A and AAAA records intstead of srv records :/ ? Werner, what are you expecting to happen here? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From lists at ssl-mail.com Wed Oct 12 16:44:35 2016 From: lists at ssl-mail.com (lists at ssl-mail.com) Date: Wed, 12 Oct 2016 07:44:35 -0700 Subject: gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)" In-Reply-To: <87pon5vdqd.fsf@alice.fifthhorseman.net> References: <1476027783.1522252.750391089.07374952@webmail.messagingengine.com> <20161009223833.GA4309@tower.spodhuis.org> <1476053249.1594379.750625153.58F21EF5@webmail.messagingengine.com> <20161010131036.GC17876@glanzmann.de> <1476105541.3317580.751181353.553BB041@webmail.messagingengine.com> <1476195700.945573.752442825.4C7CDE8B@webmail.messagingengine.com> <87twciw63f.fsf@alice.fifthhorseman.net> <1476278885.2082508.753599713.74736041@webmail.messagingengine.com> <87pon5vdqd.fsf@alice.fifthhorseman.net> Message-ID: <1476283475.2098459.753678793.0845AFC4@webmail.messagingengine.com> On Wed, Oct 12, 2016, at 07:33 AM, Daniel Kahn Gillmor wrote: > so it looks like you're doing an SRV lookup for the server in question. > do you see anything other than an NXDOMAIN when you query for this same > SRV from the command line? > > fwiw, i'm seeing NXDOMAIN for this as well from my network perspective: hm, same here ... dig any hkps.pool.sks-keyservers.net ; <<>> DiG 9.10.3-P4 <<>> any hkps.pool.sks-keyservers.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43782 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;hkps.pool.sks-keyservers.net. IN ANY ;; ANSWER SECTION: hkps.pool.sks-keyservers.net. 20 IN RRSIG NSEC 8 4 60 20161103103842 20161004093842 30729 sks-keyservers.net. m8Fm/GnAxhmuwswHgzMatQngOovhj/VCJlyFqRkLNy6WR8q/OFOk6kQp reDFdWNoRzmLvSjmMnPedelIAgOXVy1bxMzLnpW9+KWjcQRyKuzWHcnL kjOSpJ1mTiwEWnU9e+oC3VeHUp8SnVpY+as7voUK6XIyg+UOs/O1fZzD 2oMLLALj/GThbPgClBwirL+MHtXoQ2efVbT+KlEf8xOEz5a8MwfaNACj F/2PQxEki+c+hdeBByweBeW94bo8zKrmrAArLuro02OIOkPUGGlzfrny sDkToLJmEVvcgZHvpHHVYbjmPZZRaiSiJQEyLV/W7JJYAbwdMU675ZmD njHm8w== hkps.pool.sks-keyservers.net. 20 IN NSEC ipv4.pool.sks-keyservers.net. A AAAA RRSIG NSEC ;; Query time: 0 msec ;; SERVER: 10.19.2.100#53(10.19.2.100) ;; WHEN: Wed Oct 12 07:37:13 PDT 2016 ;; MSG SIZE rcvd: 413 dig any _hkp_tcp.hkps.pool.sks-keyservers.net ; <<>> DiG 9.10.3-P4 <<>> any _hkp_tcp.hkps.pool.sks-keyservers.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 18104 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;_hkp_tcp.hkps.pool.sks-keyservers.net. IN ANY ;; AUTHORITY SECTION: sks-keyservers.net. 10 IN SOA ns2.kfwebs.net. kf.kfwebs.net. 3161012162 600 14400 172800 60 ;; Query time: 0 msec ;; SERVER: 10.19.2.100#53(10.19.2.100) ;; WHEN: Wed Oct 12 07:37:23 PDT 2016 ;; MSG SIZE rcvd: 116 dig SRV _hkp_tcp.hkps.pool.sks-keyservers.net ; <<>> DiG 9.10.3-P4 <<>> SRV _hkp_tcp.hkps.pool.sks-keyservers.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 39844 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;_hkp_tcp.hkps.pool.sks-keyservers.net. IN SRV ;; AUTHORITY SECTION: sks-keyservers.net. 1 IN SOA ns2.kfwebs.net. kf.kfwebs.net. 3161012162 600 14400 172800 60 ;; Query time: 0 msec ;; SERVER: 10.19.2.100#53(10.19.2.100) ;; WHEN: Wed Oct 12 07:37:32 PDT 2016 ;; MSG SIZE rcvd: 116 From michael.blumenkrantz at gmail.com Wed Oct 12 17:01:47 2016 From: michael.blumenkrantz at gmail.com (Mike Blumenkrantz) Date: Wed, 12 Oct 2016 15:01:47 +0000 Subject: pinentry patch? In-Reply-To: <361feda2-35bc-48cf-590d-1a13999c5226@sumptuouscapital.com> References: <361feda2-35bc-48cf-590d-1a13999c5226@sumptuouscapital.com> Message-ID: Okay, I will send my patch to the list for further comments and review. Thanks all for your quick responses! On Tue, Oct 11, 2016 at 3:57 PM Kristian Fiskerstrand < kristian.fiskerstrand at sumptuouscapital.com> wrote: > On 10/11/2016 05:19 PM, Mike Blumenkrantz wrote: > > Hi, > > > > I've written an EFL-based (https://www.enlightenment.org/) frontend for > > pinentry that I would like to contribute. I could not find any process > > for submitting patches; should I just attach it in a mail to this list > > or is there somewhere I should be posting it? > > > > git format-patch / send-email as suggested by others, but keep in mind > [doc/HACKING] when it comes to commit log requirements etc while doing so > > References: > [doc/HACKING] > https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/HACKING > > -- > ---------------------------- > Kristian Fiskerstrand > Blog: https://blog.sumptuouscapital.com > Twitter: @krifisk > ---------------------------- > Public OpenPGP keyblock at hkp://pool.sks-keyservers.net > fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 > ---------------------------- > "Don't be afraid to go out on a limb. That's where the fruit is." > (H. Jackson Browne) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zmike at samsung.com Wed Oct 12 17:35:15 2016 From: zmike at samsung.com (Mike Blumenkrantz) Date: Wed, 12 Oct 2016 11:35:15 -0400 Subject: [PINENTRY PATCH] add efl-based frontend References: Message-ID: <20161012113515.675d5a30@Sir.Pimpleton> Hi, Attached is a patch implementing an efl-based gui frontend for pinentry. As a note, the formatting in pinentry-efl.c was done by using the 'indent' tool; I am not familiar enough with this coding style to manually make corrections if further changes are needed in this regard. Thanks for your time and review, Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-add-efl-based-frontend-for-pinentry.patch Type: text/x-patch Size: 25563 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From zmike at samsung.com Wed Oct 12 17:01:17 2016 From: zmike at samsung.com (Mike Blumenkrantz) Date: Wed, 12 Oct 2016 11:01:17 -0400 Subject: DCO signoff References: Message-ID: <20161012110117.37575d1a@Sir.Pimpleton> GnuPG Developer's Certificate of Origin. Version 1.0 ===================================================== By making a contribution to the GnuPG project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the free software license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate free software license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same free software license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the free software license(s) involved. Signed-off-by: Mike Blumenkrantz -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Thu Oct 13 00:07:07 2016 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Thu, 13 Oct 2016 00:07:07 +0200 Subject: gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)" In-Reply-To: <87pon5vdqd.fsf@alice.fifthhorseman.net> References: <1476027783.1522252.750391089.07374952@webmail.messagingengine.com> <20161009223833.GA4309@tower.spodhuis.org> <1476053249.1594379.750625153.58F21EF5@webmail.messagingengine.com> <20161010131036.GC17876@glanzmann.de> <1476105541.3317580.751181353.553BB041@webmail.messagingengine.com> <1476195700.945573.752442825.4C7CDE8B@webmail.messagingengine.com> <87twciw63f.fsf@alice.fifthhorseman.net> <1476278885.2082508.753599713.74736041@webmail.messagingengine.com> <87pon5vdqd.fsf@alice.fifthhorseman.net> Message-ID: <0F63C671-4066-4CF4-813A-66BC544D16FF@sumptuouscapital.com> [Sent from my iPad, as it is not a secured device there are no cryptographic keys on this device, meaning this message is sent without an OpenPGP signature. In general you should *not* rely on any information sent over such an unsecure channel, if you find any information controversial or un-expected send a response and request a signed confirmation] > > > Kristian, are you expecting the SRV records to be published at this > point in the DNS? > Well, seems SRV records are causing more issues than they are useful. They only ever make sense for the geographical sub-pools in order to distributed the traffic using weights there, for the rest of the pools they are a noop since allowing specific ports etc is a bad idea overall. This is further complicated by gnupg 2.1 using _hkp , whereby the consensus in previous implementation has been _pgpkey-http._tcp. So where SRV is implementere it is using the original identifier. Not having SRV should certainly not result in failure of operation when A and AAAA records are returned though.. From jrollins at finestructure.net Thu Oct 13 02:52:11 2016 From: jrollins at finestructure.net (Jameson Graef Rollins) Date: Wed, 12 Oct 2016 17:52:11 -0700 Subject: begging for pyme name change Message-ID: <87insx8404.fsf@servo.finestructure.net> Hi, folks. Don't know where else to bring this up so trying here. I am very, very happy that gnupg upstream is now shipping well-supported python bindings. However, I find that the choice of name for these new bindings to be incredibly unfortunate. Is there any way the name "pyme" could be changed to something more sensible? That name is so unfortunate for so many reasons. The name has zero reference to it's functionality, i.e. gpg bindings. Worse, the use of the long-discouraged "py" prefix makes it seem as if it's a python version of the "me" library, whatever that is. Is the name supposed to mean "python made easy"? Why couldn't the name just be "python-gpg", so that users just "import gpg"? I feel like naming the bindings "fred" would be less confusing. I realize upstream releases have already happened, but I beg of you to please consider changing the name, for the benefit of all of our future selves. Thank you for your consideration, and thank you very much for the crucial gnupg suite of tools. jamie. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From ineiev at gnu.org Thu Oct 13 09:27:31 2016 From: ineiev at gnu.org (Ineiev) Date: Thu, 13 Oct 2016 03:27:31 -0400 Subject: [PATCH HEAD] a typo in a message In-Reply-To: <87y420a5ga.fsf@wheatstone.g10code.de> References: <20161005143617.GP30569@gnu.org> <87zimig2g8.fsf@wheatstone.g10code.de> <20161006064340.GR30569@gnu.org> <877f9le3nj.fsf@wheatstone.g10code.de> <20161007060642.GA30569@gnu.org> <20161007062552.GB30569@gnu.org> <87y420a5ga.fsf@wheatstone.g10code.de> Message-ID: <20161013072731.GW30569@gnu.org> On Fri, Oct 07, 2016 at 11:12:05AM +0200, Werner Koch wrote: > On Fri, 7 Oct 2016 08:25, ineiev at gnu.org said: > > >> Like this? > > Yes, but this duplicates a check we will do later anyway. We need to > think this through. I'm afraid so far it looks like a war of edits, b0d2526bc 1a24c67e2 ca84f65c7. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From ineiev at gnu.org Thu Oct 13 09:24:31 2016 From: ineiev at gnu.org (Ineiev) Date: Thu, 13 Oct 2016 03:24:31 -0400 Subject: [PATCH HEAD] i18n fixes In-Reply-To: <87twcoa55e.fsf@wheatstone.g10code.de> References: <20161005142930.GO30569@gnu.org> <20161005152417.GQ30569@gnu.org> <87r37ug0ih.fsf@wheatstone.g10code.de> <20161007064446.GC30569@gnu.org> <87twcoa55e.fsf@wheatstone.g10code.de> Message-ID: <20161013072429.GV30569@gnu.org> On Fri, Oct 07, 2016 at 11:18:37AM +0200, Werner Koch wrote: > On Fri, 7 Oct 2016 08:44, ineiev at gnu.org said: > > > I wonder if pgettext is really non-portable. > > The gettext checks try to make use of other gettext implemntations. > pgettext is not available on non GNU systems and anyway pretty new. pgettext is added in gettext-0.15; configure.ac says, AM_GNU_GETTEXT_VERSION([0.17]), whatever it means. however, pgettext isn't a function, it's a macro implemented using dcgettext (yes, the application is to distribute that macro with its sources), and dcgettext was already present in the first official release of GNU gettext (1995). so pgettext is not effectively new. > > Indeed, the number of fragments can be dramatically reduced in this > > message, with more context provided. the drawback is that the total > > volume of msgids increases because the new strings share more parts. > > Let me quote from the gettext manual: > > Translatable strings should be entire sentences. It is often not > possible to translate single verbs or adjectives in a substitutable way. > > [...] > > Entire sentences are also important because in many languages, the > declination of some word in a sentence depends on the gender or the > number (singular/plural) of another part of the sentence. There are > usually more interdependencies between words than in English. The > consequence is that asking a translator to translate two half-sentences > and then combining these two half-sentences through dumb string > concatenation will not work, for many languages, even though it would > work for English. That?s why translators need to handle entire > sentences. Thank you! Applied to time_ago_str: does that mean that it should return (0) complete sentences like "Days of observed period: %i.\n" "Months of observed period: %i.\n" "Years of observed period: %i.\n" (1) a single sentence with reduced precision like "Observed period is %i~months.\n" (2) something else? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From aheinecke at intevation.de Thu Oct 13 10:45:05 2016 From: aheinecke at intevation.de (Andre Heinecke) Date: Thu, 13 Oct 2016 10:45:05 +0200 Subject: [GPGME PATCH] install cmake files without executable bit set In-Reply-To: <20161012135629.30886-1-dkg@fifthhorseman.net> References: <20161012135629.30886-1-dkg@fifthhorseman.net> Message-ID: <2167876.xTvn2rKpQm@esus> Hi, On Wednesday 12 October 2016 09:56:29 Daniel Kahn Gillmor wrote: > * lang/cpp/src/Makefile.am, lang/qt/src/Makefile.am: set permissions > on installed cmake files to 644. Sorry, I've commited the same fix today before reading gnupg-devel so it's not your patch but the change is the same. ( a274c7590aa0e38d682d5177904983632f471cb0 ) 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: 630 bytes Desc: This is a digitally signed message part. URL: From justus at g10code.com Thu Oct 13 11:19:58 2016 From: justus at g10code.com (Justus Winter) Date: Thu, 13 Oct 2016 11:19:58 +0200 Subject: begging for pyme name change In-Reply-To: <87insx8404.fsf@servo.finestructure.net> References: <87insx8404.fsf@servo.finestructure.net> Message-ID: <87bmyoy5a9.fsf@europa.jade-hamburg.de> Hello :) Jameson Graef Rollins writes: > Hi, folks. Don't know where else to bring this up so trying here. > > I am very, very happy that gnupg upstream is now shipping well-supported > python bindings. However, I find that the choice of name for these new > bindings to be incredibly unfortunate. Is there any way the name "pyme" > could be changed to something more sensible? That name is so > unfortunate for so many reasons. > > The name has zero reference to it's functionality, i.e. gpg bindings. > Worse, the use of the long-discouraged "py" prefix makes it seem as if > it's a python version of the "me" library, whatever that is. Is the > name supposed to mean "python made easy"? Why couldn't the name just be > "python-gpg", so that users just "import gpg"? I feel like naming the > bindings "fred" would be less confusing. I understand and I'm with you. However, there are so many GPGME bindings/GnuPG wrappers for Python out there, that many names are already taken. As to your suggestion, a cursory search on PyPI revealed that there is already pygpg, py-pgp, and python-gnupg. There is also pygpgme and GPG.py. We considered renaming our pyme, but we did not want to add to the already confusing large pile of names. At least pyme sticks out. However, if you can come up with a good name that doesn't sound too similar to some existing name, feel free to offer suggestions. Cheers, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From neal at walfield.org Thu Oct 13 11:25:13 2016 From: neal at walfield.org (Neal H. Walfield) Date: Thu, 13 Oct 2016 11:25:13 +0200 Subject: begging for pyme name change In-Reply-To: <87bmyoy5a9.fsf@europa.jade-hamburg.de> References: <87insx8404.fsf@servo.finestructure.net> <87bmyoy5a9.fsf@europa.jade-hamburg.de> Message-ID: <877f9csirq.wl-neal@walfield.org> On Thu, 13 Oct 2016 11:19:58 +0200, Justus Winter wrote: > Jameson Graef Rollins writes: > > > Hi, folks. Don't know where else to bring this up so trying here. > > > > I am very, very happy that gnupg upstream is now shipping well-supported > > python bindings. However, I find that the choice of name for these new > > bindings to be incredibly unfortunate. Is there any way the name "pyme" > > could be changed to something more sensible? That name is so > > unfortunate for so many reasons. > > > > The name has zero reference to it's functionality, i.e. gpg bindings. > > Worse, the use of the long-discouraged "py" prefix makes it seem as if > > it's a python version of the "me" library, whatever that is. Is the > > name supposed to mean "python made easy"? Why couldn't the name just be > > "python-gpg", so that users just "import gpg"? I feel like naming the > > bindings "fred" would be less confusing. > > I understand and I'm with you. However, there are so many GPGME > bindings/GnuPG wrappers for Python out there, that many names are > already taken. As to your suggestion, a cursory search on PyPI revealed > that there is already pygpg, py-pgp, and python-gnupg. There is also > pygpgme and GPG.py. > > We considered renaming our pyme, but we did not want to add to the > already confusing large pile of names. At least pyme sticks out. > > However, if you can come up with a good name that doesn't sound too > similar to some existing name, feel free to offer suggestions. It seems to me that there is a more fundamental issue: pyme is not a new package, so changing the name will mean updating all users of the package. Or, am I not understanding something? :) Neal From aheinecke at intevation.de Thu Oct 13 11:45:24 2016 From: aheinecke at intevation.de (Andre Heinecke) Date: Thu, 13 Oct 2016 11:45:24 +0200 Subject: begging for pyme name change In-Reply-To: <87bmyoy5a9.fsf@europa.jade-hamburg.de> References: <87insx8404.fsf@servo.finestructure.net> <87bmyoy5a9.fsf@europa.jade-hamburg.de> Message-ID: <2762679.6kZ91rvNpv@esus> Hi, On Thursday 13 October 2016 11:19:58 Justus Winter wrote: > We considered renaming our pyme, but we did not want to add to the > already confusing large pile of names. At least pyme sticks out. > > However, if you can come up with a good name that doesn't sound too > similar to some existing name, feel free to offer suggestions. We have this same problem a bit with QGpgME and GpgMEpp. Imo ideally we would follow just the scheme gpgme- for the bindings in gpgme to avoid confusion. And so that we don't have to find fancy names in the future for new languages. So that we have a gpgme, gpgme-python, gpgme-cpp, gpgme-qt, gpgme-cl etc. (Maybe gpgme-ruby, gpgme-perl etc. in the future) 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: 630 bytes Desc: This is a digitally signed message part. URL: From justus at g10code.com Thu Oct 13 14:27:21 2016 From: justus at g10code.com (Justus Winter) Date: Thu, 13 Oct 2016 14:27:21 +0200 Subject: [PINENTRY PATCH] add efl-based frontend In-Reply-To: <20161012113515.675d5a30@Sir.Pimpleton> References: <20161012113515.675d5a30@Sir.Pimpleton> Message-ID: <87y41swi1i.fsf@europa.jade-hamburg.de> Hi Mike :) Mike Blumenkrantz writes: > Attached is a patch implementing an efl-based gui frontend for pinentry. Cool! > As a note, the formatting in pinentry-efl.c was done by using the > 'indent' tool; I am not familiar enough with this coding style to > manually make corrections if further changes are needed in this > regard. The formatting of the code looks nice, thanks. The formatting of the commit message, however, does not. Details can be found in the already mentioned doc/HACKING file. At the very least, try to make it blend in with the other commit messages ;) > Thanks for your time and review, I tried to compile it, but failed to do so because it depends on a very recent libelementary which is only available from Debian experimental, and I failed to pull that in for some reason. In any case, that means that your pinentry won't be usable for the majority until the required version reaches end users. You might want to try to relax this a little (though ofc I don't know anything about libelementary, so...). But I noticed that despite me using ../configure --enable-pinentry-efl, the failed version check was not fatal. I'd say it should abort if the user explicitly asked for it but the requirements were not met. Cheers, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From dkg at fifthhorseman.net Wed Oct 12 23:58:05 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 12 Oct 2016 17:58:05 -0400 Subject: gpgme 1.7.0 "make" does not make lang/qt/doc/generated/latex/refman.pdf Message-ID: <8760oxut5e.fsf@alice.fifthhorseman.net> using gpgme 1.7.0, after a "make", i can coax a nice-looking PDF reference manual for libqgpgme by doing: (cd lang/qt/doc/generated/latex && make) This creates refman.pdf in the mentioned directory. I would have expected this pdf to be built automatically, at the same time as the rest of the stuff in that directory. Is there a reason it's not done automatically? I'm afraid i'm not enough of a doxygen wizard to know the right incantations in Makefile.am or Doxyfile to ensure that it gets built during a standard run, but it would be nice if it were! --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From michael.blumenkrantz at gmail.com Thu Oct 13 16:09:38 2016 From: michael.blumenkrantz at gmail.com (Mike Blumenkrantz) Date: Thu, 13 Oct 2016 14:09:38 +0000 Subject: [PINENTRY PATCH] add efl-based frontend In-Reply-To: <87y41swi1i.fsf@europa.jade-hamburg.de> References: <20161012113515.675d5a30@Sir.Pimpleton> <87y41swi1i.fsf@europa.jade-hamburg.de> Message-ID: Hey, thanks for the quick feedback! On Thu, Oct 13, 2016 at 8:28 AM Justus Winter wrote: > Hi Mike :) > > > > Mike Blumenkrantz writes: > > > Attached is a patch implementing an efl-based gui frontend for pinentry. > > > > Cool! > > > > > As a note, the formatting in pinentry-efl.c was done by using the > > > 'indent' tool; I am not familiar enough with this coding style to > > > manually make corrections if further changes are needed in this > > > regard. > > > > The formatting of the code looks nice, thanks. > > > > The formatting of the commit message, however, does not. Details can > > be found in the already mentioned doc/HACKING file. At the very least, > > try to make it blend in with the other commit messages ;) > Can you elaborate on exactly which parts need changes? I tried to follow the policy in that file, but there did not seem to be much which could apply to adding new frontends like this. > > > > > Thanks for your time and review, > > > > I tried to compile it, but failed to do so because it depends on a very > > recent libelementary which is only available from Debian experimental, > > and I failed to pull that in for some reason. > > > > In any case, that means that your pinentry won't be usable for the > > majority until the required version reaches end users. You might want > > to try to relax this a little (though ofc I don't know anything about > > libelementary, so...). > Regrettably, reducing the version requirements is not possible in order for the frontend to have readable text. I'm fine with it not being usable for some number of users at this time. > > > > But I noticed that despite me using ../configure --enable-pinentry-efl, > > the failed version check was not fatal. I'd say it should abort if the > > user explicitly asked for it but the requirements were not met. > Ah, I'll fix this, thanks. > > > > > > Cheers, > > Justus > > _______________________________________________ > > 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 jrollins at finestructure.net Thu Oct 13 19:20:36 2016 From: jrollins at finestructure.net (Jameson Graef Rollins) Date: Thu, 13 Oct 2016 10:20:36 -0700 Subject: begging for pyme name change In-Reply-To: <87bmyoy5a9.fsf@europa.jade-hamburg.de> References: <87insx8404.fsf@servo.finestructure.net> <87bmyoy5a9.fsf@europa.jade-hamburg.de> Message-ID: <877f9c88t7.fsf@servo.finestructure.net> On Thu, Oct 13 2016, Justus Winter wrote: > I understand and I'm with you. However, there are so many GPGME > bindings/GnuPG wrappers for Python out there, that many names are > already taken. As to your suggestion, a cursory search on PyPI revealed > that there is already pygpg, py-pgp, and python-gnupg. There is also > pygpgme and GPG.py. Rather than look at what's on pypi, I would look at what's currently being distributed by the major distros. python-gpg is not currently taken. > We considered renaming our pyme, but we did not want to add to the > already confusing large pile of names. At least pyme sticks out. Seems like it is just adding to the current confusing pile, though. And it only sticks out because of how little it relates to upstream names! > However, if you can come up with a good name that doesn't sound too > similar to some existing name, feel free to offer suggestions. These are all legitimate suggestions: python-gpg ('import gpg') python-openpgp ('import openpgp') python-rfc4880 ('import rfc4880) python-privacy ('import privacy') python-monkey ('import monkey') python-gpg is clearly the best of those options. But obviously what would really be best is 'python-gpgme'. Has there been any serious effort to reach out to the current holders of the python-gpgme namespace to see if they would be willing to hand over their project to gnupg upstream? That would really be globally best for everyone, since they wouldn't have to maintain their bindings anymore, their interface is almost identical, and it would reduce the current clutter of implementations. jamie. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From dkg at fifthhorseman.net Fri Oct 14 00:08:07 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 13 Oct 2016 18:08:07 -0400 Subject: begging for pyme name change In-Reply-To: <877f9c88t7.fsf@servo.finestructure.net> References: <87insx8404.fsf@servo.finestructure.net> <87bmyoy5a9.fsf@europa.jade-hamburg.de> <877f9c88t7.fsf@servo.finestructure.net> Message-ID: <87k2dbucl4.fsf@alice.fifthhorseman.net> [ james: if you haven't been reading this already, this is the continuation of a thread started here: https://lists.gnupg.org/pipermail/gnupg-devel/2016-October/031810.html ] On Thu 2016-10-13 13:20:36 -0400, Jameson Graef Rollins wrote: > But obviously what would really be best is 'python-gpgme'. Has there > been any serious effort to reach out to the current holders of the > python-gpgme namespace to see if they would be willing to hand over > their project to gnupg upstream? That would really be globally best for > everyone, since they wouldn't have to maintain their bindings anymore, > their interface is almost identical, and it would reduce the current > clutter of implementations. fwiw, i agree that the best name is "python-gpgme", and, having recently ported a smallish project from python-gpgme to the new upstream-supported bindings, the interfaces are definitely similar (though maybe not "almost identical"). I'm cc'ing the upstream maintainer of https://launchpad.net/pygpgme (James Henstridge) so that he knows this discussion is taking place and can maybe weigh in here. afaict there hasn't been a new release of python-gpgme since 2012. Maybe he'll be relieved at the thought that someone else wants to pick it up :) FWIW, the work for pyme to take over the namespace from python-gpgme (should James be ok with that) isn't just about changing the name -- it would also be about supporting the interfaces that python-gpgme has already established so that its users could use the new version as a drop-in replacement. The easiest way to start that work would be to try to run the python-gpgme test suite (https://bazaar.launchpad.net/~jamesh/pygpgme/trunk/files/head:/tests/) against the current pyme and see what breaks. This sort of "interface merge" might not be possible, of course -- the two projects might already declare identical interfaces with different semantics. In that case (or in the case where James doesn't want to relinquish responsibility for the python-gpgme module, or if everyone thinks this is just too much effort), the next-best option might be to just call it "python-gpgme2"; the incremented name acknowledges that there is is an interface change, and when people ask "why the 2 in gpgme2?" we can point back to the older project and say "we didn't want to deal with a collision". (i note that the current use of "pyme3" does something similar, though with an arguably worse name) wdyt? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From dkg at fifthhorseman.net Fri Oct 14 08:23:37 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 14 Oct 2016 02:23:37 -0400 Subject: [PATCH] point gpg-agent(1) at the right gpg manpage in SEE ALSO Message-ID: <20161014062337.25937-1-dkg@fifthhorseman.net> * doc/gpg-agent.texi (SEE ALSO): refer to @gpgname, instead of hard-coding "gpg2". Signed-off-by: Daniel Kahn Gillmor --- doc/gpg-agent.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/gpg-agent.texi b/doc/gpg-agent.texi index cc10a79..7c41027 100644 --- a/doc/gpg-agent.texi +++ b/doc/gpg-agent.texi @@ -1516,7 +1516,7 @@ much slower or faster than the actual box. @mansect see also @ifset isman - at command{gpg2}(1), + at command{@gpgname}(1), @command{gpgsm}(1), @command{gpg-connect-agent}(1), @command{scdaemon}(1) -- 2.9.3 From dkg at fifthhorseman.net Fri Oct 14 08:23:33 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 14 Oct 2016 02:23:33 -0400 Subject: [PATCH] point gpg-agent(1) at the right gpg manpage in SEE ALSO Message-ID: <20161014062333.25886-1-dkg@fifthhorseman.net> * doc/gpg-agent.texi (SEE ALSO): refer to @gpgname, instead of hard-coding "gpg2". Signed-off-by: Daniel Kahn Gillmor --- doc/gpg-agent.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/gpg-agent.texi b/doc/gpg-agent.texi index cc10a79..7c41027 100644 --- a/doc/gpg-agent.texi +++ b/doc/gpg-agent.texi @@ -1516,7 +1516,7 @@ much slower or faster than the actual box. @mansect see also @ifset isman - at command{gpg2}(1), + at command{@gpgname}(1), @command{gpgsm}(1), @command{gpg-connect-agent}(1), @command{scdaemon}(1) -- 2.9.3 From aheinecke at intevation.de Fri Oct 14 10:05:54 2016 From: aheinecke at intevation.de (Andre Heinecke) Date: Fri, 14 Oct 2016 10:05:54 +0200 Subject: gpgme 1.7.0 "make" does not make lang/qt/doc/generated/latex/refman.pdf In-Reply-To: <8760oxut5e.fsf@alice.fifthhorseman.net> References: <8760oxut5e.fsf@alice.fifthhorseman.net> Message-ID: <1613210.eOBHhIISi0@esus> Hi, On Wednesday 12 October 2016 17:58:05 Daniel Kahn Gillmor wrote: > using gpgme 1.7.0, after a "make", i can coax a nice-looking PDF > reference manual for libqgpgme by doing: I think that the PDF is way too large. A lot of the documentation is for private (All classes starting with QGpgME are private) API and It is very repetitive as the Jobs all follow the same pattern. It would probably better to explain the pattern in general and then list the available Jobs and how to use them. I want to work on this with doxgen but I did not find the time yet ;-) > (cd lang/qt/doc/generated/latex && make) > > This creates refman.pdf in the mentioned directory. > > I would have expected this pdf to be built automatically, at the same > time as the rest of the stuff in that directory. Is there a reason it's > not done automatically? Requires Latex and we don't check for latex. yet :-). Also this would slow down the build further and I find the HTML documentation more useful as it's better interlinked. > I'm afraid i'm not enough of a doxygen wizard to know the right > incantations in Makefile.am or Doxyfile to ensure that it gets built > during a standard run, but it would be nice if it were! The gentoo package maintainer requested that the doc is not built by default. I think if we add an explict configure option to enable the qt doc we could also then generate the pdf / check for latex. 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: 630 bytes Desc: This is a digitally signed message part. URL: From arnaud.fontaine at ssi.gouv.fr Fri Oct 14 11:26:13 2016 From: arnaud.fontaine at ssi.gouv.fr (Arnaud Fontaine) Date: Fri, 14 Oct 2016 11:26:13 +0200 Subject: [PATCH] scd: Increase ECC private key template size Message-ID: <5800A4B5.1020006@ssi.gouv.fr> * scd/app-openpgp.c: The encoded template size is two bytes long when both private and public keys are included and the curve has large coordinates. --- scd/app-openpgp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index 563a045..9eb30a0 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -2684,7 +2684,7 @@ build_ecc_privkey_template (app_t app, int keyno, suffix_len = tp - suffix; /* Now concatenate everything. */ - template_size = (1 + 1 /* 0x4d and len. */ + template_size = (1 + 2 /* 0x4d and len. */ + exthdr_len + privkey_len + suffix_len @@ -2710,7 +2710,7 @@ build_ecc_privkey_template (app_t app, int keyno, tp += ecc_q_len; } - assert (tp - template == template_size); + assert ((template_size - 1) <= (tp - template)); *result = template; *resultlen = tp - template; -- 2.9.3 From alon.barlev at gmail.com Fri Oct 14 11:36:04 2016 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Fri, 14 Oct 2016 12:36:04 +0300 Subject: gpgme 1.7.0 "make" does not make lang/qt/doc/generated/latex/refman.pdf In-Reply-To: <1613210.eOBHhIISi0@esus> References: <8760oxut5e.fsf@alice.fifthhorseman.net> <1613210.eOBHhIISi0@esus> Message-ID: On 14 October 2016 at 11:05, Andre Heinecke wrote: > > The gentoo package maintainer requested that the doc is not built by default. > I think if we add an explict configure option to enable the qt doc we could > also then generate the pdf / check for latex. > > Regards, > Andre Correct, there is no reason to build unless required to be installed by the user. For each doc component/technology there should be an explicit option in this case the apidoc of doxygen or the latex output should be two separate options which may be package width. From bernhard at intevation.de Fri Oct 14 11:00:23 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 14 Oct 2016 11:00:23 +0200 Subject: begging for pyme name change In-Reply-To: <87k2dbucl4.fsf@alice.fifthhorseman.net> References: <87insx8404.fsf@servo.finestructure.net> <877f9c88t7.fsf@servo.finestructure.net> <87k2dbucl4.fsf@alice.fifthhorseman.net> Message-ID: <201610141100.26798.bernhard@intevation.de> Am Freitag 14 Oktober 2016 00:08:07 schrieb Daniel Kahn Gillmor: > fwiw, i agree that the best name is "python-gpgme" FWIW: I believe in "python3-gnupg" Why? The "gnupg" is the strongest brand we (as the GnuPG Free Software Initiative) have. -- 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 arnaud.fontaine at ssi.gouv.fr Fri Oct 14 13:46:35 2016 From: arnaud.fontaine at ssi.gouv.fr (Arnaud Fontaine) Date: Fri, 14 Oct 2016 13:46:35 +0200 Subject: [PATCH] scd: Generation of ECC keys on-board (OpenPGP card 3) Message-ID: <5800C59B.2020305@ssi.gouv.fr> * scd/app-openpgp.c: Support for on-board generation of ECC keys introduced in OpenPGP card specification 3.0. --- scd/app-openpgp.c | 116 +++++++++++++++++++++++++++++++++++++++++------------- 1 file changed, 88 insertions(+), 28 deletions(-) diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index 563a045..775640e 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -3568,9 +3568,17 @@ do_genkey (app_t app, ctrl_t ctrl, const char *keynostr, unsigned int flags, to put a limit on the max. allowed keysize. 2048 bit will already lead to a 527 byte long status line and thus a 4096 bit key would exceed the Assuan line length limit. */ - keybits = app->app_local->keyattr[keyno].rsa.n_bits; - if (keybits > 4096) - return gpg_error (GPG_ERR_TOO_LARGE); + if (app->app_local->keyattr[keyno].key_type == KEY_TYPE_RSA) + { + keybits = app->app_local->keyattr[keyno].rsa.n_bits; + if (keybits > 4096) + return gpg_error (GPG_ERR_TOO_LARGE); + } + else + { + keybits = 600; /* arbitrary value, but large enough for curves + supported in 3.0 */ + } /* Prepare for key generation by verifying the Admin PIN. */ rc = verify_chv3 (app, pincb, pincb_arg); @@ -3625,38 +3633,90 @@ do_genkey (app_t app, ctrl_t ctrl, const char *keynostr, unsigned int flags, goto leave; } - m = find_tlv (keydata, keydatalen, 0x0081, &mlen); - if (!m) + created_at = createtime? createtime : gnupg_get_time (); + sprintf (numbuf, "%lu", (unsigned long)created_at); + send_status_info (ctrl, "KEY-CREATED-AT", + numbuf, (size_t)strlen(numbuf), NULL, 0); + + if (app->app_local->keyattr[keyno].key_type == KEY_TYPE_RSA) { - rc = gpg_error (GPG_ERR_CARD); - log_error (_("response does not contain the RSA modulus\n")); - goto leave; + m = find_tlv (keydata, keydatalen, 0x0081, &mlen); + if (!m) + { + rc = gpg_error (GPG_ERR_CARD); + log_error (_("response does not contain the RSA modulus\n")); + goto leave; + } + /* log_printhex ("RSA n:", m, mlen); */ + send_key_data (ctrl, "n", m, mlen); + + e = find_tlv (keydata, keydatalen, 0x0082, &elen); + if (!e) + { + rc = gpg_error (GPG_ERR_CARD); + log_error (_("response does not contain the RSA public exponent\n")); + goto leave; + } + /* log_printhex ("RSA e:", e, elen); */ + send_key_data (ctrl, "e", e, elen); + + for (; mlen && !*m; mlen--, m++) /* strip leading zeroes */ + ; + for (; elen && !*e; elen--, e++) /* strip leading zeroes */ + ; + + rc = store_fpr (app, keyno, (u32)created_at, fprbuf, PUBKEY_ALGO_RSA, + m, mlen, e, elen); } - /* log_printhex ("RSA n:", m, mlen); */ - send_key_data (ctrl, "n", m, mlen); - e = find_tlv (keydata, keydatalen, 0x0082, &elen); - if (!e) + if (app->app_local->keyattr[keyno].key_type == KEY_TYPE_ECC) { - rc = gpg_error (GPG_ERR_CARD); - log_error (_("response does not contain the RSA public exponent\n")); - goto leave; - } - /* log_printhex ("RSA e:", e, elen); */ - send_key_data (ctrl, "e", e, elen); + gcry_mpi_t oid; + int n; - created_at = createtime? createtime : gnupg_get_time (); - sprintf (numbuf, "%lu", (unsigned long)created_at); - send_status_info (ctrl, "KEY-CREATED-AT", - numbuf, (size_t)strlen(numbuf), NULL, 0); + m = find_tlv (keydata, keydatalen, 0x0086, &mlen); + if (!m) + { + rc = gpg_error (GPG_ERR_CARD); + log_error (_("response does not contain the EC public key\n")); + goto leave; + } - for (; mlen && !*m; mlen--, m++) /* strip leading zeroes */ - ; - for (; elen && !*e; elen--, e++) /* strip leading zeroes */ - ; + rc = openpgp_oid_from_str (app->app_local->keyattr[keyno].ecc.oid, &oid); + if (rc) + goto leave; + + e = gcry_mpi_get_opaque (oid, &n); + elen = (n+7)/8; + + send_key_data (ctrl, "q", m, mlen); + + for (; mlen && !*m; mlen--, m++) /* strip leading zeroes */ + ; + + send_key_data(ctrl, "c", e, elen); + + if (keyno == 1) + { + send_key_data(ctrl, "f", "\x03\x01\x08\x07", (size_t)4); + + rc = store_fpr (app, keyno, (u32)created_at, fprbuf, + PUBKEY_ALGO_ECDH, + e, elen, + m, mlen, + "\x03\x01\x08\x07", (size_t)4); /* KDF for ECDH : 03 01 hash_alg sym_alg */ + /* hash_alg : 8 = SHA256, 9 = SHA384, 10 = SHA512 */ + /* sym_alg : 7 = AES, 8 = AES192, 9 = AES256 */ + } + else + { + rc = store_fpr (app, keyno, (u32)created_at, fprbuf, + PUBKEY_ALGO_ECDSA, + e, elen, + m, mlen); + } + } - rc = store_fpr (app, keyno, (u32)created_at, fprbuf, PUBKEY_ALGO_RSA, - m, mlen, e, elen); if (rc) goto leave; send_fpr_if_not_null (ctrl, "KEY-FPR", -1, fprbuf); -- 2.9.3 From arnaud.fontaine at ssi.gouv.fr Fri Oct 14 14:23:39 2016 From: arnaud.fontaine at ssi.gouv.fr (Arnaud Fontaine) Date: Fri, 14 Oct 2016 14:23:39 +0200 Subject: [PATCH] agent: Support of ECC key generation by scd Message-ID: <5800CE4B.9090609@ssi.gouv.fr> * g10/call-agent.c: Retrieving data sent by scdaemon when an ECC key has been generated. * g10/call-agent.h: Change in agent info structure to hold information related to an ECC key generated by scdaemon. * g10/keygen.c: Support of ECC key generation by scd --- g10/call-agent.c | 26 ++++++++++++++++++++++-- g10/call-agent.h | 14 +++++++++++-- g10/keygen.c | 61 +++++++++++++++++++++++++++++++++++++++++++++++++------- 3 files changed, 90 insertions(+), 11 deletions(-) diff --git a/g10/call-agent.c b/g10/call-agent.c index 0fb392c..988c763 100644 --- a/g10/call-agent.c +++ b/g10/call-agent.c @@ -1049,13 +1049,35 @@ scd_genkey_cb (void *opaque, const char *line) } else rc = gcry_mpi_scan (&a, GCRYMPI_FMT_HEX, line, 0, NULL); + if (rc) log_error ("error parsing received key data: %s\n", gpg_strerror (rc)); else if (*name == 'n' && spacep (name+1)) - parm->cgk->n = a; + { + parm->cgk->algo = PUBKEY_ALGO_RSA; + parm->cgk->rsa.n = a; + } else if (*name == 'e' && spacep (name+1)) - parm->cgk->e = a; + { + parm->cgk->algo = PUBKEY_ALGO_RSA; + parm->cgk->rsa.e = a; + } + else if (*name == 'q' && spacep (name+1)) + { + parm->cgk->algo = PUBKEY_ALGO_ECDSA; + parm->cgk->ecc.q = a; + } + else if (*name == 'c' && spacep (name+1)) + { + parm->cgk->algo = PUBKEY_ALGO_ECDSA; + parm->cgk->ecc.curve_oid = a; + } + else if (*name == 'f' && spacep (name+1)) + { + parm->cgk->algo = PUBKEY_ALGO_ECDH; + parm->cgk->ecc.kdf = a; + } else { log_info ("unknown parameter name in received key data\n"); diff --git a/g10/call-agent.h b/g10/call-agent.h index d85a6fd..6440be6 100644 --- a/g10/call-agent.h +++ b/g10/call-agent.h @@ -72,8 +72,18 @@ struct agent_card_genkey_s { char fprvalid; char fpr[20]; u32 created_at; - gcry_mpi_t n; - gcry_mpi_t e; + int algo; + union { + struct { + gcry_mpi_t n; + gcry_mpi_t e; + } rsa; + struct { + gcry_mpi_t curve_oid; + gcry_mpi_t kdf; /* if algo is ECDH only */ + gcry_mpi_t q; + } ecc; + }; }; diff --git a/g10/keygen.c b/g10/keygen.c index 9cf314d..0b07677 100644 --- a/g10/keygen.c +++ b/g10/keygen.c @@ -4901,12 +4901,29 @@ gen_card_key (int algo, int keyno, int is_primary, kbnode_t pub_root, * rc = agent_scd_genkey (&info, keyno, 1); * } */ - if (!err && (!info.n || !info.e)) + if (!err && (info.algo == PUBKEY_ALGO_RSA) && (!info.rsa.n || !info.rsa.e)) { log_error ("communication error with SCD\n"); - gcry_mpi_release (info.n); - gcry_mpi_release (info.e); - err = gpg_error (GPG_ERR_GENERAL); + gcry_mpi_release (info.rsa.n); + gcry_mpi_release (info.rsa.e); + err = gpg_error (GPG_ERR_GENERAL); + } + if (!err && (info.algo == PUBKEY_ALGO_ECDSA) + && (!info.ecc.curve_oid || !info.ecc.q)) + { + log_error ("communication error with SCD\n"); + gcry_mpi_release (info.ecc.curve_oid); + gcry_mpi_release (info.ecc.q); + err = gpg_error (GPG_ERR_GENERAL); + } + if (!err && (info.algo == PUBKEY_ALGO_ECDH) + && (!info.ecc.curve_oid || !info.ecc.kdf || !info.ecc.q)) + { + log_error ("communication error with SCD\n"); + gcry_mpi_release (info.ecc.curve_oid); + gcry_mpi_release (info.ecc.kdf); + gcry_mpi_release (info.ecc.q); + err = gpg_error (GPG_ERR_GENERAL); } if (err) { @@ -4937,9 +4954,39 @@ gen_card_key (int algo, int keyno, int is_primary, kbnode_t pub_root, pk->version = 4; if (expireval) pk->expiredate = pk->timestamp + expireval; - pk->pubkey_algo = algo; - pk->pkey[0] = info.n; - pk->pkey[1] = info.e; + pk->pubkey_algo = info.algo; + if (info.algo == PUBKEY_ALGO_RSA) + { + pk->pkey[0] = info.rsa.n; + pk->pkey[1] = info.rsa.e; + } + if (info.algo == PUBKEY_ALGO_ECDH || info.algo == PUBKEY_ALGO_ECDSA) + { + unsigned char *buf = NULL; + size_t buflen = 0; + + err = gcry_mpi_aprint (GCRYMPI_FMT_USG, &buf, &buflen, info.ecc.curve_oid); + if (err) + { + log_error("Failed to convert EC curve OID"); + return err; + } + pk->pkey[0] = gcry_mpi_set_opaque_copy (NULL, buf, buflen * 8); + pk->pkey[1] = info.ecc.q; + xfree (buf); + + if (info.algo == PUBKEY_ALGO_ECDH) + { + err = gcry_mpi_aprint (GCRYMPI_FMT_USG, &buf, &buflen, info.ecc.kdf); + if (err) + { + log_error("Failed to convert ECDH KDF parameters"); + return err; + } + pk->pkey[2] = gcry_mpi_set_opaque_copy (NULL, buf, buflen * 8); + xfree (buf); + } + } pkt->pkttype = is_primary ? PKT_PUBLIC_KEY : PKT_PUBLIC_SUBKEY; pkt->pkt.public_key = pk; -- 2.9.3 From arnaud.fontaine at ssi.gouv.fr Fri Oct 14 15:30:10 2016 From: arnaud.fontaine at ssi.gouv.fr (Arnaud Fontaine) Date: Fri, 14 Oct 2016 15:30:10 +0200 Subject: [PATCH] gpg: Update card-edit wizard to support ECC key generation Message-ID: <5800DDE2.8080304@ssi.gouv.fr> * g10/card-util.c: Ask for key size only for RSA key generation. * g10/keygen.c: Add algo parameter to deal with ECC key generation. --- g10/card-util.c | 51 +++++++++++++++++++++++++++++---------------------- g10/keygen.c | 17 ++++++----------- 2 files changed, 35 insertions(+), 33 deletions(-) diff --git a/g10/card-util.c b/g10/card-util.c index 2cb44f9..6574241 100644 --- a/g10/card-util.c +++ b/g10/card-util.c @@ -1277,7 +1277,7 @@ show_keysize_warning (void) select the prompt. Returns 0 to use the default size (i.e. NBITS) or the selected size. */ static unsigned int -ask_card_keysize (int keyno, unsigned int nbits) +ask_card_rsa_keysize (int keyno, unsigned int nbits) { unsigned int min_nbits = 1024; unsigned int max_nbits = 4096; @@ -1327,7 +1327,7 @@ ask_card_keysize (int keyno, unsigned int nbits) /* Change the size of key KEYNO (0..2) to NBITS and show an error message if that fails. */ static gpg_error_t -do_change_keysize (int keyno, unsigned int nbits) +do_change_rsa_keysize (int keyno, unsigned int nbits) { gpg_error_t err; char args[100]; @@ -1406,15 +1406,18 @@ generate_card_keys (ctrl_t ctrl) for (keyno = 0; keyno < DIM (info.key_attr); keyno++) { - nbits = ask_card_keysize (keyno, info.key_attr[keyno].nbits); - if (nbits && do_change_keysize (keyno, nbits)) + if (info.key_attr[keyno].algo == PUBKEY_ALGO_RSA) { - /* Error: Better read the default key size again. */ - agent_release_card_info (&info); - if (get_info_for_key_operation (&info)) - goto leave; - /* Ask again for this key size. */ - keyno--; + nbits = ask_card_rsa_keysize (keyno, info.key_attr[keyno].nbits); + if (nbits && do_change_rsa_keysize (keyno, nbits)) + { + /* Error: Better read the default key size again. */ + agent_release_card_info (&info); + if (get_info_for_key_operation (&info)) + goto leave; + /* Ask again for this key size. */ + keyno--; + } } } /* Note that INFO has not be synced. However we will only use @@ -1483,21 +1486,25 @@ card_generate_subkey (KBNODE pub_keyblock) key size. */ if (info.is_v2 && info.extcap.aac) { - unsigned int nbits; - ask_again: - nbits = ask_card_keysize (keyno-1, info.key_attr[keyno-1].nbits); - if (nbits && do_change_keysize (keyno-1, nbits)) + if (info.key_attr[keyno-1].algo == PUBKEY_ALGO_RSA) { - /* Error: Better read the default key size again. */ - agent_release_card_info (&info); - err = get_info_for_key_operation (&info); - if (err) - goto leave; - goto ask_again; + unsigned int nbits; + + ask_again: + nbits = ask_card_rsa_keysize (keyno-1, info.key_attr[keyno-1].nbits); + if (nbits && do_change_rsa_keysize (keyno-1, nbits)) + { + /* Error: Better read the default key size again. */ + agent_release_card_info (&info); + err = get_info_for_key_operation (&info); + if (err) + goto leave; + goto ask_again; + } } - /* Note that INFO has not be synced. However we will only use - the serialnumber and thus it won't harm. */ + /* Note that INFO has not be synced. However we will only use + the serialnumber and thus it won't harm. */ } err = generate_card_subkeypair (pub_keyblock, keyno, info.serialno); diff --git a/g10/keygen.c b/g10/keygen.c index 9cf314d..84dcbc1 100644 --- a/g10/keygen.c +++ b/g10/keygen.c @@ -154,7 +154,7 @@ static gpg_error_t parse_algo_usage_expire (ctrl_t ctrl, int for_subkey, static void do_generate_keypair (ctrl_t ctrl, struct para_data_s *para, struct output_control_s *outctrl, int card ); static int write_keyblock (iobuf_t out, kbnode_t node); -static gpg_error_t gen_card_key (int algo, int keyno, int is_primary, +static gpg_error_t gen_card_key (int keyno, int is_primary, kbnode_t pub_root, u32 *timestamp, u32 expireval); @@ -4238,7 +4238,7 @@ do_generate_keypair (ctrl_t ctrl, struct para_data_s *para, get_parameter_passphrase (para), &cache_nonce, NULL); else - err = gen_card_key (PUBKEY_ALGO_RSA, 1, 1, pub_root, + err = gen_card_key (1, 1, pub_root, ×tamp, get_parameter_u32 (para, pKEYEXPIRE)); @@ -4277,7 +4277,7 @@ do_generate_keypair (ctrl_t ctrl, struct para_data_s *para, if (!err && card && get_parameter (para, pAUTHKEYTYPE)) { - err = gen_card_key (PUBKEY_ALGO_RSA, 3, 0, pub_root, + err = gen_card_key (3, 0, pub_root, ×tamp, get_parameter_u32 (para, pKEYEXPIRE)); if (!err) @@ -4317,7 +4317,7 @@ do_generate_keypair (ctrl_t ctrl, struct para_data_s *para, } else { - err = gen_card_key (PUBKEY_ALGO_RSA, 2, 0, pub_root, ×tamp, + err = gen_card_key (2, 0, pub_root, ×tamp, get_parameter_u32 (para, pKEYEXPIRE)); } @@ -4749,7 +4749,6 @@ generate_card_subkeypair (kbnode_t pub_keyblock, gpg_error_t err = 0; kbnode_t node; PKT_public_key *pri_pk = NULL; - int algo; unsigned int use; u32 expire; u32 cur_time; @@ -4800,7 +4799,6 @@ generate_card_subkeypair (kbnode_t pub_keyblock, goto leave; } - algo = PUBKEY_ALGO_RSA; expire = ask_expire_interval (0, NULL); if (keyno == 1) use = PUBKEY_USAGE_SIG; @@ -4817,7 +4815,7 @@ generate_card_subkeypair (kbnode_t pub_keyblock, /* Note, that depending on the backend, the card key generation may update CUR_TIME. */ - err = gen_card_key (algo, keyno, 0, pub_keyblock, &cur_time, expire); + err = gen_card_key (keyno, 0, pub_keyblock, &cur_time, expire); /* Get the pointer to the generated public subkey packet. */ if (!err) { @@ -4865,7 +4863,7 @@ write_keyblock( IOBUF out, KBNODE node ) /* Note that timestamp is an in/out arg. */ static gpg_error_t -gen_card_key (int algo, int keyno, int is_primary, kbnode_t pub_root, +gen_card_key (int keyno, int is_primary, kbnode_t pub_root, u32 *timestamp, u32 expireval) { #ifdef ENABLE_CARD_SUPPORT @@ -4874,9 +4872,6 @@ gen_card_key (int algo, int keyno, int is_primary, kbnode_t pub_root, PACKET *pkt; PKT_public_key *pk; - if (algo != PUBKEY_ALGO_RSA) - return gpg_error (GPG_ERR_PUBKEY_ALGO); - pk = xtrycalloc (1, sizeof *pk ); if (!pk) return gpg_error_from_syserror (); -- 2.9.3 From lists at ssl-mail.com Fri Oct 14 16:38:16 2016 From: lists at ssl-mail.com (lists at ssl-mail.com) Date: Fri, 14 Oct 2016 07:38:16 -0700 Subject: gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)" In-Reply-To: <0F63C671-4066-4CF4-813A-66BC544D16FF@sumptuouscapital.com> References: <1476027783.1522252.750391089.07374952@webmail.messagingengine.com> <20161009223833.GA4309@tower.spodhuis.org> <1476053249.1594379.750625153.58F21EF5@webmail.messagingengine.com> <20161010131036.GC17876@glanzmann.de> <1476105541.3317580.751181353.553BB041@webmail.messagingengine.com> <1476195700.945573.752442825.4C7CDE8B@webmail.messagingengine.com> <87twciw63f.fsf@alice.fifthhorseman.net> <1476278885.2082508.753599713.74736041@webmail.messagingengine.com> <87pon5vdqd.fsf@alice.fifthhorseman.net> <0F63C671-4066-4CF4-813A-66BC544D16FF@sumptuouscapital.com> Message-ID: <1476455896.2749097.756060657.05BE8764@webmail.messagingengine.com> On Wed, Oct 12, 2016, at 03:07 PM, Kristian Fiskerstrand wrote: > Well, seems SRV records are causing more issues than they are useful. They only ever make sense for the geographical sub-pools in order to distributed the traffic using weights there, for the rest of the pools they are a noop since allowing specific ports etc is a bad idea overall. > > This is further complicated by gnupg 2.1 using _hkp , whereby the consensus in previous implementation has been _pgpkey-http._tcp. So where SRV is implementere it is using the original identifier. > > Not having SRV should certainly not result in failure of operation when A and AAAA records are returned though.. Is there an alternative setup that does work with gnupg 2.1x that we should be using? Or are you saying that atm gnupg 2.1x is broken, in need of a fix? From ag4ve.us at gmail.com Fri Oct 14 15:19:09 2016 From: ag4ve.us at gmail.com (shawn wilson) Date: Fri, 14 Oct 2016 09:19:09 -0400 Subject: begging for pyme name change In-Reply-To: <201610141100.26798.bernhard@intevation.de> References: <87insx8404.fsf@servo.finestructure.net> <877f9c88t7.fsf@servo.finestructure.net> <87k2dbucl4.fsf@alice.fifthhorseman.net> <201610141100.26798.bernhard@intevation.de> Message-ID: On Oct 14, 2016 06:19, "Bernhard Reiter" wrote: > > Am Freitag 14 Oktober 2016 00:08:07 schrieb Daniel Kahn Gillmor: > > fwiw, i agree that the best name is "python-gpgme" > > FWIW: I believe in "python3-gnupg" > Why? The "gnupg" is the strongest brand we (as the GnuPG Free Software > Initiative) have. > Is this incompatible with python 2? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Fri Oct 14 18:42:24 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 14 Oct 2016 12:42:24 -0400 Subject: [PATCH] document how to manually shut down gpg-agent Message-ID: <20161014164224.31498-1-dkg@fifthhorseman.net> * doc/gpg-agent.texi: document "gpgconf --kill gpg-agent" for manual agent termination. This was requested in a side-comment in https://bugs.debian.org/840669 Signed-off-by: Daniel Kahn Gillmor --- doc/gpg-agent.texi | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/doc/gpg-agent.texi b/doc/gpg-agent.texi index 7c41027..3177af4 100644 --- a/doc/gpg-agent.texi +++ b/doc/gpg-agent.texi @@ -85,6 +85,14 @@ gpg-connect-agent /bye @end example @noindent +If you want to manually terminate the currently-running agent, you can +safely do so with: + + at example +gpgconf --kill gpg-agent + at end example + + at noindent @efindex GPG_TTY You should always add the following lines to your @code{.bashrc} or whatever initialization file is used for all shell invocations: @@ -1518,6 +1526,7 @@ much slower or faster than the actual box. @ifset isman @command{@gpgname}(1), @command{gpgsm}(1), + at command{gpgconf}(1), @command{gpg-connect-agent}(1), @command{scdaemon}(1) @end ifset -- 2.9.3 From dkg at fifthhorseman.net Fri Oct 14 19:07:38 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 14 Oct 2016 13:07:38 -0400 Subject: gpgme 1.7.0 "make" does not make lang/qt/doc/generated/latex/refman.pdf In-Reply-To: <1613210.eOBHhIISi0@esus> References: <8760oxut5e.fsf@alice.fifthhorseman.net> <1613210.eOBHhIISi0@esus> Message-ID: <87pon2rh9h.fsf@alice.fifthhorseman.net> On Fri 2016-10-14 04:05:54 -0400, Andre Heinecke wrote: > On Wednesday 12 October 2016 17:58:05 Daniel Kahn Gillmor wrote: >> using gpgme 1.7.0, after a "make", i can coax a nice-looking PDF >> reference manual for libqgpgme by doing: > > I think that the PDF is way too large. A lot of the documentation is for > private (All classes starting with QGpgME are private) API and It is very > repetitive as the Jobs all follow the same pattern. It would probably better > to explain the pattern in general and then list the available Jobs and how to > use them. I want to work on this with doxgen but I did not find the time yet > ;-) that's fine -- if you think the documentation there isn't useful, i won't build it or ship it in debian either. if you do get around to cleaning it up enough to where you like it, please make that clear so i can re-enable the build in debian. Thanks for the rapid response, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From dkg at fifthhorseman.net Fri Oct 14 19:13:45 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 14 Oct 2016 13:13:45 -0400 Subject: begging for pyme name change In-Reply-To: <201610141100.26798.bernhard@intevation.de> References: <87insx8404.fsf@servo.finestructure.net> <877f9c88t7.fsf@servo.finestructure.net> <87k2dbucl4.fsf@alice.fifthhorseman.net> <201610141100.26798.bernhard@intevation.de> Message-ID: <87mvi6rgza.fsf@alice.fifthhorseman.net> On Fri 2016-10-14 05:00:23 -0400, Bernhard Reiter wrote: > Am Freitag 14 Oktober 2016 00:08:07 schrieb Daniel Kahn Gillmor: >> fwiw, i agree that the best name is "python-gpgme" > > FWIW: I believe in "python3-gnupg" This is already taken (at least in debian) by the python-gnupg project's python3 module. https://bitbucket.org/vinay.sajip/python-gnupg python-gnupg does not have anything close to a similar interface supported by gpgme, and it also doesn't currently support gnupg 2.1.x i'm working on a series of patches for it, but this has been open for over a year upstream without being fixed: https://bitbucket.org/vinay.sajip/python-gnupg/issues/32/add-gpg-21-compability afaict, the current upstream code does not even pass the tests with 2.1.x installed :/ > Why? The "gnupg" is the strongest brand we (as the GnuPG Free Software > Initiative) have. agreed, but these bindings are specifically connected to gpgme, and "gpg" is at least present there. Also, our other language bindings include the "me" in their names; why should python bindings be any different? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From dkg at fifthhorseman.net Sat Oct 15 03:15:25 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 14 Oct 2016 21:15:25 -0400 Subject: gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)" In-Reply-To: <0F63C671-4066-4CF4-813A-66BC544D16FF@sumptuouscapital.com> References: <1476027783.1522252.750391089.07374952@webmail.messagingengine.com> <20161009223833.GA4309@tower.spodhuis.org> <1476053249.1594379.750625153.58F21EF5@webmail.messagingengine.com> <20161010131036.GC17876@glanzmann.de> <1476105541.3317580.751181353.553BB041@webmail.messagingengine.com> <1476195700.945573.752442825.4C7CDE8B@webmail.messagingengine.com> <87twciw63f.fsf@alice.fifthhorseman.net> <1476278885.2082508.753599713.74736041@webmail.messagingengine.com> <87pon5vdqd.fsf@alice.fifthhorseman.net> <0F63C671-4066-4CF4-813A-66BC544D16FF@sumptuouscapital.com> Message-ID: <87funypg42.fsf@alice.fifthhorseman.net> On Wed 2016-10-12 18:07:07 -0400, Kristian Fiskerstrand wrote: > Well, seems SRV records are causing more issues than they are > useful. They only ever make sense for the geographical sub-pools in > order to distributed the traffic using weights there, for the rest of > the pools they are a noop since allowing specific ports etc is a bad > idea overall. > > This is further complicated by gnupg 2.1 using _hkp , whereby the > consensus in previous implementation has been _pgpkey-http._tcp. So > where SRV is implementere it is using the original identifier. hm, where was _pgpkey-http._tcp initially documented? /etc/services on my machine has port 11371 registered explicitly as hkp (though it also has hkp registered with 11371/udp, which doesn't make much sense, but the comment at the top justifies it with an argument for symmetry between udp and tcp. meh) > Not having SRV should certainly not result in failure of operation > when A and AAAA records are returned though.. Agreed. Is this the same as the issues raised here https://bugs.gnupg.org/gnupg/issue2451 ? or should someone? open a distinct issue about it? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From kristian.fiskerstrand at sumptuouscapital.com Sat Oct 15 12:51:47 2016 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Sat, 15 Oct 2016 12:51:47 +0200 Subject: gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)" In-Reply-To: <87funypg42.fsf@alice.fifthhorseman.net> References: <1476027783.1522252.750391089.07374952@webmail.messagingengine.com> <20161009223833.GA4309@tower.spodhuis.org> <1476053249.1594379.750625153.58F21EF5@webmail.messagingengine.com> <20161010131036.GC17876@glanzmann.de> <1476105541.3317580.751181353.553BB041@webmail.messagingengine.com> <1476195700.945573.752442825.4C7CDE8B@webmail.messagingengine.com> <87twciw63f.fsf@alice.fifthhorseman.net> <1476278885.2082508.753599713.74736041@webmail.messagingengine.com> <87pon5vdqd.fsf@alice.fifthhorseman.net> <0F63C671-4066-4CF4-813A-66BC544D16FF@sumptuouscapital.com> <87funypg42.fsf@alice.fifthhorseman.net> Message-ID: On 10/15/2016 03:15 AM, Daniel Kahn Gillmor wrote: > On Wed 2016-10-12 18:07:07 -0400, Kristian Fiskerstrand wrote: >> Well, seems SRV records are causing more issues than they are >> useful. They only ever make sense for the geographical sub-pools in >> order to distributed the traffic using weights there, for the rest of >> the pools they are a noop since allowing specific ports etc is a bad >> idea overall. >> >> This is further complicated by gnupg 2.1 using _hkp , whereby the >> consensus in previous implementation has been _pgpkey-http._tcp. So >> where SRV is implementere it is using the original identifier. > > hm, where was _pgpkey-http._tcp initially documented? /etc/services on > my machine has port 11371 registered explicitly as hkp > It is what is used in gnupg prior to 2.1. See e.g (in stable branch) commit 2e835fd6ab70b7d85cfc90d11baa1cc4cb61a8ef Author: David Shaw Date: Wed Jul 8 04:01:13 2009 +0000 * gpgkeys_hkp.c (main, srv_replace): Minor tweaks to use the DNS-SD names ("pgpkey-http" and "pgpkey-https") in SRV lookups instead of "hkp" and "hkps". -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Fabricando fit faber Practice makes perfect -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Sat Oct 15 12:46:01 2016 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Sat, 15 Oct 2016 12:46:01 +0200 Subject: gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)" In-Reply-To: <1476455896.2749097.756060657.05BE8764@webmail.messagingengine.com> References: <1476027783.1522252.750391089.07374952@webmail.messagingengine.com> <20161009223833.GA4309@tower.spodhuis.org> <1476053249.1594379.750625153.58F21EF5@webmail.messagingengine.com> <20161010131036.GC17876@glanzmann.de> <1476105541.3317580.751181353.553BB041@webmail.messagingengine.com> <1476195700.945573.752442825.4C7CDE8B@webmail.messagingengine.com> <87twciw63f.fsf@alice.fifthhorseman.net> <1476278885.2082508.753599713.74736041@webmail.messagingengine.com> <87pon5vdqd.fsf@alice.fifthhorseman.net> <0F63C671-4066-4CF4-813A-66BC544D16FF@sumptuouscapital.com> <1476455896.2749097.756060657.05BE8764@webmail.messagingengine.com> Message-ID: <2ad09b91-dc98-091c-b516-449106497e46@sumptuouscapital.com> On 10/14/2016 04:38 PM, lists at ssl-mail.com wrote: > On Wed, Oct 12, 2016, at 03:07 PM, Kristian Fiskerstrand wrote: > Is there an alternative setup that does work with gnupg 2.1x that we > should be using? > > Or are you saying that atm gnupg 2.1x is broken, in need of a fix? > Neither, I can not reproduce your issues. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Fabricando fit faber Practice makes perfect -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Sat Oct 15 13:00:56 2016 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Sat, 15 Oct 2016 13:00:56 +0200 Subject: gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)" In-Reply-To: References: <1476027783.1522252.750391089.07374952@webmail.messagingengine.com> <20161009223833.GA4309@tower.spodhuis.org> <1476053249.1594379.750625153.58F21EF5@webmail.messagingengine.com> <20161010131036.GC17876@glanzmann.de> <1476105541.3317580.751181353.553BB041@webmail.messagingengine.com> <1476195700.945573.752442825.4C7CDE8B@webmail.messagingengine.com> <87twciw63f.fsf@alice.fifthhorseman.net> <1476278885.2082508.753599713.74736041@webmail.messagingengine.com> <87pon5vdqd.fsf@alice.fifthhorseman.net> <0F63C671-4066-4CF4-813A-66BC544D16FF@sumptuouscapital.com> <87funypg42.fsf@alice.fifthhorseman.net> Message-ID: On 10/15/2016 12:51 PM, Kristian Fiskerstrand wrote: > On 10/15/2016 03:15 AM, Daniel Kahn Gillmor wrote: >> On Wed 2016-10-12 18:07:07 -0400, Kristian Fiskerstrand wrote: >>> Well, seems SRV records are causing more issues than they are >>> useful. They only ever make sense for the geographical sub-pools in >>> order to distributed the traffic using weights there, for the rest of >>> the pools they are a noop since allowing specific ports etc is a bad >>> idea overall. >>> >>> This is further complicated by gnupg 2.1 using _hkp , whereby the >>> consensus in previous implementation has been _pgpkey-http._tcp. So >>> where SRV is implementere it is using the original identifier. >> >> hm, where was _pgpkey-http._tcp initially documented? /etc/services on >> my machine has port 11371 registered explicitly as hkp >> > > It is what is used in gnupg prior to 2.1. See e.g (in stable branch) > commit 2e835fd6ab70b7d85cfc90d11baa1cc4cb61a8ef > Author: David Shaw > Date: Wed Jul 8 04:01:13 2009 +0000 > > * gpgkeys_hkp.c (main, srv_replace): Minor tweaks to use the DNS-SD > names ("pgpkey-http" and "pgpkey-https") in SRV lookups instead of > "hkp" and "hkps". > > http://dns-sd.org/ServiceTypes.html also does not list "hkp" (but does list pgpkey-hkp, which doesn't necessarily make sense since the request is either http or https transport...) pgpkey-hkp Horowitz Key Protocol (HKP) Marc Horowitz Protocol description: http://www.mit.edu/afs/net.mit.edu/project/pks/thesis/paper/thesis.html Defined TXT keys: None pgpkey-http PGP Keyserver using HTTP/1.1 Jeroen Massar Protocol description: RFC 2816 Defined TXT keys: path= normally: "path=/pks/" pgpkey-https PGP Keyserver using HTTPS Jeroen Massar Protocol description: RFC 2818 Defined TXT keys: path= normally: "path=/pks/" pgpkey-ldap PGP Keyserver using LDAP Jeroen Massar Protocol description: RFC 2251 Defined TXT keys: None pgpkey-mailto PGP Key submission using SMTP Jeroen Massar Protocol description: RFC 2821 Defined TXT keys: user= -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Ad astra per aspera To the stars through thorns -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Sat Oct 15 13:11:46 2016 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Sat, 15 Oct 2016 13:11:46 +0200 Subject: gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)" In-Reply-To: References: <1476027783.1522252.750391089.07374952@webmail.messagingengine.com> <20161009223833.GA4309@tower.spodhuis.org> <1476053249.1594379.750625153.58F21EF5@webmail.messagingengine.com> <20161010131036.GC17876@glanzmann.de> <1476105541.3317580.751181353.553BB041@webmail.messagingengine.com> <1476195700.945573.752442825.4C7CDE8B@webmail.messagingengine.com> <87twciw63f.fsf@alice.fifthhorseman.net> <1476278885.2082508.753599713.74736041@webmail.messagingengine.com> <87pon5vdqd.fsf@alice.fifthhorseman.net> <0F63C671-4066-4CF4-813A-66BC544D16FF@sumptuouscapital.com> <87funypg42.fsf@alice.fifthhorseman.net> Message-ID: On 10/15/2016 01:00 PM, Kristian Fiskerstrand wrote: >> > > http://dns-sd.org/ServiceTypes.html also does not list "hkp" (but does > list pgpkey-hkp, which doesn't necessarily make sense since the request > is either http or https transport...) > It is listed in the [updated iana registry] though, but no way to distinguish TLS transport from plain HTTP. $ grep pgpkey service-names-port-numbers.xml pgpkey-hkp pgpkey-http pgpkey-https pgpkey-ldap pgpkey-mailto $ grep hkp service-names-port-numbers.xml hkp hkp pgpkey-hkp References: [updated iana registry] http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Nulla regula sine exceptione No rule without exception -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Mon Oct 17 05:16:27 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 17 Oct 2016 12:16:27 +0900 Subject: [PATCH] scd: Increase ECC private key template size In-Reply-To: <5800A4B5.1020006@ssi.gouv.fr> References: <5800A4B5.1020006@ssi.gouv.fr> Message-ID: Hello, On 10/14/2016 06:26 PM, Arnaud Fontaine wrote: > * scd/app-openpgp.c: The encoded template size is two bytes long when > both private and public keys are included and the curve has large > coordinates. Thanks for your patch. Please send us Developer's Certificate of Origin (DCO). It is needed so that everyone can check the origin of code. It is explained in gnupg/doc/HACKING at the section of "License policy". Meanwhile, I reviewed. And the commit is the following. ======================================== scd: Fix keytocard for ECC. * scd/app-openpgp.c (build_ecc_privkey_template): Size can be greater than 128 when it comes with public key for curve of larger field. -- Reported-by: Arnaud Fontaine Signed-off-by: NIIBE Yutaka 1 file changed, 2 insertions(+) scd/app-openpgp.c | 2 ++ modified scd/app-openpgp.c @@ -2689,6 +2689,8 @@ build_ecc_privkey_template (app_t app, int keyno, + privkey_len + suffix_len + datalen); + if (exthdr_len + privkey_len + suffix_len + datalen >= 128) + template_size++; tp = template = xtrymalloc_secure (template_size); if (!template) return gpg_error_from_syserror (); -- From bernhard at intevation.de Mon Oct 17 09:39:05 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 17 Oct 2016 09:39:05 +0200 Subject: begging for pyme name change In-Reply-To: References: <87insx8404.fsf@servo.finestructure.net> <201610141100.26798.bernhard@intevation.de> Message-ID: <201610170939.05688.bernhard@intevation.de> Am Freitag 14 Oktober 2016 15:19:09 schrieb shawn wilson: > Is this incompatible with python 2? I expect gpgme's python library to be compatible with python2 and python3. (So far I have not tried it personally.) -- 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 Mon Oct 17 09:51:27 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 17 Oct 2016 09:51:27 +0200 Subject: begging for pyme name change In-Reply-To: <87mvi6rgza.fsf@alice.fifthhorseman.net> References: <87insx8404.fsf@servo.finestructure.net> <201610141100.26798.bernhard@intevation.de> <87mvi6rgza.fsf@alice.fifthhorseman.net> Message-ID: <201610170951.32070.bernhard@intevation.de> Am Freitag 14 Oktober 2016 19:13:45 schrieb Daniel Kahn Gillmor: > On Fri 2016-10-14 05:00:23 -0400, Bernhard Reiter wrote: > > Am Freitag 14 Oktober 2016 00:08:07 schrieb Daniel Kahn Gillmor: > >> fwiw, i agree that the best name is "python-gpgme" > > > > FWIW: I believe in "python3-gnupg" > > This is already taken (at least in debian) by the python-gnupg project's > python3 module. https://bitbucket.org/vinay.sajip/gnupg is not the official python GnuPG API and "gnupg" is **our** namespace so to say. (Still any Free Software contribution is nice, so it is cool that this module was written and published. On the other hand, if we try to raise adoption for GnuPG, we all have a strong interest that there is recognition about what is more or less maintained.) IMO "python-gnupg" is the best name for this. If there are conflicts any distribution could solve them by version numbers when in doubt. Maybe debian would use package names like python3-gnupg2 python-gnupg2 To show that the there was an incompatible API change. My guiding principle is: what name would developers expect when looking for the GnuPG API? > > Why? The "gnupg" is the strongest brand we (as the GnuPG Free Software > > Initiative) have. > > agreed, but these bindings are specifically connected to gpgme, and > "gpg" is at least present there. The brand recognition is specifically highest about "gnupg" not "gpg". > Also, our other language bindings include the "me" in their names; why > should python bindings be any different? "gpgme" is acceptable for me, though I would prefer "gnupg". I am even unshure about the "binding" part as the GnuPG python module is maintained and will grow more functions beyond bare-bones-GnuPG-calling. Calling it a "binding" may be a less interesting detail, missguiding that it comes with it own additions. So the connection is: If you want GnuPG's quality for crypto from python, use its python module. 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 arnaud.fontaine at ssi.gouv.fr Mon Oct 17 09:59:48 2016 From: arnaud.fontaine at ssi.gouv.fr (Arnaud Fontaine) Date: Mon, 17 Oct 2016 09:59:48 +0200 Subject: DCO signoff Message-ID: <580484F4.8040806@ssi.gouv.fr> GnuPG Developer's Certificate of Origin. Version 1.0 ===================================================== By making a contribution to the GnuPG project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the free software license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate free software license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same free software license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the free software license(s) involved. Signed-off-by: Arnaud Fontaine (arnaud.fontaine at ssi.gouv.fr) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From justus at g10code.com Mon Oct 17 10:50:32 2016 From: justus at g10code.com (Justus Winter) Date: Mon, 17 Oct 2016 10:50:32 +0200 Subject: [PATCH] point gpg-agent(1) at the right gpg manpage in SEE ALSO In-Reply-To: <20161014062337.25937-1-dkg@fifthhorseman.net> References: <20161014062337.25937-1-dkg@fifthhorseman.net> Message-ID: <87y41n7413.fsf@europa.jade-hamburg.de> Daniel Kahn Gillmor writes: > * doc/gpg-agent.texi (SEE ALSO): refer to @gpgname, instead of > hard-coding "gpg2". Merged, thanks! Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From justus at g10code.com Mon Oct 17 10:51:13 2016 From: justus at g10code.com (Justus Winter) Date: Mon, 17 Oct 2016 10:51:13 +0200 Subject: [PATCH] document how to manually shut down gpg-agent In-Reply-To: <20161014164224.31498-1-dkg@fifthhorseman.net> References: <20161014164224.31498-1-dkg@fifthhorseman.net> Message-ID: <87vawr73zy.fsf@europa.jade-hamburg.de> Daniel Kahn Gillmor writes: > * doc/gpg-agent.texi: document "gpgconf --kill gpg-agent" for manual > agent termination. Merged, thanks! Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From dkg at fifthhorseman.net Mon Oct 17 18:45:27 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 17 Oct 2016 12:45:27 -0400 Subject: begging for pyme name change In-Reply-To: <201610170951.32070.bernhard@intevation.de> References: <87insx8404.fsf@servo.finestructure.net> <201610141100.26798.bernhard@intevation.de> <87mvi6rgza.fsf@alice.fifthhorseman.net> <201610170951.32070.bernhard@intevation.de> Message-ID: <87twcaorfc.fsf@alice.fifthhorseman.net> [ adding Vinay Sajip to this e-mail thread, so he knows this is under discussion; Vinay, if you haven't been following this discussion about the various python/gnupg namespace issues, you can see the start of the discussion over at https://lists.gnupg.org/pipermail/gnupg-devel/2016-October/031810.html ] On Mon 2016-10-17 03:51:27 -0400, Bernhard Reiter wrote: > https://bitbucket.org/vinay.sajip/gnupg is not the official python GnuPG API > and "gnupg" is **our** namespace so to say. (Still any Free Software > contribution is nice, so it is cool that this module was written and > published. On the other hand, if we try to raise adoption for GnuPG, we all > have a strong interest that there is recognition about what is more or less > maintained.) IMO "python-gnupg" is the best name for this. I hear you, but let's be clear that Vinay Sajip was maintaining this wrapper long before the GnuPG upstream team decided to offer any sort of python functionality at all. I think the fact that upstream is now aiming to take responsibility for a python binding to GnuPG is great; but we can't ignore the fact that this other project was out there filling this need long before upstream was. And this other project has an existing userbase that would be good to reach out to, rather than to ignore. > If there are conflicts any distribution could solve them by version numbers > when in doubt. Maybe debian would use package names like > > python3-gnupg2 > python-gnupg2 > > To show that the there was an incompatible API change. > > My guiding principle is: what name would developers expect when looking > for the GnuPG API? right, and the lack of declared upstream support has left this vacuum where the existing multiplicity of projects are all (confusingly) available. It's not clear to me how to break this logjam, even if we manage to get all parties in agreement that there should be a single preferred pythonic interface to GnuPG. > The brand recognition is specifically highest about "gnupg" not "gpg". I have no idea whether this is true or not. How are you measuring it? > So the connection is: If you want GnuPG's quality for crypto from python, > use its python module. I agree that this phrasing is probably better than the term "binding", thanks. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From wk at gnupg.org Mon Oct 17 19:20:50 2016 From: wk at gnupg.org (Werner Koch) Date: Mon, 17 Oct 2016 19:20:50 +0200 Subject: [PATCH] document how to manually shut down gpg-agent In-Reply-To: <20161014164224.31498-1-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 14 Oct 2016 12:42:24 -0400") References: <20161014164224.31498-1-dkg@fifthhorseman.net> Message-ID: <87d1iyvqml.fsf@wheatstone.g10code.de> On Fri, 14 Oct 2016 18:42, dkg at fifthhorseman.net said: > * doc/gpg-agent.texi: document "gpgconf --kill gpg-agent" for manual > agent termination. > > This was requested in a side-comment in https://bugs.debian.org/840669 FWIW, there is no need to write a ChangeLog entry for doc changes. Adding an explanation after a "--" line make more sense. This way we can keep the generated ChangeLog somewhat useful. But the "--" line is important - only Signed-off-by and a few other standard remarks are stripped off the ChangeLog without a "--" line. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From dkg at fifthhorseman.net Mon Oct 17 21:40:08 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 17 Oct 2016 15:40:08 -0400 Subject: begging for pyme name change In-Reply-To: <377754233.3622270.1476729098157@mail.yahoo.com> References: <87insx8404.fsf@servo.finestructure.net> <201610141100.26798.bernhard@intevation.de> <87mvi6rgza.fsf@alice.fifthhorseman.net> <201610170951.32070.bernhard@intevation.de> <87twcaorfc.fsf@alice.fifthhorseman.net> <377754233.3622270.1476729098157@mail.yahoo.com> Message-ID: <87eg3eix2f.fsf@alice.fifthhorseman.net> On Mon 2016-10-17 14:31:38 -0400, Vinay Sajip wrote: > It appears to be all about Python bindings to GPGME. However, my > project, python-gnupg, deliberately avoids binding to any C-level > library and instead provides a wrapper around the gpg executable. I agree with this, but? > The bindings-to-C and wrapper-over-gpg models are both useful in > different contexts, and should continue to co-exist as long as > possible. ? i'm not sure i'd reach this conclusion in the abstract. In particular, it'd be nice to see a single clear way to use gpg in python, so that people using python don't have to choose between one mechanism or another. what if they want functionality that's only available in one mechanism, and then they *also* want functionality that's only available in the other mechanism? Python is supposed to make those sorts of choices easy, and maintaining both approaches sounds troubling for the downstreams. This is something for the upstream GnuPG team to wrestle with too -- how do we make it easy for people to use GnuPG in a reliable way from other programs? It hasn't been as easy as it should be. > Of course the python-gpgme name is also taken (by James Henstridge's > package - I'm not sure how maintained that is, I couldn't see any > releases more recent than 2012 and nothing in the source repository > newer than 2013). However, it would make more sense to see if i think you were about to suggest asking him for that name -- i agree, and we've already reached out to him on a different branch of this discussion. Thanks for the suggestion! And, thanks for your ongoing work on python-gnupg. It's very much appreciated. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From vinay_sajip at yahoo.co.uk Mon Oct 17 20:31:38 2016 From: vinay_sajip at yahoo.co.uk (Vinay Sajip) Date: Mon, 17 Oct 2016 18:31:38 +0000 (UTC) Subject: begging for pyme name change In-Reply-To: <87twcaorfc.fsf@alice.fifthhorseman.net> References: <87insx8404.fsf@servo.finestructure.net> <201610141100.26798.bernhard@intevation.de> <87mvi6rgza.fsf@alice.fifthhorseman.net> <201610170951.32070.bernhard@intevation.de> <87twcaorfc.fsf@alice.fifthhorseman.net> Message-ID: <377754233.3622270.1476729098157@mail.yahoo.com> Dear Daniel, Thanks for bringing this discussion to my attention. It appears to be all about Python bindings to GPGME. However, my project, python-gnupg, deliberately avoids binding to any C-level library and instead provides a wrapper around the gpg executable. There are some benefits which flow from this: 1. The C-level library's functionality (as documented) seems to lag somewhat behind the functionality expressed in the gpg executable - at least, it did at the time when I looked for a binding I could use. There also seems to be very little documentation about building from source on Windows - for example, the page https://www.gnupg.org/documentation/manuals/gpgme/ seems to have no reference to Windows whatsoever. 2. The gpgme functionality on Windows seems to revolve aroung gpg4win, which seems to be a UI-heavy package which (it appears) needs to be installed separately on Windows machines and is hard to integrate into other applications (especially for back-end, server applications where UI is not a consideration). On the other hand, deploying other applications with the gpg executable is trivially easy on Windows - just copy gpg.exe and a couple of i18n DLLs to a location on the path, and python-gnupg is operational. No need to worry about DLL versioning, different incompatible MS libc-level runtimes, etc. The bindings-to-C and wrapper-over-gpg models are both useful in different contexts, and should continue to co-exist as long as possible. Note that the python-gnupg name is also used by Debian and Fedora for their distro adaptations of my package, which of course then feeds through into a lot of derived distros such as Ubuntu, Mint and so on. Both OpenBSD and FreeBSD package my project as py-gnupg. Of course the python-gpgme name is also taken (by James Henstridge's package - I'm not sure how maintained that is, I couldn't see any releases more recent than 2012 and nothing in the source repository newer than 2013). However, it would make more sense to see if However, the wording suggested by Bernhard - "If you want GnuPG's quality for crypto from python, use its python module." glosses over the distinction, whereas "binding" makes it seem more closely associated with the C library. On a side note, it also seems to impute lower quality to other modules, which I'm not sure is entirely fair ;-) Regards, Vinay Sajip ----- Original Message ----- From: Daniel Kahn Gillmor To: Bernhard Reiter ; gnupg-devel at gnupg.org; Vinay Sajip Sent: Monday, 17 October 2016, 17:45 Subject: Re: begging for pyme name change [ adding Vinay Sajip to this e-mail thread, so he knows this is under discussion; Vinay, if you haven't been following this discussion about the various python/gnupg namespace issues, you can see the start of the discussion over at https://lists.gnupg.org/pipermail/gnupg-devel/2016-October/031810.html ] On Mon 2016-10-17 03:51:27 -0400, Bernhard Reiter wrote: > https://bitbucket.org/vinay.sajip/gnupg is not the official python GnuPG API > and "gnupg" is **our** namespace so to say. (Still any Free Software > contribution is nice, so it is cool that this module was written and > published. On the other hand, if we try to raise adoption for GnuPG, we all > have a strong interest that there is recognition about what is more or less > maintained.) IMO "python-gnupg" is the best name for this. I hear you, but let's be clear that Vinay Sajip was maintaining this wrapper long before the GnuPG upstream team decided to offer any sort of python functionality at all. I think the fact that upstream is now aiming to take responsibility for a python binding to GnuPG is great; but we can't ignore the fact that this other project was out there filling this need long before upstream was. And this other project has an existing userbase that would be good to reach out to, rather than to ignore. > If there are conflicts any distribution could solve them by version numbers > when in doubt. Maybe debian would use package names like > > python3-gnupg2 > python-gnupg2 > > To show that the there was an incompatible API change. > > My guiding principle is: what name would developers expect when looking > for the GnuPG API? right, and the lack of declared upstream support has left this vacuum where the existing multiplicity of projects are all (confusingly) available. It's not clear to me how to break this logjam, even if we manage to get all parties in agreement that there should be a single preferred pythonic interface to GnuPG. > The brand recognition is specifically highest about "gnupg" not "gpg". I have no idea whether this is true or not. How are you measuring it? > So the connection is: If you want GnuPG's quality for crypto from python, > use its python module. I agree that this phrasing is probably better than the term "binding", thanks. --dkg From vinay_sajip at yahoo.co.uk Tue Oct 18 00:01:17 2016 From: vinay_sajip at yahoo.co.uk (Vinay Sajip) Date: Mon, 17 Oct 2016 22:01:17 +0000 (UTC) Subject: begging for pyme name change In-Reply-To: <87eg3eix2f.fsf@alice.fifthhorseman.net> References: <87insx8404.fsf@servo.finestructure.net> <201610141100.26798.bernhard@intevation.de> <87mvi6rgza.fsf@alice.fifthhorseman.net> <201610170951.32070.bernhard@intevation.de> <87twcaorfc.fsf@alice.fifthhorseman.net> <377754233.3622270.1476729098157@mail.yahoo.com> <87eg3eix2f.fsf@alice.fifthhorseman.net> Message-ID: <69159268.3884558.1476741677105@mail.yahoo.com> Dear Daniel, >> The bindings-to-C and wrapper-over-gpg models are both useful in > ? i'm not sure i'd reach this conclusion in the abstract. I chose to adopt the wrapper approach because the other approach was just too hard to get working on Windows, and didn't offer all the functionality the executable did. Can we be sure that's no longer the case? Windows does seem a poor relation (for example, no separate builds of just gpgme.dll seem to be available, no support for compilation with Visual Studio toolchains, just gcc, and so on). > This is something for the upstream GnuPG team to wrestle with too -- how do we make it easy for people to use GnuPG in a reliable way from other programs? It hasn't been as easy as it should be. For me, it's always been about ease of use across POSIX and Windows. I don't believe an endorsement by the GnuPG team of any project as the "blessed" way of interacting will be enough to swing many users over from one project to another, unless ease of use is reasonably comparable. I even use gpg 1.x in preference to gpg 2.x in some contexts because gpg 2.1 makes it harder to avoid confusing-to-the-user pinentry popups without end-users having to tweak their GnuPG configuration (there might be some way I've missed, but Googling hasn't helped). It's certainly possible for GnuPG upstream changes to make it harder to use the wrapper approach (which is why I can't easily see a way to support 2.1 properly in all respects, much as I'd like to). > And, thanks for your ongoing work on python-gnupg You're very welcome. I think GnuPG is a great tool to have at our disposal, and I hope that its Python story keeps on improving. Regards, Vinay Sajip ----- Original Message ----- From: Daniel Kahn Gillmor To: Vinay Sajip ; Bernhard Reiter ; "gnupg-devel at gnupg.org" Sent: Monday, 17 October 2016, 20:40 Subject: Re: begging for pyme name change On Mon 2016-10-17 14:31:38 -0400, Vinay Sajip wrote: > It appears to be all about Python bindings to GPGME. However, my > project, python-gnupg, deliberately avoids binding to any C-level > library and instead provides a wrapper around the gpg executable. I agree with this, but? > The bindings-to-C and wrapper-over-gpg models are both useful in > different contexts, and should continue to co-exist as long as > possible. ? i'm not sure i'd reach this conclusion in the abstract. In particular, it'd be nice to see a single clear way to use gpg in python, so that people using python don't have to choose between one mechanism or another. what if they want functionality that's only available in one mechanism, and then they *also* want functionality that's only available in the other mechanism? Python is supposed to make those sorts of choices easy, and maintaining both approaches sounds troubling for the downstreams. This is something for the upstream GnuPG team to wrestle with too -- how do we make it easy for people to use GnuPG in a reliable way from other programs? It hasn't been as easy as it should be. > Of course the python-gpgme name is also taken (by James Henstridge's > package - I'm not sure how maintained that is, I couldn't see any > releases more recent than 2012 and nothing in the source repository > newer than 2013). However, it would make more sense to see if i think you were about to suggest asking him for that name -- i agree, and we've already reached out to him on a different branch of this discussion. Thanks for the suggestion! And, thanks for your ongoing work on python-gnupg. It's very much appreciated. --dkg From gniibe at fsij.org Tue Oct 18 01:52:46 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 18 Oct 2016 08:52:46 +0900 Subject: [PATCH] document how to manually shut down gpg-agent In-Reply-To: <87d1iyvqml.fsf@wheatstone.g10code.de> References: <20161014164224.31498-1-dkg@fifthhorseman.net> <87d1iyvqml.fsf@wheatstone.g10code.de> Message-ID: <9df2f5d7-ee2f-31b5-97ae-1ce328871b49@fsij.org> On 10/18/2016 02:20 AM, Werner Koch wrote: > FWIW, there is no need to write a ChangeLog entry for doc changes. While wating Emacs 25 in Debian, I had an opportunity to have a look at the Emacs repository: http://git.savannah.gnu.org/cgit/emacs.git/ Now, they use "; ...". That is, commit log message which start by semicolon for document changes. I think that it is handled by the script of build-aux/gitlog-to-emacslog. The method of "; ..." would be good for both for recording document change in the commit log and not recording in ChangeLog. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Tue Oct 18 06:49:47 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 18 Oct 2016 00:49:47 -0400 Subject: begging for pyme name change In-Reply-To: <69159268.3884558.1476741677105@mail.yahoo.com> References: <87insx8404.fsf@servo.finestructure.net> <201610141100.26798.bernhard@intevation.de> <87mvi6rgza.fsf@alice.fifthhorseman.net> <201610170951.32070.bernhard@intevation.de> <87twcaorfc.fsf@alice.fifthhorseman.net> <377754233.3622270.1476729098157@mail.yahoo.com> <87eg3eix2f.fsf@alice.fifthhorseman.net> <69159268.3884558.1476741677105@mail.yahoo.com> Message-ID: <87oa2igt1w.fsf@alice.fifthhorseman.net> Hi Vinay-- On Mon 2016-10-17 18:01:17 -0400, Vinay Sajip wrote: > I chose to adopt the wrapper approach because the other approach was > just too hard to get working on Windows, and didn't offer all the > functionality the executable did. Can we be sure that's no longer the > case? Windows does seem a poor relation (for example, no separate > builds of just gpgme.dll seem to be available, no support for > compilation with Visual Studio toolchains, just gcc, and so on). A few of these are great concrete requests. Have you tried asking for them explicitly? Opening a ticket at https://bugs.gnupg.org/gnupg requesting, for example, a separate and distributable windows build of gpgme.dll seems like it would be a good step. It's possible that no one on the GnuPG team actually has a visual studio toolchain available, though -- if you do have access and you can get it building, maybe you'd be up for contributing the appropriate VS .proj files (or whatever they're using these days? it's been years since i've used VS myself). > For me, it's always been about ease of use across POSIX and Windows. I > don't believe an endorsement by the GnuPG team of any project as the > "blessed" way of interacting will be enough to swing many users over > from one project to another, unless ease of use is reasonably > comparable. I agree with you that usability and a sensible and well-supported interface are what will win the day for developers. Official "blessing" on its own clearly isn't sufficient. What i'd really like to see is an "officially blessed" version that also offers a simple and sensible and well-supported interface, though :) > I even use gpg 1.x in preference to gpg 2.x in some contexts because > gpg 2.1 makes it harder to avoid confusing-to-the-user pinentry popups > without end-users having to tweak their GnuPG configuration (there > might be some way I've missed, but Googling hasn't helped). Googling might not be the best way to find answers to these problems. If you're struggling with them, please ask here on gnupg-devel, or open tickets at https://bugs.gnupg.org/gnupg so that the upstream GnuPG team knows what problems your having and has a chance to fix them for you. > It's certainly possible for GnuPG upstream changes to make it harder > to use the wrapper approach (which is why I can't easily see a way to > support 2.1 properly in all respects, much as I'd like to). Can you explain this in more detail? I'd really like to see python-gnupg support 2.1 better. I might be able to offer you some patches, too :) Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From bernhard at intevation.de Tue Oct 18 08:57:17 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 18 Oct 2016 08:57:17 +0200 Subject: proposal python-gnupg2 (was: begging for pyme name change) In-Reply-To: <87twcaorfc.fsf@alice.fifthhorseman.net> References: <87insx8404.fsf@servo.finestructure.net> <201610170951.32070.bernhard@intevation.de> <87twcaorfc.fsf@alice.fifthhorseman.net> Message-ID: <201610180857.21253.bernhard@intevation.de> Hi Daniel, Hi Vinay, Am Montag 17 Oktober 2016 18:45:27 schrieb Daniel Kahn Gillmor: > I hear you, but let's be clear that Vinay Sajip was maintaining this > wrapper long before the GnuPG upstream team decided to offer any sort of > python functionality at all. to me it is not a timing issue, but how to offer the best GnuPG usage experience (for developers). (Gpgme used to be around for a while by now.) > And this other project has an existing userbase that would be good > to reach out to, rather than to ignore. Yes, thanks for bringing Vinay into the discussion. And thank you Vinay for your contribution to Free Software and GnuPG! > It's not clear to me how to break this logjam, even if we > manage to get all parties in agreement that there should be a single > preferred pythonic interface to GnuPG. There may be different libraries in the future of course, but it would be helpful if we have one that is considered "standard". And if we can pool most of our efforts in improving this standard module to be well tested and offering all functionality. This is why I suggest using the most natural name. My suggestion to solve this is to use the new name with the major version number being increasted like "python-gnupg2". (Though it still helps to access GnuPG 1.4.x executables.) > > The brand recognition is specifically highest about "gnupg" not "gpg". > > I have no idea whether this is true or not. How are you measuring it? My observation over a couple of years. Feedback from people that get exposed to OpenPGP. I'll followup on this with an extra post. As for the perceived shortcomings of gpgme: I believe the goal our GnuPG-Initiative is to add all needed functionality to gpgme. It basically is a wrapper around calling gpg(.exe). Some features are less known other have been added but overall it is the best solution for most cases, see Andre's talk from https://openpgp-conf.org/program.html . 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 vinay_sajip at yahoo.co.uk Tue Oct 18 10:17:18 2016 From: vinay_sajip at yahoo.co.uk (Vinay Sajip) Date: Tue, 18 Oct 2016 08:17:18 +0000 (UTC) Subject: proposal python-gnupg2 (was: begging for pyme name change) In-Reply-To: <201610180857.21253.bernhard@intevation.de> References: <87insx8404.fsf@servo.finestructure.net> <201610170951.32070.bernhard@intevation.de> <87twcaorfc.fsf@alice.fifthhorseman.net> <201610180857.21253.bernhard@intevation.de> Message-ID: <1706609744.4270641.1476778638991@mail.yahoo.com> Dear Bernhard, > I believe the goal our GnuPG-Initiative is to add all needed functionality to gpgme. It basically is a wrapper around calling gpg(.exe). I had no idea that was the case, if I understand you correctly. I had assumed that gpgme was a lower-level library providing the basic crypto functionality, using common code used by gpg(.exe). If gpg(.exe) is the canonical foundation which everything else depends on, then where is the benefit of a Python binding over a C wrapper over gpg(.exe)? Python provides a reasonably good mechanism for interacting with subprocesses. I've probably misunderstood what you said, so please tell me if I have! Regards, Vinay Sajip ----- Original Message ----- From: Bernhard Reiter To: gnupg-devel at gnupg.org; Vinay Sajip Cc: Daniel Kahn Gillmor Sent: Tuesday, 18 October 2016, 7:57 Subject: proposal python-gnupg2 (was: begging for pyme name change) Hi Daniel, Hi Vinay, Am Montag 17 Oktober 2016 18:45:27 schrieb Daniel Kahn Gillmor: > I hear you, but let's be clear that Vinay Sajip was maintaining this > wrapper long before the GnuPG upstream team decided to offer any sort of > python functionality at all. to me it is not a timing issue, but how to offer the best GnuPG usage experience (for developers). (Gpgme used to be around for a while by now.) > And this other project has an existing userbase that would be good > to reach out to, rather than to ignore. Yes, thanks for bringing Vinay into the discussion. And thank you Vinay for your contribution to Free Software and GnuPG! > It's not clear to me how to break this logjam, even if we > manage to get all parties in agreement that there should be a single > preferred pythonic interface to GnuPG. There may be different libraries in the future of course, but it would be helpful if we have one that is considered "standard". And if we can pool most of our efforts in improving this standard module to be well tested and offering all functionality. This is why I suggest using the most natural name. My suggestion to solve this is to use the new name with the major version number being increasted like "python-gnupg2". (Though it still helps to access GnuPG 1.4.x executables.) > > The brand recognition is specifically highest about "gnupg" not "gpg". > > I have no idea whether this is true or not. How are you measuring it? My observation over a couple of years. Feedback from people that get exposed to OpenPGP. I'll followup on this with an extra post. As for the perceived shortcomings of gpgme: I believe the goal our GnuPG-Initiative is to add all needed functionality to gpgme. It basically is a wrapper around calling gpg(.exe). Some features are less known other have been added but overall it is the best solution for most cases, see Andre's talk from https://openpgp-conf.org/program.html . 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 From wk at gnupg.org Tue Oct 18 11:28:08 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 18 Oct 2016 11:28:08 +0200 Subject: proposal python-gnupg2 In-Reply-To: <201610180857.21253.bernhard@intevation.de> (Bernhard Reiter's message of "Tue, 18 Oct 2016 08:57:17 +0200") References: <87insx8404.fsf@servo.finestructure.net> <201610170951.32070.bernhard@intevation.de> <87twcaorfc.fsf@alice.fifthhorseman.net> <201610180857.21253.bernhard@intevation.de> Message-ID: <87d1iyt39z.fsf@wheatstone.g10code.de> On Tue, 18 Oct 2016 08:57, bernhard at intevation.de said: > As for the perceived shortcomings of gpgme: I believe the goal our > GnuPG-Initiative is to add all needed functionality to gpgme. It basically ^^^^^^^^^^^^^^^^ For the records: The name of the thing is "The GnuPG Project". > is a wrapper around calling gpg(.exe). Some features are less known GPGME is not a wrapper around gpg but a generic API for end to end crypto protocols. How they are implemented in the backends (src/engine-*.c) is an implementation details and orthogonal to the API. And no, not all features of gpg will be supported by GPGME. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From wk at gnupg.org Tue Oct 18 11:40:28 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 18 Oct 2016 11:40:28 +0200 Subject: begging for pyme name change In-Reply-To: <87oa2igt1w.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 18 Oct 2016 00:49:47 -0400") References: <87insx8404.fsf@servo.finestructure.net> <201610141100.26798.bernhard@intevation.de> <87mvi6rgza.fsf@alice.fifthhorseman.net> <201610170951.32070.bernhard@intevation.de> <87twcaorfc.fsf@alice.fifthhorseman.net> <377754233.3622270.1476729098157@mail.yahoo.com> <87eg3eix2f.fsf@alice.fifthhorseman.net> <69159268.3884558.1476741677105@mail.yahoo.com> <87oa2igt1w.fsf@alice.fifthhorseman.net> Message-ID: <878ttmt2pf.fsf@wheatstone.g10code.de> On Tue, 18 Oct 2016 06:49, dkg at fifthhorseman.net said: > A few of these are great concrete requests. Have you tried asking for > them explicitly? Opening a ticket at https://bugs.gnupg.org/gnupg > requesting, for example, a separate and distributable windows build of > gpgme.dll seems like it would be a good step. It has bee re-iterated a hundred times over the last decade: We support only cross-building from POSIX systems. This software is about freedom and thus we try hard to avoid any proprietary stuff. However, it is all free software and anyone can go and build it with Microsoft stuff or whatever - but they should not expect that we will be willing to help with such a task. The GnuPG 2.1 installer for Windows comes with the latest GPGME DLL along with header and import files. > files (or whatever they're using these days? it's been years since i've > used VS myself). Same here. We once bought a Visual Studio thing during the port of GnuPG to Windows CE 3 - it was however only used in a prototype system due to problems with other software, namely out KMail port. The availabale gcc worked fine for GnuPG itself. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From vinay_sajip at yahoo.co.uk Tue Oct 18 12:54:52 2016 From: vinay_sajip at yahoo.co.uk (Vinay Sajip) Date: Tue, 18 Oct 2016 10:54:52 +0000 (UTC) Subject: begging for pyme name change In-Reply-To: <87oa2igt1w.fsf@alice.fifthhorseman.net> References: <87insx8404.fsf@servo.finestructure.net> <201610141100.26798.bernhard@intevation.de> <87mvi6rgza.fsf@alice.fifthhorseman.net> <201610170951.32070.bernhard@intevation.de> <87twcaorfc.fsf@alice.fifthhorseman.net> <377754233.3622270.1476729098157@mail.yahoo.com> <87eg3eix2f.fsf@alice.fifthhorseman.net> <69159268.3884558.1476741677105@mail.yahoo.com> <87oa2igt1w.fsf@alice.fifthhorseman.net> Message-ID: <1277703368.4576640.1476788092970@mail.yahoo.com> Dear Daniel, > A few of these are great concrete requests. Have you tried asking for > them explicitly? Opening a ticket at https://bugs.gnupg.org/gnupg No, because I believe the reason for Windows being a second class citizen is "political" (if I can put it that way) rather than technical. I think Werner's just confirmed this in another post. >> It's certainly possible for GnuPG upstream changes to make it harder >> to use the wrapper approach (which is why I can't easily see a way to >> support 2.1 properly in all respects, much as I'd like to). > Can you explain this in more detail? I'd really like to see > python-gnupg support 2.1 better. I might be able to offer you some > patches, too :) Example: I have a Ubuntu machine (16.04 LTS) with gpg 1.4.20 and gpg 2.1.11 installed. If I run the tests for the python-gnupg project, using python test_gnupg.py I get no passphrase prompts and all the tests pass. If, however, I run GPGBINARY=gpg2 python test_gnupg.py I get not one, but two different passphrase prompts, as per these images: http://imgur.com/a/LniHI There seems to be no way to get gpg2 to accept passphrases on fd 0 via a command-line argument. An example command line invoked from the test suite is gpg2 --status-fd 2 --no-tty --homedir /home/vinay/projects/python-gnupg/keys --batch --passphrase-fd 0 --debug-quick-random --decrypt On GPG earlier than 2.1, this causes no pinentry prompt to be shown. On 2.1, a prompt is shown. It may be possible to change this using some configuration changes in ~/.gnupg, but if GPG functionality is embedded in some other application (the use case for python-gnupg), we can't (a) change the user's configuration ourselves or (b) expect users to change their configuration, as they may not even be familiar with GnuPG themselves. Quite apart from this, GPG2.1 changed the --with-fingerprint --with-colons listing format. Here's what a line looks like with 1.4: pub:-:2048:1:CAD0AE184C7798F2:2014-07-27:::-:Andrew Able (A test user) : and with 2.1: pub:-:2048:1:CAD0AE184C7798F2:1406461871:::-: The number of elements has gone down by one - it's not clear why, since according to the documentation in both 1.4 and 2.1 (the doc/DETAILS), the user id ("Andrew Able") is in the expected place in 1.4, but just not present in 2.1. I vaguely remember Werner suggesting that this was a bug in 1.4, but as the 1.4 behaviour conforms to the 1.4 documentation, it looks like a backwards-incompatible change to me. Note also how the expired date field format has changed from "2014-07-27" in 1.4 to "1406461871" in 2.1 (the value is the same, just presented differently). Regards, Vinay Sajip From gniibe at fsij.org Tue Oct 18 16:11:14 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 18 Oct 2016 23:11:14 +0900 Subject: [PATCH] scd: Generation of ECC keys on-board (OpenPGP card 3) In-Reply-To: <5800C59B.2020305@ssi.gouv.fr> References: <5800C59B.2020305@ssi.gouv.fr> Message-ID: <1261eb8c-d779-b34a-7d60-d17c964058c7@fsij.org> On 10/14/2016 08:46 PM, Arnaud Fontaine wrote: > * scd/app-openpgp.c: Support for on-board generation of ECC keys > introduced in OpenPGP card specification 3.0. Thank you for your patch. The patch is malformed somehow. Perhaps, your MUA or MTA wrapped some lines. Anyway, I think that I understand your changes. I modified the protocol of KEY-DATA to gpg-agent. It is not limited to a single character, so, "curve" and "kdf" are better. I also modified for support of EdDSA and Curve25519 (the prefix 0x40 and PUBKEY_ALGO_EDDSA). Then, commit is pushed to master. -- From uri at mit.edu Tue Oct 18 17:04:25 2016 From: uri at mit.edu (Uri Blumenthal) Date: Tue, 18 Oct 2016 15:04:25 +0000 Subject: begging for pyme name change In-Reply-To: <87twcaorfc.fsf@alice.fifthhorseman.net> References: <87insx8404.fsf@servo.finestructure.net> <201610141100.26798.bernhard@intevation.de> <87mvi6rgza.fsf@alice.fifthhorseman.net> <201610170951.32070.bernhard@intevation.de>, <87twcaorfc.fsf@alice.fifthhorseman.net> Message-ID: One quick point: as far as I know, the highest "brand recognition" today is gpg, probably followed by PGP (at least among those who remember :)), gnupg being a distant third. And I've been with PGP development since its inception. Sent from my iPad > On Oct 17, 2016, at 12:47, Daniel Kahn Gillmor wrote: > > [ adding Vinay Sajip to this e-mail thread, so he knows this is under > discussion; Vinay, if you haven't been following this discussion about > the various python/gnupg namespace issues, you can see the start of > the discussion over at > https://lists.gnupg.org/pipermail/gnupg-devel/2016-October/031810.html ] > >> On Mon 2016-10-17 03:51:27 -0400, Bernhard Reiter wrote: >> https://bitbucket.org/vinay.sajip/gnupg is not the official python GnuPG API >> and "gnupg" is **our** namespace so to say. (Still any Free Software >> contribution is nice, so it is cool that this module was written and >> published. On the other hand, if we try to raise adoption for GnuPG, we all >> have a strong interest that there is recognition about what is more or less >> maintained.) IMO "python-gnupg" is the best name for this. > > I hear you, but let's be clear that Vinay Sajip was maintaining this > wrapper long before the GnuPG upstream team decided to offer any sort of > python functionality at all. > > I think the fact that upstream is now aiming to take responsibility for > a python binding to GnuPG is great; but we can't ignore the fact that > this other project was out there filling this need long before upstream > was. And this other project has an existing userbase that would be good > to reach out to, rather than to ignore. > >> If there are conflicts any distribution could solve them by version numbers >> when in doubt. Maybe debian would use package names like >> >> python3-gnupg2 >> python-gnupg2 >> >> To show that the there was an incompatible API change. >> >> My guiding principle is: what name would developers expect when looking >> for the GnuPG API? > > right, and the lack of declared upstream support has left this vacuum > where the existing multiplicity of projects are all (confusingly) > available. It's not clear to me how to break this logjam, even if we > manage to get all parties in agreement that there should be a single > preferred pythonic interface to GnuPG. > >> The brand recognition is specifically highest about "gnupg" not "gpg". > > I have no idea whether this is true or not. How are you measuring it? > >> So the connection is: If you want GnuPG's quality for crypto from python, >> use its python module. > > I agree that this phrasing is probably better than the term "binding", > thanks. > > --dkg > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From wk at gnupg.org Tue Oct 18 19:19:17 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 18 Oct 2016 19:19:17 +0200 Subject: begging for pyme name change In-Reply-To: <1277703368.4576640.1476788092970@mail.yahoo.com> (Vinay Sajip's message of "Tue, 18 Oct 2016 10:54:52 +0000 (UTC)") References: <87insx8404.fsf@servo.finestructure.net> <201610141100.26798.bernhard@intevation.de> <87mvi6rgza.fsf@alice.fifthhorseman.net> <201610170951.32070.bernhard@intevation.de> <87twcaorfc.fsf@alice.fifthhorseman.net> <377754233.3622270.1476729098157@mail.yahoo.com> <87eg3eix2f.fsf@alice.fifthhorseman.net> <69159268.3884558.1476741677105@mail.yahoo.com> <87oa2igt1w.fsf@alice.fifthhorseman.net> <1277703368.4576640.1476788092970@mail.yahoo.com> Message-ID: <87wph5r2wa.fsf@wheatstone.g10code.de> On Tue, 18 Oct 2016 12:54, vinay_sajip at yahoo.co.uk said: > No, because I believe the reason for Windows being a second class > citizen is "political" (if I can put it that way) rather than Windows is not a second class citizen. I am pretty sure that more gpg encrypted mails are sent from Windows hosts than from any other OS. And yes, it is political: We fully support Windows because a( privacy is important and b) we want to make it easier to eventually switch over to a free and and less prone to backdoors platform for all users > technical. I think Werner's just confirmed this in another post. Nope. > Quite apart from this, GPG2.1 changed the --with-fingerprint --with-colons listing format. Here's what a line looks like with 1.4: > > pub:-:2048:1:CAD0AE184C7798F2:2014-07-27:::-:Andrew Able (A test user) : That was actually changed with 2.0.10 in 2009: * [gpg] The option --fixed-list-mode is now implicitly used and obsolete. The --fixed-list-mode option was introduced with 1.0.5 in 2001 to fix a bug in the colon listing. If has ever since then been suggested for all users. Without that option you are simply not able to correctly get all information. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From vinay_sajip at yahoo.co.uk Tue Oct 18 21:02:02 2016 From: vinay_sajip at yahoo.co.uk (Vinay Sajip) Date: Tue, 18 Oct 2016 19:02:02 +0000 (UTC) Subject: begging for pyme name change In-Reply-To: <87wph5r2wa.fsf@wheatstone.g10code.de> References: <87insx8404.fsf@servo.finestructure.net> <201610141100.26798.bernhard@intevation.de> <87mvi6rgza.fsf@alice.fifthhorseman.net> <201610170951.32070.bernhard@intevation.de> <87twcaorfc.fsf@alice.fifthhorseman.net> <377754233.3622270.1476729098157@mail.yahoo.com> <87eg3eix2f.fsf@alice.fifthhorseman.net> <69159268.3884558.1476741677105@mail.yahoo.com> <87oa2igt1w.fsf@alice.fifthhorseman.net> <1277703368.4576640.1476788092970@mail.yahoo.com> <87wph5r2wa.fsf@wheatstone.g10code.de> Message-ID: <156942657.5549888.1476817322061@mail.yahoo.com> Dear Werner, > Windows is not a second class citizen. I am pretty sure that more gpg > encrypted mails are sent from Windows hosts than from any other OS. I meant from the toolchain point of view. Unfortunately, many users expect to use Microsoft toolchains for Windows and not mingw or other free options. > And yes, it is political: We fully support Windows because a( privacy is > important and b) we want to make it easier to eventually switch over to > a free and and less prone to backdoors platform for all users Amen to that. >> technical. > Nope. It's not technically impossible (AFAIK) to have libgpgme built using a Microsoft toolchain, is what I meant. There might be problems linking a libgpgme built using gcc with other software built using MSVC. I make no value judgements about the qualities of either toolchain - it's just that some customers expect to use the MS toolchain for their applications, and using a gcc-built libgpgme there might be problematic. Of course, wrapping gpg.exe avoids these issues altogether. Another thing you said was that "not all features of gpg will be supported by GPGME". If that is the case, it seems to mean that wrapping over gpg.exe will be needed to get access to all features of GnuPG, or have I misunderstood? > That was actually changed with 2.0.10 in 2009 Ah - my mistake. I hadn't realised this, thanks for making it clear. Regards, Vinay Sajip From neal at walfield.org Tue Oct 18 22:13:00 2016 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 18 Oct 2016 16:13:00 -0400 Subject: begging for pyme name change In-Reply-To: <878ttmt2pf.fsf@wheatstone.g10code.de> References: <87insx8404.fsf@servo.finestructure.net> <201610141100.26798.bernhard@intevation.de> <87mvi6rgza.fsf@alice.fifthhorseman.net> <201610170951.32070.bernhard@intevation.de> <87twcaorfc.fsf@alice.fifthhorseman.net> <377754233.3622270.1476729098157@mail.yahoo.com> <87eg3eix2f.fsf@alice.fifthhorseman.net> <69159268.3884558.1476741677105@mail.yahoo.com> <87oa2igt1w.fsf@alice.fifthhorseman.net> <878ttmt2pf.fsf@wheatstone.g10code.de> Message-ID: <877f954drn.wl-neal@walfield.org> Hi, At Tue, 18 Oct 2016 11:40:28 +0200, Werner Koch wrote: > On Tue, 18 Oct 2016 06:49, dkg at fifthhorseman.net said: > > > A few of these are great concrete requests. Have you tried asking for > > them explicitly? Opening a ticket at https://bugs.gnupg.org/gnupg > > requesting, for example, a separate and distributable windows build of > > gpgme.dll seems like it would be a good step. > > It has bee re-iterated a hundred times over the last decade: We support > only cross-building from POSIX systems. This software is about freedom > and thus we try hard to avoid any proprietary stuff. However, it is all > free software and anyone can go and build it with Microsoft stuff or > whatever - but they should not expect that we will be willing to help > with such a task. > > The GnuPG 2.1 installer for Windows comes with the latest GPGME DLL > along with header and import files. > > > files (or whatever they're using these days? it's been years since i've > > used VS myself). > > Same here. We once bought a Visual Studio thing during the port of > GnuPG to Windows CE 3 - it was however only used in a prototype system > due to problems with other software, namely out KMail port. The > availabale gcc worked fine for GnuPG itself. Visual Studio is a small customization of Visual Code, which is free software (it has been available under the MIT license for the past few years) [1,2]. :) Neal [1] https://code.visualstudio.com/docs/supporting/faq#_licensing [2] https://github.com/Microsoft/vscode/issues/60#issuecomment-161792005 From rjh at sixdemonbag.org Tue Oct 18 21:19:02 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 18 Oct 2016 15:19:02 -0400 Subject: begging for pyme name change In-Reply-To: <156942657.5549888.1476817322061@mail.yahoo.com> References: <87insx8404.fsf@servo.finestructure.net> <201610141100.26798.bernhard@intevation.de> <87mvi6rgza.fsf@alice.fifthhorseman.net> <201610170951.32070.bernhard@intevation.de> <87twcaorfc.fsf@alice.fifthhorseman.net> <377754233.3622270.1476729098157@mail.yahoo.com> <87eg3eix2f.fsf@alice.fifthhorseman.net> <69159268.3884558.1476741677105@mail.yahoo.com> <87oa2igt1w.fsf@alice.fifthhorseman.net> <1277703368.4576640.1476788092970@mail.yahoo.com> <87wph5r2wa.fsf@wheatstone.g10code.de> <156942657.5549888.1476817322061@mail.yahoo.com> Message-ID: <047c01d22974$7d47d350$77d779f0$@sixdemonbag.org> > There might be problems linking a > libgpgme built using gcc with other software built using MSVC. There shouldn't be. The Microsoft C ABI is well-known and GCC targets it well. See, e.g., http://www.mingw.org/wiki/msvc_and_mingw_dlls . > I make no > value judgements about the qualities of either toolchain - it's just that some > customers expect to use the MS toolchain for their applications, and using a > gcc-built libgpgme there might be problematic. The same can be said about clang and icc. In my (limited) experience, I've been able to make all four of them interoperate nicely when targeting C. From alon.barlev at gmail.com Wed Oct 19 08:03:28 2016 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Wed, 19 Oct 2016 09:03:28 +0300 Subject: [PATCH] gpg, gpgsm, python: atomic directory creation Message-ID: <1476857008-20102-1-git-send-email-alon.barlev@gmail.com> * lang/python/tests/Makefile.am, tests/gpg/Makefile.am, tests/gpgsm/Makefile.am: atomic directory creation. Signed-off-by: Alon Bar-Lev --- lang/python/tests/Makefile.am | 2 +- tests/gpg/Makefile.am | 2 +- tests/gpgsm/Makefile.am | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/lang/python/tests/Makefile.am b/lang/python/tests/Makefile.am index aa88bdc..39f532c 100644 --- a/lang/python/tests/Makefile.am +++ b/lang/python/tests/Makefile.am @@ -89,7 +89,7 @@ clean-local: ./private-keys-v1.d/gpg-sample.stamp: $(private_keys) - test -d ./private-keys-v1.d || mkdir ./private-keys-v1.d + $(MKDIR_P) ./private-keys-v1.d for k in $(private_keys); do \ cp $$k private-keys-v1.d/$${k#$(test_srcdir)/}.key; \ done diff --git a/tests/gpg/Makefile.am b/tests/gpg/Makefile.am index 2538f63..044bf3a 100644 --- a/tests/gpg/Makefile.am +++ b/tests/gpg/Makefile.am @@ -90,7 +90,7 @@ export GNUPGHOME := $(abs_builddir) export GPG_AGENT_INFO := ./private-keys-v1.d/gpg-sample.stamp: $(srcdir)/$(private_keys) - test -d ./private-keys-v1.d || mkdir ./private-keys-v1.d + $(MKDIR_P) ./private-keys-v1.d for k in $(private_keys); do \ cp $(srcdir)/$$k private-keys-v1.d/$$k.key; \ done diff --git a/tests/gpgsm/Makefile.am b/tests/gpgsm/Makefile.am index 41645b6..46d6a9b 100644 --- a/tests/gpgsm/Makefile.am +++ b/tests/gpgsm/Makefile.am @@ -70,7 +70,7 @@ export GPG_AGENT_INFO := echo faked-system-time 1008241200 >> ./gpgsm.conf ./private-keys-v1.d/$(key_id).key: $(srcdir)/$(key_id) - test -d ./private-keys-v1.d || mkdir ./private-keys-v1.d + $(MKDIR_P) ./private-keys-v1.d cp $(srcdir)/$(key_id) private-keys-v1.d/$(key_id).key ./trustlist.txt: -- 2.7.3 From alon.barlev at gmail.com Wed Oct 19 08:05:07 2016 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Wed, 19 Oct 2016 09:05:07 +0300 Subject: [PATCH] gpg, gpgsm, python: atomic directory creation In-Reply-To: <1476857008-20102-1-git-send-email-alon.barlev@gmail.com> References: <1476857008-20102-1-git-send-email-alon.barlev@gmail.com> Message-ID: Hi, This may fix parallel build issues in which mkdir fails as directory already exist. Thanks! Alon From bernhard at intevation.de Wed Oct 19 08:31:21 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 19 Oct 2016 08:31:21 +0200 Subject: gpgme as an GnuPG-API (API and windows support) (Was: begging for pyme name change) In-Reply-To: <156942657.5549888.1476817322061@mail.yahoo.com> References: <87insx8404.fsf@servo.finestructure.net> <87wph5r2wa.fsf@wheatstone.g10code.de> <156942657.5549888.1476817322061@mail.yahoo.com> Message-ID: <201610190831.25342.bernhard@intevation.de> Moin, Am Dienstag 18 Oktober 2016 21:02:02 schrieb Vinay Sajip: > many users expect to use Microsoft toolchains for Windows and not mingw or > other free options. I'd say that they expect that their toolchain is supported by the API. Which is what gpgme on windows aims for (in my understanding). It is of minor importance how gpgme itself is build. Because it is a cross plattform API, folks helping with its maintenance will need to learn about cross plattform pecularities anyway. > It's not technically impossible (AFAIK) to have libgpgme built using a > Microsoft toolchain, is what I meant. In my experience, Werner's main concerns are long term maintainabiliy. For the last ten years this mean that he personally will have to be able to do the maintenance if nobody else wants to. As a single person his preferance of a development environment that gets things done thus have a strong influence. If you could convince him that there is a long term maintainability in supporting a different build environment and there is a legitimate use case for it, it may be possible. However that is difficult for the reasons outlined. > Of course, wrapping gpg.exe avoids these issues altogether. But gets you other robustness and maintenance problems. With gpgme you are getting a much more stable API for future changes. > Another thing you said was that "not all features of gpg will be supported > by GPGME". If that is the case, it seems to mean that wrapping over gpg.exe > will be needed to get access to all features of GnuPG, or have I > misunderstood? My reading is: There is no promise for 100% coverage. Which actually is a good thing. It guards against: "Hey, I found one thing I can do with gpg2.exe I cannot do with gpgme, this must be a bug!" There are some deprecated, largely unused or debugging only features in gpg2 that nobody really needs in an API. On the other hand: If there is are legitimate use case for a GnuPG-API, it makes sense to extend gpgme. This has been done many times in the past and will continue. Once we learn about what GnuPG-API users really need, there is a clear aim to support this with at least one good way. 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 bernhard at intevation.de Wed Oct 19 08:43:18 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 19 Oct 2016 08:43:18 +0200 Subject: GnuPG API, gpgme (was: proposal python-gnupg2) In-Reply-To: <1706609744.4270641.1476778638991@mail.yahoo.com> References: <87insx8404.fsf@servo.finestructure.net> <201610180857.21253.bernhard@intevation.de> <1706609744.4270641.1476778638991@mail.yahoo.com> Message-ID: <201610190843.19034.bernhard@intevation.de> Hi Vinay, Am Dienstag 18 Oktober 2016 10:17:18 schrieb Vinay Sajip: > > I believe the goal our GnuPG-Initiative is to add all needed > > functionality to gpgme. It basically is a wrapper around calling > > gpg(.exe). > > I had no idea that was the case, if I understand you correctly. I had > assumed that gpgme was a lower-level library providing the basic crypto > functionality, using common code used by gpg(.exe). If gpg(.exe) is the > canonical foundation which everything else depends on, then where is the > benefit of a Python binding over a C wrapper over gpg(.exe)? Python > provides a reasonably good mechanism for interacting with subprocesses. > I've probably misunderstood what you said, so please tell me if I have! as also outlined in my other email (which I've send to you and the list a few minutes ago): In my understanding gpgme aims to be a good GnuPG API in a sense that it will have advantages over calling gpg2(.exe) in all cases. (There may be rare exceptions.) See the (a brief list) of advantages of gpgme in Andre's slides for his openpgp.conf talk (https://files.intevation.de/users/aheinecke/gpgme.pdf ) The disadvantages there reduced by completions and higher level funcations in the "official" version for languages like python. 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 bernhard at intevation.de Wed Oct 19 09:14:22 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 19 Oct 2016 09:14:22 +0200 Subject: the "brand" GnuPG, (was: proposal python-gnupg2) In-Reply-To: <201610180857.21253.bernhard@intevation.de> References: <87insx8404.fsf@servo.finestructure.net> <87twcaorfc.fsf@alice.fifthhorseman.net> <201610180857.21253.bernhard@intevation.de> Message-ID: <201610190914.26159.bernhard@intevation.de> Hi, what is (or should be) our "brand" (name): Wikipedia writes "Brand is a name, sign, symbol, slogan or anything that is used to identify and distinguish a specific product, service, or business." [1] So what is a good brand name for the "The GnuPG Project"? The naming principles recorded in wikipedia [2] are too profit-oriented for my taste, let me pick some product name qualities that apply to us: * They strategically distinguish the product from its competitors [..] * They hold appeal for the product?s target audience Am Dienstag 18 Oktober 2016 08:57:17 schrieb Bernhard Reiter: > > > The brand recognition is specifically highest about "gnupg" not "gpg". > > > > I have no idea whether this is true or not. ?How are you measuring it? > > My observation over a couple of years. Feedback from people that get > exposed to OpenPGP. The problem I've notived with the name "OpenPGP" is its length. It is a five syllable word. Nobody seems to type or say "OpenPGP" with joy because of its length and difficulty of prounciation (in English). People will mostly fall back to "PGP". GPG and PGP are too close to each other to offer a sufficient distinction. While GPG seems to have overtaken PGP in world-wide usage by far, people still mix it up. When reading articles in the general press, it is often mixed up. "GnuPG" scores better on the appeal (for usage) because it is shorter to write and easier to say. "GnuPG can be remembered better and is more different to the competing proprietary product "PGP" and the similiar named standard. Am Dienstag 18 Oktober 2016 17:04:25 schrieb Uri Blumenthal: > One quick point: as far as I know, the highest "brand recognition" today is > gpg, probably followed by PGP (at least among those who remember :)), gnupg > being a distant third. > > And I've been with PGP development since its inception. Uri, thanks for your observation! Given that you are long time crypto expert, you may belong to a group which is skilled in making a distinction between pgp and gpg. People farer away from the topic are less able to. My goal is to let many more people get the benefits of "The GnuPG Project" and so far "GnuPG" seems the name best suited for doing so. Best Regards, Bernhard [1] https://en.wikipedia.org/wiki/Brand_%28disambiguation%29 [2] https://en.wikipedia.org/wiki/Product_naming#Principles -- 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 Oct 19 09:22:03 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 19 Oct 2016 09:22:03 +0200 Subject: proposal python-gnupg2 In-Reply-To: <201610180857.21253.bernhard@intevation.de> References: <87insx8404.fsf@servo.finestructure.net> <87twcaorfc.fsf@alice.fifthhorseman.net> <201610180857.21253.bernhard@intevation.de> Message-ID: <201610190922.04005.bernhard@intevation.de> Am Dienstag 18 Oktober 2016 08:57:17 schrieb Bernhard Reiter: > There may be different libraries in the future of course, but it would be > helpful if we have one that is considered "standard". And if we can pool > most of our efforts in improving this standard module to be well tested > and offering all functionality. This is why I suggest using the most > natural name. My suggestion to solve this is to use the new name with the > major version number being increased like "python-gnupg2". > (Though it still helps to access GnuPG 1.4.x executables.) Even if we would go with "python-gpgme", we would need to do add a major version number to it like "python-gpgme2" and "python3-gpgme2", because of the different API. 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 Oct 19 10:53:58 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 19 Oct 2016 10:53:58 +0200 Subject: [PATCH] gpg, gpgsm, python: atomic directory creation In-Reply-To: (Alon Bar-Lev's message of "Wed, 19 Oct 2016 09:05:07 +0300") References: <1476857008-20102-1-git-send-email-alon.barlev@gmail.com> Message-ID: <87a8e0pvmh.fsf@wheatstone.g10code.de> On Wed, 19 Oct 2016 08:05, alon.barlev at gmail.com said: > This may fix parallel build issues in which mkdir fails as directory > already exist. Can you please add this comment to your patch (after a "--" line). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From wk at gnupg.org Wed Oct 19 10:59:31 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 19 Oct 2016 10:59:31 +0200 Subject: begging for pyme name change In-Reply-To: <156942657.5549888.1476817322061@mail.yahoo.com> (Vinay Sajip's message of "Tue, 18 Oct 2016 19:02:02 +0000 (UTC)") References: <87insx8404.fsf@servo.finestructure.net> <201610141100.26798.bernhard@intevation.de> <87mvi6rgza.fsf@alice.fifthhorseman.net> <201610170951.32070.bernhard@intevation.de> <87twcaorfc.fsf@alice.fifthhorseman.net> <377754233.3622270.1476729098157@mail.yahoo.com> <87eg3eix2f.fsf@alice.fifthhorseman.net> <69159268.3884558.1476741677105@mail.yahoo.com> <87oa2igt1w.fsf@alice.fifthhorseman.net> <1277703368.4576640.1476788092970@mail.yahoo.com> <87wph5r2wa.fsf@wheatstone.g10code.de> <156942657.5549888.1476817322061@mail.yahoo.com> Message-ID: <8760oopvd8.fsf@wheatstone.g10code.de> On Tue, 18 Oct 2016 21:02, vinay_sajip at yahoo.co.uk said: > It's not technically impossible (AFAIK) to have libgpgme built using a > Microsoft toolchain, is what I meant. There might be problems linking Right, but we don't support it due to maintenance issues. > it's just that some customers expect to use the MS toolchain for their > applications, and using a gcc-built libgpgme there might be > problematic. We use that very gpgme with Outlook without problems. The only minor thing you need to do is to use gpgme_free() instead of free() where gpgme returns malloced memory. The manual describes this. The reason for this peculiarity is that gpgme may use a different libc version than the caller. > Another thing you said was that "not all features of gpg will be supported by GPGME". If that is the case, it seems to mean that wrapping over gpg.exe will be needed to get access to all features of GnuPG, or have I misunderstood? If you have a valid and too esoteric use case for a certain feature, we can put this into GPGME. gpg has nearly 400 command line options and many sub options - supporting them all in a generic e2e encryption API does not make sense. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From alon.barlev at gmail.com Wed Oct 19 11:04:07 2016 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Wed, 19 Oct 2016 12:04:07 +0300 Subject: [PATCH] gpg, gpgsm, python: atomic directory creation In-Reply-To: <87a8e0pvmh.fsf@wheatstone.g10code.de> References: <87a8e0pvmh.fsf@wheatstone.g10code.de> Message-ID: <1476867847-24352-1-git-send-email-alon.barlev@gmail.com> * lang/python/tests/Makefile.am, tests/gpg/Makefile.am, tests/gpgsm/Makefile.am: atomic directory creation. -- Solves race in parallel build when mkdir fails if directory exists. Signed-off-by: Alon Bar-Lev --- lang/python/tests/Makefile.am | 2 +- tests/gpg/Makefile.am | 2 +- tests/gpgsm/Makefile.am | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/lang/python/tests/Makefile.am b/lang/python/tests/Makefile.am index aa88bdc..39f532c 100644 --- a/lang/python/tests/Makefile.am +++ b/lang/python/tests/Makefile.am @@ -89,7 +89,7 @@ clean-local: ./private-keys-v1.d/gpg-sample.stamp: $(private_keys) - test -d ./private-keys-v1.d || mkdir ./private-keys-v1.d + $(MKDIR_P) ./private-keys-v1.d for k in $(private_keys); do \ cp $$k private-keys-v1.d/$${k#$(test_srcdir)/}.key; \ done diff --git a/tests/gpg/Makefile.am b/tests/gpg/Makefile.am index 2538f63..044bf3a 100644 --- a/tests/gpg/Makefile.am +++ b/tests/gpg/Makefile.am @@ -90,7 +90,7 @@ export GNUPGHOME := $(abs_builddir) export GPG_AGENT_INFO := ./private-keys-v1.d/gpg-sample.stamp: $(srcdir)/$(private_keys) - test -d ./private-keys-v1.d || mkdir ./private-keys-v1.d + $(MKDIR_P) ./private-keys-v1.d for k in $(private_keys); do \ cp $(srcdir)/$$k private-keys-v1.d/$$k.key; \ done diff --git a/tests/gpgsm/Makefile.am b/tests/gpgsm/Makefile.am index 41645b6..46d6a9b 100644 --- a/tests/gpgsm/Makefile.am +++ b/tests/gpgsm/Makefile.am @@ -70,7 +70,7 @@ export GPG_AGENT_INFO := echo faked-system-time 1008241200 >> ./gpgsm.conf ./private-keys-v1.d/$(key_id).key: $(srcdir)/$(key_id) - test -d ./private-keys-v1.d || mkdir ./private-keys-v1.d + $(MKDIR_P) ./private-keys-v1.d cp $(srcdir)/$(key_id) private-keys-v1.d/$(key_id).key ./trustlist.txt: -- 2.7.3 From wk at gnupg.org Wed Oct 19 11:07:22 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 19 Oct 2016 11:07:22 +0200 Subject: begging for pyme name change In-Reply-To: <877f954drn.wl-neal@walfield.org> (Neal H. Walfield's message of "Tue, 18 Oct 2016 16:13:00 -0400") References: <87insx8404.fsf@servo.finestructure.net> <201610141100.26798.bernhard@intevation.de> <87mvi6rgza.fsf@alice.fifthhorseman.net> <201610170951.32070.bernhard@intevation.de> <87twcaorfc.fsf@alice.fifthhorseman.net> <377754233.3622270.1476729098157@mail.yahoo.com> <87eg3eix2f.fsf@alice.fifthhorseman.net> <69159268.3884558.1476741677105@mail.yahoo.com> <87oa2igt1w.fsf@alice.fifthhorseman.net> <878ttmt2pf.fsf@wheatstone.g10code.de> <877f954drn.wl-neal@walfield.org> Message-ID: <87y41kogfp.fsf@wheatstone.g10code.de> On Tue, 18 Oct 2016 22:13, neal at walfield.org said: > Visual Studio is a small customization of Visual Code, which is free > software (it has been available under the MIT license for the past few > years) [1,2]. I can't see the this include the core part of Visual Studio, which is a the C compiler. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From justus at g10code.com Wed Oct 19 12:20:44 2016 From: justus at g10code.com (Justus Winter) Date: Wed, 19 Oct 2016 12:20:44 +0200 Subject: [PATCH libgpg-error 4/4] estream: Support 'es_poll' on Windows. In-Reply-To: <20161019102044.6469-1-justus@g10code.com> References: <20161019102044.6469-1-justus@g10code.com> Message-ID: <20161019102044.6469-4-justus@g10code.com> * src/Makefile.am (arch_sources): Add new file. * src/estream.c (O_NONBLOCK): Move to 'gpgrt-int.h'. (BUFFER_BLOCK_SIZE): Likewise. (BUFFER_UNREAD_SIZE): Likewise. (struct notify_list_s, notify_list_t): Likewise. (struct _gpgrt_stream_internal, estream_internal_t): Likewise. (X_POLLABLE): New macro. (parse_mode): Parse keyword 'pollable', emulate O_NONBLOCK using the same mechanism on Windows. (_gpgrt_poll): Use the new '_gpgrt_w32_poll' on Windows. * src/gpgrt-int.h (_gpgrt_functions_w32_pollable): New declaration. (_gpgrt_w32_pollable_create): New prototype. (_gpgrt_w32_poll): Likewise. * src/w32-estream.c: New file. This code is adapted from GPGME. * tests/t-poll.c (create_pipe): Create pollable streams. GnuPG-bug-id: 2731 Signed-off-by: Justus Winter --- src/Makefile.am | 3 +- src/estream.c | 125 +++---- src/gpgrt-int.h | 74 ++++ src/w32-estream.c | 1044 +++++++++++++++++++++++++++++++++++++++++++++++++++++ tests/t-poll.c | 4 +- 5 files changed, 1174 insertions(+), 76 deletions(-) create mode 100644 src/w32-estream.c diff --git a/src/Makefile.am b/src/Makefile.am index c1e86a7..0c18252 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -109,7 +109,8 @@ CLEANFILES = err-sources.h err-codes.h code-to-errno.h code-from-errno.h \ # {{{ Begin Windows part # if HAVE_W32_SYSTEM -arch_sources = w32-gettext.c w32-lock.c w32-lock-obj.h w32-thread.c w32-iconv.c +arch_sources = w32-gettext.c w32-lock.c w32-lock-obj.h w32-thread.c \ + w32-iconv.c w32-estream.c RCCOMPILE = $(RC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \ -DLOCALEDIR=\"$(localedir)\" $(AM_CPPFLAGS) $(CPPFLAGS) LTRCCOMPILE = $(LIBTOOL) --mode=compile --tag=RC $(RCCOMPILE) diff --git a/src/estream.c b/src/estream.c index 7ef687a..5c64295 100644 --- a/src/estream.c +++ b/src/estream.c @@ -126,8 +126,6 @@ # ifndef S_IXOTH # define S_IXOTH S_IXUSR # endif -# undef O_NONBLOCK -# define O_NONBLOCK 0 /* FIXME: Not yet supported. */ #endif #if !defined (EWOULDBLOCK) && defined (HAVE_W32_SYSTEM) @@ -173,66 +171,6 @@ typedef void (*func_free_t) (void *mem); /* - * Buffer management layer. - */ - -#define BUFFER_BLOCK_SIZE BUFSIZ -#define BUFFER_UNREAD_SIZE 16 - - -/* - * A type to hold notification functions. - */ -struct notify_list_s -{ - struct notify_list_s *next; - void (*fnc) (estream_t, void*); /* The notification function. */ - void *fnc_value; /* The value to be passed to FNC. */ -}; -typedef struct notify_list_s *notify_list_t; - - -/* - * The private object describing a stream. - */ -struct _gpgrt_stream_internal -{ - unsigned char buffer[BUFFER_BLOCK_SIZE]; - unsigned char unread_buffer[BUFFER_UNREAD_SIZE]; - - gpgrt_lock_t lock; /* Lock. Used by *_stream_lock(). */ - - gpgrt_stream_backend_kind_t kind; - void *cookie; /* Cookie. */ - void *opaque; /* Opaque data. */ - unsigned int modeflags; /* Flags for the backend. */ - char *printable_fname; /* Malloced filename for es_fname_get. */ - gpgrt_off_t offset; - gpgrt_cookie_read_function_t func_read; - gpgrt_cookie_write_function_t func_write; - gpgrt_cookie_seek_function_t func_seek; - gpgrt_cookie_close_function_t func_close; - cookie_ioctl_function_t func_ioctl; - int strategy; - es_syshd_t syshd; /* A copy of the system handle. */ - struct - { - unsigned int err: 1; - unsigned int eof: 1; - unsigned int hup: 1; - } indicators; - unsigned int deallocate_buffer: 1; - unsigned int is_stdstream:1; /* This is a standard stream. */ - unsigned int stdstream_fd:2; /* 0, 1 or 2 for a standard stream. */ - unsigned int printable_fname_inuse: 1; /* es_fname_get has been used. */ - unsigned int samethread: 1; /* The "samethread" mode keyword. */ - size_t print_ntotal; /* Bytes written from in print_writer. */ - notify_list_t onclose; /* On close notify function list. */ -}; -typedef struct _gpgrt_stream_internal *estream_internal_t; - - -/* * A linked list to hold active stream objects. * Protected by ESTREAM_LIST_LOCK. */ @@ -1670,6 +1608,7 @@ func_file_create (void **cookie, int *filedes, /* Flags used by parse_mode and friends. */ #define X_SAMETHREAD (1 << 0) #define X_SYSOPEN (1 << 1) +#define X_POLLABLE (1 << 2) /* Parse the mode flags of fopen et al. In addition to the POSIX * defined mode flags keyword parameters are supported. These are @@ -1707,6 +1646,13 @@ func_file_create (void **cookie, int *filedes, * under Windows the direct W32 API functions (HANDLE) are used * instead of their libc counterparts (fd). * + * pollable + * + * The object is opened in a way suitable for use with es_poll. On + * POSIX this is a NOP but under Windows we create up to two + * threads, one for reading and one for writing, do any I/O there, + * and synchronize with them in order to support es_poll. + * * Note: R_CMODE is optional because is only required by functions * which are able to creat a file. */ @@ -1812,6 +1758,10 @@ parse_mode (const char *modestr, return -1; } oflags |= O_NONBLOCK; +#if HAVE_W32_SYSTEM + /* Currently, nonblock implies pollable on Windows. */ + *r_xmode |= X_POLLABLE; +#endif } else if (!strncmp (modestr, "sysopen", 7)) { @@ -1823,6 +1773,16 @@ parse_mode (const char *modestr, } *r_xmode |= X_SYSOPEN; } + else if (!strncmp (modestr, "pollable", 8)) + { + modestr += 8; + if (*modestr && !strchr (" \t,", *modestr)) + { + _set_errno (EINVAL); + return -1; + } + *r_xmode |= X_POLLABLE; + } } if (!got_cmode) cmode = (S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH); @@ -2110,6 +2070,23 @@ es_create (estream_t *stream, void *cookie, es_syshd_t *syshd, stream_new->unread_buffer_size = sizeof (stream_internal_new->unread_buffer); stream_new->intern = stream_internal_new; +#if _WIN32 + if (xmode & X_POLLABLE) + { + void *new_cookie; + + err = _gpgrt_w32_pollable_create (&new_cookie, modeflags, + functions, cookie); + if (err) + goto out; + + modeflags &= ~O_NONBLOCK; + cookie = new_cookie; + kind = BACKEND_W32_POLLABLE; + functions = _gpgrt_functions_w32_pollable; + } +#endif + init_stream_obj (stream_new, cookie, syshd, kind, functions, modeflags, xmode); init_stream_lock (stream_new); @@ -4715,11 +4692,13 @@ _gpgrt_poll (gpgrt_poll_t *fds, unsigned int nfds, int timeout) { gpgrt_poll_t *item; int count = 0; +#ifndef _WIN32 fd_set readfds, writefds, exceptfds; int any_readfd, any_writefd, any_exceptfd; - int idx; int max_fd; int fd, ret, any; +#endif + int idx; if (!fds) { @@ -4767,6 +4746,15 @@ _gpgrt_poll (gpgrt_poll_t *fds, unsigned int nfds, int timeout) return count; /* Early return without waiting. */ /* Now do the real select. */ +#ifdef _WIN32 + if (pre_syscall_func) + pre_syscall_func (); + + count = _gpgrt_w32_poll (fds, nfds, timeout); + + if (post_syscall_func) + post_syscall_func (); +#else any_readfd = any_writefd = any_exceptfd = 0; max_fd = 0; for (item = fds, idx = 0; idx < nfds; item++, idx++) @@ -4812,11 +4800,6 @@ _gpgrt_poll (gpgrt_poll_t *fds, unsigned int nfds, int timeout) } } -#ifdef _WIN32 - (void)timeout; - ret = -1; - _set_errno (EOPNOTSUPP); -#else if (pre_syscall_func) pre_syscall_func (); do @@ -4834,7 +4817,6 @@ _gpgrt_poll (gpgrt_poll_t *fds, unsigned int nfds, int timeout) while (ret == -1 && errno == EINTR); if (post_syscall_func) post_syscall_func (); -#endif if (ret == -1) return -1; @@ -4860,9 +4842,6 @@ _gpgrt_poll (gpgrt_poll_t *fds, unsigned int nfds, int timeout) item->got_hup = 1; any = 1; } -#ifndef _WIN32 - /* NB.: We can't use FD_ISSET under windows - but we don't have - * support for it anyway. */ if (item->want_read && FD_ISSET (fd, &readfds)) { item->got_read = 1; @@ -4878,11 +4857,11 @@ _gpgrt_poll (gpgrt_poll_t *fds, unsigned int nfds, int timeout) item->got_oob = 1; any = 1; } -#endif /*!_WIN32*/ if (any) count++; } +#endif return count; } diff --git a/src/gpgrt-int.h b/src/gpgrt-int.h index 2b13350..57eb86a 100644 --- a/src/gpgrt-int.h +++ b/src/gpgrt-int.h @@ -52,6 +52,12 @@ gpg_err_code_t _gpgrt_yield (void); /* Local definitions for estream. */ +#if HAVE_W32_SYSTEM +# ifndef O_NONBLOCK +# define O_NONBLOCK 0x40000000 /* FIXME: Is that safe? */ +# endif +#endif + /* * A private cookie function to implement an internal IOCTL service. * and ist IOCTL numbers. @@ -80,6 +86,65 @@ typedef enum } gpgrt_stream_backend_kind_t; +/* + * A type to hold notification functions. + */ +struct notify_list_s +{ + struct notify_list_s *next; + void (*fnc) (estream_t, void*); /* The notification function. */ + void *fnc_value; /* The value to be passed to FNC. */ +}; +typedef struct notify_list_s *notify_list_t; + + +/* + * Buffer management layer. + */ + +#define BUFFER_BLOCK_SIZE BUFSIZ +#define BUFFER_UNREAD_SIZE 16 + + +/* + * The private object describing a stream. + */ +struct _gpgrt_stream_internal +{ + unsigned char buffer[BUFFER_BLOCK_SIZE]; + unsigned char unread_buffer[BUFFER_UNREAD_SIZE]; + + gpgrt_lock_t lock; /* Lock. Used by *_stream_lock(). */ + + gpgrt_stream_backend_kind_t kind; + void *cookie; /* Cookie. */ + void *opaque; /* Opaque data. */ + unsigned int modeflags; /* Flags for the backend. */ + char *printable_fname; /* Malloced filename for es_fname_get. */ + gpgrt_off_t offset; + gpgrt_cookie_read_function_t func_read; + gpgrt_cookie_write_function_t func_write; + gpgrt_cookie_seek_function_t func_seek; + gpgrt_cookie_close_function_t func_close; + cookie_ioctl_function_t func_ioctl; + int strategy; + es_syshd_t syshd; /* A copy of the system handle. */ + struct + { + unsigned int err: 1; + unsigned int eof: 1; + unsigned int hup: 1; + } indicators; + unsigned int deallocate_buffer: 1; + unsigned int is_stdstream:1; /* This is a standard stream. */ + unsigned int stdstream_fd:2; /* 0, 1 or 2 for a standard stream. */ + unsigned int printable_fname_inuse: 1; /* es_fname_get has been used. */ + unsigned int samethread: 1; /* The "samethread" mode keyword. */ + size_t print_ntotal; /* Bytes written from in print_writer. */ + notify_list_t onclose; /* On close notify function list. */ +}; +typedef struct _gpgrt_stream_internal *estream_internal_t; + /* Local prototypes for estream. */ int _gpgrt_es_init (void); @@ -236,5 +301,14 @@ const char *_gpgrt_fname_get (gpgrt_stream_t stream); #include "estream-printf.h" +#if _WIN32 +/* Prototypes for w32-estream.c. */ +struct cookie_io_functions_s _gpgrt_functions_w32_pollable; +int _gpgrt_w32_pollable_create (void *_GPGRT__RESTRICT *_GPGRT__RESTRICT cookie, + unsigned int modeflags, + struct cookie_io_functions_s next_functions, + void *next_cookie); +int _gpgrt_w32_poll (gpgrt_poll_t *fds, size_t nfds, int timeout); +#endif #endif /*_GPGRT_GPGRT_INT_H*/ diff --git a/src/w32-estream.c b/src/w32-estream.c new file mode 100644 index 0000000..643b581 --- /dev/null +++ b/src/w32-estream.c @@ -0,0 +1,1044 @@ +/* w32-estream.c - es_poll support on W32. + Copyright (C) 2000 Werner Koch (dd9jn) + Copyright (C) 2001, 2002, 2003, 2004, 2007, 2010, 2016 g10 Code GmbH + + This file is part of libgpg-error. + + libgpg-error is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public License + as published by the Free Software Foundation; either version 2.1 of + the License, or (at your option) any later version. + + libgpg-error is distributed in the hope that it will be useful, but + WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public + License along with this program; if not, write to the Free Software + Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA + 02111-1307, USA. */ + +#ifdef HAVE_CONFIG_H +#include +#endif +#include +#include +#include +#include +#include +#include +#ifdef HAVE_SYS_TIME_H +# include +#endif +#ifdef HAVE_SYS_TYPES_H +# include +#endif +#include +#include + +#include "gpgrt-int.h" + +/* + * In order to support es_poll on Windows, we create a proxy shim that + * we use as the estream I/O functions. This shim creates reader and + * writer threads that use the original I/O functions. + */ + + + +/* Tracing/debugging support. */ +#if 0 +#define TRACE(msg, ...) \ + fprintf (stderr, msg, ## __VA_ARGS__) +#define TRACE_CTX(ctx, msg, ...) \ + fprintf (stderr, "%p: " msg "\n", ctx, ## __VA_ARGS__) +#define TRACE_ERR(ctx, err, msg, ...) do { \ + char error_message[128]; \ + FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM \ + | FORMAT_MESSAGE_IGNORE_INSERTS, \ + NULL, \ + err, \ + MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), \ + (LPTSTR) &error_message, \ + sizeof error_message, NULL ); \ + fprintf (stderr, "%p: " msg ": %s\n", ctx, \ + ## __VA_ARGS__, error_message); \ + } while (0) +#else +#define TRACE(msg, ...) (void) 0 +#define TRACE_CTX(ctx, msg, ...) (void) 0 +#define TRACE_ERR(ctx, err, msg, ...) (void) 0 +#endif + + + +/* Calculate array dimension. */ +#ifndef DIM +#define DIM(array) (sizeof (array) / sizeof (*array)) +#endif + +#define READBUF_SIZE 4096 +#define WRITEBUF_SIZE 4096 + + +typedef struct estream_cookie_w32_pollable *estream_cookie_w32_pollable_t; + +struct reader_context_s +{ + estream_cookie_w32_pollable_t pcookie; + HANDLE thread_hd; + + gpgrt_lock_t mutex; + + int stop_me; + int eof; + int eof_shortcut; + int error; + int error_code; + + /* This is manually reset. */ + HANDLE have_data_ev; + /* This is automatically reset. */ + HANDLE have_space_ev; + /* This is manually reset but actually only triggered once. */ + HANDLE close_ev; + + size_t readpos, writepos; + char buffer[READBUF_SIZE]; +}; + +struct writer_context_s +{ + estream_cookie_w32_pollable_t pcookie; + HANDLE thread_hd; + + gpgrt_lock_t mutex; + + int stop_me; + int error; + int error_code; + + /* This is manually reset. */ + HANDLE have_data; + HANDLE is_empty; + HANDLE close_ev; + size_t nbytes; + char buffer[WRITEBUF_SIZE]; +}; + +/* Cookie for pollable objects. */ +struct estream_cookie_w32_pollable +{ + unsigned int modeflags; + + struct cookie_io_functions_s next_functions; + void *next_cookie; + + struct reader_context_s *reader; + struct writer_context_s *writer; +}; + + +static HANDLE +set_synchronize (HANDLE hd) +{ +#ifdef HAVE_W32CE_SYSTEM + return hd; +#else + HANDLE new_hd; + + /* For NT we have to set the sync flag. It seems that the only way + to do it is by duplicating the handle. Tsss... */ + if (!DuplicateHandle (GetCurrentProcess (), hd, + GetCurrentProcess (), &new_hd, + EVENT_MODIFY_STATE | SYNCHRONIZE, FALSE, 0)) + { + TRACE_ERR (NULL, GetLastError (), "DuplicateHandle failed"); + /* FIXME: Should translate the error code. */ + _gpg_err_set_errno (EIO); + return INVALID_HANDLE_VALUE; + } + + CloseHandle (hd); + return new_hd; +#endif +} + + +static DWORD CALLBACK +reader (void *arg) +{ + struct reader_context_s *ctx = arg; + int nbytes; + ssize_t nread; + TRACE_CTX (ctx, "reader starting"); + + for (;;) + { + _gpgrt_lock_lock (&ctx->mutex); + /* Leave a 1 byte gap so that we can see whether it is empty or + full. */ + while ((ctx->writepos + 1) % READBUF_SIZE == ctx->readpos) + { + /* Wait for space. */ + if (!ResetEvent (ctx->have_space_ev)) + TRACE_ERR (ctx, GetLastError (), "ResetEvent failed"); + _gpgrt_lock_unlock (&ctx->mutex); + TRACE_CTX (ctx, "waiting for space"); + WaitForSingleObject (ctx->have_space_ev, INFINITE); + TRACE_CTX (ctx, "got space"); + _gpgrt_lock_lock (&ctx->mutex); + } + assert (((ctx->writepos + 1) % READBUF_SIZE != ctx->readpos)); + if (ctx->stop_me) + { + _gpgrt_lock_unlock (&ctx->mutex); + break; + } + nbytes = (ctx->readpos + READBUF_SIZE + - ctx->writepos - 1) % READBUF_SIZE; + assert (nbytes); + if (nbytes > READBUF_SIZE - ctx->writepos) + nbytes = READBUF_SIZE - ctx->writepos; + _gpgrt_lock_unlock (&ctx->mutex); + + TRACE_CTX (ctx, "reading up to %d bytes", nbytes); + + nread = ctx->pcookie->next_functions.public.func_read + (ctx->pcookie->next_cookie, ctx->buffer + ctx->writepos, nbytes); + TRACE_CTX (ctx, "got %d bytes", nread); + if (nread < 0) + { + ctx->error_code = (int) errno; + /* NOTE (W32CE): Do not ignore ERROR_BUSY! Check at + least stop_me if that happens. */ + if (ctx->error_code == ERROR_BROKEN_PIPE) + { + ctx->eof = 1; + TRACE_CTX (ctx, "got EOF (broken pipe)"); + } + else + { + ctx->error = 1; + TRACE_ERR (ctx, ctx->error_code, "read error"); + } + break; + } + + _gpgrt_lock_lock (&ctx->mutex); + if (ctx->stop_me) + { + _gpgrt_lock_unlock (&ctx->mutex); + break; + } + if (!nread) + { + ctx->eof = 1; + TRACE_CTX (ctx, "got eof"); + _gpgrt_lock_unlock (&ctx->mutex); + break; + } + + ctx->writepos = (ctx->writepos + nread) % READBUF_SIZE; + if (!SetEvent (ctx->have_data_ev)) + TRACE_ERR (ctx, GetLastError (), "SetEvent (%p) failed", + ctx->have_data_ev); + _gpgrt_lock_unlock (&ctx->mutex); + } + /* Indicate that we have an error or EOF. */ + if (!SetEvent (ctx->have_data_ev)) + TRACE_ERR (ctx, GetLastError (), "SetEvent (%p) failed", + ctx->have_data_ev); + + TRACE_CTX (ctx, "waiting for close"); + WaitForSingleObject (ctx->close_ev, INFINITE); + + CloseHandle (ctx->close_ev); + CloseHandle (ctx->have_data_ev); + CloseHandle (ctx->have_space_ev); + CloseHandle (ctx->thread_hd); + _gpgrt_lock_destroy (&ctx->mutex); + _gpgrt_free (ctx); + + return 0; +} + + +static struct reader_context_s * +create_reader (estream_cookie_w32_pollable_t pcookie) +{ + struct reader_context_s *ctx; + SECURITY_ATTRIBUTES sec_attr; + DWORD tid; + + memset (&sec_attr, 0, sizeof sec_attr); + sec_attr.nLength = sizeof sec_attr; + sec_attr.bInheritHandle = FALSE; + + ctx = calloc (1, sizeof *ctx); + if (!ctx) + { + return NULL; + } + + ctx->pcookie = pcookie; + + ctx->have_data_ev = CreateEvent (&sec_attr, TRUE, FALSE, NULL); + if (ctx->have_data_ev) + ctx->have_space_ev = CreateEvent (&sec_attr, FALSE, TRUE, NULL); + if (ctx->have_space_ev) + ctx->close_ev = CreateEvent (&sec_attr, TRUE, FALSE, NULL); + if (!ctx->have_data_ev || !ctx->have_space_ev || !ctx->close_ev) + { + TRACE_ERR (ctx, GetLastError (), "CreateEvent failed"); + if (ctx->have_data_ev) + CloseHandle (ctx->have_data_ev); + if (ctx->have_space_ev) + CloseHandle (ctx->have_space_ev); + if (ctx->close_ev) + CloseHandle (ctx->close_ev); + _gpgrt_free (ctx); + return NULL; + } + + ctx->have_data_ev = set_synchronize (ctx->have_data_ev); + _gpgrt_lock_init (&ctx->mutex); + +#ifdef HAVE_W32CE_SYSTEM + ctx->thread_hd = CreateThread (&sec_attr, 64 * 1024, reader, ctx, + STACK_SIZE_PARAM_IS_A_RESERVATION, &tid); +#else + ctx->thread_hd = CreateThread (&sec_attr, 0, reader, ctx, 0, &tid); +#endif + + if (!ctx->thread_hd) + { + TRACE_ERR (ctx, GetLastError (), "CreateThread failed"); + _gpgrt_lock_destroy (&ctx->mutex); + if (ctx->have_data_ev) + CloseHandle (ctx->have_data_ev); + if (ctx->have_space_ev) + CloseHandle (ctx->have_space_ev); + if (ctx->close_ev) + CloseHandle (ctx->close_ev); + _gpgrt_free (ctx); + return NULL; + } + else + { +#if 0 + /* We set the priority of the thread higher because we know that + it only runs for a short time. This greatly helps to + increase the performance of the I/O. */ + SetThreadPriority (ctx->thread_hd, get_desired_thread_priority ()); +#endif + } + + return ctx; +} + + +/* Prepare destruction of the reader thread for CTX. Returns 0 if a + call to this function is sufficient and destroy_reader_finish shall + not be called. */ +static void +destroy_reader (struct reader_context_s *ctx) +{ + _gpgrt_lock_lock (&ctx->mutex); + ctx->stop_me = 1; + if (ctx->have_space_ev) + SetEvent (ctx->have_space_ev); + _gpgrt_lock_unlock (&ctx->mutex); + +#ifdef HAVE_W32CE_SYSTEM + /* Scenario: We never create a full pipe, but already started + reading. Then we need to unblock the reader in the pipe driver + to make our reader thread notice that we want it to go away. */ + + if (ctx->file_hd != INVALID_HANDLE_VALUE) + { + if (!DeviceIoControl (ctx->file_hd, GPGCEDEV_IOCTL_UNBLOCK, + NULL, 0, NULL, 0, NULL, NULL)) + { + TRACE_ERR (ctx, GetLastError (), "unblock control call failed"); + } + } +#endif + + /* XXX is it feasible to unblock the thread? */ + + /* After setting this event CTX is void. */ + SetEvent (ctx->close_ev); +} + + +/* + * Read function for pollable objects. + */ +static gpgrt_ssize_t +func_w32_pollable_read (void *cookie, void *buffer, size_t count) +{ + estream_cookie_w32_pollable_t pcookie = cookie; + gpgrt_ssize_t nread; + struct reader_context_s *ctx; + + ctx = pcookie->reader; + if (ctx == NULL) + { + pcookie->reader = ctx = create_reader (pcookie); + if (!ctx) + { + _gpg_err_set_errno (EBADF); + return -1; + } + } + + TRACE_CTX (ctx, "pollable read buffer=%p, count=%u", buffer, count); + + if (ctx->eof_shortcut) + return 0; + + _gpgrt_lock_lock (&ctx->mutex); + TRACE_CTX (ctx, "readpos: %d, writepos %d", ctx->readpos, ctx->writepos); + if (ctx->readpos == ctx->writepos && !ctx->error) + { + /* No data available. */ + int eof = ctx->eof; + _gpgrt_lock_unlock (&ctx->mutex); + + if (pcookie->modeflags & O_NONBLOCK && ! eof) + { + _gpg_err_set_errno (EAGAIN); + return -1; + } + + TRACE_CTX (ctx, "waiting for data"); + WaitForSingleObject (ctx->have_data_ev, INFINITE); + TRACE_CTX (ctx, "data available"); + _gpgrt_lock_lock (&ctx->mutex); + } + + if (ctx->readpos == ctx->writepos || ctx->error) + { + _gpgrt_lock_unlock (&ctx->mutex); + ctx->eof_shortcut = 1; + if (ctx->eof) + return 0; + if (!ctx->error) + { + TRACE_CTX (ctx, "EOF but ctx->eof flag not set"); + return 0; + } + _gpg_err_set_errno (ctx->error_code); + return -1; + } + + nread = ctx->readpos < ctx->writepos + ? ctx->writepos - ctx->readpos + : READBUF_SIZE - ctx->readpos; + if (nread > count) + nread = count; + memcpy (buffer, ctx->buffer + ctx->readpos, nread); + ctx->readpos = (ctx->readpos + nread) % READBUF_SIZE; + if (ctx->readpos == ctx->writepos && !ctx->eof) + { + if (!ResetEvent (ctx->have_data_ev)) + { + TRACE_ERR (ctx, GetLastError (), "ResetEvent failed"); + _gpgrt_lock_unlock (&ctx->mutex); + /* FIXME: Should translate the error code. */ + _gpg_err_set_errno (EIO); + return -1; + } + } + if (!SetEvent (ctx->have_space_ev)) + { + TRACE_ERR (ctx, GetLastError (), "SetEvent (%p) failed", + ctx->have_space_ev); + _gpgrt_lock_unlock (&ctx->mutex); + /* FIXME: Should translate the error code. */ + _gpg_err_set_errno (EIO); + return -1; + } + _gpgrt_lock_unlock (&ctx->mutex); + + return nread; +} + + +/* The writer does use a simple buffering strategy so that we are + informed about write errors as soon as possible (i. e. with the the + next call to the write function. */ +static DWORD CALLBACK +writer (void *arg) +{ + struct writer_context_s *ctx = arg; + ssize_t nwritten; + + TRACE_CTX (ctx, "writer starting"); + + for (;;) + { + _gpgrt_lock_lock (&ctx->mutex); + if (ctx->stop_me && !ctx->nbytes) + { + _gpgrt_lock_unlock (&ctx->mutex); + break; + } + if (!ctx->nbytes) + { + if (!SetEvent (ctx->is_empty)) + TRACE_ERR (ctx, GetLastError (), "SetEvent failed"); + if (!ResetEvent (ctx->have_data)) + TRACE_ERR (ctx, GetLastError (), "ResetEvent failed"); + _gpgrt_lock_unlock (&ctx->mutex); + TRACE_CTX (ctx, "idle"); + WaitForSingleObject (ctx->have_data, INFINITE); + TRACE_CTX (ctx, "got data to write"); + _gpgrt_lock_lock (&ctx->mutex); + } + if (ctx->stop_me && !ctx->nbytes) + { + _gpgrt_lock_unlock (&ctx->mutex); + break; + } + _gpgrt_lock_unlock (&ctx->mutex); + + TRACE_CTX (ctx, "writing up to %d bytes", ctx->nbytes); + + nwritten = ctx->pcookie->next_functions.public.func_write + (ctx->pcookie->next_cookie, ctx->buffer, ctx->nbytes); + TRACE_CTX (ctx, "wrote %d bytes", nwritten); + if (nwritten < 1) + { + /* XXX */ + if (errno == ERROR_BUSY) + { + /* Probably stop_me is set now. */ + TRACE_CTX (ctx, "pipe busy (unblocked?)"); + continue; + } + + ctx->error_code = errno; + ctx->error = 1; + TRACE_ERR (ctx, ctx->error_code, "write error"); + break; + } + + _gpgrt_lock_lock (&ctx->mutex); + ctx->nbytes -= nwritten; + _gpgrt_lock_unlock (&ctx->mutex); + } + /* Indicate that we have an error. */ + if (!SetEvent (ctx->is_empty)) + TRACE_ERR (ctx, GetLastError (), "SetEvent failed"); + + TRACE_CTX (ctx, "waiting for close"); + WaitForSingleObject (ctx->close_ev, INFINITE); + + if (ctx->nbytes) + TRACE_CTX (ctx, "still %d bytes in buffer at close time", ctx->nbytes); + + CloseHandle (ctx->close_ev); + CloseHandle (ctx->have_data); + CloseHandle (ctx->is_empty); + CloseHandle (ctx->thread_hd); + _gpgrt_lock_destroy (&ctx->mutex); + _gpgrt_free (ctx); + + return 0; +} + + +static struct writer_context_s * +create_writer (estream_cookie_w32_pollable_t pcookie) +{ + struct writer_context_s *ctx; + SECURITY_ATTRIBUTES sec_attr; + DWORD tid; + + memset (&sec_attr, 0, sizeof sec_attr); + sec_attr.nLength = sizeof sec_attr; + sec_attr.bInheritHandle = FALSE; + + ctx = calloc (1, sizeof *ctx); + if (!ctx) + { + return NULL; + } + + ctx->pcookie = pcookie; + + ctx->have_data = CreateEvent (&sec_attr, TRUE, FALSE, NULL); + if (ctx->have_data) + ctx->is_empty = CreateEvent (&sec_attr, TRUE, TRUE, NULL); + if (ctx->is_empty) + ctx->close_ev = CreateEvent (&sec_attr, TRUE, FALSE, NULL); + if (!ctx->have_data || !ctx->is_empty || !ctx->close_ev) + { + TRACE_ERR (ctx, GetLastError (), "CreateEvent failed"); + if (ctx->have_data) + CloseHandle (ctx->have_data); + if (ctx->is_empty) + CloseHandle (ctx->is_empty); + if (ctx->close_ev) + CloseHandle (ctx->close_ev); + _gpgrt_free (ctx); + return NULL; + } + + ctx->is_empty = set_synchronize (ctx->is_empty); + _gpgrt_lock_init (&ctx->mutex); + +#ifdef HAVE_W32CE_SYSTEM + ctx->thread_hd = CreateThread (&sec_attr, 64 * 1024, writer, ctx, + STACK_SIZE_PARAM_IS_A_RESERVATION, &tid); +#else + ctx->thread_hd = CreateThread (&sec_attr, 0, writer, ctx, 0, &tid ); +#endif + + if (!ctx->thread_hd) + { + TRACE_ERR (ctx, GetLastError (), "CreateThread failed"); + _gpgrt_lock_destroy (&ctx->mutex); + if (ctx->have_data) + CloseHandle (ctx->have_data); + if (ctx->is_empty) + CloseHandle (ctx->is_empty); + if (ctx->close_ev) + CloseHandle (ctx->close_ev); + _gpgrt_free (ctx); + return NULL; + } + else + { +#if 0 + /* We set the priority of the thread higher because we know + that it only runs for a short time. This greatly helps to + increase the performance of the I/O. */ + SetThreadPriority (ctx->thread_hd, get_desired_thread_priority ()); +#endif + } + + return ctx; +} + + +static void +destroy_writer (struct writer_context_s *ctx) +{ + _gpgrt_lock_lock (&ctx->mutex); + ctx->stop_me = 1; + if (ctx->have_data) + SetEvent (ctx->have_data); + _gpgrt_lock_unlock (&ctx->mutex); + + /* Give the writer a chance to flush the buffer. */ + WaitForSingleObject (ctx->is_empty, INFINITE); + +#ifdef HAVE_W32CE_SYSTEM + /* Scenario: We never create a full pipe, but already started + writing more than the pipe buffer. Then we need to unblock the + writer in the pipe driver to make our writer thread notice that + we want it to go away. */ + + if (!DeviceIoControl (ctx->file_hd, GPGCEDEV_IOCTL_UNBLOCK, + NULL, 0, NULL, 0, NULL, NULL)) + { + TRACE_ERR (ctx, GetLastError (), "unblock control call failed"); + } +#endif + + /* After setting this event CTX is void. */ + SetEvent (ctx->close_ev); +} + + +/* + * Write function for pollable objects. + */ +static gpgrt_ssize_t +func_w32_pollable_write (void *cookie, const void *buffer, size_t count) +{ + estream_cookie_w32_pollable_t pcookie = cookie; + struct writer_context_s *ctx; + + if (count == 0) + return 0; + + ctx = pcookie->writer; + if (ctx == NULL) + { + pcookie->writer = ctx = create_writer (pcookie); + if (!ctx) + return -1; + } + + _gpgrt_lock_lock (&ctx->mutex); + TRACE_CTX (ctx, "pollable write buffer: %p, count: %d, nbytes: %d", + buffer, count, ctx->nbytes); + if (!ctx->error && ctx->nbytes) + { + /* Bytes are pending for send. */ + + /* Reset the is_empty event. Better safe than sorry. */ + if (!ResetEvent (ctx->is_empty)) + { + TRACE_ERR (ctx, GetLastError (), "ResetEvent failed"); + _gpgrt_lock_unlock (&ctx->mutex); + /* FIXME: Should translate the error code. */ + _gpg_err_set_errno (EIO); + return -1; + } + _gpgrt_lock_unlock (&ctx->mutex); + + if (pcookie->modeflags & O_NONBLOCK) + { + TRACE_CTX (ctx, "would block"); + _gpg_err_set_errno (EAGAIN); + return -1; + } + + TRACE_CTX (ctx, "waiting for empty buffer"); + WaitForSingleObject (ctx->is_empty, INFINITE); + TRACE_CTX (ctx, "buffer is empty"); + _gpgrt_lock_lock (&ctx->mutex); + } + + if (ctx->error) + { + _gpgrt_lock_unlock (&ctx->mutex); + if (ctx->error_code == ERROR_NO_DATA) + _gpg_err_set_errno (EPIPE); + else + _gpg_err_set_errno (EIO); + return -1; + } + + /* If no error occurred, the number of bytes in the buffer must be + zero. */ + assert (!ctx->nbytes); + + if (count > WRITEBUF_SIZE) + count = WRITEBUF_SIZE; + memcpy (ctx->buffer, buffer, count); + ctx->nbytes = count; + + /* We have to reset the is_empty event early, because it is also + used by the select() implementation to probe the channel. */ + if (!ResetEvent (ctx->is_empty)) + { + TRACE_ERR (ctx, GetLastError (), "ResetEvent failed"); + _gpgrt_lock_unlock (&ctx->mutex); + /* FIXME: Should translate the error code. */ + _gpg_err_set_errno (EIO); + return -1; + } + if (!SetEvent (ctx->have_data)) + { + TRACE_ERR (ctx, GetLastError (), "SetEvent failed"); + _gpgrt_lock_unlock (&ctx->mutex); + /* FIXME: Should translate the error code. */ + _gpg_err_set_errno (EIO); + return -1; + } + _gpgrt_lock_unlock (&ctx->mutex); + + return (int) count; +} + + +int +_gpgrt_w32_poll (gpgrt_poll_t *fds, size_t nfds, int timeout) +{ + HANDLE waitbuf[MAXIMUM_WAIT_OBJECTS]; + int waitidx[MAXIMUM_WAIT_OBJECTS]; + int code; + int nwait; + int i; + int any; + int count; + +#if 0 + restart: +#endif + + TRACE ("poll on [ "); + any = 0; + nwait = 0; + count = 0; + for (i = 0; i < nfds; i++) + { + struct estream_cookie_w32_pollable *pcookie; + + if (fds[i].ignore) + continue; + + if (fds[i].stream->intern->kind != BACKEND_W32_POLLABLE) + { + /* This stream does not support polling. */ + fds[i].got_err = 1; + continue; + } + + pcookie = fds[i].stream->intern->cookie; + + if (fds[i].want_read || fds[i].want_write) + { + /* XXX: What if one wants read and write, is that supported? */ + if (fds[i].want_read) + { + struct reader_context_s *ctx = pcookie->reader; + TRACE ("%d/read ", i); + if (ctx == NULL) + { + pcookie->reader = ctx = create_reader (pcookie); + if (!ctx) + { + /* FIXME: Is the error code appropriate? */ + _gpg_err_set_errno (EBADF); + return -1; + } + } + + if (nwait >= DIM (waitbuf)) + { + TRACE ("oops ]: Too many objects for WFMO!\n"); + /* FIXME: Should translate the error code. */ + _gpg_err_set_errno (EIO); + return -1; + } + waitidx[nwait] = i; + waitbuf[nwait++] = ctx->have_data_ev; + any = 1; + } + else if (fds[i].want_write) + { + struct writer_context_s *ctx = pcookie->writer; + TRACE ("%d/write ", i); + if (ctx == NULL) + { + pcookie->writer = ctx = create_writer (pcookie); + if (!ctx) + { + /* FIXME: Is the error code appropriate? */ + _gpg_err_set_errno (EBADF); + return -1; + } + } + + if (nwait >= DIM (waitbuf)) + { + TRACE ("oops ]: Too many objects for WFMO!"); + /* FIXME: Should translate the error code. */ + _gpg_err_set_errno (EIO); + return -1; + } + waitidx[nwait] = i; + waitbuf[nwait++] = ctx->is_empty; + any = 1; + } + } + } + TRACE ("]\n"); + if (!any) + return 0; + + code = WaitForMultipleObjects (nwait, waitbuf, 0, + timeout == -1 ? INFINITE : timeout); + if (code >= WAIT_OBJECT_0 && code < WAIT_OBJECT_0 + nwait) + { + /* This WFMO is a really silly function: It does return either + the index of the signaled object or if 2 objects have been + signalled at the same time, the index of the object with the + lowest object is returned - so and how do we find out how + many objects have been signaled???. The only solution I can + imagine is to test each object starting with the returned + index individually - how dull. */ + any = 0; + for (i = code - WAIT_OBJECT_0; i < nwait; i++) + { + if (WaitForSingleObject (waitbuf[i], 0) == WAIT_OBJECT_0) + { + assert (waitidx[i] >=0 && waitidx[i] < nfds); + /* XXX: What if one wants read and write, is that + supported? */ + if (fds[waitidx[i]].want_read) + fds[waitidx[i]].got_read = 1; + else if (fds[waitidx[i]].want_write) + fds[waitidx[i]].got_write = 1; + any = 1; + count++; + } + } + if (!any) + { + TRACE ("no signaled objects found after WFMO\n"); + count = -1; + } + } + else if (code == WAIT_TIMEOUT) + TRACE ("WFMO timed out\n"); + else if (code == WAIT_FAILED) + { + TRACE_ERR (NULL, GetLastError (), "WFMO failed"); +#if 0 + if (GetLastError () == ERROR_INVALID_HANDLE) + { + int k; + int j = handle_to_fd (waitbuf[i]); + + TRACE ("WFMO invalid handle %d removed\n", j); + for (k = 0 ; k < nfds; k++) + { + if (fds[k].fd == j) + { + fds[k].want_read = fds[k].want_write = 0; + goto restart; + } + } + TRACE (" oops, or not???\n"); + } +#endif + count = -1; + } + else + { + TRACE ("WFMO returned %d\n", code); + count = -1; + } + + if (count > 0) + { + TRACE ("poll OK [ "); + for (i = 0; i < nfds; i++) + { + if (fds[i].ignore) + continue; + if (fds[i].got_read || fds[i].got_write) + TRACE ("%c%d ", fds[i].want_read ? 'r' : 'w', i); + } + TRACE ("]\n"); + } + + if (count < 0) + { + /* FIXME: Should determine a proper error code. */ + _gpg_err_set_errno (EIO); + } + + return count; +} + + + +/* + * Implementation of pollable I/O on Windows. + */ + +/* + * Constructor for pollable objects. + */ +int +_gpgrt_w32_pollable_create (void *_GPGRT__RESTRICT *_GPGRT__RESTRICT cookie, + unsigned int modeflags, + struct cookie_io_functions_s next_functions, + void *next_cookie) +{ + estream_cookie_w32_pollable_t pcookie; + int err; + + pcookie = _gpgrt_malloc (sizeof *pcookie); + if (!pcookie) + err = -1; + else + { + pcookie->modeflags = modeflags; + pcookie->next_functions = next_functions; + pcookie->next_cookie = next_cookie; + pcookie->reader = NULL; + pcookie->writer = NULL; + *cookie = pcookie; + err = 0; + } + + return err; +} + + +/* + * Seek function for pollable objects. + */ +static int +func_w32_pollable_seek (void *cookie, gpgrt_off_t *offset, int whence) +{ + estream_cookie_w32_pollable_t pcookie = cookie; + (void) pcookie; + (void) offset; + (void) whence; + /* XXX */ + _gpg_err_set_errno (EOPNOTSUPP); + return -1; +} + + +/* + * The IOCTL function for pollable objects. + */ +static int +func_w32_pollable_ioctl (void *cookie, int cmd, void *ptr, size_t *len) +{ + estream_cookie_w32_pollable_t pcookie = cookie; + cookie_ioctl_function_t func_ioctl = pcookie->next_functions.func_ioctl; + + if (cmd == COOKIE_IOCTL_NONBLOCK) + { + if (ptr) + pcookie->modeflags |= O_NONBLOCK; + else + pcookie->modeflags &= ~O_NONBLOCK; + return 0; + } + + if (func_ioctl) + return func_ioctl (pcookie->next_cookie, cmd, ptr, len); + + _gpg_err_set_errno (EOPNOTSUPP); + return -1; +} + + +/* + * The destroy function for pollable objects. + */ +static int +func_w32_pollable_destroy (void *cookie) +{ + estream_cookie_w32_pollable_t pcookie = cookie; + + if (cookie) + { + if (pcookie->reader) + destroy_reader (pcookie->reader); + if (pcookie->writer) + destroy_writer (pcookie->writer); + pcookie->next_functions.public.func_close (pcookie->next_cookie); + _gpgrt_free (pcookie); + } + return 0; +} + +/* + * Access object for the pollable functions. + */ +struct cookie_io_functions_s _gpgrt_functions_w32_pollable = + { + { + func_w32_pollable_read, + func_w32_pollable_write, + func_w32_pollable_seek, + func_w32_pollable_destroy, + }, + func_w32_pollable_ioctl, + }; diff --git a/tests/t-poll.c b/tests/t-poll.c index 026bb88..d39797a 100644 --- a/tests/t-poll.c +++ b/tests/t-poll.c @@ -191,14 +191,14 @@ create_pipe (estream_t *r_in, estream_t *r_out) show ("created pipe [%d, %d]\n", filedes[0], filedes[1]); - *r_in = es_fdopen (filedes[0], "r"); + *r_in = es_fdopen (filedes[0], "r,pollable"); if (!*r_in) { err = gpg_error_from_syserror (); die ("error creating a stream for a pipe: %s\n", gpg_strerror (err)); } - *r_out = es_fdopen (filedes[1], "w"); + *r_out = es_fdopen (filedes[1], "w,pollable"); if (!*r_out) { err = gpg_error_from_syserror (); -- 2.9.3 From justus at g10code.com Wed Oct 19 12:20:42 2016 From: justus at g10code.com (Justus Winter) Date: Wed, 19 Oct 2016 12:20:42 +0200 Subject: [PATCH libgpg-error 2/4] estream: Rework how the cookie functions are handled. In-Reply-To: <20161019102044.6469-1-justus@g10code.com> References: <20161019102044.6469-1-justus@g10code.com> Message-ID: <20161019102044.6469-2-justus@g10code.com> * src/estream.c (cookie_ioctl_function_t): Move to 'gpgrt-int.h', along with the macros for the IOCTL numbers. (estream_functions_mem): Use the new type and add the ioctl function. (estream_functions_fd): Likewise. (estream_functions_w32): Likewise. (estream_functions_fp): Likewise. (init_stream_object): Use the new type, and also initialize 'func_ioctl'. (es_create): Use the new type. (_gpgrt_fopen): Adapt. (_gpgrt_mopen): Likewise. (_gpgrt_fopenmem): Likewise. (_gpgrt_fopencookie): Likewise. (_gpgrt_fdopen): Likewise. (_gpgrt_fpopen): Likewise. (do_w32open): Likewise. * src/gpgrt-int.h (struct cookie_io_functions_s): New type. Signed-off-by: Justus Winter --- src/estream.c | 98 ++++++++++++++++++++++++++++----------------------------- src/gpgrt-int.h | 20 ++++++++++++ 2 files changed, 69 insertions(+), 49 deletions(-) diff --git a/src/estream.c b/src/estream.c index 8901a80..1cc4001 100644 --- a/src/estream.c +++ b/src/estream.c @@ -193,16 +193,6 @@ typedef struct notify_list_s *notify_list_t; /* - * A private cookie function to implement an internal IOCTL service. - * and ist IOCTL numbers. - */ -typedef int (*cookie_ioctl_function_t) (void *cookie, int cmd, - void *ptr, size_t *len); -#define COOKIE_IOCTL_SNATCH_BUFFER 1 -#define COOKIE_IOCTL_NONBLOCK 2 - - -/* * The private object describing a stream. */ struct _gpgrt_stream_internal @@ -930,12 +920,15 @@ func_mem_destroy (void *cookie) /* * Access object for the memory functions. */ -static gpgrt_cookie_io_functions_t estream_functions_mem = +static struct cookie_io_functions_s estream_functions_mem = { - func_mem_read, - func_mem_write, - func_mem_seek, - func_mem_destroy + { + func_mem_read, + func_mem_write, + func_mem_seek, + func_mem_destroy, + }, + func_mem_ioctl, }; @@ -1155,12 +1148,15 @@ func_fd_destroy (void *cookie) /* * Access object for the fd functions. */ -static gpgrt_cookie_io_functions_t estream_functions_fd = +static struct cookie_io_functions_s estream_functions_fd = { - func_fd_read, - func_fd_write, - func_fd_seek, - func_fd_destroy + { + func_fd_read, + func_fd_write, + func_fd_seek, + func_fd_destroy, + }, + func_fd_ioctl, }; @@ -1390,12 +1386,15 @@ func_w32_destroy (void *cookie) /* * Access object for the W32 handle based objects. */ -static gpgrt_cookie_io_functions_t estream_functions_w32 = +static struct cookie_io_functions_s estream_functions_w32 = { - func_w32_read, - func_w32_write, - func_w32_seek, - func_w32_destroy + { + func_w32_read, + func_w32_write, + func_w32_seek, + func_w32_destroy, + }, + NULL, }; #endif /*HAVE_W32_SYSTEM*/ @@ -1601,12 +1600,15 @@ func_fp_destroy (void *cookie) /* * Access object for stdio based objects. */ -static gpgrt_cookie_io_functions_t estream_functions_fp = +static struct cookie_io_functions_s estream_functions_fp = { - func_fp_read, - func_fp_write, - func_fp_seek, - func_fp_destroy + { + func_fp_read, + func_fp_write, + func_fp_seek, + func_fp_destroy, + }, + NULL, }; @@ -1989,17 +1991,17 @@ es_empty (estream_t stream) static void init_stream_obj (estream_t stream, void *cookie, es_syshd_t *syshd, - gpgrt_cookie_io_functions_t functions, + struct cookie_io_functions_s functions, unsigned int modeflags, unsigned int xmode) { stream->intern->cookie = cookie; stream->intern->opaque = NULL; stream->intern->offset = 0; - stream->intern->func_read = functions.func_read; - stream->intern->func_write = functions.func_write; - stream->intern->func_seek = functions.func_seek; - stream->intern->func_ioctl = NULL; - stream->intern->func_close = functions.func_close; + stream->intern->func_read = functions.public.func_read; + stream->intern->func_write = functions.public.func_write; + stream->intern->func_seek = functions.public.func_seek; + stream->intern->func_ioctl = functions.func_ioctl; + stream->intern->func_close = functions.public.func_close; stream->intern->strategy = _IOFBF; stream->intern->syshd = *syshd; stream->intern->print_ntotal = 0; @@ -2074,7 +2076,7 @@ es_deinitialize (estream_t stream) */ static int es_create (estream_t *stream, void *cookie, es_syshd_t *syshd, - gpgrt_cookie_io_functions_t functions, unsigned int modeflags, + struct cookie_io_functions_s functions, unsigned int modeflags, unsigned int xmode, int with_locked_list) { estream_internal_t stream_internal_new; @@ -3073,7 +3075,7 @@ _gpgrt_fopen (const char *_GPGRT__RESTRICT path, out: if (err && create_called) - (*estream_functions_fd.func_close) (cookie); + (*estream_functions_fd.public.func_close) (cookie); return stream; } @@ -3125,7 +3127,7 @@ _gpgrt_mopen (void *_GPGRT__RESTRICT data, size_t data_n, size_t data_len, out: if (err && create_called) - (*estream_functions_mem.func_close) (cookie); + (*estream_functions_mem.public.func_close) (cookie); return stream; } @@ -3155,10 +3157,7 @@ _gpgrt_fopenmem (size_t memlimit, const char *_GPGRT__RESTRICT mode) memset (&syshd, 0, sizeof syshd); if (es_create (&stream, cookie, &syshd, estream_functions_mem, modeflags, xmode, 0)) - (*estream_functions_mem.func_close) (cookie); - - if (stream) - stream->intern->func_ioctl = func_mem_ioctl; + (*estream_functions_mem.public.func_close) (cookie); return stream; } @@ -3208,6 +3207,7 @@ _gpgrt_fopencookie (void *_GPGRT__RESTRICT cookie, estream_t stream; int err; es_syshd_t syshd; + struct cookie_io_functions_s io_functions = { functions, NULL, }; stream = NULL; modeflags = 0; @@ -3217,7 +3217,7 @@ _gpgrt_fopencookie (void *_GPGRT__RESTRICT cookie, goto out; memset (&syshd, 0, sizeof syshd); - err = es_create (&stream, cookie, &syshd, functions, modeflags, + err = es_create (&stream, cookie, &syshd, io_functions, modeflags, xmode, 0); if (err) goto out; @@ -3265,14 +3265,14 @@ do_fdopen (int filedes, const char *mode, int no_close, int with_locked_list) if (!err && stream) { - stream->intern->func_ioctl = func_fd_ioctl; if ((modeflags & O_NONBLOCK)) - err = func_fd_ioctl (cookie, COOKIE_IOCTL_NONBLOCK, "", NULL); + err = stream->intern->func_ioctl (cookie, COOKIE_IOCTL_NONBLOCK, + "", NULL); } out: if (err && create_called) - (*estream_functions_fd.func_close) (cookie); + (*estream_functions_fd.public.func_close) (cookie); return stream; } @@ -3332,7 +3332,7 @@ do_fpopen (FILE *fp, const char *mode, int no_close, int with_locked_list) out: if (err && create_called) - (*estream_functions_fp.func_close) (cookie); + (*estream_functions_fp.public.func_close) (cookie); return stream; } @@ -3391,7 +3391,7 @@ do_w32open (HANDLE hd, const char *mode, leave: if (err && create_called) - (*estream_functions_w32.func_close) (cookie); + (*estream_functions_w32.public.func_close) (cookie); return stream; } diff --git a/src/gpgrt-int.h b/src/gpgrt-int.h index d69fe2c..f74dc5d 100644 --- a/src/gpgrt-int.h +++ b/src/gpgrt-int.h @@ -50,6 +50,26 @@ gpg_err_code_t _gpgrt_lock_destroy (gpgrt_lock_t *lockhd); gpg_err_code_t _gpgrt_yield (void); +/* Local definitions for estream. */ + +/* + * A private cookie function to implement an internal IOCTL service. + * and ist IOCTL numbers. + */ +typedef int (*cookie_ioctl_function_t) (void *cookie, int cmd, + void *ptr, size_t *len); +#define COOKIE_IOCTL_SNATCH_BUFFER 1 +#define COOKIE_IOCTL_NONBLOCK 2 + +/* An internal variant of gpgrt_cookie_close_function_t with a slot + for the ioctl function. */ +struct cookie_io_functions_s +{ + struct _gpgrt_cookie_io_functions public; + cookie_ioctl_function_t func_ioctl; +}; + + /* Local prototypes for estream. */ int _gpgrt_es_init (void); void _gpgrt_set_syscall_clamp (void (*pre)(void), void (*post)(void)); -- 2.9.3 From justus at g10code.com Wed Oct 19 12:20:43 2016 From: justus at g10code.com (Justus Winter) Date: Wed, 19 Oct 2016 12:20:43 +0200 Subject: [PATCH libgpg-error 3/4] estream: Track the kind of backend used. In-Reply-To: <20161019102044.6469-1-justus@g10code.com> References: <20161019102044.6469-1-justus@g10code.com> Message-ID: <20161019102044.6469-3-justus@g10code.com> * src/estream.c (struct _gpgrt_stream_internal): Add 'kind'. (init_stream_obj): New parameter 'kind', initialize field. (es_create): New parameter 'kind'. Update all callers. * src/gpgrt-int.h (gpgrt_stream_backend_kind_t): New type. Signed-off-by: Justus Winter --- src/estream.c | 39 ++++++++++++++++++++++----------------- src/gpgrt-int.h | 11 +++++++++++ 2 files changed, 33 insertions(+), 17 deletions(-) diff --git a/src/estream.c b/src/estream.c index 1cc4001..7ef687a 100644 --- a/src/estream.c +++ b/src/estream.c @@ -202,6 +202,7 @@ struct _gpgrt_stream_internal gpgrt_lock_t lock; /* Lock. Used by *_stream_lock(). */ + gpgrt_stream_backend_kind_t kind; void *cookie; /* Cookie. */ void *opaque; /* Opaque data. */ unsigned int modeflags; /* Flags for the backend. */ @@ -1991,9 +1992,11 @@ es_empty (estream_t stream) static void init_stream_obj (estream_t stream, void *cookie, es_syshd_t *syshd, + gpgrt_stream_backend_kind_t kind, struct cookie_io_functions_s functions, unsigned int modeflags, unsigned int xmode) { + stream->intern->kind = kind; stream->intern->cookie = cookie; stream->intern->opaque = NULL; stream->intern->offset = 0; @@ -2076,6 +2079,7 @@ es_deinitialize (estream_t stream) */ static int es_create (estream_t *stream, void *cookie, es_syshd_t *syshd, + gpgrt_stream_backend_kind_t kind, struct cookie_io_functions_s functions, unsigned int modeflags, unsigned int xmode, int with_locked_list) { @@ -2106,7 +2110,8 @@ es_create (estream_t *stream, void *cookie, es_syshd_t *syshd, stream_new->unread_buffer_size = sizeof (stream_internal_new->unread_buffer); stream_new->intern = stream_internal_new; - init_stream_obj (stream_new, cookie, syshd, functions, modeflags, xmode); + init_stream_obj (stream_new, cookie, syshd, kind, functions, modeflags, + xmode); init_stream_lock (stream_new); err = do_list_add (stream_new, with_locked_list); @@ -2813,7 +2818,7 @@ doreadline (estream_t _GPGRT__RESTRICT stream, size_t max_length, goto out; memset (&syshd, 0, sizeof syshd); - err = es_create (&line_stream, line_stream_cookie, &syshd, + err = es_create (&line_stream, line_stream_cookie, &syshd, BACKEND_MEM, estream_functions_mem, O_RDWR, 1, 0); if (err) goto out; @@ -3064,8 +3069,8 @@ _gpgrt_fopen (const char *_GPGRT__RESTRICT path, syshd.type = ES_SYSHD_FD; syshd.u.fd = fd; create_called = 1; - err = es_create (&stream, cookie, &syshd, estream_functions_fd, modeflags, - xmode, 0); + err = es_create (&stream, cookie, &syshd, BACKEND_FD, + estream_functions_fd, modeflags, xmode, 0); if (err) goto out; @@ -3121,7 +3126,7 @@ _gpgrt_mopen (void *_GPGRT__RESTRICT data, size_t data_n, size_t data_len, memset (&syshd, 0, sizeof syshd); create_called = 1; - err = es_create (&stream, cookie, &syshd, + err = es_create (&stream, cookie, &syshd, BACKEND_MEM, estream_functions_mem, modeflags, xmode, 0); out: @@ -3155,8 +3160,8 @@ _gpgrt_fopenmem (size_t memlimit, const char *_GPGRT__RESTRICT mode) return NULL; memset (&syshd, 0, sizeof syshd); - if (es_create (&stream, cookie, &syshd, estream_functions_mem, modeflags, - xmode, 0)) + if (es_create (&stream, cookie, &syshd, BACKEND_MEM, + estream_functions_mem, modeflags, xmode, 0)) (*estream_functions_mem.public.func_close) (cookie); return stream; @@ -3217,8 +3222,8 @@ _gpgrt_fopencookie (void *_GPGRT__RESTRICT cookie, goto out; memset (&syshd, 0, sizeof syshd); - err = es_create (&stream, cookie, &syshd, io_functions, modeflags, - xmode, 0); + err = es_create (&stream, cookie, &syshd, BACKEND_USER, io_functions, + modeflags, xmode, 0); if (err) goto out; @@ -3260,7 +3265,7 @@ do_fdopen (int filedes, const char *mode, int no_close, int with_locked_list) syshd.type = ES_SYSHD_FD; syshd.u.fd = filedes; create_called = 1; - err = es_create (&stream, cookie, &syshd, estream_functions_fd, + err = es_create (&stream, cookie, &syshd, BACKEND_FD, estream_functions_fd, modeflags, xmode, with_locked_list); if (!err && stream) @@ -3326,7 +3331,7 @@ do_fpopen (FILE *fp, const char *mode, int no_close, int with_locked_list) syshd.type = ES_SYSHD_FD; syshd.u.fd = fp? fileno (fp): -1; create_called = 1; - err = es_create (&stream, cookie, &syshd, estream_functions_fp, + err = es_create (&stream, cookie, &syshd, BACKEND_FP, estream_functions_fp, modeflags, xmode, with_locked_list); out: @@ -3386,8 +3391,8 @@ do_w32open (HANDLE hd, const char *mode, syshd.type = ES_SYSHD_HANDLE; syshd.u.handle = hd; create_called = 1; - err = es_create (&stream, cookie, &syshd, estream_functions_w32, - modeflags, xmode, with_locked_list); + err = es_create (&stream, cookie, &syshd, BACKEND_W32, + estream_functions_w32, modeflags, xmode, with_locked_list); leave: if (err && create_called) @@ -3565,8 +3570,8 @@ _gpgrt_freopen (const char *_GPGRT__RESTRICT path, syshd.type = ES_SYSHD_FD; syshd.u.fd = fd; create_called = 1; - init_stream_obj (stream, cookie, &syshd, estream_functions_fd, - modeflags, xmode); + init_stream_obj (stream, cookie, &syshd, BACKEND_FD, + estream_functions_fd, modeflags, xmode); leave: @@ -4559,8 +4564,8 @@ _gpgrt_tmpfile (void) syshd.type = ES_SYSHD_FD; syshd.u.fd = fd; create_called = 1; - err = es_create (&stream, cookie, &syshd, estream_functions_fd, modeflags, - 0, 0); + err = es_create (&stream, cookie, &syshd, BACKEND_FD, estream_functions_fd, + modeflags, 0, 0); out: if (err) diff --git a/src/gpgrt-int.h b/src/gpgrt-int.h index f74dc5d..2b13350 100644 --- a/src/gpgrt-int.h +++ b/src/gpgrt-int.h @@ -69,6 +69,17 @@ struct cookie_io_functions_s cookie_ioctl_function_t func_ioctl; }; +typedef enum + { + BACKEND_MEM, + BACKEND_FD, + BACKEND_W32, + BACKEND_FP, + BACKEND_USER, + BACKEND_W32_POLLABLE, + } gpgrt_stream_backend_kind_t; + + /* Local prototypes for estream. */ int _gpgrt_es_init (void); -- 2.9.3 From justus at g10code.com Wed Oct 19 12:20:41 2016 From: justus at g10code.com (Justus Winter) Date: Wed, 19 Oct 2016 12:20:41 +0200 Subject: [PATCH libgpg-error 1/4] estream: Rework modestring handling. Message-ID: <20161019102044.6469-1-justus@g10code.com> * src/estream.c (X_SAMETHREAD, X_SYSOPEN): New macros. (parse_mode): Rework how information flows from here to 'es_create'. Instead of using an integer flag per mode, use flags. (init_stream_obj): Adapt accordingly. (es_create): Likewise. (_gpgrt_fopen): Likewise. (_gpgrt_mopen): Likewise. (_gpgrt_fopenmem): Likewise. (_gpgrt_fopencookie): Likewise. (_gpgrt_fdopen): Likewise. (_gpgrt_fpopen): Likewise. (do_w32open): Likewise. (_gpgrt_freopen): Likewise. Signed-off-by: Justus Winter --- src/estream.c | 90 +++++++++++++++++++++++++++++------------------------------ 1 file changed, 44 insertions(+), 46 deletions(-) diff --git a/src/estream.c b/src/estream.c index 95d7211..8901a80 100644 --- a/src/estream.c +++ b/src/estream.c @@ -1664,6 +1664,10 @@ func_file_create (void **cookie, int *filedes, +/* Flags used by parse_mode and friends. */ +#define X_SAMETHREAD (1 << 0) +#define X_SYSOPEN (1 << 1) + /* Parse the mode flags of fopen et al. In addition to the POSIX * defined mode flags keyword parameters are supported. These are * key/value pairs delimited by comma and optional white spaces. @@ -1705,15 +1709,14 @@ func_file_create (void **cookie, int *filedes, */ static int parse_mode (const char *modestr, - unsigned int *modeflags, int *samethread, int *sysopen, + unsigned int *modeflags, + unsigned int *r_xmode, unsigned int *r_cmode) { unsigned int omode, oflags, cmode; int got_cmode = 0; - *samethread = 0; - if (sysopen) - *sysopen = 0; + *r_xmode = 0; switch (*modestr) { @@ -1795,7 +1798,7 @@ parse_mode (const char *modestr, _set_errno (EINVAL); return -1; } - *samethread = 1; + *r_xmode |= X_SAMETHREAD; } else if (!strncmp (modestr, "nonblock", 8)) { @@ -1815,8 +1818,7 @@ parse_mode (const char *modestr, _set_errno (EINVAL); return -1; } - if (sysopen) - *sysopen = 1; + *r_xmode |= X_SYSOPEN; } } if (!got_cmode) @@ -1988,7 +1990,7 @@ static void init_stream_obj (estream_t stream, void *cookie, es_syshd_t *syshd, gpgrt_cookie_io_functions_t functions, - unsigned int modeflags, int samethread) + unsigned int modeflags, unsigned int xmode) { stream->intern->cookie = cookie; stream->intern->opaque = NULL; @@ -2009,7 +2011,7 @@ init_stream_obj (estream_t stream, stream->intern->deallocate_buffer = 0; stream->intern->printable_fname = NULL; stream->intern->printable_fname_inuse = 0; - stream->intern->samethread = !!samethread; + stream->intern->samethread = !! (xmode & X_SAMETHREAD); stream->intern->onclose = NULL; stream->data_len = 0; @@ -2073,7 +2075,7 @@ es_deinitialize (estream_t stream) static int es_create (estream_t *stream, void *cookie, es_syshd_t *syshd, gpgrt_cookie_io_functions_t functions, unsigned int modeflags, - int samethread, int with_locked_list) + unsigned int xmode, int with_locked_list) { estream_internal_t stream_internal_new; estream_t stream_new; @@ -2102,7 +2104,7 @@ es_create (estream_t *stream, void *cookie, es_syshd_t *syshd, stream_new->unread_buffer_size = sizeof (stream_internal_new->unread_buffer); stream_new->intern = stream_internal_new; - init_stream_obj (stream_new, cookie, syshd, functions, modeflags, samethread); + init_stream_obj (stream_new, cookie, syshd, functions, modeflags, xmode); init_stream_lock (stream_new); err = do_list_add (stream_new, with_locked_list); @@ -3037,8 +3039,8 @@ estream_t _gpgrt_fopen (const char *_GPGRT__RESTRICT path, const char *_GPGRT__RESTRICT mode) { - unsigned int modeflags, cmode; - int samethread, sysopen, create_called; + unsigned int modeflags, cmode, xmode; + int create_called; estream_t stream; void *cookie; int err; @@ -3049,7 +3051,7 @@ _gpgrt_fopen (const char *_GPGRT__RESTRICT path, cookie = NULL; create_called = 0; - err = parse_mode (mode, &modeflags, &samethread, &sysopen, &cmode); + err = parse_mode (mode, &modeflags, &xmode, &cmode); if (err) goto out; @@ -3061,7 +3063,7 @@ _gpgrt_fopen (const char *_GPGRT__RESTRICT path, syshd.u.fd = fd; create_called = 1; err = es_create (&stream, cookie, &syshd, estream_functions_fd, modeflags, - samethread, 0); + xmode, 0); if (err) goto out; @@ -3101,12 +3103,11 @@ _gpgrt_mopen (void *_GPGRT__RESTRICT data, size_t data_n, size_t data_len, int create_called = 0; estream_t stream = NULL; void *cookie = NULL; - unsigned int modeflags; - int samethread; + unsigned int modeflags, xmode; int err; es_syshd_t syshd; - err = parse_mode (mode, &modeflags, &samethread, NULL, NULL); + err = parse_mode (mode, &modeflags, &xmode, NULL); if (err) goto out; @@ -3119,7 +3120,7 @@ _gpgrt_mopen (void *_GPGRT__RESTRICT data, size_t data_n, size_t data_len, memset (&syshd, 0, sizeof syshd); create_called = 1; err = es_create (&stream, cookie, &syshd, - estream_functions_mem, modeflags, samethread, 0); + estream_functions_mem, modeflags, xmode, 0); out: @@ -3134,15 +3135,14 @@ _gpgrt_mopen (void *_GPGRT__RESTRICT data, size_t data_n, size_t data_len, estream_t _gpgrt_fopenmem (size_t memlimit, const char *_GPGRT__RESTRICT mode) { - unsigned int modeflags; - int samethread; + unsigned int modeflags, xmode; estream_t stream = NULL; void *cookie = NULL; es_syshd_t syshd; /* Memory streams are always read/write. We use MODE only to get the append flag. */ - if (parse_mode (mode, &modeflags, &samethread, NULL, NULL)) + if (parse_mode (mode, &modeflags, &xmode, NULL)) return NULL; modeflags |= O_RDWR; @@ -3154,7 +3154,7 @@ _gpgrt_fopenmem (size_t memlimit, const char *_GPGRT__RESTRICT mode) memset (&syshd, 0, sizeof syshd); if (es_create (&stream, cookie, &syshd, estream_functions_mem, modeflags, - samethread, 0)) + xmode, 0)) (*estream_functions_mem.func_close) (cookie); if (stream) @@ -3204,8 +3204,7 @@ _gpgrt_fopencookie (void *_GPGRT__RESTRICT cookie, const char *_GPGRT__RESTRICT mode, gpgrt_cookie_io_functions_t functions) { - unsigned int modeflags; - int samethread; + unsigned int modeflags, xmode; estream_t stream; int err; es_syshd_t syshd; @@ -3213,13 +3212,13 @@ _gpgrt_fopencookie (void *_GPGRT__RESTRICT cookie, stream = NULL; modeflags = 0; - err = parse_mode (mode, &modeflags, &samethread, NULL, NULL); + err = parse_mode (mode, &modeflags, &xmode, NULL); if (err) goto out; memset (&syshd, 0, sizeof syshd); err = es_create (&stream, cookie, &syshd, functions, modeflags, - samethread, 0); + xmode, 0); if (err) goto out; @@ -3232,8 +3231,8 @@ _gpgrt_fopencookie (void *_GPGRT__RESTRICT cookie, static estream_t do_fdopen (int filedes, const char *mode, int no_close, int with_locked_list) { - unsigned int modeflags; - int samethread, sysopen, create_called; + unsigned int modeflags, xmode; + int create_called; estream_t stream; void *cookie; int err; @@ -3243,10 +3242,10 @@ do_fdopen (int filedes, const char *mode, int no_close, int with_locked_list) cookie = NULL; create_called = 0; - err = parse_mode (mode, &modeflags, &samethread, &sysopen, NULL); + err = parse_mode (mode, &modeflags, &xmode, NULL); if (err) goto out; - if (sysopen) + if (xmode & X_SYSOPEN) { /* Not allowed for fdopen. */ _set_errno (EINVAL); @@ -3262,7 +3261,7 @@ do_fdopen (int filedes, const char *mode, int no_close, int with_locked_list) syshd.u.fd = filedes; create_called = 1; err = es_create (&stream, cookie, &syshd, estream_functions_fd, - modeflags, samethread, with_locked_list); + modeflags, xmode, with_locked_list); if (!err && stream) { @@ -3296,8 +3295,8 @@ _gpgrt_fdopen_nc (int filedes, const char *mode) static estream_t do_fpopen (FILE *fp, const char *mode, int no_close, int with_locked_list) { - unsigned int modeflags, cmode; - int samethread, sysopen, create_called; + unsigned int modeflags, cmode, xmode; + int create_called; estream_t stream; void *cookie; int err; @@ -3307,10 +3306,10 @@ do_fpopen (FILE *fp, const char *mode, int no_close, int with_locked_list) cookie = NULL; create_called = 0; - err = parse_mode (mode, &modeflags, &samethread, &sysopen, &cmode); + err = parse_mode (mode, &modeflags, &xmode, &cmode); if (err) goto out; - if (sysopen) + if (xmode & X_SYSOPEN) { /* Not allowed for fpopen. */ _set_errno (EINVAL); @@ -3328,7 +3327,7 @@ do_fpopen (FILE *fp, const char *mode, int no_close, int with_locked_list) syshd.u.fd = fp? fileno (fp): -1; create_called = 1; err = es_create (&stream, cookie, &syshd, estream_functions_fp, - modeflags, samethread, with_locked_list); + modeflags, xmode, with_locked_list); out: @@ -3368,8 +3367,7 @@ estream_t do_w32open (HANDLE hd, const char *mode, int no_close, int with_locked_list) { - unsigned int modeflags, cmode; - int samethread; + unsigned int modeflags, cmode, xmode; int create_called = 0; estream_t stream = NULL; void *cookie = NULL; @@ -3377,7 +3375,7 @@ do_w32open (HANDLE hd, const char *mode, es_syshd_t syshd; /* For obvious reasons we ignore sysmode here. */ - err = parse_mode (mode, &modeflags, &samethread, NULL, &cmode); + err = parse_mode (mode, &modeflags, &xmode, &cmode); if (err) goto leave; @@ -3389,7 +3387,7 @@ do_w32open (HANDLE hd, const char *mode, syshd.u.handle = hd; create_called = 1; err = es_create (&stream, cookie, &syshd, estream_functions_w32, - modeflags, samethread, with_locked_list); + modeflags, xmode, with_locked_list); leave: if (err && create_called) @@ -3540,8 +3538,8 @@ _gpgrt_freopen (const char *_GPGRT__RESTRICT path, if (path) { - unsigned int modeflags, cmode; - int dummy, samethread, create_called; + unsigned int modeflags, cmode, xmode, dummy; + int create_called; void *cookie; int fd; es_syshd_t syshd; @@ -3549,13 +3547,13 @@ _gpgrt_freopen (const char *_GPGRT__RESTRICT path, cookie = NULL; create_called = 0; - samethread = stream->intern->samethread; + xmode = stream->intern->samethread ? X_SAMETHREAD : 0; lock_stream (stream); es_deinitialize (stream); - err = parse_mode (mode, &modeflags, &dummy, NULL, &cmode); + err = parse_mode (mode, &modeflags, &dummy, &cmode); if (err) goto leave; (void)dummy; @@ -3568,7 +3566,7 @@ _gpgrt_freopen (const char *_GPGRT__RESTRICT path, syshd.u.fd = fd; create_called = 1; init_stream_obj (stream, cookie, &syshd, estream_functions_fd, - modeflags, samethread); + modeflags, xmode); leave: -- 2.9.3 From wk at gnupg.org Wed Oct 19 12:41:02 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 19 Oct 2016 12:41:02 +0200 Subject: gpg-agent shell variable output In-Reply-To: <87zimi64fb.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 05 Oct 2016 14:23:20 -0400") References: <87shsa7v8e.fsf@alice.fifthhorseman.net> <87k2dmhniy.fsf@wheatstone.g10code.de> <87fuoa7m62.fsf@alice.fifthhorseman.net> <87lgy2fzmc.fsf@wheatstone.g10code.de> <87zimi64fb.fsf@alice.fifthhorseman.net> Message-ID: <878ttkoc3l.fsf@wheatstone.g10code.de> On Wed, 5 Oct 2016 20:23, dkg at fifthhorseman.net said: >> $ gpg-connect-agent '/datafile -' 'getinfo socket_name' /echo /bye >> /run/user/1000/gnupg/S.gpg-agent >> >> (In a script I would suggest to replace "/bye" by " > in this example, you appear to be asking users to change their scripts > and stop expecting the old behavior and keep working, by explicitly > removing functionality that people had been relying on without any I do not see what I change here. The above suggestion is to cope for systemd being able to tell gpg-agent an arbitrary socket. I do not think that this woul be a good idea at all but at least we have a way to _partly_ cope with that. In case you meant my suggestion to replace the /bye with a redirection to stdin - that is a general precaution programs should do if they are not prepared to send input on stdin. It does not change anything. > I'm aware of this, but to a person setting up GnuPG, it's bewildering to > have --enable-ssh-socket but then --extra-socket FILENAME. If we're > deprecating things and tuning the interface, we should aim for as > regular and predictable an interface as possible. The whole discussions is based on Justus' idea to listen on --extra-socket by default. This changed the original idea and is the cause for that whole bike shedding on socket names. > * "--extra-socket" still doesn't suggest to the user what they're > signing up for They need to read the manual to see for what --extra-socket or its semi-alias --browser-socket is useful. Even with the now changed defaults the socket names are short enough; the longest on Debian would be: /run/user/1000/gnupg/d.8jec5q33fzegs887crd7wgh8/S.gpg-agent.browser or character more for higher UIDs. On other platforms we need to prefix the above with "/var" and the entire thing will still work as a socket name. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From uri at mit.edu Wed Oct 19 12:57:26 2016 From: uri at mit.edu (Uri Blumenthal) Date: Wed, 19 Oct 2016 10:57:26 +0000 Subject: the "brand" GnuPG, (was: proposal python-gnupg2) In-Reply-To: <201610190914.26159.bernhard@intevation.de> References: <87insx8404.fsf@servo.finestructure.net> <87twcaorfc.fsf@alice.fifthhorseman.net> <201610180857.21253.bernhard@intevation.de>, <201610190914.26159.bernhard@intevation.de> Message-ID: The two thought immediately coming to mind when PGP and GPG are mentioned are: - PGP started email and file security for privet users, but got commercialized; - GPG picked up from PGP and is its free replacement, provided by GNU. >From user point of view there probably isn't any other distinction. Sent from my iPad > On Oct 19, 2016, at 03:14, Bernhard Reiter wrote: > > Hi, > > what is (or should be) our "brand" (name): > > Wikipedia writes > "Brand is a name, sign, symbol, slogan or anything that is used to identify > and distinguish a specific product, service, or business." [1] > > So what is a good brand name for the "The GnuPG Project"? > > The naming principles recorded in wikipedia [2] are too profit-oriented > for my taste, let me pick some product name qualities that apply to us: > > * They strategically distinguish the product from its competitors [..] > * They hold appeal for the product?s target audience > > Am Dienstag 18 Oktober 2016 08:57:17 schrieb Bernhard Reiter: >>>> The brand recognition is specifically highest about "gnupg" not "gpg". >>> >>> I have no idea whether this is true or not. How are you measuring it? >> >> My observation over a couple of years. Feedback from people that get >> exposed to OpenPGP. > > The problem I've notived with the name "OpenPGP" is its length. It is a five > syllable word. Nobody seems to type or say "OpenPGP" with joy because of its > length and difficulty of prounciation (in English). People will mostly fall > back to "PGP". > > GPG and PGP are too close to each other to offer a sufficient distinction. > While GPG seems to have overtaken PGP in world-wide usage by far, people still > mix it up. When reading articles in the general press, it is often mixed up. > > "GnuPG" scores better on the appeal (for usage) because it is shorter to write > and easier to say. "GnuPG can be remembered better and is more different to > the competing proprietary product "PGP" and the similiar named standard. > > Am Dienstag 18 Oktober 2016 17:04:25 schrieb Uri Blumenthal: >> One quick point: as far as I know, the highest "brand recognition" today is >> gpg, probably followed by PGP (at least among those who remember :)), gnupg >> being a distant third. >> >> And I've been with PGP development since its inception. > > Uri, thanks for your observation! > Given that you are long time crypto expert, you may belong to a group which > is skilled in making a distinction between pgp and gpg. People farer away from > the topic are less able to. > > My goal is to let many more people get the benefits of "The GnuPG Project" > and so far "GnuPG" seems the name best suited for doing so. > > Best Regards, > Bernhard > > > [1] https://en.wikipedia.org/wiki/Brand_%28disambiguation%29 > [2] https://en.wikipedia.org/wiki/Product_naming#Principles > > -- > 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 > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From wk at gnupg.org Wed Oct 19 12:53:34 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 19 Oct 2016 12:53:34 +0200 Subject: [pkg-gnupg-maint] Bug#839991: gnupg-agent: 'allow-emacs-pinentry' setting in agent conf makes gpg2 respond no secret key In-Reply-To: <87twciy65e.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 11 Oct 2016 16:36:45 -0400") References: <87shs84n5t.fsf@fsfe.org> <87a8ef2869.fsf@alice.fifthhorseman.net> <87ponb5icr.fsf@wheatstone.g10code.de> <87twciy65e.fsf@alice.fifthhorseman.net> Message-ID: <874m48obip.fsf@wheatstone.g10code.de> On Tue, 11 Oct 2016 22:36, dkg at fifthhorseman.net said: > So a pinentry implementation is expected to say something other than > "GPG_ERR_UNKNOWN_OPTION" when it sees an option it recognizes, but knows > it will have no way of implementing. is that right? That seems to be That depends on whether the pinentry considers missing support for this option important enough to fail. > Is this sort of expectation documented somewhere? Would an implementer > of a new pinentry (or someone trying to use pinentry directly) be > expected to know this? New pinentries should use the framework of the standard pinentry. Recent pinentries support the option and will always return OK in that case. The whole problem here was a bug in the emacs pinentry. > fwiw, i still don't really understand the logic behind gpg-agent's > strictness around allow-external-passphrase-cache: [...] > libsecret on debian). Neither of these pinentry implementations will > report GPG_ERR_UNKNOWN_OPTION, but only one of them will actually > "respect" the flag in the sense of querying the secret service. Is this > logic correct? I think so. IIRC, we had to implement it this way to make it work in All Cases (tm). Neal might know more about it. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From arnaud.fontaine at ssi.gouv.fr Wed Oct 19 12:55:39 2016 From: arnaud.fontaine at ssi.gouv.fr (Arnaud Fontaine) Date: Wed, 19 Oct 2016 12:55:39 +0200 Subject: [PATCH] scd: Generation of ECC keys on-board (OpenPGP card 3) In-Reply-To: <1261eb8c-d779-b34a-7d60-d17c964058c7@fsij.org> References: <5800C59B.2020305@ssi.gouv.fr> <1261eb8c-d779-b34a-7d60-d17c964058c7@fsij.org> Message-ID: <5807512B.8080307@ssi.gouv.fr> > Thank you for your patch. The patch is malformed somehow. Perhaps, > your MUA or MTA wrapped some lines. Sorry for that, I will pay more attention in future submissions. > Anyway, I think that I understand your changes. > > I modified the protocol of KEY-DATA to gpg-agent. It is not limited > to a single character, so, "curve" and "kdf" are better. I also > modified for support of EdDSA and Curve25519 (the prefix 0x40 and > PUBKEY_ALGO_EDDSA). > > Then, commit is pushed to master. I will test your as soon as the agent is also updated . From justus at g10code.com Wed Oct 19 13:36:50 2016 From: justus at g10code.com (Justus Winter) Date: Wed, 19 Oct 2016 13:36:50 +0200 Subject: gpg-agent shell variable output In-Reply-To: <878ttkoc3l.fsf@wheatstone.g10code.de> References: <87shsa7v8e.fsf@alice.fifthhorseman.net> <87k2dmhniy.fsf@wheatstone.g10code.de> <87fuoa7m62.fsf@alice.fifthhorseman.net> <87lgy2fzmc.fsf@wheatstone.g10code.de> <87zimi64fb.fsf@alice.fifthhorseman.net> <878ttkoc3l.fsf@wheatstone.g10code.de> Message-ID: <87lgxk1sfh.fsf@europa.jade-hamburg.de> Werner Koch writes: > Even with the now changed defaults the socket names are short enough; > the longest on Debian would be: > > /run/user/1000/gnupg/d.8jec5q33fzegs887crd7wgh8/S.gpg-agent.browser > > or character more for higher UIDs. On other platforms we need to prefix > the above with "/var" and the entire thing will still work as a socket > name. As I have demonstrated, the size of sun_path restricts the length of the relative path to the socket. It does *not* restrict the length of the absolute path to the socket. Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From justus at g10code.com Wed Oct 19 14:07:41 2016 From: justus at g10code.com (Justus Winter) Date: Wed, 19 Oct 2016 14:07:41 +0200 Subject: [PINENTRY PATCH] add efl-based frontend In-Reply-To: References: <20161012113515.675d5a30@Sir.Pimpleton> <87y41swi1i.fsf@europa.jade-hamburg.de> Message-ID: <87inso1r02.fsf@europa.jade-hamburg.de> Mike Blumenkrantz writes: > On Thu, Oct 13, 2016 at 8:28 AM Justus Winter wrote: >> The formatting of the commit message, however, does not. Details can >> be found in the already mentioned doc/HACKING file. At the very least, >> try to make it blend in with the other commit messages ;) > > Can you elaborate on exactly which parts need changes? I tried to follow > the policy in that file, but there did not seem to be much which could > apply to adding new frontends like this. We write whole sentences, the first word starts with a capital letter, and we end sentences with a period. We include ChangeLog-style entries for all affected files. We start with a one-line summary that starts with a component followed by a colon, a space, and a whole sentence. All of that should be obvious by just averaging over some of the recent commit messages even without looking at the documentation. I realize that all of that is a matter of taste, and one cannot expect everyone to hunt down the docs, and follow it to the letter. I don't believe we are particularly picky about this, but your message really sticks out. Cheers, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From dkg at fifthhorseman.net Wed Oct 19 14:50:12 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 19 Oct 2016 08:50:12 -0400 Subject: gpg-agent shell variable output In-Reply-To: <87lgxk1sfh.fsf@europa.jade-hamburg.de> References: <87shsa7v8e.fsf@alice.fifthhorseman.net> <87k2dmhniy.fsf@wheatstone.g10code.de> <87fuoa7m62.fsf@alice.fifthhorseman.net> <87lgy2fzmc.fsf@wheatstone.g10code.de> <87zimi64fb.fsf@alice.fifthhorseman.net> <878ttkoc3l.fsf@wheatstone.g10code.de> <87lgxk1sfh.fsf@europa.jade-hamburg.de> Message-ID: <87eg3cfqpn.fsf@alice.fifthhorseman.net> On Wed 2016-10-19 07:36:50 -0400, Justus Winter wrote: > As I have demonstrated, the size of sun_path restricts the length of the > relative path to the socket. It does *not* restrict the length of the > absolute path to the socket. I think you demonstrated that it's possible to create a socket with a longer name. Do you have a technique for retrieving the filesystem location of a socket whose name is longer than sun_path? Thanks for your help on sorting this stuff out, this arbitrary limitation of POSIX has been a problem in many places. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From zmike at samsung.com Wed Oct 19 16:01:37 2016 From: zmike at samsung.com (Mike Blumenkrantz) Date: Wed, 19 Oct 2016 10:01:37 -0400 Subject: [PINENTRY PATCH] add efl-based frontend In-Reply-To: <87inso1r02.fsf@europa.jade-hamburg.de> References: <20161012113515.675d5a30@Sir.Pimpleton> <87y41swi1i.fsf@europa.jade-hamburg.de> <87inso1r02.fsf@europa.jade-hamburg.de> Message-ID: <20161019100137.66563eb7@Sir.Pimpleton> On Wed, 19 Oct 2016 14:07:41 +0200 Justus Winter wrote: > Mike Blumenkrantz writes: > > On Thu, Oct 13, 2016 at 8:28 AM Justus Winter > > wrote: > >> The formatting of the commit message, however, does not. Details > >> can be found in the already mentioned doc/HACKING file. At the > >> very least, try to make it blend in with the other commit > >> messages ;) > > > > Can you elaborate on exactly which parts need changes? I tried to > > follow the policy in that file, but there did not seem to be much > > which could apply to adding new frontends like this. > > We write whole sentences, the first word starts with a capital letter, > and we end sentences with a period. We include ChangeLog-style > entries for all affected files. We start with a one-line summary > that starts with a component followed by a colon, a space, and a > whole sentence. > > All of that should be obvious by just averaging over some of the > recent commit messages even without looking at the documentation. > > I realize that all of that is a matter of taste, and one cannot expect > everyone to hunt down the docs, and follow it to the letter. I don't > believe we are particularly picky about this, but your message really > sticks out. > > > Cheers, > Justus Hi, Thanks for your clarification. I've attached a new version of the patch which I believe addresses all the issues you have cited in both the contents of the patch and the commit log. Since we are being very technical about the commit log, and you specifically cited the docs, I'd like to point out that nowhere in the docs/HACKING file (https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/HACKING#l21) does it say anything about capitalization or punctuation. The prefixing that you've mentioned, while common in commit messages, is referred to something that is "usually" present, and it has no example for the addition of new components. Furthermore, listing files with their changes is also not in this document, nor is it done in every commit: the top-most commit that I was working off in the tree is https://git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git;a=commit;h=a383ddeb76463ddcf5aca2fb38847ea3158c42a7 and does not include it. Based on this disconnect, it's easy to see why someone like me who has been working off very direct RFC-style specifications recently would produce a commit log which "stands out" :) I'd be happy to submit a patch for the docs/HACKING file which addresses these discrepancies to avoid any potential confusion with future contributors. Regards, Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-efl-Add-an-efl-based-frontend-for-pinentry.patch Type: text/x-patch Size: 25787 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From justus at g10code.com Wed Oct 19 16:09:26 2016 From: justus at g10code.com (Justus Winter) Date: Wed, 19 Oct 2016 16:09:26 +0200 Subject: gpg-agent shell variable output In-Reply-To: <87eg3cfqpn.fsf@alice.fifthhorseman.net> References: <87shsa7v8e.fsf@alice.fifthhorseman.net> <87k2dmhniy.fsf@wheatstone.g10code.de> <87fuoa7m62.fsf@alice.fifthhorseman.net> <87lgy2fzmc.fsf@wheatstone.g10code.de> <87zimi64fb.fsf@alice.fifthhorseman.net> <878ttkoc3l.fsf@wheatstone.g10code.de> <87lgxk1sfh.fsf@europa.jade-hamburg.de> <87eg3cfqpn.fsf@alice.fifthhorseman.net> Message-ID: <87funs1ld5.fsf@europa.jade-hamburg.de> Daniel Kahn Gillmor writes: > On Wed 2016-10-19 07:36:50 -0400, Justus Winter wrote: >> As I have demonstrated, the size of sun_path restricts the length of the >> relative path to the socket. It does *not* restrict the length of the >> absolute path to the socket. > > I think you demonstrated that it's possible to create a socket with a > longer name. Do you have a technique for retrieving the filesystem > location of a socket whose name is longer than sun_path? No, and I don't see why that is necessary here. getsockname is only recently used by gpg-agent in case the sockets are given using --supervised, and then we do not need to know their name to supervise the sockets or to set some environment variable. There are two more uses for the socket names, 1/ as a fallback file for the pinentry to touch after messing with the tty (no idea what's going on here, that's what the comment says), 2/ one can ask the gpg-agent for the location of the agent's socket and the ssh socket using the 'getinfo' command, but I don't see any value in that because in order to talk to the agent one needs to know the socket location, and the ssh socket's name is easily derived from the socket name. Cheers, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From wk at gnupg.org Wed Oct 19 19:24:22 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 19 Oct 2016 19:24:22 +0200 Subject: gpg-agent shell variable output In-Reply-To: <87lgxk1sfh.fsf@europa.jade-hamburg.de> (Justus Winter's message of "Wed, 19 Oct 2016 13:36:50 +0200") References: <87shsa7v8e.fsf@alice.fifthhorseman.net> <87k2dmhniy.fsf@wheatstone.g10code.de> <87fuoa7m62.fsf@alice.fifthhorseman.net> <87lgy2fzmc.fsf@wheatstone.g10code.de> <87zimi64fb.fsf@alice.fifthhorseman.net> <878ttkoc3l.fsf@wheatstone.g10code.de> <87lgxk1sfh.fsf@europa.jade-hamburg.de> Message-ID: <878ttkmeux.fsf@wheatstone.g10code.de> On Wed, 19 Oct 2016 13:36, justus at g10code.com said: > As I have demonstrated, the size of sun_path restricts the length of the You did this for Linux, right. But what about the various BSDs, AIX, HPUX, SunOS, OS X, QNX, Minix, Genode, Cygwin, etc? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From dkg at fifthhorseman.net Wed Oct 19 23:17:04 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 19 Oct 2016 17:17:04 -0400 Subject: gpg-agent shell variable output In-Reply-To: <87funs1ld5.fsf@europa.jade-hamburg.de> References: <87shsa7v8e.fsf@alice.fifthhorseman.net> <87k2dmhniy.fsf@wheatstone.g10code.de> <87fuoa7m62.fsf@alice.fifthhorseman.net> <87lgy2fzmc.fsf@wheatstone.g10code.de> <87zimi64fb.fsf@alice.fifthhorseman.net> <878ttkoc3l.fsf@wheatstone.g10code.de> <87lgxk1sfh.fsf@europa.jade-hamburg.de> <87eg3cfqpn.fsf@alice.fifthhorseman.net> <87funs1ld5.fsf@europa.jade-hamburg.de> Message-ID: <8737jsf38v.fsf@alice.fifthhorseman.net> On Wed 2016-10-19 10:09:26 -0400, Justus Winter wrote: > No, and I don't see why that is necessary here. getsockname is only > recently used by gpg-agent in case the sockets are given using > --supervised, and then we do not need to know their name to supervise > the sockets or to set some environment variable. There are two more > uses for the socket names, 1/ as a fallback file for the pinentry to > touch after messing with the tty (no idea what's going on here, that's > what the comment says), Isn't it also used by gpg-agent to decide whether to die due to it not listening on its own socket any more? > 2/ one can ask the gpg-agent for the location of the agent's socket > and the ssh socket using the 'getinfo' command, but I don't see any > value in that because in order to talk to the agent one needs to know > the socket location, and the ssh socket's name is easily derived from > the socket name. That assumes that the names match exactly and are derived as expected. it's possible to generate sockets with different names, and pass them to the agent directly. We've said publicly that the way to find the name of the ssh socket is to ask "getinfo ssh_socket_name", right? --dkg From dkg at fifthhorseman.net Thu Oct 20 03:18:24 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 19 Oct 2016 21:18:24 -0400 Subject: begging for pyme name change In-Reply-To: References: <87insx8404.fsf@servo.finestructure.net> <87bmyoy5a9.fsf@europa.jade-hamburg.de> <877f9c88t7.fsf@servo.finestructure.net> <87k2dbucl4.fsf@alice.fifthhorseman.net> Message-ID: <878ttjes2n.fsf@alice.fifthhorseman.net> Hi James-- On Wed 2016-10-19 06:36:37 -0400, James Henstridge wrote: > This hit my inbox while I was on vacation. Sorry for not getting back > to you sooner. no worries, and thank you for this response! > I obviously haven't had much time to work on my pygpgme binding, so > I'm not going to stand in the way of anyone who wants to do better. > > If you do want to reuse the "gpgme" package name, I would appreciate > if you could maintain API compatibility to avoid breaking code using > my module. this makes complete sense. > The test suite covers most of the module's API, but in parts depends > on the behaviour of GPG itself (in the past I've had to patch it after > gpg upgrades). So a good approach would be to check that it passes > with current gpg/gpgme, and then run it against your replacement > gpgpme package. That should give pretty good assurance that users of > the current library should continue to work. I also proposed this approach as a sensible initial step for an "API merge". Thank you very much for having maintained a decent test suite. > Do you need anything else from me? I don't know enough about python module namespace handovers. are there signing keys associated with a given module, or some other constraints on pypi? If upstream does decide to take you up on this offer of a handover, what would be the right approach to repoint the old project pages on launchpad to the upstream documentation? --dkg From dkg at fifthhorseman.net Thu Oct 20 03:16:11 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 19 Oct 2016 21:16:11 -0400 Subject: proposal python-gnupg2 In-Reply-To: <201610190922.04005.bernhard@intevation.de> References: <87insx8404.fsf@servo.finestructure.net> <87twcaorfc.fsf@alice.fifthhorseman.net> <201610180857.21253.bernhard@intevation.de> <201610190922.04005.bernhard@intevation.de> Message-ID: <87a8dzes6c.fsf@alice.fifthhorseman.net> On Wed 2016-10-19 03:22:03 -0400, Bernhard Reiter wrote: > Even if we would go with "python-gpgme", we would need to do add > a major version number to it like "python-gpgme2" and "python3-gpgme2", > because of the different API. If we manage to support the same API as the original python module, as i suggested upthread (and as James suggests downthread), then i see nothing wrong with keeping python-gpgme. That's some work to do, but it doesn't seem like it would necessarily be an outrageous amount of work to do. We do need to find someone to do it, though. --dkg From justus at g10code.com Thu Oct 20 09:54:12 2016 From: justus at g10code.com (Justus Winter) Date: Thu, 20 Oct 2016 09:54:12 +0200 Subject: begging for pyme name change In-Reply-To: <878ttjes2n.fsf@alice.fifthhorseman.net> References: <87insx8404.fsf@servo.finestructure.net> <87bmyoy5a9.fsf@europa.jade-hamburg.de> <877f9c88t7.fsf@servo.finestructure.net> <87k2dbucl4.fsf@alice.fifthhorseman.net> <878ttjes2n.fsf@alice.fifthhorseman.net> Message-ID: <87pomv1mmz.fsf@europa.jade-hamburg.de> Hello, Daniel Kahn Gillmor writes: > On Wed 2016-10-19 06:36:37 -0400, James Henstridge wrote: >> If you do want to reuse the "gpgme" package name, I would appreciate >> if you could maintain API compatibility to avoid breaking code using >> my module. > > this makes complete sense. Let's see. This is pygpgme: plaintext = BytesIO(b'Hello World\n') ciphertext = BytesIO() ctx = gpgme.Context() recipient = ctx.get_key('93C2240D6B8AA10AB28F701D2CF46B7FC97E6B0F') ctx.encrypt([recipient], gpgme.ENCRYPT_ALWAYS_TRUST, plaintext, ciphertext) This is pyme2: c = core.Context() c.set_armor(True) source = core.Data("Hallo Leute\n") sink = core.Data() keys = [] keys.append(c.get_key("A0FF4590BB6122EDEF6E3C542D727CC768697734", False)) keys.append(c.get_key("D695676BDCEDCC2CDD6152BCFE180B1DA9E3B0B2", False)) c.op_encrypt(keys, constants.ENCRYPT_ALWAYS_TRUST, source, sink) So the API of gpgme's .encrypt looks very similar to the .op_encrypt one From pyme2. With pyme3 I added automatic wrapping of data, so any object implementing the buffer protocol can be used anywhere libgpgme expects a gpgme_data_t object. That should cover BytesIO iirc, and if it doesn't fit, we could fix that. Now comes the tricky part. Pyme2's interface was deemed too unpythonic, so I created a new interface on top of the old one that was quite faithful to the C API. In particular, the 'op_' prefix was perceived as ugly. This is how the pyme3 shim looks: with pyme.Context(armor=True) as c: ciphertext, _, _ = c.encrypt("Hallo Leute\n".encode(), recipients=keys, sign=False, always_trust=True) I don't see how we could make that compatible with pygpgme's .encrypt. We could ship a 'gpgme' Python module that provides a pygpgme-compatible API on top of pyme, and keep our 'pyme' Python module where we can introduce new features. But maintaining two APIs and shipping two Python modules in order to take over the name does not make sense. Even less so since we still couldn't use the 'gpgme' Python module for the interface that we want to develop and promote for new users. I'm not convinced it is worth the effort. Cheers, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From gniibe at fsij.org Thu Oct 20 13:30:23 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 20 Oct 2016 20:30:23 +0900 Subject: two problems where fixes are needed Message-ID: <63ef3d09-c768-793c-7e2c-310d2483c3a8@fsij.org> I found two things to fix. (1) agent_write_private_key function in agent/findkey.c It fails with "No such file or directory" well when FORCE=1 and there is no file existed. When FORCE=1, it opens by es_fopen with "rb+,mode=-rw", so that it can examine the existing key. But, it fails if there is no file existed. Error recovery is needed. (2) snprintf and its second arg for the size. In the commit 9a34e2142b426b98c73fd888102ea1596bbce62a, I fixed a simple mistake of off-by-one error. I was lazy (not to read the man page of snprintf) when I write the original line, and cut&paste existing code somehow. Then, it resulted an error with "OPENPGP." with no number. Reading the man, I learned that snprintf assumes '\0' at the end for the size. Here are the list: ./build-aux/speedo/w32/g4wihelp.c:73: snprintf (buf, sizeof buf - 1, "$R0=%s\r\n$R1=%s\r\n", ./build-aux/speedo/w32/g4wihelp.c:78: snprintf (buf, sizeof buf - 1, ./build-aux/speedo/w32/g4wihelp.c:281: snprintf (buf, sizeof (buf) - 1, "error: %s: ec=%d\r\n", str, ./build-aux/speedo/w32/g4wihelp.c:578: snprintf (buf, sizeof (buf) - 1, ./common/get-passphrase.c:184: snprintf (line, DIM(line)-1, ./common/get-passphrase.c:253: snprintf (line, DIM(line)-1, "CLEAR_PASSPHRASE %s", cache_id); ./g10/cpr.c:56: snprintf (buf, sizeof buf -1, "%.20s X 100 100", what ); ./g10/cpr.c:58: snprintf (buf, sizeof buf -1, "%.20s %c %d %d", ./g10/cpr.c:359: snprintf (buf+buflen, DIM(buf) - buflen - 1, ./g10/passphrase.c:350: snprintf (buf, sizeof buf -1, "%d %d %d", ./g10/passphrase.c:450: snprintf (buf, sizeof buf -1, "%08lX%08lX %08lX%08lX %d 0", ./g10/call-agent.c:729: snprintf (line, DIM(line)-1, "SCD APDU %s", hexapdu); ./g10/call-agent.c:761: snprintf (line, DIM(line)-1, "KEYTOCARD %s%s %s OPENPGP.%d %s", ./g10/call-agent.c:905: snprintf (line, DIM(line)-1, "SCD WRITECERT %s", certidstr); ./g10/call-agent.c:959: snprintf (line, DIM(line)-1, "SCD WRITEKEY --force OPENPGP.%d", keyno); ./g10/call-agent.c:1022: snprintf (line, DIM(line)-1, "SCD GENKEY %s%s %s %d", ./g10/call-agent.c:1154: snprintf (line, DIM(line)-1, "SCD READCERT %s", certidstr); ./g10/call-agent.c:1205: snprintf (line, DIM(line)-1, "SCD PASSWD %s %d", reset, chvno); ./g10/call-agent.c:1233: snprintf (line, DIM(line)-1, "SCD CHECKPIN %s", serialno); ./g10/call-agent.c:1304: snprintf (line, DIM(line)-1, ./g10/call-agent.c:1361: snprintf (line, DIM(line)-1, "CLEAR_PASSPHRASE %s", cache_id); ./g10/call-agent.c:1390: snprintf (line, DIM(line)-1, "GET_CONFIRMATION %s", tmp); ./g10/call-agent.c:1577: snprintf (line, DIM(line)-1, "KEYINFO %s", hexkeygrip); ./g10/call-agent.c:1764: snprintf (line, DIM(line)-1, "READKEY %s%s", fromcard? "--card ":"", ./g10/call-agent.c:1829: snprintf (line, DIM(line)-1, "SIGKEY %s", keygrip); ./g10/call-agent.c:1837: snprintf (line, DIM(line)-1, "SETKEYDESC %s", desc); ./g10/call-agent.c:1969: snprintf (line, DIM(line)-1, "SETKEYDESC %s", desc); ./g10/call-agent.c:2062: snprintf (line, DIM(line)-1, "KEYWRAP_KEY %s", ./g10/call-agent.c:2124: snprintf (line, DIM(line)-1, "SETKEYDESC %s", desc); ./g10/call-agent.c:2185: snprintf (line, DIM(line)-1, "SETKEYDESC %s", desc); ./g10/call-agent.c:2192: snprintf (line, DIM(line)-1, "EXPORT_KEY %s%s%s %s", ./g10/call-agent.c:2244: snprintf (line, DIM(line)-1, "SETKEYDESC %s", desc); ./g10/call-agent.c:2251: snprintf (line, DIM(line)-1, "DELETE_KEY%s %s", ./g10/call-agent.c:2290: snprintf (line, DIM(line)-1, "SETKEYDESC %s", desc); ./g10/call-agent.c:2298: snprintf (line, DIM(line)-1, "PASSWD %s%s --verify %s", ./g10/call-agent.c:2303: snprintf (line, DIM(line)-1, "PASSWD %s%s %s%s %s", ./g10/openfile.c:151: snprintf (prompt, n-1, "%s [%s]: ", s, defname ); ./g10/openfile.c:153: snprintf (prompt, n-1, "%s: ", s ); ./scd/app-openpgp.c:1875: snprintf (prompt_buffer, promptsize-1, PROMPTSTRING, sigcount); ./agent/command.c:372: snprintf (line, DIM(line)-1, "PINENTRY_LAUNCHED %lu", pid); ./agent/command.c:2563: snprintf (keydata+keydatalen-1, 30, "(10:created-at10:%010lu))", timestamp); ./agent/call-pinentry.c:737: snprintf (line, DIM(line)-1, "SETQUALITYBAR %s", tmpstr? tmpstr:""); ./agent/call-pinentry.c:766: snprintf (line, DIM(line)-1, "SETQUALITYBAR_TT %s", tmpstr? tmpstr:""); ./agent/call-pinentry.c:890: snprintf (line, DIM(line)-1, "SETKEYINFO %c/%s", ./agent/call-pinentry.c:895: snprintf (line, DIM(line)-1, "SETKEYINFO --clear"); ./agent/call-pinentry.c:902: snprintf (line, DIM(line)-1, "SETDESC %s", desc_text); ./agent/call-pinentry.c:908: snprintf (line, DIM(line)-1, "SETPROMPT %s", ./agent/call-pinentry.c:927: snprintf (line, DIM(line)-1, "SETERROR %s", initial_errtext); ./agent/call-pinentry.c:937: snprintf (line, DIM(line)-1, "SETREPEATERROR %s", ./agent/call-pinentry.c:959: snprintf (line, DIM(line)-1, L_("SETERROR %s (try %d of %d)"), ./agent/call-pinentry.c:971: snprintf (line, DIM(line)-1, "SETREPEAT %s", L_("Repeat:")); ./agent/call-pinentry.c:1103: snprintf (line, DIM(line)-1, "SETKEYINFO %c/%s", ./agent/call-pinentry.c:1108: snprintf (line, DIM(line)-1, "SETKEYINFO --clear"); ./agent/call-pinentry.c:1117: snprintf (line, DIM(line)-1, "SETDESC %s", desc); ./agent/call-pinentry.c:1119: snprintf (line, DIM(line)-1, "RESET"); ./agent/call-pinentry.c:1125: snprintf (line, DIM(line)-1, "SETPROMPT %s", prompt); ./agent/call-pinentry.c:1140: snprintf (line, DIM(line)-1, "SETERROR %s", errtext); ./agent/call-pinentry.c:1208: snprintf (line, DIM(line)-1, "SETDESC %s", desc); ./agent/call-pinentry.c:1210: snprintf (line, DIM(line)-1, "RESET"); ./agent/call-pinentry.c:1224: snprintf (line, DIM(line)-1, "SETOK %s", ok); ./agent/call-pinentry.c:1238: snprintf (line, DIM(line)-1, "SETNOTOK %s", notok); ./agent/call-pinentry.c:1248: snprintf (line, DIM(line)-1, "SETCANCEL %s", notok); ./agent/call-pinentry.c:1285: snprintf (line, DIM(line)-1, "SETDESC %s", desc); ./agent/call-pinentry.c:1287: snprintf (line, DIM(line)-1, "RESET"); ./agent/call-pinentry.c:1301: snprintf (line, DIM(line)-1, "SETOK %s", ok_btn); ./agent/call-pinentry.c:1357: snprintf (line, DIM(line)-1, "SETDESC %s", desc); ./agent/call-pinentry.c:1359: snprintf (line, DIM(line)-1, "RESET"); ./agent/call-pinentry.c:1367: snprintf (line, DIM(line)-1, "SETOK %s", ok_btn); ./agent/call-pinentry.c:1468: snprintf (line, DIM(line)-1, "CLEARPASSPHRASE %c/%s", ./agent/call-scd.c:949: snprintf (line, DIM(line)-1, "PKDECRYPT %s", keyid); ./agent/call-scd.c:989: snprintf (line, DIM(line)-1, "READCERT %s", id); ./agent/call-scd.c:1025: snprintf (line, DIM(line)-1, "READKEY %s", id); ./agent/call-scd.c:1091: snprintf (line, DIM(line)-1, "WRITEKEY %s%s", force ? "--force " : "", id); ./sm/certreqgen.c:722: snprintf ((char*)keyparms, DIM (keyparms)-1, ./sm/call-agent.c:246: snprintf (line, DIM(line)-1, "SIGKEY %s", keygrip); ./sm/call-agent.c:254: snprintf (line, DIM(line)-1, "SETKEYDESC %s", desc); ./sm/call-agent.c:338: snprintf (line, DIM(line)-1, "SCD PKSIGN %s %s", hashopt, keyid); ./sm/call-agent.c:432: snprintf (line, DIM(line)-1, "SETKEY %s", keygrip); ./sm/call-agent.c:440: snprintf (line, DIM(line)-1, "SETKEYDESC %s", desc); ./sm/call-agent.c:597: snprintf (line, DIM(line)-1, "%sREADKEY %s", ./sm/call-agent.c:813: snprintf (line, DIM(line)-1, "ISTRUSTED %s", hexfpr); ./sm/call-agent.c:827: snprintf (line, DIM(line)-1, "ISTRUSTED %s", fpr); ./sm/call-agent.c:871: snprintf (line, DIM(line)-1, "MARKTRUSTED %s S %s", fpr, dnfmt); ./sm/call-agent.c:898: snprintf (line, DIM(line)-1, "HAVEKEY %s", hexkeygrip); ./sm/call-agent.c:1048: snprintf (line, DIM(line)-1, "SETKEYDESC %s", desc); ./sm/call-agent.c:1056: snprintf (line, DIM(line)-1, "PASSWD %s", hexkeygrip); ./sm/call-agent.c:1081: snprintf (line, DIM(line)-1, "GET_CONFIRMATION %s", desc); ./sm/call-agent.c:1153: snprintf (line, DIM(line)-1, "KEYINFO %s", hexkeygrip); ./sm/call-agent.c:1199: snprintf (line, DIM(line)-1, "GET_PASSPHRASE --data%s -- X X X %s", ./sm/call-agent.c:1244: snprintf (line, DIM(line)-1, "KEYWRAP_KEY %s", ./sm/call-agent.c:1338: snprintf (line, DIM(line)-1, "SETKEYDESC %s", desc); ./sm/call-agent.c:1345: snprintf (line, DIM(line)-1, "EXPORT_KEY %s", keygrip); ./sm/call-dirmngr.c:218: snprintf (line, DIM (line) - 1, "LDAPSERVER %s:%i:%s:%s:%s", ./sm/call-dirmngr.c:551: snprintf (line, DIM(line)-1, "ISVALID%s %s", ./sm/call-dirmngr.c:806: snprintf (line, DIM(line)-1, "LOOKUP%s %s", ./sm/call-dirmngr.c:864: snprintf (line, DIM(line)-1, "LOOKUP --single --cache-only 0x%s", hexfpr); -- From dkg at fifthhorseman.net Thu Oct 20 17:45:24 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 20 Oct 2016 11:45:24 -0400 Subject: begging for pyme name change In-Reply-To: <87pomv1mmz.fsf@europa.jade-hamburg.de> References: <87insx8404.fsf@servo.finestructure.net> <87bmyoy5a9.fsf@europa.jade-hamburg.de> <877f9c88t7.fsf@servo.finestructure.net> <87k2dbucl4.fsf@alice.fifthhorseman.net> <878ttjes2n.fsf@alice.fifthhorseman.net> <87pomv1mmz.fsf@europa.jade-hamburg.de> Message-ID: <87twc7c9d7.fsf@alice.fifthhorseman.net> On Thu 2016-10-20 03:54:12 -0400, Justus Winter wrote: > Now comes the tricky part. Pyme2's interface was deemed too unpythonic, > so I created a new interface on top of the old one that was quite > faithful to the C API. In particular, the 'op_' prefix was perceived as > ugly. This is how the pyme3 shim looks: > > with pyme.Context(armor=True) as c: > ciphertext, _, _ = c.encrypt("Hallo Leute\n".encode(), > recipients=keys, > sign=False, > always_trust=True) > > I don't see how we could make that compatible with pygpgme's .encrypt. I agree that these two context.encrypt() functions are incompatible on their face. However, it might be possible to inspect the types and number of the arguments and make an educated guess. something like: If the function receives exactly 4 arguments of type and none of them are kwargs, then follow the python-gpgme semantics (and maybe emit a warning encouraging transition to the preferred semantics?) What do you think? Are there other incompatibilities like this? > We could ship a 'gpgme' Python module that provides a pygpgme-compatible > API on top of pyme, and keep our 'pyme' Python module where we can > introduce new features. But maintaining two APIs and shipping two > Python modules in order to take over the name does not make sense. Even > less so since we still couldn't use the 'gpgme' Python module for the > interface that we want to develop and promote for new users. I agree that this dual-module approach isn't a healthy or useful one. I still think that taking over the python module name "gpgme" would be a good thing, though. This is might end up being frustrating bookkeeping work. But it's work that could help simplify things for future developers who are interested in using the GnuPG suite in python, which would be a serious win. It's certainly frustrating that there's no clear way to make a clean api break in a given python module namespace. It makes maintenance and ongoing support difficult. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From vinay_sajip at yahoo.co.uk Thu Oct 20 18:56:23 2016 From: vinay_sajip at yahoo.co.uk (Vinay Sajip) Date: Thu, 20 Oct 2016 16:56:23 +0000 (UTC) Subject: Using loopback pin entry with GnuPG 2.1 References: <574777160.1243146.1476982583037.ref@mail.yahoo.com> Message-ID: <574777160.1243146.1476982583037@mail.yahoo.com> I'm having trouble trying to get loopback pinentry working from my unit tests. Environment: Ubuntu 16.04 (64-bit), GnuPG 2.1.11/libgcrypt 1.6.5 $ cat ~/.gnupg/gpg-agent.conf allow-loopback-pinentry After creating this file, I logged out and logged in again. When I run gpg2 --pinentry-mode loopback --status-fd 2 --no-tty --homedir /home/vinay/projects/python-gnupg/keys --batch --passphrase-fd 0 --debug-quick-random --decrypt from a test script, I get errors (the first line is just for context): [GNUPG:] ENC_TO BCB77EF0C7648FEB 16 0 gpg: setting pinentry mode 'loopback' failed: Not supported [GNUPG:] ERROR set_pinentry_mode 67108924 I checked the gpg-agent process: $ ps -ef | grep gpg-agent | grep -v grep vinay 21402 21284 0 17:37 ? 00:00:00 gpg-agent --homedir /home/vinay/.gnupg --use-standard-socket --daemon I can't find any reference to the error code 67108924, nor can I see what I've done wrong in the setup. Can anyone enlighten me as to how to get my tests to run all the way through without popping up pinentry prompts or failing as above? Thanks and regards, Vinay Sajip From gniibe at fsij.org Fri Oct 21 05:18:48 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 21 Oct 2016 12:18:48 +0900 Subject: two problems where fixes are needed In-Reply-To: <63ef3d09-c768-793c-7e2c-310d2483c3a8@fsij.org> References: <63ef3d09-c768-793c-7e2c-310d2483c3a8@fsij.org> Message-ID: <1cbcfb7d-a97e-5494-7e03-12d97bfc15e9@fsij.org> Both problems are fixed in master. I read: https://www.gnu.org/software/gnulib/manual/gnulib.html#snprintf For systems which require the old style of snprintf like: snprintf (line, DIM(line)-1, "SETERROR %s", initial_errtext); line[DIM(line)-1] = 0; I think that it is better to detect such snprintf by configure to be replaced by substitute. -- From gniibe at fsij.org Fri Oct 21 14:51:26 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 21 Oct 2016 21:51:26 +0900 Subject: [PATCH] agent: Support of ECC key generation by scd In-Reply-To: <5800CE4B.9090609@ssi.gouv.fr> References: <5800CE4B.9090609@ssi.gouv.fr> Message-ID: Hello, On 10/14/2016 09:23 PM, Arnaud Fontaine wrote: > * g10/call-agent.c: Retrieving data sent by scdaemon when an ECC key > has been generated. > * g10/call-agent.h: Change in agent info structure to hold information > related to an ECC key generated by scdaemon. > * g10/keygen.c: Support of ECC key generation by scd > --- > g10/call-agent.c | 26 ++++++++++++++++++++++-- > g10/call-agent.h | 14 +++++++++++-- > g10/keygen.c | 61 > +++++++++++++++++++++++++++++++++++++++++++++++++------- > 3 files changed, 90 insertions(+), 11 deletions(-) I don't apply this patch. Instead, I changed READKEY command of gpg-agent so that it can support --card option. I also change scd/app-openpgp.c so that scdaemon's GENKEY and READKEY share same routine. Then, I changed g10/keygen.c with this feature. -- From gniibe at fsij.org Fri Oct 21 15:04:00 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 21 Oct 2016 22:04:00 +0900 Subject: [PATCH] gpg: Update card-edit wizard to support ECC key generation In-Reply-To: <5800DDE2.8080304@ssi.gouv.fr> References: <5800DDE2.8080304@ssi.gouv.fr> Message-ID: <95e93a73-4d9e-49c8-71dd-728610e78eb2@fsij.org> Hello, On 10/14/2016 10:30 PM, Arnaud Fontaine wrote: > * g10/card-util.c: Ask for key size only for RSA key generation. > * g10/keygen.c: Add algo parameter to deal with ECC key generation. > --- > g10/card-util.c | 51 +++++++++++++++++++++++++++++---------------------- > g10/keygen.c | 17 ++++++----------- > 2 files changed, 35 insertions(+), 33 deletions(-) I merge your change in: commit 161cb22f13bcd8cbdb08558d9926b2168a8297ac commit dafce6f698bec6e9d4c0125b90754d0687294e86 Then, I added code which fills parameters by getting information with KEY-ATTR from scdaemon. It is: commit d2653b1a6db90aed073194a51fd61023d69773ec I test with Gnuk Token, and key generation now works well for NIST P-256, Ed25519, etc. I noticed that it won't work with P-521. That's because the KDF paramerters are hard-coded in app-openpgp.c as "\x03\x01\x08\x07". It's for SHA-256 and AES-128. We need something like the function pk_ecdh_default_params in g10/ecdh.c. -- From wk at gnupg.org Mon Oct 24 09:09:59 2016 From: wk at gnupg.org (Werner Koch) Date: Mon, 24 Oct 2016 09:09:59 +0200 Subject: Using loopback pin entry with GnuPG 2.1 In-Reply-To: <574777160.1243146.1476982583037@mail.yahoo.com> (Vinay Sajip's message of "Thu, 20 Oct 2016 16:56:23 +0000 (UTC)") References: <574777160.1243146.1476982583037.ref@mail.yahoo.com> <574777160.1243146.1476982583037@mail.yahoo.com> Message-ID: <878ttegr3s.fsf@wheatstone.g10code.de> On Thu, 20 Oct 2016 18:56, vinay_sajip at yahoo.co.uk said: > $ cat ~/.gnupg/gpg-agent.conf > allow-loopback-pinentry > > After creating this file, I logged out and logged in again. When I run Sending a HUP (or "gpgconf --reload gpg-agent") would be sufficient to enable the option. Adn with 2.1.12 --allow-loopback-pinentry is anyway the default. > gpg: setting pinentry mode 'loopback' failed: Not supported > [GNUPG:] ERROR set_pinentry_mode 67108924 $ gpg-error 67108924 67108924 = (4, 60) = (GPG_ERR_SOURCE_GPGAGENT, GPG_ERR_NOT_SUPPORTED) \ = (GPG Agent, Not supported) gpg tells gpg-agent about the requested pinentry mode using an Assun OPTION command. This command errors out with the above error. To see what's going on, I suggest to enable logging for the agent. The best way to do this is by running watchgnupg --force /home/foo/.gnupg/S.log in a second terminal and add this to gpg-agent.conf: log-file socket:///home/foo/.gnupg/S.log verbose debug ipc The kill the agent you will see all commands send to the agent in the second terminal. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From wk at gnupg.org Mon Oct 24 09:15:24 2016 From: wk at gnupg.org (Werner Koch) Date: Mon, 24 Oct 2016 09:15:24 +0200 Subject: two problems where fixes are needed In-Reply-To: <1cbcfb7d-a97e-5494-7e03-12d97bfc15e9@fsij.org> (NIIBE Yutaka's message of "Fri, 21 Oct 2016 12:18:48 +0900") References: <63ef3d09-c768-793c-7e2c-310d2483c3a8@fsij.org> <1cbcfb7d-a97e-5494-7e03-12d97bfc15e9@fsij.org> Message-ID: <874m42gqur.fsf@wheatstone.g10code.de> On Fri, 21 Oct 2016 05:18, gniibe at fsij.org said: > snprintf (line, DIM(line)-1, "SETERROR %s", initial_errtext); > line[DIM(line)-1] = 0; I did this in the past but meanwhile we do not use the system's snprint but our own implementation from libgpg-error. See gnupg/common/util.h: /* Due to a bug in mingw32's snprintf related to the 'l' modifier and for increased portability we use our snprintf on all systems. */ #undef snprintf #define snprintf gpgrt_snprintf Thus a configure check is not required. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From wk at gnupg.org Mon Oct 24 09:24:56 2016 From: wk at gnupg.org (Werner Koch) Date: Mon, 24 Oct 2016 09:24:56 +0200 Subject: two problems where fixes are needed In-Reply-To: <63ef3d09-c768-793c-7e2c-310d2483c3a8@fsij.org> (NIIBE Yutaka's message of "Thu, 20 Oct 2016 20:30:23 +0900") References: <63ef3d09-c768-793c-7e2c-310d2483c3a8@fsij.org> Message-ID: <87zilufbuf.fsf@wheatstone.g10code.de> On Thu, 20 Oct 2016 13:30, gniibe at fsij.org said: > (1) agent_write_private_key function in agent/findkey.c > > It fails with "No such file or directory" well when FORCE=1 and there > is no file existed. You mean in the case a second process removed the file? > (2) snprintf and its second arg for the size. > ./g10/call-agent.c:761: snprintf (line, DIM(line)-1, [...] Before we switched to our own snprintf we took care of buggy snprintf implementations which appened a Nul behind the buffer. The -1 is a left-over over this. Given that tehse are constants I do not think it makes sense to change to remove the "-1". FWIW, for new code I use snprintf (buffer, sizeof buffer, [...] because DIM is never required as snprintf works only with byte strings and the DIM is thus identical to sizeof. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From gniibe at fsij.org Mon Oct 24 10:34:49 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 24 Oct 2016 17:34:49 +0900 Subject: two problems where fixes are needed In-Reply-To: <87zilufbuf.fsf@wheatstone.g10code.de> References: <63ef3d09-c768-793c-7e2c-310d2483c3a8@fsij.org> <87zilufbuf.fsf@wheatstone.g10code.de> Message-ID: <9aa063eb-937b-6532-1298-ee4d9218b67d@fsij.org> On 10/24/2016 04:24 PM, Werner Koch wrote: > On Thu, 20 Oct 2016 13:30, gniibe at fsij.org said: > >> (1) agent_write_private_key function in agent/findkey.c >> >> It fails with "No such file or directory" well when FORCE=1 and there >> is no file existed. > > You mean in the case a second process removed the file? I didn't mean a case of multiple processes. Today, I check the use cases of agent_write_private_key function, it seems that there is the private key file in all possible calls with FORCE=1. I encounter this issue when I debug scdaemon. I think I manually removed the private key file. Anyway, when call of agent_write_private_key function with FORCE=1 and there is no private key file, I think that it is good to creat the file. So, I think that my change makes sense. -- From wk at gnupg.org Mon Oct 24 10:40:25 2016 From: wk at gnupg.org (Werner Koch) Date: Mon, 24 Oct 2016 10:40:25 +0200 Subject: two problems where fixes are needed In-Reply-To: <9aa063eb-937b-6532-1298-ee4d9218b67d@fsij.org> (NIIBE Yutaka's message of "Mon, 24 Oct 2016 17:34:49 +0900") References: <63ef3d09-c768-793c-7e2c-310d2483c3a8@fsij.org> <87zilufbuf.fsf@wheatstone.g10code.de> <9aa063eb-937b-6532-1298-ee4d9218b67d@fsij.org> Message-ID: <87bmyaf8cm.fsf@wheatstone.g10code.de> On Mon, 24 Oct 2016 10:34, gniibe at fsij.org said: > Anyway, when call of agent_write_private_key function with FORCE=1 and > there is no private key file, I think that it is good to creat the > file. So, I think that my change makes sense. Agreed. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From arnaud.fontaine at ssi.gouv.fr Mon Oct 24 11:43:08 2016 From: arnaud.fontaine at ssi.gouv.fr (Arnaud Fontaine) Date: Mon, 24 Oct 2016 11:43:08 +0200 Subject: [PATCH] g10: Fix ECDH secret compressed/uncompressed format Message-ID: <580DD7AC.1060001@ssi.gouv.fr> * g10/ecdh.c (pk_ecdh_encrypt_with_shared_point): Improve detection of the uncompressed format, add leading zeros to the compressed format. --- g10/ecdh.c | 33 +++++++++++++++++++++++++-------- 1 file changed, 25 insertions(+), 8 deletions(-) diff --git a/g10/ecdh.c b/g10/ecdh.c index af1d844..ed855db 100644 --- a/g10/ecdh.c +++ b/g10/ecdh.c @@ -132,13 +132,30 @@ pk_ecdh_encrypt_with_shared_point (int is_encrypt, gcry_mpi_t shared_mpi, return err; } + /* Expected size of the x component */ secret_x_size = (nbits+7)/8; - log_assert (nbytes >= secret_x_size); - if ((nbytes & 1)) - /* Remove the "04" prefix of non-compressed format. */ - memmove (secret_x, secret_x+1, secret_x_size); - if (nbytes - secret_x_size) - memset (secret_x+secret_x_size, 0, nbytes-secret_x_size); + + if (nbytes > secret_x_size) + { + /* Un-compressed format expected, so it must start with 04 */ + log_assert (secret_x[0] == (byte)0x04); + + /* Remove the "04" prefix of non-compressed format. */ + memmove (secret_x, secret_x+1, secret_x_size); + + /* Zeroize the y component following */ + if (nbytes > secret_x_size) + memset (secret_x+secret_x_size, 0, nbytes-secret_x_size); + } + else + { + /* Compressed format expected, without leading zeros */ + if (nbytes < secret_x_size) + { + memmove (secret_x+(secret_x_size - nbytes), secret_x, nbytes); + memset (secret_x, 0, secret_x_size - nbytes); + } + } if (DBG_CRYPTO) log_printhex ("ECDH shared secret X is:", secret_x, secret_x_size ); @@ -235,8 +252,8 @@ pk_ecdh_encrypt_with_shared_point (int is_encrypt, gcry_mpi_t shared_mpi, return err; } gcry_md_write(h, "\x00\x00\x00\x01", 4); /* counter = 1 */ - gcry_md_write(h, secret_x, secret_x_size); /* x of the point X */ - gcry_md_write(h, message, message_size);/* KDF parameters */ + gcry_md_write(h, secret_x, secret_x_size); /* x of the point X */ + gcry_md_write(h, message, message_size); /* KDF parameters */ gcry_md_final (h); -- 2.9.3 From alon.barlev at gmail.com Mon Oct 24 19:05:43 2016 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Mon, 24 Oct 2016 20:05:43 +0300 Subject: [PATCH] gpg, gpgsm, python: atomic directory creation In-Reply-To: <1476867847-24352-1-git-send-email-alon.barlev@gmail.com> References: <87a8e0pvmh.fsf@wheatstone.g10code.de> <1476867847-24352-1-git-send-email-alon.barlev@gmail.com> Message-ID: Hi, Anything more I can do? Thanks! On 19 October 2016 at 12:04, Alon Bar-Lev wrote: > * lang/python/tests/Makefile.am, > tests/gpg/Makefile.am, > tests/gpgsm/Makefile.am: atomic directory creation. > > -- > Solves race in parallel build when mkdir fails if directory exists. > > Signed-off-by: Alon Bar-Lev > --- > lang/python/tests/Makefile.am | 2 +- > tests/gpg/Makefile.am | 2 +- > tests/gpgsm/Makefile.am | 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/lang/python/tests/Makefile.am b/lang/python/tests/Makefile.am > index aa88bdc..39f532c 100644 > --- a/lang/python/tests/Makefile.am > +++ b/lang/python/tests/Makefile.am > @@ -89,7 +89,7 @@ clean-local: > > > ./private-keys-v1.d/gpg-sample.stamp: $(private_keys) > - test -d ./private-keys-v1.d || mkdir ./private-keys-v1.d > + $(MKDIR_P) ./private-keys-v1.d > for k in $(private_keys); do \ > cp $$k private-keys-v1.d/$${k#$(test_srcdir)/}.key; \ > done > diff --git a/tests/gpg/Makefile.am b/tests/gpg/Makefile.am > index 2538f63..044bf3a 100644 > --- a/tests/gpg/Makefile.am > +++ b/tests/gpg/Makefile.am > @@ -90,7 +90,7 @@ export GNUPGHOME := $(abs_builddir) > export GPG_AGENT_INFO := > > ./private-keys-v1.d/gpg-sample.stamp: $(srcdir)/$(private_keys) > - test -d ./private-keys-v1.d || mkdir ./private-keys-v1.d > + $(MKDIR_P) ./private-keys-v1.d > for k in $(private_keys); do \ > cp $(srcdir)/$$k private-keys-v1.d/$$k.key; \ > done > diff --git a/tests/gpgsm/Makefile.am b/tests/gpgsm/Makefile.am > index 41645b6..46d6a9b 100644 > --- a/tests/gpgsm/Makefile.am > +++ b/tests/gpgsm/Makefile.am > @@ -70,7 +70,7 @@ export GPG_AGENT_INFO := > echo faked-system-time 1008241200 >> ./gpgsm.conf > > ./private-keys-v1.d/$(key_id).key: $(srcdir)/$(key_id) > - test -d ./private-keys-v1.d || mkdir ./private-keys-v1.d > + $(MKDIR_P) ./private-keys-v1.d > cp $(srcdir)/$(key_id) private-keys-v1.d/$(key_id).key > > ./trustlist.txt: > -- > 2.7.3 > From dkg at fifthhorseman.net Mon Oct 24 21:34:16 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 24 Oct 2016 15:34:16 -0400 Subject: byte-compiled python in gpgme download tarballs [was: Re: GnuPG Made Easy (GPGME) 1.7.0 released] In-Reply-To: <87twd8gvp1.fsf@europa.jade-hamburg.de> References: <87shstu0dr.fsf@wheatstone.g10code.de> <87r38d9izv.fsf@alice.fifthhorseman.net> <87twd8gvp1.fsf@europa.jade-hamburg.de> Message-ID: <874m41o81z.fsf@alice.fifthhorseman.net> On Thu 2016-09-22 04:55:38 -0400, Justus Winter wrote: > Daniel Kahn Gillmor writes: >> I'm a curious about the inclusion of .pyc (byte-compiled python) in the >> upstream tarball: >> >> 0 dkg at alice:~$ tar tj < gpgme-1.7.0.tar.bz2 | grep pyc >> gpgme-1.7.0/lang/python/pyme/__pycache__/ >> gpgme-1.7.0/lang/python/pyme/__pycache__/version.cpython-34.pyc >> gpgme-1.7.0/lang/python/pyme/__pycache__/__init__.cpython-34.pyc >> 0 dkg at alice:~$ >> >> Is this intentional, or an oversight? If it's intentional, what do you >> expect distributors to do with these files? > > That is not intentional, and strange, usually make distcheck is quite > strict, isn't it? Also, I just tried, and I cannot reproduce this. Somehow, this has happened again in 1.7.1: 0 dkg at alice:~$ wget -q -O- https://gnupg.org/ftp/gcrypt/gpgme/gpgme-1.7.1.tar.bz2 | tar tj | grep pyc gpgme-1.7.1/lang/python/pyme/__pycache__/ gpgme-1.7.1/lang/python/pyme/__pycache__/version.cpython-34.pyc gpgme-1.7.1/lang/python/pyme/__pycache__/__init__.cpython-34.pyc 0 dkg at alice:~$ It's not the end of the world, it'd be nice to avoid this happening for 1.7.2 :) --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From gniibe at fsij.org Tue Oct 25 03:49:51 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 25 Oct 2016 10:49:51 +0900 Subject: [PATCH] g10: Fix ECDH secret compressed/uncompressed format In-Reply-To: <580DD7AC.1060001@ssi.gouv.fr> References: <580DD7AC.1060001@ssi.gouv.fr> Message-ID: Hello, Thank you for your patch. Please clarify some points. On 10/24/2016 06:43 PM, Arnaud Fontaine wrote: > * g10/ecdh.c (pk_ecdh_encrypt_with_shared_point): Improve detection of > the uncompressed format, add leading zeros to the compressed format. I interpret that "the compressed format" means x-coordinate only in Jivsov's proposal: https://tools.ietf.org/html/draft-jivsov-ecc-compact-05 For ECDH, we don't need to care about the key generation constraint. I think that it is good for OpenPGP card specification to address the point format representation: 04 || X || Y or X only, with no prefix I think that the original compressed format of SEC (02 or 03 prefix) is covered by the patent by HP. -- From wk at gnupg.org Tue Oct 25 08:48:46 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 25 Oct 2016 08:48:46 +0200 Subject: [PATCH] g10: Fix ECDH secret compressed/uncompressed format In-Reply-To: <580DD7AC.1060001@ssi.gouv.fr> (Arnaud Fontaine's message of "Mon, 24 Oct 2016 11:43:08 +0200") References: <580DD7AC.1060001@ssi.gouv.fr> Message-ID: <87zilsdiup.fsf@wheatstone.g10code.de> On Mon, 24 Oct 2016 11:43, arnaud.fontaine at ssi.gouv.fr said: > + /* Un-compressed format expected, so it must start with 04 */ > + log_assert (secret_x[0] == (byte)0x04); SECRET_X is user provided data and thus you can't use assert here but must return a proper error. Can you please give examples why you need this patch? > + else > + { > + /* Compressed format expected, without leading zeros */ > + if (nbytes < secret_x_size) Please use an "else if ()" here. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From arnaud.fontaine at ssi.gouv.fr Tue Oct 25 09:14:45 2016 From: arnaud.fontaine at ssi.gouv.fr (Arnaud Fontaine) Date: Tue, 25 Oct 2016 09:14:45 +0200 Subject: [PATCH] g10: Fix ECDH secret compressed/uncompressed format In-Reply-To: References: <580DD7AC.1060001@ssi.gouv.fr> Message-ID: <580F0665.7010906@ssi.gouv.fr> Le 25/10/2016 03:49, NIIBE Yutaka a ?crit : > I interpret that "the compressed format" means x-coordinate only > in Jivsov's proposal: > > https://tools.ietf.org/html/draft-jivsov-ecc-compact-05 > > For ECDH, we don't need to care about the key generation constraint. > > I think that it is good for OpenPGP card specification to address > the point format representation: > > 04 || X || Y > > or > > X only, with no prefix > > I think that the original compressed format of SEC (02 or 03 prefix) > is covered by the patent by HP. My comment "Compressed format" is actually imprecise, it is the raw x coordinate (without any prefix), as it is the expected output shared secret of ECDH. From arnaud.fontaine at ssi.gouv.fr Tue Oct 25 09:22:11 2016 From: arnaud.fontaine at ssi.gouv.fr (Arnaud Fontaine) Date: Tue, 25 Oct 2016 09:22:11 +0200 Subject: [PATCH] g10: Fix ECDH secret compressed/uncompressed format In-Reply-To: <87zilsdiup.fsf@wheatstone.g10code.de> References: <580DD7AC.1060001@ssi.gouv.fr> <87zilsdiup.fsf@wheatstone.g10code.de> Message-ID: <580F0823.1000203@ssi.gouv.fr> Le 25/10/2016 08:48, Werner Koch a ?crit : > On Mon, 24 Oct 2016 11:43, arnaud.fontaine at ssi.gouv.fr said: > >> + /* Un-compressed format expected, so it must start with 04 */ >> + log_assert (secret_x[0] == (byte)0x04); > > SECRET_X is user provided data and thus you can't use assert here but > must return a proper error. There is an assert for the length of this input in the existing code, that's why I also used an assert. > Can you please give examples why you need this patch? As depicted by the name of the variable, it should contain the shared secret computed by both parts following the ECDH algorithm, which is the x coordinate only, not the coordinate pair (x,y). The existing code extracts the x coordinate from the coordinate pair, but giving only the x coordinate should be also be ok. >> + else >> + { >> + /* Compressed format expected, without leading zeros */ >> + if (nbytes < secret_x_size) > > Please use an "else if ()" here. Well, I am sorry but I don't see what test can be done here. From gniibe at fsij.org Tue Oct 25 09:26:39 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 25 Oct 2016 16:26:39 +0900 Subject: [PATCH] g10: Fix ECDH secret compressed/uncompressed format In-Reply-To: <87zilsdiup.fsf@wheatstone.g10code.de> References: <580DD7AC.1060001@ssi.gouv.fr> <87zilsdiup.fsf@wheatstone.g10code.de> Message-ID: <29ec82f1-cae1-cf96-99b3-f4d04392e044@fsij.org> On 10/25/2016 03:48 PM, Werner Koch wrote: > Can you please give examples why you need this patch? Arnaud is working for the support of another OpenPGP card implementation by JavaCard API. His implementation returns X-coordinate only data for ECDH, I suppose. The data is coming from scdaemon which is computed by the card. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From arnaud.fontaine at ssi.gouv.fr Tue Oct 25 09:57:37 2016 From: arnaud.fontaine at ssi.gouv.fr (Arnaud Fontaine) Date: Tue, 25 Oct 2016 09:57:37 +0200 Subject: [PATCH] g10: Fix ECDH secret compressed/uncompressed format In-Reply-To: <580F0823.1000203@ssi.gouv.fr> References: <580DD7AC.1060001@ssi.gouv.fr> <87zilsdiup.fsf@wheatstone.g10code.de> <580F0823.1000203@ssi.gouv.fr> Message-ID: <580F1071.6020908@ssi.gouv.fr> >>> + else >>> + { >>> + /* Compressed format expected, without leading zeros */ >>> + if (nbytes < secret_x_size) >> >> Please use an "else if ()" here. > Well, I am sorry but I don't see what test can be done here. Oh ok, sorry, I see what you mean From justus at g10code.com Tue Oct 25 13:01:13 2016 From: justus at g10code.com (Justus Winter) Date: Tue, 25 Oct 2016 13:01:13 +0200 Subject: byte-compiled python in gpgme download tarballs [was: Re: GnuPG Made Easy (GPGME) 1.7.0 released] In-Reply-To: <874m41o81z.fsf@alice.fifthhorseman.net> References: <87shstu0dr.fsf@wheatstone.g10code.de> <87r38d9izv.fsf@alice.fifthhorseman.net> <87twd8gvp1.fsf@europa.jade-hamburg.de> <874m41o81z.fsf@alice.fifthhorseman.net> Message-ID: <878ttcsneu.fsf@europa.jade-hamburg.de> Daniel Kahn Gillmor writes: > [ Unknown signature status ] > On Thu 2016-09-22 04:55:38 -0400, Justus Winter wrote: >> Daniel Kahn Gillmor writes: >>> I'm a curious about the inclusion of .pyc (byte-compiled python) in the >>> upstream tarball: >>> >>> 0 dkg at alice:~$ tar tj < gpgme-1.7.0.tar.bz2 | grep pyc >>> gpgme-1.7.0/lang/python/pyme/__pycache__/ >>> gpgme-1.7.0/lang/python/pyme/__pycache__/version.cpython-34.pyc >>> gpgme-1.7.0/lang/python/pyme/__pycache__/__init__.cpython-34.pyc >>> 0 dkg at alice:~$ >>> >>> Is this intentional, or an oversight? If it's intentional, what do you >>> expect distributors to do with these files? >> >> That is not intentional, and strange, usually make distcheck is quite >> strict, isn't it? Also, I just tried, and I cannot reproduce this. > > Somehow, this has happened again in 1.7.1: > > 0 dkg at alice:~$ wget -q -O- https://gnupg.org/ftp/gcrypt/gpgme/gpgme-1.7.1.tar.bz2 | tar tj | grep pyc > gpgme-1.7.1/lang/python/pyme/__pycache__/ > gpgme-1.7.1/lang/python/pyme/__pycache__/version.cpython-34.pyc > gpgme-1.7.1/lang/python/pyme/__pycache__/__init__.cpython-34.pyc > 0 dkg at alice:~$ > > It's not the end of the world, it'd be nice to avoid this happening for > 1.7.2 :) I tried to reproduce this again, and failed again. This must be specific to how Werner builds the distribution tarballs. % tar tf gpgme-1.7.1-beta47.tar.bz2|grep pyc|wc --lines 0 Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From arnaud.fontaine at ssi.gouv.fr Tue Oct 25 13:43:08 2016 From: arnaud.fontaine at ssi.gouv.fr (Arnaud Fontaine) Date: Tue, 25 Oct 2016 13:43:08 +0200 Subject: [PATCH] g10: ECDH shared point format. Message-ID: <580F454C.9070201@ssi.gouv.fr> * g10/ecdh.c (pk_ecdh_encrypt_with_shared_point): Improve handling of ECDH shared point format. Signed-off-by: Arnaud Fontaine --- g10/ecdh.c | 33 +++++++++++++++++++++++++-------- 1 file changed, 25 insertions(+), 8 deletions(-) diff --git a/g10/ecdh.c b/g10/ecdh.c index af1d844..ba59acc 100644 --- a/g10/ecdh.c +++ b/g10/ecdh.c @@ -132,13 +132,30 @@ pk_ecdh_encrypt_with_shared_point (int is_encrypt, gcry_mpi_t shared_mpi, return err; } + /* Expected size of the x component */ secret_x_size = (nbits+7)/8; - log_assert (nbytes >= secret_x_size); - if ((nbytes & 1)) - /* Remove the "04" prefix of non-compressed format. */ - memmove (secret_x, secret_x+1, secret_x_size); - if (nbytes - secret_x_size) - memset (secret_x+secret_x_size, 0, nbytes-secret_x_size); + + if (nbytes > secret_x_size) + { + /* Uncompressed format expected, so it must start with 04 */ + if (secret_x[0] != (byte)0x04) + { + return gpg_error (GPG_ERR_BAD_DATA); + } + + /* Remove the "04" prefix of non-compressed format. */ + memmove (secret_x, secret_x+1, secret_x_size); + + /* Zeroize the y component following */ + if (nbytes > secret_x_size) + memset (secret_x+secret_x_size, 0, nbytes-secret_x_size); + } + else if (nbytes < secret_x_size) + { + /* Raw share secret (x coordinate), without leading zeros */ + memmove (secret_x+(secret_x_size - nbytes), secret_x, nbytes); + memset (secret_x, 0, secret_x_size - nbytes); + } if (DBG_CRYPTO) log_printhex ("ECDH shared secret X is:", secret_x, secret_x_size ); @@ -235,8 +252,8 @@ pk_ecdh_encrypt_with_shared_point (int is_encrypt, gcry_mpi_t shared_mpi, return err; } gcry_md_write(h, "\x00\x00\x00\x01", 4); /* counter = 1 */ - gcry_md_write(h, secret_x, secret_x_size); /* x of the point X */ - gcry_md_write(h, message, message_size);/* KDF parameters */ + gcry_md_write(h, secret_x, secret_x_size); /* x of the point X */ + gcry_md_write(h, message, message_size); /* KDF parameters */ gcry_md_final (h); -- 2.9.3 From wk at gnupg.org Tue Oct 25 14:09:29 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 25 Oct 2016 14:09:29 +0200 Subject: [PATCH] g10: Fix ECDH secret compressed/uncompressed format In-Reply-To: <580F0665.7010906@ssi.gouv.fr> (Arnaud Fontaine's message of "Tue, 25 Oct 2016 09:14:45 +0200") References: <580DD7AC.1060001@ssi.gouv.fr> <580F0665.7010906@ssi.gouv.fr> Message-ID: <87oa28d406.fsf@wheatstone.g10code.de> On Tue, 25 Oct 2016 09:14, arnaud.fontaine at ssi.gouv.fr said: > My comment "Compressed format" is actually imprecise, it is the raw x coordinate > (without any prefix), as it is the expected output shared secret of ECDH. I see. For EdDSA we extended the meaning of the flag octet like this: Flag Description ---- ----------- 0x04 Standard flag for uncompressed format 0x40 Native point format of the curve follows 0x41 Only X coordinate follows. 0x42 Only Y coordinate follows. We only use 0x40 for EdDSA but the the new flag 0x41 is what I suggest for your use. We can prefix the x-coordinate in scdaemon with 0x41 so that we do not run in ambiguities in other parts of the code. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From wk at gnupg.org Tue Oct 25 14:10:40 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 25 Oct 2016 14:10:40 +0200 Subject: [PATCH] g10: Fix ECDH secret compressed/uncompressed format In-Reply-To: <580F0823.1000203@ssi.gouv.fr> (Arnaud Fontaine's message of "Tue, 25 Oct 2016 09:22:11 +0200") References: <580DD7AC.1060001@ssi.gouv.fr> <87zilsdiup.fsf@wheatstone.g10code.de> <580F0823.1000203@ssi.gouv.fr> Message-ID: <87k2cwd3y7.fsf@wheatstone.g10code.de> On Tue, 25 Oct 2016 09:22, arnaud.fontaine at ssi.gouv.fr said: > There is an assert for the length of this input in the existing code, that's why > I also used an assert. The length is controller by the parser but not the value of the octet string. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From wk at gnupg.org Tue Oct 25 14:15:35 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 25 Oct 2016 14:15:35 +0200 Subject: byte-compiled python in gpgme download tarballs In-Reply-To: <878ttcsneu.fsf@europa.jade-hamburg.de> (Justus Winter's message of "Tue, 25 Oct 2016 13:01:13 +0200") References: <87shstu0dr.fsf@wheatstone.g10code.de> <87r38d9izv.fsf@alice.fifthhorseman.net> <87twd8gvp1.fsf@europa.jade-hamburg.de> <874m41o81z.fsf@alice.fifthhorseman.net> <878ttcsneu.fsf@europa.jade-hamburg.de> Message-ID: <87funkd3q0.fsf@wheatstone.g10code.de> On Tue, 25 Oct 2016 13:01, justus at g10code.com said: > I tried to reproduce this again, and failed again. This must be > specific to how Werner builds the distribution tarballs. What I do is cd ~/s/gpgme git tag -u KEY -m MESSAGE gpgme-N.M.K ./autogen.sh --force cd ~/b/gpgme ~/s/gpgme/configure --enable-maintainer-mode make distcheck It is possible that other files are in gpgme but "make dist" and "make disthceck" handle this case just fine. I guess the problem is due to the use of the distutils thingy. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From jeroen.ooms at stat.ucla.edu Tue Oct 25 16:24:13 2016 From: jeroen.ooms at stat.ucla.edu (Jeroen Ooms) Date: Tue, 25 Oct 2016 16:24:13 +0200 Subject: read/parse pubkeys in gpgme without importing Message-ID: Is there a way to let gpgme read/parse a (set of) keys in memory, without actually importing it in the keyring? So suppose I have a file with an armored set of keys like this: http://pgp.mit.edu/pks/lookup?op=get&search=jeroen+ooms Can I parse this file in gpgme to print the name/email/fingerprints of the pubkeys without actually importing into my keyring? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristian.fiskerstrand at sumptuouscapital.com Tue Oct 25 18:14:58 2016 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 25 Oct 2016 18:14:58 +0200 Subject: read/parse pubkeys in gpgme without importing In-Reply-To: References: Message-ID: <609b25f5-32cd-a683-ec39-21753cfcbd64@sumptuouscapital.com> On 10/25/2016 04:24 PM, Jeroen Ooms wrote: > Is there a way to let gpgme read/parse a (set of) keys in memory, without > actually importing it in the keyring? So suppose I have a file with an > armored set of keys like this: > > http://pgp.mit.edu/pks/lookup?op=get&search=jeroen+ooms > > Can I parse this file in gpgme to print the name/email/fingerprints of the > pubkeys without actually importing into my keyring? > you can always use a temporary keyring, but some import is likely necessary in order to perform validation of the various packets, in the general case you also need to ensure the keyblock validity to begin with through trustdb calculation -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Divide et impera Divide and govern -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From nathan.musoke at gmail.com Tue Oct 25 19:29:04 2016 From: nathan.musoke at gmail.com (Nathan Musoke) Date: Wed, 26 Oct 2016 06:29:04 +1300 Subject: DCO signoff Message-ID: <20161025172904.GA5427@arch0.localdomain> GnuPG Developer's Certificate of Origin. Version 1.0 ===================================================== By making a contribution to the GnuPG project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the free software license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate free software license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same free software license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the free software license(s) involved. Signed-off-by: Nathan Musoke -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-keys Size: 14038 bytes Desc: PGP Key 0x385B75C7327E99DC. URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From nathan.musoke at gmail.com Tue Oct 25 19:35:20 2016 From: nathan.musoke at gmail.com (Nathan Musoke) Date: Wed, 26 Oct 2016 06:35:20 +1300 Subject: [PATCH 1/2] doc: Typo fix Message-ID: <20161025173520.GB5427@arch0.localdomain> -- Signed-off-by: Nathan Musoke --- doc/gpg.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/gpg.texi b/doc/gpg.texi index 6cc35e0..1bc1f40 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -1853,7 +1853,7 @@ Maximum depth of a certification chain (default is 5). @opindex no-sig-cache Do not cache the verification status of key signatures. Caching gives a much better performance in key listings. However, if -you suspect that your public keyring is not save against write +you suspect that your public keyring is not safe against write modifications, you can use this option to disable the caching. It probably does not make sense to disable it because all kind of damage can be done if someone else has write access to your public keyring. -- 2.10.1 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-keys Size: 14038 bytes Desc: PGP Key 0x385B75C7327E99DC. URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From nathan.musoke at gmail.com Tue Oct 25 19:36:23 2016 From: nathan.musoke at gmail.com (Nathan Musoke) Date: Wed, 26 Oct 2016 06:36:23 +1300 Subject: [PATCH 2/2] doc: Typo fix Message-ID: <20161025173623.GC5427@arch0.localdomain> -- Signed-off-by: Nathan Musoke --- doc/gpg.texi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/gpg.texi b/doc/gpg.texi index 1bc1f40..5bd6444 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -2752,8 +2752,8 @@ protected by the signature. @opindex emit-version Force inclusion of the version string in ASCII armored output. If given once only the name of the program and the major number is -emitted, given twice the minor is also emitted, given triple -the micro is added, and given quad an operating system identification +emitted, given twice the minor is also emitted, given thrice +the micro is added, and given four times an operating system identification is also emitted. @option{--no-emit-version} (default) disables the version line. -- 2.10.1 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-keys Size: 14038 bytes Desc: PGP Key 0x385B75C7327E99DC. URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From reavertm at gmail.com Tue Oct 25 22:28:58 2016 From: reavertm at gmail.com (Maciej Mrozowski) Date: Tue, 25 Oct 2016 22:28:58 +0200 Subject: gpgconf --launch ignores gpgconf.conf? Message-ID: <10341419.Z49yr6ZIgR@liwardyna> Hello, I'm working on making ssh agent startup script (for DE) work[1] and I would like gpgconf to start gpg-agent with 'enable-ssh-support'. $ cat /etc/gnupg/gpgconf.conf * gpg-agent enable-ssh-support $ gpgconf --list-config k:*: r:::gpg-agent:enable-ssh-support:: But it doesn't work, 'gpgconf --launch gpg-agent' starts it without required option: $ ps -U maciek -x | grep gpg-agent 4570 ? Ss 0:00 gpg-agent --homedir /home/maciek/.gnupg --use- standard-socket --daemon 5843 pts/1 S+ 0:00 grep --colour=auto gpg-agent $ ssh-add Could not open a connection to your authentication agent. I know I could enable it in ~/.gnupg/gpg-agent.conf, but that's not the point. Is this bug-report worthy or (more likely) I'm missing something obvious? This is gnupg-2.1.15 (it seems there are no patches applied on top of it). 1. https://gitweb.gentoo.org/repo/gentoo.git/tree/kde-plasma/plasma-workspace/ files/10-agent-startup.sh -- regards MM -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: This is a digitally signed message part. URL: From gniibe at fsij.org Wed Oct 26 02:31:39 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 26 Oct 2016 09:31:39 +0900 Subject: [PATCH] g10: Fix ECDH secret compressed/uncompressed format In-Reply-To: <87oa28d406.fsf@wheatstone.g10code.de> References: <580DD7AC.1060001@ssi.gouv.fr> <580F0665.7010906@ssi.gouv.fr> <87oa28d406.fsf@wheatstone.g10code.de> Message-ID: Hello, Arnaud, please be patient. Examining your patch, I realized that we need to clarify things for ECDH by smartcard/token. On 10/25/2016 09:09 PM, Werner Koch wrote: > I see. For EdDSA we extended the meaning of the flag octet like this: > > Flag Description > ---- ----------- > 0x04 Standard flag for uncompressed format > 0x40 Native point format of the curve follows > 0x41 Only X coordinate follows. > 0x42 Only Y coordinate follows. > > We only use 0x40 for EdDSA but the the new flag 0x41 is what I suggest > for your use. We can prefix the x-coordinate in scdaemon with 0x41 so > that we do not run in ambiguities in other parts of the code. I agree. Let us clarify. Do 0x41 and 0x42 mean standard MPI (of big endian)? I think that the representation between scdaemon and GnuPG should always have the prefix to avoid ambiguities. Arnaud, could you please consider a possibility to change your OpenPGP card implementation to have the prefix 0x41 for the result of ECDH decryption, or padding zero to be always fixed size of bytes? No, it's not decided yet, but I'd like to see how we can change (which part of code and how). * * * Besides, in GnuPG and libgcrypt, ECDH with Curve25519 (X25519) also uses the prefix 0x40 for its point representation. It is little-endian and x-coordinate only. In Gnuk 1.2 (my own implementation of OpenPGP card), it doesn't use any prefix of ECDH with Curve25519 (X25519). It just uses its native format. For ECDH with Curve25519 (X25519), it is scdaemon which handles the prefix of 0x40. For public key, scdaemon adds the prefix 0x40 to the returned value from Gnuk, which is returned to GnuPG. For decryption, scdaemon removes the prefix 0x40 from GnuPG's representation and sends it to the token. Then, the token returns native 32-byte of x-coordinate only to scdaemon. Scdaemon adds the prefix 0x40 to the bytes to send back to GnuPG. For classic ECC, it is possible for scdaemon to do similar thing. But we need to handle the ambiguities. If it's size is smaller than x-coordinate and it starts with 0x41, it's not clear if it's the prefix or not. For completeness of the specification, this should be addressed in the OpenPGP card spec. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Wed Oct 26 05:55:08 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 25 Oct 2016 23:55:08 -0400 Subject: [PATCH 2/2] agent: --supervised mode improvements when LISTEN_FDNAMES is unset In-Reply-To: <20161026035508.15504-1-dkg@fifthhorseman.net> References: <20161026035508.15504-1-dkg@fifthhorseman.net> Message-ID: <20161026035508.15504-2-dkg@fifthhorseman.net> * agent/gpg-agent.c (map_supervised_socket): if the agent is running in --supervised mode and is not actually given LISTEN_FDNAMES directives, require at least fd 3 to be open for listening. Signed-off-by: Daniel Kahn Gillmor --- agent/gpg-agent.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/agent/gpg-agent.c b/agent/gpg-agent.c index 16edae0..7fb85aa 100644 --- a/agent/gpg-agent.c +++ b/agent/gpg-agent.c @@ -716,12 +716,19 @@ map_supervised_sockets (gnupg_fd_t *r_fd, /* Assign the descriptors to the return values. */ if (!fdnames) { + struct stat statbuf; if (fd_count != 1) log_error ("no LISTEN_FDNAMES and LISTEN_FDS (%d) != 1" " in --supervised mode." " (ignoring all sockets but the first one)\n", fd_count); + if (fstat (3, &statbuf) == -1 && errno ==EBADF) + log_fatal ("file descriptor 3 must be valid in --supervised mode (as the " + "agent's standard socket) if LISTEN_FDNAMES is not set\n"); *r_fd = 3; + socket_name = get_socket_name (3); + if (!socket_name) + log_error ("cannot learn socket name for fd 3\n"); } else if (fd_count != nfdnames) { -- 2.9.3 From dkg at fifthhorseman.net Wed Oct 26 03:43:57 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 25 Oct 2016 21:43:57 -0400 Subject: [PATCH] fix spelling of "internal" Message-ID: <20161026014357.1315-1-dkg@fifthhorseman.net> Signed-off-by: Daniel Kahn Gillmor --- doc/dirmngr.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/dirmngr.texi b/doc/dirmngr.texi index 7a85b55..bb8281d 100644 --- a/doc/dirmngr.texi +++ b/doc/dirmngr.texi @@ -493,7 +493,7 @@ Note that for OCSP responses the certificate specified using the option @item /etc/gnupg/extra-certs This directory may contain extra certificates which are preloaded -into the interal cache on startup. Applications using dirmngr (e.g. gpgsm) +into the internal cache on startup. Applications using dirmngr (e.g. gpgsm) can request cached certificates to complete a trust chain. This is convenient in cases you have a couple intermediate CA certificates or certificates usually used to sign OCSP responses. -- 2.9.3 From dkg at fifthhorseman.net Wed Oct 26 05:55:07 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 25 Oct 2016 23:55:07 -0400 Subject: [PATCH 1/2] common: avoid segfault Message-ID: <20161026035508.15504-1-dkg@fifthhorseman.net> * common/sysutils.c (gnupg_inotify_watch_socket): return EINVAL if socket_name is NULL, rather than segfaulting Signed-off-by: Daniel Kahn Gillmor --- common/sysutils.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/common/sysutils.c b/common/sysutils.c index ab2012c..3677d39 100644 --- a/common/sysutils.c +++ b/common/sysutils.c @@ -987,6 +987,9 @@ gnupg_inotify_watch_socket (int *r_fd, const char *socket_name) *r_fd = -1; + if (!socket_name) + return gpg_error (GPG_ERR_EINVAL); + fname = xtrystrdup (socket_name); if (!fname) return my_error_from_syserror (); -- 2.9.3 From gniibe at fsij.org Wed Oct 26 07:31:05 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 26 Oct 2016 14:31:05 +0900 Subject: [PATCH 2/2] agent: --supervised mode improvements when LISTEN_FDNAMES is unset In-Reply-To: <20161026035508.15504-2-dkg@fifthhorseman.net> References: <20161026035508.15504-1-dkg@fifthhorseman.net> <20161026035508.15504-2-dkg@fifthhorseman.net> Message-ID: Thanks. Both applied and pushed. I changed the title for the second as it's too long. And I modified trailing spaces. On 10/26/2016 12:55 PM, Daniel Kahn Gillmor wrote: > * common/sysutils.c (gnupg_inotify_watch_socket): return EINVAL if > socket_name is NULL, rather than segfaulting [...] > + Removed two spaces. On 10/26/2016 12:55 PM, Daniel Kahn Gillmor wrote: > * agent/gpg-agent.c (map_supervised_socket): if the agent is running > in --supervised mode and is not actually given LISTEN_FDNAMES > directives, require at least fd 3 to be open for listening. [...] > + "agent's standard socket) if LISTEN_FDNAMES is not set\n"); Removed the last trailing space before the newline. -- From gniibe at fsij.org Wed Oct 26 07:39:09 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 26 Oct 2016 14:39:09 +0900 Subject: [PATCH] fix spelling of "internal" In-Reply-To: <20161026014357.1315-1-dkg@fifthhorseman.net> References: <20161026014357.1315-1-dkg@fifthhorseman.net> Message-ID: On 10/26/2016 10:43 AM, Daniel Kahn Gillmor wrote: > doc/dirmngr.texi | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Thanks applied and pushed. -- From bernhard at intevation.de Wed Oct 26 08:42:38 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 26 Oct 2016 08:42:38 +0200 Subject: begging for pyme name change In-Reply-To: <87twc7c9d7.fsf@alice.fifthhorseman.net> References: <87insx8404.fsf@servo.finestructure.net> <87pomv1mmz.fsf@europa.jade-hamburg.de> <87twc7c9d7.fsf@alice.fifthhorseman.net> Message-ID: <201610260842.38964.bernhard@intevation.de> Am Donnerstag 20 Oktober 2016 17:45:24 schrieb Daniel Kahn Gillmor: > It's certainly frustrating that there's no clear way to make a clean api > break in a given python module namespace. python-gpgme python3-gpgme2 -- 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 Oct 26 09:24:02 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 26 Oct 2016 09:24:02 +0200 Subject: Question to WKD-Feature In-Reply-To: References: Message-ID: <201610260924.08627.bernhard@intevation.de> Hi Peter, Am Dienstag 25 Oktober 2016 18:47:13 schrieb Peter Fischer: > we want to adapt the WKS-Request by an Proxy to our HKP-Interface. it is very cool that you are considering WKD and WKS for mailbox.org! The requesting part is one important step forward. I hope the managing and email client parts will follow soon. :) > e.g. form: > https://pgp.mailbox.org/pks/lookup?op=get&search=pefi at mailbox.org > (response the active pub-key of this mailalias) > to: > https://mailbox.org/.well-known/openpgpkey/32bitsofsha1hashofmailalias > > In this mind, we have some question to the WKD-standard: According to what I know pgp.mailbox.org will only return one key. It seems to be implemented with Bounce Castle, it should be easy to add an option for a binary output. > According to: > n-3.1> > "The HTTP GET method MUST return the binary representation of the > OpenPGP key for the given mail address" > > Q1: Why is the output-key-format of the WKD-server binary and not > "ASCII amored"? In difference the key-format of the submissions-mail > is "ASCII armored". Werner? > Q2: Why do you build the URL for the public keys with SHA1-hash of the > local-part? This has been discussed a bit already, a short answer from https://wiki.gnupg.org/EasyGpg2016/PubkeyDistributionConcept#Ask_the_mail_service_provider_.28MSP.29 "The reason for using this encoding instead of a standard hex encoding is to visually distinguish such an item from a fingerprint. Furthermore, in contrast to Base-64 and other Base-32 encodings, z-Base-32 has been optimized for easier human use. " In addition we are avoiding problems with transformations for all intermediate components (see disregarded alternative): https://wiki.gnupg.org/EasyGpg2016/PubkeyDistributionConcept#Using_URL_encoding_in_the_request > * Are SHA1 hash-collisions theoretically possible (special on large > userbases) ? Let's consider each person on earth had an email address with one provider, we would have little less than 2**33 addresses. Sha1 has 2**160 possibilities. An approximation of the probability of an accidential clash if the distribution is even should be def d(n, d): return 1 - math.exp(-n**2/(2*d)) d(2**54, 2**160) give me 1.11 e-16 probability. So it is very unlikely we run into trouble this way. However researchers claim to be able to find collisions much easier (2**63 computation says wikipedia). Frankly I don't know what that does to the probability. However I doubt that an email provider will allow anything near that number of tries for choosing an email addresse. ;) > * What about lower-casing all upper-case ASCII characters in > local-part? Thats already in the spec: draft-02, Section 3.1 "Key Discovery" "all upper-case ASCII characters in a User ID are mapped to lowercase." > Maybe encoding base64, for forward and backward lookup of > the local-part? See reasons given above. > We believe that your reason for this is compatible and robustness on > differed file systems. Please describe it, in an short comment in the > DRAFT, to understand the motivation. Personally I'm not sure if we should all design thoughts into the spec itself. My aim is to record the most important ones on the wiki (linked above). I've not added the idea of file system robustness, because I don't believe this a major argument (most filesystems can deal with a lot of names). Fix length is another minor argument, I haven't recorded. > Q3: Why is in the fixed string an subfolder "hu" (e.g. > "") > * We found the answer on the WKS-Site > (), but it > is needed (and when please describe it in the Draft)? I guess someone could map an url part to a subdirectory and vice versa. So the "hu" for "hashed-userid" is a separator against other functions of this interface. So why not? 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 bernhard at intevation.de Wed Oct 26 09:41:49 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 26 Oct 2016 09:41:49 +0200 Subject: begging for pyme name change In-Reply-To: <201610260842.38964.bernhard@intevation.de> References: <87insx8404.fsf@servo.finestructure.net> <87twc7c9d7.fsf@alice.fifthhorseman.net> <201610260842.38964.bernhard@intevation.de> Message-ID: <201610260941.53615.bernhard@intevation.de> Am Mittwoch 26 Oktober 2016 08:42:38 schrieb Bernhard Reiter: > Am Donnerstag 20 Oktober 2016 17:45:24 schrieb Daniel Kahn Gillmor: > > It's certainly frustrating that there's no clear way to make a clean api > > break in a given python module namespace. > python3-gpgme2 To be more clear: I think that adding a number to the module name is a very strong api break. As examples psycopg2, libxml2, urllib2, urlib3 come to mind. So for example Debian packages would be called python-gpgme2 python3-gpgme2 And python code would do from gpgm2 import X,Y,Z Or (my prefered name): python-gnupg2 python3-gnupg2 from gnupg2 import X,Y,Z 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 arnaud.fontaine at ssi.gouv.fr Wed Oct 26 10:00:53 2016 From: arnaud.fontaine at ssi.gouv.fr (Arnaud Fontaine) Date: Wed, 26 Oct 2016 10:00:53 +0200 Subject: [PATCH] g10: Fix ECDH secret compressed/uncompressed format In-Reply-To: References: <580DD7AC.1060001@ssi.gouv.fr> <580F0665.7010906@ssi.gouv.fr> <87oa28d406.fsf@wheatstone.g10code.de> Message-ID: <581062B5.2020601@ssi.gouv.fr> Le 26/10/2016 02:31, NIIBE Yutaka a ?crit : > Hello, > > Arnaud, please be patient. Examining your patch, I realized > that we need to clarify things for ECDH by smartcard/token. Ok :-) > On 10/25/2016 09:09 PM, Werner Koch wrote: >> I see. For EdDSA we extended the meaning of the flag octet like this: >> >> Flag Description >> ---- ----------- >> 0x04 Standard flag for uncompressed format >> 0x40 Native point format of the curve follows >> 0x41 Only X coordinate follows. >> 0x42 Only Y coordinate follows. >> >> We only use 0x40 for EdDSA but the the new flag 0x41 is what I suggest >> for your use. We can prefix the x-coordinate in scdaemon with 0x41 so >> that we do not run in ambiguities in other parts of the code. > > I agree. Let us clarify. Do 0x41 and 0x42 mean standard MPI (of big > endian)? > > I think that the representation between scdaemon and GnuPG should > always have the prefix to avoid ambiguities. > > Arnaud, could you please consider a possibility to change your OpenPGP > card implementation to have the prefix 0x41 for the result of ECDH > decryption, or padding zero to be always fixed size of bytes? No, > it's not decided yet, but I'd like to see how we can change (which > part of code and how). Actually, the result my applet is returning is padded with zeros, but after it is received it is stored in the shared_mpi and then copied to secret_x using gcry_mpi_print (g10/ecdh.c line 125), so the leading zeros have disappeared. Adding a prefix could solve this problem, and it would not be a problem to impement it, but I agree with you that it should be addressed in the OpenPGP card specification so that every one will follow the same rule. From gniibe at fsij.org Wed Oct 26 10:42:47 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 26 Oct 2016 17:42:47 +0900 Subject: [PATCH] g10: Fix ECDH secret compressed/uncompressed format In-Reply-To: <581062B5.2020601@ssi.gouv.fr> References: <580DD7AC.1060001@ssi.gouv.fr> <580F0665.7010906@ssi.gouv.fr> <87oa28d406.fsf@wheatstone.g10code.de> <581062B5.2020601@ssi.gouv.fr> Message-ID: On 10/26/2016 05:00 PM, Arnaud Fontaine wrote: > Actually, the result my applet is returning is padded with zeros, but after it is > received it is stored in the shared_mpi and then copied to secret_x using > gcry_mpi_print > (g10/ecdh.c line 125), so the leading zeros have disappeared. > Adding a prefix could solve this problem, and it would not be a problem to > impement it, > but I agree with you that it should be addressed in the OpenPGP card > specification so that > every one will follow the same rule. Thank you for your explanation. I understand the situation. So, how about the following? * In the OpenPGP card specification The result from card should be one of: (1) Standard one, that is: 04 || X || Y (2) Fixed length native x-coordinate only In case of classic ECC, native means big-endian MPI. For X25519, native means little endian. * Modification in scdaemon In case of (2) for classic ECC, just like the case of X25519, scdaemon adds the prefix of 0x41 to the result by card/token. GnuPG frontend receives the bytes with the prefix, it is always fixed length. * Modification in gpg Add the support of the prefix 0x41 handling. -- From arnaud.fontaine at ssi.gouv.fr Wed Oct 26 10:55:30 2016 From: arnaud.fontaine at ssi.gouv.fr (Arnaud Fontaine) Date: Wed, 26 Oct 2016 10:55:30 +0200 Subject: [PATCH] g10: Fix ECDH secret compressed/uncompressed format In-Reply-To: References: <580DD7AC.1060001@ssi.gouv.fr> <580F0665.7010906@ssi.gouv.fr> <87oa28d406.fsf@wheatstone.g10code.de> <581062B5.2020601@ssi.gouv.fr> Message-ID: <58106F82.7050709@ssi.gouv.fr> Le 26/10/2016 10:42, NIIBE Yutaka a ?crit : > On 10/26/2016 05:00 PM, Arnaud Fontaine wrote: >> Actually, the result my applet is returning is padded with zeros, but after it is >> received it is stored in the shared_mpi and then copied to secret_x using >> gcry_mpi_print >> (g10/ecdh.c line 125), so the leading zeros have disappeared. >> Adding a prefix could solve this problem, and it would not be a problem to >> impement it, >> but I agree with you that it should be addressed in the OpenPGP card >> specification so that >> every one will follow the same rule. > > Thank you for your explanation. I understand the situation. > > So, how about the following? > > * In the OpenPGP card specification > > The result from card should be one of: > > (1) Standard one, that is: 04 || X || Y > > (2) Fixed length native x-coordinate only > In case of classic ECC, native means big-endian MPI. > For X25519, native means little endian. It ok for me, but 25519 is not supported by the OpenPGP card specification, right ? From alec at alec.pl Wed Oct 26 11:00:18 2016 From: alec at alec.pl (A.L.E.C) Date: Wed, 26 Oct 2016 11:00:18 +0200 Subject: Secret key export difference in 1.4 and 2.1 Message-ID: <54feb372-91e9-0ef0-d5e8-6cd883cd37d4@alec.pl> I ported PEAR::Crypt_GPG library to GnuPG 2.1 and one test fails when testing GnuPG 2.1.15 (no problem with 1.4.20). I'm not sure this is a bug or not. The exported key has no passphrase set and was created with 1.4. Also, the keyring is in old format before I execute gpg with --export-secret-keys argument. So, a migration process is involved. I see no errors in the gpg output, status is EXPORT_RES 1 1 1. The difference is in last three lines of the armored key data: Failed asserting that "-----BEGIN PGP PRIVATE KEY BLOCK----- lQG7BEjS+OkRBACyn20BV58+x0c2Fq49TLtrWQBCT9VxnNdeCUJ4sEgomTEUhYXu LAJ7UmORwjhT16l2X7EJKXZEfEbfZI8j/iYnpIBp/iYtsZ8y6bN70wdeNpRtZkB3 Cu1mU5C6d/thw0TmedW93bQ06wMtzBEPEQuOM+YjiKQZjjgqFmln5T3ctwCg6b/H 8//3jEa2N5J8U4yTOxZjxUMD/ROX/utLDNKX+dTLy69uQrlr94tabwszpBgdTYMw zgefgUYDdR7esWM5rZ5MMJX9lPzeePMPf0/7RllhYA4XgJ7EvzVTGNAuL45LVJrG 9B5dhwrChoKFNUtCfINS61urPdhUQA8YzmUxI+iDgBkD4FujLoh8ww+pxupJRsYZ b39iA/0ZJKZOeIN3JyUrIlqSqENG549H0+Y4TC5t8YixafB8fPBjlMz0+xGMR3Xx b8WHD+XFdulr/sVZ4WZ00YtOGhS/3ZF7qGrxCCBrCAjDRdPzqaF15nMaqgIogOIO L5j9wI6wRpMsJBxEbttWR/9K4BXhBriwg9qv4vamwzFM0t2vLQAAnRezOzJCxMwH xJHP1w6hpE8EQXV2CXq0c05vIFBhc3NwaHJhc2UgUHVibGljIGFuZCBQcml2YXRl IFRlc3QgS2V5IChkbyBub3QgZW5jcnlwdCBpbXBvcnRhbnQgZGF0YSB3aXRoIHRo aXMga2V5KSA8bm8tcGFzc3BocmFzZUBleGFtcGxlLmNvbT6IYAQTEQIAIAUCSNL4 6QIbAwYLCQgHAwIEFQIIAwQWAgMBAh4BAheAAAoJEJRWP7OYraayJmcAoMNHBJD2 jyN3z33NoeWeo+E8rh0mAJ9GYB60jPdeAy8QI8HecG15bd7kAZ0CPQRI0vj1EAgA hewinC9zCUsdDq6ajNdMztkTKyuhZuNB/7a0xBWuS2ugUobAEU549c7BuUYw8B9q pW1krb5ZDOa/szWN6FkWoyJwKG6POp38bASCZ0JL3QLcrSEENjdmqsjWggQEwfFa Teb15PLEPJQW1m5WgD31Cf5HCBRQmPMgsI2r9XDiLFJm8BdJ6JTtV9UHwCbM/kA7 U3RrL30uVfreJYhPepQvjkfU66ZzHADjmpu2d8iMee1I7d581NecYG9U87LZf2Xr 9r2m4YmiGO5w/oKVyMXuJfNAgMSMu9EIF+whBFdQjlZ2nEfwf0K1oU/Eod1lKTRA FYcpDlwhO5M18pIcc4gI+wADBQf/d5ISDTDuirgkyFOi1sJxk/avD10NNvmaXYxc 2gTYF7Natkq0T0x2behWwNbO3DhZOFrZqlj+mkg9LRx/Q0XMviac1X0ils20MdS2 PSa8wkg8BC+2RVbV6DrNAyF+E2+9penGulTgKsPIybn0azBgVkfoRBjpTu8D8xFH +ASaZUt+850oynFlDmAXWfqU5pcTMVEny+KrY62S6TDH2zLEfIJKK97oRuU9F86A UbAIn575fUHJnzgEoelxKJTWWlDCH9IPq37ZrStNeOBqURgzttvMaL7/zhcVPIEw 9WFgG8TCEpYNOg+x0gqETHM2rIRBdGfjgaSY7T9fXoxiikv37AABVAg+anwLssMt ypICzst26P2lLSCGT1f7icmHvSqBgVdOQizx/9QYGMoUigAUyohJBBgRAgAJBQJI 0vj1AhsMAAoJEJRWP7OYraaywmQAnjDYzwwdog+Rim+pH3T8zF1W7b/9AKCnZkLp rb8Yh7YE/mZLoz20MZ8eWw== =+I0b -----END PGP PRIVATE KEY BLOCK----- " contains "lQG7BEjS+OkRBACyn20BV58+x0c2Fq49TLtrWQBCT9VxnNdeCUJ4sEgomTEUhYXu LAJ7UmORwjhT16l2X7EJKXZEfEbfZI8j/iYnpIBp/iYtsZ8y6bN70wdeNpRtZkB3 Cu1mU5C6d/thw0TmedW93bQ06wMtzBEPEQuOM+YjiKQZjjgqFmln5T3ctwCg6b/H 8//3jEa2N5J8U4yTOxZjxUMD/ROX/utLDNKX+dTLy69uQrlr94tabwszpBgdTYMw zgefgUYDdR7esWM5rZ5MMJX9lPzeePMPf0/7RllhYA4XgJ7EvzVTGNAuL45LVJrG 9B5dhwrChoKFNUtCfINS61urPdhUQA8YzmUxI+iDgBkD4FujLoh8ww+pxupJRsYZ b39iA/0ZJKZOeIN3JyUrIlqSqENG549H0+Y4TC5t8YixafB8fPBjlMz0+xGMR3Xx b8WHD+XFdulr/sVZ4WZ00YtOGhS/3ZF7qGrxCCBrCAjDRdPzqaF15nMaqgIogOIO L5j9wI6wRpMsJBxEbttWR/9K4BXhBriwg9qv4vamwzFM0t2vLQAAnRezOzJCxMwH xJHP1w6hpE8EQXV2CXq0c05vIFBhc3NwaHJhc2UgUHVibGljIGFuZCBQcml2YXRl IFRlc3QgS2V5IChkbyBub3QgZW5jcnlwdCBpbXBvcnRhbnQgZGF0YSB3aXRoIHRo aXMga2V5KSA8bm8tcGFzc3BocmFzZUBleGFtcGxlLmNvbT6IYAQTEQIAIAUCSNL4 6QIbAwYLCQgHAwIEFQIIAwQWAgMBAh4BAheAAAoJEJRWP7OYraayJmcAoMNHBJD2 jyN3z33NoeWeo+E8rh0mAJ9GYB60jPdeAy8QI8HecG15bd7kAZ0CPQRI0vj1EAgA hewinC9zCUsdDq6ajNdMztkTKyuhZuNB/7a0xBWuS2ugUobAEU549c7BuUYw8B9q pW1krb5ZDOa/szWN6FkWoyJwKG6POp38bASCZ0JL3QLcrSEENjdmqsjWggQEwfFa Teb15PLEPJQW1m5WgD31Cf5HCBRQmPMgsI2r9XDiLFJm8BdJ6JTtV9UHwCbM/kA7 U3RrL30uVfreJYhPepQvjkfU66ZzHADjmpu2d8iMee1I7d581NecYG9U87LZf2Xr 9r2m4YmiGO5w/oKVyMXuJfNAgMSMu9EIF+whBFdQjlZ2nEfwf0K1oU/Eod1lKTRA FYcpDlwhO5M18pIcc4gI+wADBQf/d5ISDTDuirgkyFOi1sJxk/avD10NNvmaXYxc 2gTYF7Natkq0T0x2behWwNbO3DhZOFrZqlj+mkg9LRx/Q0XMviac1X0ils20MdS2 PSa8wkg8BC+2RVbV6DrNAyF+E2+9penGulTgKsPIybn0azBgVkfoRBjpTu8D8xFH +ASaZUt+850oynFlDmAXWfqU5pcTMVEny+KrY62S6TDH2zLEfIJKK97oRuU9F86A UbAIn575fUHJnzgEoelxKJTWWlDCH9IPq37ZrStNeOBqURgzttvMaL7/zhcVPIEw 9WFgG8TCEpYNOg+x0gqETHM2rIRBdGfjgaSY7T9fXoxiikv37AABVAg+anwLssMt ypICzst26P2lLSCGT1f7icmHvSqBgVdOQizx/9QYGMoUigAUyohJBBgRAgAJBQJI 0vj1AhsMAAoJEJRWP7OYraaywmQAoK31UjQ8v0JxjEBYQISdvYuLNpA8AKC7QxpJ WOad2BFLoSh6WM3H7KvMUg== =ZTyB -----END PGP PRIVATE KEY BLOCK-----". -- Aleksander 'A.L.E.C' Machniak Kolab Groupware Developer [http://kolab.org] Roundcube Webmail Developer [http://roundcube.net] ---------------------------------------------------- PGP: 19359DC1 # Blog: https://kolabian.wordpress.com From neal at walfield.org Wed Oct 26 11:08:06 2016 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 26 Oct 2016 11:08:06 +0200 Subject: Secret key export difference in 1.4 and 2.1 In-Reply-To: <54feb372-91e9-0ef0-d5e8-6cd883cd37d4@alec.pl> References: <54feb372-91e9-0ef0-d5e8-6cd883cd37d4@alec.pl> Message-ID: <87d1in1nrd.wl-neal@walfield.org> Hi, The secret key is not simply a dump of the private key material, but an OpenPGP message. This means that there are many ways to encode the same data. It wouldn't surprise me if we are using a slightly different encoding in 2.1 vs. 1.4. But, this is not a bug. What exactly is the test doing, and what is it testing for? Thanks! :) Neal On Wed, 26 Oct 2016 11:00:18 +0200, A.L.E.C wrote: > > I ported PEAR::Crypt_GPG library to GnuPG 2.1 and one test fails when > testing GnuPG 2.1.15 (no problem with 1.4.20). I'm not sure this is a > bug or not. > > The exported key has no passphrase set and was created with 1.4. Also, > the keyring is in old format before I execute gpg with > --export-secret-keys argument. So, a migration process is involved. I > see no errors in the gpg output, status is EXPORT_RES 1 1 1. > > The difference is in last three lines of the armored key data: > > Failed asserting that > "-----BEGIN PGP PRIVATE KEY BLOCK----- > > lQG7BEjS+OkRBACyn20BV58+x0c2Fq49TLtrWQBCT9VxnNdeCUJ4sEgomTEUhYXu > LAJ7UmORwjhT16l2X7EJKXZEfEbfZI8j/iYnpIBp/iYtsZ8y6bN70wdeNpRtZkB3 > Cu1mU5C6d/thw0TmedW93bQ06wMtzBEPEQuOM+YjiKQZjjgqFmln5T3ctwCg6b/H > 8//3jEa2N5J8U4yTOxZjxUMD/ROX/utLDNKX+dTLy69uQrlr94tabwszpBgdTYMw > zgefgUYDdR7esWM5rZ5MMJX9lPzeePMPf0/7RllhYA4XgJ7EvzVTGNAuL45LVJrG > 9B5dhwrChoKFNUtCfINS61urPdhUQA8YzmUxI+iDgBkD4FujLoh8ww+pxupJRsYZ > b39iA/0ZJKZOeIN3JyUrIlqSqENG549H0+Y4TC5t8YixafB8fPBjlMz0+xGMR3Xx > b8WHD+XFdulr/sVZ4WZ00YtOGhS/3ZF7qGrxCCBrCAjDRdPzqaF15nMaqgIogOIO > L5j9wI6wRpMsJBxEbttWR/9K4BXhBriwg9qv4vamwzFM0t2vLQAAnRezOzJCxMwH > xJHP1w6hpE8EQXV2CXq0c05vIFBhc3NwaHJhc2UgUHVibGljIGFuZCBQcml2YXRl > IFRlc3QgS2V5IChkbyBub3QgZW5jcnlwdCBpbXBvcnRhbnQgZGF0YSB3aXRoIHRo > aXMga2V5KSA8bm8tcGFzc3BocmFzZUBleGFtcGxlLmNvbT6IYAQTEQIAIAUCSNL4 > 6QIbAwYLCQgHAwIEFQIIAwQWAgMBAh4BAheAAAoJEJRWP7OYraayJmcAoMNHBJD2 > jyN3z33NoeWeo+E8rh0mAJ9GYB60jPdeAy8QI8HecG15bd7kAZ0CPQRI0vj1EAgA > hewinC9zCUsdDq6ajNdMztkTKyuhZuNB/7a0xBWuS2ugUobAEU549c7BuUYw8B9q > pW1krb5ZDOa/szWN6FkWoyJwKG6POp38bASCZ0JL3QLcrSEENjdmqsjWggQEwfFa > Teb15PLEPJQW1m5WgD31Cf5HCBRQmPMgsI2r9XDiLFJm8BdJ6JTtV9UHwCbM/kA7 > U3RrL30uVfreJYhPepQvjkfU66ZzHADjmpu2d8iMee1I7d581NecYG9U87LZf2Xr > 9r2m4YmiGO5w/oKVyMXuJfNAgMSMu9EIF+whBFdQjlZ2nEfwf0K1oU/Eod1lKTRA > FYcpDlwhO5M18pIcc4gI+wADBQf/d5ISDTDuirgkyFOi1sJxk/avD10NNvmaXYxc > > > 2gTYF7Natkq0T0x2behWwNbO3DhZOFrZqlj+mkg9LRx/Q0XMviac1X0ils20MdS2 > PSa8wkg8BC+2RVbV6DrNAyF+E2+9penGulTgKsPIybn0azBgVkfoRBjpTu8D8xFH > +ASaZUt+850oynFlDmAXWfqU5pcTMVEny+KrY62S6TDH2zLEfIJKK97oRuU9F86A > UbAIn575fUHJnzgEoelxKJTWWlDCH9IPq37ZrStNeOBqURgzttvMaL7/zhcVPIEw > 9WFgG8TCEpYNOg+x0gqETHM2rIRBdGfjgaSY7T9fXoxiikv37AABVAg+anwLssMt > ypICzst26P2lLSCGT1f7icmHvSqBgVdOQizx/9QYGMoUigAUyohJBBgRAgAJBQJI > 0vj1AhsMAAoJEJRWP7OYraaywmQAnjDYzwwdog+Rim+pH3T8zF1W7b/9AKCnZkLp > rb8Yh7YE/mZLoz20MZ8eWw== > =+I0b > -----END PGP PRIVATE KEY BLOCK----- > " > contains "lQG7BEjS+OkRBACyn20BV58+x0c2Fq49TLtrWQBCT9VxnNdeCUJ4sEgomTEUhYXu > LAJ7UmORwjhT16l2X7EJKXZEfEbfZI8j/iYnpIBp/iYtsZ8y6bN70wdeNpRtZkB3 > Cu1mU5C6d/thw0TmedW93bQ06wMtzBEPEQuOM+YjiKQZjjgqFmln5T3ctwCg6b/H > 8//3jEa2N5J8U4yTOxZjxUMD/ROX/utLDNKX+dTLy69uQrlr94tabwszpBgdTYMw > zgefgUYDdR7esWM5rZ5MMJX9lPzeePMPf0/7RllhYA4XgJ7EvzVTGNAuL45LVJrG > 9B5dhwrChoKFNUtCfINS61urPdhUQA8YzmUxI+iDgBkD4FujLoh8ww+pxupJRsYZ > b39iA/0ZJKZOeIN3JyUrIlqSqENG549H0+Y4TC5t8YixafB8fPBjlMz0+xGMR3Xx > b8WHD+XFdulr/sVZ4WZ00YtOGhS/3ZF7qGrxCCBrCAjDRdPzqaF15nMaqgIogOIO > L5j9wI6wRpMsJBxEbttWR/9K4BXhBriwg9qv4vamwzFM0t2vLQAAnRezOzJCxMwH > xJHP1w6hpE8EQXV2CXq0c05vIFBhc3NwaHJhc2UgUHVibGljIGFuZCBQcml2YXRl > IFRlc3QgS2V5IChkbyBub3QgZW5jcnlwdCBpbXBvcnRhbnQgZGF0YSB3aXRoIHRo > aXMga2V5KSA8bm8tcGFzc3BocmFzZUBleGFtcGxlLmNvbT6IYAQTEQIAIAUCSNL4 > 6QIbAwYLCQgHAwIEFQIIAwQWAgMBAh4BAheAAAoJEJRWP7OYraayJmcAoMNHBJD2 > jyN3z33NoeWeo+E8rh0mAJ9GYB60jPdeAy8QI8HecG15bd7kAZ0CPQRI0vj1EAgA > hewinC9zCUsdDq6ajNdMztkTKyuhZuNB/7a0xBWuS2ugUobAEU549c7BuUYw8B9q > pW1krb5ZDOa/szWN6FkWoyJwKG6POp38bASCZ0JL3QLcrSEENjdmqsjWggQEwfFa > Teb15PLEPJQW1m5WgD31Cf5HCBRQmPMgsI2r9XDiLFJm8BdJ6JTtV9UHwCbM/kA7 > U3RrL30uVfreJYhPepQvjkfU66ZzHADjmpu2d8iMee1I7d581NecYG9U87LZf2Xr > 9r2m4YmiGO5w/oKVyMXuJfNAgMSMu9EIF+whBFdQjlZ2nEfwf0K1oU/Eod1lKTRA > FYcpDlwhO5M18pIcc4gI+wADBQf/d5ISDTDuirgkyFOi1sJxk/avD10NNvmaXYxc > 2gTYF7Natkq0T0x2behWwNbO3DhZOFrZqlj+mkg9LRx/Q0XMviac1X0ils20MdS2 > PSa8wkg8BC+2RVbV6DrNAyF+E2+9penGulTgKsPIybn0azBgVkfoRBjpTu8D8xFH > +ASaZUt+850oynFlDmAXWfqU5pcTMVEny+KrY62S6TDH2zLEfIJKK97oRuU9F86A > UbAIn575fUHJnzgEoelxKJTWWlDCH9IPq37ZrStNeOBqURgzttvMaL7/zhcVPIEw > 9WFgG8TCEpYNOg+x0gqETHM2rIRBdGfjgaSY7T9fXoxiikv37AABVAg+anwLssMt > ypICzst26P2lLSCGT1f7icmHvSqBgVdOQizx/9QYGMoUigAUyohJBBgRAgAJBQJI > 0vj1AhsMAAoJEJRWP7OYraaywmQAoK31UjQ8v0JxjEBYQISdvYuLNpA8AKC7QxpJ > WOad2BFLoSh6WM3H7KvMUg== > =ZTyB > -----END PGP PRIVATE KEY BLOCK-----". > > -- > Aleksander 'A.L.E.C' Machniak > Kolab Groupware Developer [http://kolab.org] > Roundcube Webmail Developer [http://roundcube.net] > ---------------------------------------------------- > PGP: 19359DC1 # Blog: https://kolabian.wordpress.com > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > From alec at alec.pl Wed Oct 26 11:21:11 2016 From: alec at alec.pl (A.L.E.C) Date: Wed, 26 Oct 2016 11:21:11 +0200 Subject: Secret key export difference in 1.4 and 2.1 In-Reply-To: <87d1in1nrd.wl-neal@walfield.org> References: <54feb372-91e9-0ef0-d5e8-6cd883cd37d4@alec.pl> <87d1in1nrd.wl-neal@walfield.org> Message-ID: <2e2cc7d7-cd30-8b8f-a38c-ef40edffc0d1@alec.pl> On 10/26/2016 11:08 AM, Neal H. Walfield wrote: > The secret key is not simply a dump of the private key material, but > an OpenPGP message. This means that there are many ways to encode the > same data. It wouldn't surprise me if we are using a slightly > different encoding in 2.1 vs. 1.4. But, this is not a bug. What > exactly is the test doing, and what is it testing for? Well, the test is for our exportPrivateKey() method which does just gpg --export-secret-keys "fingerprint". We makes sure the output is always the same. It worked with 1.4. If it's not a proper way now, we'll have to change it, but I'm not sure how to do this. How to find out that exported data is really the data we want. Or can I just assume that if there's no error and output data contains "BEGIN PGP PRIVATE KEY BLOCK" we're fine? I don't think I'll decode the message, I'd prefer some simple checks. -- Aleksander 'A.L.E.C' Machniak Kolab Groupware Developer [http://kolab.org] Roundcube Webmail Developer [http://roundcube.net] ---------------------------------------------------- PGP: 19359DC1 # Blog: https://kolabian.wordpress.com From alec at alec.pl Wed Oct 26 11:24:27 2016 From: alec at alec.pl (A.L.E.C) Date: Wed, 26 Oct 2016 11:24:27 +0200 Subject: Secret key export difference in 1.4 and 2.1 In-Reply-To: <2e2cc7d7-cd30-8b8f-a38c-ef40edffc0d1@alec.pl> References: <54feb372-91e9-0ef0-d5e8-6cd883cd37d4@alec.pl> <87d1in1nrd.wl-neal@walfield.org> <2e2cc7d7-cd30-8b8f-a38c-ef40edffc0d1@alec.pl> Message-ID: <42f4a502-a323-b4e3-3713-64c46e114378@alec.pl> On 10/26/2016 11:21 AM, A.L.E.C wrote: > Well, the test is for our exportPrivateKey() method which does just gpg > --export-secret-keys "fingerprint". We makes sure the output is always > the same. It worked with 1.4. BTW, we test public keys export in the same way and it works there. -- Aleksander 'A.L.E.C' Machniak Kolab Groupware Developer [http://kolab.org] Roundcube Webmail Developer [http://roundcube.net] ---------------------------------------------------- PGP: 19359DC1 # Blog: https://kolabian.wordpress.com From justus at g10code.com Wed Oct 26 11:34:04 2016 From: justus at g10code.com (Justus Winter) Date: Wed, 26 Oct 2016 11:34:04 +0200 Subject: Secret key export difference in 1.4 and 2.1 In-Reply-To: <2e2cc7d7-cd30-8b8f-a38c-ef40edffc0d1@alec.pl> References: <54feb372-91e9-0ef0-d5e8-6cd883cd37d4@alec.pl> <87d1in1nrd.wl-neal@walfield.org> <2e2cc7d7-cd30-8b8f-a38c-ef40edffc0d1@alec.pl> Message-ID: <87vawfwj1v.fsf@europa.jade-hamburg.de> "A.L.E.C" writes: > On 10/26/2016 11:08 AM, Neal H. Walfield wrote: >> The secret key is not simply a dump of the private key material, but >> an OpenPGP message. This means that there are many ways to encode the >> same data. It wouldn't surprise me if we are using a slightly >> different encoding in 2.1 vs. 1.4. But, this is not a bug. What >> exactly is the test doing, and what is it testing for? > > Well, the test is for our exportPrivateKey() method which does just gpg > --export-secret-keys "fingerprint". We makes sure the output is always > the same. It worked with 1.4. If it's not a proper way now, we'll have > to change it, but I'm not sure how to do this. How to find out that > exported data is really the data we want. Or can I just assume that if > there's no error and output data contains "BEGIN PGP PRIVATE KEY BLOCK" > we're fine? I don't think I'll decode the message, I'd prefer some > simple checks. You can use --list-packets to inspect the message. Take a look at tests/openpgp/export.scm for inspiration. Or you can try to import the key into a fresh gnupghome. Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From neal at walfield.org Wed Oct 26 11:42:41 2016 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 26 Oct 2016 11:42:41 +0200 Subject: Secret key export difference in 1.4 and 2.1 In-Reply-To: <87vawfwj1v.fsf@europa.jade-hamburg.de> References: <54feb372-91e9-0ef0-d5e8-6cd883cd37d4@alec.pl> <87d1in1nrd.wl-neal@walfield.org> <2e2cc7d7-cd30-8b8f-a38c-ef40edffc0d1@alec.pl> <87vawfwj1v.fsf@europa.jade-hamburg.de> Message-ID: <878ttb1m5q.wl-neal@walfield.org> On Wed, 26 Oct 2016 11:34:04 +0200, Justus Winter wrote: > > On 10/26/2016 11:08 AM, Neal H. Walfield wrote: > >> The secret key is not simply a dump of the private key material, but > >> an OpenPGP message. This means that there are many ways to encode the > >> same data. It wouldn't surprise me if we are using a slightly > >> different encoding in 2.1 vs. 1.4. But, this is not a bug. What > >> exactly is the test doing, and what is it testing for? > > > > Well, the test is for our exportPrivateKey() method which does just gpg > > --export-secret-keys "fingerprint". We makes sure the output is always > > the same. It worked with 1.4. If it's not a proper way now, we'll have > > to change it, but I'm not sure how to do this. How to find out that > > exported data is really the data we want. Or can I just assume that if > > there's no error and output data contains "BEGIN PGP PRIVATE KEY BLOCK" > > we're fine? I don't think I'll decode the message, I'd prefer some > > simple checks. > > You can use --list-packets to inspect the message. Take a look at > tests/openpgp/export.scm for inspiration. Or you can try to import the > key into a fresh gnupghome. Using --list-packets is okay for debugging, but the interface is not guaranteed to be stable. Instead, you are better off doing something like: gpg --status-fd 1 --import exported-key.asc | grep 'IMPORT_OK [0-9]* FINGERPRINT' :) Neal From wk at gnupg.org Wed Oct 26 11:35:26 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 26 Oct 2016 11:35:26 +0200 Subject: Secret key export difference in 1.4 and 2.1 In-Reply-To: <54feb372-91e9-0ef0-d5e8-6cd883cd37d4@alec.pl> (A. L. E. C.'s message of "Wed, 26 Oct 2016 11:00:18 +0200") References: <54feb372-91e9-0ef0-d5e8-6cd883cd37d4@alec.pl> Message-ID: <87k2cva1wh.fsf@wheatstone.g10code.de> On Wed, 26 Oct 2016 11:00, alec at alec.pl said: > The difference is in last three lines of the armored key data: It seems that the key binding signature for the subkey has been re-created. DSA is depending on the implementation not deterministic and thus you see different signature values. An you please describe exactly how you created the keys and the test vector? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From wk at gnupg.org Wed Oct 26 11:45:02 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 26 Oct 2016 11:45:02 +0200 Subject: [PATCH] g10: Fix ECDH secret compressed/uncompressed format In-Reply-To: (NIIBE Yutaka's message of "Wed, 26 Oct 2016 09:31:39 +0900") References: <580DD7AC.1060001@ssi.gouv.fr> <580F0665.7010906@ssi.gouv.fr> <87oa28d406.fsf@wheatstone.g10code.de> Message-ID: <87funja1gh.fsf@wheatstone.g10code.de> On Wed, 26 Oct 2016 02:31, gniibe at fsij.org said: >> 0x04 Standard flag for uncompressed format >> 0x40 Native point format of the curve follows >> 0x41 Only X coordinate follows. >> 0x42 Only Y coordinate follows. >> >> We only use 0x40 for EdDSA but the the new flag 0x41 is what I suggest >> for your use. We can prefix the x-coordinate in scdaemon with 0x41 so >> that we do not run in ambiguities in other parts of the code. > > I agree. Let us clarify. Do 0x41 and 0x42 mean standard MPI (of big > endian)? Good question, given that 0x40 is the native format for the curve we may either do this 0x04 Standard flag for uncompressed format 0x40 Native point format of the curve follows 0x41 Only X coordinate follows in native endianess of the curve. 0x42 Only Y coordinate follows in native endianess of the curve. or this: 0x04 Standard flag for uncompressed format 0x40 Native point format of the curve follows 0x41 Only X coordinate follows in big endian format 0x42 Only Y coordinate follows in big endian format I am unsure. How would it best fit into Libgcrypt? > Besides, in GnuPG and libgcrypt, ECDH with Curve25519 (X25519) also > uses the prefix 0x40 for its point representation. It is > little-endian and x-coordinate only. Which is kind of okay because 0x40 is the native format of the curve and ECDH requires only the X coordinate. Depending on how we interpret 0x41 we may want to allow 0x41 also. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From wk at gnupg.org Wed Oct 26 11:47:31 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 26 Oct 2016 11:47:31 +0200 Subject: read/parse pubkeys in gpgme without importing In-Reply-To: (Jeroen Ooms's message of "Tue, 25 Oct 2016 16:24:13 +0200") References: Message-ID: <877f8va1cc.fsf@wheatstone.g10code.de> On Tue, 25 Oct 2016 16:24, jeroen.ooms at stat.ucla.edu said: > Can I parse this file in gpgme to print the name/email/fingerprints of the > pubkeys without actually importing into my keyring? Not yet. We need to add such a feature to gpgme. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From wk at gnupg.org Wed Oct 26 11:46:43 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 26 Oct 2016 11:46:43 +0200 Subject: [PATCH] g10: Fix ECDH secret compressed/uncompressed format In-Reply-To: (NIIBE Yutaka's message of "Wed, 26 Oct 2016 17:42:47 +0900") References: <580DD7AC.1060001@ssi.gouv.fr> <580F0665.7010906@ssi.gouv.fr> <87oa28d406.fsf@wheatstone.g10code.de> <581062B5.2020601@ssi.gouv.fr> Message-ID: <87bmy7a1do.fsf@wheatstone.g10code.de> On Wed, 26 Oct 2016 10:42, gniibe at fsij.org said: > * Modification in scdaemon > > In case of (2) for classic ECC, just like the case of X25519, scdaemon > adds the prefix of 0x41 to the result by card/token. GnuPG frontend > receives the bytes with the prefix, it is always fixed length. ACK. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From neal at walfield.org Wed Oct 26 12:02:28 2016 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 26 Oct 2016 12:02:28 +0200 Subject: Secret key export difference in 1.4 and 2.1 In-Reply-To: <42f4a502-a323-b4e3-3713-64c46e114378@alec.pl> References: <54feb372-91e9-0ef0-d5e8-6cd883cd37d4@alec.pl> <87d1in1nrd.wl-neal@walfield.org> <2e2cc7d7-cd30-8b8f-a38c-ef40edffc0d1@alec.pl> <42f4a502-a323-b4e3-3713-64c46e114378@alec.pl> Message-ID: <8737jj1l8r.wl-neal@walfield.org> On Wed, 26 Oct 2016 11:24:27 +0200, A.L.E.C wrote: > > On 10/26/2016 11:21 AM, A.L.E.C wrote: > > Well, the test is for our exportPrivateKey() method which does just gpg > > --export-secret-keys "fingerprint". We makes sure the output is always > > the same. It worked with 1.4. > > BTW, we test public keys export in the same way and it works there. Then you should change this as well. :) Neal From alec at alec.pl Wed Oct 26 14:20:56 2016 From: alec at alec.pl (A.L.E.C) Date: Wed, 26 Oct 2016 14:20:56 +0200 Subject: Secret key export difference in 1.4 and 2.1 In-Reply-To: <87k2cva1wh.fsf@wheatstone.g10code.de> References: <54feb372-91e9-0ef0-d5e8-6cd883cd37d4@alec.pl> <87k2cva1wh.fsf@wheatstone.g10code.de> Message-ID: On 10/26/2016 11:35 AM, Werner Koch wrote: > It seems that the key binding signature for the subkey has been > re-created. DSA is depending on the implementation not deterministic > and thus you see different signature values. > > An you please describe exactly how you created the keys and the test > vector? For each test we setup a new homedir with content generated long time ago with this script https://github.com/pear/Crypt_GPG/blob/master/tools/build-keyring.sh#L70. As generating keys takes long time we obviously can't generate the content on every tests execution. In other words, we generated a set of keys and imported them to the empty keyring. Then when we run tests we re-create a new homedir and copy saved keyring (and other homedir files) there, then execute a test. In this case we compare the original private key block with the result of the --export-secret-keys command. Maybe I just should generate a homedir and keys sets for each main gpg version separately. I should probably do it anyway, to skip the migration process on every test, but will that solve the secret key export issue? Will be signature the same for every gpg release across the main version, i.e. 1.4, 2.0, 2.1? Or maybe there's some command line argument which we could use for export command to get the same signature value? -- Aleksander 'A.L.E.C' Machniak Kolab Groupware Developer [http://kolab.org] Roundcube Webmail Developer [http://roundcube.net] ---------------------------------------------------- PGP: 19359DC1 # Blog: https://kolabian.wordpress.com From neal at walfield.org Wed Oct 26 14:31:28 2016 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 26 Oct 2016 14:31:28 +0200 Subject: Secret key export difference in 1.4 and 2.1 In-Reply-To: References: <54feb372-91e9-0ef0-d5e8-6cd883cd37d4@alec.pl> <87k2cva1wh.fsf@wheatstone.g10code.de> Message-ID: <87wpgvz3z3.wl-neal@walfield.org> On Wed, 26 Oct 2016 14:20:56 +0200, A.L.E.C wrote: > > On 10/26/2016 11:35 AM, Werner Koch wrote: > > It seems that the key binding signature for the subkey has been > > re-created. DSA is depending on the implementation not deterministic > > and thus you see different signature values. > > > > An you please describe exactly how you created the keys and the test > > vector? > > For each test we setup a new homedir with content generated long time > ago with this script > https://github.com/pear/Crypt_GPG/blob/master/tools/build-keyring.sh#L70. > As generating keys takes long time we obviously can't generate the > content on every tests execution. > > In other words, we generated a set of keys and imported them to the > empty keyring. Then when we run tests we re-create a new homedir and > copy saved keyring (and other homedir files) there, then execute a test. This is good. > In this case we compare the original private key block with the result > of the --export-secret-keys command. Please don't do this. > Maybe I just should generate a homedir and keys sets for each main gpg > version separately. I should probably do it anyway, to skip the > migration process on every test, but will that solve the secret key > export issue? Will be signature the same for every gpg release across > the main version, i.e. 1.4, 2.0, 2.1? Or maybe there's some command line > argument which we could use for export command to get the same signature > value? I provided you with an example of how to do what you want using the official API. Is it somehow inadequate? Thanks, :) Neal From dkg at fifthhorseman.net Wed Oct 26 15:15:51 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 26 Oct 2016 09:15:51 -0400 Subject: Secret key export difference in 1.4 and 2.1 In-Reply-To: <878ttb1m5q.wl-neal@walfield.org> References: <54feb372-91e9-0ef0-d5e8-6cd883cd37d4@alec.pl> <87d1in1nrd.wl-neal@walfield.org> <2e2cc7d7-cd30-8b8f-a38c-ef40edffc0d1@alec.pl> <87vawfwj1v.fsf@europa.jade-hamburg.de> <878ttb1m5q.wl-neal@walfield.org> Message-ID: <87eg33fdyw.fsf@alice.fifthhorseman.net> On Wed 2016-10-26 05:42:41 -0400, Neal H. Walfield wrote: > Using --list-packets is okay for debugging, but the interface is not > guaranteed to be stable. Instead, you are better off doing something > like: > > gpg --status-fd 1 --import exported-key.asc | grep 'IMPORT_OK [0-9]* FINGERPRINT' If you're doing this with a secret key and you don't want to trigger more passphrase prompts, you probably also want to use --batch and --no-tty for the --import part of this pipeline. --dkg From dkg at fifthhorseman.net Wed Oct 26 15:23:17 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 26 Oct 2016 09:23:17 -0400 Subject: Secret key export difference in 1.4 and 2.1 In-Reply-To: <87wpgvz3z3.wl-neal@walfield.org> References: <54feb372-91e9-0ef0-d5e8-6cd883cd37d4@alec.pl> <87k2cva1wh.fsf@wheatstone.g10code.de> <87wpgvz3z3.wl-neal@walfield.org> Message-ID: <87bmy7fdmi.fsf@alice.fifthhorseman.net> On Wed 2016-10-26 08:31:28 -0400, Neal H. Walfield wrote: >> In this case we compare the original private key block with the result >> of the --export-secret-keys command. > > Please don't do this. In particular, the reason to not do this is because there is no guarantee that gpg will create the same exact keyblock each time. Some things which would be allowed to change, just from the spec: * ASCII-armoring could have arbitrary headers (Comment:, Version:, etc) * ASCII-armoring could have arbitrary line lengths (the spec suggests a limit of 76 chars per line, but any tool could legitimately choose fewer characters in a line) * secret key material could be re-encrypted with a different session key and/or a different algorithm * Some components of an OpenPGP certificate can be re-ordered without affecting the semantics of the certificate And there are probably other variations that i'm not thinking of. The point is that expecting byte-for-byte identical output is not the right level to test the API; this isn't something that the GnuPG devs have said would be stable, and it's not something that we *want* to be stable. If newer versions of GnuPG have better ideas about how to format this output, we want to be able to make those changes. So test suites that are over-precise are brittle and make it difficult to evolve GnuPG. Please help us keep the ecosystem friendly and flexible by only depending on the interfaces that upstream intends to keep stable. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From Juergen.Schaepker at giepa.de Wed Oct 26 16:00:58 2016 From: Juergen.Schaepker at giepa.de (=?iso-8859-1?Q?J=FCrgen_Sch=E4pker?=) Date: Wed, 26 Oct 2016 16:00:58 +0200 Subject: Web Key Service draft requires binary representation keys Message-ID: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB659AA@S2008SBS.intern.giepa.de> Hi, the current OpenPGP Web Key Service draft defines in 3.1 Key Discovery: "The HTTP GET method MUST return the binary representation of the OpenPGP key for the given mail address." "The server MUST NOT return an ASCII armored version of the key." Is there a specific reason why the (possibly problematic) binary representation was chosen? Why not ASCII armored keys instead? Best regards, JS -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at ssl-mail.com Wed Oct 26 18:19:18 2016 From: lists at ssl-mail.com (lists at ssl-mail.com) Date: Wed, 26 Oct 2016 09:19:18 -0700 Subject: gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)" In-Reply-To: References: <1476027783.1522252.750391089.07374952@webmail.messagingengine.com> <20161009223833.GA4309@tower.spodhuis.org> <1476053249.1594379.750625153.58F21EF5@webmail.messagingengine.com> <20161010131036.GC17876@glanzmann.de> <1476105541.3317580.751181353.553BB041@webmail.messagingengine.com> <1476195700.945573.752442825.4C7CDE8B@webmail.messagingengine.com> <87twciw63f.fsf@alice.fifthhorseman.net> <1476278885.2082508.753599713.74736041@webmail.messagingengine.com> <87pon5vdqd.fsf@alice.fifthhorseman.net> <0F63C671-4066-4CF4-813A-66BC544D16FF@sumptuouscapital.com> <87funypg42.fsf@alice.fifthhorseman.net> Message-ID: <1477498758.699207.768108641.6E1ABF0F@webmail.messagingengine.com> dkg - after this issue's back & forth, did you get this working by any chance? here, at least, gpg 2.1.x is still a non-starter. wondering whether to lock all our users to gpg 2.0.x ... From wk at gnupg.org Wed Oct 26 19:11:52 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 26 Oct 2016 19:11:52 +0200 Subject: Web Key Service draft requires binary representation keys In-Reply-To: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB659AA@S2008SBS.intern.giepa.de> (=?utf-8?Q?=22J=C3=BCrgen_Sch=C3=A4pker=22's?= message of "Wed, 26 Oct 2016 16:00:58 +0200") References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB659AA@S2008SBS.intern.giepa.de> Message-ID: <87d1in827b.fsf@wheatstone.g10code.de> On Wed, 26 Oct 2016 16:00, Juergen.Schaepker at giepa.de said: > Is there a specific reason why the (possibly problematic) binary representation was chosen? Why not ASCII armored keys instead? HTTP handles binary data just fine. There is no need to encode it. In contrast, when sending a key to the server we use mail. The PGP/MIME standard requires an ASCII armored key. This requirement is sound because mail is not 8 bit clean and sone kind of encoding would anyway be needed. So instead of using MIME's Base64 the PGP/MIME spec unfortunately demands the use of the Base64 variant from OpenPGP. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From dkg at fifthhorseman.net Wed Oct 26 21:23:43 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 26 Oct 2016 15:23:43 -0400 Subject: gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)" In-Reply-To: <1477498758.699207.768108641.6E1ABF0F@webmail.messagingengine.com> References: <1476027783.1522252.750391089.07374952@webmail.messagingengine.com> <20161009223833.GA4309@tower.spodhuis.org> <1476053249.1594379.750625153.58F21EF5@webmail.messagingengine.com> <20161010131036.GC17876@glanzmann.de> <1476105541.3317580.751181353.553BB041@webmail.messagingengine.com> <1476195700.945573.752442825.4C7CDE8B@webmail.messagingengine.com> <87twciw63f.fsf@alice.fifthhorseman.net> <1476278885.2082508.753599713.74736041@webmail.messagingengine.com> <87pon5vdqd.fsf@alice.fifthhorseman.net> <0F63C671-4066-4CF4-813A-66BC544D16FF@sumptuouscapital.com> <87funypg42.fsf@alice.fifthhorseman.net> <1477498758.699207.768108641.6E1ABF0F@webmail.messagingengine.com> Message-ID: <87r372ewxs.fsf@alice.fifthhorseman.net> On Wed 2016-10-26 12:19:18 -0400, lists at ssl-mail.com wrote: > after this issue's back & forth, did you get this working by any > chance? I haven't fixed this particular bug, no. Is it distinct from https://bugs.gnupg.org/gnupg/issue2451, as i asked in an earlier e-mail? Kristian has already said he's unable to reproduce the issue. can you provide a more specific summary that would allow other people to reproduce the issue? if so, would you be up for submitting a bug report so that we can try to get it nailed down? > here, at least, gpg 2.1.x is still a non-starter. wondering whether > to lock all our users to gpg 2.0.x ... I don't know who "our users" is, but "locking" to 2.0.x doesn't sound like a great thing for them, given the other advantages of 2.1.x. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From lists at ssl-mail.com Wed Oct 26 21:31:27 2016 From: lists at ssl-mail.com (lists at ssl-mail.com) Date: Wed, 26 Oct 2016 12:31:27 -0700 Subject: gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)" In-Reply-To: <87r372ewxs.fsf@alice.fifthhorseman.net> References: <1476027783.1522252.750391089.07374952@webmail.messagingengine.com> <20161009223833.GA4309@tower.spodhuis.org> <1476053249.1594379.750625153.58F21EF5@webmail.messagingengine.com> <20161010131036.GC17876@glanzmann.de> <1476105541.3317580.751181353.553BB041@webmail.messagingengine.com> <1476195700.945573.752442825.4C7CDE8B@webmail.messagingengine.com> <87twciw63f.fsf@alice.fifthhorseman.net> <1476278885.2082508.753599713.74736041@webmail.messagingengine.com> <87pon5vdqd.fsf@alice.fifthhorseman.net> <0F63C671-4066-4CF4-813A-66BC544D16FF@sumptuouscapital.com> <87funypg42.fsf@alice.fifthhorseman.net> <1477498758.699207.768108641.6E1ABF0F@webmail.messagingengine.com> <87r372ewxs.fsf@alice.fifthhorseman.net> Message-ID: <1477510287.741007.768309769.06F6C72B@webmail.messagingengine.com> On Wed, Oct 26, 2016, at 12:23 PM, Daniel Kahn Gillmor wrote: > On Wed 2016-10-26 12:19:18 -0400, lists at ssl-mail.com wrote: > > > after this issue's back & forth, did you get this working by any > > chance? > > I haven't fixed this particular bug, no. > Is it distinct from > https://bugs.gnupg.org/gnupg/issue2451, as i asked in an earlier e-mail? I don't know. I've not understood the responses here TBH. And am a bit confused that you can apparently reproduced this, but others can't. FWIW, it's still fully reproducible here. > can you provide a more specific summary that would allow other people to > reproduce the issue? if so, would you be up for submitting a bug report > so that we can try to get it nailed down? already did : https://bugs.gnupg.org/gnupg/issue2745 From dkg at fifthhorseman.net Wed Oct 26 22:37:06 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 26 Oct 2016 16:37:06 -0400 Subject: [PATCH 1/3] dirmngr: report actual socket name. Message-ID: <20161026203708.3214-1-dkg@fifthhorseman.net> * dirmngr/dirmngr.[ch] (dirmngr_get_current_socket_name): new function to report known socket name. * dirmngr/server.c (cmd_getinfo): use dirmngr_get_current_socket_name to report correct socket name -- This fixes the output of 'getinfo socket_name' when dirmngr is invoked with --socket-name. Signed-off-by: Daniel Kahn Gillmor --- dirmngr/dirmngr.c | 8 ++++++++ dirmngr/dirmngr.h | 1 + dirmngr/server.c | 2 +- 3 files changed, 10 insertions(+), 1 deletion(-) diff --git a/dirmngr/dirmngr.c b/dirmngr/dirmngr.c index 41e897b..f7f0d37 100644 --- a/dirmngr/dirmngr.c +++ b/dirmngr/dirmngr.c @@ -2074,3 +2074,11 @@ handle_connections (assuan_fd_t listen_fd) cleanup (); log_info ("%s %s stopped\n", strusage(11), strusage(13)); } + +const char* dirmngr_get_current_socket_name () +{ + if (socket_name) + return socket_name; + else + return dirmngr_socket_name (); +} diff --git a/dirmngr/dirmngr.h b/dirmngr/dirmngr.h index d823519..2a6ae3c 100644 --- a/dirmngr/dirmngr.h +++ b/dirmngr/dirmngr.h @@ -184,6 +184,7 @@ void dirmngr_exit( int ); /* Wrapper for exit() */ void dirmngr_init_default_ctrl (ctrl_t ctrl); void dirmngr_deinit_default_ctrl (ctrl_t ctrl); void dirmngr_sighup_action (void); +const char* dirmngr_get_current_socket_name (); /*-- Various housekeeping functions. --*/ diff --git a/dirmngr/server.c b/dirmngr/server.c index 0ad2713..1e2196c 100644 --- a/dirmngr/server.c +++ b/dirmngr/server.c @@ -2271,7 +2271,7 @@ cmd_getinfo (assuan_context_t ctx, char *line) } else if (!strcmp (line, "socket_name")) { - const char *s = dirmngr_socket_name (); + const char *s = dirmngr_get_current_socket_name (); err = assuan_send_data (ctx, s, strlen (s)); } else if (!strcmp (line, "tor")) -- 2.9.3 From dkg at fifthhorseman.net Wed Oct 26 22:37:07 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 26 Oct 2016 16:37:07 -0400 Subject: [PATCH 2/3] agent,common: move get_socket_name() into common. In-Reply-To: <20161026203708.3214-1-dkg@fifthhorseman.net> References: <20161026203708.3214-1-dkg@fifthhorseman.net> Message-ID: <20161026203708.3214-2-dkg@fifthhorseman.net> * agent/gpg-agent.c (get_socket_name): move to ... * common/sysutils.c (gnupg_get_socket_name): ... here. This allows us to use the same functionality in dirmngr as well. Signed-off-by: Daniel Kahn Gillmor --- agent/gpg-agent.c | 50 ++------------------------------------------------ common/sysutils.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++ common/sysutils.h | 1 + 3 files changed, 53 insertions(+), 48 deletions(-) diff --git a/agent/gpg-agent.c b/agent/gpg-agent.c index 6f73fc7..7294c69 100644 --- a/agent/gpg-agent.c +++ b/agent/gpg-agent.c @@ -573,52 +573,6 @@ remove_socket (char *name, char *redir_name) } -/* Return a malloc'ed string that is the path to the passed - * unix-domain socket (or return NULL if this is not a valid - * unix-domain socket). We use a plain int here because it is only - * used on Linux. - * - * FIXME: This function needs to be moved to libassuan. */ -#ifndef HAVE_W32_SYSTEM -static char * -get_socket_name (int fd) -{ - struct sockaddr_un un; - socklen_t len = sizeof(un); - char *name = NULL; - - if (getsockname (fd, (struct sockaddr*)&un, &len) != 0) - log_error ("could not getsockname(%d): %s\n", fd, - gpg_strerror (gpg_error_from_syserror ())); - else if (un.sun_family != AF_UNIX) - log_error ("file descriptor %d is not a unix-domain socket\n", fd); - else if (len <= offsetof (struct sockaddr_un, sun_path)) - log_error ("socket name not present for file descriptor %d\n", fd); - else if (len > sizeof(un)) - log_error ("socket name for file descriptor %d was truncated " - "(passed %zu bytes, wanted %u)\n", fd, sizeof(un), len); - else - { - size_t namelen = len - offsetof (struct sockaddr_un, sun_path); - - log_debug ("file descriptor %d has path %s (%zu octets)\n", fd, - un.sun_path, namelen); - name = xtrymalloc (namelen + 1); - if (!name) - log_error ("failed to allocate memory for name of fd %d: %s\n", - fd, gpg_strerror (gpg_error_from_syserror ())); - else - { - memcpy (name, un.sun_path, namelen); - name[namelen] = 0; - } - } - - return name; -} -#endif /*!HAVE_W32_SYSTEM*/ - - /* Discover which inherited file descriptors correspond to which * services/sockets offered by gpg-agent, using the LISTEN_FDS and * LISTEN_FDNAMES convention. The understood labels are "ssh", @@ -727,7 +681,7 @@ map_supervised_sockets (gnupg_fd_t *r_fd, log_fatal ("file descriptor 3 must be valid in --supervised mode" " if LISTEN_FDNAMES is not set\n"); *r_fd = 3; - socket_name = get_socket_name (3); + socket_name = gnupg_get_socket_name (3); } else if (fd_count != nfdnames) { @@ -749,7 +703,7 @@ map_supervised_sockets (gnupg_fd_t *r_fd, fd = 3 + i; if (**tbl[j].fdaddr == -1) { - name = get_socket_name (fd); + name = gnupg_get_socket_name (fd); if (name) { **tbl[j].fdaddr = fd; diff --git a/common/sysutils.c b/common/sysutils.c index 3a08df7..e04e10b 100644 --- a/common/sysutils.c +++ b/common/sysutils.c @@ -62,6 +62,9 @@ # include # endif # include +#else /*!HAVE_W32_SYSTEM*/ +# include +# include #endif #ifdef HAVE_INOTIFY_INIT # include @@ -1082,3 +1085,50 @@ gnupg_inotify_has_name (int fd, const char *name) return 0; /* Not found. */ } + + +/* Return a malloc'ed string that is the path to the passed + * unix-domain socket (or return NULL if this is not a valid + * unix-domain socket). We use a plain int here because it is only + * used on Linux. + * + * FIXME: This function needs to be moved to libassuan. */ +#ifndef HAVE_W32_SYSTEM +char * +gnupg_get_socket_name (int fd) +{ + struct sockaddr_un un; + socklen_t len = sizeof(un); + char *name = NULL; + + if (getsockname (fd, (struct sockaddr*)&un, &len) != 0) + log_error ("could not getsockname(%d): %s\n", fd, + gpg_strerror (gpg_error_from_syserror ())); + else if (un.sun_family != AF_UNIX) + log_error ("file descriptor %d is not a unix-domain socket\n", fd); + else if (len <= offsetof (struct sockaddr_un, sun_path)) + log_error ("socket name not present for file descriptor %d\n", fd); + else if (len > sizeof(un)) + log_error ("socket name for file descriptor %d was truncated " + "(passed %zu bytes, wanted %u)\n", fd, sizeof(un), len); + else + { + size_t namelen = len - offsetof (struct sockaddr_un, sun_path); + + log_debug ("file descriptor %d has path %s (%zu octets)\n", fd, + un.sun_path, namelen); + name = xtrymalloc (namelen + 1); + if (!name) + log_error ("failed to allocate memory for name of fd %d: %s\n", + fd, gpg_strerror (gpg_error_from_syserror ())); + else + { + memcpy (name, un.sun_path, namelen); + name[namelen] = 0; + } + } + + return name; +} +#endif /*!HAVE_W32_SYSTEM*/ + diff --git a/common/sysutils.h b/common/sysutils.h index ea92e4c..7105107 100644 --- a/common/sysutils.h +++ b/common/sysutils.h @@ -66,6 +66,7 @@ char *gnupg_mkdtemp (char *template); int gnupg_setenv (const char *name, const char *value, int overwrite); int gnupg_unsetenv (const char *name); char *gnupg_getcwd (void); +char *gnupg_get_socket_name (int fd); gpg_error_t gnupg_inotify_watch_socket (int *r_fd, const char *socket_name); int gnupg_inotify_has_name (int fd, const char *name); -- 2.9.3 From dkg at fifthhorseman.net Wed Oct 26 22:37:08 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 26 Oct 2016 16:37:08 -0400 Subject: [PATCH 3/3] dirmngr: Implement --supervised command (for systemd, etc). In-Reply-To: <20161026203708.3214-1-dkg@fifthhorseman.net> References: <20161026203708.3214-1-dkg@fifthhorseman.net> Message-ID: <20161026203708.3214-3-dkg@fifthhorseman.net> * dirmngr/dirmngr.c (main): Add new --supervised command, which is a mode designed for running under a process supervision system like systemd or runit. * doc/dirmngr.texi: document --supervised option. -- "dirmngr --supervised" is a way to invoke dirmngr such that a system supervisor like systemd can provide socket-activated startup, log management, and scheduled shutdown. When running in this mode, dirmngr: * Does not open its own listening socket; rather, it expects to be given a listening socket on file descriptor 3. * Does not detach from the invoking process, staying in the foreground instead. Signed-off-by: Daniel Kahn Gillmor --- dirmngr/dirmngr.c | 41 +++++++++++++++++++++++++++++++++++++++++ doc/dirmngr.texi | 7 +++++++ 2 files changed, 48 insertions(+) diff --git a/dirmngr/dirmngr.c b/dirmngr/dirmngr.c index f7f0d37..483eb65 100644 --- a/dirmngr/dirmngr.c +++ b/dirmngr/dirmngr.c @@ -88,6 +88,7 @@ enum cmd_and_opt_values { aServer, aDaemon, + aSupervised, aListCRLs, aLoadCRL, aFetchCRL, @@ -149,6 +150,7 @@ static ARGPARSE_OPTS opts[] = { ARGPARSE_c (aServer, "server", N_("run in server mode (foreground)") ), ARGPARSE_c (aDaemon, "daemon", N_("run in daemon mode (background)") ), + ARGPARSE_c (aSupervised, "supervised", N_("run under supervision (e.g. systemd)")), ARGPARSE_c (aListCRLs, "list-crls", N_("list the contents of the CRL cache")), ARGPARSE_c (aLoadCRL, "load-crl", N_("|FILE|load CRL from FILE into cache")), ARGPARSE_c (aFetchCRL, "fetch-crl", N_("|URL|fetch a CRL from URL")), @@ -814,6 +816,7 @@ main (int argc, char **argv) { case aServer: case aDaemon: + case aSupervised: case aShutdown: case aFlush: case aListCRLs: @@ -993,6 +996,44 @@ main (int argc, char **argv) start_command_handler (ASSUAN_INVALID_FD); shutdown_reaper (); } + else if (cmd == aSupervised) + { + /* In supervised mode, we expect file descriptor 3 to be an + already opened, listening socket. + + We will also not detach from the controlling process or close + stderr; the supervisor should handle all of that. + */ + struct stat statbuf; + if (fstat (3, &statbuf) == -1 && errno ==EBADF) + { + log_fatal (_("file descriptor 3 must be already open in --supervised mode\n")); + dirmngr_exit (1); + } + socket_name = gnupg_get_socket_name (3); + + /* Now start with logging to a file if this is desired. */ + if (logfile) + { + log_set_file (logfile); + log_set_prefix (NULL, (GPGRT_LOG_WITH_PREFIX + |GPGRT_LOG_WITH_TIME + |GPGRT_LOG_WITH_PID)); + current_logfile = xstrdup (logfile); + } + else + log_set_prefix (NULL, 0); + + thread_init (); + cert_cache_init (); + crl_cache_init (); +#if USE_LDAP + ldap_wrapper_launch_thread (); +#endif /*USE_LDAP*/ + handle_connections (3); + assuan_sock_close (3); + shutdown_reaper (); + } else if (cmd == aDaemon) { assuan_fd_t fd; diff --git a/doc/dirmngr.texi b/doc/dirmngr.texi index bb8281d..69d7e5e 100644 --- a/doc/dirmngr.texi +++ b/doc/dirmngr.texi @@ -85,6 +85,13 @@ Run in background daemon mode and listen for commands on a socket. Note that this also changes the default home directory and enables the internal certificate validation code. This mode is deprecated. + at item --supervised + at opindex supervised +Run in the foreground, sending logs to stderr, and listening on file +descriptor 3, which must already be bound to a listening socket. This +is useful when running under systemd or other similar process +supervision schemes. + @item --list-crls @opindex list-crls List the contents of the CRL cache on @code{stdout}. This is probably -- 2.9.3 From dkg at fifthhorseman.net Wed Oct 26 23:36:40 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 26 Oct 2016 17:36:40 -0400 Subject: gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)" In-Reply-To: <1477510287.741007.768309769.06F6C72B@webmail.messagingengine.com> References: <1476027783.1522252.750391089.07374952@webmail.messagingengine.com> <20161009223833.GA4309@tower.spodhuis.org> <1476053249.1594379.750625153.58F21EF5@webmail.messagingengine.com> <20161010131036.GC17876@glanzmann.de> <1476105541.3317580.751181353.553BB041@webmail.messagingengine.com> <1476195700.945573.752442825.4C7CDE8B@webmail.messagingengine.com> <87twciw63f.fsf@alice.fifthhorseman.net> <1476278885.2082508.753599713.74736041@webmail.messagingengine.com> <87pon5vdqd.fsf@alice.fifthhorseman.net> <0F63C671-4066-4CF4-813A-66BC544D16FF@sumptuouscapital.com> <87funypg42.fsf@alice.fifthhorseman.net> <1477498758.699207.768108641.6E1ABF0F@webmail.messagingengine.com> <87r372ewxs.fsf@alice.fifthhorseman.net> <1477510287.741007.768309769.06F6C72B@webmail.messagingengine.com> Message-ID: <87lgxaeqs7.fsf@alice.fifthhorseman.net> On Wed 2016-10-26 15:31:27 -0400, lists at ssl-mail.com wrote: > I don't know. I've not understood the responses here TBH. And am a bit confused that you can apparently reproduced this, but others can't. > > FWIW, it's still fully reproducible here. I'm not convinced i've fully reproduced this problem. >> can you provide a more specific summary that would allow other people to >> reproduce the issue? if so, would you be up for submitting a bug report >> so that we can try to get it nailed down? > > already did : https://bugs.gnupg.org/gnupg/issue2745 I followed up there with a description of what i tested and what i saw. The short takeway is: a) SRV records for the pool (_hkp._tcp.hkps.pool.sks-keyservers.net) came back NXDOMAIN b) as soon as that response came back, dirmngr sent out a request for A records for hkps.pool.sks-keyservers.net, which was fulfilled with 10 addresses c) dirmngr subsequently looked up PTR records for each of those addressses d) dirmngr was fine continuing to use some of those 10 addresses. So i'm not seeing anything like "no keyservers found", which is what you reported. That said, i'm not convinced this is the right DNS resolution strategy for dirmngr to use. I'll open that question in separate thread on this mailing list, though. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From dkg at fifthhorseman.net Thu Oct 27 00:39:25 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 26 Oct 2016 18:39:25 -0400 Subject: dirmngr DNS resolution strategy Message-ID: <87funienvm.fsf@alice.fifthhorseman.net> Hi GnuPG folks-- over in https://bugs.gnupg.org/gnupg/issue2745 i did a bit of inspection of dirmngr DNS traffic during a simple lookup. I did this from a temporary GNUPGHOME, via: GNUPGHOME=$(mktemp -d) gpg-connect-agent --dirmngr You can do this test yourself with: keyserver hkps://pool.sks-keyservers.net keyserver --resolve hkps://pool.sks-keyservers.net If you record the DNS traffic that results from this, you'll see: a) SRV records for the pool (_hkp._tcp.hkps.pool.sks-keyservers.net) came back NXDOMAIN b) as soon as that response came back, dirmngr sent out a request for A records for hkps.pool.sks-keyservers.net, which was fulfilled with 10 addresses c) dirmngr subsequently looked up PTR records for each of those addressses d) dirmngr was fine continuing to use some of those 10 addresses. This is all using the adns library, which should allow for asynchronous DNS requests. I'm assuming that the goal here is for dirmngr to be as fast as possible in its responses. This raises several questions for me: 0) There's no reason to have the request for A records (step b) sent out *after* the SRV response comes in. Both requests could be sent concurrently, and dirmngr could update its host table with whatever answers it gets. If you prefer SRV records, then discard any A responses that come in after SRV records, while overwriting any A responses that are already present when SRV responses come in. 1) Each of the PTR records looked up in step c were done one after the other. There should be no need to wait on this; if you need PTR records, simply send all 10 PTR requests concurrently, and process them as they come back in. This parallelization will reduce the number of round trips dramatically. 2) More importantly -- why does dirmngr need PTR records at all? what's the advantage of having them? If the user is asking to connect to a pool, doing a reverse DNS lookup just seems to be an additional round trip requirement. any thoughts? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From gniibe at fsij.org Thu Oct 27 01:24:53 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 27 Oct 2016 08:24:53 +0900 Subject: [PATCH] g10: Fix ECDH secret compressed/uncompressed format In-Reply-To: <58106F82.7050709@ssi.gouv.fr> References: <580DD7AC.1060001@ssi.gouv.fr> <580F0665.7010906@ssi.gouv.fr> <87oa28d406.fsf@wheatstone.g10code.de> <581062B5.2020601@ssi.gouv.fr> <58106F82.7050709@ssi.gouv.fr> Message-ID: <947548cd-e475-d31f-05b9-1833d3c78f26@fsij.org> On 10/26/2016 05:55 PM, Arnaud Fontaine wrote: > It ok for me, Thanks. I'll proceed that direction, merging your patch. >25519 is not supported by the OpenPGP card specification, right? True. Ed25519 for signing and X25519 for ECDH is not yet in the OpenPGP card specification. I'll write to Achim. ECDH by X25519 is also not yet in OpenPGP standard (while Ed25519 singing is). It would be good if I have capability, but the language for standard is too difficult for me. I'm sorry. Since my resource is limited and I need it for the priority of other hardware projects, I'm learning Chinese (Mandarin) now. With Kanji background, it's easier for me to read, but I have to learn many cultural differences. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Thu Oct 27 01:47:11 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 26 Oct 2016 19:47:11 -0400 Subject: python-gpgme test suite failures [was: Re: begging for pyme name change] In-Reply-To: References: <87insx8404.fsf@servo.finestructure.net> <87bmyoy5a9.fsf@europa.jade-hamburg.de> <877f9c88t7.fsf@servo.finestructure.net> <87k2dbucl4.fsf@alice.fifthhorseman.net> Message-ID: <87d1imekqo.fsf@alice.fifthhorseman.net> Hi James and others interested in python GnuPG bindings-- On Wed 2016-10-19 06:36:37 -0400, James Henstridge wrote: > The test suite covers most of the module's API, but in parts depends > on the behaviour of GPG itself (in the past I've had to patch it after > gpg upgrades). So a good approach would be to check that it passes > with current gpg/gpgme I started looking into this, and i find that it doesn't actually work with the current gpg 2.1 :/ Running from the current bzr head ("Allow building with gpgme versions < 1.4.") against gnupg 2.1.15-6 and libgpgme11 1.7.0 (in debian unstable), i see a bunch of errors (below). some similar ones have also been reported on the debian build systems here: https://bugs.debian.org/835174 I fixed a few of these test suite discrepancies back in February (https://bugs.debian.org/797776) but it seems that more have arisen since then. This makes it difficult for me to even start with the rest of the prospective API unification process. Are these errors things that you might be up for fixing upstream? If not, I'm starting to think that python-gpgme2 (along with deprecation of all the other bindings) would be the simplest approach toward cleaning up the python ecosystem here. --dkg test suite failures below: 0 dkg at alice:~/src/python-gpgme/pygpgme$ env -i make check < /dev/null python setup.py build_ext -i running build_ext GPG_AGENT_INFO= python test_all.py -v test_armor (tests.test_context.ContextTestCase) ... ok test_constructor (tests.test_context.ContextTestCase) ... ok test_include_certs (tests.test_context.ContextTestCase) ... ok test_keylist_mode (tests.test_context.ContextTestCase) ... ok test_passphrase_cb (tests.test_context.ContextTestCase) ... ok test_progress_cb (tests.test_context.ContextTestCase) ... ok test_protocol (tests.test_context.ContextTestCase) ... ok test_set_engine_info (tests.test_context.ContextTestCase) ... ok test_textmode (tests.test_context.ContextTestCase) ... ok test_key1 (tests.test_keys.KeyTestCase) ... ok test_key2 (tests.test_keys.KeyTestCase) ... ok test_revoked (tests.test_keys.KeyTestCase) ... ok test_signonly (tests.test_keys.KeyTestCase) ... ok test_list_by_email (tests.test_keylist.KeylistTestCase) ... ok test_list_by_email_substring (tests.test_keylist.KeylistTestCase) ... ok test_list_by_name (tests.test_keylist.KeylistTestCase) ... ok test_list_secret (tests.test_keylist.KeylistTestCase) ... ok test_listall (tests.test_keylist.KeylistTestCase) ... ok test_import_concat (tests.test_import.ImportTestCase) ... FAIL test_import_empty (tests.test_import.ImportTestCase) ... ok test_import_file (tests.test_import.ImportTestCase) ... ok test_import_secret_file (tests.test_import.ImportTestCase) ... FAIL test_import_stringio (tests.test_import.ImportTestCase) ... ok test_import_twice (tests.test_import.ImportTestCase) ... ok test_export_by_email (tests.test_export.ExportTestCase) ... ok test_export_by_fingerprint (tests.test_export.ExportTestCase) ... ok test_export_by_name (tests.test_export.ExportTestCase) ... ok test_delete_non_existant (tests.test_delete.DeleteTestCase) ... ok test_delete_public_key (tests.test_delete.DeleteTestCase) ... ok test_delete_public_key_with_secret_key (tests.test_delete.DeleteTestCase) ... ok test_delete_secret_key (tests.test_delete.DeleteTestCase) ... ok test_sign_clearsign (tests.test_sign_verify.SignVerifyTestCase) ... ok test_sign_detatch (tests.test_sign_verify.SignVerifyTestCase) ... ok test_sign_normal (tests.test_sign_verify.SignVerifyTestCase) ... ok test_sign_normal_armor (tests.test_sign_verify.SignVerifyTestCase) ... ok test_verify_bad_signature (tests.test_sign_verify.SignVerifyTestCase) ... ok test_verify_clearsign (tests.test_sign_verify.SignVerifyTestCase) ... ok test_verify_detached (tests.test_sign_verify.SignVerifyTestCase) ... ok test_verify_multiple_sigs (tests.test_sign_verify.SignVerifyTestCase) ... ok test_verify_no_signature (tests.test_sign_verify.SignVerifyTestCase) ... ok test_verify_normal (tests.test_sign_verify.SignVerifyTestCase) ... ok test_decrypt (tests.test_encrypt_decrypt.EncryptDecryptTestCase) ... ok test_decrypt_verify (tests.test_encrypt_decrypt.EncryptDecryptTestCase) ... ok test_encrypt (tests.test_encrypt_decrypt.EncryptDecryptTestCase) ... ok test_encrypt_armor (tests.test_encrypt_decrypt.EncryptDecryptTestCase) ... ok test_encrypt_sign (tests.test_encrypt_decrypt.EncryptDecryptTestCase) ... ok test_encrypt_symmetric (tests.test_encrypt_decrypt.EncryptDecryptTestCase) ... ERROR test_encrypt_to_signonly (tests.test_encrypt_decrypt.EncryptDecryptTestCase) ... FAIL test_sign_with_passphrase_cb (tests.test_passphrase.PassphraseTestCase) ... ERROR test_sign_without_passphrase_cb (tests.test_passphrase.PassphraseTestCase) ... FAIL test_sign_with_progress_cb (tests.test_progress.ProgressTestCase) ... ok test_edit_ownertrust (tests.test_editkey.EditKeyTestCase) ... ERROR test_edit_quit (tests.test_editkey.EditKeyTestCase) ... ERROR test_edit_sign (tests.test_editkey.EditKeyTestCase) ... ERROR test_invalid_parameters (tests.test_genkey.GenerateKeyTestCase) ... ok ====================================================================== ERROR: test_encrypt_symmetric (tests.test_encrypt_decrypt.EncryptDecryptTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/dkg/src/pygpgme/pygpgme/tests/test_encrypt_decrypt.py", line 136, in test_encrypt_symmetric ctx.encrypt(None, 0, plaintext, ciphertext) GpgmeError: (7, 11, u'Bad passphrase') ====================================================================== ERROR: test_sign_with_passphrase_cb (tests.test_passphrase.PassphraseTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/dkg/src/pygpgme/pygpgme/tests/test_passphrase.py", line 65, in test_sign_with_passphrase_cb new_sigs = ctx.sign(plaintext, signature, gpgme.SIG_MODE_CLEAR) GpgmeError: (5, 303, u'Unknown error code') ====================================================================== ERROR: test_edit_ownertrust (tests.test_editkey.EditKeyTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/dkg/src/pygpgme/pygpgme/tests/test_editkey.py", line 63, in test_edit_ownertrust gpgme.editutil.edit_trust(ctx, key, trust) File "/home/dkg/src/pygpgme/pygpgme/gpgme/editutil.py", line 75, in wrapper ctx.edit(key, edit_callback, output) GpgmeError: (32, 1, u'General error') ====================================================================== ERROR: test_edit_quit (tests.test_editkey.EditKeyTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/dkg/src/pygpgme/pygpgme/tests/test_editkey.py", line 48, in test_edit_quit ctx.edit(key, self.edit_quit_cb, output) GpgmeError: (0, 32779, u'Bad file descriptor') ====================================================================== ERROR: test_edit_sign (tests.test_editkey.EditKeyTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/dkg/src/pygpgme/pygpgme/tests/test_editkey.py", line 80, in test_edit_sign gpgme.editutil.edit_sign(ctx, key, check=0) File "/home/dkg/src/pygpgme/pygpgme/gpgme/editutil.py", line 75, in wrapper ctx.edit(key, edit_callback, output) GpgmeError: (32, 1, u'General error') ====================================================================== FAIL: test_import_concat (tests.test_import.ImportTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/dkg/src/pygpgme/pygpgme/tests/test_import.py", line 108, in test_import_concat self.assertEqual(result.imported_rsa, 1) AssertionError: 0 != 1 ====================================================================== FAIL: test_import_secret_file (tests.test_import.ImportTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/dkg/src/pygpgme/pygpgme/tests/test_import.py", line 75, in test_import_secret_file None, gpgme.IMPORT_NEW | gpgme.IMPORT_SECRET)) AssertionError: Tuples differ: (u'E79A842DA34A1CA383F64A1546B... != ('E79A842DA34A1CA383F64A1546BB... First differing element 2: 1 17 - (u'E79A842DA34A1CA383F64A1546BB55F0885C65A4', None, 1) ? - + ('E79A842DA34A1CA383F64A1546BB55F0885C65A4', None, 17) ? + ====================================================================== FAIL: test_encrypt_to_signonly (tests.test_encrypt_decrypt.EncryptDecryptTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/dkg/src/pygpgme/pygpgme/tests/test_encrypt_decrypt.py", line 185, in test_encrypt_to_signonly self.assertEqual(exc.args[0], gpgme.ERR_SOURCE_UNKNOWN) AssertionError: 7 != 0 ====================================================================== FAIL: test_sign_without_passphrase_cb (tests.test_passphrase.PassphraseTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/dkg/src/pygpgme/pygpgme/tests/test_passphrase.py", line 43, in test_sign_without_passphrase_cb self.assertEqual(exc.args[0], gpgme.ERR_SOURCE_GPGME) AssertionError: 5 != 7 ---------------------------------------------------------------------- Ran 55 tests in 49.933s FAILED (failures=4, errors=5) Makefile:7: recipe for target 'check' failed make: *** [check] Error 1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From lists at ssl-mail.com Thu Oct 27 02:48:10 2016 From: lists at ssl-mail.com (lists at ssl-mail.com) Date: Wed, 26 Oct 2016 17:48:10 -0700 Subject: gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)" In-Reply-To: <87lgxaeqs7.fsf@alice.fifthhorseman.net> References: <1476027783.1522252.750391089.07374952@webmail.messagingengine.com> <20161009223833.GA4309@tower.spodhuis.org> <1476053249.1594379.750625153.58F21EF5@webmail.messagingengine.com> <20161010131036.GC17876@glanzmann.de> <1476105541.3317580.751181353.553BB041@webmail.messagingengine.com> <1476195700.945573.752442825.4C7CDE8B@webmail.messagingengine.com> <87twciw63f.fsf@alice.fifthhorseman.net> <1476278885.2082508.753599713.74736041@webmail.messagingengine.com> <87pon5vdqd.fsf@alice.fifthhorseman.net> <0F63C671-4066-4CF4-813A-66BC544D16FF@sumptuouscapital.com> <87funypg42.fsf@alice.fifthhorseman.net> <1477498758.699207.768108641.6E1ABF0F@webmail.messagingengine.com> <87r372ewxs.fsf@alice.fifthhorseman.net> <1477510287.741007.768309769.06F6C72B@webmail.messagingengine.com> <87lgxaeqs7.fsf@alice.fifthhorseman.net> Message-ID: <1477529290.809174.768573305.106AA5E9@webmail.messagingengine.com> instead of polluting the bug report with noise, I'll keep my response here. When I try tro reproduce your tests, I'm still getting the "No keyserver available" biz, but not seeing all the other detail you do. rpm -qa | egrep -i gpg2 gpg2-lang-2.1.15-197.2.noarch gpg2-2.1.15-197.2.x86_64 gpg2 --version gpg (GnuPG) 2.1.15 libgcrypt 1.7.3 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: /root/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 dirmngr --version dirmngr (GnuPG) 2.1.15 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. GNUPGHOME=$(mktemp -d) gpg-connect-agent --dirmngr gpg-connect-agent: no running Dirmngr - starting '/usr/bin/dirmngr' gpg-connect-agent: waiting for the dirmngr to come up ... (5s) gpg-connect-agent: connection to the dirmngr established > getinfo dnsinfo OK - ADNS w/o Tor support > getinfo tor ERR 167772416 False - Tor mode is NOT enabled > keyserver --clear OK > keyserver hkps://hkps.pool.sks-keyservers.net OK > keyserver --resolve hkps://hkps.pool.sks-keyservers.net S # https://hkps.pool.sks-keyservers.net:443 OK > keyserver --hosttable S # hosttable (idx, ipv6, ipv4, dead, name, time): S # 0 hkps.pool.sks-keyservers.net OK > gpg -v --debug-all --recv-keys 0x673A03E4C1DB921F gpg: reading options from '/root/.gnupg/gpg.conf' gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing cardio ipc clock lookup extprog gpg: DBG: [not enabled in the source] start gpg: no running Dirmngr - starting '/usr/bin/dirmngr' gpg: waiting for the dirmngr to come up ... (5s) gpg: DBG: chan_3 <- # Home: /root/.gnupg gpg: DBG: chan_3 <- # Config: /root/.gnupg/dirmngr.conf gpg: DBG: chan_3 <- OK Dirmngr 2.1.15 at your service gpg: connection to the dirmngr established gpg: DBG: chan_3 -> GETINFO version gpg: DBG: chan_3 <- D 2.1.15 gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> KEYSERVER --clear hkps://hkps.pool.sks-keyservers.net:443 gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> KS_GET -- 0x673A03E4C1DB921F >>> gpg: DBG: chan_3 <- ERR 167772346 No keyserver available >>> gpg: keyserver receive failed: No keyserver available gpg: DBG: chan_3 -> BYE gpg: DBG: [not enabled in the source] stop gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 gpg: secmem usage: 0/65536 bytes in 0 blocks From gniibe at fsij.org Thu Oct 27 03:59:42 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 27 Oct 2016 10:59:42 +0900 Subject: [PATCH 3/3] dirmngr: Implement --supervised command (for systemd, etc). In-Reply-To: <20161026203708.3214-3-dkg@fifthhorseman.net> References: <20161026203708.3214-1-dkg@fifthhorseman.net> <20161026203708.3214-3-dkg@fifthhorseman.net> Message-ID: <33d7ac6e-aa6f-8a85-43f1-ce316cdbe6a5@fsij.org> Hello, I reviewed and applied all of your three patches. I fixed minor formatting and typing of C language issues. Pushed. Besides, On 10/27/2016 05:37 AM, Daniel Kahn Gillmor wrote: > --- a/dirmngr/dirmngr.c > +++ b/dirmngr/dirmngr.c > @@ -993,6 +996,44 @@ main (int argc, char **argv) > start_command_handler (ASSUAN_INVALID_FD); > shutdown_reaper (); > } > + else if (cmd == aSupervised) > + { > + /* In supervised mode, we expect file descriptor 3 to be an > + already opened, listening socket. > + > + We will also not detach from the controlling process or close > + stderr; the supervisor should handle all of that. > + */ > + struct stat statbuf; > + if (fstat (3, &statbuf) == -1 && errno ==EBADF) > + { > + log_fatal (_("file descriptor 3 must be already open in --supervised mode\n")); > + dirmngr_exit (1); > + } I changed log_fatal into log_error, so that dirmngr_exit will be called, and the message is not required to be translated, just like the one of gpg-agent.c. If these messages are needed to be translated, let us do that in another change consistently, so that we can minimize translators' work. -- From gniibe at fsij.org Thu Oct 27 06:32:39 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 27 Oct 2016 13:32:39 +0900 Subject: [PATCH] g10: Fix ECDH secret compressed/uncompressed format In-Reply-To: <947548cd-e475-d31f-05b9-1833d3c78f26@fsij.org> References: <580DD7AC.1060001@ssi.gouv.fr> <580F0665.7010906@ssi.gouv.fr> <87oa28d406.fsf@wheatstone.g10code.de> <581062B5.2020601@ssi.gouv.fr> <58106F82.7050709@ssi.gouv.fr> <947548cd-e475-d31f-05b9-1833d3c78f26@fsij.org> Message-ID: On 10/27/2016 08:24 AM, NIIBE Yutaka wrote: > Thanks. I'll proceed that direction, merging your patch. OK, done. I confirmed that "make check" works well. Please test with your card implementation. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From lists at ssl-mail.com Thu Oct 27 07:54:09 2016 From: lists at ssl-mail.com (lists at ssl-mail.com) Date: Wed, 26 Oct 2016 22:54:09 -0700 Subject: gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)" In-Reply-To: <20161027054027.GA94150@tower.spodhuis.org> References: <0F63C671-4066-4CF4-813A-66BC544D16FF@sumptuouscapital.com> <87funypg42.fsf@alice.fifthhorseman.net> <1477498758.699207.768108641.6E1ABF0F@webmail.messagingengine.com> <87r372ewxs.fsf@alice.fifthhorseman.net> <1477510287.741007.768309769.06F6C72B@webmail.messagingengine.com> <87lgxaeqs7.fsf@alice.fifthhorseman.net> <1477529290.809174.768573305.106AA5E9@webmail.messagingengine.com> <20161027054027.GA94150@tower.spodhuis.org> Message-ID: <1477547649.889014.768752481.05CFCFD0@webmail.messagingengine.com> On Wed, Oct 26, 2016, at 10:40 PM, Phil Pennock wrote: > Could you please put in a `getinfo version` here just to check that the > dirmngr you're talking to here is the same one found in $PATH when you > invoked the binary directly? > > And then, also while connected to dirmngr: > > keyserver --help > > to see the list of schemas which your build claims to know about, for > reaching keyservers. yep ... GNUPGHOME=$(mktemp -d) gpg-connect-agent --dirmngr gpg-connect-agent: no running Dirmngr - starting '/usr/bin/dirmngr' gpg-connect-agent: waiting for the dirmngr to come up ... (5s) gpg-connect-agent: connection to the dirmngr established > getinfo version D 2.1.15 OK > keyserver --help S # Known schemata: S # hkp S # hkps S # http S # https S # finger S # kdns S # ldap S # (Use an URL for engine specific help.) OK > From gnupg-devel at spodhuis.org Thu Oct 27 08:18:48 2016 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Thu, 27 Oct 2016 06:18:48 +0000 Subject: gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)" In-Reply-To: <1477547649.889014.768752481.05CFCFD0@webmail.messagingengine.com> References: <1477498758.699207.768108641.6E1ABF0F@webmail.messagingengine.com> <87r372ewxs.fsf@alice.fifthhorseman.net> <1477510287.741007.768309769.06F6C72B@webmail.messagingengine.com> <87lgxaeqs7.fsf@alice.fifthhorseman.net> <1477529290.809174.768573305.106AA5E9@webmail.messagingengine.com> <20161027054027.GA94150@tower.spodhuis.org> <1477547649.889014.768752481.05CFCFD0@webmail.messagingengine.com> Message-ID: <20161027061848.GA35495@tower.spodhuis.org> On 2016-10-26 at 22:54 -0700, lists at ssl-mail.com wrote: > > getinfo version > D 2.1.15 > OK > > keyserver --help > S # Known schemata: > S # hkp > S # hkps [...] At this point, I'm grasping at straws. "It works for me"(tm). (I'm one of the keyserver operators with an interest in this working). The only thing which comes to mind is a vague recollection that adns parses some things from /etc/resolv.conf in a different order to the "usual" resolver libraries ... my memory says "search and domain" getting stomped upon, but perhaps also trying available nameservers differently (round-robin instead of the usual first-to-succeed)? Check if all the nameservers in /etc/resolv.conf are functioning correctly? Including if some are only available in certain VPN configurations? Beyond that, stumped. -Phil From gnupg-devel at spodhuis.org Thu Oct 27 07:40:27 2016 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Thu, 27 Oct 2016 05:40:27 +0000 Subject: gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)" In-Reply-To: <1477529290.809174.768573305.106AA5E9@webmail.messagingengine.com> References: <0F63C671-4066-4CF4-813A-66BC544D16FF@sumptuouscapital.com> <87funypg42.fsf@alice.fifthhorseman.net> <1477498758.699207.768108641.6E1ABF0F@webmail.messagingengine.com> <87r372ewxs.fsf@alice.fifthhorseman.net> <1477510287.741007.768309769.06F6C72B@webmail.messagingengine.com> <87lgxaeqs7.fsf@alice.fifthhorseman.net> <1477529290.809174.768573305.106AA5E9@webmail.messagingengine.com> Message-ID: <20161027054027.GA94150@tower.spodhuis.org> On 2016-10-26 at 17:48 -0700, lists at ssl-mail.com wrote: > dirmngr --version > dirmngr (GnuPG) 2.1.15 > GNUPGHOME=$(mktemp -d) gpg-connect-agent --dirmngr > gpg-connect-agent: no running Dirmngr - starting '/usr/bin/dirmngr' > gpg-connect-agent: waiting for the dirmngr to come up ... (5s) > gpg-connect-agent: connection to the dirmngr established > > getinfo dnsinfo > OK - ADNS w/o Tor support Could you please put in a `getinfo version` here just to check that the dirmngr you're talking to here is the same one found in $PATH when you invoked the binary directly? And then, also while connected to dirmngr: keyserver --help to see the list of schemas which your build claims to know about, for reaching keyservers. -Phil From arnaud.fontaine at ssi.gouv.fr Thu Oct 27 09:32:51 2016 From: arnaud.fontaine at ssi.gouv.fr (Arnaud Fontaine) Date: Thu, 27 Oct 2016 09:32:51 +0200 Subject: [PATCH] g10: Fix ECDH secret compressed/uncompressed format In-Reply-To: References: <580DD7AC.1060001@ssi.gouv.fr> <580F0665.7010906@ssi.gouv.fr> <87oa28d406.fsf@wheatstone.g10code.de> <581062B5.2020601@ssi.gouv.fr> <58106F82.7050709@ssi.gouv.fr> <947548cd-e475-d31f-05b9-1833d3c78f26@fsij.org> Message-ID: <5811ADA3.1050209@ssi.gouv.fr> Le 27/10/2016 06:32, NIIBE Yutaka a ?crit : > On 10/27/2016 08:24 AM, NIIBE Yutaka wrote: >> Thanks. I'll proceed that direction, merging your patch. > > OK, done. I confirmed that "make check" works well. > > Please test with your card implementation. I have tested with all curves and have not seen any problem :-) Thanks again ! From wk at gnupg.org Thu Oct 27 09:46:08 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 27 Oct 2016 09:46:08 +0200 Subject: [PATCH] g10: Fix ECDH secret compressed/uncompressed format In-Reply-To: <947548cd-e475-d31f-05b9-1833d3c78f26@fsij.org> (NIIBE Yutaka's message of "Thu, 27 Oct 2016 08:24:53 +0900") References: <580DD7AC.1060001@ssi.gouv.fr> <580F0665.7010906@ssi.gouv.fr> <87oa28d406.fsf@wheatstone.g10code.de> <581062B5.2020601@ssi.gouv.fr> <58106F82.7050709@ssi.gouv.fr> <947548cd-e475-d31f-05b9-1833d3c78f26@fsij.org> Message-ID: <87pomm6xq7.fsf@wheatstone.g10code.de> On Thu, 27 Oct 2016 01:24, gniibe at fsij.org said: > ECDH by X25519 is also not yet in OpenPGP standard (while Ed25519 > singing is). Well, OpenPGP allows the specification of an UID to describe the used curve. What kind of curve this is is not specified and thus our use of X25519 is compliant with the standard. RFC4880bis will likely document the OID and the specification for X25519 and maybe even declare this as SHOULD or MUST algorithm. For Ed25519 we use an entire different algorithm which would have been to ugly to somehow declare this as an ECDSA variant. The description is already part of RFC4880bis (the plannned updated of OpenPGP). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From lists at ssl-mail.com Thu Oct 27 14:56:02 2016 From: lists at ssl-mail.com (lists at ssl-mail.com) Date: Thu, 27 Oct 2016 05:56:02 -0700 Subject: gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)" In-Reply-To: <20161027061848.GA35495@tower.spodhuis.org> References: <1477498758.699207.768108641.6E1ABF0F@webmail.messagingengine.com> <87r372ewxs.fsf@alice.fifthhorseman.net> <1477510287.741007.768309769.06F6C72B@webmail.messagingengine.com> <87lgxaeqs7.fsf@alice.fifthhorseman.net> <1477529290.809174.768573305.106AA5E9@webmail.messagingengine.com> <20161027054027.GA94150@tower.spodhuis.org> <1477547649.889014.768752481.05CFCFD0@webmail.messagingengine.com> <20161027061848.GA35495@tower.spodhuis.org> Message-ID: <1477572962.1812513.769065633.63E6899A@webmail.messagingengine.com> On Wed, Oct 26, 2016, at 11:18 PM, Phil Pennock wrote: > Check if all the nameservers in /etc/resolv.conf are functioning > correctly? Including if some are only available in certain VPN > configurations? They're working correctly. I've tested as well with simplest config -- just one nameserver entry. Whether that's Google NS, or my own Bind9 instance, result's unfortunately the same. From dkg at fifthhorseman.net Thu Oct 27 15:52:12 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 27 Oct 2016 09:52:12 -0400 Subject: gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)" In-Reply-To: <1477529290.809174.768573305.106AA5E9@webmail.messagingengine.com> References: <1476027783.1522252.750391089.07374952@webmail.messagingengine.com> <20161009223833.GA4309@tower.spodhuis.org> <1476053249.1594379.750625153.58F21EF5@webmail.messagingengine.com> <20161010131036.GC17876@glanzmann.de> <1476105541.3317580.751181353.553BB041@webmail.messagingengine.com> <1476195700.945573.752442825.4C7CDE8B@webmail.messagingengine.com> <87twciw63f.fsf@alice.fifthhorseman.net> <1476278885.2082508.753599713.74736041@webmail.messagingengine.com> <87pon5vdqd.fsf@alice.fifthhorseman.net> <0F63C671-4066-4CF4-813A-66BC544D16FF@sumptuouscapital.com> <87funypg42.fsf@alice.fifthhorseman.net> <1477498758.699207.768108641.6E1ABF0F@webmail.messagingengine.com> <87r372ewxs.fsf@alice.fifthhorseman.net> <1477510287.741007.768309769.06F6C72B@webmail.messagingengine.com> <87lgxaeqs7.fsf@alice.fifthh orseman.net> <1477529290.809174.768573305.106AA5E9@webmail.messagingengine.com> Message-ID: <87a8dpew6r.fsf@alice.fifthhorseman.net> On Wed 2016-10-26 20:48:10 -0400, lists at ssl-mail.com wrote: > instead of polluting the bug report with noise, I'll keep my response > here. It's not polluting the bug report to provide relevant data. :) > When I try tro reproduce your tests, I'm still getting the "No > keyserver available" biz, but not seeing all the other detail you do. You haven't bothered to show a packet capture of all DNS traffic during this process. Can you do so? In particular, if your nameserver is 8.8.8.8 you should be able to do this with: tcpdump -s 0 -w dirmngr-dns.pcap host 8.8.8.8 And then run the test sequence. Once the test sequence is done, hit ctrl-c in the terminal that is running tcpdump. if you are concerned that there is private data in the captured file, and you don't want to post it publicly, but you're willing to share it with me, you can mail it to me using key 0x0EE5BE979282D80B9F7540F1CCD2ED94D21739E9 and i'll take a look at it with you. As it stands, i am unable to reproduce the behavior you're describing. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From lists at ssl-mail.com Thu Oct 27 16:02:21 2016 From: lists at ssl-mail.com (lists at ssl-mail.com) Date: Thu, 27 Oct 2016 07:02:21 -0700 Subject: gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)" In-Reply-To: <87a8dpew6r.fsf@alice.fifthhorseman.net> References: <1476027783.1522252.750391089.07374952@webmail.messagingengine.com> <20161009223833.GA4309@tower.spodhuis.org> <1476053249.1594379.750625153.58F21EF5@webmail.messagingengine.com> <20161010131036.GC17876@glanzmann.de> <1476105541.3317580.751181353.553BB041@webmail.messagingengine.com> <1476195700.945573.752442825.4C7CDE8B@webmail.messagingengine.com> <87twciw63f.fsf@alice.fifthhorseman.net> <1476278885.2082508.753599713.74736041@webmail.messagingengine.com> <87pon5vdqd.fsf@alice.fifthhorseman.net> <0F63C671-4066-4CF4-813A-66BC544D16FF@sumptuouscapital.com> <87funypg42.fsf@alice.fifthhorseman.net> <1477498758.699207.768108641.6E1ABF0F@webmail.messagingengine.com> <87r372ewxs.fsf@alice.fifthhorseman.net> <1477510287.741007.768309769.06F6C72B@webmail.messagingengine.com> <1477529290.809174.768573305.106AA5E9@webmail.messagingengine.com> <87a8dpew6r.fsf@alice.fifthhorseman.net> Message-ID: <1477576941.1828302.769136625.79A5A27E@webmail.messagingengine.com> On Thu, Oct 27, 2016, at 06:52 AM, Daniel Kahn Gillmor wrote: > You haven't bothered to show a packet capture of all DNS traffic during > this process. Can you do so? Minor confusion here ... how is what you're looking for now different than the packet grab you looked at here: https://lists.gnupg.org/pipermail/gnupg-devel/2016-October/031804.html ? From dkg at fifthhorseman.net Thu Oct 27 16:13:17 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 27 Oct 2016 10:13:17 -0400 Subject: gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)" In-Reply-To: <1477576941.1828302.769136625.79A5A27E@webmail.messagingengine.com> References: <1476027783.1522252.750391089.07374952@webmail.messagingengine.com> <20161009223833.GA4309@tower.spodhuis.org> <1476053249.1594379.750625153.58F21EF5@webmail.messagingengine.com> <20161010131036.GC17876@glanzmann.de> <1476105541.3317580.751181353.553BB041@webmail.messagingengine.com> <1476195700.945573.752442825.4C7CDE8B@webmail.messagingengine.com> <87twciw63f.fsf@alice.fifthhorseman.net> <1476278885.2082508.753599713.74736041@webmail.messagingengine.com> <87pon5vdqd.fsf@alice.fifthhorseman.net> <0F63C671-4066-4CF4-813A-66BC544D16FF@sumptuouscapital.com> <87funypg42.fsf@alice.fifthhorseman.net> <1477498758.699207.768108641.6E1ABF0F@webmail.messagingengine.com> <87r372ewxs.fsf@alice.fifthhorseman.net> <1477510287.741007.768309769.06F6C72B@webmail.messagingengine.com> <1477529290.809174.768573305 .106AA5E9@webmail.messagingengine.com> <87a8dpew6r.fsf@alice.fifthhorseman.net> <1477576941.1828302.769136625.79A5A27E@webmail.messagingengine.com> Message-ID: <871sz1ev7m.fsf@alice.fifthhorseman.net> On Thu 2016-10-27 10:02:21 -0400, lists at ssl-mail.com wrote: > On Thu, Oct 27, 2016, at 06:52 AM, Daniel Kahn Gillmor wrote: >> You haven't bothered to show a packet capture of all DNS traffic during >> this process. Can you do so? > > Minor confusion here ... how is what you're looking for now different than the packet grab you looked at here: > > https://lists.gnupg.org/pipermail/gnupg-devel/2016-October/031804.html It might well be the same packet grab, but we're not seeing the same behavior. You're seeing dirmngr make a single query for an SRV records, and then giving up when NXDOMAIN comes back. I'm seeing dirmngr make a single query for an SRV record, and then when an NXDOMAIN comes back, following up with an A record request. I have no idea why you're seeing different behavior than i'm seeing. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From kristian.fiskerstrand at sumptuouscapital.com Thu Oct 27 16:17:54 2016 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Thu, 27 Oct 2016 16:17:54 +0200 Subject: gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)" In-Reply-To: <871sz1ev7m.fsf@alice.fifthhorseman.net> References: <1476027783.1522252.750391089.07374952@webmail.messagingengine.com> <1476195700.945573.752442825.4C7CDE8B@webmail.messagingengine.com> <87twciw63f.fsf@alice.fifthhorseman.net> <1476278885.2082508.753599713.74736041@webmail.messagingengine.com> <87pon5vdqd.fsf@alice.fifthhorseman.net> <0F63C671-4066-4CF4-813A-66BC544D16FF@sumptuouscapital.com> <87funypg42.fsf@alice.fifthhorseman.net> <1477498758.699207.768108641.6E1ABF0F@webmail.messagingengine.com> <87r372ewxs.fsf@alice.fifthhorseman.net> <1477510287.741007.768309769.06F6C72B@webmail.messagingengine.com> <1477529290.809174.768573305 .106AA5E9@webmail.messagingengine.com> <87a8dpew6r.fsf@alice.fifthhorseman.net> <1477576941.1828302.769136625.79A5A27E@webmail.messagingengine.com> <871sz1ev7m.fsf@alice.fifthhorseman.net> Message-ID: <1fa41ed3-13d5-fd0a-2795-4064e58155ad@sumptuouscapital.com> On 10/27/2016 04:13 PM, Daniel Kahn Gillmor wrote: > On Thu 2016-10-27 10:02:21 -0400, lists at ssl-mail.com wrote: >> On Thu, Oct 27, 2016, at 06:52 AM, Daniel Kahn Gillmor wrote: .. > I have no idea why you're seeing different behavior than i'm seeing. > No idea if it can be related, but keep in mind sometimes DNS switches from UDP to TCP on same port due to payload size, so make sure to monitor both protocols (and that both are permitted in firewall) -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "The journey of a thousand miles begins with one step." (Lao Tzu) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From lists at ssl-mail.com Thu Oct 27 16:39:03 2016 From: lists at ssl-mail.com (lists at ssl-mail.com) Date: Thu, 27 Oct 2016 07:39:03 -0700 Subject: gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)" In-Reply-To: <871sz1ev7m.fsf@alice.fifthhorseman.net> References: <1476027783.1522252.750391089.07374952@webmail.messagingengine.com> <20161009223833.GA4309@tower.spodhuis.org> <1476053249.1594379.750625153.58F21EF5@webmail.messagingengine.com> <20161010131036.GC17876@glanzmann.de> <1476105541.3317580.751181353.553BB041@webmail.messagingengine.com> <1476195700.945573.752442825.4C7CDE8B@webmail.messagingengine.com> <87twciw63f.fsf@alice.fifthhorseman.net> <1476278885.2082508.753599713.74736041@webmail.messagingengine.com> <87pon5vdqd.fsf@alice.fifthhorseman.net> <0F63C671-4066-4CF4-813A-66BC544D16FF@sumptuouscapital.com> <87funypg42.fsf@alice.fifthhorseman.net> <1477498758.699207.768108641.6E1ABF0F@webmail.messagingengine.com> <87r372ewxs.fsf@alice.fifthhorseman.net> <1477510287.741007.768309769.06F6C72B@webmail.messagingengine.com> <87a8dpew6r.fsf@alice.fifthhorseman.net> <1477576941.1828302.769136625.79A5A27E@webmail.messagingengine.com> <871sz1ev7m.fsf@alice.fifthhorseman.net> Message-ID: <1477579143.1836029.769179545.31F4BBBD@webmail.messagingengine.com> On Thu, Oct 27, 2016, at 07:13 AM, Daniel Kahn Gillmor wrote: > In particular, if your nameserver is 8.8.8.8 you should be able to do > this with: > > tcpdump -s 0 -w dirmngr-dns.pcap host 8.8.8.8 > > And then run the test sequence. > using external NS (8.8.8.8) rather than my LAN's NS 2 packets captured 2 packets received by filter 0 packets dropped by kernel same as before export, now No. Time Source Destination Protocol Length Info 1 0.000000 10.19.2.7 8.8.8.8 DNS 98 Standard query 0x311f SRV _hkp._tcp.hkps.pool.sks-keyservers.net Frame 1: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) Ethernet II, Src: AsustekC_19:c3:26 (00:26:18:19:c3:26), Dst: Trendnet_c4:11:d9 (d8:eb:97:c4:11:d9) Internet Protocol Version 4, Src: 10.19.2.7, Dst: 8.8.8.8 User Datagram Protocol, Src Port: 56463, Dst Port: 53 Domain Name System (query) No. Time Source Destination Protocol Length Info 2 0.124320 8.8.8.8 10.19.2.7 DNS 148 Standard query response 0x311f No such name SRV _hkp._tcp.hkps.pool.sks-keyservers.net SOA ns2.kfwebs.net Frame 2: 148 bytes on wire (1184 bits), 148 bytes captured (1184 bits) Ethernet II, Src: Trendnet_c4:11:d9 (d8:eb:97:c4:11:d9), Dst: AsustekC_19:c3:26 (00:26:18:19:c3:26) Internet Protocol Version 4, Src: 8.8.8.8, Dst: 10.19.2.7 User Datagram Protocol, Src Port: 53, Dst Port: 56463 Domain Name System (response) export, before > ---------------------------------------- > No. Time Source Destination Protocol Length Info > 1 0.000000 10.19.2.7 10.19.2.100 DNS 98 Standard query 0x311f SRV _hkp._tcp.hkps.pool.sks-keyservers.net > > Frame 1: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) > Ethernet II, Src: AsustekC_19:c3:26 (00:26:18:19:c3:26), Dst: Trendnet_c4:11:d9 (d8:eb:97:c4:11:d9) > Internet Protocol Version 4, Src: 10.19.2.7, Dst: 10.19.2.100 > User Datagram Protocol, Src Port: 51597, Dst Port: 53 > Domain Name System (query) > > No. Time Source Destination Protocol Length Info > 2 0.544341 10.19.2.100 10.19.2.7 DNS 148 Standard query response 0x311f No such name SRV _hkp._tcp.hkps.pool.sks-keyservers.net SOA ns2.kfwebs.net > > Frame 2: 148 bytes on wire (1184 bits), 148 bytes captured (1184 bits) > Ethernet II, Src: Trendnet_c4:11:d9 (d8:eb:97:c4:11:d9), Dst: AsustekC_19:c3:26 (00:26:18:19:c3:26) > Internet Protocol Version 4, Src: 10.19.2.100, Dst: 10.19.2.7 > User Datagram Protocol, Src Port: 53, Dst Port: 51597 > Domain Name System (response) > ---------------------------------------- Also checked this from several machines on the LAN here. Same result. From dkg at fifthhorseman.net Thu Oct 27 17:40:10 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 27 Oct 2016 11:40:10 -0400 Subject: gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)" In-Reply-To: <1fa41ed3-13d5-fd0a-2795-4064e58155ad@sumptuouscapital.com> References: <1476027783.1522252.750391089.07374952@webmail.messagingengine.com> <1476195700.945573.752442825.4C7CDE8B@webmail.messagingengine.com> <87twciw63f.fsf@alice.fifthhorseman.net> <1476278885.2082508.753599713.74736041@webmail.messagingengine.com> <87pon5vdqd.fsf@alice.fifthhorseman.net> <0F63C671-4066-4CF4-813A-66BC544D16FF@sumptuouscapital.com> <87funypg42.fsf@alice.fifthhorseman.net> <1477498758.699207.768108641.6E1ABF0F@webmail.messagingengine.com> <87r372ewxs.fsf@alice.fifthhorseman.net> <1477510287.741007.768309769.06F6C72B@webmail.messagingengine.com> <87a8dpew6r.fsf@alice.fifthhorseman.net> <1477576941.1828302.769136625.79A5A27E@webmail.messagingengine.com> <871sz1ev7m.fsf@alice.fifthhorseman.net> <1fa41ed3-13d5-fd0a-2795-4064e58155ad@sumptuouscapital.com> Message-ID: <87oa25dcmd.fsf@alice.fifthhorseman.net> On Thu 2016-10-27 10:17:54 -0400, Kristian Fiskerstrand wrote: > On 10/27/2016 04:13 PM, Daniel Kahn Gillmor wrote: >> On Thu 2016-10-27 10:02:21 -0400, lists at ssl-mail.com wrote: >>> On Thu, Oct 27, 2016, at 06:52 AM, Daniel Kahn Gillmor wrote: > .. > >> I have no idea why you're seeing different behavior than i'm seeing. >> > > No idea if it can be related, but keep in mind sometimes DNS switches > from UDP to TCP on same port due to payload size, so make sure to > monitor both protocols (and that both are permitted in firewall) fwiw, it doesn't look like "lists" is seeing any subsequent requests at all. even if the firewall was blocking responses, the requests themselves should be visible. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From lists at ssl-mail.com Thu Oct 27 17:44:50 2016 From: lists at ssl-mail.com (lists at ssl-mail.com) Date: Thu, 27 Oct 2016 08:44:50 -0700 Subject: gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)" In-Reply-To: <87oa25dcmd.fsf@alice.fifthhorseman.net> References: <1476027783.1522252.750391089.07374952@webmail.messagingengine.com> <1476195700.945573.752442825.4C7CDE8B@webmail.messagingengine.com> <87twciw63f.fsf@alice.fifthhorseman.net> <1476278885.2082508.753599713.74736041@webmail.messagingengine.com> <87pon5vdqd.fsf@alice.fifthhorseman.net> <0F63C671-4066-4CF4-813A-66BC544D16FF@sumptuouscapital.com> <87funypg42.fsf@alice.fifthhorseman.net> <1477498758.699207.768108641.6E1ABF0F@webmail.messagingengine.com> <87r372ewxs.fsf@alice.fifthhorseman.net> <1477510287.741007.768309769.06F6C72B@webmail.messagingengine.com> <87a8dpew6r.fsf@alice.fifthhorseman.net> <1477576941.1828302.769136625.79A5A27E@webmail.messagingengine.com> <871sz1ev7m.fsf@alice.fifthhorseman.net> <1fa41ed3-13d5-fd0a-2795-4064e58155ad@sumptuouscapital.com> <87oa25dcmd.fsf@alice.fifthhorseman.net> Message-ID: <1477583090.1851540.769258633.7F4076E0@webmail.messagingengine.com> On Thu, Oct 27, 2016, at 08:40 AM, Daniel Kahn Gillmor wrote: > > No idea if it can be related, but keep in mind sometimes DNS switches > > from UDP to TCP on same port due to payload size, so make sure to > > monitor both protocols (and that both are permitted in firewall) > > fwiw, it doesn't look like "lists" is seeing any subsequent requests at > all. even if the firewall was blocking responses, the requests > themselves should be visible. fwiw here, fw's open & tested for both udp/tcp 53. edns is tested/vrified. no other apps have any sort of dns issues. etc etc From dkg at fifthhorseman.net Thu Oct 27 20:19:18 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 27 Oct 2016 14:19:18 -0400 Subject: [PATCH] systemd: Include config for socket-activated user services. Message-ID: <20161027181918.920-1-dkg@fifthhorseman.net> * doc/examples/systemd-user/README: New file describing how to set up these user services for both system integrators and end users. * doc/examples/systemd-user/dirmngr.service: New user service file. * doc/examples/systemd-user/dirmngr.socket: New socket-activation configuration. * doc/examples/systemd-user/gpg-agent.service: New user service file. * doc/examples/systemd-user/gpg-agent*.socket: New socket-activation configurations. * doc/Makefile.am: ship these files in the examples directory. -- These configuration files and instructions enable clean and simple daemon supervision on machines that run systemd. Signed-off-by: Daniel Kahn Gillmor --- doc/Makefile.am | 9 ++- doc/examples/systemd-user/README | 66 ++++++++++++++++++++++ doc/examples/systemd-user/dirmngr.service | 10 ++++ doc/examples/systemd-user/dirmngr.socket | 11 ++++ doc/examples/systemd-user/gpg-agent-browser.socket | 13 +++++ doc/examples/systemd-user/gpg-agent-extra.socket | 13 +++++ doc/examples/systemd-user/gpg-agent-ssh.socket | 13 +++++ doc/examples/systemd-user/gpg-agent.service | 10 ++++ doc/examples/systemd-user/gpg-agent.socket | 12 ++++ 9 files changed, 156 insertions(+), 1 deletion(-) create mode 100644 doc/examples/systemd-user/README create mode 100644 doc/examples/systemd-user/dirmngr.service create mode 100644 doc/examples/systemd-user/dirmngr.socket create mode 100644 doc/examples/systemd-user/gpg-agent-browser.socket create mode 100644 doc/examples/systemd-user/gpg-agent-extra.socket create mode 100644 doc/examples/systemd-user/gpg-agent-ssh.socket create mode 100644 doc/examples/systemd-user/gpg-agent.service create mode 100644 doc/examples/systemd-user/gpg-agent.socket diff --git a/doc/Makefile.am b/doc/Makefile.am index 52ac398..53d3084 100644 --- a/doc/Makefile.am +++ b/doc/Makefile.am @@ -21,7 +21,14 @@ AM_CPPFLAGS = include $(top_srcdir)/am/cmacros.am -examples = examples/README examples/scd-event examples/trustlist.txt \ +examples = examples/README examples/scd-event examples/trustlist.txt \ + examples/systemd-user/README \ + examples/systemd-user/dirmngr.service \ + examples/systemd-user/dirmngr.socket \ + examples/systemd-user/gpg-agent.service \ + examples/systemd-user/gpg-agent.socket \ + examples/systemd-user/gpg-agent-ssh.socket \ + examples/systemd-user/gpg-agent-extra.socket \ examples/gpgconf.conf examples/pwpattern.list helpfiles = help.txt help.be.txt help.ca.txt help.cs.txt \ diff --git a/doc/examples/systemd-user/README b/doc/examples/systemd-user/README new file mode 100644 index 0000000..43122f5 --- /dev/null +++ b/doc/examples/systemd-user/README @@ -0,0 +1,66 @@ +Socket-activated dirmngr and gpg-agent with systemd +=================================================== + +When used on a GNU/Linux system supervised by systemd, you can ensure +that the GnuPG daemons dirmngr and gpg-agent are launched +automatically the first time they're needed, and shut down cleanly at +session logout. This is done by enabling user services via +socket-activation. + +System distributors +------------------- + +The *.service and *.socket files (from this directory) should be +placed in /usr/lib/systemd/user/ alongside other user-session services +and sockets. + +To enable socket-activated dirmngr for all accounts on the system, +use: + + systemctl --user --global enable dirmngr.socket + +To enable socket-activated gpg-agent for all accounts on the system, +use: + + systemctl --user --global enable gpg-agent.socket + +Additionally, you can enable socket-activated gpg-agent ssh-agent +emulation for all accounts on the system with: + + systemctl --user --global enable gpg-agent-ssh.socket + +You can also enable restricted ("--extra-socket"-style) gpg-agent +sockets for all accounts on the system with: + + systemctl --user --global enable gpg-agent-extra.socket + +Individual users +---------------- + +A user on a system with systemd where this has not been installed +system-wide can place these files in ~/.config/systemd/user/ to make +them available. + +If a given service isn't installed system-wide, or if it's installed +system-wide but not globally enabled, individual users will still need +to enable them. For example, to enable socket-activated dirmngr for +all future sessions: + + systemctl --user enable dirmngr.socket + +To enable socket-activated gpg-agent with ssh support, do: + + systemctl --user enable gpg-agent.socket gpg-agent-ssh.socket + +These changes won't take effect until your next login after you've +fully logged out (be sure to terminate any running daemons before +logging out). + +If you'd rather try a socket-activated GnuPG daemon in an +already-running session without logging out (with or without enabling +it for all future sessions), kill any existing daemon and start the +user socket directly. For example, to set up socket-activated dirmgnr +in the current session: + + gpgconf --kill dirmngr + systemctl --user start dirmngr.socket diff --git a/doc/examples/systemd-user/dirmngr.service b/doc/examples/systemd-user/dirmngr.service new file mode 100644 index 0000000..c79dfc5 --- /dev/null +++ b/doc/examples/systemd-user/dirmngr.service @@ -0,0 +1,10 @@ +[Unit] +Description=GnuPG network certificate management daemon +Documentation=man:dirmngr(8) +Requires=dirmngr.socket +After=dirmngr.socket +## This is a socket-activated service: +RefuseManualStart=true + +[Service] +ExecStart=/usr/bin/dirmngr --supervised diff --git a/doc/examples/systemd-user/dirmngr.socket b/doc/examples/systemd-user/dirmngr.socket new file mode 100644 index 0000000..ebabf89 --- /dev/null +++ b/doc/examples/systemd-user/dirmngr.socket @@ -0,0 +1,11 @@ +[Unit] +Description=GnuPG network certificate management daemon +Documentation=man:dirmngr(8) + +[Socket] +ListenStream=%t/gnupg/S.dirmngr +SocketMode=0600 +DirectoryMode=0700 + +[Install] +WantedBy=sockets.target diff --git a/doc/examples/systemd-user/gpg-agent-browser.socket b/doc/examples/systemd-user/gpg-agent-browser.socket new file mode 100644 index 0000000..bc8d344 --- /dev/null +++ b/doc/examples/systemd-user/gpg-agent-browser.socket @@ -0,0 +1,13 @@ +[Unit] +Description=GnuPG cryptographic agent and passphrase cache (access for web browsers) +Documentation=man:gpg-agent(1) + +[Socket] +ListenStream=%t/gnupg/S.gpg-agent.browser +FileDescriptorName=browser +Service=gpg-agent.service +SocketMode=0600 +DirectoryMode=0700 + +[Install] +WantedBy=sockets.target diff --git a/doc/examples/systemd-user/gpg-agent-extra.socket b/doc/examples/systemd-user/gpg-agent-extra.socket new file mode 100644 index 0000000..5b87d09 --- /dev/null +++ b/doc/examples/systemd-user/gpg-agent-extra.socket @@ -0,0 +1,13 @@ +[Unit] +Description=GnuPG cryptographic agent and passphrase cache (restricted) +Documentation=man:gpg-agent(1) + +[Socket] +ListenStream=%t/gnupg/S.gpg-agent.extra +FileDescriptorName=extra +Service=gpg-agent.service +SocketMode=0600 +DirectoryMode=0700 + +[Install] +WantedBy=sockets.target diff --git a/doc/examples/systemd-user/gpg-agent-ssh.socket b/doc/examples/systemd-user/gpg-agent-ssh.socket new file mode 100644 index 0000000..798c1d9 --- /dev/null +++ b/doc/examples/systemd-user/gpg-agent-ssh.socket @@ -0,0 +1,13 @@ +[Unit] +Description=GnuPG cryptographic agent (ssh-agent emulation) +Documentation=man:gpg-agent(1) man:ssh-add(1) man:ssh-agent(1) man:ssh(1) + +[Socket] +ListenStream=%t/gnupg/S.gpg-agent.ssh +FileDescriptorName=ssh +Service=gpg-agent.service +SocketMode=0600 +DirectoryMode=0700 + +[Install] +WantedBy=sockets.target diff --git a/doc/examples/systemd-user/gpg-agent.service b/doc/examples/systemd-user/gpg-agent.service new file mode 100644 index 0000000..9ab9220 --- /dev/null +++ b/doc/examples/systemd-user/gpg-agent.service @@ -0,0 +1,10 @@ +[Unit] +Description=GnuPG cryptographic agent and passphrase cache +Documentation=man:gpg-agent(1) +Requires=gpg-agent.socket +After=gpg-agent.socket +## This is a socket-activated service: +RefuseManualStart=true + +[Service] +ExecStart=/usr/bin/gpg-agent --supervised diff --git a/doc/examples/systemd-user/gpg-agent.socket b/doc/examples/systemd-user/gpg-agent.socket new file mode 100644 index 0000000..4257c2c --- /dev/null +++ b/doc/examples/systemd-user/gpg-agent.socket @@ -0,0 +1,12 @@ +[Unit] +Description=GnuPG cryptographic agent and passphrase cache +Documentation=man:gpg-agent(1) + +[Socket] +ListenStream=%t/gnupg/S.gpg-agent +FileDescriptorName=std +SocketMode=0600 +DirectoryMode=0700 + +[Install] +WantedBy=sockets.target -- 2.9.3 From wk at gnupg.org Thu Oct 27 21:03:28 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 27 Oct 2016 21:03:28 +0200 Subject: [PATCH] systemd: Include config for socket-activated user services. In-Reply-To: <20161027181918.920-1-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 27 Oct 2016 14:19:18 -0400") References: <20161027181918.920-1-dkg@fifthhorseman.net> Message-ID: <87lgx962db.fsf@wheatstone.g10code.de> Hi! I mentioned it some time ago that the systemd patches are okay as long as they are generic enough. GnuPG is not a Linux only software and thus endorsing a software by adding specific documentaion for it is not what I want. I see no problem for Debian to add these examples to their package - the extra work needed for Debian should be minimal. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From alon.barlev at gmail.com Thu Oct 27 21:14:27 2016 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Thu, 27 Oct 2016 22:14:27 +0300 Subject: [PATCH] gpg, gpgsm, python: atomic directory creation In-Reply-To: References: <87a8e0pvmh.fsf@wheatstone.g10code.de> <1476867847-24352-1-git-send-email-alon.barlev@gmail.com> Message-ID: Hi, Anything I can do to help push this[1] forward? Thanks! [1] https://lists.gnupg.org/pipermail/gnupg-devel/2016-October/031873.html On 24 October 2016 at 20:05, Alon Bar-Lev wrote: > > Hi, > Anything more I can do? > Thanks! > > On 19 October 2016 at 12:04, Alon Bar-Lev wrote: > > * lang/python/tests/Makefile.am, > > tests/gpg/Makefile.am, > > tests/gpgsm/Makefile.am: atomic directory creation. > > > > -- > > Solves race in parallel build when mkdir fails if directory exists. > > > > Signed-off-by: Alon Bar-Lev > > --- > > lang/python/tests/Makefile.am | 2 +- > > tests/gpg/Makefile.am | 2 +- > > tests/gpgsm/Makefile.am | 2 +- > > 3 files changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/lang/python/tests/Makefile.am b/lang/python/tests/Makefile.am > > index aa88bdc..39f532c 100644 > > --- a/lang/python/tests/Makefile.am > > +++ b/lang/python/tests/Makefile.am > > @@ -89,7 +89,7 @@ clean-local: > > > > > > ./private-keys-v1.d/gpg-sample.stamp: $(private_keys) > > - test -d ./private-keys-v1.d || mkdir ./private-keys-v1.d > > + $(MKDIR_P) ./private-keys-v1.d > > for k in $(private_keys); do \ > > cp $$k private-keys-v1.d/$${k#$(test_srcdir)/}.key; \ > > done > > diff --git a/tests/gpg/Makefile.am b/tests/gpg/Makefile.am > > index 2538f63..044bf3a 100644 > > --- a/tests/gpg/Makefile.am > > +++ b/tests/gpg/Makefile.am > > @@ -90,7 +90,7 @@ export GNUPGHOME := $(abs_builddir) > > export GPG_AGENT_INFO := > > > > ./private-keys-v1.d/gpg-sample.stamp: $(srcdir)/$(private_keys) > > - test -d ./private-keys-v1.d || mkdir ./private-keys-v1.d > > + $(MKDIR_P) ./private-keys-v1.d > > for k in $(private_keys); do \ > > cp $(srcdir)/$$k private-keys-v1.d/$$k.key; \ > > done > > diff --git a/tests/gpgsm/Makefile.am b/tests/gpgsm/Makefile.am > > index 41645b6..46d6a9b 100644 > > --- a/tests/gpgsm/Makefile.am > > +++ b/tests/gpgsm/Makefile.am > > @@ -70,7 +70,7 @@ export GPG_AGENT_INFO := > > echo faked-system-time 1008241200 >> ./gpgsm.conf > > > > ./private-keys-v1.d/$(key_id).key: $(srcdir)/$(key_id) > > - test -d ./private-keys-v1.d || mkdir ./private-keys-v1.d > > + $(MKDIR_P) ./private-keys-v1.d > > cp $(srcdir)/$(key_id) private-keys-v1.d/$(key_id).key > > > > ./trustlist.txt: > > -- > > 2.7.3 > > From dkg at fifthhorseman.net Fri Oct 28 00:30:57 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 27 Oct 2016 18:30:57 -0400 Subject: [PATCH 1/3] dirmngr: register hkp-cacert even if the file doesn't exist yet Message-ID: <20161027223059.31844-1-dkg@fifthhorseman.net> * dirmngr/dirmngr.c (parse_readable_options): if we're unable to turn an argument for hkp-cacert into an absolute filename, terminate completely. * dirmngr/http.c (http_register_tls_ca): show a warning if file is not immediately accessible, but register it anyway. -- Without this changeset, the condition of the filesystem when dirmngr is initialized will have an effect on later activities of dirmngr. For example, if a file identified by a hkp-cacert directive doesn't exist when dirmngr starts, dirmngr will behave as though it simply didn't have the hkp-cacert directive set at all, even if the file should appear later. dirmngr currently behaves differently if no hkp-cacert directives have been set then it does when at least one hkp-cacert directive has been set. For example, its choice of CA cert for hkps://hkps.pool.sks-keyservers.net depends on whether a TLS CA file has been registered. That behavior shouldn't additionally depend on the state of the filesystem at the time of dirmngr launch. Signed-off-by: Daniel Kahn Gillmor --- dirmngr/dirmngr.c | 12 +++--------- dirmngr/http.c | 5 +++++ 2 files changed, 8 insertions(+), 9 deletions(-) diff --git a/dirmngr/dirmngr.c b/dirmngr/dirmngr.c index 07cbed9..d15b9e5 100644 --- a/dirmngr/dirmngr.c +++ b/dirmngr/dirmngr.c @@ -601,15 +601,9 @@ parse_rereadable_options (ARGPARSE_ARGS *pargs, int reread) { char *tmpname; - /* Do tilde expansion and print a warning if the file can't be - accessed. */ - tmpname = make_absfilename_try (pargs->r.ret_str, NULL); - if (!tmpname || access (tmpname, F_OK)) - log_info (_("can't access '%s': %s\n"), - tmpname? tmpname : pargs->r.ret_str, - gpg_strerror (gpg_error_from_syserror())); - else - http_register_tls_ca (tmpname); + /* Do tilde expansion and make path absolute. */ + tmpname = make_absfilename (pargs->r.ret_str, NULL); + http_register_tls_ca (tmpname); xfree (tmpname); } break; diff --git a/dirmngr/http.c b/dirmngr/http.c index ac8238c..b767c15 100644 --- a/dirmngr/http.c +++ b/dirmngr/http.c @@ -492,6 +492,11 @@ http_register_tls_ca (const char *fname) } else { + /* Warn if we can't access right now, but register it anyway in + case it becomes accessible later */ + if (access (fname, F_OK)) + log_info (_("can't access '%s': %s\n"), fname, + gpg_strerror (gpg_error_from_syserror())); sl = add_to_strlist (&tls_ca_certlist, fname); if (*sl->d && !strcmp (sl->d + strlen (sl->d) - 4, ".pem")) sl->flags = 1; -- 2.9.3 From dkg at fifthhorseman.net Fri Oct 28 00:30:59 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 27 Oct 2016 18:30:59 -0400 Subject: [PATCH 3/3] dirmngr: use a default keyserver if none is explicitly set In-Reply-To: <20161027223059.31844-1-dkg@fifthhorseman.net> References: <20161027223059.31844-1-dkg@fifthhorseman.net> Message-ID: <20161027223059.31844-3-dkg@fifthhorseman.net> * configure.ac: define DIRMNGR_DEFAULT_KEYSERVER * dirmngr/server.c (ensure_keyserver): use it if no keyservers are set * doc/dirmngr.texi: document this behavior -- A user who doesn't specify a keyserver, but asks gnupg to fetch a key currently just gets a simple error messages "No keyserver available". If the user is asking to contact a keyserver, we should have a reasonable default, and not require them to fiddle with settings when they might not know what settings to choose. This patch makes the default hkps://hkps.pool.sks-keyservers.net. Signed-off-by: Daniel Kahn Gillmor --- configure.ac | 2 ++ dirmngr/server.c | 3 ++- doc/dirmngr.texi | 2 ++ 3 files changed, 6 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 91ef5c9..88ffa72 100644 --- a/configure.ac +++ b/configure.ac @@ -1754,6 +1754,8 @@ AC_DEFINE_UNQUOTED(SCDAEMON_SOCK_NAME, "S.scdaemon", [The name of the SCdaemon socket]) AC_DEFINE_UNQUOTED(DIRMNGR_SOCK_NAME, "S.dirmngr", [The name of the dirmngr socket]) +AC_DEFINE_UNQUOTED(DIRMNGR_DEFAULT_KEYSERVER, "hkps://hkps.pool.sks-keyservers.net", + [The default keyserver for dirmngr to use, if none is explicitly given]) AC_DEFINE_UNQUOTED(GPGEXT_GPG, "gpg", [The standard binary file suffix]) diff --git a/dirmngr/server.c b/dirmngr/server.c index e3fe1a4..c04c2d6 100644 --- a/dirmngr/server.c +++ b/dirmngr/server.c @@ -1812,7 +1812,8 @@ ensure_keyserver (ctrl_t ctrl) if (ctrl->server_local->keyservers) return 0; /* Already set for this session. */ if (!opt.keyserver) - return 0; /* No global option set. */ + /* No global option set. fall back to default: */ + return make_keyserver_item (DIRMNGR_DEFAULT_KEYSERVER, &ctrl->server_local->keyservers); for (sl = opt.keyserver; sl; sl = sl->next) { diff --git a/doc/dirmngr.texi b/doc/dirmngr.texi index 8a2e5ba..9e4e5fa 100644 --- a/doc/dirmngr.texi +++ b/doc/dirmngr.texi @@ -277,6 +277,8 @@ service (.onion), Dirmngr selects the keyserver to use depending on whether Tor is locally running or not. The check for a running Tor is done for each new connection. +If no keyserver is explicitly configured, dirmngr will use the +built-in default of hkps://hkps.pool.sks-keyservers.net. @item --nameserver @var{ipaddr} @opindex nameserver -- 2.9.3 From dkg at fifthhorseman.net Fri Oct 28 00:30:58 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 27 Oct 2016 18:30:58 -0400 Subject: [PATCH 2/3] dirmngr: add system CAs if no hkp-cacert is given In-Reply-To: <20161027223059.31844-1-dkg@fifthhorseman.net> References: <20161027223059.31844-1-dkg@fifthhorseman.net> Message-ID: <20161027223059.31844-2-dkg@fifthhorseman.net> * dirmngr/dirmngr.c (http_session_new): if the user isn't talking to the HKPS pool, and they have not specified any hkp-cacert, then we should default to the system CAs, rather than nothing. * doc/dirmngr.texi: document choice of CAs. -- Consider three possible classes of dirmngr configuration: a) no hkps:// keyserver URLs at all (communication with keyservers is entirely in the clear) b) hkps:// keyserver URLs, but no hkp-cacert directives c) hkps:// keyserver URLs, and at least one hkp-cacert directive class (a) provides no confidentiality of requests. class (b) currently will never work because the server certificate cannot be validated. class (c) is currently supported as intended. This patch allows users with configurations in class (b) to work as most users expect (relying on the system certificate authorities), without affecting users in classes (a) or (c). Signed-off-by: Daniel Kahn Gillmor --- dirmngr/http.c | 14 +++++++++----- doc/dirmngr.texi | 5 +++++ 2 files changed, 14 insertions(+), 5 deletions(-) diff --git a/dirmngr/http.c b/dirmngr/http.c index b767c15..18e3b72 100644 --- a/dirmngr/http.c +++ b/dirmngr/http.c @@ -591,6 +591,8 @@ http_session_new (http_session_t *r_session, const char *tls_priority, const char *errpos; int rc; strlist_t sl; + int add_system_cas = !!(flags & HTTP_FLAG_TRUST_SYS); + int is_hkps_pool; rc = gnutls_certificate_allocate_credentials (&sess->certcred); if (rc < 0) @@ -601,13 +603,13 @@ http_session_new (http_session_t *r_session, const char *tls_priority, goto leave; } + is_hkps_pool = intended_hostname && + !ascii_strcasecmp (intended_hostname, "hkps.pool.sks-keyservers.net"); + /* If the user has not specified a CA list, and they are looking * for the hkps pool from sks-keyservers.net, then default to * Kristian's certificate authority: */ - if (!tls_ca_certlist - && intended_hostname - && !ascii_strcasecmp (intended_hostname, - "hkps.pool.sks-keyservers.net")) + if (!tls_ca_certlist && is_hkps_pool) { char *pemname = make_filename_try (gnupg_datadir (), "sks-keyservers.netCA.pem", NULL); @@ -640,10 +642,12 @@ http_session_new (http_session_t *r_session, const char *tls_priority, log_info ("setting CA from file '%s' failed: %s\n", sl->d, gnutls_strerror (rc)); } + if (!tls_ca_certlist && !is_hkps_pool) + add_system_cas = 1; } /* Add system certificates to the session. */ - if ((flags & HTTP_FLAG_TRUST_SYS)) + if (add_system_cas) { #if GNUTLS_VERSION_NUMBER >= 0x030014 static int shown; diff --git a/doc/dirmngr.texi b/doc/dirmngr.texi index 6620a87..8a2e5ba 100644 --- a/doc/dirmngr.texi +++ b/doc/dirmngr.texi @@ -462,6 +462,11 @@ the file is in PEM format a suffix of @code{.pem} is expected for @var{file}. This option may be given multiple times to add more root certificates. Tilde expansion is supported. +If no @code{hkp-cacert} directive is present, dirmngr will make a +reasonable choice: if the keyserver in question is the special pool + at code{hkps.pool.sks-keyservers.net}, it will use the bundled root +certificate for that pool. Otherwise, it will use the system CAs. + @end table -- 2.9.3 From dkg at fifthhorseman.net Fri Oct 28 00:24:04 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 27 Oct 2016 18:24:04 -0400 Subject: [PATCH] systemd: Include config for socket-activated user services. In-Reply-To: <87lgx962db.fsf@wheatstone.g10code.de> References: <20161027181918.920-1-dkg@fifthhorseman.net> <87lgx962db.fsf@wheatstone.g10code.de> Message-ID: <877f8tctx7.fsf@alice.fifthhorseman.net> On Thu 2016-10-27 15:03:28 -0400, Werner Koch wrote: > I mentioned it some time ago that the systemd patches are okay as long > as they are generic enough. GnuPG is not a Linux only software and thus > endorsing a software by adding specific documentaion for it is not what > I want. fwiw, the README makes it clear that this folder is only for systems using systemd. If you want to make it even clearer that this is "contrib" documentation somehow, and that this is certainly not the only (or expected, or recommended) way to run this software, that's of course fine by me. If these example .service and .socket files aren't merged with the upstream git repo, all the downstreams that already use systemd and want to integrate gnupg into their systems will make up their own systemd service files. Some of them will be better than others, and there will be no canonical place for people to collect improvements that will then flow out to everyone else. That seems suboptimal to me, but it's certainly up to you if you want to do that. I note that you've already got specific custom files related to system integration and build processes for the windows platform. I assume that's appreciated by folks who are working with that platform, and upstream is a sensible location to collect this stuff. > I see no problem for Debian to add these examples to their package - the > extra work needed for Debian should be minimal. I'll certainly keep them in debian if they're not imported upstream. but i'd much rather see them upstream so that other OSes that already use systemd won't need to go to the trouble of inventing their own configs to have a well-integrated, session-bound set of agents. If you had a separate directory that included mechanism to cleanly integrate into other system managers, that would also be a reasonable collection of things to host in the upstream repo. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From kristian.fiskerstrand at sumptuouscapital.com Fri Oct 28 00:59:03 2016 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 28 Oct 2016 00:59:03 +0200 Subject: [PATCH 2/3] dirmngr: add system CAs if no hkp-cacert is given In-Reply-To: <20161027223059.31844-2-dkg@fifthhorseman.net> References: <20161027223059.31844-1-dkg@fifthhorseman.net> <20161027223059.31844-2-dkg@fifthhorseman.net> Message-ID: On 10/28/2016 12:30 AM, Daniel Kahn Gillmor wrote: > * dirmngr/dirmngr.c (http_session_new): if the user isn't talking to > the HKPS pool, and they have not specified any hkp-cacert, then we > should default to the system CAs, rather than nothing. > * doc/dirmngr.texi: document choice of CAs. I'm a bit ambiguous about this change. In Gentoo we currently have the use of a system CA behind a user-selectable use flag for hkps but even so the set of provided CAs is originating mostly from Mozilla. As seen with the latest WoSign / StartCom issues, mozilla is not overly concerned about third-party usage of the provided CA certificates, and have more complex restrictions in place for NSS (e.g specific notBeforeDate and OneCRL checking). As such I question the security of the root stores and actually like that it defaults to not using system CAs so users needs to make an informed decision. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Nil satis nisi optimum Nothing but the best is good enough -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Fri Oct 28 00:59:41 2016 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 28 Oct 2016 00:59:41 +0200 Subject: [PATCH 3/3] dirmngr: use a default keyserver if none is explicitly set In-Reply-To: <20161027223059.31844-3-dkg@fifthhorseman.net> References: <20161027223059.31844-1-dkg@fifthhorseman.net> <20161027223059.31844-3-dkg@fifthhorseman.net> Message-ID: <4297c2fc-5549-e1cd-530f-c53df30af5ec@sumptuouscapital.com> On 10/28/2016 12:30 AM, Daniel Kahn Gillmor wrote: > * configure.ac: define DIRMNGR_DEFAULT_KEYSERVER > * dirmngr/server.c (ensure_keyserver): use it if no keyservers are set > * doc/dirmngr.texi: document this behavior > > -- > > A user who doesn't specify a keyserver, but asks gnupg to fetch a key > currently just gets a simple error messages "No keyserver available". > > If the user is asking to contact a keyserver, we should have a > reasonable default, and not require them to fiddle with settings when > they might not know what settings to choose. This patch makes the > default hkps://hkps.pool.sks-keyservers.net. I'm fine with this, although I'm "slightly" biased -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Nil satis nisi optimum Nothing but the best is good enough -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Fri Oct 28 01:00:44 2016 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 28 Oct 2016 01:00:44 +0200 Subject: [PATCH 1/3] dirmngr: register hkp-cacert even if the file doesn't exist yet In-Reply-To: <20161027223059.31844-1-dkg@fifthhorseman.net> References: <20161027223059.31844-1-dkg@fifthhorseman.net> Message-ID: <4f187381-d016-047e-715a-9f5f90a6d1e3@sumptuouscapital.com> On 10/28/2016 12:30 AM, Daniel Kahn Gillmor wrote: > * dirmngr/dirmngr.c (parse_readable_options): if we're unable to turn > an argument for hkp-cacert into an absolute filename, terminate > completely. > * dirmngr/http.c (http_register_tls_ca): show a warning if file is not > immediately accessible, but register it anyway. > Conceptually looks good to me -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "Be a yardstick of quality. Some people aren't used to an environment where excellence is expected." (Steve Jobs) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From Juergen.Schaepker at giepa.de Fri Oct 28 10:58:59 2016 From: Juergen.Schaepker at giepa.de (=?Windows-1252?Q?J=FCrgen_Sch=E4pker?=) Date: Fri, 28 Oct 2016 10:58:59 +0200 Subject: Web Key Service server lookup Message-ID: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65A48@S2008SBS.intern.giepa.de> Hi, thanks for the answer, Werner. I?m still not sure what the functional advantage is for using binary instead of armored, though. An idea on setup simplicity: currently the request URL is composed as https://example.org/.well-known/openpgpkey/hu/XXXX This usually requires some form of redirection to the actual WKD server (when it?s not the same as the one running at example.org). To make life easier for admins (specifically in small business scenarios) I would like to suggest that if https://example.org/.well-known/openpgpkey/hu/XXXX returns a 404 or timeout error, another attempt should be made at a subdomain like https://keys.example.org/.well-known/openpgpkey/hu/XXXX (or https://wkd.example.org/.well-known/openpgpkey/hu/XXXX). I imagine this could ease setting up a WKD server significantly (e.g. when modifications to a main server are difficult because of bureaucracy etc). https://wiki.gnupg.org/EasyGpg2016/PubkeyDistributionConcept suggests a priority list for looking up keys ? are those lookup-attempts meant to work only in sequence or in parallel and what timeouts should be used? Best regards, JS -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Fri Oct 28 21:06:11 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 28 Oct 2016 15:06:11 -0400 Subject: [PATCH] Spelling: correct spelling of "passphrase" Message-ID: <20161028190611.17524-1-dkg@fifthhorseman.net> There were several different variant spellings of "passphrase". This should fix them all for all English text. I did notice that po/it.po contains multiple instances of "passhprase", which also looks suspect to me, but i do not know Italian, so i did not try to correct it. Signed-off-by: Daniel Kahn Gillmor --- NEWS | 2 +- agent/agent.h | 2 +- agent/gpg-agent.c | 4 ++-- doc/help.be.txt | 2 +- doc/help.ca.txt | 2 +- doc/help.cs.txt | 2 +- doc/help.da.txt | 2 +- doc/help.el.txt | 2 +- doc/help.eo.txt | 2 +- doc/help.et.txt | 2 +- doc/help.gl.txt | 2 +- doc/help.nb.txt | 2 +- doc/help.sv.txt | 2 +- doc/help.txt | 2 +- g10/ChangeLog-2011 | 4 ++-- po/ca.po | 2 +- po/cs.po | 2 +- po/de.po | 2 +- po/el.po | 2 +- po/eo.po | 2 +- po/es.po | 2 +- po/et.po | 2 +- po/fi.po | 2 +- po/gl.po | 2 +- po/hu.po | 2 +- po/id.po | 2 +- po/it.po | 2 +- po/pt.po | 2 +- po/ro.po | 2 +- po/sk.po | 2 +- po/zh_CN.po | 2 +- scd/app-nks.c | 2 +- tests/openpgp/ecc.scm | 2 +- 33 files changed, 35 insertions(+), 35 deletions(-) diff --git a/NEWS b/NEWS index 1a780f8..395eca9 100644 --- a/NEWS +++ b/NEWS @@ -343,7 +343,7 @@ Noteworthy changes in version 2.1.9 (2015-10-09) * agent: Fix ssh fingerprint computation for nistp384 and EdDSA. - * agent: Fix crash during passprase entry on some platforms. + * agent: Fix crash during passphrase entry on some platforms. * scd: Change timeout to fix problems with some 2.1 cards. diff --git a/agent/agent.h b/agent/agent.h index a3ec457..1d40386 100644 --- a/agent/agent.h +++ b/agent/agent.h @@ -122,7 +122,7 @@ struct /* If set, a passphrase history will be written and checked at each passphrase change. */ - int enable_passhrase_history; + int enable_passphrase_history; int running_detached; /* We are running detached from the tty. */ diff --git a/agent/gpg-agent.c b/agent/gpg-agent.c index 7294c69..67ef321 100644 --- a/agent/gpg-agent.c +++ b/agent/gpg-agent.c @@ -789,7 +789,7 @@ parse_rereadable_options (ARGPARSE_ARGS *pargs, int reread) opt.min_passphrase_nonalpha = MIN_PASSPHRASE_NONALPHA; opt.check_passphrase_pattern = NULL; opt.max_passphrase_days = MAX_PASSPHRASE_DAYS; - opt.enable_passhrase_history = 0; + opt.enable_passphrase_history = 0; opt.ignore_cache_for_signing = 0; opt.allow_mark_trusted = 1; opt.allow_external_cache = 1; @@ -856,7 +856,7 @@ parse_rereadable_options (ARGPARSE_ARGS *pargs, int reread) opt.max_passphrase_days = pargs->r.ret_ulong; break; case oEnablePassphraseHistory: - opt.enable_passhrase_history = 1; + opt.enable_passphrase_history = 1; break; case oIgnoreCacheForSigning: opt.ignore_cache_for_signing = 1; break; diff --git a/doc/help.be.txt b/doc/help.be.txt index 36c9ffb..f722b8c 100644 --- a/doc/help.be.txt +++ b/doc/help.be.txt @@ -228,7 +228,7 @@ self-signatures will be advanced by one second. .#gpg.passphrase.enter # fixme: Please translate and remove the hash mark from the key line. -Please enter the passhrase; this is a secret sentence +Please enter the passphrase; this is a secret sentence . diff --git a/doc/help.ca.txt b/doc/help.ca.txt index 36c9ffb..f722b8c 100644 --- a/doc/help.ca.txt +++ b/doc/help.ca.txt @@ -228,7 +228,7 @@ self-signatures will be advanced by one second. .#gpg.passphrase.enter # fixme: Please translate and remove the hash mark from the key line. -Please enter the passhrase; this is a secret sentence +Please enter the passphrase; this is a secret sentence . diff --git a/doc/help.cs.txt b/doc/help.cs.txt index 36c9ffb..f722b8c 100644 --- a/doc/help.cs.txt +++ b/doc/help.cs.txt @@ -228,7 +228,7 @@ self-signatures will be advanced by one second. .#gpg.passphrase.enter # fixme: Please translate and remove the hash mark from the key line. -Please enter the passhrase; this is a secret sentence +Please enter the passphrase; this is a secret sentence . diff --git a/doc/help.da.txt b/doc/help.da.txt index 36c9ffb..f722b8c 100644 --- a/doc/help.da.txt +++ b/doc/help.da.txt @@ -228,7 +228,7 @@ self-signatures will be advanced by one second. .#gpg.passphrase.enter # fixme: Please translate and remove the hash mark from the key line. -Please enter the passhrase; this is a secret sentence +Please enter the passphrase; this is a secret sentence . diff --git a/doc/help.el.txt b/doc/help.el.txt index 36c9ffb..f722b8c 100644 --- a/doc/help.el.txt +++ b/doc/help.el.txt @@ -228,7 +228,7 @@ self-signatures will be advanced by one second. .#gpg.passphrase.enter # fixme: Please translate and remove the hash mark from the key line. -Please enter the passhrase; this is a secret sentence +Please enter the passphrase; this is a secret sentence . diff --git a/doc/help.eo.txt b/doc/help.eo.txt index 36c9ffb..f722b8c 100644 --- a/doc/help.eo.txt +++ b/doc/help.eo.txt @@ -228,7 +228,7 @@ self-signatures will be advanced by one second. .#gpg.passphrase.enter # fixme: Please translate and remove the hash mark from the key line. -Please enter the passhrase; this is a secret sentence +Please enter the passphrase; this is a secret sentence . diff --git a/doc/help.et.txt b/doc/help.et.txt index 36c9ffb..f722b8c 100644 --- a/doc/help.et.txt +++ b/doc/help.et.txt @@ -228,7 +228,7 @@ self-signatures will be advanced by one second. .#gpg.passphrase.enter # fixme: Please translate and remove the hash mark from the key line. -Please enter the passhrase; this is a secret sentence +Please enter the passphrase; this is a secret sentence . diff --git a/doc/help.gl.txt b/doc/help.gl.txt index 36c9ffb..f722b8c 100644 --- a/doc/help.gl.txt +++ b/doc/help.gl.txt @@ -228,7 +228,7 @@ self-signatures will be advanced by one second. .#gpg.passphrase.enter # fixme: Please translate and remove the hash mark from the key line. -Please enter the passhrase; this is a secret sentence +Please enter the passphrase; this is a secret sentence . diff --git a/doc/help.nb.txt b/doc/help.nb.txt index 36c9ffb..f722b8c 100644 --- a/doc/help.nb.txt +++ b/doc/help.nb.txt @@ -228,7 +228,7 @@ self-signatures will be advanced by one second. .#gpg.passphrase.enter # fixme: Please translate and remove the hash mark from the key line. -Please enter the passhrase; this is a secret sentence +Please enter the passphrase; this is a secret sentence . diff --git a/doc/help.sv.txt b/doc/help.sv.txt index 36c9ffb..f722b8c 100644 --- a/doc/help.sv.txt +++ b/doc/help.sv.txt @@ -228,7 +228,7 @@ self-signatures will be advanced by one second. .#gpg.passphrase.enter # fixme: Please translate and remove the hash mark from the key line. -Please enter the passhrase; this is a secret sentence +Please enter the passphrase; this is a secret sentence . diff --git a/doc/help.txt b/doc/help.txt index 4c6df7c..e64656e 100644 --- a/doc/help.txt +++ b/doc/help.txt @@ -312,7 +312,7 @@ self-signatures will be advanced by one second. .gpg.passphrase.enter # (keep a leading empty line) -Please enter the passhrase; this is a secret sentence. +Please enter the passphrase; this is a secret sentence. . diff --git a/g10/ChangeLog-2011 b/g10/ChangeLog-2011 index 31359d8..37da37b 100644 --- a/g10/ChangeLog-2011 +++ b/g10/ChangeLog-2011 @@ -8210,7 +8210,7 @@ to all foo-fd options. * gpgv.c, openfile.c, ringedit.c, tdbio.c: Minor fixes. Mainly replaced hardcoded path separators with EXTSEP_S like macros. - * passprase.c [__riscos__]: Disabled agent stuff + * passphrase.c [__riscos__]: Disabled agent stuff * trustdb.c (check_trust): Changed r_trustlevel to signed int to avoid mismatch problems in pkclist.c * pkclist.c (add_ownertrust): Ditto. @@ -11583,7 +11583,7 @@ Mon May 4 09:35:53 1998 Werner Koch (wk at isil.d.shuttle.de) changed all callers. * passphrase.c (make_dek_from_passphrase): Removed - * (get_passhrase_hash): Changed name to passphrase_to_dek, add arg, + * (get_passphrase_hash): Changed name to passphrase_to_dek, add arg, changed all callers. * all: Introduced the new ELG identifier and added support for the diff --git a/po/ca.po b/po/ca.po index 51f5650..9afadcc 100644 --- a/po/ca.po +++ b/po/ca.po @@ -9798,7 +9798,7 @@ msgstr "" #~ "a la llista actual de prefer?ncies. Les marques de temps de totes les\n" #~ "autosignatures afectades s'avan?aran un segon.\n" -#~ msgid "Please enter the passhrase; this is a secret sentence \n" +#~ msgid "Please enter the passphrase; this is a secret sentence \n" #~ msgstr "Introdu?u la contrasenya; aquesta ha de ser una frase secreta \n" #~ msgid "" diff --git a/po/cs.po b/po/cs.po index d185c57..1ebade0 100644 --- a/po/cs.po +++ b/po/cs.po @@ -9669,7 +9669,7 @@ msgstr "" #~ "na aktu?ln? seznam p?edvoleb. ?asov? raz?tka v?ech dot?en?ch podpis?\n" #~ "kl??? jimi samotn?mi budou posunuty o jednu vte?inu dop?edu.\n" -#~ msgid "Please enter the passhrase; this is a secret sentence \n" +#~ msgid "Please enter the passphrase; this is a secret sentence \n" #~ msgstr "Pros?m, vlo?te heslo; toto je tajn? v?ta \n" #~ msgid "" diff --git a/po/de.po b/po/de.po index 71e5700..cf01be3 100644 --- a/po/de.po +++ b/po/de.po @@ -9616,7 +9616,7 @@ msgstr "" #~ "betroffenen\n" #~ "Eigenbeglaubigungen werden um eine Sekunde vorgestellt.\n" -#~ msgid "Please enter the passhrase; this is a secret sentence \n" +#~ msgid "Please enter the passphrase; this is a secret sentence \n" #~ msgstr "Bitte geben Sie die Passphrase ein. Dies ist ein geheimer Satz \n" #~ msgid "" diff --git a/po/el.po b/po/el.po index 77c81a8..5527de9 100644 --- a/po/el.po +++ b/po/el.po @@ -9605,7 +9605,7 @@ msgstr "" #~ "???? ???????????? ????? ???????????. ? ?????????? ???? ??? ????????????\n" #~ "????-????????? ?? ??????? ???? 1 ????????????.\n" -#~ msgid "Please enter the passhrase; this is a secret sentence \n" +#~ msgid "Please enter the passphrase; this is a secret sentence \n" #~ msgstr "?????????????? ?? ????? ??????? ???? ????? ??? ??????? ??????? \n" #~ msgid "" diff --git a/po/eo.po b/po/eo.po index 63f3882..87331ff 100644 --- a/po/eo.po +++ b/po/eo.po @@ -9488,7 +9488,7 @@ msgstr "" #~ "al la aktuala listo de preferoj. La dato de ?iuj trafitaj\n" #~ "mem-subskriboj estos anta?enigitaj je unu sekundo.\n" -#~ msgid "Please enter the passhrase; this is a secret sentence \n" +#~ msgid "Please enter the passphrase; this is a secret sentence \n" #~ msgstr "Bonvolu doni la pasfrazon; tio estas sekreta frazo \n" #~ msgid "" diff --git a/po/es.po b/po/es.po index 76fae21..f12f9c0 100644 --- a/po/es.po +++ b/po/es.po @@ -9955,7 +9955,7 @@ msgstr "" #~ "seleccionados) a la lista actual de preferencias. El sello de tiempo\n" #~ "de todas las autofirmas afectadas se avanzar? en un segundo.\n" -#~ msgid "Please enter the passhrase; this is a secret sentence \n" +#~ msgid "Please enter the passphrase; this is a secret sentence \n" #~ msgstr "Por favor introduzca la contrase?a: una frase secreta \n" #~ msgid "" diff --git a/po/et.po b/po/et.po index 74426d8..75ded06 100644 --- a/po/et.po +++ b/po/et.po @@ -9492,7 +9492,7 @@ msgstr "" #~ "vastavaks hetkel m??ratud seadetele. K?ikide asjasse puutuvate\n" #~ "ise loodud allkirjade ajatempleid suurendatakse ?he sekundi v?rra.\n" -#~ msgid "Please enter the passhrase; this is a secret sentence \n" +#~ msgid "Please enter the passphrase; this is a secret sentence \n" #~ msgstr "Palun sisestage parool; see on salajane tekst \n" #~ msgid "" diff --git a/po/fi.po b/po/fi.po index 5002410..5063207 100644 --- a/po/fi.po +++ b/po/fi.po @@ -9584,7 +9584,7 @@ msgstr "" #~ "nykyiseen luetteloon valinnoista. Kaikkien muutettujen\n" #~ "oma-allekirjoitusten aikaleima siirret??n yhdell? sekunnilla eteenp?in.\n" -#~ msgid "Please enter the passhrase; this is a secret sentence \n" +#~ msgid "Please enter the passphrase; this is a secret sentence \n" #~ msgstr "Ole hyv? ja sy?t? salasana, t?m?n on salainen lause \n" #~ msgid "" diff --git a/po/gl.po b/po/gl.po index 833533d..f02986f 100644 --- a/po/gl.po +++ b/po/gl.po @@ -9605,7 +9605,7 @@ msgstr "" #~ "sinaturas\n" #~ "afectadas ha avanzar un segundo.\n" -#~ msgid "Please enter the passhrase; this is a secret sentence \n" +#~ msgid "Please enter the passphrase; this is a secret sentence \n" #~ msgstr "Por favor, introduza o contrasinal; esta ? unha frase secreta \n" #~ msgid "" diff --git a/po/hu.po b/po/hu.po index bcfe704..b068e69 100644 --- a/po/hu.po +++ b/po/hu.po @@ -9548,7 +9548,7 @@ msgstr "" #~ "tartoz? preferenci?kat az aktu?lis preferenci?kra. Minden ?rintett\n" #~ "?nal??r?s id?pontj?t egy m?sodperccel n?veli.\n" -#~ msgid "Please enter the passhrase; this is a secret sentence \n" +#~ msgid "Please enter the passphrase; this is a secret sentence \n" #~ msgstr "K?rem, adja meg a jelsz?t! Ezt egy titkos mondat. \n" #~ msgid "" diff --git a/po/id.po b/po/id.po index 015e419..5ee96c7 100644 --- a/po/id.po +++ b/po/id.po @@ -9540,7 +9540,7 @@ msgstr "" #~ "ke daftar preferensi saat ini. Timestamp seluruh self-signature\n" #~ "yang terpengaruh akan bertambah satu detik.\n" -#~ msgid "Please enter the passhrase; this is a secret sentence \n" +#~ msgid "Please enter the passphrase; this is a secret sentence \n" #~ msgstr "Silakan masukkan passphrase; ini kalimat rahasia\n" #~ msgid "" diff --git a/po/it.po b/po/it.po index dfc4f45..c109126 100644 --- a/po/it.po +++ b/po/it.po @@ -9599,7 +9599,7 @@ msgstr "" #~ "coinvolte\n" #~ "sar? aumentato di un secondo.\n" -#~ msgid "Please enter the passhrase; this is a secret sentence \n" +#~ msgid "Please enter the passphrase; this is a secret sentence \n" #~ msgstr "Inserisci la passphrase, cio? una frase segreta \n" #~ msgid "" diff --git a/po/pt.po b/po/pt.po index 1593ff0..40d65f7 100644 --- a/po/pt.po +++ b/po/pt.po @@ -9532,7 +9532,7 @@ msgstr "" #~ "O 'timestamp' de todas as auto-assinaturas afectuadas ser? avan?ado\n" #~ "em um segundo.\n" -#~ msgid "Please enter the passhrase; this is a secret sentence \n" +#~ msgid "Please enter the passphrase; this is a secret sentence \n" #~ msgstr "Por favor digite a frase secreta \n" #~ msgid "" diff --git a/po/ro.po b/po/ro.po index 460223c..12fd6f6 100644 --- a/po/ro.po +++ b/po/ro.po @@ -9639,7 +9639,7 @@ msgstr "" #~ "cele selectate) conform cu lista curent? de preferin?e. Timestamp-urile\n" #~ "tuturor auto-semn?turilor afectate vor fi avansate cu o secund?.\n" -#~ msgid "Please enter the passhrase; this is a secret sentence \n" +#~ msgid "Please enter the passphrase; this is a secret sentence \n" #~ msgstr "" #~ "V? rug?m introduce?i fraza-parol?; aceasta este o propozi?ie secret? \n" diff --git a/po/sk.po b/po/sk.po index 801cfe8..62b220e 100644 --- a/po/sk.po +++ b/po/sk.po @@ -9564,7 +9564,7 @@ msgstr "" #~ "podpisov\n" #~ "k???ov nimi samotn?mi bud? posunut? o jednu sekundu dopredu.\n" -#~ msgid "Please enter the passhrase; this is a secret sentence \n" +#~ msgid "Please enter the passphrase; this is a secret sentence \n" #~ msgstr "Pros?m, vlo?te heslo; toto je tajn? veta \n" #~ msgid "" diff --git a/po/zh_CN.po b/po/zh_CN.po index 5e16c8a..f153d7e 100644 --- a/po/zh_CN.po +++ b/po/zh_CN.po @@ -9408,7 +9408,7 @@ msgstr "" #~ "???????????(????)??????????????????\n" #~ "?????????????\n" -#~ msgid "Please enter the passhrase; this is a secret sentence \n" +#~ msgid "Please enter the passphrase; this is a secret sentence \n" #~ msgstr "??????????????? \n" #~ msgid "" diff --git a/scd/app-nks.c b/scd/app-nks.c index d0b96a9..458516b 100644 --- a/scd/app-nks.c +++ b/scd/app-nks.c @@ -1068,7 +1068,7 @@ do_decipher (app_t app, const char *keyidstr, /* Parse a password ID string. Returns NULL on error or a string - suitable as passpahrse prompt on success. On success stores the + suitable as passphrase prompt on success. On success stores the reference value for the password at R_PWID and a flag indicating that the SigG application is to be used at R_SIGG. If NEW_MODE is true, the returned description is suitable for a new Password. diff --git a/tests/openpgp/ecc.scm b/tests/openpgp/ecc.scm index f2f3b7c..8f38494 100755 --- a/tests/openpgp/ecc.scm +++ b/tests/openpgp/ecc.scm @@ -187,7 +187,7 @@ Rg== ;; ;; Now check that we can encrypt and decrypt our own messages. ;; -;; Note that we don't need to provide a passppharse because we already +;; Note that we don't need to provide a passphrase because we already ;; preset the passphrase into the gpg-agent. ;; (for-each-p -- 2.9.3 From dkg at fifthhorseman.net Fri Oct 28 22:22:27 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 28 Oct 2016 16:22:27 -0400 Subject: begging for pyme name change In-Reply-To: <87d1imekqo.fsf@alice.fifthhorseman.net> References: <87insx8404.fsf@servo.finestructure.net> <87bmyoy5a9.fsf@europa.jade-hamburg.de> <877f9c88t7.fsf@servo.finestructure.net> <87k2dbucl4.fsf@alice.fifthhorseman.net> <87d1imekqo.fsf@alice.fifthhorseman.net> Message-ID: <87wpgs9qbg.fsf@alice.fifthhorseman.net> On Wed 2016-10-26 19:47:11 -0400, Daniel Kahn Gillmor wrote: > If not, I'm starting to think that python-gpgme2 (along with deprecation > of all the other bindings) would be the simplest approach toward > cleaning up the python ecosystem here. I just looked at https://pypi.python.org/pypi/ (warning! takes a while to load!) and pulled out all the packages that had either gpg or gnupg (matched case-insensitively) in their name or their description. I'd really like to resolve this; if we're considering renaming the upstream-supported python module, we should do so as soon as possible. Then we can set about trying to clean up the rest of the ecosystem. I noticed there is no pypi module just named "gpg". "pygpg" does produce a module that can be loaded with "import gpg", but is only a few hundred lines of code, and has received no updates for over 3 years. Both PyPi and https://github.com/faust/pygpg claim that it belongs on https://www.abnorm.org/projects/pygpg/, but abnorm.org appears to have no DNS records, and i suspect the author's e-mail address (which i'm cc'ing here) will bounce. In addition to this, pygpg appears to be littered with shell-escape arbitrary code execution due to its liberal use of Popen: https://github.com/faust/pygpg/blob/master/gpg/__init__.py Anyone using pygpg to deal with remotely untrusted input probably has serious problems :/ So it seems likely that, as GnuPG upstream, we could simply claim the "gpg" name on PyPi, and that we could just take over the "gpg" module name as well. If we did that, we could then go through the remaining python modules related to the GnuPG suite and ask them to deprecate or unpublish any that don't directly use the "gpg" module. (i don't know how deprecation or unpublishing works on PyPI, but i guess we could try to figure it out. What do folks think of claiming the name "gpg" in the python module namespace (and in the PyPI source namespace) as a way forward? I can provide a patch if people think that's the right thing to do. --dkg PS Here's the list of relevant packages i found: ----------------- 2factorcli 1.1.3 This is a simple python program to allow you to store and generate time-based one-time passwords in a GPG encrypted vault. blockstack-gpg 0.0.13.0 GPG integration for Blockstack client applications cryptic 0.0.1 Encrypted messaging using GnuPG crypto 1.4.1 Simple symmetric GPG file encryption and decryption django-gnupg-mails 0.1 A Django reusable app providing the ability to send PGP/MIME signed multipart emails. easygpg 0.0.0 EncryptedGmailBackup 0.0.4 Backup your GMail account with GPG encryption. ezgpg 0.2.2 Simplified GPG UI gnupg 2.0.2 A Python wrapper for GnuPG GnuPGInterface 0.3.2 GnuPG interactions with file handles gnupg-securedrop 1.2.5-9-g6f9d63a-dirty A Python wrapper for GnuPG gpgdir 0.1 encrypts the contents of a dir with gpg gpg-inline 0.1 gpgkeys 1.23 A GnuPG Shell gpglib 0.1.1 Library for decrypting gpg that doesn't shell out to gpg gpgmailencrypt 3.1.0 an e-mail encryption, virus- and spam- checking module, gateway and daemon gpgmime 0.1 gpgpass 0.1.3 Password manager for groups. Searching thru GPG-encrypted password files. keybone 0.3.2 Create/Manage/List GPG Keys and Encrypt/Decrypt things with them keybox-keys 0.1 Storage for passwords, encrypted with GPG Krypton 0.1.2 GPG/PGP Keyserver with many enhancements mikla 0.2.1 A command line tool to edit text files encrypted with GnuPG whilst preventing the plaintext from being written to the hard drive. pearpass 1.0.2 Scripts for managing secrets with Octopus and GnuPG. pw 0.9.0 Search in GPG-encrypted password file. pygpg 1.1 GnuPG python wrapper. pygpgme 0.3 A Python module for working with OpenPGP messages pyme 0.9.0 Python support for GPGME GnuPG cryptography library pyme3 1.7.1 Python bindings for GPGME GnuPG cryptography library python-gnupg 0.3.9 A wrapper for the Gnu Privacy Guard (GPG or GnuPG) regnupg 0.3.5 A wrapper for the Gnu Privacy Guard (GPG or GnuPG) reikna 0.6.7 GPGPU algorithms for PyCUDA and PyOpenCL secret-notes 0.1 store your secrets using GPG! ----------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From dkg at fifthhorseman.net Fri Oct 28 23:08:07 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 28 Oct 2016 17:08:07 -0400 Subject: begging for pyme name change In-Reply-To: <87wpgs9qbg.fsf@alice.fifthhorseman.net> References: <87insx8404.fsf@servo.finestructure.net> <87bmyoy5a9.fsf@europa.jade-hamburg.de> <877f9c88t7.fsf@servo.finestructure.net> <87k2dbucl4.fsf@alice.fifthhorseman.net> <87d1imekqo.fsf@alice.fifthhorseman.net> <87wpgs9qbg.fsf@alice.fifthhorseman.net> Message-ID: <87twbw9o7c.fsf@alice.fifthhorseman.net> On Fri 2016-10-28 16:22:27 -0400, Daniel Kahn Gillmor wrote: > What do folks think of claiming the name "gpg" in the python module > namespace (and in the PyPI source namespace) as a way forward? I can > provide a patch if people think that's the right thing to do. fwiw, the patch is available on the pyme-to-python-gpg branch of my gitlab repo: https://gitlab.com/dkg/gpgme In particular, this is the relevant commit: https://gitlab.com/dkg/gpgme/commit/efebaeb91c667940aa39c77dab75864a7ec8a9ae If you're interested, you can do the following from your gpgme local copy: git remote add dkg https://gitlab.com/dkg/gpgme git checkout pyme-to-python-gpg The tests all pass, and the module appears to be sensibly named. If any gpgme developers think this is worth doing, please go ahead and claim the "gpg" name on pypi, and you're welcome to merge my patch. If you think this is not a good idea, i'd be happy to hear why as well. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From wk at gnupg.org Sat Oct 29 18:05:24 2016 From: wk at gnupg.org (Werner Koch) Date: Sat, 29 Oct 2016 18:05:24 +0200 Subject: begging for pyme name change In-Reply-To: <87twbw9o7c.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 28 Oct 2016 17:08:07 -0400") References: <87insx8404.fsf@servo.finestructure.net> <87bmyoy5a9.fsf@europa.jade-hamburg.de> <877f9c88t7.fsf@servo.finestructure.net> <87k2dbucl4.fsf@alice.fifthhorseman.net> <87d1imekqo.fsf@alice.fifthhorseman.net> <87wpgs9qbg.fsf@alice.fifthhorseman.net> <87twbw9o7c.fsf@alice.fifthhorseman.net> Message-ID: <877f8r3zuj.fsf@wheatstone.g10code.de> On Fri, 28 Oct 2016 23:08, dkg at fifthhorseman.net said: > If any gpgme developers think this is worth doing, please go ahead and > claim the "gpg" name on pypi, and you're welcome to merge my patch. I think this is a good idea. Justus, what do you think? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From justus at g10code.com Mon Oct 31 13:12:16 2016 From: justus at g10code.com (Justus Winter) Date: Mon, 31 Oct 2016 13:12:16 +0100 Subject: [PATCH GnuPG] RFC: g10: Improve and unify key selection. Message-ID: <20161031121216.17122-1-justus@g10code.com> * g10/getkey.c (get_best_pubkey_byname): New function. * g10/keydb.h (get_best_pubkey_byname): New prototype. * g10/keylist.c (locate_one): Use the new function. * g10/pkclist.c (find_and_check_key): Likewise. -- When a name resembling a mail address is given to either --locate-key or --recipient, rank the search results and use only the most relevant key. This also lets us query which key will be used for encryption using --locate-key. XXX: Is this true? B/c if we use --recipient, we only consider keys usable for encryption. Otoh, --locate-key has no such constraint. GnuPG-bug-id: 2359 Signed-off-by: Justus Winter --- g10/getkey.c | 109 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ g10/keydb.h | 7 ++++ g10/keylist.c | 2 +- g10/pkclist.c | 2 +- 4 files changed, 118 insertions(+), 2 deletions(-) diff --git a/g10/getkey.c b/g10/getkey.c index 5ef5fc3..53b9156 100644 --- a/g10/getkey.c +++ b/g10/getkey.c @@ -1462,6 +1462,115 @@ get_pubkey_byname (ctrl_t ctrl, GETKEY_CTX * retctx, PKT_public_key * pk, } +/* This function works like get_pubkey_byname, but if the name + resembles a mail address, the results are ranked and only the best + result is returned. */ +int +get_best_pubkey_byname (ctrl_t ctrl, GETKEY_CTX *retctx, PKT_public_key *pk, + const char *name, KBNODE *ret_keyblock, + int include_unusable, int no_akl) +{ + int rc; + struct getkey_ctx_s *ctx = NULL; + + rc = get_pubkey_byname (ctrl, &ctx, pk, name, ret_keyblock, + NULL, include_unusable, no_akl); + if (rc) + { + if (ctx) + getkey_end (ctx); + if (retctx) + *retctx = NULL; + return rc; + } + + if (is_valid_mailbox (name)) + { + /* Rank results and return only the most relevant key. */ + unsigned int best_validity = TRUST_UNKNOWN; + PKT_public_key k, best = { 0 }; + while (getkey_next (ctx, &k, NULL) == 0) + { + unsigned int validity; + validity = get_validity (ctrl, &k, NULL, NULL, 0); + + if (validity & (TRUST_FLAG_REVOKED + | TRUST_FLAG_SUB_REVOKED + | TRUST_FLAG_DISABLED) + || (validity & TRUST_MASK) == TRUST_EXPIRED) + continue; + + if (validity > best_validity + || (validity == best_validity + && k.timestamp > best.timestamp)) + { + release_public_key_parts (&best); + best = k; + best_validity = validity; + } + else + release_public_key_parts (&k); + } + getkey_end (ctx); + ctx = NULL; + + if (best.flags.valid) + { + if (retctx || ret_keyblock) + { + ctx = xtrycalloc (1, sizeof **retctx); + if (! ctx) + rc = gpg_error_from_syserror (); + else + { + ctx->kr_handle = keydb_new (); + if (! ctx->kr_handle) + { + xfree (ctx); + *retctx = NULL; + rc = gpg_error_from_syserror (); + } + else + { + u32 *keyid = pk_keyid (&best); + ctx->exact = 1; + ctx->nitems = 1; + ctx->items[0].mode = KEYDB_SEARCH_MODE_LONG_KID; + ctx->items[0].u.kid[0] = keyid[0]; + ctx->items[0].u.kid[1] = keyid[1]; + + if (ret_keyblock) + { + release_kbnode (*ret_keyblock); + *ret_keyblock = NULL; + rc = getkey_next (ctx, NULL, ret_keyblock); + } + } + } + } + + if (pk) + *pk = best; + else + release_public_key_parts (&best); + } + } + + if (rc && ctx) + { + getkey_end (ctx); + ctx = NULL; + } + + if (retctx && ctx) + *retctx = ctx; + else + getkey_end (ctx); + + return rc; +} + + /* Get a public key from a file. * * PK is the buffer to store the key. The caller needs to make sure diff --git a/g10/keydb.h b/g10/keydb.h index 35512bb..11cc695 100644 --- a/g10/keydb.h +++ b/g10/keydb.h @@ -324,6 +324,13 @@ int get_pubkey_byname (ctrl_t ctrl, KBNODE *ret_keyblock, KEYDB_HANDLE *ret_kdbhd, int include_unusable, int no_akl ); +/* Likewise, but only return the best match if NAME resembles a mail + address. */ +int get_best_pubkey_byname (ctrl_t ctrl, + GETKEY_CTX *retctx, PKT_public_key *pk, + const char *name, KBNODE *ret_keyblock, + int include_unusable, int no_akl); + /* Get a public key directly from file FNAME. */ gpg_error_t get_pubkey_fromfile (ctrl_t ctrl, PKT_public_key *pk, const char *fname); diff --git a/g10/keylist.c b/g10/keylist.c index 212d77e..51dc409 100644 --- a/g10/keylist.c +++ b/g10/keylist.c @@ -650,7 +650,7 @@ locate_one (ctrl_t ctrl, strlist_t names) for (sl = names; sl; sl = sl->next) { - rc = get_pubkey_byname (ctrl, &ctx, NULL, sl->d, &keyblock, NULL, 1, 0); + rc = get_best_pubkey_byname (ctrl, &ctx, NULL, sl->d, &keyblock, 1, 0); if (rc) { if (gpg_err_code (rc) != GPG_ERR_NO_PUBKEY) diff --git a/g10/pkclist.c b/g10/pkclist.c index da4cc06..eef3437 100644 --- a/g10/pkclist.c +++ b/g10/pkclist.c @@ -838,7 +838,7 @@ find_and_check_key (ctrl_t ctrl, const char *name, unsigned int use, if (from_file) rc = get_pubkey_fromfile (ctrl, pk, name); else - rc = get_pubkey_byname (ctrl, NULL, pk, name, NULL, NULL, 0, 0); + rc = get_best_pubkey_byname (ctrl, NULL, pk, name, NULL, 0, 0); if (rc) { int code; -- 2.10.1 From dkg at fifthhorseman.net Mon Oct 31 15:30:47 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 31 Oct 2016 10:30:47 -0400 Subject: [PATCH 2/3] dirmngr: add system CAs if no hkp-cacert is given In-Reply-To: References: <20161027223059.31844-1-dkg@fifthhorseman.net> <20161027223059.31844-2-dkg@fifthhorseman.net> Message-ID: <878tt4a8vc.fsf@alice.fifthhorseman.net> On Thu 2016-10-27 18:59:03 -0400, Kristian Fiskerstrand wrote: > On 10/28/2016 12:30 AM, Daniel Kahn Gillmor wrote: >> * dirmngr/dirmngr.c (http_session_new): if the user isn't talking to >> the HKPS pool, and they have not specified any hkp-cacert, then we >> should default to the system CAs, rather than nothing. >> * doc/dirmngr.texi: document choice of CAs. > > I'm a bit ambiguous about this change. In Gentoo we currently have the > use of a system CA behind a user-selectable use flag for hkps but even > so the set of provided CAs is originating mostly from Mozilla. > > As seen with the latest WoSign / StartCom issues, mozilla is not overly > concerned about third-party usage of the provided CA certificates, and > have more complex restrictions in place for NSS (e.g specific > notBeforeDate and OneCRL checking). > > As such I question the security of the root stores and actually like > that it defaults to not using system CAs so users needs to make an > informed decision. We're talking about case (b) from the commit message, right? that doesn't work for anyone right now. In practice, most users start in case (a), with no transport confidentiality or integrity at all. Those who manage to make it to case (c) today are in two cases: 0) someone who has one particular server that they want to connect to, and they have been fed their configuration by the administrator of that server, or 1) someone who wants to use a particular server, and they have fished around enough to figure out "where does my operating system store the standard certificate bundle". Some proportion of those who wish they were in in group (1) never figure out the answer to that question, and they fall back to cleartext, non-integrity-protected traffic. The folks in group (1) (and those who never made it to group (1) are really better-served by us using the system trust by default, rather than forcing them to do so manually. The change proposed doesn't affect those in group (0) at all. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From aheinecke at intevation.de Mon Oct 31 15:51:29 2016 From: aheinecke at intevation.de (Andre Heinecke) Date: Mon, 31 Oct 2016 15:51:29 +0100 Subject: [PATCH GnuPG] RFC: g10: Improve and unify key selection. In-Reply-To: <20161031121216.17122-1-justus@g10code.com> References: <20161031121216.17122-1-justus@g10code.com> Message-ID: <92373543.ha0chvWdI8@esus> Hi, On Monday 31 October 2016 13:12:16 Justus Winter wrote: > When a name resembling a mail address is given to either --locate-key > or --recipient, rank the search results and use only the most relevant > key. I would prefer it if this function would also return expired / revoked / validitity never etc. Keys. So in a GUI we could handle this case by informing the user that the key for this user is expired. Otherwise we would have to check for that case with another keylisting to avoid the problem that a user was able to encrypt to someone yesterday automatically and today it no longer works and the UI just shows "No key for this recipient" when a UI uses locate-keys. > This also lets us query which key will be used for encryption using > --locate-key. XXX: Is this true? B/c if we use --recipient, we only > consider keys usable for encryption. Otoh, --locate-key has no such > constraint. I think this could be solved by ranking a key that can both encrypt higher then a key that can't encrypt. This would avoid the state where an encrypt key can can't be found because a user has a different primary key with only signing (for whatever weird reason). The primary usecase of this function imo is to look up recipient keys for encryption. 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: 630 bytes Desc: This is a digitally signed message part. URL: From justus at g10code.com Mon Oct 31 15:54:47 2016 From: justus at g10code.com (Justus Winter) Date: Mon, 31 Oct 2016 15:54:47 +0100 Subject: begging for pyme name change In-Reply-To: <877f8r3zuj.fsf@wheatstone.g10code.de> References: <87insx8404.fsf@servo.finestructure.net> <87bmyoy5a9.fsf@europa.jade-hamburg.de> <877f9c88t7.fsf@servo.finestructure.net> <87k2dbucl4.fsf@alice.fifthhorseman.net> <87d1imekqo.fsf@alice.fifthhorseman.net> <87wpgs9qbg.fsf@alice.fifthhorseman.net> <87twbw9o7c.fsf@alice.fifthhorseman.net> <877f8r3zuj.fsf@wheatstone.g10code.de> Message-ID: <87wpgosh54.fsf@europa.jade-hamburg.de> Werner Koch writes: > [ Unknown signature status ] > On Fri, 28 Oct 2016 23:08, dkg at fifthhorseman.net said: > >> If any gpgme developers think this is worth doing, please go ahead and >> claim the "gpg" name on pypi, and you're welcome to merge my patch. > > I think this is a good idea. Justus, what do you think? Agreed. Daniel, thanks for sorting through our options and preparing the patch. I just merged it and uploaded it to PyPI: https://pypi.python.org/pypi/gpg Cheers, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From justus at g10code.com Mon Oct 31 16:01:23 2016 From: justus at g10code.com (Justus Winter) Date: Mon, 31 Oct 2016 16:01:23 +0100 Subject: [PATCH GnuPG] RFC: g10: Improve and unify key selection. In-Reply-To: <92373543.ha0chvWdI8@esus> References: <20161031121216.17122-1-justus@g10code.com> <92373543.ha0chvWdI8@esus> Message-ID: <87twbssgu4.fsf@europa.jade-hamburg.de> Andre Heinecke writes: > On Monday 31 October 2016 13:12:16 Justus Winter wrote: >> When a name resembling a mail address is given to either --locate-key >> or --recipient, rank the search results and use only the most relevant >> key. > > I would prefer it if this function would also return expired / revoked / > validitity never etc. Keys. So in a GUI we could handle this case by informing > the user that the key for this user is expired. > > Otherwise we would have to check for that case with another keylisting to > avoid the problem that a user was able to encrypt to someone yesterday > automatically and today it no longer works and the UI just shows "No key for > this recipient" when a UI uses locate-keys. Right, I mis-read the algorithm you posted in the bug report. >> This also lets us query which key will be used for encryption using >> --locate-key. XXX: Is this true? B/c if we use --recipient, we only >> consider keys usable for encryption. Otoh, --locate-key has no such >> constraint. > > I think this could be solved by ranking a key that can both encrypt higher > then a key that can't encrypt. This would avoid the state where an encrypt key > can can't be found because a user has a different primary key with only signing > (for whatever weird reason). The primary usecase of this function imo is to > look up recipient keys for encryption. Ok, I'll revise the patch. Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From dkg at fifthhorseman.net Mon Oct 31 17:29:04 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 31 Oct 2016 12:29:04 -0400 Subject: [PATCH GnuPG] RFC: g10: Improve and unify key selection. In-Reply-To: <92373543.ha0chvWdI8@esus> References: <20161031121216.17122-1-justus@g10code.com> <92373543.ha0chvWdI8@esus> Message-ID: <8760o8a3e7.fsf@alice.fifthhorseman.net> On Mon 2016-10-31 10:51:29 -0400, Andre Heinecke wrote: > I think this could be solved by ranking a key that can both encrypt higher > then a key that can't encrypt. This would avoid the state where an encrypt key > can can't be found because a user has a different primary key with only signing > (for whatever weird reason). The primary usecase of this function imo is to > look up recipient keys for encryption. If this is the use case, we should be explicit about it in the function naming and/or arguments. It's conceivable that someone might want to use this search for other purposes, and we should make it clear that it's encryption focused. Other possible uses: * what key to use when verifying a signature? Most signatures already indicate which key made them, so you'd find the signing key to verify directly from the signature; we don't need to look up the key by e-mail address or user ID in this case. so this one is probably not relevant. * what key(s) to permit for authentication based on a particular user ID? (e.g. monkeysphere) In practice, we might want a list of *all* keys that have a given validity-level and have an authentication-capable subkey. So this one might be relevant, and it would be nice to know that you'd be returned the keys in order of validity, so you could just stop parsing the list when the validity drops below the level that you care about. Anything else? --dkg From dkg at fifthhorseman.net Mon Oct 31 20:01:21 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 31 Oct 2016 15:01:21 -0400 Subject: GPGME question: who uses /usr/include/{gpgmepp,qgpgme}_version.h ? Message-ID: <87ins88hry.fsf@alice.fifthhorseman.net> Hi all-- i just realized that in addition to /usr/include/qgpgme/ and /usr/include/gpgme++/, GPGME's development headers want to ship /usr/include/qgpgme_version.h and /usr/include/libgpgmepp_version.h. These files contain #define macros for the version information of the library that's being built against. What's the reason for having these two files at the same level (/usr/include/) instead of shipping them inside the shipped directories? For example, why not ship /usr/include/qgpgme/version.h instead? On my own dev workstation, i see many more packages following the foo/version.h approach: 0 dkg at alice:~$ ls /usr/include/*/*version.h | wc -l 29 0 dkg at alice:~$ ls /usr/include/*version.h | wc -l 4 0 dkg at alice:~$ Is there a reason to use ${library}_version.h instead of putting the file inside the shipped directory? fwiw, if there's a concern about backward compatibility, I've looked on https://codesearch.debian.net and i don't see anyone using these version.h files directly in debian at all at the moment. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From dkg at fifthhorseman.net Mon Oct 31 20:18:02 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 31 Oct 2016 15:18:02 -0400 Subject: can we drop -lassuan and -lgpg-error from the output of "gpgme-config --libs" ? Message-ID: <87func8h05.fsf@alice.fifthhorseman.net> Hi all-- 0 dkg at alice:~$ gpgme-config --libs -L/usr/lib/x86_64-linux-gnu -lgpgme -lassuan -lgpg-error 0 dkg at alice:~$ But it's not clear to me why this should include libassuan or libgpg-error. gpgme itself may link to assuan and gpg-error, but that doesn't mean that any project linking to libgpgme itself must also *directly* link to libassuan and libgpg-error, if they use none of the symbols from those libraries themselves. The dynamic linker should handle any necessary recursive loads. I ask this because i'm seeing the following warnings from debian's build infrastructure: dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/python3-pyme/usr/lib/python3/dist-packages/pyme/_gpgme.cpython-35m-x86_64-linux-gnu.so was not linked against libgpg-error.so.0 (it uses none of the library's symbols) dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/python3-pyme/usr/lib/python3/dist-packages/pyme/_gpgme.cpython-35m-x86_64-linux-gnu.so was not linked against libassuan.so.0 (it uses none of the library's symbols) (and so on, for the C++ and QT bindings as well) I think this is happening because the build process invokes "gpgme-config --libs" explicitly and uses the resulting flags to build the project. If we were to drop this as a requirement, then any package which tries to directly use libassuan or libgpg-error would need to explicitly re-add those libraries to their build process, but i think that kind of explicit positive declaration is better than the implicit default over-declaration that's happening here. Likewise, it appears that libqgpgme is linking against both libgpgmepp and against libgpgme, even though it uses no symbols from libgpgme directly. It'd be great to make these declarations more parsimonious. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: