From dkg at fifthhorseman.net Thu Sep 1 00:19:18 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 31 Aug 2016 18:19:18 -0400 Subject: gpg --list-config should be able to run when $HOME is not writeable (or does not exist) Message-ID: <87oa48d1jt.fsf@alice.fifthhorseman.net> Hi GnuPG folks-- some gnupg commands (like --list-config) seem to want to do a lot more than they need to with the filesystem. They report errors when the gnupg homedir is not writeable, and they fail outright when $HOME is not writeable (or does not exist). but "gpg --version" works fine in those situations: 0 dkg at alice:~$ HOME=/does-not-exist gpg --version gpg (GnuPG) 2.1.15 libgcrypt 1.7.3-beta Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: /does-not-exist/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 0 dkg at alice:~$ GNUPGHOME=/does-not-exist gpg --with-colons --list-config version gpg: keyblock resource '/does-not-exist/pubring.kbx': No such file or directory cfg:version:2.1.15 2 dkg at alice:~$ HOME=/does-not-exist gpg --with-colons --list-config version gpg: Fatal: can't create directory '/does-not-exist/.gnupg': No such file or directory 2 dkg at alice:~$ Note that when $GNUPGHOME does not exist, the return code is non-zero but the answer is emitted. But when $HOME does not exist, the answer isn't even produced! We recently had a problem where GnuPG failed to build on the debian autobuilders because the test suite tried (and failed) to create $HOME/.gnupg during a test because of this. The attached patch fixes the test suite when $HOME does not exist, but it seems to me like the right fix is for gpg to not try to access these directories at all when it doesn't need to do so. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-avoid-test-suite-failures-when-HOME-is-non-existent.patch Type: text/x-diff Size: 1219 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From gnupg-devel at spodhuis.org Thu Sep 1 17:53:56 2016 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Thu, 1 Sep 2016 11:53:56 -0400 Subject: WKS enabled for gnupg.net and gnupg.org In-Reply-To: <87zinssvkm.fsf@wheatstone.g10code.de> References: <87zinssvkm.fsf@wheatstone.g10code.de> Message-ID: <20160901155355.GA10933@breadbox.private.spodhuis.org> On 2016-08-31 at 19:21 +0200, Werner Koch wrote: > An easy way of testing the system exists for [Mutt] and Gnus users: By > adding the two lines > > ,---- > | application/vnd.gnupg.wks; /usr/local/libexec/gpg-wks-client \ > | -v --read --send; needsterminal; description=WKS message > `---- > > to `/etc/mailcap' Mutt will do the decryption job and then call the > wks-client for the protocol handling. It can be expected that Mutt > users have a /usr/lib/sendmail installed which is required here. Note > that `--read' is used which tells the client that the input mail has > already been decrypted. Problem: I like GnuPG in part because of it's support for the concept of privacy. This mailcap setting is rather dangerous from that perspective. Fortunately mutt does not autoview by default, but that's a thin layer of ice to be resting upon. This command appears to be usable, with that MIME type, as a probe for an email handler which can then reply, sending arbitrary commands via email to arbitrary addresses. The fingerprint: isn't verified (a FIXME), the sender: doesn't appear to be validated as being at least in the same domain as a uid on the key. The nonce is sent back, but that can be arbitrary text with nvc_parse() explicitly handling continuations for multi-line data and gpg-wks-client only checking that the nonce is long enough. The one saving grace is that it looks like the message isn't signed? (I haven't read the code deeply enough to be sure). I've commented this back out of my .mailcap as there's a rethink needed, IMO. At a bare minimum, any command designed to be invoked from mailcap should respect the privacy of the reader by not communicating remotely without positive confirmation from the user first. gpg-wks-client should, in this scenario, parse the message, construct something to show the user, show it, flush existing keyboard input and prompt for confirmation before sending data remotely. Bonus points for ensuring that nonce can't be used for issuing arbitrary commands for arbitrary systems via email and other forms of validation. The approach is sane and with right tools integration this could be valuable ("click button to register key with email server") but at present much more is needed before this can be a template for adoption. But hey, that's the point of the -devel list and catching these things early, right? Regards, -Phil -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Digital signature URL: From dkg at fifthhorseman.net Thu Sep 1 19:07:14 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 01 Sep 2016 13:07:14 -0400 Subject: process accumulation when using ephemeral homedirs Message-ID: <87y43bblbx.fsf@alice.fifthhorseman.net> There are some GnuPG use cases that warrant the use of ephemeral $GNUPGHOME, and some of those use cases need keyserver interaction. If they're done repeatedly with gnupg 2.1, each invocation ends up spawning its own dirmngr process. even if those ephemeral homedirs are destroyed, the dirmngr process appears to just live forever. consider this (admittedly contrived) example: pidof dirmngr for x in $(seq 1 10); do export GNUPGHOME=$(mktemp -d) gpg --keyserver keys.gnupg.net --recv 0xD8692123C4065DEA5E0F3AB5249B39D24F25E3B6 gpg --list-keys rm -rf "$GNUPGHOME" done When it's done, there will be 10 more dirmngr processes running on the system, with no clear way to get at them besides finding them in the process table and killing them by a signal. Do we have a good story for this use case? The pattern of ephemeral homedirs is not an uncommon one, and i'm starting to hear reports from people who are getting into trouble because dirmngr processes are piling up. obviously, in the script above, we could add an explicit "gpgconf --kill dirmngr" or "gpg-connect-agent --dirmngr killdirmngr /bye", but that seems like it shouldn't be necessary. On a system with a kernel that supports inotify (any modern linux), we could have dirmngr watch its own socket and terminate if it disappears. Any interest in a patch for that? It's only a partial fix (only for some OSes, only for some ephemeral use cases where the ephemeral homedir is cleaned up) but it'd be a start at least. Other thoughts about the best way to avoid this kind of process accumulation? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From wk at gnupg.org Thu Sep 1 19:25:54 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 01 Sep 2016 19:25:54 +0200 Subject: gpg --list-config should be able to run when $HOME is not writeable (or does not exist) In-Reply-To: <87oa48d1jt.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 31 Aug 2016 18:19:18 -0400") References: <87oa48d1jt.fsf@alice.fifthhorseman.net> Message-ID: <87k2evo7kt.fsf@wheatstone.g10code.de> On Thu, 1 Sep 2016 00:19, dkg at fifthhorseman.net said: > some gnupg commands (like --list-config) seem to want to do a lot more > than they need to with the filesystem. They report errors when the > gnupg homedir is not writeable, and they fail outright when $HOME is not > writeable (or does not exist). but "gpg --version" works fine in those I just pushed a fix for master. --list-config --list-gcrypt-config --gpgconf-list --gpgconf-test won't anymore register a default keyring and thus create ~/.gnupg. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From dkg at fifthhorseman.net Thu Sep 1 21:38:13 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 01 Sep 2016 15:38:13 -0400 Subject: gpg --list-config should be able to run when $HOME is not writeable (or does not exist) In-Reply-To: <87k2evo7kt.fsf@wheatstone.g10code.de> References: <87oa48d1jt.fsf@alice.fifthhorseman.net> <87k2evo7kt.fsf@wheatstone.g10code.de> Message-ID: <87poonbeca.fsf@alice.fifthhorseman.net> Hi Werner-- On Thu 2016-09-01 13:25:54 -0400, Werner Koch wrote: > On Thu, 1 Sep 2016 00:19, dkg at fifthhorseman.net said: > >> some gnupg commands (like --list-config) seem to want to do a lot more >> than they need to with the filesystem. They report errors when the >> gnupg homedir is not writeable, and they fail outright when $HOME is not >> writeable (or does not exist). but "gpg --version" works fine in those > > > I just pushed a fix for master. > > --list-config > --list-gcrypt-config > --gpgconf-list > --gpgconf-test > > won't anymore register a default keyring and thus create ~/.gnupg. Thanks for this fix! If i upload another version of 2.1.15 into debian i'll use it instead of the patch which shuffles the test suite initialization. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From wk at gnupg.org Thu Sep 1 22:27:34 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 01 Sep 2016 22:27:34 +0200 Subject: process accumulation when using ephemeral homedirs In-Reply-To: <87y43bblbx.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 01 Sep 2016 13:07:14 -0400") References: <87y43bblbx.fsf@alice.fifthhorseman.net> Message-ID: <87lgzbmkll.fsf@wheatstone.g10code.de> On Thu, 1 Sep 2016 19:07, dkg at fifthhorseman.net said: > On a system with a kernel that supports inotify (any modern linux), we > could have dirmngr watch its own socket and terminate if it disappears. Actually gpg-agent does this for many years and terminates itself if another gpg-agent process has taken over the socket. This was required due to a race on Windows but the code works on Unix as well. It is check_own_socket_thread which is triggered every minute. The code can actually be put into common/ so that it can be reused by dirmngr. Not a big deal, I can do that tomorrow. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From dkg at fifthhorseman.net Thu Sep 1 23:24:39 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 01 Sep 2016 17:24:39 -0400 Subject: process accumulation when using ephemeral homedirs In-Reply-To: <87lgzbmkll.fsf@wheatstone.g10code.de> References: <87y43bblbx.fsf@alice.fifthhorseman.net> <87lgzbmkll.fsf@wheatstone.g10code.de> Message-ID: <8737ljb9ew.fsf@alice.fifthhorseman.net> On Thu 2016-09-01 16:27:34 -0400, Werner Koch wrote: > On Thu, 1 Sep 2016 19:07, dkg at fifthhorseman.net said: > >> On a system with a kernel that supports inotify (any modern linux), we >> could have dirmngr watch its own socket and terminate if it disappears. > > Actually gpg-agent does this for many years and terminates itself if > another gpg-agent process has taken over the socket. This was required > due to a race on Windows but the code works on Unix as well. > > It is check_own_socket_thread which is triggered every minute. The code > can actually be put into common/ so that it can be reused by dirmngr. That sounds reasonable on platforms where inotify isn't available, but it seems like inotify would be a better choice on platforms that support it. Would you be up for a patch for inotify support so that dirmngr can disappear immediately when its homedir does on those platforms? --dkg From wk at gnupg.org Fri Sep 2 07:52:49 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 02 Sep 2016 07:52:49 +0200 Subject: process accumulation when using ephemeral homedirs In-Reply-To: <8737ljb9ew.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 01 Sep 2016 17:24:39 -0400") References: <87y43bblbx.fsf@alice.fifthhorseman.net> <87lgzbmkll.fsf@wheatstone.g10code.de> <8737ljb9ew.fsf@alice.fifthhorseman.net> Message-ID: <874m5yn8zy.fsf@wheatstone.g10code.de> On Thu, 1 Sep 2016 23:24, dkg at fifthhorseman.net said: > That sounds reasonable on platforms where inotify isn't available, but > it seems like inotify would be a better choice on platforms that support > it. Yes, but this a bit more work. I would like to add an interface for this to libassuan or libgpg-error, so that there is a platform abstraction and we can remove some code from gpa, where it is also used. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From wk at gnupg.org Fri Sep 2 08:25:24 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 02 Sep 2016 08:25:24 +0200 Subject: WKS enabled for gnupg.net and gnupg.org In-Reply-To: <20160901155355.GA10933@breadbox.private.spodhuis.org> (Phil Pennock's message of "Thu, 1 Sep 2016 11:53:56 -0400") References: <87zinssvkm.fsf@wheatstone.g10code.de> <20160901155355.GA10933@breadbox.private.spodhuis.org> Message-ID: <87zinqlsx7.fsf@wheatstone.g10code.de> On Thu, 1 Sep 2016 17:53, gnupg-devel at spodhuis.org said: > Problem: I like GnuPG in part because of it's support for the concept of > privacy. This mailcap setting is rather dangerous from that > perspective. Fortunately mutt does not autoview by default, but that's > a thin layer of ice to be resting upon. It is not intended as a final solution. It is merely convenient for testing. > The fingerprint: isn't verified (a FIXME), the sender: doesn't appear to > be validated as being at least in the same domain as a uid on the key. > The nonce is sent back, but that can be arbitrary text with nvc_parse() > explicitly handling continuations for multi-line data and gpg-wks-client > only checking that the nonce is long enough. Right. The reason tehre are FIXMEs in the code is that they need to be fixed before the code gets into wide use. This is also the reason why you need a configure option for building the client. Here are my planned steps: - Fix the FIXMEs - Create a database for the client to track pending requests. Then answer only requests we have initiated. - Revise the protocol to better protect against spam and for easier automated processing > The one saving grace is that it looks like the message isn't signed? (I > haven't read the code deeply enough to be sure). Right, not in this revision of the protocol. My plan is this: Create a signed messages with a multipart/mixed content. The first part is a human readable description what this message is about. The second part is the encrypted confirmation request as we use it currently. A MUA may now check that the signature comes from an address from where we expect a confirmation request and silently drop the message if that is not the case. This way the user won't be asked by non-provider generated confirmation requests to enter their passphrase for decryption. The signed message also allows to present a useful prompt _before_ decryption. Right now I am unsure on whether the encrypted part should really be a MIME part (which would technically be the right thing) or just a plain inline armored or even only base64 encoded blob. The latter has the advantage that full PGP/MIME aware clients won't be able to decrypt it and thus need to employ gpg-wks-client instead - but the mailcap trick won't work either. > I've commented this back out of my .mailcap as there's a rethink needed, > IMO. As I said, it is useful for testing. > At a bare minimum, any command designed to be invoked from mailcap > should respect the privacy of the reader by not communicating remotely > without positive confirmation from the user first. gpg-wks-client Iff that is an expected request I think it is fine to send a response without user interaction. > The approach is sane and with right tools integration this could be > valuable ("click button to register key with email server") but at > present much more is needed before this can be a template for adoption. > But hey, that's the point of the -devel list and catching these things > early, right? Many thanks for your comments. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From wk at gnupg.org Fri Sep 2 08:31:52 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 02 Sep 2016 08:31:52 +0200 Subject: WKS enabled for gnupg.net and gnupg.org In-Reply-To: <8760qgep46.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 31 Aug 2016 15:04:57 -0400") References: <87zinssvkm.fsf@wheatstone.g10code.de> <8760qgep46.fsf@alice.fifthhorseman.net> Message-ID: <87vayelsmf.fsf@wheatstone.g10code.de> On Wed, 31 Aug 2016 21:04, dkg at fifthhorseman.net said: > * rename them as wks-client and wks-server and ship them in a separate > "wks" binary package for people who are interested What about a gpg-goodies package for the gpg-wks-server and other thinks which are in general not used. The gpg-wks-client needs to be part of gpg proper as soon as it is matured enough. > * add them into the standard "gnupg" package shipped in /usr/lib/gnupg > (where scdaemon lives) In Kmail the code expects gpg-wks-client in the libexecdir which in Debian is /usr/lib/gnupg. The server is currently in bin - or should it got to sbin? > is there a specific file extension that you want associated with this > mime type? .wks was used by Microsoft Works for spreadsheets, but maybe No. > I can have the debian package add this to /etc/mailcap automatically if > you think that's a good idea. Might be a good argument for a separate > wks package if we do that. See Phil's remarks on the problem with the mailcap. Thus better don't package it. A wks-server package would be useful if it does all the mail and web server integration (i.e. a dedicated user and an Exim transport) Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From bjk at luxsci.net Sun Sep 4 01:06:36 2016 From: bjk at luxsci.net (Ben Kibbey) Date: Sat, 3 Sep 2016 19:06:36 -0400 Subject: [PATCH] Check for GPG_TTY as well as DISPLAY. In-Reply-To: <20151022011509.GB15333@picnic> References: <1445385603-3678688.75890528.ft9KNxZWg007079@rs146.luxsci.com> <87eggohvmq.fsf@vigenere.g10code.de> <1445465282-9798705.77418447.ft9LM7KOY017487@rs146.luxsci.com> <20151022011509.GB15333@picnic> Message-ID: <1472944021-2356043.18370404.fu83N6bHl019328@rs146.luxsci.com> On Wed, Oct 21, 2015 at 09:15:09PM -0400, Ben Kibbey wrote: > On Wed, Oct 21, 2015 at 06:07:20PM -0400, Ben Kibbey wrote: > > which would keep the original behavior but not work for my case as the > > foreground server process would catch the pinentry rather than the > > client on another tty. > > > > Would that be OK to push after keeping the isatty() test order? > > Nevermind. Pushing the above modification wouldn't make a difference. I > got what I needed to work working. Sorry about the noise. It turns out I need this ability again. Attached is a revised patch with better readability. Since gpg-agent will always use the DISPLAY when set, and the user would need to replace/set GPG_TTY in the current environment, I don't see how it can break anything. Thanks, -- Ben Kibbey -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Check-for-GPG_TTY-when-DISPLAY-is-unset.patch Type: text/x-diff Size: 6459 bytes Desc: not available URL: From alec at alec.pl Sun Sep 4 13:09:06 2016 From: alec at alec.pl (A.L.E.C) Date: Sun, 4 Sep 2016 13:09:06 +0200 Subject: Stop gpg-agent after inactivity time Message-ID: <99923af9-473e-aa3c-5900-f4a9fc8f33b9@alec.pl> Hi! I think I saw a ticket about this, but can't find now. I'd like to add my vote for such a functionality. It would be really wanted on server systems with a lot of virtual users (homedirs). As a Roundcube webmail developer I see interest in server-side encryption capabilities. That's what Enigma plugin for Roundcube does. I know that storing secret keys on servers is not the best solution, but there are people that accept this. I successfully ported our code from GnuPG 1.x to 2.1 using "pinentry loopback mode", however gpg-agent still is in use. Problem is that I can have hundreds/thousends homedirs in such a case I'll end up with hundreds of gpg-agent processes. Would it be at all possible to implement automatic stopping of gpg-agent when it is not used? It could be with gpg command line argument. E.g. if gpg-agent was started automatically by gpg --agent-auto-stop command it will exit 1 minute after last use. -- 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 dkg at fifthhorseman.net Sun Sep 4 16:32:24 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 04 Sep 2016 10:32:24 -0400 Subject: splitting up an inline-signed OpenPGP message Message-ID: <87zinn91mv.fsf@alice.fifthhorseman.net> Hi GnuPG folks-- I'd like to provide a simple utility to split an inline-signed OpenPGP message into a body and a signature that can then be verified independently with gpgv. I've written the following perl proof of concept but the result is a body and a signature that gpgv claims is BAD, even though the body exactly matches the exact output of "gpg --decrypt < inline-signed.txt" I test this with: gpg --no-options --batch --no-default-keyring --status-fd=2 --keyring $(pwd)/trustedkeys.gpg --output body.gpg-extracted --decrypt < inline-signed.txt ./split-inline-signed.pl < inline-signed.txt >body 3>body.asc diff body.gpg-extracted body gpgv --status-fd 2 --keyring $(pwd)/trustedkeys.gpg body.asc body and everything works as expected until gpgv fails :/ Can anyone point out what i've done wrong? --dkg -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: split-inline-signed.pl URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From wk at gnupg.org Sun Sep 4 17:19:02 2016 From: wk at gnupg.org (Werner Koch) Date: Sun, 04 Sep 2016 17:19:02 +0200 Subject: Stop gpg-agent after inactivity time In-Reply-To: <99923af9-473e-aa3c-5900-f4a9fc8f33b9@alec.pl> (A. L. E. C.'s message of "Sun, 4 Sep 2016 13:09:06 +0200") References: <99923af9-473e-aa3c-5900-f4a9fc8f33b9@alec.pl> Message-ID: <87eg4zbsm1.fsf@wheatstone.g10code.de> On Sun, 4 Sep 2016 13:09, alec at alec.pl said: > Would it be at all possible to implement automatic stopping of gpg-agent > when it is not used? It could be with gpg command line argument. E.g. if > gpg-agent was started automatically by gpg --agent-auto-stop command it > will exit 1 minute after last use. We recently discussed this and the feature request is at https://bugs.gnupg.org/gnupg/issue2450 Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From alec at alec.pl Sun Sep 4 17:39:21 2016 From: alec at alec.pl (A.L.E.C) Date: Sun, 4 Sep 2016 17:39:21 +0200 Subject: Stop gpg-agent after inactivity time In-Reply-To: <87eg4zbsm1.fsf@wheatstone.g10code.de> References: <99923af9-473e-aa3c-5900-f4a9fc8f33b9@alec.pl> <87eg4zbsm1.fsf@wheatstone.g10code.de> Message-ID: On 09/04/2016 05:19 PM, Werner Koch wrote: > We recently discussed this and the feature request is at > https://bugs.gnupg.org/gnupg/issue2450 Yes, that's it. Please, note that in my use-case we work with the default configuration. So, implementing this as a config option wouldn't really work. I'd need a way to set this option when executing gpg. We do not execute gpg-agent directly here, nor create configuration files. So, making it a default with a reasonable value or possibility to set via gpg would be needed. Thanks. -- 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 guilhem at fripost.org Sun Sep 4 17:40:37 2016 From: guilhem at fripost.org (Guilhem Moulin) Date: Sun, 4 Sep 2016 17:40:37 +0200 Subject: splitting up an inline-signed OpenPGP message In-Reply-To: <87zinn91mv.fsf@alice.fifthhorseman.net> References: <87zinn91mv.fsf@alice.fifthhorseman.net> Message-ID: <20160904154037.zc5bfhjkco4ekdg5@localhost.localdomain> Hi Daniel, On Sun, 04 Sep 2016 at 10:32:24 -0400, Daniel Kahn Gillmor wrote: > I'd like to provide a simple utility to split an inline-signed OpenPGP > message into a body and a signature that can then be verified > independently with gpgv. Thanks for working on that! It's likely to be useful with uscan(1), among other things. > Can anyone point out what i've done wrong? Looks like it's due to ?The line ending (i.e., the ) before the '-----BEGIN PGP SIGNATURE-----' line that terminates the signed text is not considered part of the signed text.? ? RFC 4880 sec. 7.1 Indeed, after { echo a; echo b; echo c; } | gpg --clearsign | split-inline-signed.pl >body 3>sig.asc body contains "a\nb\nc\n". While ~$ gpg --verify sig.asc body fails, ~$ gpg --verify sig.asc <(echo -en "a\nb\nc") succeeds. Cheers, -- Guilhem. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From dshaw at jabberwocky.com Sun Sep 4 17:13:51 2016 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 4 Sep 2016 11:13:51 -0400 Subject: splitting up an inline-signed OpenPGP message In-Reply-To: <87zinn91mv.fsf@alice.fifthhorseman.net> References: <87zinn91mv.fsf@alice.fifthhorseman.net> Message-ID: <26CFAB58-4C3F-4684-8085-D6A3A7C99358@jabberwocky.com> On Sep 4, 2016, at 10:32 AM, Daniel Kahn Gillmor wrote: > > Hi GnuPG folks-- > > I'd like to provide a simple utility to split an inline-signed OpenPGP > message into a body and a signature that can then be verified > independently with gpgv. > > I've written the following perl proof of concept but the result is a > body and a signature that gpgv claims is BAD, even though the body > exactly matches the exact output of "gpg --decrypt < inline-signed.txt" > > I test this with: > > gpg --no-options --batch --no-default-keyring --status-fd=2 --keyring $(pwd)/trustedkeys.gpg --output body.gpg-extracted --decrypt < inline-signed.txt > ./split-inline-signed.pl < inline-signed.txt >body 3>body.asc > diff body.gpg-extracted body > gpgv --status-fd 2 --keyring $(pwd)/trustedkeys.gpg body.asc body > > and everything works as expected until gpgv fails :/ > > Can anyone point out what i've done wrong? I think you're being bitten by the final line ending of the body. Unlike the other line endings in a multi-line document, the final one is not a signed part of a clearsigned document. For example, create a clearsigned document that just contains "foo", a line break, and "bar": echo -e "foo\nbar" | gpg --clearsign If you run that through your perl tool, you get a body that contains "foo", a line break, "bar", and a line break. The now-detached signature will not verify. However, if you replace the body with "foo", a line break, "bar", but no final line break: echo -en "foo\nbar" > body Then the signature should verify. David From wk at gnupg.org Sun Sep 4 19:09:59 2016 From: wk at gnupg.org (Werner Koch) Date: Sun, 04 Sep 2016 19:09:59 +0200 Subject: Stop gpg-agent after inactivity time In-Reply-To: (A. L. E. C.'s message of "Sun, 4 Sep 2016 17:39:21 +0200") References: <99923af9-473e-aa3c-5900-f4a9fc8f33b9@alec.pl> <87eg4zbsm1.fsf@wheatstone.g10code.de> Message-ID: <87d1kja8wo.fsf@wheatstone.g10code.de> On Sun, 4 Sep 2016 17:39, alec at alec.pl said: > So, making it a default with a reasonable value or possibility to set > via gpg would be needed. That is not possible. If you have special requirements you need to configure the software in an appropriate way. In any case you can stop the daemons using gpgconf --kill. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From alec at alec.pl Sun Sep 4 20:10:36 2016 From: alec at alec.pl (A.L.E.C) Date: Sun, 4 Sep 2016 20:10:36 +0200 Subject: Stop gpg-agent after inactivity time In-Reply-To: <87d1kja8wo.fsf@wheatstone.g10code.de> References: <99923af9-473e-aa3c-5900-f4a9fc8f33b9@alec.pl> <87eg4zbsm1.fsf@wheatstone.g10code.de> <87d1kja8wo.fsf@wheatstone.g10code.de> Message-ID: On 09/04/2016 07:09 PM, Werner Koch wrote: >> So, making it a default with a reasonable value or possibility to set >> via gpg would be needed. > > That is not possible. If you have special requirements you need to > configure the software in an appropriate way. In any case you can stop > the daemons using gpgconf --kill. If I have a hundred gpg-agent processes, will that kill all of them? How to kill gpg-agent for specified homedir. Or should/could I just remove socket file? What if the agent is used by another process? -- 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 ludwig at enigmail.net Sun Sep 4 18:52:42 2016 From: ludwig at enigmail.net (=?UTF-8?B?THVkd2lnIEjDvGdlbHNjaMOkZmVy?=) Date: Sun, 4 Sep 2016 18:52:42 +0200 Subject: splitting up an inline-signed OpenPGP message In-Reply-To: <87zinn91mv.fsf@alice.fifthhorseman.net> References: <87zinn91mv.fsf@alice.fifthhorseman.net> Message-ID: <2d9e85fa-d187-8392-35b8-5b36b9df5f66@enigmail.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Daniel, On 04.09.16 16:32, Daniel Kahn Gillmor wrote: > Can anyone point out what i've done wrong? Just a shot in the dark: Do you canonicalize line endings (LF -> CRLF)? gpgparsemail e.g. does that. Ludwig -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXzFFQAAoJEDrb+m0Aoeb+o6AQALJe2xfHNDEDis5mR59hIBd1 RfmWmrQTDI9ZTT1duhFJjpHOtV3MwjDtJkjRJhkh5xgF8sTlLiJFvlNCXFq3yo1n 0v87gs6xi15gOui8PkrZx7kNIa2W8VbUdJeryuDLhWcK5PGrQe8LcgovyfQTa/M1 oKzRi9OMV4sgyh6oBYb0XBTSC4F5fqD///wrk8uwYM+vm51rZiJGBQNb4sEI2aFG LuXJ6xQdClXEZ9IJ8vXOljGesOIhgSVdiBS84AbjxlSUcVFXdZKks9KmpwasBd+p gYLk9IyJXS1fx9MlFduDPnzmPL3nIdLZVR+uisnHL3scPEiNRNX8KrIESEo4UHev sC1rQLaNa0Vq+3IpiHHQWlfAn5ieD0dlfu7qgWRAGuKmPYYGJvSMjSY6EwKQFa6D FyRoGn8ForEGDGoxe+UpKOmGnUFgsoejy9sjlzy6ysbtYaSIwKPKdkcGJX8Ssk4M W5+6InOqgJr359khsGZXEeDzqml0VJ8iBsLpDmpbfBvtxMvC0v8Hb/Hox3eMJfvp TLbatUWTJU3vM+dFq/RGw51FgRv63Ht6r+iU0d/XK94vAxG5TGrfiIQ/HXYlJItS h8gclOT/LaZrtfwZcOAa+1JoffXMAy2jmt6K/rqsX33uff2NjoWUK1zdARTSVr1h JuYIqL4CRBnkDIZKNLYI =pgfC -----END PGP SIGNATURE----- From gnupg-devel at spodhuis.org Mon Sep 5 01:22:49 2016 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Sun, 4 Sep 2016 19:22:49 -0400 Subject: export-filters act on subkeys? Message-ID: <20160904232248.GB23840@breadbox.private.spodhuis.org> This is a wishlist item for cleaning the interaction, with a driving use-case and an example of how I work around it right now. Problem scenario: needing to update PGP key in various places after subkey/uid updates, but discovering all sorts of services which break horribly when they receive PGP keys with subkeys using unsupported types, instead of just ignoring those subkeys. I file bug-reports, but responses come back to "Bouncy Castle does this, too hard to fix". So I need to be able to easily export my key with filtered subkeys, so that I get newer RSA subkeys out there, even while not able to use the ed25519/cv25519 subkeys. It seems that the sanest way to do this, which would ease migration for most users, would be to extend `--export-filter` (and `--import-filter`) to add `drop-subkey` for both export and import; add some properties based on the subkey, and add something to the EXAMPLES section showing the use of a good filter expression. Does this seem sane? Is there a better way? My workaround involves creating a temporary GNUPGHOME, scripting --command-fd interaction with gpg (with a sleep hack!) and ... works. So I'm not blocked, so not feeling enough pain to commit to implementing the filters, but if there's support for the idea from the maintainers, then I might see what I can do. https://gist.github.com/philpennock/e3426d21f9beb3fbf679229cad1224aa Folks shouldn't have to do that. Extending to new key types is going to be painful enough. (Example script hard-codes filename prefix, working dir, keyid and gpg executable name, deliberately not productionising this to be useful by those who can't edit shell scripts, to avoid spreading bad behaviour). Thoughts? -Phil -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Digital signature URL: From wk at gnupg.org Mon Sep 5 07:57:04 2016 From: wk at gnupg.org (Werner Koch) Date: Mon, 05 Sep 2016 07:57:04 +0200 Subject: Stop gpg-agent after inactivity time In-Reply-To: (A. L. E. C.'s message of "Sun, 4 Sep 2016 20:10:36 +0200") References: <99923af9-473e-aa3c-5900-f4a9fc8f33b9@alec.pl> <87eg4zbsm1.fsf@wheatstone.g10code.de> <87d1kja8wo.fsf@wheatstone.g10code.de> Message-ID: <87shte99e7.fsf@wheatstone.g10code.de> On Sun, 4 Sep 2016 20:10, alec at alec.pl said: > If I have a hundred gpg-agent processes, will that kill all of them? How No. gpgconf will only kill the one for the current homedir. > to kill gpg-agent for specified homedir. Or should/could I just remove > socket file? What if the agent is used by another process? gpg-agent will then cleanup itself within the next minute. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From alec at alec.pl Mon Sep 5 08:23:22 2016 From: alec at alec.pl (A.L.E.C) Date: Mon, 5 Sep 2016 08:23:22 +0200 Subject: Stop gpg-agent after inactivity time In-Reply-To: <87shte99e7.fsf@wheatstone.g10code.de> References: <99923af9-473e-aa3c-5900-f4a9fc8f33b9@alec.pl> <87eg4zbsm1.fsf@wheatstone.g10code.de> <87d1kja8wo.fsf@wheatstone.g10code.de> <87shte99e7.fsf@wheatstone.g10code.de> Message-ID: <8c08ce17-9791-5045-9a55-eb0e09e74087@alec.pl> On 05.09.2016 07:57, Werner Koch wrote: >> If I have a hundred gpg-agent processes, will that kill all of them? How > > No. gpgconf will only kill the one for the current homedir. Sorry, I might be annoying, but... I don't see --homedir in gpgconf manual. So, how do I specify which agent to kill? Remember I have virtual not phisical users, i.e. many homedirs but one real user (apache). -- 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 Mon Sep 5 09:58:27 2016 From: wk at gnupg.org (Werner Koch) Date: Mon, 05 Sep 2016 09:58:27 +0200 Subject: export-filters act on subkeys? In-Reply-To: <20160904232248.GB23840@breadbox.private.spodhuis.org> (Phil Pennock's message of "Sun, 4 Sep 2016 19:22:49 -0400") References: <20160904232248.GB23840@breadbox.private.spodhuis.org> Message-ID: <877faq93rw.fsf@wheatstone.g10code.de> On Mon, 5 Sep 2016 01:22, gnupg-devel at spodhuis.org said: > So I need to be able to easily export my key with filtered subkeys, so > that I get newer RSA subkeys out there, even while not able to use the > ed25519/cv25519 subkeys. Does this sound okay: gpg --export --export-filter drop-subkey='key_algo!=1 && key_algo!=17' which will remove all subkeys except those which are RSA or DSA. You may also use key_created > SOMETIMESTAMP or (note, new operator) key_created_d -lt 2016-09-05 to drop all subkeys created before today. > It seems that the sanest way to do this, which would ease migration for > most users, would be to extend `--export-filter` (and `--import-filter`) Right now only for export filter. We eventually need to to unify those filters. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From wk at gnupg.org Mon Sep 5 10:18:21 2016 From: wk at gnupg.org (Werner Koch) Date: Mon, 05 Sep 2016 10:18:21 +0200 Subject: Stop gpg-agent after inactivity time In-Reply-To: <8c08ce17-9791-5045-9a55-eb0e09e74087@alec.pl> (A. L. E. C.'s message of "Mon, 5 Sep 2016 08:23:22 +0200") References: <99923af9-473e-aa3c-5900-f4a9fc8f33b9@alec.pl> <87eg4zbsm1.fsf@wheatstone.g10code.de> <87d1kja8wo.fsf@wheatstone.g10code.de> <87shte99e7.fsf@wheatstone.g10code.de> <8c08ce17-9791-5045-9a55-eb0e09e74087@alec.pl> Message-ID: <87k2eq7oaa.fsf@wheatstone.g10code.de> On Mon, 5 Sep 2016 08:23, alec at alec.pl said: > Sorry, I might be annoying, but... I don't see --homedir in gpgconf > manual. So, how do I specify which agent to kill? Remember I have --homedir was added in 2.1.13. But you may also use GNUPGHOME. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From gnupg-devel at spodhuis.org Mon Sep 5 20:51:23 2016 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Mon, 5 Sep 2016 18:51:23 +0000 Subject: export-filters act on subkeys? In-Reply-To: <877faq93rw.fsf@wheatstone.g10code.de> References: <20160904232248.GB23840@breadbox.private.spodhuis.org> <877faq93rw.fsf@wheatstone.g10code.de> Message-ID: <20160905185123.GA88512@tower.spodhuis.org> On 2016-09-05 at 09:58 +0200, Werner Koch wrote: > Does this sound okay: > > gpg --export --export-filter drop-subkey='key_algo!=1 && key_algo!=17' Yes! Is this in a branch anywhere, that I might test it? Thanks, -Phil From kristian.fiskerstrand at sumptuouscapital.com Mon Sep 5 20:57:31 2016 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Mon, 5 Sep 2016 20:57:31 +0200 Subject: export-filters act on subkeys? In-Reply-To: <20160905185123.GA88512@tower.spodhuis.org> References: <20160904232248.GB23840@breadbox.private.spodhuis.org> <877faq93rw.fsf@wheatstone.g10code.de> <20160905185123.GA88512@tower.spodhuis.org> Message-ID: <006a600c-3345-6e6d-8862-574b3bbf3cfe@sumptuouscapital.com> On 09/05/2016 08:51 PM, Phil Pennock wrote: > On 2016-09-05 at 09:58 +0200, Werner Koch wrote: >> Does this sound okay: >> >> gpg --export --export-filter drop-subkey='key_algo!=1 && key_algo!=17' > > Yes! > > Is this in a branch anywhere, that I might test it? https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=0a4a03e5310946b0866a0f6a34031eda7a240162 -- ---------------------------- 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 ---------------------------- Veni vidi visa I came, I saw, I bought -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Tue Sep 6 15:55:01 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 06 Sep 2016 09:55:01 -0400 Subject: splitting up an inline-signed OpenPGP message In-Reply-To: <2d9e85fa-d187-8392-35b8-5b36b9df5f66@enigmail.net> References: <87zinn91mv.fsf@alice.fifthhorseman.net> <2d9e85fa-d187-8392-35b8-5b36b9df5f66@enigmail.net> Message-ID: <87y4355e16.fsf@alice.fifthhorseman.net> Thanks to everyone for their feedback on this. The answer was indeed that i had one trailing newline too-many. i didn't need to convert lf ? crlf; gpgv is smart enough to see that a signature is a text signature and handle the line-end munging itself. The resultant code is attached below, in both a perl and a C version. Werner, if you're up for shipping the C version as tools/openpgp-split-clearsigned.c, i'm happy to contribute it to GnuPG. It seems too small for me to be worth packaging and distributing independently. Both versions are GPL v3 or any later version. --dkg -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openpgp-split-clearsigned.c URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openpgp-split-clearsigned.pl URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From wk at gnupg.org Thu Sep 8 00:52:31 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 08 Sep 2016 00:52:31 +0200 Subject: Using --output with --verify Message-ID: <87a8fjxqz4.fsf@wheatstone.g10code.de> Hi, it has been reported that --output has no effect if --verify is used to verify signed data. This is also what the man page says. However, in particular for binary signatures and clearsigs it is useful to get hold of the actual signed data. Thus I slightly changed the semantics of --verify to allow the use of --output. For example by using "--verify --output -" the signed text can be printed to stdout. This change (commit bbe940c) should not introduce problems but if it does, please tell us soon. The next step will be to add an --output option to gpgv. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From dkg at fifthhorseman.net Thu Sep 8 12:36:30 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 08 Sep 2016 12:36:30 +0200 Subject: Using --output with --verify In-Reply-To: <87a8fjxqz4.fsf@wheatstone.g10code.de> References: <87a8fjxqz4.fsf@wheatstone.g10code.de> Message-ID: <87pooefzkh.fsf@alice.fifthhorseman.net> On Thu 2016-09-08 00:52:31 +0200, Werner Koch wrote: > it has been reported that --output has no effect if --verify is used to > verify signed data. This is also what the man page says. However, in > particular for binary signatures and clearsigs it is useful to get hold > of the actual signed data. > > Thus I slightly changed the semantics of --verify to allow the use of > --output. For example by using "--verify --output -" the signed text > can be printed to stdout. This change (commit bbe940c) should not > introduce problems but if it does, please tell us soon. thanks! this change looks good to me. (though i assume that "--output -" is an option, and "--verify" is a command, and gpg docs usually suggest that options should precede the command, so i'd write it as "gpg --output - --verify") This makes a lot more sense than what people have traditionally done (which is using "gpg --decrypt" to verify). In testing this, i noticed that --enable-special-filenames doesn't work right with --output, but that appears to be independent of this patch -- it's present in 2.1.15 as well, so i opened: https://bugs.gnupg.org/gnupg/issue2677 > The next step will be to add an --output option to gpgv. I see you've done this already -- thanks! One issue with the current implementation is how confused it gets if a file already exists, the error message appears to be wrong: 0 dkg at alice:~/tmp/trial$ rm -rf output 0 dkg at alice:~/tmp/trial$ ./g10/gpgv --output output --keyring foo.gpg test.txt.asc gpgv: Signature made Tue 06 Sep 2016 09:53:02 AM CEST gpgv: using RSA key 24ECFF5AFF68370A gpgv: Good signature from "Daniel Kahn Gillmor " 0 dkg at alice:~/tmp/trial$ ./g10/gpgv --output output --keyring foo.gpg test.txt.asc gpgv: handle plaintext failed: General error gpgv: no signature found gpgv: the signature could not be verified. Please remember that the signature file (.sig or .asc) should be the first file given on the command line. 2 dkg at alice:~/tmp/trial$ i think the error message should be something about the output file already existing. it would be nice (but not super important) to add --enable-special-filenames to gpgv as well. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From dkg at fifthhorseman.net Thu Sep 8 14:47:04 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 8 Sep 2016 14:47:04 +0200 Subject: [PATCH] gpg: print fingerprint regardless of keyid-format Message-ID: <20160908124704.6011-1-dkg@fifthhorseman.net> * g10/keylist.c (print_fingerprint): use compact format independent of keyid-format; (print_key_line): always print the fingerprint -- The choice of fingerprint display should be independent of the keyid-format. Currently, the representation of the fingerprint changes depending on whether the user has specified --keyid-format to anything besides "none". (this is common, for example, if someone happens to have "keyid-format long" in their gpg.conf for interoperability with older versions of gpg) With this changeset, keyid-format governs only the format of the displayed keyID, while the fingerprint display is governed only by the fingerprint options: [default]:: compact fpr of pubkey only --with-fingerprint:: human-readable form of fpr of pubkey only --with-fingerprint --with-fingerprint:: human-readable form of pubkey and subkey --with-subkey-fingerprint: compact fpr for pubkey and subkeys Signed-off-by: Daniel Kahn Gillmor --- g10/keylist.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/g10/keylist.c b/g10/keylist.c index a34ef64..dea9b17 100644 --- a/g10/keylist.c +++ b/g10/keylist.c @@ -1677,7 +1677,7 @@ print_fingerprint (estream_t override_fp, PKT_public_key *pk, int mode) } if (!opt.fingerprint && !opt.with_fingerprint - && opt.with_subkey_fingerprint && opt.keyid_format == KF_NONE) + && opt.with_subkey_fingerprint) compact = 1; if (pk->main_keyid[0] == pk->keyid[0] @@ -1869,7 +1869,10 @@ print_key_line (estream_t fp, PKT_public_key *pk, int secret) tty_fprintf (fp, "\n"); - if (pk->flags.primary && opt.keyid_format == KF_NONE) + /* if the user hasn't explicitly asked for human-readable + fingerprints, show compact fpr of primary key: */ + if (pk->flags.primary && + !opt.fingerprint && !opt.with_fingerprint) print_fingerprint (fp, pk, 20); } -- 2.9.3 From dkg at fifthhorseman.net Thu Sep 8 15:21:26 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 8 Sep 2016 15:21:26 +0200 Subject: [PATCH] gpgv: overwrite by default and enable special file descriptors In-Reply-To: <87mvjifryb.fsf@alice.fifthhorseman.net> References: <87mvjifryb.fsf@alice.fifthhorseman.net> Message-ID: <20160908132126.6813-1-dkg@fifthhorseman.net> * g10/gpgv.c (main): default to overwriting files with gpgv --output, and enable special filenames. * doc/gpgv.texi: document these changes. Signed-off-by: Daniel Kahn Gillmor --- doc/gpgv.texi | 11 +++++++---- g10/gpgv.c | 6 ++---- 2 files changed, 9 insertions(+), 8 deletions(-) diff --git a/doc/gpgv.texi b/doc/gpgv.texi index 6676bde..668b97b 100644 --- a/doc/gpgv.texi +++ b/doc/gpgv.texi @@ -95,12 +95,15 @@ home-directory ("~/.gnupg" if --homedir is not used). @item --output @var{file} @itemx -o @var{file} @opindex output -Write output to @var{file}. This option can be used to get the signed +Write data to @var{file}. This option can be used to get the signed text from a cleartext or binary signature; it also works for detached signatures, but in that case this option is in general not -useful. Unless you write to stdout (using @code{-} for @var{file}) you -should also use the option @option{--yes} to force overwriting an -existing file. +useful. To write to stdout, use @code{-} for @var{file}. To +write to any file descriptor, use the form @file{-&n}, where n is a +non-negative decimal number. + +Note that @var{gpgv} will overwrite any @{file} identified by + at code{--output} if @var{file} already exists. @item --status-fd @var{n} @opindex status-fd diff --git a/g10/gpgv.c b/g10/gpgv.c index aa1fcea..d19b28f 100644 --- a/g10/gpgv.c +++ b/g10/gpgv.c @@ -63,8 +63,6 @@ enum cmd_and_opt_values { oLoggerFD, oHomedir, oWeakDigest, - oAnswerYes, - oAnswerNo, aTest }; @@ -85,7 +83,6 @@ static ARGPARSE_OPTS opts[] = { ARGPARSE_s_s (oHomedir, "homedir", "@"), ARGPARSE_s_s (oWeakDigest, "weak-digest", N_("|ALGO|reject signatures made with ALGO")), - ARGPARSE_s_n (oAnswerYes, "yes", "@"), ARGPARSE_end () }; @@ -170,6 +167,8 @@ main( int argc, char **argv ) opt.no_sig_cache = 1; opt.flags.require_cross_cert = 1; opt.batch = 1; + opt.answer_yes = 1; + iobuf_enable_special_filenames (1); opt.weak_digests = NULL; @@ -194,7 +193,6 @@ main( int argc, char **argv ) break; case oKeyring: append_to_strlist( &nrings, pargs.r.ret_str); break; case oOutput: opt.outfile = pargs.r.ret_str; break; - case oAnswerYes: opt.answer_yes = 1; break; case oStatusFD: set_status_fd( pargs.r.ret_int ); break; case oLoggerFD: log_set_fd (translate_sys2libc_fd_int (pargs.r.ret_int, 1)); -- 2.9.3 From dkg at fifthhorseman.net Thu Sep 8 15:21:00 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 08 Sep 2016 15:21:00 +0200 Subject: Using --output with --verify In-Reply-To: <87pooefzkh.fsf@alice.fifthhorseman.net> References: <87a8fjxqz4.fsf@wheatstone.g10code.de> <87pooefzkh.fsf@alice.fifthhorseman.net> Message-ID: <87mvjifryb.fsf@alice.fifthhorseman.net> On Thu 2016-09-08 12:36:30 +0200, Daniel Kahn Gillmor wrote: > On Thu 2016-09-08 00:52:31 +0200, Werner Koch wrote: >> The next step will be to add an --output option to gpgv. > > I see you've done this already -- thanks! One issue with the current > implementation is how confused it gets if a file already exists, the > error message appears to be wrong: > > 0 dkg at alice:~/tmp/trial$ rm -rf output > 0 dkg at alice:~/tmp/trial$ ./g10/gpgv --output output --keyring foo.gpg test.txt.asc > gpgv: Signature made Tue 06 Sep 2016 09:53:02 AM CEST > gpgv: using RSA key 24ECFF5AFF68370A > gpgv: Good signature from "Daniel Kahn Gillmor " > 0 dkg at alice:~/tmp/trial$ ./g10/gpgv --output output --keyring foo.gpg test.txt.asc > gpgv: handle plaintext failed: General error > gpgv: no signature found > gpgv: the signature could not be verified. > Please remember that the signature file (.sig or .asc) > should be the first file given on the command line. > 2 dkg at alice:~/tmp/trial$ > > i think the error message should be something about the output file > already existing. hm, i see that you added --yes to gpgv in order to be able to override the output file. I think we should remove the --yes option entirely, and just set it to true. if the user does "gpgv --output foo data" then gpgv will wipe foo and output the signed data to it. > it would be nice (but not super important) to add > --enable-special-filenames to gpgv as well. I also changed my mind on this. I don't think introducing a new option for gpgv is the right way to go; instead, i think --enable-special-filenames should always be set for gpgv. I'll send a patch with these changes shortly. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From wk at gnupg.org Thu Sep 8 15:35:31 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 08 Sep 2016 15:35:31 +0200 Subject: [PATCH] gpgv: overwrite by default and enable special file descriptors In-Reply-To: <20160908132126.6813-1-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 8 Sep 2016 15:21:26 +0200") References: <87mvjifryb.fsf@alice.fifthhorseman.net> <20160908132126.6813-1-dkg@fifthhorseman.net> Message-ID: <87pooev7j0.fsf@wheatstone.g10code.de> Hi, thanks fo the patch. However, during the last talk I did the same and pushed that before reading mails. I also figured out the reason for the file descriptor not working for --output. Fix is a bit more complicated and I should not do that while listening to a talk. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From matan.nassau at gmail.com Thu Sep 8 20:01:37 2016 From: matan.nassau at gmail.com (Matan Nassau) Date: Thu, 08 Sep 2016 18:01:37 +0000 Subject: New pinentry program Message-ID: Hello. How do I build a new pinentry program? I understand I need to link against libpinentry. I don't think I need the entire pinentry distribution to build as part of my build, just the library part, right? I tried to include in my project only pinentry.{h,c} argparse.{h,c} and secmem. But when I try to build without any of the front ends, I fail at link time because of (at least) missing pinentry handle function pointer symbol. When I try to build the distribution pinentry without any of the front ends, the configure script insists that I build at least one front end. Is it possible to get libpinentry without any of the front ends, so I can link against it my own front end? Matan -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Fri Sep 9 08:39:58 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 09 Sep 2016 08:39:58 +0200 Subject: [PATCH] gpg: print fingerprint regardless of keyid-format In-Reply-To: <20160908124704.6011-1-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 8 Sep 2016 14:47:04 +0200") References: <20160908124704.6011-1-dkg@fifthhorseman.net> Message-ID: <87sht9tw3l.fsf@wheatstone.g10code.de> On Thu, 8 Sep 2016 14:47, dkg at fifthhorseman.net said: > * g10/keylist.c (print_fingerprint): use compact format independent of > keyid-format; (print_key_line): always print the fingerprint Pushed. Thanks. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From dkg at fifthhorseman.net Fri Sep 9 10:43:46 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 9 Sep 2016 10:43:46 +0200 Subject: [PINENTRY PATCH v2 2/2] pinentry-gnome3: fall back to curses if gcr prompt creation fails In-Reply-To: <20160909084346.27394-1-dkg@fifthhorseman.net> References: <20160829235548.17173-1-dkg@fifthhorseman.net> <20160909084346.27394-1-dkg@fifthhorseman.net> Message-ID: <20160909084346.27394-2-dkg@fifthhorseman.net> * gnome3/pinentry-gnome3.c (create_prompt): if gcr_prompt_prompt_open fails, fall back to using curses for this phase. (gnome3_cmd_handler): pass through responses from curses, if used. In some cases, the user is running in a session that has an active D-Bus session, but that session is not attached to a graphical desktop environment (e.g. sshing into a machine whose login stack initializes a D-Bus session). In that case, gcr can be reached over dbus, but it will complain that it does not know how to prompt the user. In this case, pinentry-gnome3 should fall back to curses for prompting the user. Signed-off-by: Daniel Kahn Gillmor --- gnome3/pinentry-gnome3.c | 24 +++++++++++++++++++++--- 1 file changed, 21 insertions(+), 3 deletions(-) diff --git a/gnome3/pinentry-gnome3.c b/gnome3/pinentry-gnome3.c index 95449da..3aabb91 100644 --- a/gnome3/pinentry-gnome3.c +++ b/gnome3/pinentry-gnome3.c @@ -69,12 +69,20 @@ pinentry_utf8_validate (gchar *text) return result; } +struct curses_ret +{ + int curses_used; + int curses_returned; +}; + static GcrPrompt * -create_prompt (pinentry_t pe, int confirm) +create_prompt (pinentry_t pe, int confirm, struct curses_ret *c) { GcrPrompt *prompt; GError *error = NULL; char *msg; + if (c) + c->curses_used = 0; /* Create the prompt. */ prompt = GCR_PROMPT (gcr_system_prompt_open (-1, NULL, &error)); @@ -83,6 +91,10 @@ create_prompt (pinentry_t pe, int confirm) fprintf (stderr, "couldn't create prompt for gnupg passphrase: %s", error->message); g_error_free (error); + if (c) { + c->curses_used = 1; + c->curses_returned = curses_cmd_handler (pe); + } return NULL; } @@ -169,16 +181,20 @@ gnome3_cmd_handler (pinentry_t pe) GcrPrompt *prompt = NULL; GError *error = NULL; int ret = -1; + struct curses_ret c; + c.curses_used = 0; if (pe->pin) /* Passphrase mode. */ { const char *password; - prompt = create_prompt (pe, 0); + prompt = create_prompt (pe, 0, &c); if (! prompt) /* Something went wrong. */ { + if (c.curses_used) + return c.curses_returned; pe->canceled = 1; return -1; } @@ -218,10 +234,12 @@ gnome3_cmd_handler (pinentry_t pe) { GcrPromptReply reply; - prompt = create_prompt (pe, 1); + prompt = create_prompt (pe, 1, &c); if (! prompt) /* Something went wrong. */ { + if (c.curses_used) + return c.curses_returned; pe->canceled = 1; return -1; } -- 2.9.3 From dkg at fifthhorseman.net Fri Sep 9 10:43:45 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 9 Sep 2016 10:43:45 +0200 Subject: [PINENTRY PATCH v2 1/2] gnome3: drop unnecessary use of gtk In-Reply-To: <20160829235548.17173-1-dkg@fifthhorseman.net> References: <20160829235548.17173-1-dkg@fifthhorseman.net> Message-ID: <20160909084346.27394-1-dkg@fifthhorseman.net> * configure.ac: pinentry-gnome3 only needs gcr-base, not gcr. * gnome3/pinentry-gnome3.c (main): instead of testing whether GTK can * be loaded, check for DBUS_SESSION_BUS_ADDRESS, (create_prompt): use * fprintf (stderr, ...) instead of g_warning (...), to align with the * rest of pinentry.c. pinentry-gnome3 really just uses gcr and libsecret -- there is no direct use of gtk at all. By linking only to the minimal gcr-base-3 and avoiding gcr-3 itself, we remove many unnecessary library dependencies from pinentry-gnome3. Specifically, "ldd $(which pinentry-gnome3) | wc -l" goes from 69 to 23 on debian testing. Signed-off-by: Daniel Kahn Gillmor --- configure.ac | 8 ++++---- gnome3/pinentry-gnome3.c | 16 ++++++---------- 2 files changed, 10 insertions(+), 14 deletions(-) diff --git a/configure.ac b/configure.ac index 41e9d93..1620ebd 100644 --- a/configure.ac +++ b/configure.ac @@ -476,15 +476,15 @@ AM_CONDITIONAL(BUILD_PINENTRY_GTK_2, test "$pinentry_gtk_2" = "yes") if test "$pinentry_gnome_3" != "no"; then AC_MSG_CHECKING([for gcr]) - "${PKG_CONFIG}" --exists gcr-3,gcr-base-3 + "${PKG_CONFIG}" --exists gcr-base-3 if test $? -ne 0 ; then AC_MSG_RESULT([no]) - AC_MSG_WARN([pkg-config could not find the module gcr-3,gcr-base-3]) + AC_MSG_WARN([pkg-config could not find the module gcr-base-3]) pinentry_gnome_3=no else AC_MSG_RESULT([yes]) - GNOME3CFLAGS=`"${PKG_CONFIG}" --cflags gcr-3,gcr-base-3` - GNOME3LIBS=`"${PKG_CONFIG}" --libs gcr-3,gcr-base-3` + GNOME3CFLAGS=`"${PKG_CONFIG}" --cflags gcr-base-3` + GNOME3LIBS=`"${PKG_CONFIG}" --libs gcr-base-3` AC_SUBST(GNOME3CFLAGS) AC_SUBST(GNOME3LIBS) AC_DEFINE(GCR_API_SUBJECT_TO_CHANGE, 1, [Nod nod]) diff --git a/gnome3/pinentry-gnome3.c b/gnome3/pinentry-gnome3.c index 8f91cb8..95449da 100644 --- a/gnome3/pinentry-gnome3.c +++ b/gnome3/pinentry-gnome3.c @@ -22,10 +22,10 @@ # include "config.h" #endif -#include #include #include +#include #include @@ -80,7 +80,7 @@ create_prompt (pinentry_t pe, int confirm) prompt = GCR_PROMPT (gcr_system_prompt_open (-1, NULL, &error)); if (! prompt) { - g_warning ("couldn't create prompt for gnupg passphrase: %s", + fprintf (stderr, "couldn't create prompt for gnupg passphrase: %s", error->message); g_error_free (error); return NULL; @@ -185,7 +185,7 @@ gnome3_cmd_handler (pinentry_t pe) /* "The returned password is valid until the next time a method is called to display another prompt." */ - password = gcr_prompt_password_run (prompt, NULL, &error); + password = gcr_prompt_password (prompt, NULL, &error); if (error) /* Error. */ { @@ -261,15 +261,11 @@ main (int argc, char *argv[]) pinentry_init (PGMNAME); #ifdef FALLBACK_CURSES - if (pinentry_have_display (argc, argv)) + if (!getenv ("DBUS_SESSION_BUS_ADDRESS")) { - if (! gtk_init_check (&argc, &argv)) - pinentry_cmd_handler = curses_cmd_handler; + fprintf (stderr, "No $DBUS_SESSION_BUS_ADDRESS found, falling back to curses\n"); + pinentry_cmd_handler = curses_cmd_handler; } - else - pinentry_cmd_handler = curses_cmd_handler; -#else - gtk_init (&argc, &argv); #endif pinentry_parse_opts (argc, argv); -- 2.9.3 From matan.nassau at gmail.com Fri Sep 9 14:52:44 2016 From: matan.nassau at gmail.com (Matan Nassau) Date: Fri, 9 Sep 2016 08:52:44 -0400 Subject: New pinentry program In-Reply-To: References: Message-ID: I think I worked it out. It seems I can't link libpinentry against a library, but I must link it against my executable, where I provide the handler. Then I don't need any of the pre-existing front-ends. On Thu, Sep 8, 2016 at 2:01 PM, Matan Nassau wrote: > Hello. > > How do I build a new pinentry program? I understand I need to link against > libpinentry. I don't think I need the entire pinentry distribution to build > as part of my build, just the library part, right? > > I tried to include in my project only pinentry.{h,c} argparse.{h,c} and > secmem. But when I try to build without any of the front ends, I fail at > link time because of (at least) missing pinentry handle function pointer > symbol. > > When I try to build the distribution pinentry without any of the front > ends, the configure script insists that I build at least one front end. > > Is it possible to get libpinentry without any of the front ends, so I can > link against it my own front end? > > > Matan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at mit.edu Mon Sep 12 03:18:24 2016 From: uri at mit.edu (Uri Blumenthal) Date: Mon, 12 Sep 2016 01:18:24 +0000 Subject: Add option for scdaemon to open smart card in non-exclusive mode Message-ID: <9E4086BE-CEFB-43EB-9874-51C2B7F09DDE@mit.edu> I use a token that has both PIV and OpenPGP applets provisioned. Some of my emails are secured by PGP/MIME, and others by S/MIME (depending on the crowd I?m communicating with, not surprisingly). The problem is that scdaemon insists on grabbing the token, so first - it refuses to access it when another daemon (tokend in this case) is connected to it (tokend on Mac OS X is the daemon that makes the token available to all the native OS X applications, such as Safari, Google Chrome, Apple Mail, MS Outlook, Adobe Acrobat, Keychain Access, etc. etc.). Tokend is talking to PIV applet. So the way it is now, I have to kill tokend in order for scdaemon to access the card. And then there?s no way for tokend to get back to it until the card is re-inserted. Here? where it is really inconvenient. My ideal workflow in processing emails would be - use whatever standard the given email came in under and respond in kind. Just like with soft certificates and keys. The way it is with scdaemon now, however, I have to process all the S/MIME emails first, then kill tokend, exit Apple Mail, make sure gpg2 can access the card, start Apple Mail, process PGP/MIME emails, quit Apple Mail, remove the card. Since the token is used for things other than email, it is really inconvenient, and for no real security benefit. What I am asking for: add a configuration option that would tell scdaemon to open the token in non-exclusive (shared) mode. Keep it off by default. But those who (like me) have need to use multi-applet tokens, would be able to have a smooth workflow. This has already been brought up by Martin Paljak in 2011: https://lists.gnupg.org/pipermail/gnupg-devel/2011-August/026210.html . I think it?s time we do that now. P.S. Proposed timeout setting does not solve the problem, because timeout appears to be for powering the card down. This does not help - the card should stay powered up. -- Uri Blumenthal uri at mit.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at adversary.org Mon Sep 12 11:37:14 2016 From: ben at adversary.org (Ben McGinnes) Date: Mon, 12 Sep 2016 19:37:14 +1000 Subject: Using --output with --verify In-Reply-To: <87a8fjxqz4.fsf@wheatstone.g10code.de> References: <87a8fjxqz4.fsf@wheatstone.g10code.de> Message-ID: <20160912093714.GD72702@adversary.org> On Thu, Sep 08, 2016 at 12:52:31AM +0200, Werner Koch wrote: > Hi, > > it has been reported that --output has no effect if --verify is used to > verify signed data. This is also what the man page says. However, in > particular for binary signatures and clearsigs it is useful to get hold > of the actual signed data. > > Thus I slightly changed the semantics of --verify to allow the use of > --output. For example by using "--verify --output -" the signed text > can be printed to stdout. This change (commit bbe940c) should not > introduce problems but if it does, please tell us soon. > > The next step will be to add an --output option to gpgv. Wouldn't it be better to output message data like that (basically anything GPG might otherwise report to stdout or stderr) using a different flag so that the same verification data could be captured separately when verifying a signed and encrypted file as well? Something like: gpg --message msgreport.txt --output file.txt --decrypt file.txt.asc That would also avoid confusion amongst end users regarding precisely what the --output flag does and what the new function dows. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: not available URL: From astieger at suse.com Mon Sep 12 13:34:23 2016 From: astieger at suse.com (Andreas Stieger) Date: Mon, 12 Sep 2016 13:34:23 +0200 Subject: interleaving lines of stdout with status when using --status-fd 1 Message-ID: <28c7870b-f6b7-8b9b-03ed-87ac5468d1ed@suse.com> Hello, I have an issue with 2.1.15 when printing status information to stdout. After ff71521d9698c7c5df94831a1398e948213af433, print_status_key_considered is called in the middle of printing a line in the output of --list-public-keys (--with-colons, -fixed-lost-mode, --with-dig-list). Even though use --status-fd 1 can be considered to do exactly what is sais on the tin, there are some usages: Some usages: https://github.com/search?utf8=?&q=--status-fd&type=Code Would you say that it would be beneficial to some library usages to flush the previous line, or print the status line after the regular list output has finished a line in stdout? Output is as follows: + gpg2 --import --homedir /tmp/tmp.8a043nlHjQ --no-default-keyring --quiet --no-tty --no-greeting --no-permission-warning --status-fd 1 /tmp/tmp.8a043nlHjQ/test.key [GNUPG:] KEY_CONSIDERED D7DD7C85D9598661D889F8C092AB3F6E6CB7B81F 0 [GNUPG:] IMPORTED 92AB3F6E6CB7B81F home:AndreasStieger OBS Project [GNUPG:] IMPORT_OK 1 D7DD7C85D9598661D889F8C092AB3F6E6CB7B81F [GNUPG:] IMPORT_RES 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 + gpg --list-public-keys --homedir /tmp/tmp.8a043nlHjQ --no-default-keyring --quiet --with-colons --fixed-list-mode --with-fingerprint --with-sig-list --no-tty --no-greeting --batch --status-fd 1 tru::1:1473679477:0:3:1:5 pub:-:1024:17:92AB3F6E6CB7B81F:1217757506:1474311950::-:::scSC::::::: fpr:::::::::D7DD7C85D9598661D889F8C092AB3F6E6CB7B81F: uid:-::::1405191950::1371C6CD4E3A77BDA5CFBE1C940ACD55D2895B25::home\x3aAndreasStieger OBS Project ::::::::: sig:::17:92AB3F6E6CB7B81F:1405191950::::[GNUPG:] KEY_CONSIDERED D7DD7C85D9598661D889F8C092AB3F6E6CB7B81F 0 home\x3aAndreasStieger OBS Project :13x:::::2: sig:::17:3B3011B76B9D6523:1217757506::::[User ID not found]:13x:::::2: The following would be suggested: tru::1:1473679477:0:3:1:5 pub:-:1024:17:92AB3F6E6CB7B81F:1217757506:1474311950::-:::scSC::::::: fpr:::::::::D7DD7C85D9598661D889F8C092AB3F6E6CB7B81F: uid:-::::1405191950::1371C6CD4E3A77BDA5CFBE1C940ACD55D2895B25::home\x3aAndreasStieger OBS Project ::::::::: sig:::17:92AB3F6E6CB7B81F:1405191950::::home\x3aAndreasStieger OBS Project :13x:::::2: [GNUPG:] KEY_CONSIDERED D7DD7C85D9598661D889F8C092AB3F6E6CB7B81F 0 sig:::17:3B3011B76B9D6523:1217757506::::[User ID not found]:13x:::::2: Reproducer script: #!/bin/sh -x TMPHOME=`mktemp -d` wget -O $TMPHOME/test.key http://download.opensuse.org/repositories/home:/AndreasStieger/openSUSE_Leap_42.1/repodata/repomd.xml.key gpg2 --import --homedir $TMPHOME --no-default-keyring --quiet --no-tty --no-greeting --no-permission-warning --status-fd 1 $TMPHOME/test.key gpg --list-public-keys --homedir $TMPHOME --no-default-keyring --quiet --with-colons --fixed-list-mode --with-fingerprint --with-sig-list --no-tty --no-greeting --batch --status-fd 1 Thanks, Andreas -- Andreas Stieger Project Manager Security SUSE Linux GmbH, GF: Felix Imend?rffer, Jane Smithard, Graham Norton, HRB 21284 (AG N?rnberg) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Mon Sep 12 17:50:11 2016 From: wk at gnupg.org (Werner Koch) Date: Mon, 12 Sep 2016 17:50:11 +0200 Subject: interleaving lines of stdout with status when using --status-fd 1 In-Reply-To: <28c7870b-f6b7-8b9b-03ed-87ac5468d1ed@suse.com> (Andreas Stieger's message of "Mon, 12 Sep 2016 13:34:23 +0200") References: <28c7870b-f6b7-8b9b-03ed-87ac5468d1ed@suse.com> Message-ID: <87twdlm824.fsf@wheatstone.g10code.de> On Mon, 12 Sep 2016 13:34, astieger at suse.com said: > print_status_key_considered is called in the middle of printing a line > in the output of --list-public-keys (--with-colons, -fixed-lost-mode, > --with-dig-list). The same happens with "pub" and KEYEXPIRED. Thanks for reporting; I pushed a fix (commit 31fc420). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From dkg at fifthhorseman.net Tue Sep 13 08:09:58 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 13 Sep 2016 08:09:58 +0200 Subject: [PATCH] tests/openpgp: Provide fake pinentries for downstream developers. Message-ID: <20160913060958.30933-1-dkg@fifthhorseman.net> * tests/openpgp/fake-pinentries/README.txt and tests/openpgp/fake-pinentries/fake-pinentry.{sh,py,pl,php}}: New public domain files to encourage better test suite practices from downstream developers. Signed-off-by: Daniel Kahn Gillmor --- tests/openpgp/fake-pinentries/README.txt | 28 ++++++++++++++++++++ tests/openpgp/fake-pinentries/fake-pinentry.php | 25 ++++++++++++++++++ tests/openpgp/fake-pinentries/fake-pinentry.pl | 28 ++++++++++++++++++++ tests/openpgp/fake-pinentries/fake-pinentry.py | 29 +++++++++++++++++++++ tests/openpgp/fake-pinentries/fake-pinentry.sh | 34 +++++++++++++++++++++++++ 5 files changed, 144 insertions(+) create mode 100644 tests/openpgp/fake-pinentries/README.txt create mode 100755 tests/openpgp/fake-pinentries/fake-pinentry.php create mode 100755 tests/openpgp/fake-pinentries/fake-pinentry.pl create mode 100755 tests/openpgp/fake-pinentries/fake-pinentry.py create mode 100755 tests/openpgp/fake-pinentries/fake-pinentry.sh diff --git a/tests/openpgp/fake-pinentries/README.txt b/tests/openpgp/fake-pinentries/README.txt new file mode 100644 index 0000000..7a08b32 --- /dev/null +++ b/tests/openpgp/fake-pinentries/README.txt @@ -0,0 +1,28 @@ +Fake Pinentries for Test Suites +=============================== + +If you're writing a test suite, it should use one of these pinentries +by setting the following line in $GNUPGHOME/gpg-agent.conf: + + pinentry-program /path/to/fake-pinentry.ext + +Note that different fake-pinentry programs have been supplied here in +different languages, with the intent of making them available to +developers who have different languages available. + +They are in the public domain, so they should be reusable by any +project. Feel free to copy them into your own project's test suite. + +Rationale +--------- + +If you're implementing software that uses GnuPG, you probably want a +test suite that exercises your code, and you may have some that +involve secret key material locked with a passphrase. However, you +don't want to require your developers to manually enter a passphrase +while tests are run, and you probably also don't want to deal with +alternate codepaths/workflows like using gpg's loopback pinentry. + +The solution for this is to use a fake pinentry in your test suite, +one that simply returns a pre-selected passphrase. In this case, all +the other code is the diff --git a/tests/openpgp/fake-pinentries/fake-pinentry.php b/tests/openpgp/fake-pinentries/fake-pinentry.php new file mode 100755 index 0000000..2d8f2c8 --- /dev/null +++ b/tests/openpgp/fake-pinentries/fake-pinentry.php @@ -0,0 +1,25 @@ +#!/usr/bin/php +# Use this for your test suites when a PHP interpreter is available. +# +# The encrypted keys in your test suite that you expect to work must +# be locked with a passphrase of "passphrase" +# +# Author: Daniel Kahn Gillmor +# +# License: This trivial work is hereby explicitly placed into the +# public domain. Anyone may reuse it, modify it, redistribute it for +# any purpose. + + \ No newline at end of file diff --git a/tests/openpgp/fake-pinentries/fake-pinentry.pl b/tests/openpgp/fake-pinentries/fake-pinentry.pl new file mode 100755 index 0000000..250b27c --- /dev/null +++ b/tests/openpgp/fake-pinentries/fake-pinentry.pl @@ -0,0 +1,28 @@ +#!/usr/bin/perl -w +# Use this for your test suites when a perl interpreter is available. +# +# The encrypted keys in your test suite that you expect to work must +# be locked with a passphrase of "passphrase" +# +# Author: Daniel Kahn Gillmor +# +# License: This trivial work is hereby explicitly placed into the +# public domain. Anyone may reuse it, modify it, redistribute it for +# any purpose. + +use strict; +use warnings; + +# turn off buffering +$| = 1; + +print "OK This is only for test suites, and should never be used in production\n"; +while () { + chomp; + next if (/^$/); + next if (/^#/) + print ("D passphrase\n") if (/^getpin/i); + print "OK\n"; + exit if (/^bye/i); +} +1; diff --git a/tests/openpgp/fake-pinentries/fake-pinentry.py b/tests/openpgp/fake-pinentries/fake-pinentry.py new file mode 100755 index 0000000..57d6941 --- /dev/null +++ b/tests/openpgp/fake-pinentries/fake-pinentry.py @@ -0,0 +1,29 @@ +#!/usr/bin/env python +# Use this for your test suites when a python interpreter is available. +# +# The encrypted keys in your test suite that you expect to work must +# be locked with a passphrase of "passphrase" +# +# Author: Daniel Kahn Gillmor +# +# License: This trivial work is hereby explicitly placed into the +# public domain. Anyone may reuse it, modify it, redistribute it for +# any purpose. + +import sys, os + +# turn off buffering: +sys.stdin = os.fdopen(sys.stdin.fileno(), 'r', 0) +sys.stdout = os.fdopen(sys.stdout.fileno(), 'w', 0) + +print("OK This is only for test suites, and should never be used in production") +while True: + ln = sys.stdin.readline().lower() + if (ln.strip() == '') or (ln.startswith('#')): + continue + if (ln.startswith('getpin')): + sys.stdout.write('D passphrase\n') + sys.stdout.write('OK\n') + if (ln.startswith('bye')): + break + diff --git a/tests/openpgp/fake-pinentries/fake-pinentry.sh b/tests/openpgp/fake-pinentries/fake-pinentry.sh new file mode 100755 index 0000000..57bbf91 --- /dev/null +++ b/tests/openpgp/fake-pinentries/fake-pinentry.sh @@ -0,0 +1,34 @@ +#!/bin/sh +# Use this for your test suites when a POSIX shell is available. +# +# The encrypted keys in your test suite that you expect to work must +# be locked with a passphrase of "passphrase" +# +# Author: Daniel Kahn Gillmor +# +# License: This trivial work is hereby explicitly placed into the +# public domain. Anyone may reuse it, modify it, redistribute it for +# any purpose. + +echo "OK This is only for test suites, and should never be used in production" +while read cmd rest; do + cmd=$(printf "%s" "$cmd" | tr 'A-Z' 'a-z') + if [ -z "$cmd" ]; then + continue; + fi + case "$cmd" in + \#*) + ;; + getpin) + echo "D passphrase" + echo "OK" + ;; + bye) + echo "OK" + exit 0 + ;; + *) + echo "OK" + ;; + esac +done -- 2.9.3 From dkg at fifthhorseman.net Tue Sep 13 09:52:42 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 13 Sep 2016 09:52:42 +0200 Subject: [PATCH v2] tests/openpgp: Provide fake pinentries for downstream developers. In-Reply-To: <20160913060958.30933-1-dkg@fifthhorseman.net> References: <20160913060958.30933-1-dkg@fifthhorseman.net> Message-ID: <20160913075242.4544-1-dkg@fifthhorseman.net> * tests/openpgp/fake-pinentries/README.txt and tests/openpgp/fake-pinentries/fake-pinentry.{sh,py,pl,php}}: New public domain files to encourage better test suite practices from downstream developers. Signed-off-by: Daniel Kahn Gillmor --- tests/openpgp/fake-pinentries/README.txt | 28 ++++++++++++++++++++ tests/openpgp/fake-pinentries/fake-pinentry.php | 28 ++++++++++++++++++++ tests/openpgp/fake-pinentries/fake-pinentry.pl | 28 ++++++++++++++++++++ tests/openpgp/fake-pinentries/fake-pinentry.py | 32 +++++++++++++++++++++++ tests/openpgp/fake-pinentries/fake-pinentry.sh | 34 +++++++++++++++++++++++++ 5 files changed, 150 insertions(+) create mode 100644 tests/openpgp/fake-pinentries/README.txt create mode 100755 tests/openpgp/fake-pinentries/fake-pinentry.php create mode 100755 tests/openpgp/fake-pinentries/fake-pinentry.pl create mode 100755 tests/openpgp/fake-pinentries/fake-pinentry.py create mode 100755 tests/openpgp/fake-pinentries/fake-pinentry.sh This includes minor embarrassing bugfixes for the .php, .py, and .pl fake-pinentry implementations. diff --git a/tests/openpgp/fake-pinentries/README.txt b/tests/openpgp/fake-pinentries/README.txt new file mode 100644 index 0000000..7a08b32 --- /dev/null +++ b/tests/openpgp/fake-pinentries/README.txt @@ -0,0 +1,28 @@ +Fake Pinentries for Test Suites +=============================== + +If you're writing a test suite, it should use one of these pinentries +by setting the following line in $GNUPGHOME/gpg-agent.conf: + + pinentry-program /path/to/fake-pinentry.ext + +Note that different fake-pinentry programs have been supplied here in +different languages, with the intent of making them available to +developers who have different languages available. + +They are in the public domain, so they should be reusable by any +project. Feel free to copy them into your own project's test suite. + +Rationale +--------- + +If you're implementing software that uses GnuPG, you probably want a +test suite that exercises your code, and you may have some that +involve secret key material locked with a passphrase. However, you +don't want to require your developers to manually enter a passphrase +while tests are run, and you probably also don't want to deal with +alternate codepaths/workflows like using gpg's loopback pinentry. + +The solution for this is to use a fake pinentry in your test suite, +one that simply returns a pre-selected passphrase. In this case, all +the other code is the diff --git a/tests/openpgp/fake-pinentries/fake-pinentry.php b/tests/openpgp/fake-pinentries/fake-pinentry.php new file mode 100755 index 0000000..d6c0a8c --- /dev/null +++ b/tests/openpgp/fake-pinentries/fake-pinentry.php @@ -0,0 +1,28 @@ +#!/usr/bin/php + +# +# License: This trivial work is hereby explicitly placed into the +# public domain. Anyone may reuse it, modify it, redistribute it for +# any purpose. + +print("OK This is only for test suites, and should never be used in production\n"); +while (true) { + $line = fgets(STDIN); + if (False === $line) + break; + $line = strtolower(trim($line)); + if (($line === "") || ($line[0] == '#')) + continue; + if ((0 === strncmp("getpin", $line, 6))) + print("D passphrase\n"); + print("OK\n"); + if ((0 === strncmp("bye", $line, 3))) + break; +} +?> \ No newline at end of file diff --git a/tests/openpgp/fake-pinentries/fake-pinentry.pl b/tests/openpgp/fake-pinentries/fake-pinentry.pl new file mode 100755 index 0000000..1eff277 --- /dev/null +++ b/tests/openpgp/fake-pinentries/fake-pinentry.pl @@ -0,0 +1,28 @@ +#!/usr/bin/perl -w +# Use this for your test suites when a perl interpreter is available. +# +# The encrypted keys in your test suite that you expect to work must +# be locked with a passphrase of "passphrase" +# +# Author: Daniel Kahn Gillmor +# +# License: This trivial work is hereby explicitly placed into the +# public domain. Anyone may reuse it, modify it, redistribute it for +# any purpose. + +use strict; +use warnings; + +# turn off buffering +$| = 1; + +print "OK This is only for test suites, and should never be used in production\n"; +while () { + chomp; + next if (/^$/); + next if (/^#/); + print ("D passphrase\n") if (/^getpin/i); + print "OK\n"; + exit if (/^bye/i); +} +1; diff --git a/tests/openpgp/fake-pinentries/fake-pinentry.py b/tests/openpgp/fake-pinentries/fake-pinentry.py new file mode 100755 index 0000000..f7eff1f --- /dev/null +++ b/tests/openpgp/fake-pinentries/fake-pinentry.py @@ -0,0 +1,32 @@ +#!/usr/bin/env python +# Use this for your test suites when a python interpreter is available. +# +# The encrypted keys in your test suite that you expect to work must +# be locked with a passphrase of "passphrase" +# +# Author: Daniel Kahn Gillmor +# +# License: This trivial work is hereby explicitly placed into the +# public domain. Anyone may reuse it, modify it, redistribute it for +# any purpose. + +import sys, os + +# turn off buffering: +sys.stdin = os.fdopen(sys.stdin.fileno(), 'r', 0) +sys.stdout = os.fdopen(sys.stdout.fileno(), 'w', 0) + +print("OK This is only for test suites, and should never be used in production") +while True: + ln = sys.stdin.readline() + if (ln == ''): + break + ln = ln.lower() + if (ln.strip() == '') or (ln.startswith('#')): + continue + if (ln.startswith('getpin')): + sys.stdout.write('D passphrase\n') + sys.stdout.write('OK\n') + if (ln.startswith('bye')): + break + diff --git a/tests/openpgp/fake-pinentries/fake-pinentry.sh b/tests/openpgp/fake-pinentries/fake-pinentry.sh new file mode 100755 index 0000000..57bbf91 --- /dev/null +++ b/tests/openpgp/fake-pinentries/fake-pinentry.sh @@ -0,0 +1,34 @@ +#!/bin/sh +# Use this for your test suites when a POSIX shell is available. +# +# The encrypted keys in your test suite that you expect to work must +# be locked with a passphrase of "passphrase" +# +# Author: Daniel Kahn Gillmor +# +# License: This trivial work is hereby explicitly placed into the +# public domain. Anyone may reuse it, modify it, redistribute it for +# any purpose. + +echo "OK This is only for test suites, and should never be used in production" +while read cmd rest; do + cmd=$(printf "%s" "$cmd" | tr 'A-Z' 'a-z') + if [ -z "$cmd" ]; then + continue; + fi + case "$cmd" in + \#*) + ;; + getpin) + echo "D passphrase" + echo "OK" + ;; + bye) + echo "OK" + exit 0 + ;; + *) + echo "OK" + ;; + esac +done -- 2.9.3 From justus at g10code.com Tue Sep 13 09:44:15 2016 From: justus at g10code.com (Justus Winter) Date: Tue, 13 Sep 2016 09:44:15 +0200 Subject: [PATCH] tests/openpgp: Provide fake pinentries for downstream developers. In-Reply-To: <20160913060958.30933-1-dkg@fifthhorseman.net> References: <20160913060958.30933-1-dkg@fifthhorseman.net> Message-ID: <878tuwgs6o.fsf@europa.jade-hamburg.de> Hi, Daniel Kahn Gillmor writes: > * tests/openpgp/fake-pinentries/README.txt and > tests/openpgp/fake-pinentries/fake-pinentry.{sh,py,pl,php}}: New > public domain files to encourage better test suite practices from > downstream developers. Cool, though I'd suggest to move it to tests/fake-pinentries, the pinentries are not openpgp specific after all. Also... > +The solution for this is to use a fake pinentry in your test suite, > +one that simply returns a pre-selected passphrase. In this case, all > +the other code is the > diff --git a/tests/openpgp/fake-pinentries/fake-pinentry.php b/tests/openpgp/fake-pinentries/fake-pinentry.php > new file mode 100755 > index 0000000..2d8f2c8 > --- /dev/null > +++ b/tests/openpgp/fake-pinentries/fake-pinentry.php the README is truncated. Cheers, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From neal at walfield.org Tue Sep 13 10:27:08 2016 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 13 Sep 2016 10:27:08 +0200 Subject: [PATCH] tests/openpgp: Provide fake pinentries for downstream developers. In-Reply-To: <20160913060958.30933-1-dkg@fifthhorseman.net> References: <20160913060958.30933-1-dkg@fifthhorseman.net> Message-ID: <87sht4mcgz.wl-neal@walfield.org> Hi Daniel, Thanks for working on this. Why not cc0 instead of public domain? From https://creativecommons.org/share-your-work/public-domain/cc0/: The Problem Dedicating works to the public domain is difficult if not impossible for those wanting to contribute their works for public use before applicable copyright or database protection terms expire. Few if any jurisdictions have a process for doing so easily and reliably. Laws vary from jurisdiction to jurisdiction as to what rights are automatically granted and how and when they expire or may be voluntarily relinquished. More challenging yet, many legal systems effectively prohibit any attempt by these owners to surrender rights automatically conferred by law, particularly moral rights, even when the author wishing to do so is well informed and resolute about doing so and contributing their work to the public domain. :) Neal On Tue, 13 Sep 2016 08:09:58 +0200, Daniel Kahn Gillmor wrote: > > * tests/openpgp/fake-pinentries/README.txt and > tests/openpgp/fake-pinentries/fake-pinentry.{sh,py,pl,php}}: New > public domain files to encourage better test suite practices from > downstream developers. > > Signed-off-by: Daniel Kahn Gillmor > --- > tests/openpgp/fake-pinentries/README.txt | 28 ++++++++++++++++++++ > tests/openpgp/fake-pinentries/fake-pinentry.php | 25 ++++++++++++++++++ > tests/openpgp/fake-pinentries/fake-pinentry.pl | 28 ++++++++++++++++++++ > tests/openpgp/fake-pinentries/fake-pinentry.py | 29 +++++++++++++++++++++ > tests/openpgp/fake-pinentries/fake-pinentry.sh | 34 +++++++++++++++++++++++++ > 5 files changed, 144 insertions(+) > create mode 100644 tests/openpgp/fake-pinentries/README.txt > create mode 100755 tests/openpgp/fake-pinentries/fake-pinentry.php > create mode 100755 tests/openpgp/fake-pinentries/fake-pinentry.pl > create mode 100755 tests/openpgp/fake-pinentries/fake-pinentry.py > create mode 100755 tests/openpgp/fake-pinentries/fake-pinentry.sh > > diff --git a/tests/openpgp/fake-pinentries/README.txt b/tests/openpgp/fake-pinentries/README.txt > new file mode 100644 > index 0000000..7a08b32 > --- /dev/null > +++ b/tests/openpgp/fake-pinentries/README.txt > @@ -0,0 +1,28 @@ > +Fake Pinentries for Test Suites > +=============================== > + > +If you're writing a test suite, it should use one of these pinentries > +by setting the following line in $GNUPGHOME/gpg-agent.conf: > + > + pinentry-program /path/to/fake-pinentry.ext > + > +Note that different fake-pinentry programs have been supplied here in > +different languages, with the intent of making them available to > +developers who have different languages available. > + > +They are in the public domain, so they should be reusable by any > +project. Feel free to copy them into your own project's test suite. > + > +Rationale > +--------- > + > +If you're implementing software that uses GnuPG, you probably want a > +test suite that exercises your code, and you may have some that > +involve secret key material locked with a passphrase. However, you > +don't want to require your developers to manually enter a passphrase > +while tests are run, and you probably also don't want to deal with > +alternate codepaths/workflows like using gpg's loopback pinentry. > + > +The solution for this is to use a fake pinentry in your test suite, > +one that simply returns a pre-selected passphrase. In this case, all > +the other code is the > diff --git a/tests/openpgp/fake-pinentries/fake-pinentry.php b/tests/openpgp/fake-pinentries/fake-pinentry.php > new file mode 100755 > index 0000000..2d8f2c8 > --- /dev/null > +++ b/tests/openpgp/fake-pinentries/fake-pinentry.php > @@ -0,0 +1,25 @@ > +#!/usr/bin/php > +# Use this for your test suites when a PHP interpreter is available. > +# > +# The encrypted keys in your test suite that you expect to work must > +# be locked with a passphrase of "passphrase" > +# > +# Author: Daniel Kahn Gillmor > +# > +# License: This trivial work is hereby explicitly placed into the > +# public domain. Anyone may reuse it, modify it, redistribute it for > +# any purpose. > + > + +print("OK This is only for test suites, and should never be used in production\n"); > +while (true) { > + $line = strtolower(trim(fgets(STDIN))); > + if (($line === "") || ($line[0] == '#')) > + continue; > + if ((0 === strncmp("getpin", $line, 6))) > + print("D passphrase\n"); > + print("OK\n"); > + if ((0 === strncmp("bye", $line, 3))) > + break; > +} > +?> > \ No newline at end of file > diff --git a/tests/openpgp/fake-pinentries/fake-pinentry.pl b/tests/openpgp/fake-pinentries/fake-pinentry.pl > new file mode 100755 > index 0000000..250b27c > --- /dev/null > +++ b/tests/openpgp/fake-pinentries/fake-pinentry.pl > @@ -0,0 +1,28 @@ > +#!/usr/bin/perl -w > +# Use this for your test suites when a perl interpreter is available. > +# > +# The encrypted keys in your test suite that you expect to work must > +# be locked with a passphrase of "passphrase" > +# > +# Author: Daniel Kahn Gillmor > +# > +# License: This trivial work is hereby explicitly placed into the > +# public domain. Anyone may reuse it, modify it, redistribute it for > +# any purpose. > + > +use strict; > +use warnings; > + > +# turn off buffering > +$| = 1; > + > +print "OK This is only for test suites, and should never be used in production\n"; > +while () { > + chomp; > + next if (/^$/); > + next if (/^#/) > + print ("D passphrase\n") if (/^getpin/i); > + print "OK\n"; > + exit if (/^bye/i); > +} > +1; > diff --git a/tests/openpgp/fake-pinentries/fake-pinentry.py b/tests/openpgp/fake-pinentries/fake-pinentry.py > new file mode 100755 > index 0000000..57d6941 > --- /dev/null > +++ b/tests/openpgp/fake-pinentries/fake-pinentry.py > @@ -0,0 +1,29 @@ > +#!/usr/bin/env python > +# Use this for your test suites when a python interpreter is available. > +# > +# The encrypted keys in your test suite that you expect to work must > +# be locked with a passphrase of "passphrase" > +# > +# Author: Daniel Kahn Gillmor > +# > +# License: This trivial work is hereby explicitly placed into the > +# public domain. Anyone may reuse it, modify it, redistribute it for > +# any purpose. > + > +import sys, os > + > +# turn off buffering: > +sys.stdin = os.fdopen(sys.stdin.fileno(), 'r', 0) > +sys.stdout = os.fdopen(sys.stdout.fileno(), 'w', 0) > + > +print("OK This is only for test suites, and should never be used in production") > +while True: > + ln = sys.stdin.readline().lower() > + if (ln.strip() == '') or (ln.startswith('#')): > + continue > + if (ln.startswith('getpin')): > + sys.stdout.write('D passphrase\n') > + sys.stdout.write('OK\n') > + if (ln.startswith('bye')): > + break > + > diff --git a/tests/openpgp/fake-pinentries/fake-pinentry.sh b/tests/openpgp/fake-pinentries/fake-pinentry.sh > new file mode 100755 > index 0000000..57bbf91 > --- /dev/null > +++ b/tests/openpgp/fake-pinentries/fake-pinentry.sh > @@ -0,0 +1,34 @@ > +#!/bin/sh > +# Use this for your test suites when a POSIX shell is available. > +# > +# The encrypted keys in your test suite that you expect to work must > +# be locked with a passphrase of "passphrase" > +# > +# Author: Daniel Kahn Gillmor > +# > +# License: This trivial work is hereby explicitly placed into the > +# public domain. Anyone may reuse it, modify it, redistribute it for > +# any purpose. > + > +echo "OK This is only for test suites, and should never be used in production" > +while read cmd rest; do > + cmd=$(printf "%s" "$cmd" | tr 'A-Z' 'a-z') > + if [ -z "$cmd" ]; then > + continue; > + fi > + case "$cmd" in > + \#*) > + ;; > + getpin) > + echo "D passphrase" > + echo "OK" > + ;; > + bye) > + echo "OK" > + exit 0 > + ;; > + *) > + echo "OK" > + ;; > + esac > +done > -- > 2.9.3 > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > From astieger at suse.com Tue Sep 13 16:42:34 2016 From: astieger at suse.com (Andreas Stieger) Date: Tue, 13 Sep 2016 16:42:34 +0200 Subject: interleaving lines of stdout with status when using --status-fd 1 In-Reply-To: <87twdlm824.fsf@wheatstone.g10code.de> References: <28c7870b-f6b7-8b9b-03ed-87ac5468d1ed@suse.com> <87twdlm824.fsf@wheatstone.g10code.de> Message-ID: Hello, On 09/12/2016 05:50 PM, Werner Koch wrote: > On Mon, 12 Sep 2016 13:34, astieger at suse.com said: > >> print_status_key_considered is called in the middle of printing a line >> in the output of --list-public-keys (--with-colons, -fixed-lost-mode, >> --with-dig-list). > The same happens with "pub" and KEYEXPIRED. Thanks for reporting; I > pushed a fix (commit 31fc420). Looks good. Thanks, Andreas -- Andreas Stieger Project Manager Security SUSE Linux GmbH, GF: Felix Imend?rffer, Jane Smithard, Graham Norton, HRB 21284 (AG N?rnberg) From bernhard at intevation.de Tue Sep 13 17:05:18 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 13 Sep 2016 17:05:18 +0200 Subject: Add option for scdaemon to open smart card in non-exclusive mode In-Reply-To: <9E4086BE-CEFB-43EB-9874-51C2B7F09DDE@mit.edu> References: <9E4086BE-CEFB-43EB-9874-51C2B7F09DDE@mit.edu> Message-ID: <201609131705.22469.bernhard@intevation.de> Hi Uri, Am Montag 12 September 2016 03:18:24 schrieb Uri Blumenthal: > The problem is that scdaemon insists on grabbing the token, so first - it > refuses to access it when another daemon (tokend in this case) is connected > to it (tokend on Mac OS X is the daemon that makes the token available to > all the native OS X applications, such as Safari, Google Chrome, Apple > Mail, MS Outlook, Adobe Acrobat, Keychain Access, etc. etc.). Tokend is > talking to PIV applet. from your description, I can see that you are having an use case that should be supported. The next steps would be to a) write it down, open up a ticket on bugs.gnupg.org b) come up with a good proposal how to technically solve this c) come up with someone doing or funding the work. A workaround in your case could be to use two readers, one for each token. I'm no expert, but reading up a bit, it seems that shared access from several application could be a problem, either because of the state of the token that needs to be handed over and otherwise because of speed issues if applications have to reset the token to some clean state. So I'm unsure if a "non-exclusive mode" is technically feasable. Best Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Tue Sep 13 16:55:00 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 13 Sep 2016 16:55:00 +0200 Subject: web key directory, diagram Message-ID: <201609131655.05885.bernhard@intevation.de> Werner, in order to explain WKD and WKS we want to use diagrams. I've made one used in my openpgp.conf talk public via https://wiki.gnupg.org/EasyGpg2016/PubkeyDistributionConcept check the svg metadata for the license (and sublicenses). 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 uri at mit.edu Wed Sep 14 03:16:35 2016 From: uri at mit.edu (Uri Blumenthal) Date: Wed, 14 Sep 2016 01:16:35 +0000 Subject: Add option for scdaemon to open smart card in non-exclusive mode In-Reply-To: <201609131705.22469.bernhard@intevation.de> References: <9E4086BE-CEFB-43EB-9874-51C2B7F09DDE@mit.edu> <201609131705.22469.bernhard@intevation.de> Message-ID: On Sep 13, 2016, at 11:05 , Bernhard Reiter > wrote: > Am Montag 12 September 2016 03:18:24 schrieb Uri Blumenthal: >> The problem is that scdaemon insists on grabbing the token, so first - it >> refuses to access it when another daemon (tokend in this case) is connected >> to it (tokend on Mac OS X is the daemon that makes the token available to >> all the native OS X applications, such as Safari, Google Chrome, Apple >> Mail, MS Outlook, Adobe Acrobat, Keychain Access, etc. etc.). Tokend is >> talking to PIV applet. > > from your description, I can see that you are having an use case that should > be supported. Thank you! > The next steps would be to > a) write it down, open up a ticket on bugs.gnupg.org Will do soon. > b) come up with a good proposal how to technically solve this This I?d like to discuss with the GnuPG Dev team. > c) come up with someone doing or funding the work. Since I don?t have money to offer, I guess I will do the work - thankfully the expected efforts should be fairly low. > A workaround in your case could be to use two readers, one for each token. Sorry, can?t work. For one - there are only two USB ports on my MacBook, and they are already used! Second and more important - this is one and the same physical token. It houses two (actually more, but we?re interested in two) applets - PIV (that?s being handled by OpenSC.tokend and OpenSC) and OpenPGP (accessible via scdaemon, which is the reason of my request and this email exchange). You physically cannot plug one token into two readers. > I'm no expert, but reading up a bit, it seems that shared access from several > application could be a problem, either because of the state of the token > that needs to be handed over and otherwise because of speed issues if > applications have to reset the token to some clean state. Theoretically yes. However, my experience of heavy use of the token by multiple applications (Web browser, email client, and intermittent OpenSSL via libp11 via OpenSC) shows that is not a problem in practice. > So I'm unsure if a "non-exclusive mode" is technically feasible. It certainly is feasible, as OpenSC proves quite nicely. That?s how PIV tokens work with OpenSC on Mac today: tokend connects to it and interfaces with the native Apple applications, while OpenSSL and Firefox use OpenSC PKCS#11 library to talk to the token directly. OpenSC provides a mechanism to detect if token?s state changed. Also, please note that I do not suggest eradicating exclusive access. I merely request that the user is given an option to configure scdaemon to connect in non-exclusive mode when the appropriate parameter in the config file is set. The default can well stay as it is now. -- Uri Blumenthal uri at mit.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From uri at mit.edu Wed Sep 14 03:16:57 2016 From: uri at mit.edu (Uri Blumenthal) Date: Wed, 14 Sep 2016 01:16:57 +0000 Subject: Add option for scdaemon to open smart card in non-exclusive mode In-Reply-To: <201609131705.22469.bernhard@intevation.de> References: <9E4086BE-CEFB-43EB-9874-51C2B7F09DDE@mit.edu> <201609131705.22469.bernhard@intevation.de> Message-ID: <5464605E-EC38-482D-9BF9-4B818AAE9D6F@mit.edu> On Sep 13, 2016, at 11:05 , Bernhard Reiter > wrote: > Am Montag 12 September 2016 03:18:24 schrieb Uri Blumenthal: >> The problem is that scdaemon insists on grabbing the token, so first - it >> refuses to access it when another daemon (tokend in this case) is connected >> to it (tokend on Mac OS X is the daemon that makes the token available to >> all the native OS X applications, such as Safari, Google Chrome, Apple >> Mail, MS Outlook, Adobe Acrobat, Keychain Access, etc. etc.). Tokend is >> talking to PIV applet. > > from your description, I can see that you are having an use case that should > be supported. Thank you! > The next steps would be to > a) write it down, open up a ticket on bugs.gnupg.org Will do soon. > b) come up with a good proposal how to technically solve this This I?d like to discuss with the GnuPG Dev team. > c) come up with someone doing or funding the work. Since I don?t have money to offer, I guess I will do the work - thankfully the expected efforts should be fairly low. > A workaround in your case could be to use two readers, one for each token. Sorry, can?t work. For one - there are only two USB ports on my MacBook, and they are already used! Second and more important - this is one and the same physical token. It houses two (actually more, but we?re interested in two) applets - PIV (that?s being handled by OpenSC.tokend and OpenSC) and OpenPGP (accessible via scdaemon, which is the reason of my request and this email exchange). You physically cannot plug one token into two readers. > I'm no expert, but reading up a bit, it seems that shared access from several > application could be a problem, either because of the state of the token > that needs to be handed over and otherwise because of speed issues if > applications have to reset the token to some clean state. Theoretically yes. However, my experience of heavy use of the token by multiple applications (Web browser, email client, and intermittent OpenSSL via libp11 via OpenSC) shows that is not a problem in practice. > So I'm unsure if a "non-exclusive mode" is technically feasible. It certainly is feasible, as OpenSC proves quite nicely. That?s how PIV tokens work with OpenSC on Mac today: tokend connects to it and interfaces with the native Apple applications, while OpenSSL and Firefox use OpenSC PKCS#11 library to talk to the token directly. OpenSC provides a mechanism to detect if token?s state changed. Also, please note that I do not suggest eradicating exclusive access. I merely request that the user is given an option to configure scdaemon to connect in non-exclusive mode when the appropriate parameter in the config file is set. The default can well stay as it is now. -- Uri Blumenthal uri at mit.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From bernhard at intevation.de Wed Sep 14 08:38:39 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 14 Sep 2016 08:38:39 +0200 Subject: Add option for scdaemon to open smart card in non-exclusive mode In-Reply-To: References: <9E4086BE-CEFB-43EB-9874-51C2B7F09DDE@mit.edu> <201609131705.22469.bernhard@intevation.de> Message-ID: <201609140838.39454.bernhard@intevation.de> Am Mittwoch 14 September 2016 03:16:35 schrieb Uri Blumenthal: > > The next steps would be to > > a) write it down, open up a ticket on bugs.gnupg.org > > > > Will do soon. (Check if there is one already of course. :)) > Since I don?t have money to offer, I guess I will do the work - thankfully > the expected efforts should be fairly low. You can also try to convince others that this is a useful feature. As I am not on a macosx machine, I don't face that problem for instance. > > A workaround in your case could be to use two readers, one for each > > token. > > Sorry, can?t work. For one - there are only two USB ports on my MacBook, > and they are already used! Second and more important - this is one and the > same physical token. You could use a usb hub I guess and two tokens... but I see your point. > It certainly is feasible, as OpenSC proves quite nicely. That?s how PIV > tokens work with OpenSC on Mac today: tokend connects to it and interfaces > with the native Apple applications, while OpenSSL and Firefox use OpenSC > PKCS#11 library to talk to the token directly. OpenSC provides a mechanism > to detect if token?s state changed. > > Also, please note that I do not suggest eradicating exclusive access. I > merely request that the user is given an option to configure scdaemon to > connect in non-exclusive mode when the appropriate parameter in the config > file is set. The default can well stay as it is now. -- Then you are right and if you suggest a patch I am confident that other GnuPG-developers will give it a look. Best, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Wed Sep 14 08:37:30 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 14 Sep 2016 08:37:30 +0200 Subject: Add option for scdaemon to open smart card in non-exclusive mode In-Reply-To: <9E4086BE-CEFB-43EB-9874-51C2B7F09DDE@mit.edu> (Uri Blumenthal's message of "Mon, 12 Sep 2016 01:18:24 +0000") References: <9E4086BE-CEFB-43EB-9874-51C2B7F09DDE@mit.edu> Message-ID: <87zinbgf6d.fsf@wheatstone.g10code.de> On Mon, 12 Sep 2016 03:18, uri at mit.edu said: > What I am asking for: add a configuration option that would tell > scdaemon to open the token in non-exclusive (shared) mode. Keep it off > by default. But those who (like me) have need to use multi-applet > tokens, would be able to have a smooth workflow. An option would be possible but we would state that this is an unsupported hack. Scdaemon caches the state of the card and we have found no way in PC/SC to get a notification from other applications doing anything with the card. OTOH, we would be glad to help you implementing the host side part of that tokend in scdaemon, so that it can be used by all kind of software. Note that we have a PCKS#11 interface on top of scdaemon and scdaemon also provides a direct APDU level access to the card. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From gniibe at fsij.org Wed Sep 14 09:04:32 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 14 Sep 2016 16:04:32 +0900 Subject: gpgsm: Fix alignment Message-ID: Hello, Justus, On armhf architecture, I got this warning with gcc-6: ================== ../../../gnupg/tests/gpgscm/scheme.c: In function ?alloc_cellseg?: ../../../gnupg/tests/gpgscm/scheme.c:627:15: warning: cast increases required alignment of target type [-Wcast-align] newp=(pointer)cp; ^ ================== I think that with modern C, we use (void *) for address. (char *) is specifically for character where its alignment is 1. How about this fix? diff --git a/tests/gpgscm/scheme-private.h b/tests/gpgscm/scheme-private.h index 9eafe76..727e0c0 100644 --- a/tests/gpgscm/scheme-private.h +++ b/tests/gpgscm/scheme-private.h @@ -78,7 +78,7 @@ int tracing; #ifndef CELL_NSEGMENT #define CELL_NSEGMENT 10 /* # of segments for cells */ #endif -char *alloc_seg[CELL_NSEGMENT]; +void *alloc_seg[CELL_NSEGMENT]; pointer cell_seg[CELL_NSEGMENT]; int last_cell_seg; diff --git a/tests/gpgscm/scheme.c b/tests/gpgscm/scheme.c index 1fc7643..8833950 100644 --- a/tests/gpgscm/scheme.c +++ b/tests/gpgscm/scheme.c @@ -602,7 +602,7 @@ static int alloc_cellseg(scheme *sc, int n) { pointer newp; pointer last; pointer p; - char *cp; + void *cp; long i; int k; int adj=ADJ; @@ -614,14 +614,14 @@ static int alloc_cellseg(scheme *sc, int n) { for (k = 0; k < n; k++) { if (sc->last_cell_seg >= CELL_NSEGMENT - 1) return k; - cp = (char*) sc->malloc(CELL_SEGSIZE * sizeof(struct cell)+adj); + cp = sc->malloc(CELL_SEGSIZE * sizeof(struct cell)+adj); if (cp == 0) return k; i = ++sc->last_cell_seg ; sc->alloc_seg[i] = cp; /* adjust in TYPE_BITS-bit boundary */ if(((unsigned long)cp)%adj!=0) { - cp=(char*)(adj*((unsigned long)cp/adj+1)); + cp=(void *)(adj*((unsigned long)cp/adj+1)); } /* insert new segment in address order */ newp=(pointer)cp; -- From justus at g10code.com Wed Sep 14 10:28:55 2016 From: justus at g10code.com (Justus Winter) Date: Wed, 14 Sep 2016 10:28:55 +0200 Subject: gpgsm: Fix alignment In-Reply-To: References: Message-ID: <87mvjasx4o.fsf@europa.jade-hamburg.de> Hello Niibe :) NIIBE Yutaka writes: > Hello, Justus, > > On armhf architecture, I got this warning with gcc-6: > > ================== > ../../../gnupg/tests/gpgscm/scheme.c: In function ?alloc_cellseg?: > ../../../gnupg/tests/gpgscm/scheme.c:627:15: warning: cast increases > required alignment of target type [-Wcast-align] > newp=(pointer)cp; > ^ > ================== > > I think that with modern C, we use (void *) for address. (char *) is > specifically for character where its alignment is 1. > > How about this fix? Sure, feel free to commit this. At first I tried to keep in sync with TinySCHEME upstream, but upstream was not interested in my patches, and we have diverged since. Cheers, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From bernhard at intevation.de Wed Sep 14 10:52:42 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 14 Sep 2016 10:52:42 +0200 Subject: Web Key Directory / Web Key Service wiki page Message-ID: <201609141052.42587.bernhard@intevation.de> https://wiki.gnupg.org/WKD Feedback and help appreciated! :) Bernhard = Much easier Email crypto, by fetching pubkey via HTTPS == How does it work? As an email user, you just select the recipient(s) and can see that the email will be encrypted. If you and your peers use email-providers offering this "web key service", it works by the first email. Otherwise encryption will start after you have exchanged some emails. Technically your email client will automatically * prepare for this by creating a crypto key for you and uploading it to your provider (or second best to public keyservers). * sign all emails so others see that you are ready for crypto (unless you opt out) * ask the mail provider of your recipients for their pubkeys. An email-provider offering the "web key service" technically has to * provide a pubkey for each user via ~HT~TPS * allow each user's email client to automatically manage the pubkey that gets published by email. == Details / Discussion of the proposal * [[EasyGpg2016/PubkeyDistributionConcept]] <- the (technical) details [..] -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From neal at walfield.org Wed Sep 14 15:56:31 2016 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 14 Sep 2016 15:56:31 +0200 Subject: Understanding TOFU statistics Message-ID: <87y42uk2k0.wl-neal@walfield.org> When using the TOFU trust model, gpg shows statistics about observed signatures made by and mails encrypted to the key is question. For instance, consider the following: $ gpg -r 0xF2AD85AC1E42B367 -a -e gpg: wk at g10code.com: Verified 6 signatures in the past 21 days, and encrypted 15 messages in the past 35 days. gpg: wk at gnupg.org: Verified 6 signatures in the past 21 days, and encrypted 15 messages in the past 35 days. gpg: werner at eifzilla.de: Verified 6 signatures in the past 21 days, and encrypted 15 messages in the past 35 days. gpg: Warning: if you think you've seen more signatures by this key and these user ids, then this key might be a forgery! Carefully examine the email addresses for small variations. If the key is suspect, then use gpg --tofu-policy bad 80615870F5BAD690333686D0F2AD85AC1E42B367 to mark it as being bad. In this email, I want to briefly explain why the statistics are important and, most importantly, why we need to show statistics on a per user id / key-basis and not just on a per-key basis. But first, please recall: the only reason to use TOFU is to protect against an active adversary; using --trust-model always is sufficient to protect against passive adversaries. The point of TOFU is to protect the user id / key bindings. If we detect a conflict, that is, there are multiple keys associated with a single user id (or rather, email), then the user may be under attack (MitM or forgery). But, a conflict can also arise when key rotation is not done properly (specifically, if there is no cross signature between the keys). The first reason to show the statistics is to help the user distinguish the currently used key from the new key in the case of a conflict. Note: just because one key has higher signature and encryption counts doesn't mean that it is the right key. As such, we encourage the user to contact the assumed owner. Second, statistics can help identify phishing / forgeries. To circumvent TOFU, an intelligent attacker won't simply use a known email address, but will use a mimicry, a visually similar user id (e.g., a user id in which the a:s are replaced with Cyrillic a:s). Specifically, by always showing the statistics, and a warning when the counts are small, the user will hopefully notice if the count for a usual communication partner has dropped to zero and investigate the problem. In the preceding two examples, showing the statistics on a per-key basis is probably sufficient. However, consider this scenario: an attacker creates a key with the user name Alice, and exchanges several messages with Bob. At this point, Alice's key appears to be trusted since there are a sufficient number of messages. Now, the attacker adds a new user id, Mallory, to the key and sends a message to Bob. If we were to just show the key's statistics, then Mallory's key will appear to be well known and possibly trick him into being phished. But, by showing the statistics for the individual bindings, the user will see that the user id is actually new. Note: if we know the user id that was used, then we only have to display the statistics for that binding. This is normally the case for email messages: we can use the mail's "From" header and, if available, the signer id in the signature packet. But, if this information is not available, we need to show the statistics for all bindings, as far as I can tell. :) Neal From bernhard at intevation.de Wed Sep 14 16:24:11 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 14 Sep 2016 16:24:11 +0200 Subject: Web Key Directory / Web Key Service wiki page In-Reply-To: <201609141052.42587.bernhard@intevation.de> References: <201609141052.42587.bernhard@intevation.de> Message-ID: <201609141624.15711.bernhard@intevation.de> Am Mittwoch 14 September 2016 10:52:42 schrieb Bernhard Reiter: > https://wiki.gnupg.org/WKD updated to include the following. Please send correction to me or edit the wiki directly. [..] == Implementations === GnuPG "modern" * WKD lookup experimental since v2.1.12 * WKS server and client experimental tools since v2.1.14, see //[[https://gnupg.org/blog/20160830-web-key-service.html|how to run them in GnuPG's blog vom 2016-08-30]]// === Mail User Agents * planned Kontact Mail/KMail support (part of EasyGpg2016) * planned Thunderbird support (part of EasyGpg2016) === Mail Service Providers * (gnupg.org) Testing accounts by request for developers implementing WKS in Free Software MUAs. -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Wed Sep 14 16:59:15 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 14 Sep 2016 16:59:15 +0200 Subject: WKS: discussion, attach pubkey always? Message-ID: <201609141659.18911.bernhard@intevation.de> On https://wiki.gnupg.org/EasyGpg2016/PubkeyDistributionConcept I'm making an effort to write down why some aspects in the web key service are proposed as they are. Here are new sections, in which I am trying to catch the thinking. Werner, did I get this right? @all, am I missing important aspects? Best, Bernhard == Less attractive alternatives/documenting the design process TODO documenting main disregarded alternatives and the design process === Only using email exchanges (and no lookup) Possible advantages are * Discovery of the pubkey to an email address is more difficult. It would depend on the user replying, thus the user can decide with whom to pick up encrypted communications. * There is no need to choose an MSP that support WKS. Neutral: * Attack by the MSP as man-in-the middle there is no real advantage. Of course it is slightly easier to just send out a wrong pubkey via HTTPS, but this can also be done via email, as all emails goes through the MSP anyway. On the other hand it is a little harder to anonymously check that the MSP is serving the same pubkey for you that you also hold. By email, the MSP just filters this for a number of recipients, for HTTPS you could just go to a different network connection which is harder to detect by the MSP. Considered less attractive because: * Lot of (first) emails would go unencrypted that could easily be encrypted. Think of confirmation emails to web purchases or when replying to all that have received an email. * Drawbacks for always attaching a pubkey (see below). === Attaching a pubkey to all emails The idea is to always attach one pubkey to all emails the user sends out. This could help with * No pubkey-server lookup necessary, in case of users without WKS supporting MSP. Considered less attractive because: * size, some pubkeys are quite large (1 Mebibyte) and we want to continue using the existing trust information in addition. * a pubkeyserver lookup is strongly recommended anyway looking for revocations. === Managing by HTTPS It would be possible to manage the uploading of pubkeys to the mailserver-provider via an authenticated HT~TPS connection. This is **considered less attractive than handling by email because it is estimated to be harder to implement overall**. * Early examinations by expert hint towards that it is easier to get into the mail processing chain for ~MUAs than to be able to reuse or resent the authentication credentials for TLS connections. The send, receiving the raw-mail itself is a task of the MUA that will also need to have hooks for crypto to work on the mail-structure itself. The TLS credentials used for IMAPS and SMTPS may be hidden in a different module and probably cannot just be reused by extensions, to protect them against less carefully written add-on code. The experts are [[Werner Koch]] (e.g. has implemented significant code for mutt, GpgOL Outlook, gnus and Thunderbird) and [[Andre Heinecke]] (e.g. has implemented significant code for KMail, GpgOL Outlook and Thunderbird). * An email implementation makes it easier to support offline systems (carrying over the emails over by other means). Email is already asynchronous. Doing a challenge response method that allows disconnections with HTTPS is possible, but much harder. * Email already has build-in queue handling on server and client side. A server module that only works one submission inbox is nicely separated from the rest of the system. * On server side, the HTTPS server may not have direct access to the email credentials of the users. The advantages of authenticated HTTPS would have been: * faster turn-around time and better feedback until the pubkey is available from the MSP. Probably seconds as opposed to minutes. * No need to intercept emails on client side. * No need for email crypto processing on server side, if the authentication is considered sufficient. (Someone who can authenticate towards the MSP as user, is always able to request and confirm a different pubkey to be uploaded.) === Resorting to a central fallback server In case if the MSP does not support a pubkey service, it was proposed to use a central fallback server. The main advantage: * Users can use crypto, starting with the first email The main drawbacks: * A single point of failure (or attack surface) * Takes away some incentive for MSP to offer a pubkey service. Overall an email exchange as fallback method is prefered because it is close to a natural way users build up trust in first email exchanges and comes without the drawbacks of the central fallback server. See more discussion at [[/FallbackServer]]. === Using classic (pub)"key" servers Our **unattended use for sending the email would not work** in many cases. It would be by pure chance that only one public user id will be found on the public servers ("discovery") and that it carries a signature from a cert that I already "trust" to sign others ("validation"). Anyone can upload a pubkey with a speficia email address. Our choice is to offer the user the chance to go to a more complex full-blown certificate management handling or to offer hints to contact the communication partner to adopt the scheme proposed here. However asking cert servers can be a good idea to sometimes find revocation certificates for certs I already know. This is important if the earlier stages fail which is always a possibility in the near future. So a cert-server check is part of our proposed steps. -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From dkg at fifthhorseman.net Wed Sep 14 18:16:41 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 14 Sep 2016 12:16:41 -0400 Subject: [PATCH] tests/openpgp: Provide fake pinentries for downstream developers. In-Reply-To: <87sht4mcgz.wl-neal@walfield.org> References: <20160913060958.30933-1-dkg@fifthhorseman.net> <87sht4mcgz.wl-neal@walfield.org> Message-ID: <87oa3qxxqu.fsf@alice.fifthhorseman.net> On Tue 2016-09-13 04:27:08 -0400, Neal H. Walfield wrote: > Thanks for working on this. Why not cc0 instead of public domain? I'm fine with CC0, and i'll switch the next revision to it unless anyone objects. Justus wrote: > Cool, though I'd suggest to move it to tests/fake-pinentries, the > pinentries are not openpgp specific after all. Also... [...] > the README is truncated. tests/fake-pinentries/ sounds good to me. I'll fix up the README as well. Any other suggestions or concerns before i send a v3 ? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From dkg at fifthhorseman.net Wed Sep 14 21:55:13 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 14 Sep 2016 15:55:13 -0400 Subject: [PATCH v3] tests/fake-pinentries: fake pinentries for downstream developers. In-Reply-To: <87oa3qxxqu.fsf@alice.fifthhorseman.net> References: <87oa3qxxqu.fsf@alice.fifthhorseman.net> Message-ID: <20160914195513.5258-1-dkg@fifthhorseman.net> * tests/fake-pinentries/README.txt and tests/fake-pinentries/fake-pinentry.{sh,py,pl,php}}: New public domain (CC0) files to encourage better test suite practices from downstream developers. * tests/fake-pinentries/COPYING (new): a copy of https://creativecommons.org/publicdomain/zero/1.0/legalcode.txt Signed-off-by: Daniel Kahn Gillmor --- tests/fake-pinentries/COPYING | 121 ++++++++++++++++++++++++++++++++ tests/fake-pinentries/README.txt | 37 ++++++++++ tests/fake-pinentries/fake-pinentry.php | 27 +++++++ tests/fake-pinentries/fake-pinentry.pl | 27 +++++++ tests/fake-pinentries/fake-pinentry.py | 31 ++++++++ tests/fake-pinentries/fake-pinentry.sh | 33 +++++++++ 6 files changed, 276 insertions(+) create mode 100644 tests/fake-pinentries/COPYING create mode 100644 tests/fake-pinentries/README.txt create mode 100755 tests/fake-pinentries/fake-pinentry.php create mode 100755 tests/fake-pinentries/fake-pinentry.pl create mode 100755 tests/fake-pinentries/fake-pinentry.py create mode 100755 tests/fake-pinentries/fake-pinentry.sh diff --git a/tests/fake-pinentries/COPYING b/tests/fake-pinentries/COPYING new file mode 100644 index 0000000..0e259d4 --- /dev/null +++ b/tests/fake-pinentries/COPYING @@ -0,0 +1,121 @@ +Creative Commons Legal Code + +CC0 1.0 Universal + + CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE + LEGAL SERVICES. DISTRIBUTION OF THIS DOCUMENT DOES NOT CREATE AN + ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS + INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES + REGARDING THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS + PROVIDED HEREUNDER, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM + THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS PROVIDED + HEREUNDER. + +Statement of Purpose + +The laws of most jurisdictions throughout the world automatically confer +exclusive Copyright and Related Rights (defined below) upon the creator +and subsequent owner(s) (each and all, an "owner") of an original work of +authorship and/or a database (each, a "Work"). + +Certain owners wish to permanently relinquish those rights to a Work for +the purpose of contributing to a commons of creative, cultural and +scientific works ("Commons") that the public can reliably and without fear +of later claims of infringement build upon, modify, incorporate in other +works, reuse and redistribute as freely as possible in any form whatsoever +and for any purposes, including without limitation commercial purposes. +These owners may contribute to the Commons to promote the ideal of a free +culture and the further production of creative, cultural and scientific +works, or to gain reputation or greater distribution for their Work in +part through the use and efforts of others. + +For these and/or other purposes and motivations, and without any +expectation of additional consideration or compensation, the person +associating CC0 with a Work (the "Affirmer"), to the extent that he or she +is an owner of Copyright and Related Rights in the Work, voluntarily +elects to apply CC0 to the Work and publicly distribute the Work under its +terms, with knowledge of his or her Copyright and Related Rights in the +Work and the meaning and intended legal effect of CC0 on those rights. + +1. Copyright and Related Rights. A Work made available under CC0 may be +protected by copyright and related or neighboring rights ("Copyright and +Related Rights"). Copyright and Related Rights include, but are not +limited to, the following: + + i. the right to reproduce, adapt, distribute, perform, display, + communicate, and translate a Work; + ii. moral rights retained by the original author(s) and/or performer(s); +iii. publicity and privacy rights pertaining to a person's image or + likeness depicted in a Work; + iv. rights protecting against unfair competition in regards to a Work, + subject to the limitations in paragraph 4(a), below; + v. rights protecting the extraction, dissemination, use and reuse of data + in a Work; + vi. database rights (such as those arising under Directive 96/9/EC of the + European Parliament and of the Council of 11 March 1996 on the legal + protection of databases, and under any national implementation + thereof, including any amended or successor version of such + directive); and +vii. other similar, equivalent or corresponding rights throughout the + world based on applicable law or treaty, and any national + implementations thereof. + +2. Waiver. To the greatest extent permitted by, but not in contravention +of, applicable law, Affirmer hereby overtly, fully, permanently, +irrevocably and unconditionally waives, abandons, and surrenders all of +Affirmer's Copyright and Related Rights and associated claims and causes +of action, whether now known or unknown (including existing as well as +future claims and causes of action), in the Work (i) in all territories +worldwide, (ii) for the maximum duration provided by applicable law or +treaty (including future time extensions), (iii) in any current or future +medium and for any number of copies, and (iv) for any purpose whatsoever, +including without limitation commercial, advertising or promotional +purposes (the "Waiver"). Affirmer makes the Waiver for the benefit of each +member of the public at large and to the detriment of Affirmer's heirs and +successors, fully intending that such Waiver shall not be subject to +revocation, rescission, cancellation, termination, or any other legal or +equitable action to disrupt the quiet enjoyment of the Work by the public +as contemplated by Affirmer's express Statement of Purpose. + +3. Public License Fallback. Should any part of the Waiver for any reason +be judged legally invalid or ineffective under applicable law, then the +Waiver shall be preserved to the maximum extent permitted taking into +account Affirmer's express Statement of Purpose. In addition, to the +extent the Waiver is so judged Affirmer hereby grants to each affected +person a royalty-free, non transferable, non sublicensable, non exclusive, +irrevocable and unconditional license to exercise Affirmer's Copyright and +Related Rights in the Work (i) in all territories worldwide, (ii) for the +maximum duration provided by applicable law or treaty (including future +time extensions), (iii) in any current or future medium and for any number +of copies, and (iv) for any purpose whatsoever, including without +limitation commercial, advertising or promotional purposes (the +"License"). The License shall be deemed effective as of the date CC0 was +applied by Affirmer to the Work. Should any part of the License for any +reason be judged legally invalid or ineffective under applicable law, such +partial invalidity or ineffectiveness shall not invalidate the remainder +of the License, and in such case Affirmer hereby affirms that he or she +will not (i) exercise any of his or her remaining Copyright and Related +Rights in the Work or (ii) assert any associated claims and causes of +action with respect to the Work, in either case contrary to Affirmer's +express Statement of Purpose. + +4. Limitations and Disclaimers. + + a. No trademark or patent rights held by Affirmer are waived, abandoned, + surrendered, licensed or otherwise affected by this document. + b. Affirmer offers the Work as-is and makes no representations or + warranties of any kind concerning the Work, express, implied, + statutory or otherwise, including without limitation warranties of + title, merchantability, fitness for a particular purpose, non + infringement, or the absence of latent or other defects, accuracy, or + the present or absence of errors, whether or not discoverable, all to + the greatest extent permissible under applicable law. + c. Affirmer disclaims responsibility for clearing rights of other persons + that may apply to the Work or any use thereof, including without + limitation any person's Copyright and Related Rights in the Work. + Further, Affirmer disclaims responsibility for obtaining any necessary + consents, permissions or other rights required for any use of the + Work. + d. Affirmer understands and acknowledges that Creative Commons is not a + party to this document and has no duty or obligation with respect to + this CC0 or use of the Work. diff --git a/tests/fake-pinentries/README.txt b/tests/fake-pinentries/README.txt new file mode 100644 index 0000000..6762dcc --- /dev/null +++ b/tests/fake-pinentries/README.txt @@ -0,0 +1,37 @@ +Fake Pinentries for Test Suites +=============================== + +If you're writing a test suite, it should use one of these pinentries +by setting the following line in $GNUPGHOME/gpg-agent.conf: + + pinentry-program /path/to/fake-pinentry.ext + +Note that different fake-pinentry programs have been supplied here in +different languages, with the intent of making them available to +developers who have different languages available. + +They are all licensed Creative Commons Zero (CC0-1.0-Universal, see +the COPYING file in this directory), so they should be reusable by any +project. Feel free to copy them into your own project's test suite. + +Rationale +--------- + +If you're implementing software that uses GnuPG, you probably want a +test suite that exercises your code, and you may have some that +involve secret key material locked with a passphrase. However, you +don't want to require your developers to manually enter a passphrase +while tests are run, and you probably also don't want to deal with +alternate codepaths/workflows like using gpg's loopback pinentry. + +The solution for this is to use a fake pinentry in your test suite, +one that simply returns a pre-selected passphrase. In this case, all +the other code follows the same path as normal, but the user +interaction is bypassed because the fake-pinentry is used instead. + +Troubleshooting +--------------- + +If you have any trouble with this technique, please drop a line to the +GnuPG development mailing list or open a +report on the GnuPG bug tracker at https://bugs.gnupg.org/gnupg diff --git a/tests/fake-pinentries/fake-pinentry.php b/tests/fake-pinentries/fake-pinentry.php new file mode 100755 index 0000000..feddc99 --- /dev/null +++ b/tests/fake-pinentries/fake-pinentry.php @@ -0,0 +1,27 @@ +#!/usr/bin/php + +# +# License: Creative Commons Zero ("Public Domain Dedication") -- +# Anyone may reuse it, modify it, redistribute it for any purpose. + +print("OK This is only for test suites, and should never be used in production\n"); +while (true) { + $line = fgets(STDIN); + if (False === $line) + break; + $line = strtolower(trim($line)); + if (($line === "") || ($line[0] == '#')) + continue; + if ((0 === strncmp("getpin", $line, 6))) + print("D passphrase\n"); + print("OK\n"); + if ((0 === strncmp("bye", $line, 3))) + break; +} +?> \ No newline at end of file diff --git a/tests/fake-pinentries/fake-pinentry.pl b/tests/fake-pinentries/fake-pinentry.pl new file mode 100755 index 0000000..8cb337d --- /dev/null +++ b/tests/fake-pinentries/fake-pinentry.pl @@ -0,0 +1,27 @@ +#!/usr/bin/perl -w +# Use this for your test suites when a perl interpreter is available. +# +# The encrypted keys in your test suite that you expect to work must +# be locked with a passphrase of "passphrase" +# +# Author: Daniel Kahn Gillmor +# +# License: Creative Commons Zero ("Public Domain Dedication") -- +# Anyone may reuse it, modify it, redistribute it for any purpose. + +use strict; +use warnings; + +# turn off buffering +$| = 1; + +print "OK This is only for test suites, and should never be used in production\n"; +while () { + chomp; + next if (/^$/); + next if (/^#/); + print ("D passphrase\n") if (/^getpin/i); + print "OK\n"; + exit if (/^bye/i); +} +1; diff --git a/tests/fake-pinentries/fake-pinentry.py b/tests/fake-pinentries/fake-pinentry.py new file mode 100755 index 0000000..2cab7a3 --- /dev/null +++ b/tests/fake-pinentries/fake-pinentry.py @@ -0,0 +1,31 @@ +#!/usr/bin/env python +# Use this for your test suites when a python interpreter is available. +# +# The encrypted keys in your test suite that you expect to work must +# be locked with a passphrase of "passphrase" +# +# Author: Daniel Kahn Gillmor +# +# License: Creative Commons Zero ("Public Domain Dedication") -- +# Anyone may reuse it, modify it, redistribute it for any purpose. + +import sys, os + +# turn off buffering: +sys.stdin = os.fdopen(sys.stdin.fileno(), 'r', 0) +sys.stdout = os.fdopen(sys.stdout.fileno(), 'w', 0) + +print("OK This is only for test suites, and should never be used in production") +while True: + ln = sys.stdin.readline() + if (ln == ''): + break + ln = ln.lower() + if (ln.strip() == '') or (ln.startswith('#')): + continue + if (ln.startswith('getpin')): + sys.stdout.write('D passphrase\n') + sys.stdout.write('OK\n') + if (ln.startswith('bye')): + break + diff --git a/tests/fake-pinentries/fake-pinentry.sh b/tests/fake-pinentries/fake-pinentry.sh new file mode 100755 index 0000000..44aca21 --- /dev/null +++ b/tests/fake-pinentries/fake-pinentry.sh @@ -0,0 +1,33 @@ +#!/bin/sh +# Use this for your test suites when a POSIX shell is available. +# +# The encrypted keys in your test suite that you expect to work must +# be locked with a passphrase of "passphrase" +# +# Author: Daniel Kahn Gillmor +# +# License: Creative Commons Zero ("Public Domain Dedication") -- +# Anyone may reuse it, modify it, redistribute it for any purpose. + +echo "OK This is only for test suites, and should never be used in production" +while read cmd rest; do + cmd=$(printf "%s" "$cmd" | tr 'A-Z' 'a-z') + if [ -z "$cmd" ]; then + continue; + fi + case "$cmd" in + \#*) + ;; + getpin) + echo "D passphrase" + echo "OK" + ;; + bye) + echo "OK" + exit 0 + ;; + *) + echo "OK" + ;; + esac +done -- 2.9.3 From dkg at fifthhorseman.net Wed Sep 14 23:21:19 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 14 Sep 2016 17:21:19 -0400 Subject: [PATCH] spelling: conenction should be connection Message-ID: <20160914212119.9149-1-dkg@fifthhorseman.net> * dirmngr/server.c, sm/server.c: s/conenction/connection/ Signed-off-by: Daniel Kahn Gillmor --- dirmngr/server.c | 2 +- sm/server.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/dirmngr/server.c b/dirmngr/server.c index b29628a..e5cf2c3 100644 --- a/dirmngr/server.c +++ b/dirmngr/server.c @@ -304,7 +304,7 @@ strcpy_escaped_plus (char *d, const unsigned char *s) /* This function returns true if a Tor server is running. The sattus - is cached for the current conenction. */ + is cached for the current connection. */ static int is_tor_running (ctrl_t ctrl) { diff --git a/sm/server.c b/sm/server.c index ce8085d..b4fcb43 100644 --- a/sm/server.c +++ b/sm/server.c @@ -1099,7 +1099,7 @@ static const char hlp_getinfo[] = " agent-check - Return success if the agent is running.\n" " cmd_has_option CMD OPT\n" " - Returns OK if the command CMD implements the option OPT.\n" - " offline - Returns OK if the conenction is in offline mode."; + " offline - Returns OK if the connection is in offline mode."; static gpg_error_t cmd_getinfo (assuan_context_t ctx, char *line) { -- 2.9.3 From dkg at fifthhorseman.net Wed Sep 14 23:23:09 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 14 Sep 2016 17:23:09 -0400 Subject: [PATCH] spelling: correct achived to achieved Message-ID: <20160914212309.9339-1-dkg@fifthhorseman.net> Signed-off-by: Daniel Kahn Gillmor --- doc/gpg.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/gpg.texi b/doc/gpg.texi index 8107100..118066a 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -2198,7 +2198,7 @@ opposite meaning. The options are: a formerly deleted key does not automatically gain an ownertrust values merely due to import. On the other hand it is sometimes necessary to re-import a trusted set of keys again but keeping - already assigned ownertrust values. This can be achived by using + already assigned ownertrust values. This can be achieved by using this option. @item repair-pks-subkey-bug -- 2.9.3 From gniibe at fsij.org Thu Sep 15 02:57:27 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 15 Sep 2016 09:57:27 +0900 Subject: tests/gpgscm: (was: gpgsm: Fix alignment) In-Reply-To: <87mvjasx4o.fsf@europa.jade-hamburg.de> References: <87mvjasx4o.fsf@europa.jade-hamburg.de> Message-ID: <8f405ca2-6546-de34-da21-940af6ef9b6e@fsij.org> Fix committed. On 09/14/2016 05:28 PM, Justus Winter wrote: > At first I tried to keep in sync with TinySCHEME upstream, but upstream > was not interested in my patches, and we have diverged since. I see the situation. I was wrong in the Subject line. It's not gpgsm, it's gpgscm. -- From justus at g10code.com Thu Sep 15 10:11:55 2016 From: justus at g10code.com (Justus Winter) Date: Thu, 15 Sep 2016 10:11:55 +0200 Subject: [PATCH] spelling: correct achived to achieved In-Reply-To: <20160914212309.9339-1-dkg@fifthhorseman.net> References: <20160914212309.9339-1-dkg@fifthhorseman.net> Message-ID: <874m5h4m5w.fsf@europa.jade-hamburg.de> Daniel Kahn Gillmor writes: > Signed-off-by: Daniel Kahn Gillmor > --- > doc/gpg.texi | 2 +- Both merged, many thanks! Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From justus at g10code.com Thu Sep 15 10:27:14 2016 From: justus at g10code.com (Justus Winter) Date: Thu, 15 Sep 2016 10:27:14 +0200 Subject: [PATCH v3] tests/fake-pinentries: fake pinentries for downstream developers. In-Reply-To: <20160914195513.5258-1-dkg@fifthhorseman.net> References: <87oa3qxxqu.fsf@alice.fifthhorseman.net> <20160914195513.5258-1-dkg@fifthhorseman.net> Message-ID: <871t0l4lgd.fsf@europa.jade-hamburg.de> Daniel Kahn Gillmor writes: > * tests/fake-pinentries/README.txt and > tests/fake-pinentries/fake-pinentry.{sh,py,pl,php}}: New public > domain (CC0) files to encourage better test suite practices from > downstream developers. > * tests/fake-pinentries/COPYING (new): a copy of > https://creativecommons.org/publicdomain/zero/1.0/legalcode.txt Cool, merged :) Note that there were some whitespace issues that I corrected, I wonder how you sneaked these by our pre-commit hook!? Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From astieger at suse.com Thu Sep 15 12:04:17 2016 From: astieger at suse.com (Andreas Stieger) Date: Thu, 15 Sep 2016 12:04:17 +0200 Subject: fix a void return in a non-void function In-Reply-To: <0c366bd0-2f35-d66c-54e8-fecdbb56e6a6@suse.com> References: <0c366bd0-2f35-d66c-54e8-fecdbb56e6a6@suse.com> Message-ID: <410ad80f-1584-1536-fb16-17a731c17333@suse.com> Hi, On 08/19/2016 11:17 PM, Andreas Stieger wrote: > the attached patch fixes a void return in a non-void function that was > new in 2.1.15 and was apparently introduced in 14479e2. diff --git a/common/simple-pwquery.c b/common/simple-pwquery.c [...] @@ -285,6 +285,7 @@ agent_open (assuan_context_t *ctx) errout: assuan_release (*ctx); *ctx = NULL; + return -1; } Changed to return rc in 62f3e0027724b23c0de5be6d1e66cfdeef7e7bc9. Andreas -- Andreas Stieger Project Manager Security SUSE Linux GmbH, GF: Felix Imend?rffer, Jane Smithard, Graham Norton, HRB 21284 (AG N?rnberg) From justus at g10code.com Thu Sep 15 14:58:04 2016 From: justus at g10code.com (Justus Winter) Date: Thu, 15 Sep 2016 14:58:04 +0200 Subject: [PATCH GnuPG] agent: Enable restricted, browser, and ssh socket by default. Message-ID: <20160915125804.7568-1-justus@g10code.com> * agent/gpg-agent.c (main): Provide defaults for 'extra-socket' and 'browser-socket', enable ssh socket by default, but do not emit the 'SSH_AUTH_SOCK' variable unless it has been explicitly requested. * configure.ac (GPG_AGENT_{EXTRA,BROWSER}_SOCK_NAME): New definitions. * doc/gpg-agent.texi: Update documentation. -- This change enables the restricted, browser, and ssh socket by default. Note that in all cases, the user has to do some additional configuration to her setup to make use of these features. Therefore, this should not break any existing setups, but makes it simpler to discover and use these features. Signed-off-by: Justus Winter --- agent/gpg-agent.c | 26 +++++++++++++++++--------- configure.ac | 4 ++++ doc/gpg-agent.texi | 6 +++++- 3 files changed, 26 insertions(+), 10 deletions(-) diff --git a/agent/gpg-agent.c b/agent/gpg-agent.c index 75a9283..1da862e 100644 --- a/agent/gpg-agent.c +++ b/agent/gpg-agent.c @@ -1045,6 +1045,18 @@ main (int argc, char **argv ) agent_exit (0); } + if (! opt.extra_socket) + { + opt.extra_socket = 1; /* (1 = points into r/o section) */ + socket_name_extra = GPG_AGENT_EXTRA_SOCK_NAME; + } + + if (! opt.browser_socket) + { + opt.browser_socket = 1; /* (1 = points into r/o section) */ + socket_name_browser = GPG_AGENT_BROWSER_SOCK_NAME; + } + set_debug (); if (atexit (cleanup)) @@ -1241,13 +1253,10 @@ main (int argc, char **argv ) &socket_nonce_browser); } - if (ssh_support) - { - socket_name_ssh = create_socket_name (GPG_AGENT_SSH_SOCK_NAME, 1); - fd_ssh = create_server_socket (socket_name_ssh, 0, 1, - &redir_socket_name_ssh, - &socket_nonce_ssh); - } + socket_name_ssh = create_socket_name (GPG_AGENT_SSH_SOCK_NAME, 1); + fd_ssh = create_server_socket (socket_name_ssh, 0, 1, + &redir_socket_name_ssh, + &socket_nonce_ssh); /* If we are going to exec a program in the parent, we record the PID, so that the child may check whether the program is @@ -1313,8 +1322,7 @@ main (int argc, char **argv ) *socket_name_extra = 0; if (opt.browser_socket) *socket_name_browser = 0; - if (ssh_support) - *socket_name_ssh = 0; + *socket_name_ssh = 0; if (argc) { /* Run the program given on the commandline. */ diff --git a/configure.ac b/configure.ac index b16f837..9b7e101 100644 --- a/configure.ac +++ b/configure.ac @@ -1746,6 +1746,10 @@ AC_DEFINE_UNQUOTED(GPGTAR_NAME, "gpgtar", [The name of the gpgtar tool]) AC_DEFINE_UNQUOTED(GPG_AGENT_SOCK_NAME, "S.gpg-agent", [The name of the agent socket]) +AC_DEFINE_UNQUOTED(GPG_AGENT_EXTRA_SOCK_NAME, "S.gpg-agent.restricted", + [The name of the agent socket for remote access]) +AC_DEFINE_UNQUOTED(GPG_AGENT_BROWSER_SOCK_NAME, "S.gpg-agent.browser", + [The name of the agent socket for browsers]) AC_DEFINE_UNQUOTED(GPG_AGENT_SSH_SOCK_NAME, "S.gpg-agent.ssh", [The name of the agent socket for ssh]) AC_DEFINE_UNQUOTED(DIRMNGR_INFO_NAME, "DIRMNGR_INFO", diff --git a/doc/gpg-agent.texi b/doc/gpg-agent.texi index b890c21..565b825 100644 --- a/doc/gpg-agent.texi +++ b/doc/gpg-agent.texi @@ -537,6 +537,9 @@ pinentry to pop up at the @code{tty} or display you started the agent. @anchor{option --extra-socket} @item --extra-socket @var{name} @opindex extra-socket +The extra socket is always created, you may use this option to change +the name of the 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. @@ -552,7 +555,8 @@ remote machine. @opindex enable-ssh-support @opindex enable-putty-support -Enable the OpenSSH Agent protocol. +The OpenSSH Agent protocol is always enabled, but @command{gpg-agent} +will only set the @code{SSH_AUTH_SOCK} variable if this flag is given. In this mode of operation, the agent does not only implement the gpg-agent protocol, but also the agent protocol used by OpenSSH -- 2.9.3 From bernhard at intevation.de Thu Sep 15 16:42:11 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 15 Sep 2016 16:42:11 +0200 Subject: Web Key Directory / Web Key Service wiki page In-Reply-To: <201609141624.15711.bernhard@intevation.de> References: <201609141052.42587.bernhard@intevation.de> <201609141624.15711.bernhard@intevation.de> Message-ID: <201609151642.16108.bernhard@intevation.de> https://wiki.gnupg.org/WKD > === Mail Service Providers > * (gnupg.org) Testing accounts by request for developers implementing WKS > in Free Software MUAs. Posteo announced that they will fully support WKD/WKS in the next months. https://wiki.gnupg.org/EasyGpg2016/PubkeyDistributionConcept has been completely reworked. Catching more of the design process and the current status of what changes are still being discussed. It is a 10 page document now, so I'm not posting it here (let me know, if you'd prefer this). What do you think about these wiki-pages? I will now see if I can approach more mail service providers. Best Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Thu Sep 15 17:22:02 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 15 Sep 2016 17:22:02 +0200 Subject: [PATCH GnuPG] agent: Enable restricted, browser, and ssh socket by default. In-Reply-To: <20160915125804.7568-1-justus@g10code.com> (Justus Winter's message of "Thu, 15 Sep 2016 14:58:04 +0200") References: <20160915125804.7568-1-justus@g10code.com> Message-ID: <878tutdw85.fsf@wheatstone.g10code.de> On Thu, 15 Sep 2016 14:58, justus at g10code.com said: > This change enables the restricted, browser, and ssh socket by > default. Note that in all cases, the user has to do some additional > configuration to her setup to make use of these features. Therefore, I am strongly against such defaults. They are not required for any standard GnuPG use. In particular the ssh-agent feature should not be enabled without user consent. That would be a bit similar to the GKR problem we had for years. Right, you need to tell ssh about this other socket. But at some point in the future we may have achieved auto starting of gpg-agent by ssh and then the default ssh configuration would use gpg-agent - which I would consider hostile. OpenSSH's agent and gpg-agent use a very different architecture, despite that they speak the same protocol. Those folks, who know what ssh is and want to use it, are all able to click on "enable-ssh-support" in some GnuPG GUI or add it to gpg-agent.conf. The extra socket stuff is even more hackish and by default a software shall limit itself to listen for connections on the standard port and not on some esoteric stuff. Iff there will eventually be a browser or browser extension in wide use which requires --browser-socket (and probably other stuff) we can re-consider the defaults. Note that there is a feature in the queue to set a configuration options From a recipe file. This will be used to configure GnuPG according to certain policy guidelines. A hacker's choice profile can of course then be distributed along with GnuPG. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From dkg at fifthhorseman.net Thu Sep 15 17:50:59 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 15 Sep 2016 11:50:59 -0400 Subject: [PATCH GnuPG] agent: Enable restricted, browser, and ssh socket by default. In-Reply-To: <878tutdw85.fsf@wheatstone.g10code.de> References: <20160915125804.7568-1-justus@g10code.com> <878tutdw85.fsf@wheatstone.g10code.de> Message-ID: <87d1k52mcc.fsf@alice.fifthhorseman.net> On Thu 2016-09-15 11:22:02 -0400, Werner Koch wrote: > On Thu, 15 Sep 2016 14:58, justus at g10code.com said: > >> This change enables the restricted, browser, and ssh socket by >> default. Note that in all cases, the user has to do some additional >> configuration to her setup to make use of these features. Therefore, > > I am strongly against such defaults. They are not required for any > standard GnuPG use. In particular the ssh-agent feature should not be > enabled without user consent. fwiw, i think Justus' proposal is a reasonable approach. As Justus mentions, there are safeguards in place to prevent the use of these sockets by anyone by default. For SSH, the user will need to set SSH_AUTH_SOCK explicitly to point to this location, *and* the keys must be listed in ~/.gnupg/sshcontrol. For the other sockets, the user will need to explicitly point their tools at them as well. > That would be a bit similar to the GKR problem we had for years. Right, > you need to tell ssh about this other socket. But at some point in the > future we may have achieved auto starting of gpg-agent by ssh and then > the default ssh configuration would use gpg-agent - which I would > consider hostile. If ssh auto-starts gpg-agent, then it should absolutely start it up with the ssh-socket enabled, no? I suspect that if anyone is going to find anything hostile, it would be some OpenSSH users finding it hostile to auto-start gpg-agent when they didn't want it. > OpenSSH's agent and gpg-agent use a very different architecture, > despite that they speak the same protocol. Those folks, who know what > ssh is and want to use it, are all able to click on > "enable-ssh-support" in some GnuPG GUI or add it to gpg-agent.conf. *and* then point their ssh clients at it. with justus' proposal, they only need to point their ssh client at the right locatoin. > The extra socket stuff is even more hackish and by default a software > shall limit itself to listen for connections on the standard port and > not on some esoteric stuff. Iff there will eventually be a browser or > browser extension in wide use which requires --browser-socket (and > probably other stuff) we can re-consider the defaults. I'm fine with leaving --browser-socket off by default (it's not even documented), but why should we leave extra-socket off by default? extra-socket should provide a strict subset of the functionality provided by the standard socket, right? What's the risk of exposing it given that the standard socket is already exposed? > Note that there is a feature in the queue to set a configuration options > From a recipe file. This will be used to configure GnuPG according to > certain policy guidelines. A hacker's choice profile can of course then > be distributed along with GnuPG. Sure, we can distribute all kinds of profiles, but most people are going to use the default. We should make the default capable, robust, flexible, and secure. Actually listening on ssh and extra sockets by default doesn't seem to violate those goals. Can you be more specific about what you think the problem is? Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From dkg at fifthhorseman.net Thu Sep 15 20:29:41 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 15 Sep 2016 14:29:41 -0400 Subject: cleanup: encoding and spelling Message-ID: <87twdh10fe.fsf@alice.fifthhorseman.net> hey all-- I've just made some minor but fairly widespread changes to the codebase. In particular, i fixed a bunch more spelling (all at once instead of dribbling it in) and i converted several files from non-UTF-8 encodings to UTF-8 encodings. In particular, this unifies the po/ directory so that everything is UTF-8 there. The changes are large enough that i'm not going to try to send them via mail -- and at any rate, i don't know how i'd trust a patch that changes the encoding of a file to make it through the e-mail system unscathed. At any rate, you should be able to see the changes on the "encoding-and-speling" branch on https://anonscm.debian.org/git/pkg-gnupg/gnupg2.git If you don't have that in your git repo, you should be able to fetch them and review with: git remote add debian https://anonscm.debian.org/git/pkg-gnupg/gnupg2.git git remote update debian git checkout encoding-and-speling the last of the 3 commits is commit ID aee5ff812c224fb55a60b2b6af3c209eefbd4e31 To look at in the webview: https://anonscm.debian.org/git/pkg-gnupg/gnupg2.git/log/?h=encoding-and-speling I hope this is useful, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From dkg at fifthhorseman.net Thu Sep 15 23:39:43 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 15 Sep 2016 17:39:43 -0400 Subject: coping with unknown keywords on --status-fd Message-ID: <87intw2674.fsf@alice.fifthhorseman.net> hi folks-- Is it safe for a program that is interacting with GnuPG to ignore status keywords that it gets but doesn't understand? DETAILS says: an application should always be prepared to see new keyworkds or more arguments in future versions. (i think that means "keywords", but i missed it in my recent spelling cleanup) What does "prepared to see" mean? does it mean "can safely ignore" ? Is this always going to be the case? If so, can we commit to it explicitly in DETAILS? Recent versions of GnuPG emit KEY_CONSIDERED status lines, which does seem like it could be safely ignored. But consider the situation where a list of keys that are known to be bad is introduced (imagine someone publishes corresponding secret key material, based on a bad system RNG in some OS). If GnuPG were to have access to such a blacklist, i can imagine a future version of GnuPG emitting a new status line like KEY_KNOWN_BAD, during signature validation, but this would not be safe to ignore. Or, would GnuPG emit a BADSIG instead of of a VALIDSIG in this case, in addition to a new KEY_KNOWN_BAD line? The clearer we are about what the project commits to going forward, the less brittle and more forward-compatible any downstream dependencies will be. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From wk at gnupg.org Fri Sep 16 07:53:56 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 16 Sep 2016 07:53:56 +0200 Subject: coping with unknown keywords on --status-fd In-Reply-To: <87intw2674.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 15 Sep 2016 17:39:43 -0400") References: <87intw2674.fsf@alice.fifthhorseman.net> Message-ID: <87eg4kcruz.fsf@wheatstone.g10code.de> On Thu, 15 Sep 2016 23:39, dkg at fifthhorseman.net said: > What does "prepared to see" mean? does it mean "can safely ignore" ? > Is this always going to be the case? If so, can we commit to it "can safely ignore" is what I meant. Sure, there is a reason for some keywords and applications should check whether it makes sense for them to take them in account. > Recent versions of GnuPG emit KEY_CONSIDERED status lines, which does > seem like it could be safely ignored. Right. > emitting a new status line like KEY_KNOWN_BAD, during signature > validation, but this would not be safe to ignore. That would be a new feature of GnuPG and we can't expect that applications can make use of them without knowing about that feature or keyword. > Or, would GnuPG emit a BADSIG instead of of a VALIDSIG in this case, in > addition to a new KEY_KNOWN_BAD line? Right, the existing status keywords won't go away. A precendece for this is that we get a GOODSIG and a VALIDSIG status line for all good signature. The information in GOODSIG were not sufficient and thus VALIDSIG was later introduced. > The clearer we are about what the project commits to going forward, the > less brittle and more forward-compatible any downstream dependencies > will be. Suggestions for a better description are welcome. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From wk at gnupg.org Fri Sep 16 08:09:06 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 16 Sep 2016 08:09:06 +0200 Subject: [PATCH GnuPG] agent: Enable restricted, browser, and ssh socket by default. In-Reply-To: <87d1k52mcc.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 15 Sep 2016 11:50:59 -0400") References: <20160915125804.7568-1-justus@g10code.com> <878tutdw85.fsf@wheatstone.g10code.de> <87d1k52mcc.fsf@alice.fifthhorseman.net> Message-ID: <87a8f8cr5p.fsf@wheatstone.g10code.de> On Thu, 15 Sep 2016 17:50, dkg at fifthhorseman.net said: > these sockets by anyone by default. For SSH, the user will need to set > SSH_AUTH_SOCK explicitly to point to this location, *and* the keys must > be listed in ~/.gnupg/sshcontrol. For the other sockets, the user will ssh-add adds new keys and updates sshcontrol. Manually updating sshcontrol is only required to use keys which were not initially created for ssh. > If ssh auto-starts gpg-agent, then it should absolutely start it up with > the ssh-socket enabled, no? I suspect that if anyone is going to find No, it would first check whether the support has been enabled. >> ssh is and want to use it, are all able to click on >> "enable-ssh-support" in some GnuPG GUI or add it to gpg-agent.conf. > > *and* then point their ssh clients at it. As long as we need to use the clumsy envvar thing in ssh. > provided by the standard socket, right? What's the risk of exposing it > given that the standard socket is already exposed? It used to be common practice in Debian to only open ports which are really needed. Why should gpg-agent open a port (or here a socket) which is in general not required. Adding two extra doors makes it easier to break into a house. Other reasons are extra running code, more strange bug reports, and the user might want to use a different file name for the socket than what gpg-agent defaults to. > flexible, and secure. Actually listening on ssh and extra sockets by > default doesn't seem to violate those goals. I am not convinced. As I said, when we notice that --extra-socket is in real use we can change the defaults easily. But right now it is too esoteric. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From neal at walfield.org Fri Sep 16 08:24:39 2016 From: neal at walfield.org (Neal H. Walfield) Date: Fri, 16 Sep 2016 08:24:39 +0200 Subject: coping with unknown keywords on --status-fd In-Reply-To: <87eg4kcruz.fsf@wheatstone.g10code.de> References: <87intw2674.fsf@alice.fifthhorseman.net> <87eg4kcruz.fsf@wheatstone.g10code.de> Message-ID: <87fup0mkew.wl-neal@walfield.org> On Fri, 16 Sep 2016 07:53:56 +0200, Werner Koch wrote: > On Thu, 15 Sep 2016 23:39, dkg at fifthhorseman.net said: > > emitting a new status line like KEY_KNOWN_BAD, during signature > > validation, but this would not be safe to ignore. > > That would be a new feature of GnuPG and we can't expect that > applications can make use of them without knowing about that feature or > keyword. Of course. But, we could introduce something like: if a keyword is preceded by a '!' and the applications does not understand the keyword, the application should abort. :) Neal From gniibe at fsij.org Fri Sep 16 13:26:45 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 16 Sep 2016 20:26:45 +0900 Subject: cleanup: encoding and spelling In-Reply-To: <87twdh10fe.fsf@alice.fifthhorseman.net> References: <87twdh10fe.fsf@alice.fifthhorseman.net> Message-ID: <28de62ec-25e8-3409-3bcd-38879d44acac@fsij.org> Hello, Thanks for working this. On 09/16/2016 03:29 AM, Daniel Kahn Gillmor wrote: > In particular, this unifies the po/ directory so that everything is > UTF-8 there. I'll take care of these changes of PO files. To be sure, I checked PO files of 1.4, 2.0 and 2.1. I realized that most files which had changes in recent years are all by UTF-8. Except Portuguese (pt). For Portuguese, I'll write to the translator to inform this encoding change. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From aheinecke at intevation.de Fri Sep 16 14:20:57 2016 From: aheinecke at intevation.de (Andre Heinecke) Date: Fri, 16 Sep 2016 14:20:57 +0200 Subject: New theme for wiki.gnupg.org Message-ID: <1520319.Ool5WpojMh@esus> Hi, We've enabled a new (modern and responsive) theme for wiki.gnupg.org. The theme is memodump [1] and is personally my favorite theme for moinmoin :-) You can enable it in your user settings: https://wiki.gnupg.org/Index?action=userprefs&sub=prefs Under preferred theme. Change it to memodump to enable the new theme. What do you think, should we make this theme default? Any suggestions for improvements? Regards, Andre 1: https://github.com/dossist/moinmoin-memodump -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: This is a digitally signed message part. URL: From dkg at fifthhorseman.net Fri Sep 16 22:39:20 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 16 Sep 2016 16:39:20 -0400 Subject: coping with unknown keywords on --status-fd In-Reply-To: <87fup0mkew.wl-neal@walfield.org> References: <87intw2674.fsf@alice.fifthhorseman.net> <87eg4kcruz.fsf@wheatstone.g10code.de> <87fup0mkew.wl-neal@walfield.org> Message-ID: <87vaxvziiv.fsf@alice.fifthhorseman.net> On Fri 2016-09-16 02:24:39 -0400, Neal H. Walfield wrote: > Of course. But, we could introduce something like: if a keyword is > preceded by a '!' and the applications does not understand the > keyword, the application should abort. This is a lot like the "critical" flag in OpenPGP subpackets. I understand why it would be useful for upstream. But if you want to reserve this feature, the syntax and semantics needs to be decided as soon as possible, and clearly documented. Otherwise, you get consumers of the API implemented that don't know about the criticality flag, which blithely ignore newly-introduced critical status lines. You cannot simply introduce the criticality feature with the first status line that needs the criticality, right? I'm in the process of doing a bunch of triage of consumers of this API within debian, and complete+successful implementations are unfortunately rare. Having a concise overview of these sort of concerns for implementers to review would be really helpful. Should i advise these projects that they should fail/abort on encountering !-prefixed unknown status lines or not? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From gniibe at fsij.org Sat Sep 17 09:24:15 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Sat, 17 Sep 2016 16:24:15 +0900 Subject: cleanup: encoding and spelling In-Reply-To: <28de62ec-25e8-3409-3bcd-38879d44acac@fsij.org> References: <87twdh10fe.fsf@alice.fifthhorseman.net> <28de62ec-25e8-3409-3bcd-38879d44acac@fsij.org> Message-ID: I reviewed other two commits and merged them to master. Then, I fix some minor things. -- From wk at gnupg.org Sat Sep 17 10:26:35 2016 From: wk at gnupg.org (Werner Koch) Date: Sat, 17 Sep 2016 10:26:35 +0200 Subject: coping with unknown keywords on --status-fd In-Reply-To: <87vaxvziiv.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 16 Sep 2016 16:39:20 -0400") References: <87intw2674.fsf@alice.fifthhorseman.net> <87eg4kcruz.fsf@wheatstone.g10code.de> <87fup0mkew.wl-neal@walfield.org> <87vaxvziiv.fsf@alice.fifthhorseman.net> Message-ID: <87h99f9bk4.fsf@wheatstone.g10code.de> On Fri, 16 Sep 2016 22:39, dkg at fifthhorseman.net said: > This is a lot like the "critical" flag in OpenPGP subpackets. I Indeed, however this is not really helpful because the most common problem are wrong implementations and not missing new keywords. Anyway, if we want to do an backward incompatible change (which is what the introduction of a '!' means) we have easier way to do that. The simplest would be to renamed the --status-fd option or to rename expected status keywords. > I'm in the process of doing a bunch of triage of consumers of this API > within debian, and complete+successful implementations are unfortunately > rare. Thanks for doing that. At our telco yesterday we briefly talked about audits of GnuPG consumers and we consider this a Good Thing; with the only problem that we have not enough time to do that. I would appreciate if you make your results availabale, so that we can write a small HOTO on proper use of gpg by scripts and applications. > Having a concise overview of these sort of concerns for implementers to > review would be really helpful. Should i advise these projects that > they should fail/abort on encountering !-prefixed unknown status lines You may instead want to point them to GPGME instead. This library makes many things easier. Support for 2.1 feature is GPGME close to ready. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From neal at walfield.org Sat Sep 17 11:16:21 2016 From: neal at walfield.org (Neal H. Walfield) Date: Sat, 17 Sep 2016 11:16:21 +0200 Subject: coping with unknown keywords on --status-fd In-Reply-To: <87h99f9bk4.fsf@wheatstone.g10code.de> References: <87intw2674.fsf@alice.fifthhorseman.net> <87eg4kcruz.fsf@wheatstone.g10code.de> <87fup0mkew.wl-neal@walfield.org> <87vaxvziiv.fsf@alice.fifthhorseman.net> <87h99f9bk4.fsf@wheatstone.g10code.de> Message-ID: <878tuqnaxm.wl-neal@walfield.org> On Sat, 17 Sep 2016 10:26:35 +0200, Werner Koch wrote: > On Fri, 16 Sep 2016 22:39, dkg at fifthhorseman.net said: > > > This is a lot like the "critical" flag in OpenPGP subpackets. I > > Indeed, however this is not really helpful because the most common > problem are wrong implementations and not missing new keywords. Anyway, > if we want to do an backward incompatible change (which is what the > introduction of a '!' means) we have easier way to do that. The > simplest would be to renamed the --status-fd option or to rename > expected status keywords. I'm not sure your suggestions are the best way to address Daniel's concerns. In his original mail, he writes: What does "prepared to see" mean? does it mean "can safely ignore" [unknown keywords]? But consider the situation where a list of keys that are known to be bad is introduced (imagine someone publishes corresponding secret key material, based on a bad system RNG in some OS). If GnuPG were to have access to such a blacklist, i can imagine a future version of GnuPG emitting a new status line like KEY_KNOWN_BAD, during signature validation, but this would not be safe to ignore. I think renaming --status-fd to deal with this is disproportionate and ought to be avoided. Also, I don't see how renaming a keyword would help here. But, something like a critical flag would allow an application / gpgme to know that if it receives !KEY_KNOWN_BAD, it should refuse to continue, even if it doesn't understand the KEY_KNOWN_BAD keyword. :) Neal From wk at gnupg.org Sat Sep 17 13:21:34 2016 From: wk at gnupg.org (Werner Koch) Date: Sat, 17 Sep 2016 13:21:34 +0200 Subject: coping with unknown keywords on --status-fd In-Reply-To: <878tuqnaxm.wl-neal@walfield.org> (Neal H. Walfield's message of "Sat, 17 Sep 2016 11:16:21 +0200") References: <87intw2674.fsf@alice.fifthhorseman.net> <87eg4kcruz.fsf@wheatstone.g10code.de> <87fup0mkew.wl-neal@walfield.org> <87vaxvziiv.fsf@alice.fifthhorseman.net> <87h99f9bk4.fsf@wheatstone.g10code.de> <878tuqnaxm.wl-neal@walfield.org> Message-ID: <87a8f6ai0x.fsf@wheatstone.g10code.de> On Sat, 17 Sep 2016 11:16, neal at walfield.org said: > I'm not sure your suggestions are the best way to address Daniel's > concerns. In his original mail, he writes: > > What does "prepared to see" mean? does it mean "can safely ignore" > [unknown keywords]? Don't bail out on unknown keywords. There is no requirement to act on everything. Remember what Jon Postel said: TCP implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others. This rule turned out to be major success story for the Internet (in contrast to OSI) and has been codified in RFC-1122 (Requirements for Internet Hosts -- Communication Layers). Agreed: In certain security protocol parts you need to be much more stricter - but this is what gpg encapsulates for you. > I think renaming --status-fd to deal with this is disproportionate and > ought to be avoided. Also, I don't see how renaming a keyword would I mentioned this to show how it would be possible to make applications using a newer gpg version fail - in the case gpg breaks the interface. Note that there has only been one interface break in the last 18 years: The removal of the --fixed-list-mode option in 2.1 - after it was introduced in 2001. And that has nothing to do with the status-fd output - the status-fd output has only be enhanced. The experience in X.509 and OpenPGP is also that critical flags just don't work. You simply claim that you understand them and go on with your business. This is all an non-issue. The real issue is that the majority of users still avoid the --status-fd interface and encounter breakage all the time; for example because they also forget to LC_ALL=C. You can't magically fix wrong usage of a tool. Consider how many scripts will fail on file or directory names with spaces or other unusual but allowed characters. The only thing you can do is to explain what to do. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From dkg at fifthhorseman.net Sat Sep 17 17:34:35 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 17 Sep 2016 11:34:35 -0400 Subject: [PATCH] doc/DETAILS: clarify forward-compatible expectations In-Reply-To: <87eg4kcruz.fsf@wheatstone.g10code.de> References: <87eg4kcruz.fsf@wheatstone.g10code.de> Message-ID: <20160917153435.29347-1-dkg@fifthhorseman.net> * doc/DETAILS: encourage better parsers/interpreters of with-colons and status-fd output. Signed-off-by: Daniel Kahn Gillmor --- doc/DETAILS | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/doc/DETAILS b/doc/DETAILS index b5431d0..8303cc6 100644 --- a/doc/DETAILS +++ b/doc/DETAILS @@ -35,7 +35,9 @@ Note that new version of GnuPG or the use of certain options may add new fields to the output. Parsers should not assume a limit on the number of fields per line. Some fields are not yet used or only used with certain record types; parsers should ignore fields they are not -aware of. +aware of. New versions of GnuPG or the use of certain options may add +new types of records as well. Parsers should ignore any record whose +type they do not recognize for forward-compatibility. The double =--with-fingerprint= prints the fingerprint for the subkeys too. Old versions of gpg used a slightly different format and required @@ -357,8 +359,10 @@ pkd:0:1024:B665B1435F4C2 .... FF26ABB: Every line is prefixed with "[GNUPG:] ", followed by a keyword with the type of the status line and some arguments depending on the type - (maybe none); an application should always be prepared to see new - keyworkds or more arguments in future versions. + (maybe none); an application should always be willing to ignore + unknown keywords that may be emitted by future versions of GnuPG. + Also, new versions of GnuPG may add arguments to existing keywords. + Any additional arguments should be ignored for forward-compatibility. ** General status codes *** NEWSIG [] -- 2.9.3 From wk at gnupg.org Sat Sep 17 19:03:18 2016 From: wk at gnupg.org (Werner Koch) Date: Sat, 17 Sep 2016 19:03:18 +0200 Subject: [PATCH] doc/DETAILS: clarify forward-compatible expectations In-Reply-To: <20160917153435.29347-1-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Sat, 17 Sep 2016 11:34:35 -0400") References: <87eg4kcruz.fsf@wheatstone.g10code.de> <20160917153435.29347-1-dkg@fifthhorseman.net> Message-ID: <871t0ia27d.fsf@wheatstone.g10code.de> On Sat, 17 Sep 2016 17:34, dkg at fifthhorseman.net said: > * doc/DETAILS: encourage better parsers/interpreters of with-colons > and status-fd output. Thanks. For such chnages a detail per file description is not required. Thus I changed the message to doc: Clarify forward-compatible expectations -- Encourage better parsers/interpreters of with-colons and status-fd output. Signed-off-by: Daniel Kahn Gillmor This also keep it out of the generated ChnageLog file. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From ineiev at gnu.org Sun Sep 18 07:18:38 2016 From: ineiev at gnu.org (Ineiev) Date: Sun, 18 Sep 2016 01:18:38 -0400 Subject: [HEAD] typos in doc/ In-Reply-To: <87k2hiw5yr.fsf@wheatstone.g10code.de> References: <20160126163942.GA9804@gnu.org> <87y4bbs6c7.fsf@vigenere.g10code.de> <20160310181200.GA25817@gnu.org> <20160409054645.GA4688@gnu.org> <20160508090546.GA15840@gnu.org> <20160620170501.GC23709@gnu.org> <87twgnpvy4.wl-neal@walfield.org> <87k2hiw5yr.fsf@wheatstone.g10code.de> Message-ID: <20160918051837.GF30569@gnu.org> On Wed, Jun 22, 2016 at 12:08:12AM +0200, Werner Koch wrote: > On Mon, 20 Jun 2016 20:16, neal at walfield.org said: > > > It is probably better to send these types of messages to gnupg-devel. > > Actually they are still flagged as to-be-processed in my mail folder > :-(. Good that you followed up on this. Thank you. Rebased against current HEAD (55675fa), with a new typo catched. -------------- next part -------------- A non-text attachment was scrubbed... Name: doc-fixes-55675fa.tar.gz Type: application/octet-stream Size: 28481 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From wk at gnupg.org Mon Sep 19 08:07:44 2016 From: wk at gnupg.org (Werner Koch) Date: Mon, 19 Sep 2016 08:07:44 +0200 Subject: [PATCH] Check for GPG_TTY as well as DISPLAY. In-Reply-To: <1472944021-2356043.18370404.fu83N6bHl019328@rs146.luxsci.com> (Ben Kibbey's message of "Sat, 3 Sep 2016 19:06:36 -0400") References: <1445385603-3678688.75890528.ft9KNxZWg007079@rs146.luxsci.com> <87eggohvmq.fsf@vigenere.g10code.de> <1445465282-9798705.77418447.ft9LM7KOY017487@rs146.luxsci.com> <20151022011509.GB15333@picnic> <1472944021-2356043.18370404.fu83N6bHl019328@rs146.luxsci.com> Message-ID: <87wpi8777z.fsf@wheatstone.g10code.de> On Sun, 4 Sep 2016 01:06, bjk at luxsci.net said: > It turns out I need this ability again. Attached is a revised patch with > better readability. Since gpg-agent will always use the DISPLAY when > set, and the user would need to replace/set GPG_TTY in the current > environment, I don't see how it can break anything. Applied. Thanks. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From justus at g10code.com Mon Sep 19 12:21:34 2016 From: justus at g10code.com (Justus Winter) Date: Mon, 19 Sep 2016 12:21:34 +0200 Subject: [PATCH GnuPG] agent: Enable restricted, browser, and ssh socket by default. In-Reply-To: <87a8f8cr5p.fsf@wheatstone.g10code.de> References: <20160915125804.7568-1-justus@g10code.com> <878tutdw85.fsf@wheatstone.g10code.de> <87d1k52mcc.fsf@alice.fifthhorseman.net> <87a8f8cr5p.fsf@wheatstone.g10code.de> Message-ID: <8737kwtck1.fsf@europa.jade-hamburg.de> Hello :) I'm really keen on convincing you, so here goes :) Werner Koch writes: >> If ssh auto-starts gpg-agent, then it should absolutely start it up with >> the ssh-socket enabled, no? I suspect that if anyone is going to find > > No, it would first check whether the support has been enabled. That's a pretty big if in the first place. I don't see how we can add auto-start support to ssh. Upstream won't accept such a patch, and I don't see Debian adding a patch for that either tbh. In any case, we will deal with the problem when and if that arises. >> provided by the standard socket, right? What's the risk of exposing it >> given that the standard socket is already exposed? > > It used to be common practice in Debian to only open ports which are > really needed. Why should gpg-agent open a port (or here a socket) > which is in general not required. Adding two extra doors makes it > easier to break into a house. If an attacker has access to your ~/.gnupg, she can use the non-restricted socket anyway, so what's the harm in also enabling the restricted socket? > Other reasons are extra running code, more strange bug reports, and the > user might want to use a different file name for the socket than what > gpg-agent defaults to. If there are bugs, then we will fix them. Also, it is still possible to use the option to specify a different name. I was carefull not to break anyones setup. >> flexible, and secure. Actually listening on ssh and extra sockets by >> default doesn't seem to violate those goals. > > I am not convinced. > > As I said, when we notice that --extra-socket is in real use we can > change the defaults easily. But right now it is too esoteric. I don't believe any feature will see "real use" until we stop hiding it away using some configuration option. And agent-forwarding isn't an esoteric use case. ~~~ I believe that ssh support and the restricted socket for agent-forwarding are awesome features, please don't hide features in the default configuration. Nowadays I'm using both features, but I had not even heard of them before I started working for GnuPG and dug deep into the manuals. I don't see the web socket being widely used if we need to instruct anyone who wants to use it to tweak their gnupg configuration first. And we enabled loopback pinentry by default so that Mailpile users don't have to do that manually. Another way to look at this problem is this. GnuPG is a low-level tool, we explicitly do not create fancy user interfaces. Instead, we rely on people to create awesome tools on top of GnuPG. Any such tool that requires additional tweaks to the GnuPG configuration either has to change the configuration itself or ask the user to do it. The former is frowned upon, and the latter is a huge usability problem. Therefore, tools using GnuPG are essentially restricted to the set of features that is enabled by default. Cheers, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From ca+gnupg-devel at esmtp.org Mon Sep 19 13:32:41 2016 From: ca+gnupg-devel at esmtp.org (Claus Assmann) Date: Mon, 19 Sep 2016 04:32:41 -0700 Subject: [PATCH GnuPG] agent: Enable restricted, browser, and ssh socket by default. In-Reply-To: <87a8f8cr5p.fsf@wheatstone.g10code.de> References: <20160915125804.7568-1-justus@g10code.com> <878tutdw85.fsf@wheatstone.g10code.de> <87d1k52mcc.fsf@alice.fifthhorseman.net> <87a8f8cr5p.fsf@wheatstone.g10code.de> Message-ID: <20160919113241.GA5510@x2.esmtp.org> On Fri, Sep 16, 2016, Werner Koch wrote: > really needed. Why should gpg-agent open a port (or here a socket) > which is in general not required. Adding two extra doors makes it > Other reasons are extra running code, more strange bug reports, and the Software should be "secure by default", and not "enable as many options as all of the developers together can come up with"; especially when it comes to software that is related to security. From wk at gnupg.org Mon Sep 19 18:16:12 2016 From: wk at gnupg.org (Werner Koch) Date: Mon, 19 Sep 2016 18:16:12 +0200 Subject: [PATCH GnuPG] agent: Enable restricted, browser, and ssh socket by default. In-Reply-To: <8737kwtck1.fsf@europa.jade-hamburg.de> (Justus Winter's message of "Mon, 19 Sep 2016 12:21:34 +0200") References: <20160915125804.7568-1-justus@g10code.com> <878tutdw85.fsf@wheatstone.g10code.de> <87d1k52mcc.fsf@alice.fifthhorseman.net> <87a8f8cr5p.fsf@wheatstone.g10code.de> <8737kwtck1.fsf@europa.jade-hamburg.de> Message-ID: <87ponz27cj.fsf@wheatstone.g10code.de> On Mon, 19 Sep 2016 12:21, justus at g10code.com said: > That's a pretty big if in the first place. I don't see how we can add > auto-start support to ssh. Upstream won't accept such a patch, and I Hey, don't say this. As long as we make it generic enough I see no sound reason not to get this upstream. > If an attacker has access to your ~/.gnupg, she can use the > non-restricted socket anyway, so what's the harm in also enabling the > restricted socket? As I said, it is another open door. It is the same as running portmap despite that you won't use it. Unfortunately, Debian seems to enable portmap these days by default. (Debian is not anymore the only distro which could be called secure by default :-() > use the option to specify a different name. I was carefull not to break > anyones setup. I have not see a way to disable this feature at all. This be a hard requirement. Actually this is not easy to do if you also want gpgconf be abale to modify it. However, I would except the use of "/dev/null" as flag to disable the socket. > away using some configuration option. And agent-forwarding isn't an > esoteric use case. It is pretty new; it works since January 2015 - and it is only possible since the release of OpenBSD 6.7 (?) which back then was not even in Debian. > I believe that ssh support and the restricted socket for > agent-forwarding are awesome features, please don't hide features in the Agreed. Well, your change would not have helped you either. Adding enable-ssh-socket to gpg-agent.conf is the smallest part of the stroy. The more complicated thing is the external setup and the new concept. > And we enabled loopback pinentry by default so that Mailpile users don't > have to do that manually. I am still not convinced that this was a good idea ;-) > people to create awesome tools on top of GnuPG. Any such tool that > requires additional tweaks to the GnuPG configuration either has to > change the configuration itself or ask the user to do it. The former is Yes, the tools should do that. gpgconf provides an easy way to change the configuraions. Tools are already chnaging gpg'c configuraion behind the back of the user. > frowned upon, and the latter is a huge usability problem. Therefore, > tools using GnuPG are essentially restricted to the set of features that > is enabled by default. Yes, they should stick to that, for example to use the Pinentry by default. If they want something else, they need to tweak things. Anyway, if you provide a new patch with a way for gpgconf to disable the new default and with shorter socket names (e.g. change "S.gpg-agent.restricted" to "S.gpg-agent.xtr" or ".extra"), it would be hard for me to reject such a patch. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From bertrand at jacquin.bzh Tue Sep 20 01:02:45 2016 From: bertrand at jacquin.bzh (Bertrand Jacquin) Date: Tue, 20 Sep 2016 00:02:45 +0100 Subject: browser-socket was (was: Enable restricted, browser, and ssh socket by default) In-Reply-To: <8737kwtck1.fsf@europa.jade-hamburg.de> References: <20160915125804.7568-1-justus@g10code.com> <878tutdw85.fsf@wheatstone.g10code.de> <87d1k52mcc.fsf@alice.fifthhorseman.net> <87a8f8cr5p.fsf@wheatstone.g10code.de> <8737kwtck1.fsf@europa.jade-hamburg.de> Message-ID: Hi all, On 19/09/2016 11:21, Justus Winter wrote: > I don't see the web socket being widely used if we need to instruct > anyone who wants to use it to tweak their gnupg configuration first. > And we enabled loopback pinentry by default so that Mailpile users > don't > have to do that manually. Reading this thread makes also me reading for the first time about browser-socket, as you said it's not even documented, but I'm wondering what is the goal of this option and it has any support by any browser so far. I'm curious to hear on this subject. Cheers, -- Bertrand From gniibe at fsij.org Tue Sep 20 04:30:46 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 20 Sep 2016 11:30:46 +0900 Subject: [HEAD] typos in doc/ In-Reply-To: <20160918051837.GF30569@gnu.org> References: <20160126163942.GA9804@gnu.org> <87y4bbs6c7.fsf@vigenere.g10code.de> <20160310181200.GA25817@gnu.org> <20160409054645.GA4688@gnu.org> <20160508090546.GA15840@gnu.org> <20160620170501.GC23709@gnu.org> <87twgnpvy4.wl-neal@walfield.org> <87k2hiw5yr.fsf@wheatstone.g10code.de> <20160918051837.GF30569@gnu.org> Message-ID: <967d48b9-9474-ddf6-5901-9167f5427f09@fsij.org> On 09/18/2016 02:18 PM, Ineiev wrote: > Rebased against current HEAD (55675fa), with a new typo catched. Thanks for those fixes. I reviewed and merged following patches: 0001-Fix-Martin-Hellman-s-name.patch 0006-Fix-typos.patch 0007-Fix-Not-e-that-you-can-not-abbreviate.patch 0008-Use-the-right-reference-commands.patch 0009-Eliminate-inconsistent-UK-English.patch 0011-Fix-mistakes.patch 0012-Replace-UTF8-with-UTF-8.patch 0013-Add-missing-description-of-datafile.patch 0014-Replace-rfc0123-with-RFC-0123.patch 0015-Improve-markup.patch 0005-Fix-spacings.patch Please note that I merged following patch with small changes: 0011-Fix-mistakes.patch 0013-Add-missing-description-of-datafile.patch For 0011, I think that "option" argument (with "option" in different font) is not a mistake, although it's not best. For 0013, I added [] for datafile. I leave following patches unapplied, since I think that we need to make sure the changes are relevant. 0002-Do-not-end-section-names-with.patch 0003-End-menu-comments-with.patch 0004-Replace-table-asis-with-itemize-bullet.patch 0010-Fix-full-stops.patch -- From ineiev at gnu.org Tue Sep 20 09:15:16 2016 From: ineiev at gnu.org (Ineiev) Date: Tue, 20 Sep 2016 03:15:16 -0400 Subject: [HEAD] typos in doc/ In-Reply-To: <967d48b9-9474-ddf6-5901-9167f5427f09@fsij.org> References: <20160126163942.GA9804@gnu.org> <87y4bbs6c7.fsf@vigenere.g10code.de> <20160310181200.GA25817@gnu.org> <20160409054645.GA4688@gnu.org> <20160508090546.GA15840@gnu.org> <20160620170501.GC23709@gnu.org> <87twgnpvy4.wl-neal@walfield.org> <87k2hiw5yr.fsf@wheatstone.g10code.de> <20160918051837.GF30569@gnu.org> <967d48b9-9474-ddf6-5901-9167f5427f09@fsij.org> Message-ID: <20160920071516.GK30569@gnu.org> On Tue, Sep 20, 2016 at 11:30:46AM +0900, NIIBE Yutaka wrote: > > I reviewed and merged following patches: ... > For 0013, I added [] for datafile. Thank you! > I leave following patches unapplied, since I think that we need to > make sure the changes are relevant. > > 0002-Do-not-end-section-names-with.patch > 0003-End-menu-comments-with.patch > 0004-Replace-table-asis-with-itemize-bullet.patch Probably it makes sense to drop these patches: the changes in 0002 and 0003 are quite minor, in 0004, @table is arguably as adequate as itemize. > 0010-Fix-full-stops.patch I think most of this must be relevant. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From gniibe at fsij.org Tue Sep 20 09:43:59 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 20 Sep 2016 16:43:59 +0900 Subject: [HEAD] typos in doc/ In-Reply-To: <20160920071516.GK30569@gnu.org> References: <20160126163942.GA9804@gnu.org> <87y4bbs6c7.fsf@vigenere.g10code.de> <20160310181200.GA25817@gnu.org> <20160409054645.GA4688@gnu.org> <20160508090546.GA15840@gnu.org> <20160620170501.GC23709@gnu.org> <87twgnpvy4.wl-neal@walfield.org> <87k2hiw5yr.fsf@wheatstone.g10code.de> <20160918051837.GF30569@gnu.org> <967d48b9-9474-ddf6-5901-9167f5427f09@fsij.org> <20160920071516.GK30569@gnu.org> Message-ID: <061d34cb-d9d2-24bc-343a-57b7e71dfc82@fsij.org> Hello, Ineiev, Then, I reviewed and applied following patches: 0002-Do-not-end-section-names-with.patch 0010-Fix-full-stops.patch Justus and I made fixes for yat2m and gpgsm.texi. I decided not to apply following patches: 0003-End-menu-comments-with.patch 0004-Replace-table-asis-with-itemize-bullet.patch Also, Werner pushed this change: https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=81cb71ab4d516a1e8b09a69508f7887f98508642 I was a bit careless when I applied your patch of: 0007-Fix-Not-e-that-you-can-not-abbreviate.patch In this context, "abbreviation" specifically refers to GnuPG's handling of partial string match, which is not applicable to "--help", "--version" or "--dump-options". (While short options are available.) Other options can be "abbreviated", for example, --list-secret-keys can be --list-sec. -- From wk at gnupg.org Tue Sep 20 09:54:42 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Sep 2016 09:54:42 +0200 Subject: browser-socket was In-Reply-To: (Bertrand Jacquin's message of "Tue, 20 Sep 2016 00:02:45 +0100") References: <20160915125804.7568-1-justus@g10code.com> <878tutdw85.fsf@wheatstone.g10code.de> <87d1k52mcc.fsf@alice.fifthhorseman.net> <87a8f8cr5p.fsf@wheatstone.g10code.de> <8737kwtck1.fsf@europa.jade-hamburg.de> Message-ID: <87h99bvwe5.fsf@wheatstone.g10code.de> On Tue, 20 Sep 2016 01:02, bertrand at jacquin.bzh said: > browser-socket, as you said it's not even documented, but I'm > wondering what is the goal of this option and it has any support by It is the same as --extra-socket but shows a different message in the Pinentry. The idea is to allow a browser to use gpg-agent. This can be accomplished by changing openpgp.js by diverting secret key operations to gpg-agent via a not yet written Native-Messaging-to-Assuan connector tool. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From justus at g10code.com Tue Sep 20 10:12:09 2016 From: justus at g10code.com (Justus Winter) Date: Tue, 20 Sep 2016 10:12:09 +0200 Subject: [PATCH GnuPG] agent: Enable restricted, browser, and ssh socket by default. In-Reply-To: <87ponz27cj.fsf@wheatstone.g10code.de> References: <20160915125804.7568-1-justus@g10code.com> <878tutdw85.fsf@wheatstone.g10code.de> <87d1k52mcc.fsf@alice.fifthhorseman.net> <87a8f8cr5p.fsf@wheatstone.g10code.de> <8737kwtck1.fsf@europa.jade-hamburg.de> <87ponz27cj.fsf@wheatstone.g10code.de> Message-ID: <87eg4fyopy.fsf@europa.jade-hamburg.de> Werner Koch writes: >> use the option to specify a different name. I was carefull not to break >> anyones setup. > > I have not see a way to disable this feature at all. This be a hard > requirement. Actually this is not easy to do if you also want gpgconf > be abale to modify it. However, I would except the use of "/dev/null" > as flag to disable the socket. Ok. >> I believe that ssh support and the restricted socket for >> agent-forwarding are awesome features, please don't hide features in the > > Agreed. Well, your change would not have helped you either. Adding > enable-ssh-socket to gpg-agent.conf is the smallest part of the stroy. > The more complicated thing is the external setup and the new concept. Sure it helps, it makes it easier to use and way easier to discover in the first place. >> people to create awesome tools on top of GnuPG. Any such tool that >> requires additional tweaks to the GnuPG configuration either has to >> change the configuration itself or ask the user to do it. The former is > > Yes, the tools should do that. gpgconf provides an easy way to change > the configuraions. Tools are already chnaging gpg'c configuraion behind > the back of the user. Please clarify. Do you consider automatic changes of the configuration okay or not? (Because here you write they should change the configuration, and in the next paragraph you write they should stick to the default.) >> frowned upon, and the latter is a huge usability problem. Therefore, >> tools using GnuPG are essentially restricted to the set of features that >> is enabled by default. > > Yes, they should stick to that, for example to use the Pinentry by > default. If they want something else, they need to tweak things. What if two tools need contradicting settings? > Anyway, if you provide a new patch with a way for gpgconf to disable the > new default and with shorter socket names (e.g. change > "S.gpg-agent.restricted" to "S.gpg-agent.xtr" or ".extra"), it would be > hard for me to reject such a patch. I'm really unhappy with the name 'extra', because it carries little meaning (we could as well call it 'second', or 'yetanother'). 'restricted' on the other hand hints at why you might want to use this over the standard socket. Maybe 'remote'... Cheers, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From wk at gnupg.org Tue Sep 20 11:51:33 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Sep 2016 11:51:33 +0200 Subject: [PATCH GnuPG] agent: Enable restricted, browser, and ssh socket by default. In-Reply-To: <87eg4fyopy.fsf@europa.jade-hamburg.de> (Justus Winter's message of "Tue, 20 Sep 2016 10:12:09 +0200") References: <20160915125804.7568-1-justus@g10code.com> <878tutdw85.fsf@wheatstone.g10code.de> <87d1k52mcc.fsf@alice.fifthhorseman.net> <87a8f8cr5p.fsf@wheatstone.g10code.de> <8737kwtck1.fsf@europa.jade-hamburg.de> <87ponz27cj.fsf@wheatstone.g10code.de> <87eg4fyopy.fsf@europa.jade-hamburg.de> Message-ID: <87r38evqze.fsf@wheatstone.g10code.de> On Tue, 20 Sep 2016 10:12, justus at g10code.com said: > Please clarify. Do you consider automatic changes of the configuration > okay or not? Yes. On a desktop the main gnupg application may change gpg-agent so that it works bets for this use case. That is what we have done all the time for example with keyservers. > What if two tools need contradicting settings? The configuration option in question are system policy decisions (e.g. loopback password, passphrase constraints and so on). Thus there can be only one valid setting. A tool requiring a contradicting setting would violate the system policy. Note that gpgconf has a way to inhibit certain changes based on a system wide policy file (/etc/gnupg/gpgconf.conf) > 'restricted' on the other hand hints at why you might want to use this > over the standard socket. Maybe 'remote'... I recall that my first idea for the option name was --remote-socket. I did not name it so because it is not a remote socket but a local socket which is forwarded to the remote site using a separate tool (ssh). "restricted" does not describe the feature, "additional" would be better but that is too long; thus I still like "extra". Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From neal at walfield.org Tue Sep 20 12:23:18 2016 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 20 Sep 2016 12:23:18 +0200 Subject: [PATCH GnuPG] agent: Enable restricted, browser, and ssh socket by default. In-Reply-To: <87r38evqze.fsf@wheatstone.g10code.de> References: <20160915125804.7568-1-justus@g10code.com> <878tutdw85.fsf@wheatstone.g10code.de> <87d1k52mcc.fsf@alice.fifthhorseman.net> <87a8f8cr5p.fsf@wheatstone.g10code.de> <8737kwtck1.fsf@europa.jade-hamburg.de> <87ponz27cj.fsf@wheatstone.g10code.de> <87eg4fyopy.fsf@europa.jade-hamburg.de> <87r38evqze.fsf@wheatstone.g10code.de> Message-ID: <87vaxqlvjd.wl-neal@walfield.org> On Tue, 20 Sep 2016 11:51:33 +0200, Werner Koch wrote: > > 'restricted' on the other hand hints at why you might want to use this > > over the standard socket. Maybe 'remote'... > > I recall that my first idea for the option name was --remote-socket. I > did not name it so because it is not a remote socket but a local socket > which is forwarded to the remote site using a separate tool (ssh). > > "restricted" does not describe the feature, "additional" would be better > but that is too long; thus I still like "extra". FWIW, one way to think of these different sockets is that they are capabilities: they are references to an object (GnuPG) and the reference carries the access control information (what operations are allowed). The only way to, say, decrypt a message is to invoke the appropriate operation on the GnuPG object, which is done via one of the capabilities (sockets), which determines whether this operation is allowed (the identity of the caller is not somehow checked like with ACLs). From dkg at fifthhorseman.net Tue Sep 20 03:22:36 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 19 Sep 2016 21:22:36 -0400 Subject: [PATCH GnuPG] agent: Enable restricted, browser, and ssh socket by default. In-Reply-To: <20160919113241.GA5510@x2.esmtp.org> References: <20160915125804.7568-1-justus@g10code.com> <878tutdw85.fsf@wheatstone.g10code.de> <87d1k52mcc.fsf@alice.fifthhorseman.net> <87a8f8cr5p.fsf@wheatstone.g10code.de> <20160919113241.GA5510@x2.esmtp.org> Message-ID: <87bmzjxt43.fsf@alice.fifthhorseman.net> On Mon 2016-09-19 07:32:41 -0400, Claus Assmann wrote: > On Fri, Sep 16, 2016, Werner Koch wrote: > >> really needed. Why should gpg-agent open a port (or here a socket) >> which is in general not required. Adding two extra doors makes it > >> Other reasons are extra running code, more strange bug reports, and the > > Software should be "secure by default", and not "enable as many > options as all of the developers together can come up with"; > especially when it comes to software that is related to security. Following this line of argument, we could say that only the restricted socket should be enabled by default, and the normal socket should be disabled. However, that would make gpg-agent unusable in many use cases, so we don't do it. offering the restricted socket in addition to the normal socket doesn't seem to increase the attack surface. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From justus at g10code.com Tue Sep 20 16:19:13 2016 From: justus at g10code.com (Justus Winter) Date: Tue, 20 Sep 2016 16:19:13 +0200 Subject: [PATCH GnuPG] agent: Enable restricted, browser, and ssh socket by default. In-Reply-To: <87r38evqze.fsf@wheatstone.g10code.de> References: <20160915125804.7568-1-justus@g10code.com> <878tutdw85.fsf@wheatstone.g10code.de> <87d1k52mcc.fsf@alice.fifthhorseman.net> <87a8f8cr5p.fsf@wheatstone.g10code.de> <8737kwtck1.fsf@europa.jade-hamburg.de> <87ponz27cj.fsf@wheatstone.g10code.de> <87eg4fyopy.fsf@europa.jade-hamburg.de> <87r38evqze.fsf@wheatstone.g10code.de> Message-ID: <87bmzizmam.fsf@europa.jade-hamburg.de> Werner Koch writes: > On Tue, 20 Sep 2016 10:12, justus at g10code.com said: > >> Please clarify. Do you consider automatic changes of the configuration >> okay or not? > > Yes. On a desktop the main gnupg application may change gpg-agent so > that it works bets for this use case. That is what we have done all the > time for example with keyservers. Are you somehow saying that GnuPG can only be used by one application? What is a (the? my? your?) main GnuPG application? >> 'restricted' on the other hand hints at why you might want to use this >> over the standard socket. Maybe 'remote'... > > I recall that my first idea for the option name was --remote-socket. I > did not name it so because it is not a remote socket but a local socket > which is forwarded to the remote site using a separate tool (ssh). > > "restricted" does not describe the feature, "additional" would be better > but that is too long; thus I still like "extra". The "extra" socket allows merely a subset of the operation that the "normal" socket allows, hence the allowed operations are restricted to that subset. How is "additional" a better name then "restricted"? It does not indicate that the set of operations is restricted. "additional" means nothing except that it is not the only socket. Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From ineiev at gnu.org Tue Sep 20 18:05:46 2016 From: ineiev at gnu.org (Ineiev) Date: Tue, 20 Sep 2016 12:05:46 -0400 Subject: [HEAD] typos in doc/ In-Reply-To: <061d34cb-d9d2-24bc-343a-57b7e71dfc82@fsij.org> References: <20160310181200.GA25817@gnu.org> <20160409054645.GA4688@gnu.org> <20160508090546.GA15840@gnu.org> <20160620170501.GC23709@gnu.org> <87twgnpvy4.wl-neal@walfield.org> <87k2hiw5yr.fsf@wheatstone.g10code.de> <20160918051837.GF30569@gnu.org> <967d48b9-9474-ddf6-5901-9167f5427f09@fsij.org> <20160920071516.GK30569@gnu.org> <061d34cb-d9d2-24bc-343a-57b7e71dfc82@fsij.org> Message-ID: <20160920160546.GN30569@gnu.org> On Tue, Sep 20, 2016 at 04:43:59PM +0900, NIIBE Yutaka wrote: > > Then, I reviewed and applied following patches: > > 0002-Do-not-end-section-names-with.patch > 0010-Fix-full-stops.patch > > Justus and I made fixes for yat2m and gpgsm.texi. > > I decided not to apply following patches: > > 0003-End-menu-comments-with.patch > 0004-Replace-table-asis-with-itemize-bullet.patch > > Also, Werner pushed this change: > > > https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=81cb71ab4d516a1e8b09a69508f7887f98508642 Thanks a million to all! > In this context, "abbreviation" specifically refers to GnuPG's > handling of partial string match, which is not applicable to "--help", > "--version" or "--dump-options". (While short options are available.) > Other options can be "abbreviated", for example, --list-secret-keys > can be --list-sec. I believe this is not documented; if this is the case, it would be great if it were. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From wk at gnupg.org Tue Sep 20 21:04:20 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Sep 2016 21:04:20 +0200 Subject: [PATCH GnuPG] agent: Enable restricted, browser, and ssh socket by default. In-Reply-To: <87bmzjxt43.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 19 Sep 2016 21:22:36 -0400") References: <20160915125804.7568-1-justus@g10code.com> <878tutdw85.fsf@wheatstone.g10code.de> <87d1k52mcc.fsf@alice.fifthhorseman.net> <87a8f8cr5p.fsf@wheatstone.g10code.de> <20160919113241.GA5510@x2.esmtp.org> <87bmzjxt43.fsf@alice.fifthhorseman.net> Message-ID: <87fuouv1e3.fsf@wheatstone.g10code.de> On Tue, 20 Sep 2016 03:22, dkg at fifthhorseman.net said: > offering the restricted socket in addition to the normal socket doesn't > seem to increase the attack surface. It does because its intended use is for remote boxes. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From wk at gnupg.org Tue Sep 20 21:02:33 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Sep 2016 21:02:33 +0200 Subject: [PATCH GnuPG] agent: Enable restricted, browser, and ssh socket by default. In-Reply-To: <87bmzizmam.fsf@europa.jade-hamburg.de> (Justus Winter's message of "Tue, 20 Sep 2016 16:19:13 +0200") References: <20160915125804.7568-1-justus@g10code.com> <878tutdw85.fsf@wheatstone.g10code.de> <87d1k52mcc.fsf@alice.fifthhorseman.net> <87a8f8cr5p.fsf@wheatstone.g10code.de> <8737kwtck1.fsf@europa.jade-hamburg.de> <87ponz27cj.fsf@wheatstone.g10code.de> <87eg4fyopy.fsf@europa.jade-hamburg.de> <87r38evqze.fsf@wheatstone.g10code.de> <87bmzizmam.fsf@europa.jade-hamburg.de> Message-ID: <87k2e6v1h2.fsf@wheatstone.g10code.de> On Tue, 20 Sep 2016 16:19, justus at g10code.com said: > Are you somehow saying that GnuPG can only be used by one application? > What is a (the? my? your?) main GnuPG application? No, I don't day this. Existing applications behave this way - they all have there preference and some try to auto-configure them. This is why we developed gpgconf - a way to unify changes. This is similar to other parts of the desktop: For example there are several ways to configure the keyboard, the properties of the screen, or the network. > The "extra" socket allows merely a subset of the operation that the > "normal" socket allows, hence the allowed operations are restricted to I view it the other way: The standard socket allows operations which are not necessary for every days use. The --extra-socket allows the commonly required operations. "restricted" is the wrong term. I would love to use "remote" but that would be a silly name for a local socket. After all, I only want to have a shorter name than what you proposed. > that subset. How is "additional" a better name then "restricted"? It Because that word as weel as 'extra" has a positive connotation - meaning it is an actual useful thing. Who wants to use something restricted ;-) Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From neal at walfield.org Tue Sep 20 21:25:00 2016 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 20 Sep 2016 21:25:00 +0200 Subject: [PATCH GnuPG] sockets In-Reply-To: <87k2e6v1h2.fsf@wheatstone.g10code.de> References: <20160915125804.7568-1-justus@g10code.com> <878tutdw85.fsf@wheatstone.g10code.de> <87d1k52mcc.fsf@alice.fifthhorseman.net> <87a8f8cr5p.fsf@wheatstone.g10code.de> <8737kwtck1.fsf@europa.jade-hamburg.de> <87ponz27cj.fsf@wheatstone.g10code.de> <87eg4fyopy.fsf@europa.jade-hamburg.de> <87r38evqze.fsf@wheatstone.g10code.de> <87bmzizmam.fsf@europa.jade-hamburg.de> <87k2e6v1h2.fsf@wheatstone.g10code.de> Message-ID: <87oa3il6gj.wl-neal@walfield.org> On Tue, 20 Sep 2016 21:02:33 +0200, Werner Koch wrote: > On Tue, 20 Sep 2016 16:19, justus at g10code.com said: > > The "extra" socket allows merely a subset of the operation that the > > "normal" socket allows, hence the allowed operations are restricted to > > I view it the other way: The standard socket allows operations which are > not necessary for every days use. The --extra-socket allows the > commonly required operations. "restricted" is the wrong term. I would > love to use "remote" but that would be a silly name for a local socket. > > After all, I only want to have a shorter name than what you proposed. > > > that subset. How is "additional" a better name then "restricted"? It > > Because that word as weel as 'extra" has a positive connotation - > meaning it is an actual useful thing. Who wants to use something > restricted ;-) I strongly disagree with this. I want my applications to be restricted. My solitaire program shouldn't be able to access any of my files by default or the network. I propose that we view this as an object capability system in which GnuPG is an object and the different sockets are capabilities with different authority. The main socket provides full authority. Other sockets are attenuations thereof. Correspondingly, we could do something like this: # Full authority socket S.gpg-agent # Exclude the signing authority. socket -sign S.gpg-agent-nosign etc. This has the nice advantage that it is in theory possible to have multiple sockets with similar authority. Thus, we could even add some session state so that an application, such as parcimonie, could, say, force the user of a particular key server and that change would only apply to that session. Thoughts? :) Neal From dkg at fifthhorseman.net Tue Sep 20 21:54:45 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 20 Sep 2016 15:54:45 -0400 Subject: [PATCH GnuPG] agent: Enable restricted, browser, and ssh socket by default. In-Reply-To: <87fuouv1e3.fsf@wheatstone.g10code.de> References: <20160915125804.7568-1-justus@g10code.com> <878tutdw85.fsf@wheatstone.g10code.de> <87d1k52mcc.fsf@alice.fifthhorseman.net> <87a8f8cr5p.fsf@wheatstone.g10code.de> <20160919113241.GA5510@x2.esmtp.org> <87bmzjxt43.fsf@alice.fifthhorseman.net> <87fuouv1e3.fsf@wheatstone.g10code.de> Message-ID: <87lgymuz22.fsf@alice.fifthhorseman.net> On Tue 2016-09-20 15:04:20 -0400, Werner Koch wrote: > On Tue, 20 Sep 2016 03:22, dkg at fifthhorseman.net said: > >> offering the restricted socket in addition to the normal socket doesn't >> seem to increase the attack surface. > > It does because its intended use is for remote boxes. surely it's the forwarding of this socket to remote boxes that increases the attack surface, and not creating it locally, though? you asked: > Who wants to use something restricted ;) And i'd say "i do!" I'd much rather have the overwhelming majority of my local desktop session be restricted in what it can do to manipulate my secret keys. I'll be working at some point (and would love help on!) on a restricted profile for the gpg-agent, to make it easier for people to completely isolate their secret keys, e.g. behind a separate user account. This kind of restriction is a good practice and we should be encouraging it. With this system integration work, i'll certainly dynamically configure gpg-agent to make sure it's only exposing the "extra" socket. I'd hope that such a configuration would be considered a supported configuration. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From gniibe at fsij.org Wed Sep 21 02:22:20 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 21 Sep 2016 09:22:20 +0900 Subject: [HEAD] typos in doc/ In-Reply-To: <20160920160546.GN30569@gnu.org> References: <20160310181200.GA25817@gnu.org> <20160409054645.GA4688@gnu.org> <20160508090546.GA15840@gnu.org> <20160620170501.GC23709@gnu.org> <87twgnpvy4.wl-neal@walfield.org> <87k2hiw5yr.fsf@wheatstone.g10code.de> <20160918051837.GF30569@gnu.org> <967d48b9-9474-ddf6-5901-9167f5427f09@fsij.org> <20160920071516.GK30569@gnu.org> <061d34cb-d9d2-24bc-343a-57b7e71dfc82@fsij.org> <20160920160546.GN30569@gnu.org> Message-ID: On 09/21/2016 01:05 AM, Ineiev wrote: >> In this context, "abbreviation" specifically refers to GnuPG's >> handling of partial string match, which is not applicable to "--help", >> "--version" or "--dump-options". (While short options are available.) >> Other options can be "abbreviated", for example, --list-secret-keys >> can be --list-sec. > > I believe this is not documented; if this is the case, it would be > great if it were. I agree. I think that it is not documented in GnuPG manual itself, perhaps because of historical reason. Please note that it's a common feature of GNU packages. When long option (such that --long-options, with double dashes) was introduced by GNU, it came with the feature of allowing partial string. Although GnuPG's option handling is a bit different than general GNU packages (the order matters), allowing partial string is same. -- From wk at gnupg.org Wed Sep 21 10:23:44 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 21 Sep 2016 10:23:44 +0200 Subject: [Announce] GnuPG Made Easy (GPGME) 1.7.0 released Message-ID: <87shstu0dr.fsf@wheatstone.g10code.de> Hello! We are pleased to announce version 1.7.0 of GPGME. GnuPG Made Easy (GPGME) is a C language library that allows to add support for cryptography to a program. It is designed to make access to public key crypto engines as included in GnuPG easier for applications. GPGME provides a high-level crypto API for encryption, decryption, signing, signature verification, and key management. Noteworthy changes in version 1.7.0 =================================== * New language bindings for Python 2 and 3. See * New language bindings for C++ and the Qt-Framework API. * New functions gpgme_op_createkey and gpgme_op_createsubkey to make key creation easier (requires GnuPG 2.1). * New functions gpgme_op_adduid and gpgme_op_revuid to make user id management easier (requires GnuPG 2.1). * New function gpgme_op_keysign to make key signing easier (requires GnuPG 2.1). * New function gpgme_op_interact to replace the now deprecated functions gpgme_op_edit and gpgme_op_card_edit. * New function gpgme_pubkey_algo_string to convert a public key algorithm into a GnuPG 2.1 style string. * Support for GnuPG 2.1's TOFU trust model. * Notation flags are now correctly set on verify. * New global flag "require-gnupg" to set a minimal gnupg version. * More supported items in gpgme_get_dirinfo. * New function gpgme_data_set_flag and flag "size-hint". * New function gpgme_set_ctx_flag and flags "full-status" and "raw-description". * Improved gpgme_data_identify to distinguish more file types. * New flag GPGME_ENCRYPT_SYMMETRIC for gpgme_op_encrypt to allow mixed public key and symmetric encryption. * New field KEYGRIP in gpgme_subkey_t. New fields FPR in gpgme_key_t. * New flag GPGME_DATA_ENCODING_MIME to declare that the encrypted or signed data is a valid MIME part. This is to support future GnuPG versions. Download ======== You may download this library and its OpenPGP signature from: ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.7.0.tar.bz2 (1252k) ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.7.0.tar.bz2.sig or https://gnupg.org/ftp/gcrypt/gpgme/gpgme-1.7.0.tar.bz2 (1252k) https://gnupg.org/ftp/gcrypt/gpgme/gpgme-1.7.0.tar.bz2.sig The SHA-1 checksum is 41030f0f317100af6e9a1a05a4b0218aee684d8a gpgme-1.7.0.tar.bz2 but you better check the integrity using the provided signature. See https://gnupg.org/download/integrity_check.html for details. Support ======= Please consult the archive of the gnupg-devel 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 . 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 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. Special thanks to Justus Winter and Andre Heinecke for integrating the Python and C++/Qt language bindings. For the GnuPG team, Werner p.s. This is an announcement only mailing list. Please send replies only to the gnupg-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: 2016-10-28] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31] Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 Werner Koch (Release Signing Key) You may retrieve these keys from a keyserver using this command gpg --keyserver hkp://keys.gnupg.net --recv-keys \ 249B39D24F25E3B6 04376F3EE0856959 \ 2071B08A33BD3F06 8A861B1C7EFD60D9 The keys are also available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From astieger at suse.com Wed Sep 21 14:40:14 2016 From: astieger at suse.com (Andreas Stieger) Date: Wed, 21 Sep 2016 14:40:14 +0200 Subject: gpgme C++ missing returns in non-void functions Message-ID: <3b100483-db7b-dc94-3b77-7142cd715d59@suse.com> Hello, I would like to flag up four issues that are in the new C++ code in gpgme 1.7.0: lang/cpp/src/context.cpp :: Context::signaturePolicyURL() https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=blob;f=lang/cpp/src/context.cpp;h=00f397b477665292f65786289bdc89bd85db4bc9;hb=e7ab75379feadcc2894d9d4cde0f16ad0044780d#l1047 There is a control path where there is no return in a non-void function. lang/cpp/src/context.cpp :: to_tofu_policy_t() https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=blob;f=lang/cpp/src/context.cpp;h=00f397b477665292f65786289bdc89bd85db4bc9;hb=e7ab75379feadcc2894d9d4cde0f16ad0044780d#l1333 Same, missing default case or catchall return. lang/cpp/src/key.cpp :: Key::primaryFingerprint() https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=blob;f=lang/cpp/src/key.cpp;h=cfa1ba3156b3f8a749f99c7a899a9f40c16772d2;hb=e7ab75379feadcc2894d9d4cde0f16ad0044780d#l263 There is a control path where there is no return in a non-void function. lang/cpp/src/tofuinfo.cpp :: GpgME::TofuInfo::policy() https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=blob;f=lang/cpp/src/tofuinfo.cpp;h=bb67fc8cd6b2a5c72bc8ff4da16fdb6cd0f57660;hb=e7ab75379feadcc2894d9d4cde0f16ad0044780d#l95 Same, missing default case or catchall return. Patch attached, or pull from below. The following changes since commit e7ab75379feadcc2894d9d4cde0f16ad0044780d: Release 1.7.0 (2016-09-21 09:18:01 +0200) are available in the git repository at: https://github.com/andreasstieger/gpgme.git for you to fetch changes up to 643dbabc0df78e6e1bf0a04d1e2dd666f5f308a2: cpp : Avoid missing returns in non-void functions (2016-09-21 14:28:23 +0200) ---------------------------------------------------------------- Andreas Stieger (1): cpp : Avoid missing returns in non-void functions lang/cpp/src/context.cpp | 2 ++ lang/cpp/src/key.cpp | 1 + lang/cpp/src/tofuinfo.cpp | 1 + 3 files changed, 4 insertions(+) Andreas -- Andreas Stieger Project Manager Security SUSE Linux GmbH, GF: Felix Imend?rffer, Jane Smithard, Graham Norton, HRB 21284 (AG N?rnberg) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-cpp-Avoid-missing-returns-in-non-void-functions.patch Type: text/x-patch Size: 2136 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From thomas at glanzmann.de Wed Sep 21 13:45:16 2016 From: thomas at glanzmann.de (Thomas Glanzmann) Date: Wed, 21 Sep 2016 13:45:16 +0200 Subject: [Announce] GnuPG Made Easy (GPGME) 1.7.0 released In-Reply-To: <87shstu0dr.fsf@wheatstone.g10code.de> References: <87shstu0dr.fsf@wheatstone.g10code.de> Message-ID: <20160921114516.GA7214@glanzmann.de> Hello Werner, * Werner Koch [2016-09-21 11:24]: > * Support for GnuPG 2.1's TOFU trust model. I'm using mutt and would like to use TOFU for gpg and gpgsm by using gpgme. I compiled the gpgme version, but I do not see a change. I assume, that once I receive a signed email which I do not trust yet, I get asked if I trust this public key. Is this done using the command line or is there some code which needs to be written for mutt in order to use the functionality? Cheers, Thomas From ineiev at gnu.org Wed Sep 21 15:53:22 2016 From: ineiev at gnu.org (Ineiev) Date: Wed, 21 Sep 2016 09:53:22 -0400 Subject: [HEAD] typos in doc/ In-Reply-To: References: <20160508090546.GA15840@gnu.org> <20160620170501.GC23709@gnu.org> <87twgnpvy4.wl-neal@walfield.org> <87k2hiw5yr.fsf@wheatstone.g10code.de> <20160918051837.GF30569@gnu.org> <967d48b9-9474-ddf6-5901-9167f5427f09@fsij.org> <20160920071516.GK30569@gnu.org> <061d34cb-d9d2-24bc-343a-57b7e71dfc82@fsij.org> <20160920160546.GN30569@gnu.org> Message-ID: <20160921135322.GS30569@gnu.org> On Wed, Sep 21, 2016 at 09:22:20AM +0900, NIIBE Yutaka wrote: > On 09/21/2016 01:05 AM, Ineiev wrote: > > > > I believe this is not documented; if this is the case, it would be > > great if it were. > > I agree. I think that it is not documented in GnuPG manual itself, > perhaps because of historical reason. > > Please note that it's a common feature of GNU packages. When long > option (such that --long-options, with double dashes) was introduced > by GNU, it came with the feature of allowing partial string. > > Although GnuPG's option handling is a bit different than general GNU > packages (the order matters), allowing partial string is same. Indeed; many other GNU packages don't even mention the feature at all (neither do GNU Coding Standards); it's described in getopt documentation (but not in the GNU C Library Reference Manual). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From aheinecke at intevation.de Wed Sep 21 16:47:15 2016 From: aheinecke at intevation.de (Andre Heinecke) Date: Wed, 21 Sep 2016 16:47:15 +0200 Subject: gpgme C++ missing returns in non-void functions In-Reply-To: <3b100483-db7b-dc94-3b77-7142cd715d59@suse.com> References: <3b100483-db7b-dc94-3b77-7142cd715d59@suse.com> Message-ID: <2539098.eRatkYdgnO@esus> Hi, On Wednesday 21 September 2016 14:40:14 Andreas Stieger wrote: > I would like to flag up four issues that are in the new C++ code in > gpgme 1.7.0. Thanks! I noticed that -Wall is not enabled for C++ code. I'll fix some more warnings triggered by adding -Wall and then enable this so that in the Future we won't miss such problems. I've applied your patch. Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Wed Sep 21 17:35:31 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 21 Sep 2016 17:35:31 +0200 Subject: [Announce] GnuPG Made Easy (GPGME) 1.7.0 released In-Reply-To: <20160921114516.GA7214@glanzmann.de> (Thomas Glanzmann's message of "Wed, 21 Sep 2016 13:45:16 +0200") References: <87shstu0dr.fsf@wheatstone.g10code.de> <20160921114516.GA7214@glanzmann.de> Message-ID: <87ponxs1to.fsf@wheatstone.g10code.de> On Wed, 21 Sep 2016 13:45, thomas at glanzmann.de said: > I'm using mutt and would like to use TOFU for gpg and gpgsm by using > gpgme. I compiled the gpgme version, but I do not see a change. I Sure you don't see it. You need to change Mutt to make use of it. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From thomas at glanzmann.de Wed Sep 21 18:29:59 2016 From: thomas at glanzmann.de (Thomas Glanzmann) Date: Wed, 21 Sep 2016 18:29:59 +0200 Subject: GPGME TOFU support for mutt In-Reply-To: <87ponxs1to.fsf@wheatstone.g10code.de> References: <87shstu0dr.fsf@wheatstone.g10code.de> <20160921114516.GA7214@glanzmann.de> <87ponxs1to.fsf@wheatstone.g10code.de> Message-ID: <20160921162959.GA14985@glanzmann.de> Hello Werner, > You need to change Mutt to make use of it. do you know if someone is working on it? If not, can you give some hints that I could make a patch for mutt ready: - What needs to be changed? - Which functions need to be called? - Is there document that describes what neeeds to be done? - Was the change already done to another MUA? Cheers, Thomas From dkg at fifthhorseman.net Wed Sep 21 19:40:13 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 21 Sep 2016 13:40:13 -0400 Subject: [Announce] GnuPG Made Easy (GPGME) 1.7.0 released In-Reply-To: <87shstu0dr.fsf@wheatstone.g10code.de> References: <87shstu0dr.fsf@wheatstone.g10code.de> Message-ID: <87twd99mo2.fsf@alice.fifthhorseman.net> On Wed 2016-09-21 04:23:44 -0400, Werner Koch wrote: > Hello! > > We are pleased to announce version 1.7.0 of GPGME. Thanks to the whole GnuPG team for this release! I don't see a git tag for this release in the upstream repo, though. I suspect it was meant for commit id e7ab75379feadcc2894d9d4cde0f16ad0044780d but it would be good to include a signed tag. maybe it just hasn't been pushed? Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From neal at walfield.org Wed Sep 21 20:13:58 2016 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 21 Sep 2016 20:13:58 +0200 Subject: [Announce] GnuPG Made Easy (GPGME) 1.7.0 released In-Reply-To: <20160921114516.GA7214@glanzmann.de> References: <87shstu0dr.fsf@wheatstone.g10code.de> <20160921114516.GA7214@glanzmann.de> Message-ID: <87fuotktnd.wl-neal@walfield.org> Hi, On Wed, 21 Sep 2016 13:45:16 +0200, Thomas Glanzmann wrote: > Hello Werner, > > * Werner Koch [2016-09-21 11:24]: > > * Support for GnuPG 2.1's TOFU trust model. > > I'm using mutt and would like to use TOFU for gpg and gpgsm by using > gpgme. I compiled the gpgme version, but I do not see a change. I > assume, that once I receive a signed email which I do not trust yet, I > get asked if I trust this public key. Is this done using the command > line or is there some code which needs to be written for mutt in order > to use the functionality? For full TOFU support under mutt, mutt will need to be modified (or, rather, the gpg plugin for mutt). But, simply having the newest version of gpg is not enough for TOFU support. You need need to explicitly enable it. Start here [1] for an introduction (also folloow the links). And, check the manual for more details. :) Neal [1] https://www.gnupg.org/blog/20151103-gnupg-in-october.html#sec-1-5 From wk at gnupg.org Wed Sep 21 20:23:07 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 21 Sep 2016 20:23:07 +0200 Subject: GPGME TOFU support for mutt In-Reply-To: <20160921162959.GA14985@glanzmann.de> (Thomas Glanzmann's message of "Wed, 21 Sep 2016 18:29:59 +0200") References: <87shstu0dr.fsf@wheatstone.g10code.de> <20160921114516.GA7214@glanzmann.de> <87ponxs1to.fsf@wheatstone.g10code.de> <20160921162959.GA14985@glanzmann.de> Message-ID: <877fa5ru2c.fsf@wheatstone.g10code.de> On Wed, 21 Sep 2016 18:29, thomas at glanzmann.de said: > - What needs to be changed? Andre is currently integrating TOFU into Kmail. That would give a good example on how to do it and we can also see whether that design is working for a GUI. > - Is there document that describes what neeeds to be done? We will eventually write such a document. I would also like to submit patches to Mutt but I am afraid of their use of Hg .-) Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From dkg at fifthhorseman.net Wed Sep 21 20:59:32 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 21 Sep 2016 14:59:32 -0400 Subject: [Announce] GnuPG Made Easy (GPGME) 1.7.0 released In-Reply-To: <87shstu0dr.fsf@wheatstone.g10code.de> References: <87shstu0dr.fsf@wheatstone.g10code.de> Message-ID: <87r38d9izv.fsf@alice.fifthhorseman.net> On Wed 2016-09-21 04:23:44 -0400, Werner Koch wrote: > https://gnupg.org/ftp/gcrypt/gpgme/gpgme-1.7.0.tar.bz2 (1252k) > https://gnupg.org/ftp/gcrypt/gpgme/gpgme-1.7.0.tar.bz2.sig Thanks for this! I'm a curious about the inclusion of .pyc (byte-compiled python) in the upstream tarball: 0 dkg at alice:~$ tar tj < gpgme-1.7.0.tar.bz2 | grep pyc gpgme-1.7.0/lang/python/pyme/__pycache__/ gpgme-1.7.0/lang/python/pyme/__pycache__/version.cpython-34.pyc gpgme-1.7.0/lang/python/pyme/__pycache__/__init__.cpython-34.pyc 0 dkg at alice:~$ Is this intentional, or an oversight? If it's intentional, what do you expect distributors to do with these files? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From thomas at glanzmann.de Wed Sep 21 23:27:43 2016 From: thomas at glanzmann.de (Thomas Glanzmann) Date: Wed, 21 Sep 2016 23:27:43 +0200 Subject: GPGME TOFU support for mutt In-Reply-To: <877fa5ru2c.fsf@wheatstone.g10code.de> References: <87shstu0dr.fsf@wheatstone.g10code.de> <20160921114516.GA7214@glanzmann.de> <87ponxs1to.fsf@wheatstone.g10code.de> <20160921162959.GA14985@glanzmann.de> <877fa5ru2c.fsf@wheatstone.g10code.de> Message-ID: <20160921212743.GB17114@glanzmann.de> Hello Werner, > I would also like to submit patches to Mutt but I am afraid of their > use of Hg .-) so am I. I did all my development for mutt with bitkeeper and later as soon as it was available with git. If someone starts working on it, please let me know. I'll probably have a look at it if noone else is doing it. Cheers, Thomas From justus at g10code.com Thu Sep 22 10:55:38 2016 From: justus at g10code.com (Justus Winter) Date: Thu, 22 Sep 2016 10:55:38 +0200 Subject: [Announce] GnuPG Made Easy (GPGME) 1.7.0 released In-Reply-To: <87r38d9izv.fsf@alice.fifthhorseman.net> References: <87shstu0dr.fsf@wheatstone.g10code.de> <87r38d9izv.fsf@alice.fifthhorseman.net> Message-ID: <87twd8gvp1.fsf@europa.jade-hamburg.de> Daniel Kahn Gillmor writes: > I'm a curious about the inclusion of .pyc (byte-compiled python) in the > upstream tarball: > > 0 dkg at alice:~$ tar tj < gpgme-1.7.0.tar.bz2 | grep pyc > gpgme-1.7.0/lang/python/pyme/__pycache__/ > gpgme-1.7.0/lang/python/pyme/__pycache__/version.cpython-34.pyc > gpgme-1.7.0/lang/python/pyme/__pycache__/__init__.cpython-34.pyc > 0 dkg at alice:~$ > > Is this intentional, or an oversight? If it's intentional, what do you > expect distributors to do with these files? That is not intentional, and strange, usually make distcheck is quite strict, isn't it? Also, I just tried, and I cannot reproduce this. Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From astieger at suse.com Thu Sep 22 16:27:45 2016 From: astieger at suse.com (Andreas Stieger) Date: Thu, 22 Sep 2016 16:27:45 +0200 Subject: gpgme: cpp: failing on 32 bit due to LFS requirements Message-ID: Hello, the C++ bindings are failing when building on 32 bits due to the lack of definition of the required LFS macros. As you were looking at the cpp compiler flags anyway, I thought I'd let you know: [ 95s] In file included from util.h:30:0, [ 95s] from key.cpp:25: [ 95s] ../../../src/gpgme.h:104:2: error: #error GPGME was compiled with _FILE_OFFSET_BITS = 64, please see the section "Largefile support (LFS)" in the GPGME manual. [ 95s] #error GPGME was compiled with _FILE_OFFSET_BITS = 64, please see the section "Largefile support (LFS)" in the GPGME manual. [ 95s] ^~~~~ Andreas -- Andreas Stieger Project Manager Security SUSE Linux GmbH, GF: Felix Imend?rffer, Jane Smithard, Graham Norton, HRB 21284 (AG N?rnberg) From dkg at fifthhorseman.net Thu Sep 22 18:38:49 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 22 Sep 2016 12:38:49 -0400 Subject: GPGME TOFU support for mutt In-Reply-To: <877fa5ru2c.fsf@wheatstone.g10code.de> References: <87shstu0dr.fsf@wheatstone.g10code.de> <20160921114516.GA7214@glanzmann.de> <87ponxs1to.fsf@wheatstone.g10code.de> <20160921162959.GA14985@glanzmann.de> <877fa5ru2c.fsf@wheatstone.g10code.de> Message-ID: <87zimz99eu.fsf@alice.fifthhorseman.net> On Wed 2016-09-21 14:23:07 -0400, Werner Koch wrote: > I would also like to submit patches to Mutt but I am afraid of their use > of Hg .-) I don't really work on mutt, but i've had passable success in other projects with the git-remote-hg package, which allows you to do: git clone hg:: and then just work from the client side with git. hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From dkg at fifthhorseman.net Fri Sep 23 01:06:20 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 22 Sep 2016 19:06:20 -0400 Subject: [GPGME PATCH 1/3] tests/gpgsm: remove unused text var Message-ID: <20160922230622.16521-1-dkg@fifthhorseman.net> * tests/gpgsm/t-decrypt.c: remove unused const char test_text1[], which is not actually used. It appears that this test intends to print the decrypted text rather than compare it with the correct text. If it should be compared, then the test should be modified appropriately instead. Signed-off-by: Daniel Kahn Gillmor --- tests/gpgsm/t-decrypt.c | 1 - 1 file changed, 1 deletion(-) diff --git a/tests/gpgsm/t-decrypt.c b/tests/gpgsm/t-decrypt.c index 658809c..1149160 100644 --- a/tests/gpgsm/t-decrypt.c +++ b/tests/gpgsm/t-decrypt.c @@ -34,7 +34,6 @@ #include "t-support.h" -static const char test_text1[] = "Hallo Leute!\n"; static const char test_cip1[] = "-----BEGIN CMS OBJECT-----\n" "MIAGCSqGSIb3DQEHA6CAMIACAQAxggEJMIIBBQIBADBwMGsxCzAJBgNVBAYTAkRF\n" -- 2.9.3 From dkg at fifthhorseman.net Fri Sep 23 01:06:22 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 22 Sep 2016 19:06:22 -0400 Subject: [GPGME PATCH 3/3] Fix spelling In-Reply-To: <20160922230622.16521-1-dkg@fifthhorseman.net> References: <20160922230622.16521-1-dkg@fifthhorseman.net> Message-ID: <20160922230622.16521-3-dkg@fifthhorseman.net> * lang/cpp/src/context.h, lang/qt/src/protocol.h, lang/qt/src/wkspublishjob.h, src/data-identify.c, src/engine-gpg.c: minor spelling cleanup. Signed-off-by: Daniel Kahn Gillmor --- lang/cpp/src/context.h | 4 ++-- lang/qt/src/protocol.h | 6 +++--- lang/qt/src/wkspublishjob.h | 2 +- src/data-identify.c | 2 +- src/engine-gpg.c | 2 +- 5 files changed, 8 insertions(+), 8 deletions(-) diff --git a/lang/cpp/src/context.h b/lang/cpp/src/context.h index b1e4f5f..ab15a21 100644 --- a/lang/cpp/src/context.h +++ b/lang/cpp/src/context.h @@ -364,8 +364,8 @@ public: * @param file The executable to start. * @param argv list of arguments file should be argv[0]. * @param input The data to be sent through stdin. - * @param output The data to be recieve the stdout. - * @param err The data to recieve stderr. + * @param output The data to be receive the stdout. + * @param err The data to receive stderr. * @param flags Additional flags. * * @returns An error or empty error. diff --git a/lang/qt/src/protocol.h b/lang/qt/src/protocol.h index 40ddcb5..15d83e0 100644 --- a/lang/qt/src/protocol.h +++ b/lang/qt/src/protocol.h @@ -76,7 +76,7 @@ class TofuPolicyJob; * two are always a QString for the auditlog and an GpgME::Error for * an eventual error. * - * In case async API is used and the result signal is emited a + * In case async API is used and the result signal is emitted a * job schedules its own deletion. * * Most jobs also provide a synchronous call exec in which case @@ -161,14 +161,14 @@ public: /** Obtain a reference to the OpenPGP Protocol. * * The reference is to a static object. - * @returns Refrence to the OpenPGP Protocol. + * @returns Reference to the OpenPGP Protocol. */ QGPGME_EXPORT Protocol *openpgp(); /** Obtain a reference to the smime Protocol. * * The reference is to a static object. - * @returns Refrence to the smime Protocol. + * @returns Reference to the smime Protocol. */ QGPGME_EXPORT Protocol *smime(); diff --git a/lang/qt/src/wkspublishjob.h b/lang/qt/src/wkspublishjob.h index 782112f..d7bcd5d 100644 --- a/lang/qt/src/wkspublishjob.h +++ b/lang/qt/src/wkspublishjob.h @@ -45,7 +45,7 @@ namespace QGpgME { * Handles Web Key Service Publishing. Needs WKS tools installed and * server support. * - * Remember that after a result is emited the job is auto deleted + * Remember that after a result is emitted the job is auto deleted * so you can only use it for a single action. */ class QGPGME_EXPORT WKSPublishJob: public Job diff --git a/src/data-identify.c b/src/data-identify.c index a5da7f5..615a4f3 100644 --- a/src/data-identify.c +++ b/src/data-identify.c @@ -278,7 +278,7 @@ pgp_binary_detection (const void *image_arg, size_t imagelen) /* This is probably an armored "PGP MESSAGE" which can encode * different PGP data types. STRING is modified after a call to this - * fucntion. */ + * function. */ static gpgme_data_type_t inspect_pgp_message (char *string) { diff --git a/src/engine-gpg.c b/src/engine-gpg.c index 3f1d34d..4415c94 100644 --- a/src/engine-gpg.c +++ b/src/engine-gpg.c @@ -2543,7 +2543,7 @@ gpg_keylist_build_options (engine_gpg_t gpg, int secret_only, err = add_arg (gpg, "--with-colons"); /* Since gpg 2.1.15 fingerprints are always printed, thus there is - * no more need to explictly request them. */ + * no more need to explicitly request them. */ if (!have_gpg_version (gpg, "2.1.15")) { if (!err) -- 2.9.3 From dkg at fifthhorseman.net Fri Sep 23 01:06:21 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 22 Sep 2016 19:06:21 -0400 Subject: [GPGME PATCH 2/3] move some file encodings to UTF-8 In-Reply-To: <20160922230622.16521-1-dkg@fifthhorseman.net> References: <20160922230622.16521-1-dkg@fifthhorseman.net> Message-ID: <20160922230622.16521-2-dkg@fifthhorseman.net> * THANKS, doc/ChangeLog-2011, tests/ChangeLog-2011, tests/gpg/geheim.txt: convert from iso 8859-1 to utf-8 * lang/qt/src/dataprovider.cpp, lang/qt/src/qgpgmerefreshkeysjob.cpp, lang/qt/src/qgpgmesecretkeyexportjob.cpp: replace U+FFFD REPLACEMENT CHARACTER with proper U+00E4 LATIN SMALL LETTER A WITH DIAERESIS Note that src/versioninfo.rc.in is still ISO-8859-1. I don't know whether Windows will properly handle UTF-8 in this file or not, so i have not touched it. Signed-off-by: Daniel Kahn Gillmor --- THANKS | 6 +++--- doc/ChangeLog-2011 | 2 +- lang/qt/src/dataprovider.cpp | 2 +- lang/qt/src/qgpgmerefreshkeysjob.cpp | 2 +- lang/qt/src/qgpgmesecretkeyexportjob.cpp | 2 +- tests/ChangeLog-2011 | 8 ++++---- tests/gpg/geheim.txt | 2 +- 7 files changed, 12 insertions(+), 12 deletions(-) diff --git a/THANKS b/THANKS index 9d79004..e312775 100644 --- a/THANKS +++ b/THANKS @@ -5,7 +5,7 @@ want to thank them for their help. If we forgot you, please let us know. Adriaan de Groot adridg at cs.kun.nl -Albrecht Dre? albrecht.dress at arcor.de +Albrecht Dre?? albrecht.dress at arcor.de Alfons Hoogervorst alfons at proteus.demon.nl Daniel Mueller daniel at danm.de Enno Cramer uebergeek at web.de @@ -13,13 +13,13 @@ Frank Heckenbach frank at g-n-u.de Igor Belyi gpgme at katehok.ac93.org Jan-Oliver Wagner jan at intevation.de Johannes Poehlmann jhp at caldera.de -Jose C. Garc?a Sogo jose at jaimedelamo.eu.org +Jose C. Garc??a Sogo jose at jaimedelamo.eu.org Leo Gaspard ekleog at gmail.com Mark Mutz mutz at kde.org Miguel Coca mcoca at gnu.org Noel Torres envite at rolamasao.org Patrick Spendrin patrick.spendrin at kdab.com -St?phane Corth?sy stephane at sente.ch +St??phane Corth??sy stephane at sente.ch Timo Schulz twoaday at freakmail.de Tommy Reynolds reynolds at redhat.com W. Trevor King wking at tremily.us diff --git a/doc/ChangeLog-2011 b/doc/ChangeLog-2011 index d6ecca7..e270fae 100644 --- a/doc/ChangeLog-2011 +++ b/doc/ChangeLog-2011 @@ -397,7 +397,7 @@ (Listing Keys): Update examples. (Decrypt): Result might also be available when operation failed. (Verify): Result might also be available when operation failed. - All spotted by St?phane Corth?sy. + All spotted by St??phane Corth??sy. 2003-07-22 Marcus Brinkmann diff --git a/lang/qt/src/dataprovider.cpp b/lang/qt/src/dataprovider.cpp index 533b67d..8a487a5 100644 --- a/lang/qt/src/dataprovider.cpp +++ b/lang/qt/src/dataprovider.cpp @@ -1,5 +1,5 @@ /* dataprovider.cpp - Copyright (C) 2004 Klar???vdalens Datakonsult AB + Copyright (C) 2004 Klar??vdalens Datakonsult AB Copyright (c) 2016 Intevation GmbH This file is part of QGPGME. diff --git a/lang/qt/src/qgpgmerefreshkeysjob.cpp b/lang/qt/src/qgpgmerefreshkeysjob.cpp index 3d221f6..0fe724b 100644 --- a/lang/qt/src/qgpgmerefreshkeysjob.cpp +++ b/lang/qt/src/qgpgmerefreshkeysjob.cpp @@ -2,7 +2,7 @@ qgpgmerefreshkeysjob.cpp This file is part of qgpgme, the Qt API binding for gpgme - Copyright (c) 2004 Klar???vdalens Datakonsult AB + Copyright (c) 2004 Klar??vdalens Datakonsult AB Copyright (c) 2016 Intevation GmbH QGpgME is free software; you can redistribute it and/or diff --git a/lang/qt/src/qgpgmesecretkeyexportjob.cpp b/lang/qt/src/qgpgmesecretkeyexportjob.cpp index f4ec698..ab7f1e6 100644 --- a/lang/qt/src/qgpgmesecretkeyexportjob.cpp +++ b/lang/qt/src/qgpgmesecretkeyexportjob.cpp @@ -2,7 +2,7 @@ qgpgmesecretexportjob.cpp This file is part of qgpgme, the Qt API binding for gpgme - Copyright (c) 2004 Klar???vdalens Datakonsult AB + Copyright (c) 2004 Klar??vdalens Datakonsult AB Copyright (c) 2016 Intevation GmbH QGpgME is free software; you can redistribute it and/or diff --git a/tests/ChangeLog-2011 b/tests/ChangeLog-2011 index 596c2df..3ec0fb7 100644 --- a/tests/ChangeLog-2011 +++ b/tests/ChangeLog-2011 @@ -603,7 +603,7 @@ 2002-09-28 Marcus Brinkmann - * t-version.c: Include . Reported by St?phane Corth?sy. + * t-version.c: Include . Reported by St??phane Corth??sy. 2002-09-02 Marcus Brinkmann @@ -624,8 +624,8 @@ * gpg/t-encrypt-sym.c (main): Change type of I to size_t and rename to LEN. - * gpg/t-verify.c (main): Likewise. Submitted by St?phane - Corth?sy. + * gpg/t-verify.c (main): Likewise. Submitted by St??phane + Corth??sy. 2002-07-03 Marcus Brinkmann @@ -772,7 +772,7 @@ 2001-12-19 Marcus Brinkmann * gpg/t-decrypt-verify.c: Don't include `mcheck.h'. Reported by - St?phane Corth?sy. + St??phane Corth??sy. 2001-12-19 Marcus Brinkmann diff --git a/tests/gpg/geheim.txt b/tests/gpg/geheim.txt index 99a5478..49d78a7 100644 --- a/tests/gpg/geheim.txt +++ b/tests/gpg/geheim.txt @@ -1,2 +1,2 @@ -Wenn Sie dies lesen k?nnen, ist es wohl nicht +Wenn Sie dies lesen k??nnen, ist es wohl nicht geheim genug. -- 2.9.3 From dkg at fifthhorseman.net Fri Sep 23 01:30:56 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 22 Sep 2016 19:30:56 -0400 Subject: [GPGME PATCH 2/3] move some file encodings to UTF-8 In-Reply-To: <20160922230622.16521-2-dkg@fifthhorseman.net> References: <20160922230622.16521-1-dkg@fifthhorseman.net> <20160922230622.16521-2-dkg@fifthhorseman.net> Message-ID: <87h9978qbz.fsf@alice.fifthhorseman.net> On Thu 2016-09-22 19:06:21 -0400, Daniel Kahn Gillmor wrote: > * THANKS, doc/ChangeLog-2011, tests/ChangeLog-2011, > tests/gpg/geheim.txt: convert from iso 8859-1 to utf-8 > * lang/qt/src/dataprovider.cpp, lang/qt/src/qgpgmerefreshkeysjob.cpp, > lang/qt/src/qgpgmesecretkeyexportjob.cpp: replace U+FFFD REPLACEMENT > CHARACTER with proper U+00E4 LATIN SMALL LETTER A WITH DIAERESIS > > Note that src/versioninfo.rc.in is still ISO-8859-1. I don't know > whether Windows will properly handle UTF-8 in this file or not, so i > have not touched it. hm, patches that change character encodings don't survive e-mail particularly well. This series is published as cleanup-2016-09-22 on https://anonscm.debian.org/git/pkg-gnupg/gpgme.git, which should currently have commit ID 277cb01f4e379b454c419ccd467e2007eae4038a. Feel free to pull it safely and sanely from there. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From aheinecke at intevation.de Fri Sep 23 10:03:29 2016 From: aheinecke at intevation.de (Andre Heinecke) Date: Fri, 23 Sep 2016 10:03:29 +0200 Subject: New theme for wiki.gnupg.org In-Reply-To: <1520319.Ool5WpojMh@esus> References: <1520319.Ool5WpojMh@esus> Message-ID: <2244423.6OMpgDt9Jm@esus> Hi, On Friday 16 September 2016 14:20:57 Andre Heinecke wrote: > What do you think, should we make this theme default? Any suggestions for > improvements? After some off list discussion and fiddling with the logo size a bit more we've decided to make it default. It's now active. You can of course switch to the old theme in your preferences. Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: This is a digitally signed message part. URL: From alon.barlev at gmail.com Fri Sep 23 11:29:48 2016 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Fri, 23 Sep 2016 12:29:48 +0300 Subject: [gpgme] 1.7 build experience and issues Message-ID: Hi, I am the Gentoo maintainer of gpgme. The 1.7 version is a great step forward,please see some notes regarding the build system, summary in single message, tell me if you wish individual bugs. Thanks, Alon --- FAILING TESTS t-sig-notation fails due to Unexpected notation data qt/t-encrypt opens a pinentry window, maybe due to: /* Loopback and passphrase provider don't work for mixed encryption. * So this test is disabled until gnupg(?) is fixed for this. */ QT DOC Can you please make the qtdoc enable/disable explicitly instead of autodetecting doxygen? Also, these docs are not installed, shouldn't they? PYTHON If not absolutely required to have this in the same package, maybe it would be better to split it into a separate one that is to be used post installation of pgpme using pure python tools. The autoconf ignores PYTHON override or any other attempt to use explicit environment. Please enable override to enable the packaging system to build the bindings to the supported python interpreters of the system. -------------- next part -------------- An HTML attachment was scrubbed... URL: From justus at g10code.com Fri Sep 23 15:21:59 2016 From: justus at g10code.com (Justus Winter) Date: Fri, 23 Sep 2016 15:21:59 +0200 Subject: [gpgme] 1.7 build experience and issues In-Reply-To: References: Message-ID: <8760pm3g5k.fsf@europa.jade-hamburg.de> Hi :) Alon Bar-Lev writes: > I am the Gentoo maintainer of gpgme. thanks for the feedback. > FAILING TESTS > > t-sig-notation fails due to Unexpected notation data What version of GnuPG are you using as backend? We fixed a bug in GnuPG recently to properly report a notation flag, and tightened the test case accordingly. To support older versions of GnuPG, the test tries to detect that an older version is used, but that test might fail for some reason. > PYTHON > > If not absolutely required to have this in the same package, maybe it would > be better to split it into a separate one that is to be used post > installation of pgpme using pure python tools. Surely gentoo can produce several binary packages from one source package? We are in fact using the python tools to build the bindings. The checks in configure merely try to detect which versions are available, and if everything is in place to produce python modules with SWIG. > The autoconf ignores PYTHON override or any other attempt to use explicit > environment. > Please enable override to enable the packaging system to build the bindings > to the supported python interpreters of the system. Gladly. Can you please be more specific how that would look like? Cheers, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From aheinecke at intevation.de Fri Sep 23 15:41:46 2016 From: aheinecke at intevation.de (Andre Heinecke) Date: Fri, 23 Sep 2016 15:41:46 +0200 Subject: [gpgme] 1.7 build experience and issues In-Reply-To: References: Message-ID: <3801968.rZS1F5c3J5@esus> Hi, Thanks for your feedback. On Friday 23 September 2016 12:29:48 Alon Bar-Lev wrote: > qt/t-encrypt opens a pinentry window, maybe due to: > /* Loopback and passphrase provider don't work for mixed encryption. > * So this test is disabled until gnupg(?) is fixed for this. */ I can reproduce this by using gnupg 2.0.26 instead of 2.1 or 1.4 I'll investigate. But its not related to the comment. The comment there is outdated I've since fixed that loopback and passphrase provider work with symmetric encryption it was a gpgme issue. That test should be reenabled. (As its currently not declared as a Slot it's disabled). The pinentry comes from the testSimpleEncryptDecrypt. > QT DOC > > Can you please make the qtdoc enable/disable explicitly instead of > autodetecting doxygen? > Also, these docs are not installed, shouldn't they? Mh, probably, disable by default, enable on option and then install them if the option is set. The docs are not so great and useful in my opinion that they should be installed / packaged by default. They should be improved of course ;-). Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: This is a digitally signed message part. URL: From aheinecke at intevation.de Fri Sep 23 16:12:07 2016 From: aheinecke at intevation.de (Andre Heinecke) Date: Fri, 23 Sep 2016 16:12:07 +0200 Subject: [GPGME PATCH 2/3] move some file encodings to UTF-8 In-Reply-To: <87h9978qbz.fsf@alice.fifthhorseman.net> References: <20160922230622.16521-1-dkg@fifthhorseman.net> <20160922230622.16521-2-dkg@fifthhorseman.net> <87h9978qbz.fsf@alice.fifthhorseman.net> Message-ID: <2046449.e9b8C8YaLF@esus> Hi, On Thursday 22 September 2016 19:30:56 Daniel Kahn Gillmor wrote: > On Thu 2016-09-22 19:06:21 -0400, Daniel Kahn Gillmor wrote: > This series is published as cleanup-2016-09-22 on > https://anonscm.debian.org/git/pkg-gnupg/gpgme.git, which should > currently have commit ID 277cb01f4e379b454c419ccd467e2007eae4038a. > > Feel free to pull it safely and sanely from there. Thanks for your patches. I've applied patch two and three. For the first one I rather used the variable in checking if the decrypted content matches the expected content instead of just printing it in the test. Made more sense to me. Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: This is a digitally signed message part. URL: From bshastry at sec.t-labs.tu-berlin.de Fri Sep 23 15:49:09 2016 From: bshastry at sec.t-labs.tu-berlin.de (Bhargava Shastry) Date: Fri, 23 Sep 2016 15:49:09 +0200 Subject: Making dig calls in GPG code Message-ID: <15173f4e-88b7-3f05-6c35-9231c262f055@sec.t-labs.tu-berlin.de> Hi all, Is there a documented way of making dig (dnsutils) calls from within GPG? Or a standard means to run a shell command and parse its output? I looked at exec_write() call but its usage wasn't entirely clear after I read its code because of fork+exec+pipe at play and the pipe reading from stdin. Suggestions welcome! Thanks and Regards, Bhargava -- Bhargava Shastry Security in Telecommunications TU Berlin / Telekom Innovation Laboratories Ernst-Reuter-Platz 7, Sekr TEL 17 / D - 10587 Berlin, Germany phone: +49 30 8353 58235 From bshastry at sec.t-labs.tu-berlin.de Fri Sep 23 15:46:49 2016 From: bshastry at sec.t-labs.tu-berlin.de (Bhargava Shastry) Date: Fri, 23 Sep 2016 15:46:49 +0200 Subject: Making dig calls within GPG Message-ID: Hi all, Is there a documented way of making dig (dnsutils) calls from within GPG? Or a standard means to run a shell command and parse its output? I looked at exec_write() call but its usage wasn't entirely clear after I read its code because of fork+exec+pipe at play and the pipe reading from stdin. Suggestions welcome! :-) Thanks and Regards, Bhargava -- Bhargava Shastry Security in Telecommunications TU Berlin / Telekom Innovation Laboratories Ernst-Reuter-Platz 7, Sekr TEL 17 / D - 10587 Berlin, Germany phone: +49 30 8353 58235 From dkg at fifthhorseman.net Fri Sep 23 13:58:58 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 23 Sep 2016 07:58:58 -0400 Subject: [GPGME PATCH] Clarify licensing Message-ID: <20160923115858.13053-1-dkg@fifthhorseman.net> * src/b64dec.c, src/mbox-util.c, src/mbox-util.h: These three files are explicitly licensed under LGPL, but their comments suggest that details about the warranty can be found in the GPL. Adjust comments to refer to the correct license. Signed-off-by: Daniel Kahn Gillmor --- src/b64dec.c | 2 +- src/mbox-util.c | 2 +- src/mbox-util.h | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/b64dec.c b/src/b64dec.c index 7965a30..9a7efca 100644 --- a/src/b64dec.c +++ b/src/b64dec.c @@ -12,7 +12,7 @@ * This file is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. + * GNU Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public License * along with this program; if not, see . diff --git a/src/mbox-util.c b/src/mbox-util.c index 83c8b5e..656b5d7 100644 --- a/src/mbox-util.c +++ b/src/mbox-util.c @@ -12,7 +12,7 @@ * This file is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. + * GNU Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public License * along with this program; if not, see . diff --git a/src/mbox-util.h b/src/mbox-util.h index 3195a4d..c5747b6 100644 --- a/src/mbox-util.h +++ b/src/mbox-util.h @@ -11,7 +11,7 @@ * This file is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. + * GNU Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public License * along with this program; if not, see . -- 2.9.3 From wk at gnupg.org Fri Sep 23 20:49:41 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 23 Sep 2016 20:49:41 +0200 Subject: Making dig calls within GPG In-Reply-To: (Bhargava Shastry's message of "Fri, 23 Sep 2016 15:46:49 +0200") References: Message-ID: <87zimya1tm.fsf@wheatstone.g10code.de> On Fri, 23 Sep 2016 15:46, bshastry at sec.t-labs.tu-berlin.de said: > Is there a documented way of making dig (dnsutils) calls from within > GPG? Or a standard means to run a shell command and parse its output? I No, you can of course run an external program like host or dig. For all other purposes GnuPG includes a thin layer around the standard or ADNS resolver library. This is done in dirmngr/dns-stuff.c and t-dns-stuff.c for testing the code. The code is alo abale to route DNS via Tor. > looked at exec_write() call but its usage wasn't entirely clear after I > read its code because of fork+exec+pipe at play and the pipe reading > from stdin. Look at tools/wks-receive.c as an example how you can call external tools. Or g13/sh-bolockdev.c for simple use cases. Some of the primitives don't yet work on Windows, though. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From alon.barlev at gmail.com Fri Sep 23 22:38:03 2016 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Fri, 23 Sep 2016 23:38:03 +0300 Subject: [gpgme][PATCH] build: tests: avoid build tests if not required Message-ID: <1474663083-27507-1-git-send-email-alon.barlev@gmail.com> test enables reducing dependencies for build if tests are not going to run. Signed-off-by: Alon Bar-Lev --- lang/qt/tests/Makefile.am | 2 +- tests/Makefile.am | 2 +- tests/gpg/Makefile.am | 2 +- tests/gpgsm/Makefile.am | 2 +- tests/opassuan/Makefile.am | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/lang/qt/tests/Makefile.am b/lang/qt/tests/Makefile.am index f243a55..c40d75d 100644 --- a/lang/qt/tests/Makefile.am +++ b/lang/qt/tests/Makefile.am @@ -62,7 +62,7 @@ nodist_t_keylist_SOURCES = $(moc_files) BUILT_SOURCES = $(moc_files) -noinst_PROGRAMS = t-keylist t-keylocate t-ownertrust t-tofuinfo t-encrypt \ +check_PROGRAMS = t-keylist t-keylocate t-ownertrust t-tofuinfo t-encrypt \ run-keyformailboxjob t-wkspublish CLEANFILES = secring.gpg pubring.gpg pubring.kbx trustdb.gpg dirmngr.conf \ diff --git a/tests/Makefile.am b/tests/Makefile.am index c71914f..b698e11 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -31,7 +31,7 @@ LDADD = ../src/libgpgme.la @GPG_ERROR_LIBS@ noinst_HEADERS = run-support.h -noinst_PROGRAMS = $(TESTS) run-keylist run-export run-import run-sign \ +check_PROGRAMS = $(TESTS) run-keylist run-export run-import run-sign \ run-verify run-encrypt run-identify run-decrypt run-genkey \ run-keysign run-tofu diff --git a/tests/gpg/Makefile.am b/tests/gpg/Makefile.am index 2538f63..807ca5c 100644 --- a/tests/gpg/Makefile.am +++ b/tests/gpg/Makefile.am @@ -71,7 +71,7 @@ if !HAVE_W32_SYSTEM tests_skipped += t-cancel endif -noinst_PROGRAMS = $(c_tests) $(tests_skipped) +check_PROGRAMS = $(c_tests) $(tests_skipped) clean-local: diff --git a/tests/gpgsm/Makefile.am b/tests/gpgsm/Makefile.am index 41645b6..1bdb712 100644 --- a/tests/gpgsm/Makefile.am +++ b/tests/gpgsm/Makefile.am @@ -40,7 +40,7 @@ LDADD = ../../src/libgpgme.la # We don't run t-genkey in the test suite, because it takes too long # and needs a working pinentry. -noinst_PROGRAMS = $(c_tests) t-genkey cms-keylist cms-decrypt +check_PROGRAMS = $(c_tests) t-genkey cms-keylist cms-decrypt key_id = 32100C27173EF6E9C4E9A25D3D69F86D37A4F939 diff --git a/tests/opassuan/Makefile.am b/tests/opassuan/Makefile.am index 31d26ed..608b608 100644 --- a/tests/opassuan/Makefile.am +++ b/tests/opassuan/Makefile.am @@ -27,7 +27,7 @@ EXTRA_DIST = AM_CPPFLAGS = -I$(top_builddir)/src @GPG_ERROR_CFLAGS@ LDADD = ../../src/libgpgme.la -noinst_PROGRAMS = $(TESTS) t-command +check_PROGRAMS = $(TESTS) t-command DISTCLEANFILES = -- 2.7.3 From alon.barlev at gmail.com Sat Sep 24 01:28:38 2016 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sat, 24 Sep 2016 02:28:38 +0300 Subject: [gpgme][PATCH] build: lang: python: cleanups Message-ID: <1474673318-8143-1-git-send-email-alon.barlev@gmail.com> 1. Make setup.py executable when generated. 2. Add prepare target to enable prepare the source tree without building anything. This is handy to enable standard distutils build outside of gpgme build system. 3. Treat data.h in similar manner as other VPATH issues, just copy it to the srcdir to simplify build, remove the CFLAGS requirement of distutils. 4. Add environment variable (binary_builddir) for setup to use alternate build directory so that for multiple targets same binaries may be used without rebuilding the C part. The above does not alter the behavior of current build but supports the following sequence: $ mkdir common $ cd common $ ../configure --enable-languages= $ make $ cd .. $ mkdir python $ cd python $ ../configure --enable-languages= $ cd lang/python $ make prepare $ binary_builddir="../../../common" ./setup.py build $ binary_builddir="../../../common" ./setup.py install Notice the standard use of distutils which is required for package manager to control the python selection and build process. Signed-off-by: Alon Bar-Lev --- configure.ac | 2 +- lang/python/Makefile.am | 11 ++++++----- lang/python/gpgme.i | 2 +- lang/python/setup.py.in | 9 +++++---- 4 files changed, 13 insertions(+), 11 deletions(-) diff --git a/configure.ac b/configure.ac index 4a29f2f..efa1f19 100644 --- a/configure.ac +++ b/configure.ac @@ -886,9 +886,9 @@ AC_CONFIG_FILES([lang/Makefile lang/cl/Makefile lang/cl/gpgme.asd]) AM_COND_IF([HAVE_DOXYGEN], [AC_CONFIG_FILES([lang/qt/doc/Doxyfile])]) AC_CONFIG_FILES(lang/qt/doc/Makefile) AC_CONFIG_FILES([lang/python/Makefile - lang/python/setup.py lang/python/pyme/version.py lang/python/tests/Makefile]) +AC_CONFIG_FILES([lang/python/setup.py], [chmod a+x lang/python/setup.py]) AC_OUTPUT echo " diff --git a/lang/python/Makefile.am b/lang/python/Makefile.am index 2271ce0..fb1eebf 100644 --- a/lang/python/Makefile.am +++ b/lang/python/Makefile.am @@ -51,17 +51,18 @@ copystamp: $(COPY_FILES) $(COPY_FILES_PYME) cp -R $(COPY_FILES) . ; \ cp -R $(COPY_FILES_PYME) pyme ; \ fi + cp "$(top_srcdir)/src/data.h" . touch $@ +prepare: copystamp + all-local: copystamp for PYTHON in $(PYTHONS); do \ - CFLAGS="$(CFLAGS) -I$(top_srcdir)" \ - $$PYTHON setup.py build --verbose ; \ + $$PYTHON setup.py build --verbose ; \ done dist/pyme3-$(VERSION).tar.gz dist/pyme3-$(VERSION).tar.gz.asc: copystamp - CFLAGS="$(CFLAGS) -I$(top_srcdir)" \ - $(PYTHON) setup.py sdist --verbose + $(PYTHON) setup.py sdist --verbose gpg2 --detach-sign --armor dist/pyme3-$(VERSION).tar.gz .PHONY: sdist @@ -72,7 +73,7 @@ upload: dist/pyme3-$(VERSION).tar.gz dist/pyme3-$(VERSION).tar.gz.asc twine upload $^ CLEANFILES = gpgme.h errors.i gpgme_wrap.c pyme/gpgme.py \ - copystamp + data.h copystamp # Remove the rest. # diff --git a/lang/python/gpgme.i b/lang/python/gpgme.i index 84addae..ac666f4 100644 --- a/lang/python/gpgme.i +++ b/lang/python/gpgme.i @@ -183,7 +183,7 @@ representation of struct gpgme_data for an very efficient check if the buffer has been modified. */ %{ -#include "src/data.h" /* For struct gpgme_data. */ +#include "data.h" /* For struct gpgme_data. */ %} #endif diff --git a/lang/python/setup.py.in b/lang/python/setup.py.in index 31892c1..ce06758 100755 --- a/lang/python/setup.py.in +++ b/lang/python/setup.py.in @@ -32,13 +32,14 @@ library_dirs = [] in_tree = False extra_swig_opts = [] extra_macros = dict() +binary_builddir=os.environ.get('binary_builddir', '../..') -if os.path.exists("../../src/gpgme-config"): +if os.path.exists(os.path.join(binary_builddir, "src/gpgme-config")): # In-tree build. in_tree = True - gpgme_config = ["../../src/gpgme-config"] + gpgme_config_flags - gpgme_h = "../../src/gpgme.h" - library_dirs = ["../../src/.libs"] # XXX uses libtool internals + gpgme_config = [os.path.join(binary_builddir, "src/gpgme-config")] + gpgme_config_flags + gpgme_h = os.path.join(binary_builddir, "src/gpgme.h") + library_dirs = [os.path.join(binary_builddir, "src/.libs")] # XXX uses libtool internals extra_macros.update( HAVE_DATA_H=1, IN_TREE_BUILD=1, -- 2.7.3 From alon.barlev at gmail.com Sat Sep 24 01:39:30 2016 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sat, 24 Sep 2016 02:39:30 +0300 Subject: [gpgme] 1.7 build experience and issues In-Reply-To: <8760pm3g5k.fsf@europa.jade-hamburg.de> References: <8760pm3g5k.fsf@europa.jade-hamburg.de> Message-ID: On 23 September 2016 at 16:21, Justus Winter wrote: > Hi :) > > Alon Bar-Lev writes: >> I am the Gentoo maintainer of gpgme. > > thanks for the feedback. > >> FAILING TESTS >> >> t-sig-notation fails due to Unexpected notation data > > What version of GnuPG are you using as backend? > > We fixed a bug in GnuPG recently to properly report a notation flag, and > tightened the test case accordingly. To support older versions of > GnuPG, the test tries to detect that an older version is used, but that > test might fail for some reason. $ gpg --version gpg (GnuPG) 2.0.28 libgcrypt 1.7.3 > >> PYTHON >> >> If not absolutely required to have this in the same package, maybe it would >> be better to split it into a separate one that is to be used post >> installation of pgpme using pure python tools. > > Surely gentoo can produce several binary packages from one source > package? Well, it is not that simple. When you build several binary packages, each with several binary python you end up with somekind of deadlock. Either build the C bindings over and over for each python version or hack the package. Usually, there is no value in mixing the build of the C library and the python bindings into same build process and package. It is much easier to package both as separate packages that are built on after the other, without the need to hack the in-tree and multiple variants issues. > We are in fact using the python tools to build the bindings. The checks > in configure merely try to detect which versions are available, and if > everything is in place to produce python modules with SWIG. Correct, however, the combination of autotools and distutils is what makes it more difficult. I sent a patch to clean this a bit to enable portage usage, however, I think that for generating the version into setup.py it is an overkill to use autoconf. You may consider taking this a bit farther to include version.py to be imported by setup.py, generate version.py as generated distributed source, this will skip the need to use configure and make, with the exception of data.h which should have its own solution (moving away from in-tree build). >> The autoconf ignores PYTHON override or any other attempt to use explicit >> environment. >> Please enable override to enable the packaging system to build the bindings >> to the supported python interpreters of the system. > > Gladly. Can you please be more specific how that would look like? Oh... this is simple... if you use AM_PATH_PYTHON in autoconf, never unset its macros... :) > > Cheers, > Justus From alon.barlev at gmail.com Sat Sep 24 01:42:55 2016 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sat, 24 Sep 2016 02:42:55 +0300 Subject: [gpgme] 1.7 build experience and issues In-Reply-To: <3801968.rZS1F5c3J5@esus> References: <3801968.rZS1F5c3J5@esus> Message-ID: On 23 September 2016 at 16:41, Andre Heinecke wrote: > Hi, > > Thanks for your feedback. > > On Friday 23 September 2016 12:29:48 Alon Bar-Lev wrote: >> qt/t-encrypt opens a pinentry window, maybe due to: >> /* Loopback and passphrase provider don't work for mixed encryption. >> * So this test is disabled until gnupg(?) is fixed for this. */ > > I can reproduce this by using gnupg 2.0.26 instead of 2.1 or 1.4 I'll > investigate. Thanks! > But its not related to the comment. The comment there is outdated I've since > fixed that loopback and passphrase provider work with symmetric encryption it > was a gpgme issue. That test should be reenabled. (As its currently not > declared as a Slot it's disabled). > > The pinentry comes from the testSimpleEncryptDecrypt. Good. >> QT DOC >> >> Can you please make the qtdoc enable/disable explicitly instead of >> autodetecting doxygen? >> Also, these docs are not installed, shouldn't they? > > Mh, probably, disable by default, enable on option and then install them if > the option is set. The docs are not so great and useful in my opinion that > they should be installed / packaged by default. They should be improved of > course ;-). No problem, so please add explicit --enable-qt-apidocs or --enable-apidocs to explicit enable this, also fail if doxygen is not installed while explicitly enabled. The implicit behaviours introduces different build sequences for different environment and we want to avoid that. For now, I export DOXYGEN= to disable this path. > > 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 alon.barlev at gmail.com Sat Sep 24 01:51:12 2016 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sat, 24 Sep 2016 02:51:12 +0300 Subject: [gpgme] 1.7 build experience and issues In-Reply-To: References: Message-ID: BTW: Any reason these are checked into git? These are auto generated. INSTALL can be removed from generation by AUTOMAKE_OPTIONS=foreign in top Makefile.am or AM_INIT_AUTOMAKE parameter. modified: INSTALL modified: build-aux/compile modified: build-aux/config.guess modified: build-aux/config.sub modified: build-aux/depcomp modified: build-aux/install-sh modified: build-aux/ltmain.sh modified: build-aux/missing modified: build-aux/mkinstalldirs modified: build-aux/texinfo.tex modified: m4/libtool.m4 modified: m4/ltoptions.m4 modified: m4/ltsugar.m4 modified: m4/ltversion.m4 modified: m4/lt~obsolete.m4 From alon.barlev at gmail.com Sat Sep 24 10:14:18 2016 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sat, 24 Sep 2016 11:14:18 +0300 Subject: [gpgme][PATCH] build: lang: python: cleanups In-Reply-To: <1474673318-8143-1-git-send-email-alon.barlev@gmail.com> References: <1474673318-8143-1-git-send-email-alon.barlev@gmail.com> Message-ID: <1474704858-4485-1-git-send-email-alon.barlev@gmail.com> 1. Make setup.py executable when generated. 2. Add prepare target to enable prepare the source tree without building anything. This is handy to enable standard distutils build outside of gpgme build system. 3. Treat data.h in similar manner as other VPATH issues, just symlink it to the srcdir to simplify build, remove the CFLAGS requirement of distutils. The above does not alter the behavior of current build but supports the following sequence: $ mkdir build $ cd build $ ../configure --enable-languages= $ make $ cd lang/python $ make prepare $ ./setup.py build $ ./setup.py install Notice the standard use of distutils which is required for package manager to control the python selection and build process. Signed-off-by: Alon Bar-Lev --- configure.ac | 2 +- lang/python/Makefile.am | 16 ++++++++++------ lang/python/gpgme.i | 2 +- 3 files changed, 12 insertions(+), 8 deletions(-) diff --git a/configure.ac b/configure.ac index 4a29f2f..efa1f19 100644 --- a/configure.ac +++ b/configure.ac @@ -886,9 +886,9 @@ AC_CONFIG_FILES([lang/Makefile lang/cl/Makefile lang/cl/gpgme.asd]) AM_COND_IF([HAVE_DOXYGEN], [AC_CONFIG_FILES([lang/qt/doc/Doxyfile])]) AC_CONFIG_FILES(lang/qt/doc/Makefile) AC_CONFIG_FILES([lang/python/Makefile - lang/python/setup.py lang/python/pyme/version.py lang/python/tests/Makefile]) +AC_CONFIG_FILES([lang/python/setup.py], [chmod a+x lang/python/setup.py]) AC_OUTPUT echo " diff --git a/lang/python/Makefile.am b/lang/python/Makefile.am index 2271ce0..9866f53 100644 --- a/lang/python/Makefile.am +++ b/lang/python/Makefile.am @@ -46,24 +46,28 @@ COPY_FILES_PYME = \ # For VPATH builds we need to copy some files because Python's # distutils are not VPATH-aware. -copystamp: $(COPY_FILES) $(COPY_FILES_PYME) +copystamp: $(COPY_FILES) $(COPY_FILES_PYME) data.h if test "$(srcdir)" != "$(builddir)" ; then \ cp -R $(COPY_FILES) . ; \ cp -R $(COPY_FILES_PYME) pyme ; \ fi touch $@ +data.h: + ln -s "$(top_srcdir)/src/data.h" + all-local: copystamp for PYTHON in $(PYTHONS); do \ - CFLAGS="$(CFLAGS) -I$(top_srcdir)" \ - $$PYTHON setup.py build --verbose ; \ + $$PYTHON setup.py build --verbose ; \ done dist/pyme3-$(VERSION).tar.gz dist/pyme3-$(VERSION).tar.gz.asc: copystamp - CFLAGS="$(CFLAGS) -I$(top_srcdir)" \ - $(PYTHON) setup.py sdist --verbose + $(PYTHON) setup.py sdist --verbose gpg2 --detach-sign --armor dist/pyme3-$(VERSION).tar.gz +.PHONY: prepare +prepare: copystamp + .PHONY: sdist sdist: dist/pyme3-$(VERSION).tar.gz dist/pyme3-$(VERSION).tar.gz.asc @@ -72,7 +76,7 @@ upload: dist/pyme3-$(VERSION).tar.gz dist/pyme3-$(VERSION).tar.gz.asc twine upload $^ CLEANFILES = gpgme.h errors.i gpgme_wrap.c pyme/gpgme.py \ - copystamp + data.h copystamp # Remove the rest. # diff --git a/lang/python/gpgme.i b/lang/python/gpgme.i index 84addae..ac666f4 100644 --- a/lang/python/gpgme.i +++ b/lang/python/gpgme.i @@ -183,7 +183,7 @@ representation of struct gpgme_data for an very efficient check if the buffer has been modified. */ %{ -#include "src/data.h" /* For struct gpgme_data. */ +#include "data.h" /* For struct gpgme_data. */ %} #endif -- 2.7.3 From alon.barlev at gmail.com Sat Sep 24 10:23:38 2016 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sat, 24 Sep 2016 11:23:38 +0300 Subject: [gpgme] 1.7 build experience and issues In-Reply-To: References: <8760pm3g5k.fsf@europa.jade-hamburg.de> Message-ID: On 24 September 2016 at 02:39, Alon Bar-Lev wrote: > On 23 September 2016 at 16:21, Justus Winter wrote: >> Hi :) >> >> Alon Bar-Lev writes: >>> I am the Gentoo maintainer of gpgme. >> >> thanks for the feedback. >> >>> FAILING TESTS >>> >>> t-sig-notation fails due to Unexpected notation data >> >> What version of GnuPG are you using as backend? >> >> We fixed a bug in GnuPG recently to properly report a notation flag, and >> tightened the test case accordingly. To support older versions of >> GnuPG, the test tries to detect that an older version is used, but that >> test might fail for some reason. > > $ gpg --version > gpg (GnuPG) 2.0.28 > libgcrypt 1.7.3 > > >> >>> PYTHON >>> >>> If not absolutely required to have this in the same package, maybe it would >>> be better to split it into a separate one that is to be used post >>> installation of pgpme using pure python tools. >> >> Surely gentoo can produce several binary packages from one source >> package? > > Well, it is not that simple. > When you build several binary packages, each with several binary > python you end up with somekind of deadlock. > Either build the C bindings over and over for each python version or > hack the package. > Usually, there is no value in mixing the build of the C library and > the python bindings into same build process and package. It is much > easier to package both as separate packages that are built on after > the other, without the need to hack the in-tree and multiple variants > issues. > >> We are in fact using the python tools to build the bindings. The checks >> in configure merely try to detect which versions are available, and if >> everything is in place to produce python modules with SWIG. > > Correct, however, the combination of autotools and distutils is what > makes it more difficult. > > I sent a patch to clean this a bit to enable portage usage, however, I > think that for generating the version into setup.py it is an overkill > to use autoconf. You may consider taking this a bit farther to include > version.py to be imported by setup.py, generate version.py as > generated distributed source, this will skip the need to use configure > and make, with the exception of data.h which should have its own > solution (moving away from in-tree build). I sent simplified version of the package, I did more distutils magic at packager, and could live with simpler changes, I hope it is ok. What I thought of doing (have no time right now): 1. setup.py to import version.py so that only setup's version.py is a template (vs entire setup.py). 2. setup.py to add version as preprocessor macro (-Dxx=yy) to pass it to C library without a need for additional template file. 3. pyme/version.py to obtain version from the C library at runtime. 4. use symlink instead of copy in Makefile.am, now that pyme/version.py is not a template you can symlink entire pyme. Please consider, I believe it will simplify the process. >>> The autoconf ignores PYTHON override or any other attempt to use explicit >>> environment. >>> Please enable override to enable the packaging system to build the bindings >>> to the supported python interpreters of the system. >> >> Gladly. Can you please be more specific how that would look like? > > Oh... this is simple... if you use AM_PATH_PYTHON in autoconf, never > unset its macros... :) > >> >> Cheers, >> Justus From aheinecke at intevation.de Fri Sep 23 15:33:55 2016 From: aheinecke at intevation.de (Andre Heinecke) Date: Fri, 23 Sep 2016 15:33:55 +0200 Subject: gpgme: cpp: failing on 32 bit due to LFS requirements In-Reply-To: References: Message-ID: <2450231.IqHaanloLK@esus> Hi, On Thursday 22 September 2016 16:27:45 Andreas Stieger wrote: > Hello, > > the C++ bindings are failing when building on 32 bits due to the lack of > definition of the required LFS macros. As you were looking at the cpp > compiler flags anyway, I thought I'd let you know: Thanks, I just commited a patch that includes the config.h of gpgme in the cpp and qt bindings. One of the advantages of living in the same package is that we can use the same config flags :-) Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: This is a digitally signed message part. URL: From astieger at suse.com Sat Sep 24 20:58:58 2016 From: astieger at suse.com (Andreas Stieger) Date: Sat, 24 Sep 2016 20:58:58 +0200 Subject: gpgme: cpp: failing on 32 bit due to LFS requirements In-Reply-To: <2450231.IqHaanloLK@esus> References: <2450231.IqHaanloLK@esus> Message-ID: <4aa23acd-c9a2-f046-1c71-0e780622c0ea@suse.com> Hello, On 09/23/2016 03:33 PM, Andre Heinecke wrote: > On Thursday 22 September 2016 16:27:45 Andreas Stieger wrote: >> the C++ bindings are failing when building on 32 bits due to the lack of >> definition of the required LFS macros. As you were looking at the cpp >> compiler flags anyway, I thought I'd let you know: > > Thanks, I just commited a patch that includes the config.h of gpgme in the cpp > and qt bindings. One of the advantages of living in the same package is that > we can use the same config flags :-) Thanks (a142f187b7ddb2728ec3e1743da4a0c4538ab40a) However due to the same issue the swig bindings fail to build on i586: swigging gpgme.i to gpgme_wrap.c swig -python -py3 -builtin -threads -outdir pyme -DHAVE_DATA_H=1 -DIN_TREE_BUILD=1 -o gpgme_wrap.c gpgme.i gpgme.h:104: Error: CPP #error "GPGME was compiled with _FILE_OFFSET_BITS = 64, please see the section "Largefile support (LFS)" in the GPGME manual.". Use the -cpperraswarn option to continue swig processing. Andreas -- Andreas Stieger Project Manager Security SUSE Linux GmbH, GF: Felix Imend?rffer, Jane Smithard, Graham Norton, HRB 21284 (AG N?rnberg) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Sun Sep 25 04:59:59 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 24 Sep 2016 22:59:59 -0400 Subject: [PATCH GnuPG] agent: Enable restricted, browser, and ssh socket by default. In-Reply-To: <87bmzjxt43.fsf@alice.fifthhorseman.net> References: <20160915125804.7568-1-justus@g10code.com> <878tutdw85.fsf@wheatstone.g10code.de> <87d1k52mcc.fsf@alice.fifthhorseman.net> <87a8f8cr5p.fsf@wheatstone.g10code.de> <20160919113241.GA5510@x2.esmtp.org> <87bmzjxt43.fsf@alice.fifthhorseman.net> Message-ID: <878tug8z0w.fsf@alice.fifthhorseman.net> On Mon 2016-09-19 21:22:36 -0400, Daniel Kahn Gillmor wrote: > offering the restricted socket in addition to the normal socket doesn't > seem to increase the attack surface. one more note on the naming concerns raised in this thread: gpg-agent actually already calls the socket "restricted", via its "getinfo restricted" reporting mechanism. --dkg From wk at gnupg.org Sun Sep 25 12:16:03 2016 From: wk at gnupg.org (Werner Koch) Date: Sun, 25 Sep 2016 12:16:03 +0200 Subject: [PATCH GnuPG] agent: Enable restricted, browser, and ssh socket by default. In-Reply-To: <878tug8z0w.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Sat, 24 Sep 2016 22:59:59 -0400") References: <20160915125804.7568-1-justus@g10code.com> <878tutdw85.fsf@wheatstone.g10code.de> <87d1k52mcc.fsf@alice.fifthhorseman.net> <87a8f8cr5p.fsf@wheatstone.g10code.de> <20160919113241.GA5510@x2.esmtp.org> <87bmzjxt43.fsf@alice.fifthhorseman.net> <878tug8z0w.fsf@alice.fifthhorseman.net> Message-ID: <87shso8eu4.fsf@wheatstone.g10code.de> On Sun, 25 Sep 2016 04:59, dkg at fifthhorseman.net said: > one more note on the naming concerns raised in this thread: gpg-agent > actually already calls the socket "restricted", via its "getinfo > restricted" reporting mechanism. That is not about the socket but about the current connection: # restricted - Returns OK if the connection is in restricted mode. It is just a property of the connection. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From justus at g10code.com Mon Sep 26 10:51:13 2016 From: justus at g10code.com (Justus Winter) Date: Mon, 26 Sep 2016 10:51:13 +0200 Subject: [gpgme] 1.7 build experience and issues In-Reply-To: References: <8760pm3g5k.fsf@europa.jade-hamburg.de> Message-ID: <87k2dzjb7i.fsf@europa.jade-hamburg.de> Hello :) Alon Bar-Lev writes: >>> PYTHON >>> >>> If not absolutely required to have this in the same package, maybe it would >>> be better to split it into a separate one that is to be used post >>> installation of pgpme using pure python tools. >> >> Surely gentoo can produce several binary packages from one source >> package? > > Well, it is not that simple. > When you build several binary packages, each with several binary > python you end up with somekind of deadlock. > Either build the C bindings over and over for each python version or > hack the package. > Usually, there is no value in mixing the build of the C library and > the python bindings into same build process and package. It is much > easier to package both as separate packages that are built on after > the other, without the need to hack the in-tree and multiple variants > issues. We disagree here then. >> We are in fact using the python tools to build the bindings. The checks >> in configure merely try to detect which versions are available, and if >> everything is in place to produce python modules with SWIG. > > Correct, however, the combination of autotools and distutils is what > makes it more difficult. > > I sent a patch to clean this a bit to enable portage usage, however, I > think that for generating the version into setup.py it is an overkill > to use autoconf. You may consider taking this a bit farther to include > version.py to be imported by setup.py, generate version.py as > generated distributed source, this will skip the need to use configure That was done before, however, including bits from the package in setup.py is frowned upon and lead to a problem (I don't remember, maybe the changelog mentions it), that's why I changed it to the way it is done now. > and make, with the exception of data.h which should have its own > solution (moving away from in-tree build). This needs a proper API, agreed. >>> The autoconf ignores PYTHON override or any other attempt to use explicit >>> environment. >>> Please enable override to enable the packaging system to build the bindings >>> to the supported python interpreters of the system. >> >> Gladly. Can you please be more specific how that would look like? > > Oh... this is simple... if you use AM_PATH_PYTHON in autoconf, never > unset its macros... :) Well, that is not a very helpful answer. We do use AM_PATH_PYTHON, and we do reset the information it has gathered to be able to use it again. Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From justus at g10code.com Mon Sep 26 11:02:00 2016 From: justus at g10code.com (Justus Winter) Date: Mon, 26 Sep 2016 11:02:00 +0200 Subject: [gpgme][PATCH] build: lang: python: cleanups In-Reply-To: <1474673318-8143-1-git-send-email-alon.barlev@gmail.com> References: <1474673318-8143-1-git-send-email-alon.barlev@gmail.com> Message-ID: <87h993japj.fsf@europa.jade-hamburg.de> Hello, thanks for the patch. Alon Bar-Lev writes: > 1. Make setup.py executable when generated. Please fix one issue per patch, that makes it way easier to review and partially apply. > 2. Add prepare target to enable prepare the source tree without building > anything. This is handy to enable standard distutils build outside of > gpgme build system. That is a good idea indeed. > 3. Treat data.h in similar manner as other VPATH issues, just copy it to > the srcdir to simplify build, remove the CFLAGS requirement of > distutils. No. Including data.h a hack, and the proper solution is to create a proper API so that we don't need the layout of struct gpgme_data. Also, we don't relay the CFLAGS merely to locate data.h, we also like to compile the glue code with the very same CFLAGS. > 4. Add environment variable (binary_builddir) for setup to use alternate > build directory so that for multiple targets same binaries may be > used without rebuilding the C part. I guess we could do that, yes. Thanks, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From justus at g10code.com Mon Sep 26 17:01:44 2016 From: justus at g10code.com (Justus Winter) Date: Mon, 26 Sep 2016 17:01:44 +0200 Subject: gpgme: cpp: failing on 32 bit due to LFS requirements In-Reply-To: <4aa23acd-c9a2-f046-1c71-0e780622c0ea@suse.com> References: <2450231.IqHaanloLK@esus> <4aa23acd-c9a2-f046-1c71-0e780622c0ea@suse.com> Message-ID: <87eg46k8mf.fsf@europa.jade-hamburg.de> Andreas Stieger writes: > On 09/23/2016 03:33 PM, Andre Heinecke wrote: >> On Thursday 22 September 2016 16:27:45 Andreas Stieger wrote: >>> the C++ bindings are failing when building on 32 bits due to the lack of >>> definition of the required LFS macros. As you were looking at the cpp >>> compiler flags anyway, I thought I'd let you know: >> >> Thanks, I just commited a patch that includes the config.h of gpgme in the cpp >> and qt bindings. One of the advantages of living in the same package is that >> we can use the same config flags :-) > > Thanks (a142f187b7ddb2728ec3e1743da4a0c4538ab40a) > However due to the same issue the swig bindings fail to build on i586: > > swigging gpgme.i to gpgme_wrap.c > swig -python -py3 -builtin -threads -outdir pyme -DHAVE_DATA_H=1 > -DIN_TREE_BUILD=1 -o gpgme_wrap.c gpgme.i > gpgme.h:104: Error: CPP #error "GPGME was compiled with > _FILE_OFFSET_BITS = 64, please see the section "Largefile support (LFS)" > in the GPGME manual.". Use the -cpperraswarn option to continue swig > processing. This should be fixed with 3703a472. Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From ineiev at gnu.org Tue Sep 27 06:02:42 2016 From: ineiev at gnu.org (Ineiev) Date: Tue, 27 Sep 2016 00:02:42 -0400 Subject: [PINENTRY PATCH] tty button-related fixes and refinements In-Reply-To: <20160408174738.GA26817@gnu.org> References: <20160408174738.GA26817@gnu.org> Message-ID: <20160927040242.GM30569@gnu.org> Hello, On Fri, Apr 08, 2016 at 01:47:38PM -0400, Ineiev wrote: > > I attach some fixes I've come up with when playing with non-ASCII > texts in buttons. > > The first one simplifies key checking code a little bit; the second > one fixes a few bugs in underscore processing; the third one lets > the user see the localized message even if the pinentry doesn't > support its accelerators (by the way, I think that pinentry > should localize the messages that aren't customized from the agent, > like "Press any key to continue."); the last one adds a default > message to a call of button() so that pinentry won't skip a button > when its text is localized. I've fixed a few typos in comments and log messages. Thank you! -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-tty-Refactor-usage-of-tolower.patch Type: text/x-diff Size: 1993 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-tty-Fix-underscore-processing-in-accelerators.patch Type: text/x-diff Size: 1577 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-tty-Show-supplied-message-when-using-default.patch Type: text/x-diff Size: 2509 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-tty-Avoid-using-button-with-NULL-default-text.patch Type: text/x-diff Size: 911 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From justus at g10code.com Tue Sep 27 12:43:47 2016 From: justus at g10code.com (Justus Winter) Date: Tue, 27 Sep 2016 12:43:47 +0200 Subject: [GPGME PATCH] Clarify licensing In-Reply-To: <20160923115858.13053-1-dkg@fifthhorseman.net> References: <20160923115858.13053-1-dkg@fifthhorseman.net> Message-ID: <87twd162sc.fsf@europa.jade-hamburg.de> Daniel Kahn Gillmor writes: > * src/b64dec.c, src/mbox-util.c, src/mbox-util.h: These three files > are explicitly licensed under LGPL, but their comments suggest that > details about the warranty can be found in the GPL. Adjust comments > to refer to the correct license. Merged, thanks! Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From nicolas.boullis at ecp.fr Tue Sep 27 12:23:22 2016 From: nicolas.boullis at ecp.fr (Nicolas Boullis) Date: Tue, 27 Sep 2016 12:23:22 +0200 Subject: Using Scute with a 4096-bit key and TLSv1.2? Message-ID: <20160927102322.GB1692@eridan.ccs.ecp.fr> Hi, I?ve long been using GnuPG with a PKCS#15 token, through OpenSC and gnupg-pkcs11-scd. Then I switched to an OpenPGP smartcard, and I?m very happy with the (much) simpler configuration and the ability to use my smartcard for SSH authentication. Now, I?d love it if I could also use my smartcard for https authentication with client certificate, so I gave a try to Scute. First issue: I have 4096-bit keys, which the current release of scute (1.4.0) does not handle. Fortunately, the problem is fixed in git. Second issue: also it now seems to work fine with TLSv1.1, it fails with TLSv1.2. Firefox reports: A PKCS #11 module returned CKR_FUNCTION_FAILED, indicating that the requested function could not be performed. Trying the same operation again might succeed. Error code: SEC_ERROR_PKCS11_FUNCTION_FAILED As far as I can see, this problem was discussed 2 years ago on this list: https://lists.gnupg.org/pipermail/gnupg-devel/2014-September/028717.html and the commit e22c8cfa12849b215f16afb34f7a5dc233dbc70a seems to be meant to address this problem? Any idea how I can have this problem fixed? I am no crypto-guru and probably can?t solve this problem all by myself, but I?d be happy to test things? BTW, are there plans to release Scute 1.5.0 anytime soon? FWIW, I?m running Debian 8.6 (Jessie) with the provided GnuPG; I only tried tu build Scute from git. Cheers, -- Nicolas Boullis From dgouttegattat at incenp.org Tue Sep 27 15:57:01 2016 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Tue, 27 Sep 2016 15:57:01 +0200 Subject: Using Scute with a 4096-bit key and TLSv1.2? In-Reply-To: <20160927102322.GB1692@eridan.ccs.ecp.fr> References: <20160927102322.GB1692@eridan.ccs.ecp.fr> Message-ID: On 09/27/2016 12:23 PM, Nicolas Boullis wrote: > Any idea how I can have this problem fixed? > I am no crypto-guru and probably can?t solve this problem all by myself, > but I?d be happy to test things? Is there any chance you could try with GnuPG 2.1 instead of GnuPG 2.0? If I remember correctly, even with the latest Scute (at the tip of the current master branch in Git), with GnuPG 2.0 you cannot use TLS 1.2, because the agent from GnuPG 2.0 does not expect the kind of hash that it receives from Scute. At the time, I was able to make TLS 1.2 work with GnuPG 2.0.26 by backporting commit 1c09def22d97de3738a2bec4970504bfc155680b [1]. You could try that, but I think switching to GnuPG 2.1 would be a better solution if possible. Damien [1] https://lists.gnupg.org/pipermail/gnupg-devel/2014-September/028759.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From nicolas.boullis at ecp.fr Wed Sep 28 11:39:38 2016 From: nicolas.boullis at ecp.fr (Nicolas Boullis) Date: Wed, 28 Sep 2016 11:39:38 +0200 Subject: Using Scute with a 4096-bit key and TLSv1.2? In-Reply-To: References: <20160927102322.GB1692@eridan.ccs.ecp.fr> Message-ID: <20160928093938.GA2731@eridan.ccs.ecp.fr> Hi, On Tue, Sep 27, 2016 at 03:57:01PM +0200, Damien Goutte-Gattat wrote: > > At the time, I was able to make TLS 1.2 work with GnuPG 2.0.26 by > backporting commit 1c09def22d97de3738a2bec4970504bfc155680b [1]. You could > try that, but I think switching to GnuPG 2.1 would be a better solution if > possible. Thanks for your help, I did not think the problem could be with gnupg-agent. I just tried to rebuild GnuPG 2.0.26 with that patch applied, and it now seems to work fine. I will consider switching to GnuPG 2.1. The other question remains: is there any plan to release Scute 1.5 anytime soon? Cheers, -- Nicolas From wk at gnupg.org Wed Sep 28 16:08:03 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 28 Sep 2016 16:08:03 +0200 Subject: Using Scute with a 4096-bit key and TLSv1.2? In-Reply-To: <20160928093938.GA2731@eridan.ccs.ecp.fr> (Nicolas Boullis's message of "Wed, 28 Sep 2016 11:39:38 +0200") References: <20160927102322.GB1692@eridan.ccs.ecp.fr> <20160928093938.GA2731@eridan.ccs.ecp.fr> Message-ID: <878tuc15j0.fsf@wheatstone.g10code.de> On Wed, 28 Sep 2016 11:39, nicolas.boullis at ecp.fr said: > The other question remains: is there any plan to release Scute 1.5 > anytime soon? Damien: What do you think, shall I do a release? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From dgouttegattat at incenp.org Wed Sep 28 17:13:30 2016 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Wed, 28 Sep 2016 17:13:30 +0200 Subject: Using Scute with a 4096-bit key and TLSv1.2? In-Reply-To: <878tuc15j0.fsf@wheatstone.g10code.de> References: <20160927102322.GB1692@eridan.ccs.ecp.fr> <20160928093938.GA2731@eridan.ccs.ecp.fr> <878tuc15j0.fsf@wheatstone.g10code.de> Message-ID: <7ee7f7b2-9391-cf02-cdc6-6c85c06f5e40@incenp.org> On 09/28/2016 04:08 PM, Werner Koch wrote: > Damien: What do you think, shall I do a release? I think it's a good idea. The last tarball release of Scute dates back to 2010. There has not been many changes since then, but some of them are very useful. Most importantly, the support for hash functions other than the TLS-specific "tls-md5sha1" was added by Justus at the end of 2015 (commit e22c8cf). This is a very significant change, as it both allows Scute to be used with TLS 1.2, and also brings support for S/MIME mail signing. In my opinion, that change alone is worthy of a new release. Other interesting additions include support for 4096-bit keys (commit 7346eab) and a fix for a randomly occuring signing bug (commit dd7cf6c). Looking at the TODO file and the FIXMEs in the code, I don't think there is anything that would need to be done before a new release. I wanted to implement C_Decrypt, but I don't know when I will have the time to do it (possibly never, to be honest), and I don't think we have to wait for that feature. The README file and the manual are up-to-date with the recent changes. Do you want me to update the NEWS file prior to the release? Cheers, Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From alon.barlev at gmail.com Thu Sep 29 09:30:56 2016 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Thu, 29 Sep 2016 10:30:56 +0300 Subject: [gpgme PATCH 1/3] build: python: setup.py should be executable In-Reply-To: <87h993japj.fsf@europa.jade-hamburg.de> References: <87h993japj.fsf@europa.jade-hamburg.de> Message-ID: <1475134258-19457-1-git-send-email-alon.barlev@gmail.com> Signed-off-by: Alon Bar-Lev --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 4a29f2f..efa1f19 100644 --- a/configure.ac +++ b/configure.ac @@ -886,9 +886,9 @@ AC_CONFIG_FILES([lang/Makefile lang/cl/Makefile lang/cl/gpgme.asd]) AM_COND_IF([HAVE_DOXYGEN], [AC_CONFIG_FILES([lang/qt/doc/Doxyfile])]) AC_CONFIG_FILES(lang/qt/doc/Makefile) AC_CONFIG_FILES([lang/python/Makefile - lang/python/setup.py lang/python/pyme/version.py lang/python/tests/Makefile]) +AC_CONFIG_FILES([lang/python/setup.py], [chmod a+x lang/python/setup.py]) AC_OUTPUT echo " -- 2.7.3 From alon.barlev at gmail.com Thu Sep 29 09:30:57 2016 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Thu, 29 Sep 2016 10:30:57 +0300 Subject: [gpgme PATCH 2/3] build: python: add prepare target In-Reply-To: <1475134258-19457-1-git-send-email-alon.barlev@gmail.com> References: <87h993japj.fsf@europa.jade-hamburg.de> <1475134258-19457-1-git-send-email-alon.barlev@gmail.com> Message-ID: <1475134258-19457-2-git-send-email-alon.barlev@gmail.com> this enables preparing the package using autoconf then build using distutils as separate stage. Signed-off-by: Alon Bar-Lev --- lang/python/Makefile.am | 3 +++ 1 file changed, 3 insertions(+) diff --git a/lang/python/Makefile.am b/lang/python/Makefile.am index 1d7aee8..ea37da9 100644 --- a/lang/python/Makefile.am +++ b/lang/python/Makefile.am @@ -65,6 +65,9 @@ dist/pyme3-$(VERSION).tar.gz dist/pyme3-$(VERSION).tar.gz.asc: copystamp $(PYTHON) setup.py sdist --verbose gpg2 --detach-sign --armor dist/pyme3-$(VERSION).tar.gz +.PHONY: prepare +prepare: copystamp + .PHONY: sdist sdist: dist/pyme3-$(VERSION).tar.gz dist/pyme3-$(VERSION).tar.gz.asc -- 2.7.3 From alon.barlev at gmail.com Thu Sep 29 09:30:58 2016 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Thu, 29 Sep 2016 10:30:58 +0300 Subject: [gpgme PATCH 3/3] build: lang: python: move data.h, config.h to package In-Reply-To: <1475134258-19457-1-git-send-email-alon.barlev@gmail.com> References: <87h993japj.fsf@europa.jade-hamburg.de> <1475134258-19457-1-git-send-email-alon.barlev@gmail.com> Message-ID: <1475134258-19457-3-git-send-email-alon.barlev@gmail.com> to make it easy to build the subpackage using standard tools as standalone without altering environment nor CFLAGS, symlink the required artifacts from source tree into subpackage directory when preparing sources. although data.h should be put in public API, for now it is the simplest solution that may be altered in future. this is required for minimizing the chase of downstream packager to apply upstream changes. Signed-off-by: Alon Bar-Lev --- lang/python/Makefile.am | 15 ++++++++++----- lang/python/gpgme.i | 2 +- lang/python/setup.py.in | 4 ---- 3 files changed, 11 insertions(+), 10 deletions(-) diff --git a/lang/python/Makefile.am b/lang/python/Makefile.am index ea37da9..9cb99c4 100644 --- a/lang/python/Makefile.am +++ b/lang/python/Makefile.am @@ -46,22 +46,27 @@ COPY_FILES_PYME = \ # For VPATH builds we need to copy some files because Python's # distutils are not VPATH-aware. -copystamp: $(COPY_FILES) $(COPY_FILES_PYME) +copystamp: $(COPY_FILES) $(COPY_FILES_PYME) data.h config.h if test "$(srcdir)" != "$(builddir)" ; then \ cp -R $(COPY_FILES) . ; \ cp -R $(COPY_FILES_PYME) pyme ; \ fi touch $@ +data.h: + ln -s "$(top_srcdir)/src/data.h" + +config.h: + ln -s "$(top_builddir)/config.h" + all-local: copystamp for PYTHON in $(PYTHONS); do \ - CFLAGS="$(CFLAGS) -I$(top_srcdir)" \ - top_builddir="$(top_builddir)" \ + CFLAGS="$(CFLAGS)" \ $$PYTHON setup.py build --verbose ; \ done dist/pyme3-$(VERSION).tar.gz dist/pyme3-$(VERSION).tar.gz.asc: copystamp - CFLAGS="$(CFLAGS) -I$(top_srcdir)" \ + CFLAGS="$(CFLAGS)" \ $(PYTHON) setup.py sdist --verbose gpg2 --detach-sign --armor dist/pyme3-$(VERSION).tar.gz @@ -76,7 +81,7 @@ upload: dist/pyme3-$(VERSION).tar.gz dist/pyme3-$(VERSION).tar.gz.asc twine upload $^ CLEANFILES = gpgme.h errors.i gpgme_wrap.c pyme/gpgme.py \ - copystamp + data.h config.h copystamp # Remove the rest. # diff --git a/lang/python/gpgme.i b/lang/python/gpgme.i index eaeb4f8..5d074aa 100644 --- a/lang/python/gpgme.i +++ b/lang/python/gpgme.i @@ -183,7 +183,7 @@ representation of struct gpgme_data for an very efficient check if the buffer has been modified. */ %{ -#include "src/data.h" /* For struct gpgme_data. */ +#include "data.h" /* For struct gpgme_data. */ %} #endif diff --git a/lang/python/setup.py.in b/lang/python/setup.py.in index 7af2d48..4c41673 100755 --- a/lang/python/setup.py.in +++ b/lang/python/setup.py.in @@ -39,10 +39,6 @@ if os.path.exists("../../src/gpgme-config"): in_tree = True gpgme_config = ["../../src/gpgme-config"] + gpgme_config_flags gpgme_h = "../../src/gpgme.h" - if 'top_builddir' in os.environ: - include_dirs.append(os.environ['top_builddir']) - # Make sure that SWIG finds config.h when processing gpgme.i. - extra_swig_opts.append("-I{0}".format(os.environ['top_builddir'])) library_dirs = ["../../src/.libs"] # XXX uses libtool internals extra_macros.update( HAVE_CONFIG_H=1, -- 2.7.3 From wk at gnupg.org Thu Sep 29 10:30:12 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 29 Sep 2016 10:30:12 +0200 Subject: Using Scute with a 4096-bit key and TLSv1.2? In-Reply-To: <7ee7f7b2-9391-cf02-cdc6-6c85c06f5e40@incenp.org> (Damien Goutte-Gattat's message of "Wed, 28 Sep 2016 17:13:30 +0200") References: <20160927102322.GB1692@eridan.ccs.ecp.fr> <20160928093938.GA2731@eridan.ccs.ecp.fr> <878tuc15j0.fsf@wheatstone.g10code.de> <7ee7f7b2-9391-cf02-cdc6-6c85c06f5e40@incenp.org> Message-ID: <87k2dvyup7.fsf@wheatstone.g10code.de> On Wed, 28 Sep 2016 17:13, dgouttegattat at incenp.org said: > The README file and the manual are up-to-date with the recent > changes. Do you want me to update the NEWS file prior to the release? That would indeed be helpful. I will probably need to apply some updates to the build system but that is a nobrainer. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From dgouttegattat at incenp.org Thu Sep 29 11:07:31 2016 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Thu, 29 Sep 2016 11:07:31 +0200 Subject: [PATCH] Update documentation files In-Reply-To: <87k2dvyup7.fsf@wheatstone.g10code.de> References: <87k2dvyup7.fsf@wheatstone.g10code.de> Message-ID: <20160929090731.9599-1-dgouttegattat@incenp.org> Here is the patch for the updated NEWS file. I also updated again the documentation to make it clear that while the minimum required version of GnuPG is 2.0, it actually needs GnuPG 2.1 for use with TLS 1.2. Cheers, Damien -- >8 -- Subject: [PATCH] Update documentation files * NEWS: Update for upcoming release. * README: Indicate that GnuPG 2.1 is required for some features. * doc/manual/scute.texi: Likewise. Signed-off-by: Damien Goutte-Gattat --- NEWS | 15 ++++++++++++++- README | 2 ++ doc/manual/scute.texi | 4 +++- 3 files changed, 19 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index dc84747..775d497 100644 --- a/NEWS +++ b/NEWS @@ -1,4 +1,17 @@ -Noteworthy changes in version 1.3.0 (2010-04-21) +Noteworthy changes in version 1.5.0 (2016-09-29) +------------------------------------------------ + + * Support for TLS 1.2 client authentication and SMIME signing. + + * Support for 4096 bit keys. + + * C_GenerateRandom is implemented. + + * A bug that occured when Scute was used with GnuPG 2.1 has + been fixed. + + +Noteworthy changes in version 1.4.0 (2010-04-21) ------------------------------------------------ * Update to libassuan 2.0.0 interface. diff --git a/README b/README index 7064b29..b6c837b 100644 --- a/README +++ b/README @@ -42,6 +42,8 @@ At runtime: * GnuPG 2.0, in particular: gpg-agent, scdaemon * Pinentry +Note that client authentication with TLS 1.2 requires GnuPG 2.1. + Installation ============ diff --git a/doc/manual/scute.texi b/doc/manual/scute.texi index 7199edf..392cc98 100644 --- a/doc/manual/scute.texi +++ b/doc/manual/scute.texi @@ -262,7 +262,9 @@ configured: @table @asis @item GnuPG Scute uses the GnuPG 2.0 framework to access the OpenPGP card and for -certificate management. The minimum version required is 2.0.0. +certificate management. The minimum version required is 2.0.0 for +client authentication with TLS 1.0 and 1.1. Client authentication +with TLS 1.2, email and document signing require GnuPG 2.1.0. @item Pinentry Pinentry is a dependency of GnuPG 2.0, so it also needs to be installed -- 2.9.0 From alon.barlev at gmail.com Thu Sep 29 19:53:40 2016 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Thu, 29 Sep 2016 20:53:40 +0300 Subject: [gpgme][PATCH] build: tests: avoid build tests if not required In-Reply-To: <1474663083-27507-1-git-send-email-alon.barlev@gmail.com> References: <1474663083-27507-1-git-send-email-alon.barlev@gmail.com> Message-ID: Hi, Any comment? Thanks! On 23 September 2016 at 23:38, Alon Bar-Lev wrote: > test enables reducing dependencies for build if tests are not going to > run. > > Signed-off-by: Alon Bar-Lev > --- > lang/qt/tests/Makefile.am | 2 +- > tests/Makefile.am | 2 +- > tests/gpg/Makefile.am | 2 +- > tests/gpgsm/Makefile.am | 2 +- > tests/opassuan/Makefile.am | 2 +- > 5 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/lang/qt/tests/Makefile.am b/lang/qt/tests/Makefile.am > index f243a55..c40d75d 100644 > --- a/lang/qt/tests/Makefile.am > +++ b/lang/qt/tests/Makefile.am > @@ -62,7 +62,7 @@ nodist_t_keylist_SOURCES = $(moc_files) > > BUILT_SOURCES = $(moc_files) > > -noinst_PROGRAMS = t-keylist t-keylocate t-ownertrust t-tofuinfo t-encrypt > \ > +check_PROGRAMS = t-keylist t-keylocate t-ownertrust t-tofuinfo t-encrypt \ > run-keyformailboxjob t-wkspublish > > CLEANFILES = secring.gpg pubring.gpg pubring.kbx trustdb.gpg dirmngr.conf > \ > diff --git a/tests/Makefile.am b/tests/Makefile.am > index c71914f..b698e11 100644 > --- a/tests/Makefile.am > +++ b/tests/Makefile.am > @@ -31,7 +31,7 @@ LDADD = ../src/libgpgme.la @GPG_ERROR_LIBS@ > > noinst_HEADERS = run-support.h > > -noinst_PROGRAMS = $(TESTS) run-keylist run-export run-import run-sign \ > +check_PROGRAMS = $(TESTS) run-keylist run-export run-import run-sign \ > run-verify run-encrypt run-identify run-decrypt > run-genkey \ > run-keysign run-tofu > > diff --git a/tests/gpg/Makefile.am b/tests/gpg/Makefile.am > index 2538f63..807ca5c 100644 > --- a/tests/gpg/Makefile.am > +++ b/tests/gpg/Makefile.am > @@ -71,7 +71,7 @@ if !HAVE_W32_SYSTEM > tests_skipped += t-cancel > endif > > -noinst_PROGRAMS = $(c_tests) $(tests_skipped) > +check_PROGRAMS = $(c_tests) $(tests_skipped) > > > clean-local: > diff --git a/tests/gpgsm/Makefile.am b/tests/gpgsm/Makefile.am > index 41645b6..1bdb712 100644 > --- a/tests/gpgsm/Makefile.am > +++ b/tests/gpgsm/Makefile.am > @@ -40,7 +40,7 @@ LDADD = ../../src/libgpgme.la > > # We don't run t-genkey in the test suite, because it takes too long > # and needs a working pinentry. > -noinst_PROGRAMS = $(c_tests) t-genkey cms-keylist cms-decrypt > +check_PROGRAMS = $(c_tests) t-genkey cms-keylist cms-decrypt > > key_id = 32100C27173EF6E9C4E9A25D3D69F86D37A4F939 > > diff --git a/tests/opassuan/Makefile.am b/tests/opassuan/Makefile.am > index 31d26ed..608b608 100644 > --- a/tests/opassuan/Makefile.am > +++ b/tests/opassuan/Makefile.am > @@ -27,7 +27,7 @@ EXTRA_DIST = > AM_CPPFLAGS = -I$(top_builddir)/src @GPG_ERROR_CFLAGS@ > LDADD = ../../src/libgpgme.la > > -noinst_PROGRAMS = $(TESTS) t-command > +check_PROGRAMS = $(TESTS) t-command > > DISTCLEANFILES = > > -- > 2.7.3 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aheinecke at intevation.de Fri Sep 30 00:27:45 2016 From: aheinecke at intevation.de (Andre Heinecke) Date: Fri, 30 Sep 2016 00:27:45 +0200 Subject: [gpgme][PATCH] build: tests: avoid build tests if not required In-Reply-To: References: <1474663083-27507-1-git-send-email-alon.barlev@gmail.com> Message-ID: <16602284.AMWrtJmBGa@esus> Hi, On Thursday 29 September 2016 20:53:40 Alon Bar-Lev wrote: > Hi, > Any comment? Werner: I think thats a question for you. For the Qt test I think this patch is acceptable but as the patch is global for all the tests you should decide. Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: This is a digitally signed message part. URL: From justus at g10code.com Fri Sep 30 14:29:25 2016 From: justus at g10code.com (Justus Winter) Date: Fri, 30 Sep 2016 14:29:25 +0200 Subject: [gpgme][PATCH] build: tests: avoid build tests if not required In-Reply-To: <16602284.AMWrtJmBGa@esus> References: <1474663083-27507-1-git-send-email-alon.barlev@gmail.com> <16602284.AMWrtJmBGa@esus> Message-ID: <87lgy9h8pm.fsf@europa.jade-hamburg.de> Andre Heinecke writes: > [ Unknown signature status ] > Hi, > > On Thursday 29 September 2016 20:53:40 Alon Bar-Lev wrote: >> Hi, >> Any comment? > > Werner: I think thats a question for you. For the Qt test I think this patch > is acceptable but as the patch is global for all the tests you should decide. I know Werner shot down a similar patch for GnuPG, arguing that 'make' is run more often than 'make check'. I agree with the proposed change, but not with the motivation. Does that mean that on Gentoo the test are not being executed when building packages!? Cheers, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From alon.barlev at gmail.com Fri Sep 30 14:42:13 2016 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Fri, 30 Sep 2016 15:42:13 +0300 Subject: [gpgme][PATCH] build: tests: avoid build tests if not required In-Reply-To: <87lgy9h8pm.fsf@europa.jade-hamburg.de> References: <1474663083-27507-1-git-send-email-alon.barlev@gmail.com> <16602284.AMWrtJmBGa@esus> <87lgy9h8pm.fsf@europa.jade-hamburg.de> Message-ID: On 30 September 2016 at 15:29, Justus Winter wrote: > > Andre Heinecke writes: > > > [ Unknown signature status ] > > Hi, > > > > On Thursday 29 September 2016 20:53:40 Alon Bar-Lev wrote: > >> Hi, > >> Any comment? > > > > Werner: I think thats a question for you. For the Qt test I think this patch > > is acceptable but as the patch is global for all the tests you should decide. > > I know Werner shot down a similar patch for GnuPG, arguing that 'make' > is run more often than 'make check'. > > I agree with the proposed change, but not with the motivation. Does > that mean that on Gentoo the test are not being executed when building > packages!? Your question is actually: Does that means that on "Automake" the test are not being executed when build packages (aka make all)? It has nothing to do with Gentoo... Executing tests is optional in Automake, Gentoo and manual sequence as there is no point of introducing additional dependencies and run additional builds if tests are not to run. Exactly because of this check_PROGRAMS exists and should be used for targets that are used for check target. Thanks, Alon From wk at gnupg.org Fri Sep 30 15:54:05 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 30 Sep 2016 15:54:05 +0200 Subject: [gpgme][PATCH] build: tests: avoid build tests if not required In-Reply-To: <1474663083-27507-1-git-send-email-alon.barlev@gmail.com> (Alon Bar-Lev's message of "Fri, 23 Sep 2016 23:38:03 +0300") References: <1474663083-27507-1-git-send-email-alon.barlev@gmail.com> Message-ID: <87r381v6gy.fsf@wheatstone.g10code.de> On Fri, 23 Sep 2016 22:38, alon.barlev at gmail.com said: > test enables reducing dependencies for build if tests are not going to > run. Not being able to build tests can be a sign that something with the build system is wrong. Thus I do not understand why you do not want to build them. I have never used check_ and do not user whether this has the same properties as noinst_. In particular, noinst_ is used to get rid of the wrappers for easier debugging and for testing on Windows. BTW, the commit log should be in the form described by gnupg/doc/HACKING. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From justus at g10code.com Fri Sep 30 16:06:33 2016 From: justus at g10code.com (Justus Winter) Date: Fri, 30 Sep 2016 16:06:33 +0200 Subject: [gpgme PATCH 1/3] build: python: setup.py should be executable In-Reply-To: <1475134258-19457-1-git-send-email-alon.barlev@gmail.com> References: <87h993japj.fsf@europa.jade-hamburg.de> <1475134258-19457-1-git-send-email-alon.barlev@gmail.com> Message-ID: <87fuohh47q.fsf@europa.jade-hamburg.de> Alon Bar-Lev writes: > Signed-off-by: Alon Bar-Lev > --- > configure.ac | 2 +- Thanks, I merged all the patches. I did, however, amend the commit messages. Please at least make a habbit of looking how other commit messages look like and try to make yours blend in. Better yet, try to find documentation on how the commit message should look like. For the GnuPG project, that documentation is in the gnupg repository, doc/HACKING. Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From wk at gnupg.org Fri Sep 30 16:04:40 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 30 Sep 2016 16:04:40 +0200 Subject: [gpgme] 1.7 build experience and issues In-Reply-To: (Alon Bar-Lev's message of "Sat, 24 Sep 2016 02:51:12 +0300") References: Message-ID: <87mvipv5zb.fsf@wheatstone.g10code.de> On Sat, 24 Sep 2016 01:51, alon.barlev at gmail.com said: > BTW: Any reason these are checked into git? > These are auto generated. That is so that all developers use the same macros and scripts for development and bug fixing. They are only updated by the maintainer and these updates are thus tracked in the repo. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From wk at gnupg.org Fri Sep 30 16:26:21 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 30 Sep 2016 16:26:21 +0200 Subject: [gpgme PATCH 1/3] build: python: setup.py should be executable In-Reply-To: <87fuohh47q.fsf@europa.jade-hamburg.de> (Justus Winter's message of "Fri, 30 Sep 2016 16:06:33 +0200") References: <87h993japj.fsf@europa.jade-hamburg.de> <1475134258-19457-1-git-send-email-alon.barlev@gmail.com> <87fuohh47q.fsf@europa.jade-hamburg.de> Message-ID: <874m4xv4z6.fsf@wheatstone.g10code.de> On Fri, 30 Sep 2016 16:06, justus at g10code.com said: > GnuPG project, that documentation is in the gnupg repository, > doc/HACKING. also found https://gnupg.org/faq/HACKING.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: 162 bytes Desc: not available URL: From alon.barlev at gmail.com Fri Sep 30 19:45:46 2016 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Fri, 30 Sep 2016 20:45:46 +0300 Subject: [gpgme] 1.7 build experience and issues In-Reply-To: <87mvipv5zb.fsf@wheatstone.g10code.de> References: <87mvipv5zb.fsf@wheatstone.g10code.de> Message-ID: On 30 September 2016 at 17:04, Werner Koch wrote: > On Sat, 24 Sep 2016 01:51, alon.barlev at gmail.com said: >> BTW: Any reason these are checked into git? >> These are auto generated. > > That is so that all developers use the same macros and scripts for > development and bug fixing. They are only updated by the maintainer and > these updates are thus tracked in the repo. OK, thanks. From alon.barlev at gmail.com Fri Sep 30 19:49:55 2016 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Fri, 30 Sep 2016 20:49:55 +0300 Subject: [gpgme][PATCH] build: tests: avoid build tests if not required In-Reply-To: <1781245.FIDAXHxsJN@esus> References: <1474663083-27507-1-git-send-email-alon.barlev@gmail.com> <87r381v6gy.fsf@wheatstone.g10code.de> <1781245.FIDAXHxsJN@esus> Message-ID: On 30 September 2016 at 19:36, Andre Heinecke wrote: > Hi, > > On Friday 30 September 2016 15:54:05 Werner Koch wrote: >> On Fri, 23 Sep 2016 22:38, alon.barlev at gmail.com said: >> > test enables reducing dependencies for build if tests are not going to >> > run. > > Mmh reducing dependencies I might be responsible for this. Is this because the > Qt Testsuite additionally requires QTest? > > In that case I think it might be a better fix to build the Qt tests only if > QTest is available. Would this work for you? Yes. However, autodetect is worse than just not build. As if you ignore and run "make check" then nothing will run although it should. So far I patched it to avoid users require QTest if no tests are to be executed. I will follow whatever decision you may have, including forcing QTest for users unconditionally, but I thought you have done this by mistake. Thanks. From alon.barlev at gmail.com Fri Sep 30 19:56:44 2016 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Fri, 30 Sep 2016 20:56:44 +0300 Subject: [gpgme PATCH 1/3] build: python: setup.py should be executable In-Reply-To: <874m4xv4z6.fsf@wheatstone.g10code.de> References: <87h993japj.fsf@europa.jade-hamburg.de> <1475134258-19457-1-git-send-email-alon.barlev@gmail.com> <87fuohh47q.fsf@europa.jade-hamburg.de> <874m4xv4z6.fsf@wheatstone.g10code.de> Message-ID: On 30 September 2016 at 17:26, Werner Koch wrote: > On Fri, 30 Sep 2016 16:06, justus at g10code.com said: > >> GnuPG project, that documentation is in the gnupg repository, >> doc/HACKING. > > also found https://gnupg.org/faq/HACKING.html > Guys, there is nothing wrong in you bit helping to perfect the work to the exact method you like to have it for random contributions. The important process is to understand the issue, agree on the solution and provide close enough implementation. Yes, a quick note from you and I would have fixed that as well, I waited first to see if there are any farther comments about the method I introduced.