From ineiev at gnu.org Thu Dec 1 08:18:33 2016 From: ineiev at gnu.org (Ineiev) Date: Thu, 1 Dec 2016 02:18:33 -0500 Subject: [GPA] Translation patch question In-Reply-To: References: Message-ID: <20161201071832.GW10490@gnu.org> Hello, On Tue, Nov 29, 2016 at 12:27:53PM +0100, Zdenek Hatas wrote: > I contributed translation to GPA project in the past and now made update > again. > > When I tried to send a message with a patch, "message too large" returned > to me from the list. > What is the right way to send a patch wich is 60k large? > Patch hold single file cs translation update for GPA. Some workarounds may be: - compressing the file - posting it somewhere else and putting a link in your message - sending it personally to some developer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From zdenek.hatas at gmail.com Thu Dec 1 09:02:02 2016 From: zdenek.hatas at gmail.com (Zdenek Hatas) Date: Thu, 1 Dec 2016 09:02:02 +0100 Subject: [PATCH GPA] po czech translation update Message-ID: Here I send update to Czech translation for GPA as advised. Patch is compressed because of its size. Thanks, Zden?k -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-po-czech-translation-update.patch.gz Type: application/x-gzip Size: 15461 bytes Desc: not available URL: From wk at gnupg.org Thu Dec 1 09:39:09 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 01 Dec 2016 09:39:09 +0100 Subject: [PATCH GPA] po czech translation update In-Reply-To: (Zdenek Hatas's message of "Thu, 1 Dec 2016 09:02:02 +0100") References: Message-ID: <87d1hc3uxe.fsf@wheatstone.g10code.de> On Thu, 1 Dec 2016 09:02, zdenek.hatas at gmail.com said: > Here I send update to Czech translation for GPA as advised. Thanks. Pushed as b711104. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From wk at gnupg.org Thu Dec 1 09:42:17 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 01 Dec 2016 09:42:17 +0100 Subject: [pinentry] In-Reply-To: <2209807.3WtvXZ1AUa@calvin> (Fabio Coatti's message of "Sun, 27 Nov 2016 11:56:17 +0100") References: <2209807.3WtvXZ1AUa@calvin> Message-ID: <874m2o3us6.fsf@wheatstone.g10code.de> On Sun, 27 Nov 2016 11:56, fabio.coatti at gmail.com said: > However, with LTO I'm getting this error (maybe I'm doing something wrong, > however 0.9.7 compiled just fine even with lto): I pushed a fix this morning: commit c5c7bee68730c9f66a27f9bb0d023480623a2bfb Author: Werner Koch Date: Thu Dec 1 09:10:08 2016 +0100 Fix linkage problem in tty and emacs pinentries. * emacs/pinentry-emacs.c (curses_cmd_handler): Remove var. * tty/pinentry-tty.c (curses_cmd_handler): Remove var. * pinentry/pinentry.c (flavor_flag): New local var. (pinentry_set_flavor_flag): New function. (cmd_getinfo): Use FLAVOR_FLAG for the "flavor" sub-command. * gnome3/pinentry-gnome3.c (main): Call pinentry_set_flavor_flag. * gtk+-2/pinentry-gtk-2.c (main): Ditto. * pinentry/pinentry-emacs.c (initial_emacs_cmd_handler): Ditto. * qt/main.cpp (main): Ditto. -- Fixes-commit: e4e3a9cc88704dcffac660d0b92fd1ed8abecc11 Fixes-commit: d126036671e7dd631babc118cb4113f723f15748 Signed-off-by: Werner Koch Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From wk at gnupg.org Thu Dec 1 09:40:17 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 01 Dec 2016 09:40:17 +0100 Subject: [GPA] Translation patch question In-Reply-To: <20161201071832.GW10490@gnu.org> (ineiev@gnu.org's message of "Thu, 1 Dec 2016 02:18:33 -0500") References: <20161201071832.GW10490@gnu.org> Message-ID: <878ts03uvi.fsf@wheatstone.g10code.de> On Thu, 1 Dec 2016 08:18, ineiev at gnu.org said: > - sending it personally to some developer Use translations at gnupg dot org Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From meno.abels at adviser.com Thu Dec 1 13:26:54 2016 From: meno.abels at adviser.com (Meno Abels) Date: Thu, 1 Dec 2016 13:26:54 +0100 Subject: command line keytocard Message-ID: hello, i tried to invoke from the --card-edit menu the keytocard function within batch file. But that seams not work. Which is a document feature ?card-edit is a interactive tool. To make it working, I would try to implement ?quick-keytocard in the same style like ?quick-addkey. I looked around in gpgme and didn?t not found any entry point which allows me to do keytocard. My question is, if i try now to implement quick-keytocard, would you accept my patch? Or is there any other idea how to send a key from gpg to a smartcard within a batch? I currently only know one bigger obstacle keytocard needs a passphrase and the adminpin both a gather via pinentry. This leads to a extension to the batch mode command line (--no-tty --pinentry-mode loopback --passphrase-fd). Thx in advance meno From bernhard at intevation.de Thu Dec 1 15:09:16 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 1 Dec 2016 15:09:16 +0100 Subject: gpgme 1.8.0 released In-Reply-To: <87inrnvaia.fsf@wheatstone.g10code.de> References: <87inrnvaia.fsf@wheatstone.g10code.de> Message-ID: <201612011509.20970.bernhard@intevation.de> Am Mittwoch 16 November 2016 14:07:25 schrieb Werner Koch: > This is a quick announcement, that gpgme 1.8.0 is now available at the > usual places. Thanks for the release! As a reminder: An email should also be send to gnupg-announce for consistency reasons. (GPGME release are usually announced there, so people would expect an 1.8.0 release email there as well.) 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 Thu Dec 1 17:50:13 2016 From: justus at g10code.com (Justus Winter) Date: Thu, 01 Dec 2016 17:50:13 +0100 Subject: [PATCH] python: Make Context have a repr method. In-Reply-To: <1480458380.7697.14.camel@cryptobitch.de> References: <1480458380.7697.14.camel@cryptobitch.de> Message-ID: <87d1hbegqi.fsf@europa.jade-hamburg.de> Tobias Mueller writes: > * lang/python/gpg/core.py (Context.__repr__): added Merged, many thanks! I did some editorial changes. It is customary to write 'New X.' in the ChangeLog-style section when adding stuff. > To look nicer in a REPL We prefer whole sentences. > + def __repr__(self): > + return "".join(( > + "Context(armor={0.armor}, ", > + "textmode={0.textmode}, offline={0.offline}, ", > + "signers={0.signers}, pinentry_mode={0.pinentry_mode}, ", > + "protocol={0.protocol}", > + ")")).format(self) > + This is an odd construct. Python actually joins adjacent strings like C. Cheers, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From justus at g10code.com Thu Dec 1 17:51:22 2016 From: justus at g10code.com (Justus Winter) Date: Thu, 01 Dec 2016 17:51:22 +0100 Subject: [PATCH] python: Make Results have a nicer __repr__. In-Reply-To: <1480492049.15252.4.camel@cryptobitch.de> References: <1480492049.15252.4.camel@cryptobitch.de> Message-ID: <87a8cfegol.fsf@europa.jade-hamburg.de> Tobias Mueller writes: > * lang/python/gpg/results.py (Result.__str__): Renamed to '__repr__' ... > * lang/python/gpg/results.py (Result.__repr__): ... and added fields > -- > > So that it looks a bit nicer in the Python REPL. Merged, many thanks! Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From justus at g10code.com Thu Dec 1 17:51:49 2016 From: justus at g10code.com (Justus Winter) Date: Thu, 01 Dec 2016 17:51:49 +0100 Subject: [PATCH] python: Check "buffer" when writing to sys.stdout for python2 compat. In-Reply-To: <20161130220847.GA27907@cryptobitch.de> References: <20161130220847.GA27907@cryptobitch.de> Message-ID: <877f7jegnu.fsf@europa.jade-hamburg.de> Tobias Mueller writes: > * lang/python/tests/support.py (print_data): added buffer check > -- > > When running with something like make -C lang/python check verbose=2 the > test would fail under python2, because the file objects do not have a > buffer property. Merged, thanks! Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From muelli at cryptobitch.de Thu Dec 1 21:15:12 2016 From: muelli at cryptobitch.de (Tobias Mueller) Date: Thu, 1 Dec 2016 21:15:12 +0100 Subject: [PATCH] python: define a macro for wrapping fragile result objects. Message-ID: <20161201201512.GA27571@cryptobitch.de> * lang/python/gpgme.i: defined a wrapresult macro -- This reduces the amount of copy and pasted code at the expense of a slightly more complicated logic with a macro. Signed-off-by: Tobias Mueller --- lang/python/gpgme.i | 69 ++++++++++------------------------------------------- 1 file changed, 12 insertions(+), 57 deletions(-) diff --git a/lang/python/gpgme.i b/lang/python/gpgme.i index 3332b19..b1cf011 100644 --- a/lang/python/gpgme.i +++ b/lang/python/gpgme.i @@ -424,69 +424,24 @@ /* Wrap the fragile result objects into robust Python ones. */ -%typemap(out) gpgme_encrypt_result_t { +%define wrapresult(cls, name) +%typemap(out) cls { PyObject *fragile; fragile = SWIG_NewPointerObj(SWIG_as_voidptr($1), $1_descriptor, %newpointer_flags); - $result = _gpg_wrap_result(fragile, "EncryptResult"); - Py_DECREF(fragile); -} - -%typemap(out) gpgme_decrypt_result_t { - PyObject *fragile; - fragile = SWIG_NewPointerObj(SWIG_as_voidptr($1), $1_descriptor, - %newpointer_flags); - $result = _gpg_wrap_result(fragile, "DecryptResult"); - Py_DECREF(fragile); -} - -%typemap(out) gpgme_sign_result_t { - PyObject *fragile; - fragile = SWIG_NewPointerObj(SWIG_as_voidptr($1), $1_descriptor, - %newpointer_flags); - $result = _gpg_wrap_result(fragile, "SignResult"); - Py_DECREF(fragile); -} - -%typemap(out) gpgme_verify_result_t { - PyObject *fragile; - fragile = SWIG_NewPointerObj(SWIG_as_voidptr($1), $1_descriptor, - %newpointer_flags); - $result = _gpg_wrap_result(fragile, "VerifyResult"); - Py_DECREF(fragile); -} - -%typemap(out) gpgme_import_result_t { - PyObject *fragile; - fragile = SWIG_NewPointerObj(SWIG_as_voidptr($1), $1_descriptor, - %newpointer_flags); - $result = _gpg_wrap_result(fragile, "ImportResult"); - Py_DECREF(fragile); -} - -%typemap(out) gpgme_genkey_result_t { - PyObject *fragile; - fragile = SWIG_NewPointerObj(SWIG_as_voidptr($1), $1_descriptor, - %newpointer_flags); - $result = _gpg_wrap_result(fragile, "GenkeyResult"); - Py_DECREF(fragile); -} - -%typemap(out) gpgme_keylist_result_t { - PyObject *fragile; - fragile = SWIG_NewPointerObj(SWIG_as_voidptr($1), $1_descriptor, - %newpointer_flags); - $result = _gpg_wrap_result(fragile, "KeylistResult"); + $result = _gpg_wrap_result(fragile, name); Py_DECREF(fragile); } +%enddef -%typemap(out) gpgme_vfs_mount_result_t { - PyObject *fragile; - fragile = SWIG_NewPointerObj(SWIG_as_voidptr($1), $1_descriptor, - %newpointer_flags); - $result = _gpg_wrap_result(fragile, "VFSMountResult"); - Py_DECREF(fragile); -} +wrapresult(gpgme_encrypt_result_t, "EncryptResult") +wrapresult(gpgme_decrypt_result_t, "DecryptResult") +wrapresult(gpgme_sign_result_t, "SignResult") +wrapresult(gpgme_verify_result_t, "VerifyResult") +wrapresult(gpgme_import_result_t, "ImportResult") +wrapresult(gpgme_genkey_result_t, "GenkeyResult") +wrapresult(gpgme_keylist_result_t, "KeylistResult") +wrapresult(gpgme_vfs_mount_result_t, "VFSMountResult") %typemap(out) gpgme_engine_info_t { int i; -- 2.7.4 From bernhard at intevation.de Fri Dec 2 11:29:14 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 2 Dec 2016 11:29:14 +0100 Subject: [openpgp-email] On Signed-Only Mails In-Reply-To: <20161129092040.GA3043@littlepip.fritz.box> References: <20161129092040.GA3043@littlepip.fritz.box> Message-ID: <201612021129.25156.bernhard@intevation.de> Hi Vincent, Hi friends of end-to-end-crypto! [crossposting to openpgp-email and gnupg-devel, I don't know if I am subscribed to other lists that Vincent has mailed to, feel free to forward.] Am Dienstag 29 November 2016 10:20:40 schrieb Vincent Breitmoser: > (cross-posting on openpgp and messaging mls) > > during my work on bringing OpenPGP to K-9 Mail, I found myself > reevaluating a lot of things. This time it's about signed-only mails. I like your work, it is good to ask questions and think about better solutions! Thanks for working on K-9 Mail and adding OpenPGP/MIME support, I believe this this to be really important. > In short, my conclusion so far is that signed-only mails are very rarely > useful, they are holding OpenPGP back as a solution for encrypted > e-mail, and in the interest of usability we should not roll them out in > email crypto solutions on equal terms with encryption. My take on this is quite different, in short: I think you are underestimating how the relation of implementations and user experience will change if some of the user facing implementations change. I consider signed-only emails quite useful for a) publically archiving a statement, e.g. when haveing been send to a mailinglist or a group of people b) an indication that I am able to and want to start an encrypted exchange > In some more detail: > https://k9mail.github.io/2016/11/24/OpenPGP-Considerations-Part-I.html > > I received positive as well as negative feedback about this, and I'd > love to hear more thoughts about it. To your question: Yes, I occacionally react on missing or failed signatures. But we shall not design for me, or you or most of the readers of your post. So I consider this question and possible answers a non-argument. Your main problem with OpenPGP/MIME signed only emails seems to be that other users, not having an OpenPGP/MIME aware email application, could be irritated by them. Am Dienstag 29 November 2016 10:58:43 schrieb Kristian Fiskerstrand: > > Clearsigned messages can make archiving easier, and allow for sharing > > of information across groups, while still maintaining it is in > > non-modified form from an authorized party. Am Dienstag 29 November 2016 11:18:45 schrieb Vincent Breitmoser: > Incidentally, this aligns with a thought Bjarni brought up just recently: > > https://github.com/mailpile/Mailpile/issues/1693 Here it also is irritation. While in that issue attached OpenPGP pubkeys seem to be a second case where possible irritation arises. Personally I believe pubkeys should not be attached to email, so I'll focus on the signed emails in your article in the following. == We need more security states than "save" or "not-save". I challenge your assumption that the user only wants two states for their security state: save or not-save. While keeping things as simple as possible, there needs to be a learing experience and the possibility to pay more attention to some exchanges as to others. Considering the user experience there is a natural mapping for multiple states in other communications like whom do you tell what or legal document hand-written signatures. Security must match the purpose of the communication exchange in question. A higher level of authentication go along with other drawbacks like more efforts or giving up anonymity. So I do not want those drawbacks for some exchanges, but I may want them for others. Because of the existing natural mapping I believe that software systems can be created that are a lot easier to understand and deal with more than two levels. They might even provide a better user experience compare to systems with only two states. Why? There is a pattern that first usage of some crypto-feature will lead to an outcry of the next self-proclaimed crypto-nerd: "But that is not secure! You must do this and that." I consider this pattern more damaging than the possible irritation by attachments. The path forward I see is to have more states and explain and handle them much better in implementations. == Better email-clients are a key success factor The problems with user irritations of signed-only emails could be elevated if more users would use a client that deals properly with those emails. This means they do not display the signature or the attachement, if the user does not want to deal with the implications. If better client can help, we are back to the larger problem of how to introduce new features in used email clients. Naturally this is a hard problem, but one that we (that share the idea of more end-to-end email crypto) have to solve to some extend anyway. The progress of better implementations is non-linear. There may be a tipping point where almost all users say: !Hey, I need a better implementation!" And after this the wast majority will be irritated if there is no indication of opportunistic encryption or some communication track record based indication if it is missing on the email to public. There are a number of examples for this innovation pattern, just think about the appearance of OpenOffice in the user space or the rate that you now need a new webbrowser. Given a possible solution by improved clients, we should try first to make them happen before giving up on signed-only emails, which is the solution you proposed. You may say: But this hasn't work for many years. I'd agree with this notion, but because of the non-linear nature we don't know how close we are to the tipping point. And a second reason is because in the last 1-2 years the OpenPGP implementation side has seen a significant more work than in the 6 years before (mainly because of the donations that Werner received and the BSI contracts my company Intevation is also involved in, documented on wiki.gnupg.org). This backend, concept and client progress, especially the WKD and WKS things, still have to reach users and there is a good chance for them to succeed. 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 alec at alec.pl Fri Dec 2 12:43:19 2016 From: alec at alec.pl (A.L.E.C) Date: Fri, 2 Dec 2016 12:43:19 +0100 Subject: Key import on a machine with date moved back Message-ID: <7e1aecff-42b9-7ed8-4094-d03de8812fa9@alec.pl> A scenario here is that user generates a key-pair in a web browser using openpgp.js then uploads it to the server where gpg is used to import it to a user keyring. Problem is the time on server is a few seconds behind the time on the client. So, GnuPG 2.0.22 does this: gpg: key A65FB1D8: secret key imported gpg: key A65FB1D8 was created 6 seconds in the future (time warp or clock problem) gpg: key A65FB1D8 was created 6 seconds in the future (time warp or clock problem) gpg: key A65FB1D8 was created 6 seconds in the future (time warp or clock problem) gpg: key A65FB1D8 was created 6 seconds in the future (time warp or clock problem) gpg: key A65FB1D8: no valid user IDs gpg: this may be caused by a missing self-signature gpg: Total number processed: 1 gpg: w/o user IDs: 1 gpg: secret keys read: 1 gpg: secret keys imported: 1 IMPORT_OK 17 85CE61FECEFC0C46D505D6F20C507F31A65FB1D8 IMPORT_RES 1 1 0 0 0 0 0 0 0 1 1 0 0 0 I found it a little bit confusing. First, the hint about missing self-signature and no valid user IDs is not very useful and misleading. Second, it had actually imported something, I'd expect to not import anything at all. Third, the "clock problem" error is displayed (actually logged in this case) four times. So, the question is how can we improve that? In general I'd like to import the key-pair as if there were no time issues. Maybe there's a command line argument to ignore them? Or maybe it's already fixed/implemented in 2.1? -- Aleksander 'A.L.E.C' Machniak Kolab Groupware Developer [http://kolab.org] Roundcube Webmail Developer [http://roundcube.net] ---------------------------------------------------- PGP: 19359DC1 # Blog: https://kolabian.wordpress.com From wk at gnupg.org Fri Dec 2 16:45:59 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 02 Dec 2016 16:45:59 +0100 Subject: Key import on a machine with date moved back In-Reply-To: <7e1aecff-42b9-7ed8-4094-d03de8812fa9@alec.pl> (A. L. E. C.'s message of "Fri, 2 Dec 2016 12:43:19 +0100") References: <7e1aecff-42b9-7ed8-4094-d03de8812fa9@alec.pl> Message-ID: <878trywczs.fsf@wheatstone.g10code.de> On Fri, 2 Dec 2016 12:43, alec at alec.pl said: > So, the question is how can we improve that? In general I'd like to > import the key-pair as if there were no time issues. Maybe there's a > command line argument to ignore them? --ignore-time-conflict GnuPG normally checks that the timestamps associated with keys and signatures have plausible values. However, sometimes a signature seems to be older than the key due to clock problems. This option makes these checks just a warning. See also --ignore-valid-from for timestamp issues on subkeys. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From dkg at fifthhorseman.net Fri Dec 2 15:18:18 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 02 Dec 2016 09:18:18 -0500 Subject: Key import on a machine with date moved back In-Reply-To: <7e1aecff-42b9-7ed8-4094-d03de8812fa9@alec.pl> References: <7e1aecff-42b9-7ed8-4094-d03de8812fa9@alec.pl> Message-ID: <874m2mv2hh.fsf@alice.fifthhorseman.net> On Fri 2016-12-02 06:43:19 -0500, A.L.E.C wrote: > So, the question is how can we improve that? In general I'd like to > import the key-pair as if there were no time issues. Maybe there's a > command line argument to ignore them? > > Or maybe it's already fixed/implemented in 2.1? 2.1 does have --ignore-time-conflict, but i agree with you that it might make more sense to tolerate a "typical" clock skew of a few seconds or minutes by default. Perhaps it'd make more sense to have a "tolerate-clock-skew" option that takes a time value, with some sensible default like 10min. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From wk at gnupg.org Fri Dec 2 17:41:44 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 02 Dec 2016 17:41:44 +0100 Subject: Key import on a machine with date moved back In-Reply-To: <874m2mv2hh.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 02 Dec 2016 09:18:18 -0500") References: <7e1aecff-42b9-7ed8-4094-d03de8812fa9@alec.pl> <874m2mv2hh.fsf@alice.fifthhorseman.net> Message-ID: <87wpfiuvuf.fsf@wheatstone.g10code.de> On Fri, 2 Dec 2016 15:18, dkg at fifthhorseman.net said: > 2.1 does have --ignore-time-conflict, but i agree with you that it might Actually all versions have that for many years. The RIPE requested that once. > make more sense to tolerate a "typical" clock skew of a few seconds or > minutes by default. Yes, that is useful. There is another open bug related to too strict validation result for time conflicts and in the course of fixing that we should allow for a skew of a few minutes. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From meno.abels at adviser.com Fri Dec 2 21:45:39 2016 From: meno.abels at adviser.com (Meno Abels) Date: Fri, 2 Dec 2016 21:45:39 +0100 Subject: command line keytocard In-Reply-To: References: Message-ID: <3D6E9070-A702-4990-8082-8C39036E0198@adviser.com> Hi, i yesterday, ask about this new option. And now I used this lazy friday evening to implement the first part. I tried to figure out how to contribute code and the right coding style. Both I did not had success with. So please be patient with me and give me feedback what i should change to get this in upstream. I attached the patch from this commit: ce29272e24e7b718b8fca9b84bc728e65f3dea24 I?m not sure how the process with code contribution works in gpg so again please be patient and give me feedback. Next i will try to find a solution to the loopback pinentry to pass both password. Thx in advance meno -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-gpg-New-option-quick-keytocard.patch Type: application/octet-stream Size: 10862 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-gpg-New-option-quick-keytocard.patch.asc Type: application/octet-stream Size: 6492 bytes Desc: not available URL: -------------- next part -------------- > On 1 Dec 2016, at 13:26, Meno Abels wrote: > > hello, > > i tried to invoke from the --card-edit menu the keytocard function within batch file. But that seams not work. > > Which is a document feature ?card-edit is a interactive tool. > > To make it working, I would try to implement ?quick-keytocard in the same style like ?quick-addkey. > > I looked around in gpgme and didn?t not found any entry point which allows me to do keytocard. > > My question is, if i try now to implement quick-keytocard, would you accept my patch? > > Or is there any other idea how to send a key from gpg to a smartcard within a batch? > > I currently only know one bigger obstacle keytocard needs a passphrase and the adminpin both a gather via > pinentry. This leads to a extension to the batch mode command line (--no-tty --pinentry-mode loopback --passphrase-fd). > > Thx in advance > > meno > > > From meno.abels at adviser.com Fri Dec 2 21:50:51 2016 From: meno.abels at adviser.com (Meno Abels) Date: Fri, 2 Dec 2016 21:50:51 +0100 Subject: command line keytocard In-Reply-To: <3D6E9070-A702-4990-8082-8C39036E0198@adviser.com> References: <3D6E9070-A702-4990-8082-8C39036E0198@adviser.com> Message-ID: <08A73A20-9975-43DE-B13B-FEE01613F108@adviser.com> Hi, attachments does not work: From bf9027719a27dc6c0d5eba5d8a067542ff79514d Mon Sep 17 00:00:00 2001 From: Meno Abels Date: Fri, 2 Dec 2016 21:23:39 +0100 Subject: [PATCH] gpg: New option --quick-keytocard * wrote the documentation for the new option (untested) * g10/card-util.c (send_keytocard) added * g10/gpg.c added aQuickKeyToCard to cmd_and_opt_values * g10/gpg.c added ARGPARSE_c with aQuickKeyToCard * g10/gpg.c added handling for aQuickKeyToCard * g10/keyedit.c (get_keyno_from_slot_usage) new function maps commandline option to keyno. * g10/keyedit.c (is_keyno_matching_usage) tests if the key has the right usage for the keyno. * g10/keyedit.c (keyedit_quick_keytocard) new function to prepare the commandline parameter to call (send_keytocard) to transfer the key. * g10/main.h (keyedit_quick_keytocard) forward decl * g10/main.h (send_keytocard) forward decl Tested: by hand i send ~15 keys to reseted yubikeys and try successfully to use the key for sign,encr,auth Missing: in batch we need to pass the adminpin via loopback pinentry Signed-off-by: Meno Abels --- doc/gpg.texi | 18 +++++++++++ g10/card-util.c | 62 ++++++++++++++++++++++++++++++++++++ g10/gpg.c | 25 +++++++++++++++ g10/keyedit.c | 99 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ g10/main.h | 4 +++ 5 files changed, 208 insertions(+) diff --git a/doc/gpg.texi b/doc/gpg.texi index b01d0a3..7adccf3 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -663,6 +663,24 @@ for the subkey. Several formats are supported; commonly the ISO YYYY-MM-DD format is used. The values ``never'', ``none'', or ``-'' can be used for no expiration date. + + at item --quick-keytocard @code{fpr} (@code{slot}|@code{usage}) [@code{serial}] + at opindex quick-keytocard +Sends the key identified by the fingerprint @code{fpr} to the by + at code{serial} identified smartcard. If @code{serial} is not set +the first card will be used. The @code{serial} is the serialnumber +of the smartcard. This number is found in "--card-status". +The @code{slot} and @code{usage} specify the slot in the smartcard +which should receive the choosen key. @code{slot} is just the number +of the slot starting with 1. The @code{usage} maps if 'sign' is to + at code{slot} 1. If @code{usage} is set to 'encr' the @code{slot} 2 +is written. If 'auth' is choosen the @code{slot} 3 is used. +To write to a keyslot needs the smartcard admin pin. This is usally +requested with pinentry. In the case of passing the password through +loopback pinentry you have to provide a second password. This could +be done with --passphrase-fds. The second specified fd should provide +the admin pin. + @item --gen-key @opindex gen-key Generate a new key pair using the current default parameters. This is diff --git a/g10/card-util.c b/g10/card-util.c index e358572..b905a29 100644 --- a/g10/card-util.c +++ b/g10/card-util.c @@ -1628,6 +1628,68 @@ card_store_subkey (KBNODE node, int use) return okay; } +int +send_keytocard(PKT_public_key *pk, int keyno, const char *serialno) { + gnupg_isotime_t timebuf; + struct agent_card_info_s info; + unsigned int nbits; + gpg_error_t err = 0; + int rc = 0; + char *hexgrip = 0; + int okay = 0; + + if (get_info_for_key_operation (&info)) + { + log_error (_("get_info_for_key_operations: failed:%s"), + gpg_strerror (err)); + goto leave; + } + if (serialno && *serialno && strcmp(info.serialno, serialno)) { + log_error (_("The card serial no does not match %s!=%s"), serialno, + info.serialno); + goto leave; + } + if (!info.extcap.ki) + { + log_error (_("The card does not support the import of keys")); + goto leave; + } + nbits = nbits_from_pk (pk); + if (!info.is_v2 && nbits != 1024) + { + log_error (_("You may only store a 1024 bit RSA key on the card")); + goto leave; + } + if (info.is_v2 && !info.extcap.aac + && info.key_attr[keyno-1].nbits != nbits) + { + log_error (_("Key does not match the card's capability. %d %d"), keyno, nbits); + goto leave; + } + if ((keyno == 1 && info.fpr1valid) + || (keyno == 2 && info.fpr2valid) + || (keyno == 3 && info.fpr3valid)) { + log_info (_("replace existing key in slot %d"), keyno); + } + if ((err = hexkeygrip_from_pk (pk, &hexgrip))) { + log_error (_("hexkeygrip_from_pk failed with %s"), gpg_strerror(err)); + goto leave; + } + epoch2isotime (timebuf, (time_t)pk->timestamp); + if ((err = agent_keytocard (hexgrip, keyno, rc, info.serialno, timebuf))) { + log_error (_("agent_keytocard failed: %s\n"), gpg_strerror (rc)); + if ((rc = agent_scd_learn (NULL, 1))) { + log_error (_("agent_scd_learn failed: %s\n"), gpg_strerror (rc)); + } + } else { + okay = 1; + } +leave: + xfree (hexgrip); + agent_release_card_info (&info); + return okay; +} + /* Direct sending of an hex encoded APDU with error printing. */ diff --git a/g10/gpg.c b/g10/gpg.c index 7cf51f2..deef69a 100644 --- a/g10/gpg.c +++ b/g10/gpg.c @@ -123,6 +123,7 @@ enum cmd_and_opt_values aQuickAddUid, aQuickAddKey, aQuickRevUid, + aQuickKeyToCard, aListConfig, aListGcryptConfig, aGPGConfList, @@ -448,6 +449,8 @@ static ARGPARSE_OPTS opts[] = { ARGPARSE_c (aQuickAddKey, "quick-addkey", "@"), ARGPARSE_c (aQuickRevUid, "quick-revuid", N_("quickly revoke a user-id")), + ARGPARSE_c (aQuickKeyToCard, "quick-keytocard", + N_("send a secret key to a smartcard")), ARGPARSE_c (aFullKeygen, "full-gen-key" , N_("full featured key pair generation")), ARGPARSE_c (aGenRevoke, "gen-revoke",N_("generate a revocation certificate")), @@ -2549,6 +2552,7 @@ main (int argc, char **argv) case aQuickAddUid: case aQuickAddKey: case aQuickRevUid: + case aQuickKeyToCard: case aExportOwnerTrust: case aImportOwnerTrust: case aRebuildKeydbCaches: @@ -3953,6 +3957,7 @@ main (int argc, char **argv) case aQuickAddUid: case aQuickAddKey: case aQuickRevUid: + case aQuickKeyToCard: case aFullKeygen: case aKeygen: case aImport: @@ -4383,6 +4388,26 @@ main (int argc, char **argv) keyedit_quick_revuid (ctrl, uid, uidtorev); } break; + case aQuickKeyToCard: + { + const char *x_fpr, *x_slot_usage, *x_smartcard_serial; + + if (argc < 1 || argc > 4) + wrong_args ("--quick-addkey FINGERPRINT (SLOT|USAGE) [SMARTCARDSERIAL]"); + x_fpr = *argv++; argc--; + x_slot_usage = ""; + x_smartcard_serial = ""; + if (argc) + { + x_slot_usage = *argv++; argc--; + if (argc) + { + x_smartcard_serial = *argv++; argc--; + } + } + keyedit_quick_keytocard (ctrl, x_fpr, x_slot_usage, x_smartcard_serial); + } + break; case aFastImport: opt.import_options |= IMPORT_FAST; diff --git a/g10/keyedit.c b/g10/keyedit.c index 94fa8c4..764c0df 100644 --- a/g10/keyedit.c +++ b/g10/keyedit.c @@ -3341,6 +3341,105 @@ keyedit_quick_addkey (ctrl_t ctrl, const char *fpr, const char *algostr, keydb_release (kdbhd); } +int +get_keyno_from_slot_usage(const char *slot_usage) +{ + int keyno = 1; + if (strcmp(slot_usage, "sign")) + { + keyno = 2; + if (strcmp(slot_usage, "encr")) + { + keyno = 3; + if (strcmp(slot_usage, "auth")) + { + keyno = atoi(slot_usage); + } + } + } + return keyno; +} + +int +is_keyno_matching_usage(int keyno, int usage) +{ + if (keyno == 1) { + if (!(usage & (PUBKEY_USAGE_SIG|PUBKEY_USAGE_CERT))) { + log_error (_("the key for slot 1 is not for signature or certification")); + return 0; + } + } + if (keyno == 2) { + if (!(usage & (PUBKEY_USAGE_ENC))) { + log_error (_("the key for slot 2 is not for encryption")); + return 0; + } + } + if (keyno == 3) { + if (!(usage & (PUBKEY_USAGE_SIG|PUBKEY_USAGE_AUTH))) { + log_error (_("the key for slot 1 is not for signature or authentication")); + return 0; + } + } + return 1; +} +/* Unattended send a key to a smartcard */ +void +keyedit_quick_keytocard (ctrl_t ctrl, const char *fpr, const char *slot_usage, + const char *serialno) +{ + gpg_error_t err; + kbnode_t keyblock; + KEYDB_HANDLE kdbhd; + KBNODE node = NULL; + +#ifdef HAVE_W32_SYSTEM + /* See keyedit_menu for why we need this. */ + check_trustdb_stale (ctrl); +#endif + + /* We require a fingerprint because only this uniquely identifies a + * key */ + err = get_pubkey_byname (ctrl, NULL, NULL, fpr, &keyblock, &kdbhd, 1, 1); + if (err) + { + log_error (_("key \"%s\" not found: %s\n"), fpr, gpg_strerror (err)); + goto leave; + } + + for (node = keyblock; node; node = node->next) + { + if (PKT_PUBLIC_KEY == node->pkt->pkttype || + PKT_PUBLIC_SUBKEY == node->pkt->pkttype || + PKT_SECRET_KEY == node->pkt->pkttype) + { + PKT_public_key *pk = node->pkt->pkt.public_key; + char hexfpr[2*MAX_FINGERPRINT_LEN+1]; + hexfingerprint (pk, hexfpr, sizeof hexfpr); + if (!strcmp(fpr, hexfpr)) + { + int keyno = get_keyno_from_slot_usage(slot_usage); + if (!(1 <= keyno && keyno <= 3)) + { + log_error (_("slot has to be 1,2,3 is %s"), slot_usage); + goto leave; + } + if (!is_keyno_matching_usage(keyno, pk->pubkey_usage)) + { + goto leave; + } + if (send_keytocard(pk, keyno, serialno)) + { + log_info(_("keytocard for %s to slot %u successful"), hexfpr, keyno); + } + } + } + } +leave: + release_kbnode (keyblock); + keydb_release (kdbhd); +} + static void diff --git a/g10/main.h b/g10/main.h index 63aec47..c73f682 100644 --- a/g10/main.h +++ b/g10/main.h @@ -295,6 +295,9 @@ 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 keyedit_quick_keytocard (ctrl_t ctrl, const char *fpr, + const char *slot_usage, const char *sm_serial); + void show_basic_key_info (KBNODE keyblock); /*-- keygen.c --*/ @@ -479,6 +482,7 @@ void card_status (estream_t fp, char *serialno, size_t serialnobuflen); void card_edit (ctrl_t ctrl, strlist_t commands); gpg_error_t card_generate_subkey (KBNODE pub_keyblock); int card_store_subkey (KBNODE node, int use); +int send_keytocard(PKT_public_key *pk, int keyno, const char *serialno); #endif #define S2K_DECODE_COUNT(_val) ((16ul + ((_val) & 15)) << (((_val) >> 4) + 6)) -- 2.9.3 (Apple Git-75) ----BEGIN PGP MESSAGE----- Comment: GPGTools - http://gpgtools.org owGtOWuUG9V5NpAEBjg0aRvSkwauRb0rWQ8krbRP2/F6d71ee3e9rGTAx3bGo5k7 0rDSzHge+8DeNKcttCE1SSk+pQkxJ3U5+UNJS9I8CmkTSoDEPBIMNOfUENrGlAZT oNR5EZd+370z0mgkrTc5kX12Zu583/3ej/vNpy6/cM3Fa999xdmNXzweu2PtiddK a24cPnV6m2XUSEkdSGf7+jIDUrZPkXvltJKnJSmv9Evp3r58LquqfQP5TE4hU4ZO CtQkmT6STg+y/ySbTmcE3GaQTFHdIMMlWrXJxhrcpyS83yIp85pNrZRs1DYLo5JD B8k2S0uQLBmlMuBnekk2M5jtGewZIPF0Jp0WCm7pJio7g2TvzHBxZPt+UjbLg2Sa LhDDdDRgIpk86GryXHKOLjmGLFmKIGwgC5bhUOJUKFEM2QUGHIkBq4bFVvUGftTV HWo7VIkBXjmTvhb3SLqOVk3JJGpTXRHrW8eIpChU8QCBEwBhK0S6DpnYSZeKxggA Escgck0RJcAGOuK8VHWp3QZveHZ8Zni2MCbKZEFzKuF92mBUYM+qppeZLO3BgV+q aA7yX6YOsq8bogp2Ee2q4YiuLZVpjOlAdXUZtSDUJNMmYJUa35362gE5GHqqdWvN 9nauSY5cAY78jVGdNtFU1LQAIMCyzbRuaeWKQxhU3RKddvduRWbcoAWa2Ab2TIua ksWNHRQAFqUadajFbCFVq0KLMeGFY0m6rdI6Lz4nNUnTU5UV2AD+F9DQCpWrIZww mSZQocicbZCUlpgpiUYQnnw0k0f6NjJlURsYV8iSW9JwTUA4x1oitivL1LZVt1pd QkDXpj7jTKG2VtYTVJethOQ6FWFKs22wyyDRdFJCI5EFdH3K3NOUbG4VSalpugkg 85okVA3DLEnyHIEFiBprSRAKsClVkoaqJktLq4vsZDIpYOQxx3Xookbgd5hk+km8 8RNaou0w6c0GITr+hEBU8N9hks2HUYWQTyHUwMCqCKxA1bOyR5XkCHuTJ6pWpRBC YNMyVSCjpftB7aAR9FM7Go8JgqKpKqSrsuYQ6dom7ZSaHgVNV+giKaUzSlrqSaX6 JEWW1R4C6bA3l0PlhvAFYCG8x5YtJNnb25PoJXG8ZHMEVvygs90S+jqBDD5PLamK LyCKbYKBZLumaVjgf0MsngwdfQ2QJgq7BLIHfsmpqeToqIdDNBvdUIHNigDEEx05 cEDHnbu7E3hr6BTvgPiBA8nubgHCERySMjzGE3gUXTQ1iydpBepCSiBCXIhv0Rxa a03xZItsKPSQalrLJMrvMbMtH+b3LMMsx8he7xW1NKm6vB+2M0yu23DJiBcgBu16 LGkK+L6masBeiQuvQhxRy7Q03QkSxwwCb0tLsHeQVnAHuyZZDlJJkQmVhMBskN2B DOAIcU7Gsh3CRFzQqlVfSSmm2xZUZkr2qLu1ErWEuKHyxQbJYgVpsNeIohou5hyd RJJJFno2VEbXjqSEeIAE6pJg0gnqk9gmlTWV6wNBcJsmakJ8oaJBlrErhltVII3J VJv3MnPFMCDPsRTbRAV4uskFmVlVDkmBNIA/CCEod6w8ZoKa8NhipQuqTTdmv26m F6NuDkYjE9C8hwRQoHS0Xzfmy25GMIiTFeIAs2BpjkN1ht+NOZXt7wsTxumpBwNo 02DIFElILLOjNJh87Wal8fyL+dYzFtsD6hX4lEUPuqxccOn9nAzscOKyBAUAtIW5 HHWEa3i/YGALUrEMt1wR4i05nSwZLhSfecacaRnz4K3ApE1lA2zub+CxI6MthXgJ Wykoq4yRZBKBzIoF9JOqYnOrePjcTdDzVcV3BY8Id/KGwBDixA/xMtUxIGHBD9L6 yjjVIUs5yCNWf4xQU9IsUJMvtOxaFogGJVaV3KrTKP42y0tMq835N1x7SuEVLwvT nnx/vi+bSpUG0nkpO9CchcM4PBGHVzEXZ3qz/ZiM+bUfszGCiLZjWFTkCZlEd26d 3jU6BjlBoQmCuQa8KSZApbGo41o6MeakpSGBLGN2hNdCvLnXiM7sLIqmW6pqMi6S DeYc34Z1WQmwpY7ppSJZZIOXOIwYOSTECSnrrlkWNdtwtBoVITLgUnLVIXxnO5Yr g9LAII7IuNZ01RBBqXBhEK5usy6BEdNLmmOzZahGIrUsw4IN4Uo2kTRbRyhLrj9y hip0sWxpZhMQyustsCWVd7SMPBQOFBL6a+oVjmgXvojFEJQJRUjV8DggUTEa6Yxr DxJVggquDK63I7EERw78UBJQg7cVXGKxIQ5UNiCIqhSiiS0s+3z6+iVdXQ1l4wNs I9fMKPKR8tcTpG6OWHvWiyzcIaw5IJZMxaC8fLAGnKy3121izNf3ahWjiej5JFjH oOkipCkzNad1VmudtzpHXg/BYlOrsVtIU5gFIysqjrkOGJxd+ZHFnCNRc44jNbiC w8d8FrXJMdZtgrjM5jqzuAcyXg18iXUzLOYgmSAKAXwyWxhmWcXw06qlrMwnMtLM R5OyJEnmuPCCraOvSY5j7WWBmMzsT9X5ZjedGYezXdjQPovdkJwlUyppVc2BmrBe gf9ofi/Y+cbnESLKgMkm0F+dWehsMtDHaUrM95/Dh0kDMBsEzK4A2BME7OGATd6N 75iQcISrSjKFJlCzWbFnTZjOO4CAULEQ8zynQOKAt5g7gh6TIF1eRol1iqk2iDwJ 8CrHgykY+ecNfGoaciXrZVES9ZJogt+JTsycS27GW+hqambDpz1BeIJtdLlRT4C6 SS05QUJ5wyPRUcbwnl6WA+H26WHxSNSS6+IxvliS5lvYsiKCtFCEotO7JycTJBOg 2Z5qA2XVVJkWlwmcKKm/t1cDMr6WmcoH8WFRtSita4lvwSlbFKBs2ihWfm1gME3F NL6MXQj+u3YDGdWgaXXYiRzdEHIWnFQq2Abo2OcpZHhmdDf3Ds47OxEAKLQZG65t 7TD4EbXUuPe6ij5ZzWdU6CoUStXeAam1q+DQjX6CP7NOIstOdXjpwzaCQtvcbtjE zMIHRMOKsltTEqElSC1NS7N0nkHFG0v1yZIPOAkBOmLoqlYOrozL1pIZWh+fGccF fJ1gfOdyrAHK5QYSrP3Bk4cmNyZgu2aKBRw72Xv3g7kP4TaB6Vi0iW1CIvwIJykK +HYkQSJbsGy3xfHkquNYdN7VlIjHaOM3DY7LIKBEAIwxhzUCGjArqWE5YIpp3b2h ojqBerRFWiow0mDzHtZugyOyVMfOCPUTAaMVlmSbW60CKfBupIMTIL9jjpC2kiAI USmc7izw23rPXOa9NLQ8bclAqz3LRAeN4v5cD5HENOue6m04Lsu86ZJxxKFq8ETZ jmjqbB6MDLbO5vNZ7qQ4NcGSCYFhlSGL8ZZvAzzMQ397CeFHmaC3DrZZBgW0LHPr Qj5oXq6bJYgwtoityK4FkKNowakz+G6i1vKu8eMgs5BptSpyoZRGJLlC7UEmbs9A noUkXPtWI25wz2aJ273hQre8qcvd8iYoevBlw4VCL9oucn1wAXM9/UxAuPYnsr2r lRB/zQNUHnokKjtWNUFcjEr4g+3YPKTmOhKcby4pWVSaG1pZvHpwHQrGWfCUsyhC 75HAa2P0zR/9aBN5LfVOGP4Pqx8KRjZCYwRdDbvfTHKx5oBesAy9LMJLm0Qj/piK 5ySybWJ6fGx2ZnZiukiihcldxcO7C8PjYzGytzA1PFscGZ4dLYzNTgxP7o/EhoLb Mp4hBTJlxuNDjHgyGYJpyAOgkUj4bUi8VhhfwpBEh8IZK0RpJaZW2Lbt1h1ZPR8R r0/o8NhhZu97necSzR7RykbQJrC9748kFFOS7fiRUmcAiliKn3pE/hnFJoc3kYmp mV2zRXHbcKE41NopNMbUpeZnr2MYyKlSv5xLpfp6c3JaUVs7hgZGo2torLE81ZPL sDyF10w6j3HcrCzPdZmm4MzOFRaMJ6a64IJULRvQybFKMoeJ0e+94CCglCpKrGlc 0fFzVLRpNNH4SiXED/mzAO9c4TWC7IjNT9JBO0ZwDhFpGgH4eNlAY9sOE+eAHmbA V33snro7dMLH8WAdv8nb/T0kx9ACOA0PWw42v4EOlSF6LSpXYIePbtHAkIePjYLK UwOHsky9Z2eH6SiP6y4Sndm9defYHpHlKLEwMX64aWFkbLa4Qr/f9BEKD20Zf7Tt f5ZifQh+Amj0C7wHqSvBkzk9FFZGE//ZVfE/Nj3yy3CbDXKLfrBk/mrc9fxq2h3e Xdz+69EuOiF+efgl1GvRV9mbDHc0OAXthv0caFLx4wXvVVubVDzuxOcNTRHiK+bb 1WWRQCC1KxIs37abXXoeHpozMhHnSjhFFVlYlKqGzHsJ0PnoVnH78PTo5BhhCYov N+auEKd4vmX9wDWaqlCVbB++fky8oScrFvYUimNTiABaKlBaz541OIQxYyxUlhof WSuazc+FbMZJQTkOdpaQI+HsU6VcQWiha/C8qfIOBHa+gRKc/GtsSBX88lSisoTf fL1vcvilQNcOurQa+GRlE4mpcAMzGifOxwuYfE02aBZLS7pUo35F5Od5/peZpsvX Gd6ikuC0jwf+eubFOUgoUTa7LNLeF4HjfsTzU1cPHP8Zkc4j1ZbZCvNUvEEVRz0r 1e3KzDbkGw8vyc06XXSCRQCZxuE4hN3kxIgIboDhymHNOYf9cZZMCr1ewwEDCAUW rqvEKYyNzI4VOxMJq651ak/CaKnG+0ZPjLFQoYugzb3ZDVPDN4qBllOcHJuOZ/bX gREu4ElsQMZxE5BBbqaG6j3GmgrdOq/SMTgPoF2JCxbozkW+Xe3zU2WGbNzkbdHV 5d1sxIwa6CSbOshmh2N5sSLhxz/8appJZBPsc5w3EW9LuI2f1VNjgLVONdertzjT 88KKU+jE8GqIhb7noJU8Mo0PBCvoA2dcXvj58z7Qz3qmFT5MdYntyjK1bdWtomZ8 HwjMV0OMhZqTxvjNH7LxTMuqIAtIvkuHZtAft10m+AMgVkRa+mE8X6YqXhvLH7xO uLdHonKuL5WS+3rU3v5sayfsgTfaYG+BjSYG8mwyAZcB7H+R+gqH1LblC2dCmD9b 5i5NvyaMwCG3DUUs4ecplyuQghCtarYDqEDGTgSewRqubfGWEO75oaYN/f9abdHu VJzbyRxsjpvWa4ETlqcOu2IsiCXJ5hnOm9h6RTngVmxIC2aeYwMLOCslk1Dg2ISi jw2ccv3evInt6n1gheYIjucUa41UA9FUMxHqI3gKFJ16kJVctUr1urXYRqivkHoa mpaNWk3SFfze0tSNcFR/chb+zgtpQwyKh3Za9WfhIXYkIL+GL8BDgkO8FgQ0fA20 PJpOSSG7UxwdGwHC4siu3dPFKA6WYyQazfS6VRKHG77QRTJ56F03boQVb2kzTkoA pBeSFZhLyKYGUj0kOmya0PWMa06yLx8ThI9f0HPRmrUXr/nQ+9dd9JMje4s3f+Zv X/mc842z777i7MYvHo/d8a4Lbhw+dXqNcMlv+CvP3nvFufd//I3C2d/J/Medez70 v/+jP/6VP97/rqMHz3zyq9l3xNJ7nh5Z1m/fMabf++PHvvt/hUvuzN/+wtKbn775 kYFt/zm07cznRm946+Dak989ZR7//l3vvUf72C3LkvaZk9KTb3Z/+czXv2c8/ejF ByIf/vzWfQ+ee23qmPQT+WPv3Xi5k/7h7tOv3/qdnWde/8NnRt5ev7Dd/Ob3rzt3 /auXPvNU92XvG3t4t7Hjg/tH37gydePlk9f9waXuX754dOSt+x9/5cm9S/kbXnzn sasuOvPRkcrkVTu7rto/8Ogjjz0cfW5CWbdZ/GFt5r4dt920zjwVveXM0X/+ys+i A8f3Hfn3+Mj4C2Nnzqz9xcMvxk5sO0Rf+Jcv3Hn78QdPf+8j9x77zntqz27+1uv/ ps+m3h56/O1HH77yg8/9fP3XT//u3x+5e+7P/2Tdjpc2PXE0e/SdWvX4iU8ePGLc 9g/PyKfPfeO+Z7cmf/HqrT+9d8dnx7uunn5AVv7q6VeVi9684JVrzj1RflmbvvBb T129b/LM9M+ev+fC+7/87Ytf+tcH8nvvfui+V9b9zV1fG/rCTx+687Mf3vpnXzqx fPUnvn3yt2966Pfeia259Xl6ee/zL98yZi+e/f2b7//v3JB1R+TSr732kad+NJhZ zn/gWO1L13drn3/ut/7oU490U6n3MvfgE4MvfPrkNydvveDRJ3/ztsTRKz7xvjd+ fOyfTvz1j8bP9ab+8dj4W39X+upbz/385bWXPvDmzkM/2PXEgy/9oP/kuTvuufLu Pz3yFx84FD1xavSu/wc= =KMn1 -----END PGP MESSAGE----- > On 2 Dec 2016, at 21:45, Meno Abels wrote: > > Hi, > > i yesterday, ask about this new option. > And now I used this lazy friday evening to implement the first part. > I tried to figure out how to contribute code and the right coding style. Both I did not > had success with. So please be patient with me and give me feedback what i should change > to get this in upstream. > > I attached the patch from this commit: > ce29272e24e7b718b8fca9b84bc728e65f3dea24 > > I?m not sure how the process with code contribution works in gpg so again please be > patient and give me feedback. > > Next i will try to find a solution to the loopback pinentry to pass both password. > > Thx in advance > > meno > > <0001-gpg-New-option-quick-keytocard.patch><0001-gpg-New-option-quick-keytocard.patch.asc> > >> On 1 Dec 2016, at 13:26, Meno Abels wrote: >> >> hello, >> >> i tried to invoke from the --card-edit menu the keytocard function within batch file. But that seams not work. >> >> Which is a document feature ?card-edit is a interactive tool. >> >> To make it working, I would try to implement ?quick-keytocard in the same style like ?quick-addkey. >> >> I looked around in gpgme and didn?t not found any entry point which allows me to do keytocard. >> >> My question is, if i try now to implement quick-keytocard, would you accept my patch? >> >> Or is there any other idea how to send a key from gpg to a smartcard within a batch? >> >> I currently only know one bigger obstacle keytocard needs a passphrase and the adminpin both a gather via >> pinentry. This leads to a extension to the batch mode command line (--no-tty --pinentry-mode loopback --passphrase-fd). >> >> Thx in advance >> >> meno >> >> >> > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From muelli at cryptobitch.de Fri Dec 2 23:37:27 2016 From: muelli at cryptobitch.de (Tobias Mueller) Date: Fri, 2 Dec 2016 23:37:27 +0100 Subject: [PATCH] python: Try to be more helpful when given a string to encrypt() Message-ID: <20161202223727.GA27467@cryptobitch.de> * lang/python/helpers.c (_gpg_obj2gpgme_data_t): Extended error message * lang/python/tests/t-encrypt.py: Test for "encode" in error message -- The motivation is to help the user when encrypting fails. I claim that it is not obvious to not being able to encrypt a string directly. To nudge the user into encoding it to bytes, the error message is a bit extended. Signed-off-by: Tobias Mueller --- lang/python/helpers.c | 6 ++++-- lang/python/tests/t-encrypt.py | 15 +++++++++++++++ 2 files changed, 19 insertions(+), 2 deletions(-) diff --git a/lang/python/helpers.c b/lang/python/helpers.c index 8f71a30..576767c 100644 --- a/lang/python/helpers.c +++ b/lang/python/helpers.c @@ -293,8 +293,10 @@ _gpg_obj2gpgme_data_t(PyObject *input, int argnum, gpgme_data_t *wrapper, return _gpg_obj2gpgme_t(data, "gpgme_data_t", argnum); return PyErr_Format(PyExc_TypeError, - "arg %d: expected gpg.Data, file, or an object " - "implementing the buffer protocol, got %s", + "arg %d: expected gpg.Data, file, " + "bytes (not string!), or an object " + "implementing the buffer protocol. Got: %s. " + "If you provided a string, try to encode() it.", argnum, data->ob_type->tp_name); } diff --git a/lang/python/tests/t-encrypt.py b/lang/python/tests/t-encrypt.py index 0c0ca35..3cbe8f2 100755 --- a/lang/python/tests/t-encrypt.py +++ b/lang/python/tests/t-encrypt.py @@ -62,3 +62,18 @@ with gpg.Context(armor=True) as c: assert support.sign_only.endswith(e.recipients[0].fpr) else: assert False, "Expected an InvalidRecipients error, got none" + + + + try: + # People might be tempted to provide strings. + # We should raise something useful. + ciphertext, _, _ = c.encrypt("Hallo Leute\n", + recipients=keys, + sign=False, + always_trust=True) + except TypeError as e: + # This test is a bit fragile, because the message + # may very well change. So if the behaviour will change + # this test can easily be deleted. + assert "encode" in str(e) -- 2.7.4 From meno.abels at adviser.com Fri Dec 2 23:59:54 2016 From: meno.abels at adviser.com (Meno Abels) Date: Fri, 2 Dec 2016 23:59:54 +0100 Subject: [PATCH] Re: command line keytocard In-Reply-To: <08A73A20-9975-43DE-B13B-FEE01613F108@adviser.com> References: <3D6E9070-A702-4990-8082-8C39036E0198@adviser.com> <08A73A20-9975-43DE-B13B-FEE01613F108@adviser.com> Message-ID: Now ?quick-keytocard is working for me. I can pass the passphrase and the adminpin down. I solved it by enabling the multiple use of ?passphrase-fd/file here the patch for the passphrase change commit 58bbd77b695a4beab60d6033024e3a7045dd078e gpg: Signature made Fri Dec 2 23:55:25 2016 CET gpg: using RSA key F78D5B547A9BB0E8A174C0F5060FF53CB3A32992 gpg: Good signature from "Meno Abels " [ultimate] Author: Meno Abels Date: Fri Dec 2 23:33:19 2016 gpg: Enable to pass multiple passphrases This feature is required to copy keys in a smartcard without any user interaction. It currently only used by --quick-keytocard with a command line like this: gpg --batch --pinentry-mode loopback --passphrase-file ~/p1 --passphrase-file ~/p2 --quick-keytocard auth This is not a designed solution(hack). This could break any time. Next I will try to build tests explain the odd behavior. The problem is (get_static_passphrase) now have a side effect that after the call to (get_static_passphrase) the next password will be returned on the next call to (get_static_passphrase). And (get_static_passphrase) the order and of calls defines the returned password. I discovered that in gpgsm almost the same code is used. But it is in different files. So should id refactor this? Currently i did not changed this gpgsm. * g10/gpg.c changed switch cases oPassphraseFD/oPassphraseFile to store the incoming file descriptor. * g10/gpg.c passed the collected fds to the new (read_passphrase_from_fds) * g10/keydb.h added STATIC_PASSWORD_COUNT constant (4) * g10/keydb.h modified (read_passphrase_from_fd) to (read_passphrase_from_fds) to pass multiple fds * g10/passphrase.c removed fd_passwd * g10/passphrase.c added fd_passwds[STATIC_PASSWORD_COUNT] * g10/passphrase.c added fd_passwd_idx use count * g10/passphrase.c added fd_passwd_req roundrobin counter * g10/passphrase.c (have_static_passphrase) uses fd_passwd_idx * g10/passphrase.c (get_static_passphrase) roundrobin behavior * g10/passphrase.c (set_passphrase_from_string) appends to fd_passwds * g10/passphrase.c (read_passphrase_from_fd) static and wipe added * g10/passphrase.c (read_passphrase_from_fds) loops over fds * g10/passphrase.c (passphrase_to_dek) change direct use of fw_passwd to (get_static_passphrase) Signed-off-by: Meno Abels diff --git a/doc/gpg.texi b/doc/gpg.texi index 7adccf3..78da66a 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -678,8 +678,8 @@ is written. If 'auth' is choosen the @code{slot} 3 is used. To write to a keyslot needs the smartcard admin pin. This is usally requested with pinentry. In the case of passing the password through loopback pinentry you have to provide a second password. This could -be done with --passphrase-fds. The second specified fd should provide -the admin pin. +be done with --passphrase-fd. You can call --passphrase-fd/file +multiple to pass the admin pin. @item --gen-key @opindex gen-key @@ -2965,8 +2965,8 @@ passphrase. Defaults to 1 repetition. @opindex passphrase-fd Read the passphrase from file descriptor @code{n}. Only the first line will be read from file descriptor @code{n}. If you use 0 for @code{n}, -the passphrase will be read from STDIN. This can only be used if only -one passphrase is supplied. +the passphrase will be read from STDIN. This can called multiple to +pass multiple passphrases. Note that this passphrase is only used if the option @option{--batch} has also been given. This is different from GnuPG version 1.x. @@ -2976,7 +2976,8 @@ has also been given. This is different from GnuPG version 1.x. Read the passphrase from file @code{file}. Only the first line will be read from file @code{file}. This can only be used if only one passphrase is supplied. Obviously, a passphrase stored in a file is -of questionable security if other users can read this file. Don't use +of questionable security if other users can read this file. +This can called multiple to pass multiple passphrases. Don't use this option if you can avoid it. Note that this passphrase is only used if the option @option{--batch} has also been given. This is different from GnuPG version 1.x. @@ -2985,8 +2986,9 @@ has also been given. This is different from GnuPG version 1.x. @opindex passphrase Use @code{string} as the passphrase. This can only be used if only one passphrase is supplied. Obviously, this is of very questionable -security on a multi-user system. Don't use this option if you can -avoid it. +security on a multi-user system. This can called multiple to +pass multiple passphrases. +Don't use this option if you can avoid it. Note that this passphrase is only used if the option @option{--batch} has also been given. This is different from GnuPG version 1.x. diff --git a/g10/gpg.c b/g10/gpg.c index deef69a..edca6c4 100644 --- a/g10/gpg.c +++ b/g10/gpg.c @@ -2270,7 +2270,8 @@ main (int argc, char **argv) char *pers_compress_list = NULL; int eyes_only=0; int multifile=0; - int pwfd = -1; + int pwfds_cnt = 0; + int pwfds[STATIC_PASSWORD_COUNT]; int ovrseskeyfd = -1; int fpr_maybe_cmd = 0; /* --fingerprint maybe a command. */ int any_explicit_recipient = 0; @@ -3036,10 +3037,22 @@ main (int argc, char **argv) set_passphrase_from_string(pargs.r.ret_str); break; case oPassphraseFD: - pwfd = translate_sys2libc_fd_int (pargs.r.ret_int, 0); + if (pwfds_cnt < sizeof(pwfds)/sizeof(pwfds[0])) + { + pwfds[pwfds_cnt++] = translate_sys2libc_fd_int (pargs.r.ret_int, 0); + } + else + { + log_error (_("to much passphrase-fds\n")); + } break; case oPassphraseFile: - pwfd = open_info_file (pargs.r.ret_str, 0, 1); + if (pwfds_cnt < sizeof(pwfds)/sizeof(pwfds[0])) + { + pwfds[pwfds_cnt++] = open_info_file (pargs.r.ret_str, 0, 1); + } else { + log_error (_("to much passphrase-fds\n")); + } break; case oPassphraseRepeat: opt.passphrase_repeat = pargs.r.ret_int; @@ -3876,8 +3889,8 @@ main (int argc, char **argv) g10_exit(0); - if (pwfd != -1) /* Read the passphrase now. */ - read_passphrase_from_fd (pwfd); + /* Read the passphrase now. */ + read_passphrase_from_fds (pwfds, pwfds_cnt); if (ovrseskeyfd != -1 ) /* Read the sessionkey now. */ read_sessionkey_from_fd (ovrseskeyfd); diff --git a/g10/keydb.h b/g10/keydb.h index 8daa9ee..22c2170 100644 --- a/g10/keydb.h +++ b/g10/keydb.h @@ -26,6 +26,7 @@ #include "util.h" #include "packet.h" +#define STATIC_PASSWORD_COUNT 4 /* What qualifies as a certification (rather than a signature?) */ #define IS_CERT(s) (IS_KEY_SIG(s) || IS_UID_SIG(s) || IS_SUBKEY_SIG(s) \ || IS_KEY_REV(s) || IS_UID_REV(s) || IS_SUBKEY_REV(s)) @@ -251,7 +252,7 @@ unsigned char encode_s2k_iterations (int iterations); int have_static_passphrase(void); const char *get_static_passphrase (void); void set_passphrase_from_string(const char *pass); -void read_passphrase_from_fd( int fd ); +void read_passphrase_from_fds( int *fds, int cnt); void passphrase_clear_cache (const char *cacheid); DEK *passphrase_to_dek_ext(u32 *keyid, int pubkey_algo, int cipher_algo, STRING2KEY *s2k, int mode, diff --git a/g10/passphrase.c b/g10/passphrase.c index ccd232a..4067af4 100644 --- a/g10/passphrase.c +++ b/g10/passphrase.c @@ -43,7 +43,9 @@ #include "call-agent.h" #include "../common/shareddefs.h" -static char *fd_passwd = NULL; +static char *fd_passwds[STATIC_PASSWORD_COUNT]; +static int fd_passwd_idx = 0; +static int fd_passwd_req = 0; static char *next_pw = NULL; static char *last_pw = NULL; @@ -102,7 +104,7 @@ encode_s2k_iterations (int iterations) int have_static_passphrase() { - return (!!fd_passwd + return (fd_passwd_idx > 0 && (opt.batch || opt.pinentry_mode == PINENTRY_MODE_LOOPBACK)); } @@ -111,9 +113,14 @@ have_static_passphrase() be returned if no passphrase has been set; better use have_static_passphrase first. */ const char * -get_static_passphrase (void) +get_static_passphrase () { - return fd_passwd; + int idx = fd_passwd_req++ % fd_passwd_idx; + if (fd_passwd_req > fd_passwd_idx) + { + log_info(_("get_static_passphrase did a wrap a round %d"), fd_passwd_req); + } + return fd_passwds[idx]; } @@ -154,14 +161,19 @@ get_last_passphrase() void set_passphrase_from_string(const char *pass) { - xfree (fd_passwd); - fd_passwd = xmalloc_secure(strlen(pass)+1); - strcpy (fd_passwd, pass); + if (fd_passwd_idx < sizeof(fd_passwds)/sizeof(fd_passwds[0])) + { + // xfree (fd_passwd); + fd_passwds[fd_passwd_idx] = xmalloc_secure(strlen(pass)+1); + strcpy (fd_passwds[fd_passwd_idx], pass); + ++fd_passwd_idx; + } else { + log_info(_("try to set too much passwords")); + } } - -void -read_passphrase_from_fd( int fd ) +static void +read_passphrase_from_fd( int fd) { int i, len; char *pw; @@ -200,8 +212,22 @@ read_passphrase_from_fd( int fd ) if (!opt.batch && opt.pinentry_mode != PINENTRY_MODE_LOOPBACK) tty_printf("\b\b\b \n" ); - xfree ( fd_passwd ); - fd_passwd = pw; + set_passphrase_from_string(pw); + // wipe the pass password + for (i = strlen(pw)-1; i >= 0; --i) { + pw[i] = 'X'; + } +} + + +void +read_passphrase_from_fds( int *fds, int cnt ) +{ + int i; + for(i = 0; i < cnt; ++i) + { + read_passphrase_from_fd(fds[i]); + } } @@ -360,9 +386,10 @@ passphrase_to_dek (int cipher_algo, STRING2KEY *s2k, } else if ( have_static_passphrase () ) { + const char *s = get_static_passphrase(); /* Return the passphrase we have stored in FD_PASSWD. */ - pw = xmalloc_secure ( strlen(fd_passwd)+1 ); - strcpy ( pw, fd_passwd ); + pw = xmalloc_secure ( strlen(s)+1 ); + strcpy ( pw, s ); } else { > On 2 Dec 2016, at 21:50, Meno Abels wrote: > > Hi, > > attachments does not work: > > From bf9027719a27dc6c0d5eba5d8a067542ff79514d Mon Sep 17 00:00:00 2001 > From: Meno Abels > Date: Fri, 2 Dec 2016 21:23:39 +0100 > Subject: [PATCH] gpg: New option --quick-keytocard > > * wrote the documentation for the new option (untested) > * g10/card-util.c (send_keytocard) added > * g10/gpg.c added aQuickKeyToCard to cmd_and_opt_values > * g10/gpg.c added ARGPARSE_c with aQuickKeyToCard > * g10/gpg.c added handling for aQuickKeyToCard > * g10/keyedit.c (get_keyno_from_slot_usage) new function > maps commandline option to keyno. > * g10/keyedit.c (is_keyno_matching_usage) tests if the > key has the right usage for the keyno. > * g10/keyedit.c (keyedit_quick_keytocard) new function > to prepare the commandline parameter to call > (send_keytocard) to transfer the key. > * g10/main.h (keyedit_quick_keytocard) forward decl > * g10/main.h (send_keytocard) forward decl > > Tested: by hand i send ~15 keys to reseted yubikeys > and try successfully to use the key for sign,encr,auth > Missing: in batch we need to pass the adminpin via > loopback pinentry > > Signed-off-by: Meno Abels > --- > doc/gpg.texi | 18 +++++++++++ > g10/card-util.c | 62 ++++++++++++++++++++++++++++++++++++ > g10/gpg.c | 25 +++++++++++++++ > g10/keyedit.c | 99 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > g10/main.h | 4 +++ > 5 files changed, 208 insertions(+) > > diff --git a/doc/gpg.texi b/doc/gpg.texi > index b01d0a3..7adccf3 100644 > --- a/doc/gpg.texi > +++ b/doc/gpg.texi > @@ -663,6 +663,24 @@ for the subkey. Several formats are supported; commonly the ISO > YYYY-MM-DD format is used. The values ``never'', ``none'', or ``-'' > can be used for no expiration date. > > + > + at item --quick-keytocard @code{fpr} (@code{slot}|@code{usage}) [@code{serial}] > + at opindex quick-keytocard > +Sends the key identified by the fingerprint @code{fpr} to the by > + at code{serial} identified smartcard. If @code{serial} is not set > +the first card will be used. The @code{serial} is the serialnumber > +of the smartcard. This number is found in "--card-status". > +The @code{slot} and @code{usage} specify the slot in the smartcard > +which should receive the choosen key. @code{slot} is just the number > +of the slot starting with 1. The @code{usage} maps if 'sign' is to > + at code{slot} 1. If @code{usage} is set to 'encr' the @code{slot} 2 > +is written. If 'auth' is choosen the @code{slot} 3 is used. > +To write to a keyslot needs the smartcard admin pin. This is usally > +requested with pinentry. In the case of passing the password through > +loopback pinentry you have to provide a second password. This could > +be done with --passphrase-fds. The second specified fd should provide > +the admin pin. > + > @item --gen-key > @opindex gen-key > Generate a new key pair using the current default parameters. This is > diff --git a/g10/card-util.c b/g10/card-util.c > index e358572..b905a29 100644 > --- a/g10/card-util.c > +++ b/g10/card-util.c > @@ -1628,6 +1628,68 @@ card_store_subkey (KBNODE node, int use) > return okay; > } > > +int > +send_keytocard(PKT_public_key *pk, int keyno, const char *serialno) { > + gnupg_isotime_t timebuf; > + struct agent_card_info_s info; > + unsigned int nbits; > + gpg_error_t err = 0; > + int rc = 0; > + char *hexgrip = 0; > + int okay = 0; > + > + if (get_info_for_key_operation (&info)) > + { > + log_error (_("get_info_for_key_operations: failed:%s"), > + gpg_strerror (err)); > + goto leave; > + } > + if (serialno && *serialno && strcmp(info.serialno, serialno)) { > + log_error (_("The card serial no does not match %s!=%s"), serialno, > + info.serialno); > + goto leave; > + } > + if (!info.extcap.ki) > + { > + log_error (_("The card does not support the import of keys")); > + goto leave; > + } > + nbits = nbits_from_pk (pk); > + if (!info.is_v2 && nbits != 1024) > + { > + log_error (_("You may only store a 1024 bit RSA key on the card")); > + goto leave; > + } > + if (info.is_v2 && !info.extcap.aac > + && info.key_attr[keyno-1].nbits != nbits) > + { > + log_error (_("Key does not match the card's capability. %d %d"), keyno, nbits); > + goto leave; > + } > + if ((keyno == 1 && info.fpr1valid) > + || (keyno == 2 && info.fpr2valid) > + || (keyno == 3 && info.fpr3valid)) { > + log_info (_("replace existing key in slot %d"), keyno); > + } > + if ((err = hexkeygrip_from_pk (pk, &hexgrip))) { > + log_error (_("hexkeygrip_from_pk failed with %s"), gpg_strerror(err)); > + goto leave; > + } > + epoch2isotime (timebuf, (time_t)pk->timestamp); > + if ((err = agent_keytocard (hexgrip, keyno, rc, info.serialno, timebuf))) { > + log_error (_("agent_keytocard failed: %s\n"), gpg_strerror (rc)); > + if ((rc = agent_scd_learn (NULL, 1))) { > + log_error (_("agent_scd_learn failed: %s\n"), gpg_strerror (rc)); > + } > + } else { > + okay = 1; > + } > +leave: > + xfree (hexgrip); > + agent_release_card_info (&info); > + return okay; > +} > + > > > /* Direct sending of an hex encoded APDU with error printing. */ > diff --git a/g10/gpg.c b/g10/gpg.c > index 7cf51f2..deef69a 100644 > --- a/g10/gpg.c > +++ b/g10/gpg.c > @@ -123,6 +123,7 @@ enum cmd_and_opt_values > aQuickAddUid, > aQuickAddKey, > aQuickRevUid, > + aQuickKeyToCard, > aListConfig, > aListGcryptConfig, > aGPGConfList, > @@ -448,6 +449,8 @@ static ARGPARSE_OPTS opts[] = { > ARGPARSE_c (aQuickAddKey, "quick-addkey", "@"), > ARGPARSE_c (aQuickRevUid, "quick-revuid", > N_("quickly revoke a user-id")), > + ARGPARSE_c (aQuickKeyToCard, "quick-keytocard", > + N_("send a secret key to a smartcard")), > ARGPARSE_c (aFullKeygen, "full-gen-key" , > N_("full featured key pair generation")), > ARGPARSE_c (aGenRevoke, "gen-revoke",N_("generate a revocation certificate")), > @@ -2549,6 +2552,7 @@ main (int argc, char **argv) > case aQuickAddUid: > case aQuickAddKey: > case aQuickRevUid: > + case aQuickKeyToCard: > case aExportOwnerTrust: > case aImportOwnerTrust: > case aRebuildKeydbCaches: > @@ -3953,6 +3957,7 @@ main (int argc, char **argv) > case aQuickAddUid: > case aQuickAddKey: > case aQuickRevUid: > + case aQuickKeyToCard: > case aFullKeygen: > case aKeygen: > case aImport: > @@ -4383,6 +4388,26 @@ main (int argc, char **argv) > keyedit_quick_revuid (ctrl, uid, uidtorev); > } > break; > + case aQuickKeyToCard: > + { > + const char *x_fpr, *x_slot_usage, *x_smartcard_serial; > + > + if (argc < 1 || argc > 4) > + wrong_args ("--quick-addkey FINGERPRINT (SLOT|USAGE) [SMARTCARDSERIAL]"); > + x_fpr = *argv++; argc--; > + x_slot_usage = ""; > + x_smartcard_serial = ""; > + if (argc) > + { > + x_slot_usage = *argv++; argc--; > + if (argc) > + { > + x_smartcard_serial = *argv++; argc--; > + } > + } > + keyedit_quick_keytocard (ctrl, x_fpr, x_slot_usage, x_smartcard_serial); > + } > + break; > > case aFastImport: > opt.import_options |= IMPORT_FAST; > diff --git a/g10/keyedit.c b/g10/keyedit.c > index 94fa8c4..764c0df 100644 > --- a/g10/keyedit.c > +++ b/g10/keyedit.c > @@ -3341,6 +3341,105 @@ keyedit_quick_addkey (ctrl_t ctrl, const char *fpr, const char *algostr, > keydb_release (kdbhd); > } > > +int > +get_keyno_from_slot_usage(const char *slot_usage) > +{ > + int keyno = 1; > + if (strcmp(slot_usage, "sign")) > + { > + keyno = 2; > + if (strcmp(slot_usage, "encr")) > + { > + keyno = 3; > + if (strcmp(slot_usage, "auth")) > + { > + keyno = atoi(slot_usage); > + } > + } > + } > + return keyno; > +} > + > +int > +is_keyno_matching_usage(int keyno, int usage) > +{ > + if (keyno == 1) { > + if (!(usage & (PUBKEY_USAGE_SIG|PUBKEY_USAGE_CERT))) { > + log_error (_("the key for slot 1 is not for signature or certification")); > + return 0; > + } > + } > + if (keyno == 2) { > + if (!(usage & (PUBKEY_USAGE_ENC))) { > + log_error (_("the key for slot 2 is not for encryption")); > + return 0; > + } > + } > + if (keyno == 3) { > + if (!(usage & (PUBKEY_USAGE_SIG|PUBKEY_USAGE_AUTH))) { > + log_error (_("the key for slot 1 is not for signature or authentication")); > + return 0; > + } > + } > + return 1; > +} > +/* Unattended send a key to a smartcard */ > +void > +keyedit_quick_keytocard (ctrl_t ctrl, const char *fpr, const char *slot_usage, > + const char *serialno) > +{ > + gpg_error_t err; > + kbnode_t keyblock; > + KEYDB_HANDLE kdbhd; > + KBNODE node = NULL; > + > +#ifdef HAVE_W32_SYSTEM > + /* See keyedit_menu for why we need this. */ > + check_trustdb_stale (ctrl); > +#endif > + > + /* We require a fingerprint because only this uniquely identifies a > + * key */ > + err = get_pubkey_byname (ctrl, NULL, NULL, fpr, &keyblock, &kdbhd, 1, 1); > + if (err) > + { > + log_error (_("key \"%s\" not found: %s\n"), fpr, gpg_strerror (err)); > + goto leave; > + } > + > + for (node = keyblock; node; node = node->next) > + { > + if (PKT_PUBLIC_KEY == node->pkt->pkttype || > + PKT_PUBLIC_SUBKEY == node->pkt->pkttype || > + PKT_SECRET_KEY == node->pkt->pkttype) > + { > + PKT_public_key *pk = node->pkt->pkt.public_key; > + char hexfpr[2*MAX_FINGERPRINT_LEN+1]; > + hexfingerprint (pk, hexfpr, sizeof hexfpr); > + if (!strcmp(fpr, hexfpr)) > + { > + int keyno = get_keyno_from_slot_usage(slot_usage); > + if (!(1 <= keyno && keyno <= 3)) > + { > + log_error (_("slot has to be 1,2,3 is %s"), slot_usage); > + goto leave; > + } > + if (!is_keyno_matching_usage(keyno, pk->pubkey_usage)) > + { > + goto leave; > + } > + if (send_keytocard(pk, keyno, serialno)) > + { > + log_info(_("keytocard for %s to slot %u successful"), hexfpr, keyno); > + } > + } > + } > + } > +leave: > + release_kbnode (keyblock); > + keydb_release (kdbhd); > +} > + > > > static void > diff --git a/g10/main.h b/g10/main.h > index 63aec47..c73f682 100644 > --- a/g10/main.h > +++ b/g10/main.h > @@ -295,6 +295,9 @@ 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 keyedit_quick_keytocard (ctrl_t ctrl, const char *fpr, > + const char *slot_usage, const char *sm_serial); > + > void show_basic_key_info (KBNODE keyblock); > > /*-- keygen.c --*/ > @@ -479,6 +482,7 @@ void card_status (estream_t fp, char *serialno, size_t serialnobuflen); > void card_edit (ctrl_t ctrl, strlist_t commands); > gpg_error_t card_generate_subkey (KBNODE pub_keyblock); > int card_store_subkey (KBNODE node, int use); > +int send_keytocard(PKT_public_key *pk, int keyno, const char *serialno); > #endif > > #define S2K_DECODE_COUNT(_val) ((16ul + ((_val) & 15)) << (((_val) >> 4) + 6)) > -- > 2.9.3 (Apple Git-75) > > ----BEGIN PGP MESSAGE----- > Comment: GPGTools - http://gpgtools.org > > owGtOWuUG9V5NpAEBjg0aRvSkwauRb0rWQ8krbRP2/F6d71ee3e9rGTAx3bGo5k7 > 0rDSzHge+8DeNKcttCE1SSk+pQkxJ3U5+UNJS9I8CmkTSoDEPBIMNOfUENrGlAZT > oNR5EZd+370z0mgkrTc5kX12Zu583/3ej/vNpy6/cM3Fa999xdmNXzweu2PtiddK > a24cPnV6m2XUSEkdSGf7+jIDUrZPkXvltJKnJSmv9Evp3r58LquqfQP5TE4hU4ZO > CtQkmT6STg+y/ySbTmcE3GaQTFHdIMMlWrXJxhrcpyS83yIp85pNrZRs1DYLo5JD > B8k2S0uQLBmlMuBnekk2M5jtGewZIPF0Jp0WCm7pJio7g2TvzHBxZPt+UjbLg2Sa > LhDDdDRgIpk86GryXHKOLjmGLFmKIGwgC5bhUOJUKFEM2QUGHIkBq4bFVvUGftTV > HWo7VIkBXjmTvhb3SLqOVk3JJGpTXRHrW8eIpChU8QCBEwBhK0S6DpnYSZeKxggA > Escgck0RJcAGOuK8VHWp3QZveHZ8Zni2MCbKZEFzKuF92mBUYM+qppeZLO3BgV+q > aA7yX6YOsq8bogp2Ee2q4YiuLZVpjOlAdXUZtSDUJNMmYJUa35362gE5GHqqdWvN > 9nauSY5cAY78jVGdNtFU1LQAIMCyzbRuaeWKQxhU3RKddvduRWbcoAWa2Ab2TIua > ksWNHRQAFqUadajFbCFVq0KLMeGFY0m6rdI6Lz4nNUnTU5UV2AD+F9DQCpWrIZww > mSZQocicbZCUlpgpiUYQnnw0k0f6NjJlURsYV8iSW9JwTUA4x1oitivL1LZVt1pd > QkDXpj7jTKG2VtYTVJethOQ6FWFKs22wyyDRdFJCI5EFdH3K3NOUbG4VSalpugkg > 85okVA3DLEnyHIEFiBprSRAKsClVkoaqJktLq4vsZDIpYOQxx3Xookbgd5hk+km8 > 8RNaou0w6c0GITr+hEBU8N9hks2HUYWQTyHUwMCqCKxA1bOyR5XkCHuTJ6pWpRBC > YNMyVSCjpftB7aAR9FM7Go8JgqKpKqSrsuYQ6dom7ZSaHgVNV+giKaUzSlrqSaX6 > JEWW1R4C6bA3l0PlhvAFYCG8x5YtJNnb25PoJXG8ZHMEVvygs90S+jqBDD5PLamK > LyCKbYKBZLumaVjgf0MsngwdfQ2QJgq7BLIHfsmpqeToqIdDNBvdUIHNigDEEx05 > cEDHnbu7E3hr6BTvgPiBA8nubgHCERySMjzGE3gUXTQ1iydpBepCSiBCXIhv0Rxa > a03xZItsKPSQalrLJMrvMbMtH+b3LMMsx8he7xW1NKm6vB+2M0yu23DJiBcgBu16 > LGkK+L6masBeiQuvQhxRy7Q03QkSxwwCb0tLsHeQVnAHuyZZDlJJkQmVhMBskN2B > DOAIcU7Gsh3CRFzQqlVfSSmm2xZUZkr2qLu1ErWEuKHyxQbJYgVpsNeIohou5hyd > RJJJFno2VEbXjqSEeIAE6pJg0gnqk9gmlTWV6wNBcJsmakJ8oaJBlrErhltVII3J > VJv3MnPFMCDPsRTbRAV4uskFmVlVDkmBNIA/CCEod6w8ZoKa8NhipQuqTTdmv26m > F6NuDkYjE9C8hwRQoHS0Xzfmy25GMIiTFeIAs2BpjkN1ht+NOZXt7wsTxumpBwNo > 02DIFElILLOjNJh87Wal8fyL+dYzFtsD6hX4lEUPuqxccOn9nAzscOKyBAUAtIW5 > HHWEa3i/YGALUrEMt1wR4i05nSwZLhSfecacaRnz4K3ApE1lA2zub+CxI6MthXgJ > Wykoq4yRZBKBzIoF9JOqYnOrePjcTdDzVcV3BY8Id/KGwBDixA/xMtUxIGHBD9L6 > yjjVIUs5yCNWf4xQU9IsUJMvtOxaFogGJVaV3KrTKP42y0tMq835N1x7SuEVLwvT > nnx/vi+bSpUG0nkpO9CchcM4PBGHVzEXZ3qz/ZiM+bUfszGCiLZjWFTkCZlEd26d > 3jU6BjlBoQmCuQa8KSZApbGo41o6MeakpSGBLGN2hNdCvLnXiM7sLIqmW6pqMi6S > DeYc34Z1WQmwpY7ppSJZZIOXOIwYOSTECSnrrlkWNdtwtBoVITLgUnLVIXxnO5Yr > g9LAII7IuNZ01RBBqXBhEK5usy6BEdNLmmOzZahGIrUsw4IN4Uo2kTRbRyhLrj9y > hip0sWxpZhMQyustsCWVd7SMPBQOFBL6a+oVjmgXvojFEJQJRUjV8DggUTEa6Yxr > DxJVggquDK63I7EERw78UBJQg7cVXGKxIQ5UNiCIqhSiiS0s+3z6+iVdXQ1l4wNs > I9fMKPKR8tcTpG6OWHvWiyzcIaw5IJZMxaC8fLAGnKy3121izNf3ahWjiej5JFjH > oOkipCkzNad1VmudtzpHXg/BYlOrsVtIU5gFIysqjrkOGJxd+ZHFnCNRc44jNbiC > w8d8FrXJMdZtgrjM5jqzuAcyXg18iXUzLOYgmSAKAXwyWxhmWcXw06qlrMwnMtLM > R5OyJEnmuPCCraOvSY5j7WWBmMzsT9X5ZjedGYezXdjQPovdkJwlUyppVc2BmrBe > gf9ofi/Y+cbnESLKgMkm0F+dWehsMtDHaUrM95/Dh0kDMBsEzK4A2BME7OGATd6N > 75iQcISrSjKFJlCzWbFnTZjOO4CAULEQ8zynQOKAt5g7gh6TIF1eRol1iqk2iDwJ > 8CrHgykY+ecNfGoaciXrZVES9ZJogt+JTsycS27GW+hqambDpz1BeIJtdLlRT4C6 > SS05QUJ5wyPRUcbwnl6WA+H26WHxSNSS6+IxvliS5lvYsiKCtFCEotO7JycTJBOg > 2Z5qA2XVVJkWlwmcKKm/t1cDMr6WmcoH8WFRtSita4lvwSlbFKBs2ihWfm1gME3F > NL6MXQj+u3YDGdWgaXXYiRzdEHIWnFQq2Abo2OcpZHhmdDf3Ds47OxEAKLQZG65t > 7TD4EbXUuPe6ij5ZzWdU6CoUStXeAam1q+DQjX6CP7NOIstOdXjpwzaCQtvcbtjE > zMIHRMOKsltTEqElSC1NS7N0nkHFG0v1yZIPOAkBOmLoqlYOrozL1pIZWh+fGccF > fJ1gfOdyrAHK5QYSrP3Bk4cmNyZgu2aKBRw72Xv3g7kP4TaB6Vi0iW1CIvwIJykK > +HYkQSJbsGy3xfHkquNYdN7VlIjHaOM3DY7LIKBEAIwxhzUCGjArqWE5YIpp3b2h > ojqBerRFWiow0mDzHtZugyOyVMfOCPUTAaMVlmSbW60CKfBupIMTIL9jjpC2kiAI > USmc7izw23rPXOa9NLQ8bclAqz3LRAeN4v5cD5HENOue6m04Lsu86ZJxxKFq8ETZ > jmjqbB6MDLbO5vNZ7qQ4NcGSCYFhlSGL8ZZvAzzMQ397CeFHmaC3DrZZBgW0LHPr > Qj5oXq6bJYgwtoityK4FkKNowakz+G6i1vKu8eMgs5BptSpyoZRGJLlC7UEmbs9A > noUkXPtWI25wz2aJ273hQre8qcvd8iYoevBlw4VCL9oucn1wAXM9/UxAuPYnsr2r > lRB/zQNUHnokKjtWNUFcjEr4g+3YPKTmOhKcby4pWVSaG1pZvHpwHQrGWfCUsyhC > 75HAa2P0zR/9aBN5LfVOGP4Pqx8KRjZCYwRdDbvfTHKx5oBesAy9LMJLm0Qj/piK > 5ySybWJ6fGx2ZnZiukiihcldxcO7C8PjYzGytzA1PFscGZ4dLYzNTgxP7o/EhoLb > Mp4hBTJlxuNDjHgyGYJpyAOgkUj4bUi8VhhfwpBEh8IZK0RpJaZW2Lbt1h1ZPR8R > r0/o8NhhZu97necSzR7RykbQJrC9748kFFOS7fiRUmcAiliKn3pE/hnFJoc3kYmp > mV2zRXHbcKE41NopNMbUpeZnr2MYyKlSv5xLpfp6c3JaUVs7hgZGo2torLE81ZPL > sDyF10w6j3HcrCzPdZmm4MzOFRaMJ6a64IJULRvQybFKMoeJ0e+94CCglCpKrGlc > 0fFzVLRpNNH4SiXED/mzAO9c4TWC7IjNT9JBO0ZwDhFpGgH4eNlAY9sOE+eAHmbA > V33snro7dMLH8WAdv8nb/T0kx9ACOA0PWw42v4EOlSF6LSpXYIePbtHAkIePjYLK > UwOHsky9Z2eH6SiP6y4Sndm9defYHpHlKLEwMX64aWFkbLa4Qr/f9BEKD20Zf7Tt > f5ZifQh+Amj0C7wHqSvBkzk9FFZGE//ZVfE/Nj3yy3CbDXKLfrBk/mrc9fxq2h3e > Xdz+69EuOiF+efgl1GvRV9mbDHc0OAXthv0caFLx4wXvVVubVDzuxOcNTRHiK+bb > 1WWRQCC1KxIs37abXXoeHpozMhHnSjhFFVlYlKqGzHsJ0PnoVnH78PTo5BhhCYov > N+auEKd4vmX9wDWaqlCVbB++fky8oScrFvYUimNTiABaKlBaz541OIQxYyxUlhof > WSuazc+FbMZJQTkOdpaQI+HsU6VcQWiha/C8qfIOBHa+gRKc/GtsSBX88lSisoTf > fL1vcvilQNcOurQa+GRlE4mpcAMzGifOxwuYfE02aBZLS7pUo35F5Od5/peZpsvX > Gd6ikuC0jwf+eubFOUgoUTa7LNLeF4HjfsTzU1cPHP8Zkc4j1ZbZCvNUvEEVRz0r > 1e3KzDbkGw8vyc06XXSCRQCZxuE4hN3kxIgIboDhymHNOYf9cZZMCr1ewwEDCAUW > rqvEKYyNzI4VOxMJq651ak/CaKnG+0ZPjLFQoYugzb3ZDVPDN4qBllOcHJuOZ/bX > gREu4ElsQMZxE5BBbqaG6j3GmgrdOq/SMTgPoF2JCxbozkW+Xe3zU2WGbNzkbdHV > 5d1sxIwa6CSbOshmh2N5sSLhxz/8appJZBPsc5w3EW9LuI2f1VNjgLVONdertzjT > 88KKU+jE8GqIhb7noJU8Mo0PBCvoA2dcXvj58z7Qz3qmFT5MdYntyjK1bdWtomZ8 > HwjMV0OMhZqTxvjNH7LxTMuqIAtIvkuHZtAft10m+AMgVkRa+mE8X6YqXhvLH7xO > uLdHonKuL5WS+3rU3v5sayfsgTfaYG+BjSYG8mwyAZcB7H+R+gqH1LblC2dCmD9b > 5i5NvyaMwCG3DUUs4ecplyuQghCtarYDqEDGTgSewRqubfGWEO75oaYN/f9abdHu > VJzbyRxsjpvWa4ETlqcOu2IsiCXJ5hnOm9h6RTngVmxIC2aeYwMLOCslk1Dg2ISi > jw2ccv3evInt6n1gheYIjucUa41UA9FUMxHqI3gKFJ16kJVctUr1urXYRqivkHoa > mpaNWk3SFfze0tSNcFR/chb+zgtpQwyKh3Za9WfhIXYkIL+GL8BDgkO8FgQ0fA20 > PJpOSSG7UxwdGwHC4siu3dPFKA6WYyQazfS6VRKHG77QRTJ56F03boQVb2kzTkoA > pBeSFZhLyKYGUj0kOmya0PWMa06yLx8ThI9f0HPRmrUXr/nQ+9dd9JMje4s3f+Zv > X/mc842z777i7MYvHo/d8a4Lbhw+dXqNcMlv+CvP3nvFufd//I3C2d/J/Medez70 > v/+jP/6VP97/rqMHz3zyq9l3xNJ7nh5Z1m/fMabf++PHvvt/hUvuzN/+wtKbn775 > kYFt/zm07cznRm946+Dak989ZR7//l3vvUf72C3LkvaZk9KTb3Z/+czXv2c8/ejF > ByIf/vzWfQ+ee23qmPQT+WPv3Xi5k/7h7tOv3/qdnWde/8NnRt5ev7Dd/Ob3rzt3 > /auXPvNU92XvG3t4t7Hjg/tH37gydePlk9f9waXuX754dOSt+x9/5cm9S/kbXnzn > sasuOvPRkcrkVTu7rto/8Ogjjz0cfW5CWbdZ/GFt5r4dt920zjwVveXM0X/+ys+i > A8f3Hfn3+Mj4C2Nnzqz9xcMvxk5sO0Rf+Jcv3Hn78QdPf+8j9x77zntqz27+1uv/ > ps+m3h56/O1HH77yg8/9fP3XT//u3x+5e+7P/2Tdjpc2PXE0e/SdWvX4iU8ePGLc > 9g/PyKfPfeO+Z7cmf/HqrT+9d8dnx7uunn5AVv7q6VeVi9684JVrzj1RflmbvvBb > T129b/LM9M+ev+fC+7/87Ytf+tcH8nvvfui+V9b9zV1fG/rCTx+687Mf3vpnXzqx > fPUnvn3yt2966Pfeia259Xl6ee/zL98yZi+e/f2b7//v3JB1R+TSr732kad+NJhZ > zn/gWO1L13drn3/ut/7oU490U6n3MvfgE4MvfPrkNydvveDRJ3/ztsTRKz7xvjd+ > fOyfTvz1j8bP9ab+8dj4W39X+upbz/385bWXPvDmzkM/2PXEgy/9oP/kuTvuufLu > Pz3yFx84FD1xavSu/wc= > =KMn1 > -----END PGP MESSAGE----- > > >> On 2 Dec 2016, at 21:45, Meno Abels wrote: >> >> Hi, >> >> i yesterday, ask about this new option. >> And now I used this lazy friday evening to implement the first part. >> I tried to figure out how to contribute code and the right coding style. Both I did not >> had success with. So please be patient with me and give me feedback what i should change >> to get this in upstream. >> >> I attached the patch from this commit: >> ce29272e24e7b718b8fca9b84bc728e65f3dea24 >> >> I?m not sure how the process with code contribution works in gpg so again please be >> patient and give me feedback. >> >> Next i will try to find a solution to the loopback pinentry to pass both password. >> >> Thx in advance >> >> meno >> >> <0001-gpg-New-option-quick-keytocard.patch><0001-gpg-New-option-quick-keytocard.patch.asc> >> >>> On 1 Dec 2016, at 13:26, Meno Abels wrote: >>> >>> hello, >>> >>> i tried to invoke from the --card-edit menu the keytocard function within batch file. But that seams not work. >>> >>> Which is a document feature ?card-edit is a interactive tool. >>> >>> To make it working, I would try to implement ?quick-keytocard in the same style like ?quick-addkey. >>> >>> I looked around in gpgme and didn?t not found any entry point which allows me to do keytocard. >>> >>> My question is, if i try now to implement quick-keytocard, would you accept my patch? >>> >>> Or is there any other idea how to send a key from gpg to a smartcard within a batch? >>> >>> I currently only know one bigger obstacle keytocard needs a passphrase and the adminpin both a gather via >>> pinentry. This leads to a extension to the batch mode command line (--no-tty --pinentry-mode loopback --passphrase-fd). >>> >>> Thx in advance >>> >>> meno >>> >>> >>> >> >> _______________________________________________ >> Gnupg-devel mailing list >> Gnupg-devel at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-devel > From bre at pagekite.net Fri Dec 2 20:49:50 2016 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Fri, 02 Dec 2016 19:49:50 -0000 Subject: [openpgp-email] On Signed-Only Mails In-Reply-To: <201612021129.25156.bernhard@intevation.de> References: <201612021129.25156.bernhard@intevation.de> Message-ID: <93bIsYIC5dHBB5JgffThCY94yaMhijWWroEPXwXa2178@mailpile> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello! Thanks Vincent for starting an interesting discussion. Bernhard Reiter wrote: > > https://github.com/mailpile/Mailpile/issues/1693 > > Here it also is irritation. Not so much irritation, as recognizing that sending non-technical people detached signatures (or keys) causes confusion, because usually when people are sent attachments the attachments are important and useful. So they make an effort to open them up, without much luck. We're wasting peoples' time, which is impolite at best. Wasting peoples' time may be justified if there is some education to be derived from it; sadly most signature.asc files (and keys) don't have much educational value today! Mailpile is experimenting with adding a very small HTML wrapper around the PGP content to rectify that. In-line signatures do not appear to cause the same confusion, people are used to ignoring junk at the bottom of the message. This is a data point that supports Mailpile's current recommended default of using inline signatures when the message only has a single text part, upgrading to PGP/MIME only for more complex messages. I wanted to highlight this specifically, since if I recall correctly, Mailpile is going against the GnuPG community's "best practices" by avoiding PGP/MIME and I've had heated discussions about this with people in the past. I don't know if this will change anyone's mind, but I feel it is a useful data point all the same. > == Better email-clients are a key success factor ... > Given a possible solution by improved clients, we should try > first to make them happen before giving up on signed-only > emails, which is the solution you proposed. You may say: But > this hasn't work for many years. I'd agree with this notion, > but because of the non-linear nature we don't know how close we > are to the tipping point. I think this is an interesting point. I also feel that signed e-mail has value, in that it raises the bar and has the potential to make it harder to impersonate people. That benefit also won't really be realized until after a tipping point is reached - encryption (and signatures) need to be commonplace enough that an unsigned message can be treated as an anomaly, at least in some contexts. We're not there yet. Even someone like me who uses a PGP-enabled mail client 90% of the time still reaches for the mobile GMail app now and then, sending unsigned mail. Every time I do, I weaken the signal sent by my normal signatures. Until we reach the tipping point, Vincent's argument that signatures are basically just cognitive load and bloat is largely correct. Better tools can help. Better interfaces can help; I'm on the fence in part because Mailpile wants to be one of those better tools. But I don't think Vincent is wrong to offer his users a simplified interface in the meantime. The interesting question is, whether his simplified interfaces will help us reach a tipping point sooner. They might! All the best, - Bjarni -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYQdBHAAoJEI4ANxYAz5SRz9wH/1X+wMlRgtss0ewun8G0fNHq gibBnI2FyYecKMLEP7IiaQvIQf9aTq/8s1Nk+5g+X42YVVUQNZIKJJejiHZ9O6Lk bZNDtTyL0ThMCRZ/yVeWF7SFpSMA16ux2M5dy381NsoMsG9v+XAl1HxlJjvbGYlQ MqBX2EJ4r7OtoU5oiwXEnX6HklxYOgxCbynwItWhm9cqqc+NeKsup3NPvfr/N7WB ochxM5QsqCC6Wx9+cN15EoBlkwBHGU+lU5hAN/iJ9zXo/Fxfg1BMw6eYFkHtYVit r+kV4b6RIjHvhb26f5i+QKi2C2uqe0s8GDH14XnfM4EBJza32l8rt/hFgQry3MA= =UY+L -----END PGP SIGNATURE----- From wk at gnupg.org Sat Dec 3 16:24:02 2016 From: wk at gnupg.org (Werner Koch) Date: Sat, 03 Dec 2016 16:24:02 +0100 Subject: [openpgp-email] On Signed-Only Mails In-Reply-To: <20161202131043.GA11156@littlepip.fritz.box> (Vincent Breitmoser's message of "Fri, 2 Dec 2016 14:10:43 +0100") References: <20161129092040.GA3043@littlepip.fritz.box> <201612021129.25156.bernhard@intevation.de> <20161202131043.GA11156@littlepip.fritz.box> Message-ID: <87lgvxt4rx.fsf@wheatstone.g10code.de> On Fri, 2 Dec 2016 14:10, look at my.amazin.horse said: > another mechanism like keyservers. We don't even get the whole > fingerprint as an identifier, but instead have to assume that if the > signature checks out we have the right key. Depends on your OpenPGP implementation. GnuPG already uses the #### Issuer Fingerprint (1 octet key version number, N octets of fingerprint) The OpenPGP Key fingerprint of the key issuing the signature. This subpacket SHOULD be included in all signatures. If the version of the issuing key is 4 and an Issuer subpacket is also included in the signature, the key ID of the Issuer subpacket MUST match the low 64 bits of the fingerprint. Note that the length N of the fingerprint for a version 4 key is 20 octets. which we agreed upon in the WG. I hope that OpenKeychain will add that signature subpacket soon. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From bogorodskiy at gmail.com Sat Dec 3 17:00:53 2016 From: bogorodskiy at gmail.com (Roman Bogorodskiy) Date: Sat, 3 Dec 2016 19:00:53 +0300 Subject: Was gnupg-2.1.16.tar.bz2.sig updated? Message-ID: <20161203160051.GB1750@kloomba> Hi, It looks like gnupg-2.1.16.tar.bz2.sig was updated after releasing of gnupg 2.1.16. At time of release it was: SHA256 (gnupg-2.1.16.tar.bz2.sig.orig) = 91dd1279956a533a721f3e2dc06a092248cea8bd9a5259dc19f8d7573c1d3d12 Now it is: SHA256 (gnupg-2.1.16.tar.bz2.sig) = b00b297eed7dcbbb259e960b9e4442de031124f41ea870efa5e7a367a9779fa7 It looks like an additional signature was added: $ gpg2 --verify gnupg-2.1.16.tar.bz2.sig.orig /usr/ports/distfiles/gnupg-2.1.16.tar.bz2 gpg: Signature made ???????, 18 ?????? 2016 ?. 18:58:06 gpg: using RSA key D8692123C4065DEA5E0F3AB5249B39D24F25E3B6 gpg: Good signature from "Werner Koch (dist sig)" [ultimate] $ gpg2 --verify gnupg-2.1.16.tar.bz2.sig /usr/ports/distfiles/gnupg-2.1.16.tar.bz2 gpg: Signature made ???????, 18 ?????? 2016 ?. 18:58:06 gpg: using RSA key D8692123C4065DEA5E0F3AB5249B39D24F25E3B6 gpg: Good signature from "Werner Koch (dist sig)" [ultimate] gpg: Signature made ???????, 19 ?????? 2016 ?. 07:18:00 gpg: using RSA key 2071B08A33BD3F06 gpg: Good signature from "NIIBE Yutaka (GnuPG Release Key) " [expired] gpg: Note: This key has expired! Primary key fingerprint: 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 Also, the new sig is reported as expired. Was that an intentional change? The reason I'm asking is that both release tarball and the sig are used by the FreeBSD port [1], and when a checksum changes for any of the files, port refuses to use it (unless there's some mirror with the old file or unless user explicitly forces it to continue). 1: https://svnweb.freebsd.org/ports/head/security/gnupg/distinfo?revision=426573&view=co Roman Bogorodskiy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: not available URL: From wk at gnupg.org Sat Dec 3 21:23:54 2016 From: wk at gnupg.org (Werner Koch) Date: Sat, 03 Dec 2016 21:23:54 +0100 Subject: Was gnupg-2.1.16.tar.bz2.sig updated? In-Reply-To: <20161203160051.GB1750@kloomba> (Roman Bogorodskiy's message of "Sat, 3 Dec 2016 19:00:53 +0300") References: <20161203160051.GB1750@kloomba> Message-ID: <878trwu5gl.fsf@wheatstone.g10code.de> On Sat, 3 Dec 2016 17:00, bogorodskiy at gmail.com said: > It looks like gnupg-2.1.16.tar.bz2.sig was updated after releasing of > gnupg 2.1.16. Sure. We do this very often as soon as a co-developer has verified the released package. We consider it better to have more than one signature. > Also, the new sig is reported as expired. Gniibe has prolonged the expiration time of his key and thus with a fresh copy of the key it won't claim that it is expired. Refreshing the keys on a regular base is anyway a good idea to get notice of revocations. > The reason I'm asking is that both release tarball and the sig are used > by the FreeBSD port [1], and when a checksum changes for any of the Well, the signature file is the checksum of tarball and as such the signature file should be used as is and not be used as a trigger for updates. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From muelli at cryptobitch.de Sat Dec 3 23:12:37 2016 From: muelli at cryptobitch.de (Tobias Mueller) Date: Sat, 3 Dec 2016 23:12:37 +0100 Subject: [PATCH] python: default op_keylist_start parameters. Message-ID: <20161203221237.GA13139@cryptobitch.de> * lang/python/gpgme.i: Added gpgme_op_keylist_start with defaults * lang/python/tests/t-keylist.py: Added tests for default parameters -- To increase the ease of use, op_keylist_start parameters default to sensible values. The empty string matches all keys. We assume that the user wants to retrieve public keys most of the time, so we default to public keys rather than secret keys. Signed-off-by: Tobias Mueller --- lang/python/gpgme.i | 9 +++++++++ lang/python/tests/t-keylist.py | 12 ++++++++++++ 2 files changed, 21 insertions(+) diff --git a/lang/python/gpgme.i b/lang/python/gpgme.i index 783531f..0e2feec 100644 --- a/lang/python/gpgme.i +++ b/lang/python/gpgme.i @@ -586,6 +586,15 @@ } } + +/* With SWIG, you can define default arguments for parameters. + * While it's legal in C++ it is not in C, so we cannot change the + * already existing gpgme.h. We need, however, to declare the function + * *before* SWIG loads it from gpgme.h. Hence, we define it here. */ +gpgme_error_t gpgme_op_keylist_start (gpgme_ctx_t ctx, + const char *pattern="", + int secret_only=0); + /* Include the unmodified for cc, and the cleaned-up local version for SWIG. We do, however, want to hide certain fields on some structs, which we provide prior to including the version for diff --git a/lang/python/tests/t-keylist.py b/lang/python/tests/t-keylist.py index ea2a724..5077ca6 100755 --- a/lang/python/tests/t-keylist.py +++ b/lang/python/tests/t-keylist.py @@ -219,6 +219,18 @@ result = c.op_keylist_result() assert not result.truncated, "Key listing unexpectedly truncated" +# We test for a parameter-less keylist +keyring_length = len(list(c.op_keylist_all())) +assert keyring_length > 1,\ + "Expected to find some keys, but got %r" % keyring_length + +# Then we do want to call with a pattern, only +# i.e. without giving secret=0 +alpha_keys = list(c.op_keylist_all(b"Alpha")) +assert len(alpha_keys) == 1, "Expected only one key for 'Alpha', got %r" % len(alpha_keys) + + + for i, key in enumerate(c.keylist()): try: if len(keys[i]) == 4: -- 2.7.4 From justus at g10code.com Mon Dec 5 12:55:50 2016 From: justus at g10code.com (Justus Winter) Date: Mon, 05 Dec 2016 12:55:50 +0100 Subject: [PATCH] python: default op_keylist_start parameters. In-Reply-To: <20161203221237.GA13139@cryptobitch.de> References: <20161203221237.GA13139@cryptobitch.de> Message-ID: <874m2ifv3t.fsf@europa.jade-hamburg.de> Tobias Mueller writes: > * lang/python/gpgme.i: Added gpgme_op_keylist_start with defaults > * lang/python/tests/t-keylist.py: Added tests for default parameters ... > +/* With SWIG, you can define default arguments for parameters. > + * While it's legal in C++ it is not in C, so we cannot change the > + * already existing gpgme.h. We need, however, to declare the function > + * *before* SWIG loads it from gpgme.h. Hence, we define it here. */ > +gpgme_error_t gpgme_op_keylist_start (gpgme_ctx_t ctx, > + const char *pattern="", > + int secret_only=0); Interesting, I didn't know that. Is SWIG using C++ under the hood, or are they parsing this and changing the prologue of the generated wrapper function? I'm not sure whether we want to do this or not. Currently, we provide a very faithful "C-like API", and a idiomatic Python API on top. And indeed, in the idiomatic key listing API we provide exactly these defaults: def keylist(self, pattern=None, secret=False): """List keys Keyword arguments: pattern -- return keys matching pattern (default: all keys) secret -- return only secret keys Your patch deviates from that pattern. Thoughts? Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From justus at g10code.com Mon Dec 5 12:59:07 2016 From: justus at g10code.com (Justus Winter) Date: Mon, 05 Dec 2016 12:59:07 +0100 Subject: [PATCH] python: define a macro for wrapping fragile result objects. In-Reply-To: <20161201201512.GA27571@cryptobitch.de> References: <20161201201512.GA27571@cryptobitch.de> Message-ID: <871sxmfuyc.fsf@europa.jade-hamburg.de> Tobias Mueller writes: > * lang/python/gpgme.i: defined a wrapresult macro Merged, thanks! Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From justus at g10code.com Mon Dec 5 12:59:38 2016 From: justus at g10code.com (Justus Winter) Date: Mon, 05 Dec 2016 12:59:38 +0100 Subject: [PATCH] python: Try to be more helpful when given a string to encrypt() In-Reply-To: <20161202223727.GA27467@cryptobitch.de> References: <20161202223727.GA27467@cryptobitch.de> Message-ID: <87y3zuegd1.fsf@europa.jade-hamburg.de> Tobias Mueller writes: > * lang/python/helpers.c (_gpg_obj2gpgme_data_t): Extended error message > * lang/python/tests/t-encrypt.py: Test for "encode" in error message > -- > The motivation is to help the user when encrypting fails. I claim that > it is not obvious to not being able to encrypt a string directly. > To nudge the user into encoding it to bytes, the error message is a bit > extended. Merged, thanks! Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From muelli at cryptobitch.de Mon Dec 5 13:46:19 2016 From: muelli at cryptobitch.de (Tobias Mueller) Date: Mon, 5 Dec 2016 13:46:19 +0100 Subject: [PATCH] python: default op_keylist_start parameters. In-Reply-To: <874m2ifv3t.fsf@europa.jade-hamburg.de> References: <20161203221237.GA13139@cryptobitch.de> <874m2ifv3t.fsf@europa.jade-hamburg.de> Message-ID: <20161205124619.GA3269@cryptobitch.de> Hi. On Mon, Dec 05, 2016 at 12:55:50PM +0100, Justus Winter wrote: > Interesting, I didn't know that. Is SWIG using C++ under the hood, or > are they parsing this and changing the prologue of the generated wrapper > function? No idea. I can try to find out if you want me to. > I'm not sure whether we want to do this or not. Currently, we provide a > very faithful "C-like API", and a idiomatic Python API on top. I cannot make much sense of the term "faithful", but I think that it does not exclude making the "C-like API" more usable. I think the C-like API has already been made significantly easier to use, by, e.g. raising Python exceptions, allowing buffer- or file-like objects instead of Data objects, or providing lists instead of making the user call next(). So my feeling is that providing sensible default values goes in the same direction. Other instances I have in mind are making Data.seek()'s "whence" default to os.SEEK_SET like BufferIO and StringIO do or defaulting "pubkey" and "seckey" parameters of op_genkey to NULL, because you currently have to do it when you want to generate openpgp keys. These also requires to change the "C-API" and I hope this is in the scope of the Python bindings. > Thoughts? I'm thinking that it's one additional line which increases the usability of the API. I appreciate that every line of code costs maintenance in the long run. My feeling is that it's a reasonable price to pay for making the API a bit more discoverable. Of course, my judgement is not worth much here; if only because it's likely that it won't be me who has to pay that price ;-) Cheers, Tobi From dkg at fifthhorseman.net Mon Dec 5 14:26:39 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 05 Dec 2016 08:26:39 -0500 Subject: [PATCH] python: default op_keylist_start parameters. In-Reply-To: <874m2ifv3t.fsf@europa.jade-hamburg.de> References: <20161203221237.GA13139@cryptobitch.de> <874m2ifv3t.fsf@europa.jade-hamburg.de> Message-ID: <87h96ise0g.fsf@alice.fifthhorseman.net> On Mon 2016-12-05 06:55:50 -0500, Justus Winter wrote: > I'm not sure whether we want to do this or not. Currently, we provide a > very faithful "C-like API", and a idiomatic Python API on top. And > indeed, in the idiomatic key listing API we provide exactly these > defaults: > > def keylist(self, pattern=None, secret=False): > """List keys > > Keyword arguments: > pattern -- return keys matching pattern (default: all keys) > secret -- return only secret keys > > Your patch deviates from that pattern. If it works (i haven't tested it), I'd say this patch actually is in line with this pattern. The main (only?) advantage i can see to using SWIG at all over CFFI or ctypes is that it's possible to generate bindings for other languages as well as python at the same time. The closer we can bring the SWIG interfaces to the sensible defaults that have already been provided for python, the better for all languages that eventually will derive from the SWIG interface. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From findaphone40 at gmail.com Mon Dec 5 19:01:10 2016 From: findaphone40 at gmail.com (brian huffman) Date: Mon, 5 Dec 2016 12:01:10 -0600 Subject: Gnupg-devel Digest, Vol 159, Issue 5 In-Reply-To: References: Message-ID: What is this? On Dec 5, 2016 5:59 AM, wrote: > Send Gnupg-devel mailing list submissions to > gnupg-devel at gnupg.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > or, via email, send a message with subject or body 'help' to > gnupg-devel-request at gnupg.org > > You can reach the person managing the list at > gnupg-devel-owner at gnupg.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Gnupg-devel digest..." > > Today's Topics: > > 1. Re: [openpgp-email] On Signed-Only Mails (Bjarni Runar Einarsson) > 2. Re: [openpgp-email] On Signed-Only Mails (Werner Koch) > 3. Was gnupg-2.1.16.tar.bz2.sig updated? (Roman Bogorodskiy) > 4. Re: Was gnupg-2.1.16.tar.bz2.sig updated? (Werner Koch) > 5. [PATCH] python: default op_keylist_start parameters. > (Tobias Mueller) > 6. Re: [PATCH] python: default op_keylist_start parameters. > (Justus Winter) > 7. Re: [PATCH] python: define a macro for wrapping fragile > result objects. (Justus Winter) > > > ---------- Forwarded message ---------- > From: Bjarni Runar Einarsson > To: OpenPGP-based Email Encryption > Cc: GnuPG Development List > Date: Fri, 02 Dec 2016 19:49:50 -0000 > Subject: Re: [openpgp-email] On Signed-Only Mails > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello! > > Thanks Vincent for starting an interesting discussion. > > Bernhard Reiter wrote: > > > https://github.com/mailpile/Mailpile/issues/1693 > > > > Here it also is irritation. > > Not so much irritation, as recognizing that sending non-technical > people detached signatures (or keys) causes confusion, because > usually when people are sent attachments the attachments are > important and useful. So they make an effort to open them up, > without much luck. We're wasting peoples' time, which is impolite > at best. > > Wasting peoples' time may be justified if there is some education > to be derived from it; sadly most signature.asc files (and keys) > don't have much educational value today! Mailpile is > experimenting with adding a very small HTML wrapper around the > PGP content to rectify that. > > In-line signatures do not appear to cause the same confusion, > people are used to ignoring junk at the bottom of the message. > This is a data point that supports Mailpile's current recommended > default of using inline signatures when the message only has a > single text part, upgrading to PGP/MIME only for more complex > messages. > > I wanted to highlight this specifically, since if I recall > correctly, Mailpile is going against the GnuPG community's "best > practices" by avoiding PGP/MIME and I've had heated discussions > about this with people in the past. I don't know if this will > change anyone's mind, but I feel it is a useful data point all > the same. > > > > == Better email-clients are a key success factor > ... > > Given a possible solution by improved clients, we should try > > first to make them happen before giving up on signed-only > > emails, which is the solution you proposed. You may say: But > > this hasn't work for many years. I'd agree with this notion, > > but because of the non-linear nature we don't know how close we > > are to the tipping point. > > I think this is an interesting point. I also feel that signed > e-mail has value, in that it raises the bar and has the potential > to make it harder to impersonate people. That benefit also won't > really be realized until after a tipping point is reached - > encryption (and signatures) need to be commonplace enough that an > unsigned message can be treated as an anomaly, at least in some > contexts. > > We're not there yet. Even someone like me who uses a PGP-enabled > mail client 90% of the time still reaches for the mobile GMail > app now and then, sending unsigned mail. Every time I do, I > weaken the signal sent by my normal signatures. > > Until we reach the tipping point, Vincent's argument that > signatures are basically just cognitive load and bloat is largely > correct. > > Better tools can help. Better interfaces can help; I'm on the > fence in part because Mailpile wants to be one of those better > tools. But I don't think Vincent is wrong to offer his users a > simplified interface in the meantime. > > The interesting question is, whether his simplified interfaces > will help us reach a tipping point sooner. They might! > > All the best, > - Bjarni > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJYQdBHAAoJEI4ANxYAz5SRz9wH/1X+wMlRgtss0ewun8G0fNHq > gibBnI2FyYecKMLEP7IiaQvIQf9aTq/8s1Nk+5g+X42YVVUQNZIKJJejiHZ9O6Lk > bZNDtTyL0ThMCRZ/yVeWF7SFpSMA16ux2M5dy381NsoMsG9v+XAl1HxlJjvbGYlQ > MqBX2EJ4r7OtoU5oiwXEnX6HklxYOgxCbynwItWhm9cqqc+NeKsup3NPvfr/N7WB > ochxM5QsqCC6Wx9+cN15EoBlkwBHGU+lU5hAN/iJ9zXo/Fxfg1BMw6eYFkHtYVit > r+kV4b6RIjHvhb26f5i+QKi2C2uqe0s8GDH14XnfM4EBJza32l8rt/hFgQry3MA= > =UY+L > -----END PGP SIGNATURE----- > > > ---------- Forwarded message ---------- > From: Werner Koch > To: OpenPGP-based Email Encryption > Cc: gnupg-devel at gnupg.org > Date: Sat, 03 Dec 2016 16:24:02 +0100 > Subject: Re: [openpgp-email] On Signed-Only Mails > On Fri, 2 Dec 2016 14:10, look at my.amazin.horse said: > > > another mechanism like keyservers. We don't even get the whole > > fingerprint as an identifier, but instead have to assume that if the > > signature checks out we have the right key. > > Depends on your OpenPGP implementation. GnuPG already uses the > > #### Issuer Fingerprint > > (1 octet key version number, N octets of fingerprint) > > The OpenPGP Key fingerprint of the key issuing the signature. This > subpacket SHOULD be included in all signatures. If the version of the > issuing key is 4 and an Issuer subpacket is also included in the > signature, the key ID of the Issuer subpacket MUST match the low > 64 bits of the fingerprint. > > Note that the length N of the fingerprint for a version 4 key is 20 > octets. > > which we agreed upon in the WG. I hope that OpenKeychain will add that > signature subpacket soon. > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > > ---------- Forwarded message ---------- > From: Roman Bogorodskiy > To: gnupg-devel at gnupg.org > Cc: > Date: Sat, 3 Dec 2016 19:00:53 +0300 > Subject: Was gnupg-2.1.16.tar.bz2.sig updated? > Hi, > > It looks like gnupg-2.1.16.tar.bz2.sig was updated after releasing of > gnupg 2.1.16. > > At time of release it was: > > SHA256 (gnupg-2.1.16.tar.bz2.sig.orig) = > 91dd1279956a533a721f3e2dc06a092248cea8bd9a5259dc19f8d7573c1d3d12 > > Now it is: > SHA256 (gnupg-2.1.16.tar.bz2.sig) = > b00b297eed7dcbbb259e960b9e4442de031124f41ea870efa5e7a367a9779fa7 > > It looks like an additional signature was added: > > $ gpg2 --verify gnupg-2.1.16.tar.bz2.sig.orig /usr/ports/distfiles/gnupg-2. > 1.16.tar.bz2 > gpg: Signature made ???????, 18 ?????? 2016 ?. 18:58:06 > gpg: using RSA key D8692123C4065DEA5E0F3AB5249B39D24F25E3B6 > gpg: Good signature from "Werner Koch (dist sig)" [ultimate] > > $ gpg2 --verify gnupg-2.1.16.tar.bz2.sig /usr/ports/distfiles/gnupg-2. > 1.16.tar.bz2 > gpg: Signature made ???????, 18 ?????? 2016 ?. 18:58:06 > gpg: using RSA key D8692123C4065DEA5E0F3AB5249B39D24F25E3B6 > gpg: Good signature from "Werner Koch (dist sig)" [ultimate] > gpg: Signature made ???????, 19 ?????? 2016 ?. 07:18:00 > gpg: using RSA key 2071B08A33BD3F06 > gpg: Good signature from "NIIBE Yutaka (GnuPG Release Key) < > gniibe at fsij.org>" [expired] > gpg: Note: This key has expired! > Primary key fingerprint: 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 > > Also, the new sig is reported as expired. > > Was that an intentional change? > > The reason I'm asking is that both release tarball and the sig are used > by the FreeBSD port [1], and when a checksum changes for any of the > files, port refuses to use it (unless there's some mirror with the old > file or unless user explicitly forces it to continue). > > 1: > https://svnweb.freebsd.org/ports/head/security/gnupg/ > distinfo?revision=426573&view=co > > Roman Bogorodskiy > > > ---------- Forwarded message ---------- > From: Werner Koch > To: Roman Bogorodskiy > Cc: gnupg-devel at gnupg.org > Date: Sat, 03 Dec 2016 21:23:54 +0100 > Subject: Re: Was gnupg-2.1.16.tar.bz2.sig updated? > On Sat, 3 Dec 2016 17:00, bogorodskiy at gmail.com said: > > > It looks like gnupg-2.1.16.tar.bz2.sig was updated after releasing of > > gnupg 2.1.16. > > Sure. We do this very often as soon as a co-developer has verified the > released package. We consider it better to have more than one > signature. > > > Also, the new sig is reported as expired. > > Gniibe has prolonged the expiration time of his key and thus with a > fresh copy of the key it won't claim that it is expired. Refreshing the > keys on a regular base is anyway a good idea to get notice of > revocations. > > > The reason I'm asking is that both release tarball and the sig are used > > by the FreeBSD port [1], and when a checksum changes for any of the > > Well, the signature file is the checksum of tarball and as such the > signature file should be used as is and not be used as a trigger for > updates. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > > ---------- Forwarded message ---------- > From: Tobias Mueller > To: gnupg-devel at gnupg.org > Cc: > Date: Sat, 3 Dec 2016 23:12:37 +0100 > Subject: [PATCH] python: default op_keylist_start parameters. > * lang/python/gpgme.i: Added gpgme_op_keylist_start with defaults > * lang/python/tests/t-keylist.py: Added tests for default parameters > -- > > To increase the ease of use, op_keylist_start > parameters default to sensible values. > The empty string matches all keys. > We assume that the user wants to retrieve public keys most of the time, > so we default to public keys rather than secret keys. > > Signed-off-by: Tobias Mueller > --- > lang/python/gpgme.i | 9 +++++++++ > lang/python/tests/t-keylist.py | 12 ++++++++++++ > 2 files changed, 21 insertions(+) > > diff --git a/lang/python/gpgme.i b/lang/python/gpgme.i > index 783531f..0e2feec 100644 > --- a/lang/python/gpgme.i > +++ b/lang/python/gpgme.i > @@ -586,6 +586,15 @@ > } > } > > + > +/* With SWIG, you can define default arguments for parameters. > + * While it's legal in C++ it is not in C, so we cannot change the > + * already existing gpgme.h. We need, however, to declare the function > + * *before* SWIG loads it from gpgme.h. Hence, we define it here. */ > +gpgme_error_t gpgme_op_keylist_start (gpgme_ctx_t ctx, > + const char *pattern="", > + int secret_only=0); > + > /* Include the unmodified for cc, and the cleaned-up local > version for SWIG. We do, however, want to hide certain fields on > some structs, which we provide prior to including the version for > diff --git a/lang/python/tests/t-keylist.py b/lang/python/tests/t-keylist. > py > index ea2a724..5077ca6 100755 > --- a/lang/python/tests/t-keylist.py > +++ b/lang/python/tests/t-keylist.py > @@ -219,6 +219,18 @@ result = c.op_keylist_result() > assert not result.truncated, "Key listing unexpectedly truncated" > > > +# We test for a parameter-less keylist > +keyring_length = len(list(c.op_keylist_all())) > +assert keyring_length > 1,\ > + "Expected to find some keys, but got %r" % keyring_length > + > +# Then we do want to call with a pattern, only > +# i.e. without giving secret=0 > +alpha_keys = list(c.op_keylist_all(b"Alpha")) > +assert len(alpha_keys) == 1, "Expected only one key for 'Alpha', got %r" > % len(alpha_keys) > + > + > + > for i, key in enumerate(c.keylist()): > try: > if len(keys[i]) == 4: > -- > 2.7.4 > > > > > ---------- Forwarded message ---------- > From: Justus Winter > To: Tobias Mueller , gnupg-devel at gnupg.org > Cc: > Date: Mon, 05 Dec 2016 12:55:50 +0100 > Subject: Re: [PATCH] python: default op_keylist_start parameters. > Tobias Mueller writes: > > > * lang/python/gpgme.i: Added gpgme_op_keylist_start with defaults > > * lang/python/tests/t-keylist.py: Added tests for default parameters > > ... > > > +/* With SWIG, you can define default arguments for parameters. > > + * While it's legal in C++ it is not in C, so we cannot change the > > + * already existing gpgme.h. We need, however, to declare the function > > + * *before* SWIG loads it from gpgme.h. Hence, we define it here. */ > > +gpgme_error_t gpgme_op_keylist_start (gpgme_ctx_t ctx, > > + const char *pattern="", > > + int secret_only=0); > > Interesting, I didn't know that. Is SWIG using C++ under the hood, or > are they parsing this and changing the prologue of the generated wrapper > function? > > > I'm not sure whether we want to do this or not. Currently, we provide a > very faithful "C-like API", and a idiomatic Python API on top. And > indeed, in the idiomatic key listing API we provide exactly these > defaults: > > def keylist(self, pattern=None, secret=False): > """List keys > > Keyword arguments: > pattern -- return keys matching pattern (default: all keys) > secret -- return only secret keys > > Your patch deviates from that pattern. > > > Thoughts? > Justus > > > ---------- Forwarded message ---------- > From: Justus Winter > To: Tobias Mueller , gnupg-devel at gnupg.org > Cc: > Date: Mon, 05 Dec 2016 12:59:07 +0100 > Subject: Re: [PATCH] python: define a macro for wrapping fragile result > objects. > Tobias Mueller writes: > > > * lang/python/gpgme.i: defined a wrapresult macro > > Merged, thanks! > > Justus > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Tue Dec 6 04:59:05 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 05 Dec 2016 22:59:05 -0500 Subject: Key creation problem with 2.1.16 In-Reply-To: <20161129230429.B2488100B190@remailer.paranoici.org> References: <20161129230429.B2488100B190@remailer.paranoici.org> Message-ID: <8760mxoghi.fsf@alice.fifthhorseman.net> On Tue 2016-11-29 18:04:29 -0500, Carola Grunwald wrote: > after key creation, which usually succeeds, gpg.exe sometimes returns > error number 2, which looks like a bug. you gave two examples of output, but you didn't mention what specific commands you're running. were you running something like: gpg --batch --gen-key < key_gen.cfg ? are you saying that running the exact same command multiple times sometimes fails and other times succeeds? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From meno.abels at adviser.com Tue Dec 6 07:37:53 2016 From: meno.abels at adviser.com (Meno Abels) Date: Tue, 6 Dec 2016 07:37:53 +0100 Subject: DCO and batch smartcard features Message-ID: Hi, i did not see my last emails in the mailing list archives so i assume that they got lost. So I resend them again: First my 3 patches around keytocard features, which I stored on github(https://github.com/mabels/gnupg/tree/quick-keytocard) to allow an easy cherry-pick here the sha1?s: 1) commit bf9027719a27dc6c0d5eba5d8a067542ff79514d Author: Meno Abels Date: Fri Dec 2 21:23:39 2016 gpg: New option --quick-keytocard 2) commit 58bbd77b695a4beab60d6033024e3a7045dd078e Author: Meno Abels Date: Fri Dec 2 23:33:19 2016 gpg: Enable to pass multiple passphrases 3) commit ac30d7170ee9efe7c3f87bd2e754ef9119126bb9 Author: Meno Abels Date: Sun Dec 4 14:38:08 2016 gpg: changed --change-pin to working unattendant And the needed DCO here: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 GnuPG Developer's Certificate of Origin. Version 1.0 ===================================================== By making a contribution to the GnuPG project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the free software license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate free software license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same free software license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the free software license(s) involved. Signed-off-by: meno.abels at adviser.com -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEE941bVHqbsOihdMD1Bg/1PLOjKZIFAlhGWqEACgkQBg/1PLOj KZIE3A/+IezzOUrmJ2AL9XAbfIMx7f5QYNlIX/zL0eGG4M0zsMjky/PlUn3tyjcR XX/yssyuRhErn7SwD6ITMBe0gltc/GOiGihBS7D8z8N1R92EYM2SJOEcK+uAnrsD tzk2lbgj3hthjqcYw7cVZLEFSXgX/AMPyqu/c/TF+8t0vxE7dE46ocZXf6aWSIBt kv3BrJnkdeI10cCR1fF5qecAdrxofqLRwwdpVLTH7OtxqrClv+OucT0AR0kwzn1h romQMtZ7nMQpgS7l+rYYNIgD20KQQ5DkXL+NmDB4Mc0ea/FbYce7ElLr/QHqSLk8 1JCYD+EohQQQdJyuqJfjVY7WPdIGs7HNWpd1HuCpdUggPpyaOyBMPgrXbRPbRJ2N Jg2yPwMuH+24Oia0xVTgUEgJ7XYGJvAa8CKugLUbM0l88wNuoNrRef2iyIPrvpGw 9SH1yQEhpvM7omz983N8LBYcxZ1gSbVZmK2LlJoBW564uw57j0qKJecgK84qVJHY 4xAxn+rb0kMuJs6irCzOv+00N/Whtudy0iOPG1+vb36V2tYW3l8Q6jjfyfesOY3J 6AKccD9Qrnoud3DcTmXZsOjZFJatvEZnSwKMNjwnNDECX/avLpB2PO0ng2G4eo0p t/OwOPURVKr4Q9aqEOKMfbdUkdVYrRa+LA99ZbLexM3EXeC8tD8= =aCHe -----END PGP SIGNATURE?? Thx meno From caro at nymph.paranoici.org Tue Dec 6 13:41:20 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Tue, 6 Dec 2016 12:41:20 +0000 (UTC) Subject: Key creation problem with 2.1.16 References: <20161129230429.B2488100B190@remailer.paranoici.org> <8760mxoghi.fsf@alice.fifthhorseman.net> Message-ID: <20161206124120.A4B1A1032319@remailer.paranoici.org> On Mon, 05 Dec 2016 22:59:05 -0500, Daniel Kahn Gillmor wrote: >On Tue 2016-11-29 18:04:29 -0500, Carola Grunwald wrote: >> after key creation, which usually succeeds, gpg.exe sometimes returns >> error number 2, which looks like a bug. > >you gave two examples of output, but you didn't mention what specific >commands you're running. > >were you running something like: > > gpg --batch --gen-key < key_gen.cfg > >? I'v attached my application's complete log of the 'gpg.exe' program call including the command line string ('Application' + ' ' + 'ExeStr') with the 'Environment' parameter(s) set. > >are you saying that running the exact same command multiple times >sometimes fails and other times succeeds? Yes, that's what I wrote. It's not necessarily a problem with the GenKey code but may rather point to an unreliable gpg - agent IPC, which, as gpg starts a new agent instance minutes after processing begins to fail, would also explain the many orphaned gpg-agent.exe entries in my Task Manager's Processes list. Kind regards Caro From neal at walfield.org Tue Dec 6 14:54:10 2016 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 06 Dec 2016 14:54:10 +0100 Subject: INBOME comments Message-ID: <87y3zt17ul.wl-neal@walfield.org> Hi! Unfortunately, it looks like I won't be able to attend the AME workshop. Nevertheless, I'd like to share my comments on the INBOME draft [1]. - Is there a reason to not build on the "The OpenPGP mail and news header field" specification and instead invent a new header [2]? (This specification doesn't support transferring the actual keys in the headers. Instead, a key identifier is specified and a URI pointing to the key can be provided.) - I'm not sure that transferring keys in mail headers is a great idea. For instance, gpg's minimal version of my key is 4.8KB. This is the binary version, i.e., it hasn't been ASCII encoded. $ gpg --export-options export-minimal --export 0xAACB3243630052D9 | wc -c 4811 Do you not view this as a problem? - In the group communication example, Alice sends a message to Bob and Carol at which point Bob and Carol learn about Alice's INBOME preferences. Why doesn't Alice also include Bob and Carol's latest IMBOME header so that Bob and Carol can immediately learn about Carol and Bob's keys, respectively, without additional interactions? - When I described INBOME to Werner, he noted that adoption by mail providers will probably be harder than convincing them to adopt WKS. I was initially confused by his statement, because INBOME only requires that the MUAs be modified. He then pointed out that most users use webmail. I'd be interested to hear about how you plan to get INBOME widely adopted. Thanks! :) Neal [1] https://inbome.readthedocs.io/en/latest/ [2] https://josefsson.org/openpgp-header/ From neal at walfield.org Tue Dec 6 15:09:13 2016 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 06 Dec 2016 15:09:13 +0100 Subject: Handling a TOFU conflict Message-ID: <87wpfd175i.wl-neal@walfield.org> Hi, Currently, when a TOFU conflict is encountered, the --status-fd transcript looks like the following: $ gpg --command-fd 0 --status-fd 1 --trust-model tofu -r 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 -e [GNUPG:] KEY_CONSIDERED 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 0 [GNUPG:] KEY_CONSIDERED 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 0 [GNUPG:] KEY_CONSIDERED 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 0 [GNUPG:] KEY_CONSIDERED 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 0 The email address "joke.factory at example.com" is associated with 3 keys! Please indicate whether this email address should be associated with key 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 or whether you think someone is impersonating "joke.factory at example.com". This key's user IDs: Joke Factory (policy: auto) Statistics for keys with the email address "joke.factory at example.com": 1604 5E5F D857 2D7C 44AA 6DCE CC8D 32F3 1C00 5AF3 (this key): Encrypted 0 messages. Verified 0 messages. 6F34 3BAD CC2A BE3C 5A2E 295B 2A16 A78F B662 E42F (policy: auto): Encrypted 0 messages. Verified 0 messages. 97D6 8CB9 B03F 8137 EB88 4940 EE7C 7DA4 BE04 EB2B (policy: auto): Encrypted 0 messages. Verified 0 messages. Normally, an email address is associated with a single key. However, people sometimes generate a new key if their key is too old or they think it might be compromised. Alternatively, a new key may indicate a man-in-the-middle attack! Before accepting this association, you should talk to or call the person to make sure this new key is legitimate. [GNUPG:] GET_LINE tofu.conflict The MUA has to manually figure out what the conflicting keys are and gather the statistics. In addition to the extra work for the programmer and the minor computational overhead, this introduces a small race. Further, it means that the MUA has to know that conflicts are based on the email address (and not whole user id) as well as any normalization rules that we use. Currently, we only lowercase the email address, but one could imagine adding support for google's aliases ('.'s don't mean anything) and puny code. I think that we should change this to print the stats for each conflicting binding before the tofu.conflict prompt is emitted. For this, I propose either using pairs of TOFU_USER/TOFU_STATS lines or just using the TOFU_STATS line, but extending it to include the required context (i.e., the fingerprint and the mbox). Thus, the --status-fd output could look like this: [GNUPG:] KEY_CONSIDERED 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 0 [GNUPG:] TOFU_USER [GNUPG:] TOFU_STATS ... [GNUPG:] TOFU_USER [GNUPG:] TOFU_STATS ... [GNUPG:] GET_LINE tofu.conflict I'm confident that this would at least simplify the TOFU integration in EPG. Other thoughts? Thanks! :) Neal From dkg at fifthhorseman.net Tue Dec 6 16:58:46 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 06 Dec 2016 10:58:46 -0500 Subject: INBOME comments In-Reply-To: <87y3zt17ul.wl-neal@walfield.org> References: <87y3zt17ul.wl-neal@walfield.org> Message-ID: <87inqxm4ll.fsf@alice.fifthhorseman.net> Hi Neal-- On Tue 2016-12-06 08:54:10 -0500, Neal H. Walfield wrote: > Unfortunately, it looks like I won't be able to attend the AME > workshop. sorry we'll miss you! > - Is there a reason to not build on the "The OpenPGP mail and news > header field" specification and instead invent a new header [2]? > (This specification doesn't support transferring the actual keys in > the headers. Instead, a key identifier is specified and a URI > pointing to the key can be provided.) It's conceivable that INBOME could work with S/MIME & CMS as well as OpenPGP. It's not clear that it must be OpenPGP-specific. > - I'm not sure that transferring keys in mail headers is a great > idea. For instance, gpg's minimal version of my key is 4.8KB. > This is the binary version, i.e., it hasn't been ASCII encoded. > > $ gpg --export-options export-minimal --export 0xAACB3243630052D9 | wc -c > 4811 > > Do you not view this as a problem? that's not sufficiently minimal ;) the minimal openpgp cert for a given e-mail address would be: A * primary key B * user id C * self-sig D * encryption-capable subkey E * self-sig (no cross-cert needed) so it should be about: 2*(sizeof key) + 2*(sizeof signature) + (sizeof uid). for 3072-bit RSA, i agree that's large, but it's not even 2KiB. for 25519 keys, that's less than 200B > - In the group communication example, Alice sends a message to Bob > and Carol at which point Bob and Carol learn about Alice's INBOME > preferences. Why doesn't Alice also include Bob and Carol's latest > IMBOME header so that Bob and Carol can immediately learn about > Carol and Bob's keys, respectively, without additional > interactions? While i think something like that could be useful, we need to be extremely cautious about the consequences of allowing "drive-by" INBOME data. The analogy in the DNS world is "cache poisoning". If i can set, clear, or reset your INBOME data for someone else even if i don't have access to the communitions channel, what are the consequences for your future communications? > - When I described INBOME to Werner, he noted that adoption by mail > providers will probably be harder than convincing them to adopt > WKS. I was initially confused by his statement, because INBOME > only requires that the MUAs be modified. He then pointed out that > most users use webmail. I'd be interested to hear about how you > plan to get INBOME widely adopted. INBOME explicitly excludes full-webmail from its model. This is a simplifying assumption, and certainly it's possible that some webmail implementers may want to provide hooks to interact with browser extensions that do the inbome management. But webmail itself is essentially in its design a provider-trust model, which is not end-to-end. fortunately, people are now used to installing "apps" again, as we whipsaw back and forth between the merits of "thin clients" vs "local processing", so punting on webmail seems ok for the meantime to me. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From dkg at fifthhorseman.net Tue Dec 6 17:09:56 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 6 Dec 2016 11:09:56 -0500 Subject: [PATCH] agent: Respect --enable-large-secmem Message-ID: <20161206160956.576-1-dkg@fifthhorseman.net> * agent/gpg-agent.c (main): Initialize secmem to the configured buffer size. -- This patch is a step toward addressing GnuPG-bug-id: 2857 Signed-off-by: Daniel Kahn Gillmor --- agent/gpg-agent.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/agent/gpg-agent.c b/agent/gpg-agent.c index 710357c..5e2e4bf 100644 --- a/agent/gpg-agent.c +++ b/agent/gpg-agent.c @@ -1055,7 +1055,7 @@ main (int argc, char **argv ) } /* Initialize the secure memory. */ - gcry_control (GCRYCTL_INIT_SECMEM, 32768, 0); + gcry_control (GCRYCTL_INIT_SECMEM, SECMEM_BUFFER_SIZE, 0); maybe_setuid = 0; /* -- 2.10.2 From dkg at fifthhorseman.net Tue Dec 6 17:51:58 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 06 Dec 2016 11:51:58 -0500 Subject: Key creation problem with 2.1.16 In-Reply-To: <20161206124120.A4B1A1032319@remailer.paranoici.org> References: <20161129230429.B2488100B190@remailer.paranoici.org> <8760mxoghi.fsf@alice.fifthhorseman.net> <20161206124120.A4B1A1032319@remailer.paranoici.org> Message-ID: <87fum1m24x.fsf@alice.fifthhorseman.net> Hi Carola-- On Tue 2016-12-06 07:41:20 -0500, Carola Grunwald wrote: > I'v attached my application's complete log of the 'gpg.exe' program call > including the command line string ('Application' + ' ' + 'ExeStr') with > the 'Environment' parameter(s) set. ok, but it felt a bit like "burying the lede" in your attachments -- it's a lot easier to understand what's going on if you describe it clearly at the top of your message. that may be one of the reasons it took nearly a week for anyone to respond to your message. now let's see if we can solve this! > It's not necessarily a problem with the GenKey code but may rather point > to an unreliable gpg - agent IPC, which, as gpg starts a new agent > instance minutes after processing begins to fail, would also explain the > many orphaned gpg-agent.exe entries in my Task Manager's Processes list. it would be great to see some logs for the gpg-agent processes -- if they're dying or becoming zombiefied, what were they doing when that happened? if the IPC is flakey, where is it failing? the main difference between your two logs seems to be that the agent in the failed case is actually asking gpg for a passphrase, whereas it *wasn't* asking gpg for a passphrase in the successful case. what would cause the agent to behave differently like that, given that it had already done INQUIRE NEWPASSWD ? do you think the agent died and a new agent started up, which hadn't cached the previous password? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From wk at gnupg.org Tue Dec 6 20:50:52 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 06 Dec 2016 20:50:52 +0100 Subject: [PATCH] agent: Respect --enable-large-secmem In-Reply-To: <20161206160956.576-1-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 6 Dec 2016 11:09:56 -0500") References: <20161206160956.576-1-dkg@fifthhorseman.net> Message-ID: <871sxkq1k3.fsf@wheatstone.g10code.de> On Tue, 6 Dec 2016 17:09, dkg at fifthhorseman.net said: > * agent/gpg-agent.c (main): Initialize secmem to the configured buffer > size. Please go ahead and push it. As you noted, this is not enough and we should have an --enable-large-rsa option for gpg-agent so that we can screen keys before we use them. Regarding the bug report: ...... .... okay we talked about it. Right now working on Libgcrypt. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From dkg at fifthhorseman.net Tue Dec 6 22:02:02 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 06 Dec 2016 16:02:02 -0500 Subject: [PATCH] agent: Respect --enable-large-secmem In-Reply-To: <871sxkq1k3.fsf@wheatstone.g10code.de> References: <20161206160956.576-1-dkg@fifthhorseman.net> <871sxkq1k3.fsf@wheatstone.g10code.de> Message-ID: <87inqwlqk5.fsf@alice.fifthhorseman.net> On Tue 2016-12-06 14:50:52 -0500, Werner Koch wrote: > On Tue, 6 Dec 2016 17:09, dkg at fifthhorseman.net said: >> * agent/gpg-agent.c (main): Initialize secmem to the configured buffer >> size. > > Please go ahead and push it. pushed, thanks. > As you noted, this is not enough and we should have an > --enable-large-rsa option for gpg-agent so that we can screen keys > before we use them. I don't think i understand this need. what do you mean "screen keys" ? the agent is capable of importing large keys and using them, once this patch is applied and we configure with --enable-large-secmem. Are you suggesting that we'd need a runtime argument to gpg-agent in order to be able to generate such a large key? I'm fine with never generating them, as long as people who have them can import them and use them. > Regarding the bug report: ...... > .... okay we talked about it. Right now working on Libgcrypt. Thanks, that's the right thing to do! --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From dkg at fifthhorseman.net Wed Dec 7 00:27:33 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 06 Dec 2016 18:27:33 -0500 Subject: Handling a TOFU conflict In-Reply-To: <87wpfd175i.wl-neal@walfield.org> References: <87wpfd175i.wl-neal@walfield.org> Message-ID: <87lgvsk596.fsf@alice.fifthhorseman.net> On Tue 2016-12-06 09:09:13 -0500, Neal H. Walfield wrote: > Currently, when a TOFU conflict is encountered, the --status-fd > transcript looks like the following: > > $ gpg --command-fd 0 --status-fd 1 --trust-model tofu -r 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 -e > [GNUPG:] KEY_CONSIDERED 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 0 > [GNUPG:] KEY_CONSIDERED 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 0 > [GNUPG:] KEY_CONSIDERED 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 0 > [GNUPG:] KEY_CONSIDERED 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 0 > The email address "joke.factory at example.com" is associated with 3 keys! > Please indicate whether this email address should be associated with key > 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 or whether you think someone is > impersonating "joke.factory at example.com". > > This key's user IDs: > Joke Factory (policy: auto) > > Statistics for keys with the email address "joke.factory at example.com": > 1604 5E5F D857 2D7C 44AA 6DCE CC8D 32F3 1C00 5AF3 (this key): > Encrypted 0 messages. > Verified 0 messages. > 6F34 3BAD CC2A BE3C 5A2E 295B 2A16 A78F B662 E42F (policy: auto): > Encrypted 0 messages. > Verified 0 messages. > 97D6 8CB9 B03F 8137 EB88 4940 EE7C 7DA4 BE04 EB2B (policy: auto): > Encrypted 0 messages. > Verified 0 messages. > > Normally, an email address is associated with a single key. However, > people sometimes generate a new key if their key is too old or they think > it might be compromised. Alternatively, a new key may indicate a > man-in-the-middle attack! Before accepting this association, you should > talk to or call the person to make sure this new key is legitimate. > > [GNUPG:] GET_LINE tofu.conflict > > The MUA has to manually figure out what the conflicting keys are and > gather the statistics. In addition to the extra work for the > programmer and the minor computational overhead, this introduces a > small race. Further, it means that the MUA has to know that conflicts > are based on the email address (and not whole user id) as well as any > normalization rules that we use. Currently, we only lowercase the > email address, but one could imagine adding support for google's > aliases ('.'s don't mean anything) and puny code. > > > I think that we should change this to print the stats for each > conflicting binding before the tofu.conflict prompt is emitted. For > this, I propose either using pairs of TOFU_USER/TOFU_STATS lines or > just using the TOFU_STATS line, but extending it to include the > required context (i.e., the fingerprint and the mbox). Thus, the > --status-fd output could look like this: > > [GNUPG:] KEY_CONSIDERED 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 0 > [GNUPG:] TOFU_USER > [GNUPG:] TOFU_STATS ... > [GNUPG:] TOFU_USER > [GNUPG:] TOFU_STATS ... > [GNUPG:] GET_LINE tofu.conflict given the output you show above, it sounds like GnuPG already has the information available in order to write the non-status blurb. I completely agree that we should supply this info on the --status-fd so that MUAs that want to integrate with this have access to the information. I lean in the direction of a single TOFU_STATS line per considered key, rather than a pair of TOFU_USER+TOFU_STATS -- it's just easier for clients to parse a single line at a time. Also, i note that in your example there were three keys, but above you only show two. i'd hope that that we'd emit TOFU_STATS for the currently-considered key as well as for the other known keys that match. Thanks for thinking this through, Neal! --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From wk at gnupg.org Wed Dec 7 08:32:53 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 07 Dec 2016 08:32:53 +0100 Subject: [PATCH] agent: Respect --enable-large-secmem In-Reply-To: <87inqwlqk5.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 06 Dec 2016 16:02:02 -0500") References: <20161206160956.576-1-dkg@fifthhorseman.net> <871sxkq1k3.fsf@wheatstone.g10code.de> <87inqwlqk5.fsf@alice.fifthhorseman.net> Message-ID: <87oa0onqhm.fsf@wheatstone.g10code.de> On Tue, 6 Dec 2016 22:02, dkg at fifthhorseman.net said: > patch is applied and we configure with --enable-large-secmem. Are you > suggesting that we'd need a runtime argument to gpg-agent in order to be > able to generate such a large key? I'm fine with never generating them, > as long as people who have them can import them and use them. We have the --enable-large-rsa option in gpg and thus it would be logically to do have same in gpg-agent: --enable-large-rsa --disable-large-rsa With --gen-key and --batch, enable the creation of RSA secret keys as large as 8192 bit. Note: 8192 bit is more than is generally recommended. These large keys don't significantly improve security, but they are more expensive to use, and their signatures and certifications are larger. This option is only available if the binary was build with large-secmem support. By screening I meant to limit crypto operations to keys of a certain size to avoid that one connection can stall processing of other connections by using huge keys. The hard limit imposed by Libgcrypt are 16 kbits but artificially limiting computing to 8k _may_ be useful. Unfortunately there are a few even larger keys, which have been the reason for introducing the above mentioned option. Thus we would need an option to override such a limit. Probably best not to do anything in gpg-agent. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From neal at walfield.org Wed Dec 7 10:26:00 2016 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 07 Dec 2016 10:26:00 +0100 Subject: Handling a TOFU conflict In-Reply-To: <87wpfd175i.wl-neal@walfield.org> References: <87wpfd175i.wl-neal@walfield.org> Message-ID: <87shq0145z.wl-neal@walfield.org> Attached is a minimal patch that implements the TOFU_USER/TOFU_STATS functionality. It is preceded by example output. Personally, I'd prefer to combine the TOFU_USER and TOFU_STATS lines to make it more context free. But, given how much output is currently not context free, it's not a priority. One could also imagine emitting another status line at the beginning indicating that a conflict has been detected. This would probably make it easier for parsers, since they know why the TOFU_USER and TOFU_STATS status lines are being emitted. Should I do any of these things? Should I commit as it? Or, should I leave it the way it currently is? Thanks! :) Neal $ gpg --command-fd 0 --status-fd 1 --trust-model tofu -r 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 -e gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! [GNUPG:] KEY_CONSIDERED 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 0 [GNUPG:] KEY_CONSIDERED 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 0 [GNUPG:] KEY_CONSIDERED 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 0 [GNUPG:] KEY_CONSIDERED 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 0 [GNUPG:] TOFU_USER 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 joke.factory at example.com [GNUPG:] TOFU_STATS 0 0 0 ask 0 0 0 0 1 [GNUPG:] TOFU_USER 6F343BADCC2ABE3C5A2E295B2A16A78FB662E42F joke.factory at example.com [GNUPG:] TOFU_STATS 0 0 0 ask 0 0 0 0 1 [GNUPG:] TOFU_USER 97D68CB9B03F8137EB884940EE7C7DA4BE04EB2B joke.factory at example.com [GNUPG:] TOFU_STATS 0 0 0 ask 0 0 0 0 1 The email address "joke.factory at example.com" is associated with 3 keys! Please indicate whether this email address should be associated with key 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 or whether you think someone is impersonating "joke.factory at example.com". This key's user IDs: Joke Factory (policy: auto) Statistics for keys with the email address "joke.factory at example.com": 1604 5E5F D857 2D7C 44AA 6DCE CC8D 32F3 1C00 5AF3 (this key): Encrypted 0 messages. Verified 0 messages. 6F34 3BAD CC2A BE3C 5A2E 295B 2A16 A78F B662 E42F (policy: auto): Encrypted 0 messages. Verified 0 messages. 97D6 8CB9 B03F 8137 EB88 4940 EE7C 7DA4 BE04 EB2B (policy: auto): Encrypted 0 messages. Verified 0 messages. Normally, an email address is associated with a single key. However, people sometimes generate a new key if their key is too old or they think it might be compromised. Alternatively, a new key may indicate a man-in-the-middle attack! Before accepting this association, you should talk to or call the person to make sure this new key is legitimate. [GNUPG:] GET_LINE tofu.conflict From 89b147be248c989eee1d7996a2c55ae4f0bd6ac9 Mon Sep 17 00:00:00 2001 From: "Neal H. Walfield" Date: Wed, 7 Dec 2016 10:11:46 +0100 Subject: [PATCH] g10: On a TOFU conflict, write the conflicting keys to the status fd * g10/tofu.c (ask_about_binding): Emit all of the conflicting keys and their statistics on the status fd. (show_statistics): Have the caller pass the policy as returned by get_policy. Add argument only_status_fd and don't emit any output on stdout if it is set. Update callers. -- Signed-off-by: Neal H. Walfield --- g10/tofu.c | 44 +++++++++++++++++++++++++++++--------------- 1 file changed, 29 insertions(+), 15 deletions(-) diff --git a/g10/tofu.c b/g10/tofu.c index 5b3e84c..5906bfa 100644 --- a/g10/tofu.c +++ b/g10/tofu.c @@ -112,8 +112,10 @@ struct tofu_dbs_s /* Local prototypes. */ static gpg_error_t end_transaction (ctrl_t ctrl, int only_batch); static char *email_from_user_id (const char *user_id); - - +static int show_statistics (tofu_dbs_t dbs, + const char *fingerprint, const char *email, + enum tofu_policy policy, + estream_t outfp, int only_status_fd, time_t now); const char * tofu_policy_str (enum tofu_policy policy) @@ -1797,6 +1799,9 @@ ask_about_binding (ctrl_t ctrl, xfree (key_pp); seen_in_past = 0; + + show_statistics (dbs, stats_iter->fingerprint, email, + TOFU_POLICY_ASK, NULL, 1, now); } if (labs(stats_iter->time_ago) == 1) @@ -2913,17 +2918,18 @@ write_stats_status (estream_t fp, /* Note: If OUTFP is not NULL, this function merely prints a "tfs" record * to OUTFP. * - * Returns whether the caller should call show_warning after iterating - * over all user ids. + * POLICY is the key's policy (as returned by get_policy). + * + * Returns 0 if if ONLY_STATUS_FD is set. Otherwise, returns whether + * the caller should call show_warning after iterating over all user + * ids. */ static int -show_statistics (tofu_dbs_t dbs, PKT_public_key *pk, const char *fingerprint, - const char *email, const char *user_id, - estream_t outfp, time_t now) +show_statistics (tofu_dbs_t dbs, + const char *fingerprint, const char *email, + enum tofu_policy policy, + estream_t outfp, int only_status_fd, time_t now) { - enum tofu_policy policy = - get_policy (dbs, pk, fingerprint, user_id, email, NULL, now); - char *fingerprint_pp; int rc; strlist_t strlist = NULL; @@ -2938,7 +2944,8 @@ show_statistics (tofu_dbs_t dbs, PKT_public_key *pk, const char *fingerprint, int show_warning = 0; - (void) user_id; + if (only_status_fd && ! is_status_enabled ()) + return 0; fingerprint_pp = format_hexfingerprint (fingerprint, NULL, 0); @@ -3020,7 +3027,7 @@ show_statistics (tofu_dbs_t dbs, PKT_public_key *pk, const char *fingerprint, encryption_first_done, encryption_most_recent); - if (!outfp) + if (!outfp && !only_status_fd) { estream_t fp; char *msg; @@ -3548,6 +3555,7 @@ tofu_write_tfs_record (ctrl_t ctrl, estream_t fp, tofu_dbs_t dbs; char *fingerprint; char *email; + enum tofu_policy policy; if (!*user_id) return 0; /* No TOFU stats possible for an empty ID. */ @@ -3562,8 +3570,9 @@ tofu_write_tfs_record (ctrl_t ctrl, estream_t fp, fingerprint = hexfingerprint (pk, NULL, 0); email = email_from_user_id (user_id); + policy = get_policy (dbs, pk, fingerprint, user_id, email, NULL, now); - show_statistics (dbs, pk, fingerprint, email, user_id, fp, now); + show_statistics (dbs, fingerprint, email, policy, fp, 0, now); xfree (email); xfree (fingerprint); @@ -3638,8 +3647,13 @@ tofu_get_validity (ctrl_t ctrl, PKT_public_key *pk, strlist_t user_id_list, bindings_valid ++; if (may_ask && tl != TRUST_ULTIMATE && tl != TRUST_EXPIRED) - need_warning |= - show_statistics (dbs, pk, fingerprint, email, user_id->d, NULL, now); + { + enum tofu_policy policy = + get_policy (dbs, pk, fingerprint, user_id->d, email, NULL, now); + + need_warning |= + show_statistics (dbs, fingerprint, email, policy, NULL, 0, now); + } if (tl == TRUST_NEVER) trust_level = TRUST_NEVER; -- 2.1.4 From wk at gnupg.org Wed Dec 7 11:03:21 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 07 Dec 2016 11:03:21 +0100 Subject: Handling a TOFU conflict In-Reply-To: <87wpfd175i.wl-neal@walfield.org> (Neal H. Walfield's message of "Tue, 06 Dec 2016 15:09:13 +0100") References: <87wpfd175i.wl-neal@walfield.org> Message-ID: <87fum0njiu.fsf@wheatstone.g10code.de> On Tue, 6 Dec 2016 15:09, neal at walfield.org said: > $ gpg --command-fd 0 --status-fd 1 --trust-model tofu -r 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 -e Why do you want to use the --command-fd? This is uncommon for encryption or signing operations and not supported by gpgme. The way this is handled (expired, revoked, or ambiguous addresses) is to return an error for the key and let the caller decide what to do. This needs to be done anyway for other error cases. I can't see why a TOFU conflict is different and needs a different way to handle it. When you run the above command with --batch (as it is common and suggested), you see the TOFU status lines as well as an INV_RECP status. You gave the key by fingerprint which means you already looked it up the mail address. If this has been done --always-trust is used to force the use of that key. Tofu should only kick in for keys given by mail address, because that is what TOFU is about. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From aheinecke at intevation.de Wed Dec 7 11:27:09 2016 From: aheinecke at intevation.de (Andre Heinecke) Date: Wed, 07 Dec 2016 11:27:09 +0100 Subject: Handling a TOFU conflict In-Reply-To: <87wpfd175i.wl-neal@walfield.org> References: <87wpfd175i.wl-neal@walfield.org> Message-ID: <2584939.JPQZmCuCIo@esus> Hi, On Tuesday 06 December 2016 15:09:13 Neal H. Walfield wrote: > Currently, when a TOFU conflict is encountered, the --status-fd > transcript looks like the following: ... > The MUA has to manually figure out what the conflicting keys are and > gather the statistics. In addition to the extra work for the > programmer and the minor computational overhead, this introduces a > small race. Further, it means that the MUA has to know that conflicts > are based on the email address (and not whole user id) as well as any > normalization rules that we use. Currently, we only lowercase the > email address, but one could imagine adding support for google's > aliases ('.'s don't mean anything) and puny code. I don't think this is a problem, gpgme exposes the mail normalsation as API and I don't see a security problem with a race for the additional keylisting. Do you have concerns there? A mua needs the E-Mail normalisation anyway to provide the argument for --sender. > I think that we should change this to print the stats for each > conflicting binding before the tofu.conflict prompt is emitted. For > this, I propose either using pairs of TOFU_USER/TOFU_STATS lines or > just using the TOFU_STATS line, but extending it to include the > required context (i.e., the fingerprint and the mbox). Thus, the > --status-fd output could look like this: > > [GNUPG:] KEY_CONSIDERED 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 0 > [GNUPG:] TOFU_USER > [GNUPG:] TOFU_STATS ... > [GNUPG:] TOFU_USER > [GNUPG:] TOFU_STATS ... > [GNUPG:] GET_LINE tofu.conflict > > I'm confident that this would at least simplify the TOFU integration > in EPG. Other thoughts? I think this complicates things and creates work as we have to add this to GpgME, too and is not neccessary. Altough I have no strong objection if you impement this. It would be additional information and it may help others. I currently don't think that I need information about an old key at all in case of a conflict in the user interface. But that's a different discussion. :-) 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: 659 bytes Desc: This is a digitally signed message part. URL: From neal at walfield.org Wed Dec 7 11:40:10 2016 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 07 Dec 2016 11:40:10 +0100 Subject: Handling a TOFU conflict In-Reply-To: <87fum0njiu.fsf@wheatstone.g10code.de> References: <87wpfd175i.wl-neal@walfield.org> <87fum0njiu.fsf@wheatstone.g10code.de> Message-ID: <87oa0o10qd.wl-neal@walfield.org> On Wed, 07 Dec 2016 11:03:21 +0100, Werner Koch wrote: > On Tue, 6 Dec 2016 15:09, neal at walfield.org said: > > > $ gpg --command-fd 0 --status-fd 1 --trust-model tofu -r 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 -e > > Why do you want to use the --command-fd? This is uncommon for > encryption or signing operations and not supported by gpgme. The way > this is handled (expired, revoked, or ambiguous addresses) is to return > an error for the key and let the caller decide what to do. This needs > to be done anyway for other error cases. I can't see why a TOFU > conflict is different and needs a different way to handle it. Sorry, the --command-fd option is just a distraction. But, it is how epg currently works, AFAICT. > When you run the above command with --batch (as it is common and > suggested), you see the TOFU status lines as well as an INV_RECP status. You only see the TOFU_STATS lines for the keys under consideration. It would be nice to have a way to immediately get the statistics for the conflicting keys. That is what this patch is about. Currently, you still need to get all of the conflicting keys, which, again, in addition to the extra work for the programmer and the minor computational overhead, this introduces a small race. Further, it means that the MUA has to know that conflicts are based on the email address (and not whole user id) as well as any normalization rules that we use. Currently, we only lowercase the email address, but one could imagine adding support for google's aliases ('.'s don't mean anything) and puny code. > You gave the key by fingerprint which means you already looked it up the > mail address. If this has been done --always-trust is used to force the > use of that key. I'm sorry, I don't understand why specifying a key by fingerprint should cause that key to be fully trusted. > Tofu should only kick in for keys given by mail > address, because that is what TOFU is about. Can you please elaborate. I have a rather different understanding of what TOFU is about. (If you are interested: it's about monitoring bindings for conflicts.) Thanks, :) Neal From neal at walfield.org Wed Dec 7 11:54:23 2016 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 07 Dec 2016 11:54:23 +0100 Subject: [ame2016] INBOME comments In-Reply-To: <20161206232932.GM3538@merlinux.eu> References: <87y3zt17ul.wl-neal@walfield.org> <20161206232932.GM3538@merlinux.eu> Message-ID: <87mvg8102o.wl-neal@walfield.org> Hi Holger, On Wed, 07 Dec 2016 00:29:32 +0100, holger krekel wrote: > On Tue, Dec 06, 2016 at 14:54 +0100, Neal H. Walfield wrote: > > - When I described INBOME to Werner, he noted that adoption by mail > > providers will probably be harder than convincing them to adopt > > WKS. I was initially confused by his statement, because INBOME > > only requires that the MUAs be modified. He then pointed out that > > most users use webmail. I'd be interested to hear about how you > > plan to get INBOME widely adopted. > > Actually, could you or someone else elaborate a bit on how WKS would be easier than INBOME for webmail MUAs? AIUI, today, you can encrypt mails using most webmailers using something like Mailvelope. But, mailvelope doesn't see all messages, only those that the user explicitly opens with Mailvelope. Thus, without additional help it's hard for something like Mailvelope to use the INBOME annotations. With WKS, the webmailers have to provide a new service, but it is largely self-contained. :) Neal From neal at walfield.org Wed Dec 7 12:02:12 2016 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 07 Dec 2016 12:02:12 +0100 Subject: INBOME comments In-Reply-To: <87inqxm4ll.fsf@alice.fifthhorseman.net> References: <87y3zt17ul.wl-neal@walfield.org> <87inqxm4ll.fsf@alice.fifthhorseman.net> Message-ID: <87lgvs0zpn.wl-neal@walfield.org> On Tue, 06 Dec 2016 16:58:46 +0100, Daniel Kahn Gillmor wrote: > On Tue 2016-12-06 08:54:10 -0500, Neal H. Walfield wrote: > > - Is there a reason to not build on the "The OpenPGP mail and news > > header field" specification and instead invent a new header [2]? > > (This specification doesn't support transferring the actual keys in > > the headers. Instead, a key identifier is specified and a URI > > pointing to the key can be provided.) > > It's conceivable that INBOME could work with S/MIME & CMS as well as > OpenPGP. It's not clear that it must be OpenPGP-specific. > > > - I'm not sure that transferring keys in mail headers is a great > > idea. For instance, gpg's minimal version of my key is 4.8KB. > > This is the binary version, i.e., it hasn't been ASCII encoded. > > > > $ gpg --export-options export-minimal --export 0xAACB3243630052D9 | wc -c > > 4811 > > > > Do you not view this as a problem? > > that's not sufficiently minimal ;) the minimal openpgp cert for a given > e-mail address would be: > > A * primary key > B * user id > C * self-sig > D * encryption-capable subkey > E * self-sig (no cross-cert needed) > > so it should be about: > > 2*(sizeof key) + 2*(sizeof signature) + (sizeof uid). > > for 3072-bit RSA, i agree that's large, but it's not even 2KiB. > > for 25519 keys, that's less than 200B For RSA keys, that's still a fair amount (i.e., too much, IMO). For ECC keys, it is reasonable. > > > - In the group communication example, Alice sends a message to Bob > > and Carol at which point Bob and Carol learn about Alice's INBOME > > preferences. Why doesn't Alice also include Bob and Carol's latest > > IMBOME header so that Bob and Carol can immediately learn about > > Carol and Bob's keys, respectively, without additional > > interactions? > > While i think something like that could be useful, we need to be > extremely cautious about the consequences of allowing "drive-by" INBOME > data. The analogy in the DNS world is "cache poisoning". If i can set, > clear, or reset your INBOME data for someone else even if i don't have > access to the communitions channel, what are the consequences for your > future communications? Well, this is opportunistic encryption so what are the consequences? I think the worst case, is that Bob sends an encrypted message to Carol using the wrong key. In that case, Carol replies that she could not decrypt the message at which point Bob has the right INBOME information and can securely resend. I think that this situation can also arise even without this type of gossip: someone just needs to send a forged mail. In practice, I would track the origin of the header and prefer the header from the actual recipient. :) Neal From neal at walfield.org Wed Dec 7 12:12:59 2016 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 07 Dec 2016 12:12:59 +0100 Subject: [ame2016] INBOME comments In-Reply-To: <20161206152841.bsrioeei675sog6j@calamity> References: <87y3zt17ul.wl-neal@walfield.org> <20161206152841.bsrioeei675sog6j@calamity> Message-ID: <87k2bc0z7o.wl-neal@walfield.org> Hi Vincent, On Tue, 06 Dec 2016 16:28:41 +0100, Vincent Breitmoser wrote: > > - Is there a reason to not build on the "The OpenPGP mail and news > > header field" specification and instead invent a new header [2]? > > (This specification doesn't support transferring the actual keys in > > the headers. Instead, a key identifier is specified and a URI > > pointing to the key can be provided.) > > A quick grep on my Maildir for OpenPGP header reveals a host of > different formats used in the OpenPGP header, including all combinations > of short/long key ids, fingerprints in different formats, and urls to > keyservers, keybase profiles, and other urls with keyblocks or related > data. > > Current versions of Enigmail offer setting the content of this header > field as a free text setting (although this changed(?) recently[1]), > which generates a lot of noise there. I imagine some people have > customized scripts for interpreting the header on the receiving side, > too. > > It's worth considering, but I'm not seeing an upside other than the > simple name, compared to just using a new header where we don't clash > with existing expectations and practices. Just because you have a standard doesn't mean that everyone is going to follow it. So, in the end, INBOME code will still have to deal with non-conforming content. In that regard, creating a new, very similar standard only has the disadvantage of creating a new standard. > > - I'm not sure that transferring keys in mail headers is a great > > idea. For instance, gpg's minimal version of my key is 4.8KB. > > This is the binary version, i.e., it hasn't been ASCII encoded. > > > > Do you not view this as a problem? > > This is indeed a thing we have to talk about more, and mention in our > drafts at least! > > One argument is that a few kb of data (10kb at worst) really are not > much of a technical anymore, but rather fall in the area of principle by > modern standards. > > As a shorter term mitigation, keys can be minimized further: We can drop > all subkeys besides the ones we actually want to use (in your case that > drops the auth key at least), we can also drop all user ids beside the > one we use in the email. Your key also has the peculiarity that it has a > signing subkey where the primary key can also sign (and is probably > picked to sign messages, unless the subkey is specifically selected?), > which means we could also drop that one. > > The mid term solution certainly is to switch to ecc. Sure. But in the end, you really want to get the whole key from the key servers anyway in which case the fingerprint is enough. First, having all of the data, you can potentially determine that a key is trusted. Second, you need to periodically refresh the key to discover any revocation certificate (or is INBOME propagating them?). > > - In the group communication example, Alice sends a message to Bob > > and Carol at which point Bob and Carol learn about Alice's INBOME > > preferences. Why doesn't Alice also include Bob and Carol's latest > > IMBOME header so that Bob and Carol can immediately learn about > > Carol and Bob's keys, respectively, without additional > > interactions? > > This type of gossipping is problematic because it trivially allows > injecting keys for other people, without even spoofing the message > sender address. Holger brought this up before and probably spent more > time thinking about this than me though :) I tried to address this in my reply to dkg (Message-ID: <87lgvs0zpn.wl-neal at walfield.org>). Thanks! :) Neal From justus at g10code.com Wed Dec 7 13:23:42 2016 From: justus at g10code.com (Justus Winter) Date: Wed, 07 Dec 2016 13:23:42 +0100 Subject: RFC on issue 2701, default expiration time for new keys Message-ID: <87pol49bch.fsf@europa.jade-hamburg.de> Hello, inspired by the talk on OpenKeychain UX decisions at the OpenPGP conference, I decided that it is a bad idea to let users create keys that don't expire (unless they want to hang themself with --expert). This now begs the question what a good default expiration time is. Thoughts? Relevant bug: https://bugs.gnupg.org/gnupg/issue2701 Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From kristian.fiskerstrand at sumptuouscapital.com Wed Dec 7 14:16:13 2016 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 07 Dec 2016 14:16:13 +0100 Subject: RFC on issue 2701, default expiration time for new keys In-Reply-To: <87pol49bch.fsf@europa.jade-hamburg.de> References: <87pol49bch.fsf@europa.jade-hamburg.de> Message-ID: <0B6E674F-A9D4-4409-8739-A3E904AF5987@sumptuouscapital.com> On December 7, 2016 1:23:42 PM GMT+01:00, Justus Winter wrote: >Hello, > >inspired by the talk on OpenKeychain UX decisions at the OpenPGP >conference, I decided that it is a bad idea to let users create keys >that don't expire (unless they want to hang themself with --expert). > >This now begs the question what a good default expiration time is. >Thoughts? Not really any research behind it, but intuition says 2-3 years. Not so short users run into issues before familiar but short enough for it to be worth something. > >Relevant bug: https://bugs.gnupg.org/gnupg/issue2701 > > >Justus -- ---------------------------- 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 From neal at walfield.org Wed Dec 7 15:06:11 2016 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 07 Dec 2016 15:06:11 +0100 Subject: Handling a TOFU conflict In-Reply-To: <2584939.JPQZmCuCIo@esus> References: <87wpfd175i.wl-neal@walfield.org> <2584939.JPQZmCuCIo@esus> Message-ID: <87h96f25rg.wl-neal@walfield.org> On Wed, 07 Dec 2016 11:27:09 +0100, Andre Heinecke wrote: > On Tuesday 06 December 2016 15:09:13 Neal H. Walfield wrote: > > Currently, when a TOFU conflict is encountered, the --status-fd > > transcript looks like the following: > > ... > > > The MUA has to manually figure out what the conflicting keys are and > > gather the statistics. In addition to the extra work for the > > programmer and the minor computational overhead, this introduces a > > small race. Further, it means that the MUA has to know that conflicts > > are based on the email address (and not whole user id) as well as any > > normalization rules that we use. Currently, we only lowercase the > > email address, but one could imagine adding support for google's > > aliases ('.'s don't mean anything) and puny code. > > I don't think this is a problem, gpgme exposes the mail normalsation as API > and I don't see a security problem with a race for the additional keylisting. > Do you have concerns there? > > A mua needs the E-Mail normalisation anyway to provide the argument for > --sender. The race is minor and it occurs to me that it is unavoidable anyways so this is a moot point. The more important issue has to do with listing conflicting keys. AFAICT, there is no reason for TOFU to necessarily normalize a user id in a way that the rest of gpg understands. Consider the case where we try to protect against homograph attacks by mapping characters with similar glyphs to the same symbol. In this case, a "Cyrillic a" and a "latin a" might be assigned the same symbol, and asking gpg to find the key corresponding to the normalized email address can result in no keys being found. I don't think it makes sense to expose TOFU normalization to the rest of gpg nevermind to external libraries or applications. This is particularly the case if we want to preserve the flexibility to identify new conflicts in the future, which would require changing the mapping function. As such, I think it is necessary for the TOFU code to emit the list of conflicting keys. If we are going to emit the conflicting keys, then we might as well also emit the stats, since the data is readily available. But, I don't care too much about this point. In short: I think it is essential that we emit the set of conflicting keys when a conflict is encountered. > > I think that we should change this to print the stats for each > > conflicting binding before the tofu.conflict prompt is emitted. For > > this, I propose either using pairs of TOFU_USER/TOFU_STATS lines or > > just using the TOFU_STATS line, but extending it to include the > > required context (i.e., the fingerprint and the mbox). Thus, the > > --status-fd output could look like this: > > > > [GNUPG:] KEY_CONSIDERED 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 0 > > [GNUPG:] TOFU_USER > > [GNUPG:] TOFU_STATS ... > > [GNUPG:] TOFU_USER > > [GNUPG:] TOFU_STATS ... > > [GNUPG:] GET_LINE tofu.conflict > > > > I'm confident that this would at least simplify the TOFU integration > > in EPG. Other thoughts? > > I think this complicates things and creates work as we have to add this to > GpgME, too and is not neccessary. > Altough I have no strong objection if you impement this. It would be > additional information and it may help others. > > I currently don't think that I need information about an old key at all in > case of a conflict in the user interface. But that's a different discussion. :-) I'm not sure what you mean by an old key. If there is a conflict, then you need to show all of the keys, right? From justus at g10code.com Wed Dec 7 15:32:52 2016 From: justus at g10code.com (Justus Winter) Date: Wed, 07 Dec 2016 15:32:52 +0100 Subject: [PATCH] python: Remove -builtin flag for SWIG bindings. In-Reply-To: <1480456267.7697.5.camel@cryptobitch.de> References: <1480456267.7697.5.camel@cryptobitch.de> Message-ID: <87mvg7ajxn.fsf@europa.jade-hamburg.de> Tobias Mueller writes: > * lang/python/setup.py.in: changed the swig call Please use whole sentences when describing a change. Start with a capital letter and end in a full stop. > -- > > The motivation is to be able to program __repr__ > functions more easily, i.e. in Python rather than C. Ok. > The -builtin flag prevents that, though, because Python code > will not be compiled. I don't quite understand. Python being compiled sounds at best ambiguous. Can you please provide an example of what this change will allow us to do? > The -py3 flag prevents the SWIG bindings to run under python2 > when generated without the -builtin flag, because the py3 flag > generates python3 code which is incompatible with python2. > > So we conditionally generate SWIG bindings with -py3. Indeed. That sounds like a good idea in general, independent from the '-builtin' issue. Would you be so kind to send a standalone patch? (This is in general a good idea, because it makes discussing changes, reasoning about changes, and partial application of patch series much easier, and git bisect more powerful.) > Signed-off-by: Tobias Mueller > --- > lang/python/setup.py.in | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/lang/python/setup.py.in b/lang/python/setup.py.in > index 9669c28..5b5d5be 100755 > --- a/lang/python/setup.py.in > +++ b/lang/python/setup.py.in > @@ -152,9 +152,10 @@ class BuildExtFirstHack(build): > self.run_command('build_ext') > build.run(self) > > +py3 = [] if sys.version_info.major < 3 else ['-py3'] > swige = Extension("gpg._gpgme", ["gpgme.i", "helpers.c"], > - swig_opts = ['-py3', '-builtin', '-threads', > - '-outdir', 'gpg'] + extra_swig_opts, > + swig_opts = ['-threads', > + '-outdir', 'gpg'] + py3 + extra_swig_opts, This basically reverts 856bcfe2934237011984fab0bc69800a7c25c34b. Silly past-me did not write his reasons for doing that change in the changelog, but I guess I merely wanted to reduce the amount of wrapping being done here. But I'm not opposed to reverting this if it has the benefits you mentioned. However, in that commit I also had to adapt another piece of code, and you didn't revert that chunk. Could you please investigate this? Thanks, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From aheinecke at intevation.de Wed Dec 7 17:30:54 2016 From: aheinecke at intevation.de (Andre Heinecke) Date: Wed, 07 Dec 2016 17:30:54 +0100 Subject: Handling a TOFU conflict In-Reply-To: <87h96f25rg.wl-neal@walfield.org> References: <87wpfd175i.wl-neal@walfield.org> <2584939.JPQZmCuCIo@esus> <87h96f25rg.wl-neal@walfield.org> Message-ID: <5621005.T22858bIDi@esus> Hi, On Wednesday 07 December 2016 15:06:11 Neal H. Walfield wrote: > On Wed, 07 Dec 2016 11:27:09 +0100, > Andre Heinecke wrote: > > On Tuesday 06 December 2016 15:09:13 Neal H. Walfield wrote: > > A mua needs the E-Mail normalisation anyway to provide the argument for > > --sender. > > The more important issue has to do with listing conflicting keys. > AFAICT, there is no reason for TOFU to necessarily normalize a user id > in a way that the rest of gpg understands. Consider the case where we > try to protect against homograph attacks by mapping characters with > similar glyphs to the same symbol. In this case, a "Cyrillic a" and a > "latin a" might be assigned the same symbol, and asking gpg to find > the key corresponding to the normalized email address can result in no > keys being found. > > I don't think it makes sense to expose TOFU normalization to the rest > of gpg nevermind to external libraries or applications. This is > particularly the case if we want to preserve the flexibility to > identify new conflicts in the future, which would require changing the > mapping function. As such, I think it is necessary for the TOFU code > to emit the list of conflicting keys. Ok. I could live witht his if we also add the user id that was used in a verification result which was the one used for verifcation, meaning the one that had the sign count increased and here we would need to add the unnormalized E-Mail. So that when I query the key (according to the fingerprint in the verification result) I can still figure out which UserID matches to the verification result so that I can take the TOFU Info for that UserID for validitiy display. This then should be done even when TOFU is ommited so that a MUA that provided --sender can show a mail only as green if the verification result also contains a User ID and we don't need duplicated normalisation in MUA's. --sender would then get the unnormalized Mail address from the MUA. > If we are going to emit the conflicting keys, then we might as well > also emit the stats, since the data is readily available. But, I > don't care too much about this point. I'm a bit concerned about the API simplicity of this. I think in GPGME this would look like: - Signature -- Key (only the fingerprint set) --- The Uid matched; unnormalized. -- List of Conflict-Fingerprints -- List of TofuInfo structures in sync with conflict fingerprints. Or which I would find worse a new struct with a fingerprint and tofuInfo. > In short: I think it is essential that we emit the set of conflicting > keys when a conflict is encountered. Yes if I don't have the normalisation anymore and so can't rely on the fact that I can find the Uid on the Key used for the verification I would indeed need the set of conflicting keys. > > I currently don't think that I need information about an old key at all in > > case of a conflict in the user interface. But that's a different > > discussion. :-) > I'm not sure what you mean by an old key. If there is a conflict, > then you need to show all of the keys, right? Right, thinking about this more I need it if a user does not resolve a conflict right away. And then tries to resolve while he is looking at a mail that was recieved before and is signed by the old key. Initially I thought I would resolve a conflict by a question like: ---- The key used to secure this message differs from the key usually used to secure messages from "foo at example.com" Please call "foo at example.com" or your IT Support to call what happend and check if the new key to secure your communication with him has the fingerprint: 1101 C077 198C 91E3 5BB9 CC78 856B 9E7E 60A1 542A Secure communication with "foo at example.com" is no longer possible until you have ensured that the new key is legitimate. [Use new key] [Keep using the old key] ---- With such a Dialog I would not need to have the conflicting keys, but as I probably need an "Ask me later" or allow the user to delay that decision I need indeed need the TOFU stats of the conflicting keys to show that dialog with the correct "old / new" keys later. 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: 659 bytes Desc: This is a digitally signed message part. URL: From ilf at zeromail.org Wed Dec 7 14:33:29 2016 From: ilf at zeromail.org (ilf) Date: Wed, 7 Dec 2016 14:33:29 +0100 Subject: RFC on issue 2701, default expiration time for new keys In-Reply-To: <87pol49bch.fsf@europa.jade-hamburg.de> References: <87pol49bch.fsf@europa.jade-hamburg.de> Message-ID: <20161207133329.GB32600@zeromail.org> Justus Winter: > I decided that it is a bad idea to let users create keys that don't > expire (unless they want to hang themself with --expert). Nice! > This now begs the question what a good default expiration time is. The "OpenPGP best practices" document currently sais "less than two years": https://riseup.net/en/security/message-security/openpgp/best-practices#use-an-expiration-date-less-than-two-years I would propose one or two years, but that's without hard data. I'm sure dkg will come up not only with the correct time, but also the right reasons. :) -- ilf ?ber 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes f?r Tastaturbenutzung -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From peter at digitalbrains.com Wed Dec 7 18:15:04 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 7 Dec 2016 18:15:04 +0100 Subject: RFC on issue 2701, default expiration time for new keys In-Reply-To: <20161207133329.GB32600@zeromail.org> References: <87pol49bch.fsf@europa.jade-hamburg.de> <20161207133329.GB32600@zeromail.org> Message-ID: <7a1e7b19-3808-a23e-8596-ec359a197d49@digitalbrains.com> On 07/12/16 14:33, ilf wrote: > The "OpenPGP best practices" document currently sais "less than two years": > https://riseup.net/en/security/message-security/openpgp/best-practices#use-an-expiration-date-less-than-two-years I'd not say "THE best practices document", but rather "A RANDOM best practices document someone wrote". There are lots of those, and can freely be ignored, IMNSHO. This document also recommends creating a 4K RSA key. And it complicates matters by strongly recommending installing parcimonie and Tor over just using --refresh-keys. That's one more hurdle for users to overcome in an already very complicated matter, and as such, IMNSHO, it is actually hindering user adoption. FWIW, I agree with Kristian, make it several years. Of course, you can also freely ignore me :-P. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From wk at gnupg.org Wed Dec 7 21:02:03 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 07 Dec 2016 21:02:03 +0100 Subject: Handling a TOFU conflict In-Reply-To: <87oa0o10qd.wl-neal@walfield.org> (Neal H. Walfield's message of "Wed, 07 Dec 2016 11:40:10 +0100") References: <87wpfd175i.wl-neal@walfield.org> <87fum0njiu.fsf@wheatstone.g10code.de> <87oa0o10qd.wl-neal@walfield.org> Message-ID: <87pol3mrt0.fsf@wheatstone.g10code.de> On Wed, 7 Dec 2016 11:40, neal at walfield.org said: > Sorry, the --command-fd option is just a distraction. But, it is how > epg currently works, AFAICT. Not really because it is the reason for the "GET_LINE tofu.conflict" which we can't use with any GPGME enabled MUA. Insofar epg diverts from GPGME's behaviour. > You only see the TOFU_STATS lines for the keys under consideration. > It would be nice to have a way to immediately get the statistics for > the conflicting keys. That is what this patch is about. You need to do a key listing anywa to get all details of the key. Thus gpg --with-colons --with-tofu-info MAILADDRESS while give you all information you need in a format you already need for displaying the details of the key. Adding a hint on which key conflicts might be useful but is not necessary. > means that the MUA has to know that conflicts are based on the email > address (and not whole user id) as well as any normalization rules For Tofu and all kind of "modern" key discovery, we soley use the mail address - that is the unique identifier and not some garbage in the user id. > that we use. Currently, we only lowercase the email address, but one > could imagine adding support for google's aliases ('.'s don't mean Definitely not. As soon as you start to special case things you are violating implicit assumptions and will for sure run into problems. Downcasing _ascii_ in contrast is different because case independent matching is a >30 old practice and not doing this would be a surprise. > I'm sorry, I don't understand why specifying a key by fingerprint > should cause that key to be fully trusted. Because the the user said: ?Please encrypt to exactly this key?. And that is what gpg does - questioning this request is wrong. This may only fail when the key may not be used for other reasons (revoked, expired, wrong capabilities). > Can you please elaborate. I have a rather different understanding of > what TOFU is about. (If you are interested: it's about monitoring > bindings for conflicts.) If a users demands _encryption_ to a certain well specified key (ie. by fingerprint of with -f) gpg shall just do that. The story is different when receiving mail: Verification shall of course detect conflicts. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From phoenyx33 at gmail.com Wed Dec 7 19:54:19 2016 From: phoenyx33 at gmail.com (Kenneth Benson) Date: Wed, 7 Dec 2016 13:54:19 -0500 Subject: Gnupg-devel Digest, Vol 159, Issue 9 In-Reply-To: References: Message-ID: <229aec13-73d8-c3ee-03c7-9ef03d59bc3a@gmail.com> On 12/7/2016 8:16 AM, gnupg-devel-request at gnupg.org wrote: Subject: Re: RFC on issue 2701, default expiration time for new keys From: Kristian Fiskerstrand Date: 12/7/2016 8:16 AM To: gnupg-devel at gnupg.org,Justus Winter On December 7, 2016 1:23:42 PM GMT+01:00, Justus Winter wrote: > Hello, > > inspired by the talk on OpenKeychain UX decisions at the OpenPGP > conference, I decided that it is a bad idea to let users create > keys that don't expire (unless they want to hang themself with > --expert). > > This now begs the question what a good default expiration time is. > Thoughts? Not really any research behind it, but intuition says 2-3 years. Not so short users run into issues before familiar but short enough for it to be worth something. > > Relevant bug: https://bugs.gnupg.org/gnupg/issue2701 > > > Justus -- ---------------------------- 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 > Just my 2-cents worth, but making it 3 years would tie in nicely with the normal expiration on email signing certificates. It would serve as a reminder to update both at the same time for those people who use both. But it is my 2-cents worth so feel free to ignore it, I won't worry it. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3946 bytes Desc: S/MIME Cryptographic Signature URL: From findaphone40 at gmail.com Wed Dec 7 21:21:25 2016 From: findaphone40 at gmail.com (brian huffman) Date: Wed, 7 Dec 2016 14:21:25 -0600 Subject: No subject Message-ID: What is -------------- next part -------------- An HTML attachment was scrubbed... URL: From neal at walfield.org Wed Dec 7 22:32:20 2016 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 07 Dec 2016 22:32:20 +0100 Subject: Handling a TOFU conflict In-Reply-To: <87pol3mrt0.fsf@wheatstone.g10code.de> References: <87wpfd175i.wl-neal@walfield.org> <87fum0njiu.fsf@wheatstone.g10code.de> <87oa0o10qd.wl-neal@walfield.org> <87pol3mrt0.fsf@wheatstone.g10code.de> Message-ID: <87y3zrzaqj.wl-neal@walfield.org> Hi, On Wed, 07 Dec 2016 21:02:03 +0100, Werner Koch wrote: > On Wed, 7 Dec 2016 11:40, neal at walfield.org said: > > > Sorry, the --command-fd option is just a distraction. But, it is how > > epg currently works, AFAICT. > > Not really because it is the reason for the "GET_LINE tofu.conflict" > which we can't use with any GPGME enabled MUA. Insofar epg diverts from > GPGME's behaviour. If I remove the --command-fd, then I still get the "GET_LINE tofu.conflict". Only if I add --batch is it disabled. It seems that epg is not using --batch and is using --command-fd. So, it does indeed diverge from gpgme. As far as I can tell, whether the client uses the "GET_LINE tofu.conflict" or not, whether to supply the list of conflicting keys is orthogonal. > > You only see the TOFU_STATS lines for the keys under consideration. > > It would be nice to have a way to immediately get the statistics for > > the conflicting keys. That is what this patch is about. > > You need to do a key listing anywa to get all details of the key. Thus > > gpg --with-colons --with-tofu-info MAILADDRESS > > while give you all information you need in a format you already need for > displaying the details of the key. > > Adding a hint on which key conflicts might be useful but is not necessary. Well, as far as I can tell, the TFS records and the TOFU_STATS contain the same information. Your approach also doesn't exclude keys that are known now to conflict with the selected key (e.g., if they are cross signed), and doesn't deal with the aliasing issue. > > means that the MUA has to know that conflicts are based on the email > > address (and not whole user id) as well as any normalization rules > > For Tofu and all kind of "modern" key discovery, we soley use the mail > address - that is the unique identifier and not some garbage in the user > id. > > > that we use. Currently, we only lowercase the email address, but one > > could imagine adding support for google's aliases ('.'s don't mean > > Definitely not. As soon as you start to special case things you are > violating implicit assumptions and will for sure run into problems. > Downcasing _ascii_ in contrast is different because case independent > matching is a >30 old practice and not doing this would be a surprise. I don't understand what your concerns are. This is about how TOFU internally detects conflicts; what implicit assumptions are there about how this is supposed to work? Why should the TOFU implementation not try to detect homograph attacks? > > I'm sorry, I don't understand why specifying a key by fingerprint > > should cause that key to be fully trusted. > > Because the the user said: ?Please encrypt to exactly this key?. And > that is what gpg does - questioning this request is wrong. This may > only fail when the key may not be used for other reasons (revoked, > expired, wrong capabilities). > > > Can you please elaborate. I have a rather different understanding of > > what TOFU is about. (If you are interested: it's about monitoring > > bindings for conflicts.) > > If a users demands _encryption_ to a certain well specified key (ie. by > fingerprint of with -f) gpg shall just do that. The story is different > when receiving mail: Verification shall of course detect conflicts. I just tried this using the WoT and gpg doesn't handle this case specially: $ gpg --trust-model pgp -e -r 0xEE7C7DA4BE04EB2B -a gpg: 0x73C970E81D63F2D5: There is no assurance this key belongs to the named user sub rsa2048/0x73C970E81D63F2D5 2016-12-05 Joke Factory Primary key fingerprint: 97D6 8CB9 B03F 8137 EB88 4940 EE7C 7DA4 BE04 EB2B Subkey fingerprint: C22F 9255 B78B 42DE 9BD0 8E37 73C9 70E8 1D63 F2D5 It is NOT certain that the key belongs to the person named in the user ID. If you *really* know what you are doing, you may answer the next question with yes. Use this key anyway? (y/N) So, it seems to me that what gpg currently does is wrong. Or, I'm misunderstanding something. Can you please elaborate? Thanks! :) Neal From dkg at fifthhorseman.net Wed Dec 7 23:35:45 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 07 Dec 2016 17:35:45 -0500 Subject: [ame2016] INBOME comments In-Reply-To: <20161207133738.fw6ytkuzaxhlr352@calamity> References: <87y3zt17ul.wl-neal@walfield.org> <87inqxm4ll.fsf@alice.fifthhorseman.net> <87lgvs0zpn.wl-neal@walfield.org> <20161207133738.fw6ytkuzaxhlr352@calamity> Message-ID: <877f7bjrjy.fsf@alice.fifthhorseman.net> On Wed 2016-12-07 08:37:39 -0500, Vincent Breitmoser wrote: >> For RSA keys, that's still a fair amount (i.e., too much, IMO). For >> ECC keys, it is reasonable. > > I found this iffy as well, until it occurred to me that 2kb attachments > sounded fine, and that headers aren't worse than attachments in terms of > mail size. Someone (dkg?) also mentioned that we certainly wouldn't be > the first to use large headers for things, I think their example was > Microsoft. I've got a local example of mail sent between two microsoft exchange servers. All the headers on a single message come in total to 24613 octets(!) The X-Microsoft-Exchange-Diagnostics and X-Microsoft-Exchange-Diagnostics-untrusted headers alone (there are 8 of each of them) account for 15548 octets. It looks to me like MS is breaking up the data they're hoping to transmit in these headers into lines that (if unwrapped) would still be within the SMTP 998 character limit and then just jamming as many of the headers as needed into the message's header block. They clearly don't care about optimizing for message size either -- here's an example header: X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1=3BCY1PR0101MB1433=3B7=3AZ?= =?us-ascii?Q?XImAua4ISksmNlG7KqZAmkCutHAJo1N1fbwUWvnjJ7KjW48Etwx6N5T/5Uio?= =?us-ascii?Q?CQiEHVP+5lnS+nsWWnojFKVE7Jtc9dsDK/iHeIigDQ+5hYp3SucDX5N0g2Y2?= =?us-ascii?Q?JTp3D6BMumpWytQmO5VRGKOhOCflWlph4aJlmGG6Gd3UYBKvvve+kdF0ZRnX?= =?us-ascii?Q?D9/kXlksE00+1XSGwG0Q5mjT5WEdklY13n+4fxyaAnIATrxw+XuzYUGTUAX2?= =?us-ascii?Q?LNiY1P3XULtF73KXVvwHcY4r+sdM2TTkOxoHvyQTxuTW81HIaf+nfeeHVtHJ?= =?us-ascii?Q?5SetkD912B7+iGsJHHbIDFh0AJNMeNej7RcqpZnVW93dHDUqtdMcj7rMn5SE?= =?us-ascii?Q?XoqnR6jltKvx029Qjh9Depad7FD3gGkTcdP7GX6jotbI/fQHC4yP/DqmGYcl?= =?us-ascii?Q?7nyrxDmw6YlgP+zPv4/od3tZohrvQ0IE6jQEKJxK485tjPD39gdTKt8jWu8i?= =?us-ascii?Q?YghxwyX2rY=3D?= it looks to me like they've taken an original binary thing, and then wrapped it in several layers of base64-encoding, quoted-printable encoding, and RFC 2047 encoding. I haven't bothered trying to decode it all the way down, so hopefully i'm not leaking anything dangerous by publishing it here ;) INBOME could hardly do worse than this kind of bloat. > More importantly though, we have to avoid unreadable messages. Nothing > makes a user drop a system faster than a reply "sorry couldn't read > that". Allowing gossip will increase the rate of that happening, since > the user's own MUA has less direct control over session negotiation. I tend to agree with this analysis. if we assume that INBOME can never protect the first message with a new communications partner, we gain quite a lot of usability and avoid a lot of potentially nasty pitfalls. This isn't ideal, but neither are the usability problems :) --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From wk at gnupg.org Thu Dec 8 00:06:26 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 08 Dec 2016 00:06:26 +0100 Subject: Handling a TOFU conflict In-Reply-To: <87y3zrzaqj.wl-neal@walfield.org> (Neal H. Walfield's message of "Wed, 07 Dec 2016 22:32:20 +0100") References: <87wpfd175i.wl-neal@walfield.org> <87fum0njiu.fsf@wheatstone.g10code.de> <87oa0o10qd.wl-neal@walfield.org> <87pol3mrt0.fsf@wheatstone.g10code.de> <87y3zrzaqj.wl-neal@walfield.org> Message-ID: <87a8c7mj9p.fsf@wheatstone.g10code.de> On Wed, 7 Dec 2016 22:32, neal at walfield.org said: > If I remove the --command-fd, then I still get the "GET_LINE > tofu.conflict". Only if I add --batch is it disabled. Right, either you use --command-fd or --batch. > As far as I can tell, whether the client uses the "GET_LINE > tofu.conflict" or not, whether to supply the list of conflicting keys > is orthogonal. Yep. But that is not how GPGME works, which is my primary concern. If EasyPG wants to handle this different, so be it - but changing our interface for this is a no-go. Adding additional status information in case of conflicting keys is acceptable as long as we have this info already available. In fact we already have all status lines for this available: TOFU_USER TOFU_STATS 0 .... TOFU_USER TOFU_STATS 0 .... indicates that the two keys FINGERPRINT1 and FINGERPRINT2 conflict on the address MBOX. (The 0 is "conflict" value of that SUMMARY byte). > Well, as far as I can tell, the TFS records and the TOFU_STATS contain > the same information. Your approach also doesn't exclude keys that > are known now to conflict with the selected key (e.g., if they are > cross signed), and doesn't deal with the aliasing issue. I have noticed that you put code in place to detect this and thus avoid a conflict. What do you mean by aliasing? > about how this is supposed to work? Why should the TOFU > implementation not try to detect homograph attacks? Because that is not the duty of gpg - this is an entire different layer. A MUA _might_ care about this but most likely it can only support the user in detecting this. This has nothing to do with with T0FU. Mixing up layers is the cause of a lot of evil. > I just tried this using the WoT and gpg doesn't handle this case > specially: Right, but with T0FU we are going to improve this. Before 2.1.16 we did not distinguish on how a key was specified. Now a key specified by mail address is treated different than a key specified by other means. This is to support our major goal of easily using the right key for a mail. With tofu and tofu+gpg we can and should drop the old checks and consider a key specified by fingerprint as DWIW-and-encrypt-to-this-key. For backward compatibility we can't do this for the pgp trust model. Thus it will eventually be possible for MUAs to avoid the use of GPGME_ENCRYPT_ALWAYS_TRUST (--always-trust in gpg) after the keys have been selected and passed by fingerprint to gpg. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From caro at nymph.paranoici.org Thu Dec 8 04:27:07 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Thu, 8 Dec 2016 03:27:07 +0000 (UTC) Subject: Key creation problem with 2.1.16 References: <20161129230429.B2488100B190@remailer.paranoici.org> <8760mxoghi.fsf@alice.fifthhorseman.net> <20161206124120.A4B1A1032319@remailer.paranoici.org> <87fum1m24x.fsf@alice.fifthhorseman.net> Message-ID: <20161208032707.B84771025BE0@remailer.paranoici.org> Hi Daniel, on Tue, 06 Dec 2016 11:51:58 -0500, you wrote: >Hi Carola-- > >On Tue 2016-12-06 07:41:20 -0500, Carola Grunwald wrote: >> I'v attached my application's complete log of the 'gpg.exe' program call >> including the command line string ('Application' + ' ' + 'ExeStr') with >> the 'Environment' parameter(s) set. > >ok, but it felt a bit like "burying the lede" in your attachments -- >it's a lot easier to understand what's going on if you describe it >clearly at the top of your message. > >that may be one of the reasons it took nearly a week for anyone to >respond to your message. > >now let's see if we can solve this! > >> It's not necessarily a problem with the GenKey code but may rather point >> to an unreliable gpg - agent IPC, which, as gpg starts a new agent >> instance minutes after processing begins to fail, would also explain the >> many orphaned gpg-agent.exe entries in my Task Manager's Processes list. > >it would be great to see some logs for the gpg-agent processes -- if >they're dying or becoming zombiefied, what were they doing when that >happened? I think that's what my 2nd example below is about. > >if the IPC is flakey, where is it failing? > >the main difference between your two logs seems to be that the agent in >the failed case is actually asking gpg for a passphrase, whereas it >*wasn't* asking gpg for a passphrase in the successful case. > >what would cause the agent to behave differently like that, given that >it had already done INQUIRE NEWPASSWD ? do you think the agent died and >a new agent started up, which hadn't cached the previous password? In fact I experience at least two different kinds of failure. Both are sporadic, not systematic errors. As I tried to provide a similar starting situation for each of these command calls I'm surprised at the varying outcome. There's the key creation failure, which I decided to show first, as I thought it might be easier to follow. Windows 7 in a VirtualBox VM. I start with an empty pub keyring and an empty 'private-keys-v1.d' folder, no pgp-agent.exe process running. With a fifty-fifty chance the --gen-key command unpredictably fails producing always exactly the same log which I added to my earlier mail, returning code 2. Key creation usually succeeds, as a valid .key and .rev file are written to disk, but the fingerprint ('[GNUPG:] KEY_CREATED ...') isn't returned. With this problem the agent stays alive. Follow-up commands are processed correctly. And there's a probably different problem with a likely broken IPC, where I get 259/$103 in return for the current and all following commands until another agent instance appears in the Task Manager after about 2 minutes. After a similar decryption command, which succeeds returning $0 I get: | ================================================================================ | Started : 2016-12-07 15:08:12.482 | Application: 'gpg\gpg.exe' | Command : '--pinentry-mode loopback --display-charset utf-8 --utf8-strings --no-mangle-dos-filenames --debug-level guru --debug-all --no-auto-key-locate --lock-once --no-encrypt-to --textmode --allow-weak-digest-algos --no-default-recipient --trust-model always --ignore-time-conflict --homedir "G:\mob\Mail\MyGnuPG\gpg" --no-default-keyring --keyring "G:\mob\Mail\MyGnuPG\key\nym.kbx" --keyring "G:\mob\Mail\MyGnuPG\key\srv.kbx" --no-emit-version --no-comments --status-fd 2' | Parameters : '--decrypt --command-fd 0 --try-all-secrets --passphrase "ppppppppppppppppppppppppppppppppppppppppppp" --output "G:\mob\Mail\MyGnuPG\gpg\tmp\txt_clr.675" "G:\mob\Mail\MyGnuPG\gpg\tmp\txt_enc.675"' | Environment: 'GNUPGHOME=G:\mob\Mail\MyGnuPG\gpg' | Input : 'y | ' | ExeStr (659 bytes): | '--pinentry-mode loopback --display-charset utf-8 --utf8-strings --no-mangle-dos-filenames --debug-level guru --debug-all --no-auto-key-locate --lock-once --no-encrypt-to --textmode --allow-weak-digest-algos --no-default-recipient --trust-model always --ignore-time-conflict --homedir "G:\mob\Mail\MyGnuPG\gpg" --no-default-keyring --keyring "G:\mob\Mail\MyGnuPG\key\nym.kbx" --keyring "G:\mob\Mail\MyGnuPG\key\srv.kbx" --no-emit-version --no-comments --status-fd 2 --decrypt --command-fd 0 --try-all-secrets --passphrase "ppppppppppppppppppppppppppppppppppppppppppp" --output "G:\mob\Mail\MyGnuPG\gpg\tmp\txt_clr.675" "G:\mob\Mail\MyGnuPG\gpg\tmp\txt_enc.675"' | Timeout : 30000 | ErrVal: 259 / $103 | Error: ------------------------------------------------------------------------- | gpg: Note: no default option file 'G:/mob/Mail/MyGnuPG/gpg/gpg.conf' | gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing cardio ipc clock lookup extprog | gpg: DBG: [not enabled in the source] start | gpg: DBG: fd_cache_open (G:\mob\Mail\MyGnuPG\gpg\tmp\txt_enc.675) not cached | gpg: DBG: iobuf-1.0: open 'G:\mob\Mail\MyGnuPG\gpg\tmp\txt_enc.675' desc=file_filter(fd) fd=144 | gpg: DBG: iobuf-1.0: underflow: buffer size: 8192; still buffered: 0 => space for 8192 bytes | gpg: DBG: iobuf-1.0: underflow: A->FILTER (8192 bytes) | gpg: DBG: iobuf-1.0: A->FILTER() returned rc=0 (ok), read 8192 bytes | gpg: DBG: armor-filter: control: 5 | gpg: DBG: iobuf-1.1: push 'armor_filter' | gpg: DBG: armor-filter: control: 5 | gpg: DBG: iobuf chain: 1.1 'armor_filter' filter_eof=0 start=0 len=0 | gpg: DBG: iobuf chain: 1.0 'file_filter(fd)' filter_eof=0 start=0 len=8192 | gpg: DBG: armor-filter: control: 1 | gpg: DBG: iobuf-1.1: underflow: buffer size: 8192; still buffered: 0 => space for 8192 bytes | gpg: DBG: iobuf-1.1: underflow: A->FILTER (8192 bytes) | gpg: DBG: armor-filter: control: 3 | gpg: DBG: iobuf-1.0: underflow: buffer size: 8192; still buffered: 0 => space for 8192 bytes | gpg: DBG: iobuf-1.0: underflow: A->FILTER (8192 bytes) | gpg: DBG: iobuf-1.0: A->FILTER() returned rc=0 (ok), read 1410 bytes | gpg: DBG: iobuf-1.1: A->FILTER() returned rc=0 (ok), read 6921 bytes | gpg: DBG: parse_packet(iob=1): type=1 length=524 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.16/g10/mainproc.c.1339) | [GNUPG:] ENC_TO 4444444444444444 1 0 | gpg: DBG: [not enabled in the source] get_session_key enter | gpg: DBG: [not enabled in the source] keydb_new | gpg: DBG: [not enabled in the source] keydb_search enter | gpg: DBG: keydb_search: 1 search descriptions: | gpg: DBG: keydb_search 0: FIRST | gpg: DBG: keydb_search: searching keybox (resource 0 of 2) | gpg: DBG: keydb_search: searched keybox (resource 0 of 2) => Success | gpg: DBG: [not enabled in the source] keydb_search leave (found) | gpg: DBG: [not enabled in the source] keydb_get_keybock enter | gpg: DBG: parse_packet(iob=2): type=6 length=418 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.16/g10/keydb.c.1177) | gpg: DBG: parse_packet(iob=2): type=13 length=40 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.16/g10/keydb.c.1177) | gpg: DBG: parse_packet(iob=2): type=2 length=90 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.16/g10/keydb.c.1177) | gpg: DBG: parse_packet(iob=2): type=14 length=525 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.16/g10/keydb.c.1177) | gpg: DBG: parse_packet(iob=2): type=2 length=73 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.16/g10/keydb.c.1177) | gpg: DBG: iobuf-2.0: underflow: buffer size: 1158; still buffered: 0 => space for 1158 bytes | gpg: DBG: iobuf-2.0: close '?' | | -------------------------------------------------------------------------------- | Finished : 2016-12-07 15:08:42.872 | ================================================================================ Here command processing sometimes stops instead of continuing with (the first two lines repeated) ... | gpg: DBG: iobuf-2.0: underflow: buffer size: 1158; still buffered: 0 => space for 1158 bytes | gpg: DBG: iobuf-2.0: close '?' | gpg: DBG: [not enabled in the source] keydb_get_keyblock leave | gpg: DBG: chan_0x0000009c <- OK Pleased to meet you | gpg: DBG: connection to agent established | gpg: DBG: chan_0x0000009c -> RESET | gpg: DBG: chan_0x0000009c <- OK | gpg: DBG: chan_0x0000009c -> GETINFO version | gpg: DBG: chan_0x0000009c <- D 2.1.16 | gpg: DBG: chan_0x0000009c <- OK | gpg: DBG: chan_0x0000009c -> OPTION allow-pinentry-notify | gpg: DBG: chan_0x0000009c <- OK | gpg: DBG: chan_0x0000009c -> OPTION agent-awareness=2.1.0 | gpg: DBG: chan_0x0000009c <- OK | gpg: DBG: chan_0x0000009c -> OPTION pinentry-mode=loopback | gpg: DBG: chan_0x0000009c <- OK | gpg: DBG: get_keygrip for public key | gpg: DBG: keygrip= 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 | gpg: DBG: get_keygrip for public key | gpg: DBG: keygrip= 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 | gpg: DBG: chan_0x0000009c -> HAVEKEY 1111111111111111111111111111111111111111 2222222222222222222222222222222222222222 | gpg: DBG: chan_0x0000009c <- OK | gpg: DBG: finish_lookup: checking key 33333333 (all)(req_usage=0) | gpg: DBG: using key 33333333 | [GNUPG:] KEY_CONSIDERED 3333333333333333333333333333333333333333 0 ... I'd like to provide further information. So is there a chance to get an even more verbose processing log. Please tell me what to do. Kind regards Caro From dkg at fifthhorseman.net Thu Dec 8 05:58:19 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 07 Dec 2016 23:58:19 -0500 Subject: [ame2016] INBOME comments In-Reply-To: <87mvg8102o.wl-neal@walfield.org> References: <87y3zt17ul.wl-neal@walfield.org> <20161206232932.GM3538@merlinux.eu> <87mvg8102o.wl-neal@walfield.org> Message-ID: <87mvg7hv9w.fsf@alice.fifthhorseman.net> On Wed 2016-12-07 05:54:23 -0500, Neal H. Walfield wrote: > AIUI, today, you can encrypt mails using most webmailers using > something like Mailvelope. Have you tried actually using this? What i hear from friends is that this is painful at best, and only becomes marginally less-painful when the webmail interface is specifically designed to interact well with mailvelope. Once you're in the process of doing that kind of interop work, the webmail interface can certainly define a way to pass the headers to the extension. Ideally, friendly webmail implementations would expose the entire mime structure, both on message composition and message retrieval. --dkg From dkg at fifthhorseman.net Thu Dec 8 05:30:20 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 07 Dec 2016 23:30:20 -0500 Subject: Key creation problem with 2.1.16 In-Reply-To: <20161208032707.B84771025BE0@remailer.paranoici.org> References: <20161129230429.B2488100B190@remailer.paranoici.org> <8760mxoghi.fsf@alice.fifthhorseman.net> <20161206124120.A4B1A1032319@remailer.paranoici.org> <87fum1m24x.fsf@alice.fifthhorseman.net> <20161208032707.B84771025BE0@remailer.paranoici.org> Message-ID: <87y3zrhwkj.fsf@alice.fifthhorseman.net> On Wed 2016-12-07 22:27:07 -0500, Carola Grunwald wrote: > In fact I experience at least two different kinds of failure. Both are > sporadic, not systematic errors. As I tried to provide a similar > starting situation for each of these command calls I'm surprised at the > varying outcome. Thanks for the details, Carola. This all sounds really frustrating, but i'm afraid i'm not in a good position to debug it, given that it seems to involve Windows. I'm not able to reproduce a 50/50 error on the linux systems i usually test and develop on :/ hopefully someone with more windows experience can help you out more. sorry to not be more help, --dkg From neal at walfield.org Thu Dec 8 10:19:29 2016 From: neal at walfield.org (Neal H. Walfield) Date: Thu, 08 Dec 2016 10:19:29 +0100 Subject: Handling a TOFU conflict In-Reply-To: <87a8c7mj9p.fsf@wheatstone.g10code.de> References: <87wpfd175i.wl-neal@walfield.org> <87fum0njiu.fsf@wheatstone.g10code.de> <87oa0o10qd.wl-neal@walfield.org> <87pol3mrt0.fsf@wheatstone.g10code.de> <87y3zrzaqj.wl-neal@walfield.org> <87a8c7mj9p.fsf@wheatstone.g10code.de> Message-ID: <87wpfazske.wl-neal@walfield.org> On Thu, 08 Dec 2016 00:06:26 +0100, Werner Koch wrote: > On Wed, 7 Dec 2016 22:32, neal at walfield.org said: > > As far as I can tell, whether the client uses the "GET_LINE > > tofu.conflict" or not, whether to supply the list of conflicting keys > > is orthogonal. > > Yep. But that is not how GPGME works, which is my primary concern. > If EasyPG wants to handle this different, so be it - but changing > our interface for this is a no-go. So, your primary convern is that EPG is using --command-fd while gpgme is using --batch. I think this is reasonable. Daiki will need to decide how he wants to handle this, but I suspect it is a fair amount of destabilizing work and won't make it into the next version of Debian. > Adding additional status information in > case of conflicting keys is acceptable as long as we have this info > already available. In fact we already have all status lines for this > available: > > TOFU_USER > TOFU_STATS 0 .... > TOFU_USER > TOFU_STATS 0 .... > > indicates that the two keys FINGERPRINT1 and FINGERPRINT2 conflict on > the address MBOX. (The 0 is "conflict" value of that SUMMARY byte). My experiments suggest that this information is not available (see Message-ID: <87wpfd175i.wl-neal at walfield.org>). My proposed patch in that mail changes this. > > Well, as far as I can tell, the TFS records and the TOFU_STATS contain > > the same information. Your approach also doesn't exclude keys that > > are known now to conflict with the selected key (e.g., if they are > > cross signed), and doesn't deal with the aliasing issue. > > I have noticed that you put code in place to detect this and thus avoid > a conflict. What do you mean by aliasing? Say we have a at example.org and a at example.org (the first a is a latin a and the second a is a Cyrillic a) and we internally normalize them to be the same thing (i.e., we decide that a at example.org and a at example.org conflict even though a memcmp says they are not identical), then doing gpg -k mbox won't find all of the conflicts, because gpg doesn't do the same transformation. > > about how this is supposed to work? Why should the TOFU > > implementation not try to detect homograph attacks? > > Because that is not the duty of gpg - this is an entire different layer. > A MUA _might_ care about this but most likely it can only support the > user in detecting this. This has nothing to do with with T0FU. > > Mixing up layers is the cause of a lot of evil. TOFU is about monitoring bindings to detect conflicts. If we don't try to actively detect conflicts, then we are left with --always-trust. Thus, this is precisely the type of thing that TOFU is trying to do. If you think TOFU is about something else, I'd like to hear your definition. > > I just tried this using the WoT and gpg doesn't handle this case > > specially: > > Right, but with T0FU we are going to improve this. Before 2.1.16 we did > not distinguish on how a key was specified. Now a key specified by mail > address is treated different than a key specified by other means. This > is to support our major goal of easily using the right key for a mail. > With tofu and tofu+gpg we can and should drop the old checks and > consider a key specified by fingerprint as DWIW-and-encrypt-to-this-key. > For backward compatibility we can't do this for the pgp trust model. > > Thus it will eventually be possible for MUAs to avoid the use of > GPGME_ENCRYPT_ALWAYS_TRUST (--always-trust in gpg) after the keys have > been selected and passed by fingerprint to gpg. I missed this discussion. Thanks for clarifying. I need to think about whether this is a good idea or not. :) Neal From neal at walfield.org Thu Dec 8 10:22:25 2016 From: neal at walfield.org (Neal H. Walfield) Date: Thu, 08 Dec 2016 10:22:25 +0100 Subject: [ame2016] INBOME comments In-Reply-To: <87mvg7hv9w.fsf@alice.fifthhorseman.net> References: <87y3zt17ul.wl-neal@walfield.org> <20161206232932.GM3538@merlinux.eu> <87mvg8102o.wl-neal@walfield.org> <87mvg7hv9w.fsf@alice.fifthhorseman.net> Message-ID: <87vauuzsfi.wl-neal@walfield.org> On Thu, 08 Dec 2016 05:58:19 +0100, Daniel Kahn Gillmor wrote: > On Wed 2016-12-07 05:54:23 -0500, Neal H. Walfield wrote: > > AIUI, today, you can encrypt mails using most webmailers using > > something like Mailvelope. > > Have you tried actually using this? What i hear from friends is that > this is painful at best, and only becomes marginally less-painful when > the webmail interface is specifically designed to interact well with > mailvelope. I can't imagine the pain, but FWIW this is what the BuzzFeed opsec team is training their reporters to use. (And, BuzzFeed has on boarded a lot of people.) > Once you're in the process of doing that kind of interop work, the > webmail interface can certainly define a way to pass the headers to the > extension. Ideally, friendly webmail implementations would expose the > entire mime structure, both on message composition and message > retrieval. Of course. But that is exactly the point: you're going to have to modify the webmailers a lot. From neal at walfield.org Thu Dec 8 10:25:13 2016 From: neal at walfield.org (Neal H. Walfield) Date: Thu, 08 Dec 2016 10:25:13 +0100 Subject: [ame2016] INBOME comments In-Reply-To: <877f7bjrjy.fsf@alice.fifthhorseman.net> References: <87y3zt17ul.wl-neal@walfield.org> <87inqxm4ll.fsf@alice.fifthhorseman.net> <87lgvs0zpn.wl-neal@walfield.org> <20161207133738.fw6ytkuzaxhlr352@calamity> <877f7bjrjy.fsf@alice.fifthhorseman.net> Message-ID: <87twaezsau.wl-neal@walfield.org> On Wed, 07 Dec 2016 23:35:45 +0100, Daniel Kahn Gillmor wrote: > > [1 ] > [1.1 ] > On Wed 2016-12-07 08:37:39 -0500, Vincent Breitmoser wrote: > >> For RSA keys, that's still a fair amount (i.e., too much, IMO). For > >> ECC keys, it is reasonable. > > > > I found this iffy as well, until it occurred to me that 2kb attachments > > sounded fine, and that headers aren't worse than attachments in terms of > > mail size. Someone (dkg?) also mentioned that we certainly wouldn't be > > the first to use large headers for things, I think their example was > > Microsoft. > > I've got a local example of mail sent between two microsoft exchange > servers. All the headers on a single message come in total to 24613 > octets(!) ... > INBOME could hardly do worse than this kind of bloat. Thanks for this data point. > > More importantly though, we have to avoid unreadable messages. Nothing > > makes a user drop a system faster than a reply "sorry couldn't read > > that". Allowing gossip will increase the rate of that happening, since > > the user's own MUA has less direct control over session negotiation. > > I tend to agree with this analysis. if we assume that INBOME can never > protect the first message with a new communications partner, we gain > quite a lot of usability and avoid a lot of potentially nasty pitfalls. > This isn't ideal, but neither are the usability problems :) I see the point, but I'm not entirely convinced. Unfortunately, I don't have any strong arguments. Anyway, it is rather minor in the scheme of things. Thanks! :) Neal From ueno at gnu.org Thu Dec 8 10:43:20 2016 From: ueno at gnu.org (Daiki Ueno) Date: Thu, 08 Dec 2016 10:43:20 +0100 Subject: Handling a TOFU conflict In-Reply-To: <87wpfazske.wl-neal@walfield.org> (Neal H. Walfield's message of "Thu, 08 Dec 2016 10:19:29 +0100") References: <87wpfd175i.wl-neal@walfield.org> <87fum0njiu.fsf@wheatstone.g10code.de> <87oa0o10qd.wl-neal@walfield.org> <87pol3mrt0.fsf@wheatstone.g10code.de> <87y3zrzaqj.wl-neal@walfield.org> <87a8c7mj9p.fsf@wheatstone.g10code.de> <87wpfazske.wl-neal@walfield.org> Message-ID: "Neal H. Walfield" writes: > On Thu, 08 Dec 2016 00:06:26 +0100, > Werner Koch wrote: >> On Wed, 7 Dec 2016 22:32, neal at walfield.org said: >> > As far as I can tell, whether the client uses the "GET_LINE >> > tofu.conflict" or not, whether to supply the list of conflicting keys >> > is orthogonal. >> >> Yep. But that is not how GPGME works, which is my primary concern. >> If EasyPG wants to handle this different, so be it - but changing >> our interface for this is a no-go. > > So, your primary convern is that EPG is using --command-fd while gpgme > is using --batch. I think this is reasonable. Daiki will need to > decide how he wants to handle this, but I suspect it is a fair amount > of destabilizing work and won't make it into the next version of > Debian. Sorry, I don't actually follow the discussion. Would you care to explain how gpgme is handling this? I have never wanted to diverge epg.el from gpgme, and tried not to implement any features not supported by gpgme. Of course, due to some limitations of Emacs IPC, we sometimes had to use a different mechanism to communicate with gpg. Regards, -- Daiki Ueno From wk at gnupg.org Thu Dec 8 11:23:30 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 08 Dec 2016 11:23:30 +0100 Subject: Handling a TOFU conflict In-Reply-To: <87wpfazske.wl-neal@walfield.org> (Neal H. Walfield's message of "Thu, 08 Dec 2016 10:19:29 +0100") References: <87wpfd175i.wl-neal@walfield.org> <87fum0njiu.fsf@wheatstone.g10code.de> <87oa0o10qd.wl-neal@walfield.org> <87pol3mrt0.fsf@wheatstone.g10code.de> <87y3zrzaqj.wl-neal@walfield.org> <87a8c7mj9p.fsf@wheatstone.g10code.de> <87wpfazske.wl-neal@walfield.org> Message-ID: <87k2balnx9.fsf@wheatstone.g10code.de> On Thu, 8 Dec 2016 10:19, neal at walfield.org said: > Say we have a at example.org and a at example.org (the first a is a latin a > and the second a is a Cyrillic a) and we internally normalize them to As I already mentioned, we won't normalize anything. > TOFU is about monitoring bindings to detect conflicts. If we don't TOFU at example.org and T0FU at example.org are different identities - even if you can't see that immediately. _We_ do not need to bother, a MUA _may_ give a hint that they look similar but that has nothing to do with TOFU. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From neal at walfield.org Thu Dec 8 11:34:26 2016 From: neal at walfield.org (Neal H. Walfield) Date: Thu, 08 Dec 2016 11:34:26 +0100 Subject: Handling a TOFU conflict In-Reply-To: <87k2balnx9.fsf@wheatstone.g10code.de> References: <87wpfd175i.wl-neal@walfield.org> <87fum0njiu.fsf@wheatstone.g10code.de> <87oa0o10qd.wl-neal@walfield.org> <87pol3mrt0.fsf@wheatstone.g10code.de> <87y3zrzaqj.wl-neal@walfield.org> <87a8c7mj9p.fsf@wheatstone.g10code.de> <87wpfazske.wl-neal@walfield.org> <87k2balnx9.fsf@wheatstone.g10code.de> Message-ID: <87shpyzp3h.wl-neal@walfield.org> On Thu, 08 Dec 2016 11:23:30 +0100, Werner Koch wrote: > On Thu, 8 Dec 2016 10:19, neal at walfield.org said: > > > Say we have a at example.org and a at example.org (the first a is a latin a > > and the second a is a Cyrillic a) and we internally normalize them to > > As I already mentioned, we won't normalize anything. Well, you're the boss. Nevertheless, I'd still like to hear a reasoned argument. (If there was one please point me to it.) > > > TOFU is about monitoring bindings to detect conflicts. If we don't > > TOFU at example.org and T0FU at example.org are different identities - even if > you can't see that immediately. _We_ do not need to bother, a MUA _may_ > give a hint that they look similar but that has nothing to do with > TOFU. Then we'll have to disagree. I would honestly and sincerely like to hear what you think TOFU is trying to protect against. From wk at gnupg.org Thu Dec 8 19:36:00 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 08 Dec 2016 19:36:00 +0100 Subject: Handling a TOFU conflict In-Reply-To: <87shpyzp3h.wl-neal@walfield.org> (Neal H. Walfield's message of "Thu, 08 Dec 2016 11:34:26 +0100") References: <87wpfd175i.wl-neal@walfield.org> <87fum0njiu.fsf@wheatstone.g10code.de> <87oa0o10qd.wl-neal@walfield.org> <87pol3mrt0.fsf@wheatstone.g10code.de> <87y3zrzaqj.wl-neal@walfield.org> <87a8c7mj9p.fsf@wheatstone.g10code.de> <87wpfazske.wl-neal@walfield.org> <87k2balnx9.fsf@wheatstone.g10code.de> <87shpyzp3h.wl-neal@walfield.org> Message-ID: <87r35ijmjz.fsf@wheatstone.g10code.de> On Thu, 8 Dec 2016 11:34, neal at walfield.org said: > reasoned argument. (If there was one please point me to it.) Aside from discussions here, we discussed this in person, on ohone, and on jabber several times. I know that you write a paper where you argued that protecting against homograph is important. I do not share this view, though. What seems to be a homograph to one person it is a plausible different entity to another person. > Then we'll have to disagree. I would honestly and sincerely like to > hear what you think TOFU is trying to protect against. To detect and warn about a different key with the same mail address. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From aheinecke at intevation.de Thu Dec 8 20:13:38 2016 From: aheinecke at intevation.de (Andre Heinecke) Date: Thu, 08 Dec 2016 20:13:38 +0100 Subject: Handling a TOFU conflict In-Reply-To: <87r35ijmjz.fsf@wheatstone.g10code.de> References: <87wpfd175i.wl-neal@walfield.org> <87shpyzp3h.wl-neal@walfield.org> <87r35ijmjz.fsf@wheatstone.g10code.de> Message-ID: <1615852.m0umjRhzK6@esus> Hi, On Thursday 08 December 2016 19:36:00 Werner Koch wrote: > On Thu, 8 Dec 2016 11:34, neal at walfield.org said: > > reasoned argument. (If there was one please point me to it.) > > Aside from discussions here, we discussed this in person, on ohone, and > on jabber several times. I know that you write a paper where you argued > that protecting against homograph is important. I do not share this > view, though. What seems to be a homograph to one person it is a > plausible different entity to another person. for the record. I completely agree with werner here and this may hurt usability through false positives so much that automated crypto is not doable. > > Then we'll have to disagree. I would honestly and sincerely like to > > hear what you think TOFU is trying to protect against. > > To detect and warn about a different key with the same mail address. I'm also in agreement, I think TOFU is most important as a tool for automated encryption. And as long as I won't try to write mails to "T0FU at example.com" instead of "TOFU at example.com" this is a non issue. 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: 659 bytes Desc: This is a digitally signed message part. URL: From neal at walfield.org Thu Dec 8 20:41:43 2016 From: neal at walfield.org (Neal H. Walfield) Date: Thu, 08 Dec 2016 20:41:43 +0100 Subject: Handling a TOFU conflict In-Reply-To: <1615852.m0umjRhzK6@esus> References: <87wpfd175i.wl-neal@walfield.org> <87shpyzp3h.wl-neal@walfield.org> <87r35ijmjz.fsf@wheatstone.g10code.de> <1615852.m0umjRhzK6@esus> Message-ID: <87r35iyzrc.wl-neal@walfield.org> On Thu, 08 Dec 2016 20:13:38 +0100, Andre Heinecke wrote: > On Thursday 08 December 2016 19:36:00 Werner Koch wrote: > > On Thu, 8 Dec 2016 11:34, neal at walfield.org said: > > > reasoned argument. (If there was one please point me to it.) > > > > Aside from discussions here, we discussed this in person, on ohone, and > > on jabber several times. I know that you write a paper where you argued > > that protecting against homograph is important. I do not share this > > view, though. What seems to be a homograph to one person it is a > > plausible different entity to another person. > > for the record. I completely agree with werner here and this may hurt > usability through false positives so much that automated crypto is not doable. I find it hard to imagine that detecting homographic-based conflicts would introduce many false positives. > > > Then we'll have to disagree. I would honestly and sincerely like to > > > hear what you think TOFU is trying to protect against. > > > > To detect and warn about a different key with the same mail address. > > I'm also in agreement, I think TOFU is most important as a tool for automated > encryption. And as long as I won't try to write mails to "T0FU at example.com" > instead of "TOFU at example.com" this is a non issue. Serious question: what is this tool (i.e., TOFU) supposed to do? That is, how is it supposed to help automated encryption? Thanks, :) Neal From aheinecke at intevation.de Thu Dec 8 21:09:44 2016 From: aheinecke at intevation.de (Andre Heinecke) Date: Thu, 08 Dec 2016 21:09:44 +0100 Subject: Handling a TOFU conflict In-Reply-To: <87r35iyzrc.wl-neal@walfield.org> References: <87wpfd175i.wl-neal@walfield.org> <1615852.m0umjRhzK6@esus> <87r35iyzrc.wl-neal@walfield.org> Message-ID: <2266991.1AgMOifCKG@esus> Hi, On Thursday 08 December 2016 20:41:43 Neal H. Walfield wrote: > I find it hard to imagine that detecting homographic-based conflicts > would introduce many false positives. My goal is to detect / resolve problems on the senders side. Using a new mail address that is "homographic" different is not an attack to me. Please outline how a homographic conflict could be used as an attack on TOFU. Please do not see this as unconstructive bashing. I am currently in the process of trying to create / understand an attack tree on a TOFU trust model, and I just don't see homographic attacks there. > > > > Then we'll have to disagree. I would honestly and sincerely like to > > > > hear what you think TOFU is trying to protect against. > > > > > > To detect and warn about a different key with the same mail address. > > > > I'm also in agreement, I think TOFU is most important as a tool for > > automated encryption. And as long as I won't try to write mails to > > "T0FU at example.com" instead of "TOFU at example.com" this is a non issue. > > Serious question: what is this tool (i.e., TOFU) supposed to do? That > is, how is it supposed to help automated encryption? It should help in two cases: a) You have some weak indication that the sender is who he claims because you have communication history with him. So after some history you can show an indicator "Ok this is really who you think that is belonging to the senders address" b) You can be confident that the recipient can decrypt your messages because you have history that he used the key for signing messages to you. Or alternatively you think that he was able to decrypt messages sent to him. 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: 659 bytes Desc: This is a digitally signed message part. URL: From neal at walfield.org Thu Dec 8 22:11:19 2016 From: neal at walfield.org (Neal H. Walfield) Date: Thu, 08 Dec 2016 22:11:19 +0100 Subject: Handling a TOFU conflict In-Reply-To: <2266991.1AgMOifCKG@esus> References: <87wpfd175i.wl-neal@walfield.org> <1615852.m0umjRhzK6@esus> <87r35iyzrc.wl-neal@walfield.org> <2266991.1AgMOifCKG@esus> Message-ID: <87pol2yvm0.wl-neal@walfield.org> On Thu, 08 Dec 2016 21:09:44 +0100, Andre Heinecke wrote: > On Thursday 08 December 2016 20:41:43 Neal H. Walfield wrote: > > I find it hard to imagine that detecting homographic-based conflicts > > would introduce many false positives. > > My goal is to detect / resolve problems on the senders side. Using a new mail > address that is "homographic" different is not an attack to me. Please outline > how a homographic conflict could be used as an attack on TOFU. Please do not > see this as unconstructive bashing. I am currently in the process of trying to > create / understand an attack tree on a TOFU trust model, and I just don't see > homographic attacks there. A homographic attack is not an attack on TOFU; it is an attack on the user. TOFU can help prevent such attacks. Let's say, Alice and Bob communicate with each other regularly, and that an attacker wants to trick Alice into sharing some of her secrets with Bob. The attacker could send her an encrypted and signed email from "B0b" with the body, "Can you please send me document so and so." If TOFU detects this, it can warn Alice about the potential phishing attack. If not, Alice needs to recognize that the mail was from B0b and not Bob, which is not easy even if Alice is a sophisticated user. The TOFU statistics help Alice detect this type of attack. But, if we are able to detect obvious homograph attacks and instead raise a conflict, that would, IMO, be better. > > > > > Then we'll have to disagree. I would honestly and sincerely like to > > > > > hear what you think TOFU is trying to protect against. > > > > > > > > To detect and warn about a different key with the same mail address. > > > > > > I'm also in agreement, I think TOFU is most important as a tool for > > > automated encryption. And as long as I won't try to write mails to > > > "T0FU at example.com" instead of "TOFU at example.com" this is a non issue. > > > > Serious question: what is this tool (i.e., TOFU) supposed to do? That > > is, how is it supposed to help automated encryption? > > It should help in two cases: > > a) You have some weak indication that the sender is who he claims because you > have communication history with him. > > So after some history you can show an indicator "Ok this is really who you > think that is belonging to the senders address" I agree that we want to use TOFU to provide weak authentication (i.e., verify that entity X controls key Y). > b) You can be confident that the recipient can decrypt your messages because > you have history that he used the key for signing messages to you. Or > alternatively you think that he was able to decrypt messages sent to him. This isn't a trust model's goal (a trust model is about verification). But clearly, any key that is verified will satisfy these requirements. The difficult question is: how to we find an appropriate key for a given entity when we haven't verified the entity? It is appealing to use TOFU, whose judgments are based on history, but this is a hack. Instead, we should provide a separate interface that answers the question: "If I want to send a message to bob at example.com what is the best key?" How exactly this works is an implementation detail, but it could internally reuse some of the facts that the TOFU engine has collected. Thanks, Neal From wk at gnupg.org Fri Dec 9 11:30:19 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 09 Dec 2016 11:30:19 +0100 Subject: Handling a TOFU conflict In-Reply-To: <87pol2yvm0.wl-neal@walfield.org> (Neal H. Walfield's message of "Thu, 08 Dec 2016 22:11:19 +0100") References: <87wpfd175i.wl-neal@walfield.org> <1615852.m0umjRhzK6@esus> <87r35iyzrc.wl-neal@walfield.org> <2266991.1AgMOifCKG@esus> <87pol2yvm0.wl-neal@walfield.org> Message-ID: <87d1h1jsxw.fsf@wheatstone.g10code.de> On Thu, 8 Dec 2016 22:11, neal at walfield.org said: > A homographic attack is not an attack on TOFU; it is an attack on the > user. TOFU can help prevent such attacks. Maybe a TOFU system can helper. However, this is not for what we use it. > I agree that we want to use TOFU to provide weak authentication (i.e., > verify that entity X controls key Y). TOFU means Trust on _First Use_ and that is what we need. We trust the mail address and its key on the first use and we want the TOFU code to tell us about a conflict and help to resolve a possible conflict (i.e. a a key with a mail address which is not legitimate). > The difficult question is: how to we find an appropriate key for a > given entity when we haven't verified the entity? It is appealing to > use TOFU, whose judgments are based on history, but this is a hack. That is not the goal of TOFU. To discover the key for a given address we have other methods (DANE, WKD, signature verification). > question: "If I want to send a message to bob at example.com what is the > best key?" How exactly this works is an implementation detail, but it That is not the question. There will only be one key for bob at example.com. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From justus at g10code.com Fri Dec 9 14:55:54 2016 From: justus at g10code.com (Justus Winter) Date: Fri, 09 Dec 2016 14:55:54 +0100 Subject: RFC on issue 2701, default expiration time for new keys In-Reply-To: <87pol49bch.fsf@europa.jade-hamburg.de> References: <87pol49bch.fsf@europa.jade-hamburg.de> Message-ID: <87a8c52olx.fsf@europa.jade-hamburg.de> Justus Winter writes: > inspired by the talk on OpenKeychain UX decisions at the OpenPGP > conference, I decided that it is a bad idea to let users create keys > that don't expire (unless they want to hang themself with --expert). Working on that I discovered that it is a bit more complicated (isn't it always...?). There are multiple ways to generate keys using GnuPG: 1) gpg --gen-key 2) gpg --full-gen-key 3) gpg --full-gen-key --expert 4) gpg --quick-gen-key 5) gpg --quick-addkey 1) is our simplified key generation dialog. I noticed that it creates keys that do not expire at all, and I fixed that. 2) is the old key generation dialog. This asks for an expiration time, and allows one to create keys that do not expire. Shall I change that? 3) this let's one shoot in the foot. No need to do anything here. 4) and 5) are part of the fairly recent --quick-* API that is (mostly) intended for use with GPGME, but I guess this will see widespread use in scripts too. 4) generates an identity key, 5) adds subkeys to an existing key. Both allow one to specify an expiration time (optional, or '-' to explicitly select the default, or the key words 'never' and 'none'). By default the keys generated using this way do not expire. I'd like to change that as well. Thoughts? > This now begs the question what a good default expiration time is. > Thoughts? Based on the feedback I went with two years. Objections? Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From neal at walfield.org Fri Dec 9 15:14:39 2016 From: neal at walfield.org (Neal H. Walfield) Date: Fri, 09 Dec 2016 15:14:39 +0100 Subject: RFC on issue 2701, default expiration time for new keys In-Reply-To: <87a8c52olx.fsf@europa.jade-hamburg.de> References: <87pol49bch.fsf@europa.jade-hamburg.de> <87a8c52olx.fsf@europa.jade-hamburg.de> Message-ID: <87oa0lyysw.wl-neal@walfield.org> On Fri, 09 Dec 2016 14:55:54 +0100, Justus Winter wrote: > Justus Winter writes: > > This now begs the question what a good default expiration time is. > > Thoughts? > > Based on the feedback I went with two years. Objections? I think two years is a good minimum reasonable default. But, not yet. The problem that I see is that the tools are not yet there. With a two year default, people are going to have to start extending the expiration in about 18 to 20 months (to give time for the update to propagate). The tools (e.g., enigmail) should make extending the expiration easy (e.g., a dialog: do you want to extend your key's expiration for another two years?), but AFAIK they don't yet. Further, users are going to have to update keys regularly. Ideally, dirmngr should do this automatically a la parcimonie, but that functionality is only planned for gpg 2.3. As such, I wonder if starting with a 4 or 5 year default expiration wouldn't be better. Thanks! :) Neal From peter at digitalbrains.com Fri Dec 9 15:17:54 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 9 Dec 2016 15:17:54 +0100 Subject: RFC on issue 2701, default expiration time for new keys In-Reply-To: <87a8c52olx.fsf@europa.jade-hamburg.de> References: <87pol49bch.fsf@europa.jade-hamburg.de> <87a8c52olx.fsf@europa.jade-hamburg.de> Message-ID: On 09/12/16 14:55, Justus Winter wrote: >[...] 5) adds subkeys to an > existing key. Both allow one to specify an expiration time (optional, > or '-' to explicitly select the default, or the key words 'never' and > 'none'). By default the keys generated using this way do not expire. > I'd like to change that as well. What's the purpose of putting an expiry date on the subkeys? I thought this was mainly to deal with losing access to the private key material. Isn't that only relevant for the primary key? Cheers, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From Alexander.Strobel at giepa.de Fri Dec 9 15:48:43 2016 From: Alexander.Strobel at giepa.de (Alexander Strobel) Date: Fri, 9 Dec 2016 15:48:43 +0100 Subject: RFC on issue 2701, default expiration time for new keys In-Reply-To: <87oa0lyysw.wl-neal@walfield.org> References: <87pol49bch.fsf@europa.jade-hamburg.de> <87a8c52olx.fsf@europa.jade-hamburg.de> <87oa0lyysw.wl-neal@walfield.org> Message-ID: <926efcc0-70ab-c315-6fcc-b27c14355caa@giepa.de> Am 09.12.2016 um 15:14 schrieb Neal H. Walfield: > The problem that I see is that the tools are not yet there. With a > two year default, people are going to have to start extending the > expiration in about 18 to 20 months (to give time for the update to > propagate). The tools (e.g., enigmail) should make extending the > expiration easy (e.g., a dialog: do you want to extend your key's > expiration for another two years?), but AFAIK they don't yet. Enigmail shows a messagebox when a key is about to expire. I think I saw something like 30 days before my key was about to expire. In gpg4o we have a feature like this on out todo list for about three years now and we will probably implement it within the few months. :) Best regards Alex Strobel www.gpg4o.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From neal at walfield.org Fri Dec 9 15:54:05 2016 From: neal at walfield.org (Neal H. Walfield) Date: Fri, 09 Dec 2016 15:54:05 +0100 Subject: RFC on issue 2701, default expiration time for new keys In-Reply-To: <926efcc0-70ab-c315-6fcc-b27c14355caa@giepa.de> References: <87pol49bch.fsf@europa.jade-hamburg.de> <87a8c52olx.fsf@europa.jade-hamburg.de> <87oa0lyysw.wl-neal@walfield.org> <926efcc0-70ab-c315-6fcc-b27c14355caa@giepa.de> Message-ID: <87mvg5ywz6.wl-neal@walfield.org> Hi, On Fri, 09 Dec 2016 15:48:43 +0100, Alexander Strobel wrote: > Am 09.12.2016 um 15:14 schrieb Neal H. Walfield: > > The problem that I see is that the tools are not yet there. With a > > two year default, people are going to have to start extending the > > expiration in about 18 to 20 months (to give time for the update to > > propagate). The tools (e.g., enigmail) should make extending the > > expiration easy (e.g., a dialog: do you want to extend your key's > > expiration for another two years?), but AFAIK they don't yet. > > Enigmail shows a messagebox when a key is about to expire. I think I saw > something like 30 days before my key was about to expire. Thanks for the correction! I think 30 days is a bit short given the delay propagation, but I'm happy that that feature is already there. > In gpg4o we have a feature like this on out todo list for about three > years now and we will probably implement it within the few months. :) That's good to hear. :) Neal From infinity0 at pwned.gg Fri Dec 9 15:33:00 2016 From: infinity0 at pwned.gg (Ximin Luo) Date: Fri, 09 Dec 2016 14:33:00 +0000 Subject: RFC on issue 2701, default expiration time for new keys In-Reply-To: <1a0b8459-5aa7-d376-f250-4cb1672bb568@pwned.gg> References: <87pol49bch.fsf@europa.jade-hamburg.de> <87a8c52olx.fsf@europa.jade-hamburg.de> <1a0b8459-5aa7-d376-f250-4cb1672bb568@pwned.gg> Message-ID: <166087fa-713a-0719-5487-9b0cce767929@pwned.gg> Ximin Luo: > Peter Lebbing: >> On 09/12/16 14:55, Justus Winter wrote: >>> [...] 5) adds subkeys to an >>> existing key. Both allow one to specify an expiration time (optional, >>> or '-' to explicitly select the default, or the key words 'never' and >>> 'none'). By default the keys generated using this way do not expire. >>> I'd like to change that as well. >> >> What's the purpose of putting an expiry date on the subkeys? I thought >> this was mainly to deal with losing access to the private key material. >> Isn't that only relevant for the primary key? >> > > No, some people like to split their secret master keys and subkeys. You can do --export-secret-subkeys then selectively import the subkeys. > For example, what I do here is set 15 months expiry date for the Certify/Sign/Authenticate keys and 9 months for Encrypt. https://github.com/infinity0/l33tutils/blob/master/data/security/gpgen.sh The numbers are meant to be round numbers (1 year, 1/2 year) plus 3 months to give a suitable overlap time for other people to update your key. If you set your expiry dates to 3 years, you then have to update things every 2 3/4 years or something like that. It's easier to plan around, if you just do it every December. :) X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git From infinity0 at pwned.gg Fri Dec 9 15:29:00 2016 From: infinity0 at pwned.gg (Ximin Luo) Date: Fri, 09 Dec 2016 14:29:00 +0000 Subject: RFC on issue 2701, default expiration time for new keys In-Reply-To: References: <87pol49bch.fsf@europa.jade-hamburg.de> <87a8c52olx.fsf@europa.jade-hamburg.de> Message-ID: <1a0b8459-5aa7-d376-f250-4cb1672bb568@pwned.gg> Peter Lebbing: > On 09/12/16 14:55, Justus Winter wrote: >> [...] 5) adds subkeys to an >> existing key. Both allow one to specify an expiration time (optional, >> or '-' to explicitly select the default, or the key words 'never' and >> 'none'). By default the keys generated using this way do not expire. >> I'd like to change that as well. > > What's the purpose of putting an expiry date on the subkeys? I thought > this was mainly to deal with losing access to the private key material. > Isn't that only relevant for the primary key? > No, some people like to split their secret master keys and subkeys. You can do --export-secret-subkeys then selectively import the subkeys. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git From peter at digitalbrains.com Fri Dec 9 19:20:33 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 9 Dec 2016 19:20:33 +0100 Subject: RFC on issue 2701, default expiration time for new keys In-Reply-To: <1a0b8459-5aa7-d376-f250-4cb1672bb568@pwned.gg> References: <87pol49bch.fsf@europa.jade-hamburg.de> <87a8c52olx.fsf@europa.jade-hamburg.de> <1a0b8459-5aa7-d376-f250-4cb1672bb568@pwned.gg> Message-ID: <7702ef0c-2c8f-42f4-68a8-ded6c1b93566@digitalbrains.com> On 09/12/16 15:29, Ximin Luo wrote: > No, some people like to split their secret master keys and subkeys. I'm pretty sure expirations and revocations are signed by the primary key, also expirations and revocations of subkeys. So if you happen to lose access to the private key material of a subkey, you can revoke or expire it on the spot, with the primary key. If you say "we should have expiries to cope with the fact that you can't revoke anymore once you lose access to the private key", I think that is purely related to losing access to the primary key. I don't see the purpose of putting an expiry on a subkey in this use case. Obviously there can be other reasons to put expiries on subkeys, but are they within scope of this discussion? Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From infinity0 at pwned.gg Fri Dec 9 20:00:00 2016 From: infinity0 at pwned.gg (Ximin Luo) Date: Fri, 09 Dec 2016 19:00:00 +0000 Subject: RFC on issue 2701, default expiration time for new keys In-Reply-To: <7702ef0c-2c8f-42f4-68a8-ded6c1b93566@digitalbrains.com> References: <87pol49bch.fsf@europa.jade-hamburg.de> <87a8c52olx.fsf@europa.jade-hamburg.de> <1a0b8459-5aa7-d376-f250-4cb1672bb568@pwned.gg> <7702ef0c-2c8f-42f4-68a8-ded6c1b93566@digitalbrains.com> Message-ID: <8f70b021-3d85-1b24-777e-c88f59d7d99f@pwned.gg> Peter Lebbing: > On 09/12/16 15:29, Ximin Luo wrote: >> No, some people like to split their secret master keys and subkeys. > > I'm pretty sure expirations and revocations are signed by the primary > key, also expirations and revocations of subkeys. > > So if you happen to lose access to the private key material of a subkey, > you can revoke or expire it on the spot, with the primary key. > > If you say "we should have expiries to cope with the fact that you can't > revoke anymore once you lose access to the private key", I think that is > purely related to losing access to the primary key. I don't see the > purpose of putting an expiry on a subkey in this use case. Obviously > there can be other reasons to put expiries on subkeys, but are they > within scope of this discussion? > You are correct in all of the above regarding the power of the private master key. However, expiry dates are more of a policy statement by the controller of the private master key. When you set an expiry date you're saying to the world "I consider this [sub]key no longer valid after this date", you're making a public committment. This enables your recipient to ensure fresheness of that subkey - if it's expired then "something is wrong", either you should have renewed the expiry date or added a new subkey. Now it's reasonable that someone might want to set different policy "validation periods" for different subkeys. For example, I like to set the encryption subkey to have a relatively short expiry, to try to provide some approximation to forward secrecy. But I don't see an equal need for signing subkeys to have short expiries, probably longer expiries are more convenient. Or maybe someone else could disagree, then they could set it to have the same expiry as their encryption subkey[s]. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git From wk at gnupg.org Fri Dec 9 20:56:57 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 09 Dec 2016 20:56:57 +0100 Subject: RFC on issue 2701, default expiration time for new keys In-Reply-To: <7702ef0c-2c8f-42f4-68a8-ded6c1b93566@digitalbrains.com> (Peter Lebbing's message of "Fri, 9 Dec 2016 19:20:33 +0100") References: <87pol49bch.fsf@europa.jade-hamburg.de> <87a8c52olx.fsf@europa.jade-hamburg.de> <1a0b8459-5aa7-d376-f250-4cb1672bb568@pwned.gg> <7702ef0c-2c8f-42f4-68a8-ded6c1b93566@digitalbrains.com> Message-ID: <87oa0kho52.fsf@wheatstone.g10code.de> On Fri, 9 Dec 2016 19:20, peter at digitalbrains.com said: > So if you happen to lose access to the private key material of a subkey, > you can revoke or expire it on the spot, with the primary key. That is indeed one of the purposes of an offline primary key. You can simply create a new subkey or change the subkey'ss expiration time. I concur that a default expiration time for a subkey makes no sense. Tweaking subkeys is an expert operation. The only valid reason for a default expiration time, as suggested by Justus, is to limit the time data can accidently be encrypted to a key of which the owner forgot the passphrase (common case) or lost the key material. With access to the primary secret key a user can do all necessary key operations. FWIW, I would like to see a 2 years expiration time for new keys. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From neal at walfield.org Fri Dec 9 22:50:35 2016 From: neal at walfield.org (Neal H. Walfield) Date: Fri, 09 Dec 2016 22:50:35 +0100 Subject: Handling a TOFU conflict In-Reply-To: <87r35ijmjz.fsf@wheatstone.g10code.de> References: <87wpfd175i.wl-neal@walfield.org> <87fum0njiu.fsf@wheatstone.g10code.de> <87oa0o10qd.wl-neal@walfield.org> <87pol3mrt0.fsf@wheatstone.g10code.de> <87y3zrzaqj.wl-neal@walfield.org> <87a8c7mj9p.fsf@wheatstone.g10code.de> <87wpfazske.wl-neal@walfield.org> <87k2balnx9.fsf@wheatstone.g10code.de> <87shpyzp3h.wl-neal@walfield.org> <87r35ijmjz.fsf@wheatstone.g10code.de> Message-ID: <87lgvozs9g.wl-neal@walfield.org> On Thu, 08 Dec 2016 19:36:00 +0100, Werner Koch wrote: > On Thu, 8 Dec 2016 11:34, neal at walfield.org said: > > > reasoned argument. (If there was one please point me to it.) > > Aside from discussions here, we discussed this in person, on ohone, and > on jabber several times. I know that you write a paper where you argued > that protecting against homograph is important. I do not share this > view, though. What seems to be a homograph to one person it is a > plausible different entity to another person. > > > Then we'll have to disagree. I would honestly and sincerely like to > > hear what you think TOFU is trying to protect against. > > To detect and warn about a different key with the same mail address. This is a symptom of some underlying problem. I'd like to know what the underlying problem that we are trying mitigate is. Do you agree that we are trying to hinder active adversaries? Or, are we only trying to protect users from passive adversaries? If the former, what are the adversaries trying to do / what are they capable of? Are they interested in forging messages (e.g., spear phishing)? Are they interested in conducting MitM attacks? Do we assume that they are capable of owning the user's home router? Or, can they only send emails? Thanks! From aheinecke at intevation.de Fri Dec 9 23:29:17 2016 From: aheinecke at intevation.de (Andre Heinecke) Date: Fri, 09 Dec 2016 23:29:17 +0100 Subject: Handling a TOFU conflict In-Reply-To: <87lgvozs9g.wl-neal@walfield.org> References: <87wpfd175i.wl-neal@walfield.org> <87r35ijmjz.fsf@wheatstone.g10code.de> <87lgvozs9g.wl-neal@walfield.org> Message-ID: <2482531.QmTKuqGI0K@esus> Hey neal On Friday 09 December 2016 22:50:35 Neal H. Walfield wrote: > Do you agree that we are trying to hinder active adversaries? Or, are > we only trying to protect users from passive adversaries? If the > former, what are the adversaries trying to do / what are they capable > of? Are they interested in forging messages (e.g., spear phishing)? > Are they interested in conducting MitM attacks? Do we assume that > they are capable of owning the user's home router? Or, can they only > send emails? Please stop this. I thought we had agreed that we need to think through how we want to use TOFU to assist a user and what the threats / attacks against tofu acutally are. And how we are trying to protect against these threats. I find your flood of questions (I still answer them below) an aggressive style of communication and you should not be suprised to get aggressive answers. And regarding homographic attacks i think that you and werner (as I told you both in person today) are repeating the same arguments again and again where you could both agree that you disagree after hearing all the arguments the other side has to offer. Any repetion of that does not help either. I'm trying (still not complete) to come up with a concept for tofu use in MUA's on: https://wiki.gnupg.org/EasyGpg2016/AutomatedEncryption We should work out attack trees / scenarios. That would be super helpful. Fwiw: I'm totally on werner's side reagarding homgraphic attacks because I currently don't see them as a threat. But I am open for arguments :-) > Do you agree that we are trying to hinder active adversaries? Yes. > Or, are we only trying to protect users from passive adversaries? No. > If the former, what are the adversaries trying to do / what are they capable > of? Are they interested in forging messages (e.g., spear phishing)? Yes. They may even be convincing enough to go over "Key with enough history with basic trust" But we prevent that attack through organisational measures + including pgp. > Are they interested in conducting MitM attacks? Yes we want to protect against that, too. > Do we assume that they are capable of owning the user's home router? > Or, can they only send emails? I think both. 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 From rjh at sixdemonbag.org Sat Dec 10 01:54:59 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 9 Dec 2016 19:54:59 -0500 Subject: Handling a TOFU conflict In-Reply-To: <2482531.QmTKuqGI0K@esus> References: <87wpfd175i.wl-neal@walfield.org> <87r35ijmjz.fsf@wheatstone.g10code.de> <87lgvozs9g.wl-neal@walfield.org> <2482531.QmTKuqGI0K@esus> Message-ID: <18186247-ae5e-b500-3f9a-41840ee9a7a2@sixdemonbag.org> > Fwiw: I'm totally on werner's side reagarding homgraphic attacks because I > currently don't see them as a threat. But I am open for arguments :-) I agree with you. More than that, I see this is a Bill-and-Ted problem (so named for the movie _Bill and Ted's Excellent Adventure_): Bill: Ted, while I agree that, in time, our band will be most triumphant, the truth is Wyld Stallyns will never be a super band until we have Eddie Van Halen on guitar. Ted: Yes, Bill. But I do not believe we will get Eddie Van Halen until we have a triumphant video. Bill: Ted, it's pointless to have a triumphant video before we even have decent instruments. Ted: Well, how can we have decent instruments when we don't really even know how to play? Bill: That's why we need Eddie Van Halen! Ted: And that's why we need a triumphant video! Bill-and-Tedism is like bikeshedding, but even less productive. Bikeshedding wastes valuable time and energy on trivia; Bill-and-Tedding escalates trivial things to issues that block work getting done. Insisting that theoretical attacks be mitigated is (usually) Bill-and-Tedism. There will always be more theoretical attacks to mitigate and as a result it'll never be deployed. On the other hand, you can always put in the release notes, "We do not defend against this theoretical attack. If that's a problem for you, disable this feature." AFAIK, there are no reports of homographic attacks being used in the wild. I personally would be overjoyed if they were: that would mean OpenPGP's adoption had increased to the point where it was worthwhile to make these attacks... From caro at nymph.paranoici.org Sun Dec 11 03:01:31 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Sun, 11 Dec 2016 02:01:31 +0000 (UTC) Subject: Key creation problem with 2.1.16 References: <20161129230429.B2488100B190@remailer.paranoici.org> <8760mxoghi.fsf@alice.fifthhorseman.net> <20161206124120.A4B1A1032319@remailer.paranoici.org> <87fum1m24x.fsf@alice.fifthhorseman.net> <20161208032707.B84771025BE0@remailer.paranoici.org> <87y3zrhwkj.fsf@alice.fifthhorseman.net> Message-ID: <20161211020131.DFD3210322B2@remailer.paranoici.org> Hello Daniel, on Wed, 07 Dec 2016 23:30:20 -0500, you wrote: >On Wed 2016-12-07 22:27:07 -0500, Carola Grunwald wrote: >> In fact I experience at least two different kinds of failure. Both are >> sporadic, not systematic errors. As I tried to provide a similar >> starting situation for each of these command calls I'm surprised at the >> varying outcome. > >Thanks for the details, Carola. This all sounds really frustrating, but >i'm afraid i'm not in a good position to debug it, given that it seems >to involve Windows. I'm not able to reproduce a 50/50 error on the >linux systems i usually test and develop on :/ > >hopefully someone with more windows experience can help you out more. Well, let's hope so. > >sorry to not be more help, Thanks a lot Daniel, I appreciate your dedication. P.S.: Maybe I finally got it! For unattended key creation you're allowed to add the passphrase to the parameter file defined with the --gen-key command. That's what the manual https://www.gnupg.org/documentation/manuals/gnupg.pdf tells us at page 84 and what works with v1.4. | Passphrase: string | If you want to specify a passphrase for the secret key, enter it here. | Default is to use the Pinentry dialog to ask for a passphrase. But with v2.1 it looks as if you nevertheless have to add a --passphrase parameter. Otherwise the command aborts with an error 2. It looks as if the passphrase in the file is used only for key creation but not for key data retrieval, which happens afterwards. That's where it complains about the missing passphrase input. I don't know why the gen-key command still succeeds every now and then even with a missing --passphrase parameter. Either a miracle, or that happens when the passphrase is in the cache, which I love so much for the confusion I expect it can cause. Kind regards Caro From muelli at cryptobitch.de Sun Dec 11 22:25:08 2016 From: muelli at cryptobitch.de (Tobias Mueller) Date: Sun, 11 Dec 2016 22:25:08 +0100 Subject: RFC on issue 2701, default expiration time for new keys In-Reply-To: <87pol49bch.fsf@europa.jade-hamburg.de> References: <87pol49bch.fsf@europa.jade-hamburg.de> Message-ID: <20161211212508.GA4181@cryptobitch.de> Hi. On Wed, Dec 07, 2016 at 01:23:42PM +0100, Justus Winter wrote: > inspired by the talk on OpenKeychain UX decisions at the OpenPGP > conference, I decided that it is a bad idea to let users create keys > that don't expire (unless they want to hang themself with --expert). > > This now begs the question what a good default expiration time is. > Thoughts? What does OpenKeychain do? Were they asked to provide input reg. that question? I suppose they have an opinion on the default expiration time. And maybe even reasons. Cheers, Tobi From justus at g10code.com Mon Dec 12 10:48:53 2016 From: justus at g10code.com (Justus Winter) Date: Mon, 12 Dec 2016 10:48:53 +0100 Subject: RFC on issue 2701, default expiration time for new keys In-Reply-To: <20161211212508.GA4181@cryptobitch.de> References: <87pol49bch.fsf@europa.jade-hamburg.de> <20161211212508.GA4181@cryptobitch.de> Message-ID: <87shpt32be.fsf@europa.jade-hamburg.de> Tobias Mueller writes: > On Wed, Dec 07, 2016 at 01:23:42PM +0100, Justus Winter wrote: >> inspired by the talk on OpenKeychain UX decisions at the OpenPGP >> conference, I decided that it is a bad idea to let users create keys >> that don't expire (unless they want to hang themself with --expert). >> >> This now begs the question what a good default expiration time is. >> Thoughts? > What does OpenKeychain do? Hard to tell, I just tried to create a new key, and I have not been asked for an expiration time on the master key, nor have I found a way to view the expiration time of existing master keys. It is possible to configure expiration times for the subkeys, which do not expire by default. > Were they asked to provide input reg. that question? No. Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From neal at walfield.org Wed Dec 14 13:26:51 2016 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 14 Dec 2016 13:26:51 +0100 Subject: INBOME comments In-Reply-To: <87inqxm4ll.fsf@alice.fifthhorseman.net> References: <87y3zt17ul.wl-neal@walfield.org> <87inqxm4ll.fsf@alice.fifthhorseman.net> Message-ID: <87d1guzofo.wl-neal@walfield.org> On Tue, 06 Dec 2016 16:58:46 +0100, Daniel Kahn Gillmor wrote: > > - In the group communication example, Alice sends a message to Bob > > and Carol at which point Bob and Carol learn about Alice's INBOME > > preferences. Why doesn't Alice also include Bob and Carol's latest > > IMBOME header so that Bob and Carol can immediately learn about > > Carol and Bob's keys, respectively, without additional > > interactions? > > While i think something like that could be useful, we need to be > extremely cautious about the consequences of allowing "drive-by" INBOME > data. The analogy in the DNS world is "cache poisoning". If i can set, > clear, or reset your INBOME data for someone else even if i don't have > access to the communitions channel, what are the consequences for your > future communications? I'd like to add that I appreciate it when people send me keys or fingerprints of others who are in cc. It makes following up so much easier. If the keys were automatically imported and marked as having been provided by a particular person, that would be even better. From dominik at dominikschuermann.de Wed Dec 14 12:49:00 2016 From: dominik at dominikschuermann.de (Dominik Schuermann) Date: Wed, 14 Dec 2016 12:49:00 +0100 Subject: RFC on issue 2701, default expiration time for new keys In-Reply-To: <87shpt32be.fsf@europa.jade-hamburg.de> References: <87pol49bch.fsf@europa.jade-hamburg.de> <20161211212508.GA4181@cryptobitch.de> <87shpt32be.fsf@europa.jade-hamburg.de> Message-ID: <1641dbfc-bed3-5043-7e97-6fdc12ec01d6@dominikschuermann.de> On 12/12/2016 10:48 AM, Justus Winter wrote: > Tobias Mueller writes: > >> On Wed, Dec 07, 2016 at 01:23:42PM +0100, Justus Winter wrote: >> What does OpenKeychain do? > > Hard to tell, I just tried to create a new key, and I have not been > asked for an expiration time on the master key, nor have I found a way > to view the expiration time of existing master keys. It is possible to > configure expiration times for the subkeys, which do not expire by > default. The first key displayed in Advanced->Subkeys is the master key. We haven't put much time into the advanced screen design. Currently, OpenKeychain does not set an expiration date by default. We wrote down our design decisions here: https://github.com/open-keychain/open-keychain/wiki/OpenPGP-Security#no-expiry-for-keys-created-by-openkeychain We are not fully convinced by our own arguments :). Maybe we will switch to a mechanism were an expiration date is set and extended automatically in the background. This would let the key expire automatically from the point on where OpenKeychain is no longer installed. We are open on input on this matter. Cheers Dominik -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Dec 15 10:46:00 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 15 Dec 2016 10:46:00 +0100 Subject: [Announce] Libgcrypt 1.7.5 released Message-ID: <87mvfx7cfb.fsf@wheatstone.g10code.de> Hi! The GnuPG Project is pleased to announce the availability of Libgcrypt version 1.7.5. 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.5 (2016-12-15) ------------------------------------------------ * Bug fixes: - Fix regression in mlock detection introduced with 1.7.4 [bug#2870]. Noteworthy changes in version 1.7.4 (2016-12-09) ------------------------------------------------ * Performance: - More ARMv8/AArch32 improvements for AES, GCM, SHA-256, and SHA-1. - Add ARMv8/AArch32 assembly implementation for Twofish and Camellia. - Add bulk processing implementation for ARMv8/AArch32. - Add Stribog OIDs. - Improve the DRBG performance and sync the code with the Linux version. * Internal changes: - When secure memory is requested by the MPI functions or by gcry_xmalloc_secure, they do not anymore lead to a fatal error if the secure memory pool is used up. Instead new pools are allocated as needed. These new pools are not protected against being swapped out (mlock can't be used). However, these days this is considered a minor issue and can easily be mitigated by using encrypted swap space. * Bug fixes: - Fix GOST 28147 CryptoPro-B S-box. - Fix error code handling of mlock calls. 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.5.tar.bz2 (2816k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.5.tar.bz2.sig That file is bzip2 compressed. A gzip compressed version is here: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.5.tar.gz (3365k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.5.tar.gz.sig The same files are also available via HTTP: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.5.tar.bz2 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.5.tar.bz2.sig https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.5.tar.gz https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.5.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.5.tar.bz2 you would use this command: gpg --verify libgcrypt-1.7.5.tar.bz2.sig libgcrypt-1.7.5.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 the end of this mail 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 libgcrypt-1.7.5.tar.bz2, you run the command like this: sha1sum libgcrypt-1.7.5.tar.bz2 and check that the output matches the first line from the this list: fa485d854748fc06ea041b3057b2de2f12fbc17f libgcrypt-1.7.5.tar.bz2 9dc6171c0d6b46a7bc38e4af65091044633dc59a libgcrypt-1.7.5.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 [1] https://lists.gnupg.org/mailman/listinfo/gcrypt-devel [2] https://www.gnupg.org/service.html [3] https://gnupg.org/donate/kudos.html p.s. This is an announcement only mailing list. Please send replies only to the gcrypt-devel 'at' gnupg.org mailing list. p.p.s List of 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: 2020-10-30] 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. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From curt at brune.net Fri Dec 16 02:58:36 2016 From: curt at brune.net (Curt Brune) Date: Thu, 15 Dec 2016 17:58:36 -0800 Subject: [PATCH 0/1] gpg-agent: multi-sdcard convenience option Message-ID: <1481853517-31171-1-git-send-email-curt@brune.net> This patch introduces a new gpg-agent option that is convenient when the user has encrypted data for multiple card recipients. The patch is made against gnupg tag gnupg-2.1.11, which is the version that comes with my Ubuntu 16.04 system. Curt Brune (1): gpg-agent: add new option --cancel-card-pinentry agent/agent.h | 7 +++++++ agent/divert-scd.c | 5 +++++ agent/gpg-agent.c | 7 +++++++ doc/gpg-agent.texi | 16 ++++++++++++++++ tools/gpgconf-comp.c | 3 +++ 5 files changed, 38 insertions(+) -- 2.7.4 From curt at brune.net Fri Dec 16 02:58:37 2016 From: curt at brune.net (Curt Brune) Date: Thu, 15 Dec 2016 17:58:37 -0800 Subject: [PATCH 1/1] gpg-agent: add new option --cancel-card-pinentry Message-ID: <1481853517-31171-2-git-send-email-curt@brune.net> This patch adds a new boolean global option to gpg-agent. The goal is to suppress unneeded pinentry prompting when the inserted smartcard's serial number does not match the requested serial number. When the requested smartcard serial number does not match the inserted card's serial number, automatically skip the card without prompting the user. This skips the launching of pinetry and moves on, as if the user had selected "cancel". This is convenient when decrypting a file encrypted for multiple smartcard recipients, but only one smartcard is available. In this case only one pinetry will be shown to the user (the one for the inserted card), while the remaining pinetry prompts for unavailable smartcards will be suppressed. Signed-off-by: Curt Brune --- agent/agent.h | 7 +++++++ agent/divert-scd.c | 5 +++++ agent/gpg-agent.c | 7 +++++++ doc/gpg-agent.texi | 16 ++++++++++++++++ tools/gpgconf-comp.c | 3 +++ 5 files changed, 38 insertions(+) diff --git a/agent/agent.h b/agent/agent.h index c2726bb..14d1a3b 100644 --- a/agent/agent.h +++ b/agent/agent.h @@ -158,20 +158,27 @@ struct /* This global options indicates the use of an extra socket. Note that we use a hack for cleanup handling in gpg-agent.c: If the value is less than 2 the name has not yet been malloced. */ int extra_socket; /* This global options indicates the use of an extra socket for web browsers. Note that we use a hack for cleanup handling in gpg-agent.c: If the value is less than 2 the name has not yet been malloced. */ int browser_socket; + + /* If this global option is true, then when a smartcard serial + number does not match the requested serial number, automatically + assume the user wants to skip this card. This skips the + launching of pinetry and moves on, as if the user had selected + "cancel". */ + int cancel_card_pinentry; } opt; /* Bit values for the --debug option. */ #define DBG_COMMAND_VALUE 1 /* debug commands i/o */ #define DBG_MPI_VALUE 2 /* debug mpi details */ #define DBG_CRYPTO_VALUE 4 /* debug low level crypto */ #define DBG_MEMORY_VALUE 32 /* debug memory allocation stuff */ #define DBG_CACHE_VALUE 64 /* debug the caching */ #define DBG_MEMSTAT_VALUE 128 /* show memory statistics */ diff --git a/agent/divert-scd.c b/agent/divert-scd.c index 5d3b1ef..7e8c7fb 100644 --- a/agent/divert-scd.c +++ b/agent/divert-scd.c @@ -64,20 +64,25 @@ ask_for_card (ctrl_t ctrl, const unsigned char *shadow_info, char **r_kid) log_debug ("detected card with S/N %s\n", serialno); i = strcmp (serialno, want_sn); xfree (serialno); serialno = NULL; if (!i) { xfree (want_sn); *r_kid = want_kid; return 0; /* yes, we have the correct card */ } + if (opt.cancel_card_pinentry) + { + log_debug ("automatically skipping card with mismatched S/N\n"); + rc = gpg_error (GPG_ERR_CANCELED); + } } else if (gpg_err_code (rc) == GPG_ERR_CARD_NOT_PRESENT) { log_debug ("no card present\n"); rc = 0; no_card = 1; } else { log_error ("error accessing card: %s\n", gpg_strerror (rc)); diff --git a/agent/gpg-agent.c b/agent/gpg-agent.c index 8aab2b9..54ff4ca 100644 --- a/agent/gpg-agent.c +++ b/agent/gpg-agent.c @@ -117,20 +117,21 @@ enum cmd_and_opt_values oBrowserSocket, oFakedSystemTime, oIgnoreCacheForSigning, oAllowMarkTrusted, oNoAllowMarkTrusted, oAllowPresetPassphrase, oAllowLoopbackPinentry, oNoAllowExternalCache, oAllowEmacsPinentry, + oCancelCardPinentry, oKeepTTY, oKeepDISPLAY, oSSHSupport, oPuttySupport, oDisableScdaemon, oDisableCheckOwnSocket, oWriteEnvFile }; @@ -217,20 +218,22 @@ static ARGPARSE_OPTS opts[] = { /* */ N_("disallow the use of an external password cache")), ARGPARSE_s_n (oNoAllowMarkTrusted, "no-allow-mark-trusted", /* */ N_("disallow clients to mark keys as \"trusted\"")), ARGPARSE_s_n (oAllowMarkTrusted, "allow-mark-trusted", "@"), ARGPARSE_s_n (oAllowPresetPassphrase, "allow-preset-passphrase", /* */ N_("allow presetting passphrase")), ARGPARSE_s_n (oAllowLoopbackPinentry, "allow-loopback-pinentry", N_("allow caller to override the pinentry")), ARGPARSE_s_n (oAllowEmacsPinentry, "allow-emacs-pinentry", /* */ N_("allow passphrase to be prompted through Emacs")), + ARGPARSE_s_n (oCancelCardPinentry, "cancel-card-pinentry", + /* */ N_("cancel pinentry display for card with mismatched S/N")), ARGPARSE_s_n (oSSHSupport, "enable-ssh-support", N_("enable ssh support")), ARGPARSE_s_n (oPuttySupport, "enable-putty-support", #ifdef HAVE_W32_SYSTEM /* */ N_("enable putty support") #else /* */ "@" #endif ), @@ -967,20 +970,24 @@ main (int argc, char **argv ) time_t faked_time = isotime2epoch (pargs.r.ret_str); if (faked_time == (time_t)(-1)) faked_time = (time_t)strtoul (pargs.r.ret_str, NULL, 10); gnupg_set_time (faked_time, 0); } break; case oKeepTTY: opt.keep_tty = 1; break; case oKeepDISPLAY: opt.keep_display = 1; break; + case oCancelCardPinentry: + opt.cancel_card_pinentry = 1; + break; + case oSSHSupport: ssh_support = 1; break; case oPuttySupport: # ifdef HAVE_W32_SYSTEM putty_support = 1; # endif break; case oExtraSocket: diff --git a/doc/gpg-agent.texi b/doc/gpg-agent.texi index f4da9cf..bb22464 100644 --- a/doc/gpg-agent.texi +++ b/doc/gpg-agent.texi @@ -497,20 +497,36 @@ pinentry to pop up at the @code{tty} or display you started the agent. @opindex extra-socket Also listen on native gpg-agent connections on the given socket. The intended use for this extra socket is to setup a Unix domain socket forwarding from a remote machine to this socket on the local machine. A @command{gpg} running on the remote machine may then connect to the local gpg-agent and use its private keys. This allows to decrypt or sign data on a remote machine without exposing the private keys to the remote machine. + at anchor{option --cancel-card-pinentry} + at item --cancel-card-pinentry + at opindex cancel-card-pinentry + +When the requested smartcard serial number does not match the inserted +card's serial number, automatically skip the card without prompting +the user. This skips the launching of pinetry and moves on, as if the +user had selected "cancel". + +This is convenient when decrypting a file encrypted for multiple +smartcard recipients, but only one smartcard is available. In this +case only one pinetry will be shown to the user (the one for the +inserted card), while the remaining pinetry prompts for unavailable +smartcards will be suppressed. + + @anchor{option --enable-ssh-support} @item --enable-ssh-support @itemx --enable-putty-support @opindex enable-ssh-support @opindex enable-putty-support Enable the OpenSSH Agent protocol. In this mode of operation, the agent does not only implement the gpg-agent protocol, but also the agent protocol used by OpenSSH diff --git a/tools/gpgconf-comp.c b/tools/gpgconf-comp.c index 45e5c90..441f46a 100644 --- a/tools/gpgconf-comp.c +++ b/tools/gpgconf-comp.c @@ -489,20 +489,23 @@ static gc_option_t gc_options_gpg_agent[] = { "Configuration", GC_OPT_FLAG_GROUP, GC_LEVEL_BASIC, "gnupg", N_("Options controlling the configuration") }, { "options", GC_OPT_FLAG_NONE, GC_LEVEL_EXPERT, "gnupg", "|FILE|read options from FILE", GC_ARG_TYPE_FILENAME, GC_BACKEND_GPG_AGENT }, { "disable-scdaemon", GC_OPT_FLAG_NONE, GC_LEVEL_ADVANCED, "gnupg", "do not use the SCdaemon", GC_ARG_TYPE_NONE, GC_BACKEND_GPG_AGENT }, + { "cancel-card-pinentry", GC_OPT_FLAG_NONE, GC_LEVEL_BASIC, + "gnupg", "cancel card pinentry on mismatched serial number", + GC_ARG_TYPE_NONE, GC_BACKEND_GPG_AGENT }, { "enable-ssh-support", GC_OPT_FLAG_NONE, GC_LEVEL_BASIC, "gnupg", "enable ssh support", GC_ARG_TYPE_NONE, GC_BACKEND_GPG_AGENT }, { "enable-putty-support", GC_OPT_FLAG_NONE, GC_LEVEL_BASIC, "gnupg", "enable putty support", GC_ARG_TYPE_NONE, GC_BACKEND_GPG_AGENT }, { "Debug", GC_OPT_FLAG_GROUP, GC_LEVEL_ADVANCED, "gnupg", N_("Options useful for debugging") }, -- 2.7.4 From neal at walfield.org Fri Dec 16 08:48:58 2016 From: neal at walfield.org (Neal H. Walfield) Date: Fri, 16 Dec 2016 08:48:58 +0100 Subject: [PATCH 1/1] gpg-agent: add new option --cancel-card-pinentry In-Reply-To: <1481853517-31171-2-git-send-email-curt@brune.net> References: <1481853517-31171-2-git-send-email-curt@brune.net> Message-ID: <87vauke2l1.wl-neal@walfield.org> Hi, On Fri, 16 Dec 2016 02:58:37 +0100, Curt Brune wrote: > This patch adds a new boolean global option to gpg-agent. > > The goal is to suppress unneeded pinentry prompting when the inserted > smartcard's serial number does not match the requested serial number. The idea is good, but I don't think the implementation is appropriate in general. Further, I don't like the option's name. Ideally, gpg would iterate over all of the PK-ESK blocks, determine whether the user could potentially decrypt them, and then rank them according to the expected ease with which the user could do that. One criteria would be the one that you suggested. That idea has been floated around in the past and will hopefully be implemented in 2.3. Thanks! :) Neal From wk at gnupg.org Fri Dec 16 18:27:01 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 16 Dec 2016 18:27:01 +0100 Subject: [PATCH 1/1] gpg-agent: add new option --cancel-card-pinentry In-Reply-To: <87vauke2l1.wl-neal@walfield.org> (Neal H. Walfield's message of "Fri, 16 Dec 2016 08:48:58 +0100") References: <1481853517-31171-2-git-send-email-curt@brune.net> <87vauke2l1.wl-neal@walfield.org> Message-ID: <874m234wey.fsf@wheatstone.g10code.de> On Fri, 16 Dec 2016 08:48, neal at walfield.org said: > would iterate over all of the PK-ESK blocks, determine whether the > user could potentially decrypt them, and then rank them according to > the expected ease with which the user could do that. One criteria Right, we have this comment in gpg: /* FIXME: Store this all in a list and process it later so that we can prioritize what key to use. This gives a better user experience if wildcard keyids are used. */ Curt: I would change the code to have such an option in gpg and not in gpg-agent. Thus the flag needs to be stored in the CTRL object which is initialized from a new Assuan OPTION (similar to pinentry-mode). The option name in gpg should also reflect what it is about and not how it technically works. Something with like --no-card-change-prompt. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From curt at brune.net Fri Dec 16 19:41:30 2016 From: curt at brune.net (Curt Brune) Date: Fri, 16 Dec 2016 10:41:30 -0800 Subject: [PATCH 1/1] gpg-agent: add new option --cancel-card-pinentry In-Reply-To: <874m234wey.fsf@wheatstone.g10code.de> References: <1481853517-31171-2-git-send-email-curt@brune.net> <87vauke2l1.wl-neal@walfield.org> <874m234wey.fsf@wheatstone.g10code.de> Message-ID: On Fri, Dec 16, 2016 at 9:27 AM, Werner Koch wrote: > On Fri, 16 Dec 2016 08:48, neal at walfield.org said: > > > would iterate over all of the PK-ESK blocks, determine whether the > > user could potentially decrypt them, and then rank them according to > > the expected ease with which the user could do that. One criteria > > Right, we have this comment in gpg: > > /* FIXME: Store this all in a list and process it later so that > we can prioritize what key to use. This gives a better user > experience if wildcard keyids are used. */ > > ?That is the problem exactly. I saw that gpg tried the keyids one by one...? > Curt: I would change the code to have such an option in gpg and not in > gpg-agent. Thus the flag needs to be stored in the CTRL object which is > initialized from a new Assuan OPTION (similar to pinentry-mode). > > ?Thanks for the suggestion. I will look into that. ? > The option name in gpg should also reflect what it is about and not how > it technically works. Something with like --no-card-change-prompt. > > ?Indeed, the option name is bad. I went through 3 or 4 different names, none of them very good.? The naming took the most time :) ?Cheers, Curt? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Fri Dec 16 22:19:51 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 16 Dec 2016 22:19:51 +0100 Subject: Farewell adns, welcome Libdns Message-ID: <87lgvf372g.fsf@wheatstone.g10code.de> Hi! We had several problems with the ADNS maintainer to get our SOCKS patches into upstream. This had the unfortunate effect that on Unix we had no Tor support in GnuPG (for keyservers etc.) but on Windows. That is because we could use our ADNS fork on Windows - which we originally forked to have suitable resolver on Windows w/o resorting to the Windows API. Clearly we want to have Tor support in Debian and thus we replaced ADNS by an even more complete resolver: Libdns [1]. William Ahern, the author, agreed to accept our patches. Even if he would not do, this is less of a problem, because Libdns are just two source files. Justus took the hard work of adding SOCKS support to Libdns and I just pushed the latest version to the repo. On Unix Tor support is now ready for testing; a little bit of work is left to do on Windows, though. Salam-Shalom, Werner [1] http://25thandClement.com/~william/projects/dns.c.html. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From rakuco at FreeBSD.org Sun Dec 18 11:41:33 2016 From: rakuco at FreeBSD.org (Raphael Kubo da Costa) Date: Sun, 18 Dec 2016 11:41:33 +0100 Subject: [PATCH pinentry] Qt: Make sure extended grep is used with '|'. Message-ID: <20161218104133.69732-1-rakuco@FreeBSD.org> * m4/qt.m4: Use grep -E when using the alternation character. -- POSIX specifies '|' is only supposed to work as an alternation special character when grep is used in extended mode. The code worked fine with GNU grep because it accepts extended regular expressions by default, but other POSIX-compliant implementations might fail and take it literally. Signed-off-by: Raphael Kubo da Costa --- m4/qt.m4 | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/m4/qt.m4 b/m4/qt.m4 index 90c4a6e..35d9ae2 100644 --- a/m4/qt.m4 +++ b/m4/qt.m4 @@ -60,18 +60,18 @@ AC_DEFUN([FIND_QT], AC_CHECK_TOOL(MOC, moc) AC_MSG_CHECKING([moc version]) mocversion=`$MOC -v 2>&1` - mocversiongrep=`echo $mocversion | grep "Qt 5\|moc 5"` + mocversiongrep=`echo $mocversion | grep -E "Qt 5|moc 5"` if test x"$mocversiongrep" != x"$mocversion"; then AC_MSG_RESULT([no]) # moc was not the qt5 one, try with moc-qt5 AC_CHECK_TOOL(MOC2, moc-qt5) mocversion=`$MOC2 -v 2>&1` - mocversiongrep=`echo $mocversion | grep "Qt 5\|moc-qt5 5\|moc 5"` + mocversiongrep=`echo $mocversion | grep -E "Qt 5|moc-qt5 5|moc 5"` if test x"$mocversiongrep" != x"$mocversion"; then AC_CHECK_TOOL(QTCHOOSER, qtchooser) qt5tooldir=`QT_SELECT=qt5 qtchooser -print-env | grep QTTOOLDIR | cut -d '=' -f 2 | cut -d \" -f 2` mocversion=`$qt5tooldir/moc -v 2>&1` - mocversiongrep=`echo $mocversion | grep "Qt 5\|moc 5"` + mocversiongrep=`echo $mocversion | grep -E "Qt 5|moc 5"` if test x"$mocversiongrep" != x"$mocversion"; then # no valid moc found have_qt5_libs="no"; -- 2.11.0 From felixc at felixcrux.com Mon Dec 19 01:07:44 2016 From: felixc at felixcrux.com (Felix Crux) Date: Sun, 18 Dec 2016 19:07:44 -0500 Subject: Signed DCO Message-ID: <20161219000744.GA2408@zond> GnuPG Developer's Certificate of Origin. Version 1.0 ===================================================== By making a contribution to the GnuPG project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the free software license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate free software license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same free software license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the free software license(s) involved. Signed-off-by: Felix Crux -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From felixc at felixcrux.com Mon Dec 19 01:11:04 2016 From: felixc at felixcrux.com (Felix Crux) Date: Sun, 18 Dec 2016 19:11:04 -0500 Subject: [PATCH] tty: Treat enter key as synonymous with OK. Message-ID: <20161219001104.GA16172@zond> * tty/pinentry-tty.c: Accept '\n' as equivalent to designated 'ok' key. -- This is a convenience that is analogous to the 'OK' button having keyboard focus by default in GUI versions of pinentry. Signed-off-by: Felix Crux --- tty/pinentry-tty.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tty/pinentry-tty.c b/tty/pinentry-tty.c index a509d79..a87a1eb 100644 --- a/tty/pinentry-tty.c +++ b/tty/pinentry-tty.c @@ -273,7 +273,7 @@ confirm (pinentry_t pinentry, FILE *ttyfi, FILE *ttyfo) ret = 0; break; } - else if (ok && input == ok) + else if (ok && (input == ok || input == '\n')) { ret = 1; break; -- 2.1.4 From gniibe at fsij.org Mon Dec 19 10:37:19 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 19 Dec 2016 18:37:19 +0900 Subject: scdaemon monitoring usb device removal Message-ID: Hello, In Debian, we have dirmngr-idling and gpg-agent-idling patches. Inspired by those patches, I'm considering possible changes to scdaemon, which also has "handle_tick" thing. Basically, scdaemon's handle_tick checks the removal of card or the removal of device periodically, by explicitly sending status request to USB device. I don't think we can remove handle_tick for all cases. The reasons are: We support Windows. We support access through PC/SC. We support card readers with no interrupt transfer support. Nevertheless, we don't need handle_tick, for following two cases. (1) With internal CCID driver, when it's USB token (like Yubikey, Nitrokey, and Gnuk Token), we can use select system call for detecting removal of device. (2) With internal CCID driver, when the card reader support interrupt transfer support for card change, we can check the USB endpoint for card removal. I am now testing the change of (1) on GNU/Linux. On GNU/Linux, the file descriptor for USB device can be used for removal of device. It returns POLLHUP for poll(2). In the libusb API 1.0, we have libusb_getpollfds function. Unfortunately, there is no access directly to get the file descriptor for specific device. Still, we can distinguish the file descriptor, by the returned pollfd structure with POLLOUT events (on GNU/Linux). I don't know if there is similar way for FreeBSD / macOS. And we use select(2) instead of poll(2) in scdaemon (through nPth library). Here we have an interface mismatch somehow. I checked that when select is called with read_fdset of the USB device descriptor, we can detect the removal of device. I'll post the change after the release of GnuPG 2.1.17. Please note that this is experimental change. Obvious drawback would be that the LED blinking of FST-01 will be changed. -- From aheinecke at intevation.de Mon Dec 19 10:39:28 2016 From: aheinecke at intevation.de (Andre Heinecke) Date: Mon, 19 Dec 2016 10:39:28 +0100 Subject: [PATCH pinentry] Qt: Make sure extended grep is used with '|'. In-Reply-To: <20161218104133.69732-1-rakuco@FreeBSD.org> References: <20161218104133.69732-1-rakuco@FreeBSD.org> Message-ID: <3507458.ADAzkLXFU9@esus> Hi, On Sunday 18 December 2016 11:41:33 Raphael Kubo da Costa wrote: > * m4/qt.m4: Use grep -E when using the alternation character. I've applied your patch both to pinentry and to gpgme where the same script is used. I see that poppler (where I originally copied the macro from) had a similar patch applied. Thanks! 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: 659 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Tue Dec 20 12:29:35 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Dec 2016 12:29:35 +0100 Subject: [Announce] GnuPG 2.1.17 released Message-ID: <87inqeyh28.fsf@wheatstone.g10code.de> Hello! Today marks the 19th anniversary of GnuPG and we are pleased to announce the availability of a new release: GnuPG 2.1.17. See below for a list of new features and bug fixes. About GnuPG ============= 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) comes with the latest features and is suggested for most users. This announcement is about this branch. - GnuPG "stable" (2.0) is the currently mostly used branch which will be maintain until 2017-12-31. - GnuPG "classic" (1.4) is a simplified version of GnuPG, required on very old platforms or to decrypt data created with PGP-2 keys. 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.17 ==================================== * gpg: By default new keys expire after 2 years. * gpg: New command --quick-set-expire to conveniently change the expiration date of keys. * gpg: Option and command names have been changed for easier comprehension. The old names are still available as aliases. * gpg: Improved the TOFU trust model. * gpg: New option --default-new-key-algo. * scd: Support OpenPGP card V3 for RSA. * dirmngr: Support for the ADNS library has been removed. Instead William Ahern's Libdns is now source included and used on all platforms. This enables Tor support on all platforms. The new option --standard-resolver can be used to disable this code at runtime. In case of build problems the new configure option --disable-libdns can be used to build without Libdns. * dirmngr: Lazily launch ldap reaper thread. * tools: New options --check and --status-fd for gpg-wks-client. * The UTF-8 byte order mark is now skipped when reading conf files. * Fixed many bugs and regressions. * Major improvements to the test suite. For example it is possible to run the external test suite of GPGME. A detailed description of the changes found in this 2.1 branch can be found at . Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.1.17 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.17.tar.bz2 (5830k) ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.17.tar.bz2.sig or here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.17.tar.bz2 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.17.tar.bz2.sig An installer for Windows without any graphical frontend except for a very minimal Pinentry tool is available here: ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.17_20161220.exe (3665k) ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.17_20161220.exe.sig or here https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.17_20161220.exe https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.17_20161220.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; it is still missing HKPS and Web Key Directory 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.17.tar.bz2 you would use this command: gpg --verify gnupg-2.1.17.tar.bz2.sig gnupg-2.1.17.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 the end of this mail 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.17.tar.bz2, you run the command like this: sha1sum gnupg-2.1.17.tar.bz2 and check that the output matches the next line: d83ab893faab35f37ace772ca29b939e6a5aa6a7 gnupg-2.1.17.tar.bz2 a95758912ed5354235ff9947a3c402108d5ec67e gnupg-w32-2.1.17_20161220.exe a358666de565a1f86ba9cd6bc8700a8224ea1078 gnupg-w32-2.1.17_20161220.tar.xz Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese, Czech, French, German, Japanese, Norwegian, Russian, and Ukrainian being almost completely translated. Due to expected changes in forthcoming releases some strings pertaining to the TOFU code are not yet translated. 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. The GnuPG project employs 3 full-time developers, one part-timer, and one contractor. They all work exclusivly on GnuPG and closely related software like Libgcrypt, GPGME, 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. The GnuPG hackers, Andre, dkg, gniibe, Justus, Neal, and Werner p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users'at'gnupg.org mailing list. p.p.s List of 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: 2020-10-30] 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. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From muelli at cryptobitch.de Tue Dec 20 17:48:53 2016 From: muelli at cryptobitch.de (Tobias Mueller) Date: Tue, 20 Dec 2016 17:48:53 +0100 Subject: [PATCH] python: Remove -builtin flag for SWIG bindings. In-Reply-To: <87mvg7ajxn.fsf@europa.jade-hamburg.de> References: <1480456267.7697.5.camel@cryptobitch.de> <87mvg7ajxn.fsf@europa.jade-hamburg.de> Message-ID: <20161220164853.GN4181@cryptobitch.de> Hi, On Wed, Dec 07, 2016 at 03:32:52PM +0100, Justus Winter wrote: > Tobias Mueller writes: > > The -builtin flag prevents that, though, because Python code > > will not be compiled. > > I don't quite understand. Python being compiled sounds at best > ambiguous. True. When run with -builtin, SWIG will not generate Python proxy classes: . It seems to especially not generate "additional pythoncode": That, however, can be useful to write parts of the wrapper in Python rather than C or SWIG. > Can you please provide an example of what this change will allow us to > do? Will send patches. > > The -py3 flag prevents the SWIG bindings to run under python2 > > when generated without the -builtin flag, because the py3 flag > > generates python3 code which is incompatible with python2. > > > > So we conditionally generate SWIG bindings with -py3. > > Indeed. That sounds like a good idea in general, independent from the > '-builtin' issue. It's not fully independent, because with -builtin, the py3 flag seems to be irrelevant. The library has been fully functional with python2, after all. It seems the py3 flag only influences the generated python code. With the -builtin flag, you don't seem to get any. That is, the generated gpg/gpgme.py file consists only of a few functions rather than proxy classes. $ git diff --stat /tmp/gpgme-with-builtin.py /tmp/gpgme-no-builtin.py .../{gpgme-with-builtin.py => gpgme-no-builtin.py} | 2894 +++++++++++++++++++- 1 file changed, 2893 insertions(+), 1 deletion(-) > > swige = Extension("gpg._gpgme", ["gpgme.i", "helpers.c"], > > - swig_opts = ['-py3', '-builtin', '-threads', > > - '-outdir', 'gpg'] + extra_swig_opts, > > + swig_opts = ['-threads', > > + '-outdir', 'gpg'] + py3 + extra_swig_opts, > > This basically reverts 856bcfe2934237011984fab0bc69800a7c25c34b. Silly > past-me did not write his reasons for doing that change in the > changelog, but I guess I merely wanted to reduce the amount of wrapping > being done here. Right. The SWIG documentation leaves the impression that -builtin is solely for increasing performance: New in SWIG version 2.0.4: The use of Python proxy classes has performance implications that may be unacceptable for a high-performance library. The new -builtin option instructs SWIG to forego the use of proxy classes, and instead create wrapped types as new built-in Python types. When this option is used, the following section ("Proxy classes") does not apply. Details on the use of the -builtin option are in the Built-in Types section. > But I'm not opposed to reverting this if it has the > benefits you mentioned. cool. Note that when the py3 flag kicks in, you also get interface definitions (which cause the python2 incompatibility) for the offered functions which people may appreciate for producing more type-safe code. > However, in that commit I also had to adapt another piece of code, and > you didn't revert that chunk. Could you please investigate this? > 856bcfe2934237011984fab0bc69800a7c25c34b changed a call to SWIG_NewPointerObj to a call to SWIG_Python_NewPointerObj. The latter seems to be more internal, e.g. it cannot be found in the documentation . It seems to be an implementation detail, because in the generated gpgme_wrap.c you can find this: #ifdef SWIGPYTHON_BUILTIN #define SWIG_NewPointerObj(ptr, type, flags) SWIG_Python_NewPointerObj(self, ptr, type, flags) #else #define SWIG_NewPointerObj(ptr, type, flags) SWIG_Python_NewPointerObj(NULL, ptr, type, flags) #endif So when compiling with -builtin, it expects "self" to be declared. Because "self" had not declared, compilation fails. That's probably why 856bcfe2934237011984fab0bc69800a7c25c34b changed the call. Now I see two options: Either leave the call as is or change it back to SWIG_NewPointerObj. Leaving it has the advantage of working regardless whether the builtin flag is set. Changing it has the advange of using a documented function rather than something that looks like a potentially fragile detail to me. When also definining a "self" variable before calling SWIG_NewPointerObj, both benefits should be preserved at the expense of somewhat obscure code with a stray self variable. I will send a proposal with changing it back. Cheers, Tobi From muelli at cryptobitch.de Tue Dec 20 18:00:36 2016 From: muelli at cryptobitch.de (Tobias Mueller) Date: Tue, 20 Dec 2016 18:00:36 +0100 Subject: [PATCH 1/4] python: Conditionally provide py3 argument to SWIG In-Reply-To: <20161220164853.GN4181@cryptobitch.de> References: <20161220164853.GN4181@cryptobitch.de> Message-ID: <1482253236.22871.3.camel@cryptobitch.de> * lang/python/setup.py.in: Only call with -py3 when we run under python3 or higher. -- If we ever remove the -builtin flag and leave the the -py3 flag, SWIG will generate Python code which will be incompatible with Python 2, because the py3 flag generates python3 code which is incompatible with python2. So we conditionally generate SWIG bindings with -py3. Signed-off-by: Tobias Mueller --- lang/python/setup.py.in | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/lang/python/setup.py.in b/lang/python/setup.py.in index 9669c28..c7f981a 100755 --- a/lang/python/setup.py.in +++ b/lang/python/setup.py.in @@ -152,9 +152,10 @@ class BuildExtFirstHack(build): self.run_command('build_ext') build.run(self) +py3 = [] if sys.version_info.major < 3 else ['-py3'] swige = Extension("gpg._gpgme", ["gpgme.i", "helpers.c"], - swig_opts = ['-py3', '-builtin', '-threads', - '-outdir', 'gpg'] + extra_swig_opts, + swig_opts = ['-threads', '-builtin', + '-outdir', 'gpg'] + py3 + extra_swig_opts, include_dirs = include_dirs, define_macros = define_macros, library_dirs = library_dirs, -- 2.7.4 From muelli at cryptobitch.de Tue Dec 20 18:01:27 2016 From: muelli at cryptobitch.de (Tobias Mueller) Date: Tue, 20 Dec 2016 18:01:27 +0100 Subject: [PATCH 2/4] python: Call SWIG_NewPointerObj rather than SWIG_Python_NewPointerObj. In-Reply-To: <20161220164853.GN4181@cryptobitch.de> References: <20161220164853.GN4181@cryptobitch.de> Message-ID: <1482253287.22871.4.camel@cryptobitch.de> * lang/python/gpgme.i (pygpgme_wrap_gpgme_data_t): Provide a "self" variable for SWIG_NewPointerObj and call SWIG_NewPointerObj rather than SWIG_Python_NewPointerObj. -- SWIG_Python_NewPointerObj seems to be an implementation detail, because SWIG's documentation does not mention that function at all. In fact, SWIG_NewPointerObj is a call to SWIG_Python_NewPointerObj with the first parameter being either NULL or the "self" variable, depending on whether SWIG is called with the -builtin flag. So far, the first parameter was hard-coded to NULL. This change also hard-codes it to NULL but makes it more explicit. The benefit is that the documented function is being used and that compilation works regardless of the -builtin flag. Partially reverts: 856bcfe2934237011984fab0bc69800a7c25c34b Signed-off-by: Tobias Mueller --- lang/python/gpgme.i | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/lang/python/gpgme.i b/lang/python/gpgme.i index 73533d0..70b87e6 100644 --- a/lang/python/gpgme.i +++ b/lang/python/gpgme.i @@ -611,7 +611,11 @@ FILE *fdopen(int fildes, const char *mode); PyObject * _gpg_wrap_gpgme_data_t(gpgme_data_t data) { - return SWIG_Python_NewPointerObj(NULL, data, SWIGTYPE_p_gpgme_data, 0); + /* SWIG_NewPointerObj may assume a "self" variable in case + the -builtin flag is used. + */ + PyObject* self = NULL; + return SWIG_NewPointerObj(data, SWIGTYPE_p_gpgme_data, 0); } gpgme_ctx_t -- 2.7.4 From muelli at cryptobitch.de Tue Dec 20 18:02:20 2016 From: muelli at cryptobitch.de (Tobias Mueller) Date: Tue, 20 Dec 2016 18:02:20 +0100 Subject: [PATCH 3/4] python: Remove the -builtin flag for SWIG. In-Reply-To: <20161220164853.GN4181@cryptobitch.de> References: <20161220164853.GN4181@cryptobitch.de> Message-ID: <1482253340.22871.5.camel@cryptobitch.de> * lang/python/setup.py.in: Call SWIG without the builtin flag. -- The SWIG documentation leaves the impression that -builtin is solely for increasing performance: New in SWIG version 2.0.4: The use of Python proxy classes has performance implications that may be unacceptable for a high- performance library. The new -builtin option instructs SWIG to forego the use of proxy classes, and instead create wrapped types as new built-in Python types. When this option is used, the following section ("Proxy classes") does not apply. Details on the use of the -builtin option are in the Built-in Types section. While not wasting CPU cycles is good, it also prevents Python code being written in the wrapper itself. That, however, may be useful to make it easier to extend the wrapper. Partially reverts: 856bcfe2934237011984fab0bc69800a7c25c34b Signed-off-by: Tobias Mueller --- lang/python/setup.py.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lang/python/setup.py.in b/lang/python/setup.py.in index c7f981a..5b5d5be 100755 --- a/lang/python/setup.py.in +++ b/lang/python/setup.py.in @@ -154,7 +154,7 @@ class BuildExtFirstHack(build): py3 = [] if sys.version_info.major < 3 else ['-py3'] swige = Extension("gpg._gpgme", ["gpgme.i", "helpers.c"], - swig_opts = ['-threads', '-builtin', + swig_opts = ['-threads', '-outdir', 'gpg'] + py3 + extra_swig_opts, include_dirs = include_dirs, define_macros = define_macros, -- 2.7.4 From muelli at cryptobitch.de Tue Dec 20 18:02:36 2016 From: muelli at cryptobitch.de (Tobias Mueller) Date: Tue, 20 Dec 2016 18:02:36 +0100 Subject: [PATCH 4/4] python: Extend SWIG gpgme_{sub,}key with a __repr__ method. In-Reply-To: <20161220164853.GN4181@cryptobitch.de> References: <20161220164853.GN4181@cryptobitch.de> Message-ID: <1482253356.22871.7.camel@cryptobitch.de> * lang/python/gpgme.i: Added a genericrepr macro and use it for gpgme_key, gpgme_subkey, and gpgme_key_sig. -- To look nicer in Python's REPL. We define a generic __repr__ as a SWIG macro and use that to extend some defined SWIG objects. The alternative would have been to write a custom __repr__ function for each class but that would need to be changed everytime the object's structure changes. The bindings should be easy to maintain, I guess. This comes at the expense that the reprs are now relatively long and contain, for example, both keyid and fingerprint. Signed-off-by: Tobias Mueller --- lang/python/gpgme.i | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/lang/python/gpgme.i b/lang/python/gpgme.i index 70b87e6..6337f7e 100644 --- a/lang/python/gpgme.i +++ b/lang/python/gpgme.i @@ -634,3 +634,30 @@ _gpg_unwrap_gpgme_ctx_t(PyObject *wrapped) /* ... but only the public definitions here. They will be exposed to the Python world, so let's be careful. */ %include "helpers.h" + + +%define genericrepr(cls) +%pythoncode %{ + def __repr__(self): + names = [name for name in dir(self) + if not name.startswith("_") and name != "this"] + props = ", ".join(("{}={!r}".format(name, getattr(self, name)) + for name in names) + ) + return "cls({})".format(props) +%} + +%enddef + +%extend _gpgme_key { + genericrepr(Key) +}; + + +%extend _gpgme_subkey { + genericrepr(SubKey) +}; + +%extend _gpgme_key_sig { + genericrepr(KeySig) +}; -- 2.7.4 From beebe at math.utah.edu Tue Dec 20 15:42:48 2016 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Tue, 20 Dec 2016 07:42:48 -0700 Subject: gnupg-2.1.17 feedback Message-ID: I have builds of gnupg-2.1.17 in progress on 125+ systems in our test lab, and am starting to look at logs. On FreeBSD 11, I noticed this output: skipping test: /bin/true not executable: No such file or directoryskipping test: /bin/false not executable: No such file or directoryPASS: t-exectool On that system, /bin/false does not exist; the utility is found in /usr/bin/false. I then ran a test on all our test lab systems, and found that /bin/false is missing on DragonFlyBSD, FreeBSD, GhostBSD, HardenedBSD, Mac OS X, MidnightBSD, Minix, one version of MirBSD, NetBSD, OpenBSD, PacBSD, PCBSD, and TrueOS. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From wk at gnupg.org Tue Dec 20 18:42:48 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Dec 2016 18:42:48 +0100 Subject: gnupg-2.1.17 feedback In-Reply-To: (Nelson H. F. Beebe's message of "Tue, 20 Dec 2016 07:42:48 -0700") References: Message-ID: <87zijqwl7r.fsf@wheatstone.g10code.de> On Tue, 20 Dec 2016 15:42, beebe at math.utah.edu said: > I then ran a test on all our test lab systems, and found that > /bin/false is missing on DragonFlyBSD, FreeBSD, GhostBSD, HardenedBSD, > Mac OS X, MidnightBSD, Minix, one version of MirBSD, NetBSD, OpenBSD, > PacBSD, PCBSD, and TrueOS. Thanks for reporting this. I just pushed a fix. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From wk at gnupg.org Tue Dec 20 23:26:11 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Dec 2016 23:26:11 +0100 Subject: gnupg-2.1.17 test segfaults on i686 In-Reply-To: <20161220204211.GA22326@fugu.vesath.org> (Gaetan Bisson's message of "Tue, 20 Dec 2016 10:42:11 -1000") References: <20161220204211.GA22326@fugu.vesath.org> Message-ID: <87eg12utj0.fsf@wheatstone.g10code.de> On Tue, 20 Dec 2016 21:42, bisson at archlinux.org said: > I'm getting the following error when running the gnupg-2.1.17 testsuite > on 32-bit Arch Linux platforms: I can replicate that on a 32 bit box. The bug is in our test script interpreter and thus is independant of the other gnupg code. Justus: We better add a 32 bit box to our Jenkins setup. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From bisson at archlinux.org Tue Dec 20 21:42:11 2016 From: bisson at archlinux.org (Gaetan Bisson) Date: Tue, 20 Dec 2016 10:42:11 -1000 Subject: gnupg-2.1.17 test segfaults on i686 Message-ID: <20161220204211.GA22326@fugu.vesath.org> Hi, I'm getting the following error when running the gnupg-2.1.17 testsuite on 32-bit Arch Linux platforms: Making check in tests make[1]: Entering directory '/build/src/gnupg-2.1.17/tests' Making check in gpgscm make[2]: Entering directory '/build/src/gnupg-2.1.17/tests/gpgscm' make check-local make[3]: Entering directory '/build/src/gnupg-2.1.17/tests/gpgscm' EXEEXT= GPGSCM_PATH=. \ ./gpgscm ./t-child.scm make[3]: *** [Makefile:838: check-local] Segmentation fault (core dumped) make[3]: Leaving directory '/build/src/gnupg-2.1.17/tests/gpgscm' make[2]: *** [Makefile:705: check-am] Error 2 make[2]: Leaving directory '/build/src/gnupg-2.1.17/tests/gpgscm' make[1]: *** [Makefile:532: check-recursive] Error 1 make[1]: Leaving directory '/build/src/gnupg-2.1.17/tests' make: *** [Makefile:581: check-recursive] Error 1 If I run the test manually and attach GDB to gpgscm I get: Starting program: /build/src/gnupg-2.1.17/tests/gpgscm/gpgscm ./t-child.scm Program received signal SIGSEGV, Segmentation fault. 0xb7d65446 in __strlen_sse2_bsf () from /usr/lib/libc.so.6 (gdb) bt #0 0xb7d65446 in __strlen_sse2_bsf () from /usr/lib/libc.so.6 #1 0x080589b0 in opexe_5 () #2 0x0805537f in Eval_Cycle () #3 0x0805567d in scheme_load_string () #4 0x08050909 in ffi_scheme_eval () #5 0x080509ba in ffi_init () #6 0x0804acee in main () Can I safely ignore this? :) -- Gaetan From bre at pagekite.net Wed Dec 21 12:13:01 2016 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Wed, 21 Dec 2016 11:13:01 -0000 Subject: Problems with pip install gpg Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello GnuPG! I'm very glad to hear that you've made Python a first-class citizen of the GPGME world. Unfortunately, pip install, doesn't appear to work: $ pip install gpg Downloading/unpacking gpg Downloading gpg-1.8.0.tar.gz Running setup.py (path:/tmp/pip-build-sz2de8/gpg/setup.py) egg_info for package gpg Need at least GPGME version 1.7, found 1.5.5. Complete output from command python setup.py egg_info: Need at least GPGME version 1.7, found 1.5.5. This is on Ubuntu 15.10. At the AME workshop last week I noticed others having similar difficulties on other distros. Everyone ended up using other Python libraries as a result. Generally, mature python libraries take care to either include logic to build their C dependencies as part of pip install, or the packager provides binaries (or both). Since the subset of Python devs that are also comfortable as C developers is relatively small, this is actually a nontrivial barrier to entry. I know that for my (Mailpile's) developer community, I can't really make GPGME a requirement until this is a bit easier - I'd lose all my contributors and testers! Thanks for your consideration, - Bjarni -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYWmOwAAoJEI4ANxYAz5SRPBYH/RfVU84HBrFSOwlOhWvsStCk q5tCJoBDIX54d2S94FZNqcnNrw/fHRePnOsYTnKVxOvbDMnyB1u4QDJnrp/d+8bO CJMyrGm0za6r7auHWbJxzLLSI7wINHwqYyDu62a4o/HoijOEhl65tjPHB11WakOa HK/oPINX5r+OJR/zAyh1IG0a8OJe5FqZ9RlTvTTE3nVIXXLHcQvx6TIlxUVxVX5C m4Niqg2hP/ZRahHBQpb2ghCoqZ7TXrKj4yxhY1xVKos5eW6lDUlovrxwJ7ytsk7F NJlFdwDhD+GdqyJYA57CgsxICDD5AzDyFuOTMgqk1I21aG7rdCe8JsCxV1KhOFM= =dByI -----END PGP SIGNATURE----- From kristian.fiskerstrand at sumptuouscapital.com Wed Dec 21 12:17:58 2016 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 21 Dec 2016 12:17:58 +0100 Subject: Problems with pip install gpg In-Reply-To: References: Message-ID: <5eab61a9-081a-ae76-76da-40b6ab3b255c@sumptuouscapital.com> On 12/21/2016 12:13 PM, Bjarni Runar Einarsson wrote: > Unfortunately, pip install, doesn't appear to work: Does the issue also happen using the distribution's package management system? global pip in stalls are generally a bad idea to begin with. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "At 18 our convictions are hills from which we look; At 45 they are caves in which we hide." (F. Scott Fitzgerald) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From bre at pagekite.net Wed Dec 21 12:28:51 2016 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Wed, 21 Dec 2016 11:28:51 -0000 Subject: Problems with pip install gpg In-Reply-To: <5eab61a9-081a-ae76-76da-40b6ab3b255c@sumptuouscapital.com> References: <5eab61a9-081a-ae76-76da-40b6ab3b255c@sumptuouscapital.com> Message-ID: <9JNPahd3skCTMXGmoEj7xQbGcSZhKy8IS6JI4a5Y2182@mailpile> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kristian Fiskerstrand wrote: > On 12/21/2016 12:13 PM, Bjarni Runar Einarsson wrote: > > Unfortunately, pip install, doesn't appear to work: > > Does the issue also happen using the distribution's package > management system? global pip in stalls are generally a bad > idea to begin with. That was in a virtualenv, not globally. Not that it matters... Generally "pip install" solves a different use-case from the distro package manager. The distro will certainly take care of making things work at their end; pip install is for developers or folks who need something that hasn't yet been packaged for their distro. But even if my distro provided a new enough python-gpg package, I'd still want pip install to work for folks on other platforms, such as OS X or even Windows. - Bjarni -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYWmeNAAoJEI4ANxYAz5SRMcEH/ifY72nXoClimUF6a1OUUvGo bNfFdmK49Ym1E7I+xgfJsL4u5ItdCg24Rd1Z5H4FI4hFpqYJ3YydEjF9fcfN95nI 2Mnd5HuCCPuBLOcLREeZ3zlDgz5/5S1jPs0JedS0197UzrE8QeaL6Wk5YMr8X7jR ylCIGTAItLkBDe13XNTU1ne5cRp4Kdh1vq0WqZeScniVLtPYZvHx8XSny/iw0qt+ yodu1ZxVJWJLejZbgCBsw/Oz9qTJW504L8Gt1PottUeb4u0GeQR3Y/8G8Yc2MiPE hyiWZUEedAO3u1Ywkt/zf7lni8Yg9n2AQal6hL/beCc6LTy0ErldJSHAGjguXZc= =Eqar -----END PGP SIGNATURE----- From ilf at zeromail.org Wed Dec 21 13:51:05 2016 From: ilf at zeromail.org (ilf) Date: Wed, 21 Dec 2016 13:51:05 +0100 Subject: Problems with pip install gpg In-Reply-To: References: Message-ID: <20161221125105.GS1072@zeromail.org> Bjarni Runar Einarsson: > This is on Ubuntu 15.10. Ubuntu 15.10 reached End of Life on July 28 2016: https://lists.ubuntu.com/archives/ubuntu-announce/2016-July/000208.html -- ilf ?ber 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes f?r Tastaturbenutzung -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From alec at alec.pl Wed Dec 21 14:37:26 2016 From: alec at alec.pl (A.L.E.C) Date: Wed, 21 Dec 2016 14:37:26 +0100 Subject: Problems with pip install gpg In-Reply-To: <20161221125105.GS1072@zeromail.org> References: <20161221125105.GS1072@zeromail.org> Message-ID: On 12/21/2016 01:51 PM, ilf wrote: > Bjarni Runar Einarsson: >> This is on Ubuntu 15.10. > > Ubuntu 15.10 reached End of Life on July 28 2016: > https://lists.ubuntu.com/archives/ubuntu-announce/2016-July/000208.html Actually there's no libgpgme 1.7.x in any of Ubuntu (official) releases. That's not the point, anyway. -- Aleksander 'A.L.E.C' Machniak Kolab Groupware Developer [http://kolab.org] Roundcube Webmail Developer [http://roundcube.net] ---------------------------------------------------- PGP: 19359DC1 # Blog: https://kolabian.wordpress.com From peter at digitalbrains.com Wed Dec 21 15:33:13 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 21 Dec 2016 15:33:13 +0100 Subject: Problems with pip install gpg In-Reply-To: References: <20161221125105.GS1072@zeromail.org> Message-ID: <9a605186-563a-9d61-c646-75b96ef8adcf@digitalbrains.com> On 21/12/16 14:37, A.L.E.C wrote: > That's not the point, anyway. Hmmmm, I disagree. We're talking about running security software; GnuPG is not an image editor ;-). You need an OS that still receives security updates for that. I think it's correct to point this out to the OP. My 2 cents, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From bre at pagekite.net Wed Dec 21 15:39:08 2016 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Wed, 21 Dec 2016 14:39:08 -0000 Subject: Problems with pip install gpg In-Reply-To: References: Message-ID: <2g8cyTTZMQjaVGdQCtgyXhdNsVXtLXL2TzJSP74m2182@mailpile> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Um, Please note that my original post pointed out multiple non-obsolete-distro use-cases and I also pointed out REAL WORLD DIFFICULTIES experienced by FRIENDLY DEVELOPERS who WANTED TO USE GPGME. Let's please not get derailed by the fact that my laptop is out of date. If gpgme wants to be used, eliminating barriers to entry is important work. We can of course also just choose to sit in an ivory tower sneering at everyone who isn't up-to-date enough... but that will have some pretty predictable consequences. :-) - Bjarni "A.L.E.C" wrote: > On 12/21/2016 01:51 PM, ilf wrote: > > Bjarni Runar Einarsson: > >> This is on Ubuntu 15.10. > > > > Ubuntu 15.10 reached End of Life on July 28 2016: > > https://lists.ubuntu.com/archives/ubuntu-announce/2016-July/000208.html > > Actually there's no libgpgme 1.7.x in any of Ubuntu (official) > releases. That's not the point, anyway. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYWpQZAAoJEI4ANxYAz5SRsFEIAJCkaUhvftiJxUJgdDPqocqT D3yUEOZFHr9XiJK/hQOQqsEyqhpxOWwCfLhu4BrxfBfrwlPdQEsZv3HqL+3x1PKu zo0x6gbZY2mMxn1UOYIsGda7nlqy+UwwrXttuxHlIbSlCGeEu8kg4+iPSbN776Ne aGEgy6uddA8vuWS5MvmLC/QgCzhZ/XBGtTQ2WtAkIPE+OgxvglPSi9Z3ddrm1qKA W2hD0fDfA/ieuT4vmxPS5wpF8aGPmAdlvEsS9IY33iOTVAMxpOn1OnkceLKFVBT9 R9ZyM6jw3VAYZrz7cuB4cJaqIEOQxF84i1IXBWSjhm5UV9S3aW1X+npmq+H9zPo= =MxWE -----END PGP SIGNATURE----- From wk at gnupg.org Wed Dec 21 17:02:20 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 21 Dec 2016 17:02:20 +0100 Subject: Problems with pip install gpg In-Reply-To: <2g8cyTTZMQjaVGdQCtgyXhdNsVXtLXL2TzJSP74m2182@mailpile> (Bjarni Runar Einarsson's message of "Wed, 21 Dec 2016 14:39:08 -0000") References: <2g8cyTTZMQjaVGdQCtgyXhdNsVXtLXL2TzJSP74m2182@mailpile> Message-ID: <87bmw5s22b.fsf@wheatstone.g10code.de> On Wed, 21 Dec 2016 15:39, bre at pagekite.net said: > If gpgme wants to be used, eliminating barriers to entry is > important work. We can of course also just choose to sit in an $ apt-cache rdepends libgpgme11 | grep '^ ' | wc -l 90 Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From bre at pagekite.net Wed Dec 21 17:18:57 2016 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Wed, 21 Dec 2016 16:18:57 -0000 Subject: Problems with pip install gpg In-Reply-To: <87bmw5s22b.fsf@wheatstone.g10code.de> References: <87bmw5s22b.fsf@wheatstone.g10code.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Werner Koch wrote: > On Wed, 21 Dec 2016 15:39, bre at pagekite.net said: > > > If gpgme wants to be used, eliminating barriers to entry is > > important work. We can of course also just choose to sit in an > > $ apt-cache rdepends libgpgme11 | grep '^ ' | wc -l > 90 $ apt-cache rdepends python-gpg |grep '^ ' |wc -l E: No packages found 0 If Python developers can't even begin development until the distros start shipping the latest and greatest, that number isn't likely to change any time soon. - Bjarni -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYWquPAAoJEI4ANxYAz5SRg3IH/jGQ1pbmBUi/LYvOj90nUDlA +sx8WmDtkAUeXKtX3W7atGu/TVwXufTd+JZQenBFmdGu7YjrcuVIp+7DUf5hThRm 1/l79lV84TOQBekMHetxkN4zY2bLw7rsy35X4liKI03NKGRj1+ZMUr5fAQkUTysn 8Ol9SCuwuUNGFDu/xhWm/COmY+4kqJ+pFUaXxFFYbXvbqoemt+Roqz0+jjpUYspv HNCLL62Q54qY8/0Co1TxmsJkpwMjG/K4NC5wUKbXaFAoLBLLLKP4gFl/u6lOJbP1 KH49eOf0/k6hljdK481TMHOFludXVVRPQOQb798KTKr+CndqhjRI3NlPVB7hsjs= =gEnG -----END PGP SIGNATURE----- From peter at digitalbrains.com Wed Dec 21 17:29:04 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 21 Dec 2016 17:29:04 +0100 Subject: (OT) Problems with pip install gpg In-Reply-To: <2g8cyTTZMQjaVGdQCtgyXhdNsVXtLXL2TzJSP74m2182@mailpile> References: <2g8cyTTZMQjaVGdQCtgyXhdNsVXtLXL2TzJSP74m2182@mailpile> Message-ID: <72e0af76-e4ca-090d-f031-d9f5d73e91ca@digitalbrains.com> On 21/12/16 15:39, Bjarni Runar Einarsson wrote: > [rant] I give this rant zero points for originality. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From wk at gnupg.org Wed Dec 21 19:25:59 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 21 Dec 2016 19:25:59 +0100 Subject: Problems with pip install gpg In-Reply-To: (Bjarni Runar Einarsson's message of "Wed, 21 Dec 2016 16:18:57 -0000") References: <87bmw5s22b.fsf@wheatstone.g10code.de> Message-ID: <87oa05qgug.fsf@wheatstone.g10code.de> On Wed, 21 Dec 2016 17:18, bre at pagekite.net said: > $ apt-cache rdepends python-gpg |grep '^ ' |wc -l > E: No packages found > 0 That is because Python folks tend to write their own binding. I have seen many of them - including Mailpile. I somewhat lost the context - what was your point? That the new gpgme python bindings are not yet in widespread use? You can't seriously claiming that given that we released them only 3 months ago. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From beebe at math.utah.edu Wed Dec 21 19:34:14 2016 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Wed, 21 Dec 2016 11:34:14 -0700 Subject: gnupg-2.1.17 feedback: list of successes Message-ID: I've now completed 155 build attempts for gnupg-2.1.17 in our test lab on 125+ flavors of Unix(-like) systems. All of those systems are kept up-to-date with vendor/distribution software updates, and they represent a broad swath of systems likely to be encountered at end-user sites around the planet. I can report successful validations and installations on these systems (all x86-64 CPUs): Debian 8 (testing) Debian 8 (unstable) DragonFlyBSD 4.4 DragonFlyBSD 4.6 DragonFlyBSD 4.6.1 Fedora Rawhide (bleeding edge) FreeBSD 11 FreeBSD 12 NetBSD 7.0 NetBSD 7.0.2 TrueOS (FreeBSD 12 relative) Ubuntu 16.10 Ubuntu rolling release (bleeding edge) That is a success rate of just 10%. I recorded two test failures on the systems where I installed gnupg-2.1.17: DragonFlyBSD 4.6: FAIL: gpgtar.scm NetBSD 7.0.2: FAIL: quick-key-manipulation.scm On the latest DragonFlyBSD 4.7, the build completed, but there were 52 FAIL reports, so I did not install it. It is disappointing to me that GnuPG 2.1.x development requires extremely recent versions of the assuan, gcrypt, gpg-error, ksba, and npth libraries. Even the current most-recent STABLE versions of CentOS, Debian, Fedora, Red Hat, DragonFlyBSD, OpenBSD, and Ubuntu do not have sufficiently new library versions from that list to allow gnupg-2.1.17 to be built on them, unless I go to the extra effort of attempting to install the latest versions of those libraries (which would mean more than 625 builds for my lab). I did, however, build and install npth-1.3 everywhere, replacing earlier 1.1 versions on the lab systems. That, at least, went smoothly, except that for most BSD-family systems, I had to manually restart the builds with make LIBS=-lpthread all check because the npth-1.3 configure script apparently did not figure out that -lpthread was needed on those systems. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From bre at pagekite.net Wed Dec 21 19:39:10 2016 From: bre at pagekite.net (=?UTF-8?Q?Bjarni_R=C3=BAnar_Einarsson?=) Date: Wed, 21 Dec 2016 18:39:10 +0000 Subject: Problems with pip install gpg In-Reply-To: <87oa05qgug.fsf@wheatstone.g10code.de> References: <87bmw5s22b.fsf@wheatstone.g10code.de> <87oa05qgug.fsf@wheatstone.g10code.de> Message-ID: My point was that if the bindings were more accessible to developers, developers would be more likely to use them. You guys are really close, but your pip package could use some work to that end. I don't understand why I'm getting pushback here. Neal and DKG both asked me to send this to the list so it wouldn't get forgotten. - Bjarni On 21 Dec 2016 19:32, "Werner Koch" wrote: > On Wed, 21 Dec 2016 17:18, bre at pagekite.net said: > > > $ apt-cache rdepends python-gpg |grep '^ ' |wc -l > > E: No packages found > > 0 > > That is because Python folks tend to write their own binding. I have > seen many of them - including Mailpile. > > I somewhat lost the context - what was your point? That the new gpgme > python bindings are not yet in widespread use? You can't seriously > claiming that given that we released them only 3 months ago. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From neal at walfield.org Wed Dec 21 20:54:47 2016 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 21 Dec 2016 20:54:47 +0100 Subject: Problems with pip install gpg In-Reply-To: <87oa05qgug.fsf@wheatstone.g10code.de> References: <87bmw5s22b.fsf@wheatstone.g10code.de> <87oa05qgug.fsf@wheatstone.g10code.de> Message-ID: <87d1glcb20.wl-neal@walfield.org> On Wed, 21 Dec 2016 19:25:59 +0100, Werner Koch wrote: > On Wed, 21 Dec 2016 17:18, bre at pagekite.net said: > > > $ apt-cache rdepends python-gpg |grep '^ ' |wc -l > > E: No packages found > > 0 > > That is because Python folks tend to write their own binding. I have > seen many of them - including Mailpile. > > I somewhat lost the context - what was your point? That the new gpgme > python bindings are not yet in widespread use? You can't seriously > claiming that given that we released them only 3 months ago. The problem, as I understand it, is that Python developers expect packages installed using pip to install their "strong" dependencies. In this case, that would be gpgme. Not being a Python developer, I can't comment on this. But if this is how the ecosystem works, then I think we ought to seriously take this into consideration. This is particularly the case if we want to encourage people to use our new bindings (and we did actively encourage Bjarni to transition to them and drop his own implementation). FWIW, in Justus' original announcement, he said: If you cannot wait until pyme3 is packaged by your distribution, and you do not want to build GPGME 1.7 from source merely to get pyme3, you can build it out-of-tree provided you have at least GPGME 1.6, the Python development packages, and SWIG. https://www.gnupg.org/blog/20160921-python-bindings-for-gpgme.html GPGME was released in August 2015. I suspect that all current distributions except Debian (which has 1.5) satisfy this requirement. 1.7, on the other hand, was released this past September. From neal at walfield.org Wed Dec 21 21:46:34 2016 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 21 Dec 2016 21:46:34 +0100 Subject: Problems with pip install gpg In-Reply-To: References: <87bmw5s22b.fsf@wheatstone.g10code.de> <87oa05qgug.fsf@wheatstone.g10code.de> Message-ID: <87tw9xau39.wl-neal@walfield.org> On Wed, 21 Dec 2016 19:39:10 +0100, Bjarni R?nar Einarsson wrote: > I don't understand why I'm getting pushback here. Neal and DKG both > asked me to send this to the list so it wouldn't get forgotten. I'm sorry if I somehow raised your expectations. I don't speak for anyone but me. I encouraged you to send it to the list, because, as you described the situation, it sounded like a real problem. Based on what I've read so far, it still sounds like a real problem. From peter at digitalbrains.com Wed Dec 21 22:44:23 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 21 Dec 2016 22:44:23 +0100 Subject: (OT) Problems with pip install gpg In-Reply-To: References: <87bmw5s22b.fsf@wheatstone.g10code.de> <87oa05qgug.fsf@wheatstone.g10code.de> Message-ID: <53f378e0-bbe7-e89e-ed06-d4c193d22d37@digitalbrains.com> On 21/12/16 19:39, Bjarni R?nar Einarsson wrote: > I don't understand why I'm getting pushback here. I'm sure things look different from different angles, but I only saw pushback /after/ your "ivory tower" post. Before that, I saw a reply by someone who couldn't help you with the problem you asked about, but did notice a different, real and existing security problem with your setup. I was completely surprised and irked by the reply you gave to that help, which contained SHOUTING and strong, generalizing accusations. Hence my sarcasm that followed. And here we now are, with nobody still talking about the original problem. Not a welcome outcome, but that's life. I suggest we all forget about this whole business and return to "pip install" and automatically fetching GPGME, which seems like a really good idea and the Right Thing To Do, if there aren't repercussions with multiple library versions on one system. Cheers, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From gniibe at fsij.org Thu Dec 22 05:55:09 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 22 Dec 2016 13:55:09 +0900 Subject: scdaemon monitoring usb device removal In-Reply-To: References: Message-ID: <878tr8tvf6.fsf@iwagami.gniibe.org> NIIBE Yutaka writes: > I'll post the change after the release of GnuPG 2.1.17. Please > note that this is experimental change. Here is the expelimenta change. It assumes that the card reader is always token. Writing this patch, I now consider that re-organizing the scdaemon would be better. Currently, gpg-agent assumes a single card and asks operations to scdaemon by serial number of the card (+ identifier/keyno like OPENPGP.1, OPENPGP.2, and OPENPGP.3). My current idea is that it's much simpler if we can use KEYGRIP here. Then, supporting multiple cards will be easier. diff --git a/scd/apdu.c b/scd/apdu.c index 225ceee..dc473ab 100644 --- a/scd/apdu.c +++ b/scd/apdu.c @@ -2597,7 +2597,7 @@ ccid_pinpad_operation (int slot, int class, int ins, int p0, int p1, /* Open the reader and try to read an ATR. */ static int -open_ccid_reader (const char *portstr) +open_ccid_reader (const char *portstr, void *arg) { int err; int slot; @@ -2608,7 +2608,7 @@ open_ccid_reader (const char *portstr) return -1; slotp = reader_table + slot; - err = ccid_open_reader (&slotp->ccid.handle, portstr, + err = ccid_open_reader (&slotp->ccid.handle, portstr, arg, (const char **)&slotp->rdrname); if (err) { @@ -2964,7 +2964,7 @@ open_rapdu_reader (int portno, error. If PORTSTR is NULL we default to a suitable port (for ctAPI: the first USB reader. For PC/SC the first listed reader). */ int -apdu_open_reader (const char *portstr) +apdu_open_reader (const char *portstr, void *arg) { static int pcsc_api_loaded, ct_api_loaded; int slot; @@ -2979,7 +2979,7 @@ apdu_open_reader (const char *portstr) int i; const char *s; - slot = open_ccid_reader (portstr); + slot = open_ccid_reader (portstr, arg); if (slot != -1) { once_available = 1; diff --git a/scd/apdu.h b/scd/apdu.h index c79b3fd..8970b32 100644 --- a/scd/apdu.h +++ b/scd/apdu.h @@ -85,7 +85,7 @@ enum { /* Note, that apdu_open_reader returns no status word but -1 on error. */ -int apdu_open_reader (const char *portstr); +int apdu_open_reader (const char *portstr, void *arg); int apdu_open_remote_reader (const char *portstr, const unsigned char *cookie, size_t length, int (*readfnc) (void *opaque, diff --git a/scd/ccid-driver.c b/scd/ccid-driver.c index 0917105..e22827e 100644 --- a/scd/ccid-driver.c +++ b/scd/ccid-driver.c @@ -89,6 +89,7 @@ #endif /*HAVE_NPTH*/ #include +#include #include "scdaemon.h" #include "iso7816.h" @@ -273,6 +274,7 @@ struct ccid_driver_s ccid_set_progress_cb. */ void (*progress_cb)(void *, const char *, int, int, int); void *progress_cb_arg; + void *upper_layer; }; @@ -1547,10 +1549,49 @@ ccid_vendor_specific_init (ccid_driver_t handle) } +static void +removal_cb (void *arg) +{ + ccid_driver_t handle = (ccid_driver_t)arg; + + scd_handle_reader_removal (handle->upper_layer); +} + +static void +manage_removal_of_device (ccid_driver_t handle, int is_token) +{ + const struct libusb_pollfd **pfd_array; + + DEBUGOUT_1 ("manage removal of device (%p)\n", handle); + + /* FIXME: it's good if there is an API of libusb to get + corresponding FD for the specific device. + This works for now with a single USB device. + For multiple devices support, fix is needed. + */ + pfd_array = libusb_get_pollfds (NULL); + if (pfd_array) + { + const struct libusb_pollfd **p = pfd_array; + do + { + DEBUGOUT_2 ("polling fd (%d): %08x\n", (*p)->fd, (*p)->events); + if (((*p)->events & POLLOUT)) + { + /* This is fd for the USB device. */ + scd_manage_device_removal_check ((*p)->fd, is_token, removal_cb, handle); + } + } + while (*++p); + + libusb_free_pollfds (pfd_array); + } +} + /* Open the reader with the internal number READERNO and return a pointer to be used as handle in HANDLE. Returns 0 on success. */ int -ccid_open_reader (ccid_driver_t *handle, const char *readerid, +ccid_open_reader (ccid_driver_t *handle, const char *readerid, void *arg, const char **rdrname_p) { int rc = 0; @@ -1622,6 +1663,8 @@ ccid_open_reader (ccid_driver_t *handle, const char *readerid, (*handle)->ep_bulk_out = ep_bulk_out; (*handle)->ep_bulk_in = ep_bulk_in; (*handle)->ep_intr = ep_intr; + (*handle)->upper_layer = arg; + manage_removal_of_device (*handle, 1); } else if (dev_fd != -1) /* Device transport. */ { @@ -3650,7 +3693,7 @@ main (int argc, char **argv) break; } - rc = ccid_open_reader (&ccid, argc? *argv:NULL, NULL); + rc = ccid_open_reader (&ccid, argc? *argv:NULL, NULL, NULL); if (rc) return 1; diff --git a/scd/ccid-driver.h b/scd/ccid-driver.h index e3aed9f..f7c46d0 100644 --- a/scd/ccid-driver.h +++ b/scd/ccid-driver.h @@ -111,7 +111,7 @@ typedef struct ccid_driver_s *ccid_driver_t; int ccid_set_debug_level (int level); char *ccid_get_reader_list (void); -int ccid_open_reader (ccid_driver_t *handle, const char *readerid, +int ccid_open_reader (ccid_driver_t *handle, const char *readerid, void *arg, const char **rdrname_p); int ccid_set_progress_cb (ccid_driver_t handle, void (*cb)(void *, const char *, int, int, int), diff --git a/scd/command.c b/scd/command.c index f6dfa39..d5598d4 100644 --- a/scd/command.c +++ b/scd/command.c @@ -395,7 +395,7 @@ get_current_reader (void) /* Try to open the reader. */ if (vr->slot == -1) { - vr->slot = apdu_open_reader (opt.reader_port); + vr->slot = apdu_open_reader (opt.reader_port, vr); /* If we still don't have a slot, we have no readers. Invalidate for now until a reader is attached. */ @@ -2338,3 +2338,16 @@ scd_update_reader_status_file (void) log_error ("failed to release status_file_update lock: %s\n", strerror (err)); } + + +void +scd_handle_reader_removal (void *arg) +{ + struct vreader_s *vr = arg; + int idx = vr - vreader_table; + + if (!vr->valid || vr->slot == -1) + return; + + update_card_removed (idx, 1); +} diff --git a/scd/scdaemon.c b/scd/scdaemon.c index 38e3c40..8deeb13 100644 --- a/scd/scdaemon.c +++ b/scd/scdaemon.c @@ -1175,6 +1175,87 @@ start_connection_thread (void *arg) return NULL; } +static fd_set fdset; +static int nfd; + +struct reader_list { + int fd; + int is_token; + callback cb; + void *arg; + struct reader_list *next; +}; +struct reader_list *reader_list; + + +/* Register/Unregister FD to monitor removal of token. */ +void +scd_manage_device_removal_check (int fd, int is_token, callback cb, void *arg) +{ + struct reader_list *l; + + l = xtrycalloc (1, sizeof *l); + if (!l) + { + log_error ("error allocating device monitor check: %s\n", + strerror (errno) ); + scd_exit (2); + } + + l->fd = fd; + l->is_token = is_token; + l->cb = cb; + l->arg = arg; + l->next = reader_list; + reader_list = l; + + FD_SET (fd, &fdset); + if (fd > nfd) + nfd = fd; +} + +static int +usb_token_registered (void) +{ + struct reader_list *l; + + if (reader_list == NULL) + return 0; + + for (l = reader_list; l; l = l->next) + if (!l->is_token) + return 0; + + return 1; +} + +static void +handle_device_removal (int fd) +{ + struct reader_list *l, *l_prev, *l_next; + + l_prev = NULL; + for (l = reader_list; l; l = l_next) + { + l_next = l->next; + + if (l->fd == fd) + { + l->cb (l->arg); + FD_CLR (fd, &fdset); + + if (l_prev) + l_prev->next = l_next; + else + reader_list = l_next; + xfree (l); + break; + } + else + l_prev = l; + } +} + /* Connection handler loop. Wait for connection requests and spawn a thread after accepting a connection. LISTEN_FD is allowed to be -1 @@ -1186,13 +1267,13 @@ handle_connections (int listen_fd) npth_attr_t tattr; struct sockaddr_un paddr; socklen_t plen; - fd_set fdset, read_fdset; + fd_set read_fdset; int ret; int fd; - int nfd; struct timespec abstime; struct timespec curtime; struct timespec timeout; + struct timespec *t; int saved_errno; #ifndef HAVE_W32_SYSTEM int signo; @@ -1241,29 +1322,35 @@ handle_connections (int listen_fd) listen_fd = -1; } - npth_clock_gettime (&curtime); - if (!(npth_timercmp (&curtime, &abstime, <))) - { - /* Timeout. */ - handle_tick (); - timeout.tv_sec = TIMERTICK_INTERVAL_SEC; - timeout.tv_nsec = TIMERTICK_INTERVAL_USEC * 1000; - npth_timeradd (&curtime, &timeout, &abstime); - } - npth_timersub (&abstime, &curtime, &timeout); + if (usb_token_registered ()) + t = NULL; + else + { + npth_clock_gettime (&curtime); + if (!(npth_timercmp (&curtime, &abstime, <))) + { + /* Timeout. */ + handle_tick (); + timeout.tv_sec = TIMERTICK_INTERVAL_SEC; + timeout.tv_nsec = TIMERTICK_INTERVAL_USEC * 1000; + npth_timeradd (&curtime, &timeout, &abstime); + } + npth_timersub (&abstime, &curtime, &timeout); + t = &timeout; + } /* POSIX says that fd_set should be implemented as a structure, thus a simple assignment is fine to copy the entire set. */ read_fdset = fdset; #ifndef HAVE_W32_SYSTEM - ret = npth_pselect (nfd+1, &read_fdset, NULL, NULL, &timeout, npth_sigev_sigmask()); + ret = npth_pselect (nfd+1, &read_fdset, NULL, NULL, t, npth_sigev_sigmask()); saved_errno = errno; while (npth_sigev_get_pending(&signo)) handle_signal (signo); #else - ret = npth_eselect (nfd+1, &read_fdset, NULL, NULL, &timeout, NULL, NULL); + ret = npth_eselect (nfd+1, &read_fdset, NULL, NULL, t, NULL, NULL); saved_errno = errno; #endif @@ -1314,7 +1401,18 @@ handle_connections (int listen_fd) npth_setname_np (thread, threadname); } fd = -1; - } + + ret--; + } + + if (ret) + { + int i; + + for (i = 0; i < FD_SETSIZE; i++) + if (FD_ISSET (i, &read_fdset)) + handle_device_removal (i); + } } cleanup (); diff --git a/scd/scdaemon.h b/scd/scdaemon.h index 38aa490..fd0b69f 100644 --- a/scd/scdaemon.h +++ b/scd/scdaemon.h @@ -112,6 +112,7 @@ struct server_control_s }; typedef struct app_ctx_s *app_t; +typedef void (*callback) (void *); /*-- scdaemon.c --*/ void scd_exit (int rc); @@ -124,6 +125,8 @@ void send_status_info (ctrl_t ctrl, const char *keyword, ...) GPGRT_ATTR_SENTINEL(1); void send_status_direct (ctrl_t ctrl, const char *keyword, const char *args); void scd_update_reader_status_file (void); +void scd_manage_device_removal_check (int fd, int is_token, callback cb, void *arg); +void scd_handle_reader_removal (void *arg); #endif /*SCDAEMON_H*/ -- From justus at g10code.com Thu Dec 22 11:20:51 2016 From: justus at g10code.com (Justus Winter) Date: Thu, 22 Dec 2016 11:20:51 +0100 Subject: gnupg-2.1.17 test segfaults on i686 In-Reply-To: <87eg12utj0.fsf@wheatstone.g10code.de> References: <20161220204211.GA22326@fugu.vesath.org> <87eg12utj0.fsf@wheatstone.g10code.de> Message-ID: <87d1gk6z98.fsf@europa.jade-hamburg.de> Werner Koch writes: > [ Unknown signature status ] > On Tue, 20 Dec 2016 21:42, bisson at archlinux.org said: > >> I'm getting the following error when running the gnupg-2.1.17 testsuite >> on 32-bit Arch Linux platforms: > > I can replicate that on a 32 bit box. The bug is in our test script > interpreter and thus is independant of the other gnupg code. Indeed :( I pushed a fix yesterday. Maybe we should do another release? > Justus: We better add a 32 bit box to our Jenkins setup. Yes. Cheers, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From wk at gnupg.org Thu Dec 22 11:38:17 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 22 Dec 2016 11:38:17 +0100 Subject: gnupg-2.1.17 test segfaults on i686 In-Reply-To: <87d1gk6z98.fsf@europa.jade-hamburg.de> (Justus Winter's message of "Thu, 22 Dec 2016 11:20:51 +0100") References: <20161220204211.GA22326@fugu.vesath.org> <87eg12utj0.fsf@wheatstone.g10code.de> <87d1gk6z98.fsf@europa.jade-hamburg.de> Message-ID: <8760mcqmee.fsf@wheatstone.g10code.de> On Thu, 22 Dec 2016 11:20, justus at g10code.com said: > Indeed :( I pushed a fix yesterday. Maybe we should do another release? We have a monthly release schedule but I can imagine to do a fresh release earlier in January. Can you please post the fix here? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From justus at g10code.com Thu Dec 22 11:46:39 2016 From: justus at g10code.com (Justus Winter) Date: Thu, 22 Dec 2016 11:46:39 +0100 Subject: [PATCH GnuPG] gpgscm: Guard use of union member. In-Reply-To: <8760mcqmee.fsf@wheatstone.g10code.de> References: <8760mcqmee.fsf@wheatstone.g10code.de> Message-ID: <20161222104639.23519-1-justus@g10code.com> * tests/gpgscm/scheme.c (opexe_5): Check that we have a file port before accessing filename. Fixes a crash on 32-bit architectures. Fixes-commit: e7429b1ced0c69fa7901f888f8dc25f00fc346a4 Signed-off-by: Justus Winter --- tests/gpgscm/scheme.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/gpgscm/scheme.c b/tests/gpgscm/scheme.c index a5b7691fb..284454557 100644 --- a/tests/gpgscm/scheme.c +++ b/tests/gpgscm/scheme.c @@ -4838,7 +4838,7 @@ static pointer opexe_5(scheme *sc, enum scheme_opcodes op) { } else { sc->nesting_stack[sc->file_i]++; #if USE_TAGS && SHOW_ERROR_LINE - { + if (sc->load_stack[sc->file_i].kind & port_file) { const char *filename = sc->load_stack[sc->file_i].rep.stdio.filename; int lineno = -- 2.11.0 From wk at gnupg.org Thu Dec 22 11:51:11 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 22 Dec 2016 11:51:11 +0100 Subject: gnupg-2.1.17 feedback: list of successes In-Reply-To: (Nelson H. F. Beebe's message of "Wed, 21 Dec 2016 11:34:14 -0700") References: Message-ID: <87tw9wp78g.fsf@wheatstone.g10code.de> On Wed, 21 Dec 2016 19:34, beebe at math.utah.edu said: > I've now completed 155 build attempts for gnupg-2.1.17 in our test lab > on 125+ flavors of Unix(-like) systems. All of those systems are kept Thanks for the work you are doing for better portability. > On the latest DragonFlyBSD 4.7, the build completed, but there were 52 > FAIL reports, so I did not install it. There is a bug in the test tools which seems to show uop only on 32 bit systems. Unfortunately we do not yet have a 32 bit platform in our jenkins. > It is disappointing to me that GnuPG 2.1.x development requires > extremely recent versions of the assuan, gcrypt, gpg-error, ksba, and > npth libraries. Even the current most-recent STABLE versions of We decided to do that because 2.1 was anyway a big cut and thus a good opportunity to get rid of old compatibility code. > because the npth-1.3 configure script apparently did not figure out > that -lpthread was needed on those systems. I created bug 2886 to track this. Regarding all these build failures: Might they be due to a C99 requirement we now have in dirmngr and wrong flags passed to allow C99 in cc? It is possible to disable the use of C99 with the --disable-libdns configure option. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From wk at gnupg.org Thu Dec 22 12:07:10 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 22 Dec 2016 12:07:10 +0100 Subject: Problems with pip install gpg In-Reply-To: ("Bjarni =?utf-8?Q?R=C3=BAnar?= Einarsson"'s message of "Wed, 21 Dec 2016 18:39:10 +0000") References: <87bmw5s22b.fsf@wheatstone.g10code.de> <87oa05qgug.fsf@wheatstone.g10code.de> Message-ID: <8760mcp6ht.fsf@wheatstone.g10code.de> On Wed, 21 Dec 2016 19:39, bre at pagekite.net said: > My point was that if the bindings were more accessible to developers, > developers would be more likely to use them. You guys are really > close, but What I don't understand is why a _developer_ has problems to do the usual ./configure && make followed by a make install as user with appropriate permissions. This used to be one of the first advanced things you learned as a sysadmin. I can't imagine that a Python developer is missing these basic abilities. And if it is about the time this takes: reading the manual and come up with an idea on how to use a library will for sure take more time. Or are we living in a copy+paste examples world now? But well, I as one of these gray haired Unix folks I have a hard time realizing that a shell is not anymore the basic interface for a hacker. (cf. today's ) Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From peter at digitalbrains.com Thu Dec 22 14:14:23 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 22 Dec 2016 14:14:23 +0100 Subject: Problems with pip install gpg In-Reply-To: <8760mcp6ht.fsf@wheatstone.g10code.de> References: <87bmw5s22b.fsf@wheatstone.g10code.de> <87oa05qgug.fsf@wheatstone.g10code.de> <8760mcp6ht.fsf@wheatstone.g10code.de> Message-ID: <292c9293-3237-c6a6-9610-288c8fa17568@digitalbrains.com> On 22/12/16 12:07, Werner Koch wrote: > What I don't understand is why a _developer_ has problems to do the > usual At the start of the topic, Bjarni wrote: > Generally, mature python libraries take care to either include > logic to build their C dependencies as part of pip install, or > the packager provides binaries (or both). If this is what a Python dev is accustomed to and expects, doesn't it make sense for the gpg module to do this as well? "pip" and a distro package manager solve similar problems (unfortunately also running into eachother that way). A distro package manager would download and install a library dependency as well, not error out to the user to compile a library from source. I presume the right thing for "pip" to do would be to use an already installed library if it can, or automatically install the needed version. The state of the computer at the end would be the same as when the user downloaded and compiled the library manually, only it was done for them automatically. My 2 cents, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From bre at pagekite.net Thu Dec 22 13:19:42 2016 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Thu, 22 Dec 2016 12:19:42 -0000 Subject: Problems with pip install gpg In-Reply-To: <8760mcp6ht.fsf@wheatstone.g10code.de> References: <8760mcp6ht.fsf@wheatstone.g10code.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Werner! Werner Koch wrote: > > What I don't understand is why a _developer_ has problems to do > the usual > > ./configure && make > > followed by a > > make install This is what "pip install" is for. It automates this process, so a Python developer doesn't also have to be a C developer. It (along with virtualenv) also handles scoping of the installed libraries, so developers don't have to install (potentially conflicting) development libraries system-wide. This involves setting a bunch of ./configure arguments (prefix etc.). Getting all of those things right, for multiple libraries, is a lot of boring, error-prone work. The Python community has decided to automate this so developers can focus on other things. It's a really nice system. > I can't imagine that a Python developer is missing these basic > abilities. Many are. It doesn't mean they're bad developers, it just means they've been able to specialize in other things because the sysadmin crap has been automated away. > And if it is about the time this takes: reading the > manual and come up with an idea on how to use a library will > for sure take more time. Or are we living in a copy+paste > examples world now? Please consider that the free software community is much larger and more diverse than it used to be. Nobody knows how to use all the tools anymore! I am guessing you would be annoyed if you were required to learn the entire javascript/nodejs toolchain in order to contribute a patch to your favourite C project. People who are hacking on GnuPG should know how to check out, build and configure GnuPG. In my opinion, people hacking on other things shouldn't have to. So if a developer wants to check out Mailpile, change the way e-mail addresses are formatted in the user interface and see it work, then requiring they know how to build and install GnuPG first is a major problem. It's out of scope for what they are trying to do and it's a major barrier to entry. If you think this is unreasonable, then we will just have to agree to disagree on that. The fact remains that I am not going to use GPGME if it means losing a large chunk of my contributors and testers. It's just not going to happen and I can guarantee that many other projects will come to the same conclusion. The GnuPG team has repeatedly asked me to use GPGME, and I know some of the people on your team are annoyed with me for not doing so. I am trying to explain why it's not happening. I would like to use GPGME instead of maintaining my own wrapper. But I can't - yet. I do hope this doesn't sound like I'm making demands. If you guys feel this is out of scope or don't have time, that is of course your call. I am simply pointing out areas for improvement and trying to explain my point of view and that of the Python community as I understand it. Thanks for reading, - Bjarni -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYW8TRAAoJEI4ANxYAz5SRctYH/19bSBtPkgaSROFe1oAMYjVH A8PnplMjET7q/4iC+Fpt5nqpJd2XagFQgvP6nFU3eezl+m7+5B2k2iIan3X1gyRz Ez9w1AaoqPmZwiB86dDoJn23ica7XOf57sKL4AnFI9NVDGe5bt2HGJppZU62ipFz M6Rz1Qf3mHRCI99kr2/depxg9RFjqDtuE3JmD6kM6MD0pvZa0Xm22/tguRwQ9g0Y 53VKLSitI+kq9YeuLJmeuIWTfjgcEL9ZyrkKiifcV2KMpXcaGoatufCcVYjkjNEz uqF9MxqYgqLD0wGXsDuv2eRQMBJtKMuKgJlUDwTFEVlwW9LIF6+5punf2Yar+bA= =amog -----END PGP SIGNATURE----- From wk at gnupg.org Thu Dec 22 15:27:14 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 22 Dec 2016 15:27:14 +0100 Subject: Problems with pip install gpg In-Reply-To: <292c9293-3237-c6a6-9610-288c8fa17568@digitalbrains.com> (Peter Lebbing's message of "Thu, 22 Dec 2016 14:14:23 +0100") References: <87bmw5s22b.fsf@wheatstone.g10code.de> <87oa05qgug.fsf@wheatstone.g10code.de> <8760mcp6ht.fsf@wheatstone.g10code.de> <292c9293-3237-c6a6-9610-288c8fa17568@digitalbrains.com> Message-ID: <87fulgninx.fsf@wheatstone.g10code.de> On Thu, 22 Dec 2016 14:14, peter at digitalbrains.com said: > If this is what a Python dev is accustomed to and expects, doesn't it > make sense for the gpg module to do this as well? Maybe it was wrong to do that PIP module at all. It was meant to help with faster migration to the new gpg module but it seems it has its own problems. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From wk at gnupg.org Thu Dec 22 15:41:38 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 22 Dec 2016 15:41:38 +0100 Subject: Problems with pip install gpg In-Reply-To: (Bjarni Runar Einarsson's message of "Thu, 22 Dec 2016 12:19:42 -0000") References: <8760mcp6ht.fsf@wheatstone.g10code.de> Message-ID: <87bmw4nhzx.fsf@wheatstone.g10code.de> On Thu, 22 Dec 2016 13:19, bre at pagekite.net said: > This is what "pip install" is for. It automates this process, so > a Python developer doesn't also have to be a C developer. Does not need to be a C hacker. The configure stuff even works for Python and is activly used for this (e.g. Mailman). > It (along with virtualenv) also handles scoping of the installed > libraries, so developers don't have to install (potentially > conflicting) development libraries system-wide. This involves That is what /usr/local is for and configure defaults to this. > Many are. It doesn't mean they're bad developers, it just means > they've been able to specialize in other things because the > sysadmin crap has been automated away. sysadmin crap ? Good that we are not close to the last Friday in July. > build and configure GnuPG. In my opinion, people hacking on other > things shouldn't have to. I expect any developer to be able to build and install software on his own Unix system. > So if a developer wants to check out Mailpile, change the way > e-mail addresses are formatted in the user interface and see it > work, then requiring they know how to build and install GnuPG Mailpile is writte in an interpreter langugae, right? Thus they can simply change the code and they are done. No need to install anything. > If you think this is unreasonable, then we will just have to > agree to disagree on that. Okay, let's disagree. > will come to the same conclusion. The GnuPG team has repeatedly > asked me to use GPGME, and I know some of the people on your team and assigned a developer to write the required changes. > are annoyed with me for not doing so. I am trying to explain why > it's not happening. I would like to use GPGME instead of > maintaining my own wrapper. But I can't - yet. Okay, it seems we should give up on helping Mailpile. Back then we considered it a good idea to help Mailpile to get into a usable state for everyone not just Python hacker. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From bisson at archlinux.org Thu Dec 22 19:16:07 2016 From: bisson at archlinux.org (Gaetan Bisson) Date: Thu, 22 Dec 2016 08:16:07 -1000 Subject: gnupg-2.1.17 test segfaults on i686 In-Reply-To: <8760mcqmee.fsf@wheatstone.g10code.de> References: <20161220204211.GA22326@fugu.vesath.org> <87eg12utj0.fsf@wheatstone.g10code.de> <87d1gk6z98.fsf@europa.jade-hamburg.de> <8760mcqmee.fsf@wheatstone.g10code.de> Message-ID: <20161222181607.GA1363@fugu.vesath.org> [2016-12-22 11:38:17 +0100] Werner Koch: > On Thu, 22 Dec 2016 11:20, justus at g10code.com said: > > > Indeed :( I pushed a fix yesterday. Maybe we should do another release? > > We have a monthly release schedule but I can imagine to do a fresh > release earlier in January. I'd like to mention another critical issue we're having with 2.1.17: https://bugs.gnupg.org/gnupg/issue2889 A new release which fixes this would be very much appreciated, though of course I could also backport the fix myself when it's available. Cheers. -- Gaetan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From goldim at gmail.com Thu Dec 22 23:46:28 2016 From: goldim at gmail.com (Leo Goldim) Date: Thu, 22 Dec 2016 20:46:28 -0200 Subject: Compiling libgpg-error for Android Message-ID: Hi all, I'm using ndk standalone toolchain to compile libgpg-error (to use for compile gpgme), I'm using libgpg-error version 1.26. My configure (./configure --prefix=/home/ec2-user/gpgme/libgpg-error-1.26-arm --host=arm-linux-android) runs ok, but I get the following error during make: cc -g -O0 -I. -I. -o mkheader ./mkheader.c if test -f lock-obj-pub.native.h; then rm lock-obj-pub.native.h; fi ./mkheader linux-android arm-unknown-linux-android ./gpg-error.h.in \ ../config.h 1.26 0x011a00 >gpg-error.h ./gpg-error.h.in:435: error including `./syscfg/lock-obj-pub.linux-android.h': No such file or directory make[2]: *** [gpg-error.h] Error 1 make[2]: Leaving directory `/home/ec2-user/gpgme/libgpg-error-1.26/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/ec2-user/gpgme/libgpg-error-1.26' make: *** [all] Error 2 Someone already did it? Or have any suggestions on how to compile gpgme for Android? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From bre at pagekite.net Fri Dec 23 00:58:19 2016 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Thu, 22 Dec 2016 23:58:19 -0000 Subject: Problems with pip install gpg In-Reply-To: <87fulgninx.fsf@wheatstone.g10code.de> References: <87fulgninx.fsf@wheatstone.g10code.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, The PIP module in its current form only helps people that already have a recent GPGME installed - but if they have a recent enough GPGME, they probably already got the Python module from the same place. I am going to take a look and see how hard it is to get the PIP module to build gpgme. Maybe I can finally contribute something back instead of just pointing out problems. :-P Take care, - Bjarni Werner Koch wrote: > On Thu, 22 Dec 2016 14:14, peter at digitalbrains.com said: > > > If this is what a Python dev is accustomed to and expects, doesn't it > > make sense for the gpg module to do this as well? > > Maybe it was wrong to do that PIP module at all. It was meant > to help with faster migration to the new gpg module but it > seems it has its own problems. > > > Shalom-Salam, > > Werner > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYXGiGAAoJEI4ANxYAz5SRa5YH/35GntOlNk7x6FqapF5xIEqN Cc1jTQe2mnYZiURsD7KEtl7od3zUIAFO0oQYfqUUU+usb+5Ce7qJhMjAMzmpkbKD 3aZN/NuC2tSKIzavK6D4EWvfEn5Lz6rWMSSojduou7tAJiXYRAjJMQpMUbV4dsy9 DvZxcHe+0asiJtsWlD5LjDGF72oFy8YZRFrrDBW6GOEYyAZB6JnbMnmwfM5zSd6p 8K2mS43k0MF80+omSwJHsfnNb6xneKwpCqpcaymiUWxn4PTFZ66YVqGTKkyexazx 3HWahKJF7i2nTV8IUp9FwP6QQA/CIlZtvQZS2zSWsP06CMmYkgXFVWzA/Y/G7cI= =XkqO -----END PGP SIGNATURE----- From bre at pagekite.net Fri Dec 23 00:58:19 2016 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Thu, 22 Dec 2016 23:58:19 -0000 Subject: Problems with pip install gpg In-Reply-To: <87fulgninx.fsf@wheatstone.g10code.de> References: <87fulgninx.fsf@wheatstone.g10code.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, The PIP module in its current form only helps people that already have a recent GPGME installed - but if they have a recent enough GPGME, they probably already got the Python module from the same place. I am going to take a look and see how hard it is to get the PIP module to build gpgme. Maybe I can finally contribute something back instead of just pointing out problems. :-P Take care, - Bjarni Werner Koch wrote: > On Thu, 22 Dec 2016 14:14, peter at digitalbrains.com said: > > > If this is what a Python dev is accustomed to and expects, doesn't it > > make sense for the gpg module to do this as well? > > Maybe it was wrong to do that PIP module at all. It was meant > to help with faster migration to the new gpg module but it > seems it has its own problems. > > > Shalom-Salam, > > Werner > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYXGiGAAoJEI4ANxYAz5SRa5YH/35GntOlNk7x6FqapF5xIEqN Cc1jTQe2mnYZiURsD7KEtl7od3zUIAFO0oQYfqUUU+usb+5Ce7qJhMjAMzmpkbKD 3aZN/NuC2tSKIzavK6D4EWvfEn5Lz6rWMSSojduou7tAJiXYRAjJMQpMUbV4dsy9 DvZxcHe+0asiJtsWlD5LjDGF72oFy8YZRFrrDBW6GOEYyAZB6JnbMnmwfM5zSd6p 8K2mS43k0MF80+omSwJHsfnNb6xneKwpCqpcaymiUWxn4PTFZ66YVqGTKkyexazx 3HWahKJF7i2nTV8IUp9FwP6QQA/CIlZtvQZS2zSWsP06CMmYkgXFVWzA/Y/G7cI= =XkqO -----END PGP SIGNATURE----- From bre at pagekite.net Fri Dec 23 09:52:15 2016 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Fri, 23 Dec 2016 08:52:15 -0000 Subject: OT: Helping Mailpile In-Reply-To: <87bmw4nhzx.fsf@wheatstone.g10code.de> References: <87bmw4nhzx.fsf@wheatstone.g10code.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Werner, Correcting some misunderstandings. Sorry. Werner Koch wrote: > > So if a developer wants to check out Mailpile, change the way > > e-mail addresses are formatted in the user interface and see it > > work, then requiring they know how to build and install GnuPG > > Mailpile is writte in an interpreter langugae, right? Thus they > can simply change the code and they are done. No need to > install anything. If they can't get Mailpile installed in the first place because of complex dependencies, then they'll never get that far. The fact that it is an interpreted language is irrelevant. > > will come to the same conclusion. The GnuPG team has repeatedly > > asked me to use GPGME, and I know some of the people on your team > > and assigned a developer to write the required changes. You did this without asking me whether I wanted it, or seeking my input on whether it was even a useful thing to do. You just threw code over the wall: a patch that broke basic things in the app, was unworkable for community reasons, and was also broken by undocumented upstream changes before I had a chance to review it. When I reached out to try and figure this out and give feedback on what my needs really are (basically the same needs as any Python app), your colleagues in Jabber heap me with abuse and your reaction here is: > Okay, it seems we should give up on helping Mailpile. Back then > we considered it a good idea to help Mailpile to get into a > usable state for everyone not just Python hacker. The priority inversion you've made there speaks volumes. You can't help Mailpile without helping Python hackers first. And why in the world would you want that? Mailpile may fail, but the Python community is vibrant and strong. Bet on them, not on me. Peace, - Bjarni -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYXOW3AAoJEI4ANxYAz5SRFE0H/07ro1Jqfxc068RfTaLJgL7w OmSiVNdnDBwejZof35mXIzUCZmr930ssEo3qqCpoE3pbabZLZtIvsY7dwUxOrwXA QmoLDbYt2P72iQQ8LccMclBwkxB7QwDAzwuUSbBNlpN2K+oFSH8KgCo86fq2j3w1 /KrQHUSow90XtXcKSk2poaCUb55ff3UGzmO5CO3s0FWaOgHLjSo1y4GqIeAh9+bV GT3L0cnAYl/81W/hisRz4sVi2usv+vuEWdCc25JnoPetp3m/QxeiUt6mCUTor1Pb +Acb68/M9svIGNBd5UCQJeeaMEdzEkDx2TPBBQZS1QqXn1Ttojd9iUyv9OIOprk= =N6zn -----END PGP SIGNATURE----- From bre at pagekite.net Fri Dec 23 09:52:15 2016 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Fri, 23 Dec 2016 08:52:15 -0000 Subject: OT: Helping Mailpile In-Reply-To: <87bmw4nhzx.fsf@wheatstone.g10code.de> References: <87bmw4nhzx.fsf@wheatstone.g10code.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Werner, Correcting some misunderstandings. Sorry. Werner Koch wrote: > > So if a developer wants to check out Mailpile, change the way > > e-mail addresses are formatted in the user interface and see it > > work, then requiring they know how to build and install GnuPG > > Mailpile is writte in an interpreter langugae, right? Thus they > can simply change the code and they are done. No need to > install anything. If they can't get Mailpile installed in the first place because of complex dependencies, then they'll never get that far. The fact that it is an interpreted language is irrelevant. > > will come to the same conclusion. The GnuPG team has repeatedly > > asked me to use GPGME, and I know some of the people on your team > > and assigned a developer to write the required changes. You did this without asking me whether I wanted it, or seeking my input on whether it was even a useful thing to do. You just threw code over the wall: a patch that broke basic things in the app, was unworkable for community reasons, and was also broken by undocumented upstream changes before I had a chance to review it. When I reached out to try and figure this out and give feedback on what my needs really are (basically the same needs as any Python app), your colleagues in Jabber heap me with abuse and your reaction here is: > Okay, it seems we should give up on helping Mailpile. Back then > we considered it a good idea to help Mailpile to get into a > usable state for everyone not just Python hacker. The priority inversion you've made there speaks volumes. You can't help Mailpile without helping Python hackers first. And why in the world would you want that? Mailpile may fail, but the Python community is vibrant and strong. Bet on them, not on me. Peace, - Bjarni -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYXOW3AAoJEI4ANxYAz5SRFE0H/07ro1Jqfxc068RfTaLJgL7w OmSiVNdnDBwejZof35mXIzUCZmr930ssEo3qqCpoE3pbabZLZtIvsY7dwUxOrwXA QmoLDbYt2P72iQQ8LccMclBwkxB7QwDAzwuUSbBNlpN2K+oFSH8KgCo86fq2j3w1 /KrQHUSow90XtXcKSk2poaCUb55ff3UGzmO5CO3s0FWaOgHLjSo1y4GqIeAh9+bV GT3L0cnAYl/81W/hisRz4sVi2usv+vuEWdCc25JnoPetp3m/QxeiUt6mCUTor1Pb +Acb68/M9svIGNBd5UCQJeeaMEdzEkDx2TPBBQZS1QqXn1Ttojd9iUyv9OIOprk= =N6zn -----END PGP SIGNATURE----- From findaphone40 at gmail.com Fri Dec 23 18:09:25 2016 From: findaphone40 at gmail.com (brian huffman) Date: Fri, 23 Dec 2016 11:09:25 -0600 Subject: Gnupg-devel Digest, Vol 159, Issue 22 In-Reply-To: References: Message-ID: If you only knew On Dec 22, 2016 8:33 AM, wrote: > Send Gnupg-devel mailing list submissions to > gnupg-devel at gnupg.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > or, via email, send a message with subject or body 'help' to > gnupg-devel-request at gnupg.org > > You can reach the person managing the list at > gnupg-devel-owner at gnupg.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Gnupg-devel digest..." > > Today's Topics: > > 1. Re: gnupg-2.1.17 test segfaults on i686 (Justus Winter) > 2. Re: gnupg-2.1.17 test segfaults on i686 (Werner Koch) > 3. [PATCH GnuPG] gpgscm: Guard use of union member. (Justus Winter) > 4. Re: gnupg-2.1.17 feedback: list of successes (Werner Koch) > 5. Re: Problems with pip install gpg (Werner Koch) > 6. Re: Problems with pip install gpg (Peter Lebbing) > 7. Re: Problems with pip install gpg (Bjarni Runar Einarsson) > 8. Re: Problems with pip install gpg (Werner Koch) > > > ---------- Forwarded message ---------- > From: Justus Winter > To: Werner Koch , Gaetan Bisson > Cc: gnupg-devel at gnupg.org > Date: Thu, 22 Dec 2016 11:20:51 +0100 > Subject: Re: gnupg-2.1.17 test segfaults on i686 > Werner Koch writes: > > > [ Unknown signature status ] > > On Tue, 20 Dec 2016 21:42, bisson at archlinux.org said: > > > >> I'm getting the following error when running the gnupg-2.1.17 testsuite > >> on 32-bit Arch Linux platforms: > > > > I can replicate that on a 32 bit box. The bug is in our test script > > interpreter and thus is independant of the other gnupg code. > > Indeed :( I pushed a fix yesterday. Maybe we should do another release? > > > Justus: We better add a 32 bit box to our Jenkins setup. > > Yes. > > > Cheers, > Justus > > > ---------- Forwarded message ---------- > From: Werner Koch > To: Justus Winter > Cc: Gaetan Bisson , gnupg-devel at gnupg.org > Date: Thu, 22 Dec 2016 11:38:17 +0100 > Subject: Re: gnupg-2.1.17 test segfaults on i686 > On Thu, 22 Dec 2016 11:20, justus at g10code.com said: > > > Indeed :( I pushed a fix yesterday. Maybe we should do another release? > > We have a monthly release schedule but I can imagine to do a fresh > release earlier in January. > > Can you please post the fix here? > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > > ---------- Forwarded message ---------- > From: Justus Winter > To: gnupg-devel at gnupg.org > Cc: > Date: Thu, 22 Dec 2016 11:46:39 +0100 > Subject: [PATCH GnuPG] gpgscm: Guard use of union member. > * tests/gpgscm/scheme.c (opexe_5): Check that we have a file port > before accessing filename. Fixes a crash on 32-bit architectures. > > Fixes-commit: e7429b1ced0c69fa7901f888f8dc25f00fc346a4 > Signed-off-by: Justus Winter > --- > tests/gpgscm/scheme.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tests/gpgscm/scheme.c b/tests/gpgscm/scheme.c > index a5b7691fb..284454557 100644 > --- a/tests/gpgscm/scheme.c > +++ b/tests/gpgscm/scheme.c > @@ -4838,7 +4838,7 @@ static pointer opexe_5(scheme *sc, enum > scheme_opcodes op) { > } else { > sc->nesting_stack[sc->file_i]++; > #if USE_TAGS && SHOW_ERROR_LINE > - { > + if (sc->load_stack[sc->file_i].kind & port_file) { > const char *filename = > sc->load_stack[sc->file_i].rep.stdio.filename; > int lineno = > -- > 2.11.0 > > > > > > ---------- Forwarded message ---------- > From: Werner Koch > To: "Nelson H. F. Beebe" > Cc: gnupg-devel at gnupg.org > Date: Thu, 22 Dec 2016 11:51:11 +0100 > Subject: Re: gnupg-2.1.17 feedback: list of successes > On Wed, 21 Dec 2016 19:34, beebe at math.utah.edu said: > > I've now completed 155 build attempts for gnupg-2.1.17 in our test lab > > on 125+ flavors of Unix(-like) systems. All of those systems are kept > > Thanks for the work you are doing for better portability. > > > On the latest DragonFlyBSD 4.7, the build completed, but there were 52 > > FAIL reports, so I did not install it. > > There is a bug in the test tools which seems to show uop only on 32 bit > systems. Unfortunately we do not yet have a 32 bit platform in our > jenkins. > > > It is disappointing to me that GnuPG 2.1.x development requires > > extremely recent versions of the assuan, gcrypt, gpg-error, ksba, and > > npth libraries. Even the current most-recent STABLE versions of > > We decided to do that because 2.1 was anyway a big cut and thus a good > opportunity to get rid of old compatibility code. > > > because the npth-1.3 configure script apparently did not figure out > > that -lpthread was needed on those systems. > > I created bug 2886 to track this. > > Regarding all these build failures: Might they be due to a C99 > requirement we now have in dirmngr and wrong flags passed to allow C99 > in cc? It is possible to disable the use of C99 with the > --disable-libdns configure option. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > > ---------- Forwarded message ---------- > From: Werner Koch > To: "Bjarni R?nar Einarsson" > Cc: GnuPG Development List > Date: Thu, 22 Dec 2016 12:07:10 +0100 > Subject: Re: Problems with pip install gpg > On Wed, 21 Dec 2016 19:39, bre at pagekite.net said: > > > My point was that if the bindings were more accessible to developers, > > developers would be more likely to use them. You guys are really > > close, but > > What I don't understand is why a _developer_ has problems to do the > usual > > ./configure && make > > followed by a > > make install > > as user with appropriate permissions. This used to be one of the first > advanced things you learned as a sysadmin. I can't imagine that a > Python developer is missing these basic abilities. And if it is about > the time this takes: reading the manual and come up with an idea on how > to use a library will for sure take more time. Or are we living in a > copy+paste examples world now? > > But well, I as one of these gray haired Unix folks I have a hard time > realizing that a shell is not anymore the basic interface for a > hacker. (cf. today's ) > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > > ---------- Forwarded message ---------- > From: Peter Lebbing > To: "Bjarni R?nar Einarsson" , GnuPG Development List < > gnupg-devel at gnupg.org> > Cc: > Date: Thu, 22 Dec 2016 14:14:23 +0100 > Subject: Re: Problems with pip install gpg > On 22/12/16 12:07, Werner Koch wrote: > > What I don't understand is why a _developer_ has problems to do the > > usual > > At the start of the topic, Bjarni wrote: > > > Generally, mature python libraries take care to either include > > logic to build their C dependencies as part of pip install, or > > the packager provides binaries (or both). > > If this is what a Python dev is accustomed to and expects, doesn't it > make sense for the gpg module to do this as well? > > "pip" and a distro package manager solve similar problems (unfortunately > also running into eachother that way). A distro package manager would > download and install a library dependency as well, not error out to the > user to compile a library from source. > > I presume the right thing for "pip" to do would be to use an already > installed library if it can, or automatically install the needed > version. The state of the computer at the end would be the same as when > the user downloaded and compiled the library manually, only it was done > for them automatically. > > My 2 cents, > > Peter. > > -- > I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. > You can send me encrypted mail if you want some privacy. > My key is available at > > > > > ---------- Forwarded message ---------- > From: Bjarni Runar Einarsson > To: Werner Koch > Cc: GnuPG Development List > Date: Thu, 22 Dec 2016 12:19:42 -0000 > Subject: Re: Problems with pip install gpg > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Werner! > > Werner Koch wrote: > > > > What I don't understand is why a _developer_ has problems to do > > the usual > > > > ./configure && make > > > > followed by a > > > > make install > > This is what "pip install" is for. It automates this process, so > a Python developer doesn't also have to be a C developer. > > It (along with virtualenv) also handles scoping of the installed > libraries, so developers don't have to install (potentially > conflicting) development libraries system-wide. This involves > setting a bunch of ./configure arguments (prefix etc.). Getting > all of those things right, for multiple libraries, is a lot of > boring, error-prone work. The Python community has decided to > automate this so developers can focus on other things. It's a > really nice system. > > > I can't imagine that a Python developer is missing these basic > > abilities. > > Many are. It doesn't mean they're bad developers, it just means > they've been able to specialize in other things because the > sysadmin crap has been automated away. > > > And if it is about the time this takes: reading the > > manual and come up with an idea on how to use a library will > > for sure take more time. Or are we living in a copy+paste > > examples world now? > > Please consider that the free software community is much larger > and more diverse than it used to be. Nobody knows how to use all > the tools anymore! I am guessing you would be annoyed if you were > required to learn the entire javascript/nodejs toolchain in order > to contribute a patch to your favourite C project. > > People who are hacking on GnuPG should know how to check out, > build and configure GnuPG. In my opinion, people hacking on other > things shouldn't have to. > > So if a developer wants to check out Mailpile, change the way > e-mail addresses are formatted in the user interface and see it > work, then requiring they know how to build and install GnuPG > first is a major problem. It's out of scope for what they are > trying to do and it's a major barrier to entry. > > If you think this is unreasonable, then we will just have to > agree to disagree on that. > > The fact remains that I am not going to use GPGME if it means > losing a large chunk of my contributors and testers. It's just > not going to happen and I can guarantee that many other projects > will come to the same conclusion. The GnuPG team has repeatedly > asked me to use GPGME, and I know some of the people on your team > are annoyed with me for not doing so. I am trying to explain why > it's not happening. I would like to use GPGME instead of > maintaining my own wrapper. But I can't - yet. > > I do hope this doesn't sound like I'm making demands. If you guys > feel this is out of scope or don't have time, that is of course > your call. I am simply pointing out areas for improvement and > trying to explain my point of view and that of the Python > community as I understand it. > > Thanks for reading, > - Bjarni > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJYW8TRAAoJEI4ANxYAz5SRctYH/19bSBtPkgaSROFe1oAMYjVH > A8PnplMjET7q/4iC+Fpt5nqpJd2XagFQgvP6nFU3eezl+m7+5B2k2iIan3X1gyRz > Ez9w1AaoqPmZwiB86dDoJn23ica7XOf57sKL4AnFI9NVDGe5bt2HGJppZU62ipFz > M6Rz1Qf3mHRCI99kr2/depxg9RFjqDtuE3JmD6kM6MD0pvZa0Xm22/tguRwQ9g0Y > 53VKLSitI+kq9YeuLJmeuIWTfjgcEL9ZyrkKiifcV2KMpXcaGoatufCcVYjkjNEz > uqF9MxqYgqLD0wGXsDuv2eRQMBJtKMuKgJlUDwTFEVlwW9LIF6+5punf2Yar+bA= > =amog > -----END PGP SIGNATURE----- > > > ---------- Forwarded message ---------- > From: Werner Koch > To: Peter Lebbing > Cc: "Bjarni R?nar Einarsson" , GnuPG Development List < > gnupg-devel at gnupg.org> > Date: Thu, 22 Dec 2016 15:27:14 +0100 > Subject: Re: Problems with pip install gpg > On Thu, 22 Dec 2016 14:14, peter at digitalbrains.com said: > > > If this is what a Python dev is accustomed to and expects, doesn't it > > make sense for the gpg module to do this as well? > > Maybe it was wrong to do that PIP module at all. It was meant to help > with faster migration to the new gpg module but it seems it has its own > problems. > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bre at pagekite.net Fri Dec 23 21:50:39 2016 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Fri, 23 Dec 2016 20:50:39 -0000 Subject: OT: Helping Mailpile In-Reply-To: References: Message-ID: <82E2mMyYDBIhJAQykWyhCuhogTeUqmC7ALxEPBnc2183@mailpile> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 For the rest of the list: We've taken this discussion off-list. And to be clear, I have no doubt the GnuPG were genuine in their desire to help. I wouldn't be here if I didn't think GnuPG was a fantastic project. Unfortunately, their offer came with some strings attached, some wrong assumptions were made on both sides and we've had a fair bit of friction of late as a result. Sorry for airing our dirty laundry, we're working it out. Cheers, - Bjarni -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYXY4ZAAoJEI4ANxYAz5SRIMMH/2S6VYuwIZLTVh6QcJpfJgym +YaoXeadUxDhyerLiv8xSbbPLoazoQizNEmQMcsnhGbkyzJZu3cvfP3fXsYoxOKL 2794UeS9DSawrTjXVzuw8V3TZtiEefFDDBiJj7ohnks7uM9ECn0rLNHMBwvt7Qt3 nv2g9rA6QshLlEph6vq1hIXSW92MQCg1MFpsM0ZgTs6fhQWXy4YyPttJsYF/pdvc Ik+ZOmdwCwrRWZbsPdYoCcP1ob5AYSEgpTV61G5Sf6/n+7qypOjD7cuRJPTBTphB pjrpPqEKTC6z8gLHDNE3B2aOnxbWGG1ulMqaJos4hV7X5MXXYnTi6ASvVb8KfqE= =+4Dv -----END PGP SIGNATURE----- From bre at pagekite.net Tue Dec 27 00:49:44 2016 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Mon, 26 Dec 2016 23:49:44 -0000 Subject: Problems with pip install gpg In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 An update: I have looked into this in more detail. It appears that this is not easily solvable due to the modularity of the GnuPG codebase; it's not really reasonable to ship all the GnuPG modules as part of the Python "source package" and I haven't found much precedent for Python modules actually downloading additional dependencies during their build phases. I thought they did (as stated in my original message), but it turns out all they download is the Python source package and other *Python* dependencies. External dependencies appear to be out of scope for the pip tool. I am going to ask around a bit more, but this is my current understanding. AFAICT, this leaves two options: 1) Publish static binaries. 2) Make the wrappers backwards compatible. Details on both options: Publishing static binaries (note: imprecise terminology, sorry) would involve changing the build process for the Python wrapper to directly link all the dependencies into the SWIG-generated shared object, and then publishing Python binary "wheels." This is probably a relatively straightforward change to the build process, but it implies the GnuPG team would start directly publishing binaries. I think this would be a significant departure from what the team has done until now, and would probably require some sort of build farm for the different distros. A bit much work? The other option, making the wrapper backwards compatible, so you can download the latest wrapper from pip, but build it against whatever older version of libgpgme your distribution is currently shipping, would elegantly solve the Linux use-case and let people start getting into the habit of using "pip install gpg" today. They wouldn't have access to all the features, but it could still be a significant step towards defragmenting the Python/GnuPG ecosystem. I don't know how much work this is, since the wrapper is auto-generated using SWIG and I'm not familiar with that tool. But I suspect this is the easier of the two options, if the GnuPG team wants to make their PIP package useful in the near future. Note that because of the lag time between when GnuPG upstream releases new things and the distributions catching up and publishing updates, I don't think this problem is going to go away unless a specific effort is made. Hope this helps, - Bjarni -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYYay2AAoJEI4ANxYAz5SRwkcH/3hucRPu4PPvzTYlRk+AqRP+ 452FyzjGQJY9YfMClLqQhSAFm8n0fAO1oQaDCZ5/NLxfphhR8M32dqxbCGmr3DJD YbTOjgTA1yFEflQzcEfoi7rd7g5aK1wBH3/mn5JfgFqMmlNQdlBZEFAw8fAyKjqv esWjeVlGazWLgJwKZxH2sMgjpdQMRL86U627gW71OdtqEUIkeKhjT1OBauKJmsja NRKoDLULKHKHbpZ6gqh+3sTD2f6yOfFX4QMQpZtpwwR9IkSpSoGVidg4lzM9dRa9 mqTAS1u0IZUovH0bYShYhBp3hxkEcXJD8UR6tNoHaaCVJZHJd+41SwwCO+B4NF0= =mLYk -----END PGP SIGNATURE----- From steven at stebalien.com Thu Dec 29 22:41:21 2016 From: steven at stebalien.com (Steven Allen) Date: Thu, 29 Dec 2016 13:41:21 -0800 Subject: use-tor should not imply allow-version-check Message-ID: <8760m24dmm.fsf@stebalien.com> For some reason, dirmngr's use-tor option implies allow-version-check. Looking through the commit message (see commit [1]) and the manual, I can't find any explanation for this. At a minimum, there should be a way to turn this off but really, unrelated options shouldn't depend on each other. Note: These update checks are *not* made over TOR. [1]: https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=bd91f92ace09263e3a91177f2a1644379baeb08a;hp=c45ca316a54665915ae08399484db271566db7c0 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From guilhem at fripost.org Fri Dec 30 00:11:01 2016 From: guilhem at fripost.org (Guilhem Moulin) Date: Fri, 30 Dec 2016 00:11:01 +0100 Subject: Automatically reorder OpenPGP packets upon --import and --recv-key Message-ID: <20161229231101.uqxobz6s4pwntmhn@localhost.localdomain> Hi there, Some keys are found on the keyserver network with non-self signatures incorrectly attached to a subkey instead of a UID (cf. Issue2236). Since 2.1.13 it's possible to reorder fix these keys by running the ?check? command of the gpg shell. However the procedure currently has to be repeated after refreshing the keyring, since each --refresh-keys command downloads the badly ordered key again. In msg8279 Werner wrote that ?We will eventually call that reorder function during import. But let's wait for bug reports with the --edit-key triggered code.? This code has been working fine for me since 2.1.13, so I was wondering if it could be activated for --import (and --recv-key) in 2.1.18? (So we get this in the next Debian stable :-) Moreover, as Neal pointed out to me privately, there is no overhead for keys that don't have incorrectly placed signature packets. Thanks! Cheers, -- Guilhem. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From gniibe at fsij.org Fri Dec 30 05:33:17 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 30 Dec 2016 13:33:17 +0900 Subject: scd: support of multiple card readers Message-ID: <87k2aiavea.fsf@iwagami.gniibe.org> Hello, Here is my experimental patch for support of multiple card readers. It support multiple card readers by internal CCID driver. PC/SC support is unchanged. Please note that this change is only the lower level things. Currently, only "learn --all --force" (adding new option --all) is supported by command level. To use effectively, we need to change the command sets of scdaemon so that it can work with multiple cards. Perhaps, specifying KEYGRIP for methods would be good. Or, adding KEYINFO command just like gpg-agent would be good. diff --git a/scd/apdu.c b/scd/apdu.c index d0b75c8..d9fde61 100644 --- a/scd/apdu.c +++ b/scd/apdu.c @@ -66,6 +66,13 @@ #define CCID_DRIVER_INCLUDE_USB_IDS 1 #include "ccid-driver.h" +struct dev_list { + struct ccid_dev_table *ccid_table; + const char *portstr; + int idx; + int idx_max; +}; + /* Due to conflicting use of threading libraries we usually can't link against libpcsclite if we are using Pth. Instead we use a wrapper program. Note that with nPth there is no need for a wrapper. */ @@ -428,7 +435,6 @@ new_reader_slot (void) { int i, reader = -1; - npth_mutex_lock (&reader_table_lock); for (i=0; i < MAX_READER; i++) if (!reader_table[i].used) { @@ -436,7 +442,6 @@ new_reader_slot (void) reader_table[reader].used = 1; break; } - npth_mutex_unlock (&reader_table_lock); if (reader == -1) { @@ -1428,8 +1433,6 @@ static int close_pcsc_reader_direct (int slot) { pcsc_release_context (reader_table[slot].pcsc.context); - xfree (reader_table[slot].rdrname); - reader_table[slot].rdrname = NULL; return 0; } #endif /*!NEED_PCSC_WRAPPER*/ @@ -2432,7 +2435,6 @@ static int close_ccid_reader (int slot) { ccid_close_reader (reader_table[slot].ccid.handle); - reader_table[slot].rdrname = NULL; return 0; } @@ -2566,7 +2568,7 @@ ccid_pinpad_operation (int slot, int class, int ins, int p0, int p1, /* Open the reader and try to read an ATR. */ static int -open_ccid_reader (const char *portstr) +open_ccid_reader (struct dev_list *dl) { int err; int slot; @@ -2577,8 +2579,8 @@ open_ccid_reader (const char *portstr) return -1; slotp = reader_table + slot; - err = ccid_open_reader (&slotp->ccid.handle, portstr, - (const char **)&slotp->rdrname); + err = ccid_open_reader (dl->portstr, dl->idx, dl->ccid_table, + &slotp->ccid.handle, &slotp->rdrname); if (err) { slotp->used = 0; @@ -2611,12 +2613,7 @@ open_ccid_reader (const char *portstr) unlock_slot (slot); return slot; } - - - #endif /* HAVE_LIBUSB */ - - #ifdef USE_G10CODE_RAPDU /* @@ -2919,63 +2916,80 @@ open_rapdu_reader (int portno, /* Driver Access */ +gpg_error_t +apdu_dev_list_start (const char *portstr, struct dev_list **l_p) +{ + gpg_error_t err; + struct dev_list *dl = xtrymalloc (sizeof (struct dev_list)); + *l_p = NULL; + if (!dl) + return gpg_error_from_syserror (); -/* Open the reader and return an internal slot number or -1 on - error. If PORTSTR is NULL we default to a suitable port (for ctAPI: - the first USB reader. For PC/SC the first listed reader). */ -int -apdu_open_reader (const char *portstr) -{ - static int pcsc_api_loaded, ct_api_loaded; - int slot; + dl->portstr = portstr; + dl->idx = 0; - if (DBG_READER) - log_debug ("enter: apdu_open_reader: portstr=%s\n", portstr); + npth_mutex_lock (&reader_table_lock); #ifdef HAVE_LIBUSB - if (!opt.disable_ccid) + if (opt.disable_ccid) { - static int once_available; - int i; - const char *s; - - slot = open_ccid_reader (portstr); - if (slot != -1) - { - once_available = 1; - if (DBG_READER) - log_debug ("leave: apdu_open_reader => slot=%d [ccid]\n", slot); - return slot; /* got one */ - } + dl->ccid_table = NULL; + dl->idx_max = 1; + } + else + { + err = ccid_dev_scan (&dl->idx_max, &dl->ccid_table); + if (err) + return err; - /* If we ever loaded successfully loaded a CCID reader we never - want to fallback to another driver. This solves a problem - where ccid was used, the card unplugged and then scdaemon - tries to find a new reader and will eventually try PC/SC over - and over again. To reset this flag "gpgconf --kill scdaemon" - can be used. */ - if (once_available) + if (dl->idx_max == 0) { - if (DBG_READER) - log_debug ("leave: apdu_open_reader => slot=-1 (once_avail)\n"); - return -1; - } - - /* If a CCID reader specification has been given, the user does - not want a fallback to other drivers. */ - if (portstr) - for (s=portstr, i=0; *s; s++) - if (*s == ':' && (++i == 3)) + /* If a CCID reader specification has been given, the user does + not want a fallback to other drivers. */ + if (portstr && strlen (portstr) > 5 && portstr[4] == ':') { if (DBG_READER) log_debug ("leave: apdu_open_reader => slot=-1 (no ccid)\n"); - return -1; + + xfree (dl); + npth_mutex_unlock (&reader_table_lock); + return gpg_error (GPG_ERR_ENODEV); } + else + dl->idx_max = 1; + } } - +#else + dl->ccid_table = NULL; + dl->idx_max = 1; #endif /* HAVE_LIBUSB */ + *l_p = dl; + return 0; +} + +void +apdu_dev_list_finish (struct dev_list *dl) +{ + ccid_dev_scan_finish (dl->ccid_table, dl->idx_max); + xfree (dl); + npth_mutex_unlock (&reader_table_lock); +} + + +/* Open the reader and return an internal slot number or -1 on + error. If PORTSTR is NULL we default to a suitable port (for ctAPI: + the first USB reader. For PC/SC the first listed reader). */ +static int +apdu_open_one_reader (const char *portstr) +{ + static int pcsc_api_loaded, ct_api_loaded; + int slot; + + if (DBG_READER) + log_debug ("enter: apdu_open_reader: portstr=%s\n", portstr); + if (opt.ctapi_driver && *opt.ctapi_driver) { int port = portstr? atoi (portstr) : 32768; @@ -3005,7 +3019,6 @@ apdu_open_reader (const char *portstr) return open_ct_reader (port); } - /* No ctAPI configured, so lets try the PC/SC API */ if (!pcsc_api_loaded) { @@ -3099,6 +3112,95 @@ apdu_open_reader (const char *portstr) return slot; } +int +apdu_open_reader (struct dev_list *dl) +{ + int slot; + + if (dl->ccid_table) + { /* CCID readers. */ + int readerno; + + /* See whether we want to use the reader ID string or a reader + number. A readerno of -1 indicates that the reader ID string is + to be used. */ + if (dl->portstr && strchr (dl->portstr, ':')) + readerno = -1; /* We want to use the readerid. */ + else if (dl->portstr) + { + readerno = atoi (dl->portstr); + if (readerno < 0) + { + return -1; + } + } + else + readerno = 0; /* Default. */ + + if (readerno > 0) + { /* Use single, the specific reader. */ + if (readerno >= dl->idx_max) + return -1; + + dl->idx = readerno; + dl->portstr = NULL; + slot = open_ccid_reader (dl); + dl->idx = dl->idx_max; + if (slot >= 0) + return slot; + else + return -1; + } + + while (dl->idx < dl->idx_max) + { + unsigned int bai = ccid_get_BAI (dl->idx, dl->ccid_table); + + if (DBG_READER) + log_debug ("apdu_open_reader: BAI=%x\n", bai); + + /* Check identity by BAI against already opened HANDLEs. */ + for (slot = 0; slot < MAX_READER; slot++) + if (reader_table[slot].used + && ccid_compare_BAI (reader_table[slot].ccid.handle, bai)) + break; + + if (slot == MAX_READER) + { /* Found a new device. */ + if (DBG_READER) + log_debug ("apdu_open_reader: new device=%x\n", bai); + + slot = open_ccid_reader (dl); + + dl->idx++; + if (slot >= 0) + return slot; + else + { + log_error ("ccid open error\n"); + return -1; + } + } + else + dl->idx++; + } + + slot = -1; + } + else + { /* PC/SC readers. */ + if (dl->idx++ == 0) + slot = apdu_open_one_reader (dl->portstr); + else + slot = -1; + } + + if (DBG_READER) + log_debug ("leave: apdu_open_reader => slot=%d [ccid]\n", slot); + + return slot; +} + /* Open an remote reader and return an internal slot number or -1 on error. This function is an alternative to apdu_open_reader and used @@ -3177,6 +3279,8 @@ apdu_close_reader (int slot) log_debug ("leave: apdu_close_reader => 0x%x (close_reader)\n", sw); return sw; } + xfree (reader_table[slot].rdrname); + reader_table[slot].rdrname = NULL; reader_table[slot].used = 0; if (DBG_READER) log_debug ("leave: apdu_close_reader => SW_HOST_NOT_SUPPORTED\n"); @@ -3204,6 +3308,8 @@ apdu_prepare_exit (void) apdu_disconnect (slot); if (reader_table[slot].close_reader) reader_table[slot].close_reader (slot); + xfree (reader_table[slot].rdrname); + reader_table[slot].rdrname = NULL; reader_table[slot].used = 0; } npth_mutex_unlock (&reader_table_lock); diff --git a/scd/apdu.h b/scd/apdu.h index 3021cf7..473def5 100644 --- a/scd/apdu.h +++ b/scd/apdu.h @@ -74,6 +74,7 @@ enum { SW_HOST_ALREADY_CONNECTED = 0x1000f }; +struct dev_list; #define SW_EXACT_LENGTH_P(a) (((a)&~0xff) == SW_EXACT_LENGTH) @@ -86,8 +87,11 @@ enum { gpg_error_t apdu_init (void); +gpg_error_t apdu_dev_list_start (const char *portstr, struct dev_list **l_p); +void apdu_dev_list_finish (struct dev_list *l); + /* Note, that apdu_open_reader returns no status word but -1 on error. */ -int apdu_open_reader (const char *portstr); +int apdu_open_reader (struct dev_list *l); int apdu_open_remote_reader (const char *portstr, const unsigned char *cookie, size_t length, int (*readfnc) (void *opaque, @@ -117,9 +121,9 @@ int apdu_reset (int slot); int apdu_get_status (int slot, int hang, unsigned int *status); int apdu_check_pinpad (int slot, int command, pininfo_t *pininfo); int apdu_pinpad_verify (int slot, int class, int ins, int p0, int p1, - pininfo_t *pininfo); + pininfo_t *pininfo); int apdu_pinpad_modify (int slot, int class, int ins, int p0, int p1, - pininfo_t *pininfo); + pininfo_t *pininfo); int apdu_send_simple (int slot, int extended_mode, int class, int ins, int p0, int p1, int lc, const char *data); diff --git a/scd/app-common.h b/scd/app-common.h index 781bf46..2371818 100644 --- a/scd/app-common.h +++ b/scd/app-common.h @@ -121,6 +121,9 @@ size_t app_help_read_length_of_cert (int slot, int fid, size_t *r_certoff); /*-- app.c --*/ +app_t app_list_start (void); +void app_list_finish (void); + void app_dump_state (void); void application_notify_card_reset (int slot); gpg_error_t check_application_conflict (const char *name, app_t app); diff --git a/scd/app.c b/scd/app.c index 39910d2..92d0783 100644 --- a/scd/app.c +++ b/scd/app.c @@ -319,22 +319,30 @@ app_new_register (int slot, ctrl_t ctrl, const char *name) gpg_error_t select_application (ctrl_t ctrl, const char *name, app_t *r_app, int scan) { - gpg_error_t err; + gpg_error_t err = 0; app_t app; - int slot; *r_app = NULL; - if (scan - /* FIXME: Here, we can change code to support multiple readers. - For now, we only open a single reader. - */ - && !app_top) + if (scan) { - slot = apdu_open_reader (opt.reader_port); - if (slot >= 0) + struct dev_list *l; + + err = apdu_dev_list_start (opt.reader_port, &l); + if (err) + return err; + + while (1) { - int sw = apdu_connect (slot); + int slot; + int sw; + + slot = apdu_open_reader (l); + if (slot < 0) + break; + + err = 0; + sw = apdu_connect (slot); if (sw == SW_HOST_CARD_INACTIVE) { @@ -346,23 +354,17 @@ select_application (ctrl_t ctrl, const char *name, app_t *r_app, int scan) err = 0; else err = gpg_error (GPG_ERR_ENODEV); + + if (!err) + err = app_new_register (slot, ctrl, name); + else + apdu_close_reader (slot); } - else - err = gpg_error (GPG_ERR_ENODEV); - if (!err) - err = app_new_register (slot, ctrl, name); - else - apdu_close_reader (slot); + apdu_dev_list_finish (l); } - else - err = 0; - - if (!err) - app = app_top; - else - app = NULL; + app = app_top; if (app) { lock_app (app, ctrl); @@ -550,8 +552,10 @@ app_write_learn_status (app_t app, ctrl_t ctrl, unsigned int flags) if (!app) return gpg_error (GPG_ERR_INV_VALUE); +#if 0 if (!app->ref_count) return gpg_error (GPG_ERR_CARD_NOT_INITIALIZED); +#endif if (!app->fnc.learn_status) return gpg_error (GPG_ERR_UNSUPPORTED_OPERATION); @@ -1069,3 +1073,16 @@ initialize_module_command (void) return apdu_init (); } + +app_t +app_list_start (void) +{ + npth_mutex_lock (&app_list_lock); + return app_top; +} + +void +app_list_finish (void) +{ + npth_mutex_unlock (&app_list_lock); +} diff --git a/scd/ccid-driver.c b/scd/ccid-driver.c index 6d81122..48dd887 100644 --- a/scd/ccid-driver.c +++ b/scd/ccid-driver.c @@ -239,12 +239,11 @@ static struct struct ccid_driver_s { libusb_device_handle *idev; - char *rid; int dev_fd; /* -1 for USB transport or file descriptor of the transport device. */ + unsigned int bai; unsigned short id_vendor; unsigned short id_product; - unsigned short bcd_device; int ifc_no; int ep_bulk_out; int ep_bulk_in; @@ -718,8 +717,6 @@ print_r2p_unknown (const unsigned char *msg, size_t msglen) static void prepare_special_transport (ccid_driver_t handle) { - assert (!handle->id_vendor); - handle->nonnull_nad = 0; handle->auto_ifsd = 0; handle->max_ifsd = 32; @@ -744,14 +741,13 @@ prepare_special_transport (ccid_driver_t handle) Note, that this code is based on the one in lsusb.c of the usb-utils package, I wrote on 2003-09-01. -wk. */ static int -parse_ccid_descriptor (ccid_driver_t handle, +parse_ccid_descriptor (ccid_driver_t handle, unsigned short bcd_device, const unsigned char *buf, size_t buflen) { unsigned int i; unsigned int us; int have_t1 = 0, have_tpdu=0; - handle->nonnull_nad = 0; handle->auto_ifsd = 0; handle->max_ifsd = 32; @@ -761,7 +757,7 @@ parse_ccid_descriptor (ccid_driver_t handle, handle->auto_param = 0; handle->auto_pps = 0; DEBUGOUT_3 ("idVendor: %04X idProduct: %04X bcdDevice: %04X\n", - handle->id_vendor, handle->id_product, handle->bcd_device); + handle->id_vendor, handle->id_product, bcd_device); if (buflen < 54 || buf[0] < 54) { DEBUGOUT ("CCID device descriptor is too short\n"); @@ -964,11 +960,11 @@ parse_ccid_descriptor (ccid_driver_t handle, */ if (handle->id_vendor == VENDOR_SCM && handle->max_ifsd > 48 - && ( (handle->id_product == SCM_SCR331 && handle->bcd_device < 0x0516) - ||(handle->id_product == SCM_SCR331DI && handle->bcd_device < 0x0620) - ||(handle->id_product == SCM_SCR335 && handle->bcd_device < 0x0514) - ||(handle->id_product == SCM_SPR532 && handle->bcd_device < 0x0504) - ||(handle->id_product == SCM_SCR3320 && handle->bcd_device < 0x0522) + && ( (handle->id_product == SCM_SCR331 && bcd_device < 0x0516) + ||(handle->id_product == SCM_SCR331DI && bcd_device < 0x0620) + ||(handle->id_product == SCM_SCR335 && bcd_device < 0x0514) + ||(handle->id_product == SCM_SPR532 && bcd_device < 0x0504) + ||(handle->id_product == SCM_SCR3320 && bcd_device < 0x0522) )) { DEBUGOUT ("enabling workaround for buggy SCM readers\n"); @@ -1534,23 +1530,33 @@ ccid_vendor_specific_init (ccid_driver_t handle) } -/* Open the reader with the internal number READERNO and return a - pointer to be used as handle in HANDLE. Returns 0 on success. */ -int -ccid_open_reader (ccid_driver_t *handle, const char *readerid, - const char **rdrname_p) -{ - int rc = 0; - libusb_device_handle *idev = NULL; - int dev_fd = -1; - char *rid = NULL; - unsigned char *ifcdesc_extra = NULL; +#define MAX_DEVICE 4 /* See MAX_READER in apdu.c. */ + +struct ccid_dev_table { + int n; /* Index to ccid_usb_dev_list */ + int transport; + int interface_number; + int setting_number; + unsigned char *ifcdesc_extra; + int ep_bulk_out; + int ep_bulk_in; + int ep_intr; size_t ifcdesc_extra_len; - int readerno; - int ifc_no, set_no, ep_bulk_out, ep_bulk_in, ep_intr; - struct libusb_device_descriptor desc; +}; - *handle = NULL; +static libusb_device **ccid_usb_dev_list; +static struct ccid_dev_table ccid_dev_table[MAX_DEVICE]; + +gpg_error_t +ccid_dev_scan (int *idx_max_p, struct ccid_dev_table **t_p) +{ + ssize_t n; + libusb_device *dev; + int i; + int ifc_no; + int set_no; + int idx = 0; + int err = 0; if (!initialized_usb) { @@ -1558,122 +1564,379 @@ ccid_open_reader (ccid_driver_t *handle, const char *readerid, initialized_usb = 1; } - /* See whether we want to use the reader ID string or a reader - number. A readerno of -1 indicates that the reader ID string is - to be used. */ - if (readerid && strchr (readerid, ':')) - readerno = -1; /* We want to use the readerid. */ - else if (readerid) + n = libusb_get_device_list (NULL, &ccid_usb_dev_list); + for (i = 0; i < n; i++) + { + struct libusb_config_descriptor *config; + struct libusb_device_descriptor desc; + + dev = ccid_usb_dev_list[i]; + + if (libusb_get_device_descriptor (dev, &desc)) + continue; + + if (libusb_get_active_config_descriptor (dev, &config)) + continue; + + for (ifc_no=0; ifc_no < config->bNumInterfaces; ifc_no++) + for (set_no=0; set_no < config->interface[ifc_no].num_altsetting; + set_no++) + { + const struct libusb_interface_descriptor *ifcdesc; + + ifcdesc = &config->interface[ifc_no].altsetting[set_no]; + /* The second condition is for older SCM SPR 532 who did + not know about the assigned CCID class. The third + condition does the same for a Cherry SmartTerminal + ST-2000. Instead of trying to interpret the strings + we simply check the product ID. */ + if (ifcdesc && ifcdesc->extra + && ((ifcdesc->bInterfaceClass == 11 + && ifcdesc->bInterfaceSubClass == 0 + && ifcdesc->bInterfaceProtocol == 0) + || (ifcdesc->bInterfaceClass == 255 + && desc.idVendor == VENDOR_SCM + && desc.idProduct == SCM_SPR532) + || (ifcdesc->bInterfaceClass == 255 + && desc.idVendor == VENDOR_CHERRY + && desc.idProduct == CHERRY_ST2000))) + { + /* Found a reader. */ + unsigned char *ifcdesc_extra; + + ifcdesc_extra = malloc (ifcdesc->extra_length); + if (!ifcdesc_extra) + { + err = gpg_error_from_syserror (); + libusb_free_config_descriptor (config); + goto scan_finish; + } + memcpy (ifcdesc_extra, ifcdesc->extra, ifcdesc->extra_length); + + ccid_dev_table[idx].transport = TRANSPORT_USB; + ccid_dev_table[idx].n = i; + ccid_dev_table[idx].interface_number = ifc_no; + ccid_dev_table[idx].setting_number = set_no; + ccid_dev_table[idx].ifcdesc_extra = ifcdesc_extra; + ccid_dev_table[idx].ifcdesc_extra_len = ifcdesc->extra_length; + ccid_dev_table[idx].ep_bulk_out = find_endpoint (ifcdesc, 0); + ccid_dev_table[idx].ep_bulk_in = find_endpoint (ifcdesc, 1); + ccid_dev_table[idx].ep_intr = find_endpoint (ifcdesc, 2); + + idx++; + if (idx >= MAX_DEVICE) + { + libusb_free_config_descriptor (config); + err = 0; + goto scan_finish; + } + } + } + + libusb_free_config_descriptor (config); + } + + /* Now check whether there are any devices with special transport types. */ + for (i=0; transports[i].name; i++) { - readerno = atoi (readerid); - if (readerno < 0) + if (access (transports[i].name, (R_OK|W_OK)) == 0) { - DEBUGOUT ("no CCID readers found\n"); - rc = CCID_DRIVER_ERR_NO_READER; - goto leave; + /* Found a device. */ + DEBUGOUT_1 ("Found CCID reader %d\n", idx); + + ccid_dev_table[idx].transport = TRANSPORT_CM4040; + ccid_dev_table[idx].n = i; + ccid_dev_table[idx].interface_number = 0; + ccid_dev_table[idx].setting_number = 0; + ccid_dev_table[idx].ifcdesc_extra = NULL; + ccid_dev_table[idx].ifcdesc_extra_len = 0; + ccid_dev_table[idx].ep_bulk_out = 0; + ccid_dev_table[idx].ep_bulk_in = 0; + ccid_dev_table[idx].ep_intr = 0; + + idx++; + if (idx >= MAX_DEVICE) + goto scan_finish; } } - else - readerno = 0; /* Default. */ - if (scan_or_find_devices (readerno, readerid, &rid, &desc, &ifcdesc_extra, - &ifcdesc_extra_len, &ifc_no, &set_no, &ep_bulk_out, - &ep_bulk_in, &ep_intr, &idev, &dev_fd)) + scan_finish: + + if (err) { - if (readerno == -1) - DEBUGOUT_1 ("no CCID reader with ID %s\n", readerid ); + *idx_max_p = 0; + *t_p = NULL; + for (i = 0; i < idx; i++) + { + free (ccid_dev_table[idx].ifcdesc_extra); + ccid_dev_table[idx].transport = 0; + ccid_dev_table[idx].n = 0; + ccid_dev_table[idx].interface_number = 0; + ccid_dev_table[idx].setting_number = 0; + ccid_dev_table[idx].ifcdesc_extra = NULL; + ccid_dev_table[idx].ifcdesc_extra_len = 0; + ccid_dev_table[idx].ep_bulk_out = 0; + ccid_dev_table[idx].ep_bulk_in = 0; + ccid_dev_table[idx].ep_intr = 0; + } + libusb_free_device_list (ccid_usb_dev_list, 1); + ccid_usb_dev_list = NULL; + } + else + { + *idx_max_p = idx; + if (idx) + *t_p = ccid_dev_table; else - DEBUGOUT_1 ("no CCID reader with number %d\n", readerno ); - rc = CCID_DRIVER_ERR_NO_READER; - goto leave; + *t_p = NULL; } - /* Okay, this is a CCID reader. */ - *handle = calloc (1, sizeof **handle); - if (!*handle) + return err; +} + +void +ccid_dev_scan_finish (struct ccid_dev_table *tbl, int max) +{ + int i; + + for (i = 0; i < max; i++) { - DEBUGOUT ("out of memory\n"); - rc = CCID_DRIVER_ERR_OUT_OF_CORE; - goto leave; + free (tbl[i].ifcdesc_extra); + tbl[i].transport = 0; + tbl[i].n = 0; + tbl[i].interface_number = 0; + tbl[i].setting_number = 0; + tbl[i].ifcdesc_extra = NULL; + tbl[i].ifcdesc_extra_len = 0; + tbl[i].ep_bulk_out = 0; + tbl[i].ep_bulk_in = 0; + tbl[i].ep_intr = 0; } - (*handle)->rid = rid; - if (idev) /* Regular USB transport. */ + libusb_free_device_list (ccid_usb_dev_list, 1); + ccid_usb_dev_list = NULL; +} + +unsigned int +ccid_get_BAI (int idx, struct ccid_dev_table *tbl) +{ + int n; + int bus, addr, intf; + unsigned int bai; + + if (tbl[idx].transport == TRANSPORT_USB) { - (*handle)->idev = idev; - (*handle)->dev_fd = -1; - (*handle)->id_vendor = desc.idVendor; - (*handle)->id_product = desc.idProduct; - (*handle)->bcd_device = desc.bcdDevice; - (*handle)->ifc_no = ifc_no; - (*handle)->ep_bulk_out = ep_bulk_out; - (*handle)->ep_bulk_in = ep_bulk_in; - (*handle)->ep_intr = ep_intr; + libusb_device *dev; + + n = tbl[idx].n; + dev = ccid_usb_dev_list[n]; + + bus = libusb_get_bus_number (dev); + addr = libusb_get_device_address (dev); + intf = tbl[idx].interface_number; + bai = (bus << 16) | (addr << 8) | intf; } - else if (dev_fd != -1) /* Device transport. */ + else { - (*handle)->idev = NULL; - (*handle)->dev_fd = dev_fd; - (*handle)->id_vendor = 0; /* Magic vendor for special transport. */ - (*handle)->id_product = ifc_no; /* Transport type */ - prepare_special_transport (*handle); + n = tbl[idx].n; + bai = 0xFFFF0000 | n; } - else + + return bai; +} + +int +ccid_compare_BAI (ccid_driver_t handle, unsigned int bai) +{ + return handle->bai == bai; +} + +static int +ccid_open_usb_reader (const char *spec_reader_name, + int idx, struct ccid_dev_table *ccid_table, + ccid_driver_t *handle, char **rdrname_p) +{ + libusb_device *dev; + libusb_device_handle *idev = NULL; + char *rid; + int rc = 0; + int ifc_no, set_no; + struct libusb_device_descriptor desc; + int n; + int bus, addr; + unsigned int bai; + + n = ccid_table[idx].n; + ifc_no = ccid_table[idx].interface_number; + set_no = ccid_table[idx].setting_number; + + dev = ccid_usb_dev_list[n]; + bus = libusb_get_bus_number (dev); + addr = libusb_get_device_address (dev); + bai = (bus << 16) | (addr << 8) | ifc_no; + + rc = libusb_open (dev, &idev); + if (rc) { - assert (!"no transport"); /* Bug. */ + DEBUGOUT_1 ("usb_open failed: %s\n", libusb_error_name (rc)); + free (*handle); + *handle = NULL; + return rc; } - DEBUGOUT_2 ("using CCID reader %d (ID=%s)\n", readerno, rid ); + rc = libusb_get_device_descriptor (dev, &desc); + if (rc) + { + libusb_close (idev); + free (*handle); + *handle = NULL; + return rc; + } + + rid = make_reader_id (idev, desc.idVendor, desc.idProduct, + desc.iSerialNumber); - if (idev) + /* Check to see if reader name matches the spec. */ + if (spec_reader_name + && strncmp (rid, spec_reader_name, strlen (spec_reader_name))) { - if (parse_ccid_descriptor (*handle, ifcdesc_extra, ifcdesc_extra_len)) - { - DEBUGOUT ("device not supported\n"); - rc = CCID_DRIVER_ERR_NO_READER; - goto leave; - } + DEBUGOUT ("device not matched\n"); + rc = CCID_DRIVER_ERR_NO_READER; + goto leave; + } + + (*handle)->id_vendor = desc.idVendor; + (*handle)->id_product = desc.idProduct; + (*handle)->idev = idev; + (*handle)->dev_fd = -1; + (*handle)->bai = bai; + (*handle)->ifc_no = ifc_no; + (*handle)->ep_bulk_out = ccid_table[idx].ep_bulk_out; + (*handle)->ep_bulk_in = ccid_table[idx].ep_bulk_in; + (*handle)->ep_intr = ccid_table[idx].ep_intr; + + DEBUGOUT_2 ("using CCID reader %d (ID=%s)\n", idx, rid); + + if (parse_ccid_descriptor (*handle, desc.bcdDevice, + ccid_table[idx].ifcdesc_extra, + ccid_table[idx].ifcdesc_extra_len)) + { + DEBUGOUT ("device not supported\n"); + rc = CCID_DRIVER_ERR_NO_READER; + goto leave; + } + + rc = libusb_claim_interface (idev, ifc_no); + if (rc) + { + DEBUGOUT_1 ("usb_claim_interface failed: %d\n", rc); + rc = CCID_DRIVER_ERR_CARD_IO_ERROR; + goto leave; + } - rc = libusb_claim_interface (idev, ifc_no); + if (set_no != 0) + { + rc = libusb_set_interface_alt_setting (idev, ifc_no, set_no); if (rc) { - DEBUGOUT_1 ("usb_claim_interface failed: %d\n", rc); + DEBUGOUT_1 ("usb_set_interface_alt_setting failed: %d\n", rc); rc = CCID_DRIVER_ERR_CARD_IO_ERROR; goto leave; } - - if (set_no != 0) - { - rc = libusb_set_interface_alt_setting (idev, ifc_no, set_no); - if (rc) - { - DEBUGOUT_1 ("usb_set_interface_alt_setting failed: %d\n", rc); - rc = CCID_DRIVER_ERR_CARD_IO_ERROR; - goto leave; - } - } } rc = ccid_vendor_specific_init (*handle); leave: - free (ifcdesc_extra); if (rc) { free (rid); - if (idev) - libusb_close (idev); - if (dev_fd != -1) - close (dev_fd); + libusb_close (idev); free (*handle); *handle = NULL; } else - if (rdrname_p) - *rdrname_p = (*handle)->rid; + { + if (rdrname_p) + *rdrname_p = rid; + else + free (rid); + } return rc; } +/* Open the reader with the internal number READERNO and return a + pointer to be used as handle in HANDLE. Returns 0 on success. */ +int +ccid_open_reader (const char *spec_reader_name, + int idx, struct ccid_dev_table *ccid_table, + ccid_driver_t *handle, char **rdrname_p) +{ + int n; + int fd; + char *rid; + + *handle = calloc (1, sizeof **handle); + if (!*handle) + { + DEBUGOUT ("out of memory\n"); + return CCID_DRIVER_ERR_OUT_OF_CORE; + } + + if (ccid_table[idx].transport == TRANSPORT_USB) + return ccid_open_usb_reader (spec_reader_name, idx, ccid_table, + handle, rdrname_p); + + /* Special transport support. */ + + n = ccid_table[idx].n; + fd = open (transports[n].name, O_RDWR); + if (fd < 0) + { + DEBUGOUT_2 ("failed to open '%s': %s\n", + transports[n].name, strerror (errno)); + free (*handle); + *handle = NULL; + return -1; + } + + rid = malloc (strlen (transports[n].name) + 30 + 10); + if (!rid) + { + close (fd); + free (*handle); + *handle = NULL; + return -1; /* Error. */ + } + + sprintf (rid, "0000:%04X:%s:0", transports[n].type, transports[n].name); + + /* Check to see if reader name matches the spec. */ + if (spec_reader_name + && strncmp (rid, spec_reader_name, strlen (spec_reader_name))) + { + DEBUGOUT ("device not matched\n"); + free (rid); + close (fd); + free (*handle); + *handle = NULL; + return -1; + } + + (*handle)->id_vendor = 0; + (*handle)->id_product = transports[n].type; + (*handle)->idev = NULL; + (*handle)->dev_fd = fd; + (*handle)->bai = 0xFFFF0000 | n; + prepare_special_transport (*handle); + if (rdrname_p) + *rdrname_p = rid; + else + free (rid); + + return 0; +} + static void do_close_reader (ccid_driver_t handle) @@ -1719,7 +1982,7 @@ ccid_set_progress_cb (ccid_driver_t handle, void (*cb)(void *, const char *, int, int, int), void *cb_arg) { - if (!handle || !handle->rid) + if (!handle) return CCID_DRIVER_ERR_INV_VALUE; handle->progress_cb = cb; @@ -1736,7 +1999,6 @@ ccid_close_reader (ccid_driver_t handle) return 0; do_close_reader (handle); - free (handle->rid); free (handle); return 0; } diff --git a/scd/ccid-driver.h b/scd/ccid-driver.h index e3aed9f..9e71f5e 100644 --- a/scd/ccid-driver.h +++ b/scd/ccid-driver.h @@ -1,5 +1,5 @@ -/* ccid-driver.c - USB ChipCardInterfaceDevices driver - * Copyright (C) 2003 Free Software Foundation, Inc. +/* ccid-driver.h - USB ChipCardInterfaceDevices driver + * Copyright (C) 2003 Free Software Foundation, Inc. * * This file is part of GnuPG. * @@ -109,10 +109,18 @@ enum { struct ccid_driver_s; typedef struct ccid_driver_s *ccid_driver_t; +struct ccid_dev_table; + int ccid_set_debug_level (int level); char *ccid_get_reader_list (void); -int ccid_open_reader (ccid_driver_t *handle, const char *readerid, - const char **rdrname_p); + +gpg_error_t ccid_dev_scan (int *idx_max, struct ccid_dev_table **t_p); +void ccid_dev_scan_finish (struct ccid_dev_table *tbl, int max); +unsigned int ccid_get_BAI (int, struct ccid_dev_table *tbl); +int ccid_compare_BAI (ccid_driver_t handle, unsigned int); +int ccid_open_reader (const char *spec_reader_name, + int idx, struct ccid_dev_table *ccid_table, + ccid_driver_t *handle, char **rdrname_p); int ccid_set_progress_cb (ccid_driver_t handle, void (*cb)(void *, const char *, int, int, int), void *cb_arg); @@ -126,7 +134,7 @@ int ccid_transceive (ccid_driver_t handle, unsigned char *resp, size_t maxresplen, size_t *nresp); int ccid_transceive_secure (ccid_driver_t handle, const unsigned char *apdu, size_t apdulen, - pininfo_t *pininfo, + pininfo_t *pininfo, unsigned char *resp, size_t maxresplen, size_t *nresp); int ccid_transceive_escape (ccid_driver_t handle, const unsigned char *data, size_t datalen, diff --git a/scd/command.c b/scd/command.c index ce2be34..59b16a2 100644 --- a/scd/command.c +++ b/scd/command.c @@ -281,6 +281,75 @@ cmd_serialno (assuan_context_t ctx, char *line) } +static gpg_error_t +do_learn (ctrl_t ctrl, assuan_context_t ctx, app_t app, + int force, int only_keypairinfo) +{ + int rc = 0; + + /* Unless the force option is used we try a shortcut by identifying + the card using a serial number and inquiring the client with + that. The client may choose to cancel the operation if he already + knows about this card */ + if (!only_keypairinfo) + { + const char *reader; + char *serial; + time_t stamp; + + reader = apdu_get_reader_name (app->slot); + if (!reader) + return out_of_core (); + send_status_direct (ctrl, "READER", reader); + /* No need to free the string of READER. */ + + rc = app_get_serial_and_stamp (app, &serial, &stamp); + if (rc) + return rc; + + rc = print_assuan_status (ctx, "SERIALNO", "%s %lu", + serial, (unsigned long)stamp); + if (rc < 0) + { + xfree (serial); + return out_of_core (); + } + + if (!force) + { + char *command; + + rc = gpgrt_asprintf (&command, "KNOWNCARDP %s %lu", + serial, (unsigned long)stamp); + if (rc < 0) + { + xfree (serial); + return out_of_core (); + } + rc = assuan_inquire (ctx, command, NULL, NULL, 0); + xfree (command); + if (rc) + { + if (gpg_err_code (rc) != GPG_ERR_ASS_CANCELED) + log_error ("inquire KNOWNCARDP failed: %s\n", + gpg_strerror (rc)); + xfree (serial); + return rc; + } + /* Not canceled, so we have to proceeed. */ + } + xfree (serial); + } + + /* Let the application print out its collection of useful status + information. */ + if (!rc) + rc = app_write_learn_status (app, ctrl, only_keypairinfo); + + return rc; +} + + static const char hlp_learn[] = "LEARN [--force] [--keypairinfo]\n" "\n" @@ -355,75 +424,30 @@ cmd_learn (assuan_context_t ctx, char *line) { ctrl_t ctrl = assuan_get_pointer (ctx); int rc = 0; + int force = has_option (line, "--force"); int only_keypairinfo = has_option (line, "--keypairinfo"); + int all = has_option (line, "--all"); + + app_t app; if ((rc = open_card (ctrl, NULL, 0))) return rc; - /* Unless the force option is used we try a shortcut by identifying - the card using a serial number and inquiring the client with - that. The client may choose to cancel the operation if he already - knows about this card */ - if (!only_keypairinfo) + if (!all) { - const char *reader; - char *serial; - time_t stamp; - app_t app = ctrl->app_ctx; - + app = ctrl->app_ctx; if (!app) return gpg_error (GPG_ERR_CARD_NOT_PRESENT); - reader = apdu_get_reader_name (app->slot); - if (!reader) - return out_of_core (); - send_status_direct (ctrl, "READER", reader); - /* No need to free the string of READER. */ - - rc = app_get_serial_and_stamp (ctrl->app_ctx, &serial, &stamp); - if (rc) - return rc; - - rc = print_assuan_status (ctx, "SERIALNO", "%s %lu", - serial, (unsigned long)stamp); - if (rc < 0) - { - xfree (serial); - return out_of_core (); - } - - if (!has_option (line, "--force")) - { - char *command; - - rc = gpgrt_asprintf (&command, "KNOWNCARDP %s %lu", - serial, (unsigned long)stamp); - if (rc < 0) - { - xfree (serial); - return out_of_core (); - } - rc = assuan_inquire (ctx, command, NULL, NULL, 0); - xfree (command); - if (rc) - { - if (gpg_err_code (rc) != GPG_ERR_ASS_CANCELED) - log_error ("inquire KNOWNCARDP failed: %s\n", - gpg_strerror (rc)); - xfree (serial); - return rc; - } - /* Not canceled, so we have to proceeed. */ - } - xfree (serial); + return do_learn (ctrl, ctx, app, force, only_keypairinfo); + } + else + { + for (app = app_list_start (); app; app = app->next) + do_learn (ctrl, ctx, app, force, only_keypairinfo); + app_list_finish (); + return 0; } - - /* Let the application print out its collection of useful status - information. */ - if (!rc) - rc = app_write_learn_status (ctrl->app_ctx, ctrl, only_keypairinfo); - - return rc; } -- From juraj at sarinay.com Sat Dec 31 00:40:26 2016 From: juraj at sarinay.com (=?UTF-8?Q?Juraj_=c5=a0arinay?=) Date: Sat, 31 Dec 2016 00:40:26 +0100 Subject: Degenerate ElGamal & duplicate key IDs Message-ID: <59c3f9a2-ecea-f4ed-8e39-bdc47f99c94f@sarinay.com> Hello I have been playing around with ElGamal encryption within OpenPGP and found out that GnuPG (2.1.17 tested) accepts degenerate ElGamal ciphertexts with the first component equal to one, such as the attached degenerate_universal.txt.gpg. Every ElGamal private key (with appropriate modulus length) can be used to "decrypt" such degenerate messages. Maybe the recipient should be warned that the the content was actually sent in clear. I would even consider rejecting all such messages as invalid. I have generated a "corresponding" ElGamal public subkey with g=y=1 and found out that it can be imported and used to produce degenerate ElGamal ciphertexts. See the attached fake_subkey.gpg. Please consider treating such degenerate subkeys as invalid. I had a rather far-fetched scenario in mind, where a legitimate ElGamal public subkey is swapped for a degenerate one with the same ID. This could lead to an arguably "easier" MITM attack, because all the messages encrypted under the fake subkey decrypt with the legitimate one. I have actually generated two example ElGamal keys, one reasonable and the other one degenerate, with identical IDs. For more context, see http://www.sarinay.com/blog/taher-was-not-here/ In the course of my experiments, I also generated two primary DSA keys with identical IDs and ran into another minor issue. When verifying a signature, if there are multiple public keys with the appropriate key ID, GnuPG appears to select the key that was imported first. If there are two legitimate public keys with identical IDs, the validity of a signature may depend on the internal ordering of the keys. I have attached two example public keys, DSA_1_cert_sign.gpg and DSA_2_certonly.gpg. The file signed.txt.gpg is signed with the first key. If I import DSA_1 first and DSA_2 second, the signature verifies fine. If I import the public keys the other way around, GnuPG reports that the signature is bad. Only DSA_1 actually has the sign flag set, so I expected that DSA_2 would be skipped and DSA_1 tried instead. Would it not make sense to try all the public keys with the appropriate ID? If we do that, what should be output if none matches? Is it "BAD signature" or "Can't check signature: No public key"? The former is what we currently output if one key was tried, the latter if none. Why the difference? Every time GnuPG outputs "BAD signature", it could still be valid under a key we do not have. In this particular case, GnuPG appears to behave as if IDs were unique, yet there is partial support for multiple keys with identical IDs. Why bother with the support at all? It could be argued that the chance of a random ID collision within a relatively small keyring is indeed negligible. The few colliding pairs we have seen so far were AFAIK all artificially generated examples. Have there been genuine collisions in the wild? It might be a good idea to warn the user that a repeated ID is probably an attack attempt and only actually allow the coexistence of the keys if imported in expert mode. Best Regards Juraj -------------- next part -------------- A non-text attachment was scrubbed... Name: degenerate_universal.txt.gpg Type: application/pgp-encrypted Size: 373 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fake_subkey.gpg Type: application/pgp-encrypted Size: 273 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DSA_1_cert_sign.gpg Type: application/pgp-encrypted Size: 988 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DSA_2_certonly.gpg Type: application/pgp-encrypted Size: 988 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signed.txt.gpg Type: application/pgp-encrypted Size: 144 bytes Desc: not available URL: