From gniibe at fsij.org Fri May 1 09:30:36 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 01 May 2015 16:30:36 +0900 Subject: [PATCH] --batch should imply --pinentry-mode=loopback??? Message-ID: <55432B9C.1050405@fsij.org> Hello, These are fix candidates for the issue 1928: https://bugs.gnupg.org/gnupg/issue1928 In g10/passphrase.c, there is a condtion like: (opt.batch || opt.pinentry_mode == PINENTRY_MODE_LOOPBACK) ... which makes me wonder if there is a case people want to specify options with --batch --pinentry-mode=ask/cancel. If not, the fix will be (1). If yes, the fix will be (2). (1) Simple one (passphrase.c will need to fix, later) ======================================================================= diff --git a/g10/gpg.c b/g10/gpg.c index 13d6884..4f35bbf 100644 --- a/g10/gpg.c +++ b/g10/gpg.c @@ -2376,6 +2376,7 @@ main (int argc, char **argv) case oBatch: opt.batch = 1; + opt.pinentry_mode = PINENTRY_MODE_LOOPBACK; nogreeting = 1; break; (2) We pass on pinentry-mode=loopback to gpg-agent when have_static_passphrase()==1 ======================================================================= diff --git a/g10/call-agent.c b/g10/call-agent.c index 017e916..5162530 100644 --- a/g10/call-agent.c +++ b/g10/call-agent.c @@ -164,17 +164,18 @@ default_inq_cb (void *opaque, const char *line) log_error (_("failed to proxy %s inquiry to client\n"), "PINENTRY_LAUNCHED"); /* We do not pass errors to avoid breaking other code. */ + return err; } - else if ((has_leading_keyword (line, "PASSPHRASE") - || has_leading_keyword (line, "NEW_PASSPHRASE")) - && opt.pinentry_mode == PINENTRY_MODE_LOOPBACK) + + if ((has_leading_keyword (line, "PASSPHRASE") + || has_leading_keyword (line, "NEW_PASSPHRASE"))) { if (have_static_passphrase ()) { const char *s = get_static_passphrase (); - err = assuan_send_data (parm->ctx, s, strlen (s)); + return assuan_send_data (parm->ctx, s, strlen (s)); } - else + else if (opt.batch || opt.pinentry_mode == PINENTRY_MODE_LOOPBACK) { char *pw; @@ -189,11 +190,11 @@ default_inq_cb (void *opaque, const char *line) else err = assuan_send_data (parm->ctx, pw, strlen (pw)); xfree (pw); + return err; } } - else - log_debug ("ignoring gpg-agent inquiry '%s'\n", line); + log_debug ("ignoring gpg-agent inquiry '%s'\n", line); return err; } @@ -306,9 +307,10 @@ start_agent (ctrl_t ctrl, int for_card) assuan_transact (agent_ctx, "OPTION agent-awareness=2.1.0", NULL, NULL, NULL, NULL, NULL, NULL); /* Pass on the pinentry mode. */ - if (opt.pinentry_mode) + if (have_static_passphrase () || opt.pinentry_mode) { char *tmp = xasprintf ("OPTION pinentry-mode=%s", + opt.batch ? "loopback" : str_pinentry_mode (opt.pinentry_mode)); rc = assuan_transact (agent_ctx, tmp, NULL, NULL, NULL, NULL, NULL, NULL); -- From bre at pagekite.net Fri May 1 11:15:21 2015 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Fri, 01 May 2015 09:15:21 -0000 Subject: excessive usage of /dev/random? In-Reply-To: <87twvxises.fsf@alice.fifthhorseman.net> References: <87twvxises.fsf@alice.fifthhorseman.net> Message-ID: <20150501091520-16843-95607-mailpile@slinky> Thanks for starting this discussion, Daniel. I just wanted to chime in and point out that this decision has a cost for the usability and complexity of apps like Mailpile, where the first thing we do upon setup is create a key for the user if one does not exist already. It's common for key creation (for a 4096 bit key) to take over 10 minutes and I've seen it take well over 30. This adds complexity, because: a) waiting so long is an unacceptable user experience, so apps have to be written create the key in the background and communicate progress to the user somehow. This includes blocking or disabling elements of the UI that depend on the key existing. b) apps have to gracefully deal with the very common situation that the user quits the app before the key creation has completed. It may not sound like much, but this adds complexity all over the place in the app (Mailpile does not get all this stuff right yet), both in terms of code and communicating with the user. The alternative, asking the user to "please wait half an hour" is just not acceptable. If gnupg were more frugal with entropy, key creation would take less time and this would be much less of an issue. Note that I'm not asking that GnuPG compromise on security and trust Werner and others more qualified to make safe choices in that regard. However, this *is* slightly impacting the security of Mailpile, as I'm probably not going to go with 4096 bit keys by default, simply because creating them takes too long. I'm told 2048 is probably "good enough", as a default, so that's what we'll be shipping. So if there is indeed headroom to be more frugal with /dev/random and speed things up corrospondingly, doing so has my vote! Cheers, - Bjarni Daniel Kahn Gillmor wrote: > The argument that the man page makes (and that djb makes in > http://blog.cr.yp.to/20140205-entropy.html) is that for a proper CSPRNG, > you shouldn't really need more than 256 bits of true entropy to get a > properly unbreakable seed. "some safety margin above that minimum is > reasonable", but going from 32 bytes to 300 bytes is a rather large > safety margin. ... -- Sent using Mailpile, Free Software from www.mailpile.is -------------- next part -------------- A non-text attachment was scrubbed... Name: Secure_Headers.txt Type: text/rfc822-headers Size: 512 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: OpenPGP Digital Signature URL: From cswiger at mac.com Fri May 1 18:41:50 2015 From: cswiger at mac.com (Charles Swiger) Date: Fri, 01 May 2015 09:41:50 -0700 Subject: excessive usage of /dev/random? In-Reply-To: <20150501091520-16843-95607-mailpile@slinky> References: <87twvxises.fsf@alice.fifthhorseman.net> <20150501091520-16843-95607-mailpile@slinky> Message-ID: <41DBE96E-0C52-4F69-B23F-05AD3C9720DB@mac.com> On May 1, 2015, at 2:15 AM, Bjarni Runar Einarsson wrote: > I just wanted to chime in and point out that this decision has a cost > for the usability and complexity of apps like Mailpile, where the first > thing we do upon setup is create a key for the user if one does not > exist already. It's common for key creation (for a 4096 bit key) to take > over 10 minutes and I've seen it take well over 30. I'd suggest looking into Yarrow or Fortuna, which are CSPRNG algorithms intended to be suitable for generating crypto keys. If your operating system doesn't already use them-- I believe FreeBSD, MacOS X, and some other BSD flavors use Yarrow + hardware entropy harvesting in their /dev/random implementation-- one can implement the algorithms in userland and minimize the drain against a blocking /dev/random. Regards, -- -Chuck From dkg at fifthhorseman.net Fri May 1 20:21:35 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 01 May 2015 14:21:35 -0400 Subject: excessive usage of /dev/random? In-Reply-To: <41DBE96E-0C52-4F69-B23F-05AD3C9720DB@mac.com> References: <87twvxises.fsf@alice.fifthhorseman.net> <20150501091520-16843-95607-mailpile@slinky> <41DBE96E-0C52-4F69-B23F-05AD3C9720DB@mac.com> Message-ID: <87pp6k9n0w.fsf@alice.fifthhorseman.net> On Fri 2015-05-01 12:41:50 -0400, Charles Swiger wrote: > On May 1, 2015, at 2:15 AM, Bjarni Runar Einarsson wrote: >> I just wanted to chime in and point out that this decision has a cost >> for the usability and complexity of apps like Mailpile, where the first >> thing we do upon setup is create a key for the user if one does not >> exist already. It's common for key creation (for a 4096 bit key) to take >> over 10 minutes and I've seen it take well over 30. > > I'd suggest looking into Yarrow or Fortuna, which are CSPRNG algorithms > intended to be suitable for generating crypto keys. If your operating system > doesn't already use them-- I believe FreeBSD, MacOS X, and some other BSD flavors > use Yarrow + hardware entropy harvesting in their /dev/random implementation-- > one can implement the algorithms in userland and minimize the drain against a > blocking /dev/random. GnuPG already implements a CSPRNG, as noted upthread by Werner. I'm asking here about whether we are over-seeding it. I'm not trying to reopen the whole discussion about what specific CSPRNG we should be using in GnuPG. If anyone wants to have that discussion, can we please have it in a separate thread? --dkg From rjh at sixdemonbag.org Fri May 1 20:40:32 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 01 May 2015 14:40:32 -0400 Subject: excessive usage of /dev/random? In-Reply-To: <41DBE96E-0C52-4F69-B23F-05AD3C9720DB@mac.com> References: <87twvxises.fsf@alice.fifthhorseman.net> <20150501091520-16843-95607-mailpile@slinky> <41DBE96E-0C52-4F69-B23F-05AD3C9720DB@mac.com> Message-ID: <5543C8A0.8060300@sixdemonbag.org> > I'd suggest looking into Yarrow or Fortuna, which are CSPRNG > algorithms intended to be suitable for generating crypto keys. Yarrow's troublesome to implement, in that it requires accurate estimates of available entropy pools and how they refresh. Fortuna has a simpler design. The Yarrow authors recommend using Fortuna, and one of them has declared Yarrow will no longer receive support or updates. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3744 bytes Desc: S/MIME Cryptographic Signature URL: From cswiger at mac.com Fri May 1 20:43:38 2015 From: cswiger at mac.com (Charles Swiger) Date: Fri, 01 May 2015 11:43:38 -0700 Subject: excessive usage of /dev/random? In-Reply-To: <87pp6k9n0w.fsf@alice.fifthhorseman.net> References: <87twvxises.fsf@alice.fifthhorseman.net> <20150501091520-16843-95607-mailpile@slinky> <41DBE96E-0C52-4F69-B23F-05AD3C9720DB@mac.com> <87pp6k9n0w.fsf@alice.fifthhorseman.net> Message-ID: On May 1, 2015, at 11:21 AM, Daniel Kahn Gillmor wrote: [ ... ] > GnuPG already implements a CSPRNG, as noted upthread by Werner. I'm > asking here about whether we are over-seeding it. Drawing ~300 bytes from /dev/random to create a ~2048 bit keypair seems entirely reasonable. Whether that should go through a CSPRNG depends on how good the CSPRNG is compared to the /dev/random implementation. > I'm not trying to > reopen the whole discussion about what specific CSPRNG we should be > using in GnuPG. If anyone wants to have that discussion, can we please > have it in a separate thread? Excuse me, Daniel-- I'd replied to Bjarni, not a post made by you. It seemed germane to the origin of the thread because the reason why someone might care about pulling 300 bytes from /dev/random (versus 200 or whatever), is because your platform has a blocking /dev/random implementation. Regards, -- -Chuck From neal at walfield.org Fri May 1 20:43:56 2015 From: neal at walfield.org (Neal H. Walfield) Date: Fri, 01 May 2015 20:43:56 +0200 Subject: [PATCH 1/4] pinentry-tty: handle designated tty outside of read_password In-Reply-To: <87wq0tiuwx.fsf@alice.fifthhorseman.net> References: <1430240476-27188-1-git-send-email-dkg@fifthhorseman.net> <874mnxg7ka.wl-neal@walfield.org> <87wq0tiuwx.fsf@alice.fifthhorseman.net> Message-ID: <87wq0sdtoz.wl-neal@walfield.org> Hi Daniel, I've now pushed your four patches. Thanks for the fixes! At Thu, 30 Apr 2015 09:54:06 -0400, Daniel Kahn Gillmor wrote: > On Thu 2015-04-30 07:49:09 -0400, Neal H. Walfield wrote: > > I had a bit of trouble applying them to git head (due to differing > > white space). What version did you base these patches on? > > For me, they apply directly atop > 9d2d8b6bfaf2d5b07e7fb5be7188516e4158ed98, which is what i see as the > main "master" branch at git://git.gnupg.org/pinentry.git. I just tested > that by piping each e-mail message through "git am" in sequence after > that commit. I also used git am and it complained about some whitespace issues. > You can also see these changes on the "tty-refactor" branch at: > > git://lair.fifthhorseman.net/~dkg/pinentry > > If you'd prefer to see the changes in some other form, please let me > know what is most convenient for you. Personally, I prefer pulling from a git repo. But, if it's not any trouble, feel free to also send the patches to this list in this format for the record. I don't know what Werner prefers. If he doesn't like this suggestion, then he's welcome to chime in :). > > Also, you didn't update the copyright header. I'll fit this for you. > > What's appropriate here? > > Thanks! I think you're asking about attribution, so: you can credit the > changes to Daniel Kahn Gillmor . If you're > asking for some other detail, please let me know. I think I meant copyright. I've added the following header to the file you modified: Copyright (C) 2015 Daniel Kahn Gillmor Neal From wk at gnupg.org Fri May 1 20:46:11 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 01 May 2015 20:46:11 +0200 Subject: excessive usage of /dev/random? In-Reply-To: <87twvxises.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 30 Apr 2015 10:48:11 -0400") References: <87twvykd8w.fsf@alice.fifthhorseman.net> <87sibi5cvb.fsf@vigenere.g10code.de> <87twvxises.fsf@alice.fifthhorseman.net> Message-ID: <87bni43zm4.fsf@vigenere.g10code.de> On Thu, 30 Apr 2015 16:48, dkg at fifthhorseman.net said: > http://blog.cr.yp.to/20140205-entropy.html) is that for a proper CSPRNG, > you shouldn't really need more than 256 bits of true entropy to get a > properly unbreakable seed. "some safety margin above that minimum is That is easy to see for a 256 bit ECC key. > reasonable", but going from 32 bytes to 300 bytes is a rather large > safety margin. 300 bytes are only 2400 bit which is sufficient for a 2048 bit RSA key. For a 4096 bit RSA key, which many people started to use, this is not sufficient. Right the full 4800 bits collected in the pool would be sufficient here but maintaining this pool is pretty costly and thus we keep it over the invocation of gpg/gpg-agent by means of the random_seed file. Requiring 300 fresh bytes before generating the first long term key by gpg-agent (or gpg < 2.1) guarantees that we don't decrease the security of a new 2048 bit RSA key in case the random_seed somehow leaked or or was overwritten with known data. For ECC keys, which are generated by gpg-agent, it would be possible to tell the RNG that it should only make sure that there are 32 fresh random bytes in the pool. This could be done with a new API for getting N bytes of random with the promise that this is all the random required for the object. The current API allows to put RNG in chunks into a buffer. The RNG has no knowledge on whether these requests for random are for one object or are independent. Sure, such a new API can be done but it also increases the code complexity in the RNG thus I won't do this without a very good reason. > is "way too fast" really an issue? If we had excellent entropy, we > wouldn't care about it showing up speedily, right? I consider this a bug in the kernel or maybe it is due to the use of RDRAND. Might not be an issue with current kernels anymore, though. > outside. I'm asking about whether we really need 300 bytes (2400 bits) > of a seed, which random(4) suggests is overkill. For example, a 3072-bit RSA or Diffie-Hellman private key has an effective key size of 128 bits (it requires about 2^128 operations to break) so a key generator only needs 128 bits (16 bytes) of seed material from /dev/random. This is the common assumption when comparing asymmetric keys to symmetric keys. Here we are talking about the generation of asymmetric keys and I do not know whether the same relation can be applied. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From cswiger at mac.com Fri May 1 21:11:22 2015 From: cswiger at mac.com (Charles Swiger) Date: Fri, 01 May 2015 12:11:22 -0700 Subject: excessive usage of /dev/random? In-Reply-To: <5543C8A0.8060300@sixdemonbag.org> References: <87twvxises.fsf@alice.fifthhorseman.net> <20150501091520-16843-95607-mailpile@slinky> <41DBE96E-0C52-4F69-B23F-05AD3C9720DB@mac.com> <5543C8A0.8060300@sixdemonbag.org> Message-ID: <9F5EEDC5-3E4D-4FEA-B209-34C60604C71E@mac.com> On May 1, 2015, at 11:40 AM, Robert J. Hansen wrote: >> I'd suggest looking into Yarrow or Fortuna, which are CSPRNG >> algorithms intended to be suitable for generating crypto keys. > > Yarrow's troublesome to implement, in that it requires accurate > estimates of available entropy pools and how they refresh. True. I can recall vigorous debate about tweaking the # of bits of entropy one could assume from various HW sources on the FreeBSD lists. They ended up picking conservative estimates since it still provided a sufficient amount of entropy for Yarrow to supply megabytes per second from /dev/random. (Except diskless systems, perhaps, since I/O completion time is usually a major source of entropy, unless a hardware RNG is handy.) > Fortuna has a simpler design. The Yarrow authors recommend using Fortuna, and one > of them has declared Yarrow will no longer receive support or updates. Agreed. I've love to see Fortuna get adopted more widely; it would make a worthy project for someone (GSoC?). Regards, -- -Chuck From lists-gnupgdev at lina.inka.de Fri May 1 21:25:43 2015 From: lists-gnupgdev at lina.inka.de (lists-gnupgdev at lina.inka.de) Date: Fri, 1 May 2015 21:25:43 +0200 Subject: excessive usage of /dev/random? In-Reply-To: <87bni43zm4.fsf@vigenere.g10code.de> References: <87twvykd8w.fsf@alice.fifthhorseman.net> <87sibi5cvb.fsf@vigenere.g10code.de> <87twvxises.fsf@alice.fifthhorseman.net> <87bni43zm4.fsf@vigenere.g10code.de> Message-ID: <20150501212543.00002439.ecki@lina.inka.de> Am Fri, 01 May 2015 20:46:11 +0200 schrieb Werner Koch : > > is "way too fast" really an issue? If we had excellent entropy, we > > wouldn't care about it showing up speedily, right? > > I consider this a bug in the kernel or maybe it is due to the use of > RDRAND. Might not be an issue with current kernels anymore, though. I think this was only a problem with urandom. Unfortunatelly the new random() syscall in Linux is not much safer to use (especially if requesting more than 256bytes a time). I wish arc4randome from OpenBSD would be more common place. Gruss Bernd PS: http://www.openbsd.org/papers/hackfest2014-arc4random/mgp00015.html From rjh at sixdemonbag.org Fri May 1 21:52:13 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 01 May 2015 15:52:13 -0400 Subject: excessive usage of /dev/random? In-Reply-To: References: <87twvxises.fsf@alice.fifthhorseman.net> <20150501091520-16843-95607-mailpile@slinky> <41DBE96E-0C52-4F69-B23F-05AD3C9720DB@mac.com> <87pp6k9n0w.fsf@alice.fifthhorseman.net> Message-ID: <5543D96D.8070904@sixdemonbag.org> > Drawing ~300 bytes from /dev/random to create a ~2048 bit keypair > seems entirely reasonable. I had a response to this that I thought was a neat digression into why this may not be a reasonable assumption: by the end of it I realized I'd just shown that ultimately it may be reasonable, too. For that reason I'm not sharing it, because ultimately it amounted to no contribution at all. But if anyone wants to see a high school math overview of large number theory and what it tells us about asymmetric key generation and how to break asymmetric keys, email me *OFF-LIST* and I'll share it. :) Remember: *OFF-LIST*. Let's not clutter gnupg-devel. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3744 bytes Desc: S/MIME Cryptographic Signature URL: From dkg at fifthhorseman.net Fri May 1 23:08:50 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 01 May 2015 17:08:50 -0400 Subject: [PATCH 1/4] pinentry-tty: handle designated tty outside of read_password In-Reply-To: <87wq0sdtoz.wl-neal@walfield.org> References: <1430240476-27188-1-git-send-email-dkg@fifthhorseman.net> <874mnxg7ka.wl-neal@walfield.org> <87wq0tiuwx.fsf@alice.fifthhorseman.net> <87wq0sdtoz.wl-neal@walfield.org> Message-ID: <87a8xo9fa5.fsf@alice.fifthhorseman.net> On Fri 2015-05-01 14:43:56 -0400, Neal H. Walfield wrote: > I've now pushed your four patches. Thanks for the fixes! Sweet, glad they're useful. I just checked, and noticed your updates to the pinentry documentation and to fine-tuning the PIN prompt for -tty. That kind of attention to detail is much appreciated! > I also used git am and it complained about some whitespace issues. huh, weird. I guess they were munged by some MTA somehow? I'm happy to try to debug this with you offlist if you like, because it seems like "git am" ought to Just Work. > Personally, I prefer pulling from a git repo. But, if it's not any > trouble, feel free to also send the patches to this list in this > format for the record. I don't know what Werner prefers. If he > doesn't like this suggestion, then he's welcome to chime in :). works for me. > I think I meant copyright. I've added the following header to the > file you modified: > > Copyright (C) 2015 Daniel Kahn Gillmor Looks good, thanks. --dkg From pgut001 at cs.auckland.ac.nz Fri May 1 23:37:26 2015 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Sat, 02 May 2015 09:37:26 +1200 Subject: excessive usage of /dev/random? In-Reply-To: <87bni43zm4.fsf@vigenere.g10code.de> Message-ID: Werner Koch writes: >300 bytes are only 2400 bit which is sufficient for a 2048 bit RSA key. For a >4096 bit RSA key, which many people started to use, this is not sufficient. It should be plenty. Cryptographic numerology (http://www.keylength.com/) tells us that a 2048-bit RSA key needs about 103 bits of entropy, and a 4096 bit key needs about 142 bits (with a bit of variation depending on whose numerology you're using). So take 150 bits of RNG output, feed it into a PRF, and you're done. Peter. From pgut001 at cs.auckland.ac.nz Sat May 2 00:45:12 2015 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Fri, 1 May 2015 22:45:12 +0000 Subject: excessive usage of /dev/random? Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB00FC46@uxcn10-tdc05.UoA.auckland.ac.nz> Werner Koch writes: >300 bytes are only 2400 bit which is sufficient for a 2048 bit RSA key. For a >4096 bit RSA key, which many people started to use, this is not sufficient. It should be plenty. Cryptographic numerology (http://www.keylength.com/) tells us that a 2048-bit RSA key needs about 103 bits of entropy, and a 4096 bit key needs about 142 bits (with a bit of variation depending on whose numerology you're using). So take 150 bits of RNG output, feed it into a PRF, and you're done. Peter. From dkg at fifthhorseman.net Sat May 2 03:01:32 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 01 May 2015 21:01:32 -0400 Subject: excessive usage of /dev/random? In-Reply-To: References: Message-ID: <87h9rv94ib.fsf@alice.fifthhorseman.net> On Fri 2015-05-01 15:52:13 -0400, Robert J. Hansen wrote: >> Drawing ~300 bytes from /dev/random to create a ~2048 bit keypair >> seems entirely reasonable. > > I had a response to this that I thought was a neat digression into why > this may not be a reasonable assumption: by the end of it I realized I'd > just shown that ultimately it may be reasonable, too. For that reason > I'm not sharing it, because ultimately it amounted to no contribution at > all. > > But if anyone wants to see a high school math overview of large number > theory and what it tells us about asymmetric key generation and how to > break asymmetric keys, email me *OFF-LIST* and I'll share it. :) On Fri 2015-05-01 17:37:26 -0400, Peter Gutmann wrote: > Werner Koch writes: > >>300 bytes are only 2400 bit which is sufficient for a 2048 bit RSA key. For a >>4096 bit RSA key, which many people started to use, this is not sufficient. > > It should be plenty. Cryptographic numerology (http://www.keylength.com/) > tells us that a 2048-bit RSA key needs about 103 bits of entropy, and a 4096 > bit key needs about 142 bits (with a bit of variation depending on whose > numerology you're using). So take 150 bits of RNG output, feed it into a PRF, > and you're done. We now have two apparently contrary assertions made to gnupg-devel about what the right/necessary thing to do is in this circumstance. One assertion (from Robert J. Hansen) implies that a "high school math overview of large number theory" suggests that it may well be reasonable to require 2400 bits of entropy to generate a 2048-bit RSA key. The other assertion (From Peter Gutmann) says that it's not necessary (with a sarcastic allusion to "numerology"), and seems to roughly echo the perspective found in random(4), while citing (indirectly) several major surveys of cryptographic strength. Robert, i know you might think this is "cluttering" the list, but please show your work if you think it invalidates Peter's assertion. I think this dicsussion is clearly relevant to the development of gpg, even if the result of the discussion is a conensus to keep the current behavior. Peter, if your "numerology" remark is actually ironic (that is, if you do not believe the literal conclusion you've drawn but are instead critiquing what you see as bogus equivalences between classes of cryptographic algorithms), could you please clarify that? Sorry for having to ask... My basic understanding of the argument from random(4) as applied to asymmetric key generation for integer factorization, DLOG, and related problems is this: 0) the best attacks we know about for this class of problems are much cheaper than a brute force search of the entire keyspace. The cost to break a 2048-bit RSA key is a bit more than 2^100 "operations" (this rough equivalence estimate is what Peter calls "numerology"). 1) key generation routines for these problems need an unpredictable source of entropy with which to search the space of possible values to produce a proper secret key. 2) we can produce an arbitrary amount of unpredictable data from a CSPRNG seeded with 256 bits of entropy. If the CSPRNG behaves according to expectations, an attacker can guess at this pool (where 2^x guesses cover x bits of the initial seed entropy) but if they don't stumble across the exact seed in that search, they won't be able to use this to learn anything about the actual key. 3) An attacker capable of searching a large amount of the seed space (covering 100 bits of the seed space should cost about 2^100 "operations") has enough compute power to instead mount one of the typical attacks against the underlying asymmetric problem, since it's the same cost. One possible hole in this argument (that i can think of) would be if there were some sort of "meet in the middle" attack, where with knowledge of the CSPRNG and the secret key search strategy, an attacker could combine the speedups of the traditional attack with a somehow-constrained search of the initial seed entropy to mount a more computationally effective attack than either attack individually. I have no idea what this kind of combined attack would look like; i certainly don't know whether it exists or not. If other folks think this discussion is seriously off-topic here, could you suggest a preferred place for it? Regards, --dkg From pgut001 at cs.auckland.ac.nz Sat May 2 03:13:31 2015 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Sat, 02 May 2015 13:13:31 +1200 Subject: excessive usage of /dev/random? In-Reply-To: <87h9rv94ib.fsf@alice.fifthhorseman.net> Message-ID: Daniel Kahn Gillmor writes: >Peter, if your "numerology" remark is actually ironic (that is, if you do not >believe the literal conclusion you've drawn but are instead critiquing what >you see as bogus equivalences between classes of cryptographic algorithms), >could you please clarify that? Sorry for having to ask... It's most definitely ironic, it was meant in the sense of "the numerologists say we need to do X, so let's see what happens when I throw that statement out there". (The cryptographic numerology here comes from the confusing idea of algorithm pairings, that every conventional encryption algorithm or key size has to be somehow matched up to a public-key algorithm key size. Since conventional encryption algorithms generally have the property that every single bit added to the key doubles the work factor needed to break it by brute force while public-key algorithms don't, this means that attempts to pair conventional- encryption with public-key sizes leads to insanely large public keys as the conventional-encryption key sizes get larger. Using any known technology it's unlikely that humans can ever get beyond about 2^^100 operations, which means that common key sizes of 112 bits (triple DES), 128 bits (AES), 192 bits (AES again), and 256 bits (yet more AES, because you can never have too many key sizes) are all equally unbreakable, and yet the desire for algorithm pairing means that we're supposed to go to public-key sizes of 2048, 3072, 7680, and 15,360 bits respectively for all of these equally-unbreakable conventional key sizes. Thus: "cryptographic numerology"). >2) we can produce an arbitrary amount of unpredictable data from a CSPRNG >seeded with 256 bits of entropy. Yup. Now that doesn't mean don't use 2048 bits (or whatever) if it's available, but you don't need 2048 bits of pure entropy, anything over... well lets round it up to a nice 128 bits, should be OK. (Adding some further comment in case this ends up getting quoted elsewhere, you don't even need 128 bits of "pure entropy", just 128 bits not known to your opponent. Choose a fixed 128-bit value that you keep very secret and add one to it every time it's used, it's not optimal but good enough if it's the only option). Peter. From dkg at fifthhorseman.net Sat May 2 03:33:34 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 01 May 2015 21:33:34 -0400 Subject: [PATCH] --batch should imply --pinentry-mode=loopback??? In-Reply-To: <55432B9C.1050405@fsij.org> References: <55432B9C.1050405@fsij.org> Message-ID: <87egmz930x.fsf@alice.fifthhorseman.net> This for bringing this up! On Fri 2015-05-01 03:30:36 -0400, NIIBE Yutaka wrote: > These are fix candidates for the issue 1928: > https://bugs.gnupg.org/gnupg/issue1928 > > In g10/passphrase.c, there is a condtion like: > > (opt.batch || opt.pinentry_mode == PINENTRY_MODE_LOOPBACK) > > ... which makes me wonder if there is a case people want to specify > options with --batch --pinentry-mode=ask/cancel. There is definitely a case where we want both --batch and --pinentry-mode=ask Consider a graphical GnuPG frontend that does key generation. Ideally, that frontend should not need to ever touch the user's password, or to implement any password-entry UI. However, it should be able to select appropriate values for the initial user ID and for any sort of key parameters (usage flags, etc) that are relevant to the use case. Please do not remove the ability to use --gen-key --batch with --pinentry-mode=ask ! --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From wk at gnupg.org Sat May 2 18:34:45 2015 From: wk at gnupg.org (Werner Koch) Date: Sat, 02 May 2015 18:34:45 +0200 Subject: [PATCH 1/4] pinentry-tty: handle designated tty outside of read_password In-Reply-To: <87a8xo9fa5.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 01 May 2015 17:08:50 -0400") References: <1430240476-27188-1-git-send-email-dkg@fifthhorseman.net> <874mnxg7ka.wl-neal@walfield.org> <87wq0tiuwx.fsf@alice.fifthhorseman.net> <87wq0sdtoz.wl-neal@walfield.org> <87a8xo9fa5.fsf@alice.fifthhorseman.net> Message-ID: <87h9rv2b16.fsf@vigenere.g10code.de> On Fri, 1 May 2015 23:08, dkg at fifthhorseman.net said: >> I also used git am and it complained about some whitespace issues. > > huh, weird. I guess they were munged by some MTA somehow? I'm happy to > try to debug this with you offlist if you like, because it seems like > "git am" ought to Just Work. I virtually never see problems with applying patches from you. I usually feed the attachment into something like "ssh foo | git am -" @neal: Trouble with wanderlust? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Sat May 2 18:31:24 2015 From: wk at gnupg.org (Werner Koch) Date: Sat, 02 May 2015 18:31:24 +0200 Subject: [PATCH 1/4] pinentry-tty: handle designated tty outside of read_password In-Reply-To: <87wq0sdtoz.wl-neal@walfield.org> (Neal H. Walfield's message of "Fri, 01 May 2015 20:43:56 +0200") References: <1430240476-27188-1-git-send-email-dkg@fifthhorseman.net> <874mnxg7ka.wl-neal@walfield.org> <87wq0tiuwx.fsf@alice.fifthhorseman.net> <87wq0sdtoz.wl-neal@walfield.org> Message-ID: <87lhh72b6r.fsf@vigenere.g10code.de> On Fri, 1 May 2015 20:43, neal at walfield.org said: > format for the record. I don't know what Werner prefers. If he I prefer patches because there is no need to go online when I find the time to apply them. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From neal at walfield.org Sat May 2 21:39:20 2015 From: neal at walfield.org (Neal H. Walfield) Date: Sat, 02 May 2015 21:39:20 +0200 Subject: [PATCH 1/4] pinentry-tty: handle designated tty outside of read_password In-Reply-To: <87wq0tiuwx.fsf@alice.fifthhorseman.net> References: <1430240476-27188-1-git-send-email-dkg@fifthhorseman.net> <874mnxg7ka.wl-neal@walfield.org> <87wq0tiuwx.fsf@alice.fifthhorseman.net> Message-ID: <87twvueplj.wl-neal@walfield.org> At Thu, 30 Apr 2015 09:54:06 -0400, Daniel Kahn Gillmor wrote: > On Thu 2015-04-30 07:49:09 -0400, Neal H. Walfield wrote: > > > Thanks for these patches. I'm taking a look at them right now. > > Thanks! > > > I had a bit of trouble applying them to git head (due to differing > > white space). What version did you base these patches on? > > For me, they apply directly atop > 9d2d8b6bfaf2d5b07e7fb5be7188516e4158ed98, which is what i see as the > main "master" branch at git://git.gnupg.org/pinentry.git. I just tested > that by piping each e-mail message through "git am" in sequence after > that commit. I tried to figure out what the problem was by starting with a clean slate and carefully applying the patches in order. This time, there was no error. So, it looks like Werner's suggestion of blaming my MUA is not appropriate; I must have messed something up. Sorry for the noise. Neal From dominyktiller at gmail.com Sun May 3 02:55:23 2015 From: dominyktiller at gmail.com (Dominyk Tiller) Date: Sun, 3 May 2015 01:55:23 +0100 Subject: Most GnuPG 2.1.1 tests fail on Solaris 10 Message-ID: <554571FB.8080005@gmail.com> Hey Werner, Apologies for the manual copy-paste of an old email discussion. Wanted to follow up on the latter issue raised. Homebrew, the OS X package manager, recently switched (https://github.com/Homebrew/homebrew/pull/39199) its default preferred TMPDIR over from `/tmp` to the user's own specific tmpdir as defined in `env`. We seem to have run into the issue around path length. Or at least, that *seems* to be the issue. The path is usually around ~50 characters, so it should be way under the suspected 107, but if I move the `TMPDIR` default back to `/tmp` and recompile the `make check` stage passes fine so I'm not quite sure what else it could be. Full build logs are here: https://gist.github.com/anonymous/529ffe922261402a75ab Discussion on the potential breakage and expected end result is here: https://github.com/Homebrew/homebrew/commit/b95f27ce9f956c56d080b6dc29ba8efb841c6690 Is there anything that can be done to mitigate the breakage other than either disabling the `make check` stage or reverting the TMPDIR default change? Thanks, Dominyk Sent from OS X. If you wish to communicate more securely my PGP Public Key is 0x872524db9d74326c. ================================================================= On Thu, 18 Dec 2014 13:45, laurent at elanor.org said: > Well, I hate the backquotes myself, so if you've got a policy to > replace them with $(), I can manage on my side to replace the shell > with bash. WONTFIX is fine. Well, if Solaris is the last of the modern Unices to not support a POSIX shell, I would indeed tag it as wontfix. > There's a secret message in there, a gpg-agent error that was not > displayed, it's really being picky on the path length: Alright, this is not Solaris specific. You have this problem on all Unices because the path length of a Unix domain socket is limit (107 seems to be a common value). We hafe this socket redirection feature but the API for this also uses the sun_path field of the sockaddr_un structure. Thus we have the same limitations. But that would also require manual configuration. Is it really worth to do that or should we better document that limitation? Salam-Shalom, Werner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From Daniel.Ranft at giepa.de Mon May 4 14:42:02 2015 From: Daniel.Ranft at giepa.de (Daniel Ranft) Date: Mon, 4 May 2015 14:42:02 +0200 Subject: [gpg 2.1] GOOD_PASSPHRASE status message - missing or obsolete? Message-ID: <1DC3C8C67280FB4C9A402CB6DB1358F519E90A4C90@S2008SBS.intern.giepa.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm currently rewriting our status evaluation code of gpg4o and having some trouble with a decryption status output in GnuPG 2.1.3: [GNUPG:] ENC_TO 03DDD5A8E039B423 1 0 [GNUPG:] USERID_HINT 03DDD5A8E039B423 hans [GNUPG:] NEED_PASSPHRASE 03DDD5A8E039B423 EC50066D490FD2DC 1 0 [GNUPG:] BEGIN_DECRYPTION [GNUPG:] DECRYPTION_INFO 2 9 [GNUPG:] PLAINTEXT 62 1430292130 status.txt [GNUPG:] PLAINTEXT_LENGTH 306 [GNUPG:] DECRYPTION_OKAY [GNUPG:] GOODMDC [GNUPG:] END_DECRYPTION Am I just stupid or is the GOOD_PASSPHRASE status message missing? Should I interpret this as a bug of GnuPG 2.1 or is the GOOD_PASSPHRASE message obsolete now? For this decryption I used --pinentry-mode loopback because there is no pinentry delivered with the 2.1.3 installer for windows. Thanks, Daniel - -- Verschl?sseln Sie Ihre E-Mails mit gpg4o f?r Outlook | Encrypt your email with gpg4o Meinen PGP-Schl?ssel finden Sie auf hkp://pgp.mit.edu. Key-ID: A2B4B3EF - ------------------------------------------------------------------------------------------------------------------- Daniel Ranft Softwareentwickler Giegerich & Partner GmbH Robert-Bosch-Stra?e 18 | D-63303 Dreieich Tel. +49 6103 5881-50 | Fax +49 6103 5881-49 daniel.ranft at giepa.de | http://www.giepa.de Gesch?ftsf?hrer: Dipl.-Ing. (TU) Hans-Joachim Giegerich Amtsgericht Offenbach/Main | HRB 33236 TeleTrusT Quality Seal ?IT Security made in Germany? www.teletrust.de/itsmig - ------------------------------------------------------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using gpg4o v3.5.0.5504 - http://www.gpg4o.de/ Charset: utf-8 iQEcBAEBAgAGBQJVR2kaAAoJEC7sK2WitLPvMGEIAKf/eMJZ2BZA8On1mg8Y94Kl iqyOa9QQNHb004p3w4Pu8n6lsHT0Eez5rPW6Ev3+4zOZ+Hkv86BYVtXeiGOVomLB g/iUh/zVGRYBt6zLqedBVhy0dOI2XCafPYqT3uimpX342vBt8DAhnBtL8XJP4mk4 +6Q6zuWdVwVzxx4iWOfhUlal925oGI/mJmxABJ+sNSa9IinY02iQRbnwf9XA6BGX xT+StcKp9ltf9+/IQQj5wXamdoDP63aQGUG8kA10wU1IVSWmWygSVMVzWaNBjsH+ YFgr4S2GpqMAkve0NINXgo28gES3rVT5bVvOWj/uL5Zh6VCt3RXcwmPa+7ZfFYg= =Kli0 -----END PGP SIGNATURE----- From wk at gnupg.org Mon May 4 16:48:45 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 04 May 2015 16:48:45 +0200 Subject: excessive usage of /dev/random? In-Reply-To: (Peter Gutmann's message of "Sat, 02 May 2015 13:13:31 +1200") References: Message-ID: <87zj5kwg8i.fsf@vigenere.g10code.de> On Sat, 2 May 2015 03:13, pgut001 at cs.auckland.ac.nz said: > Yup. Now that doesn't mean don't use 2048 bits (or whatever) if it's > available, but you don't need 2048 bits of pure entropy, anything over... well > lets round it up to a nice 128 bits, should be OK. Libgcrypt (and GnuPG 1.4) RNG has always been pretty conservative given that the random numbers are the weakest part of our cryptography and the worst attscks we have seen are on the random numbers. I fact most real world attacks are based breaking the RNG, for example: There?s no evidence of a ?wow? cryptanalysis; it was key theft, or an implant, or a predicted RNG or supply-chain interference. [1] The attack model implemented in Libgcrypt might not be realistic, though: We keep state in a file and assume that for long term key generation the content of this file is not trustworthy. Thus we re-seed it with 2400 bits from our slow entropy gatherer (/dev/random on most platforms) and only the start to use it. Now for the actual key generation even this is not enough and the requested number of random bits are mixed into the pool again (again from /dev/random). If we don't trust that this file (random_seed) for long term keys why should we assume that reading /dev/random improves the situation. An attacker able to modify random_seed will also be able to find a local exploit and tamper with /dev/random. The only left reason will be a misbehaving backup/restore or syncing of ~/.gnupg/. Recipes on how to backup ~/.gnupg explicitly require not to restore random_seed. Thus the chance that this a an avenue for an attack is very small. And on top of everything we always re-seed our pool before extracting random for long term keys. For session keys we don't go into such length and only require a somehow filled pool. Having said this, I agree that a change is due. What about the attached change? Should this we done for master or also for stable (1.6)? Shalom-Salam, Werner p.s. Note that in my use the acronym CSPRNG stands for "Continuously Seeded PseudoRandom Number Generator" as used in Peter's implementation of the paper and not only for "Cryptographically Secure PseudoRandom Number Generator". [1] https://www.lightbluetouchpaper.org/2015/05/02/meeting-snowden-in-princeton/ -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-random-Change-initial-extra-seeding-from-2400-bits-t.patch Type: text/x-diff Size: 1081 bytes Desc: not available URL: From pgut001 at cs.auckland.ac.nz Tue May 5 13:43:50 2015 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Tue, 05 May 2015 23:43:50 +1200 Subject: excessive usage of /dev/random? In-Reply-To: <87zj5kwg8i.fsf@vigenere.g10code.de> Message-ID: Werner Koch writes: >Note that in my use the acronym CSPRNG stands for "Continuously Seeded >PseudoRandom Number Generator" as used in Peter's implementation of the paper >and not only for "Cryptographically Secure PseudoRandom Number Generator". I should note that the use of "Continuously Seeded" is due to Hugo Krawczyk, who pointed out that "Cryptographically Strong" isn't really appropriate since we don't have any provably cryptographically strong generators (well, you can argue about BBS I guess...), while "Continuously Seeded" more closely reflects the way it works. Peter. From rjh at sixdemonbag.org Tue May 5 15:51:00 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 05 May 2015 09:51:00 -0400 Subject: excessive usage of /dev/random? In-Reply-To: References: Message-ID: <5548CAC4.8010202@sixdemonbag.org> > we don't have any provably cryptographically strong generators (well, > you can argue about BBS I guess...) I thought BBS had a proof of security related to the difficulty of the quadratic residuosity problem. Given how close that is to IFP, BBS seems to be as secure as RSA, which is good enough for my purposes. ;) Or is there some new development related to BBS that I'm unaware of? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3744 bytes Desc: S/MIME Cryptographic Signature URL: From ben at adversary.org Tue May 5 21:09:53 2015 From: ben at adversary.org (Ben McGinnes) Date: Wed, 06 May 2015 05:09:53 +1000 Subject: Python 3 binding for GPGME Message-ID: <55491581.60001@adversary.org> Hello, There are now Python 3 bindings for GPGME in the lang/py3-pyme/ directory of that repository (actually, right now it's in a branch called pyme just in case something unexpected pops up). This is a port of PyME 0.9.0 to use Python 3.2 or above instead of the older Python 2 series, which is still maintained by Martin Albrecht. At least some of the changes made on this port will be backported to that original module too. PyME uses SWIG to automatically generate the relevant links between C and Python, enabling it to provide native Python functions for all of the GPGME features. Now I was able to test this port on my system (OS X 10.9.5, Python 3.4.3, SWIG 3.0.2 and whichever version of clang came with OS X 10.9 and the current version of Xcode) during the porting process, but there has been very little testing of it on other systems. So if any of you could grab that branch of the GPGME repo and confirm that it at least compiles and is able to be imported into Python 3 before the branch is merged with the master branch, that'd be great. The module will currently be built as pyme in the Python 3 site-packages directory on your system, so even though it shares the name with the original, it won't clash with an existing installation which will be in the Python 2 site-packages directory. At some point in the future this will likely be superceded by a Python 3 API implementation which takes advantage of more recent advances in the language. The aim being to both provide a native Python binding to GPGME (as currently provided with PyME) and to provide IO functions which may be leveraged by any other language which can connect to Python or which Python can connect to (i.e. pretty much all of them), but without needing to use operating system specific commands (which is what python-gnupg and its variants/forks do). This binding is released under the same licenses as the original PyME package and which were originally sourced from GPGME itself by John Goerzen in 2002. Those licenses are the GPL 2.0 and the LGPL 2.1, both with the "or any later version" clauses, though contributions would need to be provided under those same terms in order to maintain code sharing with the original PyME Martin is maintaining.. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Thu May 7 00:05:37 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 06 May 2015 18:05:37 -0400 Subject: python bindings for libassuan Message-ID: <87vbg5nyz2.fsf@alice.fifthhorseman.net> hey folks-- i've taken a first stab at writing python bindings for libassuan. If you're interested, you can look at them here: git clone git://lair.fifthhorseman.net/~dkg/python-assuan the current HEAD is 2a7557d1434bbfca4100ef63720d900320b8da8a It should build with the usual: setup.py build I've targeted Python 3, and haven't bothered to try to make it work on Python 2.x. Currently, the only supported workflow is an assuan client connection to a pre-existing socket. You can do something simple like this: ---------- #!/usr/bin/env python3 import assuan.gnupg dirmngr = assuan.gnupg.client('dirmngr') dirmngr.transact('KEYSERVER --hosttable') for line in dirmngr.status: print(line) ---------- See example.py at the top level of the repo for more details. I've been running this test script from my amd64 machine without having to install the new module like so: (cd build/lib.linux-x86_64-3.4 && python3) < example.py Feedback is welcome, as are other contributions (tuning the bindings for a server workflow would be particularly nice). I've licensed it LGPL-2.1+, since that matches most of libassuan. I could probably be convinced by reasonable arguments to select a different license, or to just give the bindings directly to the GnuPG project, if people want that. Let me know what you think, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From dkg at fifthhorseman.net Thu May 7 06:52:48 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 7 May 2015 00:52:48 -0400 Subject: [PATCH] clean up assuan documentation Message-ID: <1430974368-2605-1-git-send-email-dkg@fifthhorseman.net> * doc/assuan.texi: fix documentation -- Reading up on assuan to create python bindings uncovered a few bugs in the documentation. --- doc/assuan.texi | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/doc/assuan.texi b/doc/assuan.texi index b932be0..b7b8f3f 100644 --- a/doc/assuan.texi +++ b/doc/assuan.texi @@ -814,7 +814,7 @@ flags are usually 1 or 0 but certain flags might need other values. @deftp {Data type} assuan_flag_t The flags are all named and collected in an @code{enum} for better readability. -Currently only one flag is defined: +Available flags are: @table @code @item ASSUAN_NO_WAITPID @@ -1072,12 +1072,12 @@ If the peer is not a simple pipe server but one using full-duplex sockets, the full-fledged variant of the above function should be used: - at deftypefun gpg_error_t assuan_pipe_connect (@w{assuan_context_t *@var{ctx}}, at w{const char *@var{name}}, @w{const char *@var{argv}[]}, @w{assuan_fd_t *@var{fd_child_list}}, @w{void (*@var{atfork}) (void *, int)}, @w{void *@var{atforkvalue}}, @w{unsigned int @var{flags}}) + at deftypefun gpg_error_t assuan_pipe_connect (@w{assuan_context_t @var{ctx}}, at w{const char *@var{name}}, @w{const char *@var{argv}[]}, @w{assuan_fd_t *@var{fd_child_list}}, @w{void (*@var{atfork}) (void *, int)}, @w{void *@var{atforkvalue}}, @w{unsigned int @var{flags}}) A call to this functions forks the current process and executes the program @var{name}, passing the arguments given in the NULL-terminated list @var{argv}. A list of file descriptors not to be closed may be -given using the @code{ASSUAN_INVLID_FD} terminated array @var{fd_child_list}. +given using the @code{ASSUAN_INVALID_FD} terminated array @var{fd_child_list}. If @var{name} is a null pointer, only a fork but no exec is done. Thus the child continues to run. However all file descriptors are closed and @@ -1115,13 +1115,13 @@ server. On W32CE systems this flag is ignored. If you are using a long running server listening either on a TCP or a Unix domain socket, the following function is used to connect to the server: - at deftypefun gpg_error_t assuan_socket_connect (@w{assuan_context_t *@var{ctx}}, @w{const char *@var{name}}, @w{pid_t @var{server_pid}}, @w{unsigned int @var{flags}}) + at deftypefun gpg_error_t assuan_socket_connect (@w{assuan_context_t @var{ctx}}, @w{const char *@var{name}}, @w{pid_t @var{server_pid}}, @w{unsigned int @var{flags}}) -Make a connection to the Unix domain socket @var{name} and return a -new Assuan context at @var{ctx}. @var{server_pid} is currently not -used but may become handy in the future; if you don't know the -server's process ID (PID), pass @code{ASSUAN_INVALID_PID}. With - at var{flags} set to @code{ASSUAN_SOCKET_CONNECT_FDPASSIN}, +Make a connection to the Unix domain socket @var{name} using +already-initialized Assuan context at @var{ctx}. @var{server_pid} is +currently not used but may become handy in the future; if you don't +know the server's process ID (PID), pass @code{ASSUAN_INVALID_PID}. +With @var{flags} set to @code{ASSUAN_SOCKET_CONNECT_FDPASSING}, @code{sendmsg} and @code{recvmesg} are used for input and output and thereby enable the use of descriptor passing. -- 2.1.4 From neal at walfield.org Thu May 7 14:56:23 2015 From: neal at walfield.org (Neal H. Walfield) Date: Thu, 07 May 2015 14:56:23 +0200 Subject: [PATCH] clean up assuan documentation In-Reply-To: <1430974368-2605-1-git-send-email-dkg@fifthhorseman.net> References: <1430974368-2605-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <87d22ceebs.wl-neal@walfield.org> Hi Daniel, Thanks! I've applied these changes. :) Neal At Thu, 7 May 2015 00:52:48 -0400, Daniel Kahn Gillmor wrote: > > * doc/assuan.texi: fix documentation > > -- > > Reading up on assuan to create python bindings uncovered a few bugs in > the documentation. > --- > doc/assuan.texi | 18 +++++++++--------- > 1 file changed, 9 insertions(+), 9 deletions(-) > > diff --git a/doc/assuan.texi b/doc/assuan.texi > index b932be0..b7b8f3f 100644 > --- a/doc/assuan.texi > +++ b/doc/assuan.texi > @@ -814,7 +814,7 @@ flags are usually 1 or 0 but certain flags might need other values. > > @deftp {Data type} assuan_flag_t > The flags are all named and collected in an @code{enum} for better readability. > -Currently only one flag is defined: > +Available flags are: > > @table @code > @item ASSUAN_NO_WAITPID > @@ -1072,12 +1072,12 @@ If the peer is not a simple pipe server but one using full-duplex > sockets, the full-fledged variant of the above function should be > used: > > - at deftypefun gpg_error_t assuan_pipe_connect (@w{assuan_context_t *@var{ctx}}, at w{const char *@var{name}}, @w{const char *@var{argv}[]}, @w{assuan_fd_t *@var{fd_child_list}}, @w{void (*@var{atfork}) (void *, int)}, @w{void *@var{atforkvalue}}, @w{unsigned int @var{flags}}) > + at deftypefun gpg_error_t assuan_pipe_connect (@w{assuan_context_t @var{ctx}}, at w{const char *@var{name}}, @w{const char *@var{argv}[]}, @w{assuan_fd_t *@var{fd_child_list}}, @w{void (*@var{atfork}) (void *, int)}, @w{void *@var{atforkvalue}}, @w{unsigned int @var{flags}}) > > A call to this functions forks the current process and executes the > program @var{name}, passing the arguments given in the NULL-terminated > list @var{argv}. A list of file descriptors not to be closed may be > -given using the @code{ASSUAN_INVLID_FD} terminated array @var{fd_child_list}. > +given using the @code{ASSUAN_INVALID_FD} terminated array @var{fd_child_list}. > > If @var{name} is a null pointer, only a fork but no exec is done. Thus > the child continues to run. However all file descriptors are closed and > @@ -1115,13 +1115,13 @@ server. On W32CE systems this flag is ignored. > If you are using a long running server listening either on a TCP or a > Unix domain socket, the following function is used to connect to the server: > > - at deftypefun gpg_error_t assuan_socket_connect (@w{assuan_context_t *@var{ctx}}, @w{const char *@var{name}}, @w{pid_t @var{server_pid}}, @w{unsigned int @var{flags}}) > + at deftypefun gpg_error_t assuan_socket_connect (@w{assuan_context_t @var{ctx}}, @w{const char *@var{name}}, @w{pid_t @var{server_pid}}, @w{unsigned int @var{flags}}) > > -Make a connection to the Unix domain socket @var{name} and return a > -new Assuan context at @var{ctx}. @var{server_pid} is currently not > -used but may become handy in the future; if you don't know the > -server's process ID (PID), pass @code{ASSUAN_INVALID_PID}. With > - at var{flags} set to @code{ASSUAN_SOCKET_CONNECT_FDPASSIN}, > +Make a connection to the Unix domain socket @var{name} using > +already-initialized Assuan context at @var{ctx}. @var{server_pid} is > +currently not used but may become handy in the future; if you don't > +know the server's process ID (PID), pass @code{ASSUAN_INVALID_PID}. > +With @var{flags} set to @code{ASSUAN_SOCKET_CONNECT_FDPASSING}, > @code{sendmsg} and @code{recvmesg} are used for input and output and > thereby enable the use of descriptor passing. > > -- > 2.1.4 > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > From neal at walfield.org Thu May 7 15:02:34 2015 From: neal at walfield.org (Neal H. Walfield) Date: Thu, 07 May 2015 15:02:34 +0200 Subject: [PATCH] dirmngr: Fix segfault in ldap engine In-Reply-To: <5529AE5F.7010109@sumptuouscapital.com> References: <5529AE5F.7010109@sumptuouscapital.com> Message-ID: <87bnhwee1h.wl-neal@walfield.org> At Sun, 12 Apr 2015 01:29:35 +0200, Kristian Fiskerstrand wrote: > > dirmngr: keyserver --help results in segfault, backtrace on [0]. Patch > attached: > > (ks-engine-ldap.c) Fix segfault caused by missing check whether uri is > initialized I've applied your patch, thanks! > Additionally two issues with LDAP support: > (i) --refresh-keys is not implemented , so can't do gpg --keyserver > ldap://keys.domain --refresh-keys @domain > gpg: keyserver refresh failed: Not supported I've created a bug report for this issue: https://bugs.gnupg.org/gnupg/issue1971 > (ii) No warning is printed if returned list is truncated. 2.0 gives a > gpgkeys: search results exceeded server limit. First 2 results shown. > 2.1 just prints the two records returned with no warning. I've created a bug report for this issue: https://bugs.gnupg.org/gnupg/issue1972 Thanks! Neal From wk at gnupg.org Thu May 7 18:40:14 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 May 2015 18:40:14 +0200 Subject: pinentry hide/show button Message-ID: <87zj5gs5n5.fsf@vigenere.g10code.de> Hi! For long passphrases and if you are anyway working out of sight of cameras it is convenient to actually see what you are typing. Thus a hide/show button for password entries is desirable. What do you think of a toggle button to the right of the entry field? The patch below implements this for the GTK pinentry. It does not actually work but I would like to get an opinion on the behaviour: ("***" = hidden, "abc" - visible). https://wiki.gnupg.org/ScratchWK or https://gnupg.org/scratch/pinentry-hidden.png https://gnupg.org/scratch/pinentry-reveal.png Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-gtk-Add-a-button-to-show-hide-the-passphrase.patch Type: text/x-diff Size: 3546 bytes Desc: not available URL: From neal at walfield.org Thu May 7 20:13:00 2015 From: neal at walfield.org (Neal H. Walfield) Date: Thu, 07 May 2015 20:13:00 +0200 Subject: pinentry hide/show button In-Reply-To: <87zj5gs5n5.fsf@vigenere.g10code.de> References: <87zj5gs5n5.fsf@vigenere.g10code.de> Message-ID: <87a8xgdzo3.wl-neal@walfield.org> At Thu, 07 May 2015 18:40:14 +0200, Werner Koch wrote: > For long passphrases and if you are anyway working out of sight of > cameras it is convenient to actually see what you are typing. Thus a > hide/show button for password entries is desirable. What do you think > of a toggle button to the right of the entry field? > > The patch below implements this for the GTK pinentry. It does not > actually work but I would like to get an opinion on the behaviour: > ("***" = hidden, "abc" - visible). > > https://wiki.gnupg.org/ScratchWK > > or > > https://gnupg.org/scratch/pinentry-hidden.png > https://gnupg.org/scratch/pinentry-reveal.png This should be: https://gnupg.org/scratch/pinentry-revealed.png ^^ I think the icons are backwards. The ***s should be shown when the password is revealed and abc should be shown when the password is hidden. (I.e., the button should show you what you get when you click.) I think it is important that the button not be in the tabbing order to prevent accidentally selecting it. Alternatively or in addition, it might make sense to pop up a dialog asking the user if she really wants to reveal her password. Neal From wk at gnupg.org Thu May 7 20:43:35 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 May 2015 20:43:35 +0200 Subject: pinentry hide/show button In-Reply-To: <87a8xgdzo3.wl-neal@walfield.org> (Neal H. Walfield's message of "Thu, 07 May 2015 20:13:00 +0200") References: <87zj5gs5n5.fsf@vigenere.g10code.de> <87a8xgdzo3.wl-neal@walfield.org> Message-ID: <87twvorzxk.fsf@vigenere.g10code.de> On Thu, 7 May 2015 20:13, neal at walfield.org said: > I think the icons are backwards. The ***s should be shown when the > password is revealed and abc should be shown when the password is Okay. I was not sure. The asterisks indicate that they will be displayed in the entry but I agree that this is a reverse logic. The gtk_switch might be a better widget here but it is only available in newer GTk versions and it requires a lot more space. > I think it is important that the button not be in the tabbing order to > prevent accidentally selecting it. I was thinking about this too. It could be put before the entry in the tabbing order but that would be a strange experience for the user. Only allowing to use it with the mouse is also not the best idea for accesibility. Thus we need an accelerator key - but which one? We can als add an option to gpg-agent to unhide the passphrase by default. > Alternatively or in addition, it might make sense to pop up a dialog > asking the user if she really wants to reveal her password. That would be annoying. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Thu May 7 20:53:20 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 07 May 2015 14:53:20 -0400 Subject: pinentry hide/show button In-Reply-To: <87a8xgdzo3.wl-neal@walfield.org> References: <87zj5gs5n5.fsf@vigenere.g10code.de> <87a8xgdzo3.wl-neal@walfield.org> Message-ID: <876184nrrz.fsf@alice.fifthhorseman.net> On Thu 2015-05-07 14:13:00 -0400, Neal H. Walfield wrote: > At Thu, 07 May 2015 18:40:14 +0200, Werner Koch wrote: >> For long passphrases and if you are anyway working out of sight of >> cameras it is convenient to actually see what you are typing. Thus a >> hide/show button for password entries is desirable. What do you think >> of a toggle button to the right of the entry field? >> >> The patch below implements this for the GTK pinentry. It does not >> actually work but I would like to get an opinion on the behaviour: >> ("***" = hidden, "abc" - visible). >> >> https://wiki.gnupg.org/ScratchWK >> >> or >> >> https://gnupg.org/scratch/pinentry-hidden.png >> https://gnupg.org/scratch/pinentry-reveal.png > > This should be: > > https://gnupg.org/scratch/pinentry-revealed.png > ^^ > > I think the icons are backwards. The ***s should be shown when the > password is revealed and abc should be shown when the password is > hidden. (I.e., the button should show you what you get when you > click.) In other dialog boxes (e.g. whatever displays the dialog box for wifi passwords on a GNOME installation) it is displayed as a checkbox immediately under the password field titled "show password" or something: +====================================================+ | | | Enter password: [______________________________] | | [ ] show password | | | | [ OK ] [ Cancel ] | +----------------------------------------------------+ > I think it is important that the button not be in the tabbing order to > prevent accidentally selecting it. I have mixed feelings about this. If it's not in the tabbing order, how do i select it without a mouse? Can we guarantee an accelerator key? > Alternatively or in addition, it might make sense to pop up a dialog > asking the user if she really wants to reveal her password. a dialog going from hide->show sounds vaguely acceptable (though a little bit annoying). please don't do a dialog in the show->hide direction, of course! --dkg From neal at walfield.org Thu May 7 20:59:25 2015 From: neal at walfield.org (Neal H. Walfield) Date: Thu, 07 May 2015 20:59:25 +0200 Subject: pinentry hide/show button In-Reply-To: <87twvorzxk.fsf@vigenere.g10code.de> References: <87zj5gs5n5.fsf@vigenere.g10code.de> <87a8xgdzo3.wl-neal@walfield.org> <87twvorzxk.fsf@vigenere.g10code.de> Message-ID: <874mnodxiq.wl-neal@walfield.org> At Thu, 07 May 2015 20:43:35 +0200, Werner Koch wrote: > On Thu, 7 May 2015 20:13, neal at walfield.org said: > > I think it is important that the button not be in the tabbing order to > > prevent accidentally selecting it. > > I was thinking about this too. It could be put before the entry in the > tabbing order but that would be a strange experience for the user. Only > allowing to use it with the mouse is also not the best idea for > accesibility. Thus we need an accelerator key - but which one? > > We can als add an option to gpg-agent to unhide the passphrase by > default. > > > Alternatively or in addition, it might make sense to pop up a dialog > > asking the user if she really wants to reveal her password. > > That would be annoying. It would also be annoying to show your passphrase on camera. This is probably better than removing the widget from the tab order. And, as Daniel said, this is only needed when going from hide to reveal. Neal From dkg at fifthhorseman.net Thu May 7 21:18:22 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 07 May 2015 15:18:22 -0400 Subject: puts ("- gpg control packet") Message-ID: <87wq0kmc1t.fsf@alice.fifthhorseman.net> I just noticed that g10/parse-packet.c contains a single call to puts() that seems pretty out of place: de5070ca (Werner Koch 2006-07-27 14:18:55 +0000 2906) goto skipit; /* Definitely too large. We skip it to avoid an de5070ca (Werner Koch 2006-07-27 14:18:55 +0000 2907) overflow in the malloc. */ 72503314 (Repo Admin 2003-06-05 07:14:21 +0000 2908) if (list_mode) 72503314 (Repo Admin 2003-06-05 07:14:21 +0000 2909) puts ("- gpg control packet"); 72503314 (Repo Admin 2003-06-05 07:14:21 +0000 2910) c0c2c580 (Werner Koch 2003-06-18 19:56:13 +0000 2911) packet->pkt.gpg_control = xmalloc (sizeof *packet->pkt.gpg_control 72503314 (Repo Admin 2003-06-05 07:14:21 +0000 2912) + pktlen - 1); the git blame output above makes it look like it was introduced during the branch to 1.9 -- maybe it goes back a long way. is there a reason this is here? it sends this line of data to stdout when i run "gpg -vvvvvv --verify" on a clearsigned message, which is potentially confusing to processes which are looking for anything in stdout. --dkg From dkg at fifthhorseman.net Thu May 7 21:25:33 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 07 May 2015 15:25:33 -0400 Subject: gpg --check-trustdb returns data on stdout when --verbose --verbose is present? Message-ID: <87twvombpu.fsf@alice.fifthhorseman.net> gpg --check-trustdb normally sends no data to stdout, even if --verbose is specfieid once. however, when i add --verbose --verbose it sends a lot of data to stdout, in particular, lines like this: 0:F2AD85AC1E42B367:U:::f:::Werner Koch : [...] I believe this also happens when the trustdb is automatically checked (though i'm not sure how to force that to happen to test it better). sending additional data to stdout during an automatic check (or even during --check-trustdb when it's not otherwise expected) seems problematic for anyone using the tool programmatically. --dkg From wk at gnupg.org Thu May 7 21:23:55 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 May 2015 21:23:55 +0200 Subject: pinentry hide/show button In-Reply-To: <876184nrrz.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 07 May 2015 14:53:20 -0400") References: <87zj5gs5n5.fsf@vigenere.g10code.de> <87a8xgdzo3.wl-neal@walfield.org> <876184nrrz.fsf@alice.fifthhorseman.net> Message-ID: <87oalwry2c.fsf@vigenere.g10code.de> On Thu, 7 May 2015 20:53, dkg at fifthhorseman.net said: > In other dialog boxes (e.g. whatever displays the dialog box for wifi > passwords on a GNOME installation) it is displayed as a checkbox > immediately under the password field titled "show password" or I have installed several tools and did a bit of web search. A button without a label next to the entry field is quite common and has the advantage that it is small and does not need translation (except for the tooltips). > I have mixed feelings about this. If it's not in the tabbing order, how > do i select it without a mouse? Can we guarantee an accelerator key? I am not sure. >> Alternatively or in addition, it might make sense to pop up a dialog >> asking the user if she really wants to reveal her password. > > a dialog going from hide->show sounds vaguely acceptable (though a > little bit annoying). please don't do a dialog in the show->hide What about showing a warning dialog only if more than one character has been entered? Or any character? Of course not from show->hide. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Thu May 7 21:46:44 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 07 May 2015 15:46:44 -0400 Subject: pinentry hide/show button In-Reply-To: <87oalwry2c.fsf@vigenere.g10code.de> References: <87zj5gs5n5.fsf@vigenere.g10code.de> <87a8xgdzo3.wl-neal@walfield.org> <876184nrrz.fsf@alice.fifthhorseman.net> <87oalwry2c.fsf@vigenere.g10code.de> Message-ID: <87mw1gmaqj.fsf@alice.fifthhorseman.net> On Thu 2015-05-07 15:23:55 -0400, Werner Koch wrote: > On Thu, 7 May 2015 20:53, dkg at fifthhorseman.net said: > >> In other dialog boxes (e.g. whatever displays the dialog box for wifi >> passwords on a GNOME installation) it is displayed as a checkbox >> immediately under the password field titled "show password" or > > I have installed several tools and did a bit of web search. A button > without a label next to the entry field is quite common and has the > advantage that it is small and does not need translation (except for the > tooltips). > >> I have mixed feelings about this. If it's not in the tabbing order, how >> do i select it without a mouse? Can we guarantee an accelerator key? > > I am not sure. > >>> Alternatively or in addition, it might make sense to pop up a dialog >>> asking the user if she really wants to reveal her password. >> >> a dialog going from hide->show sounds vaguely acceptable (though a >> little bit annoying). please don't do a dialog in the show->hide > > What about showing a warning dialog only if more than one character has > been entered? Or any character? Of course not from show->hide. I like this compromise. It helps to avoid catching the "type passphrase, tab, enter" workflow, which people might be accustomed to. It's also conceivable that we could just *move* the button in the tabbing order, to after "cancel", so the tabbing order would go: passphrase_entry OK_button Cancel_button show_password_toggle That wouldn't be too difficult to use (you'd find it pretty easily in a tab-cycle search, and you could shift-tab to it once you knew it was set up that way), and it also helps avoid a bad outcome for folks with the workflow i described above, while still leaving things accessible without a mouse or an accelerator key. --dkg From wk at gnupg.org Thu May 7 22:09:56 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 May 2015 22:09:56 +0200 Subject: pinentry hide/show button In-Reply-To: <87mw1gmaqj.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 07 May 2015 15:46:44 -0400") References: <87zj5gs5n5.fsf@vigenere.g10code.de> <87a8xgdzo3.wl-neal@walfield.org> <876184nrrz.fsf@alice.fifthhorseman.net> <87oalwry2c.fsf@vigenere.g10code.de> <87mw1gmaqj.fsf@alice.fifthhorseman.net> Message-ID: <87ioc4rvxn.fsf@vigenere.g10code.de> On Thu, 7 May 2015 21:46, dkg at fifthhorseman.net said: > I like this compromise. It helps to avoid catching the "type > passphrase, tab, enter" workflow, which people might be accustomed to. There is a new screenshot with the warning dialog at https://wiki.gnupg.org/ScratchWK Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From neal at walfield.org Thu May 7 22:13:47 2015 From: neal at walfield.org (Neal H. Walfield) Date: Thu, 07 May 2015 22:13:47 +0200 Subject: pinentry hide/show button In-Reply-To: <87ioc4rvxn.fsf@vigenere.g10code.de> References: <87zj5gs5n5.fsf@vigenere.g10code.de> <87a8xgdzo3.wl-neal@walfield.org> <876184nrrz.fsf@alice.fifthhorseman.net> <87oalwry2c.fsf@vigenere.g10code.de> <87mw1gmaqj.fsf@alice.fifthhorseman.net> <87ioc4rvxn.fsf@vigenere.g10code.de> Message-ID: <873838du2s.wl-neal@walfield.org> At Thu, 07 May 2015 22:09:56 +0200, Werner Koch wrote: > > On Thu, 7 May 2015 21:46, dkg at fifthhorseman.net said: > > > I like this compromise. It helps to avoid catching the "type > > passphrase, tab, enter" workflow, which people might be accustomed to. > > There is a new screenshot with the warning dialog at > > https://wiki.gnupg.org/ScratchWK This looks quite good, I think. Neal From dkg at fifthhorseman.net Thu May 7 22:29:28 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 07 May 2015 16:29:28 -0400 Subject: pinentry hide/show button In-Reply-To: <873838du2s.wl-neal@walfield.org> References: <87zj5gs5n5.fsf@vigenere.g10code.de> <87a8xgdzo3.wl-neal@walfield.org> <876184nrrz.fsf@alice.fifthhorseman.net> <87oalwry2c.fsf@vigenere.g10code.de> <87mw1gmaqj.fsf@alice.fifthhorseman.net> <87ioc4rvxn.fsf@vigenere.g10code.de> <873838du2s.wl-neal@walfield.org> Message-ID: <87h9rom8rb.fsf@alice.fifthhorseman.net> On Thu 2015-05-07 16:13:47 -0400, Neal H. Walfield wrote: > At Thu, 07 May 2015 22:09:56 +0200, > Werner Koch wrote: >> >> On Thu, 7 May 2015 21:46, dkg at fifthhorseman.net said: >> >> > I like this compromise. It helps to avoid catching the "type >> > passphrase, tab, enter" workflow, which people might be accustomed to. >> >> There is a new screenshot with the warning dialog at >> >> https://wiki.gnupg.org/ScratchWK > > This looks quite good, I think. Agreed, though i think the choice of image on the button is backward. if "abc" is visible, it should mean "show password" and "***" is visible, it should mean "hide password". --dkg From gniibe at fsij.org Fri May 8 04:26:06 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 08 May 2015 11:26:06 +0900 Subject: [PATCH] g10: detects public key encryption packet error properly Message-ID: <554C1EBE.7050401@fsij.org> Hello, I come up to this fix while looking the bug report: https://bugs.debian.org/638619 The detection of public key encryption packet error should be done earlier in mainproc.c. I think that in gpg14/gpg20 we had the line: || enc->pubkey_algo == PUBKEY_ALGO_DSA and simply it was extended it to ECDSA and EDDSA, but those algorithms are irrelevant for encryption. diff --git a/g10/mainproc.c b/g10/mainproc.c index e72d076..c90b9e3 100644 --- a/g10/mainproc.c +++ b/g10/mainproc.c @@ -406,12 +406,10 @@ proc_pubkey_enc (CTX c, PACKET *pkt) c->dek = NULL; } } - else if (is_ELGAMAL(enc->pubkey_algo) - || enc->pubkey_algo == PUBKEY_ALGO_DSA - || enc->pubkey_algo == PUBKEY_ALGO_ECDSA - || enc->pubkey_algo == PUBKEY_ALGO_EDDSA + else if (enc->pubkey_algo == PUBKEY_ALGO_ELGAMAL_E || enc->pubkey_algo == PUBKEY_ALGO_ECDH - || is_RSA (enc->pubkey_algo) + || enc->pubkey_algo == PUBKEY_ALGO_RSA + || enc->pubkey_algo == PUBKEY_ALGO_RSA_E || enc->pubkey_algo == PUBKEY_ALGO_ELGAMAL) { /* Note that we also allow type 20 Elgamal keys for decryption. -- From gniibe at fsij.org Fri May 8 04:33:56 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 08 May 2015 11:33:56 +0900 Subject: gpg-agent features of loopback-pinentry mode, preset_passphrase Message-ID: <554C2094.20904@fsij.org> Hello, While trying fix the issue 1928: https://bugs.gnupg.org/gnupg/issue1928 With GnuPG 2.1, the secret keys are under control of gpg-agent. Invoking gpg with --passphrase (-file, -fd), the gpg frontend needs to supply passphrase to gpg-agent. I think that the feature of loopback-pinentry mode and/or preset_passphrase could be used for that. However, those features are disabled as defaults. Are there any reason those feature could be disabled? I think that loopback-pinentry mode should be always supported so that --passphrase option of gpg can work well. -- From dkg at fifthhorseman.net Fri May 8 04:54:28 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 07 May 2015 22:54:28 -0400 Subject: gpg-agent features of loopback-pinentry mode, preset_passphrase In-Reply-To: <554C2094.20904@fsij.org> References: <554C2094.20904@fsij.org> Message-ID: <874mnnlqxn.fsf@alice.fifthhorseman.net> On Thu 2015-05-07 22:33:56 -0400, NIIBE Yutaka wrote: > With GnuPG 2.1, the secret keys are under control of gpg-agent. > > Invoking gpg with --passphrase (-file, -fd), the gpg frontend needs to > supply passphrase to gpg-agent. I think that the feature of > loopback-pinentry mode and/or preset_passphrase could be used for > that. > > However, those features are disabled as defaults. Are there any > reason those feature could be disabled? > > I think that loopback-pinentry mode should be always supported so that > --passphrase option of gpg can work well. I think this depends on what the main purpose of gpg-agent is. Here's one proposed purpose for gpg-agent: * prevent the use of secret key material without the user's knowledge, even to a process with access to the gpg-agent's socket (note that the --extra-socket section of gpg-agent(1) implies that gpg-agent is aware of use cases where the agent's socket is extended to machines that are not otherwise considered trustworthy). If this is the goal, then loopback pinentry is a problem, because an attacker with access to the gpg-agent socket can run a passphrase-guessing attack without any visibility to the user. --dkg From gniibe at fsij.org Fri May 8 05:42:23 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 08 May 2015 12:42:23 +0900 Subject: gpg-agent features of loopback-pinentry mode, preset_passphrase In-Reply-To: <874mnnlqxn.fsf@alice.fifthhorseman.net> References: <554C2094.20904@fsij.org> <874mnnlqxn.fsf@alice.fifthhorseman.net> Message-ID: <554C309F.5010706@fsij.org> On 05/08/2015 11:54 AM, Daniel Kahn Gillmor wrote: > If this is the goal, then loopback pinentry is a problem, because an > attacker with access to the gpg-agent socket can run a > passphrase-guessing attack without any visibility to the user. Thank you for pointing out this. Now, I understand cases of disabling loopback-pinentry mode (and preset_passphrase), and the reason why it's disabled by defaults. Indeed, there is a case where we forward gpg-agent's socket. Well, given this condition, then, we need better diagnostic message to user, when --passphrase doesn't work well. My idea is like: When --passphrase option is offered, gpg checks gpg-agent feature availability (before reading passphrase from file/fd), and gives explanation if not. And gpg/gpg-agent manual should address the relationship of --passphrase and loopback-pinentry mode. -- From wk at gnupg.org Fri May 8 08:32:47 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 08 May 2015 08:32:47 +0200 Subject: pinentry hide/show button In-Reply-To: <87h9rom8rb.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 07 May 2015 16:29:28 -0400") References: <87zj5gs5n5.fsf@vigenere.g10code.de> <87a8xgdzo3.wl-neal@walfield.org> <876184nrrz.fsf@alice.fifthhorseman.net> <87oalwry2c.fsf@vigenere.g10code.de> <87mw1gmaqj.fsf@alice.fifthhorseman.net> <87ioc4rvxn.fsf@vigenere.g10code.de> <873838du2s.wl-neal@walfield.org> <87h9rom8rb.fsf@alice.fifthhorseman.net> Message-ID: <87a8xfsho0.fsf@vigenere.g10code.de> On Thu, 7 May 2015 22:29, dkg at fifthhorseman.net said: > Agreed, though i think the choice of image on the button is backward. > if "abc" is visible, it should mean "show password" and "***" is > visible, it should mean "hide password". Right. I already changed that for the last screenshot. I did not changed the first two screenshots, though. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ben at adversary.org Fri May 8 15:29:04 2015 From: ben at adversary.org (Ben McGinnes) Date: Fri, 08 May 2015 23:29:04 +1000 Subject: python bindings for libassuan In-Reply-To: <87vbg5nyz2.fsf@alice.fifthhorseman.net> References: <87vbg5nyz2.fsf@alice.fifthhorseman.net> Message-ID: <554CBA20.1070307@adversary.org> On 7/05/2015 8:05 am, Daniel Kahn Gillmor wrote: > hey folks-- > > i've taken a first stab at writing python bindings for libassuan. If > you're interested, you can look at them here: > > git clone git://lair.fifthhorseman.net/~dkg/python-assuan Excellent, I'll definitely take a peek at that. Did you opt for ctypes, the plain Python C-API or one of the other solutions? > I've targeted Python 3, and haven't bothered to try to make it work on > Python 2.x. As long as it doesn't get too complex you can probably get Python 2.7 covered by including the UTF-8 encoding near the top of each file and including "from __future__ import unicode_literals". > Feedback is welcome, as are other contributions (tuning the bindings > for a server workflow would be particularly nice). I've licensed it > LGPL-2.1+, since that matches most of libassuan. I could probably > be convinced by reasonable arguments to select a different license, > or to just give the bindings directly to the GnuPG project, if > people want that. LGPL 2.1+ is good, we want people to switch to things like this or GPGME. If it is not provided with a permissive enough license then people will continue to use python-gnupg with its subprocess calls to the gpg binary. Do you really want that? Didn't think so. ;) Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Fri May 8 16:20:49 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 08 May 2015 16:20:49 +0200 Subject: puts ("- gpg control packet") In-Reply-To: <87wq0kmc1t.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 07 May 2015 15:18:22 -0400") References: <87wq0kmc1t.fsf@alice.fifthhorseman.net> Message-ID: <87twvnqhfi.fsf@vigenere.g10code.de> On Thu, 7 May 2015 21:18, dkg at fifthhorseman.net said: > the git blame output above makes it look like it was introduced during > the branch to 1.9 -- maybe it goes back a long way. is there a reason > this is here? Fixed in master: gpg: Fix wrong output in list mode. * g10/parse-packet.c (parse_gpg_control): Replace puts by es_fputs to LISTFP. -- Reported-by: Daniel Kahn Gillmor This was an oversight from the conversion to estream or a separate listing stream. Signed-off-by: Werner Koch Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Fri May 8 16:56:32 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 08 May 2015 10:56:32 -0400 Subject: python bindings for libassuan In-Reply-To: <554CBA20.1070307@adversary.org> References: <87vbg5nyz2.fsf@alice.fifthhorseman.net> <554CBA20.1070307@adversary.org> Message-ID: <87oalvjexr.fsf@alice.fifthhorseman.net> On Fri 2015-05-08 09:29:04 -0400, Ben McGinnes wrote: > Excellent, I'll definitely take a peek at that. Did you opt for > ctypes, the plain Python C-API or one of the other solutions? The plain Python C-API. I tend to find ctypes mappings not very pythonic, especially for libraries with interesting/complex C workflows like libassuan. For example, ctypes for the assuan_transact(), with its C function pointers and void* would be deeply weird in python (or at least i couldn't figure out how to make that seem sensible). Instead, I made a python object assuan.context, which has python methods which get called during a transaction. >> I've targeted Python 3, and haven't bothered to try to make it work on >> Python 2.x. > > As long as it doesn't get too complex you can probably get Python 2.7 > covered by including the UTF-8 encoding near the top of each file and > including "from __future__ import unicode_literals". Ah, i'm less concerned about the pure-python parts of it than the C-API, which i think might have changed incompatibly between 2 and 3 (so i don't want to uglify-up the C code with a ton of nasty #ifdefs -- but if someone sends clean-ish patches to make it compile correctly against python2, though, i would definitely accept them. > LGPL 2.1+ is good, we want people to switch to things like this or > GPGME. If it is not provided with a permissive enough license then > people will continue to use python-gnupg with its subprocess calls to > the gpg binary. Do you really want that? Well, for gpg, it's all doing subprocess calls to the gpg binary somehow, whether that's managed through gpgme or in python directly :/ Please let me know what you think after taking a look at it! Hopefully gnupg-devel is an OK place for this discussion for now. --dkg From ben at adversary.org Fri May 8 20:57:48 2015 From: ben at adversary.org (Ben McGinnes) Date: Sat, 09 May 2015 04:57:48 +1000 Subject: python bindings for libassuan In-Reply-To: <87oalvjexr.fsf@alice.fifthhorseman.net> References: <87vbg5nyz2.fsf@alice.fifthhorseman.net> <554CBA20.1070307@adversary.org> <87oalvjexr.fsf@alice.fifthhorseman.net> Message-ID: <554D072C.8030100@adversary.org> On 9/05/2015 12:56 am, Daniel Kahn Gillmor wrote: > On Fri 2015-05-08 09:29:04 -0400, Ben McGinnes wrote: > >> Excellent, I'll definitely take a peek at that. Did you opt for >> ctypes, the plain Python C-API or one of the other solutions? > > The plain Python C-API. I tend to find ctypes mappings not very > pythonic, especially for libraries with interesting/complex C workflows > like libassuan. Yeah, ctypes seem okay for small, relatively constrained things and can easily break. The VideoLAN project uses them for the python bondings in libvlc and vlc.py, which all looked great until they released 2.2 and it keeled over. > For example, ctypes for the assuan_transact(), with its C function > pointers and void* would be deeply weird in python (or at least i > couldn't figure out how to make that seem sensible). Instead, I made a > python object assuan.context, which has python methods which get called > during a transaction. Right, and None might do it, maybe. If not, then what? Defining void? Just thinking about trying something like that makes my head throb. From the gpgme side of things, in spite of the weekend's effort with porting PyME, it's pretty clear that that's more a stop-gap measure than a long term solution. It'll do for now, of course, but I think people expect a little more from APIs these days than they did a decade and a half ago. I strongly suspect that wiping the slate clean and writing a "proper" Python driven API, as Werner suggested, would've had to be done anyway. Doing all that as C-API modules, however, is a ridiculously mammoth undertaking, so in that case something which lends itself a little more towards a reasonable development timeframe is far more likely. The two options currently under consideration are Cython and CFFI, even though neither are part of the standard library. With CFFI it would necessitate non-standard requirements, while Cython has its own fusion of C and Python for its code; CFFI can be written entirely in Python and will even work with PyPY, while Cython will generate C with which to take the gpgme libs and make the relevant CPython modules (Cython would only need to be installed by people developing the API/bindings, not by every end user). Both have their advantages, of course, and both lend themselves to aiding a developer whose Python is pretty good, but whose work with C tends more towards troubleshooting kernels rather than actually writing anything with it (mostly). Anyway, there's other overhauling to be done in gpgme, so I can continue to evaluate all the contenders and plan ahead in that time. Although SWIG is already out; that's what PyME uses currently and while it was the only real option for a long time, there are better options available now. >>> I've targeted Python 3, and haven't bothered to try to make it work on >>> Python 2.x. >> >> As long as it doesn't get too complex you can probably get Python 2.7 >> covered by including the UTF-8 encoding near the top of each file and >> including "from __future__ import unicode_literals". > > Ah, i'm less concerned about the pure-python parts of it than the C-API, > which i think might have changed incompatibly between 2 and 3 (so i > don't want to uglify-up the C code with a ton of nasty #ifdefs -- At this point I think Python should be well on the way to getting most people away from 2.7 and really leaving it just to those few legacy deployments that can't shift for whatever reason. The rest of us can enjoy the 21st century. > but if someone sends clean-ish patches to make it compile correctly > against python2, though, i would definitely accept them. Well, of course, presumably someone in legacy land will do that eventually. Either that or they'll remember the python is a brilliant glue language and get their python 2 things to interact with the python 3 bits. > Well, for gpg, it's all doing subprocess calls to the gpg binary > somehow, whether that's managed through gpgme or in python directly :/ Yes, but only one of these two is more likely to give someone shell access if that was not the intent. > Please let me know what you think after taking a look at it! Hopefully > gnupg-devel is an OK place for this discussion for now. I can't think of anywhere better. So I think we're good, and threads are easy enough to ignore or mark as read. I also have your first patch for you if there's somewhere I can push it to. It's not much, just a more pythonic way of specifying the homedir in assuan/gnupg.py. The relevant bits are attached. Regards, Ben -------------- next part -------------- commit 9bdbee54fbfa08f795e62b15adc9944b55ade7be Author: Ben McGinnes Date: Sat May 9 03:53:47 2015 +1000 Pythonic homedir * Narrowed os.path import. * Replaced getenv calls and $HOME with os.path.expanduser(). * Added generic (not guaranteed to work) homedir for Windows. commit 2a7557d1434bbfca4100ef63720d900320b8da8a Author: Daniel Kahn Gillmor Date: Wed May 6 17:51:46 2015 -0400 prettify the example and the comments further -------------- next part -------------- diff --git a/assuan/gnupg.py b/assuan/gnupg.py index 14328af..026e904 100644 --- a/assuan/gnupg.py +++ b/assuan/gnupg.py @@ -2,17 +2,19 @@ '''Use assuan to talk to typical GnuPG services''' -import os +import os.path +import sys import assuan def sockpath(servicename, homedir=None): '''Given the name of a standard GnuPG daemon, guess its default socket path''' if (homedir is None): - homedir = os.path.join(os.getenv('GNUPGHOME', - os.path.join(os.getenv('HOME', '.'), - '.gnupg'))) - + home = os.path.expanduser('~') + if sys.platform == 'win32': + homedir = os.path.join(home, '/', '_gnupg') + else: + homedir = os.path.join(home, '/', '.gnupg') return os.path.join(homedir, "S." + servicename) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Fri May 8 21:25:38 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 08 May 2015 15:25:38 -0400 Subject: python bindings for libassuan In-Reply-To: <554D072C.8030100@adversary.org> References: <87vbg5nyz2.fsf@alice.fifthhorseman.net> <554CBA20.1070307@adversary.org> <87oalvjexr.fsf@alice.fifthhorseman.net> <554D072C.8030100@adversary.org> Message-ID: <87bnhuj2h9.fsf@alice.fifthhorseman.net> On Fri 2015-05-08 14:57:48 -0400, Ben McGinnes wrote: > I strongly suspect that wiping the slate clean and writing a "proper" > Python driven API, as Werner suggested, would've had to be done > anyway. Doing all that as C-API modules, however, is a ridiculously > mammoth undertaking, so in that case something which lends itself a > little more towards a reasonable development timeframe is far more > likely. As you've seen, the approach i took was to make a plausible stab at a python mapping to the underlying C library via the C-API, and then write a bit more sensible/pythonic type stuff in python around that core. > The two options currently under consideration are Cython and CFFI, > even though neither are part of the standard library. I don't know anytihng about these approaches, i'm afraid i'm a bit of a python newbie. I've looked at SWIG, and agree that the interfaces it produces by default look scary and non-pythonic for libraries like libassuan. > At this point I think Python should be well on the way to getting most > people away from 2.7 and really leaving it just to those few legacy > deployments that can't shift for whatever reason. The rest of us can > enjoy the 21st century. :) > I also have your first patch for you if there's somewhere I can push > it to. It's not much, just a more pythonic way of specifying the > homedir in assuan/gnupg.py. The relevant bits are attached. Thanks, applied and pushed. If you send your patches as produced via "git format-patch" (or even easier, sent via "git send-email") then they're easier for me to apply directly, rather than sending the log and the patch as separate attachments. Regards, --dkg From brian at minton.name Fri May 8 21:58:13 2015 From: brian at minton.name (Brian Minton) Date: Fri, 8 May 2015 15:58:13 -0400 Subject: python bindings for libassuan In-Reply-To: <87bnhuj2h9.fsf@alice.fifthhorseman.net> References: <87vbg5nyz2.fsf@alice.fifthhorseman.net> <554CBA20.1070307@adversary.org> <87oalvjexr.fsf@alice.fifthhorseman.net> <554D072C.8030100@adversary.org> <87bnhuj2h9.fsf@alice.fifthhorseman.net> Message-ID: https://docs.python.org/2/library/ctypes.html#callback-functions Looks like calling a Python function from a C callback is possible. On Fri, May 8, 2015 at 3:25 PM, Daniel Kahn Gillmor wrote: > On Fri 2015-05-08 14:57:48 -0400, Ben McGinnes wrote: >> I strongly suspect that wiping the slate clean and writing a "proper" >> Python driven API, as Werner suggested, would've had to be done >> anyway. Doing all that as C-API modules, however, is a ridiculously >> mammoth undertaking, so in that case something which lends itself a >> little more towards a reasonable development timeframe is far more >> likely. > > As you've seen, the approach i took was to make a plausible stab at a > python mapping to the underlying C library via the C-API, and then write > a bit more sensible/pythonic type stuff in python around that core. > >> The two options currently under consideration are Cython and CFFI, >> even though neither are part of the standard library. > > I don't know anytihng about these approaches, i'm afraid i'm a bit of a > python newbie. > > I've looked at SWIG, and agree that the interfaces it produces by > default look scary and non-pythonic for libraries like libassuan. > >> At this point I think Python should be well on the way to getting most >> people away from 2.7 and really leaving it just to those few legacy >> deployments that can't shift for whatever reason. The rest of us can >> enjoy the 21st century. > > :) > >> I also have your first patch for you if there's somewhere I can push >> it to. It's not much, just a more pythonic way of specifying the >> homedir in assuan/gnupg.py. The relevant bits are attached. > > Thanks, applied and pushed. > > If you send your patches as produced via "git format-patch" (or even > easier, sent via "git send-email") then they're easier for me to apply > directly, rather than sending the log and the patch as separate > attachments. > > Regards, > > --dkg > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From dkg at fifthhorseman.net Fri May 8 22:21:50 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 08 May 2015 16:21:50 -0400 Subject: python bindings for libassuan In-Reply-To: References: <87vbg5nyz2.fsf@alice.fifthhorseman.net> <554CBA20.1070307@adversary.org> <87oalvjexr.fsf@alice.fifthhorseman.net> <554D072C.8030100@adversary.org> <87bnhuj2h9.fsf@alice.fifthhorseman.net> Message-ID: <87wq0ihlb5.fsf@alice.fifthhorseman.net> On Fri 2015-05-08 15:58:13 -0400, Brian Minton wrote: > https://docs.python.org/2/library/ctypes.html#callback-functions > Looks like calling a Python function from a C callback is possible. hm, it does look like that. I don't think i'm well-versed enough in ctypes to understand how to best wrap things there; if someone wants to make a ctypes wrapper for libassuan, i'd be happy to learn from it. --dkg From ben at adversary.org Sat May 9 04:27:26 2015 From: ben at adversary.org (Ben McGinnes) Date: Sat, 09 May 2015 12:27:26 +1000 Subject: python bindings for libassuan In-Reply-To: <87bnhuj2h9.fsf@alice.fifthhorseman.net> References: <87vbg5nyz2.fsf@alice.fifthhorseman.net> <554CBA20.1070307@adversary.org> <87oalvjexr.fsf@alice.fifthhorseman.net> <554D072C.8030100@adversary.org> <87bnhuj2h9.fsf@alice.fifthhorseman.net> Message-ID: <554D708E.6040809@adversary.org> On 9/05/2015 5:25 am, Daniel Kahn Gillmor wrote: > On Fri 2015-05-08 14:57:48 -0400, Ben McGinnes wrote: >> I strongly suspect that wiping the slate clean and writing a "proper" >> Python driven API, as Werner suggested, would've had to be done >> anyway. Doing all that as C-API modules, however, is a ridiculously >> mammoth undertaking, so in that case something which lends itself a >> little more towards a reasonable development timeframe is far more >> likely. > > As you've seen, the approach i took was to make a plausible stab at a > python mapping to the underlying C library via the C-API, and then write > a bit more sensible/pythonic type stuff in python around that core. Right, which is the sort of thing I'll look to for pointers when I start crafting the other thing. Might also have to try to recall where I left that copy of K&R's C book. >> The two options currently under consideration are Cython and CFFI, >> even though neither are part of the standard library. > > I don't know anytihng about these approaches, i'm afraid i'm a bit of a > python newbie. Whereas it's the one language I'm most comfortable with. A result of it being the language of choice at my first tech employer (an ISP). Anyway, CFFI is what the Python Cryptography project uses, though they're also moving towards using PyCrypto for their backend (which in turn relies on OpenSSL and a whole bunch of custom contributed C modules for Python). If I take the CFFI route then there's some good examples in their code: https://github.com/pyca/cryptography https://cryptography.io/ https://cryptography.io/en/latest/ https://cffi.readthedocs.org/en/latest/ https://bitbucket.org/cffi/cffi http://cython.org/ Cython, on the other hand, takes a rather different approach, but it very closely resembles Python code and can be used to generate C source code. So it's effectively possible to write something that's 99% Python which will produce C source code that will compile into a CPython module and once the source is written it will happily compile on multiple platforms and for multiple Python implementations and versions. I wouldn't write a kernel with it (or implement a cryptosystem from scratch), but pretty much everything else is up for grabs. Both have significant advantages depending on the intended outcome, but I think CFFI might be a little easier both to code and to manage. Depending on whether or not using it to load libgpgme.[so|dylib|dll] or libassuan.[so|dylib|dll] is enough to achieve the end goal. If not then Cython may step up to the plate to take care of building a CPython module with the relevant libs, but everything I've seen so far indicates CFFI can do it all (including callbacks). I think I might have to give both a spin before deciding, though. > I've looked at SWIG, and agree that the interfaces it produces by > default look scary and non-pythonic for libraries like libassuan. Yeah, it's only as entrenched as it is because for a long time it was the only option at all that didn't involve coding Python modules in C, like the core of CPython is. Well, there was Boost too, but to say it's painful to configure is an understatement. >> I also have your first patch for you if there's somewhere I can push >> it to. It's not much, just a more pythonic way of specifying the >> homedir in assuan/gnupg.py. The relevant bits are attached. > > Thanks, applied and pushed. You're welcome. > If you send your patches as produced via "git format-patch" (or even > easier, sent via "git send-email") then they're easier for me to apply > directly, rather than sending the log and the patch as separate > attachments. Ah-ha, more git voodoo! It can be a peculiar little thing at times, but it works. Added that one to my cheat sheet, thanks. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: OpenPGP digital signature URL: From pgut001 at cs.auckland.ac.nz Sat May 9 14:39:42 2015 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Sun, 10 May 2015 00:39:42 +1200 Subject: excessive usage of /dev/random? In-Reply-To: <5548CAC4.8010202@sixdemonbag.org> Message-ID: "Robert J. Hansen" writes: >I thought BBS had a proof of security related to the difficulty of the >quadratic residuosity problem. Given how close that is to IFP, BBS seems to >be as secure as RSA, which is good enough for my purposes. ;) Yeah, and that's its sole feature, that you can say it has "provable security". Apart from that it's really slow, awkward, and hard to implement. In terms of practical security, it's probably no better than a decent HMAC- based PRF, while having all of the above drawbacks. Peter. From brian at minton.name Tue May 12 16:01:39 2015 From: brian at minton.name (Brian Minton) Date: Tue, 12 May 2015 10:01:39 -0400 Subject: excessive usage of /dev/random? In-Reply-To: References: <5548CAC4.8010202@sixdemonbag.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Sat, May 9, 2015 at 8:39 AM, Peter Gutmann wrote: > Yeah, and that's its sole feature, that you can say it has "provable > security". Apart from that it's really slow, awkward, and hard to > implement. In terms of practical security, it's probably no better > than a decent HMAC-based PRF, while having all of the above drawbacks. BBS also needs two large random primes, which if you already have two large primes, you could just use them for the RSA key. To be fair though, I am not sure how big the primes need to be for Blum Blum Shub. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iF4EAREIAAYFAlVSB7YACgkQa46zoGXPuqnacQD8CTzFTQfuL0nh3a32E3qsH0Y6 KkkMPxWdwYWfzTxYm8IA/j0oJqRADd8JM4ziO14JmFoskPwp1+oTXG9JwklB5EuT =ATbt -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Tue May 12 18:24:40 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 12 May 2015 18:24:40 +0200 Subject: [Announce] GnuPG 2.1.4 released Message-ID: <87sib1ojav.fsf@vigenere.g10code.de> Hello! The GnuPG Project is pleased to announce the availability of a new release of GnuPG modern: Version 2.1.4. The GNU Privacy Guard (GnuPG) is a complete and free implementation of the OpenPGP standard which is commonly abbreviated as PGP. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries making use of GnuPG are available. Since version 2 GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Three different branches of GnuPG are actively maintained: - GnuPG "modern" (2.1) is the latest development with a lot of new features. This announcement is about this branch. - GnuPG "stable" (2.0) is the current stable version for general use. This is what most users are currently using. - GnuPG "classic" (1.4) is the old standalone version which is most suitable for older or embedded platforms. You may not install "modern" (2.1) and "stable" (2.0) at the same time. However, it is possible to install "classic" (1.4) along with any of the other versions. Noteworthy changes in version 2.1.4 =================================== * gpg: Add command --quick-adduid to non-interactively add a new user id to an existing key. * gpg: Do no enable honor-keyserver-url by default. Make it work if enabled. * gpg: Display the serial number in the --card-status output again. * agent: Support for external password managers. Add option --no-allow-external-cache. * scdaemon: Improved handling of extended APDUs. * Make HTTP proxies work again. * All network access including DNS as been moved to Dirmngr. * Allow building without LDAP support. A detailed description of the changes found in the 2.1 branch can be found at . This version fixes many bugs found after the release of 2.1.3 but there are still known bugs which we are working on. Please check the the bug tracker, https://wiki.gnupg.org, or mailing list archives for known problems and workaround. Getting the Software ==================== Please follow the instructions found at https://gnupg.org/download/ or read on: GnuPG 2.1.4 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. On ftp.gnupg.org you find these files: ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.4.tar.bz2 (4771k) ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.4.tar.bz2.sig This is the GnuPG source code compressed using BZIP2 and its OpenPGP signature. ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.4_20150512.exe (2566k) ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.4_20150512.exe.sig This is an installer for Windows without graphical frontends except for a basic Pinentry tool. Please de-install an installed Gpg4win version before trying this installer. Note, that TLS access to keyservers is not yet available. The sources used to build the installer can be found in the same directory with an ".tar.xz" suffix. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.1.4.tar.bz2 you would use this command: gpg --verify gnupg-2.1.4.tar.bz2.sig gnupg-2.1.4.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See below for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.1.4.tar.bz2, you would run the command like this: sha1sum gnupg-2.1.4.tar.bz2 and check that the output matches the next line: ad68d65c54698e3c781e17864ab5918442df155a gnupg-2.1.4.tar.bz2 d8f4a326c36578d05af5751abea668a15ea0aae1 gnupg-w32-2.1.4_20150512.exe dbd3af91467ecb4c0826d45497793cc3249f9cc9 gnupg-w32-2.1.4_20150512.tar.xz Release Signing Keys ==================== To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: 2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31] Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 Werner Koch (Release Signing Key) You may retrieve these files from a keyserver using this command gpg --keyserver hkp://keys.gnupg.net --recv-keys \ 249B39D24F25E3B6 04376F3EE0856959 \ 2071B08A33BD3F06 8A861B1C7EFD60D9 The keys are also available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed using by a different key. Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese, Czech, French, German, Japanese, Russian, and Ukrainian being almost completely translated (2062 different strings). Documentation ============= If you used GnuPG in the past you should read the description of changes and new features at doc/whats-new-in-2.1.txt or online at https://gnupg.org/faq/whats-new-in-2.1.html The file gnupg.info has the complete user manual of the system. Separate man pages are included as well but they have not all the details available as are the manual. It is also possible to read the complete manual online in HTML format at https://gnupg.org/documentation/manuals/gnupg/ or in Portable Document Format at https://gnupg.org/documentation/manuals/gnupg.pdf . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. You may also want search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. You may also want to follow postings at https://gnupg.org/blob/. Support ======== Please consult the archive of the gnupg-users mailing list before reporting a bug . We suggest to send bug reports for a new release to this list in favor of filing a bug at . For commercial support requests we keep a list of known service companies at: https://gnupg.org/service.html If you are a developer and you may need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Maintenance and development of GnuPG is possible due to many individual and corporate donations; for a list of non-anonymous donors see . For the GnuPG hackers, Werner p.s. This is a announcement only mailing list. Please send replies only to the gnupg-users at gnupg.org mailing list. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From dkg at fifthhorseman.net Wed May 13 19:04:04 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 13 May 2015 13:04:04 -0400 Subject: removing pinentry's subdirectories from git: debian/ gtk/ qt/ Message-ID: <87twvg8l4r.fsf@alice.fifthhorseman.net> Hi pinentry people-- I notice that pinentry git contains three subdirectories that aren't even shipped in the released tarballs: debian/ gtk/ qt/ We have these files in the git history -- is there a reason to keep them around in the master branch? If not, a "git rm -r debian gtk qt" should do the trick. That will make it easier to keep track of the code that we think is currently relevant, while retaining the ability to recover it from git history should we find we need it. Regards, --dkg From dkg at fifthhorseman.net Wed May 13 21:14:26 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 13 May 2015 15:14:26 -0400 Subject: error building pinentry 0.9.2 with libsecret Message-ID: <87d2248f3h.fsf@alice.fifthhorseman.net> hi there pinentry people-- trying to build pinentry 0.9.2 with libsecret on a debian testing system, and i get the following error when linking pinentry/pinentry-curses.c: gcc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wno-pointer-sign -Wl,-z,relro -Wl,--as-needed -o pinentry-curses pinentry-curses.o -lsecret-1 -lgio-2.0 -lgobject-2.0 -lglib-2.0 ../pinentry/libpinentry.a ../pinentry/libpinentry-curses.a ../assuan/libassuan.a ../secmem/libsecmem.a -lncursesw ../pinentry/libpinentry.a(password-cache.o): In function `password_cache_save': /home/dkg/src/pkg-gnupg/pinentry/pinentry/password-cache.c:80: undefined reference to `secret_password_store_sync' /home/dkg/src/pkg-gnupg/pinentry/pinentry/password-cache.c:89: undefined reference to `g_error_free' ../pinentry/libpinentry.a(password-cache.o): In function `password_cache_lookup': /home/dkg/src/pkg-gnupg/pinentry/pinentry/password-cache.c:109: undefined reference to `secret_password_lookup_nonpageable_sync' /home/dkg/src/pkg-gnupg/pinentry/pinentry/password-cache.c:131: undefined reference to `secret_password_free' /home/dkg/src/pkg-gnupg/pinentry/pinentry/password-cache.c:117: undefined reference to `g_error_free' collect2: error: ld returned 1 exit status Makefile:389: recipe for target 'pinentry-curses' failed make: *** [pinentry-curses] Error 1 I'm a little confused, because i see the -lsecret-1 in the linking line, and i'd expect secret_password_store to be defined there. And i'd think that g_error_free would be available from -lglib-2.0. i think Kristian Fiskerstrand is seeing the same concerns building on gentoo. Presumably it is working for you upstream. Any hints on what we might be missing? --dkg From neal at walfield.org Wed May 13 21:27:42 2015 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 13 May 2015 21:27:42 +0200 Subject: removing pinentry's subdirectories from git: debian/ gtk/ qt/ In-Reply-To: <87twvg8l4r.fsf@alice.fifthhorseman.net> References: <87twvg8l4r.fsf@alice.fifthhorseman.net> Message-ID: <87bnhowa4x.wl-neal@walfield.org> Hi Daniel, At Wed, 13 May 2015 13:04:04 -0400, Daniel Kahn Gillmor wrote: > I notice that pinentry git contains three subdirectories that aren't > even shipped in the released tarballs: > > debian/ > gtk/ > qt/ Werner mentioned removing gtk (the old gtk1 implementation) and qt (the qt3 implementation). I've been doing some other cleanups and haven't gotten to that yet. Since you're a Debian developer, I'll trust you that removing the debian directory is the right thing to do. (Taking a look now, it does appear quite outdated.) :) Neal From neal at walfield.org Wed May 13 21:47:48 2015 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 13 May 2015 21:47:48 +0200 Subject: error building pinentry 0.9.2 with libsecret In-Reply-To: <87d2248f3h.fsf@alice.fifthhorseman.net> References: <87d2248f3h.fsf@alice.fifthhorseman.net> Message-ID: <87a8x8w97f.wl-neal@walfield.org> Hi Daniel, At Wed, 13 May 2015 15:14:26 -0400, Daniel Kahn Gillmor wrote: > trying to build pinentry 0.9.2 with libsecret on a debian testing > system, and i get the following error when linking > pinentry/pinentry-curses.c: > > gcc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wno-pointer-sign -Wl,-z,relro -Wl,--as-needed -o pinentry-curses pinentry-curses.o -lsecret-1 -lgio-2.0 -lgobject-2.0 -lglib-2.0 ../pinentry/libpinentry.a ../pinentry/libpinentry-curses.a ../assuan/libassuan.a ../secmem/libsecmem.a -lncursesw When I use your link command (replacing ncursesw with ncurses), I see the same errors. It appears to be cause by the linker option: --as-needed: removing it causes it to link again. The problem is that --as-need works from left to right. When libsecret is linked in, nothing has required any symbols from libsecret. (Only libpinentry.a needs it.) Thus, it is deemed irrelevant and ignored. The solution is to include all of the .as before the -ls. I've just pushed a fix. Please let me know if it is sufficient. Thanks for the bug report. :) Neal From dkg at fifthhorseman.net Wed May 13 21:52:09 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 13 May 2015 15:52:09 -0400 Subject: using -Wl, --as-needed with libsecret and glib? [was: Re: error building pinentry 0.9.2 with libsecret] In-Reply-To: <87d2248f3h.fsf@alice.fifthhorseman.net> References: <87d2248f3h.fsf@alice.fifthhorseman.net> Message-ID: <874mng8dcm.fsf@alice.fifthhorseman.net> On Wed 2015-05-13 15:14:26 -0400, Daniel Kahn Gillmor wrote: > hi there pinentry people-- > > trying to build pinentry 0.9.2 with libsecret on a debian testing > system, and i get the following error when linking > pinentry/pinentry-curses.c: > > gcc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wno-pointer-sign -Wl,-z,relro -Wl,--as-needed -o pinentry-curses pinentry-curses.o -lsecret-1 -lgio-2.0 -lgobject-2.0 -lglib-2.0 ../pinentry/libpinentry.a ../pinentry/libpinentry-curses.a ../assuan/libassuan.a ../secmem/libsecmem.a -lncursesw > ../pinentry/libpinentry.a(password-cache.o): In function `password_cache_save': > /home/dkg/src/pkg-gnupg/pinentry/pinentry/password-cache.c:80: undefined reference to `secret_password_store_sync' > /home/dkg/src/pkg-gnupg/pinentry/pinentry/password-cache.c:89: undefined reference to `g_error_free' > ../pinentry/libpinentry.a(password-cache.o): In function `password_cache_lookup': > /home/dkg/src/pkg-gnupg/pinentry/pinentry/password-cache.c:109: undefined reference to `secret_password_lookup_nonpageable_sync' > /home/dkg/src/pkg-gnupg/pinentry/pinentry/password-cache.c:131: undefined reference to `secret_password_free' > /home/dkg/src/pkg-gnupg/pinentry/pinentry/password-cache.c:117: undefined reference to `g_error_free' > collect2: error: ld returned 1 exit status > Makefile:389: recipe for target 'pinentry-curses' failed > make: *** [pinentry-curses] Error 1 > > I'm a little confused, because i see the -lsecret-1 in the linking line, > and i'd expect secret_password_store to be defined there. > > And i'd think that g_error_free would be available from -lglib-2.0. > > i think Kristian Fiskerstrand is seeing the same concerns building on > gentoo. the problem seems to be related to the -Wl,--as-needed linker option, which Kristian is using too. I've minimized it to this test case, which seems like it shouldn't be happening, unless there's some sort of bad interaction between glib and ld's --as-needed flag: --------------- 0 dkg at alice:~/src/pkg-gnupg/pinentry$ cat test.c #include int main(int argc, char * argv[]) { GError *error = NULL; g_error_free (error); return 0; } 0 dkg at alice:~/src/pkg-gnupg/pinentry$ gcc -o test $(pkg-config --cflags --libs glib-2.0) test.c 0 dkg at alice:~/src/pkg-gnupg/pinentry$ gcc -o test -Wl,--as-needed $(pkg-config --cflags --libs glib-2.0) test.c /home/dkg/tmp/ccJ27dyL.o: In function `main': test.c:(.text+0x1f): undefined reference to `g_error_free' collect2: error: ld returned 1 exit status 1 dkg at alice:~/src/pkg-gnupg/pinentry$ gcc -o test $(pkg-config --cflags --libs glib-2.0) -Wl,--as-needed test.c 0 dkg at alice:~/src/pkg-gnupg/pinentry$ ---------------- So what matters is whether the supplied -l flags go before or after -Wl,--as-needed. (indeed, the ld man page suggests that --as-needed only applies to arguments that follow it on the linker command line) I'd like to be able to use --as-needed to minimize unnecessary linking. I found this, but it doesn't seem to resolve the issue: https://sigquit.wordpress.com/2011/02/16/why-asneeded-doesnt-work-as-expected-for-your-libraries-on-your-autotools-project/ Any pointers? --dkg From dimitri.j.ledkov at intel.com Wed May 13 19:12:53 2015 From: dimitri.j.ledkov at intel.com (Dimitri John Ledkov) Date: Wed, 13 May 2015 18:12:53 +0100 Subject: removing pinentry's subdirectories from git: debian/ gtk/ qt/ In-Reply-To: <87twvg8l4r.fsf@alice.fifthhorseman.net> References: <87twvg8l4r.fsf@alice.fifthhorseman.net> Message-ID: On 13 May 2015 at 18:04, Daniel Kahn Gillmor wrote: > Hi pinentry people-- > > I notice that pinentry git contains three subdirectories that aren't > even shipped in the released tarballs: > > debian/ > gtk/ > qt/ > > We have these files in the git history -- is there a reason to keep them > around in the master branch? > > If not, a "git rm -r debian gtk qt" should do the trick. > > That will make it easier to keep track of the code that we think is > currently relevant, while retaining the ability to recover it from git > history should we find we need it. > yes, please purge. It's equivalent of having #if 0, or .back files committed in tree. We have a version control system, and it is clearer to commit/uncommit things. -- Regards, Dimitri. Pura Vida! https://clearlinux.org Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. From dkg at fifthhorseman.net Wed May 13 22:11:45 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 13 May 2015 16:11:45 -0400 Subject: error building pinentry 0.9.2 with libsecret In-Reply-To: <87a8x8w97f.wl-neal@walfield.org> References: <87d2248f3h.fsf@alice.fifthhorseman.net> <87a8x8w97f.wl-neal@walfield.org> Message-ID: <871tik8cfy.fsf@alice.fifthhorseman.net> On Wed 2015-05-13 15:47:48 -0400, Neal H. Walfield wrote: > I've just pushed a fix. Please let me know if it is sufficient. Yep, i think that does it, thanks! --dkg From dkg at fifthhorseman.net Wed May 13 22:35:02 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 13 May 2015 16:35:02 -0400 Subject: compiler warnings in pinentry-qt4 Message-ID: <87y4ks6wsp.fsf@alice.fifthhorseman.net> Hi gnupg pinentry folks-- I'm seeing the compiler warnings below when building pinentry-qt4 from 0.9.2. It'd be nice to clean up the source, so that real warnings/errors stand out a bit more. Thanks for your work on pinentry! --dkg g++ -DHAVE_CONFIG_H -I. -I.. -pthread -I/usr/include/libsecret-1 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I.. -I../assuan -I../secmem -I/usr/include/ncursesw -I../pinentry -D_FORTIFY_SOURCE=2 -Wall -DQT_SHARED -I/usr/include/qt4 -I/usr/include/qt4/QtCore -DQT_SHARED -I/usr/include/qt4 -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I/usr/include/qt4/QtCore -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -c -o secstring.o secstring.cpp secstring.cpp: In function ?secstring toUtf8(const secqstring&)?: secstring.cpp:71:16: warning: unused variable ?cursor? [-Wunused-variable] uchar *cursor = (uchar*)ba.data(); ^ g++ -DHAVE_CONFIG_H -I. -I.. -pthread -I/usr/include/libsecret-1 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I.. -I../assuan -I../secmem -I/usr/include/ncursesw -I../pinentry -D_FORTIFY_SOURCE=2 -Wall -DQT_SHARED -I/usr/include/qt4 -I/usr/include/qt4/QtCore -DQT_SHARED -I/usr/include/qt4 -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I/usr/include/qt4/QtCore -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -c -o qsecurelineedit.o qsecurelineedit.cpp In file included from /usr/include/qt4/QtCore/qnamespace.h:45:0, from /usr/include/qt4/QtCore/qobjectdefs.h:45, from /usr/include/qt4/QtGui/qwindowdefs.h:45, from /usr/include/qt4/QtGui/qwidget.h:46, from /usr/include/qt4/QtGui/qframe.h:45, from /usr/include/qt4/QtGui/qlineedit.h:45, from qsecurelineedit.cpp:47: qsecurelineedit.cpp: In member function ?virtual QSize QSecureLineEdit::sizeHint() const?: /usr/include/qt4/QtCore/qglobal.h:2599:43: warning: unused variable ?d? [-Wunused-variable] #define Q_D(Class) Class##Private * const d = d_func() ^ qsecurelineedit.cpp:718:5: note: in expansion of macro ?Q_D? Q_D(const QSecureLineEdit); ^ qsecurelineedit.cpp: In member function ?virtual QSize QSecureLineEdit::minimumSizeHint() const?: /usr/include/qt4/QtCore/qglobal.h:2599:43: warning: unused variable ?d? [-Wunused-variable] #define Q_D(Class) Class##Private * const d = d_func() ^ qsecurelineedit.cpp:742:5: note: in expansion of macro ?Q_D? Q_D(const QSecureLineEdit); ^ qsecurelineedit.cpp: In member function ?void QSecureLineEdit::setCursorPosition(int)?: qsecurelineedit.cpp:776:13: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] if (pos <= d->text.length()) ^ In file included from /usr/include/qt4/QtCore/qnamespace.h:45:0, from /usr/include/qt4/QtCore/qobjectdefs.h:45, from /usr/include/qt4/QtGui/qwindowdefs.h:45, from /usr/include/qt4/QtGui/qwidget.h:46, from /usr/include/qt4/QtGui/qframe.h:45, from /usr/include/qt4/QtGui/qlineedit.h:45, from qsecurelineedit.cpp:47: qsecurelineedit.cpp: In member function ?void QSecureLineEdit::paste()?: /usr/include/qt4/QtCore/qglobal.h:2599:43: warning: unused variable ?d? [-Wunused-variable] #define Q_D(Class) Class##Private * const d = d_func() ^ qsecurelineedit.cpp:1484:5: note: in expansion of macro ?Q_D? Q_D(QSecureLineEdit); ^ qsecurelineedit.cpp: In member function ?void QSecureLineEditPrivate::setText(const secqstring&, int, bool)?: qsecurelineedit.cpp:2925:30: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] cursor = (pos < 0 || pos > text.size()) ? text.size() : pos; ^ qsecurelineedit.cpp: In member function ?bool QSecureLineEditPrivate::hasAcceptableInput(const secqstring&) const?: qsecurelineedit.cpp:3214:22: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] if (str.length() != maxLength) ^ qsecurelineedit.cpp: In member function ?secqstring QSecureLineEditPrivate::maskString(uint, const secqstring&, bool) const?: qsecurelineedit.cpp:3247:22: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] if (strIndex < str.length()) { ^ From dkg at fifthhorseman.net Wed May 13 22:36:26 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 13 May 2015 16:36:26 -0400 Subject: [PATCH] avoid implicit declaration of function addnwstr Message-ID: <1431549386-7432-1-git-send-email-dkg@fifthhorseman.net> When built with libncursesw, we see this problem: pinentry-curses.c:440:8: warning: implicit declaration of function ?addnwstr? [-Wimplicit-function-declaration] ADDCH (start[i]); ^ --- pinentry/pinentry-curses.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/pinentry/pinentry-curses.c b/pinentry/pinentry-curses.c index 135d714..9f95bff 100644 --- a/pinentry/pinentry-curses.c +++ b/pinentry/pinentry-curses.c @@ -22,7 +22,11 @@ #include #endif #include +#ifdef HAVE_NCURSESW +#include +#else #include +#endif #include #include #include -- 2.1.4 From dimitri.j.ledkov at intel.com Thu May 14 11:54:04 2015 From: dimitri.j.ledkov at intel.com (Dimitri John Ledkov) Date: Thu, 14 May 2015 10:54:04 +0100 Subject: removing pinentry's subdirectories from git: debian/ gtk/ qt/ In-Reply-To: <87bnhowa4x.wl-neal@walfield.org> References: <87twvg8l4r.fsf@alice.fifthhorseman.net> <87bnhowa4x.wl-neal@walfield.org> Message-ID: On 13 May 2015 at 20:27, Neal H. Walfield wrote: > Hi Daniel, > > At Wed, 13 May 2015 13:04:04 -0400, > Daniel Kahn Gillmor wrote: >> I notice that pinentry git contains three subdirectories that aren't >> even shipped in the released tarballs: >> >> debian/ >> gtk/ >> qt/ > > Werner mentioned removing gtk (the old gtk1 implementation) and qt > (the qt3 implementation). I've been doing some other cleanups and > haven't gotten to that yet. > > Since you're a Debian developer, I'll trust you that removing the > debian directory is the right thing to do. (Taking a look now, it > does appear quite outdated.) > Debian Developers got sick of upstreams shipping debian/ directories, hence for many years now dpkg-source when using v3 format nukes the ./debian/ directory out of the upstream tarballs on unpack. However here lies the irony.... Debian upstream project tarballs ship debian/ directories and use a v3-native subformat.... -- Regards, Dimitri. Pura Vida! https://clearlinux.org Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. From wk at gnupg.org Thu May 14 13:01:30 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 14 May 2015 13:01:30 +0200 Subject: removing pinentry's subdirectories from git: debian/ gtk/ qt/ In-Reply-To: (Dimitri John Ledkov's message of "Thu, 14 May 2015 10:54:04 +0100") References: <87twvg8l4r.fsf@alice.fifthhorseman.net> <87bnhowa4x.wl-neal@walfield.org> Message-ID: <87twvfmnhx.fsf@vigenere.g10code.de> On Thu, 14 May 2015 11:54, dimitri.j.ledkov at intel.com said: > Debian Developers got sick of upstreams shipping debian/ directories, Back in 1998 the former Debian GnuPG Maintainer (James Troup) suggested to add a debian/ directory. This was later revised but for some packages it still sits in the repos. Sure debian/ should be removed. However, in some cases I like to keep old directories in the repo for example if we are in the process of moving code. The migration from keyserver helpers to dirmngr is such a case. tags require that everything has been checked out. BTW, the repos are development only and do not make a proper release! Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Thu May 14 15:36:17 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 14 May 2015 09:36:17 -0400 Subject: removing pinentry's subdirectories from git: debian/ gtk/ qt/ In-Reply-To: <87twvfmnhx.fsf@vigenere.g10code.de> References: <87twvg8l4r.fsf@alice.fifthhorseman.net> <87bnhowa4x.wl-neal@walfield.org> <87twvfmnhx.fsf@vigenere.g10code.de> Message-ID: <87fv6z7032.fsf@alice.fifthhorseman.net> On Thu 2015-05-14 07:01:30 -0400, Werner Koch wrote: > Sure debian/ should be removed. However, in some cases I like to keep > old directories in the repo for example if we are in the process of > moving code. The migration from keyserver helpers to dirmngr is such > a case. tags require that everything has been checked out. yep, understood. I don't think that we're in the middle of transferring code from debian/, gtk/, or qt/ though, right? > BTW, the repos are development only and do not make a proper release! Yes, of course. We build debian packages based on the released tarballs. But having a clearer/cleaner relationship between the released tarballs and the upstream repo makes it easier for debian developers to contribute back to upstream, and to pull narrowly-targeted changesets from the upstream revision control if they're needed to fix identified bugs before a new release comes out. Speaking of new releases, thanks for all the recent work on pinentry, Neal! it's exciting to see that coming along. I hope my little flood of minor bug reports the last few days has been encouraging instead of discouraging :) --dkg From dimitri.j.ledkov at intel.com Thu May 14 15:41:51 2015 From: dimitri.j.ledkov at intel.com (Dimitri John Ledkov) Date: Thu, 14 May 2015 14:41:51 +0100 Subject: removing pinentry's subdirectories from git: debian/ gtk/ qt/ In-Reply-To: <87twvfmnhx.fsf@vigenere.g10code.de> References: <87twvg8l4r.fsf@alice.fifthhorseman.net> <87bnhowa4x.wl-neal@walfield.org> <87twvfmnhx.fsf@vigenere.g10code.de> Message-ID: On 14 May 2015 at 12:01, Werner Koch wrote: > On Thu, 14 May 2015 11:54, dimitri.j.ledkov at intel.com said: > >> Debian Developers got sick of upstreams shipping debian/ directories, > > Back in 1998 the former Debian GnuPG Maintainer (James Troup) suggested I only started debian development 10 years ago... =) > to add a debian/ directory. This was later revised but for some > packages it still sits in the repos. > > Sure debian/ should be removed. However, in some cases I like to keep > old directories in the repo for example if we are in the process of > moving code. The migration from keyserver helpers to dirmngr is such a > case. tags require that everything has been checked out. > I don't follow..... $ git checkout old-tag debian/ -> will resurrect debian directory in the current working tree, if one actively needs to poke it with an editor. It will keep everything else at the current HEAD, and one can continue to pull/commit/push just the new stuff across. Thus dead stuff should never be in the current commited HEAD. Everyone always have the full history.... unlike e.g. svn where a tag is essentially a different branch not part of trunk's history. It is confusing for new developers when poking things to see what's actually currently in use... > BTW, the repos are development only and do not make a proper release! > Sure, i'm talking about (upstream) developer experience as well. Debian Developers know how to fetch and use debian packaging together with upstream source code pretty well and don't need ./debian/ directories upstream. Also, i am a strong believer that VCS checkout should match verbantim a "release tarball", and release tarballs shouldn't have any on the fly generated cruft sideloaded in. I also gpg sign my commits, I like that a lot because one can trace that history was not modified and that there was no things side-loaded in the past and then removed, in essence it's a cannary. > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > -- Regards, Dimitri. Pura Vida! https://clearlinux.org Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. From dimitri.j.ledkov at intel.com Thu May 14 15:45:28 2015 From: dimitri.j.ledkov at intel.com (Dimitri John Ledkov) Date: Thu, 14 May 2015 14:45:28 +0100 Subject: removing pinentry's subdirectories from git: debian/ gtk/ qt/ In-Reply-To: <87fv6z7032.fsf@alice.fifthhorseman.net> References: <87twvg8l4r.fsf@alice.fifthhorseman.net> <87bnhowa4x.wl-neal@walfield.org> <87twvfmnhx.fsf@vigenere.g10code.de> <87fv6z7032.fsf@alice.fifthhorseman.net> Message-ID: On 14 May 2015 at 14:36, Daniel Kahn Gillmor wrote: > On Thu 2015-05-14 07:01:30 -0400, Werner Koch wrote: > >> Sure debian/ should be removed. However, in some cases I like to keep >> old directories in the repo for example if we are in the process of >> moving code. The migration from keyserver helpers to dirmngr is such >> a case. tags require that everything has been checked out. > > yep, understood. I don't think that we're in the middle of transferring > code from debian/, gtk/, or qt/ though, right? > >> BTW, the repos are development only and do not make a proper release! > > Yes, of course. We build debian packages based on the released > tarballs. > > But having a clearer/cleaner relationship between the released tarballs > and the upstream repo makes it easier for debian developers to > contribute back to upstream, and to pull narrowly-targeted changesets > from the upstream revision control if they're needed to fix identified > bugs before a new release comes out. > > Speaking of new releases, thanks for all the recent work on pinentry, > Neal! it's exciting to see that coming along. I hope my little flood > of minor bug reports the last few days has been encouraging instead of > discouraging :) Yeah I also can't wait for the gtk3 compatible pin entry to be out! Even if my partial patch at fixing gtk3 didn't get reviewed/include from way back when, and now is obsolete. -- Regards, Dimitri. Pura Vida! https://clearlinux.org Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. From hw42 at ipsumj.de Thu May 14 16:08:58 2015 From: hw42 at ipsumj.de (HW42) Date: Thu, 14 May 2015 16:08:58 +0200 Subject: gnupg 2.1.4 fails to build with --disable-gpgsm Message-ID: <5554AC7A.5040101@ipsumj.de> Hi, when I try to build gnupg 2.1.4 with --disable-gpgsm the build fails. $ ./configure --disable-gpgsm --disable-gpgtar [ ... ] GnuPG v2.1.4 has been configured as follows: Revision: a67ead6 (42622) Platform: GNU/Linux (x86_64-unknown-linux-gnu) OpenPGP: yes S/MIME: no Agent: yes Smartcard: yes (without internal CCID driver) G13: yes Dirmngr: yes Gpgtar: no Protect tool: (default) LDAP wrapper: (default) Default agent: (default) Default pinentry: (default) Default scdaemon: (default) Default dirmngr: (default) Dirmngr auto start: yes Readline support: yes LDAP support: yes DNS SRV support: yes TLS support: gnutls $ make [ ... ] mv -f .deps/getkey.Tpo .deps/getkey.Po gcc -DHAVE_CONFIG_H -I. -I.. -I../common -DLOCALEDIR=\"/usr/local/share/locale\" -DGNUPG_BINDIR="\"/usr/local/bin\"" -DGNUPG_LIBEXECDIR="\"/usr/local/libexec\"" -DGNUPG_LIBDIR="\"/usr/local/lib/gnupg\"" -DGNUPG_DATADIR="\"/usr/local/share/gnupg\"" -DGNUPG_SYSCONFDIR="\"/usr/local/etc/gnupg\"" -DGNUPG_LOCALSTATEDIR="\"/usr/local/var\"" -I/tmp/b/libgcrypt-1.6.3/build/include -I/tmp/b/libgpg-error-1.19/build/include -I/tmp/b/libassuan-2.2.0/build/include -I/tmp/b/libgpg-error-1.19/build/include -I/tmp/b/libgpg-error-1.19/build/include -Wall -Wno-pointer-sign -Wpointer-arith -MT keydb.o -MD -MP -MF .deps/keydb.Tpo -c -o keydb.o keydb.c In file included from keydb.c:37:0: ../kbx/keybox.h:36:19: fatal error: ksba.h: No such file or directory # include ^ compilation terminated. Makefile:775: recipe for target 'keydb.o' failed make[2]: *** [keydb.o] Error 1 make[2]: Leaving directory '/tmp/b/gnupg-2.1.4/g10' Makefile:576: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/tmp/b/gnupg-2.1.4' Makefile:495: recipe for target 'all' failed make: *** [all] Error 2 $ export CFLAGS="$CFLAGS $(ksba-config --cflags)" # workaroud 1 $ ./configure --disable-gpgsm --disable-gpgtar [ ... ] $ make [ ... ] make[2]: *** No rule to make target '../kbx/libkeybox.a', needed by 'gpg2'. Stop. make[2]: Leaving directory '/tmp/b/gnupg-2.1.4/g10' Makefile:576: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/tmp/b/gnupg-2.1.4' Makefile:495: recipe for target 'all' failed make: *** [all] Error 2 $ make kbx=kbx # workaround 2 [ ... ] $ # successful build Without the --disable-gpgtar there is another missing include error. HW42 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From hw42 at ipsumj.de Thu May 14 17:42:09 2015 From: hw42 at ipsumj.de (HW42) Date: Thu, 14 May 2015 17:42:09 +0200 Subject: building libgcrypt 1.6.3 for win64 Message-ID: <5554C251.8090404@ipsumj.de> Hi, when I try to build libgcrypt 1.6.3 for win64 it fails: $ make [ ... ] mv -f .deps/random-fips.Tpo .deps/random-fips.Plo /bin/bash ../libtool --tag=CC --mode=compile x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/tmp/b/libgpg-error-1.19/build/include -g -O2 -Wall -MT random-system.lo -MD -MP -MF .deps/random-system.Tpo -c -o random-system.lo random-system.c libtool: compile: x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/tmp/b/libgpg-error-1.19/build/include -g -O2 -Wall -MT random-system.lo -MD -MP -MF .deps/random-system.Tpo -c random-system.c -DDLL_EXPORT -DPIC -o .libs/random-system.o mv -f .deps/random-system.Tpo .deps/random-system.Plo /bin/bash ../libtool --tag=CC --mode=compile x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/tmp/b/libgpg-error-1.19/build/include -g -O2 -Wall -MT rndhw.lo -MD -MP -MF .deps/rndhw.Tpo -c -o rndhw.lo rndhw.c libtool: compile: x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/tmp/b/libgpg-error-1.19/build/include -g -O2 -Wall -MT rndhw.lo -MD -MP -MF .deps/rndhw.Tpo -c rndhw.c -DDLL_EXPORT -DPIC -o .libs/rndhw.o /tmp/ccxCcj5Y.s: Assembler messages: /tmp/ccxCcj5Y.s:53: Error: unsupported instruction `mov' Makefile:458: recipe for target 'rndhw.lo' failed make[2]: *** [rndhw.lo] Error 1 make[2]: Leaving directory '/tmp/b/libgcrypt-1.6.3/random' Makefile:477: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/tmp/b/libgcrypt-1.6.3' Makefile:408: recipe for target 'all' failed make: *** [all] Error 2 $ this is the case regardless of whether I use $ ./configure --prefix=`pwd`/build --host=x86_64-w64-mingw32 or $ ./autogen.sh --build-w64 I'm building on a Debian unstable with gcc-mingw-w64-x86-64 version 4.9.2-15+15.1+b1. HW42 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From neal at walfield.org Thu May 14 20:19:12 2015 From: neal at walfield.org (Neal H. Walfield) Date: Thu, 14 May 2015 20:19:12 +0200 Subject: removing pinentry's subdirectories from git: debian/ gtk/ qt/ In-Reply-To: <87fv6z7032.fsf@alice.fifthhorseman.net> References: <87twvg8l4r.fsf@alice.fifthhorseman.net> <87bnhowa4x.wl-neal@walfield.org> <87twvfmnhx.fsf@vigenere.g10code.de> <87fv6z7032.fsf@alice.fifthhorseman.net> Message-ID: <878ucrvx7j.wl-neal@walfield.org> Hi Daniel, At Thu, 14 May 2015 09:36:17 -0400, Daniel Kahn Gillmor wrote: > On Thu 2015-05-14 07:01:30 -0400, Werner Koch wrote: > > Speaking of new releases, thanks for all the recent work on pinentry, > Neal! it's exciting to see that coming along. I hope my little flood > of minor bug reports the last few days has been encouraging instead of > discouraging :) It's great to get quick feedback about changes! First, it's nice to hear that someone is interested in what I'm working on. Second, it much easier to deal with bug reports when the relevant code is still in my working memory. This is particularly important given that the amount of testing that I can easily do is limited. Thanks! Keep 'em coming! :) Neal From neal at walfield.org Thu May 14 20:34:40 2015 From: neal at walfield.org (Neal H. Walfield) Date: Thu, 14 May 2015 20:34:40 +0200 Subject: gnome keyring & gpg agent In-Reply-To: <87fv6z7032.fsf@alice.fifthhorseman.net> References: <87twvg8l4r.fsf@alice.fifthhorseman.net> <87bnhowa4x.wl-neal@walfield.org> <87twvfmnhx.fsf@vigenere.g10code.de> <87fv6z7032.fsf@alice.fifthhorseman.net> Message-ID: <877fsbvwhr.wl-neal@walfield.org> Hi Daniel, At Thu, 14 May 2015 09:36:17 -0400, Daniel Kahn Gillmor wrote: > But having a clearer/cleaner relationship between the released tarballs > and the upstream repo makes it easier for debian developers to > contribute back to upstream, and to pull narrowly-targeted changesets > from the upstream revision control if they're needed to fix identified > bugs before a new release comes out. The pieces are now basically in place to fix the GPG Agent / Gnome Keyring issue. There are three minor issues: - There are a couple of small deficiencies in the gnome3 pinentry (e.g., no one button confirmation messages, but this is easily worked around). These deficiencies have more to do with limitations in Gcr than with the Pinentry implementation. - Gnome Keyring's maintainer hasn't yet ripped out the GPG Agent support, but fully agrees with the changes so far. (Of course, the GPG Agent proxy can be trivially disabled since it is a separate component.) - To fully replace Gnome Keyring's GPG Agent Proxy, a couple of minor changes had to be made to GPG. These are so far only in 2.1, but I will backport them to 2.0 soon. Is it possible to fix this issue in Debian Stable (e.g., in the next point release)? So far, I've identified these requirements: - Adding a new pinentry-gnome3 package with the yet-to-be-released pinentry with Gnome3 support. - An update to GPG with the relatively small change. - An update to Gnome-Keyring that disables it GPG Agent proxy. - Make Gnome Keyring depend on pinentry-gnome3. Thoughts? Neal From kristian.fiskerstrand at sumptuouscapital.com Thu May 14 20:41:25 2015 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Thu, 14 May 2015 20:41:25 +0200 Subject: gnome keyring & gpg agent In-Reply-To: <877fsbvwhr.wl-neal@walfield.org> References: <87twvg8l4r.fsf@alice.fifthhorseman.net> <87bnhowa4x.wl-neal@walfield.org> <87twvfmnhx.fsf@vigenere.g10code.de> <87fv6z7032.fsf@alice.fifthhorseman.net> <877fsbvwhr.wl-neal@walfield.org> Message-ID: <5554EC55.4070201@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05/14/2015 08:34 PM, Neal H. Walfield wrote: > Hi Daniel, > Hi Neal, thanks for your work on this > > Is it possible to fix this issue in Debian Stable (e.g., in the > next point release)? > > So far, I've identified these requirements: > > - Adding a new pinentry-gnome3 package with the yet-to-be-released > pinentry with Gnome3 support. > > - An update to GPG with the relatively small change. > > - An update to Gnome-Keyring that disables it GPG Agent proxy. > > - Make Gnome Keyring depend on pinentry-gnome3. > > Thoughts? > > Neal Fwiw, the tracking bugs are Gentoo: https://bugs.gentoo.org/show_bug.cgi?id=547456 Here I've already included the latest patches in testing (~arch), so awaiting feedback from the gnome team (we have 2.1 in testing, so backporting isn't necessary per se). Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784289 Redhat: https://bugzilla.redhat.com/show_bug.cgi?id=1153676 - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Testis unus, testis nullus A single witness is no witness -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJVVOxRAAoJEP7VAChXwav6wVsIAIrIsyDxIm/+8S1SKpSV7r/H 2Zzxp0qC2x9QzIl9FnFaLASb/pZgkO0Ww7WuElOKWY5QVRL9oVtkCVY6RFNP1nOb be9JbNF/mqDx71i/bkub+qyF28YjHwiWchbF1v0V+FRq/e7eHaZpM3FDNNd4c4ke rGTJXNEmHwRGI3BMyRxNs/Zh8x4ke9FuvDS2W/5S+vwtEy/hSRTIv2Pw+X12VIX+ OZkeWS+0deyHLHCpzU1NYX0N0tIRB2gq7SFFP6U0zTr+U/pX16tEpKTkzBsj1frc Kk/BI3BdB93GLtC4KHKKNtLKj/cnnsBcXNEtqQvnT7GWr8kb5EHBW6uW7b87A40= =EHw9 -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Thu May 14 20:44:34 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 14 May 2015 14:44:34 -0400 Subject: testing pinentry [was: Re: removing pinentry's subdirectories from git: debian/ gtk/ qt/] In-Reply-To: <878ucrvx7j.wl-neal@walfield.org> References: <87twvg8l4r.fsf@alice.fifthhorseman.net> <87bnhowa4x.wl-neal@walfield.org> <87twvfmnhx.fsf@vigenere.g10code.de> <87fv6z7032.fsf@alice.fifthhorseman.net> <878ucrvx7j.wl-neal@walfield.org> Message-ID: <877fsb578t.fsf@alice.fifthhorseman.net> On Thu 2015-05-14 14:19:12 -0400, Neal H. Walfield wrote: > It's great to get quick feedback about changes! First, it's nice to > hear that someone is interested in what I'm working on. Second, it > much easier to deal with bug reports when the relevant code is still > in my working memory. I'm happy that you see things this way, Neal :) > This is particularly important given that the amount of testing that I > can easily do is limited. Testing pinentry seems like a particularly thorny problem, as there are a lot of interacting variables, from window managers to actual humans in the loop. Has anyone tried to draft a more comprehensive pinentry test suite? for X11-based systems, it seems possible to use something like xserver-xephyr plus xdotool or other GUI automation systems might be worth experimenting with. Or maybe start with something interacting with a single tty and the curses interface? Does something like this already exist? I don't have the bandwidth to set something like this up, but if anyone reading the list wants to look into an automated test suite for the various pinentries, that seems like it would be a useful contribution. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From dimitri.j.ledkov at intel.com Fri May 15 11:03:49 2015 From: dimitri.j.ledkov at intel.com (Dimitri John Ledkov) Date: Fri, 15 May 2015 10:03:49 +0100 Subject: gnome keyring & gpg agent In-Reply-To: <877fsbvwhr.wl-neal@walfield.org> References: <87twvg8l4r.fsf@alice.fifthhorseman.net> <87bnhowa4x.wl-neal@walfield.org> <87twvfmnhx.fsf@vigenere.g10code.de> <87fv6z7032.fsf@alice.fifthhorseman.net> <877fsbvwhr.wl-neal@walfield.org> Message-ID: On 14 May 2015 at 19:34, Neal H. Walfield wrote: > Hi Daniel, > > At Thu, 14 May 2015 09:36:17 -0400, > Daniel Kahn Gillmor wrote: >> But having a clearer/cleaner relationship between the released tarballs >> and the upstream repo makes it easier for debian developers to >> contribute back to upstream, and to pull narrowly-targeted changesets >> from the upstream revision control if they're needed to fix identified >> bugs before a new release comes out. > > The pieces are now basically in place to fix the GPG Agent / Gnome > Keyring issue. There are three minor issues: > > - There are a couple of small deficiencies in the gnome3 pinentry > (e.g., no one button confirmation messages, but this is easily > worked around). These deficiencies have more to do with > limitations in Gcr than with the Pinentry implementation. > > - Gnome Keyring's maintainer hasn't yet ripped out the GPG Agent > support, but fully agrees with the changes so far. (Of course, > the GPG Agent proxy can be trivially disabled since it is a > separate component.) > > - To fully replace Gnome Keyring's GPG Agent Proxy, a couple of > minor changes had to be made to GPG. These are so far only in > 2.1, but I will backport them to 2.0 soon. > > Is it possible to fix this issue in Debian Stable (e.g., in the next > point release)? > > So far, I've identified these requirements: > > - Adding a new pinentry-gnome3 package with the yet-to-be-released > pinentry with Gnome3 support. > > - An update to GPG with the relatively small change. > > - An update to Gnome-Keyring that disables it GPG Agent proxy. > > - Make Gnome Keyring depend on pinentry-gnome3. Currently in Ubuntu we use gnupg 1.x as the default one, however I would like to make a push to transition to 2.x by default. I'll be switching gnupg2 package to 2.1 series soon in the development release (Wily Werewolf 15.10). Having a Gtk 3 compatible pin-entry was a blocker to switch from 1.x to 2.x series by default. I have already re-factored Gnome-Keyring GPG Agent to be as stand-alone as possible in Ubuntu both current stable releases and 14.04 LTS, because many people already disable gnome-keyring's agents (gpg, ssh, or both). I do it, cause I'm using gpg smartcard for both gpg subkeys and ssh authentication and thus gnome-keyring is useless for me. If there are patches needed for 2.0.x i'm happy to cherry-pick them for 14.04 LTS stable release update. Getting the lot done in Ubuntu/Debian development releases will be quick, and like provide ubuntu ppa with these changes. Stable updates probably will take some more time. -- Regards, Dimitri. Pura Vida! https://clearlinux.org Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. From wk at gnupg.org Fri May 15 12:47:48 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 15 May 2015 12:47:48 +0200 Subject: building libgcrypt 1.6.3 for win64 In-Reply-To: <5554C251.8090404@ipsumj.de> (HW's message of "Thu, 14 May 2015 17:42:09 +0200") References: <5554C251.8090404@ipsumj.de> Message-ID: <87617um817.fsf@vigenere.g10code.de> On Thu, 14 May 2015 17:42, hw42 at ipsumj.de said: > when I try to build libgcrypt 1.6.3 for win64 it fails: This is not supported. Work is going on for 1.7 to support 64 bit WIndows builds. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri May 15 13:02:38 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 15 May 2015 13:02:38 +0200 Subject: removing pinentry's subdirectories from git: debian/ gtk/ qt/ In-Reply-To: (Dimitri John Ledkov's message of "Thu, 14 May 2015 14:45:28 +0100") References: <87twvg8l4r.fsf@alice.fifthhorseman.net> <87bnhowa4x.wl-neal@walfield.org> <87twvfmnhx.fsf@vigenere.g10code.de> <87fv6z7032.fsf@alice.fifthhorseman.net> Message-ID: <871tiim7ch.fsf@vigenere.g10code.de> On Thu, 14 May 2015 15:45, dimitri.j.ledkov at intel.com said: > Even if my partial patch at fixing gtk3 didn't get reviewed/include > from way back when, and now is obsolete. I looked at them but they would not have allowed to build it with older GTK versions. Thus was not abale to apply them. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri May 15 13:18:13 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 15 May 2015 13:18:13 +0200 Subject: removing pinentry's subdirectories from git: debian/ gtk/ qt/ In-Reply-To: (Dimitri John Ledkov's message of "Thu, 14 May 2015 14:41:51 +0100") References: <87twvg8l4r.fsf@alice.fifthhorseman.net> <87bnhowa4x.wl-neal@walfield.org> <87twvfmnhx.fsf@vigenere.g10code.de> Message-ID: <87wq0aks22.fsf@vigenere.g10code.de> On Thu, 14 May 2015 15:41, dimitri.j.ledkov at intel.com said: > Thus dead stuff should never be in the current commited HEAD. It is not dead. I am a heavy user of tags and thus I need all source to be available. It is just easier during development. You may have noticed that the keyserver directory has gone from gnupg after most of the helper haven been merged into dirmngr. The same is going on for Pinentry, Neal is about to remove Gtk 1 and Qt3 versions but that is not finished. > It is confusing for new developers when poking things to see what's > actually currently in use... That is easy to see because you won't see the directories in your build. If you do not use VPATH builds you have a lot of other problems. ;-) > Also, i am a strong believer that VCS checkout should match verbantim > a "release tarball", and release tarballs shouldn't have any on the I see we disagree here. There are too many local configuration options which make this impossible. This is why we have release tarballs which are complete with a higher probability. (cf "make distcheck"). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From neal at walfield.org Sat May 16 13:38:59 2015 From: neal at walfield.org (Neal H. Walfield) Date: Sat, 16 May 2015 13:38:59 +0200 Subject: [PATCH] avoid implicit declaration of function addnwstr In-Reply-To: <1431549386-7432-1-git-send-email-dkg@fifthhorseman.net> References: <1431549386-7432-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <87617swy3w.wl-neal@walfield.org> Applied with a slightly different change log entry. Thanks! :) Neal At Wed, 13 May 2015 16:36:26 -0400, Daniel Kahn Gillmor wrote: > > When built with libncursesw, we see this problem: > > pinentry-curses.c:440:8: warning: implicit declaration of function ?addnwstr? [-Wimplicit-function-declaration] > ADDCH (start[i]); > ^ > --- > pinentry/pinentry-curses.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/pinentry/pinentry-curses.c b/pinentry/pinentry-curses.c > index 135d714..9f95bff 100644 > --- a/pinentry/pinentry-curses.c > +++ b/pinentry/pinentry-curses.c > @@ -22,7 +22,11 @@ > #include > #endif > #include > +#ifdef HAVE_NCURSESW > +#include > +#else > #include > +#endif > #include > #include > #include > -- > 2.1.4 > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From dkg at fifthhorseman.net Sat May 16 22:19:16 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 16 May 2015 16:19:16 -0400 Subject: connection reset by peer for git://git.gnupg.org Message-ID: <87r3qg1diz.fsf@alice.fifthhorseman.net> hi folks-- whatever was serving the git protocol at git.gnupg.org seems to be down: 0 dkg at alice:/tmp/cdtemp.vnI01k$ git clone git://git.gnupg.org/pinentry.git Cloning into 'pinentry'... fatal: read error: Connection reset by peer 128 dkg at alice:/tmp/cdtemp.vnI01k$ maybe it needs a kick? --dkg From ben at adversary.org Sat May 16 22:26:26 2015 From: ben at adversary.org (Ben McGinnes) Date: Sun, 17 May 2015 06:26:26 +1000 Subject: GPGME pyme branch ready to merge with master Message-ID: <5557A7F2.5090002@adversary.org> Hello, As the subject indicates, the pyme branch in the GPGME repo is ready to be merged with master. It will almost certainly produce a bunch of PEP8 complaints about trailing whitespace, but this is primarily due to checking files it shouldn't be checking, like the license files, documentation and the big one is the text copy of the decade or so of Python 2 PyME commit logs. Just ignore the lot (there will be a very small number of unported scripts amongst the examples also in this category, which is explained in the current commit log and in the Examples.rst file). Should there be anything in the actual module also raising an error like this, it's nothing that will actually affect the function of the module, not given the ported example code and what it's been doing for the last several hours. It's at least as good as the current Python 2 version and a little better than what can be installed by Python 2 users from PyPI. Installation of this version is identical to a manual installation of the original, by running "python3 setup.py install" in the py3-pyme/ directory in lang/ and methods of calling it match the original in all ways except for those differences mandated by the switch from Python 2 to 3. The majority of this is the change in strings from ASCII to byte encoded, but Python 3 developers will already be treating all their strings appropriately for this anyway. The module is still installed as pyme and imported by that name, which will not interfere with any existing installation of the module for Python 2. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Mon May 18 04:27:45 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 18 May 2015 11:27:45 +0900 Subject: [PATCH] Improve handling of no corresponding public key for a private key Message-ID: <55594E21.7050802@fsij.org> Hello, This is a fix for the issue 1422: https://bugs.gnupg.org/gnupg/issue1422 Here is my scenario to reproduce the bug. (1) With --gen-key, generate DSA+Elgamal key (2) make a encrypted file using (1) (3) make a copy of .gnupg/secring.gpg (4) With --edit-key, delkey Elgamal subkey (5) With --export, make public key file (6) With --delete-secret-key, delete the key generated by (1) (7) Restore .gnupg/secring.gpg by the copy of (3) (8) Import DSA only public key of (5) Now, it has secret subkey, but no corresponding public key. (8) Try to decrypt encrypted file of (2) It asks the passphrase, then input it, then, it stops with: gpg: Ohhhh jeeee: no decrypt() for 17 It's Debian GnuPG 1.4.18-7 in stable. I think that it is better to check availability of public key for the private subkey. The function get_seckey should not return the public key of primary key when it is asked for the public key of subkey. Here is a patch. Tested in GnuPG 1.4. I think that this could be also applied to 2.0. diff --git a/g10/getkey.c b/g10/getkey.c index d5d1135..fc3c179 100644 --- a/g10/getkey.c +++ b/g10/getkey.c @@ -498,7 +498,19 @@ get_seckey( PKT_secret_key *sk, u32 *keyid ) ctx.req_usage = sk->req_usage; rc = lookup( &ctx, &kb, 1 ); if ( !rc ) { + u32 skid[2]; + sk_from_block ( &ctx, sk, kb ); + keyid_from_sk ( sk, skid ); + /* + * Make sure it's exact match of keyid. + * If not, it's secret subkey with no public key. + */ + if (!(keyid[0] == skid[0] && keyid[1] == skid[1])) { + log_error (_("key %s: secret key without public key" + " - skipped\n"), keystr(keyid)); + rc = G10ERR_NO_PUBKEY; + } } get_seckey_end( &ctx ); release_kbnode ( kb ); -- From neal at walfield.org Mon May 18 11:57:58 2015 From: neal at walfield.org (Neal H. Walfield) Date: Mon, 18 May 2015 11:57:58 +0200 Subject: [PATCH] pinentry: More gseal/gtk3 compatibility in the gtk+3 UI. In-Reply-To: <1415012703-7153-1-git-send-email-dimitri.j.ledkov@intel.com> References: <1415012703-7153-1-git-send-email-dimitri.j.ledkov@intel.com> Message-ID: <87y4kmus0p.wl-neal@walfield.org> Hi, I've created an issue for this so it doesn't get completely lost: https://bugs.gnupg.org/gnupg/issue1990 Thanks, Neal At Mon, 3 Nov 2014 11:05:03 +0000, Dimitri John Ledkov wrote: > > Signed-off-by: Dimitri John Ledkov > --- > gtk+-2/gtksecentry.c | 84 ++++++++++++++++++++++++++++++------------------- > gtk+-2/pinentry-gtk-2.c | 22 ++++++++----- > 2 files changed, 66 insertions(+), 40 deletions(-) > > diff --git a/gtk+-2/gtksecentry.c b/gtk+-2/gtksecentry.c > index 824d45a..1b630ac 100644 > --- a/gtk+-2/gtksecentry.c > +++ b/gtk+-2/gtksecentry.c > @@ -802,7 +802,7 @@ gtk_secure_entry_get_property(GObject * object, > static void > gtk_secure_entry_init(GtkSecureEntry * entry) > { > - GTK_WIDGET_SET_FLAGS(entry, GTK_CAN_FOCUS); > + gtk_widget_set_can_focus((GtkWidget *)entry, TRUE); > > entry->text_size = MIN_SIZE; > WITH_SECURE_MEM(entry->text = g_malloc(entry->text_size)); > @@ -864,7 +864,7 @@ gtk_secure_entry_realize(GtkWidget * widget) > GdkWindowAttr attributes; > gint attributes_mask; > > - GTK_WIDGET_SET_FLAGS(widget, GTK_REALIZED); > + gtk_widget_set_realized(widget, TRUE); > entry = GTK_SECURE_ENTRY(widget); > > attributes.window_type = GDK_WINDOW_CHILD; > @@ -888,9 +888,9 @@ gtk_secure_entry_realize(GtkWidget * widget) > attributes_mask = > GDK_WA_X | GDK_WA_Y | GDK_WA_VISUAL | GDK_WA_COLORMAP; > > - widget->window = > + gtk_widget_set_window (widget, > gdk_window_new(gtk_widget_get_parent_window(widget), &attributes, > - attributes_mask); > + attributes_mask)); > gdk_window_set_user_data(widget->window, entry); > > get_text_area_size(entry, &attributes.x, &attributes.y, > @@ -911,10 +911,10 @@ gtk_secure_entry_realize(GtkWidget * widget) > > gdk_window_set_background(widget->window, > &widget->style-> > - base[GTK_WIDGET_STATE(widget)]); > + base[gtk_widget_get_state(widget)]); > gdk_window_set_background(entry->text_area, > &widget->style-> > - base[GTK_WIDGET_STATE(widget)]); > + base[gtk_widget_get_state(widget)]); > > gdk_window_show(entry->text_area); > > @@ -1074,7 +1074,7 @@ gtk_secure_entry_size_allocate(GtkWidget * widget, > > widget->allocation = *allocation; > > - if (GTK_WIDGET_REALIZED(widget)) { > + if (gtk_widget_get_realized(widget)) { > /* We call gtk_widget_get_child_requisition, since we want (for > * backwards compatibility reasons) the realization here to > * be affected by the usize of the entry, if set > @@ -1105,9 +1105,14 @@ gtk_secure_entry_draw_frame(GtkWidget * widget) > "interior-focus", &interior_focus, > "focus-line-width", &focus_width, NULL); > > +#if GTK_CHECK_VERSION (2, 24, 0) > + width = gdk_window_get_width(widget->window); > + height = gdk_window_get_height(widget->window); > +#else > gdk_drawable_get_size(widget->window, &width, &height); > +#endif > > - if (GTK_WIDGET_HAS_FOCUS(widget) && !interior_focus) { > + if (gtk_widget_has_focus(widget) && !interior_focus) { > x += focus_width; > y += focus_width; > width -= 2 * focus_width; > @@ -1118,14 +1123,14 @@ gtk_secure_entry_draw_frame(GtkWidget * widget) > GTK_STATE_NORMAL, GTK_SHADOW_IN, > NULL, widget, "entry", x, y, width, height); > > - if (GTK_WIDGET_HAS_FOCUS(widget) && !interior_focus) { > + if (gtk_widget_has_focus(widget) && !interior_focus) { > x -= focus_width; > y -= focus_width; > width += 2 * focus_width; > height += 2 * focus_width; > > gtk_paint_focus(widget->style, widget->window, > - GTK_WIDGET_STATE(widget), NULL, widget, "entry", 0, > + gtk_widget_get_state(widget), NULL, widget, "entry", 0, > 0, width, height); > } > } > @@ -1143,12 +1148,12 @@ gtk_secure_entry_expose(GtkWidget * widget, GdkEventExpose * event) > get_text_area_size(entry, NULL, NULL, &area_width, &area_height); > > gtk_paint_flat_box(widget->style, entry->text_area, > - GTK_WIDGET_STATE(widget), GTK_SHADOW_NONE, > + gtk_widget_get_state(widget), GTK_SHADOW_NONE, > NULL, widget, "entry_bg", > 0, 0, area_width, area_height); > > if ((entry->invisible_char != 0) && > - GTK_WIDGET_HAS_FOCUS(widget) && > + gtk_widget_has_focus(widget) && > entry->selection_bound == entry->current_pos > && entry->cursor_visible) > gtk_secure_entry_draw_cursor(GTK_SECURE_ENTRY(widget)); > @@ -1171,7 +1176,7 @@ gtk_secure_entry_button_press(GtkWidget * widget, GdkEventButton * event) > > entry->button = event->button; > > - if (!GTK_WIDGET_HAS_FOCUS(widget)) { > + if (!gtk_widget_has_focus(widget)) { > entry->in_click = TRUE; > gtk_widget_grab_focus(widget); > entry->in_click = FALSE; > @@ -1248,7 +1253,11 @@ gtk_secure_entry_motion_notify(GtkWidget * widget, GdkEventMotion * event) > > { > gint height; > +#if GTK_CHECK_VERSION (2, 24, 0) > + height = gdk_window_get_height(entry->text_area); > +#else > gdk_drawable_get_size(entry->text_area, NULL, &height); > +#endif > > if (event->y < 0) > tmp_pos = 0; > @@ -1385,7 +1394,7 @@ gtk_secure_entry_grab_focus(GtkWidget * widget) > GtkSecureEntry *entry = GTK_SECURE_ENTRY(widget); > gboolean select_on_focus; > > - GTK_WIDGET_SET_FLAGS(widget, GTK_CAN_DEFAULT); > + gtk_widget_set_can_default(widget, TRUE); > GTK_WIDGET_CLASS(parent_class)->grab_focus(widget); > > /* read current select on focus setting from GtkEntry */ > @@ -1416,16 +1425,16 @@ gtk_secure_entry_state_changed(GtkWidget * widget, > { > GtkSecureEntry *entry = GTK_SECURE_ENTRY(widget); > > - if (GTK_WIDGET_REALIZED(widget)) { > + if (gtk_widget_get_realized(widget)) { > gdk_window_set_background(widget->window, > &widget->style-> > - base[GTK_WIDGET_STATE(widget)]); > + base[gtk_widget_get_state(widget)]); > gdk_window_set_background(entry->text_area, > &widget->style-> > - base[GTK_WIDGET_STATE(widget)]); > + base[gtk_widget_get_state(widget)]); > } > > - if (!GTK_WIDGET_IS_SENSITIVE(widget)) { > + if (!gtk_widget_is_sensitive(widget)) { > /* Clear any selection */ > gtk_editable_select_region(GTK_EDITABLE(entry), entry->current_pos, > entry->current_pos); > @@ -1553,13 +1562,13 @@ gtk_secure_entry_style_set(GtkWidget * widget, GtkStyle * previous_style) > > gtk_secure_entry_recompute(entry); > > - if (previous_style && GTK_WIDGET_REALIZED(widget)) { > + if (previous_style && gtk_widget_get_realized(widget)) { > gdk_window_set_background(widget->window, > &widget->style-> > - base[GTK_WIDGET_STATE(widget)]); > + base[gtk_widget_get_state(widget)]); > gdk_window_set_background(entry->text_area, > &widget->style-> > - base[GTK_WIDGET_STATE(widget)]); > + base[gtk_widget_get_state(widget)]); > } > } > > @@ -2026,7 +2035,7 @@ gtk_secure_entry_real_activate(GtkSecureEntry * entry) > widget != window->default_widget && > !(widget == window->focus_widget && > (!window->default_widget > - || !GTK_WIDGET_SENSITIVE(window->default_widget)))) > + || !gtk_widget_get_sensitive(window->default_widget)))) > gtk_window_activate_default(window); > } > } > @@ -2300,7 +2309,7 @@ gtk_secure_entry_create_layout(GtkSecureEntry * entry, > > pango_dir = pango_find_base_dir(entry->text, entry->n_bytes); > if (pango_dir == PANGO_DIRECTION_NEUTRAL) { > - if (GTK_WIDGET_HAS_FOCUS(widget)) { > + if (gtk_widget_has_focus(widget)) { > GdkDisplay *display = gtk_widget_get_display(widget); > GdkKeymap *keymap = gdk_keymap_get_for_display(display); > pango_dir = gdk_keymap_get_direction(keymap); > @@ -2411,7 +2420,7 @@ gtk_secure_entry_draw_text(GtkSecureEntry * entry) > if (entry->invisible_char == 0) > return; > > - if (GTK_WIDGET_DRAWABLE(entry)) { > + if (gtk_widget_is_drawable((GtkWidget *)entry)) { > PangoLayout *layout = gtk_secure_entry_ensure_layout(entry, TRUE); > gint x, y; > gint start_pos, end_pos; > @@ -2445,7 +2454,7 @@ gtk_secure_entry_draw_text(GtkSecureEntry * entry) > > pango_layout_get_extents(layout, NULL, &logical_rect); > > - if (GTK_WIDGET_HAS_FOCUS(entry)) { > + if (gtk_widget_has_focus((GtkWidget *)entry)) { > selection_gc = widget->style->base_gc[GTK_STATE_SELECTED]; > text_gc = widget->style->text_gc[GTK_STATE_SELECTED]; > } else { > @@ -2508,7 +2517,7 @@ gtk_secure_entry_draw_cursor(GtkSecureEntry * entry) > (GTK_WIDGET(entry))); > PangoDirection keymap_direction = gdk_keymap_get_direction(keymap); > > - if (GTK_WIDGET_DRAWABLE(entry)) { > + if (gtk_widget_is_drawable((GtkWidget *)entry)) { > GtkWidget *widget = GTK_WIDGET(entry); > GdkRectangle cursor_location; > gboolean split_cursor; > @@ -2521,7 +2530,12 @@ gtk_secure_entry_draw_cursor(GtkSecureEntry * entry) > gint x1 = 0; > gint x2 = 0; > > + > +#if GTK_CHECK_VERSION (2, 24, 0) > + text_area_height = gdk_window_get_height(entry->text_area); > +#else > gdk_drawable_get_size(entry->text_area, NULL, &text_area_height); > +#endif > > gtk_secure_entry_get_cursor_locations(entry, &strong_x, &weak_x); > > @@ -2567,7 +2581,7 @@ gtk_secure_entry_draw_cursor(GtkSecureEntry * entry) > static void > gtk_secure_entry_queue_draw(GtkSecureEntry * entry) > { > - if (GTK_WIDGET_REALIZED(entry)) > + if (gtk_widget_get_realized((GtkWidget *)entry)) > gdk_window_invalidate_rect(entry->text_area, NULL, FALSE); > } > > @@ -2656,10 +2670,14 @@ gtk_secure_entry_adjust_scroll(GtkSecureEntry * entry) > PangoLayoutLine *line; > PangoRectangle logical_rect; > > - if (!GTK_WIDGET_REALIZED(entry)) > + if (!gtk_widget_get_realized((GtkWidget *)entry)) > return; > > +#if GTK_CHECK_VERSION (2, 24, 0) > + text_area_width = gdk_window_get_width(entry->text_area); > +#else > gdk_drawable_get_size(entry->text_area, &text_area_width, NULL); > +#endif > text_area_width -= 2 * INNER_BORDER; > > layout = gtk_secure_entry_ensure_layout(entry, TRUE); > @@ -3309,7 +3327,7 @@ cursor_blinks(GtkSecureEntry * entry) > GtkSettings *settings = gtk_widget_get_settings(GTK_WIDGET(entry)); > gboolean blink; > > - if (GTK_WIDGET_HAS_FOCUS(entry) && > + if (gtk_widget_has_focus((GtkWidget *)entry) && > entry->selection_bound == entry->current_pos) { > g_object_get(settings, "gtk-cursor-blink", &blink, NULL); > return blink; > @@ -3334,7 +3352,7 @@ show_cursor(GtkSecureEntry * entry) > if (!entry->cursor_visible) { > entry->cursor_visible = TRUE; > > - if (GTK_WIDGET_HAS_FOCUS(entry) > + if (gtk_widget_has_focus((GtkWidget *)entry) > && entry->selection_bound == entry->current_pos) > gtk_widget_queue_draw(GTK_WIDGET(entry)); > } > @@ -3346,7 +3364,7 @@ hide_cursor(GtkSecureEntry * entry) > if (entry->cursor_visible) { > entry->cursor_visible = FALSE; > > - if (GTK_WIDGET_HAS_FOCUS(entry) > + if (gtk_widget_has_focus((GtkWidget *)entry) > && entry->selection_bound == entry->current_pos) > gtk_widget_queue_draw(GTK_WIDGET(entry)); > } > @@ -3364,14 +3382,14 @@ blink_cb(gpointer data) > > entry = GTK_SECURE_ENTRY(data); > > - if (!GTK_WIDGET_HAS_FOCUS(entry)) { > + if (!gtk_widget_has_focus((GtkWidget *)entry)) { > g_warning > ("GtkSecureEntry - did not receive focus-out-event. If you\n" > "connect a handler to this signal, it must return\n" > "FALSE so the entry gets the event as well"); > } > > - g_assert(GTK_WIDGET_HAS_FOCUS(entry)); > + g_assert(gtk_widget_has_focus((GtkWidget *)entry)); > g_assert(entry->selection_bound == entry->current_pos); > > if (entry->cursor_visible) { > diff --git a/gtk+-2/pinentry-gtk-2.c b/gtk+-2/pinentry-gtk-2.c > index 1a8c083..235bd99 100644 > --- a/gtk+-2/pinentry-gtk-2.c > +++ b/gtk+-2/pinentry-gtk-2.c > @@ -65,7 +65,9 @@ static GtkWidget *qualitybar; > static GtkWidget *insure; > static GtkWidget *time_out; > #endif > +#if !GTK_CHECK_VERSION (2, 12, 0) > static GtkTooltips *tooltips; > +#endif > static gboolean got_input; > > /* Gnome hig small and large space in pixels. */ > @@ -127,7 +129,7 @@ make_transient (GtkWidget *win, GdkEvent *event, gpointer data) > /* Make window transient for the root window. */ > screen = gdk_screen_get_default (); > root = gdk_screen_get_root_window (screen); > - gdk_window_set_transient_for (win->window, root); > + gdk_window_set_transient_for (gtk_widget_get_window(win), root); > } > > > @@ -138,7 +140,7 @@ grab_keyboard (GtkWidget *win, GdkEvent *event, gpointer data) > if (! pinentry->grab) > return FALSE; > > - if (gdk_keyboard_grab (win->window, FALSE, gdk_event_get_time (event))) > + if (gdk_keyboard_grab (gtk_widget_get_window(win), FALSE, gdk_event_get_time (event))) > { > g_critical ("could not grab keyboard"); > grab_failed = 1; > @@ -157,7 +159,7 @@ ungrab_keyboard (GtkWidget *win, GdkEvent *event, gpointer data) > /* gdk_window_set_transient_for cannot be used with parent = NULL to > unset transient hint (unlike gtk_ version which can). Replacement > code is taken from gtk_window_transient_parent_unrealized. */ > - gdk_property_delete (win->window, > + gdk_property_delete (gtk_widget_get_window(win), > gdk_atom_intern_static_string ("WM_TRANSIENT_FOR")); > return FALSE; > } > @@ -330,7 +332,9 @@ create_window (int confirm_mode) > GtkAccelGroup *acc; > gchar *msg; > > +#if !GTK_CHECK_VERSION (2, 12, 0) > tooltips = gtk_tooltips_new (); > +#endif > > /* FIXME: check the grabbing code against the one we used with the > old gpg-agent */ > @@ -471,8 +475,12 @@ create_window (int confirm_mode) > QUALITYBAR_EMPTY_TEXT); > gtk_progress_bar_set_fraction (GTK_PROGRESS_BAR (qualitybar), 0.0); > if (pinentry->quality_bar_tt) > +#if !GTK_CHECK_VERSION (2, 12, 0) > gtk_tooltips_set_tip (GTK_TOOLTIPS (tooltips), qualitybar, > pinentry->quality_bar_tt, ""); > +#else > + gtk_widget_set_tooltip_text (qualitybar, pinentry->quality_bar_tt); > +#endif > gtk_table_attach (GTK_TABLE (table), qualitybar, 1, 2, nrow, nrow+1, > GTK_EXPAND|GTK_FILL, GTK_EXPAND|GTK_FILL, 0, 0); > nrow++; > @@ -561,7 +569,7 @@ create_window (int confirm_mode) > G_CALLBACK (confirm_mode ? confirm_button_clicked > : button_clicked), > (gpointer) CONFIRM_CANCEL); > - GTK_WIDGET_SET_FLAGS (w, GTK_CAN_DEFAULT); > + gtk_widget_set_can_default (w, TRUE); > } > > if (confirm_mode && !pinentry->one_button && pinentry->notok) > @@ -574,7 +582,7 @@ create_window (int confirm_mode) > g_signal_connect (G_OBJECT (w), "clicked", > G_CALLBACK (confirm_button_clicked), > (gpointer) CONFIRM_NOTOK); > - GTK_WIDGET_SET_FLAGS (w, GTK_CAN_DEFAULT); > + gtk_widget_set_can_default (w, TRUE); > } > > if (pinentry->ok) > @@ -602,7 +610,7 @@ create_window (int confirm_mode) > { > g_signal_connect (G_OBJECT (w), "clicked", > G_CALLBACK (button_clicked), "ok"); > - GTK_WIDGET_SET_FLAGS (w, GTK_CAN_DEFAULT); > + gtk_widget_set_can_default (w, TRUE); > gtk_widget_grab_default (w); > g_signal_connect_object (G_OBJECT (entry), "focus_in_event", > G_CALLBACK (gtk_widget_grab_default), > @@ -613,7 +621,7 @@ create_window (int confirm_mode) > g_signal_connect (G_OBJECT (w), "clicked", > G_CALLBACK(confirm_button_clicked), > (gpointer) CONFIRM_OK); > - GTK_WIDGET_SET_FLAGS (w, GTK_CAN_DEFAULT); > + gtk_widget_set_can_default (w, TRUE); > } > > gtk_window_set_position (GTK_WINDOW (win), GTK_WIN_POS_CENTER); > -- > 2.1.0 > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > From wk at gnupg.org Mon May 18 12:12:14 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 18 May 2015 12:12:14 +0200 Subject: gpg-agent features of loopback-pinentry mode, preset_passphrase In-Reply-To: <554C309F.5010706@fsij.org> (NIIBE Yutaka's message of "Fri, 08 May 2015 12:42:23 +0900") References: <554C2094.20904@fsij.org> <874mnnlqxn.fsf@alice.fifthhorseman.net> <554C309F.5010706@fsij.org> Message-ID: <871tiegpoh.fsf@vigenere.g10code.de> On Fri, 8 May 2015 05:42, gniibe at fsij.org said: > When --passphrase option is offered, gpg checks gpg-agent feature > availability (before reading passphrase from file/fd), and gives > explanation if not. And gpg/gpg-agent manual should address the > relationship of --passphrase and loopback-pinentry mode. Actually, I expected that the loopback mode would be used with --command-fd and not with the one-time setting of a passphrase. I kept passphrase working because that can be used for symmteric encryption. After all loopback mode is a hack to bypass the standard way of asking for passphrases and to allow a simpler thing than a pinentry-wrapper (e.g. for use by CGIs). We should never advertise it as a way to query an unprotect-the-secret-key-passphrase - this would defeat the split between gpg and gpg-agent. Your suggestion to query the availibility of feature first is good from the average user perspective. However, average users should not use the loopback mode anyway (unless a tool uses it invisible). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Mon May 18 16:10:17 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 18 May 2015 10:10:17 -0400 Subject: GPGME pyme branch ready to merge with master In-Reply-To: <5557A7F2.5090002@adversary.org> References: <5557A7F2.5090002@adversary.org> Message-ID: <87twvayo1i.fsf@alice.fifthhorseman.net> On Sat 2015-05-16 16:26:26 -0400, Ben McGinnes wrote: > As the subject indicates, the pyme branch in the GPGME repo is > ready to be merged with master. It will almost certainly produce a > bunch of PEP8 complaints about trailing whitespace, but this is > primarily due to checking files it shouldn't be checking, like the > license files, documentation and the big one is the text copy of the > decade or so of Python 2 PyME commit logs. Is there a reason to keep the trailing whitespace in the commit logs, license files, and documentation? If there's no reason that we need it, i would say clear it out so that legit PEP8 complaints don't get lost in the noise. (i personally see no problem with "altering the historical record" of commit logs by stripping trailing whitespace as long as it's documented clearly in the revision control history) --dkg From gniibe at fsij.org Tue May 19 03:50:30 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 19 May 2015 10:50:30 +0900 Subject: [PATCH] Improve handling of no corresponding public key for a private key In-Reply-To: <55594E21.7050802@fsij.org> References: <55594E21.7050802@fsij.org> Message-ID: <555A96E6.5060600@fsij.org> On 05/18/2015 11:27 AM, NIIBE Yutaka wrote: > This is a fix for the issue 1422: https://bugs.gnupg.org/gnupg/issue1422 Committed to 1.4 and 2.0. -- From gniibe at fsij.org Tue May 19 03:51:52 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 19 May 2015 10:51:52 +0900 Subject: [PATCH] g10: detects public key encryption packet error properly In-Reply-To: <554C1EBE.7050401@fsij.org> References: <554C1EBE.7050401@fsij.org> Message-ID: <555A9738.800@fsij.org> On 05/08/2015 11:26 AM, NIIBE Yutaka wrote: > The detection of public key encryption packet error should be done > earlier in mainproc.c. Committed to the master. It was backported to 2.0 and 1.4, too. -- From gniibe at fsij.org Tue May 19 07:03:21 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 19 May 2015 14:03:21 +0900 Subject: gpg-agent features of loopback-pinentry mode, preset_passphrase In-Reply-To: <871tiegpoh.fsf@vigenere.g10code.de> References: <554C2094.20904@fsij.org> <874mnnlqxn.fsf@alice.fifthhorseman.net> <554C309F.5010706@fsij.org> <871tiegpoh.fsf@vigenere.g10code.de> Message-ID: <555AC419.60801@fsij.org> On 05/18/2015 07:12 PM, Werner Koch wrote: > Actually, I expected that the loopback mode would be used with > --command-fd and not with the one-time setting of a passphrase. I kept > passphrase working because that can be used for symmteric encryption. > > After all loopback mode is a hack to bypass the standard way of asking > for passphrases and to allow a simpler thing than a pinentry-wrapper > (e.g. for use by CGIs). We should never advertise it as a way to query > an unprotect-the-secret-key-passphrase - this would defeat the split > between gpg and gpg-agent. > > Your suggestion to query the availibility of feature first is good from > the average user perspective. However, average users should not use the > loopback mode anyway (unless a tool uses it invisible). Thank you for the explanation. I understand the intent and background. I decline adding error message to user for suggesting loopback mode. Well, let's consider how to handle the issue 1928: https://bugs.gnupg.org/gnupg/issue1928 With classic and stable versions, it worked: (0) gpg --batch --passphrase-file pass-file --decrypt encrypted-file Now with 2.1, what's the answer to the existing script(s)? Using command-file, it would be: (1) gpg --batch --pinentry-mode=loopback --command-file input-file \ --decrypt encrypted-file This requires allow-loopback-pinentry option in .gnupg/gpg-agent.conf. I understand that using loopback mode is for expert, so, I think that the requirement of configuration of allow-loopback-pinentry is legitimate (it makes sense to have default as not allowing loopback mode). Although it would not be intended, following also works with 2.1 (with allow-loopback-pinentry option of gpg-agent). (2) gpg2 --batch --pinentry-mode=loopback --passphrase-file pass-file \ --decrypt encrypted-file While the split between gpg and gpg-agent highly makes sense for interactive usages, in general, there might still be valid usages where it doesn't matter much and where it's OK to invoke gpg-agent for every invocation of gpg command. While we lead/ask people to pinentry wrapper solution or (1) with GnuPG 2.1, I think that requiring change from (0) to (1) or (2) would be still a regression. Just in case, following is a patch to support (0) with GnuPG 2.1. It let give gpg to pass "OPTION pinentry-mode=loopback" when the function have_static_passphrase returns true and to offer the string of get_static_passphrase to gpg-agent. BTW, in the commit of 1cd6445eec4c3642ad92afb02f3563a01cc10c10 in January 30, 2013, I think that the comment /* We do not pass errors to avoid breaking other code. */ should have been removed. diff --git a/g10/call-agent.c b/g10/call-agent.c index edee66e..258a48b 100644 --- a/g10/call-agent.c +++ b/g10/call-agent.c @@ -163,18 +163,18 @@ default_inq_cb (void *opaque, const char *line) if (err) log_error (_("failed to proxy %s inquiry to client\n"), "PINENTRY_LAUNCHED"); - /* We do not pass errors to avoid breaking other code. */ + return err; } - else if ((has_leading_keyword (line, "PASSPHRASE") - || has_leading_keyword (line, "NEW_PASSPHRASE")) - && opt.pinentry_mode == PINENTRY_MODE_LOOPBACK) + + if ((has_leading_keyword (line, "PASSPHRASE") + || has_leading_keyword (line, "NEW_PASSPHRASE"))) { if (have_static_passphrase ()) { const char *s = get_static_passphrase (); - err = assuan_send_data (parm->ctx, s, strlen (s)); + return assuan_send_data (parm->ctx, s, strlen (s)); } - else + else if (opt.batch || opt.pinentry_mode == PINENTRY_MODE_LOOPBACK) { char *pw; @@ -189,11 +189,11 @@ default_inq_cb (void *opaque, const char *line) else err = assuan_send_data (parm->ctx, pw, strlen (pw)); xfree (pw); + return err; } } - else - log_debug ("ignoring gpg-agent inquiry '%s'\n", line); + log_debug ("ignoring gpg-agent inquiry '%s'\n", line); return err; } @@ -306,9 +306,10 @@ start_agent (ctrl_t ctrl, int for_card) assuan_transact (agent_ctx, "OPTION agent-awareness=2.1.0", NULL, NULL, NULL, NULL, NULL, NULL); /* Pass on the pinentry mode. */ - if (opt.pinentry_mode) + if (have_static_passphrase () || opt.pinentry_mode) { char *tmp = xasprintf ("OPTION pinentry-mode=%s", + opt.batch ? "loopback" : str_pinentry_mode (opt.pinentry_mode)); rc = assuan_transact (agent_ctx, tmp, NULL, NULL, NULL, NULL, NULL, NULL); -- From hagman33 at icloud.com Tue May 19 07:05:58 2015 From: hagman33 at icloud.com (Aaron Haggerty) Date: Mon, 18 May 2015 23:05:58 -0600 Subject: gpg-agent features of loopback-pinentry mode, preset_passphrase In-Reply-To: <555AC419.60801@fsij.org> References: <554C2094.20904@fsij.org> <874mnnlqxn.fsf@alice.fifthhorseman.net> <554C309F.5010706@fsij.org> <871tiegpoh.fsf@vigenere.g10code.de> <555AC419.60801@fsij.org> Message-ID: <40A0C239-5360-4D3C-86A9-570F3095295A@icloud.com> Fuck u A > On May 18, 2015, at 11:03 PM, NIIBE Yutaka wrote: > >> On 05/18/2015 07:12 PM, Werner Koch wrote: >> Actually, I expected that the loopback mode would be used with >> --command-fd and not with the one-time setting of a passphrase. I kept >> passphrase working because that can be used for symmteric encryption. >> >> After all loopback mode is a hack to bypass the standard way of asking >> for passphrases and to allow a simpler thing than a pinentry-wrapper >> (e.g. for use by CGIs). We should never advertise it as a way to query >> an unprotect-the-secret-key-passphrase - this would defeat the split >> between gpg and gpg-agent. >> >> Your suggestion to query the availibility of feature first is good from >> the average user perspective. However, average users should not use the >> loopback mode anyway (unless a tool uses it invisible). > > Thank you for the explanation. I understand the intent and > background. > > I decline adding error message to user for suggesting loopback mode. > > > Well, let's consider how to handle the issue 1928: > https://bugs.gnupg.org/gnupg/issue1928 > > With classic and stable versions, it worked: > > (0) gpg --batch --passphrase-file pass-file --decrypt encrypted-file > > Now with 2.1, what's the answer to the existing script(s)? > > Using command-file, it would be: > > (1) gpg --batch --pinentry-mode=loopback --command-file input-file \ > --decrypt encrypted-file > > This requires allow-loopback-pinentry option in .gnupg/gpg-agent.conf. > > I understand that using loopback mode is for expert, so, I think that > the requirement of configuration of allow-loopback-pinentry is > legitimate (it makes sense to have default as not allowing loopback > mode). > > Although it would not be intended, following also works with 2.1 (with > allow-loopback-pinentry option of gpg-agent). > > (2) gpg2 --batch --pinentry-mode=loopback --passphrase-file pass-file \ > --decrypt encrypted-file > > > While the split between gpg and gpg-agent highly makes sense for > interactive usages, in general, there might still be valid usages > where it doesn't matter much and where it's OK to invoke gpg-agent for > every invocation of gpg command. > > While we lead/ask people to pinentry wrapper solution or (1) with > GnuPG 2.1, I think that requiring change from (0) to (1) or (2) would > be still a regression. > > Just in case, following is a patch to support (0) with GnuPG 2.1. It > let give gpg to pass "OPTION pinentry-mode=loopback" when the function > have_static_passphrase returns true and to offer the string of > get_static_passphrase to gpg-agent. > > > BTW, in the commit of 1cd6445eec4c3642ad92afb02f3563a01cc10c10 in > January 30, 2013, I think that the comment > > /* We do not pass errors to avoid breaking other code. */ > > should have been removed. > > > diff --git a/g10/call-agent.c b/g10/call-agent.c > index edee66e..258a48b 100644 > --- a/g10/call-agent.c > +++ b/g10/call-agent.c > @@ -163,18 +163,18 @@ default_inq_cb (void *opaque, const char *line) > if (err) > log_error (_("failed to proxy %s inquiry to client\n"), > "PINENTRY_LAUNCHED"); > - /* We do not pass errors to avoid breaking other code. */ > + return err; > } > - else if ((has_leading_keyword (line, "PASSPHRASE") > - || has_leading_keyword (line, "NEW_PASSPHRASE")) > - && opt.pinentry_mode == PINENTRY_MODE_LOOPBACK) > + > + if ((has_leading_keyword (line, "PASSPHRASE") > + || has_leading_keyword (line, "NEW_PASSPHRASE"))) > { > if (have_static_passphrase ()) > { > const char *s = get_static_passphrase (); > - err = assuan_send_data (parm->ctx, s, strlen (s)); > + return assuan_send_data (parm->ctx, s, strlen (s)); > } > - else > + else if (opt.batch || opt.pinentry_mode == PINENTRY_MODE_LOOPBACK) > { > char *pw; > > @@ -189,11 +189,11 @@ default_inq_cb (void *opaque, const char *line) > else > err = assuan_send_data (parm->ctx, pw, strlen (pw)); > xfree (pw); > + return err; > } > } > - else > - log_debug ("ignoring gpg-agent inquiry '%s'\n", line); > > + log_debug ("ignoring gpg-agent inquiry '%s'\n", line); > return err; > } > > @@ -306,9 +306,10 @@ start_agent (ctrl_t ctrl, int for_card) > assuan_transact (agent_ctx, "OPTION agent-awareness=2.1.0", > NULL, NULL, NULL, NULL, NULL, NULL); > /* Pass on the pinentry mode. */ > - if (opt.pinentry_mode) > + if (have_static_passphrase () || opt.pinentry_mode) > { > char *tmp = xasprintf ("OPTION pinentry-mode=%s", > + opt.batch ? "loopback" : > str_pinentry_mode (opt.pinentry_mode)); > rc = assuan_transact (agent_ctx, tmp, > NULL, NULL, NULL, NULL, NULL, NULL); > -- > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From bjk at luxsci.net Tue May 19 12:44:27 2015 From: bjk at luxsci.net (Ben Kibbey) Date: Tue, 19 May 2015 06:44:27 -0400 Subject: gpg-agent features of loopback-pinentry mode, preset_passphrase In-Reply-To: <871tiegpoh.fsf@vigenere.g10code.de> References: <554C2094.20904@fsij.org> <874mnnlqxn.fsf@alice.fifthhorseman.net> <554C309F.5010706@fsij.org> <871tiegpoh.fsf@vigenere.g10code.de> Message-ID: <1432032302-353352.688746913.ft4JAiSDp000769@rs146.luxsci.com> On Mon, May 18, 2015 at 12:12:14PM +0200, Werner Koch wrote: > On Fri, 8 May 2015 05:42, gniibe at fsij.org said: > > > When --passphrase option is offered, gpg checks gpg-agent feature > > availability (before reading passphrase from file/fd), and gives > > explanation if not. And gpg/gpg-agent manual should address the > > relationship of --passphrase and loopback-pinentry mode. > > Actually, I expected that the loopback mode would be used with > --command-fd and not with the one-time setting of a passphrase. I kept > passphrase working because that can be used for symmteric encryption. While looking at the code for --gen-key I noticed that gpg-agent isn't used for getting the passphrase. Is it possible to do this? Or would that make creating the public key impossible? I ask because --command-fd isn't considered during --gen-key making pinentry-mode=loopback broken. I have patches for fixing --command-fd (bjk/passphrase-inquire branches of gpgme and gnupg) but those still don't use gpg-agent during --gen-key. Maybe there is a reason why --gen-key isn't supposed to work while using pinentry-mode=loopback? -- Ben Kibbey From gniibe at fsij.org Tue May 19 13:01:14 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 19 May 2015 20:01:14 +0900 Subject: [PATCH] g10: Fix a race condition initially creating trustdb Message-ID: <555B17FA.9070601@fsij.org> Hello, This is a fix for the issue 1675: https://bugs.gnupg.org/gnupg/issue1675 The commit b73ae3ca36547939c9aaf54c0d05fbc93d47c096 in Sep 23, 2011 changed make_dotlock into dotlock_take, but there was a mistake that it changed to dotlock_make (for riscos). The commit acde3f8ea660ced34ebe34f7d31185c9fdea8295 in Sep 22, 2011 said "Remove support for RISCOS from dotlock.c", so, I think that "ifdef __riscos__ in dotlock.c" is dead code. Following patch (only) implements the mutual exclusion between: * initial creation of trustdb.gpg (write access) in tdbio_set_dbname * reading from trustdb.gpg in tdbio_read_record (read access) I read through the code for trustdb.gpg. If I read the code correctly, it implements mutual exclusions between write accesses to trustdb.gpg, but there are still races between: * writing to trustdb.gpg * reading from trustdb.gpg I'll try to make reproducible case(s) and to consider fixes for those. This patch is tested against the minimal reproducible case. It would be better to implement multiple-readers-single-writer-lock, but assuming the write access to trustdb is rare, simple mutual exclusion would be just acceptable. Meanwhile, please review following patch. diff --git a/g10/tdbio.c b/g10/tdbio.c index 69438b4..08e2ab9 100644 --- a/g10/tdbio.c +++ b/g10/tdbio.c @@ -548,14 +548,18 @@ tdbio_set_dbname( const char *new_dbname, int create, int *r_nofile) xfree(db_name); db_name = fname; -#ifdef __riscos__ + if( !lockhandle ) lockhandle = dotlock_create (db_name, 0); if( !lockhandle ) log_fatal( _("can't create lock for '%s'\n"), db_name ); - if( dotlock_make (lockhandle, -1) ) - log_fatal( _("can't lock '%s'\n"), db_name ); -#endif /* __riscos__ */ + if( !is_locked ) { + if( dotlock_take (lockhandle, -1) ) + log_fatal( _("can't lock '%s'\n"), db_name ); + else + is_locked = 1; + } + oldmask=umask(077); if (is_secured_filename (fname)) { fp = NULL; @@ -573,13 +577,6 @@ tdbio_set_dbname( const char *new_dbname, int create, int *r_nofile) log_fatal (_("can't open '%s': %s\n"), db_name, strerror (errno)); -#ifndef __riscos__ - if( !lockhandle ) - lockhandle = dotlock_create (db_name, 0); - if( !lockhandle ) - log_fatal( _("can't create lock for '%s'\n"), db_name ); -#endif /* !__riscos__ */ - rc = create_version_record (); if( rc ) log_fatal( _("%s: failed to create version record: %s"), @@ -591,6 +588,10 @@ tdbio_set_dbname( const char *new_dbname, int create, int *r_nofile) if( !opt.quiet ) log_info(_("%s: trustdb created\n"), db_name); + if( !opt.lock_once ) { + if( !dotlock_release( lockhandle ) ) + is_locked = 0; + } return 0; } } @@ -619,10 +620,13 @@ open_db() lockhandle = dotlock_create (db_name, 0); if (!lockhandle ) log_fatal( _("can't create lock for '%s'\n"), db_name ); -#ifdef __riscos__ - if (dotlock_take (lockhandle, -1) ) - log_fatal( _("can't lock '%s'\n"), db_name ); -#endif /* __riscos__ */ + if( !is_locked ) { + if( dotlock_take( lockhandle, -1 ) ) + log_fatal("can't acquire lock - giving up\n"); + else + is_locked = 1; + } + #ifdef HAVE_W32CE_SYSTEM { DWORD prevrc = 0; @@ -659,6 +663,11 @@ open_db() /* Read the version record. */ if (tdbio_read_record (0, &rec, RECTYPE_VER ) ) log_fatal( _("%s: invalid trustdb\n"), db_name ); + + if( !opt.lock_once ) { + if( !dotlock_release( lockhandle ) ) + is_locked = 0; + } } -- From neal at walfield.org Tue May 19 15:36:40 2015 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 19 May 2015 15:36:40 +0200 Subject: gnome keyring & gpg agent: backport to gpg 2.0 done In-Reply-To: <877fsbvwhr.wl-neal@walfield.org> References: <87twvg8l4r.fsf@alice.fifthhorseman.net> <87bnhowa4x.wl-neal@walfield.org> <87twvfmnhx.fsf@vigenere.g10code.de> <87fv6z7032.fsf@alice.fifthhorseman.net> <877fsbvwhr.wl-neal@walfield.org> Message-ID: <87h9r8pu3b.wl-neal@walfield.org> At Thu, 14 May 2015 20:34:40 +0200, Neal H. Walfield wrote: > The pieces are now basically in place to fix the GPG Agent / Gnome > Keyring issue. There are three minor issues: > > - There are a couple of small deficiencies in the gnome3 pinentry > (e.g., no one button confirmation messages, but this is easily > worked around). These deficiencies have more to do with > limitations in Gcr than with the Pinentry implementation. > > - Gnome Keyring's maintainer hasn't yet ripped out the GPG Agent > support, but fully agrees with the changes so far. (Of course, > the GPG Agent proxy can be trivially disabled since it is a > separate component.) There is a GSoC project that is being managed by Stef (the maintainer of GNOME Keyring). Part of the project is to finish these items. But, again, these items are primarily aesthetic: there is no reason that distributions can't ship the new pinentry now and disable GNOME Keyring's gpg agent proxy. > - To fully replace Gnome Keyring's GPG Agent Proxy, a couple of > minor changes had to be made to GPG. These are so far only in > 2.1, but I will backport them to 2.0 soon. I've now finished this. Neal From gniibe at fsij.org Wed May 20 02:19:03 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 20 May 2015 09:19:03 +0900 Subject: [PATCH] g10: Fix a race condition initially creating trustdb In-Reply-To: <555B17FA.9070601@fsij.org> References: <555B17FA.9070601@fsij.org> Message-ID: <555BD2F7.8000706@fsij.org> On 05/19/2015 08:01 PM, NIIBE Yutaka wrote: > This is a fix for the issue 1675: > https://bugs.gnupg.org/gnupg/issue1675 Sorry, the fix of mine is in-mature, there is still a race between initial creators (two processes could try to create initial trustdb.gpg, as checking by access(2) is done with no lock). I'll post updated version, soon. > I read through the code for trustdb.gpg. If I read the code > correctly, it implements mutual exclusions between write accesses to > trustdb.gpg, but there are still races between: > > * writing to trustdb.gpg > > * reading from trustdb.gpg When writing this message, I assumed that write(2) could be non-atomic (depending on the file system), when the access is at the boundary of block size. In this (wrong) theory, read(2) from another process would see inconsistent data. (Since TRUST_RECORD_LEN=40, I had a concern. If its size were 32 or 64, I had not.) I checked POSIX and it seems the atomicity is guaranteed: http://pubs.opengroup.org/onlinepubs/9699919799/functions/write.html So, I don't need to care. But, at least with ext4 in 2011, we had a issue: http://thread.gmane.org/gmane.comp.file-systems.ext4/24425 -- From gniibe at fsij.org Wed May 20 05:05:55 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 20 May 2015 12:05:55 +0900 Subject: [PATCH] g10: Fix a race condition initially creating trustdb In-Reply-To: <555BD2F7.8000706@fsij.org> References: <555B17FA.9070601@fsij.org> <555BD2F7.8000706@fsij.org> Message-ID: <555BFA13.9010604@fsij.org> On 05/20/2015 09:19 AM, NIIBE Yutaka wrote: > I'll post updated version, soon. Here is the one. Assuming write(2) is atomic, the comment I wrote (saying: multiple race conditions) in the issue 1675 is wrong. The race condition was only here (nowhere than that). Tested against the minimal reproducible test case. The bug exists in 1.4 and in 2.0, too. diff --git a/g10/tdbio.c b/g10/tdbio.c index 69438b4..74127d5 100644 --- a/g10/tdbio.c +++ b/g10/tdbio.c @@ -504,6 +504,21 @@ tdbio_set_dbname( const char *new_dbname, int create, int *r_nofile) else fname = xstrdup (new_dbname); + xfree (db_name); + db_name = fname; + + if( !lockhandle ) + lockhandle = dotlock_create (db_name, 0); + if( !lockhandle ) + log_fatal( _("can't create lock for '%s'\n"), db_name ); + + if( !is_locked ) { + if( dotlock_take( lockhandle, -1 ) ) + log_fatal( _("can't lock '%s'\n"), db_name ); + else + is_locked = 1; + } + if( access( fname, R_OK ) ) { #ifdef HAVE_W32CE_SYSTEM /* We know how the cegcc implementation of access works ;-). */ @@ -512,11 +527,9 @@ tdbio_set_dbname( const char *new_dbname, int create, int *r_nofile) else gpg_err_set_errno (EIO); #endif /*HAVE_W32CE_SYSTEM*/ - if( errno != ENOENT ) { - log_error( _("can't access '%s': %s\n"), fname, strerror(errno) ); - xfree(fname); - return GPG_ERR_TRUSTDB; - } + if( errno != ENOENT ) + log_fatal( _("can't access '%s': %s\n"), fname, strerror(errno) ); + if (!create) *r_nofile = 1; else { @@ -546,16 +559,6 @@ tdbio_set_dbname( const char *new_dbname, int create, int *r_nofile) } *p = save_slash; - xfree(db_name); - db_name = fname; -#ifdef __riscos__ - if( !lockhandle ) - lockhandle = dotlock_create (db_name, 0); - if( !lockhandle ) - log_fatal( _("can't create lock for '%s'\n"), db_name ); - if( dotlock_make (lockhandle, -1) ) - log_fatal( _("can't lock '%s'\n"), db_name ); -#endif /* __riscos__ */ oldmask=umask(077); if (is_secured_filename (fname)) { fp = NULL; @@ -573,13 +576,6 @@ tdbio_set_dbname( const char *new_dbname, int create, int *r_nofile) log_fatal (_("can't open '%s': %s\n"), db_name, strerror (errno)); -#ifndef __riscos__ - if( !lockhandle ) - lockhandle = dotlock_create (db_name, 0); - if( !lockhandle ) - log_fatal( _("can't create lock for '%s'\n"), db_name ); -#endif /* !__riscos__ */ - rc = create_version_record (); if( rc ) log_fatal( _("%s: failed to create version record: %s"), @@ -590,12 +586,14 @@ tdbio_set_dbname( const char *new_dbname, int create, int *r_nofile) if( !opt.quiet ) log_info(_("%s: trustdb created\n"), db_name); - - return 0; } } - xfree(db_name); - db_name = fname; + + if( !opt.lock_once ) { + if( !dotlock_release( lockhandle ) ) + is_locked = 0; + } + return 0; } @@ -615,14 +613,6 @@ open_db() assert( db_fd == -1 ); - if (!lockhandle ) - lockhandle = dotlock_create (db_name, 0); - if (!lockhandle ) - log_fatal( _("can't create lock for '%s'\n"), db_name ); -#ifdef __riscos__ - if (dotlock_take (lockhandle, -1) ) - log_fatal( _("can't lock '%s'\n"), db_name ); -#endif /* __riscos__ */ #ifdef HAVE_W32CE_SYSTEM { DWORD prevrc = 0; -- From dfalko at digiflak.com Wed May 20 15:27:11 2015 From: dfalko at digiflak.com (Dmitry Falko) Date: Wed, 20 May 2015 16:27:11 +0300 Subject: [PATCH] dirmngr_ldap: support ldap secure connection(ldaps) Message-ID: <555C8BAF.1060202@digiflak.com> Hello! I encountered a problem connecting to the LDAP server via TLS and wrote a small patch, send it as is. * dirmngr.h (ldap_server_s): add schema field * dirmngr_ldap.c (fetch_ldap): ldaps support * ldap.c (make_url, start_cert_fetch_ldap): add schema * ldapserver.c (ldapserver_parse_one): parse schema * server.c (lookup_cert_by_pattern): additional log info dirmngr_ldap can retrieve certificates from LDAP server by TLS(using ldaps protocol). Protocol can be set in dirmngr_ldapserver.conf: hostname:port:username:password:base_dn:schema If not set use ldap.By default dirmngr_ldap use /etc/ssl/CA(dirmngr_ldap.c CA_CERT_DEFAULT) CA certificate, user can set DIRMNGR_LDAP_CACERT env variable to override this value. --- dirmngr/dirmngr.h | 1 + dirmngr/dirmngr_ldap.c | 61 +++++++++++++++++++++++++++++++++++++++++++++----- dirmngr/ldap.c | 24 +++++++++++++++----- dirmngr/ldapserver.c | 5 +++++ dirmngr/server.c | 3 ++- 5 files changed, 81 insertions(+), 13 deletions(-) diff --git a/dirmngr/dirmngr.h b/dirmngr/dirmngr.h index 4f037e7..3406494 100644 --- a/dirmngr/dirmngr.h +++ b/dirmngr/dirmngr.h @@ -46,6 +46,7 @@ struct ldap_server_s char *user; char *pass; char *base; + char *schema; }; typedef struct ldap_server_s *ldap_server_t; diff --git a/dirmngr/dirmngr_ldap.c b/dirmngr/dirmngr_ldap.c index 61a7e39..8bb739c 100644 --- a/dirmngr/dirmngr_ldap.c +++ b/dirmngr/dirmngr_ldap.c @@ -46,6 +46,8 @@ /* For OpenLDAP, to enable the API that we're using. */ # define LDAP_DEPRECATED 1 # include + /* FIXME: use configure script to set this define */ +# define CA_CERT_DEFAULT ("/etc/ssl/CA") #endif @@ -571,9 +573,10 @@ fetch_ldap (my_opt_t myopt, const char *url, const LDAPURLDesc *ludp) LDAP *ld; LDAPMessage *msg; int rc = 0; - char *host, *dn, *filter, *attrs[2], *attr; + char *host, *dn, *filter, *attrs[2], *attr, *ca_cert, *ldap_url; int port; int ret; + int err; host = myopt->host? myopt->host : ludp->lud_host; port = myopt->port? myopt->port : ludp->lud_port; @@ -583,6 +586,17 @@ fetch_ldap (my_opt_t myopt, const char *url, const LDAPURLDesc *ludp) attrs[1] = NULL; attr = attrs[0]; + ca_cert = getenv("DIRMNGR_LDAP_CACERT"); + if(!ca_cert) + { + if (myopt->verbose) + { + log_info("Using default CA certificate"); + } + + ca_cert = CA_CERT_DEFAULT; + } + if (!port) port = (ludp->lud_scheme && !strcmp (ludp->lud_scheme, "ldaps"))? 636:389; @@ -628,23 +642,58 @@ fetch_ldap (my_opt_t myopt, const char *url, const LDAPURLDesc *ludp) set_timeout (myopt); + + ldap_url = alloca(4 + strlen(ludp->lud_scheme) + + strlen(host) + + 5); /* for port */ + sprintf(ldap_url, "%s://%s:%d", ludp->lud_scheme, host, port); + npth_unprotect (); - ld = my_ldap_init (host, port); + err = ldap_initialize(&ld, ldap_url) ; npth_protect (); - if (!ld) + if (err != LDAP_SUCCESS) { - log_error (_("LDAP init to '%s:%d' failed: %s\n"), - host, port, strerror (errno)); + log_error (_("LDAP init to '%s' failed: %s\n"), + ldap_url, ldap_err2string (errno)); return -1; } npth_unprotect (); + + if(!strcmp (ludp->lud_scheme, "ldaps")) + { + /* Additional options for tls connection */ + /*FIXME: LDAP_OPT_X_TLS_NEVER or LDAP_OPT_X_TLS_HARD, add option*/ + int req_cert = LDAP_OPT_X_TLS_NEVER; + + err = ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTFILE, + ca_cert); + npth_protect (); + if(err != LDAP_SUCCESS) + { + log_error (_("setting ca-certificate failed: %s\n"), + ldap_err2string (err)); + return -1; + } + npth_unprotect (); + err=ldap_set_option(NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, + &req_cert); + npth_protect (); + if(err != LDAP_SUCCESS) + { + log_error (_("setting require certificate failed: %s\n"), + ldap_err2string (err)); + return -1; + } + npth_unprotect (); + } + /* Fixme: Can we use MYOPT->user or is it shared with other theeads?. */ ret = my_ldap_simple_bind_s (ld, myopt->user, myopt->pass); npth_protect (); if (ret) { log_error (_("binding to '%s:%d' failed: %s\n"), - host, port, strerror (errno)); + host, port, ldap_err2string (errno)); ldap_unbind (ld); return -1; } diff --git a/dirmngr/ldap.c b/dirmngr/ldap.c index e4c6aa2..d4e0730 100644 --- a/dirmngr/ldap.c +++ b/dirmngr/ldap.c @@ -423,10 +423,10 @@ escape4url (const char *string) need the host and port because this will be specified using the override options. */ static gpg_error_t -make_url (char **url, const char *dn, const char *filter) +make_url (char **url, const char *dn, const char *filter, const char *schema) { gpg_error_t err; - char *u_dn, *u_filter; + char *u_dn, *u_filter, *u_schema; char const attrs[] = (USERCERTIFICATE "," /* USERSMIMECERTIFICATE "," */ CACERTIFICATE "," @@ -434,6 +434,10 @@ make_url (char **url, const char *dn, const char *filter) *url = NULL; + u_schema = escape4url (schema); + if(!u_schema) + return gpg_error_from_errno (errno); + u_dn = escape4url (dn); if (!u_dn) return gpg_error_from_errno (errno); @@ -445,7 +449,8 @@ make_url (char **url, const char *dn, const char *filter) xfree (u_dn); return err; } - *url = malloc ( 8 + strlen (u_dn) + *url = malloc ( 4 + strlen (schema) + + strlen (u_dn) + 1 + strlen (attrs) + 5 + strlen (u_filter) + 1 ); if (!*url) @@ -456,12 +461,14 @@ make_url (char **url, const char *dn, const char *filter) return err; } - stpcpy (stpcpy (stpcpy (stpcpy (stpcpy (stpcpy (*url, "ldap:///"), + stpcpy (stpcpy (stpcpy (stpcpy (stpcpy (stpcpy (stpcpy(*url, u_schema), + ":///"), u_dn), "?"), attrs), "?sub?"), u_filter); + xfree (u_schema); xfree (u_dn); xfree (u_filter); return 0; @@ -525,6 +532,7 @@ start_cert_fetch_ldap (ctrl_t ctrl, cert_fetch_context_t *context, const char *user; const char *pass; const char *base; + const char *schema; const char *argv[50]; int argc; char portbuf[30], timeoutbuf[30]; @@ -538,6 +546,7 @@ start_cert_fetch_ldap (ctrl_t ctrl, cert_fetch_context_t *context, user = server->user; pass = server->pass; base = server->base; + schema = server->schema; } else /* Use a default server. */ return gpg_error (GPG_ERR_NOT_IMPLEMENTED); @@ -545,6 +554,9 @@ start_cert_fetch_ldap (ctrl_t ctrl, cert_fetch_context_t *context, if (!base) base = ""; + if(!schema) + schema = "ldap"; + argc = 0; if (pass) /* Note: Must be the first item. */ { @@ -606,9 +618,9 @@ start_cert_fetch_ldap (ctrl_t ctrl, cert_fetch_context_t *context, return gpg_error (GPG_ERR_INV_USER_ID); } if ((sl->flags & 1)) - err = make_url (&url, sl->d, "objectClass=*"); + err = make_url (&url, sl->d, "objectClass=*", schema); else - err = make_url (&url, base, sl->d); + err = make_url (&url, base, sl->d, schema); free_strlist (sl); if (err) { diff --git a/dirmngr/ldapserver.c b/dirmngr/ldapserver.c index 16e13e2..87c8b47 100644 --- a/dirmngr/ldapserver.c +++ b/dirmngr/ldapserver.c @@ -115,6 +115,11 @@ ldapserver_parse_one (char *line, server->base = xstrdup (p); break; + case 6: + if (*p) + server->schema = xstrdup (p); + break; + default: /* (We silently ignore extra fields.) */ break; diff --git a/dirmngr/server.c b/dirmngr/server.c index 1b7e9e9..bcf83f9 100644 --- a/dirmngr/server.c +++ b/dirmngr/server.c @@ -1259,7 +1259,8 @@ lookup_cert_by_pattern (assuan_context_t ctx, char *line, ldap_server_t ldapserver = ldapserver_iter.server; if (DBG_LOOKUP) - log_debug ("cmd_lookup: trying %s:%d base=%s\n", + log_debug ("cmd_lookup: trying %s://%s:%d base=%s\n", + ldapserver->schema ? ldapserver->schema: "ldap", ldapserver->host, ldapserver->port, ldapserver->base?ldapserver->base : "[default]"); -- 1.9.1 -- Best Regards! -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at adversary.org Wed May 20 18:54:09 2015 From: ben at adversary.org (Ben McGinnes) Date: Thu, 21 May 2015 02:54:09 +1000 Subject: GPGME pyme branch ready to merge with master In-Reply-To: <87twvayo1i.fsf@alice.fifthhorseman.net> References: <5557A7F2.5090002@adversary.org> <87twvayo1i.fsf@alice.fifthhorseman.net> Message-ID: <555CBC31.3070703@adversary.org> On 19/05/2015 12:10 am, Daniel Kahn Gillmor wrote: > On Sat 2015-05-16 16:26:26 -0400, Ben McGinnes wrote: > >> As the subject indicates, the pyme branch in the GPGME repo is >> ready to be merged with master. It will almost certainly produce a >> bunch of PEP8 complaints about trailing whitespace, but this is >> primarily due to checking files it shouldn't be checking, like the >> license files, documentation and the big one is the text copy of the >> decade or so of Python 2 PyME commit logs. > > Is there a reason to keep the trailing whitespace in the commit logs, > license files, and documentation? If there's no reason that we need it, > i would say clear it out so that legit PEP8 complaints don't get lost in > the noise. That's done and I'm postponing the merge until I've trawled through the rest. There are a couple of scripts I'll have to remove temporarily and they're Igor's massive GUI ones. Porting and fixing them properly will actually take more work than porting the entire module did, go figure. Plus it doesn't help that he relied on a gtk module which isn't in PyPI and I've no idea where it came from or if there's more than one or whatever. Obviously those scripts will remain in Martin's python 2 incarnation (and thus on PyPI), as they will continue to exist on the github repo I used between the fork from Martin's work (on bitbucket) and bringing it over here. Which is another way of saying; nothing is lost, but some of it needs to be diverted for a time. > (i personally see no problem with "altering the historical record" > of commit logs by stripping trailing whitespace as long as it's > documented clearly in the revision control history) Yeah, makes sense and I can cope with pushing back the "it's ready for people to try to break it" date for a little while. Though there will still be silly errors popping up which will need to be ignored. Things like complaining of "missing whitespace around operator" in reST files because the "=" sign or the "-" sign are used for headings. Anyway, I've got a slight distraction at the moment (i.e. PPAU work; gotta get stuck into developing a DV policy and that is rather important), but this work will be able to fall back into place around that within a week or so and continue from there. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Thu May 21 13:23:08 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 21 May 2015 20:23:08 +0900 Subject: [PATCH] g10: Fix a race condition initially creating trustdb In-Reply-To: <555BFA13.9010604@fsij.org> References: <555B17FA.9070601@fsij.org> <555BD2F7.8000706@fsij.org> <555BFA13.9010604@fsij.org> Message-ID: <555DC01C.8090408@fsij.org> Hello, I updated the patch again. In this version, helper functions take_write_lock and release_write_lock, so that the code is easier to read and to be maintained. The intention is to express that we do serialization of write accesses to trustdb.gpg from multiple processes of gpg. Besides, preparation of the lock (calling dotlock_create function) is in the take_write_lock function now, deferring the preparation as possible. In tdbio_set_dbname, I added a quick check for existing trustdb.gpg, so that we can avoid lock operations for most likely case. With this change against the one yesterday, if it's read-only accesses to trustdb.gpg, no write access to the file system is done. So, it's friendly to the situation of read-only file system. My idea is applying this to 2.1. Later, I intend to apply to 1.4 and 2.0. diff --git a/g10/tdbio.c b/g10/tdbio.c index 69438b4..6d071a8 100644 --- a/g10/tdbio.c +++ b/g10/tdbio.c @@ -100,7 +100,33 @@ static int in_transaction; static void open_db(void); +static int +take_write_lock (void) +{ + if (!lockhandle) + lockhandle = dotlock_create (db_name, 0); + if (!lockhandle) + log_fatal ( _("can't create lock for '%s'\n"), db_name ); + + if (!is_locked) + { + if (dotlock_take (lockhandle, -1) ) + log_fatal ( _("can't lock '%s'\n"), db_name ); + else + is_locked = 1; + return 0; + } + else + return 1; +} +static void +release_write_lock (void) +{ + if (!opt.lock_once) + if (!dotlock_release (lockhandle)) + is_locked = 0; +} /************************************* ************* record cache ********** @@ -256,12 +282,7 @@ put_record_into_cache( ulong recno, const char *data ) int n = dirty_count / 5; /* discard some dirty entries */ if( !n ) n = 1; - if( !is_locked ) { - if( dotlock_take( lockhandle, -1 ) ) - log_fatal("can't acquire lock - giving up\n"); - else - is_locked = 1; - } + take_write_lock (); for( unused = NULL, r = cache_list; r; r = r->next ) { if( r->flags.used && r->flags.dirty ) { int rc = write_cache_item( r ); @@ -275,10 +296,7 @@ put_record_into_cache( ulong recno, const char *data ) break; } } - if( !opt.lock_once ) { - if( !dotlock_release( lockhandle ) ) - is_locked = 0; - } + release_write_lock (); assert( unused ); r = unused; r->flags.used = 1; @@ -317,13 +335,9 @@ tdbio_sync() if( !cache_is_dirty ) return 0; - if( !is_locked ) { - if( dotlock_take( lockhandle, -1 ) ) - log_fatal("can't acquire lock - giving up\n"); - else - is_locked = 1; - did_lock = 1; - } + if (!take_write_lock ()) + did_lock = 1; + for( r = cache_list; r; r = r->next ) { if( r->flags.used && r->flags.dirty ) { int rc = write_cache_item( r ); @@ -332,10 +346,8 @@ tdbio_sync() } } cache_is_dirty = 0; - if( did_lock && !opt.lock_once ) { - if( !dotlock_release (lockhandle) ) - is_locked = 0; - } + if (did_lock) + release_write_lock (); return 0; } @@ -372,20 +384,12 @@ tdbio_end_transaction() if( !in_transaction ) log_bug("tdbio: no active transaction\n"); - if( !is_locked ) { - if( dotlock_take( lockhandle, -1 ) ) - log_fatal("can't acquire lock - giving up\n"); - else - is_locked = 1; - } + take_write_lock (); block_all_signals(); in_transaction = 0; rc = tdbio_sync(); unblock_all_signals(); - if( !opt.lock_once ) { - if( !dotlock_release (lockhandle) ) - is_locked = 0; - } + release_write_lock (); return rc; } @@ -483,6 +487,7 @@ int tdbio_set_dbname( const char *new_dbname, int create, int *r_nofile) { char *fname; + struct stat statbuf; static int initialized = 0; if( !initialized ) { @@ -504,6 +509,21 @@ tdbio_set_dbname( const char *new_dbname, int create, int *r_nofile) else fname = xstrdup (new_dbname); + xfree (db_name); + db_name = fname; + + /* + * Quick check for (likely) case where there is trustdb.gpg + * already. This check is not required in theory, but it helps in + * practice, avoiding costly operations of preparing and taking + * the lock. + */ + if (stat (fname, &statbuf) == 0 && statbuf.st_size > 0) + /* OK, we have the valid trustdb.gpg already. */ + return 0; + + take_write_lock (); + if( access( fname, R_OK ) ) { #ifdef HAVE_W32CE_SYSTEM /* We know how the cegcc implementation of access works ;-). */ @@ -512,11 +532,9 @@ tdbio_set_dbname( const char *new_dbname, int create, int *r_nofile) else gpg_err_set_errno (EIO); #endif /*HAVE_W32CE_SYSTEM*/ - if( errno != ENOENT ) { - log_error( _("can't access '%s': %s\n"), fname, strerror(errno) ); - xfree(fname); - return GPG_ERR_TRUSTDB; - } + if( errno != ENOENT ) + log_fatal( _("can't access '%s': %s\n"), fname, strerror(errno) ); + if (!create) *r_nofile = 1; else { @@ -546,16 +564,6 @@ tdbio_set_dbname( const char *new_dbname, int create, int *r_nofile) } *p = save_slash; - xfree(db_name); - db_name = fname; -#ifdef __riscos__ - if( !lockhandle ) - lockhandle = dotlock_create (db_name, 0); - if( !lockhandle ) - log_fatal( _("can't create lock for '%s'\n"), db_name ); - if( dotlock_make (lockhandle, -1) ) - log_fatal( _("can't lock '%s'\n"), db_name ); -#endif /* __riscos__ */ oldmask=umask(077); if (is_secured_filename (fname)) { fp = NULL; @@ -573,13 +581,6 @@ tdbio_set_dbname( const char *new_dbname, int create, int *r_nofile) log_fatal (_("can't open '%s': %s\n"), db_name, strerror (errno)); -#ifndef __riscos__ - if( !lockhandle ) - lockhandle = dotlock_create (db_name, 0); - if( !lockhandle ) - log_fatal( _("can't create lock for '%s'\n"), db_name ); -#endif /* !__riscos__ */ - rc = create_version_record (); if( rc ) log_fatal( _("%s: failed to create version record: %s"), @@ -590,12 +591,10 @@ tdbio_set_dbname( const char *new_dbname, int create, int *r_nofile) if( !opt.quiet ) log_info(_("%s: trustdb created\n"), db_name); - - return 0; } } - xfree(db_name); - db_name = fname; + + release_write_lock (); return 0; } @@ -615,14 +614,6 @@ open_db() assert( db_fd == -1 ); - if (!lockhandle ) - lockhandle = dotlock_create (db_name, 0); - if (!lockhandle ) - log_fatal( _("can't create lock for '%s'\n"), db_name ); -#ifdef __riscos__ - if (dotlock_take (lockhandle, -1) ) - log_fatal( _("can't lock '%s'\n"), db_name ); -#endif /* __riscos__ */ #ifdef HAVE_W32CE_SYSTEM { DWORD prevrc = 0; -- From ueno at gnu.org Fri May 22 05:42:07 2015 From: ueno at gnu.org (Daiki Ueno) Date: Fri, 22 May 2015 12:42:07 +0900 Subject: [PATCH] gpg: Allow setting of temporary pinentry program Message-ID: Hello, Related to https://bugs.gnupg.org/gnupg/issue1976, where I was originally requesting to fix a behavior of --pinentry-mode=loopback for Emacs. However using the option is seemingly not the the preferred way and NIIBE-san suggested to write a pinentry wrapper instead. Unfortunately, it is not an option for Emacs. We want to use the custom pinentry program only temporarily, and continue to use the default pinentry program for other use-cases (e.g. calling gpg from gnome-terminal). This is currently not possible. So, the attached patch adds --pinentry-program option to gpg, which will be passed to gpg-agent: $ ./g10/gpg2 --symmetric --pinentry-program '/usr/bin/pinentry-gnome3' \ -o /dev/null < README To be honest, I doubt this change is acceptable, and I prefer that the loopback behavior is eventually fixed, regardless of the original intent of that option. Regards, -- Daiki Ueno -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-gpg-Allow-setting-of-temporary-pinentry-program.patch Type: text/x-patch Size: 5606 bytes Desc: not available URL: From wk at gnupg.org Fri May 22 09:20:15 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 May 2015 09:20:15 +0200 Subject: [PATCH] gpg: Allow setting of temporary pinentry program In-Reply-To: (Daiki Ueno's message of "Fri, 22 May 2015 12:42:07 +0900") References: Message-ID: <87y4kh5b9s.fsf@vigenere.g10code.de> On Fri, 22 May 2015 05:42, ueno at gnu.org said: > Unfortunately, it is not an option for Emacs. We want to use the custom > pinentry program only temporarily, and continue to use the default > pinentry program for other use-cases (e.g. calling gpg from > gnome-terminal). This is currently not possible. To do this you can put a magic value into the PINENTRY_USER_DATA envvar and let your wrapper divert to your Pinentry if that magic value is detected. If really required we can also add a new envvar for that purpose but that will only work for future gpg versions (gpg uses a static list of envvars to be forwarded to gpg-agent). > To be honest, I doubt this change is acceptable, and I prefer that the Right. That won't go into upstream. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ueno at gnu.org Fri May 22 09:50:30 2015 From: ueno at gnu.org (Daiki Ueno) Date: Fri, 22 May 2015 16:50:30 +0900 Subject: [PATCH] gpg: Allow setting of temporary pinentry program In-Reply-To: <87y4kh5b9s.fsf@vigenere.g10code.de> (Werner Koch's message of "Fri, 22 May 2015 09:20:15 +0200") References: <87y4kh5b9s.fsf@vigenere.g10code.de> Message-ID: Werner Koch writes: > On Fri, 22 May 2015 05:42, ueno at gnu.org said: > >> Unfortunately, it is not an option for Emacs. We want to use the custom >> pinentry program only temporarily, and continue to use the default >> pinentry program for other use-cases (e.g. calling gpg from >> gnome-terminal). This is currently not possible. > > To do this you can put a magic value into the PINENTRY_USER_DATA envvar > and let your wrapper divert to your Pinentry if that magic value is > detected. The problem with this approach is that the wrapper doesn't know the default pinentry. gpgconf --list-options doesn't include the value, right? And even if it is possible, it will list the wrapper, instead of the default one. So, instead of implementing the diversion mechanism in wrapper, I would rather suggest to add the diversion mechanism in gpg-agent. E.g., allow --pinentry-program to have multiple values, and try one by one until success. Regards, -- Daiki Ueno From wk at gnupg.org Fri May 22 10:21:59 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 May 2015 10:21:59 +0200 Subject: [PATCH] gpg: Allow setting of temporary pinentry program In-Reply-To: (Daiki Ueno's message of "Fri, 22 May 2015 16:50:30 +0900") References: <87y4kh5b9s.fsf@vigenere.g10code.de> Message-ID: <87k2w158ew.fsf@vigenere.g10code.de> On Fri, 22 May 2015 09:50, ueno at gnu.org said: > The problem with this approach is that the wrapper doesn't know the > default pinentry. gpgconf --list-options doesn't include the value, /usr/bin/pinentry is the default. Variants should be installed as a symlink. > So, instead of implementing the diversion mechanism in wrapper, I would > rather suggest to add the diversion mechanism in gpg-agent. E.g., allow > --pinentry-program to have multiple values, and try one by one until If you want that do it in pinentry. Actually pinentry already does this: If DISPLAY is not set or it cannot init Gtk+ pinnetry falls back to curses. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dfalko at digiflak.com Fri May 22 10:26:14 2015 From: dfalko at digiflak.com (Dmitry Falko) Date: Fri, 22 May 2015 11:26:14 +0300 Subject: [PATCH] dirmngr_ldap: support ldap secure connection(ldaps) In-Reply-To: <555C8BAF.1060202@digiflak.com> References: <555C8BAF.1060202@digiflak.com> Message-ID: <555EE826.9030803@digiflak.com> Hello! Why my patch ignored? It's bad, or useless? 20.05.2015 16:27, Dmitry Falko wrote: > Hello! > > I encountered a problem connecting to the LDAP server via TLS and > wrote a small patch, send it as is. > > * dirmngr.h (ldap_server_s): add schema field > * dirmngr_ldap.c (fetch_ldap): ldaps support > * ldap.c (make_url, start_cert_fetch_ldap): add schema > * ldapserver.c (ldapserver_parse_one): parse schema > * server.c (lookup_cert_by_pattern): additional log info > > dirmngr_ldap can retrieve certificates from LDAP server > by TLS(using ldaps protocol). Protocol can be set in > dirmngr_ldapserver.conf: > hostname:port:username:password:base_dn:schema > If not set use ldap.By default dirmngr_ldap use > /etc/ssl/CA(dirmngr_ldap.c CA_CERT_DEFAULT) CA certificate, > user can set DIRMNGR_LDAP_CACERT env variable to > override this value. > --- > dirmngr/dirmngr.h | 1 + > dirmngr/dirmngr_ldap.c | 61 > +++++++++++++++++++++++++++++++++++++++++++++----- > dirmngr/ldap.c | 24 +++++++++++++++----- > dirmngr/ldapserver.c | 5 +++++ > dirmngr/server.c | 3 ++- > 5 files changed, 81 insertions(+), 13 deletions(-) > > diff --git a/dirmngr/dirmngr.h b/dirmngr/dirmngr.h > index 4f037e7..3406494 100644 > --- a/dirmngr/dirmngr.h > +++ b/dirmngr/dirmngr.h > @@ -46,6 +46,7 @@ struct ldap_server_s > char *user; > char *pass; > char *base; > + char *schema; > }; > typedef struct ldap_server_s *ldap_server_t; > > diff --git a/dirmngr/dirmngr_ldap.c b/dirmngr/dirmngr_ldap.c > index 61a7e39..8bb739c 100644 > --- a/dirmngr/dirmngr_ldap.c > +++ b/dirmngr/dirmngr_ldap.c > @@ -46,6 +46,8 @@ > /* For OpenLDAP, to enable the API that we're using. */ > # define LDAP_DEPRECATED 1 > # include > + /* FIXME: use configure script to set this define */ > +# define CA_CERT_DEFAULT ("/etc/ssl/CA") > #endif > > > @@ -571,9 +573,10 @@ fetch_ldap (my_opt_t myopt, const char *url, > const LDAPURLDesc *ludp) > LDAP *ld; > LDAPMessage *msg; > int rc = 0; > - char *host, *dn, *filter, *attrs[2], *attr; > + char *host, *dn, *filter, *attrs[2], *attr, *ca_cert, *ldap_url; > int port; > int ret; > + int err; > > host = myopt->host? myopt->host : ludp->lud_host; > port = myopt->port? myopt->port : ludp->lud_port; > @@ -583,6 +586,17 @@ fetch_ldap (my_opt_t myopt, const char *url, > const LDAPURLDesc *ludp) > attrs[1] = NULL; > attr = attrs[0]; > > + ca_cert = getenv("DIRMNGR_LDAP_CACERT"); > + if(!ca_cert) > + { > + if (myopt->verbose) > + { > + log_info("Using default CA certificate"); > + } > + > + ca_cert = CA_CERT_DEFAULT; > + } > + > if (!port) > port = (ludp->lud_scheme && !strcmp (ludp->lud_scheme, "ldaps"))? > 636:389; > > @@ -628,23 +642,58 @@ fetch_ldap (my_opt_t myopt, const char *url, > const LDAPURLDesc *ludp) > > > set_timeout (myopt); > + > + ldap_url = alloca(4 + strlen(ludp->lud_scheme) > + + strlen(host) > + + 5); /* for port */ > + sprintf(ldap_url, "%s://%s:%d", ludp->lud_scheme, host, port); > + > npth_unprotect (); > - ld = my_ldap_init (host, port); > + err = ldap_initialize(&ld, ldap_url) ; > npth_protect (); > - if (!ld) > + if (err != LDAP_SUCCESS) > { > - log_error (_("LDAP init to '%s:%d' failed: %s\n"), > - host, port, strerror (errno)); > + log_error (_("LDAP init to '%s' failed: %s\n"), > + ldap_url, ldap_err2string (errno)); > return -1; > } > npth_unprotect (); > + > + if(!strcmp (ludp->lud_scheme, "ldaps")) > + { > + /* Additional options for tls connection */ > + /*FIXME: LDAP_OPT_X_TLS_NEVER or LDAP_OPT_X_TLS_HARD, add option*/ > + int req_cert = LDAP_OPT_X_TLS_NEVER; > + > + err = ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTFILE, > + ca_cert); > + npth_protect (); > + if(err != LDAP_SUCCESS) > + { > + log_error (_("setting ca-certificate failed: %s\n"), > + ldap_err2string (err)); > + return -1; > + } > + npth_unprotect (); > + err=ldap_set_option(NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, > + &req_cert); > + npth_protect (); > + if(err != LDAP_SUCCESS) > + { > + log_error (_("setting require certificate failed: %s\n"), > + ldap_err2string (err)); > + return -1; > + } > + npth_unprotect (); > + } > + > /* Fixme: Can we use MYOPT->user or is it shared with other > theeads?. */ > ret = my_ldap_simple_bind_s (ld, myopt->user, myopt->pass); > npth_protect (); > if (ret) > { > log_error (_("binding to '%s:%d' failed: %s\n"), > - host, port, strerror (errno)); > + host, port, ldap_err2string (errno)); > ldap_unbind (ld); > return -1; > } > diff --git a/dirmngr/ldap.c b/dirmngr/ldap.c > index e4c6aa2..d4e0730 100644 > --- a/dirmngr/ldap.c > +++ b/dirmngr/ldap.c > @@ -423,10 +423,10 @@ escape4url (const char *string) > need the host and port because this will be specified using the > override options. */ > static gpg_error_t > -make_url (char **url, const char *dn, const char *filter) > +make_url (char **url, const char *dn, const char *filter, const char > *schema) > { > gpg_error_t err; > - char *u_dn, *u_filter; > + char *u_dn, *u_filter, *u_schema; > char const attrs[] = (USERCERTIFICATE "," > /* USERSMIMECERTIFICATE "," */ > CACERTIFICATE "," > @@ -434,6 +434,10 @@ make_url (char **url, const char *dn, const char > *filter) > > *url = NULL; > > + u_schema = escape4url (schema); > + if(!u_schema) > + return gpg_error_from_errno (errno); > + > u_dn = escape4url (dn); > if (!u_dn) > return gpg_error_from_errno (errno); > @@ -445,7 +449,8 @@ make_url (char **url, const char *dn, const char > *filter) > xfree (u_dn); > return err; > } > - *url = malloc ( 8 + strlen (u_dn) > + *url = malloc ( 4 + strlen (schema) > + + strlen (u_dn) > + 1 + strlen (attrs) > + 5 + strlen (u_filter) + 1 ); > if (!*url) > @@ -456,12 +461,14 @@ make_url (char **url, const char *dn, const char > *filter) > return err; > } > > - stpcpy (stpcpy (stpcpy (stpcpy (stpcpy (stpcpy (*url, "ldap:///"), > + stpcpy (stpcpy (stpcpy (stpcpy (stpcpy (stpcpy (stpcpy(*url, > u_schema), > + ":///"), > u_dn), > "?"), > attrs), > "?sub?"), > u_filter); > + xfree (u_schema); > xfree (u_dn); > xfree (u_filter); > return 0; > @@ -525,6 +532,7 @@ start_cert_fetch_ldap (ctrl_t ctrl, > cert_fetch_context_t *context, > const char *user; > const char *pass; > const char *base; > + const char *schema; > const char *argv[50]; > int argc; > char portbuf[30], timeoutbuf[30]; > @@ -538,6 +546,7 @@ start_cert_fetch_ldap (ctrl_t ctrl, > cert_fetch_context_t *context, > user = server->user; > pass = server->pass; > base = server->base; > + schema = server->schema; > } > else /* Use a default server. */ > return gpg_error (GPG_ERR_NOT_IMPLEMENTED); > @@ -545,6 +554,9 @@ start_cert_fetch_ldap (ctrl_t ctrl, > cert_fetch_context_t *context, > if (!base) > base = ""; > > + if(!schema) > + schema = "ldap"; > + > argc = 0; > if (pass) /* Note: Must be the first item. */ > { > @@ -606,9 +618,9 @@ start_cert_fetch_ldap (ctrl_t ctrl, > cert_fetch_context_t *context, > return gpg_error (GPG_ERR_INV_USER_ID); > } > if ((sl->flags & 1)) > - err = make_url (&url, sl->d, "objectClass=*"); > + err = make_url (&url, sl->d, "objectClass=*", schema); > else > - err = make_url (&url, base, sl->d); > + err = make_url (&url, base, sl->d, schema); > free_strlist (sl); > if (err) > { > diff --git a/dirmngr/ldapserver.c b/dirmngr/ldapserver.c > index 16e13e2..87c8b47 100644 > --- a/dirmngr/ldapserver.c > +++ b/dirmngr/ldapserver.c > @@ -115,6 +115,11 @@ ldapserver_parse_one (char *line, > server->base = xstrdup (p); > break; > > + case 6: > + if (*p) > + server->schema = xstrdup (p); > + break; > + > default: > /* (We silently ignore extra fields.) */ > break; > diff --git a/dirmngr/server.c b/dirmngr/server.c > index 1b7e9e9..bcf83f9 100644 > --- a/dirmngr/server.c > +++ b/dirmngr/server.c > @@ -1259,7 +1259,8 @@ lookup_cert_by_pattern (assuan_context_t ctx, > char *line, > ldap_server_t ldapserver = ldapserver_iter.server; > > if (DBG_LOOKUP) > - log_debug ("cmd_lookup: trying %s:%d base=%s\n", > + log_debug ("cmd_lookup: trying %s://%s:%d base=%s\n", > + ldapserver->schema ? ldapserver->schema: "ldap", > ldapserver->host, ldapserver->port, > ldapserver->base?ldapserver->base : "[default]"); > > -- > 1.9.1 > > > -- > Best Regards! > > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel -- C ?????????, ???????! -------------- next part -------------- An HTML attachment was scrubbed... URL: From ueno at gnu.org Fri May 22 10:45:46 2015 From: ueno at gnu.org (Daiki Ueno) Date: Fri, 22 May 2015 17:45:46 +0900 Subject: [PATCH] gpg: Allow setting of temporary pinentry program In-Reply-To: <87k2w158ew.fsf@vigenere.g10code.de> (Werner Koch's message of "Fri, 22 May 2015 10:21:59 +0200") References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> Message-ID: Werner Koch writes: >> So, instead of implementing the diversion mechanism in wrapper, I would >> rather suggest to add the diversion mechanism in gpg-agent. E.g., allow >> --pinentry-program to have multiple values, and try one by one until > > If you want that do it in pinentry. Actually pinentry already does > this: If DISPLAY is not set or it cannot init Gtk+ pinnetry falls back > to curses. Just to confirm your suggestion: would it be acceptable to add a hack in Pinentry (upstream, instead of a wrapper) to check INSIDE_EMACS envvar? http://www.gnu.org/software/emacs/manual/html_node/emacs/Interactive-Shell.html#Interactive-Shell Regards, -- Daiki Ueno From wk at gnupg.org Fri May 22 12:22:27 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 May 2015 12:22:27 +0200 Subject: [PATCH] gpg: Allow setting of temporary pinentry program In-Reply-To: (Daiki Ueno's message of "Fri, 22 May 2015 17:45:46 +0900") References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> Message-ID: <878ucg6hek.fsf@vigenere.g10code.de> On Fri, 22 May 2015 10:45, ueno at gnu.org said: > Just to confirm your suggestion: would it be acceptable to add a hack in > Pinentry (upstream, instead of a wrapper) to check INSIDE_EMACS envvar? > http://www.gnu.org/software/emacs/manual/html_node/emacs/Interactive-Shell.html#Interactive-Shell Yes. To actually convey the variable to pinentry a small change to GnuPG is required (common/session-env.c:stdenvnames). Shall I do that part? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Mon May 25 07:41:05 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 25 May 2015 14:41:05 +0900 Subject: [PATCH] g10: Fix a race condition initially creating trustdb In-Reply-To: <555DC01C.8090408@fsij.org> References: <555B17FA.9070601@fsij.org> <555BD2F7.8000706@fsij.org> <555BFA13.9010604@fsij.org> <555DC01C.8090408@fsij.org> Message-ID: <5562B5F1.1080907@fsij.org> On 05/21/2015 08:23 PM, NIIBE Yutaka wrote: > I updated the patch again. If there is no problem, I'd like to commit this to master branch. Any other thought? -- From gniibe at fsij.org Tue May 26 04:07:41 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 26 May 2015 11:07:41 +0900 Subject: [PATCH] g10: remove g10/signal.c. Message-ID: <5563D56D.5040102@fsij.org> Hello, This is a clean up. I noticed this during grepping the code. g10/signal.c should be removed. In the commit 5c46f134e22d57fafc901c95350fad11efc10516 (2003-06-27), we had the last change (context is g10/): 2003-06-24 Werner Koch * Makefile.am: Removed signal.c * g10.c (emergency_cleanup): New. (main): Use gnupg_init_signals and register malloc for assuan. >From this point, we don't need g10/signal.c any more, since we have common/signal.c. Following is a patch to finish the removal. The lines in g10/main.h is old ones not used after 2003-06-27. The call in g10/tdbio.c is dead code now (#ifdef-out-ed), but just in case we will enable it. OK to commit (together with the removal of g10/signal.c)? diff --git a/g10/main.h b/g10/main.h index a89f711..9370ae5 100644 --- a/g10/main.h +++ b/g10/main.h @@ -379,11 +379,6 @@ int hash_datafile_by_fd ( gcry_md_hd_t md, gcry_md_hd_t md2, int data_fd, int textmode ); PKT_plaintext *setup_plaintext_name(const char *filename,IOBUF iobuf); -/*-- signal.c --*/ -void init_signals(void); -void block_all_signals(void); -void unblock_all_signals(void); - /*-- server.c --*/ int gpg_server (ctrl_t); gpg_error_t gpg_proxy_pinentry_notify (ctrl_t ctrl, diff --git a/g10/tdbio.c b/g10/tdbio.c index 69438b4..98a7773 100644 --- a/g10/tdbio.c +++ b/g10/tdbio.c @@ -378,10 +378,10 @@ tdbio_end_transaction() else is_locked = 1; } - block_all_signals(); + gnupg_block_all_signals(); in_transaction = 0; rc = tdbio_sync(); - unblock_all_signals(); + gnupg_unblock_all_signals(); if( !opt.lock_once ) { if( !dotlock_release (lockhandle) ) is_locked = 0; -- From folkert at vanheusden.com Wed May 27 21:30:09 2015 From: folkert at vanheusden.com (folkert) Date: Wed, 27 May 2015 21:30:09 +0200 Subject: passphrase callback Message-ID: <20150527193008.GA5163@belle.intranet.vanheusden.com> Hi, I'm trying to use gpgme in an unattended environment, e.g. without user interaction. Now I try to use gpgme_set_passphrase_cb() and I find two issues: - when I invoke it without the ctx beining setup, it silently ignores/fails - even though I set the passphrase callback, it still tries to invoke the gpg-agent gui. if I remove that program (as the situation will be on he server), it still doesn't use the passphrase callback How to proceed? Thanks. Versions of software used: gnupg 1.4.18-7 gnupg2 2.0.26-6 gnupg-agent 2.0.26-6 gpgv 1.4.18-7 libgpg-error0:amd64 1.17-3 libgpg-error0:i386 1.17-3 libgpg-error-dev 1.17-3 libgpgme11:amd64 1.5.1-6 libgpgme11-dev 1.5.1-6 libgpgme++2 4:4.14.2-2+b1 Folkert van Heusden -- From folkert at vanheusden.com Wed May 27 23:07:17 2015 From: folkert at vanheusden.com (folkert) Date: Wed, 27 May 2015 23:07:17 +0200 Subject: passphrase callback In-Reply-To: <20150527193008.GA5163@belle.intranet.vanheusden.com> References: <20150527193008.GA5163@belle.intranet.vanheusden.com> Message-ID: <20150527210717.GB5163@belle.intranet.vanheusden.com> Hi, Found out that the documentation on the gnu website is no longer up-to-date and that I need to set the pin mode to loop-back: gpgme_set_passphrase_cb(*ctx, NULL, NULL); (void)gpgme_set_pinentry_mode(*ctx, GPGME_PINENTRY_MODE_LOOPBACK); gpgme_set_passphrase_cb(*ctx, passphrase_cb, data); Now something strange happens: apparently this lets gpgme use a new gpg2 command-line switch and this fails: [pid 14558] execve("/usr/bin/gpg2", ["gpg2", "--enable-special-filenames", "--pinentry-mode=loopback", "--no-sk-comment", "--lc-messages", "C", "--lc-ctype", "C", "--status-fd", "4", "--no-tty", "--charset", "utf8", "--enable-progress-filter", "--display", ":0.0", "--command-fd", "5", "--encrypt", "--sign", "--always-trust", "-r", "95C76C5EF83943DA2F322CF4D2C2514414B7E8E6", "-u", "D2C2514414B7E8E6", "--output", "-", "--", "-&9"], [/* 31 vars */]) = 0 [pid 14558] write(2, "gpg: invalid option \"--pinentry-mode=loopback\"\n", 47) = 47 This is a bit odd I would say? Please advise. On Wed, May 27, 2015 at 09:30:09PM +0200, folkert wrote: > Hi, > > I'm trying to use gpgme in an unattended environment, e.g. without user > interaction. > Now I try to use gpgme_set_passphrase_cb() and I find two issues: > - when I invoke it without the ctx beining setup, it silently > ignores/fails > - even though I set the passphrase callback, it still tries to invoke > the gpg-agent gui. if I remove that program (as the situation will be > on he server), it still doesn't use the passphrase callback > > How to proceed? > > Thanks. > > Versions of software used: > > gnupg 1.4.18-7 > gnupg2 2.0.26-6 > gnupg-agent 2.0.26-6 > gpgv 1.4.18-7 > libgpg-error0:amd64 1.17-3 > libgpg-error0:i386 1.17-3 > libgpg-error-dev 1.17-3 > libgpgme11:amd64 1.5.1-6 > libgpgme11-dev 1.5.1-6 > libgpgme++2 4:4.14.2-2+b1 > > > Folkert van Heusden > > -- > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel Folkert van Heusden -- You've probably gotten really fed up with never winning in the Mega- Millions lottery. Well, weep no longer: www.smartwinning.info tells you everything that might help you deciding what numbers to choose. With nice graphs and pretty animations! From wk at gnupg.org Thu May 28 09:02:11 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 28 May 2015 09:02:11 +0200 Subject: passphrase callback In-Reply-To: <20150527210717.GB5163@belle.intranet.vanheusden.com> (folkert@vanheusden.com's message of "Wed, 27 May 2015 23:07:17 +0200") References: <20150527193008.GA5163@belle.intranet.vanheusden.com> <20150527210717.GB5163@belle.intranet.vanheusden.com> Message-ID: <87vbfdyyks.fsf@vigenere.g10code.de> On Wed, 27 May 2015 23:07, folkert at vanheusden.com said: > Found out that the documentation on the gnu website is no longer > up-to-date and that I need to set the pin mode to loop-back: gnu.org or gnupg.org - I have mot updated anything at gnu.org for quite soem time. However, all packages come with a reference manual. > [pid 14558] write(2, "gpg: invalid option \"--pinentry-mode=loopback\"\n", 47) = 47 > > This is a bit odd I would say? No. --pinentry-mode is a new feature of GnuPG 2.1 and the gpgme manual does not yet document this new API. You are using 2.0 which does not provide pinentry-mode at all. > On Wed, May 27, 2015 at 09:30:09PM +0200, folkert wrote: >> I'm trying to use gpgme in an unattended environment, e.g. without user >> interaction. >> Now I try to use gpgme_set_passphrase_cb() and I find two issues: >> - when I invoke it without the ctx beining setup, it silently >> ignores/fails Sure, without a context gpgme can't store the callback. >> - even though I set the passphrase callback, it still tries to invoke >> the gpg-agent gui. if I remove that program (as the situation will be >> on he server), it still doesn't use the passphrase callback That depends on the configuraion of gpg 2.0 or 1.4. IIRC< you need to use no-use-agent in gpg.conf. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Thu May 28 10:22:23 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 28 May 2015 04:22:23 -0400 Subject: gnome keyring & gpg agent: backport to gpg 2.0 done In-Reply-To: <87h9r8pu3b.wl-neal@walfield.org> References: <87twvg8l4r.fsf@alice.fifthhorseman.net> <87bnhowa4x.wl-neal@walfield.org> <87twvfmnhx.fsf@vigenere.g10code.de> <87fv6z7032.fsf@alice.fifthhorseman.net> <877fsbvwhr.wl-neal@walfield.org> <87h9r8pu3b.wl-neal@walfield.org> Message-ID: <874mmxdscg.fsf@alice.fifthhorseman.net> On Tue 2015-05-19 09:36:40 -0400, Neal H. Walfield wrote: > But, again, these items are primarily aesthetic: there is no reason > that distributions can't ship the new pinentry now and disable GNOME > Keyring's gpg agent proxy. I'm not inclined to ship the new GNOME3 pinentry if it's not part of a released version of pinentry. I could do so with a beta release (e.g. in debian experimental), or i could invent a release of my own From git HEAD, but i'm wary about doing this unless you tell me as upstream that pinentry is in a good stopping place. (also, the common gnupg practice of shipping tarballs that differ significantly from the revision control system makes it more complicated for me to "cut a release" on my own as a distributor, since the release i cut is likely to be different from whatever you produce as upstream) I'd be happy to try to get something like pinentry-gnome3 into debian if it's ready, though. Is it ready? Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From gniibe at fsij.org Thu May 28 10:23:42 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 28 May 2015 17:23:42 +0900 Subject: [PATCH] g10: Fix a race condition initially creating trustdb In-Reply-To: <5562B5F1.1080907@fsij.org> References: <555B17FA.9070601@fsij.org> <555BD2F7.8000706@fsij.org> <555BFA13.9010604@fsij.org> <555DC01C.8090408@fsij.org> <5562B5F1.1080907@fsij.org> Message-ID: <5566D08E.6070009@fsij.org> On 05/25/2015 02:41 PM, NIIBE Yutaka wrote: > Any other thought? Here is again for review. g10: Fix a race condition initially creating trustdb. * g10/tdbio.c (take_write_lock, release_write_lock): New. (put_record_into_cache, tdbio_sync, tdbio_end_transaction): Use new lock functions. (tdbio_set_dbname): Fix the race. (open_db): Don't call dotlocck_create. -- GnuPG-bug-id: 1675 I believe this fix is correct. Tested in 2.1. I also made backport to 1.4 and it was also tested. Will do for 2.0. May I push this change to master? diff --git a/g10/tdbio.c b/g10/tdbio.c index 98a7773..940165c 100644 --- a/g10/tdbio.c +++ b/g10/tdbio.c @@ -100,7 +100,33 @@ static int in_transaction; static void open_db(void); +static int +take_write_lock (void) +{ + if (!lockhandle) + lockhandle = dotlock_create (db_name, 0); + if (!lockhandle) + log_fatal ( _("can't create lock for '%s'\n"), db_name ); + + if (!is_locked) + { + if (dotlock_take (lockhandle, -1) ) + log_fatal ( _("can't lock '%s'\n"), db_name ); + else + is_locked = 1; + return 0; + } + else + return 1; +} +static void +release_write_lock (void) +{ + if (!opt.lock_once) + if (!dotlock_release (lockhandle)) + is_locked = 0; +} /************************************* ************* record cache ********** @@ -256,12 +282,7 @@ put_record_into_cache( ulong recno, const char *data ) int n = dirty_count / 5; /* discard some dirty entries */ if( !n ) n = 1; - if( !is_locked ) { - if( dotlock_take( lockhandle, -1 ) ) - log_fatal("can't acquire lock - giving up\n"); - else - is_locked = 1; - } + take_write_lock (); for( unused = NULL, r = cache_list; r; r = r->next ) { if( r->flags.used && r->flags.dirty ) { int rc = write_cache_item( r ); @@ -275,10 +296,7 @@ put_record_into_cache( ulong recno, const char *data ) break; } } - if( !opt.lock_once ) { - if( !dotlock_release( lockhandle ) ) - is_locked = 0; - } + release_write_lock (); assert( unused ); r = unused; r->flags.used = 1; @@ -317,13 +335,9 @@ tdbio_sync() if( !cache_is_dirty ) return 0; - if( !is_locked ) { - if( dotlock_take( lockhandle, -1 ) ) - log_fatal("can't acquire lock - giving up\n"); - else - is_locked = 1; - did_lock = 1; - } + if (!take_write_lock ()) + did_lock = 1; + for( r = cache_list; r; r = r->next ) { if( r->flags.used && r->flags.dirty ) { int rc = write_cache_item( r ); @@ -332,10 +346,8 @@ tdbio_sync() } } cache_is_dirty = 0; - if( did_lock && !opt.lock_once ) { - if( !dotlock_release (lockhandle) ) - is_locked = 0; - } + if (did_lock) + release_write_lock (); return 0; } @@ -372,20 +384,12 @@ tdbio_end_transaction() if( !in_transaction ) log_bug("tdbio: no active transaction\n"); - if( !is_locked ) { - if( dotlock_take( lockhandle, -1 ) ) - log_fatal("can't acquire lock - giving up\n"); - else - is_locked = 1; - } + take_write_lock (); gnupg_block_all_signals(); in_transaction = 0; rc = tdbio_sync(); gnupg_unblock_all_signals(); - if( !opt.lock_once ) { - if( !dotlock_release (lockhandle) ) - is_locked = 0; - } + release_write_lock (); return rc; } @@ -483,6 +487,7 @@ int tdbio_set_dbname( const char *new_dbname, int create, int *r_nofile) { char *fname; + struct stat statbuf; static int initialized = 0; if( !initialized ) { @@ -504,6 +509,21 @@ tdbio_set_dbname( const char *new_dbname, int create, int *r_nofile) else fname = xstrdup (new_dbname); + xfree (db_name); + db_name = fname; + + /* + * Quick check for (likely) case where there is trustdb.gpg + * already. This check is not required in theory, but it helps in + * practice, avoiding costly operations of preparing and taking + * the lock. + */ + if (stat (fname, &statbuf) == 0 && statbuf.st_size > 0) + /* OK, we have the valid trustdb.gpg already. */ + return 0; + + take_write_lock (); + if( access( fname, R_OK ) ) { #ifdef HAVE_W32CE_SYSTEM /* We know how the cegcc implementation of access works ;-). */ @@ -512,11 +532,9 @@ tdbio_set_dbname( const char *new_dbname, int create, int *r_nofile) else gpg_err_set_errno (EIO); #endif /*HAVE_W32CE_SYSTEM*/ - if( errno != ENOENT ) { - log_error( _("can't access '%s': %s\n"), fname, strerror(errno) ); - xfree(fname); - return GPG_ERR_TRUSTDB; - } + if( errno != ENOENT ) + log_fatal( _("can't access '%s': %s\n"), fname, strerror(errno) ); + if (!create) *r_nofile = 1; else { @@ -546,16 +564,6 @@ tdbio_set_dbname( const char *new_dbname, int create, int *r_nofile) } *p = save_slash; - xfree(db_name); - db_name = fname; -#ifdef __riscos__ - if( !lockhandle ) - lockhandle = dotlock_create (db_name, 0); - if( !lockhandle ) - log_fatal( _("can't create lock for '%s'\n"), db_name ); - if( dotlock_make (lockhandle, -1) ) - log_fatal( _("can't lock '%s'\n"), db_name ); -#endif /* __riscos__ */ oldmask=umask(077); if (is_secured_filename (fname)) { fp = NULL; @@ -573,13 +581,6 @@ tdbio_set_dbname( const char *new_dbname, int create, int *r_nofile) log_fatal (_("can't open '%s': %s\n"), db_name, strerror (errno)); -#ifndef __riscos__ - if( !lockhandle ) - lockhandle = dotlock_create (db_name, 0); - if( !lockhandle ) - log_fatal( _("can't create lock for '%s'\n"), db_name ); -#endif /* !__riscos__ */ - rc = create_version_record (); if( rc ) log_fatal( _("%s: failed to create version record: %s"), @@ -590,12 +591,10 @@ tdbio_set_dbname( const char *new_dbname, int create, int *r_nofile) if( !opt.quiet ) log_info(_("%s: trustdb created\n"), db_name); - - return 0; } } - xfree(db_name); - db_name = fname; + + release_write_lock (); return 0; } @@ -615,14 +614,6 @@ open_db() assert( db_fd == -1 ); - if (!lockhandle ) - lockhandle = dotlock_create (db_name, 0); - if (!lockhandle ) - log_fatal( _("can't create lock for '%s'\n"), db_name ); -#ifdef __riscos__ - if (dotlock_take (lockhandle, -1) ) - log_fatal( _("can't lock '%s'\n"), db_name ); -#endif /* __riscos__ */ #ifdef HAVE_W32CE_SYSTEM { DWORD prevrc = 0; -- From ueno at gnu.org Thu May 28 11:03:44 2015 From: ueno at gnu.org (Daiki Ueno) Date: Thu, 28 May 2015 18:03:44 +0900 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: <878ucg6hek.fsf@vigenere.g10code.de> (Werner Koch's message of "Fri, 22 May 2015 12:22:27 +0200") References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> Message-ID: Werner Koch writes: > On Fri, 22 May 2015 10:45, ueno at gnu.org said: > >> Just to confirm your suggestion: would it be acceptable to add a hack in >> Pinentry (upstream, instead of a wrapper) to check INSIDE_EMACS envvar? >> http://www.gnu.org/software/emacs/manual/html_node/emacs/Interactive-Shell.html#Interactive-Shell > > Yes. Okay, here is a tentative patch in that direction. I'm also attaching a patch to Emacs, needed for testing. > To actually convey the variable to pinentry a small change to > GnuPG is required (common/session-env.c:stdenvnames). Shall I do that > part? Sure, thanks. Please also considier adding TMPDIR, since emacsclient looks for a socket file under "$TMPDIR/emacs$UID/server". Comments appreciated. Regards, -- Daiki Ueno -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-inside-Emacs-mode-to-GUI-pinentry-programs.patch Type: text/x-patch Size: 36467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-epg-Support-external-pinentry-callback.patch Type: text/x-patch Size: 3239 bytes Desc: not available URL: From wk at gnupg.org Thu May 28 12:08:56 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 28 May 2015 12:08:56 +0200 Subject: gnome keyring & gpg agent: backport to gpg 2.0 done In-Reply-To: <874mmxdscg.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 28 May 2015 04:22:23 -0400") References: <87twvg8l4r.fsf@alice.fifthhorseman.net> <87bnhowa4x.wl-neal@walfield.org> <87twvfmnhx.fsf@vigenere.g10code.de> <87fv6z7032.fsf@alice.fifthhorseman.net> <877fsbvwhr.wl-neal@walfield.org> <87h9r8pu3b.wl-neal@walfield.org> <874mmxdscg.fsf@alice.fifthhorseman.net> Message-ID: <87mw0pypxj.fsf@vigenere.g10code.de> On Thu, 28 May 2015 10:22, dkg at fifthhorseman.net said: > I'd be happy to try to get something like pinentry-gnome3 into debian if > it's ready, though. Is it ready? @neal: Any immediate plans to fix certain things? If not I can do yet another release. It will miss the hide/unhide feature but if that helps to get rid of a gnome problem, I am all in favor of doing a release today. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu May 28 12:14:52 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 28 May 2015 12:14:52 +0200 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: (Daiki Ueno's message of "Thu, 28 May 2015 18:03:44 +0900") References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> Message-ID: <87iobdypnn.fsf@vigenere.g10code.de> On Thu, 28 May 2015 11:03, ueno at gnu.org said: > Sure, thanks. Please also considier adding TMPDIR, since emacsclient > looks for a socket file under "$TMPDIR/emacs$UID/server". TMPDIR is not Emacs specific and allowing a client to change that variable for Pinentry is not a good idea. Why not using an emacs specific variable for this or change it in pinentry-emacs. @neal: Do you have time to look at the patch? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From neal at walfield.org Thu May 28 13:39:56 2015 From: neal at walfield.org (Neal H. Walfield) Date: Thu, 28 May 2015 13:39:56 +0200 Subject: gnome keyring & gpg agent: backport to gpg 2.0 done In-Reply-To: <87mw0pypxj.fsf@vigenere.g10code.de> References: <87twvg8l4r.fsf@alice.fifthhorseman.net> <87bnhowa4x.wl-neal@walfield.org> <87twvfmnhx.fsf@vigenere.g10code.de> <87fv6z7032.fsf@alice.fifthhorseman.net> <877fsbvwhr.wl-neal@walfield.org> <87h9r8pu3b.wl-neal@walfield.org> <874mmxdscg.fsf@alice.fifthhorseman.net> <87mw0pypxj.fsf@vigenere.g10code.de> Message-ID: <87h9qx3p83.wl-neal@walfield.org> Hi, At Thu, 28 May 2015 12:08:56 +0200, Werner Koch wrote: > > On Thu, 28 May 2015 10:22, dkg at fifthhorseman.net said: > > > I'd be happy to try to get something like pinentry-gnome3 into debian if > > it's ready, though. Is it ready? > > @neal: Any immediate plans to fix certain things? > > If not I can do yet another release. It will miss the hide/unhide > feature but if that helps to get rid of a gnome problem, I am all in > favor of doing a release today. I'm feeling pretty good about the code at this point and I don't have any more changes planned. Let's do a release. Neal From neal at walfield.org Thu May 28 13:49:16 2015 From: neal at walfield.org (Neal H. Walfield) Date: Thu, 28 May 2015 13:49:16 +0200 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: <87iobdypnn.fsf@vigenere.g10code.de> References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <87iobdypnn.fsf@vigenere.g10code.de> Message-ID: <87fv6g53cz.wl-neal@walfield.org> Hi, At Thu, 28 May 2015 12:14:52 +0200, Werner Koch wrote: > On Thu, 28 May 2015 11:03, ueno at gnu.org said: > > > Sure, thanks. Please also considier adding TMPDIR, since emacsclient > > looks for a socket file under "$TMPDIR/emacs$UID/server". > > TMPDIR is not Emacs specific and allowing a client to change that > variable for Pinentry is not a good idea. Why not using an emacs > specific variable for this or change it in pinentry-emacs. > > @neal: Do you have time to look at the patch? I don't think I'll find time today, but I'll take a look at it in the next few days. Neal From wk at gnupg.org Thu May 28 15:20:52 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 28 May 2015 15:20:52 +0200 Subject: [PATCH] g10: Fix a race condition initially creating trustdb In-Reply-To: <5566D08E.6070009@fsij.org> (NIIBE Yutaka's message of "Thu, 28 May 2015 17:23:42 +0900") References: <555B17FA.9070601@fsij.org> <555BD2F7.8000706@fsij.org> <555BFA13.9010604@fsij.org> <555DC01C.8090408@fsij.org> <5562B5F1.1080907@fsij.org> <5566D08E.6070009@fsij.org> Message-ID: <87wpzsyh1n.fsf@vigenere.g10code.de> On Thu, 28 May 2015 10:23, gniibe at fsij.org said: > Here is again for review. Fine. I am also glad that you took care to re-use an already translated string. Thanks. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ueno at gnu.org Fri May 29 05:06:02 2015 From: ueno at gnu.org (Daiki Ueno) Date: Fri, 29 May 2015 12:06:02 +0900 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: <87fv6g53cz.wl-neal@walfield.org> (Neal H. Walfield's message of "Thu, 28 May 2015 13:49:16 +0200") References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <87iobdypnn.fsf@vigenere.g10code.de> <87fv6g53cz.wl-neal@walfield.org> Message-ID: "Neal H. Walfield" writes: >> Why not using an emacs specific variable for this or change it in >> pinentry-emacs. Yes, it would be certainly possible. On the other hand, I now have a few concerns on using the emacsclient protocol for the Pinentry purpose: the output strings are encoded in 'file-name-coding-system', which can be different from the locale encoding, and are even pretty-printed with 'pp'. So, I wonder if it might be better to invent a dedicated protocol for pinentry-emacs, only supporting raw UTF-8 strings and communicating through a fixed socket. In that case, we could eliminate the need for the envvar. >> @neal: Do you have time to look at the patch? > > I don't think I'll find time today, but I'll take a look at it in the > next few days. Thanks. Regards, -- Daiki Ueno From gniibe at fsij.org Fri May 29 07:12:17 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 29 May 2015 14:12:17 +0900 Subject: scd: Fix key template of ECC. Message-ID: <5567F531.2090803@fsij.org> Hello, Here is simple fix to match ECC support in OpenPGPcard specification 3.0. The value 0x91 was my guess-work, and it found it's wrong. The impact is nothing, as Gnuk 1.1 doesn't check this particular value. This is simple obvious change, so, I'm going to push it now. diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index 10bd64e..8520231 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -2755,7 +2755,7 @@ build_ecc_privkey_template (app_t app, int keyno, datalen = 0; tp = privkey; - tp += add_tlv (tp, 0x91, ecc_d_len); /* Tag 0x91??? */ + tp += add_tlv (tp, 0x92, ecc_d_len); datalen += ecc_d_len; privkey_len = tp - privkey; -- From folkert at vanheusden.com Fri May 29 09:05:17 2015 From: folkert at vanheusden.com (folkert) Date: Fri, 29 May 2015 09:05:17 +0200 Subject: passphrase callback In-Reply-To: <87vbfdyyks.fsf@vigenere.g10code.de> References: <20150527193008.GA5163@belle.intranet.vanheusden.com> <20150527210717.GB5163@belle.intranet.vanheusden.com> <87vbfdyyks.fsf@vigenere.g10code.de> Message-ID: <20150529070517.GC5163@belle.intranet.vanheusden.com> > > Found out that the documentation on the gnu website is no longer > > up-to-date and that I need to set the pin mode to loop-back: > > gnu.org or gnupg.org - I have mot updated anything at gnu.org for quite > soem time. However, all packages come with a reference manual. The gnu.org one iirc. It doesn't mention the new pin calls. > > [pid 14558] write(2, "gpg: invalid option \"--pinentry-mode=loopback\"\n", 47) = 47 > > This is a bit odd I would say? > > No. --pinentry-mode is a new feature of GnuPG 2.1 and the gpgme manual > does not yet document this new API. You are using 2.0 which does not > provide pinentry-mode at all. Ah so there's a mismatch between the gpgme and gpg2 version in debian right? Can you confirm this? Then I'll create a debian bug report for it. > >> I'm trying to use gpgme in an unattended environment, e.g. without user > >> interaction. > >> Now I try to use gpgme_set_passphrase_cb() and I find two issues: > >> - when I invoke it without the ctx beining setup, it silently > >> ignores/fails > > Sure, without a context gpgme can't store the callback. Yeah but maybe it should emit an error or so. Maybe in debug-mode. > >> - even though I set the passphrase callback, it still tries to invoke > >> the gpg-agent gui. if I remove that program (as the situation will be > >> on he server), it still doesn't use the passphrase callback > > That depends on the configuraion of gpg 2.0 or 1.4. IIRC< you need to > use no-use-agent in gpg.conf. thanks! Folkert van Heusden -- ---------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com From dkg at fifthhorseman.net Fri May 29 17:17:21 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 29 May 2015 11:17:21 -0400 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: <87fv6g53cz.wl-neal@walfield.org> References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <87iobdypnn.fsf@vigenere.g10code.de> <87fv6g53cz.wl-neal@walfield.org> Message-ID: <87twuv9zwe.fsf@alice.fifthhorseman.net> On Thu 2015-05-28 07:49:16 -0400, Neal H. Walfield wrote: > I don't think I'll find time today, but I'll take a look at it in the > next few days. Thanks, Neal! I'm sorry i haven't had the time to look into this more deeply myself. Scanning the code, it looks like it has a sensible general structure, as long as the change to gpg's common/session-env.c is set. however, doing this seems like it might open up a possible hole in the protections offered by the agent, so i think we need to proceed thoughtfully. If the requester can instruct the agent to talk to arbitrary emacs sessions, then an attacker with access to the agent's socket can potentially do things like mount password-guessing attacks without any visibility to the user. It's possible that this kind of attack is already available to an attacker who has access to both the gpg-agent socket and an allocated TTY, via sending the TTY environment variable to the agent, which then passes it on to pinentry -- so maybe the argument would be that this is not strictly any worse? Do we care about these kind of attacks? --dkg From ueno at gnu.org Sat May 30 01:05:16 2015 From: ueno at gnu.org (Daiki Ueno) Date: Sat, 30 May 2015 08:05:16 +0900 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: <87twuv9zwe.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 29 May 2015 11:17:21 -0400") References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <87iobdypnn.fsf@vigenere.g10code.de> <87fv6g53cz.wl-neal@walfield.org> <87twuv9zwe.fsf@alice.fifthhorseman.net> Message-ID: <87617bf0ib.fsf-ueno@gnu.org> Daniel Kahn Gillmor writes: > however, doing this seems like it might open up a possible hole in the > protections offered by the agent, so i think we need to proceed > thoughtfully. If the requester can instruct the agent to talk to > arbitrary emacs sessions, then an attacker with access to the agent's > socket can potentially do things like mount password-guessing attacks > without any visibility to the user. Thanks for bringing it up. I think Emacs is secure enough nowadays to such kind of attacks, i.e., it properly sets up the permission of the parent directory of a socket, and the client does some checks of the file owner. However, we should double-check if it is secure enough for this use-case, indeed. By the way, is the envvar restriction really working? I was curious how pinentry-gnome3 works without knowing the address of the D-Bus session bus, since gcr internally uses it to talk to the actual prompter service implementation (i.e., gnome-shell). So just tried: $ pkill gpg-agent $ gpg2 --symmetric -o /dev/null < /dev/null ...works ok... $ pkill gpg-agent $ DBUS_SESSION_BUS_ADDRESS=unix:path=/tmp/invalid \ gpg2 --symmetric -o /dev/null < /dev/null gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! gpg: cancelled by user gpg: error creating passphrase: Operation cancelled gpg: symmetric encryption of '[stdin]' failed: Operation cancelled I don't see the envvar listed in common/session-env.c, but it seems to be actually passed to pinentry-gnome3: $ DBUS_SESSION_BUS_ADDRESS=unix:path=/tmp/invalid \ strace -e trace=connect -f gpg2 --symmetric -o /dev/null < /dev/null ... 25983 connect(5, {sa_family=AF_LOCAL, sun_path="/tmp/invalid"}, 110) = -1 ENOENT (No such file or directory) ... Perhaps libassuan/src/system-posix.c:__assuan_spawn should use execve, instead of execv? Regards, -- Daiki Ueno From wk at gnupg.org Sat May 30 20:27:15 2015 From: wk at gnupg.org (Werner Koch) Date: Sat, 30 May 2015 20:27:15 +0200 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: <87617bf0ib.fsf-ueno@gnu.org> (Daiki Ueno's message of "Sat, 30 May 2015 08:05:16 +0900") References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <87iobdypnn.fsf@vigenere.g10code.de> <87fv6g53cz.wl-neal@walfield.org> <87twuv9zwe.fsf@alice.fifthhorseman.net> <87617bf0ib.fsf-ueno@gnu.org> Message-ID: <87twutvs3g.fsf@vigenere.g10code.de> On Sat, 30 May 2015 01:05, ueno at gnu.org said: > I don't see the envvar listed in common/session-env.c, but it seems to > be actually passed to pinentry-gnome3: You started gpg-agent trhough gpg and thus it inherits all envvars. However, if you have an gpg-agent already running in another session it won't know about envvars set in the gpg session. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From neal at walfield.org Sun May 31 18:00:55 2015 From: neal at walfield.org (Neal H. Walfield) Date: Sun, 31 May 2015 18:00:55 +0200 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> Message-ID: <874mms4tzc.wl-neal@walfield.org> Hi Daiki, Thank you for this patch. It looks quite good. There are some minor issues. I can correct them if you don't have time, but I'd appreciate it if you could just confirm my understanding. Thanks, :) Neal At Thu, 28 May 2015 18:03:44 +0900, Daiki Ueno wrote: > +if test "$pinentry_emacs" = "maybe"; then > + AC_MSG_CHECKING([if Unix domain socket is supported]) > + AC_TRY_COMPILE([ > +#include > +#include > +], > + [int s = socket (AF_UNIX, SOCK_STREAM, 0);], > + [_unixsock_works=yes], > + [_unixsock_works=no]) > + AC_MSG_RESULT($_unixsock_works) > + if test "$_unixsock_works" = "yes"; then > + pinentry_emacs=yes > + else > + pinentry_emacs=no > + fi > +fi I think we should check for != "no" here. If pinentry_emacs is yes, but we don't support unix domain sockets, then it would be better to error out here than when compiling the code. Do you agree? > --- /dev/null > +++ b/pinentry/pinentry-emacs.c > +#include As far as I can tell, this include is gratuitious. > + if (strlen (tmpdir) + strlen (socket_name) + 10 + 2 > + >= sizeof (emacs_server_address.sun_path)) > + { > + fprintf (stderr, "socket name is too long\n"); > + free (tmpdir_storage); > + return 0; > + } > + > + sprintf (emacs_server_address.sun_path, "%s/emacs%lu/%s", > + tmpdir, (unsigned long) uid, socket_name); I think the check above is wrong. It should be something like: if (strlen (tmpdir) + strlen("/emacs") + 10 + strlen("/") + strlen (socket_name) + 1 >= sizeof (emacs_server_address.sun_path)) Or, less conservatively, we could replace 10 with the actual length of the uid as a base-10 string. Perhaps the best approach is to use something like asprintf. (I say like, because we can't use asprintf: it is not portable. But, recent version of libgpg-error provide a replacement.) > +static int > +connect_to_server (void) > ... > + if (connect (s, (struct sockaddr *) &emacs_server_address, > + strlen (emacs_server_address.sun_path) + 2) < 0) Why don't you just use 'sizeof (emacs_server_address)' here? I really don't like the magic number 2 here. > +static int > +read_from_emacs (int s, int timeout, char *result, size_t *lengthp) > +{ > ... > + /* Loop over all NL-terminated messages. */ > + for (end_p = p = string; end_p != NULL && *end_p != '\0'; p = end_p) > + { > + char *str; > + size_t str_length; > + end_p = strchr (p, '\n'); > + if (end_p != NULL) > + *end_p++ = '\0'; > + if (strprefix ("-print ", p)) > + { > + /* -print STRING: Print STRING on the terminal. */ > + str = p + strlen ("-print "); > + unquote_argument (str, &str_length); > + if (capacity < !!needlf + str_length) > + return 0; > + > + if (needlf) > + { > + *out_p++ = '\n'; > + capacity--; > + } > + > + memcpy (out_p, str, str_length); > + out_p += str_length; > + capacity -= str_length; > + needlf = str[0] == '\0' ? needlf : str[strlen (str) - 1] != '\n'; > + } > + else if (strprefix ("-print-nonl ", p)) > + { > + /* -print-nonl STRING: Print STRING on the terminal. > + Used to continue a preceding -print command. */ > + str = p + strlen ("-print-nonl "); > + unquote_argument (str, &str_length); > + if (capacity < str_length) > + return 0; > + memcpy (out_p, str, str_length); > + out_p += str_length; > + capacity -= str_length; > + needlf = str[0] == '\0' ? needlf : str[strlen (str) - 1] != '\n'; > + } > + else if (strprefix ("-error ", p)) > + { > + /* -error DESCRIPTION: Signal an error on the terminal. */ > + got_error = 1; > + break; > + } > + } > + } Does it make sense to emit a warning if there is a line with an unrecognized prefix? As far as I can see, lines with unknown commands are currently ignored. > +char * > +build_command (const char *name, const char *value) > +{ ... > + command_length = strlen ("(" CALLBACK_NAME " \"\" )") > + + strlen (name) + quoted_value_length; > + > + command = malloc (command_length + 1); > + if (!command) > + { > + perror ("malloc"); > + return NULL; > + } > + > + sprintf (command, "(" CALLBACK_NAME " \"%s\" %s)", > + name, quoted_value); > + if (quoted_value != nil) > + free (quoted_value); Here's another instance where I'd strongly prefer something like asprintf. > +int > +set_value (pinentry_t pe, const char *name, const char *value) > +{ > + char buffer[16], *quoted_command, *local_value = value; > + size_t length; > + int s, success; > + > + if (value) > + { > + local_value = pinentry_utf8_to_local (pe->lc_ctype, value); > + if (!local_value) > + return 0; > + } > + > + quoted_command = build_command (name, local_value); > + if (local_value != value) > + free (local_value); I think this comparison is useless. If value is not NULL, then we call pinentry_utf8_to_local, which always allocates a new buffer. > + if (!quoted_command) > + return 0; > + > + s = connect_to_server (); > + if (s < 0) > + { > + free (quoted_command); > + return 0; > + } > + > + length = sizeof (buffer); > + success = send_to_emacs (s, "-eval ") > + && send_to_emacs (s, quoted_command) > + && send_to_emacs (s, "\n") > + && read_from_emacs (s, pe->timeout, buffer, &length) > + && length == 1 && *buffer == 't'; > + > + free (quoted_command); > + close (s); > + > + return success; > +} > + > +int > +do_password (pinentry_t pe) > +{ > + char buffer[16], *quoted_command; > + size_t length; > + int s, success; > + > + set_value (pe, "SETTITLE", pe->title); > + set_value (pe, "SETDESC", pe->description); > + set_value (pe, "SETERROR", pe->error); > + set_value (pe, "SETPROMPT", pe->prompt); Does emacs not support setting custom button labels? If pe->prompt is NULL, then you should fallback to pe->default_prompt. If you have time, it would be nice to add support for the external password manager checkbox. In the very least, please note the lack of this support with an XXX comment in the source code. > + if (pe->repeat_passphrase) > + pe->repeat_okay = 1; Why are you setting this if the user didn't actually enter the password twice? > + /* FIXME: Should we return the length of PASSWORD_UTF8, as > + described in pinentry.h? */ > + return 1; I recently changed the API so that that is no longer necessary. I see I forgot to update the comment for pinentry_cmd_handler_t. I'll do that. > +int > +do_confirm (pinentry_t pe) > +{ > + char buffer[16], *quoted_command; > + size_t length; > + int s, success; > + > + set_value (pe, "SETTITLE", pe->title); > + set_value (pe, "SETDESC", pe->description); > + set_value (pe, "SETERROR", pe->error); > + set_value (pe, "SETPROMPT", pe->prompt); Again, please fallback to pe->default_prompt. Any reason, there is no support for custom button labels? Also, what about support for the other button? If this is not yet possible, please note it with an XXX comment. > diff --git a/pinentry/pinentry.c b/pinentry/pinentry.c > index 9a6a090..0187309 100644 > --- a/pinentry/pinentry.c > +++ b/pinentry/pinentry.c > @@ -173,7 +173,7 @@ pinentry_assuan_reset_handler (ASSUAN_CONTEXT ctx) > > static int lc_ctype_unknown_warning = 0; > > -#if defined FALLBACK_CURSES || defined PINENTRY_CURSES || defined PINENTRY_GTK > +#if defined FALLBACK_CURSES || defined INSIDE_EMACS || defined PINENTRY_CURSES || defined PINENTRY_GTK > char * > pinentry_utf8_to_local (const char *lc_ctype, const char *text) > { I think we should check if PINENTRY_EMACS is defined, not INSIDE_EMACS here. From folkert at vanheusden.com Sun May 31 20:14:06 2015 From: folkert at vanheusden.com (folkert) Date: Sun, 31 May 2015 20:14:06 +0200 Subject: for signing; selecting a specific private key Message-ID: <20150531181406.GF5163@belle.intranet.vanheusden.com> Hi, I'm trying to sign some data. In the key ring I have more then 1 private key so I want to select the correct one. This fails with: "Unusable secret key (117440566)". The key was generated with gnupg2 itself. sec 1024R/14B7E8E6 2015-05-27 Key fingerprint = 95C7 6C5E F839 43DA 2F32 2CF4 D2C2 5144 14B7 E8E6 uid testkey2 (testkey2) ssb 1024R/ED8059EA 2015-05-27 pub rsa1024/14B7E8E6 created: 2015-05-27 expires: never usage: SC trust: ultimate validity: ultimate sub rsa1024/ED8059EA created: 2015-05-27 expires: never usage: E sub rsa1024/74D6F5C6 created: 2015-05-31 expires: never usage: S First I check if there's a private key for the key selected: gpgme_op_keylist_start(..., ..., 1); if (gpgme_op_keylist_nex() == GPG_ERR_NO_ERROR) { proceed } do the signing: gpgme_new() gpgme_set_pinentry_mode(GPGME_PINENTRY_MODE_LOOPBACK) // yes i installed v2.1 gpgme_set_passphrase_cb() /* ...binary to gpgme_data_t... */ gpgme_data_set_encoding(GPGME_DATA_ENCODING_BINARY) gpgme_signers_clear() gpgme_signers_add() // <- that key that I checked for existance earlier if (gpgme_signers_count() != 1) { fail(); } // sanity check gpgme_op_encrypt_sign(ctx, recipient, GPGME_ENCRYPT_ALWAYS_TRUST /* FIXME */, data_in, sig); Now that gpgme_op_encrypt_sign always fails with that error I wrote earlier. Any tips/hints? Software versions: ----------------- gnupg 1.4.18-7 gnupg-agent 2.1.4-1 gnupg2 2.1.4-1 libgpgme++2 4:4.14.2-2+b1 libgpgme11:amd64 1.5.1-6 libgpgme11-dev 1.5.1-6 python-gnupginterface 0.3.2-9.1 Folkert van Heusden -- MultiTail ist eine flexible Applikation um Logfiles und Kommando Eingaben zu ?berpr?fen. Inkl. Filter, Farben, Zusammenf?hren, Ansichten etc. http://www.vanheusden.com/multitail/ ---------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com