From rfkrocktk at gmail.com Wed Jun 1 01:10:08 2016 From: rfkrocktk at gmail.com (Naftuli Tzvi Kay) Date: Tue, 31 May 2016 16:10:08 -0700 Subject: Inspect output of --export and --export-secret-*? Message-ID: Hello, I'm learning a lot about GnuPG currently and I'd like to understand the file format and be able to study my exported public and private keys to validate my assumptions about how the various export commands work. Is there a tool out there which will allow me to examine the contents of a public or private key exported to disk? I'd like to be able to take an arbitrary file and see exactly what's in it. Does such a tool exist? Thanks, - Naftuli Tzvi -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at adversary.org Wed Jun 1 07:33:43 2016 From: ben at adversary.org (Ben McGinnes) Date: Wed, 1 Jun 2016 15:33:43 +1000 Subject: python bindings for gpgme In-Reply-To: <20160531132139.10665.36847@thinkbox.jade-hamburg.de> References: <201605311439.22496.bernhard@intevation.de> <20160531132139.10665.36847@thinkbox.jade-hamburg.de> Message-ID: <20160601053343.GJ91898@adversary.org> On Tue, May 31, 2016 at 03:21:39PM +0200, Justus Winter wrote: > > > * Why was the swig based approach of pyme chosen over the manually build > > interface of pygpgme? > > I don't know the details, but Ben did some work porting the pyme > bindings to Python3 well before my time, so we thought it was best to > pick that up. Also, the pyme way should be easier to maintain, > because functionality added to gpgme should become available without > touching the bindings in most cases. I've got a duck out in a moment, so I'll come back to this thread when I get back. For now, though: the pyme project was first started back in around 2000 or 2001 and at that time SWIG was the best choice. Still, it is very dated now and there are better ways of doing it, which is why there are plans to replace pyme in its entirety with bindings using CFFI, which is getting a lot of attention from the PyPy developers and has already been leveraged very effectively in the cryptography.py project (pyca). The pyme code here is basically just the result of porting the version of pyme on PyPI from Python 2 to Python 3. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: not available URL: From wk at gnupg.org Wed Jun 1 08:54:36 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 01 Jun 2016 08:54:36 +0200 Subject: Inspect output of --export and --export-secret-*? In-Reply-To: (Naftuli Tzvi Kay's message of "Tue, 31 May 2016 16:10:08 -0700") References: Message-ID: <87fusxxutv.fsf@wheatstone.g10code.de> On Wed, 1 Jun 2016 01:10, rfkrocktk at gmail.com said: > Is there a tool out there which will allow me to examine the contents of a > public or private key exported to disk? I'd like to be able to take an > arbitrary file and see exactly what's in it. Does such a tool exist? gpg --list-packets FILE Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ From bernhard at intevation.de Wed Jun 1 09:30:29 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 1 Jun 2016 09:30:29 +0200 Subject: python bindings for gpgme In-Reply-To: <87d1o2gcie.fsf@alice.fifthhorseman.net> References: <201605311439.22496.bernhard@intevation.de> <5551365.8PJssPBumB@kymo.gruen> <87d1o2gcie.fsf@alice.fifthhorseman.net> Message-ID: <201606010930.29409.bernhard@intevation.de> Hi dkg, Am Dienstag, 31. Mai 2016 23:10:01 schrieb Daniel Kahn Gillmor: > > So far I haven't done a comparison between pygpgme and pyme. > > From my point of view the most pythonic one should be used. > > pygpgme is already available for python3 for a few years longer than > > pyme, I believe. > > i've been using pygpgme for a few years now, including some of that with > python3. ?I'd really like there to be one officially-supported python > gpgme binding, and it should absolutely have stable python 3 support. how important is the criteria "pythonic" to you? Do you view pygpgme compared to pyme? (I guess you will have looked at both at least a little bit.) Best, Bernhard -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Wed Jun 1 09:38:44 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 1 Jun 2016 09:38:44 +0200 Subject: python bindings for gpgme In-Reply-To: <20160601053343.GJ91898@adversary.org> References: <201605311439.22496.bernhard@intevation.de> <20160531132139.10665.36847@thinkbox.jade-hamburg.de> <20160601053343.GJ91898@adversary.org> Message-ID: <201606010938.44733.bernhard@intevation.de> Hi Ben, Am Mittwoch, 1. Juni 2016 07:33:43 schrieb Ben McGinnes: > I've got a duck out in a moment, so I'll come back to this thread when > I get back. ? (No problem. I appreciate your work towards better python bindings!) > For now, though: the pyme project was first started back > in around 2000 or 2001 and at that time SWIG was the best choice. Yes, we've tried swig at that time as well for a different python library. The maintenance work and lack of precision (because of the abstraction) made us > Still, it is very dated now and there are better ways of doing it, > which is why there are plans to replace pyme in its entirety with > bindings using CFFI, which is getting a lot of attention from the PyPy > developers and has already been leveraged very effectively in the > cryptography.py project (pyca). Until those plans come to be, we should select the better abstraction I guess. (I do not have much experience with CFFI [1], the challenge will be to map the C api of gpgme to an object oriented pythonic interface.) > The pyme code here is basically just the result of porting the version > of pyme on PyPI from Python 2 to Python 3. Why did you choose porting pyme over pygpgme? Which one do you consider more pythonic? The challenge I see is that if there is an official python-gpgme in a week or so, this API will need to be supported for a longer time. Even if the implementation underneath could be completely replaced, the python API probably could not. So if pygpgme offers the better abstraction now, making the pyme abstraction official may pose a problem for the future. Best, Bernhard [1] https://pypi.python.org/pypi/cffi "Foreign Function Interface for Python calling C code." -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Wed Jun 1 09:52:16 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 1 Jun 2016 09:52:16 +0200 Subject: Web Key Directory (dealing with subaddressing?) In-Reply-To: <87r3cz8irr.fsf@wheatstone.g10code.de> References: <201605171507.41446.bernhard@intevation.de> <87r3cz8irr.fsf@wheatstone.g10code.de> Message-ID: <201606010952.20102.bernhard@intevation.de> Am Mittwoch, 18. Mai 2016 17:53:28 schrieb Werner Koch: > On Tue, 17 May 2016 15:07, bernhard at intevation.de said: > > ?148 The so mapped "local-part" is hashed using the SHA-1 algorithm. > > > > What about the common pattern of subaddressing? > > Still part of the local-part thus it does not matter. ?It is an open > question on how to handle such sub-addressing. ?I discussed this in > detail with Neal while thinking about TOFU; our conclusion was that it > is to early to settle for a standard on how to canonicalize such > addresses. If that makes sense at all. The server must know, as it will do the email routing. This is why me (and I believe Guilhem, too) think that transfering the original localpart to the server and let the server do the decisions about an and if to handle this maybe be a good idea to consider further. > > I think there is merit in letting the server decide, how to treat it. > > That is the idea of the RFC but not the idea of the user. ?Users don't > care about case and use whatever case they got (e.g. from papers). ?I > have also seen people who are in the habit of always upcasing mail > addresses. Letting the server (of the mail service provider (MSP)) decide how to deal with the local-part is best for the user and she can continue to use all the interpretations that her MSP offers without further configuration. The user does not care about if this is implemented in her client or on her MSP's server. Best Regards, Bernhard -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Wed Jun 1 10:06:32 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 1 Jun 2016 10:06:32 +0200 Subject: Web Key Directory (dealing with subaddressing?) In-Reply-To: <20160518171543.GA23537@localhost.localdomain> References: <201605171507.41446.bernhard@intevation.de> <20160518171543.GA23537@localhost.localdomain> Message-ID: <201606011006.36349.bernhard@intevation.de> Am Mittwoch, 18. Mai 2016 19:15:43 schrieb Guilhem Moulin: > Right, the recipient delimiter is a valid character in the RFC 5321 > local-part that is not allowed in account names. ?Clients shouldn't > assume that messages sent ?u+e at example.net? are delivered to > ?u at example.net?. ?For instance ?u+e? and ?u? can very well be two > different account names. [citation moved further to the top:] > Furthermore, letting the server interpret the *original* local part > solves the case sensitivity issue I mentioned earlier. I take it that you agree that it would be an advantage to let the server see the original local-part and decide how to handle it. The next question is == How to transfer the original local-part? > > We could just use the URL to transfer the full address or > > /domain-part/local-part and then have the server decide. > > This conflicts with hashing the local part, since the server needs to > reconstruct the original address from the given URL. Yes, only using it in the url would be feasable exclusively in the case when we do not hash. > I agree with Werner that it not desirable to have non URL-safe characters > in the local parts (such as ?/?), but a base32-URL or base64-URL would do. The goal is to ease implementations on the server and client sides, I assume. As towards the danger of "non-url-safe" characters: The server implementations will have to saveguard against malicious requests anyway. If we define to interpret everything right off xyz/domain-part/ as being the local-part, I think there is no real danger and usual URL percent coding of RFC3986 could be used, aka %2F for '/'. == email alias names > On a related note, should the server ensure that the same key is > delivered for the account itself and its aliases? ?(Such as for > login at example.org and full.name at example.org.) ?Since messages sent to > either address are routed to the same account, it make sense to use the > same key, but of course a downside is that it exposes the server's alias > database. ?All in all I think the decision should be left to the user or > service operator. The question also occurred to me. I have not been giving it much thought so far. One design idea could be that the client will add more user ids (as a user often also needs to add more "identities" in the client to use a specific from: address with real name and identify which emails are considered "mine".) Best, Bernhard -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From justus at g10code.com Wed Jun 1 12:02:57 2016 From: justus at g10code.com (Justus Winter) Date: Wed, 01 Jun 2016 12:02:57 +0200 Subject: python bindings for gpgme In-Reply-To: <5551365.8PJssPBumB@kymo.gruen> References: <201605311439.22496.bernhard@intevation.de> <20160531132139.10665.36847@thinkbox.jade-hamburg.de> <5551365.8PJssPBumB@kymo.gruen> Message-ID: <20160601100257.3724.83134@thinkbox.jade-hamburg.de> Hi Bernhard, Quoting Bernhard Reiter (2016-05-31 21:23:48) > In my experience what counts most for python developers is that the > bindings are very pythonic. Agreed. > In my limited experience the SWIG layer makes this harder to do. I don't see why. SWIG creates a really thin layer, and the resulting interface is a very faithful image of the c api. Note that the same is true for every FFI solution. > Also the additional abstraction really pays out if you use SWIG to > create binding for a number of languages. Not true. SWIG requires target language-specific code. > Otherwise it is just one more abstraction layer to learn when you > want to debug or extend things. I disagree. It is quite the opposite really, with pyme/SWIG we get most enhancements to GPGME for free, whereas in pygpgme it requires a lot of c code talking to Python's c api. > So far I haven't done a comparison between pygpgme and pyme. Let's compare encryption then: pyme: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=blob;f=lang/python/tests/t-encrypt.py;h=24869fcd15e19a4cef2e5144570d9a5d37586e58;hb=HEAD pygpgme: http://bazaar.launchpad.net/~jamesh/pygpgme/trunk/view/head:/tests/test_encrypt_decrypt.py#L99 I don't see much of a difference really. > From my point of view the most pythonic one should be used. And here is the thing. While pygpgme is implemented purely in c, and any attempt of making it more pythonic must also be done in c, pyme is using SWIG for the FFI, and layers a shim written in Python on top. This is the place one augments or extends the api to make it more pythonic, e.g.: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=blob;f=lang/python/pyme/core.py;h=cc262c95aba3abc9fb7986af62e9b579b8229723;hb=HEAD#l529 > pygpgme is already available for python3 for a few years longer than > pyme, I believe. I must admit I didn't compare pygpgme and pyme before, mostly because I wasn't around when the initial effort started, but if I should choose now, I'd chose pyme as a starting point again. Having said that, I agree that making it a little more pythonic is important, as Python is the cheese to catch developers these days. And we will do just that ;) Here is what a decrypting filter looks like with the current bindings: ~~~ snip ~~~ import sys from pyme import core core.check_version() core.Context().op_decrypt(core.Data(file=sys.stdin), core.Data(file=sys.stdout)) ~~~ snap ~~~ And I plan to bring it down to: ~~~ snip ~~~ import sys from pyme import core core.Context().op_decrypt(sys.stdin, sys.stdout) ~~~ snap ~~~ Also, I'm thinking about offering an 'open' function that offers transparent encryption/decryption, similar how there is 'codecs.open' offering transparent encoding/decoding. Cheers, Justus From wk at gnupg.org Wed Jun 1 12:37:05 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 01 Jun 2016 12:37:05 +0200 Subject: python bindings for gpgme In-Reply-To: <201606010938.44733.bernhard@intevation.de> (Bernhard Reiter's message of "Wed, 1 Jun 2016 09:38:44 +0200") References: <201605311439.22496.bernhard@intevation.de> <20160531132139.10665.36847@thinkbox.jade-hamburg.de> <20160601053343.GJ91898@adversary.org> <201606010938.44733.bernhard@intevation.de> Message-ID: <87eg8hw5yl.fsf@wheatstone.g10code.de> On Wed, 1 Jun 2016 09:38, bernhard at intevation.de said: > Why did you choose porting pyme over pygpgme? Ben has been working on this for more than a year (see https://git.gnupg.org/gpgme.git) and explained his work on gnupg-devel. Challenging this decision now does not seem to be very helpful. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ From ben at adversary.org Wed Jun 1 13:44:58 2016 From: ben at adversary.org (Ben McGinnes) Date: Wed, 1 Jun 2016 21:44:58 +1000 Subject: python bindings for gpgme In-Reply-To: <87eg8hw5yl.fsf@wheatstone.g10code.de> References: <201605311439.22496.bernhard@intevation.de> <20160531132139.10665.36847@thinkbox.jade-hamburg.de> <20160601053343.GJ91898@adversary.org> <201606010938.44733.bernhard@intevation.de> <87eg8hw5yl.fsf@wheatstone.g10code.de> Message-ID: <20160601114458.GB73302@adversary.org> On Wed, Jun 01, 2016 at 12:37:05PM +0200, Werner Koch wrote: > On Wed, 1 Jun 2016 09:38, bernhard at intevation.de said: > > > Why did you choose porting pyme over pygpgme? > > Ben has been working on this for more than a year (see > https://git.gnupg.org/gpgme.git) and explained his work on gnupg-devel. > Challenging this decision now does not seem to be very helpful. I went back and had another look at pygpgme to see why I didn't choose that route. I was reminded very quickly why: it doesn't compile so well on OS X or, indeed, at all. I'd have to rewrite bits of it to a much greater extent. Plus from the PyPI view it looks a bit abandoned (that may not actually be the case, but the version on PyPI hasn't been updated in four years. Oh, there is a port for it on MacPorts which might work, but it's Python 2.7 only, so nope. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: not available URL: From bernhard at intevation.de Wed Jun 1 14:38:29 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 1 Jun 2016 14:38:29 +0200 Subject: python bindings for gpgme In-Reply-To: <20160601114458.GB73302@adversary.org> References: <201605311439.22496.bernhard@intevation.de> <87eg8hw5yl.fsf@wheatstone.g10code.de> <20160601114458.GB73302@adversary.org> Message-ID: <201606011438.33105.bernhard@intevation.de> Am Mittwoch, 1. Juni 2016 13:44:58 schrieb Ben McGinnes: > On Wed, Jun 01, 2016 at 12:37:05PM +0200, Werner Koch wrote: > > On Wed, 1 Jun 2016 09:38, bernhard at intevation.de said: > > > Why did you choose porting pyme over pygpgme? > > > > Ben has been working on this for more than a year (see > > https://git.gnupg.org/gpgme.git) and explained his work on gnupg-devel. > > Challenging this decision now does not seem to be very helpful. I saw the explanation last May, there has not been much discussion since then. And frankly I did not fully realize back then, that you would want this to be the official gpgme python api. I realize I am being late, but it is as early as I understood the potential implications. Maybe pyme is the better choice, I don't know. I haven't seen the decision documented anywhere, though. > I went back and had another look at pygpgme to see why I didn't choose > that route. I was reminded very quickly why: it doesn't compile so > well on OS X or, indeed, at all. I'd have to rewrite bits of it to a > much greater extent. That is something that could have been potentially fixed, if the mapping to python were better. (Which I don't know at this point.) > Plus from the PyPI view it looks a bit abandoned > (that may not actually be the case, but the version on PyPI hasn't > been updated in four years. Both pyme and pygpgme did not see much of maintenance work if I remember correctly. I think that the 0.3 release of pygpgme in 2012 possibly is the newest larger update to both libraries. > Oh, there is a port for it on MacPorts which might work, but it's > Python 2.7 only, so nope. python3-gpgme packages on Debian and Ubuntu show that python3 support should be close. Anyway both points do not say much about how pythonic the abstraction is for both libraries, so I'm switchting this to the thread with Justus. -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Wed Jun 1 14:53:38 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 1 Jun 2016 14:53:38 +0200 Subject: python bindings for gpgme In-Reply-To: <20160601100257.3724.83134@thinkbox.jade-hamburg.de> References: <201605311439.22496.bernhard@intevation.de> <5551365.8PJssPBumB@kymo.gruen> <20160601100257.3724.83134@thinkbox.jade-hamburg.de> Message-ID: <201606011453.43022.bernhard@intevation.de> Hi Justus, Am Mittwoch, 1. Juni 2016 12:02:57 schrieb Justus Winter: > Quoting Bernhard Reiter (2016-05-31 21:23:48) > > > In my experience what counts most for python developers is that the > > bindings are very pythonic. > > Agreed. so we probably should evaluate this. > > In my limited experience the SWIG layer makes this harder to do. > > I don't see why. SWIG creates a really thin layer, and the resulting > interface is a very faithful image of the c api. Note that the same > is true for every FFI solution. You can probably implement a speficic API with all four solutions that have been mentioned (swig, cffi, cython and manual c-code). But, as Ben also noted SWIG is old style and the design decision of SWIG (AFAIR) was to generalize the interface to generate bindings for several languages at once. > > Also the additional abstraction really pays out if you use SWIG to > > create binding for a number of languages. > > Not true. SWIG requires target language-specific code. That SWIG requires some language-specific code does not mean it is necessarily good or elegant to create good binding for one language. The design goal is to abstract and so SWIG aims towards that goal, making it harded to use SWIG for python only. Of course if you want to support ruby, python and some more at once, this extra effort may pay out. > > Otherwise it is just one more abstraction layer to learn when you > > want to debug or extend things. > > I disagree. It is quite the opposite really, with pyme/SWIG we get > most enhancements to GPGME for free, whereas in pygpgme it requires a > lot of c code talking to Python's c api. My argument is: First I have to understand python's c api with SWIG I have to understand python's c api and SWIG (and its generated code). > > So far I haven't done a comparison between pygpgme and pyme. > > Let's compare encryption then: > > pyme: > http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=blob;f=lang/python/te >sts/t-encrypt.py;h=24869fcd15e19a4cef2e5144570d9a5d37586e58;hb=HEAD pygpgme: > http://bazaar.launchpad.net/~jamesh/pygpgme/trunk/view/head:/tests/test_enc >rypt_decrypt.py#L99 > > I don't see much of a difference really. Comparing the operation and the results, pygpgme combination into one call seems more pythonic to me. Over time this will add up to a lot of more code. > > From my point of view the most pythonic one should be used. > > And here is the thing. While pygpgme is implemented purely in c, and > any attempt of making it more pythonic must also be done in c, pyme is > using SWIG for the FFI, and layers a shim written in Python on top. > This is the place one augments or extends the api to make it more > pythonic, e.g.: > > http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=blob;f=lang/python/pyme/core.py;h=cc262c95aba3abc9fb7986af62e9b579b8229723;hb=HEAD#l529 My main concern is the python API. A secondary concern is how it is implemented. You can see that python people move off SWIG to stuff like CFFI (which Ben reported about last May). pygpgme is closer to something like CFFI, one layer less indirection (though more c-code). > > pygpgme is already available for python3 for a few years longer than > > pyme, I believe. > > I must admit I didn't compare pygpgme and pyme before, mostly because > I wasn't around when the initial effort started, but if I should > choose now, I'd chose pyme as a starting point again. Having said > that, I agree that making it a little more pythonic is important, as > Python is the cheese to catch developers these days. And we will do > just that ;) What will be the status of the gpgme/lang/python binding when gpgme will be released? experimental? beta? Once people start relying on it, it will be harder to change the API itself. > Here is what a decrypting filter looks like with the current bindings: (This is only a simple example, so its value is limited. I think that the "op_" part looks ugly.) Best, Bernhard -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From justus at g10code.com Wed Jun 1 16:15:04 2016 From: justus at g10code.com (Justus Winter) Date: Wed, 01 Jun 2016 16:15:04 +0200 Subject: python bindings for gpgme In-Reply-To: <201606011453.43022.bernhard@intevation.de> References: <201605311439.22496.bernhard@intevation.de> <5551365.8PJssPBumB@kymo.gruen> <20160601100257.3724.83134@thinkbox.jade-hamburg.de> <201606011453.43022.bernhard@intevation.de> Message-ID: <20160601141504.3724.9533@thinkbox.jade-hamburg.de> Hi, Quoting Bernhard Reiter (2016-06-01 14:53:38) > Hi Justus, > > Am Mittwoch, 1. Juni 2016 12:02:57 schrieb Justus Winter: > > Quoting Bernhard Reiter (2016-05-31 21:23:48) > > > > > In my experience what counts most for python developers is that the > > > bindings are very pythonic. > > > > Agreed. > > so we probably should evaluate this. I just did, and as Werner noted, we are very well beyond the evaluation phase. > > > In my limited experience the SWIG layer makes this harder to do. > > > > I don't see why. SWIG creates a really thin layer, and the resulting > > interface is a very faithful image of the c api. Note that the same > > is true for every FFI solution. > > You can probably implement a speficic API with all four solutions > that have been mentioned (swig, cffi, cython and manual c-code). > But, as Ben also noted SWIG is old style and the design decision > of SWIG (AFAIR) was to generalize the interface to generate bindings for > several languages at once. > > > > Also the additional abstraction really pays out if you use SWIG to > > > create binding for a number of languages. > > > > Not true. SWIG requires target language-specific code. > > That SWIG requires some language-specific code [...] SWIG requires *only* language-specific code. In case you are curious, it is here: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=blob;f=lang/python/gpgme.i;hb=HEAD > does not mean it is necessarily good or elegant to create good > binding for one language. We did not create the binding, it was already there. > The design goal is to abstract and so SWIG aims towards that goal, > making it harded to use SWIG for python only. Of course if you want to support > ruby, python and some more at once, this extra effort may pay out. There is *no* language-independent code that we wrote. > > > Otherwise it is just one more abstraction layer to learn when you > > > want to debug or extend things. > > > > I disagree. It is quite the opposite really, with pyme/SWIG we get > > most enhancements to GPGME for free, whereas in pygpgme it requires a > > lot of c code talking to Python's c api. > > My argument is: First I have to understand python's c api with SWIG I have to > understand python's c api and SWIG (and its generated code). I disagree. With SWIG, you write functions translating c types to python types and back. Any function provided by the c library is then automagically wrapped, with the data being converted by the functions you wrote *once*. Add a new function to gpgme, and you likely don't need to do anything in pyme. With pygpgme, you write code translating the types forth and back *explicitly for every function you want to make available to python*. It is a huge overhead, and likely a source of many errors as that code is likely copied over and over again, without being properly understood. Let's look at the sizes: % sloccount pygpgme/src [...] 3037 src ansic=3037 % sloccount lang/python/helpers.* lang/python/gpgme.i lang/python/pyme 544 top_dir ansic=544 497 pyme python=497 Based on that I gather that there must be three to six times as many bugs in pygpgme. > > > So far I haven't done a comparison between pygpgme and pyme. > > > > Let's compare encryption then: > > > > pyme: > > http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=blob;f=lang/python/te > >sts/t-encrypt.py;h=24869fcd15e19a4cef2e5144570d9a5d37586e58;hb=HEAD pygpgme: > > http://bazaar.launchpad.net/~jamesh/pygpgme/trunk/view/head:/tests/test_enc > >rypt_decrypt.py#L99 > > > > I don't see much of a difference really. > > Comparing the operation and the results, pygpgme combination > into one call seems more pythonic to me. Over time this will add up to a lot > of more code. So let's combine these operations in pymes python shim. > > > From my point of view the most pythonic one should be used. > > > > And here is the thing. While pygpgme is implemented purely in c, and > > any attempt of making it more pythonic must also be done in c, pyme is > > using SWIG for the FFI, and layers a shim written in Python on top. > > This is the place one augments or extends the api to make it more > > pythonic, e.g.: > > > > > http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=blob;f=lang/python/pyme/core.py;h=cc262c95aba3abc9fb7986af62e9b579b8229723;hb=HEAD#l529 > > My main concern is the python API. I understand that, and I believe that providing a more pythonic api is easier with pyme, for reasons I repeatedly stated. > A secondary concern is how it is implemented. I have some experience with creating bindings for Python, and I'm familiar with the available FFI solutions. SWIG may be a more classic solution, but I don't see any problem with the method. > You can see that python people move off SWIG to stuff like CFFI (which Ben > reported about last May). And for new bindings, cffi should be chosen over SWIG. > pygpgme is closer to something like CFFI, No. Not at all. > one layer less indirection (though more c-code). Six times more c code. > > > pygpgme is already available for python3 for a few years longer than > > > pyme, I believe. > > > > I must admit I didn't compare pygpgme and pyme before, mostly because > > I wasn't around when the initial effort started, but if I should > > choose now, I'd chose pyme as a starting point again. Having said > > that, I agree that making it a little more pythonic is important, as > > Python is the cheese to catch developers these days. And we will do > > just that ;) > > What will be the status of the gpgme/lang/python binding when gpgme will be > released? experimental? beta? Why would we release something experimental? > Once people start relying on it, it will be harder to change the API itself. People are already relying on it. pygpgme isn't the only binding that already existed. Existing projects using pyme should have no trouble switching over. > > Here is what a decrypting filter looks like with the current bindings: > > (This is only a simple example, so its value is limited. Yeah, if you have a better example maybe it is a good idea to write it down here so that we can discuss it. I created that simple example just to see how simple one can implement decryption with the current bindings. That was the point. > I think that the "op_" part looks ugly.) Which we can drop, breaking all pyme applications in the process. We could, however, add a 'decrypt' operation to the Context class *in Python* that combines decryption and fetching all relevant results. That is another thing where pyme is superior to pygpgme. The latter implements classes in c, which we cannot subclass in Python. Cheers, Justus From rfkrocktk at gmail.com Wed Jun 1 17:20:02 2016 From: rfkrocktk at gmail.com (Naftuli Tzvi Kay) Date: Wed, 1 Jun 2016 08:20:02 -0700 Subject: Inspect output of --export and --export-secret-*? In-Reply-To: <87fusxxutv.fsf@wheatstone.g10code.de> References: <87fusxxutv.fsf@wheatstone.g10code.de> Message-ID: Thank you! Thanks, - Naftuli Tzvi On Tue, May 31, 2016 at 11:54 PM, Werner Koch wrote: > On Wed, 1 Jun 2016 01:10, rfkrocktk at gmail.com said: > > > Is there a tool out there which will allow me to examine the contents of > a > > public or private key exported to disk? I'd like to be able to take an > > arbitrary file and see exactly what's in it. Does such a tool exist? > > gpg --list-packets FILE > > > > Shalom-Salam, > > Werner > > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > /* EFH in Erkrath: https://alt-hochdahl.de/haus */ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at adversary.org Wed Jun 1 17:36:26 2016 From: ben at adversary.org (Ben McGinnes) Date: Thu, 2 Jun 2016 01:36:26 +1000 Subject: python bindings for gpgme In-Reply-To: <201606011438.33105.bernhard@intevation.de> References: <201605311439.22496.bernhard@intevation.de> <87eg8hw5yl.fsf@wheatstone.g10code.de> <20160601114458.GB73302@adversary.org> <201606011438.33105.bernhard@intevation.de> Message-ID: <20160601153626.GC73302@adversary.org> On Wed, Jun 01, 2016 at 02:38:29PM +0200, Bernhard Reiter wrote: > Am Mittwoch, 1. Juni 2016 13:44:58 schrieb Ben McGinnes: >> On Wed, Jun 01, 2016 at 12:37:05PM +0200, Werner Koch wrote: >>> On Wed, 1 Jun 2016 09:38, bernhard at intevation.de said: >>>> Why did you choose porting pyme over pygpgme? >>> >>> Ben has been working on this for more than a year (see >>> https://git.gnupg.org/gpgme.git) and explained his work on >>> gnupg-devel. Challenging this decision now does not seem to be >>> very helpful. > > I saw the explanation last May, there has not been much discussion > since then. And frankly I did not fully realize back then, that you > would want this to be the official gpgme python api. I realize I am > being late, but it is as early as I understood the potential > implications. Maybe pyme is the better choice, I don't know. I > haven't seen the decision documented anywhere, though. I don't actually see pyme as the ideal for the official Python API component, that's what the plans around a CFFI based solution are for. One which would be able to behave pythonically, of course, but more importantly would be able to be accessed by any other language (e.g. on a unix socket locally) in order toprovide GPGME access to all those other languages. One of the other decisions made around that was to support JSON data formats for interacting with the thing because far too many people automatically think REST when they hear API (even though this could *never* actually be a REST API. In the meantime I do think that pyme is a reasonable interim solution and certainly better than the most popular (and easiest) method of accessing GPG in Python: the python-gnupg module. Which is basically just calling GPG commands in subprocess.call() functions. >> I went back and had another look at pygpgme to see why I didn't choose >> that route. I was reminded very quickly why: it doesn't compile so >> well on OS X or, indeed, at all. I'd have to rewrite bits of it to a >> much greater extent. > > That is something that could have been potentially fixed, if the > mapping to python were better. (Which I don't know at this point.) I'm pretty sure it begins with stupid assumptions like hard-coding where certain libraries will always be. Whereas the pyme port to Python 3 behaves identically to the original Python 2 versiom with the exception of the GTK 2 based examples, since the GTK 2 support has not been carried over to Python 3 (it has GTK 3 support instead). >> Plus from the PyPI view it looks a bit abandoned >> (that may not actually be the case, but the version on PyPI hasn't >> been updated in four years. > > Both pyme and pygpgme did not see much of maintenance work if I > remember correctly. I think that the 0.3 release of pygpgme in 2012 > possibly is the newest larger update to both libraries. Well, last year one hadn't been updated in 3 years and the other had been updated around a year prior. Plus it worked in Python 2 and I was initially looking for something that would let me move a whole bunch of other things off Python 2. >> Oh, there is a port for it on MacPorts which might work, but it's >> Python 2.7 only, so nope. > > python3-gpgme packages on Debian and Ubuntu show that python3 > support should be close. The setup.py file says it should support Python 3, but the fact that that's not included in any of the MacPorts ports indicates that I may not be the only person who had trouble installing from source. As it happens the Python 2 port didn't install either, but for rather different reasons (it views GPG 2.1 as a conflict which precludes GPGME being installed, even though I overrode that). Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: not available URL: From bernhard at intevation.de Wed Jun 1 17:54:43 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 1 Jun 2016 17:54:43 +0200 Subject: python bindings for gpgme In-Reply-To: <20160601141504.3724.9533@thinkbox.jade-hamburg.de> References: <201605311439.22496.bernhard@intevation.de> <201606011453.43022.bernhard@intevation.de> <20160601141504.3724.9533@thinkbox.jade-hamburg.de> Message-ID: <201606011754.43709.bernhard@intevation.de> Hi Justus, Am Mittwoch, 1. Juni 2016 16:15:04 schrieb Justus Winter: > > so we probably should evaluate this. > > I just did, and as Werner noted, we are very well beyond the > evaluation phase. your evaluation looks a bit biased because you are defending what you have currently implemented. I appreciate the effort to improve the python bindings and have official ones, too. My questions about the decision are asked in order to help GnuPG to get better python bindings. > SWIG requires *only* language-specific code. In case you are curious, > it is here: > http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=blob;f=lang/python/gpgme.i;hb=HEAD I still don't see that defying my argument that SWIG as an additional layer creates some overhead (learning python's c api and swig). > > does not mean it is necessarily good or elegant to create good > > binding for one language. > > We did not create the binding, it was already there. I know (you have probably seen my code in there). Still it may not be a good one. [..] > > My argument is: First I have to understand python's c api with SWIG I > > have to understand python's c api and SWIG (and its generated code). > > I disagree. > > With SWIG, you write functions translating c types to python types and > back. Any function provided by the c library is then automagically > wrapped, with the data being converted by the functions you wrote > *once*. Add a new function to gpgme, and you likely don't need to do > anything in pyme. When debugging you need to fully understand the resulting c-code and it was more complicated with SWIG (last time I've tried). > With pygpgme, you write code translating the types forth and back > *explicitly for every function you want to make available to python*. > It is a huge overhead, and likely a source of many errors as that code > is likely copied over and over again, without being properly > understood. I haven't checked how it is implemented in pygpgme, there will be typical C methods to avoid too much code duplication. > Let's look at the sizes: > > % sloccount pygpgme/src > [...] > 3037 src ansic=3037 > % sloccount lang/python/helpers.* lang/python/gpgme.i lang/python/pyme > 544 top_dir ansic=544 > 497 pyme python=497 > > Based on that I gather that there must be three to six times as many > bugs in pygpgme. If it is mostly duplicated code, your estimation does not hold. Also it will be the quality of the defects, not just the number. Difficulties of writing correct code are always correlated in a linar way. (Anyway you all know this, I guess.) > > Comparing the operation and the results, pygpgme combination > > into one call seems more pythonic to me. Over time this will add up to a > > lot of more code. > > So let's combine these operations in pymes python shim. Before the release? Or do we have two ways to achieve the same thing then? > > My main concern is the python API. > > I understand that, and I believe that providing a more pythonic api is > easier with pyme, for reasons I repeatedly stated. If it is done with SWIG or later with CFFI, I don't care. We should look at the API ideas of pygpgme, I guess. > > A secondary concern is how it is implemented. > > I have some experience with creating bindings for Python, and I'm > familiar with the available FFI solutions. SWIG may be a more classic > solution, but I don't see any problem with the method. As we agree on the first concern, let us concentrate on that. > > What will be the status of the gpgme/lang/python binding when gpgme will > > be released? experimental? beta? > > Why would we release something experimental? (To make it available and to mark it as something that still will change.) Or are you asking this Werner who "released" the experimental WKD with Gnupg 2.1.12? >:) > > Once people start relying on it, it will be harder to change the API > > itself. > > People are already relying on it. pygpgme isn't the only binding that > already existed. It had no python3 port, so I venture that no Free Software initiatives rely on the python3-gpgme (as in master) currently. > Existing projects using pyme should have no trouble switching over. I have no usage stats for pygpgme or pyme. pygpgme could also be a large group. API changes can be expected when switching the library or the version of python. However usually GnuPG is very conservative with its APIs. > > > Here is what a decrypting filter looks like with the current bindings: > > > > (This is only a simple example, so its value is limited. > > Yeah, if you have a better example maybe it is a good idea to write it > down here so that we can discuss it. I created that simple example > just to see how simple one can implement decryption with the current > bindings. That was the point. The question was which libary suggest the better API, I merely pointed out that your simple example does not help much answering the question. > > I think that the "op_" part looks ugly.) > > Which we can drop, breaking all pyme applications in the process. no real one (see above). .. and breaking the pygpgme application at the same time. > We could, however, add a 'decrypt' operation to the Context class *in > Python* that combines decryption and fetching all relevant results. Overall I have not yet seen a deeper analysis of the APIs suggested by pygpgme and pyme. The API of the upcoming python3-gpgme was choosen without the potential lessons of such a comparison. I am not in a position to provide such an analysis on short notice and we are short on time anyway. Maybe somebody can. Otherwise let us just hope for the best. Best Regards, Bernhard -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Thu Jun 2 21:43:43 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 02 Jun 2016 21:43:43 +0200 Subject: Advanced key generation on the command line Message-ID: <87porzqsuo.fsf@wheatstone.g10code.de> Hi! I tweaked the --quick-gen-key command to allow for extra parameters and also added a --quick-addkey command. This should make the scripted creation of non-standard keys much easier. Here is an example: We want to create a key for bar at example.net with a primary key only suitable for certification. That key shall expire at the final date for all rfc4880 keys. --8<---------------cut here---------------start------------->8--- $ gpg --yes --batch -v --passphrase abc --status-fd 2 \ --quick-gen-key bar at example.net ed25519 cert 2106-02-06 gpg: writing self signature gpg: EDDSA/SHA256 signature from: "778A04A6 [?]" gpg: writing public key to '[...]' gpg: using pgp trust model gpg: key 778A04A6 marked as ultimately trusted [GNUPG:] KEY_CONSIDERED 23F6D3A87C021F4C5E769A32B72043E2778A04A6 0 gpg: writing to [...] gpg: EDDSA/SHA256 signature from: "778A04A6 bar at example.net" gpg: revocation certificate stored as [...] [GNUPG:] KEY_CREATED P 23F6D3A87C021F4C5E769A32B72043E2778A04A6 --8<---------------cut here---------------end--------------->8--- This also demonstrates on how to set a fixed passphrase (you better use --passphrase-fd or --passphrase-file, though). The last status line shows us the fingerprint of the created key, a quick awk extracts it and we can run: --8<---------------cut here---------------start------------->8--- $ gpg --yes --batch -v --status-fd 2 --quick-addkey \ 23F6D3A87C021F4C5E769A32B72043E2778A04A6 cv25519 - 2016-12-31 [GNUPG:] KEY_CONSIDERED 23F6D3A87C021F4C5E769A32B72043E2778A04A6 0 [GNUPG:] PINENTRY_LAUNCHED 1171 gpg: writing key binding signature gpg: EDDSA/SHA256 signature from: "778A04A6 bar at example.net" [GNUPG:] KEY_CREATED S --8<---------------cut here---------------end--------------->8--- This adds an encryption subkey which will expire at the end of this year. Here we do not use a fixed passphrase, but let Pinentry do its work. In contrast to --edit-key's "addkey" subcommand there won't be a prompt for a new passphrase; instead the passphrase of the primary key is used also for this subkey. Of course we also want a signing subkey. We allows that subkey to also act as an ssh key: --8<---------------cut here---------------start------------->8--- $ gpg --yes --batch -v --status-fd 2 --quick-addkey \ 23F6D3A87C021F4C5E769A32B72043E2778A04A6 ed25519 sign,auth 2063-04-05 [GNUPG:] KEY_CONSIDERED 23F6D3A87C021F4C5E769A32B72043E2778A04A6 0 [GNUPG:] PINENTRY_LAUNCHED 1251 gpg: writing key binding signature gpg: EDDSA/SHA256 signature from: "778A04A6 bar at example.net" gpg: EDDSA/SHA256 signature from: "EDDE665C [?]" [GNUPG:] KEY_CREATED S --8<---------------cut here---------------end--------------->8--- And here is the final result: $ gpg -K 23F6D3A87C021F4C5E769A32B72043E2778A04A6 sec ed25519/778A04A6 2016-06-02 [C] [expires: 2106-02-06] uid [ultimate] bar at example.net ssb cv25519/A20B4350 2016-06-02 [E] [expires: 2016-12-31] ssb ed25519/EDDE665C 2016-06-02 [SA] [expires: 2063-04-05] Right, the KEY_CREATED status lines for the subkey miss the fingerrpint; this will be fixed soon. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ From gniibe at fsij.org Fri Jun 3 04:40:26 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 3 Jun 2016 11:40:26 +0900 Subject: write_header2 in build-packet.c Message-ID: <5750EE1A.8070009@fsij.org> Hello, I write some information to this list for the issue 2374. https://bugs.gnupg.org/gnupg/issue2374 I committed this change. commit db1ecc8212defdd183abbb6b1407fcc8d2dc9552 Author: NIIBE Yutaka Date: Wed Jun 1 20:59:09 2016 +0900 g10: Allow User ID length >= 256. * build-packet.c (do_user_id): Call write_header2 with HDRLEN not set. Once, I thought this should be backported to 1.4 and 2.0. Examining code in detail, I concluded it's not needed and not worth to apply this to 1.4 and 2.0. Actually, we had similar change in master for do_key as well. commit 02cf1357dd5ee34a57371f55b9d312b8b9e3a7e8 Author: Justus Winter Date: Thu Apr 7 13:55:42 2016 +0200 g10: Fix exporting secret keys of certain sizes. * g10/build-packet.c (do_key): Do not use the header length specified by the public key packet from the keyring, but let 'write_header2' compute the required length. -- Specifically exporting RSA keys of length 1024 failed, as the encoded public key packet requires 141 bytes a length that fits into one byte, but the secret key is significantly larger, making the export fail. GnuPG-bug-id: 2307 Signed-off-by: Justus Winter Those two changes are needed for master but not for 1.4 and 2.0. That's because we have this in master. commit 960f5e26f2cda3ac6e6b30548fa808a690c39ffc Author: Neal H. Walfield Date: Thu Feb 25 21:20:32 2016 +0100 gpg: More carefully encode a packet's length. * g10/build-packet.c (write_header2): Make sure the length bits are cleared. Fail if HDRLEN is set and the specified length can't be encoded in the available space. -- Signed-off-by: Neal H. Walfield I think that the intention of this modification is good. At first, I failed to recognize the change of the semantics introduced by this modification. In 1.4 and 2.0, HDRLEN is used as just a hint for the length of packet. For example, when HDRLEN=2 and LENGTH=294, CTB will be |= 2, and then, the packet with 5-byte header will be built with no failure. It can be represented with 3-byte header actually, but it still works. Modification by 960f5e2 changes the HDRLEN as a packet length specification, thus, we needed to change the callers side by 02cf135 and db1ecc8. Now, all calls of write_header2 are with HDRLEN=0, so, we could clean up things more. -- From dashohoxha at gmail.com Fri Jun 3 07:19:34 2016 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Fri, 3 Jun 2016 07:19:34 +0200 Subject: Stable release of branch 2.1 In-Reply-To: <87fusvqsow.fsf@wheatstone.g10code.de> References: <87fusvqsow.fsf@wheatstone.g10code.de> Message-ID: On Thu, Jun 2, 2016 at 9:47 PM, Werner Koch wrote: > On Thu, 2 Jun 2016 12:43, dashohoxha at gmail.com said: > > > How far is the branch 2.1 from a stable release? > > it is not just stable, but modern! Go and use it. > I am using it, but we have to convice the major distributions (Debian, CentOS, Ubuntu) that it is stable. Being "modern" is good, but it doesn't mean anything to them. We have to say explicitly that it is "stable". To my understanding, stable means that there are no new features and no interface changes. All new development is being done on another branch, and this one is frozen, except for bug fixes. Are we there yet? That is, are all the planned/intended features and improvements implemented already? Peace, Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Fri Jun 3 08:43:40 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 03 Jun 2016 08:43:40 +0200 Subject: write_header2 in build-packet.c In-Reply-To: <5750EE1A.8070009@fsij.org> (NIIBE Yutaka's message of "Fri, 3 Jun 2016 11:40:26 +0900") References: <5750EE1A.8070009@fsij.org> Message-ID: <874m9apyar.fsf@wheatstone.g10code.de> On Fri, 3 Jun 2016 04:40, gniibe at fsij.org said: > I write some information to this list for the issue 2374. Thanks for this additional information. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ From dkg at fifthhorseman.net Fri Jun 3 23:09:14 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 03 Jun 2016 17:09:14 -0400 Subject: default keyid format In-Reply-To: <87si06ocxm.fsf@alice.fifthhorseman.net> References: <87egd37cpz.fsf@alice.fifthhorseman.net> <87mvrrto8l.fsf@vigenere.g10code.de> <877fiu66y8.fsf@alice.fifthhorseman.net> <87lh78ld9w.fsf@vigenere.g10code.de> <87si06ocxm.fsf@alice.fifthhorseman.net> Message-ID: <87k2i6f091.fsf@alice.fifthhorseman.net> On Fri 2016-03-04 03:38:29 -0500, Daniel Kahn Gillmor wrote: > On Fri 2016-01-29 14:35:07 +0100, Werner Koch wrote: >> Let me do this along with --with-fingerprint being the default and a new >> option --without-fingerprint. > > What's the plan on this change? Should i record it in > https://bugs.gnupg.org/ ? I've opened a ticket for this here: https://bugs.gnupg.org/gnupg/issue2379 --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From justus at g10code.com Mon Jun 6 17:20:47 2016 From: justus at g10code.com (Justus Winter) Date: Mon, 06 Jun 2016 17:20:47 +0200 Subject: python bindings for gpgme In-Reply-To: <201606011754.43709.bernhard@intevation.de> References: <201605311439.22496.bernhard@intevation.de> <201606011453.43022.bernhard@intevation.de> <20160601141504.3724.9533@thinkbox.jade-hamburg.de> <201606011754.43709.bernhard@intevation.de> Message-ID: <20160606152047.10010.70223@thinkbox.jade-hamburg.de> Hello Bernhard, Quoting Bernhard Reiter (2016-06-01 17:54:43) > Am Mittwoch, 1. Juni 2016 16:15:04 schrieb Justus Winter: > > > so we probably should evaluate this. > > > > I just did, and as Werner noted, we are very well beyond the > > evaluation phase. > > your evaluation looks a bit biased because you are defending > what you have currently implemented. What else would I be defending? > > > SWIG requires *only* language-specific code. In case you are curious, > > it is here: > > > http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=blob;f=lang/python/gpgme.i;hb=HEAD > > I still don't see that defying my argument that SWIG as an additional layer > creates some overhead (learning python's c api and swig). It defies your argument that using SWIG only pays off if you create bindings for more than one language, which can only be the case if there is a language-independend part to it, which there isn't. > > > My argument is: First I have to understand python's c api with SWIG I > > > have to understand python's c api and SWIG (and its generated code). > > > > I disagree. > > > > With SWIG, you write functions translating c types to python types and > > back. Any function provided by the c library is then automagically > > wrapped, with the data being converted by the functions you wrote > > *once*. Add a new function to gpgme, and you likely don't need to do > > anything in pyme. > > When debugging you need to fully understand the resulting c-code > and it was more complicated with SWIG (last time I've tried). > > > With pygpgme, you write code translating the types forth and back > > *explicitly for every function you want to make available to python*. > > It is a huge overhead, and likely a source of many errors as that code > > is likely copied over and over again, without being properly > > understood. > > I haven't checked how it is implemented in pygpgme, there will be typical C > methods to avoid too much code duplication. One of such typical methods is code generation, which is exactly what SWIG does. In fact, pyme and pygpgme are very similar, they employ a compiled module at the core, but pyme uses SWIG to generate large parts of that code. > > Let's look at the sizes: > > > > % sloccount pygpgme/src > > [...] > > 3037 src ansic=3037 > > % sloccount lang/python/helpers.* lang/python/gpgme.i lang/python/pyme > > 544 top_dir ansic=544 > > 497 pyme python=497 > > > > Based on that I gather that there must be three to six times as many > > bugs in pygpgme. > > If it is mostly duplicated code, your estimation does not hold. I doubt that. In fact, I believe that copying code around increases the chance of errors, and that it leads to cargo-cult-style programming. It also makes fixing these bugs hard. > > > Comparing the operation and the results, pygpgme combination > > > into one call seems more pythonic to me. Over time this will add up to a > > > lot of more code. > > > > So let's combine these operations in pymes python shim. > > Before the release? Or do we have two ways to achieve the same thing then? I'm thinking of providing joined operations, op_decrypt_verify+op_decrypt_result+op_verify_result => decrypt_verify. So there would be a second set of operations. > > > My main concern is the python API. > > > > I understand that, and I believe that providing a more pythonic api is > > easier with pyme, for reasons I repeatedly stated. > > If it is done with SWIG or later with CFFI, I don't care. Ok. > We should look at the API ideas of pygpgme, I guess. What ideas? I'm tired of "make it more pythonic" with noone having a clear idea what that actually means. I fear that it means something different for everyone. So until someone here actually provides a constructive critique of the current pyme API, I'm going to sand-off the edges that would annoy me the most. For example, one can now just use file objects everywhere a gpgme_data_t object is expected (in most cases): http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=blob;f=lang/python/tests/t-idiomatic.py;hb=HEAD#l28 I plan to extend this to every object implementing the buffer interface. I also want to provide the compound operations, and work a little on the documentation. Cheers, Justus From wk at gnupg.org Mon Jun 6 19:03:52 2016 From: wk at gnupg.org (Werner Koch) Date: Mon, 06 Jun 2016 19:03:52 +0200 Subject: New --keyid-format=none Message-ID: <877fe2b66f.fsf@wheatstone.g10code.de> Hi! We have been talking about this since January, so it was time to implement it for the forthcoming 2.1.13. We now do not show key ids anymore by default (those who have configured gpg to use long key ids won't notice that change, though). Here is an example: $ gpg --no-options -k 1e42b367 pub dsa2048 2007-12-31 [SC] [expires: 2018-12-31] 80615870F5BAD690333686D0F2AD85AC1E42B367 uid [ full ] Werner Koch uid [ full ] Werner Koch uid [ full ] Werner Koch sub dsa1024 2011-11-02 [S] sub rsa2048 2014-01-02 [E] [expires: 2016-12-31] as you can see we print the fingerprint in a compact format to make c+p much easier. To show the better readable format use $ gpg --no-options --with-fingerprint -k 1e42b367 pub dsa2048 2007-12-31 [SC] [expires: 2018-12-31] 8061 5870 F5BA D690 3336 86D0 F2AD 85AC 1E42 B367 uid [ full ] Werner Koch [...] In rare cases the fingerprints of the subkeys are of interest. This can either be done by using --with-fingerrpints twice or with a new option: $ gpg --no-options --with-subkey-fingerprint -k 1e42b367 pub dsa2048 2007-12-31 [SC] [expires: 2018-12-31] 80615870F5BAD690333686D0F2AD85AC1E42B367 uid [ full ] Werner Koch uid [ full ] Werner Koch uid [ full ] Werner Koch sub dsa1024 2011-11-02 [S] E4B868C8F90C8964B5AF9DBC4F0540D577F95F95 sub rsa2048 2014-01-02 [E] [expires: 2016-12-31] 16CC3D3B02382A7F67B5C2111E0FE11D664D7444 To get back to the old format use --keyid-format=long - but I would strongly suggest to get used to the new fingerprint only format. And yes, I should have used at least the long keyid to select my key in the examples ;-) Even with the default --keyid-format=none diagnostics which refer a key use the long key id. Changing this to a fingerprint would make the error messages too hard to read. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ From neal at walfield.org Mon Jun 6 19:12:48 2016 From: neal at walfield.org (Neal H. Walfield) Date: Mon, 06 Jun 2016 19:12:48 +0200 Subject: New --keyid-format=none In-Reply-To: <877fe2b66f.fsf@wheatstone.g10code.de> References: <877fe2b66f.fsf@wheatstone.g10code.de> Message-ID: <8760tmw8a7.wl-neal@walfield.org> On Mon, 06 Jun 2016 19:03:52 +0200, Werner Koch wrote: > $ gpg --no-options -k 1e42b367 > pub dsa2048 2007-12-31 [SC] [expires: 2018-12-31] > 80615870F5BAD690333686D0F2AD85AC1E42B367 > uid [ full ] Werner Koch > uid [ full ] Werner Koch > uid [ full ] Werner Koch > sub dsa1024 2011-11-02 [S] > sub rsa2048 2014-01-02 [E] [expires: 2016-12-31] > > as you can see we print the fingerprint in a compact format to make c+p > much easier. To show the better readable format use It may be compact, but it is much harder to read. Why not use a delimiter that is normally included when double clicking on some text in a terminal and is considered part of a work by control-w in bach? Here, dash works. :) Neal From wk at gnupg.org Mon Jun 6 19:24:10 2016 From: wk at gnupg.org (Werner Koch) Date: Mon, 06 Jun 2016 19:24:10 +0200 Subject: New --keyid-format=none References: <877fe2b66f.fsf@wheatstone.g10code.de> <8760tmw8a7.wl-neal@walfield.org> Message-ID: <87vb1m9qo5.fsf@wheatstone.g10code.de> On Mon, 6 Jun 2016 19:12, neal at walfield.org said: > It may be compact, but it is much harder to read. Why not use a > delimiter that is normally included when double clicking on some text Because such a delimiter would depend on the used shell and the OS. A single hex string is the simplest thing to use. You are not supposed to read it. If you want to compare a fingerprint, use --fingerprint instead - that is what we have told people. And if you want to read it even better use --with-icao-spelling ;-) > Here, dash works. In Emacs you need to be in lisp-mode if you do not want '-' to be a word delimiter. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ From christoph at christoph-egger.org Mon Jun 6 19:16:44 2016 From: christoph at christoph-egger.org (Christoph Egger) Date: Mon, 06 Jun 2016 19:16:44 +0200 Subject: New --keyid-format=none In-Reply-To: <8760tmw8a7.wl-neal@walfield.org> (sfid-20160606_191432_642770_2E7D9C00) (Neal H. Walfield's message of "Mon, 06 Jun 2016 19:12:48 +0200") References: <877fe2b66f.fsf@wheatstone.g10code.de> <8760tmw8a7.wl-neal@walfield.org> Message-ID: <8737oqs0eb.fsf@hepworth.siccegge.de> "Neal H. Walfield" writes: > On Mon, 06 Jun 2016 19:03:52 +0200, > Werner Koch wrote: >> $ gpg --no-options -k 1e42b367 >> pub dsa2048 2007-12-31 [SC] [expires: 2018-12-31] >> 80615870F5BAD690333686D0F2AD85AC1E42B367 >> uid [ full ] Werner Koch >> uid [ full ] Werner Koch >> uid [ full ] Werner Koch >> sub dsa1024 2011-11-02 [S] >> sub rsa2048 2014-01-02 [E] [expires: 2016-12-31] >> >> as you can see we print the fingerprint in a compact format to make c+p >> much easier. To show the better readable format use > > It may be compact, but it is much harder to read. Why not use a > delimiter that is normally included when double clicking on some text > in a terminal and is considered part of a work by control-w in bach? > Here, dash works. How often do you actually need to read the fingerprint? The current form has the huge advantage of being in a format that is already widely understood by any tool consuming keyids/fingerprints. Christoph -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Lisp Hacker | CaCert Assurer From dkg at fifthhorseman.net Mon Jun 6 23:31:45 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 06 Jun 2016 17:31:45 -0400 Subject: python bindings for gpgme In-Reply-To: <20160606152047.10010.70223@thinkbox.jade-hamburg.de> References: <201605311439.22496.bernhard@intevation.de> <201606011453.43022.bernhard@intevation.de> <20160601141504.3724.9533@thinkbox.jade-hamburg.de> <201606011754.43709.bernhard@intevation.de> <20160606152047.10010.70223@thinkbox.jade-hamburg.de> Message-ID: <87h9d6hum6.fsf@alice.fifthhorseman.net> On Mon 2016-06-06 11:20:47 -0400, Justus Winter wrote: > What ideas? I'm tired of "make it more pythonic" with noone having a > clear idea what that actually means. I fear that it means something > different for everyone. So until someone here actually provides a > constructive critique of the current pyme API, I'm going to sand-off > the edges that would annoy me the most. > > For example, one can now just use file objects everywhere a > gpgme_data_t object is expected (in most cases): > > http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=blob;f=lang/python/tests/t-idiomatic.py;hb=HEAD#l28 > > I plan to extend this to every object implementing the buffer > interface. I also want to provide the compound operations, and work a > little on the documentation. All this is very much appreciated, Justus. As the co-maintainer of a downstream (https://packages.debian.org/assword) that depends on python-gpgme, i'd be happy to convert it to pyme going forward if it will have good documentation and sanded-off edges :) When pyme is ready for python3 in debian, i can take a look at assword's (relatively basic) use and see what (if anything) might need to be adjusted in either project to make it work cleanly. 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 ben at adversary.org Tue Jun 7 19:10:32 2016 From: ben at adversary.org (Ben McGinnes) Date: Wed, 8 Jun 2016 03:10:32 +1000 Subject: python bindings for gpgme In-Reply-To: <20160606152047.10010.70223@thinkbox.jade-hamburg.de> References: <201605311439.22496.bernhard@intevation.de> <201606011453.43022.bernhard@intevation.de> <20160601141504.3724.9533@thinkbox.jade-hamburg.de> <201606011754.43709.bernhard@intevation.de> <20160606152047.10010.70223@thinkbox.jade-hamburg.de> Message-ID: <20160607171032.GC81949@adversary.org> On Mon, Jun 06, 2016 at 05:20:47PM +0200, Justus Winter wrote: > Hello Bernhard, > > Quoting Bernhard Reiter (2016-06-01 17:54:43) >> Am Mittwoch, 1. Juni 2016 16:15:04 schrieb Justus Winter: >>>> so we probably should evaluate this. >>> >>> I just did, and as Werner noted, we are very well beyond the >>> evaluation phase. >> >> your evaluation looks a bit biased because you are defending >> what you have currently implemented. > > What else would I be defending? > >> >>> SWIG requires *only* language-specific code. In case you are curious, >>> it is here: >>> >> http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=blob;f=lang/python/gpgme.i;hb=HEAD >> >> I still don't see that defying my argument that SWIG as an additional layer >> creates some overhead (learning python's c api and swig). > > It defies your argument that using SWIG only pays off if you create > bindings for more than one language, which can only be the case if > there is a language-independend part to it, which there isn't. > >>>> My argument is: First I have to understand python's c api with SWIG I >>>> have to understand python's c api and SWIG (and its generated code). >>> >>> I disagree. >>> >>> With SWIG, you write functions translating c types to python types and >>> back. Any function provided by the c library is then automagically >>> wrapped, with the data being converted by the functions you wrote >>> *once*. Add a new function to gpgme, and you likely don't need to do >>> anything in pyme. >> >> When debugging you need to fully understand the resulting c-code >> and it was more complicated with SWIG (last time I've tried). >> >>> With pygpgme, you write code translating the types forth and back >>> *explicitly for every function you want to make available to python*. >>> It is a huge overhead, and likely a source of many errors as that code >>> is likely copied over and over again, without being properly >>> understood. >> >> I haven't checked how it is implemented in pygpgme, there will be typical C >> methods to avoid too much code duplication. > > One of such typical methods is code generation, which is exactly what > SWIG does. In fact, pyme and pygpgme are very similar, they employ a > compiled module at the core, but pyme uses SWIG to generate large > parts of that code. > >>> Let's look at the sizes: >>> >>> % sloccount pygpgme/src >>> [...] >>> 3037 src ansic=3037 >>> % sloccount lang/python/helpers.* lang/python/gpgme.i lang/python/pyme >>> 544 top_dir ansic=544 >>> 497 pyme python=497 >>> >>> Based on that I gather that there must be three to six times as many >>> bugs in pygpgme. >> >> If it is mostly duplicated code, your estimation does not hold. > > I doubt that. In fact, I believe that copying code around increases > the chance of errors, and that it leads to cargo-cult-style > programming. It also makes fixing these bugs hard. > >>>> Comparing the operation and the results, pygpgme combination >>>> into one call seems more pythonic to me. Over time this will add up to a >>>> lot of more code. >>> >>> So let's combine these operations in pymes python shim. >> >> Before the release? Or do we have two ways to achieve the same thing then? > > I'm thinking of providing joined operations, > op_decrypt_verify+op_decrypt_result+op_verify_result => > decrypt_verify. So there would be a second set of operations. > >>>> My main concern is the python API. >>> >>> I understand that, and I believe that providing a more pythonic api is >>> easier with pyme, for reasons I repeatedly stated. >> >> If it is done with SWIG or later with CFFI, I don't care. > > Ok. > >> We should look at the API ideas of pygpgme, I guess. > > What ideas? I'm tired of "make it more pythonic" with noone having a > clear idea what that actually means. Whereas my view of remaking things with Python following an overhaul of GPGME was not so much "make it more Pythonic" (though if that happened as well I wouldn't object) as much as it was "make it more modular" and "make it kind of REST-like" (with all the relevant caveats). For example; using JSON for feeding in data types and receiving the responses. I wanted something which would be familiar enough to all those web-weenies, Javanauts, Node-velopers and Mono-thoughts; at least in relation to the data types they fed it and received from it that they'd have to actually want to code an insecure thing to do anything else. Having something that could also be imported into other Python 3 code is just a functional effect of using the language, not the end goal. If it were the end goal then it'd be no different from any other Python binding. > I fear that it means something different for everyone. So until > someone here actually provides a constructive critique of the > current pyme API, Almost certainly. Which is why I took my cue from what Werner described last year as the intended aim of having an official API for the API. > I'm going to sand-off the edges that would annoy me the most. Fair enough. > I plan to extend this to every object implementing the buffer > interface. I also want to provide the compound operations, and work a > little on the documentation. Cool. I think that currently the biggest impediment to pyme adoption is the lack of usable documentation from Python coders' perspectives. The documentation that does exist is essentially just the existing GPGME documentation with a terse introduction and a couple of examples. It doesn't help that the examples don't really demonstrate the two most common use cases in code: encrypting a thing and decrypting that same thing. There's a lot to be said for a gentler introductory document with some basic examples in it, at least so people can wrap their brains around what they're looking at. The current code and documentation is basically saying, "if you didn't start your coding career with C then you're screwed." So rather than learn C, people go and grab something which might not be quite so secure (like all those awful javascript "implementations" of OpenPGP ... HaneWIN, for instance). Now python-gnupg has many flaws, but it does have fairly coherent documentation with easily replicable code examples throughout the entire thing. By contrast, pyme has the GPGME documentation plus a handful of introductory text paragraphs near the start with one example inside it and no guarantees on what can be found in the examples directory itself on account of every single example being written by people who were *not* the original author (and said original author washed his hands of the thing over a decade ago). Meeting that particular "unspoken requirement" of most developers these days is most likely to gradually lead to an ever increasing uptake of GPGME based code. So I guess I'd better pitch in with the documentation efforts. ;) Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: not available URL: From wk at gnupg.org Wed Jun 8 15:29:13 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 08 Jun 2016 15:29:13 +0200 Subject: Moving the agent's socket to /var/run ? In-Reply-To: <87k2lv5u0y.fsf@wheatstone.g10code.de> (Werner Koch's message of "Tue, 23 Feb 2016 16:24:45 +0100") References: <87k2lv5u0y.fsf@wheatstone.g10code.de> Message-ID: <87h9d3zu52.fsf@wheatstone.g10code.de> Hi, I just pushed some changes to use sockets below /run/user: If a [/var]/run/user/$(id -u)/ directory exists, a gnupg subdir is created as needed and the permissions of the directories are checked. If that all matches that directory name is returned instead of the homedir. To cope with non standard homedirs (via GNUPGHOME or --homedir) the SHA-1 hash of the homedir is computed, left truncated to 120 bits, zBase-32 encoded, prefixed with "d.", and appended to "[/var]/run/user/$(id -u)/gnupg/". If that directory exists and has proper permissions it is returned as socket dir - if not the homedir is used. Due to cleanup issues, this directory will not be auto-created but needs to be created by the user in advance. The required permissions are: directory owned by the user, group and others bits not set. As long as no /run/user/$UID directory exists, you should not run into problems. If that directory exists GnUPG will try to use it - in this case you should restart the daemons (gpgconf --kill gpg-agent; gpgconf --kill dirmngr). If you are not using the default homedirectly, you may use gpgconf --create-sockdir to create a dedicated directory below /run/user/$UID/gnupg. gpgconf --remove-socketdir can be used for cleanup; gpgconf now also understands --homedir. If you are using gpg-agent for ssh, remember to change the envvar to the new place: SSH_AUTH_SOCK="/run/user/${UID}/gnupg/S.gpg-agent.ssh" export SSH_AUTH_SOCK This envvar is actually a bit annoying and thus I would appreciate if Debian could change ssh to try the above socket if for example SSH_AUTH_SOCK is set to "gpg-agent" or some other magic. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ From dkg at fifthhorseman.net Wed Jun 8 19:33:47 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 08 Jun 2016 13:33:47 -0400 Subject: Moving the agent's socket to /var/run ? In-Reply-To: <87h9d3zu52.fsf@wheatstone.g10code.de> References: <87k2lv5u0y.fsf@wheatstone.g10code.de> <87h9d3zu52.fsf@wheatstone.g10code.de> Message-ID: <8737onfuv8.fsf@alice.fifthhorseman.net> Hi Werner-- On Wed 2016-06-08 09:29:13 -0400, Werner Koch wrote: > I just pushed some changes to use sockets below /run/user: > > If a [/var]/run/user/$(id -u)/ directory exists, a gnupg subdir is > created as needed and the permissions of the directories are checked. > If that all matches that directory name is returned instead of the > homedir. > > To cope with non standard homedirs (via GNUPGHOME or --homedir) the > SHA-1 hash of the homedir is computed, left truncated to 120 bits, > zBase-32 encoded, prefixed with "d.", and appended to > "[/var]/run/user/$(id -u)/gnupg/". If that directory exists and has > proper permissions it is returned as socket dir - if not the homedir > is used. Due to cleanup issues, this directory will not be > auto-created but needs to be created by the user in advance. > > The required permissions are: directory owned by the user, group and > others bits not set. Thanks, these are great changes! I think i understand the variation with non-standard homedirs, but i wonder what happens if GNUPGHOME (or --homedir) is set, but it happens to be exactly the same as the default homedir. At that point, what directory is used -- the standard directory, the one with the digested value, or the one actually in the homedir? (or should the digested value of the default appear automatically as a symlink to .. ?) Also, is there an easy/automated way to query gpg for the hashed directory? it'd be nice for external tools to be able to do something like: gpgconf --homedir $foo --print-socket-dir instead of re-implementing the logic you've described above. Is the ssh-agent socket also placed inside the socket dir, or always in the non-custom location? > If you are using gpg-agent for ssh, remember to change the envvar to the > new place: > > SSH_AUTH_SOCK="/run/user/${UID}/gnupg/S.gpg-agent.ssh" > export SSH_AUTH_SOCK > > This envvar is actually a bit annoying and thus I would appreciate if > Debian could change ssh to try the above socket if for example > SSH_AUTH_SOCK is set to "gpg-agent" or some other magic. That's an interesting proposal, though i'm not sure that debian is the right place to do it. Why not propose such a change to upstream OpenSSH? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From skawashima at uchicago.edu Wed Jun 8 19:12:45 2016 From: skawashima at uchicago.edu (Seiya Kawashima) Date: Wed, 8 Jun 2016 17:12:45 +0000 Subject: gpgme: prerequisite for running tests under gpgme/tests/gpg Message-ID: <8CA79C4C24A06A48A11BA99F564B78ED37C519C8@xm-mbx-05-prod> Hi, I've been learning how GPGME-1.6.0, GnuPG stable-2.0.30 and Pinentry-0.9.7 work downloading, modifying and compiling them. As long as I know, gpgme/tests/gpg/t-decrypt.c, gpgme/tests/gpg/t-decrypt-verify.c, gpgme/tests/gpg/t-encrypt.c, gpgme/tests/gpg/t-encrypt-large.c and t-encrypt-sign.c don't run simply compiling. I've checked the source code in GPGME-1.6.0 and via git as of 06/08/2016. All the tests seem to stay the same so I assume that they still don't run. If I totally miss the point, please disregard the email. I would need more study on them. The errors returned by the tests are such as t-encrypt.c:60: GPGME: End of file and t-decrypt.c:65: GPGME: Decryption failed. These tests seem to assume that specific keys exist. I'm not sure about this but they might also expect some environment variables as in the discussion at http://marc.info/?l=gnupg-devel&m=120346698810871&w=2 like below. > The included test suite comes with its own environment, which is > provided by environment variables. Try something like: > > GNUPGHOME=`pwd` srcdir=`pwd` ./t-encrypt However, I think that it might be better that the tests run simply compiling. To make them run without the assumptions, It might be better to have the work flow of generate key, encrypt or decrypt and delete the generated key on each test. With this way, they can run simply compiling. To make this happen, enough entropy should be provided so that the tests don't hang when generating keys. I would like to show you my approach for gpgme/tests/gpg/t-decrypt.c as follows: commit 55e5f8ae371b8cf1207b1b1ec077d9518757f057 Author: Seiya Kawashima Date: Wed Jun 8 04:56:06 2016 -0500 add work flow of generate key, encrypt, decrypt and delete key in tests/gpg/t-decrypt.c diff --git a/tests/gpg/t-decrypt.c b/tests/gpg/t-decrypt.c index 2a2f4d7..60a39b3 100644 --- a/tests/gpg/t-decrypt.c +++ b/tests/gpg/t-decrypt.c @@ -41,37 +41,79 @@ main (int argc, char *argv[]) { gpgme_ctx_t ctx; gpgme_error_t err; - gpgme_data_t in, out; - gpgme_decrypt_result_t result; - const char *cipher_1_asc = make_filename ("cipher-1.asc"); + gpgme_data_t in,out; + gpgme_genkey_result_t gen_result; + gpgme_encrypt_result_t enc_result; + gpgme_decrypt_result_t dec_result; + gpgme_key_t keys[2] = {NULL,NULL}; + char *agent_info; + agent_info = getenv("GPG_AGENT_INFO"); + if (!(agent_info && strchr (agent_info, ':'))) + gpgme_set_passphrase_cb (ctx, passphrase_cb, NULL); init_gpgme (GPGME_PROTOCOL_OpenPGP); err = gpgme_new (&ctx); fail_if_err (err); + gpgme_set_armor (ctx,1); - agent_info = getenv("GPG_AGENT_INFO"); - if (!(agent_info && strchr (agent_info, ':'))) - gpgme_set_passphrase_cb (ctx, passphrase_cb, NULL); + + /* Generate test key for encryption. */ + err = generate_test_key (ctx,NULL); + fail_if_err (err); + gen_result = gpgme_op_genkey_result (ctx); - err = gpgme_data_new_from_file (&in, cipher_1_asc, 1); + /* Search key for encryption. */ + gpgme_key_t key; + err = gpgme_get_key (ctx,gen_result->fpr,&key,1); fail_if_err (err); + /* Initialize input buffer. */ + err = gpgme_data_new_from_mem (&in,"Hallo Leute\n", 12, 0); + fail_if_err (err); + + /* Initialize output buffer. */ err = gpgme_data_new (&out); fail_if_err (err); - - err = gpgme_op_decrypt (ctx, in, out); + + /* Encrypt data. */ + keys[0] = key; + err = gpgme_op_encrypt (ctx,keys,GPGME_ENCRYPT_ALWAYS_TRUST,in,out); fail_if_err (err); - result = gpgme_op_decrypt_result (ctx); - if (result->unsupported_algorithm) + enc_result = gpgme_op_encrypt_result (ctx); + if (enc_result->invalid_recipients) { - fprintf (stderr, "%s:%i: unsupported algorithm: %s\n", - __FILE__, __LINE__, result->unsupported_algorithm); + fprintf (stderr, "Invalid recipient encountered: %s\n", + enc_result->invalid_recipients->fpr); exit (1); } print_data (out); - + + /* out stores encrypted data and it's the input for decryption. Use in as + the output for decryption. */ + gpgme_data_release (in); + err = gpgme_data_new (&in); + fail_if_err (err); + + /* Decrypt data. */ + err = gpgme_op_decrypt (ctx,out,in); + fail_if_err (err); + dec_result = gpgme_op_decrypt_result (ctx); + if (dec_result->unsupported_algorithm) + { + fprintf (stderr, "%s:%i: unsupported algorithm: %s\n", + __FILE__, __LINE__, dec_result->unsupported_algorithm); + exit (1); + } + print_data (in); + + err = delete_test_key (ctx,key); + fail_if_err (err); + gpgme_data_release (in); gpgme_data_release (out); gpgme_release (ctx); diff --git a/tests/gpg/t-support.h b/tests/gpg/t-support.h index 6a18b5c..c541a07 100644 --- a/tests/gpg/t-support.h +++ b/tests/gpg/t-support.h @@ -69,6 +69,13 @@ print_data (gpgme_data_t dh) fwrite (buf, ret, 1, stdout); if (ret < 0) fail_if_err (gpgme_err_code_from_errno (errno)); + + /* Reset read position to the beginning so that dh can be used as input + for another operation after this method call. For example, dh is an + output from encryption and also is used as an input for decryption. + Otherwise GPG_ERR_NO_DATA is returned since this method moves the + read position. */ + ret = gpgme_data_seek (dh, 0, SEEK_SET); } @@ -187,3 +194,32 @@ print_import_result (gpgme_import_result_t r) r->not_imported); } +gpgme_error_t +generate_test_key (gpgme_ctx_t ctx, + void (*progress_meter) (void *hook, const char *what, int type, int current, + int total)) +{ + gpgme_error_t err; + const char *parms = "\n" + "Key-Type: DSA\n" + "Key-Length: 1024\n" + "Subkey-Type: ELG-E\n" + "Subkey-Length: 1024\n" + "Name-Real: Joe Tester\n" + "Name-Comment: with stupid passphrase\n" + "Name-Email: joe at foo.bar\n" + "Expire-Date: 0\n" + "Passphrase: abc\n" + "\n"; + + gpgme_set_progress_cb (ctx, progress_meter, NULL); + return gpgme_op_genkey (ctx, parms, NULL, NULL); +} + +gpgme_error_t +delete_test_key (gpgme_ctx_t ctx,gpgme_key_t key) +{ + gpgme_error_t err = gpgme_op_delete (ctx,key,1); + gpgme_key_unref (key); + return err; +} Thank you Seiya From wk at gnupg.org Thu Jun 9 08:50:42 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 09 Jun 2016 08:50:42 +0200 Subject: Moving the agent's socket to /var/run ? In-Reply-To: <8737onfuv8.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 08 Jun 2016 13:33:47 -0400") References: <87k2lv5u0y.fsf@wheatstone.g10code.de> <87h9d3zu52.fsf@wheatstone.g10code.de> <8737onfuv8.fsf@alice.fifthhorseman.net> Message-ID: <87k2hyx3ct.fsf@wheatstone.g10code.de> On Wed, 8 Jun 2016 19:33, dkg at fifthhorseman.net said: > I think i understand the variation with non-standard homedirs, but i > wonder what happens if GNUPGHOME (or --homedir) is set, but it happens > to be exactly the same as the default homedir. At that point, what I hope I have made sure that specifify GNUPGHOME or --homedir as the default home directory (~/.gnupg) is simply ignored: gpg --homedir ~/.gnupg will thus connect the agent at /run/user/$UID/gnupg/S.gpg-agent . Bind mounts are a different story, though. As a side-effect of these changes GNUPGHOME=. gpg ..... now works as expected and there is no more need for GNUPGHOME=$(pwd) > Also, is there an easy/automated way to query gpg for the hashed > directory? it'd be nice for external tools to be able to do something > like: > > gpgconf --homedir $foo --print-socket-dir gpgconf --list-dirs | grep ^agent-socket: | cut -d: -f2 it gives the socket name, though. I can add a socket directory line though. To see the socket directory which would be used if it exists and all permissions are fine, you can use $ gpgconf --dry-run --create-socketdir gpgconf: socketdir is '/run/user/1000/gnupg' $ gpgconf --homedir /foo/tmp --dry-run --create-socketdir gpgconf: socketdir is '/run/user/1000/gnupg/d.xhmoxiusfxtwuy8s69hkyxtc' gpgconf: non-default homedir gpgconf: no such subdir I would add it to the --list-dirs output but I simply have not come up with a good name for that. Something like candidate-socketdir: maybe? > Is the ssh-agent socket also placed inside the socket dir, or always in > the non-custom location? Yes. Only gpg-agent's --extra-socket and --browser-socket options have no defaults and use whatever you specify >> This envvar is actually a bit annoying and thus I would appreciate if >> Debian could change ssh to try the above socket if for example >> SSH_AUTH_SOCK is set to "gpg-agent" or some other magic. > > That's an interesting proposal, though i'm not sure that debian is the > right place to do it. Why not propose such a change to upstream I fear that they will hesitate to add support for a GPL tool ;-). I can try, though. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ From wk at gnupg.org Thu Jun 9 09:06:35 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 09 Jun 2016 09:06:35 +0200 Subject: gpgme: prerequisite for running tests under gpgme/tests/gpg In-Reply-To: <8CA79C4C24A06A48A11BA99F564B78ED37C519C8@xm-mbx-05-prod> (Seiya Kawashima's message of "Wed, 8 Jun 2016 17:12:45 +0000") References: <8CA79C4C24A06A48A11BA99F564B78ED37C519C8@xm-mbx-05-prod> Message-ID: <87bn3ax2mc.fsf@wheatstone.g10code.de> On Wed, 8 Jun 2016 19:12, skawashima at uchicago.edu said: > Pinentry-0.9.7 work downloading, modifying and compiling them. As long > as I know, gpgme/tests/gpg/t-decrypt.c, > gpgme/tests/gpg/t-decrypt-verify.c, gpgme/tests/gpg/t-encrypt.c, > gpgme/tests/gpg/t-encrypt-large.c and t-encrypt-sign.c don't run > simply compiling. I've checked the source code in GPGME-1.6.0 and via The required keys are imported before the test and a dedicated gpg-agent is started. For example the import is done by the Makefile.am targets ./private-keys-v1.d/gpg-sample.stamp and ./pubring-stamp which are triggered by check-local, which is triggered by the check target (Automake created; check the created Makefile). Your problem must be a different one. What OS are you using, might it be a gmake/make incompatibility (the generated Makefiles should work with all make versions, tough)? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ From gniibe at fsij.org Thu Jun 9 10:12:44 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 9 Jun 2016 17:12:44 +0900 Subject: trustdb locking Message-ID: <575924FC.70505@fsij.org> Hello, In the issue 1675, we handle trustdb locking: https://bugs.gnupg.org/gnupg/issue1675 I had identified a race condition for creation of trustdb.gpg. This was fixed last year. However, the problem of trustdb corruption has not gone yet. This week, I looked through the code (trustdb.c and tdbio.c), and I found that we have more places to lock the write access. Even if we consider the write(2) for the record can be atomic, we have following: (1) FIXED The serialization of newly creating trustdb.gpg in the function tdbio_set_dbname (tdbio.c). <--- last year's fix. (2) BEING ANALYZED The serialization of newly creating hash table in the function create_hashtable (tdbio.c). <--- I think this is the issue now. When two processes race for the position of end of file by lseek (db_fd, 0, SEEK_END), it might result corrupted trustdb. A process which comes later will also create a record for hash table at the end of file at later time, but the block will be overwritten by another process which comes first. (3) The serialization of appending a record of RECTYPE_HLST in the function upd_hashtable (tdbio.c). (4) The serialization of creating a record of RECTYPE_TRUST in the function tdb_update_ownertrust, update_min_ownertrust and update_validity (trustdb.c). (5) The serialization of creating a record of RECTYPE_VALID in the function update_validity (trustdb.c). -- From ueno at gnu.org Thu Jun 9 11:16:46 2016 From: ueno at gnu.org (Daiki Ueno) Date: Thu, 09 Jun 2016 18:16:46 +0900 Subject: The loopback pinentry In-Reply-To: <87h9evck4f.fsf@wheatstone.g10code.de> (Werner Koch's message of "Thu, 21 Apr 2016 12:49:04 +0200") References: <87wpnsfjat.fsf@wheatstone.g10code.de> <87potk13fr.wl-neal@walfield.org> <87h9evck4f.fsf@wheatstone.g10code.de> Message-ID: Werner Koch writes: > Before someone asks: The --allow-emacs-pinentry option should be kept > because that new emacs mode has actual security implications and should > thus not be enabled by default. I also consider that Emacs users can be > expected to enter M-x f ~/.gnupg/gpg-agent.conf ;-) If the loopback pinentry evolves into general purpose mechanism, I would rather suggest to remove the Emacs specific stuff entirely. The rationale is: - The immediate motivation behind the Emacs pinentry was that the loopback pinentry had some limitations when used as a replacement of gpg1's passphrase prompt, e.g. [1], which was fixed a while ago. - Debian seems unlikely to build in the Emacs mode with Pinentry[2]. That means to add another (non-working) configuration vector and upstream Emacs cannot rely on that feature[3]. What do you think? Is there really anything that can be done better with the Emacs pinentry than with the loopback pinentry? If you agree, I can take care of the removal. Thanks, Footnotes: [1] https://bugs.gnupg.org/gnupg/issue1976 [2] https://bugs.gnupg.org/gnupg/issue2034 [3] http://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/epg.el#n607 -- Daiki Ueno From ben at adversary.org Tue Jun 7 19:10:32 2016 From: ben at adversary.org (Ben McGinnes) Date: Wed, 8 Jun 2016 03:10:32 +1000 Subject: python bindings for gpgme In-Reply-To: <20160606152047.10010.70223@thinkbox.jade-hamburg.de> References: <201605311439.22496.bernhard@intevation.de> <201606011453.43022.bernhard@intevation.de> <20160601141504.3724.9533@thinkbox.jade-hamburg.de> <201606011754.43709.bernhard@intevation.de> <20160606152047.10010.70223@thinkbox.jade-hamburg.de> Message-ID: <20160607171032.GC81949@adversary.org> On Mon, Jun 06, 2016 at 05:20:47PM +0200, Justus Winter wrote: > Hello Bernhard, > > Quoting Bernhard Reiter (2016-06-01 17:54:43) >> Am Mittwoch, 1. Juni 2016 16:15:04 schrieb Justus Winter: >>>> so we probably should evaluate this. >>> >>> I just did, and as Werner noted, we are very well beyond the >>> evaluation phase. >> >> your evaluation looks a bit biased because you are defending >> what you have currently implemented. > > What else would I be defending? > >> >>> SWIG requires *only* language-specific code. In case you are curious, >>> it is here: >>> >> http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=blob;f=lang/python/gpgme.i;hb=HEAD >> >> I still don't see that defying my argument that SWIG as an additional layer >> creates some overhead (learning python's c api and swig). > > It defies your argument that using SWIG only pays off if you create > bindings for more than one language, which can only be the case if > there is a language-independend part to it, which there isn't. > >>>> My argument is: First I have to understand python's c api with SWIG I >>>> have to understand python's c api and SWIG (and its generated code). >>> >>> I disagree. >>> >>> With SWIG, you write functions translating c types to python types and >>> back. Any function provided by the c library is then automagically >>> wrapped, with the data being converted by the functions you wrote >>> *once*. Add a new function to gpgme, and you likely don't need to do >>> anything in pyme. >> >> When debugging you need to fully understand the resulting c-code >> and it was more complicated with SWIG (last time I've tried). >> >>> With pygpgme, you write code translating the types forth and back >>> *explicitly for every function you want to make available to python*. >>> It is a huge overhead, and likely a source of many errors as that code >>> is likely copied over and over again, without being properly >>> understood. >> >> I haven't checked how it is implemented in pygpgme, there will be typical C >> methods to avoid too much code duplication. > > One of such typical methods is code generation, which is exactly what > SWIG does. In fact, pyme and pygpgme are very similar, they employ a > compiled module at the core, but pyme uses SWIG to generate large > parts of that code. > >>> Let's look at the sizes: >>> >>> % sloccount pygpgme/src >>> [...] >>> 3037 src ansic=3037 >>> % sloccount lang/python/helpers.* lang/python/gpgme.i lang/python/pyme >>> 544 top_dir ansic=544 >>> 497 pyme python=497 >>> >>> Based on that I gather that there must be three to six times as many >>> bugs in pygpgme. >> >> If it is mostly duplicated code, your estimation does not hold. > > I doubt that. In fact, I believe that copying code around increases > the chance of errors, and that it leads to cargo-cult-style > programming. It also makes fixing these bugs hard. > >>>> Comparing the operation and the results, pygpgme combination >>>> into one call seems more pythonic to me. Over time this will add up to a >>>> lot of more code. >>> >>> So let's combine these operations in pymes python shim. >> >> Before the release? Or do we have two ways to achieve the same thing then? > > I'm thinking of providing joined operations, > op_decrypt_verify+op_decrypt_result+op_verify_result => > decrypt_verify. So there would be a second set of operations. > >>>> My main concern is the python API. >>> >>> I understand that, and I believe that providing a more pythonic api is >>> easier with pyme, for reasons I repeatedly stated. >> >> If it is done with SWIG or later with CFFI, I don't care. > > Ok. > >> We should look at the API ideas of pygpgme, I guess. > > What ideas? I'm tired of "make it more pythonic" with noone having a > clear idea what that actually means. Whereas my view of remaking things with Python following an overhaul of GPGME was not so much "make it more Pythonic" (though if that happened as well I wouldn't object) as much as it was "make it more modular" and "make it kind of REST-like" (with all the relevant caveats). For example; using JSON for feeding in data types and receiving the responses. I wanted something which would be familiar enough to all those web-weenies, Javanauts, Node-velopers and Mono-thoughts; at least in relation to the data types they fed it and received from it that they'd have to actually want to code an insecure thing to do anything else. Having something that could also be imported into other Python 3 code is just a functional effect of using the language, not the end goal. If it were the end goal then it'd be no different from any other Python binding. > I fear that it means something different for everyone. So until > someone here actually provides a constructive critique of the > current pyme API, Almost certainly. Which is why I took my cue from what Werner described last year as the intended aim of having an official API for the API. > I'm going to sand-off the edges that would annoy me the most. Fair enough. > I plan to extend this to every object implementing the buffer > interface. I also want to provide the compound operations, and work a > little on the documentation. Cool. I think that currently the biggest impediment to pyme adoption is the lack of usable documentation from Python coders' perspectives. The documentation that does exist is essentially just the existing GPGME documentation with a terse introduction and a couple of examples. It doesn't help that the examples don't really demonstrate the two most common use cases in code: encrypting a thing and decrypting that same thing. There's a lot to be said for a gentler introductory document with some basic examples in it, at least so people can wrap their brains around what they're looking at. The current code and documentation is basically saying, "if you didn't start your coding career with C then you're screwed." So rather than learn C, people go and grab something which might not be quite so secure (like all those awful javascript "implementations" of OpenPGP ... HaneWIN, for instance). Now python-gnupg has many flaws, but it does have fairly coherent documentation with easily replicable code examples throughout the entire thing. By contrast, pyme has the GPGME documentation plus a handful of introductory text paragraphs near the start with one example inside it and no guarantees on what can be found in the examples directory itself on account of every single example being written by people who were *not* the original author (and said original author washed his hands of the thing over a decade ago). Meeting that particular "unspoken requirement" of most developers these days is most likely to gradually lead to an ever increasing uptake of GPGME based code. So I guess I'd better pitch in with the documentation efforts. ;) Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: not available URL: From skawashima at uchicago.edu Thu Jun 9 19:04:58 2016 From: skawashima at uchicago.edu (Seiya Kawashima) Date: Thu, 9 Jun 2016 17:04:58 +0000 Subject: gpgme: prerequisite for running tests under gpgme/tests/gpg In-Reply-To: <87bn3ax2mc.fsf@wheatstone.g10code.de> References: <8CA79C4C24A06A48A11BA99F564B78ED37C519C8@xm-mbx-05-prod>, <87bn3ax2mc.fsf@wheatstone.g10code.de> Message-ID: <8CA79C4C24A06A48A11BA99F564B78ED37C51CBF@xm-mbx-05-prod> > The required keys are imported before the test and a dedicated gpg-agent > is started. For example the import is done by the Makefile.am targets > ./private-keys-v1.d/gpg-sample.stamp > and > ./pubring-stamp > which are triggered by check-local, which is triggered by the > check target (Automake created; check the created Makefile). As you suggested, I took a look at the created Makefile under gpgme/tests/gpg and ran the commands like below on my machine, openSUSE 13.1 (Bottle) (x86_64). If I followed your suggestion correctly, all the tests pass. I appreciate your help on this matter. ~/Downloads/gpgme-1.6.0/tests/gpg>make clean ~/Downloads/gpgme-1.6.0/tests/gpg>make ~/Downloads/gpgme-1.6.0/tests/gpg>make check-TESTS =================== All 23 tests passed =================== Now I would like to make sure a couple of more things to understand the tests under gpgme/tests/gpg. Please forgive me if I miss something. Now If I type the commands like below to run individual tests under gpgme/tests/gpg, would these tests be able to run ? I would need to take a closer look at the test files and the created Makefile but I believe that they would not run because the required keys are not imported. The required keys are imported by initial.test on the created Makefile. I believe that this would be expected or I must have missed a way to run individual tests on the created Makefile. ~/Downloads/gpgme-1.6.0/tests/gpg> ./t-decrypt t-decrypt.c:65: GPGME: Decryption failed ~/Downloads/gpgme-1.6.0/tests/gpg> ./t-decrypt-verify t-decrypt-verify.c:123: GPGME: Decryption failed ~/Downloads/gpgme-1.6.0/tests/gpg> ./t-encrypt t-encrypt.c:60: GPGME: End of file ~/Downloads/gpgme-1.6.0/tests/gpg> ./t-encrypt-sign t-encrypt-sign.c:116: GPGME: End of file Now if I compile a test under gpgme/tests/gpg without make command but simply compile the test like below, would the test be able to run ? I think that it would not run because the required keys are not imported. I believe that this would also be expected or again I must have missed a way to compile individual tests on the created Makefile. ~/Downloads/gpgme-1.6.0/tests/gpg> gcc t-decrypt.c -lgpgme ~/Downloads/gpgme-1.6.0/tests/gpg> ./a.out t-decrypt.c:65: GPGME: Decryption failed Thank you Seiya From aheinecke at intevation.de Fri Jun 10 10:35:08 2016 From: aheinecke at intevation.de (Andre Heinecke) Date: Fri, 10 Jun 2016 10:35:08 +0200 Subject: How to show TOFU / Web Key Directory trust in Mail user Agents Message-ID: <2574570.7SfqMvLxNl@esus> Hi, I'm currently writing a plan how we will implement support for TOFU in KMail for signature states this is relatively clear to me. We only show a "Green" or Valid / Trusted signature once we have the reached the "Key with enough history for basic trust" state. Well actually we will probably follow what GpgME tells us. But for sending I'm unsure how to handle encrypting to a recipient that does not have enough history for basic trust. Currently KMail warns if a Key for a UID is selected where the UID Validity is less then Marginal. In the Future [1] we want to show an icon representation / and simplified Tooltip of the Key Validity next to the Recipient entry field. Where a click on the Icon would open a Details dialog with more explanations. Unknown / key without history: Some kind of Warning / Question Mark Icon and a tooltip with something simple like "Security Unkown". But the next point is where I am unsure about: Marginal / key with too little history for basic trust: I'd like to show something like "Security Good" / Green check mark in that case already. Because: a) Encrypting with this key means you are already protected against all passive attacks and just using OpenPGP is way better then sending an unencrypted mail. b) We are using TOFU (Trust on _first_ Use) not TOTU (Trust on tenth use ;-) ) c) I don't know what else the user could do to increase that trust in the Tofu model. "Hey please send me 10 more mails before I will respond to you with all my secret data." Full Details with TOFU History would be available on click in the details Dialog for technically interested users. But of course this leaves you open to an attack that would prompt you to encrypt data to a Mail Address, sent in a signed Mail and the Reply would already show "Good" security as you have verified one signature from that key. Because of this I was critisized that this is a too "relaxed" UI and that we should rather show some "There is no indication that this Key belongs to the User" warning for cases where TOFU Trust is "Key with too little history". Which leads me to another Problem. How to show / handle the case where a Key was obtained from the Drafted Web Key Directory [2]. In this case there is already an indication that the Key belongs to the owner of the Mail account as the provider / web key service told us this. But in the TOFU Trust model this key would be handled like a key with too little history. I think ideally such a key would be treated like a key with enough history for basic trust as an Attack would have been more expensive then just "tricking" the user into verifying one mail. Do you have any suggestions how we should handle this in the UI? And how to treat Web Key Directory keys? Regards, Andre 1: https://phabricator.kde.org/T2520 2: http://www.ietf.org/id/draft-koch-openpgp-webkey-service-00.txt -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: This is a digitally signed message part. URL: From meskio at sindominio.net Fri Jun 10 12:08:53 2016 From: meskio at sindominio.net (meskio) Date: Fri, 10 Jun 2016 12:08:53 +0200 Subject: How to show TOFU / Web Key Directory trust in Mail user Agents In-Reply-To: <2574570.7SfqMvLxNl@esus> References: <2574570.7SfqMvLxNl@esus> Message-ID: <146555333351.7746.13584915052188419503@KingMob> Quoting Andre Heinecke (2016-06-10 10:35:08) > I'm currently writing a plan how we will implement support for TOFU in KMail > for signature states this is relatively clear to me. We only show a "Green" or > Valid / Trusted signature once we have the reached the "Key with enough > history for basic trust" state. Well actually we will probably follow what > GpgME tells us. > > But for sending I'm unsure how to handle encrypting to a recipient that does > not have enough history for basic trust. > > Currently KMail warns if a Key for a UID is selected where the UID Validity is > less then Marginal. In the Future [1] we want to show an icon representation / > and simplified Tooltip of the Key Validity next to the Recipient entry field. > Where a click on the Icon would open a Details dialog with more explanations. > > Unknown / key without history: Some kind of Warning / Question Mark Icon and a > tooltip with something simple like "Security Unkown". > > But the next point is where I am unsure about: > Marginal / key with too little history for basic trust: I'd like to show > something like "Security Good" / Green check mark in that case already. > Because: > a) Encrypting with this key means you are already protected against all > passive attacks and just using OpenPGP is way better then sending an > unencrypted mail. > b) We are using TOFU (Trust on _first_ Use) not TOTU (Trust on tenth use ;-) ) > c) I don't know what else the user could do to increase that trust in the Tofu > model. "Hey please send me 10 more mails before I will respond to you with all > my secret data." > > Full Details with TOFU History would be available on click in the details > Dialog for technically interested users. > > But of course this leaves you open to an attack that would prompt you to > encrypt data to a Mail Address, sent in a signed Mail and the Reply would > already show "Good" security as you have verified one signature from that key. > > Because of this I was critisized that this is a too "relaxed" UI and that we > should rather show some "There is no indication that this Key belongs to the > User" warning for cases where TOFU Trust is "Key with too little history". > > Which leads me to another Problem. How to show / handle the case where a Key > was obtained from the Drafted Web Key Directory [2]. In this case there is > already an indication that the Key belongs to the owner of the Mail account as > the provider / web key service told us this. But in the TOFU Trust model this > key would be handled like a key with too little history. > > I think ideally such a key would be treated like a key with enough history for > basic trust as an Attack would have been more expensive then just "tricking" > the user into verifying one mail. > > Do you have any suggestions how we should handle this in the UI? And how to > treat Web Key Directory keys? Pretty interesting this 'key with enough history for basic trust' concept. At bitmask[0] we have something similar but simpler where we do kind of TOFU once we have sent an encrypted email and received a signed one. About how to treat Web Key Directory keys maybe you can get some inspiration on how we do it. We don't have support for Web Key Directories yet, but will be easy to add to our trust model, we have something similar were the providers certify the keys of it's users[1]. We have a numeric representation of the level of trust of the source of the key, we call it Validation Level. And we use this validation levels combined the use of the keys to see if we should trust a new key we found for this email address or not. See a longer explanation at: https://leap.se/en/docs/design/transitional-key-validation [0] https://bitmask.net/ [1] https://leap.se/en/docs/design/nicknym -- Ruben Pollan | http://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: http://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: signature URL: From wk at gnupg.org Fri Jun 10 15:04:41 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 10 Jun 2016 15:04:41 +0200 Subject: [PATCH 1/8] tests/openpgp: add export-cleartext In-Reply-To: <87fut6qgw3.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 25 May 2016 11:47:08 -0400") References: <1463787671-7563-1-git-send-email-dkg@fifthhorseman.net> <87iny3qyby.fsf@alice.fifthhorseman.net> <87k2iimz6n.fsf@wheatstone.g10code.de> <87fut6qgw3.fsf@alice.fifthhorseman.net> Message-ID: <87k2hx9ouu.fsf@wheatstone.g10code.de> On Wed, 25 May 2016 17:47, dkg at fifthhorseman.net said: > I broke the patches out into separate logical commits with the goal of > making the series of changes easier to audit and to understand the > workflow piece by piece. (see also mjg's recent discussion about Yeah, okay. However, there is some loss of context and I would prefer to squash some of them. I see 3 kinds of changes: - Some general things (e.g. comments) - Code to request and provide the cleartext flag - The actual export code (2 or 2 of your patches). If you can do that I will gladly apply them because we urgently need a way forward and you have existing code. There are some C-99 issues but I can quickly clean them up later. > whoops, i've historically thought that the Author: line was the > equivalent of that, but i see that doc/HACKING recommends it on a > per-commit basis. I can re-send the patch series with signed-off-by Yeah, that is how the DCO scheme requires. I think a signed commit would do it also, but that does not work with mailed patches. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ From dkg at fifthhorseman.net Fri Jun 10 16:51:34 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 10 Jun 2016 10:51:34 -0400 Subject: [PATCH 1/8] tests/openpgp: add export-cleartext In-Reply-To: <87k2hx9ouu.fsf@wheatstone.g10code.de> References: <1463787671-7563-1-git-send-email-dkg@fifthhorseman.net> <87iny3qyby.fsf@alice.fifthhorseman.net> <87k2iimz6n.fsf@wheatstone.g10code.de> <87fut6qgw3.fsf@alice.fifthhorseman.net> <87k2hx9ouu.fsf@wheatstone.g10code.de> Message-ID: <87y46d9jwp.fsf@alice.fifthhorseman.net> On Fri 2016-06-10 09:04:41 -0400, Werner Koch wrote: > On Wed, 25 May 2016 17:47, dkg at fifthhorseman.net said: > >> I broke the patches out into separate logical commits with the goal of >> making the series of changes easier to audit and to understand the >> workflow piece by piece. (see also mjg's recent discussion about > > Yeah, okay. However, there is some loss of context and I would prefer > to squash some of them. I see 3 kinds of changes: > > - Some general things (e.g. comments) > - Code to request and provide the cleartext flag > - The actual export code (2 or 2 of your patches). > > If you can do that I will gladly apply them because we urgently need a > way forward and you have existing code. There are some C-99 issues but > I can quickly clean them up later. will do, i'll send this to the list later today. > Yeah, that is how the DCO scheme requires. I think a signed commit > would do it also, but that does not work with mailed patches. right, i'll try to do better going forward. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From skawashima at uchicago.edu Fri Jun 10 17:17:51 2016 From: skawashima at uchicago.edu (Seiya Kawashima) Date: Fri, 10 Jun 2016 15:17:51 +0000 Subject: gpgme: potential minor memory leaks in tests under gpgme/test/gpg Message-ID: <8CA79C4C24A06A48A11BA99F564B78ED37C51E4E@xm-mbx-05-prod> Hi, I've been checking the test files under gpgme/tests/gpg. I cloned GPGME via git. The commit is 77d149e8614c381458e07808a7930ce3fb92cdc3 and the date is Wed Jun 8 18:06:24 2016 +0200. I might have found potential minor memory leaks in gpgme/tests/gpg/t-decrypt.c, gpgme/tests/gpg/t-import.c, gpgme/tests/gpg/t-thread1.c and gpgme/tests/gpg/t-decrypt-verify.c. If they are not memory leaks or they are already fixed, please disregard the email. It seems to me that all the leaks are caused by make_filename() in t-support.h:104. make_filename() allocates memory via malloc() in t-support.h:111 like buf = malloc (strlen(srcdir) + strlen(fname) + 2); but the memory is never freed in those tests.The file names are created in the tests as below. ./t-decrypt.c:46: const char *cipher_1_asc = make_filename ("cipher-1.asc"); ./t-import.c:217: const char *pubkey_1_asc = make_filename ("pubkey-1.asc"); ./t-import.c:218: const char *seckey_1_asc = make_filename ("seckey-1.asc"); ./t-thread1.c:97: const char *cipher_1_asc = make_filename ("cipher-1.asc"); ./t-decrypt-verify.c:104: const char *cipher_2_asc = make_filename ("cipher-2.asc"); The corresponding free() seems to be needed. I've checked the source code of gpgme_data_new_from_filepart() and gpgme_data_new_from_file(). When the file name is dynamically allocated, the caller of gpgme_data_new_from_file() seems to be responsible for freeing the memory. The small C code below simulates the memory leak. #include #include #include #include "t-support.h" int main (int argc, char *argv[]) { gpgme_error_t err; gpgme_data_t in; const char *cipher_1_asc = make_filename ("cipher-1.asc"); err = gpgme_data_new_from_file (&in, cipher_1_asc, 1); fail_if_err (err); /* Need to free cipher_1_asc. Comment the below free() to cause a memory leak. Copy and paste the code into gpgme/tests/gpg. Compile the code like gcc -g t-make-filename.c -lgpgme. Run it with Valgrind like valgrind --leak-check=full ./a.out. */ free((char *)cipher_1_asc); gpgme_data_release (in); return 0; } Keep up the great work. Seiya From dkg at fifthhorseman.net Fri Jun 10 22:15:32 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 10 Jun 2016 16:15:32 -0400 Subject: non-interactive export of secret keys stored in cleartext In-Reply-To: <87y46d9jwp.fsf@alice.fifthhorseman.net> References: <87y46d9jwp.fsf@alice.fifthhorseman.net> Message-ID: <1465589736-8267-1-git-send-email-dkg@fifthhorseman.net> A shorter (squashed) series of changesets follows that address the ability to export cleartext secret key material when it is stored in the clear. These should apply the the current published git master (8127043d549a5843ea1ba2dc6da4906fc2258d53). overview of total changes in this series: agent/command.c | 7 +- g10/call-agent.c | 76 +++++++++++----- g10/call-agent.h | 5 +- g10/export.c | 227 +++++++++++++++++++++++++++++++++++++++++++++- g10/gpgv.c | 4 +- g10/keyedit.c | 4 +- g10/keygen.c | 4 +- g10/keylist.c | 10 +- g10/main.h | 1 + g10/sign.c | 2 +- g10/test-stubs.c | 4 +- tests/openpgp/export.test | 28 +----- 12 files changed, 305 insertions(+), 67 deletions(-) From dkg at fifthhorseman.net Fri Jun 10 22:15:36 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 10 Jun 2016 16:15:36 -0400 Subject: [PATCH v2 4/4] g10: export cleartext keys as cleartext In-Reply-To: <1465589736-8267-1-git-send-email-dkg@fifthhorseman.net> References: <87y46d9jwp.fsf@alice.fifthhorseman.net> <1465589736-8267-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <1465589736-8267-5-git-send-email-dkg@fifthhorseman.net> * g10/export.c (do_export_stream): if a key is stored by the agent in cleartext, then try to export it as cleartext. * tests/openpgp/export.test: for secret keys that are stored in cleartext, test should try to export without pinentry interaction. This restores the behavior of GnuPG 2.0 and 1.4 when exporting passphraseless secret keys, and fixes the test suite accordingly. -- GnuPG-bug-id: 2070, 2324 Signed-off-by: Daniel Kahn Gillmor --- g10/export.c | 5 +++-- tests/openpgp/export.test | 28 ++++------------------------ 2 files changed, 7 insertions(+), 26 deletions(-) diff --git a/g10/export.c b/g10/export.c index 25a3319..870cb45 100644 --- a/g10/export.c +++ b/g10/export.c @@ -1141,6 +1141,7 @@ do_export_stream (ctrl_t ctrl, iobuf_t out, strlist_t users, int secret, gcry_cipher_hd_t cipherhd = NULL; char *cache_nonce = NULL; struct export_stats_s dummystats; + int cleartext = 0; if (!stats) stats = &dummystats; @@ -1445,7 +1446,7 @@ do_export_stream (ctrl_t ctrl, iobuf_t out, strlist_t users, int secret, serialno = NULL; } else - err = agent_get_keyinfo (ctrl, hexgrip, &serialno, NULL); + err = agent_get_keyinfo (ctrl, hexgrip, &serialno, &cleartext); if ((!err && serialno) && secret == 2 && node->pkt->pkttype == PKT_PUBLIC_KEY) @@ -1494,7 +1495,7 @@ do_export_stream (ctrl_t ctrl, iobuf_t out, strlist_t users, int secret, else if (!err) { err = receive_seckey_from_agent (ctrl, cipherhd, - 0, &cache_nonce, + cleartext, &cache_nonce, hexgrip, pk); if (err) { diff --git a/tests/openpgp/export.test b/tests/openpgp/export.test index e0fe926..3d0dc3f 100755 --- a/tests/openpgp/export.test +++ b/tests/openpgp/export.test @@ -61,8 +61,6 @@ assert_passphrases_consumed() rm -f -- $logfile } -# XXX: Currently, gpg does not allow one to export private keys -# without a passphrase (issue2070, issue2324). export PINENTRY_USER_DATA="--logfile=$logfile --passphrasefile=$ppfile" info "Checking key export." @@ -78,23 +76,13 @@ do check_armored_public_key $KEY.public rm $KEY.public + # test without --armor: + if [ $KEY = D74C5F22 ]; then # Key D74C5F22 is protected by a passphrase. Prepare this # one. Currently, GnuPG does not ask for an export passphrase # in this case. prepare_passphrase "$usrpass1" - else - # We use a weak passphrase which we'll have to confirm. - prepare_passphrase "export passphrase" - prepare_passphrase_confirm - prepare_passphrase "export passphrase" - - # Key C40FDECF has a subkey. - if [ $KEY = C40FDECF ]; then - prepare_passphrase "export passphrase" - prepare_passphrase_confirm - prepare_passphrase "export passphrase" - fi fi $GPG --export-secret-keys $KEY >$KEY.private @@ -103,21 +91,13 @@ do assert_passphrases_consumed + # test with --armor: + if [ $KEY = D74C5F22 ]; then # Key D74C5F22 is protected by a passphrase. Prepare this # one. Currently, GnuPG does not ask for an export passphrase # in this case. prepare_passphrase "$usrpass1" - else - # We use a stronger passphrase here. - prepare_passphrase "strong export passphrase H0LHWCHPkNa36A" - prepare_passphrase "strong export passphrase H0LHWCHPkNa36A" - - # Key C40FDECF has a subkey. - if [ $KEY = C40FDECF ]; then - prepare_passphrase "strong export passphrase H0LHWCHPkNa36A" - prepare_passphrase "strong export passphrase H0LHWCHPkNa36A" - fi fi $GPG --armor --export-secret-keys $KEY >$KEY.private -- 2.8.1 From dkg at fifthhorseman.net Fri Jun 10 22:15:33 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 10 Jun 2016 16:15:33 -0400 Subject: [PATCH v2 1/4] g10: report whether key in agent is passphrase-protected or not In-Reply-To: <1465589736-8267-1-git-send-email-dkg@fifthhorseman.net> References: <87y46d9jwp.fsf@alice.fifthhorseman.net> <1465589736-8267-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <1465589736-8267-2-git-send-email-dkg@fifthhorseman.net> * g10/call-agent.c, g10/call-agent.h (agent_get_keyinfo): add r_cleartext parameter to report whether a key is stored without passphrase protection. * g10/gpgv.c, g10/test-stubs.c: augment dummy agent_get_keyinfo to match new API. * g10/export.c, g10/keyedit.c, g10/keygen.c, g10/keylist.c, g10/sign.c: pass NULL to agent_get_keyinfo since we do not yet need to know whether agent is passphrase-protected. -- Signed-off-by: Daniel Kahn Gillmor --- g10/call-agent.c | 61 +++++++++++++++++++++++++++++++++++++++----------------- g10/call-agent.h | 2 +- g10/export.c | 2 +- g10/gpgv.c | 4 +++- g10/keyedit.c | 4 ++-- g10/keygen.c | 2 +- g10/keylist.c | 10 +++++----- g10/sign.c | 2 +- g10/test-stubs.c | 4 +++- 9 files changed, 60 insertions(+), 31 deletions(-) diff --git a/g10/call-agent.c b/g10/call-agent.c index 46dfd57..470fa16 100644 --- a/g10/call-agent.c +++ b/g10/call-agent.c @@ -1671,26 +1671,42 @@ agent_probe_any_secret_key (ctrl_t ctrl, kbnode_t keyblock) +struct keyinfo_data { + char *serialno; + int cleartext; +}; + static gpg_error_t keyinfo_status_cb (void *opaque, const char *line) { - char **serialno = opaque; + struct keyinfo_data *data = opaque; + int is_smartcard; const char *s, *s2; - if ((s = has_leading_keyword (line, "KEYINFO")) && !*serialno) + if ((s = has_leading_keyword (line, "KEYINFO")) && data) { s = strchr (s, ' '); - if (s && s[1] == 'T' && s[2] == ' ' && s[3]) + if (s) { - s += 3; - s2 = strchr (s, ' '); - if ( s2 > s ) + is_smartcard = (s[1] == 'T'); + if ( s[2] == ' ' && s[3] ) { - *serialno = xtrymalloc ((s2 - s)+1); - if (*serialno) + s += 3; + s2 = strchr (s, ' '); + if ( s2 > s ) { - memcpy (*serialno, s, s2 - s); - (*serialno)[s2 - s] = 0; + if (is_smartcard && !data->serialno) + { + data->serialno = xtrymalloc ((s2 - s)+1); + if (data->serialno) + { + memcpy (data->serialno, s, s2 - s); + (data->serialno)[s2 - s] = 0; + } + } + if (s2 = strchr (s2 + 1, ' '), s2) /* skip IDSTR (can IDSTR contain a space?) */ + if (s2 = strchr (s2 + 1, ' '), s2) /* skip CACHED */ + data->cleartext = (s2[1] == 'C'); /* 'P' for protected, 'C' for clear */ } } } @@ -1701,13 +1717,18 @@ keyinfo_status_cb (void *opaque, const char *line) /* Return the serial number for a secret key. If the returned serial number is NULL, the key is not stored on a smartcard. Caller needs - to free R_SERIALNO. */ + to free R_SERIALNO. + + if r_cleartext is not NULL, the referenced int will be set to 1 if + the agent's copy of the key is stored in the clear, or 0 otherwise +*/ gpg_error_t -agent_get_keyinfo (ctrl_t ctrl, const char *hexkeygrip, char **r_serialno) +agent_get_keyinfo (ctrl_t ctrl, const char *hexkeygrip, + char **r_serialno, int *r_cleartext) { gpg_error_t err; char line[ASSUAN_LINELENGTH]; - char *serialno = NULL; + struct keyinfo_data keyinfo = { .serialno = NULL, .cleartext = 0 }; *r_serialno = NULL; @@ -1722,17 +1743,21 @@ agent_get_keyinfo (ctrl_t ctrl, const char *hexkeygrip, char **r_serialno) line[DIM(line)-1] = 0; err = assuan_transact (agent_ctx, line, NULL, NULL, NULL, NULL, - keyinfo_status_cb, &serialno); - if (!err && serialno) + keyinfo_status_cb, &keyinfo); + if (!err && keyinfo.serialno) { /* Sanity check for bad characters. */ - if (strpbrk (serialno, ":\n\r")) + if (strpbrk (keyinfo.serialno, ":\n\r")) err = GPG_ERR_INV_VALUE; } if (err) - xfree (serialno); + xfree (keyinfo.serialno); else - *r_serialno = serialno; + { + *r_serialno = keyinfo.serialno; + if (r_cleartext) + *r_cleartext = keyinfo.cleartext; + } return err; } diff --git a/g10/call-agent.h b/g10/call-agent.h index 4e83388..a5d01e6 100644 --- a/g10/call-agent.h +++ b/g10/call-agent.h @@ -153,7 +153,7 @@ gpg_error_t agent_probe_any_secret_key (ctrl_t ctrl, kbnode_t keyblock); /* Return infos about the secret key with HEXKEYGRIP. */ gpg_error_t agent_get_keyinfo (ctrl_t ctrl, const char *hexkeygrip, - char **r_serialno); + char **r_serialno, int *r_cleartext); /* Generate a new key. */ gpg_error_t agent_genkey (ctrl_t ctrl, diff --git a/g10/export.c b/g10/export.c index aae8d42..d47c27d 100644 --- a/g10/export.c +++ b/g10/export.c @@ -1228,7 +1228,7 @@ do_export_stream (ctrl_t ctrl, iobuf_t out, strlist_t users, int secret, serialno = NULL; } else - err = agent_get_keyinfo (ctrl, hexgrip, &serialno); + err = agent_get_keyinfo (ctrl, hexgrip, &serialno, NULL); if ((!err && serialno) && secret == 2 && node->pkt->pkttype == PKT_PUBLIC_KEY) diff --git a/g10/gpgv.c b/g10/gpgv.c index 30b4422..2aed10c 100644 --- a/g10/gpgv.c +++ b/g10/gpgv.c @@ -603,10 +603,12 @@ agent_probe_any_secret_key (ctrl_t ctrl, kbnode_t keyblock) } gpg_error_t -agent_get_keyinfo (ctrl_t ctrl, const char *hexkeygrip, char **r_serialno) +agent_get_keyinfo (ctrl_t ctrl, const char *hexkeygrip, + char **r_serialno, int *r_cleartext) { (void)ctrl; (void)hexkeygrip; + (void)r_cleartext; *r_serialno = NULL; return gpg_error (GPG_ERR_NO_SECKEY); } diff --git a/g10/keyedit.c b/g10/keyedit.c index aa62cc1..d05ea5d 100644 --- a/g10/keyedit.c +++ b/g10/keyedit.c @@ -1692,7 +1692,7 @@ change_passphrase (ctrl_t ctrl, kbnode_t keyblock) err = hexkeygrip_from_pk (pk, &hexgrip); if (err) goto leave; - err = agent_get_keyinfo (ctrl, hexgrip, &serialno); + err = agent_get_keyinfo (ctrl, hexgrip, &serialno, NULL); if (!err && serialno) ; /* Key on card. */ else if (gpg_err_code (err) == GPG_ERR_NOT_FOUND) @@ -3766,7 +3766,7 @@ show_key_with_all_names (ctrl_t ctrl, estream_t fp, have_seckey = 0; } else - have_seckey = !agent_get_keyinfo (ctrl, hexgrip, &serialno); + have_seckey = !agent_get_keyinfo (ctrl, hexgrip, &serialno, NULL); xfree (hexgrip); } diff --git a/g10/keygen.c b/g10/keygen.c index ad5dfa4..b8e4cb8 100644 --- a/g10/keygen.c +++ b/g10/keygen.c @@ -4571,7 +4571,7 @@ generate_subkeypair (ctrl_t ctrl, kbnode_t keyblock, const char *algostr, err = hexkeygrip_from_pk (pri_psk, &hexgrip); if (err) goto leave; - if (agent_get_keyinfo (NULL, hexgrip, &serialno)) + if (agent_get_keyinfo (NULL, hexgrip, &serialno, NULL)) { if (interactive) tty_printf (_("Secret parts of primary key are not available.\n")); diff --git a/g10/keylist.c b/g10/keylist.c index 231f3c0..973a9fb 100644 --- a/g10/keylist.c +++ b/g10/keylist.c @@ -247,7 +247,7 @@ print_card_key_info (estream_t fp, kbnode_t keyblock) log_error ("error computing a keygrip: %s\n", gpg_strerror (rc)); s2k_char = '?'; } - else if (!agent_get_keyinfo (NULL, hexgrip, &serialno)) + else if (!agent_get_keyinfo (NULL, hexgrip, &serialno, NULL)) s2k_char = serialno? '>':' '; else s2k_char = '#'; /* Key not found. */ @@ -1046,7 +1046,7 @@ list_keyblock_print (ctrl_t ctrl, kbnode_t keyblock, int secret, int fpr, if (secret) { /* Encode some info about the secret key in SECRET. */ - if (!agent_get_keyinfo (NULL, hexgrip, &serialno)) + if (!agent_get_keyinfo (NULL, hexgrip, &serialno, NULL)) secret = serialno? 3 : 1; else secret = 2; /* Key not found. */ @@ -1160,7 +1160,7 @@ list_keyblock_print (ctrl_t ctrl, kbnode_t keyblock, int secret, int fpr, } if (secret) { - if (!agent_get_keyinfo (NULL, hexgrip, &serialno)) + if (!agent_get_keyinfo (NULL, hexgrip, &serialno, NULL)) secret = serialno? 3 : 1; else secret = '2'; /* Key not found. */ @@ -1354,7 +1354,7 @@ list_keyblock_colon (ctrl_t ctrl, kbnode_t keyblock, log_error ("error computing a keygrip: %s\n", gpg_strerror (rc)); } stubkey = 0; - if ((secret||has_secret) && agent_get_keyinfo (NULL, hexgrip, &serialno)) + if ((secret||has_secret) && agent_get_keyinfo (NULL, hexgrip, &serialno, NULL)) stubkey = 1; /* Key not found. */ keyid_from_pk (pk, keyid); @@ -1501,7 +1501,7 @@ list_keyblock_colon (ctrl_t ctrl, kbnode_t keyblock, } stubkey = 0; if ((secret||has_secret) - && agent_get_keyinfo (NULL, hexgrip, &serialno)) + && agent_get_keyinfo (NULL, hexgrip, &serialno, NULL)) stubkey = 1; /* Key not found. */ keyid_from_pk (pk2, keyid2); diff --git a/g10/sign.c b/g10/sign.c index 364634a..15c18ee 100644 --- a/g10/sign.c +++ b/g10/sign.c @@ -346,7 +346,7 @@ openpgp_card_v1_p (PKT_public_key *pk) } xfree (pk->serialno); - agent_get_keyinfo (NULL, hexgrip, &pk->serialno); + agent_get_keyinfo (NULL, hexgrip, &pk->serialno, NULL); xfree (hexgrip); pk->flags.serialno_valid = 1; } diff --git a/g10/test-stubs.c b/g10/test-stubs.c index cfaa72c..42c91f8 100644 --- a/g10/test-stubs.c +++ b/g10/test-stubs.c @@ -415,10 +415,12 @@ agent_probe_any_secret_key (ctrl_t ctrl, kbnode_t keyblock) } gpg_error_t -agent_get_keyinfo (ctrl_t ctrl, const char *hexkeygrip, char **r_serialno) +agent_get_keyinfo (ctrl_t ctrl, const char *hexkeygrip, + char **r_serialno, int *r_cleartext) { (void)ctrl; (void)hexkeygrip; + (void)r_cleartext; *r_serialno = NULL; return gpg_error (GPG_ERR_NO_SECKEY); } -- 2.8.1 From dkg at fifthhorseman.net Fri Jun 10 22:15:34 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 10 Jun 2016 16:15:34 -0400 Subject: [PATCH v2 2/4] g10: add openpgp_protected flag to agent secret key export functions In-Reply-To: <1465589736-8267-1-git-send-email-dkg@fifthhorseman.net> References: <87y46d9jwp.fsf@alice.fifthhorseman.net> <1465589736-8267-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <1465589736-8267-3-git-send-email-dkg@fifthhorseman.net> * g10/call-agent.c, g10/call-agent.h (agent_export_key): add openpgp_protected flag. * g10/export.c (receive_seckey_from_agent): request openpgp_protected secret keys from agent. * agent/command.c (hlp_export_key): EXPORT_KEY help text: add a brief description of the effect of --openpgp. The --openpgp flag for gpg-agent's EXPORT_KEY actually forces encryption in a certain (RFC 4880-compatible format). This changeset exposes that functionality in internal functions, and clarifies functionality in the agent's help text. -- Signed-off-by: Daniel Kahn Gillmor --- agent/command.c | 7 ++++++- g10/call-agent.c | 15 +++++++++------ g10/call-agent.h | 3 ++- g10/export.c | 2 +- 4 files changed, 18 insertions(+), 9 deletions(-) diff --git a/agent/command.c b/agent/command.c index 1898d6c..de5b184 100644 --- a/agent/command.c +++ b/agent/command.c @@ -2210,7 +2210,12 @@ static const char hlp_export_key[] = "Export a secret key from the key store. The key will be encrypted\n" "using the current session's key wrapping key (cf. command KEYWRAP_KEY)\n" "using the AESWRAP-128 algorithm. The caller needs to retrieve that key\n" - "prior to using this command. The function takes the keygrip as argument.\n"; + "prior to using this command. The function takes the keygrip as argument.\n" + "\n" + "If --openpgp is used, the secret key material will be exported in RFC 4880\n" + "compatible passphrase-protected form. Without --openpgp, the secret key\n" + "material will be exported in the clear (after prompting the user to unlock\n" + "it, if needed).\n"; static gpg_error_t cmd_export_key (assuan_context_t ctx, char *line) { diff --git a/g10/call-agent.c b/g10/call-agent.c index 470fa16..06a2d86 100644 --- a/g10/call-agent.c +++ b/g10/call-agent.c @@ -2315,13 +2315,15 @@ agent_import_key (ctrl_t ctrl, const char *desc, char **cache_nonce_addr, /* Receive a secret key from the agent. HEXKEYGRIP is the hexified keygrip, DESC a prompt to be displayed with the agent's passphrase - question (needs to be plus+percent escaped). If CACHE_NONCE_ADDR - is not NULL the agent is advised to first try a passphrase - associated with that nonce. On success the key is stored as a - canonical S-expression at R_RESULT and R_RESULTLEN. */ + question (needs to be plus+percent escaped). if OPENPGP_PROTECTED + is not zero, ensure that the key material is returned in RFC + 4880-compatible passphrased-protected form. If CACHE_NONCE_ADDR is + not NULL the agent is advised to first try a passphrase associated + with that nonce. On success the key is stored as a canonical + S-expression at R_RESULT and R_RESULTLEN. */ gpg_error_t agent_export_key (ctrl_t ctrl, const char *hexkeygrip, const char *desc, - char **cache_nonce_addr, + int openpgp_protected, char **cache_nonce_addr, unsigned char **r_result, size_t *r_resultlen) { gpg_error_t err; @@ -2351,7 +2353,8 @@ agent_export_key (ctrl_t ctrl, const char *hexkeygrip, const char *desc, return err; } - snprintf (line, DIM(line)-1, "EXPORT_KEY --openpgp %s%s %s", + snprintf (line, DIM(line)-1, "EXPORT_KEY %s%s%s %s", + openpgp_protected ? "--openpgp ":"", cache_nonce_addr && *cache_nonce_addr? "--cache-nonce=":"", cache_nonce_addr && *cache_nonce_addr? *cache_nonce_addr:"", hexkeygrip); diff --git a/g10/call-agent.h b/g10/call-agent.h index a5d01e6..d85a6fd 100644 --- a/g10/call-agent.h +++ b/g10/call-agent.h @@ -192,7 +192,8 @@ gpg_error_t agent_import_key (ctrl_t ctrl, const char *desc, /* Receive a key from the agent. */ gpg_error_t agent_export_key (ctrl_t ctrl, const char *keygrip, - const char *desc, char **cache_nonce_addr, + const char *desc, int openpgp_protected, + char **cache_nonce_addr, unsigned char **r_result, size_t *r_resultlen); /* Delete a key from the agent. */ diff --git a/g10/export.c b/g10/export.c index d47c27d..5b161ae 100644 --- a/g10/export.c +++ b/g10/export.c @@ -852,7 +852,7 @@ receive_seckey_from_agent (ctrl_t ctrl, gcry_cipher_hd_t cipherhd, log_info ("key %s: asking agent for the secret parts\n", hexgrip); prompt = gpg_format_keydesc (pk, FORMAT_KEYDESC_EXPORT,1); - err = agent_export_key (ctrl, hexgrip, prompt, cache_nonce_addr, + err = agent_export_key (ctrl, hexgrip, prompt, 1, cache_nonce_addr, &wrappedkey, &wrappedkeylen); xfree (prompt); -- 2.8.1 From dkg at fifthhorseman.net Fri Jun 10 22:15:35 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 10 Jun 2016 16:15:35 -0400 Subject: [PATCH v2 3/4] g10: allow receiving cleartext secret keys from agent In-Reply-To: <1465589736-8267-1-git-send-email-dkg@fifthhorseman.net> References: <87y46d9jwp.fsf@alice.fifthhorseman.net> <1465589736-8267-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <1465589736-8267-4-git-send-email-dkg@fifthhorseman.net> * g10/export.c (match_curve_skey_pk): new function, testing whether an OpenPGP public key and an S-expression use the same curve. * g10/export.c (cleartext_secret_key_to_openpgp): new function, filling in the secret key parameters of a PKT_public_key object from a corresponding cleartext S-expression. * g10/export.c, g10/main.h (receive_seckey_from_agent): add cleartext parameter, enabling retrieval of the secret key, unlocked. * g10/export.c (do_export_stream): send cleartext as 0, keeping current behavior. * g10/keygen.c (card_store_key_with_backup): use cleartext=0 to ensure that smartcard backups are all passphrase-locked. This sets up internal functionality to be capable of exporting cleartext secret keys, but does not change any existing behavior. -- Signed-off-by: Daniel Kahn Gillmor --- g10/export.c | 224 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- g10/keygen.c | 2 +- g10/main.h | 1 + 3 files changed, 223 insertions(+), 4 deletions(-) diff --git a/g10/export.c b/g10/export.c index 5b161ae..25a3319 100644 --- a/g10/export.c +++ b/g10/export.c @@ -390,6 +390,71 @@ exact_subkey_match_p (KEYDB_SEARCH_DESC *desc, KBNODE node) return result; } +/* return an error if the key represented by the S-expression s_key + and the OpenPGP key represented by pk do not use the same curve. */ +static gpg_error_t +match_curve_skey_pk (gcry_sexp_t s_key, PKT_public_key *pk) +{ + gcry_sexp_t curve = NULL, flags = NULL; + char *curve_str = NULL, *flag; + const char *oidstr = NULL; + gcry_mpi_t curve_as_mpi = NULL; + gpg_error_t err; + int is_eddsa = 0, idx = 0; + + if (!(pk->pubkey_algo==PUBKEY_ALGO_ECDH || + pk->pubkey_algo==PUBKEY_ALGO_ECDSA || + pk->pubkey_algo==PUBKEY_ALGO_EDDSA)) + return gpg_error (GPG_ERR_PUBKEY_ALGO); + + curve = gcry_sexp_find_token (s_key, "curve", 0); + if (!curve) + { + log_error ("no reported curve\n"); + err = gpg_error (GPG_ERR_UNKNOWN_CURVE); + } + curve_str = gcry_sexp_nth_string (curve, 1); + gcry_sexp_release (curve); curve = NULL; + if (!curve_str) + { + log_error ("no curve name\n"); + return gpg_error (GPG_ERR_UNKNOWN_CURVE); + } + oidstr = openpgp_curve_to_oid (curve_str, NULL); + if (!oidstr) + { + log_error ("no OID known for curve '%s'\n", curve_str); + gcry_free (curve_str); + return gpg_error (GPG_ERR_UNKNOWN_CURVE); + } + gcry_free (curve_str); + err = openpgp_oid_from_str (oidstr, &curve_as_mpi); + if (err) + return err; + if (gcry_mpi_cmp(pk->pkey[0], curve_as_mpi)) + { + log_error ("curves do not match\n"); + err = gpg_error (GPG_ERR_INV_CURVE); + } + gcry_mpi_release (curve_as_mpi); + flags = gcry_sexp_find_token (s_key, "flags", 0); + if (flags) + for (idx = 1; idx < gcry_sexp_length (flags); idx++) + { + flag = gcry_sexp_nth_string (flags, idx); + if (flag && (strcmp ("eddsa", flag) == 0)) + is_eddsa = 1; + gcry_free (flag); + } + if (is_eddsa != + (pk->pubkey_algo==PUBKEY_ALGO_EDDSA)) + { + log_error ("disagreement about EdDSA\n"); + err = gpg_error (GPG_ERR_INV_CURVE); + } + + return err; +} /* Return a canonicalized public key algoithms. This is used to compare different flavors of algorithms (e.g. ELG and ELG_E are @@ -411,6 +476,150 @@ canon_pk_algo (enum gcry_pk_algos algo) } } +/* take a cleartext dump of a secret key in PK and change the + parameter array in PK to include the secret parameters. */ +static gpg_error_t +cleartext_secret_key_to_openpgp (gcry_sexp_t s_key, PKT_public_key *pk) +{ + gpg_error_t err = gpg_error (GPG_ERR_NOT_IMPLEMENTED); + gcry_sexp_t top_list; + gcry_sexp_t key = NULL; + char *key_type = NULL; + enum gcry_pk_algos pk_algo; + struct seckey_info *ski; + int idx, sec_start; + gcry_mpi_t pub_params[10] = { NULL }; + + /* we look for a private-key, then the first element in it tells us + the type */ + top_list = gcry_sexp_find_token (s_key, "private-key", 0); + if (!top_list) + goto bad_seckey; + if (gcry_sexp_length(top_list) != 2) + goto bad_seckey; + key = gcry_sexp_nth (top_list, 1); + if (!key) + goto bad_seckey; + key_type = gcry_sexp_nth_string(key, 0); + pk_algo = gcry_pk_map_name (key_type); + + log_assert(pk->seckey_info == NULL); + + pk->seckey_info = ski = xtrycalloc (1, sizeof *ski); + if (!ski) + { + err = gpg_error_from_syserror (); + goto leave; + } + + switch (canon_pk_algo (pk_algo)) + { + case GCRY_PK_RSA: + if (!is_RSA (pk->pubkey_algo)) + goto bad_pubkey_algo; + err = gcry_sexp_extract_param (key, NULL, "ne", + &pub_params[0], + &pub_params[1], + NULL); + for (idx=0; idx < 2 && !err; idx++) + if (gcry_mpi_cmp(pk->pkey[idx], pub_params[idx])) + err = gpg_error (GPG_ERR_BAD_PUBKEY); + if (!err) + err = gcry_sexp_extract_param (key, NULL, "dpqu", + &pk->pkey[2], + &pk->pkey[3], + &pk->pkey[4], + &pk->pkey[5], + NULL); + if (!err) + for (idx = 2; idx < 6; idx++) + ski->csum += checksum_mpi (pk->pkey[idx]); + break; + + case GCRY_PK_DSA: + if (!is_DSA (pk->pubkey_algo)) + goto bad_pubkey_algo; + err = gcry_sexp_extract_param (key, NULL, "pqgy", + &pub_params[0], + &pub_params[1], + &pub_params[2], + &pub_params[3], + NULL); + for (idx=0; idx < 4 && !err; idx++) + if (gcry_mpi_cmp(pk->pkey[idx], pub_params[idx])) + err = gpg_error (GPG_ERR_BAD_PUBKEY); + if (!err) + err = gcry_sexp_extract_param (key, NULL, "x", + &pk->pkey[4], + NULL); + if (!err) + ski->csum += checksum_mpi (pk->pkey[4]); + break; + + case GCRY_PK_ELG: + if (!is_ELGAMAL (pk->pubkey_algo)) + goto bad_pubkey_algo; + err = gcry_sexp_extract_param (key, NULL, "pgy", + &pub_params[0], + &pub_params[1], + &pub_params[2], + NULL); + for (idx=0; idx < 3 && !err; idx++) + if (gcry_mpi_cmp(pk->pkey[idx], pub_params[idx])) + err = gpg_error (GPG_ERR_BAD_PUBKEY); + if (!err) + err = gcry_sexp_extract_param (key, NULL, "x", + &pk->pkey[3], + NULL); + if (!err) + ski->csum += checksum_mpi (pk->pkey[3]); + break; + + case GCRY_PK_ECC: + err = match_curve_skey_pk (key, pk); + if (err) + goto leave; + if (!err) + err = gcry_sexp_extract_param (key, NULL, "q", + &pub_params[0], + NULL); + if (!err && (gcry_mpi_cmp(pk->pkey[1], pub_params[0]))) + err = gpg_error (GPG_ERR_BAD_PUBKEY); + + sec_start = 2; + if (pk->pubkey_algo == PUBKEY_ALGO_ECDH) + sec_start += 1; + if (!err) + err = gcry_sexp_extract_param (key, NULL, "d", + &pk->pkey[sec_start], + NULL); + + if (!err) + ski->csum += checksum_mpi (pk->pkey[sec_start]); + break; + + default: + pk->seckey_info = NULL; + free (ski); + err = gpg_error (GPG_ERR_NOT_IMPLEMENTED); + } + leave: + gcry_sexp_release (top_list); + gcry_sexp_release (key); + gcry_free (key_type); + + for (idx=0; idx < DIM(pub_params); idx++) + gcry_mpi_release (pub_params[idx]); + return err; + + bad_pubkey_algo: + err = gpg_error (GPG_ERR_PUBKEY_ALGO); + goto leave; + + bad_seckey: + err = gpg_error (GPG_ERR_BAD_SECKEY); + goto leave; +} /* Use the key transfer format given in S_PGP to create the secinfo structure in PK and change the parameter array in PK to include the @@ -833,10 +1042,15 @@ print_status_exported (PKT_public_key *pk) * Then, parse the decrypted key data in transfer format, and put * secret parameters into PK. * + * if CLEARTEXT is 0, store the secret key material + * passphrase-protected. otherwise, store secret key material in the + * clear. + * * CACHE_NONCE_ADDR is used to share nonce for multple key retrievals. */ gpg_error_t receive_seckey_from_agent (ctrl_t ctrl, gcry_cipher_hd_t cipherhd, + int cleartext, char **cache_nonce_addr, const char *hexgrip, PKT_public_key *pk) { @@ -852,7 +1066,7 @@ receive_seckey_from_agent (ctrl_t ctrl, gcry_cipher_hd_t cipherhd, log_info ("key %s: asking agent for the secret parts\n", hexgrip); prompt = gpg_format_keydesc (pk, FORMAT_KEYDESC_EXPORT,1); - err = agent_export_key (ctrl, hexgrip, prompt, 1, cache_nonce_addr, + err = agent_export_key (ctrl, hexgrip, prompt, !cleartext, cache_nonce_addr, &wrappedkey, &wrappedkeylen); xfree (prompt); @@ -880,7 +1094,10 @@ receive_seckey_from_agent (ctrl_t ctrl, gcry_cipher_hd_t cipherhd, err = gcry_sexp_sscan (&s_skey, NULL, key, realkeylen); if (!err) { - err = transfer_format_to_openpgp (s_skey, pk); + if (cleartext) + err = cleartext_secret_key_to_openpgp (s_skey, pk); + else + err = transfer_format_to_openpgp (s_skey, pk); gcry_sexp_release (s_skey); } @@ -1276,7 +1493,8 @@ do_export_stream (ctrl_t ctrl, iobuf_t out, strlist_t users, int secret, } else if (!err) { - err = receive_seckey_from_agent (ctrl, cipherhd, &cache_nonce, + err = receive_seckey_from_agent (ctrl, cipherhd, + 0, &cache_nonce, hexgrip, pk); if (err) { diff --git a/g10/keygen.c b/g10/keygen.c index b8e4cb8..afb13e0 100644 --- a/g10/keygen.c +++ b/g10/keygen.c @@ -4075,7 +4075,7 @@ card_store_key_with_backup (ctrl_t ctrl, PKT_public_key *sub_psk, goto leave; } - err = receive_seckey_from_agent (ctrl, cipherhd, &cache_nonce, hexgrip, sk); + err = receive_seckey_from_agent (ctrl, cipherhd, 0, &cache_nonce, hexgrip, sk); if (err) { log_error ("error getting secret key from agent: %s\n", gpg_strerror (err)); diff --git a/g10/main.h b/g10/main.h index bda0bc1..7b716ff 100644 --- a/g10/main.h +++ b/g10/main.h @@ -389,6 +389,7 @@ gpg_error_t export_pubkey_buffer (ctrl_t ctrl, const char *keyspec, void **r_data, size_t *r_datalen); gpg_error_t receive_seckey_from_agent (ctrl_t ctrl, gcry_cipher_hd_t cipherhd, + int cleartext, char **cache_nonce_addr, const char *hexgrip, PKT_public_key *pk); -- 2.8.1 From wk at gnupg.org Fri Jun 10 21:54:07 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 10 Jun 2016 21:54:07 +0200 Subject: gpgme: potential minor memory leaks in tests under gpgme/test/gpg In-Reply-To: <8CA79C4C24A06A48A11BA99F564B78ED37C51E4E@xm-mbx-05-prod> (Seiya Kawashima's message of "Fri, 10 Jun 2016 15:17:51 +0000") References: <8CA79C4C24A06A48A11BA99F564B78ED37C51E4E@xm-mbx-05-prod> Message-ID: <8737okakgw.fsf@wheatstone.g10code.de> On Fri, 10 Jun 2016 17:17, skawashima at uchicago.edu said: > If they are not memory leaks or they are already fixed, please disregard the email. Technically correct but these are one time allocations and we don't care to release them. > free((char *)cipher_1_asc); (No need to cast here becuase free takes a void *.). > Keep up the great work. Thanks. And also thanks for looking at the code. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ From wk at gnupg.org Sat Jun 11 20:48:11 2016 From: wk at gnupg.org (Werner Koch) Date: Sat, 11 Jun 2016 20:48:11 +0200 Subject: non-interactive export of secret keys stored in cleartext In-Reply-To: <1465589736-8267-1-git-send-email-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 10 Jun 2016 16:15:32 -0400") References: <87y46d9jwp.fsf@alice.fifthhorseman.net> <1465589736-8267-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <87lh2b8sus.fsf@wheatstone.g10code.de> On Fri, 10 Jun 2016 22:15, dkg at fifthhorseman.net said: > A shorter (squashed) series of changesets follows that address the > ability to export cleartext secret key material when it is stored in > the clear. Many thanks. I applied them. One question however: commit c41c46fa84cabbed74a13ded51fc3a817a919367 g10: Export cleartext keys as cleartext [...] * tests/openpgp/export.test: for secret keys that are stored in cleartext, test should try to export without pinentry interaction. Justus recently improved these test and your patch seems to remove most of the new code. Justus: Can you please look at the changes and remember to re-add the new tests when porting them to gpgscm if needed. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ From dkg at fifthhorseman.net Sun Jun 12 03:35:35 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 11 Jun 2016 21:35:35 -0400 Subject: non-interactive export of secret keys stored in cleartext In-Reply-To: <87lh2b8sus.fsf@wheatstone.g10code.de> References: <87y46d9jwp.fsf@alice.fifthhorseman.net> <1465589736-8267-1-git-send-email-dkg@fifthhorseman.net> <87lh2b8sus.fsf@wheatstone.g10code.de> Message-ID: <87wplv89zs.fsf@alice.fifthhorseman.net> On Sat 2016-06-11 14:48:11 -0400, Werner Koch wrote: > Many thanks. I applied them. Thanks! > One question however: > > commit c41c46fa84cabbed74a13ded51fc3a817a919367 > > g10: Export cleartext keys as cleartext > > [...] > * tests/openpgp/export.test: for secret keys that are stored in > cleartext, test should try to export without pinentry interaction. > > Justus recently improved these test and your patch seems to remove most > of the new code. I think Justus actually *created* this test recently, and the new test included a lot of stuff to provide passphrases for exporting cleartext secret key material (as a way of documenting current behavior). c41c46fa84cabbed74a13ded51fc3a817a919367 removed a bunch of that code code -- it isn't necessary any longer, and you should see that the pinentry data is completely consumed as expected. > Justus: Can you please look at the changes and remember to re-add the > new tests when porting them to gpgscm if needed. Thanks for the work on the test suite, Justus! Please let me know if you have any suggestions or preferences for my edits to the tests. Regards, --dkg From gniibe at fsij.org Mon Jun 13 04:34:52 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 13 Jun 2016 11:34:52 +0900 Subject: trustdb locking In-Reply-To: <575924FC.70505@fsij.org> References: <575924FC.70505@fsij.org> Message-ID: <575E1BCC.6000806@fsij.org> Hello, We have this bug in 1.4, 2.0, and 2.1. My intention is to fix in 2.1 and backporting fix to 1.4 and 2.0. On 06/09/2016 05:12 PM, NIIBE Yutaka wrote: > In the issue 1675, we handle trustdb locking: > https://bugs.gnupg.org/gnupg/issue1675 > > I had identified a race condition for creation of trustdb.gpg. This > was fixed last year. However, the problem of trustdb corruption has > not gone yet. [...] > (2) BEING ANALYZED > The serialization of newly creating hash table in the function > create_hashtable (tdbio.c). <--- I think this is the issue now. > > When two processes race for the position of end of file by lseek > (db_fd, 0, SEEK_END), it might result corrupted trustdb. A > process which comes later will also create a record for hash table > at the end of file at later time, but the block will be > overwritten by another process which comes first. While this is a race condition (WRITE vs. WRITE), I think I finally identified another race condition (WRITE vs. READ) which can reproduce same result of issue1675. In 2.1, I managed to reproduce it by following steps. (0) We will use the file SHA256SUMS.gpg and SHA256SUMS to verify the signature as the report of issue1675 does. Get the files from: http://archive.ubuntu.com/ubuntu/dists/precise/main/installer-amd64/current/images (Any signature works, here we use same files as the report) (1) Make a temporal homedir environment. $ mkdir /tmp/gpghome; chmod og-rwx /tmp/gpghome (2) Prepare a key for verification (any key works, here we use same key as the report). $ gpg2-1-12 --homedir=/tmp/gpghome --keyserver=sks-keyservers.net --recv-key 40976EAF437D05B5 Then, we have pubring.kbx and trustdb.gpg of 1200-byte. Here, trustdb.gpg is composed by version record and hash table. To reproduce the bug, we setup artificial situation. $ rm /tmp/gpghome/trustdb.gpg $ mv /tmp/gpghome/pubring.kbx /tmp/gpghome/pubring.kbx.bak (3) Let GPG make a VERSION record-only of trustdb.gpg by -k command with no-key. $ gpg2-1-12 --homedir=/tmp/gpghome -k Then, restore the public key $ mv /tmp/gpghome/pubring.kbx.bak /tmp/gpghome/pubring.kbx (4) Now, it has 40-byte trustdb.gpg, which is VERSION record only. ls -l /tmp/gpghome shows like: -rw-r--r-- 1 gniibe gniibe 10059 Jun 13 11:04 pubring.kbx -rw------- 1 gniibe gniibe 40 Jun 13 11:06 trustdb.gpg (5) In this situation invoke GPG under GDB. $ gdb /path-to/gpg2-1-12 Then, let GDB have a break point at write_cache_item, and run GPG. (gdb) break write_cache_item (gdb) run --homedir=/tmp/gpghome --verify SHA256SUMS.gpg SHA256SUMS Then, we see: Breakpoint 1, write_cache_item (r=r at entry=0xbf380) at ../../gnupg/g10/tdbio.c:201 201 if (lseek (db_fd, r->recno * TRUST_RECORD_LEN, SEEK_SET) == -1) (gdb) list 196 write_cache_item (CACHE_CTRL r) 197 { 198 gpg_error_t err; 199 int n; 200 201 if (lseek (db_fd, r->recno * TRUST_RECORD_LEN, SEEK_SET) == -1) 202 { 203 err = gpg_error_from_syserror (); 204 log_error (_("trustdb rec %lu: lseek failed: %s\n"), 205 r->recno, strerror (errno)); (gdb) print *r $67 = {next = 0xbf348, flags = {used = 1, dirty = 1}, recno = 0, data = "\001gpg\003\003\001\005\001\002\000\000W^\025\032", '\000' , "\001"} The version record is now updating. Let GDB continue the execution of GPG. (gdb) cont Continuing. Breakpoint 1, write_cache_item (r=r at entry=0xbf348) at ../../gnupg/g10/tdbio.c:201 201 if (lseek (db_fd, r->recno * TRUST_RECORD_LEN, SEEK_SET) == -1) (gdb) print *r $69 = {next = 0xbf310, flags = {used = 1, dirty = 1}, recno = 29, data = "\n", '\000' } After the update of the version record, now GPG is writing to the hash table. Note that the order of writing data to disk. It updates the version record first, then, hash table. When let it go further step, it will be more clear. (gdb) cont Continuing. Breakpoint 3, write_cache_item (r=r at entry=0xbf310) at ../../gnupg/g10/tdbio.c:201 201 if (lseek (db_fd, r->recno * TRUST_RECORD_LEN, SEEK_SET) == -1) (gdb) print *r $71 = {next = 0xc7f00, flags = {used = 1, dirty = 1}, recno = 28, data = "\n", '\000' } The RECNO is, 0 for the version record, then 1...29 for the hash table. It goes from 29 to 1. Here (after the write to the version record), we keep stopping the GPG process, and we invoke another GPG command. (6) In another terminal, invoke GPG, then, we got the error. $ gpg2-1-12 --homedir=/tmp/gpghome --verify SHA256SUMS.gpg SHA256SUMS gpg: Signature made Tue 24 Apr 2012 04:52:09 AM JST using DSA key ID 437D05B5 gpg: 12: read expected rec type 10, got 0 gpg: lookup_hashtable failed: Trust DB error gpg: trustdb: searching trust record failed: Trust DB error gpg: Error: The trustdb is corrupted. gpg: You may try to re-create the trustdb using the commands: gpg: cd ~/.gnupg gpg: gpg --export-ownertrust > otrust.tmp gpg: rm trustdb.gpg gpg: gpg --import-ownertrust < otrust.tmp gpg: If that does not work, please consult the manual It fails because the hash table is currently being written by the GPG process under GDB (holding the write lock). -- From skawashima at uchicago.edu Mon Jun 13 17:19:06 2016 From: skawashima at uchicago.edu (Seiya Kawashima) Date: Mon, 13 Jun 2016 15:19:06 +0000 Subject: gpgme: gpgme_op_export() with non default keyserver Message-ID: <8CA79C4C24A06A48A11BA99F564B78ED37C521A6@xm-mbx-05-prod> Hi, I've been trying to modify how GPGME_EXPORT_MODE_EXTERN of gpgme_op_export() works with non default keyserver. And I hope that it would be useful for other users as well. I've cloned GPGME via git and the commit is 77d149e8614c381458e07808a7930ce3fb92cdc3 and the date is Wed Jun 8 18:06:24 2016 +0200. According to the documentation at https://www.gnupg.org/documentation/manuals/gpgme/Exporting-Keys.html#Exporting-Keys, GPGME_EXPORT_MODE_EXTERN of gpgme_op_export() sends keys to the default keyserver via "--send-keys" GPG option. To send keys to a non default keyserver, what I need to do is support "--keyserver" GPG option along with "--send-keys" GPG option in GPGME. For this purpose, I've modified export_common() in engine-gpg.c:1821 to have a keyserver via an environment variable named "GPG_KEYSERVER" as follows. I was wondering if using environment variables is the right way to support more GPG options in GPGME than currently GPGME supports. diff --git a/src/engine-gpg.c b/src/engine-gpg.c index 9fa9994..c2ad3e9 100644 --- a/src/engine-gpg.c +++ b/src/engine-gpg.c @@ -1835,6 +1835,15 @@ export_common (engine_gpg_t gpg, gpgme_export_mode_t mode, ; else if ((mode & GPGME_EXPORT_MODE_EXTERN)) { + char *tmp; + _gpgme_getenv ("GPG_KEYSERVER", &tmp); + if (tmp) + { + err = add_arg (gpg, "--keyserver"); + if (!err) + add_arg (gpg, tmp); + free(tmp); + } err = add_arg (gpg, "--send-keys"); } else Thank you Seiya From dkg at fifthhorseman.net Mon Jun 13 22:35:00 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 13 Jun 2016 16:35:00 -0400 Subject: [LIBGPG-ERROR PATCH] refer to --with-libgpg-error-prefix, instead of --with-gpg-error-prefix In-Reply-To: <1454956291-3542-1-git-send-email-dkg@fifthhorseman.net> References: <1454956291-3542-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <8737og3k0b.fsf@alice.fifthhorseman.net> On Mon 2016-02-08 13:31:31 -0500, Daniel Kahn Gillmor wrote: > * src/gpg-error.m4: announce the preferred form of configuration, > since --with-gpg-error-prefix is deprecated earlier in the file. > --- > src/gpg-error.m4 | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/gpg-error.m4 b/src/gpg-error.m4 > index 1661204..60c88d8 100644 > --- a/src/gpg-error.m4 > +++ b/src/gpg-error.m4 > @@ -100,7 +100,7 @@ AC_DEFUN([AM_PATH_GPG_ERROR], > *** The config script $GPG_ERROR_CONFIG was > *** built for $gpg_error_config_host and thus may not match the > *** used host $host. > -*** You may want to use the configure option --with-gpg-error-prefix > +*** You may want to use the configure option --with-libgpg-error-prefix > *** to specify a matching config script or use \$SYSROOT. > ***]]) > gpg_config_script_warn="$gpg_config_script_warn libgpg-error" > -- Is there a reason to avoid applying this upstream? In case it helps: Signed-off-by: Daniel Kahn Gillmor :) Regards, --dkg From gniibe at fsij.org Tue Jun 14 02:57:40 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 14 Jun 2016 09:57:40 +0900 Subject: [PATCH] create_hashtable together with version_record (was: trustdb locking) In-Reply-To: <575E1BCC.6000806@fsij.org> References: <575924FC.70505@fsij.org> <575E1BCC.6000806@fsij.org> Message-ID: <575F5684.8030708@fsij.org> On 06/13/2016 11:34 AM, NIIBE Yutaka wrote: > We have this bug in 1.4, 2.0, and 2.1. My intention is to fix > in 2.1 and backporting fix to 1.4 and 2.0. Well, fixing all serialization problems of trustdb access requires major change. I think that: If we rely on the fact that write(2) is atomic, the size of records should be 64 (or some number which is power of 2). Currently, the size is 40, so, I think that in some specific cases around a boundary of a block, it won't be atomic. Fine grained lock requires many change of the code. Easier way would be introducing something like a giant lock, which allows the access to trustdb by a single process. Many use-cases of GPG are interactive. Especially, trustdb write access is rare, and it is happened in an interactive use mainly. Because of that, fixing all serialization problems wouldn't be high priority, perhaps. Even so, the situation of the issue 1675 is important. It occurs when a user only does --verify (it's not the intentional modification of trustdb, trust or validity). It is about the first time access to trustdb, and it might result not only a failure by another process (demonstrated by my email yesterday), but also a corruption of trustdb. Since I believe that it is so important to be fixed soon, I propose following patch (for 2.1). This patch moves create_hashtable into create_version_record. Thus, initial creation of trustdb will be always 1200-byte with version record and hash table. Since initial creation of trustdb is already serialized properly, it fixes a problem of the serialization of trustdb access in this particular case. diff --git a/g10/tdbio.c b/g10/tdbio.c index a414709..9e35fcc 100644 --- a/g10/tdbio.c +++ b/g10/tdbio.c @@ -119,6 +119,7 @@ static int in_transaction; static void open_db (void); +static void create_hashtable (TRUSTREC *vr, int type); @@ -582,8 +583,13 @@ create_version_record (void) rec.rectype = RECTYPE_VER; rec.recnum = 0; rc = tdbio_write_record (&rec); + if (!rc) tdbio_sync (); + + if (!rc) + create_hashtable (&rec, 0); + return rc; } @@ -957,8 +963,6 @@ get_trusthashrec(void) if (rc) log_fatal (_("%s: error reading version record: %s\n"), db_name, gpg_strerror (rc) ); - if (!vr.r.ver.trusthashtbl) - create_hashtable (&vr, 0); trusthashtbl = vr.r.ver.trusthashtbl; } -- From gniibe at fsij.org Tue Jun 14 03:18:58 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 14 Jun 2016 10:18:58 +0900 Subject: [LIBGPG-ERROR PATCH] estream read/write access Message-ID: <575F5B82.8070301@fsij.org> Hello, I'm looking at the issue 2371: https://bugs.gnupg.org/gnupg/issue2371 I think that this bug (in libgpg-error for gpg 2.1) should be fixed soon. This bug is revealed by the change of GPG: https://lists.gnupg.org/pipermail/gnupg-devel/2016-April/031001.html commit 12af2630cf4d1a39179179925fac8f2cce7504ff Author: Justus Winter Date: Fri Apr 8 19:21:12 2016 +0200 common: Add support for the new extended private key format. * agent/findkey.c (write_extended_private_key): New function. (agent_write_private_key): Detect if an existing file is in extended format and update the key within if it is. (read_key_file): Handle the new format. No, this change itself is valid and nothing wrong. However, this is the first instance for estream to do READ and WRITE (in the history of the code > 10 years :-). In the function agent_write_private_key, the pattern is: es_fopen es_fread es_fseek es_fwrite which should work well, but if results core dump by assertion failure in the function es_flush of libgpg-error. Here is a fix. diff --git a/src/estream.c b/src/estream.c index 499cc75..14576d3 100644 --- a/src/estream.c +++ b/src/estream.c @@ -2671,6 +2671,7 @@ es_writen (estream_t _GPGRT__RESTRICT stream, else goto out; } + stream->flags.writing = 1; } } @@ -2693,9 +2694,6 @@ es_writen (estream_t _GPGRT__RESTRICT stream, if (bytes_written) *bytes_written = data_written; - if (data_written) - if (!stream->flags.writing) - stream->flags.writing = 1; return err; } -- From bernhard at intevation.de Tue Jun 14 11:20:23 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 14 Jun 2016 11:20:23 +0200 Subject: python bindings for gpgme In-Reply-To: <20160606152047.10010.70223@thinkbox.jade-hamburg.de> References: <201605311439.22496.bernhard@intevation.de> <201606011754.43709.bernhard@intevation.de> <20160606152047.10010.70223@thinkbox.jade-hamburg.de> Message-ID: <201606141120.27890.bernhard@intevation.de> Hi Justus, hi all! Am Montag, 6. Juni 2016 17:20:47 schrieb Justus Winter: > Quoting Bernhard Reiter (2016-06-01 17:54:43) > > your evaluation looks a bit biased because you are defending > > what you have currently implemented. > > What else would I be defending? My hope would be to be open for new aspects and viewpoints that you have not considered previously. > It defies your argument that using SWIG only pays off if you create > bindings for more than one language, which can only be the case if > there is a language-independend part to it, which there isn't. I'll don't find the arguments I've read conclusive, but maybe SWIG has changed over the years, so I'll take your word for its fitness. > I'm thinking of providing joined operations, > op_decrypt_verify+op_decrypt_result+op_verify_result => > decrypt_verify. So there would be a second set of operations. If possible good APIs offer one good way of doing things. > > We should look at the API ideas of pygpgme, I guess. > > What ideas? I'm tired of "make it more pythonic" with noone having a > clear idea what that actually means. I fear that it means something > different for everyone. Acceptance within python programmers is an important goal and "being pythonic" is a major keyword in reaching this goal. So looking at pygpgme, and its usage can give us ideas there. We may also check who is using pyme and pygpgme already. > So until someone here actually provides a > constructive critique of the current pyme API, I'm going to sand-off > the edges that would annoy me the most. Specific criticism that (in some form) came up so far: a) ugly names with "op_". b) two ways of doing things where one operation would be enough Best Regards, Bernhard -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Tue Jun 14 11:25:11 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 14 Jun 2016 11:25:11 +0200 Subject: python bindings for gpgme In-Reply-To: <20160607171032.GC81949@adversary.org> References: <201605311439.22496.bernhard@intevation.de> <20160606152047.10010.70223@thinkbox.jade-hamburg.de> <20160607171032.GC81949@adversary.org> Message-ID: <201606141125.11413.bernhard@intevation.de> Am Dienstag, 7. Juni 2016 19:10:32 schrieb Ben McGinnes: > Whereas my view of remaking things with Python following an overhaul > of GPGME was not so much "make it more Pythonic" (though if that > happened as well I wouldn't object) as much as it was "make it more > modular" and "make it kind of REST-like" (with all the relevant > caveats). The overal goal, as far as I can see, is to get acceptance within python programming people first. Will modularity and restfullness help here? I have no clear conception of what it will mean for the python bindings of gpgme. > For example; using JSON for feeding in data types and receiving the > responses. ?I wanted something which would be familiar enough to all > those web-weenies, Javanauts, Node-velopers and Mono-thoughts; at > least in relation to the data types they fed it and received from it > that they'd have to actually want to code an insecure thing to do > anything else. While I like json over more complex data types, I wouldn't expect it from a python-gpgme binding right away. -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Tue Jun 14 11:46:02 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 14 Jun 2016 11:46:02 +0200 Subject: Request for Discussion: new/PubKeyDistributionConcept/FallbackServer In-Reply-To: <201605041751.51371.bernhard@intevation.de> References: <201605041751.51371.bernhard@intevation.de> Message-ID: <201606141146.06585.bernhard@intevation.de> Hi, during the EasyGpg contract we are looking for a way to find a single OpenPGP pubkey, so we can automate sending an encrypted email better. Feedback is welcome, I like to discuss the ideas here on gnupg-devel@ and aim to summarize the discussion on the wiki later. Am Mittwoch, 4. Mai 2016 17:51:46 schrieb Bernhard Reiter: > there is a new wiki page which starts to document some of the design > reasoning behind a proposed new way how to distribute, find > and (somewhat) validate public OpenPGP keys. > > While it is not complete nor polished, > you have early access to be able to comment: I've just renamed the page to https://wiki.gnupg.org/EasyGpg2016/PubkeyDistributionConcept and move the discussion about a fallback server to a subpage https://wiki.gnupg.org/EasyGpg2016/PubkeyDistributionConcept/FallbackServer I have not yet included some of the discussion of the WKD from this list, though the general ideas should be in there. Personally my current mindset is: a) the msp first approach is a good compromise in order of getting more users. It is distinct enough from a central "validating keyserver" framework and communication history has a resonable chance to catch attacs by MSPs. b) a pubkey from a wkd should significantly add to the "validity" level c) having a fallback server is better than not having one, so that many people can make the new user experience right away. However we must have a good plan moving users pubkeys to the MSPs. This is easier if we have more users, because we can use the number and the users to approach their MSPs. Best Regards, Bernhard -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From neal at walfield.org Tue Jun 14 14:25:20 2016 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 14 Jun 2016 14:25:20 +0200 Subject: Request for Discussion: new/PubKeyDistributionConcept/FallbackServer In-Reply-To: <201606141146.06585.bernhard@intevation.de> References: <201605041751.51371.bernhard@intevation.de> <201606141146.06585.bernhard@intevation.de> Message-ID: <87eg80q7nz.wl-neal@walfield.org> On Tue, 14 Jun 2016 11:46:02 +0200, Bernhard Reiter wrote: > during the EasyGpg contract we are looking for a way > to find a single OpenPGP pubkey, so we can automate > sending an encrypted email better. > > ... > Personally my current mindset is: > a) the msp first approach is a good compromise in order of getting more users. > It is distinct enough from a central "validating keyserver" framework and > communication history has a resonable chance to catch attacs by MSPs. > b) a pubkey from a wkd should significantly add to the "validity" level > c) having a fallback server is better than not having one, so that many > people can make the new user experience right away. However we must > have a good plan moving users pubkeys to the MSPs. This is easier > if we have more users, because we can use the number and the users to > approach their MSPs. Before I comment: what an MSP? What does "significantly add to `validity level' mean? Thanks, :) Neal From bernhard at intevation.de Tue Jun 14 14:47:16 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 14 Jun 2016 14:47:16 +0200 Subject: Request for Discussion: new/PubKeyDistributionConcept/FallbackServer In-Reply-To: <87eg80q7nz.wl-neal@walfield.org> References: <201605041751.51371.bernhard@intevation.de> <201606141146.06585.bernhard@intevation.de> <87eg80q7nz.wl-neal@walfield.org> Message-ID: <201606141447.21583.bernhard@intevation.de> Am Dienstag, 14. Juni 2016 14:25:20 schrieb Neal H. Walfield: > Before I comment: what an MSP? MSP: mail service provider (I've just taken the abbreviation from the wiki page. It makes sense to read it first anyway.) > What does "significantly add to `validity level' mean? Getting a pubkey from a MSP operated WKD should add a medium amount to the level of "how much do I believe that this pubkey belongs the owner of the email address that I am looking for". Medium because it will have to be a lot more than the contribution I get from having communicated with pubkey A and user U once or a couple of time. Only medium because other sources of validity will be necessary to detect malicious behaviour, so they must be able to get over medium for these scenarios. This mainly documents my mental model how a good and secure user experience can be constructed in the future. I know that Werner's model is different. We need a way to get this exposed and talked about. Best, Bernhard -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From neal at walfield.org Tue Jun 14 15:29:09 2016 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 14 Jun 2016 15:29:09 +0200 Subject: Request for Discussion: new/PubKeyDistributionConcept/FallbackServer In-Reply-To: <201606141447.21583.bernhard@intevation.de> References: <201605041751.51371.bernhard@intevation.de> <201606141146.06585.bernhard@intevation.de> <87eg80q7nz.wl-neal@walfield.org> <201606141447.21583.bernhard@intevation.de> Message-ID: <87d1njrja2.wl-neal@walfield.org> On Tue, 14 Jun 2016 14:47:16 +0200, Bernhard Reiter wrote: > Am Dienstag, 14. Juni 2016 14:25:20 schrieb Neal H. Walfield: > > Before I comment: what an MSP? > > MSP: mail service provider > > (I've just taken the abbreviation from the wiki page. > It makes sense to read it first anyway.) > > > What does "significantly add to `validity level' mean? > > Getting a pubkey from a MSP operated WKD should add a medium amount > to the level of "how much do I believe that this pubkey belongs > the owner of the email address that I am looking for". > > Medium because it will have to be a lot more than the contribution I get from > having communicated with pubkey A and user U once or a couple of time. > Only medium because other sources of validity will be necessary to detect > malicious behaviour, so they must be able to get over medium for these > scenarios. > > This mainly documents my mental model how a good and secure user experience > can be constructed in the future. I know that Werner's model is different. > We need a way to get this exposed and talked about. Please explain to me how a WKD being run by an MSP is not almost the same thing as using key escrow? Let's say Alice's MSP runs WKD? I look up her key using WKD, and her MSP returns the public part of a fresh key. When I send her an email, the MSP reencrypts the message and neither I nor Alice is any wiser. The only defense against this is if Alice anonymously and regularly checks that the WKD server returns the correct public key, which isn't a terribly good defense. So, no, WKD is not add a "medium" amount of validity to the key. In fact, using a key server and guessing which key is right is probably better than this scheme, because it uses a different network path, which means your MSP couldn't be compromised by an NSL! Note: it would be possible to save this scheme if we augmented WKD with something like Coniks [1], but Werner doesn't like this, because it adds complexity and will take too much time to implement and we need to ship in the near future. [1] https://coniks.cs.princeton.edu/ :) Neal From wk at gnupg.org Tue Jun 14 17:14:27 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 14 Jun 2016 17:14:27 +0200 Subject: Request for Discussion: new/PubKeyDistributionConcept/FallbackServer In-Reply-To: <87d1njrja2.wl-neal@walfield.org> (Neal H. Walfield's message of "Tue, 14 Jun 2016 15:29:09 +0200") References: <201605041751.51371.bernhard@intevation.de> <201606141146.06585.bernhard@intevation.de> <87eg80q7nz.wl-neal@walfield.org> <201606141447.21583.bernhard@intevation.de> <87d1njrja2.wl-neal@walfield.org> Message-ID: <87bn33vm3w.fsf@wheatstone.g10code.de> On Tue, 14 Jun 2016 15:29, neal at walfield.org said: > So, no, WKD is not add a "medium" amount of validity to the key. In I fully agree. > Note: it would be possible to save this scheme if we augmented WKD > with something like Coniks [1], but Werner doesn't like this, because > it adds complexity and will take too much time to implement and we Nope, I like it but know how hard it will be to deploy certificate transparency for offline protocols out of the blue. First things first: we need to tackle the problem that keyservers are not anymore useful to find the key for a given mail address. Thus we need to _deploy_ a system for reliable key discovery. Then, while the TLAs are busy locating budgets for mass intrusion into computers, we start to deploy a monitoring system to detect malicious mail providers. And we need to hope that on the political edge data sabotage by TLAs will be prevented. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ From neal at walfield.org Tue Jun 14 17:34:39 2016 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 14 Jun 2016 17:34:39 +0200 Subject: Request for Discussion: new/PubKeyDistributionConcept/FallbackServer In-Reply-To: <87bn33vm3w.fsf@wheatstone.g10code.de> References: <201605041751.51371.bernhard@intevation.de> <201606141146.06585.bernhard@intevation.de> <87eg80q7nz.wl-neal@walfield.org> <201606141447.21583.bernhard@intevation.de> <87d1njrja2.wl-neal@walfield.org> <87bn33vm3w.fsf@wheatstone.g10code.de> Message-ID: <87bn33rdgw.wl-neal@walfield.org> On Tue, 14 Jun 2016 17:14:27 +0200, Werner Koch wrote: > > On Tue, 14 Jun 2016 15:29, neal at walfield.org said: > > > So, no, WKD is not add a "medium" amount of validity to the key. In > > I fully agree. > > > Note: it would be possible to save this scheme if we augmented WKD > > with something like Coniks [1], but Werner doesn't like this, because > > it adds complexity and will take too much time to implement and we > > Nope, I like it but know how hard it will be to deploy certificate > transparency for offline protocols out of the blue. I think that is what I said: you don't like it *because* of the required effort. > First things first: we need to tackle the problem that keyservers are > not anymore useful to find the key for a given mail address. Thus we > need to _deploy_ a system for reliable key discovery. Then, while the > TLAs are busy locating budgets for mass intrusion into computers, we > start to deploy a monitoring system to detect malicious mail providers. > And we need to hope that on the political edge data sabotage by TLAs > will be prevented. This is where we disagree. I think it will be harder to get MSPs to upgrade, because they will say something like: hey, we already have the solution that you wanted! And, this new one only adds additional complexity, but it increases their liability, because it can be proven that they either didn't take care of their systems or they were malicious. See google's fight to get CAs to implement certificate transparency. :) Neal From wk at gnupg.org Tue Jun 14 20:13:57 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 14 Jun 2016 20:13:57 +0200 Subject: Request for Discussion: new/PubKeyDistributionConcept/FallbackServer In-Reply-To: <87bn33rdgw.wl-neal@walfield.org> (Neal H. Walfield's message of "Tue, 14 Jun 2016 17:34:39 +0200") References: <201605041751.51371.bernhard@intevation.de> <201606141146.06585.bernhard@intevation.de> <87eg80q7nz.wl-neal@walfield.org> <201606141447.21583.bernhard@intevation.de> <87d1njrja2.wl-neal@walfield.org> <87bn33vm3w.fsf@wheatstone.g10code.de> <87bn33rdgw.wl-neal@walfield.org> Message-ID: <87k2hrtz8a.fsf@wheatstone.g10code.de> On Tue, 14 Jun 2016 17:34, neal at walfield.org said: > This is where we disagree. I think it will be harder to get MSPs to > upgrade, because they will say something like: hey, we already have > the solution that you wanted! And, this new one only adds additional The problem is that CONIKS is an entirely new system with many open questions. What they have is a prototype but zero experience with deployment. Further, CONIKS is an entirely new service to deploy which requires new infrastructure (servers, HSMs, failure procedures, and so on) and requires the involvement of several departments at an ISP. I got from a large provider a quote of 200kEUR of internal costs for setting up that simple and standard Web Key Directory method. How much do you think will it need to deploy an entirely new service which has only a Java prototype implementation right now and is missing the parts of the protocol. > malicious. See google's fight to get CAs to implement certificate > transparency. Well, if you want to call a heavyweight against a flyweight a fight ;-) Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ From neal at walfield.org Tue Jun 14 20:29:54 2016 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 14 Jun 2016 20:29:54 +0200 Subject: Request for Discussion: new/PubKeyDistributionConcept/FallbackServer In-Reply-To: <87k2hrtz8a.fsf@wheatstone.g10code.de> References: <201605041751.51371.bernhard@intevation.de> <201606141146.06585.bernhard@intevation.de> <87eg80q7nz.wl-neal@walfield.org> <201606141447.21583.bernhard@intevation.de> <87d1njrja2.wl-neal@walfield.org> <87bn33vm3w.fsf@wheatstone.g10code.de> <87bn33rdgw.wl-neal@walfield.org> <87k2hrtz8a.fsf@wheatstone.g10code.de> Message-ID: <877fdrr5ct.wl-neal@walfield.org> On Tue, 14 Jun 2016 20:13:57 +0200, Werner Koch wrote: > On Tue, 14 Jun 2016 17:34, neal at walfield.org said: > > > This is where we disagree. I think it will be harder to get MSPs to > > upgrade, because they will say something like: hey, we already have > > the solution that you wanted! And, this new one only adds additional > > The problem is that CONIKS is an entirely new system with many open > questions. What they have is a prototype but zero experience with > deployment. FWIW, Google began to work on Coniks in May 2015. https://lists.cs.princeton.edu/mailman/private/coniks/2015-May/000000.html > Further, CONIKS is an entirely new service to deploy which > requires new infrastructure (servers, HSMs, failure procedures, and so > on) and requires the involvement of several departments at an ISP. > > I got from a large provider a quote of 200kEUR of internal costs for > setting up that simple and standard Web Key Directory method. How much > do you think will it need to deploy an entirely new service which has > only a Java prototype implementation right now and is missing the parts > of the protocol. Sure. I don't dispute that the implementation is a lot of work. I just speculate that the human side is more work and doubly so when trying to convince ISPs to do an upgrade that increases their liability. :) Neal From wk at gnupg.org Tue Jun 14 20:33:24 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 14 Jun 2016 20:33:24 +0200 Subject: [PATCH] create_hashtable together with version_record In-Reply-To: <575F5684.8030708@fsij.org> (NIIBE Yutaka's message of "Tue, 14 Jun 2016 09:57:40 +0900") References: <575924FC.70505@fsij.org> <575E1BCC.6000806@fsij.org> <575F5684.8030708@fsij.org> Message-ID: <878ty7tybv.fsf@wheatstone.g10code.de> On Tue, 14 Jun 2016 02:57, gniibe at fsij.org said: > Fine grained lock requires many change of the code. That is not worth it. There is anyway the idea to eventually implement a daemon based key directly which would then also keep meta information like the trustdb. But not for 2.2. > Since I believe that it is so important to be fixed soon, I propose > following patch (for 2.1). That patch looks fine because it is prettuy conservative. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ From wk at gnupg.org Tue Jun 14 20:36:53 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 14 Jun 2016 20:36:53 +0200 Subject: Request for Discussion: new/PubKeyDistributionConcept/FallbackServer In-Reply-To: <877fdrr5ct.wl-neal@walfield.org> (Neal H. Walfield's message of "Tue, 14 Jun 2016 20:29:54 +0200") References: <201605041751.51371.bernhard@intevation.de> <201606141146.06585.bernhard@intevation.de> <87eg80q7nz.wl-neal@walfield.org> <201606141447.21583.bernhard@intevation.de> <87d1njrja2.wl-neal@walfield.org> <87bn33vm3w.fsf@wheatstone.g10code.de> <87bn33rdgw.wl-neal@walfield.org> <87k2hrtz8a.fsf@wheatstone.g10code.de> <877fdrr5ct.wl-neal@walfield.org> Message-ID: <8737ofty62.fsf@wheatstone.g10code.de> On Tue, 14 Jun 2016 20:29, neal at walfield.org said: > https://lists.cs.princeton.edu/mailman/private/coniks/2015-May/000000.html Huh? Subscriber only archive. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ From neal at walfield.org Tue Jun 14 21:28:02 2016 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 14 Jun 2016 21:28:02 +0200 Subject: Request for Discussion: new/PubKeyDistributionConcept/FallbackServer In-Reply-To: <8737ofty62.fsf@wheatstone.g10code.de> References: <201605041751.51371.bernhard@intevation.de> <201606141146.06585.bernhard@intevation.de> <87eg80q7nz.wl-neal@walfield.org> <201606141447.21583.bernhard@intevation.de> <87d1njrja2.wl-neal@walfield.org> <87bn33vm3w.fsf@wheatstone.g10code.de> <87bn33rdgw.wl-neal@walfield.org> <87k2hrtz8a.fsf@wheatstone.g10code.de> <877fdrr5ct.wl-neal@walfield.org> <8737ofty62.fsf@wheatstone.g10code.de> Message-ID: <8760tbr2nx.wl-neal@walfield.org> On Tue, 14 Jun 2016 20:36:53 +0200, Werner Koch wrote: > > On Tue, 14 Jun 2016 20:29, neal at walfield.org said: > > > https://lists.cs.princeton.edu/mailman/private/coniks/2015-May/000000.html > > Huh? Subscriber only archive. Since the message is hardly private and it is easy enough to get at it, here it is: [coniks] Hello from Google Gary Belvin gdb at google.com Mon May 4 13:26:53 EDT 2015 This is just a friendly introduction message. I'm Gary, I'm on the Google security team, building CONIKS as part of Google's End to End project. https://github.com/google/end-to-end The hope is to have an open source docker version of CONIKS at some point so other people can participate easily at-scale. Handling identities for domains that don't have a CONIKS server, and properly transitioning trust when domains go up and down are open questions that need work. Best, Gary Belvin From gniibe at fsij.org Wed Jun 15 02:15:28 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 15 Jun 2016 09:15:28 +0900 Subject: [PATCH] create_hashtable together with version_record In-Reply-To: <878ty7tybv.fsf@wheatstone.g10code.de> References: <575924FC.70505@fsij.org> <575E1BCC.6000806@fsij.org> <575F5684.8030708@fsij.org> <878ty7tybv.fsf@wheatstone.g10code.de> Message-ID: <57609E20.8020302@fsij.org> On 06/15/2016 03:33 AM, Werner Koch wrote: > That patch looks fine because it is prettuy conservative. OK. Pushed to master. It is backported to 1.4 and 2.0. -- From bernhard at intevation.de Wed Jun 15 10:26:15 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 15 Jun 2016 10:26:15 +0200 Subject: Request for Discussion: new/PubKeyDistributionConcept/FallbackServer In-Reply-To: <87d1njrja2.wl-neal@walfield.org> References: <201605041751.51371.bernhard@intevation.de> <201606141447.21583.bernhard@intevation.de> <87d1njrja2.wl-neal@walfield.org> Message-ID: <201606151026.19672.bernhard@intevation.de> Hi Neal, Am Dienstag, 14. Juni 2016 15:29:09 schrieb Neal H. Walfield: > Please explain to me how a WKD being run by an MSP is not almost the > same thing as using key escrow? Let's say Alice's MSP runs WKD? I > look up her key using WKD, and her MSP returns the public part of a > fresh key. When I send her an email, the MSP reencrypts the message > and neither I nor Alice is any wiser. thanks for asking the question on a pointed way! This is why I am asking. There are a number of considerations. They need to be discussed and fully explored. To give my personally summary (of my current state): Right now I believe that the introduction of WKD will have a better overal security balance, because many more communication partners and many more encrypted emails. > The only defense against this > is if Alice anonymously and regularly checks that the WKD server > returns the correct public key, which isn't a terribly good defense. I claim that there are more defense possibilities and it is better to trust a number of MSPs a bit that you will have to give some trust anyway. (They could always just chose not to deliver an email and send their own encrypted email to Alice.) There is also communication history that can serve as a defense against malicious MSPs and there is the possibility for Bob who wants to send email to Alice to change the trust values of signatures and communication history. For this Bob needs to be an experienced user, because he will have to argu about trust explicitely. > So, no, WKD is not add a "medium" amount of validity to the key. In > fact, using a key server and guessing which key is right is probably > better than this scheme, because it uses a different network path, > which means your MSP couldn't be compromised by an NSL! The big problem we are trying to solve is that for many user groups we need to design a system that does not require advanced experience with crypto concepts. To overcome this obstacle we try to find one pubkey that is (medium) likely to belong to the person that controls the email address I want to encrypt to. So it can be done automatically in 99.9% of all cases. As you can see from the discussion in the wiki, WKD can be helpful, but leaves the atack vectrr of the MSP oben. It is much better than chosing a pubkey from a public server where everybody can upload rouge pubkeys, because the attack against an MSP is much more expensive and there are many MSPs to chose from. You could chose some residing in a country that does not have national security letter like the US has. > Note: it would be possible to save this scheme if we augmented WKD > with something like Coniks [1], but Werner doesn't like this, because > it adds complexity and will take too much time to implement and we > need to ship in the near future. > > [1] https://coniks.cs.princeton.edu/ I agree with Werner here (you did see the coniks an other concept mentioned on the wiki page?) Coniks is to heavy to introduce now, time and number of parties that we will have to win over are an issue. There is a conflict line with the EasyGPG2016 contract, because this contract has a limited time line. (This is why I am openly talking about this.) However I believe because of other reasons, that end-to-end encryption with OpenPGP needs to do something and thus a more lightwright approach is good. Once a system linke CONIKS is there, we can switch to it with comparatively small efforts. Best Regards, Bernhard -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From neal at walfield.org Wed Jun 15 11:04:45 2016 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 15 Jun 2016 11:04:45 +0200 Subject: Request for Discussion: new/PubKeyDistributionConcept/FallbackServer In-Reply-To: <201606151026.19672.bernhard@intevation.de> References: <201605041751.51371.bernhard@intevation.de> <201606141447.21583.bernhard@intevation.de> <87d1njrja2.wl-neal@walfield.org> <201606151026.19672.bernhard@intevation.de> Message-ID: <874m8urff6.wl-neal@walfield.org> On Wed, 15 Jun 2016 10:26:15 +0200, Bernhard Reiter wrote: > Am Dienstag, 14. Juni 2016 15:29:09 schrieb Neal H. Walfield: > To give my personally summary (of my current state): > Right now I believe that the introduction of WKD will have a better overal > security balance, because many more communication partners and > many more encrypted emails. But does it create a false sense of security? We want to be better than x509, right? If not, then just use S/MIME. > > The only defense against this > > is if Alice anonymously and regularly checks that the WKD server > > returns the correct public key, which isn't a terribly good defense. > > I claim that there are more defense possibilities and it is better > to trust a number of MSPs a bit that you will have to give some trust > anyway. (They could always just chose not to deliver an email > and send their own encrypted email to Alice.) To prevent a MitM, you need a secure channel. You can decrease the change of a MitM be using multiple insecure channels. These insecure channels can be either in space (different network routes) or time (last year, last month and yesterday). This is what TOFU exploits. WKD uses a single insecure channel multiple times. This does not add trust. > The big problem we are trying to solve is that for many user > groups we need to design a system that does not require advanced experience > with crypto concepts. To overcome this obstacle we try to find one > pubkey that is (medium) likely to belong to the person that controls the email > address I want to encrypt to. Well WKD doesn't get you medium assurance. Or, you idea of medium is much different from mine. > So it can be done automatically in 99.9% of > all cases. As you can see from the discussion in the wiki, WKD can be helpful, > but leaves the atack vectrr of the MSP oben. It is much better than chosing a > pubkey from a public server where everybody can upload rouge pubkeys, > because the attack against an MSP is much more expensive and there > are many MSPs to chose from. You could chose some residing in a country that > does not have national security letter like the US has. I disagree. Using a key server means you get multiple routes, which is better. > However I believe because of > other reasons, that end-to-end encryption with OpenPGP needs to do something > and thus a more lightwright approach is good. Once a system linke CONIKS is > there, we can switch to it with comparatively small efforts. I disagree. AS I've stated in other mails, I think it will be harder, because MSPs will rightly see that Coniks increases their liability and they can say that they already implement a security measure. :) Neal From bernhard at intevation.de Wed Jun 15 11:59:20 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 15 Jun 2016 11:59:20 +0200 Subject: Request for Discussion: new/PubKeyDistributionConcept/FallbackServer In-Reply-To: <874m8urff6.wl-neal@walfield.org> References: <201605041751.51371.bernhard@intevation.de> <201606151026.19672.bernhard@intevation.de> <874m8urff6.wl-neal@walfield.org> Message-ID: <201606151159.25166.bernhard@intevation.de> Am Mittwoch, 15. Juni 2016 11:04:45 schrieb Neal H. Walfield: > On Wed, 15 Jun 2016 10:26:15 +0200, > > Bernhard Reiter wrote: > > Am Dienstag, 14. Juni 2016 15:29:09 schrieb Neal H. Walfield: > > To give my personally summary (of my current state): > > Right now I believe that the introduction of WKD will have a better > > overal security balance, because many more communication partners and > > many more encrypted emails. > > But does it create a false sense of security? In my mental model it does not. It builds on the trust you have in your personal MSP and does not go far beyond it. > We want to be better > than x509, right? If not, then just use S/MIME. No, we do not want to get better in all aspects. PKIX (x509) is central where you have to trust a hierarchy. Okay you can have several trust anchors, so it is not one single trust anchor, but there is no practical way to a) find good trust anchors (without advanced crypto knowledge) b) start low cost c) update to stronger trust modules d) have communication history flow in e) come with a reasonable default configuration. > > > The only defense against this > > > is if Alice anonymously and regularly checks that the WKD server > > > returns the correct public key, which isn't a terribly good defense. > > > > I claim that there are more defense possibilities and it is better > > to trust a number of MSPs a bit that you will have to give some trust > > anyway. (They could always just chose not to deliver an email > > and send their own encrypted email to Alice.) > > To prevent a MitM, you need a secure channel. You can decrease the > change of a MitM be using multiple insecure channels. These insecure > channels can be either in space (different network routes) or time > (last year, last month and yesterday). This is what TOFU exploits. > > WKD uses a single insecure channel multiple times. This does not add > trust. WKD over TLS is a secure channel to the MSP. Adding the other channels (signature, other communication) and time there is some protection against single malicious MSPs. > > The big problem we are trying to solve is that for many user > > groups we need to design a system that does not require advanced > > experience with crypto concepts. To overcome this obstacle we try to find > > one pubkey that is (medium) likely to belong to the person that controls > > the email address I want to encrypt to. > > Well WKD doesn't get you medium assurance. Or, you idea of medium is > much different from mine. Yes, this seems to be the case. My argument is that is harder (more expensive) to attack than publishing malicous pubkeys with keyservers or initiatiating a low number of email interactions with a faked email address. > > So it can be done automatically in 99.9% of > > all cases. As you can see from the discussion in the wiki, WKD can be > > helpful, but leaves the atack vectrr of the MSP oben. It is much better > > than chosing a pubkey from a public server where everybody can upload > > rouge pubkeys, because the attack against an MSP is much more expensive > > and there are many MSPs to chose from. You could chose some residing in a > > country that does not have national security letter like the US has. > > I disagree. Using a key server means you get multiple routes, which > is better. Using a key server will not get a pubkey selected, there is no way to decide which key is bad or not. This does not change if you get those pubkeys from several sources or not, there is no indication at all that they belong to the owner of the email address. > > However I believe because of > > other reasons, that end-to-end encryption with OpenPGP needs to do > > something and thus a more lightwright approach is good. Once a system > > linke CONIKS is there, we can switch to it with comparatively small > > efforts. > > I disagree. AS I've stated in other mails, I think it will be harder, > because MSPs will rightly see that Coniks increases their liability > and they can say that they already implement a security measure. I accept the argument that having one system in place that solves (a part of) the problem will decrease the likelyhood of a more improved system to be adopted. I give it less weight though. The reason is: If OpenPGP does not come over the principal challenge, it will be superceded by more practical systems implementing something like the Signal protocol. I believe that OpenPGP has merits over the Signal protocol, so I want OpenPGP implementations to improve. In addition, clients could implement a common view system without the support of MSPs later if they have WKD in place. Best Regards, Bernhard -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Wed Jun 15 16:41:13 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 15 Jun 2016 16:41:13 +0200 Subject: [Announce] Libgcrypt 1.7.1 released Message-ID: <87poripl9y.fsf@wheatstone.g10code.de> Hello! The GnuPG Project is pleased to announce the availability of Libgcrypt version 1.7.1. This is a maintenace release. Libgcrypt is a general purpose library of cryptographic building blocks. It is originally based on code used by GnuPG. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required to use Libgcrypt. Noteworthy changes in version 1.7.1 =================================== * Bug fixes: - Fix ecc_verify for cofactor support. - Fix portability bug when using gcc with Solaris 9 SPARC. - Build fix for OpenBSD/amd64 - Add OIDs to the Serpent ciphers. * Internal changes: - Use getrandom system call on Linux if available. - Blinding is now also used for RSA signature creation. - Changed names of debug envvars Download ======== Source code is hosted at the GnuPG FTP server and its mirrors as listed at https://gnupg.org/download/mirrors.html . On the primary server the source tarball and its digital signature are: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.1.tar.bz2 (2776k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.1.tar.bz2.sig That file is bzip2 compressed. A gzip compressed version is here: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.1.tar.gz (3314k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.1.tar.gz.sig The same files are also available via HTTP: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.1.tar.bz2 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.1.tar.bz2.sig https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.1.tar.gz https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.1.tar.gz.sig In order to check that the version of Libgcrypt you downloaded is an original and unmodified file please follow the instructions found at . In short, you may use one of the following methods: - Check the supplied OpenPGP signature. For example to check the signature of the file libgcrypt-1.7.1.tar.bz2 you would use this command: gpg --verify libgcrypt-1.7.1.tar.bz2.sig libgcrypt-1.7.1.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. - If you are not able to use GnuPG, you have to verify the SHA-1 checksum: sha1sum libgcrypt-1.7.1.tar.bz2 and check that the output matches the first line from the this list: b688add52b622bb96bbd823ba21aa05a116d442f libgcrypt-1.7.1.tar.bz2 7310ed270c3a98b74acb58bcc95a2b4f596417cb libgcrypt-1.7.1.tar.gz You should also verify that the checksums above are authentic by matching them with copies of this announcement. Those copies can be found at other mailing lists, web sites, and search engines. Copying ======= Libgcrypt is distributed under the terms of the GNU Lesser General Public License (LGPLv2.1+). The helper programs as well as the documentation are distributed under the terms of the GNU General Public License (GPLv2+). The file LICENSES has notices about contributions that require that these additional notices are distributed. Support ======= For help on developing with Libgcrypt you should read the included manual and optional ask on the gcrypt-devel mailing list [1]. A listing with commercial support offers for Libgcrypt and related software is available at the GnuPG web site [2]. If you are a developer and you may need a certain feature for your project, please do not hesitate to bring it to the gcrypt-devel mailing list for discussion. Maintenance and development of Libgcrypt is mostly financed by donations; see . We currently employ 3 full-time developers, one part-timer, and one contractor to work on GnuPG and closely related software like Libgcrypt. Thanks ====== We like to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Also many thanks to all our donors [3]. For the GnuPG hackers, Werner p.s. This is an announcement only mailing list. Please send replies only to the gcrypt-devel 'at' gnupg.org mailing list. [1] https://lists.gnupg.org/mailman/listinfo/gcrypt-devel [2] https://www.gnupg.org/service.html [3] https://gnupg.org/donate/kudos.html -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ -------------- 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 meno.abels at adviser.com Thu Jun 16 08:30:58 2016 From: meno.abels at adviser.com (Meno Abels) Date: Thu, 16 Jun 2016 06:30:58 +0000 Subject: Outputformat of --list-secret-keys Message-ID: Hi, i discovered that the output-format of the --list-secret-keys options has changed since the last release 2.1.12. In the last release version it looks like: sec# ed25519/06A4BEEF 2016-05-31 [C] [expires: 2021-05-30] the shorted keyid is behind the /. In the head version it looks like this: sec# ed25519 2016-05-31 [C] [verf?llt: 2021-05-30] F36846C4A7DEFD55F492069C19B013CF06A4BEEF is this intended? If yes I would recommend to stick with the old format and add another option for the long keyid. And to leave the long keyId in the same line at the same column. This makes it much easier to parse by thirdparty tools-:) thx meno -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristian.fiskerstrand at sumptuouscapital.com Thu Jun 16 10:02:14 2016 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Thu, 16 Jun 2016 10:02:14 +0200 Subject: Outputformat of --list-secret-keys In-Reply-To: References: Message-ID: <6dd2f488-c0ba-1b1d-bb3a-684c5c652bdb@sumptuouscapital.com> On 06/16/2016 08:30 AM, Meno Abels wrote: > Hi, > > is this intended? If yes I would recommend to stick with the old format > and add another option for the long keyid. > And to leave the long keyId in the same line at the same column. > This makes it much easier to parse by thirdparty tools-:) Third party tools should use --with-colons to begin with (or gpgme), not parsing the human readable interface -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP certificate at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "If you are successful, you may win false friends and true enemies. Succeed anyway." (Mother Teresa) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Jun 16 19:54:37 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 16 Jun 2016 19:54:37 +0200 Subject: [LIBGPG-ERROR PATCH] estream read/write access In-Reply-To: <575F5B82.8070301@fsij.org> (NIIBE Yutaka's message of "Tue, 14 Jun 2016 10:18:58 +0900") References: <575F5B82.8070301@fsij.org> Message-ID: <87ziqlkoiq.fsf@wheatstone.g10code.de> On Tue, 14 Jun 2016 03:18, gniibe at fsij.org said: > I think that this bug (in libgpg-error for gpg 2.1) should be fixed > soon. Libgpg-error 1.23 has this fix. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ From wk at gnupg.org Thu Jun 16 20:27:52 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 16 Jun 2016 20:27:52 +0200 Subject: [Announce] GnuPG 2.1.13 released Message-ID: <87fusdkmzb.fsf@wheatstone.g10code.de> Hello! The GnuPG team is pleased to announce the availability of a new release of GnuPG modern: Version 2.1.13. See below for new features and bug fixes. The GNU Privacy Guard (GnuPG) is a complete and free implementation of the OpenPGP standard which is commonly abbreviated as PGP. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries making use of GnuPG are available. Since version 2 GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Three different branches of GnuPG are actively maintained: - GnuPG "modern" (2.1) is the latest development with a lot of new features. This announcement is about this branch. - GnuPG "stable" (2.0) is the current stable version for general use. This is what most users are still using. - GnuPG "classic" (1.4) is the old standalone version which is most suitable for older or embedded platforms. You may not install "modern" (2.1) and "stable" (2.0) at the same time. However, it is possible to install "classic" (1.4) along with any of the other versions. Noteworthy changes in version 2.1.13 ==================================== * gpg: New command --quick-addkey. Extend the --quick-gen-key command. * gpg: New --keyid-format "none" which is now also the default. * gpg: New option --with-subkey-fingerprint. * gpg: Include Signer's UID subpacket in signatures if the secret key has been specified using a mail address and the new option --disable-signer-uid is not used. * gpg: Allow unattended deletion of a secret key. * gpg: Allow export of non-passphrase protected secret keys. * gpg: New status lines KEY_CONSIDERED and NOTATION_FLAGS. * gpg: Change status line TOFU_STATS_LONG to use '~' as a non-breaking-space character. * gpg: Speedup key listings in Tofu mode. * gpg: Make sure that the current and total values of a PROGRESS status line are small enough. * gpgsm: Allow the use of AES192 and SERPENT ciphers. * dirmngr: Adjust WKD lookup to current specs. * dirmngr: Fallback to LDAP v3 if v2 is is not supported. * gpgconf: New commands --create-socketdir and --remove-socketdir, new option --homedir. * If a /run/user/$UID directory exists, that directory is now used for IPC sockets instead of the GNUPGHOME directory. This fixes problems with NFS and too long socket names and thus avoids the need for redirection files. * The Speedo build systems now uses the new versions.gnupg.org server to retrieve the default package versions. * Fix detection of libusb on FreeBSD. * Speedup fd closing after a fork. A detailed description of the changes found in the 2.1 branch can be found at . Please be aware that there are still known bugs which we are working on. Check https://bugs.gnupg.org, https://wiki.gnupg.org, and the mailing list archives for known problems and workarounds. Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.1.13 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.13.tar.bz2 (5415k) ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.13.tar.bz2.sig or here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.13.tar.bz2 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.13.tar.bz2.sig Please kill running gpg-agent and dirmngr processes before using this release. An installer for Windows without any graphical frontend except for a basic Pinentry tool is available here: ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.13_20160616.exe (3527k) ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.13_20160616.exe.sig or here https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.13_20160616.exe https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.13_20160616.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. This Windows installer comes with Tofu support, translations, and support for Tor and the Tor browser. It is still missing HKPS support, though. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.1.13.tar.bz2 you would use this command: gpg --verify gnupg-2.1.13.tar.bz2.sig gnupg-2.1.13.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.13.tar.bz2, you run the command like this: sha1sum gnupg-2.1.13.tar.bz2 and check that the output matches the next line: 6ec1ae6db7815fdbd4151fb6b0b7197b65b05d1f gnupg-2.1.13.tar.bz2 2debd757534d777bb9c69c18f9492e9a9e5a3a72 gnupg-w32-2.1.13_20160616.exe 44b473d355de8546351c4f737f807b40220715ff gnupg-w32-2.1.13_20160616.tar.xz Release Signing Keys ==================== To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: 2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31] Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 Werner Koch (Release Signing Key) You may retrieve these keys from a keyserver using this command gpg --keyserver hkp://keys.gnupg.net --recv-keys \ 249B39D24F25E3B6 04376F3EE0856959 \ 2071B08A33BD3F06 8A861B1C7EFD60D9 The keys are also available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese, Czech, French, German, Japanese, Russian, and Ukrainian being almost completely translated (2168 different strings). Documentation ============= If you used GnuPG in the past you should read the description of changes and new features at doc/whats-new-in-2.1.txt or online at https://gnupg.org/faq/whats-new-in-2.1.html The file gnupg.info has the complete user manual of the system. Separate man pages are included as well but they have not all the details available as are the manual. It is also possible to read the complete manual online in HTML format at https://gnupg.org/documentation/manuals/gnupg/ or in Portable Document Format at https://gnupg.org/documentation/manuals/gnupg.pdf . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. You may also want search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. You may also want to follow our postings at and . Support ======== Please consult the archive of the gnupg-users mailing list before reporting a bug . We suggest to send bug reports for a new release to this list in favor of filing a bug at . If you need commercial support check out . If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Maintenance and development of GnuPG is mostly financed by donations. As of today we employ 3 full-time developers, one part-timer, and one contractor. They all work on GnuPG and closely related software like Libgcrypt and GPA. Please consider to donate via: https://gnupg.org/donate/ Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, answering questions on the mailing lists, and donating money. See you at OpenPGP.conf . For the GnuPG hackers, Werner p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users'at'gnupg.org mailing list. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ -------------- 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 Thu Jun 16 21:33:56 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 16 Jun 2016 15:33:56 -0400 Subject: tests/pkits failing on master (when building from git) In-Reply-To: <87k31jubm3.fsf@vigenere.g10code.de> References: <5436FB65.2000306@fifthhorseman.net> <878ui3s1y5.fsf@alice.fifthhorseman.net> <87k31jubm3.fsf@vigenere.g10code.de> Message-ID: <87bn31vsgr.fsf@alice.fifthhorseman.net> On Mon 2014-12-22 07:12:36 -0500, Werner Koch wrote: > On Fri, 19 Dec 2014 23:35, dkg at fifthhorseman.net said: > >> I'm still seeing long failures in all three of these when running "make >> check" off of the current master, from git >> 76140141699b545f7a988bf5fc101063917e8ce3. > > That test suite is pretty fragile and was never completed. Resolving > the problems might take some time. > > >> Should they also be skipped when running "make check" from git? or do >> they need to be cleaned up/fixed somehow? Or is there something wrong >> with my environment > > On my GIT build they are skipped. Are you using a newer automake? I > guess that will be the problem. My plan was to switch to automake 1.14 > with the release of Jessie but I may reconsider that and do it in > January. These tests are still running (and failing) for me when i build master From git. I've got automake 1.15 and automake 1.11 installed, fwiw. is there something i should do to avoid having this failure? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From kristian.fiskerstrand at sumptuouscapital.com Thu Jun 16 21:40:29 2016 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Thu, 16 Jun 2016 21:40:29 +0200 Subject: [Announce] GnuPG 2.1.13 released In-Reply-To: <87fusdkmzb.fsf@wheatstone.g10code.de> References: <87fusdkmzb.fsf@wheatstone.g10code.de> Message-ID: <85db5c5b-c608-b3ae-f2d4-dd279c59deea@sumptuouscapital.com> Congratulations on a new release, I just pushed it to Gentoo ~arch as well On 06/16/2016 08:27 PM, Werner Koch wrote: > * gpg: New option --with-subkey-fingerprint. Will this option be backported to older branches to provide a consistent interface vs dual --with-fingerprint? -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP certificate at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "The best way to predict the future is to invent it" (Alan Kay) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Fri Jun 17 00:05:57 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 16 Jun 2016 18:05:57 -0400 Subject: [PATCH] g10: implement gpg --quick-revuid Message-ID: <1466114757-23740-1-git-send-email-dkg@fifthhorseman.net> * g10/revoke.c (get_default_uid_revocation_reason): new * g10/keyedit.c (menu_revuid): break out creation of uid revocation into new function core_revuid * g10/keyedit.c (keyedit_quick_revuid): new: selects key and uid, invokes core_revuid * g10/gpg.c (main): handle --quick-revuid argument * doc/gpg.texi, doc/whats-new-in-2.1.txt: document --quick-revuid * tests/openpgp/quick-key-manipulation.test: add simple test of --quick-* commands -- This functionality is a counterpart to --quick-adduid, and will be useful for projects that depend programmatically on gpg to revoke user IDs (one such example is "monkeysphere-host revoke-servicename"). Signed-off-by: Daniel Kahn Gillmor --- doc/gpg.texi | 9 + doc/whats-new-in-2.1.txt | 14 ++ g10/gpg.c | 17 ++ g10/keyedit.c | 268 ++++++++++++++++++++++-------- g10/main.h | 3 + g10/revoke.c | 10 ++ tests/openpgp/Makefile.am | 1 + tests/openpgp/quick-key-manipulation.test | 70 ++++++++ 8 files changed, 327 insertions(+), 65 deletions(-) create mode 100755 tests/openpgp/quick-key-manipulation.test diff --git a/doc/gpg.texi b/doc/gpg.texi index 6437b90..92ff835 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -1041,6 +1041,15 @@ the interactive sub-command @code{adduid} of @option{--edit-key} the white space removed, it is expected to be UTF-8 encoded, and no checks on its form are applied. + at item --quick-revuid @var{user-id} @var{user-id-to-revoke} + at opindex quick-revuid +This command revokes a User ID on an existing key. It cannot be used +to revoke the last User ID on key (some non-revoked User ID must +remain), with revocation reason ``User ID is no longer valid''. If +you want to specify a different revocation reason, or to supply +supplementary revocation text, you should use the interactive +sub-command @code{revuid} of @option{--edit-key}. + @item --passwd @var{user_id} @opindex passwd Change the passphrase of the secret key belonging to the certificate diff --git a/doc/whats-new-in-2.1.txt b/doc/whats-new-in-2.1.txt index 6c46b04..d8b9ae1 100644 --- a/doc/whats-new-in-2.1.txt +++ b/doc/whats-new-in-2.1.txt @@ -437,6 +437,20 @@ https://gnupg.org/faq/whats-new-in-2.1.html ? uid [ unknown] EdDSA sample key 1 ????? + Since version 2.1.14 it possible to revoke a user id on an existing + key: + + ????? + ? $ gpg2 -k 8CFDE12197965A9A + ? pub ed25519/8CFDE12197965A9A 2014-08-19 + ? uid [ unknown] Sample 2 + ? uid [ unknown] EdDSA sample key 1 + ? $ gpg2 --quick-revuid 8CFDE12197965A9A 'EdDSA sample key 1' + ? $ gpg2 -k 8CFDE12197965A9A + ? pub ed25519/8CFDE12197965A9A 2014-08-19 + ? uid [ unknown] Sample 2 + ????? + 1.6 Improved Pinentry support ????????????????????????????? diff --git a/g10/gpg.c b/g10/gpg.c index 1f2d416..f6013f3 100644 --- a/g10/gpg.c +++ b/g10/gpg.c @@ -118,6 +118,7 @@ enum cmd_and_opt_values aQuickLSignKey, aQuickAddUid, aQuickAddKey, + aQuickRevUid, aListConfig, aListGcryptConfig, aGPGConfList, @@ -430,6 +431,8 @@ static ARGPARSE_OPTS opts[] = { ARGPARSE_c (aQuickAddUid, "quick-adduid", N_("quickly add a new user-id")), ARGPARSE_c (aQuickAddKey, "quick-addkey", "@"), + ARGPARSE_c (aQuickRevUid, "quick-revuid", + N_("quickly revoke a user-id")), ARGPARSE_c (aFullKeygen, "full-gen-key" , N_("full featured key pair generation")), ARGPARSE_c (aGenRevoke, "gen-revoke",N_("generate a revocation certificate")), @@ -2432,6 +2435,7 @@ main (int argc, char **argv) case aQuickKeygen: case aQuickAddUid: case aQuickAddKey: + case aQuickRevUid: case aExportOwnerTrust: case aImportOwnerTrust: case aRebuildKeydbCaches: @@ -3777,6 +3781,7 @@ main (int argc, char **argv) case aQuickKeygen: case aQuickAddUid: case aQuickAddKey: + case aQuickRevUid: case aFullKeygen: case aKeygen: case aImport: @@ -4196,6 +4201,18 @@ main (int argc, char **argv) } break; + case aQuickRevUid: + { + const char *uid, *uidtorev; + + if (argc != 2) + wrong_args ("--quick-revuid USER-ID USER-ID-TO-REVOKE"); + uid = *argv++; argc--; + uidtorev = *argv++; argc--; + keyedit_quick_revuid (ctrl, uid, uidtorev); + } + break; + case aFastImport: opt.import_options |= IMPORT_FAST; case aImport: diff --git a/g10/keyedit.c b/g10/keyedit.c index d05ea5d..2f106dd 100644 --- a/g10/keyedit.c +++ b/g10/keyedit.c @@ -87,6 +87,9 @@ static int real_uids_left (KBNODE keyblock); static int count_selected_keys (KBNODE keyblock); static int menu_revsig (KBNODE keyblock); static int menu_revuid (ctrl_t ctrl, kbnode_t keyblock); +static int core_revuid (ctrl_t ctrl, kbnode_t keyblock, KBNODE node, + const struct revocation_reason_info *reason, + int *modified); static int menu_revkey (KBNODE pub_keyblock); static int menu_revsubkey (KBNODE pub_keyblock); #ifndef NO_TRUST_MODELS @@ -2937,6 +2940,107 @@ keyedit_quick_adduid (ctrl_t ctrl, const char *username, const char *newuid) keydb_release (kdbhd); } +/* Unattended revokation of a keyid. USERNAME specifies the + key. UIDTOREV is the user id revoke from the key. */ +void +keyedit_quick_revuid (ctrl_t ctrl, const char *username, const char *uidtorev) +{ + gpg_error_t err; + KEYDB_HANDLE kdbhd = NULL; + KEYDB_SEARCH_DESC desc; + kbnode_t keyblock = NULL; + kbnode_t node; + int modified = 0; + size_t revlen; + +#ifdef HAVE_W32_SYSTEM + /* See keyedit_menu for why we need this. */ + check_trustdb_stale (); +#endif + + /* Search the key; we don't want the whole getkey stuff here. */ + kdbhd = keydb_new (); + if (!kdbhd) + { + /* Note that keydb_new has already used log_error. */ + goto leave; + } + + err = classify_user_id (username, &desc, 1); + if (!err) + err = keydb_search (kdbhd, &desc, 1, NULL); + if (!err) + { + err = keydb_get_keyblock (kdbhd, &keyblock); + if (err) + { + log_error (_("error reading keyblock: %s\n"), gpg_strerror (err)); + goto leave; + } + /* Now with the keyblock retrieved, search again to detect an + ambiguous specification. We need to save the found state so + that we can do an update later. */ + keydb_push_found_state (kdbhd); + err = keydb_search (kdbhd, &desc, 1, NULL); + if (!err) + err = gpg_error (GPG_ERR_AMBIGUOUS_NAME); + else if (gpg_err_code (err) == GPG_ERR_NOT_FOUND) + err = 0; + keydb_pop_found_state (kdbhd); + + if (!err) + { + /* We require the secret primary key to revoke a UID. */ + node = find_kbnode (keyblock, PKT_PUBLIC_KEY); + if (!node) + BUG (); + err = agent_probe_secret_key (ctrl, node->pkt->pkt.public_key); + } + } + if (err) + { + log_error (_("secret key \"%s\" not found: %s\n"), + username, gpg_strerror (err)); + goto leave; + } + + fix_keyblock (&keyblock); + setup_main_keyids (keyblock); + + revlen = strlen (uidtorev); + /* find the right UID */ + for (node = keyblock; node; node = node->next) + { + if (node->pkt->pkttype == PKT_USER_ID && + revlen == node->pkt->pkt.user_id->len && + 0 == memcmp (node->pkt->pkt.user_id->name, uidtorev, revlen)) + { + struct revocation_reason_info *reason = get_default_uid_revocation_reason(); + err = core_revuid (ctrl, keyblock, node, reason, &modified); + release_revocation_reason_info (reason); + if (err) + { + log_error (_("User ID revocation failed: %s\n"), gpg_strerror (err)); + goto leave; + } + err = keydb_update_keyblock (kdbhd, keyblock); + if (err) + { + log_error (_("update failed: %s\n"), gpg_strerror (err)); + goto leave; + } + + if (update_trust) + revalidation_mark (); + goto leave; + } + } + + leave: + release_kbnode (keyblock); + keydb_release (kdbhd); +} + /* Find a keyblock by fingerprint because only this uniquely * identifies a key and may thus be used to select a key for @@ -6106,6 +6210,95 @@ reloop: /* (must use this, because we are modifing the list) */ } +/* return 0 if revocation of NODE (which must be a User ID) was + successful, non-zero if there was an error. *modified will be set + to 1 if a change was made. */ +static int +core_revuid (ctrl_t ctrl, kbnode_t keyblock, KBNODE node, + const struct revocation_reason_info *reason, int *modified) +{ + PKT_public_key *pk = keyblock->pkt->pkt.public_key; + gpg_error_t rc; + + if (node->pkt->pkttype != PKT_USER_ID) + { + rc = gpg_error (GPG_ERR_NO_USER_ID); + write_status_error ("keysig", rc); + log_error (_("tried to revoke a non-user ID: %s\n"), gpg_strerror (rc)); + return 1; + } + else + { + PKT_user_id *uid = node->pkt->pkt.user_id; + + if (uid->is_revoked) + { + char *user = utf8_to_native (uid->name, uid->len, 0); + log_info (_("user ID \"%s\" is already revoked\n"), user); + xfree (user); + } + else + { + PACKET *pkt; + PKT_signature *sig; + struct sign_attrib attrib; + u32 timestamp = make_timestamp (); + + if (uid->created >= timestamp) + { + /* Okay, this is a problem. The user ID selfsig was + created in the future, so we need to warn the user and + set our revocation timestamp one second after that so + everything comes out clean. */ + + log_info (_("WARNING: a user ID signature is dated %d" + " seconds in the future\n"), + uid->created - timestamp); + + timestamp = uid->created + 1; + } + + memset (&attrib, 0, sizeof attrib); + /* should not need to cast away const here; but + revocation_reason_build_cb needs to take a non-const + void* in order to meet the function signtuare for the + mksubpkt argument to make_keysig_packet */ + attrib.reason = (struct revocation_reason_info *)reason; + + rc = make_keysig_packet (&sig, pk, uid, NULL, pk, 0x30, 0, + timestamp, 0, + sign_mk_attrib, &attrib, NULL); + if (rc) + { + write_status_error ("keysig", rc); + log_error (_("signing failed: %s\n"), gpg_strerror (rc)); + return 1; + } + else + { + pkt = xmalloc_clear (sizeof *pkt); + pkt->pkttype = PKT_SIGNATURE; + pkt->pkt.signature = sig; + insert_kbnode (node, new_kbnode (pkt), 0); + +#ifndef NO_TRUST_MODELS + /* If the trustdb has an entry for this key+uid then the + trustdb needs an update. */ + if (!update_trust + && (get_validity (ctrl, pk, uid, NULL, 0) & TRUST_MASK) >= + TRUST_UNDEFINED) + update_trust = 1; +#endif /*!NO_TRUST_MODELS*/ + + node->pkt->pkt.user_id->is_revoked = 1; + if (modified) + *modified = 1; + } + } + return 0; + } +} + /* Revoke a user ID (i.e. revoke a user ID selfsig). Return true if keyblock changed. */ static int @@ -6132,75 +6325,20 @@ menu_revuid (ctrl_t ctrl, kbnode_t pub_keyblock) goto leave; } - reloop: /* (better this way because we are modifing the keyring) */ + reloop: /* (better this way because we are modifying the keyring) */ for (node = pub_keyblock; node; node = node->next) if (node->pkt->pkttype == PKT_USER_ID && (node->flag & NODFLG_SELUID)) { - PKT_user_id *uid = node->pkt->pkt.user_id; - - if (uid->is_revoked) - { - char *user = utf8_to_native (uid->name, uid->len, 0); - log_info (_("user ID \"%s\" is already revoked\n"), user); - xfree (user); - } - else - { - PACKET *pkt; - PKT_signature *sig; - struct sign_attrib attrib; - u32 timestamp = make_timestamp (); - - if (uid->created >= timestamp) - { - /* Okay, this is a problem. The user ID selfsig was - created in the future, so we need to warn the user and - set our revocation timestamp one second after that so - everything comes out clean. */ - - log_info (_("WARNING: a user ID signature is dated %d" - " seconds in the future\n"), - uid->created - timestamp); - - timestamp = uid->created + 1; - } - - memset (&attrib, 0, sizeof attrib); - attrib.reason = reason; - + int modified = 0; + rc = core_revuid (ctrl, pub_keyblock, node, reason, &modified); + if (rc) + goto leave; + if (modified) + { node->flag &= ~NODFLG_SELUID; - - rc = make_keysig_packet (&sig, pk, uid, NULL, pk, 0x30, 0, - timestamp, 0, - sign_mk_attrib, &attrib, NULL); - if (rc) - { - write_status_error ("keysig", rc); - log_error (_("signing failed: %s\n"), gpg_strerror (rc)); - goto leave; - } - else - { - pkt = xmalloc_clear (sizeof *pkt); - pkt->pkttype = PKT_SIGNATURE; - pkt->pkt.signature = sig; - insert_kbnode (node, new_kbnode (pkt), 0); - -#ifndef NO_TRUST_MODELS - /* If the trustdb has an entry for this key+uid then the - trustdb needs an update. */ - if (!update_trust - && (get_validity (ctrl, pk, uid, NULL, 0) & TRUST_MASK) >= - TRUST_UNDEFINED) - update_trust = 1; -#endif /*!NO_TRUST_MODELS*/ - - changed = 1; - node->pkt->pkt.user_id->is_revoked = 1; - - goto reloop; - } - } + changed = 1; + goto reloop; + } } if (changed) diff --git a/g10/main.h b/g10/main.h index 7b716ff..b11a853 100644 --- a/g10/main.h +++ b/g10/main.h @@ -289,6 +289,8 @@ void keyedit_quick_adduid (ctrl_t ctrl, const char *username, const char *newuid); void keyedit_quick_addkey (ctrl_t ctrl, const char *fpr, const char *algostr, const char *usagestr, const char *expirestr); +void keyedit_quick_revuid (ctrl_t ctrl, const char *username, + const char *uidtorev); void keyedit_quick_sign (ctrl_t ctrl, const char *fpr, strlist_t uids, strlist_t locusr, int local); void show_basic_key_info (KBNODE keyblock); @@ -407,6 +409,7 @@ int gen_desig_revoke (ctrl_t ctrl, const char *uname, strlist_t locusr); int revocation_reason_build_cb( PKT_signature *sig, void *opaque ); struct revocation_reason_info * ask_revocation_reason( int key_rev, int cert_rev, int hint ); +struct revocation_reason_info * get_default_uid_revocation_reason(void); void release_revocation_reason_info( struct revocation_reason_info *reason ); /*-- keylist.c --*/ diff --git a/g10/revoke.c b/g10/revoke.c index 218ca59..15a91ac 100644 --- a/g10/revoke.c +++ b/g10/revoke.c @@ -862,6 +862,16 @@ ask_revocation_reason( int key_rev, int cert_rev, int hint ) return reason; } +struct revocation_reason_info * +get_default_uid_revocation_reason(void) +{ + struct revocation_reason_info *reason; + reason = xmalloc( sizeof *reason ); + reason->code = 0x20; /* uid is no longer valid */ + reason->desc = strdup(""); /* no text */ + return reason; +} + void release_revocation_reason_info( struct revocation_reason_info *reason ) { diff --git a/tests/openpgp/Makefile.am b/tests/openpgp/Makefile.am index bb1047d..020df78 100644 --- a/tests/openpgp/Makefile.am +++ b/tests/openpgp/Makefile.am @@ -52,6 +52,7 @@ TESTS = version.test mds.test \ signencrypt.test signencrypt-dsa.test \ armsignencrypt.test armdetach.test \ armdetachm.test detachm.test genkey1024.test \ + quick-key-manipulation.test \ conventional.test conventional-mdc.test \ multisig.test verify.test armor.test \ import.test ecc.test 4gb-packet.test \ diff --git a/tests/openpgp/quick-key-manipulation.test b/tests/openpgp/quick-key-manipulation.test new file mode 100755 index 0000000..4185601 --- /dev/null +++ b/tests/openpgp/quick-key-manipulation.test @@ -0,0 +1,70 @@ +#!/bin/sh +# Copyright 2016 Free Software Foundation, Inc. +# This file is free software; as a special exception the author gives +# unlimited permission to copy and/or distribute it, with or without +# modifications, as long as this notice is preserved. This file is +# distributed in the hope that it will be useful, but WITHOUT ANY +# WARRANTY, to the extent permitted by law; without even the implied +# warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + +. $srcdir/defs.inc || exit 3 + +export PINENTRY_USER_DATA=test + +alpha="Alpha " +bravo="Bravo " + +$GPG --with-colons --with-fingerprint --list-secret-keys ="$alpha" && + error "User ID '$alpha'exists when it should not!" +$GPG --with-colons --with-fingerprint --list-secret-keys ="$bravo" && + error "User ID '$bravo' exists when it should not!" + +#info verify that key creation works +$GPG --quick-gen-key "$alpha" || \ + error "failed to generate key" + +fpr=$($GPG --with-colons --with-fingerprint --list-secret-keys ="$alpha" | \ + grep '^fpr:' | cut -f10 -d: | head -n1) + +$GPG --check-trustdb + +cleanup() { + $GPG --batch --yes --delete-secret-key "0x$fpr" + $GPG --batch --yes --delete-key "0x$fpr" +} + +count_uids_of_secret() { + if ! [ $($GPG --with-colons --list-secret-keys ="$1" | \ + grep -c '^uid:u:') = "$2" ] ; then + cleanup + error "wrong number of user IDs for '$1' after $3" + fi +} + +count_uids_of_secret "$alpha" 1 "key generation" + +#info verify that we can add a user ID +if ! $GPG --quick-adduid ="$alpha" "$bravo" ; then + cleanup + error "failed to add user id" +fi + +$GPG --check-trustdb + +count_uids_of_secret "$alpha" 2 "adding User ID" +count_uids_of_secret "$bravo" 2 "adding User ID" + +#info verify that we can revoke a user ID +if ! $GPG --quick-revuid ="$bravo" "$alpha"; then + cleanup + error "failed to revoke user id" +fi + +$GPG --check-trustdb + +count_uids_of_secret "$bravo" 1 "revoking user ID" + +cleanup + +! $GPG --with-colons --list-secret-keys ="$bravo" || + error "key still exists when it should not!" -- 2.8.1 From dkg at fifthhorseman.net Fri Jun 17 00:11:26 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 16 Jun 2016 18:11:26 -0400 Subject: [PATCH] .gitignore: ignore doc/gnupg-module-overview.{pdf,png} Message-ID: <1466115086-24610-1-git-send-email-dkg@fifthhorseman.net> * doc/gnupg-module-overview.{pdf,png}: These generated files should not be tracked by git. Signed-off-by: Daniel Kahn Gillmor --- .gitignore | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.gitignore b/.gitignore index dd3d031..4ae758f 100644 --- a/.gitignore +++ b/.gitignore @@ -59,6 +59,8 @@ doc/faq.raw.xref doc/gnupg-card-architecture.eps doc/gnupg-card-architecture.pdf doc/gnupg-card-architecture.png +doc/gnupg-module-overview.pdf +doc/gnupg-module-overview.png doc/gnupg.7 doc/gpg-agent.1 doc/gpg-connect-agent.1 -- 2.8.1 From dkg at fifthhorseman.net Fri Jun 17 00:41:56 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 16 Jun 2016 18:41:56 -0400 Subject: Moving the agent's socket to /var/run ? In-Reply-To: <87h9d3zu52.fsf@wheatstone.g10code.de> References: <87k2lv5u0y.fsf@wheatstone.g10code.de> <87h9d3zu52.fsf@wheatstone.g10code.de> Message-ID: <8737ocwybv.fsf@alice.fifthhorseman.net> On Wed 2016-06-08 09:29:13 -0400, Werner Koch wrote: > To cope with non standard homedirs (via GNUPGHOME or --homedir) the > SHA-1 hash of the homedir is computed, left truncated to 120 bits, > zBase-32 encoded, prefixed with "d.", and appended to > "[/var]/run/user/$(id -u)/gnupg/". Out of curiosity, how will this value be calculated if any of the filesystems along the path to --homedir are case-insensitive? will there be any attempt in that case to normalize the case of the input to the hash function, or will it be treated as a raw bytestream? doesn't matter much for my own use, but it occurs to me that if there are people on platforms (like Mac OS, iirc) or on filesystems (like FAT32) where case-insensitivity is the norm, it's conceivable that two different processes could be accessing the same --homedir but use different agent socket paths. --dkg From mail at tankredhase.de Fri Jun 17 00:11:33 2016 From: mail at tankredhase.de (Tankred Hase) Date: Fri, 17 Jun 2016 00:11:33 +0200 Subject: Request for Discussion: new/PubKeyDistributionConcept/FallbackServer Message-ID: <3C8BA21B-AC65-4411-B572-F92A41335316@tankredhase.de> Hey everyone, I saw the discussion and thought I'd share what we've built in the past few weeks for Mailvelope. It's a very simple key server that borrows from Signal to allow TOFU m/automatic key lookup. No key transparency included: https://keys.mailvelope.com Tankred -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Fri Jun 17 02:45:23 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 16 Jun 2016 20:45:23 -0400 Subject: [Announce] GnuPG 2.1.13 released In-Reply-To: <87fusdkmzb.fsf@wheatstone.g10code.de> References: <87fusdkmzb.fsf@wheatstone.g10code.de> Message-ID: <87porgve1o.fsf@alice.fifthhorseman.net> On Thu 2016-06-16 14:27:52 -0400, Werner Koch wrote: > The GnuPG team is pleased to announce the availability of a new release > of GnuPG modern: Version 2.1.13. See below for new features and bug > fixes. Thank you Werner for this release, and to everyone who contributed work getting it ready! I've uploaded it into debian experimental, where it provides several packages, including gnupg, which ships /usr/bin/gpg. I'm hoping to make an upload to debian unstable in the near future (maybe next week), alongside an upload of 1.4.x that provides /usr/bin/gpg1. If you're a debian user or developer interested in gnupg, please try out the packages in experimental and report problems. 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 wk at gnupg.org Fri Jun 17 08:48:21 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 17 Jun 2016 08:48:21 +0200 Subject: tests/pkits failing on master (when building from git) In-Reply-To: <87bn31vsgr.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 16 Jun 2016 15:33:56 -0400") References: <5436FB65.2000306@fifthhorseman.net> <878ui3s1y5.fsf@alice.fifthhorseman.net> <87k31jubm3.fsf@vigenere.g10code.de> <87bn31vsgr.fsf@alice.fifthhorseman.net> Message-ID: <87twgsia4q.fsf@wheatstone.g10code.de> On Thu, 16 Jun 2016 21:33, dkg at fifthhorseman.net said: > These tests are still running (and failing) for me when i build master > From git. I've got automake 1.15 and automake 1.11 installed, fwiw. Do you mean tests/pkits are failing but you have not installed the pkits tarball? They should be skipped if PKITS_data.tar.bz2 is not installed. Frankly, I do not know whether the PKITS will still work. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ From wk at gnupg.org Fri Jun 17 08:49:55 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 17 Jun 2016 08:49:55 +0200 Subject: [Announce] GnuPG 2.1.13 released In-Reply-To: <85db5c5b-c608-b3ae-f2d4-dd279c59deea@sumptuouscapital.com> (Kristian Fiskerstrand's message of "Thu, 16 Jun 2016 21:40:29 +0200") References: <87fusdkmzb.fsf@wheatstone.g10code.de> <85db5c5b-c608-b3ae-f2d4-dd279c59deea@sumptuouscapital.com> Message-ID: <87porgia24.fsf@wheatstone.g10code.de> On Thu, 16 Jun 2016 21:40, kristian.fiskerstrand at sumptuouscapital.com said: >> * gpg: New option --with-subkey-fingerprint. > > Will this option be backported to older branches to provide a consistent > interface vs dual --with-fingerprint? The --with-subkey-fingerprint was required due to the new default key listsing format. It might make sense to implement it in 1.4 and 2.0 too - with slightly different semantics, though. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ From wk at gnupg.org Fri Jun 17 08:53:25 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 17 Jun 2016 08:53:25 +0200 Subject: [PATCH] g10: implement gpg --quick-revuid In-Reply-To: <1466114757-23740-1-git-send-email-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 16 Jun 2016 18:05:57 -0400") References: <1466114757-23740-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <87inx8i9wa.fsf@wheatstone.g10code.de> > This functionality is a counterpart to --quick-adduid, and will be > useful for projects that depend programmatically on gpg to revoke user > IDs (one such example is "monkeysphere-host revoke-servicename"). Looks good. I am going to apply it in a few days. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ From wk at gnupg.org Fri Jun 17 08:59:50 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 17 Jun 2016 08:59:50 +0200 Subject: Moving the agent's socket to /var/run ? In-Reply-To: <8737ocwybv.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 16 Jun 2016 18:41:56 -0400") References: <87k2lv5u0y.fsf@wheatstone.g10code.de> <87h9d3zu52.fsf@wheatstone.g10code.de> <8737ocwybv.fsf@alice.fifthhorseman.net> Message-ID: <87a8iki9ll.fsf@wheatstone.g10code.de> On Fri, 17 Jun 2016 00:41, dkg at fifthhorseman.net said: > Out of curiosity, how will this value be calculated if any of the > filesystems along the path to --homedir are case-insensitive? will Unix file systems should are case-insensitive. Right, you can mount a FAT file system but I am pretty sure that mounting a FAT file system at /run will raise a lot more problems. We do not use this on Windows Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ From rjh at sixdemonbag.org Fri Jun 17 09:04:25 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 17 Jun 2016 03:04:25 -0400 Subject: Moving the agent's socket to /var/run ? In-Reply-To: <87a8iki9ll.fsf@wheatstone.g10code.de> References: <87k2lv5u0y.fsf@wheatstone.g10code.de> <87h9d3zu52.fsf@wheatstone.g10code.de> <8737ocwybv.fsf@alice.fifthhorseman.net> <87a8iki9ll.fsf@wheatstone.g10code.de> Message-ID: <4a689c31-481a-a2cf-faa1-a3c9e6271f72@sixdemonbag.org> > Unix file systems should are case-insensitive. Neither POSIX nor SUS requires this. Mac OS X is a true-blue UNIX and has a case-insensitive filesystem. From wk at gnupg.org Fri Jun 17 11:14:28 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 17 Jun 2016 11:14:28 +0200 Subject: Moving the agent's socket to /var/run ? In-Reply-To: <4a689c31-481a-a2cf-faa1-a3c9e6271f72@sixdemonbag.org> (Robert J. Hansen's message of "Fri, 17 Jun 2016 03:04:25 -0400") References: <87k2lv5u0y.fsf@wheatstone.g10code.de> <87h9d3zu52.fsf@wheatstone.g10code.de> <8737ocwybv.fsf@alice.fifthhorseman.net> <87a8iki9ll.fsf@wheatstone.g10code.de> <4a689c31-481a-a2cf-faa1-a3c9e6271f72@sixdemonbag.org> Message-ID: <87mvmkgosr.fsf@wheatstone.g10code.de> On Fri, 17 Jun 2016 09:04, rjh at sixdemonbag.org said: > Neither POSIX nor SUS requires this. Mac OS X is a true-blue UNIX and They also do not describe sockets or other common features of UNIX. It seems OS X, HFS+ is case-preserving like very old Unix systems. Interesting that things work anyway. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ From wk at gnupg.org Fri Jun 17 11:19:25 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 17 Jun 2016 11:19:25 +0200 Subject: Request for Discussion: new/PubKeyDistributionConcept/FallbackServer In-Reply-To: <3C8BA21B-AC65-4411-B572-F92A41335316@tankredhase.de> (Tankred Hase's message of "Fri, 17 Jun 2016 00:11:33 +0200") References: <3C8BA21B-AC65-4411-B572-F92A41335316@tankredhase.de> Message-ID: <87d1nggoki.fsf@wheatstone.g10code.de> On Fri, 17 Jun 2016 00:11, mail at tankredhase.de said: > past few weeks for Mailvelope. It's a very simple key server that > borrows from Signal to allow TOFU m/automatic key lookup. No key Did you consider to give a talk at the OpenPGP.conf [1] to present your concept? Although the CfP ended, we are still looking for more presentations. Salam-Shalom, Werner [1] Cologne, September 8+9, https://gnupg.org/conf -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ From mail at tankredhase.de Fri Jun 17 12:02:41 2016 From: mail at tankredhase.de (Tankred Hase) Date: Fri, 17 Jun 2016 12:02:41 +0200 Subject: Request for Discussion: new/PubKeyDistributionConcept/FallbackServer In-Reply-To: <87d1nggoki.fsf@wheatstone.g10code.de> References: <3C8BA21B-AC65-4411-B572-F92A41335316@tankredhase.de> <87d1nggoki.fsf@wheatstone.g10code.de> Message-ID: <0382B357-4E46-444F-A564-A1957BEE6DF9@tankredhase.de> > Am 17.06.2016 um 11:19 schrieb Werner Koch : > > On Fri, 17 Jun 2016 00:11, mail at tankredhase.de said: > >> past few weeks for Mailvelope. It's a very simple key server that >> borrows from Signal to allow TOFU m/automatic key lookup. No key > > Did you consider to give a talk at the OpenPGP.conf [1] to present your > concept? Although the CfP ended, we are still looking for more > presentations. Yeah, I heard about the conference. Looks interesting. I?ll already be giving a talk at the OpenPGP Summit on 9./10. July [1] about: 1. OpenPGP.js v2.x [2] 2. OpenPGP.js v3.x roadmap (mainly ECC support) [3] 3. Mailvelope Key Server [4] So I guess it would make sense hold the same talk at OpenPGP.conf as well. The registration form on the website does not seem to be open yet. Is this enough as an informal registration or should I go through another channel? Thanks, Tankred [1] https://wiki.gnupg.org/OpenPGPEmailSummit201607 [2] https://github.com/openpgpjs/openpgpjs/releases/tag/v2.0.0 [3] https://github.com/openpgpjs/openpgpjs/milestones/v3.0 [4] https://github.com/mailvelope/keyserver From patrick at enigmail.net Fri Jun 17 12:42:20 2016 From: patrick at enigmail.net (Patrick Brunschwig) Date: Fri, 17 Jun 2016 12:42:20 +0200 Subject: Moving the agent's socket to /var/run ? In-Reply-To: <87mvmkgosr.fsf@wheatstone.g10code.de> References: <87k2lv5u0y.fsf@wheatstone.g10code.de> <87h9d3zu52.fsf@wheatstone.g10code.de> <8737ocwybv.fsf@alice.fifthhorseman.net> <87a8iki9ll.fsf@wheatstone.g10code.de> <4a689c31-481a-a2cf-faa1-a3c9e6271f72@sixdemonbag.org> <87mvmkgosr.fsf@wheatstone.g10code.de> Message-ID: <4a649c21-c3f2-4468-31e0-3a8646b7272b@enigmail.net> On 17.06.16 11:14, Werner Koch wrote: > On Fri, 17 Jun 2016 09:04, rjh at sixdemonbag.org said: > >> Neither POSIX nor SUS requires this. Mac OS X is a true-blue UNIX and > > They also do not describe sockets or other common features of UNIX. > > It seems OS X, HFS+ is case-preserving like very old Unix systems. > Interesting that things work anyway. Indeed, yes. Fortunately there is no /var/run/($id -u)/ directory on OS X, so we don't run into an issue if we derive a hash value from the home dir ;-) -Patrick From wk at gnupg.org Fri Jun 17 13:04:03 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 17 Jun 2016 13:04:03 +0200 Subject: Request for Discussion: new/PubKeyDistributionConcept/FallbackServer In-Reply-To: <0382B357-4E46-444F-A564-A1957BEE6DF9@tankredhase.de> (Tankred Hase's message of "Fri, 17 Jun 2016 12:02:41 +0200") References: <3C8BA21B-AC65-4411-B572-F92A41335316@tankredhase.de> <87d1nggoki.fsf@wheatstone.g10code.de> <0382B357-4E46-444F-A564-A1957BEE6DF9@tankredhase.de> Message-ID: <87porgf55o.fsf@wheatstone.g10code.de> On Fri, 17 Jun 2016 12:02, mail at tankredhase.de said: > So I guess it would make sense hold the same talk at OpenPGP.conf as > well. The registration form on the website does not seem to be open > yet. Is this enough as an informal registration or should I go through > another channel? You should send an abstract to the address given at gnupg.org/conf/cfp.html - don't care about the deadline. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ From wk at gnupg.org Fri Jun 17 13:06:18 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 17 Jun 2016 13:06:18 +0200 Subject: Moving the agent's socket to /var/run ? In-Reply-To: <4a649c21-c3f2-4468-31e0-3a8646b7272b@enigmail.net> (Patrick Brunschwig's message of "Fri, 17 Jun 2016 12:42:20 +0200") References: <87k2lv5u0y.fsf@wheatstone.g10code.de> <87h9d3zu52.fsf@wheatstone.g10code.de> <8737ocwybv.fsf@alice.fifthhorseman.net> <87a8iki9ll.fsf@wheatstone.g10code.de> <4a689c31-481a-a2cf-faa1-a3c9e6271f72@sixdemonbag.org> <87mvmkgosr.fsf@wheatstone.g10code.de> <4a649c21-c3f2-4468-31e0-3a8646b7272b@enigmail.net> Message-ID: <87inx8f51x.fsf@wheatstone.g10code.de> On Fri, 17 Jun 2016 12:42, patrick at enigmail.net said: > Fortunately there is no /var/run/($id -u)/ directory on OS X, so we > don't run into an issue if we derive a hash value from the home dir ;-) There are couple of other place where file names are compared. What a mess - I need to get one of these OS X boxes. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ From mail at tankredhase.de Fri Jun 17 14:56:28 2016 From: mail at tankredhase.de (Tankred Hase) Date: Fri, 17 Jun 2016 14:56:28 +0200 Subject: Request for Discussion: new/PubKeyDistributionConcept/FallbackServer In-Reply-To: <87porgf55o.fsf@wheatstone.g10code.de> References: <3C8BA21B-AC65-4411-B572-F92A41335316@tankredhase.de> <87d1nggoki.fsf@wheatstone.g10code.de> <0382B357-4E46-444F-A564-A1957BEE6DF9@tankredhase.de> <87porgf55o.fsf@wheatstone.g10code.de> Message-ID: > Am 17.06.2016 um 13:04 schrieb Werner Koch : > > You should send an abstract to the address given at > gnupg.org/conf/cfp.html - don't care about the deadline. Done! Looking forward to having a beer and ?fachsimpling? just like the first OpenPGP Summit :) You guys should really agree on a single conference. Not everyone can afford the travel budget to go to two :/ Tankred From wk at gnupg.org Fri Jun 17 17:17:25 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 17 Jun 2016 17:17:25 +0200 Subject: Request for Discussion: new/PubKeyDistributionConcept/FallbackServer In-Reply-To: (Tankred Hase's message of "Fri, 17 Jun 2016 14:56:28 +0200") References: <3C8BA21B-AC65-4411-B572-F92A41335316@tankredhase.de> <87d1nggoki.fsf@wheatstone.g10code.de> <0382B357-4E46-444F-A564-A1957BEE6DF9@tankredhase.de> <87porgf55o.fsf@wheatstone.g10code.de> Message-ID: <87mvmjetfe.fsf@wheatstone.g10code.de> On Fri, 17 Jun 2016 14:56, mail at tankredhase.de said: > Done! Looking forward to having a beer and ?fachsimpling? just like > the first OpenPGP Summit :) You guys should really agree on a single > conference. Not everyone can afford the travel budget to go to two :/ I am sorry, that it took us so long to find a date for the OpenPGP.conf. It was planned for last year, delayed, announced in the GUUG member's magazine in December, and further delayed. Nico asked me this spring how long it will take to us to find a date, I could not give a definitive answer, and, understandable, decided not to wait any longer and announced his own event. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ From meno.abels at adviser.com Fri Jun 17 22:10:15 2016 From: meno.abels at adviser.com (Meno Abels) Date: Fri, 17 Jun 2016 20:10:15 +0000 Subject: Tests on 2.1.13 fail on yosemite Message-ID: Hi, i just updated the formular of brew on the mac to 2.1.13. The automated tests show a odd behavior, any idea's? https://github.com/Homebrew/homebrew-versions/pull/1290#issuecomment-226868573 Meno -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Fri Jun 17 22:49:50 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 17 Jun 2016 16:49:50 -0400 Subject: Moving the agent's socket to /var/run ? In-Reply-To: <87a8iki9ll.fsf@wheatstone.g10code.de> References: <87k2lv5u0y.fsf@wheatstone.g10code.de> <87h9d3zu52.fsf@wheatstone.g10code.de> <8737ocwybv.fsf@alice.fifthhorseman.net> <87a8iki9ll.fsf@wheatstone.g10code.de> Message-ID: <87ziqjtua9.fsf@alice.fifthhorseman.net> One more wrinkle that i'm finding related to this setup -- what to do about overlong socket paths? This is a problem inherent in using the --standard-socket when GNUPGHOME is large on systems that have an upper-bound on socket names. But /run might offer a fix. I'm wondering whether it would make sense to use /run automatically on systems where /run/$UID/ is available and the standard-socket is prohibited by length (not just by filesystem type). On many systems, the name of unix-domain sockets has a formal limit, which is 108 bytes on linux: ------ /* unix-domain-socket-length.c */ #include #include #include int main() { struct sockaddr_un unix_addr; return printf ("maximum length of unix-domain socket: %zu bytes\n", sizeof(unix_addr.sun_path)); } ------ 0 dkg at alice:~/src/test$ gcc -o unix-domain-socket-length unix-domain-socket-length.c --pedantic -Wall 0 dkg at alice:~/src/test$ ./unix-domain-socket-length maximum length of unix-domain socket: 108 bytes 48 dkg at alice:~/src/test$ This means that it's not possible to open the standard socket in directories that are too long. fwiw, this isn't idle speculation. I work on monkeysphere in /home/dkg/src/monkeysphere/monkeysphere, which is 39 characters in length. the standard test suite operates in a tmpdir templated from the cwd as tmp/monkeyspheretest.XXXXXX (another 32 characters), and in the test suite tmpdir, there is a GNUPGHOME dir named authentication/sphere (another 21 characters). that's 92 characters already, and the 13 more of S.gnupg-agent itself alongside the trailing NUL and a few / characters pushes it over the limit. I'm avoiding this in monkeysphere right now by shortening the length of the tmpdir path and making sure i don't personally build it any deeper in the fs hierarchy than i have to. But it seems like it would be nice to get this to happen automatically, no? If it's possible to detect that a given path is too long for the underlying operating system to create a socket, why not automatically cut over to the shorter path in /run ? gpg-agent could auto-create the directory upon launch if it finds it can't auto-create the typical standard socket. it could auto-remove the directory when it terminates cleanly as well. --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 Fri Jun 17 23:22:43 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 17 Jun 2016 17:22:43 -0400 Subject: Tests on 2.1.13 fail on yosemite In-Reply-To: References: Message-ID: <87mvmjtsrg.fsf@alice.fifthhorseman.net> On Fri 2016-06-17 16:10:15 -0400, Meno Abels wrote: > i just updated the formular of brew on the mac to 2.1.13. > The automated tests show a odd behavior, any idea's? > > https://github.com/Homebrew/homebrew-versions/pull/1290#issuecomment-226868573 from the above webreport: -------- PASS: tofu.test FAIL: gpgtar.test PASS: use-exact-key.test PASS: default-key.test > D74C5F22 C40FDECF ECABF51D < PASS: export.test PASS: finish.test ======================================= 1 of 36 tests failed Please report to https://bugs.gnupg.org ======================================= make[3]: *** [check-TESTS] Error 1 make[2]: *** [check-am] Error 2 make[1]: *** [check-recursive] Error 1 make: *** [check-recursive] Error 1 -------- What's the contents of tests/openpgp/gpgtar.test.log ? --dkg From dkg at fifthhorseman.net Sat Jun 18 00:05:32 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 17 Jun 2016 18:05:32 -0400 Subject: tests/pkits failing on master (when building from git) In-Reply-To: <87twgsia4q.fsf@wheatstone.g10code.de> References: <5436FB65.2000306@fifthhorseman.net> <878ui3s1y5.fsf@alice.fifthhorseman.net> <87k31jubm3.fsf@vigenere.g10code.de> <87bn31vsgr.fsf@alice.fifthhorseman.net> <87twgsia4q.fsf@wheatstone.g10code.de> Message-ID: <87d1nftqs3.fsf@alice.fifthhorseman.net> On Fri 2016-06-17 02:48:21 -0400, Werner Koch wrote: > Do you mean tests/pkits are failing but you have not installed the pkits > tarball? They should be skipped if PKITS_data.tar.bz2 is not installed. I don't have that file anywhere in the build path. However, the tests are failing. > Frankly, I do not know whether the PKITS will still work. I'd be happy if i can skip them reliably :) --dkg From dominyktiller at gmail.com Sat Jun 18 01:59:17 2016 From: dominyktiller at gmail.com (Dominyk Tiller) Date: Sat, 18 Jun 2016 00:59:17 +0100 Subject: Tests on 2.1.13 fail on yosemite In-Reply-To: <87mvmjtsrg.fsf@alice.fifthhorseman.net> References: <87mvmjtsrg.fsf@alice.fifthhorseman.net> Message-ID: Hey Daniel, I'm the other guy in the thread there. I finally managed to reproduce the initial failure, although it took 10+ builds to get it to happen twice. Logs attached. ==== Sent from OS X. If you wish to communicate more securely my PGP Public Key is 0x872524db9d74326c. On 17/06/2016 22:22, Daniel Kahn Gillmor wrote: > On Fri 2016-06-17 16:10:15 -0400, Meno Abels wrote: >> i just updated the formular of brew on the mac to 2.1.13. >> The automated tests show a odd behavior, any idea's? >> >> https://github.com/Homebrew/homebrew-versions/pull/1290#issuecomment-226868573 > > from the above webreport: > > -------- > PASS: tofu.test > FAIL: gpgtar.test > PASS: use-exact-key.test > PASS: default-key.test > > D74C5F22 C40FDECF ECABF51D < > PASS: export.test > PASS: finish.test > ======================================= > 1 of 36 tests failed > Please report to https://bugs.gnupg.org > ======================================= > make[3]: *** [check-TESTS] Error 1 > make[2]: *** [check-am] Error 2 > make[1]: *** [check-recursive] Error 1 > make: *** [check-recursive] Error 1 > -------- > > What's the contents of tests/openpgp/gpgtar.test.log ? > > --dkg > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > -------------- next part -------------- Test: gpgtar.test GNUPGHOME=/private/tmp/gnupg21-20160617-26264-ehu3mc/gnupg-2.1.13/tests/openpgp gpgtar: gpg: encrypted with 1024-bit ELG key, ID 05A37887B27907AA, created 2003-12-31 gpgtar: gpg: "Test two (no pp) " gpgtar: gpg: encrypted with 1024-bit ELG key, ID 05A37887B27907AA, created 2003-12-31 gpgtar: gpg: "Test two (no pp) " gpgtar: gpg: encrypted with 1024-bit ELG key, ID 05A37887B27907AA, created 2003-12-31 gpgtar: gpg: "Test two (no pp) " gpgtar: gpg: Signature made Fri Jun 17 16:15:24 2016 PDT using RSA key ID D120B626ECABF51D gpgtar: gpg: Good signature from "Test three (no pp) " [unknown] gpgtar: gpg: WARNING: Using untrusted key! gpgtar: gpg: encrypted with 1024-bit ELG key, ID 05A37887B27907AA, created 2003-12-31 gpgtar: gpg: "Test two (no pp) " gpgtar: gpg: Signature made Fri Jun 17 16:15:24 2016 PDT using RSA key ID D120B626ECABF51D gpgtar: gpg: Good signature from "Test three (no pp) " [unknown] gpgtar: gpg: WARNING: Using untrusted key! gpgtar: gpg: Signature made Fri Jun 17 16:15:24 2016 PDT using RSA key ID D120B626ECABF51D gpgtar: gpg: Good signature from "Test three (no pp) " [unknown] gpgtar: gpg: WARNING: Using untrusted key! gpgtar: gpg: Signature made Fri Jun 17 16:15:24 2016 PDT using RSA key ID D120B626ECABF51D gpgtar: gpg: Good signature from "Test three (no pp) " [unknown] gpgtar: gpg: WARNING: Using untrusted key! gpgtar: gpg: AES encrypted data gpgtar: gpg: encrypted with 1 passphrase gpgtar: gpg: AES encrypted data gpgtar: gpg: encrypted with 1 passphrase gpgtar: error reading '[?]': premature EOF (size of last record: 0) -------------- next part -------------- Test: gpgtar.test GNUPGHOME=/private/tmp/gnupg21-20160617-26264-ehu3mc/gnupg-2.1.13/tests/openpgp gpgtar: gpg: encrypted with 1024-bit ELG key, ID 05A37887B27907AA, created 2003-12-31 gpgtar: gpg: "Test two (no pp) " gpgtar: [?]: warning: name not terminated by a nul byte gpgtar: [?]: invalid octal number encountered - assuming 0 gpgtar: [?]: invalid octal number encountered - assuming 0 gpgtar: [?]: warning: name not terminated by a nul byte gpgtar: [?]: invalid octal number encountered - assuming 0 gpgtar: [?]: invalid octal number encountered - assuming 0 gpgtar: [?]: invalid octal number encountered - assuming 0 gpgtar: [?]: invalid octal number encountered - assuming 0 gpgtar: [?]: warning: garbage after name gpgtar: [?]: invalid octal number encountered - assuming 0 gpgtar: [?]: invalid octal number encountered - assuming 0 gpgtar: error reading '[?]': premature EOF (size of last record: 0) From gniibe at fsij.org Tue Jun 21 01:42:55 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 21 Jun 2016 08:42:55 +0900 Subject: regression: card-edit/fetch doesn't work Message-ID: Hello, While I update the documentation of Gnuk, I found that card-edit/fetch doesn't work with GnuPG 2.1. The part is: http://www.fsij.org/doc-gnuk/using-gnuk-token-with-another-computer.html#fetch-the-public-key-and-connect-it-to-the-token With 2.0, it works well. I can export my public key by the command of "gpg -a --export" to put the ascii armored key on the web site, and let it serve request of card-edit/fetch. In 2.0, it is done by helper program gpg2keys_curl, and it works. In 2.1, it seems that it assumes a keyserver. -- From gniibe at fsij.org Tue Jun 21 03:53:09 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 21 Jun 2016 10:53:09 +0900 Subject: Missing Npth test In-Reply-To: <5729D546.8060804@fsij.org> References: <57286956.6030808@fsij.org> <878tzr2gdd.fsf@wheatstone.g10code.de> <5729D546.8060804@fsij.org> Message-ID: <75cd2bd8-432e-e295-1689-38f8f5c2dfb1@fsij.org> On 05/04/2016 07:56 PM, NIIBE Yutaka wrote: > Let me see if it works on AIX or not. Patch updated. I tested on: Platform: powerpc-ibm-aix7.1.3.0 I confirmed the failure of t-fork program with have_fork_unsafe_semaphore=no and the success with have_fork_unsafe_semaphore=yes diff --git a/configure.ac b/configure.ac index 84d34ff..f34857e 100644 --- a/configure.ac +++ b/configure.ac @@ -125,9 +125,15 @@ case "${host}" in *-apple-darwin*) AC_DEFINE(_XOPEN_SOURCE, 500, Activate POSIX interface on MacOS X) ;; + *-*-aix*) + have_fork_unsafe_semaphore=yes + ;; esac AM_CONDITIONAL(HAVE_LD_VERSION_SCRIPT, test "$have_ld_version_script" = "yes") +if test "$have_fork_unsafe_semaphore" = yes; then + AC_DEFINE(HAVE_FORK_UNSAFE_SEMAPHORE, 1, [Defined if we have fork-unsafe semaphore]) +fi # Set some default values config_libs="-lnpth" diff --git a/src/npth.c b/src/npth.c index 7de6c9d..c647c26 100644 --- a/src/npth.c +++ b/src/npth.c @@ -61,6 +61,32 @@ static sem_t sceptre_buffer; static sem_t *sceptre = &sceptre_buffer; +/* Configure defines HAVE_FORK_UNSAFE_SEMAPHORE if child process can't + access non-shared unnamed semaphore which is created by its parent. + + We use unnamed semaphore (if available) for the global lock. The + specific semaphore is only valid for those threads in a process, + and it is no use by other processes. Thus, PSHARED argument for + sem_init is naturally 0. + + However, there are daemon-like applications which use fork after + npth's initialization by npth_init. In this case, a child process + uses the semaphore which was created by its parent process, while + parent does nothing with the semaphore. In some system (e.g. AIX), + access by child process to non-shared unnamed semaphore is + prohibited. For such a system, HAVE_FORK_UNSAFE_SEMAPHORE should + be defined, so that unnamed semaphore will be created with the + option PSHARED=1. The purpose of the setting of PSHARED=1 is only + for allowing the access of the lock by child process. For NPTH, it + does not mean any other interactions between processes. + + */ +#ifdef HAVE_FORK_UNSAFE_SEMAPHORE +#define NPTH_SEMAPHORE_PSHARED 1 +#else +#define NPTH_SEMAPHORE_PSHARED 0 +#endif + /* The main thread is the active thread at the time pth_init was called. As of now it is only useful for debugging. The volatile make sure the compiler does not eliminate this set but not used @@ -181,8 +207,8 @@ npth_init (void) sem_init. */ errno = 0; - /* The semaphore is not shared and binary. */ - res = sem_init (sceptre, 0, 1); + /* The semaphore is binary. */ + res = sem_init (sceptre, NPTH_SEMAPHORE_PSHARED, 1); if (res < 0) { /* Mac OSX and some AIX versions have sem_init but return diff --git a/tests/Makefile.am b/tests/Makefile.am index 0dd436e..2a0542b 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -40,6 +40,7 @@ else AM_CPPFLAGS = -I../src -D_POSIX_C_SOURCE=200112L AM_LDFLAGS = LDADD = ../src/libnpth.la $(LIBSOCKET) $(LIB_CLOCK_GETTIME) +TESTS += t-fork endif noinst_HEADERS = t-support.h diff --git a/tests/t-fork.c b/tests/t-fork.c new file mode 100644 index 0000000..2f0b181 --- /dev/null +++ b/tests/t-fork.c @@ -0,0 +1,49 @@ +/* t-fork.c + * Copyright 2016 g10 Code GmbH + * + * This file is free software; as a special exception the author gives + * unlimited permission to copy and/or distribute it, with or without + * modifications, as long as this notice is preserved. + * + * This file is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY, to the extent permitted by law; without even the + * implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + */ + +#include +#include +#include +#include "t-support.h" + + +int +main (int argc, const char *argv[]) +{ + int rc; + pid_t pid; + + if (argc >= 2 && !strcmp (argv[1], "--verbose")) + opt_verbose = 1; + + rc = npth_init (); + fail_if_err (rc); + + pid = fork (); + if (pid == (pid_t)-1) + fail_msg ("fork failed"); + else if (pid) + { + int status; + + info_msg ("forked"); + wait (&status); + fail_if_err (status); + } + else + { + info_msg ("child exit"); + npth_usleep (1000); /* Let NPTH enter, sleep, and leave. */ + } + + return 0; +} -- From neal at walfield.org Tue Jun 21 12:15:44 2016 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 21 Jun 2016 12:15:44 +0200 Subject: feature request: automatically check OpenPGP signatures Message-ID: <87shw6q23z.wl-neal@walfield.org> Hi wget developers, It is unfortunately increasingly common that tutorials, howtos and installation programs do something like: wget --no-check-certificate https://some.server/path/install.sh chmod a+x install.sh ./install.sh Ouch! It would be great if wget had an option to specify an OpenPGP fingerprint that should be used to check a signature. I imagine something like this: wget --check-sig 8F17777118A33DDA9BA48E62AACB3243630052D9 http://... (The signature could either be inline, which would prevent the use of the file until the signature is verified, which is arguably good, or automatically looked for in a separate file called, say, filename.sig, by default.) For users who are just copying and pasting, this represents no additional work while adding a fair amount of protection. For developers, it is a bit more work, but they should be providing signatures anyways. For those who already provide signatures, this would help ensure that people actually check them and it would simplify the installation guides. See, for instance, tails: https://tails.boum.org/install/expert/usb/ Thanks for considering this feature request! :) Neal From rjh at sixdemonbag.org Tue Jun 21 13:59:53 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 21 Jun 2016 07:59:53 -0400 Subject: feature request: automatically check OpenPGP signatures In-Reply-To: <87shw6q23z.wl-neal@walfield.org> References: <87shw6q23z.wl-neal@walfield.org> Message-ID: > It is unfortunately increasingly common that tutorials, howtos and > installation programs do something like: > > wget --no-check-certificate https://some.server/path/install.sh > chmod a+x install.sh > ./install.sh Let me make sure I understand this: (a) People care so little about security they'll disable certificate checks, but (b) The same people who care so little about security will care enough about it to make OpenPGP signatures available. From neal at walfield.org Tue Jun 21 15:03:05 2016 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 21 Jun 2016 15:03:05 +0200 Subject: feature request: automatically check OpenPGP signatures In-Reply-To: References: <87shw6q23z.wl-neal@walfield.org> Message-ID: <87r3bqpud2.wl-neal@walfield.org> Hi, On Tue, 21 Jun 2016 13:59:53 +0200, Robert J. Hansen wrote: > > It is unfortunately increasingly common that tutorials, howtos and > > installation programs do something like: > > > > wget --no-check-certificate https://some.server/path/install.sh > > chmod a+x install.sh > > ./install.sh > > Let me make sure I understand this: > > (a) People care so little about security they'll disable certificate > checks, but > (b) The same people who care so little about security will care > enough about it to make OpenPGP signatures available. I have a less disingenuous take. The problem has to do with self-signed certificates. People have gone to the trouble of enabling TLS on their web servers (yeah!), but they don't want to pay for a certificate (which are of questionable value, anyways). This is starting to change thanks to Let's Encrypt, but Let's Encrypt has just started and the required tools are not yet integrated into stable OS distributions. Also, you ignore that this feature makes it easier for people to check signatures, which are already available. :) Neal From ben at adversary.org Tue Jun 21 19:46:54 2016 From: ben at adversary.org (Ben McGinnes) Date: Wed, 22 Jun 2016 03:46:54 +1000 Subject: Tests on 2.1.13 fail on yosemite In-Reply-To: References: Message-ID: <20160621174654.GD24753@adversary.org> On Fri, Jun 17, 2016 at 08:10:15PM +0000, Meno Abels wrote: > Hi, > > i just updated the formular of brew on the mac to 2.1.13. > The automated tests show a odd behavior, any idea's? Try explicitly specifying: --with-libassuan-prefix=/usr/local --with-libgpg-error-prefix=/usr/local --with-libgcrypt-prefix=/usr/local I'm assuming that brew will use /usr/local for all three of those, but if not then change them to wherever they're installed (I don't use brew, but I was able to replicate the error by leaving those out of a custom compile on Mavericks). Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: not available URL: From gniibe at fsij.org Wed Jun 22 01:19:59 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 22 Jun 2016 08:19:59 +0900 Subject: regression: card-edit/fetch doesn't work In-Reply-To: References: Message-ID: <23cecf11-8cac-442e-9132-73b8c17cca2e@fsij.org> On 06/21/2016 08:42 AM, NIIBE Yutaka wrote: > While I update the documentation of Gnuk, I found that card-edit/fetch > doesn't work with GnuPG 2.1. In 2.0, it seems that the helper program gpg2keys_curl supports both features of fetching a key file and retrieving from key server. If I understand correctly, card-edit/fetch (mainly) expects fetching a key (like gpg --fetch-key). The issue is that, the comments explicitly addresses the use cases of HKP and LDAP. Anyhow, here is a patch for --fetch-key like behavior: diff --git a/g10/card-util.c b/g10/card-util.c index be1a593..2cb44f9 100644 --- a/g10/card-util.c +++ b/g10/card-util.c @@ -733,28 +733,18 @@ fetch_url (ctrl_t ctrl) log_error("error retrieving URL from card: %s\n",gpg_strerror(rc)); else { - struct keyserver_spec *spec=NULL; - rc=agent_scd_getattr("KEY-FPR",&info); if(rc) log_error("error retrieving key fingerprint from card: %s\n", gpg_strerror(rc)); else if (info.pubkey_url && *info.pubkey_url) - { - spec = parse_keyserver_uri (info.pubkey_url, 1); - if(spec && info.fpr1valid) - { - /* This is not perfectly right. Currently, all card - fingerprints are 20 digits, but what about - fingerprints for a future v5 key? We should get the - length from somewhere lower in the code. In any - event, the fpr/keyid is not meaningful for straight - HTTP fetches, but using it allows the card to point - to HKP and LDAP servers as well. */ - rc = keyserver_import_fprint (ctrl, info.fpr1, 20, spec); - free_keyserver_spec(spec); - } - } + { + strlist_t sl = NULL; + + add_to_strlist (&sl, info.pubkey_url); + rc = keyserver_fetch (ctrl, sl); + free_strlist (sl); + } else if (info.fpr1valid) { rc = keyserver_import_fprint (ctrl, info.fpr1, 20, opt.keyserver); -- From neal at walfield.org Wed Jun 22 10:44:34 2016 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 22 Jun 2016 10:44:34 +0200 Subject: [Bug-wget] feature request: automatically check OpenPGP signatures In-Reply-To: <2959954.CRXXnN5IvM@blitz-lx> References: <87shw6q23z.wl-neal@walfield.org> <2959954.CRXXnN5IvM@blitz-lx> Message-ID: <87por9pq8d.wl-neal@walfield.org> Hi Tim, On Wed, 22 Jun 2016 10:33:50 +0200, Tim Ruehsen wrote: > there already is a standard for such things, called Metalink, supported by > wget (and most other download tools). The standard also contains support for > OpenPGP signatures. I wasn't aware of this. Thanks for pointing it out! :) Neal From wk at gnupg.org Wed Jun 22 18:09:55 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 22 Jun 2016 18:09:55 +0200 Subject: regression: card-edit/fetch doesn't work In-Reply-To: <23cecf11-8cac-442e-9132-73b8c17cca2e@fsij.org> (NIIBE Yutaka's message of "Wed, 22 Jun 2016 08:19:59 +0900") References: <23cecf11-8cac-442e-9132-73b8c17cca2e@fsij.org> Message-ID: <87wplhtdbg.fsf@wheatstone.g10code.de> On Wed, 22 Jun 2016 01:19, gniibe at fsij.org said: > If I understand correctly, card-edit/fetch (mainly) expects fetching a > key (like gpg --fetch-key). The issue is that, the comments IIRC, historically it was the other way around. But you are right card-edit/fetch should behave exactly like --fetch-key. > Anyhow, here is a patch for --fetch-key like behavior: Cool. Please push. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ From gniibe at fsij.org Fri Jun 24 03:28:44 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 24 Jun 2016 10:28:44 +0900 Subject: regression: card-edit/fetch doesn't work In-Reply-To: <87wplhtdbg.fsf@wheatstone.g10code.de> References: <23cecf11-8cac-442e-9132-73b8c17cca2e@fsij.org> <87wplhtdbg.fsf@wheatstone.g10code.de> Message-ID: <727fe27d-281c-c9f5-8585-218c4afd2d53@fsij.org> On 06/23/2016 01:09 AM, Werner Koch wrote: > Cool. Please push. Pushed. And I realized that this can be applied to 2.0 and fixes the issue1828. https://bugs.gnupg.org/gnupg/issue1828 Shall I apply it to 2.0? -- From wk at gnupg.org Fri Jun 24 09:40:06 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 24 Jun 2016 09:40:06 +0200 Subject: regression: card-edit/fetch doesn't work In-Reply-To: <727fe27d-281c-c9f5-8585-218c4afd2d53@fsij.org> (NIIBE Yutaka's message of "Fri, 24 Jun 2016 10:28:44 +0900") References: <23cecf11-8cac-442e-9132-73b8c17cca2e@fsij.org> <87wplhtdbg.fsf@wheatstone.g10code.de> <727fe27d-281c-c9f5-8585-218c4afd2d53@fsij.org> Message-ID: <87oa6rm3vt.fsf@wheatstone.g10code.de> On Fri, 24 Jun 2016 03:28, gniibe at fsij.org said: > https://bugs.gnupg.org/gnupg/issue1828 > > Shall I apply it to 2.0? Yes, please. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ From bernhard at intevation.de Mon Jun 27 17:49:20 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 27 Jun 2016 17:49:20 +0200 Subject: [solved] Re: Web Key Directory (dealing with subaddressing?) In-Reply-To: <201606010952.20102.bernhard@intevation.de> References: <201605171507.41446.bernhard@intevation.de> <87r3cz8irr.fsf@wheatstone.g10code.de> <201606010952.20102.bernhard@intevation.de> Message-ID: <201606271749.24343.bernhard@intevation.de> Am Mittwoch, 1. Juni 2016 09:52:16 schrieb Bernhard Reiter: > > > What about the common pattern of subaddressing? > > > > Still part of the local-part thus it does not matter. ?It is an open > > question on how to handle such sub-addressing. ?I discussed this in > > detail with Neal while thinking about TOFU; our conclusion was that it > > is to early to settle for a standard on how to canonicalize such > > addresses. If that makes sense at all. > > The server must know, as it will do the email routing. > This is why me (and I believe ?Guilhem, too) think that > transfering the original localpart to the server and let the > server do the decisions about an and if to handle this > maybe be a good idea to consider further. Last week Werner and Andre (that I had the pleasure to meet in person) convinced me that doing the canonicalisation and hasing on client side is a good approach. What convinced me is, that the client also will have to "interpret" the local-part, when it compares the user-id of the returning pubkey to the email-address it wants to encrypt and send email to. Thus it makes sense to use a common interpretation on client-side anyway. And if we do that, why not hash right away to make the server implementations easier. We can just let aliases and subaddresses be interpreted as additional "email-identities". As for case-insensitivity in the local part, I believe it is okay to ignore rarely used RFC parts in order to get a system up and running for the common case. Bernhard -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From gniibe at fsij.org Tue Jun 28 02:41:53 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 28 Jun 2016 09:41:53 +0900 Subject: [PATCH] opt.list_packets Message-ID: <7f53bfe1-c92a-f4ab-14f3-5a79d9b794b0@fsij.org> Hello, Since this is a quite long-standing bug (exists even < 1.0), I'm writing to this list. In the function do_proc_packets (g10/mainproc.c), it says: /* Stop processing when an invalid packet has been encountered * but don't do so when we are doing a --list-packets. */ However, it stops always, because opt.list_packets is never 2 when running this function. We have a function, set_packet_list_mode which sets the variable list_mode, and we have opt.list_packets which is set by command line option. It seemed that once it was tried to integrate list_mode and opt.list_packets, with the value of 2 for opt.list_packets, but it had never been worked as expected. Before the fix of mine, it goes like that: (1) opt.list_packets is assigned to 2 (2) set_packet_list_mode is called When opt.list_packets == 2, stdout is selected as output (3) opt.list_packets is assigend to 1 (4) do_proc_packets is called with opt.list_packets==1 I do think the assignment to the variable like opt.list_packets should be one time, yes, once and all. I don't usually introduce semantics change of variable or function when I fix something, but this is a fix for a bug with wrong semantics. Please accept this exception. Here are the changes. * --list-packets enables keeping running after invalid packet * opt.list_packets is set to 1 with --list-packets * With --list-packets, set_packet_list_mode is called after the assignment of opt.list_packets I'm going to apply this change to 1.4, 2.0, and 2.1. ================================== diff --git a/g10/gpg.c b/g10/gpg.c index ef27562..9750c57 100644 --- a/g10/gpg.c +++ b/g10/gpg.c @@ -4656,7 +4656,6 @@ main (int argc, char **argv) break; case aListPackets: - opt.list_packets=2; default: if( argc > 1 ) wrong_args(_("[filename]")); @@ -4685,8 +4684,8 @@ main (int argc, char **argv) } } if( cmd == aListPackets ) { - set_packet_list_mode(1); opt.list_packets=1; + set_packet_list_mode(1); } rc = proc_packets (ctrl, NULL, a ); if( rc ) diff --git a/g10/mainproc.c b/g10/mainproc.c index bd738ab..c191fe0 100644 --- a/g10/mainproc.c +++ b/g10/mainproc.c @@ -1328,7 +1328,7 @@ do_proc_packets (ctrl_t ctrl, CTX c, iobuf_t a) /* Stop processing when an invalid packet has been encountered * but don't do so when we are doing a --list-packets. */ if (gpg_err_code (rc) == GPG_ERR_INV_PACKET - && opt.list_packets != 2 ) + && opt.list_packets == 0) break; continue; } diff --git a/g10/options.h b/g10/options.h index 4279bd6..fc333cd 100644 --- a/g10/options.h +++ b/g10/options.h @@ -80,7 +80,7 @@ struct int print_pka_records; int print_dane_records; int no_armor; - int list_packets; /* list-packets mode: 1=normal, 2=invoked by command*/ + int list_packets; /* Option --list-packets active. */ int def_cipher_algo; int force_mdc; int disable_mdc; diff --git a/g10/parse-packet.c b/g10/parse-packet.c index 1c1b389..ec8a641 100644 --- a/g10/parse-packet.c +++ b/g10/parse-packet.c @@ -211,7 +211,7 @@ set_packet_list_mode (int mode) enable the list mode only with a special option. */ if (!listfp) { - if (opt.list_packets == 2) + if (opt.list_packets) { listfp = es_stdout; if (opt.verbose) -- From wk at gnupg.org Tue Jun 28 08:03:39 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 28 Jun 2016 08:03:39 +0200 Subject: [PATCH] opt.list_packets In-Reply-To: <7f53bfe1-c92a-f4ab-14f3-5a79d9b794b0@fsij.org> (NIIBE Yutaka's message of "Tue, 28 Jun 2016 09:41:53 +0900") References: <7f53bfe1-c92a-f4ab-14f3-5a79d9b794b0@fsij.org> Message-ID: <877fd9alz8.fsf@wheatstone.g10code.de> On Tue, 28 Jun 2016 02:41, gniibe at fsij.org said: > It seemed that once it was tried to integrate list_mode and > opt.list_packets, with the value of 2 for opt.list_packets, but it had > never been worked as expected. There have been many changes with --list-apckets in the early years. I implemented it as a debug helper and put not much thought into it. Thanks for comimg up with a real solution. > I don't usually introduce semantics change of variable or function > when I fix something, but this is a fix for a bug with wrong > semantics. Please accept this exception. Sure. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ From aheinecke at intevation.de Tue Jun 28 14:04:41 2016 From: aheinecke at intevation.de (Andre Heinecke) Date: Tue, 28 Jun 2016 14:04:41 +0200 Subject: Only grab keyboard when line edits have focus in pinentry (qt) Message-ID: <1865128.hvf1RZ7cfB@esus> Hi, When I recently changed pinentry-qt to also support the "repeat" mode (meaning two password entries in one dialog for key generation) I had to change the keyboard grabbing so that it would work for both line edits. In that commit I've changed that pinentry-qt now only grabs the keyboard when a password line edit has input focus. To my knowledge this still protects against keyloggers which simply capture all X-Events and thus does not reduce the security over the old "globally grab as soon as we are visible" behavior. This has the added advantage that you still can continue to work when pinentry pops up and for example, look up the passphrase for a key in another encrypted file without having to minimize pinentry-qt. But maybe I've missed some attack that is mitigated by the global grabbing behavoir, so if you have concerns about that please let me know so that we can discuss this before we release pinentry with this change. Regards, Andre 1: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git;a=commit;h=04115b3289dcc9b02044f88c08580618c055a571 -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: This is a digitally signed message part. URL: From justus at g10code.com Tue Jun 28 15:37:29 2016 From: justus at g10code.com (Justus Winter) Date: Tue, 28 Jun 2016 15:37:29 +0200 Subject: Tests on 2.1.13 fail on yosemite In-Reply-To: References: <87mvmjtsrg.fsf@alice.fifthhorseman.net> Message-ID: <87d1n1juxy.fsf@europa.jade-hamburg.de> Hi :) Dominyk Tiller writes: > I finally managed to reproduce the initial failure, although it took 10+ > builds to get it to happen twice. Logs attached. I fixed that in 8f79c31b. Cheers, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From dkg at fifthhorseman.net Tue Jun 28 17:08:22 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 28 Jun 2016 11:08:22 -0400 Subject: Only grab keyboard when line edits have focus in pinentry (qt) In-Reply-To: <1865128.hvf1RZ7cfB@esus> References: <1865128.hvf1RZ7cfB@esus> Message-ID: <87lh1pe4gp.fsf@alice.fifthhorseman.net> Hi Andre-- On Tue 2016-06-28 08:04:41 -0400, Andre Heinecke wrote: > When I recently changed pinentry-qt to also support the "repeat" mode (meaning > two password entries in one dialog for key generation) I had to change the > keyboard grabbing so that it would work for both line edits. > > In that commit I've changed that pinentry-qt now only grabs the keyboard when > a password line edit has input focus. To my knowledge this still protects > against keyloggers which simply capture all X-Events and thus does not reduce > the security over the old "globally grab as soon as we are visible" behavior. > > This has the added advantage that you still can continue to work when pinentry > pops up and for example, look up the passphrase for a key in another encrypted > file without having to minimize pinentry-qt. > > But maybe I've missed some attack that is mitigated by the global grabbing > behavoir, so if you have concerns about that please let me know so that we can > discuss this before we release pinentry with this change. I've always thought there are two different (but complementary) use cases for keyboard-grabbing: a) malicious X11 (or other) applications sniffing the keyboard activity. b) user confusion about window focus (e.g. typing your password into your chat client by accident when you think you're typing in your pinentry) I think the change you've made still satisfies use case (a), but i think it might lose something for use case (b). Maybe other people don't care about use case (b); if so, that's fine. For myself, i often have enough things running concurrently (and can become sufficiently distracted) that global kbd grab probably saves me from making that particular mistake about once or twice a month. --dkg From bernhard at intevation.de Tue Jun 28 17:16:03 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 28 Jun 2016 17:16:03 +0200 Subject: keys.mailvelope.com (Re: Request for Discussion: new/PubKeyDistributionConcept/FallbackServer) In-Reply-To: <3C8BA21B-AC65-4411-B572-F92A41335316@tankredhase.de> References: <3C8BA21B-AC65-4411-B572-F92A41335316@tankredhase.de> Message-ID: <201606281716.08588.bernhard@intevation.de> Hi Trankred, Am Freitag, 17. Juni 2016 00:11:33 schrieb Tankred Hase: > I saw the discussion and thought I'd share what we've built in the past few > weeks for Mailvelope. It's a very simple key server that borrows from > Signal to allow TOFU m/automatic key lookup. No key transparency included: > > https://keys.mailvelope.com thanks for sharing your work! I gave it a brief look. Is my understanding good that you don't do a crypto challenge to check for the ownership of secret key. How did you consider privacy issues (like people in Germany demanding that you delete their personal information) or spam? Is this going to be like I first thought about a fallback server, so can I take this as a statement that Mailvelope is going to implement https://wiki.gnupg.org/EasyGpg2016/PubkeyDistributionConcept ? :) Best Regards, Bernhard -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Tue Jun 28 17:25:34 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 28 Jun 2016 17:25:34 +0200 Subject: Request for Discussion: new/PubKeyDistributionConcept/FallbackServer In-Reply-To: <874m8urff6.wl-neal@walfield.org> References: <201605041751.51371.bernhard@intevation.de> <201606151026.19672.bernhard@intevation.de> <874m8urff6.wl-neal@walfield.org> Message-ID: <201606281725.34319.bernhard@intevation.de> Am Mittwoch, 15. Juni 2016 11:04:45 schrieb Neal H. Walfield: > To prevent a MitM, you need a secure channel. ?You can decrease the > change of a MitM be using multiple insecure channels. ?These insecure > channels can be either in space (different network routes) or time > (last year, last month and yesterday). ?This is what TOFU exploits. Given that receiving and sending emails will all go over the MSP that a particular user is using, several email contacts over time will not help TOFU much. > WKD uses a single insecure channel multiple times. ? > This does not add trust. At least other parties (with different network routes) or the user going to a different networks access (e.g. while travelling) would increase the chances of detecting an MSP MitM attack. With just several email contacts over time the chance of detection is much lower because the MSP does not have to make the pubkey it hands out public. (: Bernhard -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Tue Jun 28 17:41:59 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 28 Jun 2016 17:41:59 +0200 Subject: python bindings for gpgme In-Reply-To: <20160606152047.10010.70223@thinkbox.jade-hamburg.de> References: <201605311439.22496.bernhard@intevation.de> <201606011754.43709.bernhard@intevation.de> <20160606152047.10010.70223@thinkbox.jade-hamburg.de> Message-ID: <201606281742.04788.bernhard@intevation.de> Hi Justus, talking to Werner last week I felt a potential missunderstanding. To clarify: Am Montag, 6. Juni 2016 17:20:47 schrieb Justus Winter: > So until someone here actually provides a > constructive critique of the current pyme API, I'm going to sand-off > the edges that would annoy me the most. Your and Ben's efforts towards better and official python support for gpgme are highly appreciated by me! My remarks in the last month aimed towards supporting you in this work. In my personal experience good technical decisions come out of pondering alternatives. I was trying to show my respect towards you by asking questions that I would have liked to be asked. If this felt unconstructive to you, I appologize. Please go ahead to have an official python-gpgme soon. Best Regards, Bernhard -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From dkg at fifthhorseman.net Tue Jun 28 21:17:14 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 28 Jun 2016 15:17:14 -0400 Subject: [PATCH] g10: implement gpg --quick-revuid In-Reply-To: <87inx8i9wa.fsf@wheatstone.g10code.de> References: <1466114757-23740-1-git-send-email-dkg@fifthhorseman.net> <87inx8i9wa.fsf@wheatstone.g10code.de> Message-ID: <87furxdsxx.fsf@alice.fifthhorseman.net> On Fri 2016-06-17 02:53:25 -0400, Werner Koch wrote: >> This functionality is a counterpart to --quick-adduid, and will be >> useful for projects that depend programmatically on gpg to revoke user >> IDs (one such example is "monkeysphere-host revoke-servicename"). > > Looks good. I am going to apply it in a few days. Any word on this? i don't think it has been applied yet. does it need anything? --dkg From bernhard at intevation.de Wed Jun 29 10:22:22 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 29 Jun 2016 10:22:22 +0200 Subject: Only grab keyboard when line edits have focus in pinentry (qt) In-Reply-To: <87lh1pe4gp.fsf@alice.fifthhorseman.net> References: <1865128.hvf1RZ7cfB@esus> <87lh1pe4gp.fsf@alice.fifthhorseman.net> Message-ID: <201606291022.27393.bernhard@intevation.de> Am Dienstag, 28. Juni 2016 17:08:22 schrieb Daniel Kahn Gillmor: > ?b) user confusion about window focus (e.g. typing your password into > ? ? your chat client by accident when you think you're typing in your > ? ? pinentry) How does that happen in detail? Are you refering to the following case: You start typing in the pinentry and after the third key you have pressed, a new, different window pops up and the fourth key goes to that window? Or is it: You see the pinentry, but your keyboard focus is elsewhere, so you start typing, but the first key goes to the other window (which still had the focus). > i think it might lose something for use case (b). ? > Maybe other people don't care > about use case (b); if so, that's fine. ?For myself, i often have enough > things running concurrently (and can become sufficiently distracted) > that global kbd grab probably saves me from making that particular > mistake about once or twice a month. Bernhard -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Wed Jun 29 13:31:49 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 29 Jun 2016 13:31:49 +0200 Subject: [PATCH] g10: implement gpg --quick-revuid In-Reply-To: <87furxdsxx.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 28 Jun 2016 15:17:14 -0400") References: <1466114757-23740-1-git-send-email-dkg@fifthhorseman.net> <87inx8i9wa.fsf@wheatstone.g10code.de> <87furxdsxx.fsf@alice.fifthhorseman.net> Message-ID: <87k2h844ey.fsf@wheatstone.g10code.de> On Tue, 28 Jun 2016 21:17, dkg at fifthhorseman.net said: > Any word on this? i don't think it has been applied yet. does it need > anything? It is still ticked in my inbox ... Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ From aheinecke at intevation.de Wed Jun 29 15:04:13 2016 From: aheinecke at intevation.de (Andre Heinecke) Date: Wed, 29 Jun 2016 15:04:13 +0200 Subject: Only grab keyboard when line edits have focus in pinentry (qt) In-Reply-To: <201606291022.27393.bernhard@intevation.de> References: <1865128.hvf1RZ7cfB@esus> <87lh1pe4gp.fsf@alice.fifthhorseman.net> <201606291022.27393.bernhard@intevation.de> Message-ID: <9122063.jun5QvPei1@esus> Hi, On Wednesday 29 June 2016 10:22:22 Bernhard Reiter wrote: > Am Dienstag, 28. Juni 2016 17:08:22 schrieb Daniel Kahn Gillmor: > > b) user confusion about window focus (e.g. typing your password into > > your chat client by accident when you think you're typing in your > > pinentry) > > How does that happen in detail? > Are you refering to the following case: > You start typing in the pinentry and after the third key you have pressed, > a new, different window pops up and the fourth key goes to that window? Imo this would be an agressive (like pinentry) other window that also tries to "steal" the focus which is generally a bad usability choice and you don't see something like that often. But yes this could happen when previously it required that pinentry was minimized. > Or is it: > You see the pinentry, but your keyboard focus is elsewhere, so you start > typing, but the first key goes to the other window (which still had the > focus). I think that case is covered because pinentry still pops up in the foreground and sets the focus to the line edit (which then also grabs the keyboard). > > i think it might lose something for use case (b). > > Maybe other people don't care As case b) is more of a usability problem and not a technical vulnerability my personal weighing would be that the global grab is the bigger usability problem then the chance that you accidentally input secrets into the wrong window. I've also seen no other password entry, yet, that globally grabs the keyboard and so I think that users may find this unexpected with pinentry. > > about use case (b); if so, that's fine. For myself, i often have enough > > things running concurrently (and can become sufficiently distracted) > > that global kbd grab probably saves me from making that particular > > mistake about once or twice a month. Ok your experience there differes from mine I have never felt that the global grab saved me from anything but often felt "aaah damn, forgot to decrypt the passphrase before signing this file". Because I regularly have to look up the passphrase for other keys in encrypted files so for me having multiple pinentries active / decrypting a file containting a passphrase while pinentry is open is a regular use case for me and for that the "less agressive" grabbing is an advantage. The global grab is actually a reason why I like to use a smartcard reader with a pinpad. Imo as pinentry is already very diverse we could just keep the global grab in GTK and do the focused Grab in Qt and thus offer a good solution for both cases. Hurray for diversity. :-) Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: This is a digitally signed message part. URL: From dkg at fifthhorseman.net Thu Jun 30 07:30:55 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 30 Jun 2016 01:30:55 -0400 Subject: Only grab keyboard when line edits have focus in pinentry (qt) In-Reply-To: <201606291022.27393.bernhard@intevation.de> References: <1865128.hvf1RZ7cfB@esus> <87lh1pe4gp.fsf@alice.fifthhorseman.net> <201606291022.27393.bernhard@intevation.de> Message-ID: <87oa6j2qgg.fsf@alice.fifthhorseman.net> On Wed 2016-06-29 04:22:22 -0400, Bernhard Reiter wrote: > [ Unknown signature status ] > Am Dienstag, 28. Juni 2016 17:08:22 schrieb Daniel Kahn Gillmor: >> ?b) user confusion about window focus (e.g. typing your password into >> ? ? your chat client by accident when you think you're typing in your >> ? ? pinentry) > > How does that happen in detail? > Are you refering to the following case: > You start typing in the pinentry and after the third key you have pressed, > a new, different window pops up and the fourth key goes to that window? > > Or is it: > You see the pinentry, but your keyboard focus is elsewhere, so you start > typing, but the first key goes to the other window (which still had the > focus). fwiw, i've seen both things happen. it's also possible that the focus is in the pinentry, but slips out (e.g. due to mouse wiggle on focus-follows-mouse systems, or accidental "heel-click" of tap-to-click trackpads). --dkg From bernhard at intevation.de Thu Jun 30 09:13:21 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 30 Jun 2016 09:13:21 +0200 Subject: Only grab keyboard when line edits have focus in pinentry (qt) In-Reply-To: <87oa6j2qgg.fsf@alice.fifthhorseman.net> References: <1865128.hvf1RZ7cfB@esus> <201606291022.27393.bernhard@intevation.de> <87oa6j2qgg.fsf@alice.fifthhorseman.net> Message-ID: <201606300913.25466.bernhard@intevation.de> Am Donnerstag, 30. Juni 2016 07:30:55 schrieb Daniel Kahn Gillmor: > fwiw, i've seen both things happen. ?it's also possible that the focus > is in the pinentry, but slips out (e.g. due to mouse wiggle on > focus-follows-mouse systems, or accidental "heel-click" of tap-to-click > trackpads). What is the situation happening to you that you refered to as | For myself, i often have enough | things running concurrently (and can become sufficiently distracted) | that global kbd grab probably saves me from making that particular | mistake about once or twice a month. (I've just asked to understand more about how this undesired behaviour "happens" to you.) -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Thu Jun 30 09:23:16 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 30 Jun 2016 09:23:16 +0200 Subject: keys.mailvelope.com (Re: Request for Discussion: new/PubKeyDistributionConcept/FallbackServer) In-Reply-To: <146713027693.9988.4603459167281847325@solidarity.enteig.net> References: <3C8BA21B-AC65-4411-B572-F92A41335316@tankredhase.de> <201606281716.08588.bernhard@intevation.de> <146713027693.9988.4603459167281847325@solidarity.enteig.net> Message-ID: <201606300923.16760.bernhard@intevation.de> Hi Malte, Am Dienstag, 28. Juni 2016 18:11:16 schrieb malte at wk3.org: > Quoting Bernhard Reiter (2016-06-28 17:16:03) > > > https://keys.mailvelope.com > > I gave it a brief look. > > Is my understanding good that you don't do a crypto challenge > > to check for the ownership of secret key. > > As the website (https://keys.mailvelope.com/) says: > > """ > Verify Yourself > > The server verifies email address ownership as well as private key > ownership by sending an encrypted verification email. > """ Ah, thanks for pointing this out. (There was no mention of this on the detailed README.md, so I overlooked it.) > > How did you consider privacy issues (like people in Germany demanding > > that you delete their personal information) or spam? > > As the website says: > > """ > No Web of Trust > > No more key signing parties or publishing your social network online. > You can even delete your public key at anytime. Learn more > """ Because deletion needs verification, I can spam each email owner by demanding deletion of the key? How is walking the keyserver be prevented? Best, Bernhard -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Thu Jun 30 12:03:11 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 30 Jun 2016 12:03:11 +0200 Subject: [PATCH] g10: implement gpg --quick-revuid In-Reply-To: <1466114757-23740-1-git-send-email-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 16 Jun 2016 18:05:57 -0400") References: <1466114757-23740-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <87oa6juh7k.fsf@wheatstone.g10code.de> Thanks for the pacth. I applied it with these modifications - Minor re-indentation work. - Changed a "0 == memcmp" to "!memcmp" - Removed tests/openpgp/quick-key-manipulation.test from the Makefile. This test needs to be converted to gpgscm. - Removed example from whats-new-in-2.1.txt because that is generated. I also pushed the example to the gnupg-doc repo. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From dkg at fifthhorseman.net Thu Jun 30 17:30:57 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 30 Jun 2016 11:30:57 -0400 Subject: Only grab keyboard when line edits have focus in pinentry (qt) In-Reply-To: <201606300913.25466.bernhard@intevation.de> References: <1865128.hvf1RZ7cfB@esus> <201606291022.27393.bernhard@intevation.de> <87oa6j2qgg.fsf@alice.fifthhorseman.net> <201606300913.25466.bernhard@intevation.de> Message-ID: <87a8i23d8u.fsf@alice.fifthhorseman.net> On Thu 2016-06-30 03:13:21 -0400, Bernhard Reiter wrote: > [ Unknown signature status ] > Am Donnerstag, 30. Juni 2016 07:30:55 schrieb Daniel Kahn Gillmor: >> fwiw, i've seen both things happen. ?it's also possible that the focus >> is in the pinentry, but slips out (e.g. due to mouse wiggle on >> focus-follows-mouse systems, or accidental "heel-click" of tap-to-click >> trackpads). > > What is the situation happening to you that you refered to as > | For myself, i often have enough > | things running concurrently (and can become sufficiently distracted) > | that global kbd grab probably saves me from making that particular > | mistake about once or twice a month. > > (I've just asked to understand more about how this undesired behaviour > "happens" to you.) just what i've said above: * mouse wiggle on focus-follows-mouse systems -- when you cross a window boundary, the focus moves to the other window, even though the keyboard is grabbed and signals can't be sent to the other window that now has the focus. I recognize that focus-follows-mouse isn't a popular UI paradigm these days, and that most systems use click-to-raise-and-focus. * "heel-click" on tap-to-click trackpads -- this doesn't happen as often to me because i disable any trackpad i'm capable of disabling :) but it's a risk for folks who use click-to-raise-and-focus with a trackpad. by "heel-click" i mean that the heel (lower palm) of your hand brushes against the trackpad and registers as an accidental click. maybe neither of these things ever happen to anyone else? --dkg From dkg at fifthhorseman.net Thu Jun 30 17:40:21 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 30 Jun 2016 11:40:21 -0400 Subject: Only grab keyboard when line edits have focus in pinentry (qt) In-Reply-To: <9122063.jun5QvPei1@esus> References: <1865128.hvf1RZ7cfB@esus> <87lh1pe4gp.fsf@alice.fifthhorseman.net> <201606291022.27393.bernhard@intevation.de> <9122063.jun5QvPei1@esus> Message-ID: <878txm3ct6.fsf@alice.fifthhorseman.net> On Wed 2016-06-29 09:04:13 -0400, Andre Heinecke wrote: > As case b) is more of a usability problem and not a technical > vulnerability my personal weighing would be that the global grab is > the bigger usability problem then the chance that you accidentally > input secrets into the wrong window. usability problems and technical vulnerabilities are not mutually exclusive :) i don't know whether i've ever had a malicious application try to snoop my passphrases, but i've *definitely* had situations where i was saved by the keygrab from mistyping my passphrase into the wrong window. > Ok your experience there differes from mine I have never felt that the > global grab saved me from anything but often felt "aaah damn, forgot > to decrypt the passphrase before signing this file". Because I > regularly have to look up the passphrase for other keys in encrypted > files so for me having multiple pinentries active / decrypting a file > containting a passphrase while pinentry is open is a regular use case > for me and for that the "less agressive" grabbing is an advantage. sure, i understand this frustration and have run into it myself. It suggests to me that my passphrase-caching mechanism isn't sufficiently integrated into my workflow, not that kbd-grabbing is the wrong approach. > The global grab is actually a reason why I like to use a smartcard > reader with a pinpad. for security purposes, i'd love to see a pinentry that relies on inputs/signalling from outside X11 entirely. > Imo as pinentry is already very diverse we could just keep the global > grab in GTK and do the focused Grab in Qt and thus offer a good > solution for both cases. Hurray for diversity. :-) Sure, i'm not trying to force any one pattern, i'm just observing that this change would probably remove a major security benefit that i've seen in the past (albeit a security benefit that defends against clumsiness, not against a wilful adversary) --dkg From dominyktiller at gmail.com Thu Jun 30 21:31:41 2016 From: dominyktiller at gmail.com (Dominyk Tiller) Date: Thu, 30 Jun 2016 20:31:41 +0100 Subject: Tests on 2.1.13 fail on yosemite In-Reply-To: <87d1n1juxy.fsf@europa.jade-hamburg.de> References: <87mvmjtsrg.fsf@alice.fifthhorseman.net> <87d1n1juxy.fsf@europa.jade-hamburg.de> Message-ID: Confirmed as fixed here with that change as well. Thanks Justus, Appreciated! Dominyk ==== Sent from OS X. If you wish to communicate more securely my PGP Public Key is 0x872524db9d74326c. On 28/06/2016 14:37, Justus Winter wrote: > Hi :) > > Dominyk Tiller writes: >> I finally managed to reproduce the initial failure, although it took 10+ >> builds to get it to happen twice. Logs attached. > > I fixed that in 8f79c31b. > > Cheers, > Justus > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: