From dbaryshkov at gmail.com Mon Sep 1 03:14:56 2014 From: dbaryshkov at gmail.com (Dmitry Eremin-Solenikov) Date: Mon, 1 Sep 2014 05:14:56 +0400 Subject: NSS 3.16 incompatibility In-Reply-To: <5403041D.60908@gmx.com> References: <53389593.80602@gmx.com> <5403041D.60908@gmx.com> Message-ID: Hello, On Sun, Aug 31, 2014 at 3:16 PM, Ed Finnerty wrote: > I see that there's been no reply to this issue at all, either here or on > the NSS bug tracker site: > https://bugzilla.mozilla.org/show_bug.cgi?id=990958 > > Should I assume that compatibility with NSS is not a goal at all for gpgsm? I checked your scenario. It looks like it is a bug in the NSS, not in gpgsm. openssl smime can correctly parse and decode the messages which cause cmsutil to return an error. > > On 03/31/14 01:07, Ed Finnerty wrote: >> Hello, >> >> Running this script: >> >> #!/bin/sh >> >> # Create an input file with random content >> dd if=/dev/urandom of=input.bin bs=1K count=1 >> >> # Loop forever >> while : ; do >> >> # Cleanup previous output >> rm -f out.bin >> >> # Encrypt input, write to out.bin >> gpgsm -e -r email at address input.bin 2>/dev/null > out.bin >> >> # Decrypt with cmsutil >> cmsutil -D -d ~/.thunderbird/yourprofile.default -i out.bin -v -n >> >> # If cmsutil, break out of the loop >> if [[ $? != 0 ]] ; then >> echo "GOTCHA" >> break >> fi >> >> done # While loop done >> >> Will eventually produce this output: >> >> NSS has been initialized. >> Got default certdb >> cmsutil: failed to decode message. >> cmsutil: problem decoding: SEC_ERROR_BAD_DATABASE: security library: bad >> database. >> GOTCHA >> >> Here's more info: >> >> $ gpgsm --version >> gpgsm (GnuPG) 2.0.22 >> libgcrypt 1.5.3 >> libksba 1.3.0 >> Copyright (C) 2013 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: ~/.gnupg >> Supported algorithms: >> Cipher: 3DES, AES, AES192, AES256, SERPENT128, SERPENT192, SERPENT256, >> SEED, CAMELLIA128, CAMELLIA192, CAMELLIA256 >> Pubkey: RSA, ECDSA >> Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224, WHIRLPOOL >> >> I'm using NSS 3.16. >> >> Obviously, you need to have the proper certificates imported with gpgsm, >> certutil, etc. >> >> What's happening? >> >> Thanks. > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel -- With best wishes Dmitry From wk at gnupg.org Mon Sep 1 10:07:35 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 01 Sep 2014 10:07:35 +0200 Subject: [Announce] GPA 0.9.5 released Message-ID: <87tx4rpxvc.fsf@vigenere.g10code.de> Hello! I am pleased to announce GPA version 0.9.5. GPA is a graphical frontend for the GNU Privacy Guard (GnuPG). GPA can be used for most operations supported by GnuPG using either the OpenPGP or the S/MIME protocols. A smartcard manager and a generic user interface server features are included as well. You can find the release here: ftp://ftp.gnupg.org/gcrypt/gpa/gpa-0.9.5.tar.bz2 (716k) ftp://ftp.gnupg.org/gcrypt/gpa/gpa-0.9.5.tar.bz2.sig and soon on all ftp.gnupg.org mirrors. A binary version for Windows is currently not planned. The SHA1 checksum for this release is: ea53b934a7f5dd4e2dfb35dac2b35cafc7b54c90 gpa-0.9.5.tar.bz2 Noteworthy changes in version 0.9.5 ----------------------------------- * GPA now starts with the UI server enabled and tests on startup whether such a server is already running to open that one instead of launching a second instance. * GPA is now aware of ECC keys. * Improved detection of CMS objects (which are used by S/MIME) and detached OpenPGP signatures. * Allow import and export of X.509 certificates. Allow backup of X.509 keys. * The key creation date is now displayed in the key listing. * Armored detached signature files are now created with an ".asc" suffix and not with ".sig". * The GnuPG home directory is now detected using the gpgconf tool. * Added launch-gpa wrapper for Windows. * Fixed several bugs leading to crashs. If you want to contribute to the development of GPA, please subscribe to the gnupg-devel mailing list [1] and read the file doc/HACKING. The driving force behind the development of GPA is my company g10 Code. Maintenance and improvement of GnuPG and related software, such as GPA, takes up most of our resources. To allow us to continue our work on free software, we ask to either purchase a support contract, engage us for custom enhancements, or to donate money: https://gnupg.org/donate/ Many thanks to all who contributed to GPA development, be it bug fixes, code, documentation, testing, and helping users. Shalom-Salam, Werner [1] See http://www.gnupg.org/documentation/mailing-lists.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: 180 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From simon at josefsson.org Mon Sep 1 22:47:24 2014 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 01 Sep 2014 22:47:24 +0200 Subject: Should I mark/announce GNOME as incompatible with gpg2 for now? In-Reply-To: <53FF3D4A.9050005@fsij.org> (NIIBE Yutaka's message of "Thu, 28 Aug 2014 23:31:38 +0900") References: <53FF0869.8090201@thewalter.net> <53FF3D4A.9050005@fsij.org> Message-ID: <87ha0rvzj7.fsf@latte.josefsson.org> NIIBE Yutaka writes: > However, how to disable the features of gpg-agent/ssh-agent for > gnome-keyring has been changed in version to version. I had figured > out how to do that in GNOME2 and in younger GNOME 3, but now, I don't > know how we can disable the features in GNOME 3.12 or later (using > proper gpg-agent). mkdir ~/.config/autostart/ cp /etc/xdg/autostart/gnome-keyring-gpg.desktop ~/.config/autostart/ echo 'Hidden=true' >> ~/.config/autostart/gnome-keyring-gpg.desktop As far as I know, there is no GUI to do this in modern GNOME. It used to be possible through gnome-session-properties, but there is no way to do the same with gnome-tweak-tool. /Simon From simon at josefsson.org Tue Sep 2 09:51:10 2014 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 02 Sep 2014 09:51:10 +0200 Subject: OpenPGP Card ECC status? Message-ID: <87lhq2qx3l.fsf@latte.josefsson.org> Hi. What's the status of support for OpenPGP cards with ECC in GnuPG? Is there a recommended GnuPG version to test with? Does on-board key generation work? Key import? We are happy to add support for ECC on the hardware side in the YubiKey NEO applet [1]. I have been under the impression that the GnuPG side of things haven't been ready, but I'm happy if this is no longer the case. /Simon [1] https://github.com/Yubico/ykneo-openpgp -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 489 bytes Desc: not available URL: From achim at pietig.com Tue Sep 2 11:49:38 2014 From: achim at pietig.com (Achim Pietig) Date: Tue, 02 Sep 2014 11:49:38 +0200 Subject: OpenPGP Card ECC status? In-Reply-To: <87lhq2qx3l.fsf@latte.josefsson.org> References: <87lhq2qx3l.fsf@latte.josefsson.org> Message-ID: <540592B2.5090207@pietig.com> Hi Simon, there was a little henn-egg problem with the card specification in the past. I published a beta version with ECC (partly) last year, but the related standards (ISO 7816-x) were not finished. As in the past I plan to be as close as possible to international smart card standards because all somming products will follow them and there is no chance to get proprietary functions/algorithms in cards on the market. Most important for future cards will be EN 419212 (Application Interface for smart cards used as Secure Signature Creation Devices), that replaces the discarded EN 14890, that I used in previous versions of the OpenPGP card spec. This standard is ready now and I plan to finalize the OpenPGP card spec soon. I still need some help from Werner for defining the dec-command, because this requires a special usage of ECC. sign and auth is clear at the moment - all new standards only support Brainpool, NIST was stripped of from all papers after the NSA problem last year. Key import for ECC is also described in new ISO 7816-8 (not ready, but stable enough for usage). After finishing the spec we can do test implementations and after that GnuPG can be finished in that direction. Best regards Achim Am 02.09.2014 um 09:51 schrieb Simon Josefsson: > Hi. What's the status of support for OpenPGP cards with ECC in GnuPG? > Is there a recommended GnuPG version to test with? Does on-board key > generation work? Key import? We are happy to add support for ECC on > the hardware side in the YubiKey NEO applet [1]. I have been under the > impression that the GnuPG side of things haven't been ready, but I'm > happy if this is no longer the case. > > /Simon > > [1] https://github.com/Yubico/ykneo-openpgp > > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > From wk at gnupg.org Tue Sep 2 12:12:17 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Sep 2014 12:12:17 +0200 Subject: ECC Key export incorrectly produces 0-sized output for secret part of key. In-Reply-To: (Kyle Butt's message of "Thu, 28 Aug 2014 16:23:31 -0700") References: Message-ID: <87ppfel4am.fsf@vigenere.g10code.de> On Fri, 29 Aug 2014 01:23, kylebutt at gmail.com said: > As far as I can tell, the agent produces s-expressions where the public and > private key values are opaque, and then gcry_mpi_aprint prints an empty > value inside of apply_protection in agent/cvt-openpgp.c (There's a complete > backtrace at the end.) > > I'd go further, but I'm unsure which is wrong, the opaqueness, or the > conversion routine. Actually the entire export and import of ECC was messed up. If you pull from the wk/test-gpgrt-estream branch, your problem is hopefully fixed. This branch also includes a patch to allow AES-256 for key protection. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dgouttegattat at incenp.org Tue Sep 2 14:17:40 2014 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Tue, 02 Sep 2014 14:17:40 +0200 Subject: Patches gpg-agent + scute for ssl/tls auth using opengpg card with 2048 rsa key In-Reply-To: <1661443.XlFuGbBlzz@gamix64> References: <1661443.XlFuGbBlzz@gamix64> Message-ID: <5405B564.5090709@incenp.org> Hello, > The two patches below against gpg-agent (gnupg2-2.0.26) [1] and > scute-1.4.0 [2] allow ssl/tls auth using an opengpg card with 2048 > rsa key. First of all, your patches work for me and I thank you for that, I was struggling to make Scute work with a recent Firefox. But, are you sure this has anything to do with the size of the RSA key? It seems that the problem you are addressing is rather caused by a change between TLS 1.1 (or less) and TLS 1.2. Indeed, disabling TLS 1.2 in Firefox (by setting the variable security.tls.version.max to "2" instead of "3" in about:config) is enough to make Scute work for me, even with a 2048-bit RSA key and even without your patches. According to a bug report in Mozilla?s NSS library [1], the change introduced by TLS 1.2 is that the data to be signed is no longer a "MD5+SHA1 hash" (36 bytes, which is the length expected by GPG-Agent), but is instead an ASN.1 structure representing a DigestInfo object (35 or 51 bytes total, depending on the hash used). Damien [1] https://bugzilla.mozilla.org/show_bug.cgi?id=970913#c8 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Tue Sep 2 15:43:20 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 2 Sep 2014 09:43:20 -0400 Subject: [PATCH] Typo fix for gpg.texi Message-ID: <1409665400-14603-1-git-send-email-dkg@fifthhorseman.net> Originally reported by Jakub Wilk in https://bugs.debian.org/760273 --- doc/gpg.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/gpg.texi b/doc/gpg.texi index 7ac1613..e9bcff3 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -3509,7 +3509,7 @@ sense. Although OpenPGP works with time intervals, GnuPG uses an absolute value internally and thus the last year we can represent is 2105. - at item Ceation-Date: @var{iso-date} + at item Creation-Date: @var{iso-date} Set the creation date of the key as stored in the key information and which is also part of the fingerprint calculation. Either a date like "1986-04-26" or a full timestamp like "19860426T042640" may be used. -- 2.1.0 From lechten at wi.uni-muenster.de Tue Sep 2 16:40:01 2014 From: lechten at wi.uni-muenster.de (Jens Lechtenboerger) Date: Tue, 02 Sep 2014 16:40:01 +0200 Subject: Problems with gpgsm/dirmngr in gnupg-2.1.0-beta751 In-Reply-To: <87oavze49q.fsf@vigenere.g10code.de> (Werner Koch's message of "Tue, 5 Aug 2014 10:20:49 +0200") References: <87zjgjpx3e.fsf@pcwi7557.uni-muenster.de> <201407311026.47586.bernhard@intevation.de> <87oavze49q.fsf@vigenere.g10code.de> Message-ID: <87a96icchq.fsf@pcwi7557.uni-muenster.de> On 2014-08-05, Werner Koch wrote: > On Thu, 31 Jul 2014 10:26, bernhard at intevation.de said: > >> In our setups we prefer to run dirmnger as a system service, >> you could try this variant and see if you get further. > > This changed with 2.1. Dirmngr has been changed to be a proper part of > GnuPG and it is started on demand by gpg or gpgsm. > > The LDAP code of the new dirmngr has not been well tested, though. The problem still persists with beta783, and is actually in the HTTP code: crl_fetch calls http_open_document with NULL as session, which in turn calls http_open. If I understand correctly, session is only useful for HTTPS connections, while the attempt to download the CRL is via HTTP. Thus, session should not be accessed at all. However, http_open calls http_session_ref, dereferencing the NULL session. A quick fix is to add a NULL check to http_session_ref. A better solution might be to use session only for HTTPS connections. (Actually, no HTTP open should work right now, unless it is passed a bogus session.) Best wishes Jens From coruus at gmail.com Tue Sep 2 15:42:58 2014 From: coruus at gmail.com (David Leon Gil) Date: Tue, 2 Sep 2014 09:42:58 -0400 Subject: Patches to fix undefined behavior Message-ID: These patches are against 1.4.18. 1&2/3: Correct undefined behavior due to failure to cast type-promoted values to unsigned int before left-shifting. This fixes a number of irritating errors when running GPG built with UBSan. For example, when running './g10/gpg --list-packets checks/plain-1-pgp.asc': des.c:479:3: runtime error: left shift of 242 by 24 places cannot be represented in type 'int' des.c:479:3: runtime error: left shift of 246 by 24 places cannot be represented in type 'int' des.c:695:3: runtime error: left shift of 254 by 24 places cannot be represented in type 'int' des.c:695:3: runtime error: left shift of 182 by 24 places cannot be represented in type 'int' gpg: armor header: Version: GnuPG v1.3.5-cvs (GNU/Linux) parse-packet.c:100:31: runtime error: left shift of 203 by 24 places cannot be represented in type 'int' :pubkey enc packet: version 3, algo 16, keyid 5B7A02F0CB879DE9 data: [765 bits] data: [766 bits] gpg: public key is 0x5B7A02F0CB879DE9 keyid.c:303:22: runtime error: left shift of 131 by 24 places cannot be represented in type 'int' keyid.c:304:22: runtime error: left shift of 209 by 24 places cannot be represented in type 'int' :encrypted data packet: length: unknown keyid.c:357:22: runtime error: left shift of 131 by 24 places cannot be represented in type 'int' keyid.c:358:22: runtime error: left shift of 209 by 24 places cannot be represented in type 'int' gpg: encrypted with ELG-E key, ID 0x5B7A02F0CB879DE9 gpg: decryption failed: secret key not available 3/3: Correct undefined behavior due to dereferencing a null pointer in util/secmem.c. Note: It is unclear what the code in util/secmem.c that dereferences a null pointer is intended to calculate. All tests pass with the replacement code here, but... - David >From e8e3f460b5ecf88eda4546cf1b74a7fb1f4c6038 Mon Sep 17 00:00:00 2001 From: David Leon Gil Date: Tue, 2 Sep 2014 09:29:20 -0400 Subject: [PATCH 1/3] Fix undefined behavior in g10/ and util/ due to failure to properly cast type-promoted integers. This patch was generated by applying the following Cocci spatch; all patch-points have been manually checked for correctness. @@ expression x; @@ - x << 24 + (unsigned int)(x) << 24 --- g10/apdu.c | 20 ++++++++++---------- g10/app-openpgp.c | 2 +- g10/build-packet.c | 2 +- g10/ccid-driver.c | 2 +- g10/keygen.c | 4 ++-- g10/keyid.c | 20 ++++++++++---------- g10/misc.c | 2 +- g10/parse-packet.c | 8 ++++---- util/iobuf.c | 2 +- util/simple-gettext.c | 2 +- 10 files changed, 32 insertions(+), 32 deletions(-) diff --git a/g10/apdu.c b/g10/apdu.c index 66cf30b..b154235 100644 --- a/g10/apdu.c +++ b/g10/apdu.c @@ -916,14 +916,14 @@ pcsc_get_status_wrapped (int slot, unsigned int *status) i? strerror (errno) : "premature EOF"); goto command_failed; } - len = (msgbuf[1] << 24) | (msgbuf[2] << 16) | (msgbuf[3] << 8 ) | msgbuf[4]; + len = ((unsigned int)(msgbuf[1]) << 24) | (msgbuf[2] << 16) | (msgbuf[3] << 8 ) | msgbuf[4]; if (msgbuf[0] != 0x81 || len < 4) { log_error ("invalid response header from PC/SC received\n"); goto command_failed; } len -= 4; /* Already read the error code. */ - err = PCSC_ERR_MASK ((msgbuf[5] << 24) | (msgbuf[6] << 16) + err = PCSC_ERR_MASK (((unsigned int)(msgbuf[5]) << 24) | (msgbuf[6] << 16) | (msgbuf[7] << 8 ) | msgbuf[8]); if (err) { @@ -1084,14 +1084,14 @@ pcsc_send_apdu_wrapped (int slot, unsigned char *apdu, size_t apdulen, i? strerror (errno) : "premature EOF"); goto command_failed; } - len = (msgbuf[1] << 24) | (msgbuf[2] << 16) | (msgbuf[3] << 8 ) | msgbuf[4]; + len = ((unsigned int)(msgbuf[1]) << 24) | (msgbuf[2] << 16) | (msgbuf[3] << 8 ) | msgbuf[4]; if (msgbuf[0] != 0x81 || len < 4) { log_error ("invalid response header from PC/SC received\n"); goto command_failed; } len -= 4; /* Already read the error code. */ - err = PCSC_ERR_MASK ((msgbuf[5] << 24) | (msgbuf[6] << 16) + err = PCSC_ERR_MASK (((unsigned int)(msgbuf[5]) << 24) | (msgbuf[6] << 16) | (msgbuf[7] << 8 ) | msgbuf[8]); if (err) { @@ -1217,14 +1217,14 @@ close_pcsc_reader_wrapped (int slot) i? strerror (errno) : "premature EOF"); goto command_failed; } - len = (msgbuf[1] << 24) | (msgbuf[2] << 16) | (msgbuf[3] << 8 ) | msgbuf[4]; + len = ((unsigned int)(msgbuf[1]) << 24) | (msgbuf[2] << 16) | (msgbuf[3] << 8 ) | msgbuf[4]; if (msgbuf[0] != 0x81 || len < 4) { log_error ("invalid response header from PC/SC received\n"); goto command_failed; } len -= 4; /* Already read the error code. */ - err = PCSC_ERR_MASK ((msgbuf[5] << 24) | (msgbuf[6] << 16) + err = PCSC_ERR_MASK (((unsigned int)(msgbuf[5]) << 24) | (msgbuf[6] << 16) | (msgbuf[7] << 8 ) | msgbuf[8]); if (err) log_error ("pcsc_close failed: %s (0x%lx)\n", @@ -1405,7 +1405,7 @@ reset_pcsc_reader_wrapped (int slot) i? strerror (errno) : "premature EOF"); goto command_failed; } - len = (msgbuf[1] << 24) | (msgbuf[2] << 16) | (msgbuf[3] << 8 ) | msgbuf[4]; + len = ((unsigned int)(msgbuf[1]) << 24) | (msgbuf[2] << 16) | (msgbuf[3] << 8 ) | msgbuf[4]; if (msgbuf[0] != 0x81 || len < 4) { log_error ("invalid response header from PC/SC received\n"); @@ -1419,7 +1419,7 @@ reset_pcsc_reader_wrapped (int slot) sw = SW_HOST_GENERAL_ERROR; goto command_failed; } - err = PCSC_ERR_MASK ((msgbuf[5] << 24) | (msgbuf[6] << 16) + err = PCSC_ERR_MASK (((unsigned int)(msgbuf[5]) << 24) | (msgbuf[6] << 16) | (msgbuf[7] << 8 ) | msgbuf[8]); if (err) { @@ -1719,7 +1719,7 @@ open_pcsc_reader_wrapped (const char *portstr) i? strerror (errno) : "premature EOF"); goto command_failed; } - len = (msgbuf[1] << 24) | (msgbuf[2] << 16) | (msgbuf[3] << 8 ) | msgbuf[4]; + len = ((unsigned int)(msgbuf[1]) << 24) | (msgbuf[2] << 16) | (msgbuf[3] << 8 ) | msgbuf[4]; if (msgbuf[0] != 0x81 || len < 4) { log_error ("invalid response header from PC/SC received\n"); @@ -1732,7 +1732,7 @@ open_pcsc_reader_wrapped (const char *portstr) (unsigned long)len); goto command_failed; } - err = PCSC_ERR_MASK ((msgbuf[5] << 24) | (msgbuf[6] << 16) + err = PCSC_ERR_MASK (((unsigned int)(msgbuf[5]) << 24) | (msgbuf[6] << 16) | (msgbuf[7] << 8 ) | msgbuf[8]); if (err) { diff --git a/g10/app-openpgp.c b/g10/app-openpgp.c index a3a977b..5e03f8d 100644 --- a/g10/app-openpgp.c +++ b/g10/app-openpgp.c @@ -744,7 +744,7 @@ send_fprtime_if_not_null (ctrl_t ctrl, const char *keyword, char numbuf1[50], numbuf2[50]; unsigned long value; - value = (stamp[0] << 24) | (stamp[1]<<16) | (stamp[2]<<8) | stamp[3]; + value = ((unsigned int)(stamp[0]) << 24) | (stamp[1]<<16) | (stamp[2]<<8) | stamp[3]; if (!value) return; sprintf (numbuf1, "%d", number); diff --git a/g10/build-packet.c b/g10/build-packet.c index abe0181..9b93ff6 100644 --- a/g10/build-packet.c +++ b/g10/build-packet.c @@ -585,7 +585,7 @@ delete_sig_subpkt (subpktarea_t *area, sigsubpkttype_t reqtype ) if( n == 255 ) { if( buflen < 4 ) break; - n = (buffer[0] << 24) | (buffer[1] << 16) + n = ((unsigned int)(buffer[0]) << 24) | (buffer[1] << 16) | (buffer[2] << 8) | buffer[3]; buffer += 4; buflen -= 4; diff --git a/g10/ccid-driver.c b/g10/ccid-driver.c index 8c362d7..07037c7 100644 --- a/g10/ccid-driver.c +++ b/g10/ccid-driver.c @@ -292,7 +292,7 @@ static int abort_cmd (ccid_driver_t handle, int seqno); static unsigned int convert_le_u32 (const unsigned char *buf) { - return buf[0] | (buf[1] << 8) | (buf[2] << 16) | (buf[3] << 24); + return buf[0] | (buf[1] << 8) | (buf[2] << 16) | ((unsigned int)(buf[3]) << 24); } diff --git a/g10/keygen.c b/g10/keygen.c index 84f852f..23d80a3 100644 --- a/g10/keygen.c +++ b/g10/keygen.c @@ -832,7 +832,7 @@ make_backsig (PKT_signature *sig, PKT_public_key *pk, } else if(buf[1]==255) { - pktlen =buf[2] << 24; + pktlen =(unsigned int)(buf[2]) << 24; pktlen|=buf[3] << 16; pktlen|=buf[4] << 8; pktlen|=buf[5]; @@ -852,7 +852,7 @@ make_backsig (PKT_signature *sig, PKT_public_key *pk, break; case 2: - pktlen =buf[mark++] << 24; + pktlen =(unsigned int)(buf[mark++]) << 24; pktlen|=buf[mark++] << 16; case 1: diff --git a/g10/keyid.c b/g10/keyid.c index d7072d4..cf0725f 100644 --- a/g10/keyid.c +++ b/g10/keyid.c @@ -241,11 +241,11 @@ keystr_from_desc(KEYDB_SEARCH_DESC *desc) { u32 keyid[2]; - keyid[0] = (unsigned char)desc->u.fpr[12] << 24 + keyid[0] = (unsigned int)((unsigned char)desc->u.fpr[12]) << 24 | (unsigned char)desc->u.fpr[13] << 16 | (unsigned char)desc->u.fpr[14] << 8 | (unsigned char)desc->u.fpr[15] ; - keyid[1] = (unsigned char)desc->u.fpr[16] << 24 + keyid[1] = (unsigned int)((unsigned char)desc->u.fpr[16]) << 24 | (unsigned char)desc->u.fpr[17] << 16 | (unsigned char)desc->u.fpr[18] << 8 | (unsigned char)desc->u.fpr[19] ; @@ -300,8 +300,8 @@ keyid_from_sk( PKT_secret_key *sk, u32 *keyid ) if(md) { dp = md_read( md, 0 ); - keyid[0] = dp[12] << 24 | dp[13] << 16 | dp[14] << 8 | dp[15] ; - keyid[1] = dp[16] << 24 | dp[17] << 16 | dp[18] << 8 | dp[19] ; + keyid[0] = (unsigned int)(dp[12]) << 24 | dp[13] << 16 | dp[14] << 8 | dp[15] ; + keyid[1] = (unsigned int)(dp[16]) << 24 | dp[17] << 16 | dp[18] << 8 | dp[19] ; lowbits = keyid[1]; md_close(md); sk->keyid[0] = keyid[0]; @@ -354,8 +354,8 @@ keyid_from_pk( PKT_public_key *pk, u32 *keyid ) if(md) { dp = md_read( md, 0 ); - keyid[0] = dp[12] << 24 | dp[13] << 16 | dp[14] << 8 | dp[15] ; - keyid[1] = dp[16] << 24 | dp[17] << 16 | dp[18] << 8 | dp[19] ; + keyid[0] = (unsigned int)(dp[12]) << 24 | dp[13] << 16 | dp[14] << 8 | dp[15] ; + keyid[1] = (unsigned int)(dp[16]) << 24 | dp[17] << 16 | dp[18] << 8 | dp[19] ; lowbits = keyid[1]; md_close(md); pk->keyid[0] = keyid[0]; @@ -398,8 +398,8 @@ keyid_from_fingerprint( const byte *fprint, size_t fprint_len, u32 *keyid ) } else { const byte *dp = fprint; - keyid[0] = dp[12] << 24 | dp[13] << 16 | dp[14] << 8 | dp[15] ; - keyid[1] = dp[16] << 24 | dp[17] << 16 | dp[18] << 8 | dp[19] ; + keyid[0] = (unsigned int)(dp[12]) << 24 | dp[13] << 16 | dp[14] << 8 | dp[15] ; + keyid[1] = (unsigned int)(dp[16]) << 24 | dp[17] << 16 | dp[18] << 8 | dp[19] ; } return keyid[1]; @@ -687,8 +687,8 @@ fingerprint_from_pk( PKT_public_key *pk, byte *array, size_t *ret_len ) if( !array ) array = xmalloc( len ); memcpy(array, dp, len ); - pk->keyid[0] = dp[12] << 24 | dp[13] << 16 | dp[14] << 8 | dp[15] ; - pk->keyid[1] = dp[16] << 24 | dp[17] << 16 | dp[18] << 8 | dp[19] ; + pk->keyid[0] = (unsigned int)(dp[12]) << 24 | dp[13] << 16 | dp[14] << 8 | dp[15] ; + pk->keyid[1] = (unsigned int)(dp[16]) << 24 | dp[17] << 16 | dp[18] << 8 | dp[19] ; md_close(md); } diff --git a/g10/misc.c b/g10/misc.c index 68b4cea..e443836 100644 --- a/g10/misc.c +++ b/g10/misc.c @@ -299,7 +299,7 @@ u32 buffer_to_u32( const byte *buffer ) { unsigned long a; - a = *buffer << 24; + a = (unsigned int)(*buffer) << 24; a |= buffer[1] << 16; a |= buffer[2] << 8; a |= buffer[3]; diff --git a/g10/parse-packet.c b/g10/parse-packet.c index dcda8ef..92fc399 100644 --- a/g10/parse-packet.c +++ b/g10/parse-packet.c @@ -97,7 +97,7 @@ static unsigned long read_32(IOBUF inp) { unsigned long a; - a = iobuf_get_noeof(inp) << 24; + a = (unsigned int)(iobuf_get_noeof(inp)) << 24; a |= iobuf_get_noeof(inp) << 16; a |= iobuf_get_noeof(inp) << 8; a |= iobuf_get_noeof(inp); @@ -377,7 +377,7 @@ parse( IOBUF inp, PACKET *pkt, int onlykeypkts, off_t *retpos, } else if( c == 255 ) { - pktlen = (hdr[hdrlen++] = iobuf_get_noeof(inp)) << 24; + pktlen = (unsigned int)((hdr[hdrlen++] = iobuf_get_noeof(inp))) << 24; pktlen |= (hdr[hdrlen++] = iobuf_get_noeof(inp)) << 16; pktlen |= (hdr[hdrlen++] = iobuf_get_noeof(inp)) << 8; if( (c = iobuf_get(inp)) == -1 ) @@ -1178,7 +1178,7 @@ enum_sig_subpkt( const subpktarea_t *pktbuf, sigsubpkttype_t reqtype, if( n == 255 ) { /* 4 byte length header */ if( buflen < 4 ) goto too_short; - n = (buffer[0] << 24) | (buffer[1] << 16) + n = ((unsigned int)(buffer[0]) << 24) | (buffer[1] << 16) | (buffer[2] << 8) | buffer[3]; buffer += 4; buflen -= 4; @@ -2011,7 +2011,7 @@ parse_attribute_subpkts(PKT_user_id *uid) if( n == 255 ) { /* 4 byte length header */ if( buflen < 4 ) goto too_short; - n = (buffer[0] << 24) | (buffer[1] << 16) + n = ((unsigned int)(buffer[0]) << 24) | (buffer[1] << 16) | (buffer[2] << 8) | buffer[3]; buffer += 4; buflen -= 4; diff --git a/util/iobuf.c b/util/iobuf.c index 35de020..ec931d5 100644 --- a/util/iobuf.c +++ b/util/iobuf.c @@ -738,7 +738,7 @@ block_filter(void *opaque, int control, IOBUF chain, byte *buf, size_t *ret_len) } } else if( c == 255 ) { - a->size = iobuf_get(chain) << 24; + a->size = (unsigned int)(iobuf_get(chain)) << 24; a->size |= iobuf_get(chain) << 16; a->size |= iobuf_get(chain) << 8; if( (c = iobuf_get(chain)) == -1 ) { diff --git a/util/simple-gettext.c b/util/simple-gettext.c index 9225737..7751efb 100644 --- a/util/simple-gettext.c +++ b/util/simple-gettext.c @@ -107,7 +107,7 @@ static struct loaded_domain *the_domain; static __inline__ u32 do_swap_u32( u32 i ) { - return (i << 24) | ((i & 0xff00) << 8) | ((i >> 8) & 0xff00) | (i >> 24); + return ((unsigned int)(i) << 24) | ((i & 0xff00) << 8) | ((i >> 8) & 0xff00) | (i >> 24); } #define SWAPIT(flag, data) ((flag) ? do_swap_u32(data) : (data) ) -- 1.8.5.2 (Apple Git-48) >From 77512ffe117e951e49fa6a4b67aa85c82afda960 Mon Sep 17 00:00:00 2001 From: David Leon Gil Date: Tue, 2 Sep 2014 09:30:29 -0400 Subject: [PATCH 2/3] Fix undefined behavior in cipher/ due to failure to properly cast type-promoted integers. (This includes an instance of the idiom which Coccinelle failed to produce a correct patch for.) --- cipher/blowfish.c | 8 ++++---- cipher/cast5.c | 16 ++++++++-------- cipher/des.c | 4 ++-- cipher/twofish.c | 2 +- 4 files changed, 15 insertions(+), 15 deletions(-) diff --git a/cipher/blowfish.c b/cipher/blowfish.c index 61cd2b7..3fb0892 100644 --- a/cipher/blowfish.c +++ b/cipher/blowfish.c @@ -424,8 +424,8 @@ do_encrypt_block( BLOWFISH_context *bc, byte *outbuf, const byte *inbuf ) { u32 d1, d2; - d1 = inbuf[0] << 24 | inbuf[1] << 16 | inbuf[2] << 8 | inbuf[3]; - d2 = inbuf[4] << 24 | inbuf[5] << 16 | inbuf[6] << 8 | inbuf[7]; + d1 = (unsigned int)(inbuf[0]) << 24 | inbuf[1] << 16 | inbuf[2] << 8 | inbuf[3]; + d2 = (unsigned int)(inbuf[4]) << 24 | inbuf[5] << 16 | inbuf[6] << 8 | inbuf[7]; do_encrypt( bc, &d1, &d2 ); outbuf[0] = (d1 >> 24) & 0xff; outbuf[1] = (d1 >> 16) & 0xff; @@ -449,8 +449,8 @@ do_decrypt_block( BLOWFISH_context *bc, byte *outbuf, const byte *inbuf ) { u32 d1, d2; - d1 = inbuf[0] << 24 | inbuf[1] << 16 | inbuf[2] << 8 | inbuf[3]; - d2 = inbuf[4] << 24 | inbuf[5] << 16 | inbuf[6] << 8 | inbuf[7]; + d1 = (unsigned int)(inbuf[0]) << 24 | inbuf[1] << 16 | inbuf[2] << 8 | inbuf[3]; + d2 = (unsigned int)(inbuf[4]) << 24 | inbuf[5] << 16 | inbuf[6] << 8 | inbuf[7]; decrypt( bc, &d1, &d2 ); outbuf[0] = (d1 >> 24) & 0xff; outbuf[1] = (d1 >> 16) & 0xff; diff --git a/cipher/cast5.c b/cipher/cast5.c index ed8c738..c3abc67 100644 --- a/cipher/cast5.c +++ b/cipher/cast5.c @@ -375,8 +375,8 @@ do_encrypt_block( CAST5_context *c, byte *outbuf, const byte *inbuf ) /* (L0,R0) <-- (m1...m64). (Split the plaintext into left and * right 32-bit halves L0 = m1...m32 and R0 = m33...m64.) */ - l = inbuf[0] << 24 | inbuf[1] << 16 | inbuf[2] << 8 | inbuf[3]; - r = inbuf[4] << 24 | inbuf[5] << 16 | inbuf[6] << 8 | inbuf[7]; + l = (unsigned int)(inbuf[0]) << 24 | inbuf[1] << 16 | inbuf[2] << 8 | inbuf[3]; + r = (unsigned int)(inbuf[4]) << 24 | inbuf[5] << 16 | inbuf[6] << 8 | inbuf[7]; /* (16 rounds) for i from 1 to 16, compute Li and Ri as follows: * Li = Ri-1; @@ -433,8 +433,8 @@ do_decrypt_block (CAST5_context *c, byte *outbuf, const byte *inbuf ) Km = c->Km; Kr = c->Kr; - l = inbuf[0] << 24 | inbuf[1] << 16 | inbuf[2] << 8 | inbuf[3]; - r = inbuf[4] << 24 | inbuf[5] << 16 | inbuf[6] << 8 | inbuf[7]; + l = (unsigned int)(inbuf[0]) << 24 | inbuf[1] << 16 | inbuf[2] << 8 | inbuf[3]; + r = (unsigned int)(inbuf[4]) << 24 | inbuf[5] << 16 | inbuf[6] << 8 | inbuf[7]; t = l; l = r; r = t ^ F1(r, Km[15], Kr[15]); t = l; l = r; r = t ^ F3(r, Km[14], Kr[14]); @@ -588,10 +588,10 @@ do_cast_setkey( CAST5_context *c, const byte *key, unsigned keylen ) if( keylen != 16 ) return G10ERR_WRONG_KEYLEN; - x[0] = key[0] << 24 | key[1] << 16 | key[2] << 8 | key[3]; - x[1] = key[4] << 24 | key[5] << 16 | key[6] << 8 | key[7]; - x[2] = key[8] << 24 | key[9] << 16 | key[10] << 8 | key[11]; - x[3] = key[12] << 24 | key[13] << 16 | key[14] << 8 | key[15]; + x[0] = (unsigned int)(key[0]) << 24 | key[1] << 16 | key[2] << 8 | key[3]; + x[1] = (unsigned int)(key[4]) << 24 | key[5] << 16 | key[6] << 8 | key[7]; + x[2] = (unsigned int)(key[8]) << 24 | key[9] << 16 | key[10] << 8 | key[11]; + x[3] = (unsigned int)(key[12]) << 24 | key[13] << 16 | key[14] << 8 | key[15]; key_schedule( x, z, k ); for(i=0; i < 16; i++ ) diff --git a/cipher/des.c b/cipher/des.c index 756c146..f5934e5 100644 --- a/cipher/des.c +++ b/cipher/des.c @@ -430,8 +430,8 @@ static byte weak_keys[64][8] = * Macros to convert 8 bytes from/to 32bit words. */ #define READ_64BIT_DATA(data, left, right) \ - left = (data[0] << 24) | (data[1] << 16) | (data[2] << 8) | data[3]; \ - right = (data[4] << 24) | (data[5] << 16) | (data[6] << 8) | data[7]; + left = ((unsigned int)data[0] << 24) | (data[1] << 16) | (data[2] << 8) | data[3]; \ + right = ((unsigned int)data[4] << 24) | (data[5] << 16) | (data[6] << 8) | data[7]; #define WRITE_64BIT_DATA(data, left, right) \ data[0] = (left >> 24) &0xff; data[1] = (left >> 16) &0xff; \ diff --git a/cipher/twofish.c b/cipher/twofish.c index 2feccdf..603a806 100644 --- a/cipher/twofish.c +++ b/cipher/twofish.c @@ -756,7 +756,7 @@ twofish_setkey (void *ctx, const byte *key, unsigned int keylen) #define INPACK(n, x, m) \ x = in[4 * (n)] ^ (in[4 * (n) + 1] << 8) \ - ^ (in[4 * (n) + 2] << 16) ^ (in[4 * (n) + 3] << 24) ^ ctx->w[m] + ^ (in[4 * (n) + 2] << 16) ^ ((unsigned int)(in[4 * (n) + 3]) << 24) ^ ctx->w[m] #define OUTUNPACK(n, x, m) \ x ^= ctx->w[m]; \ -- 1.8.5.2 (Apple Git-48) >From 34adb565128a8b40aee1a69037e9c598e9086346 Mon Sep 17 00:00:00 2001 From: David Leon Gil Date: Tue, 2 Sep 2014 09:32:48 -0400 Subject: [PATCH 3/3] Fix undefined behavior due to dereferencing a NULL pointer in util/secmem.c. Adds a static MEMBLOCK, which is used to calculate the same(?) offset that the previous code attempted to calculate. --- util/secmem.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/util/secmem.c b/util/secmem.c index 553175b..3123e5b 100644 --- a/util/secmem.c +++ b/util/secmem.c @@ -68,6 +68,7 @@ struct memblock_struct { } u; }; +static const MEMBLOCK mbforalignment; static void *pool; @@ -415,7 +416,8 @@ secmexrealloc( void *p, size_t newsize ) size_t size; void *a; - mb = (MEMBLOCK*)((char*)p - ((size_t) &((MEMBLOCK*)0)->u.aligned.c)); + mb = (MEMBLOCK*)((char*)p - ((size_t)((uintptr_t)(&(mbforalignment.u.aligned.c)) - (uintptr_t)(&mbforalignment))) +); size = mb->size; if (size < sizeof(MEMBLOCK)) log_bug ("secure memory corrupted at block %p\n", (void *)mb); @@ -442,7 +444,8 @@ secmem_free( void *a ) if( !a ) return; - mb = (MEMBLOCK*)((char*)a - ((size_t) &((MEMBLOCK*)0)->u.aligned.c)); + mb = (MEMBLOCK*)((char*)a - ((size_t)((uintptr_t)(&(mbforalignment.u.aligned.c)) - (uintptr_t)(&mbforalignment))) +); size = mb->size; /* This does not make much sense: probably this memory is held in the * cache. We do it anyway: */ -- 1.8.5.2 (Apple Git-48) From e1ven at e1ven.com Tue Sep 2 20:38:56 2014 From: e1ven at e1ven.com (Colin Davis) Date: Tue, 2 Sep 2014 14:38:56 -0400 Subject: Cannot build 2.1 beta 6 on Mac OSX 10.9.4 In-Reply-To: References: Message-ID: I had had to patch this to bypass the error on my machine. I suspect everyone trying to compile on OSX will have to do the same. I wrote up my instructions at http://e1ven.com/2014/05/26/compiling-gpg-2-1-on-osx/ Specifically, I made a small patch, which let GPG compile for me. https://gist.githubusercontent.com/e1ven/167af3ac8a196773fc46/raw/62f4deb4936a6a32634ac3ee12c9a06cb4c8eac7/makefile.patch Perhaps this will help you as well? -CPD > On Aug 30, 2014, at 7:21 PM, Charles Diza wrote: > > I tried to build the sixth beta of 2.1 on Mac OSX 10.9.4. All the prereq's build fine, but when building gnupg2 it always fails here: > > gcc -I/usr/local/Cellar/libgcrypt/1.6.2/include -I/usr/local/Cellar/libgpg-error/1.13/include -I/usr/local/Cellar/libassuan/2.1.2/include -I/usr/local/Cellar/libgpg-error/1.13/include -I/usr/local/Cellar/libksba/1.3.0/include -I/usr/local/Cellar/libgpg-error/1.13/include -g -O2 -Wall -Wno-pointer-sign -Wpointer-arith -o t-openpgp-oid t-openpgp-oid.o libcommon.a ../gl/libgnu.a -L/usr/local/Cellar/libgcrypt/1.6.2/lib -lgcrypt -L/usr/local/Cellar/libgpg-error/1.13/lib -lgpg-error -L/usr/local/Cellar/libassuan/2.1.2/lib -lassuan -L/usr/local/Cellar/libgpg-error/1.13/lib -lgpg-error -L/usr/local/Cellar/libgpg-error/1.13/lib -lgpg-error -liconv > Undefined symbols for architecture x86_64: > "_default_errsource", referenced from: > _parse_ber_header in libcommon.a(libcommon_a-tlv.o) > _parse_sexp in libcommon.a(libcommon_a-tlv.o) > ld: symbol(s) not found for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see invocation) > make[3]: *** [t-sexputil] Error 1 > make[3]: *** Waiting for unfinished jobs.... > make[2]: *** [all] Error 2 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > > Let me know if you want more information. > > Cheers, > Charles > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From oliverml1 at oli1170.net Tue Sep 2 21:45:46 2014 From: oliverml1 at oli1170.net (Oliver Winker) Date: Tue, 02 Sep 2014 21:45:46 +0200 Subject: Patches gpg-agent + scute for ssl/tls auth using opengpg card with 2048 rsa key In-Reply-To: <5405B564.5090709@incenp.org> References: <1661443.XlFuGbBlzz@gamix64> <5405B564.5090709@incenp.org> Message-ID: <2845848.VqNA4ZNNaE@gamix64> Hello, On Tuesday 02 September 2014 14:17:40 Damien Goutte-Gattat wrote: > First of all, your patches work for me and I thank you for that, I was > struggling to make Scute work with a recent Firefox. Good :) > But, are you sure this has anything to do with the size of the RSA key? No ;) > It seems that the problem you are addressing is rather caused by a > change between TLS 1.1 (or less) and TLS 1.2. Very well possible. I'm not enough in these protocol details to tell for sure. Just debugged it and worked through the error path. > Indeed, disabling TLS 1.2 in Firefox (by setting the variable > security.tls.version.max to "2" instead of "3" in about:config) is > enough to make Scute work for me, even with a 2048-bit RSA key and even > without your patches. > > According to a bug report in Mozilla?s NSS library [1], the change > introduced by TLS 1.2 is that the data to be signed is no longer a > "MD5+SHA1 hash" (36 bytes, which is the length expected by GPG-Agent), > but is instead an ASN.1 structure representing a DigestInfo object (35 > or 51 bytes total, depending on the hash used). This sounds indeed interesting and plausible then. Actually therefore I submitted the patch with some "imprecision margin", so that someone who better knows the subjects can put these details right. Best Regards, Oliver From bernhard at intevation.de Wed Sep 3 15:26:52 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 3 Sep 2014 15:26:52 +0200 Subject: upstream-tracker.org ABI history Message-ID: <201409031527.02849.bernhard@intevation.de> Probably known to some, the service upstream-tracker seems to have a nice overview about how the ABIs developed over time. For gpgme, there are even some warnings, which may be relevant. http://upstream-tracker.org/versions/gpgme.html http://upstream-tracker.org/versions/libgpg-error.html http://upstream-tracker.org/versions/libgcrypt.html Anatol Pomozov posted here before with a patch, he is the maintainer of the service. I've also added the service to wiki.gnupg.org. Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by 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 3 16:20:37 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 3 Sep 2014 10:20:37 -0400 Subject: [PATCH] only document --faked-system-time for gpg 2.1 and later Message-ID: <1409754037-22421-1-git-send-email-dkg@fifthhorseman.net> faked-system-time is not present at all in the codebase for 1.4; it is present only for gpgsm and gpg-agent (not gpg itself) in 2.0; it appears in gpg for 2.1. This patch adjusts the gpg documentation appropriately. (The other way to resolve the problem would be to backport the faked-system-time call to earlier branches of gpg) Debian-Bug: 760354 --- doc/gpg.texi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/gpg.texi b/doc/gpg.texi index e9bcff3..0e6b4e9 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -2487,12 +2487,14 @@ Enable debug output from the included CCID driver for smartcards. Note that this option is only available on some system. @end ifset + at ifset gpgtwoone @item --faked-system-time @var{epoch} @opindex faked-system-time This option is only useful for testing; it sets the system time back or forth to @var{epoch} which is the number of seconds elapsed since the year 1970. Alternatively @var{epoch} may be given as a full ISO time string (e.g. "20070924T154812"). + at end ifset @item --enable-progress-filter @opindex enable-progress-filter -- 2.1.0 From wk at gnupg.org Wed Sep 3 16:47:30 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 03 Sep 2014 16:47:30 +0200 Subject: upstream-tracker.org ABI history In-Reply-To: <201409031527.02849.bernhard@intevation.de> (Bernhard Reiter's message of "Wed, 3 Sep 2014 15:26:52 +0200") References: <201409031527.02849.bernhard@intevation.de> Message-ID: <871trshibh.fsf@vigenere.g10code.de> On Wed, 3 Sep 2014 15:26, bernhard at intevation.de said: > developed over time. For gpgme, there are even some warnings, > which may be relevant. The gpgme_subkey_t describes objects created by gpgme. Those objects may not be modified by a user. Thus extending the size of this structure is a backward compatible ABI change. > Anatol Pomozov posted here before with a patch, Any pointer? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Sep 3 17:12:03 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 03 Sep 2014 17:12:03 +0200 Subject: [PATCH] only document --faked-system-time for gpg 2.1 and later In-Reply-To: <1409754037-22421-1-git-send-email-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 3 Sep 2014 10:20:37 -0400") References: <1409754037-22421-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <87wq9kg2m4.fsf@vigenere.g10code.de> On Wed, 3 Sep 2014 16:20, dkg at fifthhorseman.net said: > (The other way to resolve the problem would be to backport the > faked-system-time call to earlier branches of gpg) Oh no, no backports for such changes. The risk of breaking stuff is too high. I will wait a few days before I apply your patch in case you find some more of these tiny things. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernhard at intevation.de Wed Sep 3 17:23:28 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 3 Sep 2014 17:23:28 +0200 Subject: upstream-tracker.org ABI history In-Reply-To: <871trshibh.fsf@vigenere.g10code.de> References: <201409031527.02849.bernhard@intevation.de> <871trshibh.fsf@vigenere.g10code.de> Message-ID: <201409031723.35896.bernhard@intevation.de> On Wednesday 03 September 2014 at 16:47:30, Werner Koch wrote: > On Wed, 3 Sep 2014 15:26, bernhard at intevation.de said: > > developed over time. For gpgme, there are even some warnings, > > which may be relevant. > > The gpgme_subkey_t describes objects created by gpgme. Those objects > may not be modified by a user. Thus extending the size of this > structure is a backward compatible ABI change. Sounds good to me, I just wanted to point to the service. > > Anatol Pomozov posted here before with a patch, > Any pointer? Sorry, I was not precise enough. On the 2014-06-21 he posted on gnupg-users, but he is not the maintainer of upstream-tracker. He just reported an issue with libgcrypt that he found using upstream-tracker back then. Best, Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by 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 3 18:07:27 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 03 Sep 2014 18:07:27 +0200 Subject: upstream-tracker.org ABI history In-Reply-To: <201409031723.35896.bernhard@intevation.de> (Bernhard Reiter's message of "Wed, 3 Sep 2014 17:23:28 +0200") References: <201409031527.02849.bernhard@intevation.de> <871trshibh.fsf@vigenere.g10code.de> <201409031723.35896.bernhard@intevation.de> Message-ID: <87lhq0elhc.fsf@vigenere.g10code.de> On Wed, 3 Sep 2014 17:23, bernhard at intevation.de said: > On the 2014-06-21 he posted on gnupg-users, but he is not the Okay. Libgcrypt 1.6 has an ABI break on purpose (with glibc so.20 instead of so.11). Most people won't notice that break because the API changes were minimal except for the removal of a very rarley used and long deprecated subsystem. However some software broke anyway. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From simon at josefsson.org Wed Sep 3 23:23:30 2014 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 03 Sep 2014 23:23:30 +0200 Subject: OpenPGP Card ECC status? In-Reply-To: <540592B2.5090207@pietig.com> (Achim Pietig's message of "Tue, 02 Sep 2014 11:49:38 +0200") References: <87lhq2qx3l.fsf@latte.josefsson.org> <540592B2.5090207@pietig.com> Message-ID: <87r3zs1jql.fsf@latte.josefsson.org> Hi Achim, Thanks for the update on the OpenPGP Card spec! That all sounds good. I'm hoping Werner can comment on what's left to do in GnuPG. (FWIW, I believe the NEO can support NIST, Brainpool and ANSSI curves -- https://github.com/Yubico/ykneo-curves -- but probably not Curve25519) /Simon Achim Pietig writes: > Hi Simon, > > there was a little henn-egg problem with the card specification in the past. > I published a beta version with ECC (partly) last year, but the > related standards (ISO 7816-x) > were not finished. As in the past I plan to be as close as possible to > international smart card standards > because all somming products will follow them and there is no chance > to get proprietary functions/algorithms > in cards on the market. > Most important for future cards will be EN 419212 (Application > Interface for smart cards used as Secure Signature Creation Devices), > that replaces the discarded EN 14890, that I used in previous versions > of the OpenPGP card spec. This standard is ready now and I plan > to finalize the OpenPGP card spec soon. I still need some help from > Werner for defining the dec-command, because this requires a special > usage of ECC. > sign and auth is clear at the moment - all new standards only support > Brainpool, NIST was stripped of from all papers after the NSA problem > last year. > Key import for ECC is also described in new ISO 7816-8 (not ready, but > stable enough for usage). > After finishing the spec we can do test implementations and after that > GnuPG can be finished in that direction. > > Best regards > Achim > > > Am 02.09.2014 um 09:51 schrieb Simon Josefsson: >> Hi. What's the status of support for OpenPGP cards with ECC in GnuPG? >> Is there a recommended GnuPG version to test with? Does on-board key >> generation work? Key import? We are happy to add support for ECC on >> the hardware side in the YubiKey NEO applet [1]. I have been under the >> impression that the GnuPG side of things haven't been ready, but I'm >> happy if this is no longer the case. >> >> /Simon >> >> [1] https://github.com/Yubico/ykneo-openpgp >> >> >> >> _______________________________________________ >> Gnupg-devel mailing list >> Gnupg-devel at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-devel >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From wk at gnupg.org Thu Sep 4 17:02:22 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 04 Sep 2014 17:02:22 +0200 Subject: OpenPGP Card ECC status? In-Reply-To: <87r3zs1jql.fsf@latte.josefsson.org> (Simon Josefsson's message of "Wed, 03 Sep 2014 23:23:30 +0200") References: <87lhq2qx3l.fsf@latte.josefsson.org> <540592B2.5090207@pietig.com> <87r3zs1jql.fsf@latte.josefsson.org> Message-ID: <87zjefcttt.fsf@vigenere.g10code.de> On Wed, 3 Sep 2014 23:23, simon at josefsson.org said: > Thanks for the update on the OpenPGP Card spec! That all sounds good. > I'm hoping Werner can comment on what's left to do in GnuPG. I would really like to see Ed25519 and Curve25519 DH support in a card. For the old curves the card should behave similar to gpg-agent; thus being protocol neutral and it is not required that the rfc-6637 ECDH algorithm is implemented by the card. > Achim Pietig writes: >> sign and auth is clear at the moment - all new standards only support >> Brainpool, NIST was stripped of from all papers after the NSA problem If the NIST curves are found to be bugged we should also be cautious with the Brainpool curves. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Sat Sep 6 07:04:07 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 6 Sep 2014 01:04:07 -0400 Subject: [PATCH] update gpgme's doc/gpl.texi to match version from gnupg Message-ID: <1409979847-31480-1-git-send-email-dkg@fifthhorseman.net> Somehow the doc/gpl.texi from gpgme and gnupg drifted out of sync. This patch to gpgme's file brings it in line with gnupg's master branch, and avoids the following errors during make: ./gpl.texi:667: @section seen before @end enumerate ./gpl.texi:724: unmatched `@end enumerate' ./gpl.texi:1: warning: node next `Copying' in menu `Concept Index' and in sectioning `Function and Data Index' differ --- doc/gpl.texi | 34 +++++++++++++++++++++------------- 1 file changed, 21 insertions(+), 13 deletions(-) diff --git a/doc/gpl.texi b/doc/gpl.texi index 1b29a81..d13e9e4 100644 --- a/doc/gpl.texi +++ b/doc/gpl.texi @@ -1,4 +1,5 @@ @node Copying + @unnumbered GNU General Public License @center Version 3, 29 June 2007 @@ -11,7 +12,7 @@ Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. @end display - at section Preamble + at unnumberedsec Preamble The GNU General Public License is a free, copyleft license for software and other kinds of works. @@ -77,7 +78,7 @@ The precise terms and conditions for copying, distribution and modification follow. @iftex - at section TERMS AND CONDITIONS + at unnumberedsec TERMS AND CONDITIONS @end iftex @ifinfo @center TERMS AND CONDITIONS @@ -227,7 +228,7 @@ terms of section 4, provided that you also meet all of these conditions: @enumerate a - at item + at item The work must carry prominent notices stating that you modified it, and giving a relevant date. @@ -658,13 +659,16 @@ an absolute waiver of all civil liability in connection with the Program, unless a warranty or assumption of liability accompanies a copy of the Program in return for a fee. + at end enumerate + @iftex @heading END OF TERMS AND CONDITIONS @end iftex @ifinfo @center END OF TERMS AND CONDITIONS @end ifinfo - at section How to Apply These Terms to Your New Programs + + at unnumberedsec How to Apply These Terms to Your New Programs If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it @@ -674,9 +678,11 @@ terms. To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively state the exclusion of warranty; and each file should have at least -the ``copyright'' line and a pointer to where the full notice is found. - at smallexample - at var{one line to give the program's name and a brief idea of what it does.} +the ``copyright'' line and a pointer to where the full notice is +found. + + at example + at var{one line to give the program's name and a brief idea of what it does.} Copyright (C) @var{year} @var{name of author} This program is free software: you can redistribute it and/or modify @@ -691,17 +697,21 @@ General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see @url{http://www.gnu.org/licenses/}. - at end smallexample + at end example + at noindent Also add information on how to contact you by electronic and paper mail. + at noindent If the program does terminal interaction, make it output a short notice like this when it starts in an interactive mode: @smallexample - at var{program} Copyright (C) @var{year} @var{name of author} -This program comes with ABSOLUTELY NO WARRANTY; for details type @samp{show w}. -This is free software, and you are welcome to redistribute it under certain conditions; type @samp{show c} for details. + at var{program} Copyright (C) @var{year} @var{name of author} +This program comes with ABSOLUTELY NO WARRANTY; for details +type @samp{show w}. This is free software, and you are +welcome to redistribute it under certain conditions; +type @samp{show c} for details. @end smallexample The hypothetical commands @samp{show w} and @samp{show c} should show @@ -720,5 +730,3 @@ library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License. But first, please read @url{http://www.gnu.org/philosophy/why-not-lgpl.html}. - - at end enumerate -- 2.1.0 From mail at tgries.de Sun Sep 7 21:36:12 2014 From: mail at tgries.de (Thomas Gries) Date: Sun, 07 Sep 2014 21:36:12 +0200 Subject: =?UTF-8?B?SSBzdGlsbCBjYW5ub3QgYnVpbGQgcGluZW50cnkgLi9jb25maWd1cmU=?= =?UTF-8?B?IHN0b3BzIHdpdGggc3ludGF4IGVycm9yIG5lYXIgdW5leHBlY3RlZCB0b2tlbiA=?= =?UTF-8?B?w6xjb252Jw==?= Message-ID: <540CB3AC.9020101@tgries.de> I cannot built *pinetry *on OpenSuse 13.1 and OpenSuse Factory (i.e. the latest) error in configure: see below (*) automake --version ? 1.11.6 , tried also 1.14.1 autoconf --version ? 2.69 git clone git://git.gnupg.org/pinentry.git cd pinentry ./autogen.sh ? main::scan_file() called too early to check prototype at /usr/local/bin/aclocal line 643. Running aclocal -I m4 ... main::scan_file() called too early to check prototype at /usr/local/bin/aclocal line 643. configure.ac:302: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but not m4_defun'd m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from... m4/iconv.m4:22: AM_ICONV_LINK is expanded from... m4/iconv.m4:77: AM_ICONV is expanded from... configure.ac:302: the top level configure.ac:302: warning: AC_LIB_RPATH is m4_require'd but not m4_defun'd m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from... m4/iconv.m4:22: AM_ICONV_LINK is expanded from... m4/iconv.m4:77: AM_ICONV is expanded from... configure.ac:302: the top level Running autoheader... ? ./configure --enable-maintainer-mode ? ? (*) *./configure: line 7718: **syntax error**near unexpected token `iconv' ** **./configure: line 7718: ` AC_LIB_LINKFLAGS_BODY(iconv)'** *** /Can anyone help to get this compiled?// / -------------- next part -------------- An HTML attachment was scrubbed... URL: From chdiza at gmail.com Sun Sep 7 22:04:15 2014 From: chdiza at gmail.com (Charles Diza) Date: Sun, 7 Sep 2014 16:04:15 -0400 Subject: Cannot build 2.1 beta 6 on Mac OSX 10.9.4 In-Reply-To: References: Message-ID: On Tue, Sep 2, 2014 at 2:38 PM, Colin Davis wrote: > I had had to patch this to bypass the error on my machine. > I suspect everyone trying to compile on OSX will have to do the same. > > I wrote up my instructions at > http://e1ven.com/2014/05/26/compiling-gpg-2-1-on-osx/ > > Specifically, I made a small patch, which let GPG compile for me. > > https://gist.githubusercontent.com/e1ven/167af3ac8a196773fc46/raw/62f4deb4936a6a32634ac3ee12c9a06cb4c8eac7/makefile.patch > > Perhaps this will help you as well? > -CPD > I tried the patch, but get the exact same failure as before. To be fair, I didn't follow the rest of your posted procedure. But the patch alone doesn't seem to fix this particular issue. Cheers, Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at tgries.de Sun Sep 7 22:26:58 2014 From: mail at tgries.de (Thomas Gries) Date: Sun, 07 Sep 2014 22:26:58 +0200 Subject: =?UTF-8?B?UmU6IEkgc3RpbGwgY2Fubm90IGJ1aWxkIHBpbmVudHJ5IC4vY29uZmk=?= =?UTF-8?B?Z3VyZSBzdG9wcyB3aXRoIHN5bnRheCBlcnJvciBuZWFyIHVuZXhwZWN0ZWQgdG8=?= =?UTF-8?B?a2VuIMOsY29udic=?= In-Reply-To: <540CB3AC.9020101@tgries.de> References: <540CB3AC.9020101@tgries.de> Message-ID: <540CBF92.80608@tgries.de> Am 07.09.2014 um 21:36 > I cannot built *pinetry *on OpenSuse 13.1 and OpenSuse Factory (i.e. > the latest) > error in configure: see below (*) > > automake --version ? 1.11.6 , tried also 1.14.1 > autoconf --version ? 2.69 > > git clone git://git.gnupg.org/pinentry.git > cd pinentry > ./autogen.sh ? > > main::scan_file() called too early to check prototype at > /usr/local/bin/aclocal line 643. > Running aclocal -I m4 ... > main::scan_file() called too early to check prototype at > /usr/local/bin/aclocal line 643. > configure.ac:302: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but > not m4_defun'd > m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from... > m4/iconv.m4:22: AM_ICONV_LINK is expanded from... > m4/iconv.m4:77: AM_ICONV is expanded from... > configure.ac:302: the top level > configure.ac:302: warning: AC_LIB_RPATH is m4_require'd but not m4_defun'd > m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from... > m4/iconv.m4:22: AM_ICONV_LINK is expanded from... > m4/iconv.m4:77: AM_ICONV is expanded from... > configure.ac:302: the top level > Running autoheader... > ? > > ./configure --enable-maintainer-mode ? > ? > > (*) > *./configure: line 7718: **syntax error**near unexpected token `iconv' ** > **./configure: line 7718: ` AC_LIB_LINKFLAGS_BODY(iconv)'** > *** > > /Can anyone help to get this compiled?// > / [update] http://dpaste.com/2MS8PHD has the relevant generated code around line 7718 from file configure. Who can help? -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at josefsson.org Tue Sep 9 08:41:22 2014 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 09 Sep 2014 08:41:22 +0200 Subject: OpenPGP Card ECC status? In-Reply-To: <87zjefcttt.fsf@vigenere.g10code.de> (Werner Koch's message of "Thu, 04 Sep 2014 17:02:22 +0200") References: <87lhq2qx3l.fsf@latte.josefsson.org> <540592B2.5090207@pietig.com> <87r3zs1jql.fsf@latte.josefsson.org> <87zjefcttt.fsf@vigenere.g10code.de> Message-ID: <8738c1mh2l.fsf@latte.josefsson.org> Werner Koch writes: > On Wed, 3 Sep 2014 23:23, simon at josefsson.org said: > >> Thanks for the update on the OpenPGP Card spec! That all sounds good. >> I'm hoping Werner can comment on what's left to do in GnuPG. > > I would really like to see Ed25519 and Curve25519 DH support in a card. So do I.. I'm hoping this won't be too far away, but I think there is value in getting experience with the existing ECC standards with GnuPG and with smartcards, since that appears to be lower-hanging-fruit. > For the old curves the card should behave similar to gpg-agent; thus > being protocol neutral and it is not required that the rfc-6637 ECDH > algorithm is implemented by the card. Ok. >> Achim Pietig writes: > >>> sign and auth is clear at the moment - all new standards only support >>> Brainpool, NIST was stripped of from all papers after the NSA problem > > If the NIST curves are found to be bugged we should also be cautious > with the Brainpool curves. Yeah, to me they fall into the same class. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From gniibe at fsij.org Tue Sep 9 09:54:56 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 09 Sep 2014 16:54:56 +0900 Subject: OpenPGP Card ECC status? In-Reply-To: <8738c1mh2l.fsf@latte.josefsson.org> References: <87lhq2qx3l.fsf@latte.josefsson.org> <540592B2.5090207@pietig.com> <87r3zs1jql.fsf@latte.josefsson.org> <87zjefcttt.fsf@vigenere.g10code.de> <8738c1mh2l.fsf@latte.josefsson.org> Message-ID: <1410249296.4075.10.camel@cfw2.gniibe.org> On 2014-09-09 at 08:41 +0200, Simon Josefsson wrote: > So do I.. I'm hoping this won't be too far away, but I think there is > value in getting experience with the existing ECC standards with GnuPG > and with smartcards, since that appears to be lower-hanging-fruit. For smartcard/tokon part, I implemented NIST P256 curve in Gnuk around February 2013. IIRC, I submitted an experimental patch for SCDaemon to support this, around March 2013. I tested, it worked well for me. Then, the summer of 2013 came. No one (I mean, my target customers) wants to use that, so, I didn't push this further. Then, one of my customers suggested me to support the curve of Bitcoin, so that Gnuk can be a private key store for Bitcoin. I implemented the curve in February 2014. I'm not sure if I submitted a patch to support this ECC thing for SCDaemon, but, I submitted a patch to support this curve to libgcrypt and GnuPG, and it's included already. SKS also supports this now. I tested, it worked well for me. My public key even has subkey for this curve. Mostly simultaneously, Mt.Gox became so famous in Japan. It was unfortunate that "Bitcoin" sounds very bad for general public in Japan, and... I stop working for that (because of family reasons). Then, I implemented ed25519 and curve25519 in Gnuk. Also, I implemented Montgomery curve routine in libgcrypt, so that we can support curve25519. I'm working this now. For GnuPG support of those ECC features of smartcard/token, all that we need is some modification of smartcard protocol specification for them and some glue code of gpg-agent and scdaemon. -- From simon at josefsson.org Tue Sep 9 16:01:04 2014 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 09 Sep 2014 16:01:04 +0200 Subject: OpenPGP Card ECC status? In-Reply-To: <1410249296.4075.10.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Tue, 09 Sep 2014 16:54:56 +0900") References: <87lhq2qx3l.fsf@latte.josefsson.org> <540592B2.5090207@pietig.com> <87r3zs1jql.fsf@latte.josefsson.org> <87zjefcttt.fsf@vigenere.g10code.de> <8738c1mh2l.fsf@latte.josefsson.org> <1410249296.4075.10.camel@cfw2.gniibe.org> Message-ID: <87tx4ggafz.fsf@latte.josefsson.org> NIIBE Yutaka writes: > On 2014-09-09 at 08:41 +0200, Simon Josefsson wrote: >> So do I.. I'm hoping this won't be too far away, but I think there is >> value in getting experience with the existing ECC standards with GnuPG >> and with smartcards, since that appears to be lower-hanging-fruit. > > For smartcard/tokon part, I implemented NIST P256 curve in Gnuk around > February 2013. IIRC, I submitted an experimental patch for SCDaemon > to support this, around March 2013. I tested, it worked well for me. Do you have a pointer to this patch? I suspect that's what I'd like to test to see if we can get it to work with the Yubikey NEO too. Any reason the patch hasn't been merged? /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From gniibe at fsij.org Wed Sep 10 04:06:37 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 10 Sep 2014 11:06:37 +0900 Subject: OpenPGP Card ECC status? In-Reply-To: <87tx4ggafz.fsf@latte.josefsson.org> References: <87lhq2qx3l.fsf@latte.josefsson.org> <540592B2.5090207@pietig.com> <87r3zs1jql.fsf@latte.josefsson.org> <87zjefcttt.fsf@vigenere.g10code.de> <8738c1mh2l.fsf@latte.josefsson.org> <1410249296.4075.10.camel@cfw2.gniibe.org> <87tx4ggafz.fsf@latte.josefsson.org> Message-ID: <1410314797.1528.1.camel@cfw2.gniibe.org> On 2014-09-09 at 16:01 +0200, Simon Josefsson wrote: > NIIBE Yutaka writes: > > For smartcard/tokon part, I implemented NIST P256 curve in Gnuk around > > February 2013. IIRC, I submitted an experimental patch for SCDaemon > > to support this, around March 2013. I tested, it worked well for me. > > Do you have a pointer to this patch? I suspect that's what I'd like to > test to see if we can get it to work with the Yubikey NEO too. Any > reason the patch hasn't been merged? My memory is not that accurate. I checked the mail archive: http://lists.gnupg.org/pipermail/gnupg-devel/2013-February/thread.html http://lists.gnupg.org/pipermail/gnupg-devel/2013-March/thread.html Discussions: ECC and smartcards: http://lists.gnupg.org/pipermail/gnupg-devel/2013-February/027373.html OpenPGP card specification enhancement for ECDSA support: http://lists.gnupg.org/pipermail/gnupg-devel/2013-March/027436.html Patches: [PATCH] scd: support ECDSA public key http://lists.gnupg.org/pipermail/gnupg-devel/2013-February/027432.html [PATCH] scd: support ECDSA public key http://lists.gnupg.org/pipermail/gnupg-devel/2013-March/027485.html Sorry, I misunderstood. Those patches for ECDSA have been merged to 2.1 already. It is ECDH, which is not fully implemented by GnuPG. In scd/app-openpgp.c, we have a function named ecdh_writekey, but it is not implemented yet. I created the page on wiki.gnupg.org: http://wiki.gnupg.org/OpenPGPcardECC?highlight=%28ecc%29 Well, sorry, again. I'm not good at formatting in WiKi. I think that for ECDSA, it's mostly settled. For ECDH, there are things to be determined. Once, we will have this enhancement of the specification, it's not that hard to implement ecdh_writekey or patch functions in scd/app-openpgp.c. I think that you can try ECDSA with NIST P-256 with 2.1.x beta. -- From guilhem at fripost.org Wed Sep 10 09:15:20 2014 From: guilhem at fripost.org (Guilhem Moulin) Date: Wed, 10 Sep 2014 09:15:20 +0200 Subject: [PATCH] Display key UIDs in key listing even when --fast-list-mode is set. Message-ID: <1410333320-4408-1-git-send-email-guilhem@fripost.org> As it's already the done for --edit-key: $ gpg --with-colons --fast-list-mode --edit-key $KEYID quit This makes --fast-list-mode useful together with --list-sigs, as it's shows on which UID the certificate signatures are added. Using --fast-list-mode with --list-sigs can make the command tremendously faster on large keyrings when the listed key(s) contains many signatures. Printing the key UIDs does not seem to add any significant performance penalty to the old behavior of --fast-list-mode. This is not surprising since UID packets are part of the OpenPGP Public-Key packet hence are encountered during the listing anyway; printing the text doesn't require extra lookup in the keyring (unlike displaying the primary UID of the signing keys) or otherwise expensive computation (unlike trust or validity calculation). --- doc/gpg.texi | 10 +++++----- g10/keylist.c | 8 ++++---- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/doc/gpg.texi b/doc/gpg.texi index 8ea8199..f7dede5 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -2807,11 +2807,11 @@ print the public key data. @item --fast-list-mode @opindex fast-list-mode Changes the output of the list commands to work faster; this is achieved -by leaving some parts empty. Some applications don't need the user ID -and the trust information given in the listings. By using this options -they can get a faster listing. The exact behaviour of this option may -change in future versions. If you are missing some information, don't -use this option. +by leaving some parts empty. Some applications don't need the user ID of +the signing keys and the trust information given in the listings. By +using this options they can get a faster listing. The exact behaviour of +this option may change in future versions. If you are missing some +information, don't use this option. @item --no-literal @opindex no-literal diff --git a/g10/keylist.c b/g10/keylist.c index 2728308..d0ac953 100644 --- a/g10/keylist.c +++ b/g10/keylist.c @@ -820,7 +820,7 @@ list_keyblock_print ( KBNODE keyblock, int secret, int fpr, void *opaque ) print_key_data( pk ); for( kbctx=NULL; (node=walk_kbnode( keyblock, &kbctx, 0)) ; ) { - if( node->pkt->pkttype == PKT_USER_ID && !opt.fast_list_mode ) { + if( node->pkt->pkttype == PKT_USER_ID ) { PKT_user_id *uid=node->pkt->pkt.user_id; if(pk && (uid->is_expired || uid->is_revoked) @@ -836,7 +836,7 @@ list_keyblock_print ( KBNODE keyblock, int secret, int fpr, void *opaque ) dump_attribs(uid,pk,sk); if((uid->is_revoked || uid->is_expired) - || ((opt.list_options&LIST_SHOW_UID_VALIDITY) && pk)) + || ((opt.list_options&LIST_SHOW_UID_VALIDITY) && !opt.fast_list_mode && pk)) { const char *validity; int indent; @@ -1126,7 +1126,7 @@ list_keyblock_colon( KBNODE keyblock, int secret, int fpr ) } for( kbctx=NULL; (node=walk_kbnode( keyblock, &kbctx, 0)) ; ) { - if( node->pkt->pkttype == PKT_USER_ID && !opt.fast_list_mode ) { + if( node->pkt->pkttype == PKT_USER_ID ) { PKT_user_id *uid=node->pkt->pkt.user_id; if(attrib_fp && node->pkt->pkt.user_id->attrib_data!=NULL) dump_attribs(node->pkt->pkt.user_id,pk,sk); @@ -1144,7 +1144,7 @@ list_keyblock_colon( KBNODE keyblock, int secret, int fpr ) printf("%s:r::::",str); else if ( uid->is_expired ) printf("%s:e::::",str); - else if ( opt.no_expensive_trust_checks ) + else if ( opt.fast_list_mode || opt.no_expensive_trust_checks ) printf("%s:::::",str); else { int uid_validity; -- 2.1.0 From wk at gnupg.org Wed Sep 10 09:30:55 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 10 Sep 2014 09:30:55 +0200 Subject: Problems with gpgsm/dirmngr in gnupg-2.1.0-beta751 In-Reply-To: <87a96icchq.fsf@pcwi7557.uni-muenster.de> (Jens Lechtenboerger's message of "Tue, 02 Sep 2014 16:40:01 +0200") References: <87zjgjpx3e.fsf@pcwi7557.uni-muenster.de> <201407311026.47586.bernhard@intevation.de> <87oavze49q.fsf@vigenere.g10code.de> <87a96icchq.fsf@pcwi7557.uni-muenster.de> Message-ID: <87wq9c2aq8.fsf@vigenere.g10code.de> On Tue, 2 Sep 2014 16:40, lechten at wi.uni-muenster.de said: > However, http_open calls http_session_ref, dereferencing the NULL > session. A quick fix is to add a NULL check to http_session_ref. This seems to be the correct fix given that the rest of the code does not assume that a session object exists. > connections. (Actually, no HTTP open should work right now, unless > it is passed a bogus session.) Indeed: $ gpg-connect-agent --dirmngr 'ks_fetch http://werner.eifzilla.de/mykey.asc' /bye gpg-connect-agent: no running Dirmngr - starting '/usr/local/bin/dirmngr' gpg-connect-agent: waiting for the dirmngr to come up ... (5s) gpg-connect-agent: connection to the dirmngr established gpg-connect-agent: receiving line failed: End of file The dirmngr crashed. With the fix it works: $ gpg-connect-agent --dirmngr 'ks_fetch http://werner.eifzilla.de/mykey.asc' /bye gpg-connect-agent: no running Dirmngr - starting '/usr/local/bin/dirmngr' gpg-connect-agent: waiting for the dirmngr to come up ... (5s) gpg-connect-agent: connection to the dirmngr established D pub 2048D/1E42B367 2007-12-31 [expires: 2018-12-31]%0A D uid Werner Koch %0A [...] Thanks, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From guilhem at fripost.org Wed Sep 10 13:37:46 2014 From: guilhem at fripost.org (Guilhem Moulin) Date: Wed, 10 Sep 2014 13:37:46 +0200 Subject: [PATCH] Display key UIDs in key listing even when --fast-list-mode is set. In-Reply-To: <1410333320-4408-1-git-send-email-guilhem@fripost.org> References: <1410333320-4408-1-git-send-email-guilhem@fripost.org> Message-ID: <20140910113746.GA7204@localhost> On Wed, 10 Sep 2014 at 09:15:20 +0200, Guilhem Moulin wrote: > This makes --fast-list-mode useful together with --list-sigs, as it's > shows on which UID the certificate signatures are added. I should have said that the previous patch doesn't apply as is to master and the 2.0 branch. I'll port it from 1.4.18 if the change is accepted ;-) -- Guilhem. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From dkg at fifthhorseman.net Thu Sep 11 18:19:24 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 11 Sep 2014 12:19:24 -0400 Subject: libgpg-error symbol visibility Message-ID: <87egviyvsj.fsf@alice.fifthhorseman.net> Hi Werner and other GnuPG folks-- I notice that libgpg-error 0.14 was released a few days ago -- thanks! In addition to the addition of estream functionality, the biggest change i see as a packager is the addition of symbol versioning visibility, with a version node of GPG_ERROR_1.0. IIUC, this actually moves all the pre-existing symbols from the "Base" (implicit) version node to the new GPG_ERROR_1.0 version node, which means that packages built against 0.14 but which only use pre-0.14 symbols will actually produce a (non-fatal) warning message when run against a pre-0.14 version of libgpg-error. For example: 0 dkg at alice:~$ echo test | gpg2 --encrypt -r $PGPID > tmp/test.pgp gpg2: /lib/x86_64-linux-gnu/libgpg-error.so.0: no version information available (required by gpg2) 0 dkg at alice:~$ I don't know enough about symbol versioning to know if there's a way to produce a smoother upgrade path. I've tried a couple different approaches, but none of them worked so i have no patch to propose. I'm trying to prepare this version for upload to Debian before we freeze (soon!), and i want to make sure that we're doing the right thing with it. At the moment, i'm looking for alternatives to the default option: A) ship 0.14 as-is, with all symbols bound to the new GPG_ERROR_1.0 version node, and accept that this will force an unnecessarily strong versioned dependency for packages built against the new package but only using pre-existing symbols. Is there a way that we can avoid this tighter versioned dependency and still avoid the warning messages shown above, or should we just accept the tight dependency and move forward? The tight versioned dependency will make backporting packages that depend on libgpg-error slightly more painful, but it's probably not a terrible thing. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From wk at gnupg.org Thu Sep 11 19:01:43 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 11 Sep 2014 19:01:43 +0200 Subject: libgpg-error symbol visibility In-Reply-To: <87egviyvsj.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 11 Sep 2014 12:19:24 -0400") References: <87egviyvsj.fsf@alice.fifthhorseman.net> Message-ID: <8761gut7k8.fsf@vigenere.g10code.de> On Thu, 11 Sep 2014 18:19, dkg at fifthhorseman.net said: > I notice that libgpg-error 0.14 was released a few days ago -- Well, I released 1.15 today and removed 1.14 from the ftp server: * This releases fixes problems with the use of off_t and ssize_t by the estream functions introduced with 1.14. Although this is technically an ABI break on some platforms, we take this as a simple bug fix for 1.14. The new functions are very unlikely in use by any code and thus no breakage should happen. The 1.14 tarball will be removed from the archive. * Add type gpgrt_off_t which is guaranteed to be 64 bit. * Add type gpgrt_ssize_t to make use on Windows easier. On Unix platforms this is an alias for ssize_t. > In addition to the addition of estream functionality, the biggest change > i see as a packager is the addition of symbol versioning visibility, > with a version node of GPG_ERROR_1.0. This should have been done much earlier. I must have missed that in the past. > IIUC, this actually moves all the pre-existing symbols from the "Base" > (implicit) version node to the new GPG_ERROR_1.0 version node, which > means that packages built against 0.14 but which only use pre-0.14 > symbols will actually produce a (non-fatal) warning message when run Interesting but I see that this can be a useful warning. > produce a smoother upgrade path. I've tried a couple different > approaches, but none of them worked so i have no patch to propose. The whole purpose of the arning is to tell about possible problems. I do not think that there will be any problems, though. Unfortunatley libgpg-error is used used by Libgcrypt and thus a lot of software will be bugged by this warning. > A) ship 0.14 as-is, with all symbols bound to the new GPG_ERROR_1.0 > version node, and accept that this will force an unnecessarily > strong versioned dependency for packages built against the new > package but only using pre-existing symbols. After all it is only a warning which will should go away after all packages have been rebuild. > Is there a way that we can avoid this tighter versioned dependency and > still avoid the warning messages shown above, or should we just accept > the tight dependency and move forward? I do not think that this is really a dependency. I would fear more the new constructor which adds an atexit callback and uses a lock in the callback. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From simon at josefsson.org Thu Sep 11 22:52:29 2014 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 11 Sep 2014 22:52:29 +0200 Subject: OpenPGP Card ECC status? In-Reply-To: <1410314797.1528.1.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Wed, 10 Sep 2014 11:06:37 +0900") References: <87lhq2qx3l.fsf@latte.josefsson.org> <540592B2.5090207@pietig.com> <87r3zs1jql.fsf@latte.josefsson.org> <87zjefcttt.fsf@vigenere.g10code.de> <8738c1mh2l.fsf@latte.josefsson.org> <1410249296.4075.10.camel@cfw2.gniibe.org> <87tx4ggafz.fsf@latte.josefsson.org> <1410314797.1528.1.camel@cfw2.gniibe.org> Message-ID: <87r3zhswvm.fsf@latte.josefsson.org> NIIBE Yutaka writes: > My memory is not that accurate. I checked the mail archive: Thank you for digging up these pointers! > I think that you can try ECDSA with NIST P-256 with 2.1.x beta. Splendid, I will try it and see what happens. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From dkg at fifthhorseman.net Thu Sep 11 21:04:24 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 11 Sep 2014 15:04:24 -0400 Subject: libgpg-error: man page for gpg-error-config Message-ID: <87bnqmyo5j.fsf@alice.fifthhorseman.net> Hi there-- Debian has been shipping a man page for gpg-error-config with the libgpg-error-dev package. If you think it would be useful to ship with the upstream package, we'd be happy to contribute it so it can be useful to non-debian developers as well. It's attached below. Regards, --dkg -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gpg-error-config.1 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From mailinglisten at hauke-laging.de Fri Sep 12 02:28:14 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 12 Sep 2014 02:28:14 +0200 Subject: bad signature (was: libgpg-error: man page for gpg-error-config) In-Reply-To: <87bnqmyo5j.fsf@alice.fifthhorseman.net> References: <87bnqmyo5j.fsf@alice.fifthhorseman.net> Message-ID: <18323150.oWTro5XuLm@inno> Am Do 11.09.2014, 15:04:24 schrieb Daniel Kahn Gillmor: > Hi there-- KMail shows me a bad signature for this email. Enigmail shows a correct one. Usually I would expect this is a bug in KMail but I cannot verify the signature manually. This should be an easy case: no encoding and a text signature. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From chdiza at gmail.com Fri Sep 12 04:38:35 2014 From: chdiza at gmail.com (Charles Diza) Date: Thu, 11 Sep 2014 22:38:35 -0400 Subject: libgpg-error 1.15 fails to build on MacOSX Message-ID: I just tried building libgpg-error 1.15 on Mac OSX 10.9.4. While version 1.13 had no problems, the attempt to build 1.15 fails with the following error message: /bin/sh ../libtool --tag=CC --mode=compile /usr/bin/clang -DHAVE_CONFIG_H -I. -I.. -DLOCALEDIR=\"/usr/local/Cellar/libgpg-error/1.15/share/locale\" -Os -w -pipe -march=native -mmacosx-version-min=10.9 -Wall -Wpointer-arith -c -o libgpg_error_la-estream.lo `test -f 'estream.c' || echo './'`estream.c libtool: compile: /usr/bin/clang -DHAVE_CONFIG_H -I. -I.. -DLOCALEDIR=\"/usr/local/Cellar/libgpg-error/1.15/share/locale\" -Os -w -pipe -march=native -mmacosx-version-min=10.9 -Wall -Wpointer-arith -c estream.c -fno-common -DPIC -o .libs/libgpg_error_la-estream.o estream.c:3501:1: error: conflicting types for '_gpgrt_fseeko' _gpgrt_fseeko (estream_t stream, gpgrt_off_t offset, int whence) ^ ./gpgrt-int.h:108:5: note: previous declaration is here int _gpgrt_fseeko (gpgrt_stream_t stream, off_t offset, int whence); ^ estream.c:3527:1: error: conflicting types for '_gpgrt_ftello' _gpgrt_ftello (estream_t stream) ^ ./gpgrt-int.h:110:7: note: previous declaration is here off_t _gpgrt_ftello (gpgrt_stream_t stream); ^ 2 errors generated. make[2]: *** [libgpg_error_la-estream.lo] Error 1 make[1]: *** [install] Error 2 make: *** [install-recursive] Error 1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Fri Sep 12 10:34:52 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 12 Sep 2014 10:34:52 +0200 Subject: libgpg-error 1.15 fails to build on MacOSX In-Reply-To: (Charles Diza's message of "Thu, 11 Sep 2014 22:38:35 -0400") References: Message-ID: <87k359s0cz.fsf@vigenere.g10code.de> On Fri, 12 Sep 2014 04:38, chdiza at gmail.com said: > int _gpgrt_fseeko (gpgrt_stream_t stream, off_t offset, int whence); > ^ The fix is obvious; see below. Nevertheless, can you please send me the already generated src/gpg-error.h file (with or without the patch - it won't matter)? Salam-Shalom, Werner commit e1882ee8c541020ec590bf096508ca5b6d2ab944 (HEAD, refs/heads/wk-master) Author: Werner Koch Date: Fri Sep 12 10:33:16 2014 +0200 Fix a prototype * src/gpgrt-int.h: s/off_t/gpgrt_off_t/. Modified src/gpgrt-int.h diff --git a/src/gpgrt-int.h b/src/gpgrt-int.h index 0e6f69c..f97166f 100644 --- a/src/gpgrt-int.h +++ b/src/gpgrt-int.h @@ -105,9 +105,9 @@ void _gpgrt_clearerr_unlocked (gpgrt_stream_t stream); int _gpgrt_fflush (gpgrt_stream_t stream); int _gpgrt_fseek (gpgrt_stream_t stream, long int offset, int whence); -int _gpgrt_fseeko (gpgrt_stream_t stream, off_t offset, int whence); +int _gpgrt_fseeko (gpgrt_stream_t stream, gpgrt_off_t offset, int whence); long int _gpgrt_ftell (gpgrt_stream_t stream); -off_t _gpgrt_ftello (gpgrt_stream_t stream); +gpgrt_off_t _gpgrt_ftello (gpgrt_stream_t stream); void _gpgrt_rewind (gpgrt_stream_t stream); int _gpgrt_fgetc (gpgrt_stream_t stream); -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Sep 12 13:36:37 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 12 Sep 2014 13:36:37 +0200 Subject: Patches gpg-agent + scute for ssl/tls auth using opengpg card with 2048 rsa key In-Reply-To: <5405B564.5090709@incenp.org> (Damien Goutte-Gattat's message of "Tue, 02 Sep 2014 14:17:40 +0200") References: <1661443.XlFuGbBlzz@gamix64> <5405B564.5090709@incenp.org> Message-ID: <877g19rry2.fsf@vigenere.g10code.de> On Tue, 2 Sep 2014 14:17, dgouttegattat at incenp.org said: > According to a bug report in Mozilla?s NSS library [1], the change > introduced by TLS 1.2 is that the data to be signed is no longer a > "MD5+SHA1 hash" (36 bytes, which is the length expected by GPG-Agent), > but is instead an ASN.1 structure representing a DigestInfo object (35 > or 51 bytes total, depending on the hash used). In this case only Scute needs to be changed. gpg-agent's SETHASH expects the raw hash and information on the hash algorithm. The reason why it works anyway with that patch is that some lower level parts of gpg-agemt/scdaemon have less restrictions than SETHASH and remove known ASN.1 prefixes from the hash. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Sep 12 15:50:17 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 12 Sep 2014 15:50:17 +0200 Subject: Patches gpg-agent + scute for ssl/tls auth using opengpg card with 2048 rsa key In-Reply-To: <1661443.XlFuGbBlzz@gamix64> (Oliver Winker's message of "Sun, 31 Aug 2014 12:04:39 +0200") References: <1661443.XlFuGbBlzz@gamix64> Message-ID: <8738bxrlra.fsf@vigenere.g10code.de> On Sun, 31 Aug 2014 12:04, oliverml1 at oli1170.net said: > I prefer to leave the tuning of the details to the specialists ;). Well, I coded something up but did not test it. Can you please apply the attached patch to Scute and try it? No need for any GnuPG patches. Salam-Shalom, Werner >From a797aae1476601cdde7152174c02c5cc4447bcc5 Mon Sep 17 00:00:00 2001 From: Werner Koch Date: Fri, 12 Sep 2014 15:46:41 +0200 Subject: [PATCH] Allow signing with other algorithms than MD5+SHA1. * src/support.h (STR, STR2): NEw. * src/agent.c (sha1_prefix, sha224_prefix, sha256_prefix) (sha384_prefix, sha512_prefix): New. (scute_agent_sign): Increase MAX_DATA_LEN to 64. Determine hash algorithm by checking the ASN.1 prefixes. --- src/agent.c | 105 ++++++++++++++++++++++++++++++++++++++++++--------------- src/support.h | 10 ++++-- 2 files changed, 85 insertions(+), 30 deletions(-) diff --git a/src/agent.c b/src/agent.c index 9265ca2..edf8d2d 100644 --- a/src/agent.c +++ b/src/agent.c @@ -2,7 +2,7 @@ Copyright (C) 2006, 2007, 2008 g10 Code GmbH This file is part of Scute. - + Scute is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or @@ -65,7 +65,7 @@ static int agent_version_minor; /* Hack required for Windows. */ -void +void gnupg_allow_set_foregound_window (pid_t pid) { if (!pid || pid == (pid_t)(-1)) @@ -111,7 +111,7 @@ build_w32_commandline_copy (char *buffer, const char *string) /* Build a command line for use with W32's CreateProcess. On success CMDLINE gets the address of a newly allocated string. */ static gpg_error_t -build_w32_commandline (const char *pgmname, const char * const *argv, +build_w32_commandline (const char *pgmname, const char * const *argv, char **cmdline) { int i, n; @@ -139,7 +139,7 @@ build_w32_commandline (const char *pgmname, const char * const *argv, return gpg_error_from_syserror (); p = build_w32_commandline_copy (p, pgmname); - for (i=0; argv[i]; i++) + for (i=0; argv[i]; i++) { *p++ = ' '; p = build_w32_commandline_copy (p, argv[i]); @@ -161,7 +161,7 @@ spawn_process_detached (const char *pgmname, const char *argv[]) { gpg_error_t err; SECURITY_ATTRIBUTES sec_attr; - PROCESS_INFORMATION pi = + PROCESS_INFORMATION pi = { NULL, /* Returns process handle. */ 0, /* Returns primary thread handle. */ @@ -179,11 +179,11 @@ spawn_process_detached (const char *pgmname, const char *argv[]) memset (&sec_attr, 0, sizeof sec_attr ); sec_attr.nLength = sizeof sec_attr; sec_attr.bInheritHandle = FALSE; - + /* Build the command line. */ err = build_w32_commandline (pgmname, argv, &cmdline); if (err) - return err; + return err; /* Start the process. */ memset (&si, 0, sizeof si); @@ -194,7 +194,7 @@ spawn_process_detached (const char *pgmname, const char *argv[]) cr_flags = (CREATE_DEFAULT_ERROR_MODE | GetPriorityClass (GetCurrentProcess ()) | CREATE_NEW_PROCESS_GROUP - | DETACHED_PROCESS); + | DETACHED_PROCESS); DEBUG (DBG_INFO, "CreateProcess(detached), path=`%s' cmdline=`%s'\n", pgmname, cmdline); if (!CreateProcess (pgmname, /* Program to start. */ @@ -221,7 +221,7 @@ spawn_process_detached (const char *pgmname, const char *argv[]) " dwProcessID=%d dwThreadId=%d\n", pi.hProcess, pi.hThread, (int) pi.dwProcessId, (int) pi.dwThreadId); - CloseHandle (pi.hThread); + CloseHandle (pi.hThread); return 0; } @@ -280,8 +280,8 @@ agent_connect (assuan_context_t *ctx_r) const char *argv[3]; argv[0] = "--daemon"; - argv[1] = "--use-standard-socket"; - argv[2] = NULL; + argv[1] = "--use-standard-socket"; + argv[2] = NULL; err = spawn_process_detached (agent_program, argv); if (err) @@ -306,15 +306,15 @@ agent_connect (assuan_context_t *ctx_r) pgmname = agent_program; else pgmname++; - + argv[0] = pgmname; argv[1] = "--server"; argv[2] = NULL; - + i=0; no_close_list[i++] = assuan_fd_from_posix_fd (fileno (stderr)); no_close_list[i] = -1; - + /* Connect to the agent and perform initial handshaking. */ err = assuan_pipe_connect (ctx, agent_program, argv, no_close_list, NULL, NULL, 0); @@ -353,7 +353,7 @@ agent_connect (assuan_context_t *ctx_r) force_pipe_server = 1; goto restart; } - + err = assuan_socket_connect (ctx, infostr, pid, 0); free (infostr); if (err) @@ -400,7 +400,7 @@ default_inq_cb (void *opaque, const char *line) /* Send a simple command to the agent. */ -static gpg_error_t +static gpg_error_t agent_simple_cmd (assuan_context_t ctx, const char *fmt, ...) { gpg_error_t err; @@ -421,7 +421,7 @@ agent_simple_cmd (assuan_context_t ctx, const char *fmt, ...) DEBUG (DBG_CRIT, "gpg-agent command '%s' failed: %s", optstr, gpg_strerror (err)); free (optstr); - + return err; } @@ -432,7 +432,7 @@ read_version_cb (void *opaque, const void *buffer, size_t length) { char version[20]; const char *s; - + if (length > sizeof (version) -1) length = sizeof (version) - 1; strncpy (version, buffer, length); @@ -444,7 +444,7 @@ read_version_cb (void *opaque, const void *buffer, size_t length) return 0; } - + /* Configure the GPG agent at connection CTX. */ static gpg_error_t @@ -615,7 +615,7 @@ unescape_status_string (const unsigned char *src) while (*src) { if (*src == '%' && src[1] && src[2]) - { + { src++; *dst = xtoi_2 (src); if (*dst == '\0') @@ -631,7 +631,7 @@ unescape_status_string (const unsigned char *src) else *(dst++) = *(src++); } - *dst = 0; + *dst = 0; return buffer; } @@ -894,7 +894,7 @@ geteventcounter_status_cb (void *opaque, const char *line) last_count = count; } } - + return 0; } @@ -989,6 +989,28 @@ pksign_cb (void *opaque, const void *buffer, size_t length) #define SIG_LEN 128 #define SIG_LEN_2 256 + +static unsigned char sha1_prefix[15] = /* (1.3.14.3.2.26) */ + { 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0e, 0x03, + 0x02, 0x1a, 0x05, 0x00, 0x04, 0x14 }; +static unsigned char sha224_prefix[19] = /* (2.16.840.1.101.3.4.2.4) */ + { 0x30, 0x2D, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 0x48, + 0x01, 0x65, 0x03, 0x04, 0x02, 0x04, 0x05, 0x00, 0x04, + 0x1C }; +static unsigned char sha256_prefix[19] = /* (2.16.840.1.101.3.4.2.1) */ + { 0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, + 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05, + 0x00, 0x04, 0x20 }; +static unsigned char sha384_prefix[19] = /* (2.16.840.1.101.3.4.2.2) */ + { 0x30, 0x41, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, + 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02, 0x05, + 0x00, 0x04, 0x30 }; +static unsigned char sha512_prefix[19] = /* (2.16.840.1.101.3.4.2.3) */ + { 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, + 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03, 0x05, + 0x00, 0x04, 0x40 }; + + /* Call the agent to learn about a smartcard. */ gpg_error_t scute_agent_sign (char *grip, unsigned char *data, int len, @@ -996,10 +1018,12 @@ scute_agent_sign (char *grip, unsigned char *data, int len, { char cmd[150]; gpg_error_t err; -#define MAX_DATA_LEN 36 +#define MAX_DATA_LEN 64 /* For SHA-512 - see below. */ unsigned char pretty_data[2 * MAX_DATA_LEN + 1]; int i; struct signature sig; + const char *algostr; + int off; sig.len = 0; @@ -1025,11 +1049,38 @@ scute_agent_sign (char *grip, unsigned char *data, int len, if (err) return err; + /* Find out the digest algorithm and strip off the prefix. */ +#define X(a,b) \ + (len == sizeof a ## _prefix + (b) \ + && !memcmp (data, a ## _prefix, sizeof a ## _prefix)) \ + { \ + algostr = STR(a); \ + off = sizeof a ## _prefix; \ + len -= sizeof a ## _prefix; \ + } + + if (len == 36) + { + algostr = "tls-md5sha1"; + off = 0; + } + else if X(sha1, 20) + else if X(sha224, 28) + else if X(sha256, 32) + else if X(sha384, 48) + else if X(sha512, 64) /* MAX_DATA_LEN must be at least this. */ + else + { + DEBUG (DBG_INFO, "sign input data format is unknown, size=%d\n", len); + return gpg_error (GPG_ERR_DIGEST_ALGO); + } +#undef X + for (i = 0; i < len; i++) - snprintf (&pretty_data[2 * i], 3, "%02X", data[i]); + snprintf (&pretty_data[2 * i], 3, "%02X", data[off+i]); pretty_data[2 * len] = '\0'; - snprintf (cmd, sizeof (cmd), "SETHASH --hash=tls-md5sha1 %s", pretty_data); + snprintf (cmd, sizeof (cmd), "SETHASH --hash=%s %s", algostr, pretty_data); err = assuan_transact (agent_ctx, cmd, NULL, NULL, default_inq_cb, NULL, NULL, NULL); if (err) @@ -1063,8 +1114,8 @@ scute_agent_sign (char *grip, unsigned char *data, int len, memcpy (sig_result, sig.data + SIG_PREFIX_LEN, SIG_LEN); *sig_len = SIG_LEN; } - - + + return 0; } diff --git a/src/support.h b/src/support.h index 8f4d538..f6bb80c 100644 --- a/src/support.h +++ b/src/support.h @@ -2,7 +2,7 @@ Copyright (C) 2006 g10 Code GmbH This file is part of Scute. - + Scute is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or @@ -40,6 +40,10 @@ #define xtoi_2(p) ((xtoi_1(p) * 16) + xtoi_1((p)+1)) #define DIM(x) (sizeof (x) / sizeof (x[0])) +#ifndef STR +# define STR(v) #v +#endif +#define STR2(v) STR(v) /* Copy a string into its location, with blank character padding. */ static inline void @@ -64,7 +68,7 @@ scute_copy_string (char *dest, char *src, int max_len) #ifndef HAVE_TTYNAME /* Systems without ttyname (W32) will merely return NULL. */ static inline char * -ttyname (int fd) +ttyname (int fd) { return NULL; } @@ -96,5 +100,5 @@ const char *default_homedir (void); char *make_filename (const char *first_part, ...); - + #endif /* !SUPPORT_H */ -- 1.7.7.1 -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Fri Sep 12 16:46:41 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 12 Sep 2014 10:46:41 -0400 Subject: libgpg-error symbol visibility In-Reply-To: <8761gut7k8.fsf@vigenere.g10code.de> References: <87egviyvsj.fsf@alice.fifthhorseman.net> <8761gut7k8.fsf@vigenere.g10code.de> Message-ID: <54130751.4030300@fifthhorseman.net> On 09/11/2014 01:01 PM, Werner Koch wrote: > I do not think that this is really a dependency. well, debian packaging tracks symbols and symbol versions, so our systems are likely to treat it as a hard dependency anyway, which i think is probably the right thing for a binary distribution (most users are unlikely to understand what the warning message means or to know how to resolve it). > I would fear more the new constructor which adds an atexit callback and > uses a lock in the callback. Thanks for the heads-up. Can you help me understand more concretely what i should fear here? I'd be happy to try to test for any problems you think might show up for users of the newer versions of libgpg-error. Is the concern a hang on process exit? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Fri Sep 12 17:26:04 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 12 Sep 2014 17:26:04 +0200 Subject: libgpg-error symbol visibility In-Reply-To: <54130751.4030300@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 12 Sep 2014 10:46:41 -0400") References: <87egviyvsj.fsf@alice.fifthhorseman.net> <8761gut7k8.fsf@vigenere.g10code.de> <54130751.4030300@fifthhorseman.net> Message-ID: <87lhporhbn.fsf@vigenere.g10code.de> On Fri, 12 Sep 2014 16:46, dkg at fifthhorseman.net said: > well, debian packaging tracks symbols and symbol versions, so our > systems are likely to treat it as a hard dependency anyway, which i Frankly, that was new to me. I have always taken care to mark ABI changes but I didn't expected a problem by adding visibility. Sorry for the problems. The only other solution I can think of is to rename libgpg-error to librt which would be a better name anyway. But that also introduces a lot of work. >> I would fear more the new constructor which adds an atexit callback and >> uses a lock in the callback. > > Thanks for the heads-up. Can you help me understand more concretely > what i should fear here? I'd be happy to try to test for any problems Found and fixed a related one today ;-). There is a constructor which initializes the estream library (on systems which support constructors). This involves setting up an atexit handler. This should not be a problem unless an application is already close to the limit of registered atexit handlers. The problem might be on shutdown where the cleanup calls gpgrt_fflush (NULL), which in turn needs to employ an gpgrt global lock to walk the list of streams. That is list of course empty if estream functions have not been used, but nevertheless a lock is taken and released. That is some extra code run before process termination. Should not harm, but that might be famous last words. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Fri Sep 12 17:54:49 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 12 Sep 2014 11:54:49 -0400 Subject: libgpg-error symbol visibility In-Reply-To: <87lhporhbn.fsf@vigenere.g10code.de> References: <87egviyvsj.fsf@alice.fifthhorseman.net> <8761gut7k8.fsf@vigenere.g10code.de> <54130751.4030300@fifthhorseman.net> <87lhporhbn.fsf@vigenere.g10code.de> Message-ID: <54131749.7020908@fifthhorseman.net> On 09/12/2014 11:26 AM, Werner Koch wrote: > On Fri, 12 Sep 2014 16:46, dkg at fifthhorseman.net said: > >> well, debian packaging tracks symbols and symbol versions, so our >> systems are likely to treat it as a hard dependency anyway, which i > > Frankly, that was new to me. I have always taken care to mark ABI > changes but I didn't expected a problem by adding visibility. Sorry > for the problems. No worries -- you're one of the more conscientious upstreams in this way, and if everyone marked ABI changes as clearly as you do, we might never have bothered to implement symbol tracking. That isn't the universe we live in, though :) Also, i note that you're exporting the following 4 symbols with leading underscores: _gpgrt_set_std_fd; _gpgrt_get_std_stream; _gpgrt_getc_underflow; _gpgrt_putc_overflow; They're also in gpg-error.h. I'm used to a convention where a symbol with a leading underscore is "private" or internal, and i would try to avoid exporting it from a shared library. Is this something i should be concerned about? If other _-prefixed functions show up in the list of exported symbols by accident, should i report them as a concern? > The only other solution I can think of is to rename > libgpg-error to librt which would be a better name anyway. But that > also introduces a lot of work. Yeah, a rename of the library sounds even more invasive, and probably not a good thing for debian at this stage of the release cycle (we hope to freeze in the next two months). Out of curiosity -- why "rt"? And while i'm on the human-understanding kick: I think the README is out-of-date with the recent changes, and could probably use a brief update. > Found and fixed a related one today ;-). Can you point me toward that fix? It would help me to understand the problem more clearly. > There is a constructor which initializes the estream library (on systems > which support constructors). This involves setting up an atexit > handler. This should not be a problem unless an application is already > close to the limit of registered atexit handlers. In this scenario, the gpg-error atexit handler wouldn't get called, right? Unless gpg-error is initialized early, in which case some other atexit() handler might be the one that falls off the stack. > The problem might be > on shutdown where the cleanup calls gpgrt_fflush (NULL), which in turn > needs to employ an gpgrt global lock to walk the list of streams. That > is list of course empty if estream functions have not been used, but > nevertheless a lock is taken and released. That is some extra code run > before process termination. Should not harm, but that might be famous > last words. OK, i'll keep an eye out for it. Thanks for the explanation, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From ametzler at bebt.de Fri Sep 12 18:50:11 2014 From: ametzler at bebt.de (Andreas Metzler) Date: Fri, 12 Sep 2014 18:50:11 +0200 Subject: libgpg-error symbol visibility References: <87egviyvsj.fsf@alice.fifthhorseman.net> Message-ID: <1rkbeb-vcc.ln1@argenau.downhill.at.eu.org> In gmane.comp.encryption.gpg.devel Daniel Kahn Gillmor wrote: [...] > In addition to the addition of estream functionality, the biggest change > i see as a packager is the addition of symbol versioning visibility, > with a version node of GPG_ERROR_1.0. > IIUC, this actually moves all the pre-existing symbols from the "Base" > (implicit) version node to the new GPG_ERROR_1.0 version node, which > means that packages built against 0.14 but which only use pre-0.14 > symbols will actually produce a (non-fatal) warning message when run > against a pre-0.14 version of libgpg-error. For example: > 0 dkg at alice:~$ echo test | gpg2 --encrypt -r $PGPID > tmp/test.pgp > gpg2: /lib/x86_64-linux-gnu/libgpg-error.so.0: no version information available (required by gpg2) > 0 dkg at alice:~$ > I don't know enough about symbol versioning to know if there's a way to > produce a smoother upgrade path. I've tried a couple different > approaches, but none of them worked so i have no patch to propose. > I'm trying to prepare this version for upload to Debian before we freeze > (soon!), and i want to make sure that we're doing the right thing with > it. At the moment, i'm looking for alternatives to the default option: > A) ship 0.14 as-is, with all symbols bound to the new GPG_ERROR_1.0 > version node, and accept that this will force an unnecessarily > strong versioned dependency for packages built against the new > package but only using pre-existing symbols. > Is there a way that we can avoid this tighter versioned dependency and > still avoid the warning messages shown above, or should we just accept > the tight dependency and move forward? Hello, I think that is the correct thing to do, and it should not bother us at Debian a lot. Our users will never see the warning message since packages built against the newer gpg-error will depend on it and packages built against the old one will not show the warning either. (I have not actually run any tests to verify this, but I guess you did.) > The tight versioned dependency will make backporting packages that > depend on libgpg-error slightly more painful, but it's probably not a > terrible thing. Afaiui this will not not complicate backporting either. Backports of libgpg-error using packages will be built against the native (older) libgpg-error version. That is unless they require features from the newer libgpg-error. Then somebody will need to provide a backport of that package first and the backport will be built against it and wil depend on it. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From dkg at fifthhorseman.net Fri Sep 12 19:25:48 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 12 Sep 2014 13:25:48 -0400 Subject: [Pkg-gnupg-maint] libgpg-error symbol visibility In-Reply-To: <1rkbeb-vcc.ln1@argenau.downhill.at.eu.org> References: <87egviyvsj.fsf@alice.fifthhorseman.net> <1rkbeb-vcc.ln1@argenau.downhill.at.eu.org> Message-ID: <54132C9C.5010701@fifthhorseman.net> On 09/12/2014 12:50 PM, Andreas Metzler wrote: > In gmane.comp.encryption.gpg.devel Daniel Kahn Gillmor wrote: >> Is there a way that we can avoid this tighter versioned dependency and >> still avoid the warning messages shown above, or should we just accept >> the tight dependency and move forward? > > I think that is the correct thing to do, and it should not bother > us at Debian a lot. Our users will never see the warning message since > packages built against the newer gpg-error will depend on it and > packages built against the old one will not show the warning either. > (I have not actually run any tests to verify this, but I guess you > did.) Thanks for weighing in on this, Andreas, it's good to have your perspective. I did indeed test these different scenarios, and they play out as you describe. Unless someone from Debian's pkg-gnupg team speaks up with new concerns today, i'll probably go ahead with an upload of 1.15 to debian unstable tomorrow. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Fri Sep 12 20:35:03 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 12 Sep 2014 20:35:03 +0200 Subject: libgpg-error symbol visibility In-Reply-To: <54131749.7020908@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 12 Sep 2014 11:54:49 -0400") References: <87egviyvsj.fsf@alice.fifthhorseman.net> <8761gut7k8.fsf@vigenere.g10code.de> <54130751.4030300@fifthhorseman.net> <87lhporhbn.fsf@vigenere.g10code.de> <54131749.7020908@fifthhorseman.net> Message-ID: <87r3zgpu08.fsf@vigenere.g10code.de> On Fri, 12 Sep 2014 17:54, dkg at fifthhorseman.net said: > I'm used to a convention where a symbol with a leading underscore is > "private" or internal, and i would try to avoid exporting it from a > shared library. Is this something i should be concerned about? If No, these are on purpose. Two are the helper functions for getc and putc macros, _gpgrt_get_std_stream is used to implement gpgrt_stdin et al. macros and _gpgrt_set_std_fd is only used for WindowsCE but exported anyway maybe for regression tests or such. > other _-prefixed functions show up in the list of exported symbols by > accident, should i report them as a concern? If you notice them, please report. > Out of curiosity -- why "rt"? And while i'm on the human-understanding > kick: I think the README is out-of-date with the recent changes, and > could probably use a brief update. "rt" = RunTime support for gpg. There is quite some code source copied by all gnupg related libraries which benefit from being in a library of its own. The real reason why this will eventually be needed (in particular file related functions) is that there is plan for native Windows 64 support. Over there we have the problem that a Windows HANDLE does not fit into an "int" bug we need a common object for sockets and fds and sometimes HANDLES. Even the current code for 32 bit Windows is hard to debug and at some places we have more or less to guess what kind of object this is and call the appropriate function. A common runtime layer will help with portability. > Can you point me toward that fix? It would help me to understand the > problem more clearly. http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=commitdiff;h=c307e1f801cd9a25c4a5b9a90073362219d52ee6 And look into estream.c:do_close > In this scenario, the gpg-error atexit handler wouldn't get called, > right? Unless gpg-error is initialized early, in which case some other > atexit() handler might be the one that falls off the stack. I general yes, unless other libs are using a constructor with atexit. But I doubt that this will ever happen. We would have more problems than just libgpg-error. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Fri Sep 12 20:53:37 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 12 Sep 2014 14:53:37 -0400 Subject: libgpg-error symbol visibility In-Reply-To: <87r3zgpu08.fsf@vigenere.g10code.de> References: <87egviyvsj.fsf@alice.fifthhorseman.net> <8761gut7k8.fsf@vigenere.g10code.de> <54130751.4030300@fifthhorseman.net> <87lhporhbn.fsf@vigenere.g10code.de> <54131749.7020908@fifthhorseman.net> <87r3zgpu08.fsf@vigenere.g10code.de> Message-ID: <54134131.4050705@fifthhorseman.net> On 09/12/2014 02:35 PM, Werner Koch wrote: >> > Can you point me toward that fix? It would help me to understand the >> > problem more clearly. > http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=commitdiff;h=c307e1f801cd9a25c4a5b9a90073362219d52ee6 > > And look into estream.c:do_close Thanks. I'm inclined to pull that patch into the version of 1.15 that i'm preparing for debian. Please let me know if there's some reason that i shouldn't do so. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From oliverml1 at oli1170.net Fri Sep 12 21:07:48 2014 From: oliverml1 at oli1170.net (Oliver Winker) Date: Fri, 12 Sep 2014 21:07:48 +0200 Subject: Patches gpg-agent + scute for ssl/tls auth using opengpg card with 2048 rsa key In-Reply-To: <8738bxrlra.fsf@vigenere.g10code.de> References: <1661443.XlFuGbBlzz@gamix64> <8738bxrlra.fsf@vigenere.g10code.de> Message-ID: <1453200.jdloHsaW1l@gamix64> Hi Werner, Just made a test using a scute-1.4.0 with your patch applied and an unpatched gnupg2-2.0.26, but it didn't work: Iceweasel: --- A PKCS #11 module returned CKR_FUNCTION_FAILED, indicating that the requested function could not be performed. Trying the same operation again might succeed. --- Also still tried then with my patched gnupg2-2.0.26, but same result. Probably it fails somewhere inside scute. Unfortunately probably I'll won't have so much time during this weekend, but I could try to trace it during next week. Last time I used the SCUTE_DEBUG facility and via stracing iceweasel, gpg-agent and scdaemon one could get already some view on the messaging. Best Regards, Oliver On Friday 12 September 2014 15:50:17 Werner Koch wrote: > On Sun, 31 Aug 2014 12:04, oliverml1 at oli1170.net said: > > I prefer to leave the tuning of the details to the specialists ;). > > Well, I coded something up but did not test it. Can you please apply > the attached patch to Scute and try it? No need for any GnuPG patches. > > > Salam-Shalom, > > Werner > > >From a797aae1476601cdde7152174c02c5cc4447bcc5 Mon Sep 17 00:00:00 2001 > > From: Werner Koch > Date: Fri, 12 Sep 2014 15:46:41 +0200 > Subject: [PATCH] Allow signing with other algorithms than MD5+SHA1. > > * src/support.h (STR, STR2): NEw. > * src/agent.c (sha1_prefix, sha224_prefix, sha256_prefix) > (sha384_prefix, sha512_prefix): New. > (scute_agent_sign): Increase MAX_DATA_LEN to 64. Determine hash > algorithm by checking the ASN.1 prefixes. > --- From dgouttegattat at incenp.org Sat Sep 13 03:32:45 2014 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sat, 13 Sep 2014 03:32:45 +0200 Subject: Patches gpg-agent + scute for ssl/tls auth using opengpg card with 2048 rsa key In-Reply-To: <8738bxrlra.fsf@vigenere.g10code.de> References: <1661443.XlFuGbBlzz@gamix64> <8738bxrlra.fsf@vigenere.g10code.de> Message-ID: <54139EBD.9090102@incenp.org> On 09/12/2014 03:50 PM, Werner Koch wrote: > Well, I coded something up but did not test it. Can you please apply > the attached patch to Scute and try it? No need for any GnuPG patches. I have applied the patch and tried, but it does not work with an unpatched GnuPG 2.0.26. Here is a trace of the dialog between Gpg-agent and Scute (chan_8), and between Gpg-agent and Scdaemon (chan_9): gpg-agent[1443]: chan_8 <- SIGKEY 379926AD[truncated] gpg-agent[1443]: chan_8 -> OK gpg-agent[1443]: chan_8 <- SETHASH --hash=3Dsha256 C318621C[truncated] gpg-agent[1443]: chan_8 -> OK gpg-agent[1443]: chan_8 <- PKSIGN gpg-agent[1443]: chan_9 -> SERIALNO gpg-agent[1443]: chan_9 <- S SERIALNO D2760001240102000005000019B60000 0 gpg-agent[1443]: chan_9 <- OK gpg-agent[1443]: chan_9 -> SETDATA 3031300D[truncated] gpg-agent[1443]: chan_9 <- OK gpg-agent[1443]: chan_9 -> PKSIGN OPENPGP.3 gpg-agent[1443]: chan_9 <- ERR 100663351 Invalid value gpg-agent[1443] smartcard signing failed: Invalid value gpg-agent[1443] command pksign failed: Invalid value gpg-agent[1443]: chan_8 -> ERR 100663351 Invalid value I believe that the second PKISGN command (the one sent by Gpg-agent to Scdaemon) should be `PKSIGN --sha256 OPENPGP.3', so that the daemon would know to expect a SHA256 value. This problem seems to have been fixed already in master branch by the following commit: commit 1c09def22d97de3738a2bec4970504bfc155680b Author: Werner Koch Fix usage of SHA-2 algorithm with OpenPGP cards. I have not tested with the master branch, but I backported that commit to the 2.0.26 release (patch below for anyone interested), and it works. Damien -- >8 -- From 431f4a3e4db197a663264d628cd7db4b0352f64c Mon Sep 17 00:00:00 2001 From: Damien Goutte-Gattat Date: Sun, 7 Sep 2014 13:53:13 +0200 Subject: [PATCH] Fix usage of SHA-2 algorithm with OpenPGP cards. Backport commit 1c09def22d97de3738a2bec4970504bfc155680b into the 2.0.26 version. diff --git a/agent/agent.h b/agent/agent.h index 938a9aa..2c8dc75 100644 --- a/agent/agent.h +++ b/agent/agent.h @@ -370,6 +370,7 @@ int agent_card_pksign (ctrl_t ctrl, const char *keyid, int (*getpin_cb)(void *, const char *, char*, size_t), void *getpin_cb_arg, + int mdalgo, const unsigned char *indata, size_t indatalen, unsigned char **r_buf, size_t *r_buflen); int agent_card_pkdecrypt (ctrl_t ctrl, diff --git a/agent/call-scd.c b/agent/call-scd.c index 9a2e65e..9785696 100644 --- a/agent/call-scd.c +++ b/agent/call-scd.c @@ -804,13 +804,32 @@ inq_needpin (void *opaque, const char *line) } +/* Helper returning a command option to describe the used hash + algorithm. See scd/command.c:cmd_pksign. */ +static const char * +hash_algo_option (int algo) +{ + switch (algo) + { + case GCRY_MD_MD5 : return "--hash=md5"; + case GCRY_MD_RMD160: return "--hash=rmd160"; + case GCRY_MD_SHA1 : return "--hash=sha1"; + case GCRY_MD_SHA224: return "--hash=sha224"; + case GCRY_MD_SHA256: return "--hash=sha256"; + case GCRY_MD_SHA384: return "--hash=sha384"; + case GCRY_MD_SHA512: return "--hash=sha512"; + default: return ""; + } +} -/* Create a signature using the current card */ +/* Create a signature using the current card. MDALGO is either 0 or + gives the digest algorithm. */ int agent_card_pksign (ctrl_t ctrl, const char *keyid, int (*getpin_cb)(void *, const char *, char*, size_t), void *getpin_cb_arg, + int mdalgo, const unsigned char *indata, size_t indatalen, unsigned char **r_buf, size_t *r_buflen) { @@ -844,8 +863,11 @@ agent_card_pksign (ctrl_t ctrl, inqparm.getpin_cb = getpin_cb; inqparm.getpin_cb_arg = getpin_cb_arg; inqparm.passthru = 0; - snprintf (line, DIM(line)-1, - ctrl->use_auth_call? "PKAUTH %s":"PKSIGN %s", keyid); + if (ctrl->use_auth_call) + snprintf (line, DIM(line)-1, "PKAUTH %s", keyid); + else + snprintf (line, DIM(line)-1, "PKSIGN %s %s", + hash_algo_option (mdalgo), keyid); line[DIM(line)-1] = 0; rc = assuan_transact (ctrl->scd_local->ctx, line, membuf_data_cb, &data, diff --git a/agent/divert-scd.c b/agent/divert-scd.c index 1f36f6e..ee5bcc7 100644 --- a/agent/divert-scd.c +++ b/agent/divert-scd.c @@ -347,7 +347,7 @@ divert_pksign (ctrl_t ctrl, int save = ctrl->use_auth_call; ctrl->use_auth_call = 1; rc = agent_card_pksign (ctrl, kid, getpin_cb, ctrl, - digest, digestlen, &sigval, &siglen); + algo, digest, digestlen, &sigval, &siglen); ctrl->use_auth_call = save; } else @@ -359,7 +359,7 @@ divert_pksign (ctrl_t ctrl, if (!rc) { rc = agent_card_pksign (ctrl, kid, getpin_cb, ctrl, - data, ndata, &sigval, &siglen); + algo, data, ndata, &sigval, &siglen); xfree (data); } } -- 1.8.4 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Sat Sep 13 12:35:37 2014 From: wk at gnupg.org (Werner Koch) Date: Sat, 13 Sep 2014 12:35:37 +0200 Subject: Patches gpg-agent + scute for ssl/tls auth using opengpg card with 2048 rsa key In-Reply-To: <1453200.jdloHsaW1l@gamix64> (Oliver Winker's message of "Fri, 12 Sep 2014 21:07:48 +0200") References: <1661443.XlFuGbBlzz@gamix64> <8738bxrlra.fsf@vigenere.g10code.de> <1453200.jdloHsaW1l@gamix64> Message-ID: <87lhpnolja.fsf@vigenere.g10code.de> On Fri, 12 Sep 2014 21:07, oliverml1 at oli1170.net said: > Just made a test using a scute-1.4.0 with your patch applied and an unpatched > gnupg2-2.0.26, but it didn't work: Okay, I need to setup my debug environemt for Scute. I make take some time, sorry. Any help appreciated, of course. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From oliverml1 at oli1170.net Sat Sep 13 15:33:47 2014 From: oliverml1 at oli1170.net (Oliver Winker) Date: Sat, 13 Sep 2014 15:33:47 +0200 Subject: Patches gpg-agent + scute for ssl/tls auth using opengpg card with 2048 rsa key In-Reply-To: <87lhpnolja.fsf@vigenere.g10code.de> References: <1661443.XlFuGbBlzz@gamix64> <1453200.jdloHsaW1l@gamix64> <87lhpnolja.fsf@vigenere.g10code.de> Message-ID: <2131386.sBRzrlKPhV@gamix64> Hi Werner, On Saturday 13 September 2014 12:35:37 Werner Koch wrote: > On Fri, 12 Sep 2014 21:07, oliverml1 at oli1170.net said: > > Just made a test using a scute-1.4.0 with your patch applied and an > > unpatched > > gnupg2-2.0.26, but it didn't work: > Okay, I need to setup my debug environemt for Scute. I make take some > time, sorry. Any help appreciated, of course. Damien has also still looked into it, and it seems to work. I didn't try yet my self. For the debug env, it's basically an apache ssl/tls setup with client auth. Just for info, for the pki: in case you setup a test-ce using xca + openssl 1.0.1i, there is a patch here to make it work: http://sourceforge.net/p/xca/patches/14/ I can still provide more details in the course of the week, if required. Best Regards, Oliver From dgouttegattat at incenp.org Sat Sep 13 21:35:55 2014 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sat, 13 Sep 2014 21:35:55 +0200 Subject: Patches gpg-agent + scute for ssl/tls auth using opengpg card with 2048 rsa key In-Reply-To: <2131386.sBRzrlKPhV@gamix64> References: <1661443.XlFuGbBlzz@gamix64> <1453200.jdloHsaW1l@gamix64> <87lhpnolja.fsf@vigenere.g10code.de> <2131386.sBRzrlKPhV@gamix64> Message-ID: <54149C9B.3020603@incenp.org> On 09/13/2014 03:33 PM, Oliver Winker wrote: > For the debug env, it's basically an apache ssl/tls setup with client auth. Same here, but I also performed some tests with the tools provided with GnuTLS and OpenSSL, which comes in handy if you don't have a running web server around. For example, with GnuTLS: $ gnutls-serv --http --port=8000 \ --x509certfile=server-cert.pem --x509keyfile=server-key.pem \ --require-client-cert --x509cafile=client-ca-cert.pem And with OpenSSL: $ openssl s_server -HTTP -accept 8000 \ --cert server-cert.pem --key server-key.pem \ --Verify 1 -CAfile client-ca-cert.pem Both commands start a web server that will listen on localhost port 8000 and will expect a client to present a certificate signed by `client-ca-cert.pem'. Yet another option is to use Thunderbird: configure it to use Scute as a Security Device the same way you do with Firefox, then send to yourself a mail that you will attempt to sign (using S/MIME, *not* OpenPGP) with your card-based certificate. That's even simpler than the above, since you do not need to generate a server certificate at all. Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From eric at debian.org Mon Sep 15 05:54:49 2014 From: eric at debian.org (Eric Dorland) Date: Sun, 14 Sep 2014 23:54:49 -0400 Subject: Debian GnuPG BoF video at DebConf 14 Message-ID: <20140915035449.GY24040@gambit> Hi Werner et al, It may be of interest to the wider GnuPG development community, there was a BoF on GnuPG in Debian at DebConf 14 a couple of weeks ago. There's a video of it available here: http://meetings-archive.debian.net/pub/debian-meetings/2014/debconf14/webm/GnuPG_in_Debian_BoF.webm. One thing that came out of the discussion was a fair amount of consensus that we should move gnupg2 as the default. Also we're hoping to get gnupg2.1 into experimental to try to get more testing and work out any upgrade issues. And Werner, in case you don't watch the video, near the end someone asks if we could invite you to next year's DebConf. I think that's a great idea. DebConf 15 will take place in Heidelberg August 15-22. While it's a bit early to start planning, we hope you can come. -- Eric Dorland 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From f.schwind at chili-radiology.com Mon Sep 15 09:24:40 2014 From: f.schwind at chili-radiology.com (Florian Schwind) Date: Mon, 15 Sep 2014 09:24:40 +0200 Subject: GPGME 1.5.1: Invalid crypto engine Message-ID: <54169438.5030804@chili-radiology.com> Hi, after building GPGME on SuSE SLES 10 I ran make check an got some "Invalid crypto engine" errors. make check Making check in src make[1]: Entering directory `/tmp/cbs-compile-cbuild/gpgme-1.5.1/src' make[1]: F?r das Ziel ?check? ist nichts zu tun. make[1]: Leaving directory `/tmp/cbs-compile-cbuild/gpgme-1.5.1/src' Making check in tests make[1]: Entering directory `/tmp/cbs-compile-cbuild/gpgme-1.5.1/tests' Making check in gpg make[2]: Entering directory `/tmp/cbs-compile-cbuild/gpgme-1.5.1/tests/gpg' make check-TESTS make[3]: Entering directory `/tmp/cbs-compile-cbuild/gpgme-1.5.1/tests/gpg' starting gpg-agent error starting gpg-agent PASS: initial.test t-support.h:134: GPGME: Invalid crypto engine FAIL: t-encrypt t-support.h:134: GPGME: Invalid crypto engine FAIL: t-encrypt-sym t-support.h:134: GPGME: Invalid crypto engine FAIL: t-encrypt-sign t-support.h:134: GPGME: Invalid crypto engine FAIL: t-sign t-support.h:134: GPGME: Invalid crypto engine FAIL: t-signers t-support.h:134: GPGME: Invalid crypto engine FAIL: t-decrypt t-support.h:134: GPGME: Invalid crypto engine FAIL: t-verify t-support.h:134: GPGME: Invalid crypto engine FAIL: t-decrypt-verify t-support.h:134: GPGME: Invalid crypto engine FAIL: t-sig-notation t-support.h:134: GPGME: Invalid crypto engine FAIL: t-export t-support.h:134: GPGME: Invalid crypto engine FAIL: t-import t-support.h:134: GPGME: Invalid crypto engine FAIL: t-trustlist t-support.h:134: GPGME: Invalid crypto engine FAIL: t-edit t-support.h:134: GPGME: Invalid crypto engine FAIL: t-keylist t-support.h:134: GPGME: Invalid crypto engine FAIL: t-keylist-sig t-support.h:134: GPGME: Invalid crypto engine FAIL: t-wait t-support.h:134: GPGME: Invalid crypto engine FAIL: t-encrypt-large t-support.h:134: GPGME: Invalid crypto engine FAIL: t-file-name PASS: t-gpgconf t-support.h:134: GPGME: Invalid crypto engine FAIL: t-eventloop t-support.h:134: GPGME: Invalid crypto engine FAIL: t-thread1 gpg-agent not running PASS: final.test ====================================== 20 of 23 tests failed Please report to http://bugs.gnupg.org ====================================== Digging deeper into the problem I found out, that gpgme only finds one crypto-engine at /usr/bin/gpgconf, which could not be used as engine for OpenGPG. Calling the function gpgme_set_engine_info(GPGME_PROTOCOL_OpenPGP, "/usr/bin/gpg", NULL) in a testprogram shows, that even then only one crypto-engine is found and the path to /usr/bin/gpg is ignored because gpgme_get_engine_info(&info) only returns the GPGCONF engine. I tried this on several other linux system like SLES 11, SLES 9, OpenSuse 11.3 (32 and 64 bit) and everything works ok. I'm really puzzled what I'd doing wrong on SLES 10. This could not only be a problem in my software by using the API in a wrong way, because the "make check" fails as well. I added some debug output and also exported GPGME_DEBUG which did only help to narrow down to problem to the file engine.c and the call of engine_get_file_name (proto_list[proto]), which returns NULL for the OpenGPG protocol. I'm using the newest versions available: GPGME 1.5.1, GPG 1.4.18 and LIBGPG-ERR 1.14. Does anyone have an idea how to proceed? Regards Florian P.S.: I omitted the gpgme_debug.log because at first try my message was rejected from the list because the logfile was too large. From wk at gnupg.org Tue Sep 16 16:59:16 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 16 Sep 2014 16:59:16 +0200 Subject: Debian GnuPG BoF video at DebConf 14 In-Reply-To: <20140915035449.GY24040@gambit> (Eric Dorland's message of "Sun, 14 Sep 2014 23:54:49 -0400") References: <20140915035449.GY24040@gambit> Message-ID: <87wq93ipbv.fsf@vigenere.g10code.de> On Mon, 15 Sep 2014 05:54, eric at debian.org said: > there was a BoF on GnuPG in Debian at DebConf 14 a couple of > weeks ago. There's a video of it available here: Thanks. > consensus that we should move gnupg2 as the default. Also we're hoping > to get gnupg2.1 into experimental to try to get more testing and work > out any upgrade issues. Great. But be aware of gnome-keyring-daemon; you may want to change the defaults. > great idea. DebConf 15 will take place in Heidelberg August > 15-22. While it's a bit early to start planning, we hope you can come. I would really like to come, yet not on the 15th. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From djhaskin987 at gmail.com Thu Sep 18 02:25:21 2014 From: djhaskin987 at gmail.com (Daniel Jay Haskin) Date: Wed, 17 Sep 2014 18:25:21 -0600 Subject: No subject Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I have noticed that gnupg 2.1 has been in beta for four years. I have also seen Werner say on this mailing list that he has used 2.1 "for years now". I wonder if there is a measure by which the four-year-old version shall be considered stable. If so, what is it? If not, or if there is a reason other than a technical reason for not calling it stable, it makes me feel like a four year old branch, having had many bug fixes, is ready for production no matter matter what we call it. I realize my view is probably uneducated, and I only bring this up because I am truly curious. If anyone can supply explanation, I'm all ears :) Thanks - -- Daniel Jay Haskin http://djhaskin987.github.io/ -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQJdBAEBCgBHBQJUGiZxQBxEYW5pZWwgSmF5IEhhc2tpbiAoUlNBIFBvc3QtSGVh cnRibGVlZCkgPGRqaGFza2luOTg3QGdtYWlsLmNvbT4ACgkQ1i2qPggOF6m3lBAA oUpnBvsd4uTzyvpS0lxnC0R/6TETlf8+u28WQqT1OxkDjnDZ6GmCSCPpDfWQiIjR woZgNOZqckrIeCCS7Hxowix90rIkwmkf6nrFCV+FtgL165lWaO0g2PV9k4DYOZW4 RBn1rgpibEX9lHhIcXxiVrW785nkLtkKXPx9D4Fd2qHsbmMYnBJGUfJ38EvT0Pmk QODklboOogTqebuRTdxvlcyoKdtGwbm2Qlgxw4tWf7pzBBV38cgpudYDywx4ry8Z LSozCsakyTVusHufTMWnunXfxXZ7WNSbkwWG0OgrVc2aRnFBrsmOaVwINtq+aTLu zf21ISCzMkmACtkeZtFJGO6ien8ctOlQ6JeDTRmKvoZQWWh09Zx/sPwAF9e3kWL4 7ak8dhKkeQ1dWLun4LY/vQ2l/nkuumrpKTW/JjuBB6bfzQYlHTJlulDYCz/5uSQX ST7ODdgWierd+3SZOn2QkgqCfKNMyU+NDWYLL0VEe/pSmPbCdQDd/Gz9J3sSbCUL VFnB9rpe39HdbDl+ZFj+9DRfZZuTZnCVAzmY4IVz9HuAZu2wJnUwbAec/6bW+tAp /22M8ai/YWka79Vmx/2dA/CnuhI99MTrT6rZR8A/vh2FGk+5z2xGGooGXFzBm8b8 WSuzMsxl9vhPy7PKRJv1FcMCurf+lyLbx891tPQftoI= =QU5+ -----END PGP SIGNATURE----- From wk at gnupg.org Fri Sep 19 10:49:25 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 19 Sep 2014 10:49:25 +0200 Subject: Why 2.1 is delayed for so long (was: none) In-Reply-To: (Daniel Jay Haskin's message of "Wed, 17 Sep 2014 18:25:21 -0600") References: Message-ID: <871tr86lm2.fsf@vigenere.g10code.de> On Thu, 18 Sep 2014 02:25, djhaskin987 at gmail.com said: > also seen Werner say on this mailing list that he has used 2.1 "for > years now". I wonder if there is a measure by which the four-year-old > version shall be considered stable. If so, what is it? If not, or if Never change a running system (i.e. 1.4). I am glad to see that after 11 years 2.0 is now going mainstream. I assume that 2.1 will be be adopted faster because it has improvements which are fashionable now; in particular ECC. However, ECC is also one of the problems why 2.1 is delayed. The plan is to implement the new non-TLA created ECC curves (Curve255519). Last fall it looked that the IETF would fast adopt they as standards but they keep on debating. Thus the likely outcome is that 2.1 will be released without an official IETF standard for the new curves. I did a new beta yesterday but my experience with beta versions is that they are not widely used or problems/success are not reported. To move forward we might have to jump into cold water and release 2.1 without having many test results. And I need to set aside enough time to quickly work on reported problems after 2.1.0. Thus all other construction areas should be cleaned up before. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From infinity0 at pwned.gg Fri Sep 19 14:30:37 2014 From: infinity0 at pwned.gg (Ximin Luo) Date: Fri, 19 Sep 2014 13:30:37 +0100 Subject: Why 2.1 is delayed for so long In-Reply-To: <871tr86lm2.fsf@vigenere.g10code.de> References: <871tr86lm2.fsf@vigenere.g10code.de> Message-ID: <541C21ED.2090602@pwned.gg> On 19/09/14 09:49, Werner Koch wrote: > On Thu, 18 Sep 2014 02:25, djhaskin987 at gmail.com said: > >> also seen Werner say on this mailing list that he has used 2.1 "for >> years now". I wonder if there is a measure by which the four-year-old >> version shall be considered stable. If so, what is it? If not, or if > > Never change a running system (i.e. 1.4). I am glad to see that after > 11 years 2.0 is now going mainstream. > > I assume that 2.1 will be be adopted faster because it has improvements > which are fashionable now; in particular ECC. However, ECC is also one > of the problems why 2.1 is delayed. The plan is to implement the new > non-TLA created ECC curves (Curve255519). Last fall it looked that the > IETF would fast adopt they as standards but they keep on debating. Thus > the likely outcome is that 2.1 will be released without an official IETF > standard for the new curves. > > I did a new beta yesterday but my experience with beta versions is that > they are not widely used or problems/success are not reported. To move > forward we might have to jump into cold water and release 2.1 without > having many test results. And I need to set aside enough time to > quickly work on reported problems after 2.1.0. Thus all other > construction areas should be cleaned up before. > FWIW I would be happy to help test, if someone makes a Debian package for gnupg 2.1. I might do that myself this weekend. Let me know if there's any significant installation differences between 2.0 and 2.1. Is the data format for EdDSA keys now final? X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Fri Sep 19 16:35:45 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 19 Sep 2014 10:35:45 -0400 Subject: Why 2.1 is delayed for so long In-Reply-To: <541C21ED.2090602@pwned.gg> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> Message-ID: <541C3F41.3050107@fifthhorseman.net> [cc'ing debian's pkg-gnupg-maint mailing list, since this discussion is relevant there] On 09/19/2014 08:30 AM, Ximin Luo wrote: > On 19/09/14 09:49, Werner Koch wrote: >> On Thu, 18 Sep 2014 02:25, djhaskin987 at gmail.com said: >> >>> also seen Werner say on this mailing list that he has used 2.1 "for >>> years now". I wonder if there is a measure by which the four-year-old >>> version shall be considered stable. If so, what is it? If not, or if >> >> Never change a running system (i.e. 1.4). I am glad to see that after >> 11 years 2.0 is now going mainstream. >> >> I assume that 2.1 will be be adopted faster because it has improvements >> which are fashionable now; in particular ECC. However, ECC is also one >> of the problems why 2.1 is delayed. The plan is to implement the new >> non-TLA created ECC curves (Curve255519). Last fall it looked that the >> IETF would fast adopt they as standards but they keep on debating. Thus >> the likely outcome is that 2.1 will be released without an official IETF >> standard for the new curves. >> >> I did a new beta yesterday but my experience with beta versions is that >> they are not widely used or problems/success are not reported. To move >> forward we might have to jump into cold water and release 2.1 without >> having many test results. And I need to set aside enough time to >> quickly work on reported problems after 2.1.0. Thus all other >> construction areas should be cleaned up before. > > FWIW I would be happy to help test, if someone makes a Debian package for gnupg 2.1. I might do that myself this weekend. Let me know if there's any significant installation differences between 2.0 and 2.1. I've packaged the latest beta for gnupg 2.1, with the idea of shipping it in debian experimental, but i'm reluctant to distribute it in debian yet for a couple reasons (which i'll go into below, thanks for prompting me to write this up). If you want to build and install it yourself, you should be able to do so from git (the repo is about 25MiB): git clone git://anonscm.debian.org/pkg-gnupg/gnupg2.git cd gnupg2 git checkout upstream-2.1 git checkout pristine-tar git checkout experimental git-buildpackage -uc -us This should produce .deb files for you in ../ Note that these will replace any existing gnupg2 packages on your debian system! the current head of the experimental branch is: 5239f4155a7b8bc773a5d490ff4c61c1280d61ed OK, so why am i not ready to upload this to debian's experimental repository yet? I see three outstanding concerns, the first two of which are relevant for upstream: 0) reverse compatibility of ~/.gnupg/pubring.gpg with earlier gnupg 1.4.x and 2.0.x When a new keyring is created with 2.1 in ~/.gnupg/pubring.gpg, it is created in a keybox format. This format is unreadable by gnupg 1.4.x and 2.0.x. So GNUPGHOME directories created by 2.1 will be unusable by older versions. Given that the older versions aren't going away in the short term, this seems problematic. Why not use ~/.gnupg/pubring.kbx, as documented in the man page? In the event that both versions coexist, synchronizing the two files (or at least updating the .kbx from changes to the .gpg) seems like a pain, but it seems more manageable than simply making 1.4.x or 2.0.x unusable in the event that the keybox-formatted pubring.gpg exists. (i think earlier betas actually aggressively transformed the pubring.gpg into a keybox format when run, which was even worse than the current situation; beta834 seems to only present the problem for new GNUPGHOME directories) 2) interactions between running gpg-agent and newer gnupg2 One common upgrade path i can imagine is this, especially during the experimental phase: * user decides "i want to try this new, fancy gpg 2.1". from within their graphical desktop, which already has gpg-agent 2.0.x running, they do: "sudo apt-get install -t experimental gnupg2" * then, immediately, they want to try out the fancy goods, so they run gpg2. gpg2 tries to talk to the running agent, but the running agent is the old agent, not the new agent. the upgrade process fails weirdly (while claiming success!): gpg: starting migration from earlier GnuPG versions gpg: porting secret keys from '/home/foo/.gnupg/secring.gpg' to gpg-agent gpg: error getting the KEK: Unknown IPC command gpg: migration succeeded clearsigning a message also fails: gpg: signing failed: Unsupported protection gpg: [stdin]: clearsign failed: Unsupported protection or sometimes: gpg: signing failed: Provided object is too short gpg: [stdin]: clearsign failed: Provided object is too short So i think that gpg2.1 needs to somehow detect that the running agent is old, and either fail more gracefully (making it clear to the user or actually restart the agent if it can be sure that gpg-agent is the right version. 0) dirmngr gpg2.1 depends on the latest version of dirmngr for any/all of its remote access functionality (e.g. keyserver fetches). Debian has traditionally packaged dirmngr separately from gnupg, but it looks like we should really bring the two of them together. This is is debian-specific packaging work; we've already gotten permission of the dirmngr maintainer to do this, so it's just outstanding work that needs to be done: http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/2014-September/001828.html I welcome any feedback and suggestions on these issues. happy hacking, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Fri Sep 19 17:15:49 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 19 Sep 2014 17:15:49 +0200 Subject: Why 2.1 is delayed for so long In-Reply-To: <541C21ED.2090602@pwned.gg> (Ximin Luo's message of "Fri, 19 Sep 2014 13:30:37 +0100") References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> Message-ID: <8738bn1w0q.fsf@vigenere.g10code.de> On Fri, 19 Sep 2014 14:30, infinity0 at pwned.gg said: > FWIW I would be happy to help test, if someone makes a Debian package for gnupg 2.1. I might do that myself this weekend. Let me know if there's any significant installation differences between 2.0 and 2.1. > > Is the data format for EdDSA keys now final? Well, if the IANA eventually decides that another number will be assigned, I need to make sure that GnuPG will continues to support this version of EdDSA. That can be done by looking at the curve OID. This would be an ugly hack, but I think it is better to go ahead with 22 than to wait at least several more weeks for the IETF process. All modulo bugs in the the EdDSA code or protocol. Shalom-Salam, Werner p.s. I'll reply to dkg's mail later the day. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Fri Sep 19 17:27:47 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 19 Sep 2014 11:27:47 -0400 Subject: [Pkg-gnupg-maint] Why 2.1 is delayed for so long In-Reply-To: <541C3F41.3050107@fifthhorseman.net> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541C3F41.3050107@fifthhorseman.net> Message-ID: <541C4B73.6010600@fifthhorseman.net> On 09/19/2014 10:35 AM, Daniel Kahn Gillmor wrote: > I've packaged the latest beta for gnupg 2.1, with the idea of shipping > it in debian experimental, On re-reading, i fear that my previous e-mail with its list of concerns may have sounded rather negative. I just wanted to say how excited and hopeful i am that we can get gpg 2.1 (whether beta or not) into broader testing (and more generally wider adoption). The features offered by gpg 2.1 (in particular, ecc, keybox and a fully-cryptographic gpg-agent) are really great, and i want to see them used more widely. So thanks for gpg 2.1, i hope we can get these minor concerns sorted out! --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From aheinecke at intevation.de Fri Sep 19 19:32:07 2014 From: aheinecke at intevation.de (Andre Heinecke) Date: Fri, 19 Sep 2014 19:32:07 +0200 Subject: DCO for Andre Heinecke Message-ID: <4525694.FcpLvWDUFT@esus> GnuPG Developer's Certificate of Origin. Version 1.0 ===================================================== By making a contribution to the GnuPG project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the free software license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate free software license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same free software license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the free software license(s) involved. Signed-off-by: Andre Heinecke -- 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: 198 bytes Desc: This is a digitally signed message part. URL: From dkg at fifthhorseman.net Fri Sep 19 20:49:13 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 19 Sep 2014 14:49:13 -0400 Subject: curve25519 and encryption capabilities [Re: Why 2.1 is delayed for so long] In-Reply-To: <8738bn1w0q.fsf@vigenere.g10code.de> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <8738bn1w0q.fsf@vigenere.g10code.de> Message-ID: <541C7AA9.3090405@fifthhorseman.net> On 09/19/2014 11:15 AM, Werner Koch wrote: > All modulo bugs in the the EdDSA code or protocol. I just tried making some EdDSA keys with 2.1 beta 834. I had to use the --expert option just to get any ECC options at all for --gen-key. after using --expert, i'm given these options: Please select what kind of key you want: [... non-ECC stripped ...] (9) ECC (10) ECC (sign only) (11) ECC (set your own capabilities) If i choose (9) i only get NIST and brainpool curves. If i choose (10) then i get Curve25519 as an option. The key created this way is not encryption-capable, and it has no encryption-capable subkey. If i go back to add a subkey, i can't add an ECC subkey without using --expert again. So i do that, and i get these options from "addkey": (10) ECC (sign only) (11) ECC (set your own capabilities) (12) ECC (encrypt only) If i choose 12 (ECC (encrypt only)), i get the full slate of ECC algorithms, including Curve25519. I chose Curve25519, and it let me enter a passphrase for this new key, but then failed with: gpg: agent_genkey failed: Unknown elliptic curve gpg: Key generation failed: Unknown elliptic curve So i suspect what's happening here is that Curve25519 is defined for signatures and certification and authentication only, but not for encryption, and the menus need to be a bit more constrained in what they offer. Or should we be able to encrypt to Curve25519 keys? fwiw, the generated Curve25519 keys are marked with asymmetric algorithm ID 22, and the generated ECDSA (NIST and brainpool both) are asym algo 18, as expected. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Fri Sep 19 20:12:40 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 19 Sep 2014 20:12:40 +0200 Subject: [Pkg-gnupg-maint] Why 2.1 is delayed for so long In-Reply-To: <541C4B73.6010600@fifthhorseman.net> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541C3F41.3050107@fifthhorseman.net> <541C4B73.6010600@fifthhorseman.net> Message-ID: <541C7218.6040606@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 09/19/2014 05:27 PM, Daniel Kahn Gillmor wrote: > On 09/19/2014 10:35 AM, Daniel Kahn Gillmor wrote: >> I've packaged the latest beta for gnupg 2.1, with the idea of >> shipping it in debian experimental, > ... > > I just wanted to say how excited and hopeful i am that we can get > gpg 2.1 (whether beta or not) into broader testing (and more > generally wider adoption). Indeed good news :) FWIW I just bumped from beta783 to beta834 for Gentoo users as well. - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Dura necessitas Necessity is harsh -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUHHIXAAoJEPw7F94F4TagV08P/AngKSmkp5iIw/iDp4YrtzJ/ l2rcn8sEvx0esZ5/kbrlnnBlywk+Ms8mBOGkCAZrjR0NZameXAVTeT7mfq9g8Wj7 I4muqK9SWU3yztcWs61k/pFqeoAOanPOh9B+/BMAw4MpaoUgUZthS1QQJ8BHQE3U YojdNZjo6nlMVsEAqYcUcEzck+Pg8Inn9vYQDk9I30B/pfdVOyJVYlvgAkpplroy X7HkozL+h0OjYtfQRWhQIS9YcEFxa4wFAwKTFeeTl7Q1Fuijx/8/SkB3f66oAgg2 eEoPFDh/hlo1/J2Sv6yzA/jPDT3Y2ke14ktojFQmewxP0FiNeUzJiT1WIpEIk6/Y qdr5FQND5SBEF2vAjAPARN5s4coDAWCUtd/6UwZ8V4fArkc7P6ld9KCLGw8S3m9z V8k4kvpL/oCvguzaJlpBAd+poUYXvfx/X0DXPnVnm60FSpeUkLCke6dqktnwcX6E SjXu1Wv2CwNaj7pttayNHIYrsGMYkGAR3/gnKSLAB/wvcXZlTwu6C2zVZBe1Wav9 cCWKaXBu+xeIuPqGuQVoq2IKTr8byA7QQn8Rwzhqyl3XFPbCJ6xUlawApkOHjryS 24K5faI0riKTvs4m+rqYS9KUtnFkiZbkb1P2BEVzZn70JjQyVD7GiA5poqixnc7f fOXsxb2soelaplDN5Y3g =MP6s -----END PGP SIGNATURE----- From wk at gnupg.org Fri Sep 19 21:54:38 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 19 Sep 2014 21:54:38 +0200 Subject: curve25519 and encryption capabilities In-Reply-To: <541C7AA9.3090405@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 19 Sep 2014 14:49:13 -0400") References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <8738bn1w0q.fsf@vigenere.g10code.de> <541C7AA9.3090405@fifthhorseman.net> Message-ID: <878ulfz8qp.fsf_-_@vigenere.g10code.de> On Fri, 19 Sep 2014 20:49, dkg at fifthhorseman.net said: > I had to use the --expert option just to get any ECC options at all for > --gen-key. That is our usual strategy for introducing new algorithms. First we want to have the new version, with the support for new algorithms, running on many machines ("read-only mode"). Then, with a future version, we enable the new algorithm in "write-mode", i.e. for general use without --expert. In a last step we may make it the default. If we don't do that, people start to generate new keys and would be surprised that most people can't encrypt for them or verify their signature. Given the importance of moving to ECC and use modern curves created by trustworthy people, I am all in favor of shorten the above process. > (9) ECC > (10) ECC (sign only) > (11) ECC (set your own capabilities) > > If i choose (9) i only get NIST and brainpool curves. Right, 9 creates a primary and a subkey. We can't offer Curve25519 becuase we have currently no implementation for encryption. Thus Curve255519 does not show up. > If i choose (10) then i get Curve25519 as an option. 10 creates a signing key (cf. "sign only"). You may later add an encrytion key (probably RSA because there is no Curve25519 encryption key yet). > If i go back to add a subkey, i can't add an ECC subkey without using > --expert again. See explanation at top. > If i choose 12 (ECC (encrypt only)), i get the full slate of ECC > algorithms, including Curve25519. Right, but if won't work. I need to add code to disable it. I have not yet done that in the hope that we could add Curve25519 encryption support soon. > So i suspect what's happening here is that Curve25519 is defined for > signatures and certification and authentication only, but not for > encryption, and the menus need to be a bit more constrained in what they Correct. It is a litte bit more complicated right now. I decided to use the term Curve25519 for both, the signing and the encryption algorithm. However, in practise we are using a variant of Curve25519 for signinig, a curve named Ed25519 (Twisted Edwards form of the Cruve25519 which is defined as Montgomery curve). The algorthm used with Ed25519 is also quite different and thus used the new algorithm id 22; while for encryption we will use ECDH (18) as defined in rfc-6637 (although we will probably extend it with by using point compression). > offer. Or should we be able to encrypt to Curve25519 keys? We will have Ed25519 using EdDSA for signing. We will have Curve25519 using ECDH for encryption. They are not exchangeable similar to DSA and Elgamal. > ID 22, and the generated ECDSA (NIST and brainpool both) are asym algo > 18, as expected. ECDH (encryption) is 18 ECDSA (signing) should be 19 The keys are technically exchangeable. Salam-Shalom, Werner ps. Thanks for testing it and giving me the opportunity to explain this new stuff. We should extend the FAQ soon after a release. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Sep 19 21:59:12 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 19 Sep 2014 21:59:12 +0200 Subject: [Pkg-gnupg-maint] Why 2.1 is delayed for so long In-Reply-To: <541C4B73.6010600@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 19 Sep 2014 11:27:47 -0400") References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541C3F41.3050107@fifthhorseman.net> <541C4B73.6010600@fifthhorseman.net> Message-ID: <874mw3z8j3.fsf@vigenere.g10code.de> On Fri, 19 Sep 2014 17:27, dkg at fifthhorseman.net said: > On re-reading, i fear that my previous e-mail with its list of concerns > may have sounded rather negative. I didn't took it for that. I am actually thankful for all constructive critics. For too long only a few people have been using the latest features. I close my shop for today - I'll comment on it on Monday. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Fri Sep 19 22:34:44 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 19 Sep 2014 16:34:44 -0400 Subject: curve25519 and encryption capabilities In-Reply-To: <878ulfz8qp.fsf_-_@vigenere.g10code.de> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <8738bn1w0q.fsf@vigenere.g10code.de> <541C7AA9.3090405@fifthhorseman.net> <878ulfz8qp.fsf_-_@vigenere.g10code.de> Message-ID: <541C9364.1060605@fifthhorseman.net> Hi Werner-- Thanks for the detailed explanations! On 09/19/2014 03:54 PM, Werner Koch wrote: > On Fri, 19 Sep 2014 20:49, dkg at fifthhorseman.net said: >> If i choose 12 (ECC (encrypt only)), i get the full slate of ECC >> algorithms, including Curve25519. > > Right, but if won't work. I need to add code to disable it. I have not > yet done that in the hope that we could add Curve25519 encryption > support soon. Thanks, this is the explanation i was missing :) > Correct. It is a litte bit more complicated right now. I decided to > use the term Curve25519 for both, the signing and the encryption > algorithm. However, in practise we are using a variant of Curve25519 > for signinig, a curve named Ed25519 (Twisted Edwards form of the > Cruve25519 which is defined as Montgomery curve). The algorthm used > with Ed25519 is also quite different and thus used the new algorithm id > 22; while for encryption we will use ECDH (18) as defined in rfc-6637 > (although we will probably extend it with by using point compression). fwiw, djb seems to be proposing (on the CFRG mailing list) that the curve itself should be referred to as Curve25519; the signature mechanism should be Ed25519; and the DH key exchange should be X25519. This is pretty confusing, though, since the widespread implementation called "curve25519" actually implemented what djb now wants to call X25519. :/ >> offer. Or should we be able to encrypt to Curve25519 keys? > > We will have Ed25519 using EdDSA for signing. > We will have Curve25519 using ECDH for encryption. > They are not exchangeable similar to DSA and Elgamal. > >> ID 22, and the generated ECDSA (NIST and brainpool both) are asym algo >> 18, as expected. > > ECDH (encryption) is 18 > ECDSA (signing) should be 19 Ah, right. signing-capable keys are indeed ID 19. > The keys are technically exchangeable. That's a little weird. it seems in some sense like we're heading back to ID 2 and 3 (RSA encrypt-only and RSA sign-only), which i thought the community had moved away from in favor of generic ID 1 (RSA). but in practice, since we want to discourage reuse of keys in different algorithms, it's probably not a bad thing. > Thanks for testing it and giving me the opportunity to explain this new > stuff. We should extend the FAQ soon after a release. sounds good! --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Fri Sep 19 22:39:32 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 19 Sep 2014 22:39:32 +0200 Subject: curve25519 and encryption capabilities In-Reply-To: <541C9364.1060605@fifthhorseman.net> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <8738bn1w0q.fsf@vigenere.g10code.de> <541C7AA9.3090405@fifthhorseman.net> <878ulfz8qp.fsf_-_@vigenere.g10code.de> <541C9364.1060605@fifthhorseman.net> Message-ID: <541C9484.2030705@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 09/19/2014 10:34 PM, Daniel Kahn Gillmor wrote: > Hi Werner-- > .. >> >> ECDH (encryption) is 18 ECDSA (signing) should be 19 > > Ah, right. signing-capable keys are indeed ID 19. > >> The keys are technically exchangeable. > > That's a little weird. it seems in some sense like we're heading > back to ID 2 and 3 (RSA encrypt-only and RSA sign-only), which i > thought the community had moved away from in favor of generic ID 1 > (RSA). but in practice, since we want to discourage reuse of keys > in different Although the keys are technically exchangable, they have different fields when parsing c.f. rfc6637 (see the kdf parts for ecdh), so separate algo-id makes it cleaner to parse it. - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- "Excellence is not a singular act but a habit. You are what you do repeatedly." (Shaquille O'Neal) -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUHJSCAAoJEPw7F94F4TagBK8P/1fLoCHZbiq6KMq6sKx3xesf /Xzb9jcZ4cIAIDfXt8aAwFWkV6uAB2rcGe9RLk3JundifRaTXEyWROVHtOcLayC7 L/kEmsZ4YfMyV9ci1a9cTZlAE+O5TbgkTCEEB9sMqQNsTc8Pqml+XBr4UH3n1U19 ieRRGAjrfnT1vQywOMjU6Z8V7KL8t23sEslPiOh6zKMgPSvICtndbpLe0yTcZpb1 FMfCK03JXDWrRri8zn2O0miXBu9YmOf6rgvBZSaj7SadRPolcED/YG3jvJcN6dbq UPTOYN3qnvE0n3xKj699BcR3bog9/cR95sFpVPI512sG+BET0yR8CHBlhjWVdAU5 /HIk5x31juSIVHY0H4aMi5y8QvoeJPtYWpXON8ODau/9QhwYzj4B8RrfiSXYamTu dsv1JVX/lVCRGcg7m0m1Qxa2HGGXdHvH2DcfYoPEmwJP0y7flI/YPUfdgNM80rgE 56Q+AYy1M1nz6f6FJk4U+YmZmJYE52e6nH4AdCQ9uJH4qauJfYCwKi5srYmxIbxs w6+r/w6gpMAYW4gJlJsO0vDIKj8TJaUz6y/dDpoJbZi+qmOuOcQLoLlWd/uMNshp DWngByGua7DjwfSnZMUVHgrPPDZGmcMHOVNzczKH1PcNSGl5tIzTLyKjyGuwPV+l XwCCxE5kO8AMKFRJDCOH =zp/g -----END PGP SIGNATURE----- From infinity0 at pwned.gg Sat Sep 20 03:02:15 2014 From: infinity0 at pwned.gg (Ximin Luo) Date: Sat, 20 Sep 2014 02:02:15 +0100 Subject: Why 2.1 is delayed for so long In-Reply-To: <541C3F41.3050107@fifthhorseman.net> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541C3F41.3050107@fifthhorseman.net> Message-ID: <541CD217.4090000@pwned.gg> On 19/09/14 15:35, Daniel Kahn Gillmor wrote: > > 2) interactions between running gpg-agent and newer gnupg2 > > [..] > > the upgrade process fails weirdly > (while claiming success!): > > [..] > > So i think that gpg2.1 needs to somehow detect that the running agent is > old, and either fail more gracefully (making it clear to the user or > actually restart the agent if it can be sure that gpg-agent is the right > version. > Is this the debian or gnupg upgrade process? Either way, we can run it with --no-use-agent? Then warn the user if GPG_AGENT_INFO is set? According to various posts on the internet we could also run "gpg-connect-agent killagent /bye" [1] but I just tried it and it doesn't work. `man gpg-connect-agent` doesn't mention any commands, except "control" ones that start with / and I can't find any documentation anywhere online about these commands. :| $ gpg-connect-agent killagent /bye ERR 103 unknown command $ gpg-connect-agent --version gpg-connect-agent (GnuPG) 2.0.26 [1] http://lists.gnupg.org/pipermail/gnupg-users/2013-July/046947.html > 0) dirmngr > > gpg2.1 depends on the latest version of dirmngr for any/all of its > remote access functionality (e.g. keyserver fetches). Debian has > traditionally packaged dirmngr separately from gnupg, but it looks like > we should really bring the two of them together. This is is > debian-specific packaging work; we've already gotten permission of the > dirmngr maintainer to do this, so it's just outstanding work that needs > to be done: > > http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/2014-September/001828.html > Does this have anything to do with the failures above? X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From infinity0 at pwned.gg Sat Sep 20 04:44:11 2014 From: infinity0 at pwned.gg (Ximin Luo) Date: Sat, 20 Sep 2014 03:44:11 +0100 Subject: Why 2.1 is delayed for so long In-Reply-To: <541C21ED.2090602@pwned.gg> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> Message-ID: <541CE9FB.7030102@pwned.gg> On 19/09/14 13:30, Ximin Luo wrote: > On 19/09/14 09:49, Werner Koch wrote: >> On Thu, 18 Sep 2014 02:25, djhaskin987 at gmail.com said: >> >>> also seen Werner say on this mailing list that he has used 2.1 "for >>> years now". I wonder if there is a measure by which the four-year-old >>> version shall be considered stable. If so, what is it? If not, or if >> >> Never change a running system (i.e. 1.4). I am glad to see that after >> 11 years 2.0 is now going mainstream. >> >> I assume that 2.1 will be be adopted faster because it has improvements >> which are fashionable now; in particular ECC. However, ECC is also one >> of the problems why 2.1 is delayed. The plan is to implement the new >> non-TLA created ECC curves (Curve255519). Last fall it looked that the >> IETF would fast adopt they as standards but they keep on debating. Thus >> the likely outcome is that 2.1 will be released without an official IETF >> standard for the new curves. >> >> I did a new beta yesterday but my experience with beta versions is that >> they are not widely used or problems/success are not reported. To move >> forward we might have to jump into cold water and release 2.1 without >> having many test results. And I need to set aside enough time to >> quickly work on reported problems after 2.1.0. Thus all other >> construction areas should be cleaned up before. >> > > FWIW I would be happy to help test, if someone makes a Debian package for gnupg 2.1. I might do that myself this weekend. Let me know if there's any significant installation differences between 2.0 and 2.1. > > Is the data format for EdDSA keys now final? > First impressions testing 2.1: * --secret-keyring has no effect. How do I back up my secret keyring? It seems secrets are now controlled by the agent? How do I back this stuff up? ** What if I (or a program I'm using) want to separate my secrets into separate locations? I need to start a new gpg-agent for each homedir? This would be quite awkward to do. * when auto-generating a key, I'm now prompted to input a passphrase for every single subkey. For newly-generated keys, the message is generic and has no context, so 7 pop ups in a row is very confusing. Could some sort of context be added? Instead of saying "Please enter the passphrase for your new key", you should say "Please enter the passphrase for your new ECC key, , expires XYZ". Similar thing for exporting keys, and I'm sure there are other uses. * no more documentation describing batch mode? (I hope it is much improved; last time I checked batch mode it was very limited and not fit for purpose; I had to script up the normal CLI instead. [1]) * Instead of having to confirm yet again "Use this curve anyway? (y/N) y" I would just put it in the key selector display: Please select which elliptic curve you want: (1) Curve 25519 (not yet part of OpenPGP standard!) * I've always thought the key creation descriptions were counter-intuitive. I guess they were intended to be "simple for newbies", but I don't think this goal is achieved, rather it makes it worse. The current descriptions present to the user a mental model that is completely different from what is actually happening. Instead of the current: (1) RSA and RSA (default) (2) DSA and Elgamal (9) ECC they should be named: (1) RSA (for sign+certify) and RSA subkey (for encryption) (2) DSA (for sign+certify) and Elgamal subkey (for encryption) (9) ECC (for sign+certify) and ECC subkey (for encryption) I think this is much clearer. Even for newbies, it at least hints to what is going on, which means they can build up a mental model. Also, these two: (7) DSA (set your own capabilities) (11) ECC (set your own capabilities) would better be named: (7) DSA (set your own signing capabilities) (11) ECC (set your own signing capabilities) Also, +1 for getting Curve25519 encryption working... X [1] https://github.com/infinity0/l33tutils/blob/master/data/security/gpgen.sh -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Sat Sep 20 10:50:35 2014 From: wk at gnupg.org (Werner Koch) Date: Sat, 20 Sep 2014 10:50:35 +0200 Subject: curve25519 and encryption capabilities In-Reply-To: <541C9364.1060605@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 19 Sep 2014 16:34:44 -0400") References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <8738bn1w0q.fsf@vigenere.g10code.de> <541C7AA9.3090405@fifthhorseman.net> <878ulfz8qp.fsf_-_@vigenere.g10code.de> <541C9364.1060605@fifthhorseman.net> Message-ID: <87tx42y8tg.fsf@vigenere.g10code.de> On Fri, 19 Sep 2014 22:34, dkg at fifthhorseman.net said: > fwiw, djb seems to be proposing (on the CFRG mailing list) that the > curve itself should be referred to as Curve25519; the signature > mechanism should be Ed25519; and the DH key exchange should be X25519. I know, it is now all a mess. Reminds me of PGP's use of D-H while the standard correctly uses Elgamal. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Sat Sep 20 12:05:03 2014 From: wk at gnupg.org (Werner Koch) Date: Sat, 20 Sep 2014 12:05:03 +0200 Subject: Why 2.1 is delayed for so long In-Reply-To: <541CD217.4090000@pwned.gg> (Ximin Luo's message of "Sat, 20 Sep 2014 02:02:15 +0100") References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541C3F41.3050107@fifthhorseman.net> <541CD217.4090000@pwned.gg> Message-ID: <87ppeqy5dc.fsf@vigenere.g10code.de> On Sat, 20 Sep 2014 03:02, infinity0 at pwned.gg said: > According to various posts on the internet we could also run > "gpg-connect-agent killagent /bye" [1] but I just tried it and it > doesn't work. `man gpg-connect-agent` doesn't mention any commands, Sure it doesn't. ssh neither shows you the available commands on the connected host. You may try the command "help" and "help COMMAND". For reloading the agent, you may also use "gpgconf --reload gpg-agent" or to kill it "gpgconf --kill gpg-agent" > $ gpg-connect-agent killagent /bye > ERR 103 unknown command > help killagent # KILLAGENT # # If the agent has been started using a standard socket # we allow a client to stop the agent. OK 2.0.26 might not stpport this command on Unix systems - I have not checked. It was orginally introduced for the Windows port because kill commands are not standard there. 2.1 has this command with the above mentioned exception. > $ gpg-connect-agent --version > gpg-connect-agent (GnuPG) 2.0.26 What you want is $ gpg-connect-agent 'getinfo version' /bye D 2.1.0-beta772 OK Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Sat Sep 20 12:23:16 2014 From: wk at gnupg.org (Werner Koch) Date: Sat, 20 Sep 2014 12:23:16 +0200 Subject: Why 2.1 is delayed for so long In-Reply-To: <541CE9FB.7030102@pwned.gg> (Ximin Luo's message of "Sat, 20 Sep 2014 03:44:11 +0100") References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> Message-ID: <87lhpey4iz.fsf@vigenere.g10code.de> On Sat, 20 Sep 2014 04:44, infinity0 at pwned.gg said: > * --secret-keyring has no effect. How do I back up my secret keyring? > It seems secrets are now controlled by the agent? How do I back this > stuff up? The same way you have always done it with gpgsm: Backup ~/.gnupg/private-keys-v1.d/ > ** What if I (or a program I'm using) want to separate my secrets into > separate locations? I need to start a new gpg-agent for each homedir? > This would be quite awkward to do. Yes, you need to do that. This is actually how I run my tests. In the test home directory I do GNUPGHOME=$(pwd) agent/gpg-agent --daemon ~/bin/gnupg-setup-tests with the script being: --8<---------------cut here---------------start------------->8--- #!/bin/sh cat >setup-tests.ini <<'EOF' PS1="$(echo "$PS1" | sed 's,\\\$ $,(GnuPGTest)\\\$ ,')" EOF exec bash --init-file setup-tests.ini --8<---------------cut here---------------end--------------->8--- The reason for having the secret material all in one place is the standard crypto practice of placing your eggs/keys all into one basket and guard them closely. You may even symlink the private-key-v1.d to share them between different (test) installations. > * when auto-generating a key, I'm now prompted to input a passphrase > for every single subkey. For newly-generated keys, the message is Are you sure that you use the latest agent? Does gpg-connect-agent 'getinfo version' /bye show the right version number (at least 2.1.0-beta834)> > "Please enter the passphrase for your new key", you should say "Please > enter the passphrase for your new ECC key, , expires Good suggestion. Hoever, I would keep the algorithm out. > * no more documentation describing batch mode? (I hope it is much > improved; last time I checked batch mode it was very limited and not > fit for purpose; I had to script up the normal CLI instead. [1]) I don't understand what you mean. --batch has always been docuemnted as not requiring any user input at runtime. > * Instead of having to confirm yet again "Use this curve anyway? (y/N) y" I would just put it in the key selector display: > > Please select which elliptic curve you want: > (1) Curve 25519 (not yet part of OpenPGP standard!) Doing it the inteactive way is more informative and avoids i18n (translation) problems. At some point the prompt will simply be removed. > * I've always thought the key creation descriptions were > counter-intuitive. I guess they were intended to be "simple for > newbies", but I don't think this goal is achieved, rather it makes it > worse. The current descriptions present to the user a mental model > that is completely different from what is actually happening Maybe. But most people use a GUI frontend anyway. Did you know that you could enter a '?' on response to all prompt. You will see a help text which can be locally be changed to suite an organizations needs. > (1) RSA (for sign+certify) and RSA subkey (for encryption) > (2) DSA (for sign+certify) and Elgamal subkey (for encryption) > (9) ECC (for sign+certify) and ECC subkey (for encryption) Too much details - not a good idea. > I think this is much clearer. Even for newbies, it at least hints to what is going on, which means they can build up a mental model. Thus there is the "(default)" marker which is what newbies should do. > would better be named: > > (7) DSA (set your own signing capabilities) > (11) ECC (set your own signing capabilities) I prefer generic strings. And well, there is just one signing capability, the others are called authentication, encryption, and certification. > Also, +1 for getting Curve25519 encryption working... Me too, but there are a couple of problems and encryption is not as important as signing (i.e. certification). Adding an encryption subkey can be done at any time. In the meantime you can collect key signatures if you like. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Sat Sep 20 12:39:05 2014 From: wk at gnupg.org (Werner Koch) Date: Sat, 20 Sep 2014 12:39:05 +0200 Subject: Why 2.1 is delayed for so long In-Reply-To: <541C3F41.3050107@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 19 Sep 2014 10:35:45 -0400") References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541C3F41.3050107@fifthhorseman.net> Message-ID: <87ha02y3sm.fsf@vigenere.g10code.de> On Fri, 19 Sep 2014 16:35, dkg at fifthhorseman.net said: > the current head of the experimental branch is: > 5239f4155a7b8bc773a5d490ff4c61c1280d61ed i.e. with your own changes. I assume it is based on beta834 (commit 93f158df) > 0) reverse compatibility of ~/.gnupg/pubring.gpg with earlier gnupg > 1.4.x and 2.0.x I do not have this problem, but let's see: > When a new keyring is created with 2.1 in ~/.gnupg/pubring.gpg, it is > created in a keybox format. This format is unreadable by gnupg 1.4.x > and 2.0.x. So GNUPGHOME directories created by 2.1 will be unusable by > older versions. Given that the older versions aren't going away in the > short term, this seems problematic. > > Why not use ~/.gnupg/pubring.kbx, as documented in the man page? In the Well, that is a bug. A newly created file should be named this and not ".gpg". > event that both versions coexist, synchronizing the two files (or at > least updating the .kbx from changes to the .gpg) seems like a pain, but > it seems more manageable than simply making 1.4.x or 2.0.x unusable in > the event that the keybox-formatted pubring.gpg exists. I agree. Syncinging is easy, though: "gpg1 --export | gpg2 --import" > (i think earlier betas actually aggressively transformed the pubring.gpg > into a keybox format when run, which was even worse than the current No they they didn't. You might have got the impression because gpgsm has always created a "pubring.kbx". I really want to use the keybox format for new keys. If an existing pubring.gpg exists, gpg2.1 will continue to use that and not the kbx format. > * then, immediately, they want to try out the fancy goods, so they run > gpg2. gpg2 tries to talk to the running agent, but the running agent is > the old agent, not the new agent. the upgrade process fails weirdly > (while claiming success!): Okay, what to do: - Have gpg check the agent version and refuse all commands if it does not match its expectations (ie. for now the same version as gpg) - Popup Pinentry to explain the situation The latter has the advantage that it will give a clear error message also if gpg is silently used by a fronend. > So i think that gpg2.1 needs to somehow detect that the running agent is > old, and either fail more gracefully (making it clear to the user or > actually restart the agent if it can be sure that gpg-agent is the right > version. Restarting without user consent might be problematic. > 0) dirmngr > > gpg2.1 depends on the latest version of dirmngr for any/all of its > remote access functionality (e.g. keyserver fetches). Debian has > traditionally packaged dirmngr separately from gnupg, but it looks like > we should really bring the two of them together. This is is > debian-specific packaging work; we've already gotten permission of the > dirmngr maintainer to do this, so it's just outstanding work that needs The question is whether the old dirmnagr is at all useful. How many are using it to check CRLs or run OCSP checks for X.509? Or would it be useful to rename the new dirmngr so that both can co-exist? The name is anyway alien to GnuPG. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From infinity0 at pwned.gg Sat Sep 20 13:49:12 2014 From: infinity0 at pwned.gg (Ximin Luo) Date: Sat, 20 Sep 2014 12:49:12 +0100 Subject: Why 2.1 is delayed for so long In-Reply-To: <87lhpey4iz.fsf@vigenere.g10code.de> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <87lhpey4iz.fsf@vigenere.g10code.de> Message-ID: <541D69B8.7060606@pwned.gg> On 20/09/14 11:23, Werner Koch wrote: > On Sat, 20 Sep 2014 04:44, infinity0 at pwned.gg said: > > The reason for having the secret material all in one place is the > standard crypto practice of placing your eggs/keys all into one basket > and guard them closely. You may even symlink the private-key-v1.d to share > them between different (test) installations. > OK, this is less of an issue than I originally thought. My original concern was for applications like caff, that want to do things separately on the side, so as to not pollute the user's keyrings. But looking at them, they all seem to work on public keys only, rather than secret keys. But maybe a future one will want a separate pool for secret keys. So it would be good to add a --auto-launch-agent option, to automatically launch a new gpg-agent if the current one has a different --homedir. At least, the manual page should be updated to say --secret-keyring is now ignored (and to point to the new location). >> * when auto-generating a key, I'm now prompted to input a passphrase >> for every single subkey. For newly-generated keys, the message is > > Are you sure that you use the latest agent? Does > > gpg-connect-agent 'getinfo version' /bye > > show the right version number (at least 2.1.0-beta834)> > Yes, this is gpg-agent 2.1. I'm using --edit-key --expert then addkey. It prompts me for a passphrase for each new subkey. >> "Please enter the passphrase for your new key", you should say "Please >> enter the passphrase for your new ECC key, , expires > > Good suggestion. Hoever, I would keep the algorithm out. > Well, at least it should say the keyid, whether it is a subkey (what use-flags) and (if so) which master key it belongs to? I like the gpg 1.4 prompt - it's informative, when I sign something and it prompts me to unlock, it says: "You need a passphrase [...] for user , 4096 RSA, subkey $ID, created $date (main keyid $ID)." >> * no more documentation describing batch mode? (I hope it is much >> improved; last time I checked batch mode it was very limited and not >> fit for purpose; I had to script up the normal CLI instead. [1]) > > I don't understand what you mean. --batch has always been docuemnted as > not requiring any user input at runtime. > In DETAILS.gz, it now says: * Unattended key generation Please see the GnuPG manual for a description. Previously (with gpg 1.4) it contained the actual documentation. Perhaps Debian should just package the manual. With gpg 1.4 (and it seem the case for 2, [2]), there was a bunch of things stopping me from writing this script [1] using batch mode. The main blocker was: Subkey-Type: | This generates a secondary key. Currently only one subkey can be handled. but possibly there was more, I can't remember. [1] https://github.com/infinity0/l33tutils/blob/master/data/security/gpgen.sh [2] https://www.gnupg.org/documentation/manuals/gnupg-devel/Unattended-GPG-key-generation.html >> * Instead of having to confirm yet again "Use this curve anyway? (y/N) y" I would just put it in the key selector display: >> >> Please select which elliptic curve you want: >> (1) Curve 25519 (not yet part of OpenPGP standard!) > > Doing it the inteactive way is more informative and avoids i18n > (translation) problems. At some point the prompt will simply be removed. > OK, my motivation was that not having a prompt makes the input flow more consistent, so easier to script with. But probably the best solution is to fix batch mode (and maybe make it work for an existing key) rather than to make the CLI "more scriptable". >> * I've always thought the key creation descriptions were >> counter-intuitive. I guess they were intended to be "simple for >> newbies", but I don't think this goal is achieved, rather it makes it >> worse. The current descriptions present to the user a mental model >> that is completely different from what is actually happening > > Maybe. But most people use a GUI frontend anyway. Did you know that you > could enter a '?' on response to all prompt. You will see a help text > which can be locally be changed to suite an organizations needs. > >> (1) RSA (for sign+certify) and RSA subkey (for encryption) >> (2) DSA (for sign+certify) and Elgamal subkey (for encryption) >> (9) ECC (for sign+certify) and ECC subkey (for encryption) > > Too much details - not a good idea. > How about: (1) RSA (sign) and RSA subkey (encryption) At least, the (9) ECC option should make it clear there are two keys being made. As dkg pointed out, it is extra confusing when mixed with (10) and (11). (9) ECC (sign) and ECC subkey (encryption) (9) ECC and ECC This would also match the existing (1) RSA and RSA. >> I think this is much clearer. Even for newbies, it at least hints to what is going on, which means they can build up a mental model. > > Thus there is the "(default)" marker which is what newbies should do. > >> would better be named: >> >> (7) DSA (set your own signing capabilities) >> (11) ECC (set your own signing capabilities) > > I prefer generic strings. And well, there is just one signing > capability, the others are called authentication, encryption, and > certification. > As I understand, C/S/A all treats the public key as a signature scheme. You can tweak the suggestion, e.g. "(set your own capabilities, except encryption)", the point is to distinguish it from keytypes that can actually support all capabilities. There is no way to "go back" in the CLI, so I have to quit the whole program if I pick the wrong option. Maybe then we can add a "back" option? >> Also, +1 for getting Curve25519 encryption working... > > Me too, but there are a couple of problems and encryption is not as > important as signing (i.e. certification). Adding an encryption subkey > can be done at any time. In the meantime you can collect key signatures > if you like. > That is true, and I can use ElGamal in the meantime. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From infinity0 at pwned.gg Sat Sep 20 14:15:21 2014 From: infinity0 at pwned.gg (Ximin Luo) Date: Sat, 20 Sep 2014 13:15:21 +0100 Subject: Why 2.1 is delayed for so long In-Reply-To: <541D69B8.7060606@pwned.gg> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <87lhpey4iz.fsf@vigenere.g10code.de> <541D69B8.7060606@pwned.gg> Message-ID: <541D6FD9.2010303@pwned.gg> On 20/09/14 12:49, Ximin Luo wrote: > On 20/09/14 11:23, Werner Koch wrote: >> On Sat, 20 Sep 2014 04:44, infinity0 at pwned.gg said: >> >> The reason for having the secret material all in one place is the >> standard crypto practice of placing your eggs/keys all into one basket >> and guard them closely. You may even symlink the private-key-v1.d to share >> them between different (test) installations. >> > > OK, this is less of an issue than I originally thought. My original concern was for applications like caff, that want to do things separately on the side, so as to not pollute the user's keyrings. But looking at them, they all seem to work on public keys only, rather than secret keys. > > But maybe a future one will want a separate pool for secret keys. So it would be good to add a --auto-launch-agent option, to automatically launch a new gpg-agent if the current one has a different --homedir. > > At least, the manual page should be updated to say --secret-keyring is now ignored (and to point to the new location). > It seems --delete-secret-key $UID will now select public keys as well, and offer them for deletion but do a no-op if you go ahead with it. # Correct behaviour in gpg 1.4: $ gpg --delete-secret-key dkg [..] gpg: key "dkg" not found: eof gpg: dkg: delete key failed: eof 2 $ gpg2 --delete-secret-key dkg [..] sec rsa4096/CCD2ED94D21739E9 2007-06-02 Daniel Kahn Gillmor Delete this key from the keyring? (y/N) y This is a secret key! - really delete? (y/N) y # key still here, though $ gpg2 --delete-secret-key dkg [..] sec rsa4096/CCD2ED94D21739E9 2007-06-02 Daniel Kahn Gillmor Delete this key from the keyring? (y/N) y This is a secret key! - really delete? (y/N) y X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Sat Sep 20 15:17:03 2014 From: wk at gnupg.org (Werner Koch) Date: Sat, 20 Sep 2014 15:17:03 +0200 Subject: Why 2.1 is delayed for so long In-Reply-To: <541D69B8.7060606@pwned.gg> (Ximin Luo's message of "Sat, 20 Sep 2014 12:49:12 +0100") References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <87lhpey4iz.fsf@vigenere.g10code.de> <541D69B8.7060606@pwned.gg> Message-ID: <874mw2xwhc.fsf@vigenere.g10code.de> On Sat, 20 Sep 2014 13:49, infinity0 at pwned.gg said: > But maybe a future one will want a separate pool for secret keys. So > it would be good to add a --auto-launch-agent option, to automatically > launch a new gpg-agent if the current one has a different --homedir. This is exactly what already happens. > At least, the manual page should be updated to say --secret-keyring is now ignored (and to point to the new location). Change to: --secret-keyring file This is an obsolete option and ignored. All secret keys are stored in the 'private-keys-v1.d' directory below the GnuPG home directory. > Yes, this is gpg-agent 2.1. I'm using --edit-key --expert then > addkey. It prompts me for a passphrase for each new subkey. Okay, that is a different thing. I do not think that caching is needed for adding a new subkey. You usually don't add several subkeys and in any case it helps to remember the passphrase. > Well, at least it should say the keyid, whether it is a subkey (what use-flags) and (if so) which master key it belongs to? Why? You already told gpg what to create. > I like the gpg 1.4 prompt - it's informative, when I sign something and it prompts me to unlock, it says: > > "You need a passphrase [...] for user , 4096 RSA, subkey $ID, created $date (main keyid $ID)." This is what I see on my system. See g10/passphrase.c:gpg_format_keydesc. desc = xtryasprintf (_("%s\n" "\"%.*s\"\n" "%u-bit %s key, ID %s,\n" "created %s%s.\n%s"), prompt, (int)uidlen, uid, nbits_from_pk (pk), algo_name, keystr (pk->keyid), timestr, maink?maink:"", trailer); > Previously (with gpg 1.4) it contained the actual > documentation. Perhaps Debian should just package the manual. The manual is build by default. Debian should install it; after all it is one of the very few GNU manuals which does not use the FDL at all (it is GPLv3). > With gpg 1.4 (and it seem the case for 2, [2]), there was a bunch of things stopping me from writing this script [1] using batch mode. The main blocker was: > > Subkey-Type: | > This generates a secondary key. Currently only one subkey > can be handled. You mean, "only one subkey"? Enter a feature request into the BTS, but given that this is rarely used I can't promise that I will implement it any time sonn. See also the recent discussion on whether to add --quick-gen-subkey. > OK, my motivation was that not having a prompt makes the input flow > more consistent, so easier to script with. But probably the best > solution is to fix batch mode (and maybe make it work for an existing > key) rather than to make the CLI "more scriptable". You can easily script it. --command-fd/status-fd are your friends. It you see an unknown prompt, send a LF and the default action will be used. > At least, the (9) ECC option should make it clear there are two keys being made. As dkg pointed out, it is extra confusing when mixed with (10) and (11). > (9) ECC and ECC Good suggestion. Done. > There is no way to "go back" in the CLI, so I have to quit the whole > program if I pick the wrong option. Maybe then we can add a "back" > option? Hey, it is for experts ;-) > That is true, and I can use ElGamal in the meantime. Use RSA instead. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From infinity0 at pwned.gg Sat Sep 20 16:11:39 2014 From: infinity0 at pwned.gg (Ximin Luo) Date: Sat, 20 Sep 2014 15:11:39 +0100 Subject: Why 2.1 is delayed for so long In-Reply-To: <874mw2xwhc.fsf@vigenere.g10code.de> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <87lhpey4iz.fsf@vigenere.g10code.de> <541D69B8.7060606@pwned.gg> <874mw2xwhc.fsf@vigenere.g10code.de> Message-ID: <541D8B1B.9020608@pwned.gg> On 20/09/14 14:17, Werner Koch wrote: > On Sat, 20 Sep 2014 13:49, infinity0 at pwned.gg said: > >> But maybe a future one will want a separate pool for secret keys. So >> it would be good to add a --auto-launch-agent option, to automatically >> launch a new gpg-agent if the current one has a different --homedir. > > This is exactly what already happens. > As I observe, if the current GPG_AGENT_INFO has a different homedir from GNUPGHOME, gpg2 will happily use that agent, rather than starting up a new one for the current GNUPGHOME. >> At least, the manual page should be updated to say --secret-keyring is now ignored (and to point to the new location). > > Change to: > > --secret-keyring file > > This is an obsolete option and ignored. All secret keys > are stored in the 'private-keys-v1.d' directory below the > GnuPG home directory. > Sounds good. >> Yes, this is gpg-agent 2.1. I'm using --edit-key --expert then >> addkey. It prompts me for a passphrase for each new subkey. > > Okay, that is a different thing. I do not think that caching is needed > for adding a new subkey. You usually don't add several subkeys and in > any case it helps to remember the passphrase. > >> Well, at least it should say the keyid, whether it is a subkey (what use-flags) and (if so) which master key it belongs to? > > Why? You already told gpg what to create. > From a script or program or batch mode generation, the user might not have any notice on what the program is trying to do. So gpg-agent should still display this information. >> I like the gpg 1.4 prompt - it's informative, when I sign something and it prompts me to unlock, it says: >> >> "You need a passphrase [...] for user , 4096 RSA, subkey $ID, created $date (main keyid $ID)." > > This is what I see on my system. See g10/passphrase.c:gpg_format_keydesc. > > desc = xtryasprintf (_("%s\n" > "\"%.*s\"\n" > "%u-bit %s key, ID %s,\n" > "created %s%s.\n%s"), > prompt, > (int)uidlen, uid, > nbits_from_pk (pk), algo_name, > keystr (pk->keyid), timestr, > maink?maink:"", trailer); > Yes, the good case is for signatures in GPG 1.4. I'm saying the bad case for key creation in GPG 2.1 should be like the good case, as discussed above. For GPG 2.1, key creation only says "Please enter the passphrase to protect your new key". >> Previously (with gpg 1.4) it contained the actual >> documentation. Perhaps Debian should just package the manual. > > The manual is build by default. Debian should install it; after all it > is one of the very few GNU manuals which does not use the FDL at all (it > is GPLv3). > >> With gpg 1.4 (and it seem the case for 2, [2]), there was a bunch of things stopping me from writing this script [1] using batch mode. The main blocker was: >> >> Subkey-Type: | >> This generates a secondary key. Currently only one subkey >> can be handled. > > You mean, "only one subkey"? Enter a feature request into the BTS, but > given that this is rarely used I can't promise that I will implement it > any time sonn. See also the recent discussion on whether to add > --quick-gen-subkey. > I guess it's rarely used because it's not useful? The case where batch mode is needed most (for complex key creation) is not supported by it! >> OK, my motivation was that not having a prompt makes the input flow >> more consistent, so easier to script with. But probably the best >> solution is to fix batch mode (and maybe make it work for an existing >> key) rather than to make the CLI "more scriptable". > > You can easily script it. --command-fd/status-fd are your friends. It > you see an unknown prompt, send a LF and the default action will be > used. > I am already doing this. Scripting the CLI is awkward and annoying, and the source code ends up giving no indication to the user what is actually happening unless you know the GPG CLI off by heart. See [1] for an example. https://github.com/infinity0/l33tutils/blob/master/data/security/gpgen.sh Batch mode would be much nicer. >> At least, the (9) ECC option should make it clear there are two keys being made. As dkg pointed out, it is extra confusing when mixed with (10) and (11). > >> (9) ECC and ECC > > Good suggestion. Done. > >> There is no way to "go back" in the CLI, so I have to quit the whole >> program if I pick the wrong option. Maybe then we can add a "back" >> option? > > Hey, it is for experts ;-) > Seriously though, it is bad UX experience to go several steps without being able to correct yourself. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Sat Sep 20 16:26:24 2014 From: wk at gnupg.org (Werner Koch) Date: Sat, 20 Sep 2014 16:26:24 +0200 Subject: Why 2.1 is delayed for so long In-Reply-To: <541D6FD9.2010303@pwned.gg> (Ximin Luo's message of "Sat, 20 Sep 2014 13:15:21 +0100") References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <87lhpey4iz.fsf@vigenere.g10code.de> <541D69B8.7060606@pwned.gg> <541D6FD9.2010303@pwned.gg> Message-ID: <87r3z6wepb.fsf@vigenere.g10code.de> On Sat, 20 Sep 2014 14:15, infinity0 at pwned.gg said: > It seems --delete-secret-key $UID will now select public keys as well, and offer them for deletion but do a no-op if you go ahead with it. Fix pushed. Thanks. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From eric at debian.org Sun Sep 21 03:09:53 2014 From: eric at debian.org (Eric Dorland) Date: Sat, 20 Sep 2014 21:09:53 -0400 Subject: [Pkg-gnupg-maint] Why 2.1 is delayed for so long In-Reply-To: <87ha02y3sm.fsf@vigenere.g10code.de> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541C3F41.3050107@fifthhorseman.net> <87ha02y3sm.fsf@vigenere.g10code.de> Message-ID: <20140921010953.GH24040@gambit> * Werner Koch (wk at gnupg.org) wrote: [snip] > > So i think that gpg2.1 needs to somehow detect that the running agent is > > old, and either fail more gracefully (making it clear to the user or > > actually restart the agent if it can be sure that gpg-agent is the right > > version. > > Restarting without user consent might be problematic. My $0.02 is that it's fine to just print an error with instructions on how to restart your gpg-agent. > > 0) dirmngr > > > > gpg2.1 depends on the latest version of dirmngr for any/all of its > > remote access functionality (e.g. keyserver fetches). Debian has > > traditionally packaged dirmngr separately from gnupg, but it looks like > > we should really bring the two of them together. This is is > > debian-specific packaging work; we've already gotten permission of the > > dirmngr maintainer to do this, so it's just outstanding work that needs > > The question is whether the old dirmnagr is at all useful. How many are > using it to check CRLs or run OCSP checks for X.509? Does the new version not support the same operations as the old one? > Or would it be useful to rename the new dirmngr so that both can > co-exist? The name is anyway alien to GnuPG. -- Eric Dorland 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From wk at gnupg.org Sun Sep 21 09:59:24 2014 From: wk at gnupg.org (Werner Koch) Date: Sun, 21 Sep 2014 09:59:24 +0200 Subject: [Pkg-gnupg-maint] Why 2.1 is delayed for so long In-Reply-To: <20140921010953.GH24040@gambit> (Eric Dorland's message of "Sat, 20 Sep 2014 21:09:53 -0400") References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541C3F41.3050107@fifthhorseman.net> <87ha02y3sm.fsf@vigenere.g10code.de> <20140921010953.GH24040@gambit> Message-ID: <8738blwgir.fsf@vigenere.g10code.de> On Sun, 21 Sep 2014 03:09, eric at debian.org said: >> The question is whether the old dirmnagr is at all useful. How many are >> using it to check CRLs or run OCSP checks for X.509? > > Does the new version not support the same operations as the old one? Yes, it does. It is actually the same code base which has been changed to take advantage of code already in gnupg/ and the gpg keyserver helpers have been merged into it. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From e1ven at e1ven.com Sun Sep 21 18:29:49 2014 From: e1ven at e1ven.com (Colin Davis) Date: Sun, 21 Sep 2014 12:29:49 -0400 Subject: S In-Reply-To: References: <87r3z856kw.fsf@vigenere.g10code.de> Message-ID: <4E206518-D56F-4914-84C1-163693DCACAA@e1ven.com> Thanks for working on this - This is much better than it was even two months ago! I was able to compile this successfully on OSX, both in the current stable (10.9.5) and the beta (10.10 DP8) Charles - I believe it's using gpgv to verify the downloads - If you make sure you have an existing version of gpg installed (such as `brew install gpg`, this should work). There were a few other small configuration issues- As before, you need to have automake installed - It looks like it still really wants automake 1.11. IIRC, there were some patches proposed last year to support both, but until then you'll want to manually install automake 1.11 wget http://ftp.gnu.org/gnu/automake/automake-1.11.6.tar.gz tar -xzf automake-1.11.6.tar.gz cd automake-1.11.6/ ./configure make make install AUTOMAKE_SUFFIX=1.11 You'll also want to set gl_cv_absolute_stdint_h, so that gpg picks up the version in /usr gl_cv_absolute_stdint_h=/usr/include/stdint.h OSX ships with "shasum", rather than "sha1sum", so you need to modify speedy to use this method On line 726 of build-aux/speedo.mk, replace sha1sum with shasum. Finally, we need to edit the Makefile- edit common/Makefile.am, and go to line 194. Replace: t_common_ldadd = libcommon.a ../gl/libgnu.a \ with t_common_ldadd = libcommon.a libcommon_a-init.o ../gl/libgnu.a \ then run make -f build-aux/speedo.mk native This should provide you with a copy of gpg2 in PLAY/inst/bin/gpg2 gnupg-2.1.0-beta834 e1ven$ PLAY/inst/bin/gpg2 --version gpg (GnuPG) 2.1.0-beta834 libgcrypt 1.6.2 NOTE: THIS IS A DEVELOPMENT VERSION! It is only intended for test purposes and should NOT be used in a production environment or with production keys! Copyright (C) 2014 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: ~/.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 > On Sep 19, 2014, at 11:34 AM, Charles Diza wrote: > > Hello, > > I am getting the exact same error as before. > > Does this beta require newer versions of {npth,libassuan,libksba,libgpg-error,libgcrypt} than the "current" released versions? I'm just building against the current releases. > > > To get the list of the latest versions do this > > > build-aux/getswdb.sh > > That didn't work for me. I get: > > build-aux/getswdb.sh: line 101: gpgv: command not found > list of software versions is not valid! > > > Is there still a problem with /usr/include/stdint.h - I have lost track > > of it. > > It is still the case that without a manual setting of: > > export gl_cv_absolute_stdint_h="/usr/include/stdint.h" > > building is not possible. Some package managers for Mac (e.g., Homebrew) will prepend to the value of that var a MacOS-specific SDK path, but this varies from version to version. > > Cheers, > Charles > > On Fri, Sep 19, 2014 at 4:59 AM, Werner Koch wrote: > Hi folks, > > would you mind to do a test build of the new beta (see below) and report > to gnupg-devel at gnupg.org? I'd like to have the OSX build problems fixed > before a real release. > > I fixed some of the build problems and stepped other aside by not > building some unused programs (t-http and t-helpfile). > > Is there still a problem with /usr/include/stdint.h - I have lost track > of it. > > If you run the speedo script mentioned below (remember to use GNU make) > it will download the required libraries and also show the latest > versions. If you can't use gmake, you need to build it manually as > before (which is actually better because you can then install it > properly). To get the list of the latest versions do this > > build-aux/getswdb.sh > > it creates a file swdb.lst with versions and checksums. > > > Shalom-Salam, > > Werner > > > ===== > I just uploaded a new beta: > > ftp://ftp.gnupg.org/gcrypt/gnupg/unstable/gnupg-2.1.0-beta834.tar.bz2 > ftp://ftp.gnupg.org/gcrypt/gnupg/unstable/gnupg-2.1.0-beta834.tar.bz2.sig > > Noteworthy changes in version 2.1.0-beta834 (2014-09-18) > -------------------------------------------------------- > > * gpg: Improved passphrase caching. > > * gpg: Switched to algorithm number 22 for EdDSA. > > * gpg: Removed CAST5 from the default preferences. > > * gpg: Order SHA-1 last in the hash preferences. > > * gpg: Changed default cipher for --symmetric to AES-128. > > * gpg: Fixed export of ECC keys and import of EdDSA keys. > > * dirmngr: Fixed the KS_FETCH command. > > * speedo: Downloads related packages and works for non-Windows. > > > To quickly build all required software without installing it, the > Speedo method may be used: > > make -f build-aux/speedo.mk native > > This method downloads all required libraries and does a native build > of GnuPG to PLAY/inst/. GNU make is required and you need to set > LD_LIBRARY_PATH to $(pwd)/PLAY/inst/lib. > > > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > From wk at gnupg.org Mon Sep 22 14:26:51 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 22 Sep 2014 14:26:51 +0200 Subject: Why 2.1 is delayed for so long In-Reply-To: <541D8B1B.9020608@pwned.gg> (Ximin Luo's message of "Sat, 20 Sep 2014 15:11:39 +0100") References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <87lhpey4iz.fsf@vigenere.g10code.de> <541D69B8.7060606@pwned.gg> <874mw2xwhc.fsf@vigenere.g10code.de> <541D8B1B.9020608@pwned.gg> Message-ID: <8738bjvo1g.fsf@vigenere.g10code.de> On Sat, 20 Sep 2014 16:11, infinity0 at pwned.gg said: > As I observe, if the current GPG_AGENT_INFO has a different homedir > from GNUPGHOME, gpg2 will happily use that agent, rather than starting > up a new one for the current GNUPGHOME. That is why I suggested to unset GPG_AGENT_INFO in the bashrc. I need to research whether we can completely do without GPG_AGENT_INFO. IT is only used in case a non-standard socket is used. For what I know, this is required if the GNUPGHOME is mounted on file system which does not support sockets (i.e. remove file system or vfat). An idea would be to stat the socket file and if is a real file, read the name of the to be used socket form that file. Thus it must be created prior to starting gpg-agent and be considered a configuration file. This would actually help to remove some code from GnuPG. Implementation should be easy, most can be done in Libassuan. >>> Well, at least it should say the keyid, whether it is a subkey (what use-flags) and (if so) which master key it belongs to? >> >> Why? You already told gpg what to create. >> > > From a script or program or batch mode generation, the user might not > have any notice on what the program is trying to do. So gpg-agent > should still display this information. The script should tell that the user. If you think this is important, please add it as a feature request for 2.1 to the BTS. [pinentry while signing] > Yes, the good case is for signatures in GPG 1.4. I'm saying the bad > case for key creation in GPG 2.1 should be like the good case, as > discussed above. Sorry, I don't understand. > For GPG 2.1, key creation only says "Please enter the passphrase to > protect your new key". 1.4 and 2.0 use very similar prompts. We can't use the standard prompt because we do not know the keyid at that point. Yes, we could ask after key creation but that has the problem that the prompt for the passphrase would show up only after minutes and the user needs to wait for it and not come back and the key has already been protected and saved. > I guess it's rarely used because it's not useful? The case where batch mode is needed most (for complex key creation) is not supported by it! I assume that if there is a need for it, you have the time to implement a proper script to control gpg. Sometimes new commands make sense, like the --quick-sign-key I implemented for something John Gilmore was hacking on. > I am already doing this. Scripting the CLI is awkward and annoying, > and the source code ends up giving no indication to the user what is > actually happening unless you know the GPG CLI off by heart. See [1] No, no. You should never do it this way. That is not scripting the interface but feeding it with canned commands. This will for sure break. For example the original author of GPA did it this way and it broke with the next vesion of gpg. It is entirely unreliable. GnuPG has a machine oriented interface for a reason; you are ignoring it. Here is an extract from mail-signed-keys which uses the machine interface as intended: gpg OTHEROPTIONS --check-sigs --with-colons 2>/dev/null \ | awk -F: -v signedby="$signedby" ' BEGIN { sendmail="/usr/lib/sendmail -oi -t " } $1 == "pub" { nextkid=$5; nextuid=$10 if( uidcount > 0 ) { myflush() } kid=nextkid; uid=nextuid; next } $1 == "uid" { uid=$10 ; next } $1 == "sig" && $2 == "!" && $5 == signedby { uids[uidcount++] = uid; next } END { if( uidcount > 0 ) { myflush() } } ' Using --gen-key is more complicated, though. You need to wait for "[GNUPG:] GET_LINE", switch on the following argument (e.g. "keygen.algo") and send appropriate answers. If you not know the argument, just answer with a LF which takes the default. You should see "GOT_IT" line next; if not something went wrong. You can do that with awk or perl, or whatever you like. > Seriously though, it is bad UX experience to go several steps without > being able to correct yourself. Yeah well, but in the last 16 years that was not a real problem. Implementing such extras is easy but testing them takes lots of time. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Sep 22 14:54:57 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 22 Sep 2014 14:54:57 +0200 Subject: S In-Reply-To: <4E206518-D56F-4914-84C1-163693DCACAA@e1ven.com> (Colin Davis's message of "Sun, 21 Sep 2014 12:29:49 -0400") References: <87r3z856kw.fsf@vigenere.g10code.de> <4E206518-D56F-4914-84C1-163693DCACAA@e1ven.com> Message-ID: <87y4tbu866.fsf@vigenere.g10code.de> On Sun, 21 Sep 2014 18:29, e1ven at e1ven.com said: > Charles - I believe it's using gpgv to verify the downloads - If you Right, I hoped that at least gpgv is availabale on all major platforms by default. It is the case for most Linux distributions. I print a warning now. > As before, you need to have automake installed - It looks like it > still really wants automake 1.11. I can't see why you need automake or autoconf for building. You need it only if you build from GIT. I just removed autoconf and automake from my machine and the speedo build works as expected. > You'll also want to set gl_cv_absolute_stdint_h, so that gpg picks up the version in /usr > gl_cv_absolute_stdint_h=/usr/include/stdint.h With no access to an OS X mahcine it is hard for me to figure out why the configure checks fail. I'd appreciate any help. > OSX ships with "shasum", rather than "sha1sum", so you need to modify > speedy to use this method Now runtime detected. > Finally, we need to edit the Makefile- > edit common/Makefile.am, and go to line 194. Replace: > t_common_ldadd = libcommon.a ../gl/libgnu.a \ > with > t_common_ldadd = libcommon.a libcommon_a-init.o ../gl/libgnu.a \ Well, this change is of course the reason why you need automake. However, I am still puzzled why you need to add init.o. It is already included in libcommon.a and the functions from libcommon.a don't use functions from init.o. Can you provide a build log again without the above patch? I would also like to see the libcommon.a libcommon_a-init.o and the main object file of a failing test program (tar up, gzip and send to me by PM). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rjh at sixdemonbag.org Mon Sep 22 15:48:36 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 22 Sep 2014 09:48:36 -0400 Subject: Why 2.1 is delayed for so long In-Reply-To: <541CE9FB.7030102@pwned.gg> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> Message-ID: <542028B4.3070204@sixdemonbag.org> > they should be named: > > (1) RSA (for sign+certify) and RSA subkey (for encryption) > (2) DSA (for sign+certify) and Elgamal subkey (for encryption) > (9) ECC (for sign+certify) and ECC subkey (for encryption) > > I think this is much clearer. Even for newbies... I'm (extremely!) reluctant to agree here; I think it's exactly the opposite. If I had my way, key generation wouldn't even ask what algorithms to use unless the --expert flag was provided. Two good rules of thumb for UI design: * Never ask the user to make an irrelevant choice * Never ask the user to make a choice with consequences they do not or cannot understand Whether one uses RSA/RSA, DSA/Elg or ECC/ECC is completely irrelevant for the "normal" use case -- someone who cares that their email is protected with strong cryptography, but doesn't care so much about how. Further, the "normal" user isn't going to have any idea what the differences among RSA, DSA, Elgamal and ECC are, so we shouldn't burden them with having to make that choice. In --expert mode we should give the user as much rope as they want to hang themselves with, but outside of that I think we should move towards removing irrelevant and/or expert-level choices, not including them. From rjh at sixdemonbag.org Mon Sep 22 15:50:08 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 22 Sep 2014 09:50:08 -0400 Subject: curve25519 and encryption capabilities In-Reply-To: <87tx42y8tg.fsf@vigenere.g10code.de> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <8738bn1w0q.fsf@vigenere.g10code.de> <541C7AA9.3090405@fifthhorseman.net> <878ulfz8qp.fsf_-_@vigenere.g10code.de> <541C9364.1060605@fifthhorseman.net> <87tx42y8tg.fsf@vigenere.g10code.de> Message-ID: <54202910.6040108@sixdemonbag.org> > I know, it is now all a mess. Reminds me of PGP's use of D-H while > the standard correctly uses Elgamal. Which was done, if memory serves, to get a one-time reduction in royalty payments to some partner. Long after the benefit from the misnaming is gone they're stuck still supporting it. From infinity0 at pwned.gg Mon Sep 22 15:56:08 2014 From: infinity0 at pwned.gg (Ximin Luo) Date: Mon, 22 Sep 2014 14:56:08 +0100 Subject: Why 2.1 is delayed for so long In-Reply-To: <542028B4.3070204@sixdemonbag.org> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> Message-ID: <54202A78.6010302@pwned.gg> On 22/09/14 14:48, Robert J. Hansen wrote: >> they should be named: >> >> (1) RSA (for sign+certify) and RSA subkey (for encryption) >> (2) DSA (for sign+certify) and Elgamal subkey (for encryption) >> (9) ECC (for sign+certify) and ECC subkey (for encryption) >> >> I think this is much clearer. Even for newbies... > > I'm (extremely!) reluctant to agree here; I think it's exactly the > opposite. If I had my way, key generation wouldn't even ask what > algorithms to use unless the --expert flag was provided. > > Two good rules of thumb for UI design: > > * Never ask the user to make an irrelevant choice > * Never ask the user to make a choice with consequences they > do not or cannot understand > I agree with these principles, but I think you are not applying them in the right way. The fact that the user is doing gpg --gen-key already means the choice is relevant, and they can understand the consequences. There are lots of other point-and-click interfaces for GPG for users that "don't care". There is a third principle: * Never present to the user a false model of what actually happens. Too often, I see UI designers who *don't understand what is happening* make bad suggestions in the name of the first two principles, completely inappropriately, which incapacitates the user from making appropriate security decisions. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Mon Sep 22 16:17:34 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 22 Sep 2014 10:17:34 -0400 Subject: Why 2.1 is delayed for so long In-Reply-To: <54202A78.6010302@pwned.gg> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <54202A78.6010302@pwned.gg> Message-ID: <54202F7E.9090806@sixdemonbag.org> > I agree with these principles, but I think you are not applying them > in the right way. The fact that the user is doing gpg --gen-key > already means the choice is relevant... Emphatically not! I can count on one hand with fingers leftover the number of times I've cared over the last 15 years of using GnuPG whether the key I'm generating used RSA or DSA/Elg. (Three fingers leftover; twice I had a specific need for RSA, for compatibility with stuff further down the toolchain that's outside of GnuPG's control.) The rest of the time the choice was completely irrelevant Some users enjoy tweaking with the knobs and dials. There's nothing wrong with that, and I think GnuPG should support that. But I also think that irrelevant knobs and dials should be hidden from the user. Algorithm choice and key size are two such things. Pick sane defaults, make it easy to override them with --expert, and don't reveal them to the casual user. > There are lots of other point-and-click interfaces for GPG for users > that "don't care". There are also a lot of people who look at GnuPG's FAQ for advice on how to begin using GnuPG. Those instructions currently amount to "--gen-key and trust the defaults." > * Never present to the user a false model of what actually happens. How is hiding irrelevant choices, or choices the user cannot understand, presenting a "false model," especially when I've explicitly said that with --expert the choices should return? From dkg at fifthhorseman.net Mon Sep 22 16:26:12 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 22 Sep 2014 10:26:12 -0400 Subject: Why 2.1 is delayed for so long In-Reply-To: <874mw2xwhc.fsf@vigenere.g10code.de> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <87lhpey4iz.fsf@vigenere.g10code.de> <541D69B8.7060606@pwned.gg> <874mw2xwhc.fsf@vigenere.g10code.de> Message-ID: <874mvzybnf.fsf@alice.fifthhorseman.net> On Sat 2014-09-20 09:17:03 -0400, Werner Koch wrote: > On Sat, 20 Sep 2014 13:49, infinity0 at pwned.gg said: >> Previously (with gpg 1.4) it contained the actual >> documentation. Perhaps Debian should just package the manual. > > The manual is build by default. Debian should install it; after all it > is one of the very few GNU manuals which does not use the FDL at all (it > is GPLv3). Which manual are we talking about here? debian packages should already ship the man page and the DETAILS.gz. are we talking about some of the things that we ship (kind of) in gnupg-doc? I asked about the data contained in debian's out-of-date gnupg-doc package recently [0], but have gotten no response on that thread, and the package was removed from testing about a year ago with no complaints. This makes me suspect it's not being actually used. If there's a particular manual that we're not shipping but should be, please tell me specifically which manual and where i should look for the source. I'm happy to make sure we ship it. all the best, --dkg [0] http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/2014-September/001760.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From dkg at fifthhorseman.net Mon Sep 22 16:28:38 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 22 Sep 2014 10:28:38 -0400 Subject: bad signature In-Reply-To: <18323150.oWTro5XuLm@inno> References: <87bnqmyo5j.fsf@alice.fifthhorseman.net> <18323150.oWTro5XuLm@inno> Message-ID: <871tr3ybjd.fsf@alice.fifthhorseman.net> On Thu 2014-09-11 20:28:14 -0400, Hauke Laging wrote: > Am Do 11.09.2014, 15:04:24 schrieb Daniel Kahn Gillmor: >> Hi there-- > > KMail shows me a bad signature for this email. Enigmail shows a correct > one. > > Usually I would expect this is a bug in KMail but I cannot verify the > signature manually. This should be an easy case: no encoding and a text > signature. Please report this to kmail upstream. I can verify the signature in both enigmail and notmuch, but i don't have a configured kmail system to test with at the moment. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From infinity0 at pwned.gg Mon Sep 22 17:00:15 2014 From: infinity0 at pwned.gg (Ximin Luo) Date: Mon, 22 Sep 2014 16:00:15 +0100 Subject: UX and defaults; was Re: Why 2.1 is delayed for so long In-Reply-To: <54202F7E.9090806@sixdemonbag.org> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <54202A78.6010302@pwned.gg> <54202F7E.9090806@sixdemonbag.org> Message-ID: <5420397F.2030303@pwned.gg> On 22/09/14 15:17, Robert J. Hansen wrote: >> I agree with these principles, but I think you are not applying them >> in the right way. The fact that the user is doing gpg --gen-key >> already means the choice is relevant... > > Emphatically not! > > I can count on one hand with fingers leftover the number of times I've > cared over the last 15 years of using GnuPG whether the key I'm > generating used RSA or DSA/Elg. (Three fingers leftover; twice I had a > specific need for RSA, for compatibility with stuff further down the > toolchain that's outside of GnuPG's control.) The rest of the time the > choice was completely irrelevant > > Some users enjoy tweaking with the knobs and dials. There's nothing > wrong with that, and I think GnuPG should support that. But I also > think that irrelevant knobs and dials should be hidden from the user. > Algorithm choice and key size are two such things. Pick sane defaults, > make it easy to override them with --expert, and don't reveal them to > the casual user. > An optionless way to generate keys makes sense. I mostly take issue with your other suggestion, that a more precisely-worded options list is inappropriate, *given* that an options list is appropriate for the usage (in whatever --expert mode you care to put the options list in). As for the defaults issue, I agree that this is a UX issue, but I disagree with your narrative that it is to do with cutting down "irrelevant" options. I extremely dislike UX design approaches that assert 99% of people have a particular use-case, implying that everything else is "irrelevant", then using this to justify sacrificing features that are useful to the 1% of people who actually know what is happening. (You don't suggest the latter, thankfully, but I have seen plenty of other non-general-purpose UX acolytes use the narrative you mention, to justify doing so.) It is not a matter of "irrelevant" options. Instead, I think it is more to do with being able to *perform your preferences quicker*. It just so happens you're personally happy with the existing GPG defaults, so you don't want to bother with the options list. I don't like the GPG defaults (which is why I wrote the script I mentioned in a previous email), but actually I don't want to bother with the options list either, I just want GPG to generate my preferred key in one simple command. One way to accomplish this is to improve "batch mode". Then, I can store my preferred key settings in a config file, like ~/.gnupg/genkey.conf, and --gen-key would use those settings automatically. GPG could place a default file for the user to edit. >> There are lots of other point-and-click interfaces for GPG for users >> that "don't care". > > There are also a lot of people who look at GnuPG's FAQ for advice on how > to begin using GnuPG. Those instructions currently amount to "--gen-key > and trust the defaults." > >> * Never present to the user a false model of what actually happens. > > How is hiding irrelevant choices, or choices the user cannot understand, > presenting a "false model," especially when I've explicitly said that > with --expert the choices should return? > The choices make no mention of master/subkey structure, nor the actual "Use Flags". "Sign" actually means "Sign and Certify". "X and Y" actually means "X master key and Y subkey". X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From mailinglists at gusnan.se Mon Sep 22 16:36:22 2014 From: mailinglists at gusnan.se (Andreas =?UTF-8?B?UsO2bm5xdWlzdA==?=) Date: Mon, 22 Sep 2014 16:36:22 +0200 Subject: bad signature In-Reply-To: <871tr3ybjd.fsf@alice.fifthhorseman.net> References: <87bnqmyo5j.fsf@alice.fifthhorseman.net> <18323150.oWTro5XuLm@inno> <871tr3ybjd.fsf@alice.fifthhorseman.net> Message-ID: <20140922163622.5e858b9e@debian-workstation.lan> On Mon, 22 Sep 2014 10:28:38 -0400, Daniel Kahn Gillmor wrote: >On Thu 2014-09-11 20:28:14 -0400, Hauke Laging wrote: >> Am Do 11.09.2014, 15:04:24 schrieb Daniel Kahn Gillmor: >>> Hi there-- >> >> KMail shows me a bad signature for this email. Enigmail shows a >> correct one. >> >> Usually I would expect this is a bug in KMail but I cannot verify >> the signature manually. This should be an easy case: no encoding and >> a text signature. > >Please report this to kmail upstream. I can verify the signature in >both enigmail and notmuch, but i don't have a configured kmail system >to test with at the moment. > > --dkg This might be this: https://bugs.kde.org/show_bug.cgi?id=332036 -- Andreas R?nnquist mailinglists at gusnan.se gusnan at gusnan.se From rjh at sixdemonbag.org Mon Sep 22 17:53:59 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 22 Sep 2014 11:53:59 -0400 Subject: UX and defaults; was Re: Why 2.1 is delayed for so long In-Reply-To: <5420397F.2030303@pwned.gg> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <54202A78.6010302@pwned.gg> <54202F7E.9090806@sixdemonbag.org> <5420397F.2030303@pwned.gg> Message-ID: <54204617.5060404@sixdemonbag.org> > On 22/09/14 15:17, Robert J. Hansen wrote: >>> I agree with these principles, but I think you are not applying them >>> in the right way. The fact that the user is doing gpg --gen-key >>> already means the choice is relevant... >> >> Emphatically not! Okay, apparently we misunderstood each other. You meant "given that we're already talking about a case in which the user cares about the algorithms," and I was thinking you meant "whenever a user generates a key, the fact they're generating a key makes the choice relevant." So long as the user explicitly asks to be given that level of detail, then yes, I think your proposed text would be a good idea. :) From dshaw at jabberwocky.com Mon Sep 22 17:14:44 2014 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 22 Sep 2014 11:14:44 -0400 Subject: Why 2.1 is delayed for so long In-Reply-To: <542028B4.3070204@sixdemonbag.org> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> Message-ID: <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> On Sep 22, 2014, at 9:48 AM, Robert J. Hansen wrote: >> they should be named: >> >> (1) RSA (for sign+certify) and RSA subkey (for encryption) >> (2) DSA (for sign+certify) and Elgamal subkey (for encryption) >> (9) ECC (for sign+certify) and ECC subkey (for encryption) >> >> I think this is much clearer. Even for newbies... > > I'm (extremely!) reluctant to agree here; I think it's exactly the > opposite. If I had my way, key generation wouldn't even ask what > algorithms to use unless the --expert flag was provided. I basically agree with this. In the past, it made sense to ask RSA or DSA/Elgamal. There were compatibility issues, with one implementation supporting algorithm A, and another supporting algorithm B and this other one supporting both A and B, but with bugs... etc. The RSA patent certainly didn't help either. These days, everyone fully supports all of RSA, DSA, and Elgamal, and has for years. Especially given that the advice (both here and in the FAQ) is "always use the defaults", why even give an option other than the defaults? It confuses the issue. Of course, --expert would have everything and give all options, including setting key flags, as today. But without --expert, just make an RSA (sign+certify) + RSA (encrypt) key, as is the default today. David From wk at gnupg.org Mon Sep 22 18:45:03 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 22 Sep 2014 18:45:03 +0200 Subject: Why 2.1 is delayed for so long In-Reply-To: <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> (David Shaw's message of "Mon, 22 Sep 2014 11:14:44 -0400") References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> Message-ID: <87oau7txio.fsf@vigenere.g10code.de> On Mon, 22 Sep 2014 17:14, dshaw at jabberwocky.com said: > I basically agree with this. Me too. > Of course, --expert would have everything and give all options, > including setting key flags, as today. But without --expert, just > make an RSA (sign+certify) + RSA (encrypt) key, as is the default > today. I wonder whether a sign only key (and then being able to select between DSA or RSA) makes sense in non-expert mode. What do you think? Shall we add a line "For more options run gpg with --expert"? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Sep 22 18:40:23 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 22 Sep 2014 18:40:23 +0200 Subject: Why 2.1 is delayed for so long In-Reply-To: <874mvzybnf.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 22 Sep 2014 10:26:12 -0400") References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <87lhpey4iz.fsf@vigenere.g10code.de> <541D69B8.7060606@pwned.gg> <874mw2xwhc.fsf@vigenere.g10code.de> <874mvzybnf.fsf@alice.fifthhorseman.net> Message-ID: <87sijjtxqg.fsf@vigenere.g10code.de> On Mon, 22 Sep 2014 16:26, dkg at fifthhorseman.net said: > Which manual are we talking about here? debian packages should already > ship the man page and the DETAILS.gz. The pdf and the info version of the texinfo files. ("make pdf" from the top directory). The man pages are extracted from the info file but they do not document everything as stated in each SEE ALSO section. > are we talking about some of the things that we ship (kind of) in > gnupg-doc? I asked about the data contained in debian's out-of-date That seems to be stuff from the website. I do not think this is useful The git repo gnupg-doc is used to build the website and several related things. It is quite specific for gnupg.org. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From infinity0 at pwned.gg Mon Sep 22 19:22:42 2014 From: infinity0 at pwned.gg (Ximin Luo) Date: Mon, 22 Sep 2014 18:22:42 +0100 Subject: Why 2.1 is delayed for so long In-Reply-To: <87oau7txio.fsf@vigenere.g10code.de> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> Message-ID: <54205AE2.40905@pwned.gg> On 22/09/14 17:45, Werner Koch wrote: > On Mon, 22 Sep 2014 17:14, dshaw at jabberwocky.com said: > >> I basically agree with this. > > Me too. > >> Of course, --expert would have everything and give all options, >> including setting key flags, as today. But without --expert, just >> make an RSA (sign+certify) + RSA (encrypt) key, as is the default >> today. > Whilst we're on this topic, I think the master key should be certify-only by default, and have two subkeys for signing and encryption. This means that someone can later move the master key to separate storage, if they learn more about GPG and decide that this is suitable for them. If you start off with a master key for sign+certify, this is more awkward. > I wonder whether a sign only key (and then being able to select between > DSA or RSA) makes sense in non-expert mode. What do you think? > > Shall we add a line "For more options run gpg with --expert"? > Yes, it's good to let the user know this option is there. I hope however, that this doesn't cause the usability of expert mode to be neglected. Even "expert mode" should be easy-to-use; I'll reply to the other posts that touch on this later. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Mon Sep 22 21:00:20 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 22 Sep 2014 15:00:20 -0400 Subject: Why 2.1 is delayed for so long In-Reply-To: <87sijjtxqg.fsf@vigenere.g10code.de> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <87lhpey4iz.fsf@vigenere.g10code.de> <541D69B8.7060606@pwned.gg> <874mw2xwhc.fsf@vigenere.g10code.de> <874mvzybnf.fsf@alice.fifthhorseman.net> <87sijjtxqg.fsf@vigenere.g10code.de> Message-ID: <542071C4.1070408@fifthhorseman.net> On 09/22/2014 12:40 PM, Werner Koch wrote: > On Mon, 22 Sep 2014 16:26, dkg at fifthhorseman.net said: > >> Which manual are we talking about here? debian packages should already >> ship the man page and the DETAILS.gz. > > The pdf and the info version of the texinfo files. ("make pdf" from the > top directory). The man pages are extracted from the info file but they > do not document everything as stated in each SEE ALSO section. "info gnupg" works for me based on the debian package, and shows the gnupg info pages. We don't ship the PDF at the moment. do you think it adds anything to ship the PDF as well as the info pages? > That seems to be stuff from the website. I do not think this is useful traditionally, we have shipped some data that is also available on the web as debian packages (e.g. debian-policy) to facilitate offline work. the main elements shipped in gnupg-doc are: o The GNU Privacy Handbook o Replacing PGP 2.x with GnuPG o GnuPG mini-HOWTO Do you think that these things are not useful for people in offline scenarios? Should we stop shipping one or more of those references? Are there other references that you think we should ship? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From infinity0 at pwned.gg Mon Sep 22 21:07:21 2014 From: infinity0 at pwned.gg (Ximin Luo) Date: Mon, 22 Sep 2014 20:07:21 +0100 Subject: Why 2.1 is delayed for so long In-Reply-To: <542071C4.1070408@fifthhorseman.net> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <87lhpey4iz.fsf@vigenere.g10code.de> <541D69B8.7060606@pwned.gg> <874mw2xwhc.fsf@vigenere.g10code.de> <874mvzybnf.fsf@alice.fifthhorseman.net> <87sijjtxqg.fsf@vigenere.g10code.de> <542071C4.1070408@fifthhorseman.net> Message-ID: <54207369.60904@pwned.gg> On 22/09/14 20:00, Daniel Kahn Gillmor wrote: > On 09/22/2014 12:40 PM, Werner Koch wrote: >> On Mon, 22 Sep 2014 16:26, dkg at fifthhorseman.net said: >> >>> Which manual are we talking about here? debian packages should already >>> ship the man page and the DETAILS.gz. >> >> The pdf and the info version of the texinfo files. ("make pdf" from the >> top directory). The man pages are extracted from the info file but they >> do not document everything as stated in each SEE ALSO section. > > "info gnupg" works for me based on the debian package, and shows the > gnupg info pages. > > We don't ship the PDF at the moment. do you think it adds anything to > ship the PDF as well as the info pages? > >> That seems to be stuff from the website. I do not think this is useful > > traditionally, we have shipped some data that is also available on the > web as debian packages (e.g. debian-policy) to facilitate offline work. > > the main elements shipped in gnupg-doc are: > > o The GNU Privacy Handbook > o Replacing PGP 2.x with GnuPG > o GnuPG mini-HOWTO > > Do you think that these things are not useful for people in offline > scenarios? Should we stop shipping one or more of those references? > Are there other references that you think we should ship? > Hi, I should probably have chimed in earlier. Originally I was referring to the GPG manual: https://www.gnupg.org/documentation/manuals/gnupg/Unattended-GPG-key-generation.html In DETAILS.gz in version 2.1, the section on "Unattended key generation" now has been deleted and says "Please see the GnuPG manual for a description", which I assume refers to the above page. I had hoped this might be in the gnupg-doc package, but this is not the case. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Mon Sep 22 21:12:40 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 22 Sep 2014 15:12:40 -0400 Subject: Why 2.1 is delayed for so long In-Reply-To: <54207369.60904@pwned.gg> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <87lhpey4iz.fsf@vigenere.g10code.de> <541D69B8.7060606@pwned.gg> <874mw2xwhc.fsf@vigenere.g10code.de> <874mvzybnf.fsf@alice.fifthhorseman.net> <87sijjtxqg.fsf@vigenere.g10code.de> <542071C4.1070408@fifthhorseman.net> <54207369.60904@pwned.gg> Message-ID: <542074A8.1080007@fifthhorseman.net> Hi Ximin-- On 09/22/2014 03:07 PM, Ximin Luo wrote: > Hi, I should probably have chimed in earlier. Originally I was referring to the GPG manual: > > https://www.gnupg.org/documentation/manuals/gnupg/Unattended-GPG-key-generation.html > > In DETAILS.gz in version 2.1, the section on "Unattended key generation" now has been deleted and says "Please see the GnuPG manual for a description", which I assume refers to the above page. I had hoped this might be in the gnupg-doc package, but this is not the case. i can see this in my debian system by running: info gnupg and then from the info browser, searching (ctrl-s) for 'unattended key generation' (without the quotes). Perhaps autobuilding and shipping the PDF would make this info more visible within debian as well? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From infinity0 at pwned.gg Mon Sep 22 21:23:33 2014 From: infinity0 at pwned.gg (Ximin Luo) Date: Mon, 22 Sep 2014 20:23:33 +0100 Subject: Why 2.1 is delayed for so long In-Reply-To: <542074A8.1080007@fifthhorseman.net> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <87lhpey4iz.fsf@vigenere.g10code.de> <541D69B8.7060606@pwned.gg> <874mw2xwhc.fsf@vigenere.g10code.de> <874mvzybnf.fsf@alice.fifthhorseman.net> <87sijjtxqg.fsf@vigenere.g10code.de> <542071C4.1070408@fifthhorseman.net> <54207369.60904@pwned.gg> <542074A8.1080007@fifthhorseman.net> Message-ID: <54207735.8000200@pwned.gg> On 22/09/14 20:12, Daniel Kahn Gillmor wrote: > Hi Ximin-- > > On 09/22/2014 03:07 PM, Ximin Luo wrote: >> Hi, I should probably have chimed in earlier. Originally I was referring to the GPG manual: >> >> https://www.gnupg.org/documentation/manuals/gnupg/Unattended-GPG-key-generation.html >> >> In DETAILS.gz in version 2.1, the section on "Unattended key generation" now has been deleted and says "Please see the GnuPG manual for a description", which I assume refers to the above page. I had hoped this might be in the gnupg-doc package, but this is not the case. > > i can see this in my debian system by running: > > info gnupg > > and then from the info browser, searching (ctrl-s) for 'unattended key > generation' (without the quotes). > > Perhaps autobuilding and shipping the PDF would make this info more > visible within debian as well? > > --dkg > Ah, whoops. I don't think adding a PDF would have helped me - I used `dpkg -L gnupg` and `dpkg -L gnupg-doc` and my eyes missed a single info file. I think all that is needed to fix this, is to update the man page: --gen-key [..] There is also a feature which allows you to create keys in batch mode. See the file ?doc/DETAILS? in the source distribution on how to use this. If this said directly "the Texinfo manual", I'm pretty confident I would have found it by myself. "GnuPG manual" doesn't immediately bring Texinfo to mind. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Mon Sep 22 21:40:45 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 22 Sep 2014 15:40:45 -0400 Subject: [PATCH] Allow ./configure to explicitly set libgpg-error's build timestamp Message-ID: <1411414845-5992-1-git-send-email-dkg@fifthhorseman.net> A group within Debian is working on making the archive rebuildable in a reproducible way, so that the compiled binary outputs are byte-for-byte identical when built for the same platform using the same toolchain. This is useful in providing auditability and corroboration for users of the operating system. libgpg-error is very close to reproducible except for embedding the build timestamp in the generated binary. This timestamp is set in config.h during ./configure. This patch allows an external build system to set this embedded timestamp explicitly, which appears to make the package build repeatably when ./configure is called with EXTERNAL_BUILD_TIMESTAMP set. Debian-bug-id: 762397 --- configure.ac | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index b32b751..1093077 100644 --- a/configure.ac +++ b/configure.ac @@ -484,7 +484,11 @@ changequote([,])dnl BUILD_FILEVERSION="${BUILD_FILEVERSION}0,mym4_revision_dec" AC_SUBST(BUILD_FILEVERSION) -BUILD_TIMESTAMP=`date -u +%Y-%m-%dT%H:%M+0000 2>/dev/null || date` +if test "$EXTERNAL_BUILD_TIMESTAMP" = ''; then + BUILD_TIMESTAMP=`date -u +%Y-%m-%dT%H:%M+0000 2>/dev/null || date` +else + BUILD_TIMESTAMP="$EXTERNAL_BUILD_TIMESTAMP" +fi AC_SUBST(BUILD_TIMESTAMP) AC_DEFINE_UNQUOTED(BUILD_TIMESTAMP, "$BUILD_TIMESTAMP", [The time this package was configured for a build]) -- 2.1.0 From dkg at fifthhorseman.net Mon Sep 22 21:44:40 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 22 Sep 2014 15:44:40 -0400 Subject: [PATCH] add src/syscfg/lock-obj-pub.powerpc64el-unknown-linux-gnu.h Message-ID: <1411415080-6159-1-git-send-email-dkg@fifthhorseman.net> Here is a arch-specific lock-obj header file for little-endian 64-bit powerpc. Debian-bug-id: 762322 --- .../lock-obj-pub.powerpc64el-unknown-linux-gnu.h | 25 ++++++++++++++++++++++ 1 file changed, 25 insertions(+) create mode 100644 src/syscfg/lock-obj-pub.powerpc64el-unknown-linux-gnu.h diff --git a/src/syscfg/lock-obj-pub.powerpc64el-unknown-linux-gnu.h b/src/syscfg/lock-obj-pub.powerpc64el-unknown-linux-gnu.h new file mode 100644 index 0000000..79073d4 --- /dev/null +++ b/src/syscfg/lock-obj-pub.powerpc64el-unknown-linux-gnu.h @@ -0,0 +1,25 @@ +## lock-obj-pub.powerpc64le-unknown-linux-gnu.h +## File created by gen-posix-lock-obj - DO NOT EDIT +## To be included by mkheader into gpg-error.h + +typedef struct +{ + long _vers; + union { + volatile char _priv[40]; + long _x_align; + long *_xp_align; + } u; +} gpgrt_lock_t; + +#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0}}} +## +## Local Variables: +## mode: c +## buffer-read-only: t +## End: +## -- 2.1.0 From dkg at fifthhorseman.net Mon Sep 22 23:19:36 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 22 Sep 2014 17:19:36 -0400 Subject: [PATCH] Allow ./configure to explicitly set libgpg-error's build timestamp In-Reply-To: <1411414845-5992-1-git-send-email-dkg@fifthhorseman.net> References: <1411414845-5992-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <54209268.3080201@fifthhorseman.net> On 09/22/2014 03:40 PM, Daniel Kahn Gillmor wrote: > A group within Debian is working on making the archive rebuildable in > a reproducible way, so that the compiled binary outputs are > byte-for-byte identical when built for the same platform using the > same toolchain. This is useful in providing auditability and > corroboration for users of the operating system. > > libgpg-error is very close to reproducible except for embedding the > build timestamp in the generated binary. This timestamp is set in > config.h during ./configure. > > This patch allows an external build system to set this embedded > timestamp explicitly, which appears to make the package build > repeatably when ./configure is called with EXTERNAL_BUILD_TIMESTAMP > set. Of course, another reasonable approach would be to avoid embedding the timestamp in the build at all. What is the advantage of including the timestamp in the built executable? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From chdiza at gmail.com Tue Sep 23 00:56:50 2014 From: chdiza at gmail.com (Charles Diza) Date: Mon, 22 Sep 2014 18:56:50 -0400 Subject: S In-Reply-To: <87y4tbu866.fsf@vigenere.g10code.de> References: <87r3z856kw.fsf@vigenere.g10code.de> <4E206518-D56F-4914-84C1-163693DCACAA@e1ven.com> <87y4tbu866.fsf@vigenere.g10code.de> Message-ID: On Mon, Sep 22, 2014 at 8:54 AM, Werner Koch wrote: > On Sun, 21 Sep 2014 18:29, e1ven at e1ven.com said: > > > Charles - I believe it's using gpgv to verify the downloads - If you > > Right, I hoped that at least gpgv is availabale on all major platforms > by default. It is the case for most Linux distributions. I print a > warning now. > gpgv does not and never did come with OSX. I'd never even heard of it until recently. > You'll also want to set gl_cv_absolute_stdint_h, so that gpg picks up the > version in /usr > > gl_cv_absolute_stdint_h=/usr/include/stdint.h > > With no access to an OS X mahcine it is hard for me to figure out why the > configure checks fail. I'd appreciate any help. > I'm no programmer, so I'm of very limited help. However, I do seem to recall that last time I looked into this the problem is more with Apple than with the configure checks. They had multiple copies of stdint.h, and when XCode5 came out, one of them was corrupt. The configure script detects the bad one unless one sets $gl_cv_absolute_stdint_h as above. I have found through testing that such a setting is backwards compatible to pre-XCode5; I got it to work all the way back to OSX 10.4.11 with XCode 2.5. But such a hard-coding might be susceptible to future breakage, because Apple loves to shift development headers around when new major versions of XCode get released. (Note that I have no problems with XCode 6.0.1 so far wrt gnupg2.0.26.) To avoid hard-coding, there will have to be some wizardry to detect OSX version and XCode version. And unfortunately I'm unable to help. Cheers, Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Tue Sep 23 08:27:12 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 23 Sep 2014 08:27:12 +0200 Subject: Why 2.1 is delayed for so long In-Reply-To: <54205AE2.40905@pwned.gg> (Ximin Luo's message of "Mon, 22 Sep 2014 18:22:42 +0100") References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> <54205AE2.40905@pwned.gg> Message-ID: <87fvfiua0v.fsf@vigenere.g10code.de> On Mon, 22 Sep 2014 19:22, infinity0 at pwned.gg said: > Whilst we're on this topic, I think the master key should be > certify-only by default, and have two subkeys for signing and > encryption. This means that someone can later move the master key to > separate storage, if they learn more about GPG and decide that this is > suitable for them. If you start off with a master key for > sign+certify, this is more awkward. I disagree. Two subkeys are the exception and are only used by a minority of people who want to put extra work into setting up their WoT. We may ask the keyserver admins whether they can figure out the percentage of keys which have a separate signing key. In any case, adding a signing subkey is simple and it just works for everyone as soon as the public key has been uploaded. It is actually much easier than replacing the encryption subkey (the you need to keep the old encryption key online for several months to be able to decrypt mails from people who didn't refreshed your key yet). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Sep 23 08:32:43 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 23 Sep 2014 08:32:43 +0200 Subject: Why 2.1 is delayed for so long In-Reply-To: <542071C4.1070408@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 22 Sep 2014 15:00:20 -0400") References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <87lhpey4iz.fsf@vigenere.g10code.de> <541D69B8.7060606@pwned.gg> <874mw2xwhc.fsf@vigenere.g10code.de> <874mvzybnf.fsf@alice.fifthhorseman.net> <87sijjtxqg.fsf@vigenere.g10code.de> <542071C4.1070408@fifthhorseman.net> Message-ID: <87bnq6u9ro.fsf@vigenere.g10code.de> On Mon, 22 Sep 2014 21:00, dkg at fifthhorseman.net said: > "info gnupg" works for me based on the debian package, and shows the I see, "info gpg: work on my servers. > We don't ship the PDF at the moment. do you think it adds anything to > ship the PDF as well as the info pages? No, we have it on the website anyway. > o The GNU Privacy Handbook > o Replacing PGP 2.x with GnuPG > o GnuPG mini-HOWTO > > Do you think that these things are not useful for people in offline > scenarios? Should we stop shipping one or more of those references? I think replacing PGP 2.x can be retired. The other two need an overhaul. In general, I think offline docs are a Goog Thing. > Are there other references that you think we should ship? The new FAQ. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Sep 23 08:38:15 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 23 Sep 2014 08:38:15 +0200 Subject: Why 2.1 is delayed for so long In-Reply-To: <54207735.8000200@pwned.gg> (Ximin Luo's message of "Mon, 22 Sep 2014 20:23:33 +0100") References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <87lhpey4iz.fsf@vigenere.g10code.de> <541D69B8.7060606@pwned.gg> <874mw2xwhc.fsf@vigenere.g10code.de> <874mvzybnf.fsf@alice.fifthhorseman.net> <87sijjtxqg.fsf@vigenere.g10code.de> <542071C4.1070408@fifthhorseman.net> <54207369.60904@pwned.gg> <542074A8.1080007@fifthhorseman.net> <54207735.8000200@pwned.gg> Message-ID: <877g0uu9ig.fsf@vigenere.g10code.de> On Mon, 22 Sep 2014 21:23, infinity0 at pwned.gg said: > If this said directly "the Texinfo manual", I'm pretty confident I > would have found it by myself. "GnuPG manual" doesn't immediately > bring Texinfo to mind. texinfo is just the source format. Most don't read that but the HTML, PDF, or INFO versions. Thus "Manual". Having the PDF installed or at least a more prominent pointer to the online version in the README.Debian may be useful. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Sep 23 08:44:08 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 23 Sep 2014 08:44:08 +0200 Subject: [PATCH] Allow ./configure to explicitly set libgpg-error's build timestamp In-Reply-To: <1411414845-5992-1-git-send-email-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 22 Sep 2014 15:40:45 -0400") References: <1411414845-5992-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <87tx3ysuo7.fsf@vigenere.g10code.de> On Mon, 22 Sep 2014 21:40, dkg at fifthhorseman.net said: > A group within Debian is working on making the archive rebuildable in > a reproducible way, so that the compiled binary outputs are > byte-for-byte identical when built for the same platform using the I am not that convinced about need for binary indetical builds but if they really want that ... > This patch allows an external build system to set this embedded > timestamp explicitly, which appears to make the package build > repeatably when ./configure is called with EXTERNAL_BUILD_TIMESTAMP Is EXTERNAL_BUILD_TIMESTAMP a de-facto Debian standard for that? If not I would prefer to use a configure option for this. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Sep 23 08:48:54 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 23 Sep 2014 08:48:54 +0200 Subject: [PATCH] Allow ./configure to explicitly set libgpg-error's build timestamp In-Reply-To: <54209268.3080201@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 22 Sep 2014 17:19:36 -0400") References: <1411414845-5992-1-git-send-email-dkg@fifthhorseman.net> <54209268.3080201@fifthhorseman.net> Message-ID: <87ppemsug9.fsf@vigenere.g10code.de> On Mon, 22 Sep 2014 23:19, dkg at fifthhorseman.net said: > What is the advantage of including the timestamp in the built executable? Windows does it too ;-) A timestamp is helpful to analyze bug reports from production systems. Often it is not clear how or when a binary has been build; the timestamp can be helpful to find the used build environment. It is also part of the embedded copyright info which is very useful to research copyright violations. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Sep 23 09:15:38 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 23 Sep 2014 09:15:38 +0200 Subject: S In-Reply-To: (Charles Diza's message of "Mon, 22 Sep 2014 18:56:50 -0400") References: <87r3z856kw.fsf@vigenere.g10code.de> <4E206518-D56F-4914-84C1-163693DCACAA@e1ven.com> <87y4tbu866.fsf@vigenere.g10code.de> Message-ID: <87h9zyst7p.fsf@vigenere.g10code.de> On Tue, 23 Sep 2014 00:56, chdiza at gmail.com said: > 6.0.1 so far wrt gnupg2.0.26.) To avoid hard-coding, there will have to be > some wizardry to detect OSX version and XCode version. And unfortunately This can of course be done but for the meatime it might be easier to docuemtnthe workaround. I have put this intop the README: ** Specific build problems on some machines: *** Apple OSX 10.x using XCode On some versions the correct location of a header file can't be detected by configure. To fix that you should run configure like this ./configure gl_cv_absolute_stdint_h=/usr/include/stdint.h Add other options as needed. Anything else? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernhard at intevation.de Tue Sep 23 10:11:29 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 23 Sep 2014 10:11:29 +0200 Subject: GPGME 1.5.1: Invalid crypto engine In-Reply-To: <54169438.5030804@chili-radiology.com> References: <54169438.5030804@chili-radiology.com> Message-ID: <201409231011.35171.bernhard@intevation.de> On Monday 15 September 2014 at 09:24:40, Florian Schwind wrote: > I added some debug output and also exported > GPGME_DEBUG which did only help to narrow down to problem to the file > engine.c and the call of engine_get_file_name (proto_list[proto]), which > returns NULL for the OpenGPG protocol. Add some printf debugging lines or use a debugger to compare how OpenSuse (success) and SLES 10 (failure) runs through the code. You could also compare other things between the success and the failure case, like the environment variables, installed packages. > I'm using the newest versions available: GPGME 1.5.1, GPG 1.4.18 and > LIBGPG-ERR 1.14. > > Does anyone have an idea how to proceed? HTH, Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by 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 infinity0 at pwned.gg Tue Sep 23 12:14:40 2014 From: infinity0 at pwned.gg (Ximin Luo) Date: Tue, 23 Sep 2014 11:14:40 +0100 Subject: Why 2.1 is delayed for so long In-Reply-To: <87fvfiua0v.fsf@vigenere.g10code.de> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> <54205AE2.40905@pwned.gg> <87fvfiua0v.fsf@vigenere.g10code.de> Message-ID: <54214810.50300@pwned.gg> On 23/09/14 07:27, Werner Koch wrote: > On Mon, 22 Sep 2014 19:22, infinity0 at pwned.gg said: > >> Whilst we're on this topic, I think the master key should be >> certify-only by default, and have two subkeys for signing and >> encryption. This means that someone can later move the master key to >> separate storage, if they learn more about GPG and decide that this is >> suitable for them. If you start off with a master key for >> sign+certify, this is more awkward. > > I disagree. Two subkeys are the exception and are only used by a > minority of people who want to put extra work into setting up their WoT. > We may ask the keyserver admins whether they can figure out the > percentage of keys which have a separate signing key. > > In any case, adding a signing subkey is simple and it just works for > everyone as soon as the public key has been uploaded. It is actually > much easier than replacing the encryption subkey (the you need to keep > the old encryption key online for several months to be able to decrypt > mails from people who didn't refreshed your key yet). > "Two subkeys are the exception" because it's not the default and people don't know better. If it were made the default, it would become the norm. What is the disadvantage to having two subkeys? You keep knocking down my suggestions because "it's easy [for the user] to do [X]". However, if you keep making arguments like this, the overall effect is that a typical user has to tweak a lot of things to get a maximal level of security, which is not good usability-wise. Another suggestion is, a revocation certificate should be automatically generated when a key is generated, with clear instructions on the user what to do with it. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From infinity0 at pwned.gg Tue Sep 23 12:25:45 2014 From: infinity0 at pwned.gg (Ximin Luo) Date: Tue, 23 Sep 2014 11:25:45 +0100 Subject: Why 2.1 is delayed for so long In-Reply-To: <877g0uu9ig.fsf@vigenere.g10code.de> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <87lhpey4iz.fsf@vigenere.g10code.de> <541D69B8.7060606@pwned.gg> <874mw2xwhc.fsf@vigenere.g10code.de> <874mvzybnf.fsf@alice.fifthhorseman.net> <87sijjtxqg.fsf@vigenere.g10code.de> <542071C4.1070408@fifthhorseman.net> <54207369.60904@pwned.gg> <542074A8.1080007@fifthhorseman.net> <54207735.8000200@pwned.gg> <877g0uu9ig.fsf@vigenere.g10code.de> Message-ID: <54214AA9.3080300@pwned.gg> On 23/09/14 07:38, Werner Koch wrote: > On Mon, 22 Sep 2014 21:23, infinity0 at pwned.gg said: > >> If this said directly "the Texinfo manual", I'm pretty confident I >> would have found it by myself. "GnuPG manual" doesn't immediately >> bring Texinfo to mind. > > texinfo is just the source format. Most don't read that but the HTML, > PDF, or INFO versions. Thus "Manual". Having the PDF installed or at > least a more prominent pointer to the online version in the > README.Debian may be useful. > > The main point is that you should fix the double-redirect from man page -> DETAILS -> "Manual". You can word it better than I did, to make the point that the manual is also available different formats. At the bottom of the man page, it already mentions the "Texinfo manual" and "`info gnupg`", so perhaps you can point to that. It's not clear that "GnuPG manual" refers to a system-installed document, when the system already has man pages. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From infinity0 at pwned.gg Tue Sep 23 12:48:53 2014 From: infinity0 at pwned.gg (Ximin Luo) Date: Tue, 23 Sep 2014 11:48:53 +0100 Subject: Why 2.1 is delayed for so long In-Reply-To: <8738bjvo1g.fsf@vigenere.g10code.de> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <87lhpey4iz.fsf@vigenere.g10code.de> <541D69B8.7060606@pwned.gg> <874mw2xwhc.fsf@vigenere.g10code.de> <541D8B1B.9020608@pwned.gg> <8738bjvo1g.fsf@vigenere.g10code.de> Message-ID: <54215015.8050104@pwned.gg> On 22/09/14 13:26, Werner Koch wrote: > On Sat, 20 Sep 2014 16:11, infinity0 at pwned.gg said: > >> As I observe, if the current GPG_AGENT_INFO has a different homedir >> from GNUPGHOME, gpg2 will happily use that agent, rather than starting >> up a new one for the current GNUPGHOME. > > That is why I suggested to unset GPG_AGENT_INFO in the bashrc. I need > to research whether we can completely do without GPG_AGENT_INFO. IT is > only used in case a non-standard socket is used. For what I know, this > is required if the GNUPGHOME is mounted on file system which does not > support sockets (i.e. remove file system or vfat). An idea would be to > stat the socket file and if is a real file, read the name of the to be > used socket form that file. Thus it must be created prior to starting > gpg-agent and be considered a configuration file. This would actually > help to remove some code from GnuPG. Implementation should be easy, most > can be done in Libassuan. > OK. This is a major issue I can see for GPG 2.1 as a user, I will keep an eye on it. As for the upgrade behaviour that dkg and I had problems with: how about, when gpg 2.1 upgrades your homedir, it does a "getinfo" on the gpg-agent it connects to, and if it's actually a 2.0 gpg-agent then it kills it and starts a 2.1 one automatically? >>>> Well, at least it should say the keyid, whether it is a subkey (what use-flags) and (if so) which master key it belongs to? >>> >>> Why? You already told gpg what to create. >>> >> >> From a script or program or batch mode generation, the user might not >> have any notice on what the program is trying to do. So gpg-agent >> should still display this information. > > The script should tell that the user. If you think this is important, > please add it as a feature request for 2.1 to the BTS. > OK, I will file. > > [pinentry while signing] >> Yes, the good case is for signatures in GPG 1.4. I'm saying the bad >> case for key creation in GPG 2.1 should be like the good case, as >> discussed above. > > Sorry, I don't understand. > >> For GPG 2.1, key creation only says "Please enter the passphrase to >> protect your new key". > > 1.4 and 2.0 use very similar prompts. We can't use the standard prompt > because we do not know the keyid at that point. Yes, we could ask after > key creation but that has the problem that the prompt for the > passphrase would show up only after minutes and the user needs to wait > for it and not come back and the key has already been protected and > saved. > You don't know the keyid for the master key, but you know the UID and expiry date, and the fact it's a master key. For subkeys, you know the master key it's associated with, and its UIDs. This would be useful information in the prompt as well. Come on, work with me here instead of just trying to find ways to knock down my suggestions. I am trying to help. >> I guess it's rarely used because it's not useful? The case where batch mode is needed most (for complex key creation) is not supported by it! > > I assume that if there is a need for it, you have the time to implement > a proper script to control gpg. Sometimes new commands make sense, like > the --quick-sign-key I implemented for something John Gilmore was > hacking on. > >> I am already doing this. Scripting the CLI is awkward and annoying, >> and the source code ends up giving no indication to the user what is >> actually happening unless you know the GPG CLI off by heart. See [1] > > > No, no. You should never do it this way. That is not scripting the > interface but feeding it with canned commands. This will for sure > break. For example the original author of GPA did it this way and it > broke with the next vesion of gpg. It is entirely unreliable. GnuPG > has a machine oriented interface for a reason; you are ignoring it. > > Here is an extract from mail-signed-keys which uses the machine > interface as intended: > > gpg OTHEROPTIONS --check-sigs --with-colons 2>/dev/null \ > | awk -F: -v signedby="$signedby" ' > BEGIN { sendmail="/usr/lib/sendmail -oi -t " } > $1 == "pub" { nextkid=$5; nextuid=$10 > if( uidcount > 0 ) { myflush() } > kid=nextkid; uid=nextuid; next > } > $1 == "uid" { uid=$10 ; next } > $1 == "sig" && $2 == "!" && $5 == signedby { uids[uidcount++] = uid; next } > END { if( uidcount > 0 ) { myflush() } } > ' > > Using --gen-key is more complicated, though. You need to wait for > "[GNUPG:] GET_LINE", switch on the following argument > (e.g. "keygen.algo") and send appropriate answers. If you not know the > argument, just answer with a LF which takes the default. You should see > "GOT_IT" line next; if not something went wrong. You can do that with > awk or perl, or whatever you like. > OK, it is good there is some sort of machine-scriptable interface in mind. Ideally though, one should not have to go to the complexity of writing a multi-round request-response protocol script, for a task where you already know all the input info at the start of the task - such as key generation. But sure, I get you have other things to do; I can have a go at writing a python script or that reads a descriptor like "batch mode" and interacts with GPG via GET_LINE to create a key. (I would just fix "batch mode", but I'm not good at C.) Would you be interested in having that as part of GPG, as a key generation script? Are the parameters documented anywhere? For example, I see GET_LINE in DETAILS but no mention of the possible options it takes. Of course I can play with it, it is just more awkward and I'd have to guess the behaviour. >> Seriously though, it is bad UX experience to go several steps without >> being able to correct yourself. > > Yeah well, but in the last 16 years that was not a real problem. > Implementing such extras is easy but testing them takes lots of time. > UX issues are typically not "problems" that people will bother reporting. Indeed I didn't bother, until I came to write about other more important things, and thought I'd lump it in. OK, I will file a bug for this and we'll see if it ever gets done. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue Sep 23 14:58:09 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 23 Sep 2014 14:58:09 +0200 Subject: Why 2.1 is delayed for so long In-Reply-To: <54214810.50300@pwned.gg> (Ximin Luo's message of "Tue, 23 Sep 2014 11:14:40 +0100") References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> <54205AE2.40905@pwned.gg> <87fvfiua0v.fsf@vigenere.g10code.de> <54214810.50300@pwned.gg> Message-ID: <877g0usdcu.fsf@vigenere.g10code.de> On Tue, 23 Sep 2014 12:14, infinity0 at pwned.gg said: > "Two subkeys are the exception" because it's not the default and > people don't know better. If it were made the default, it would become > the norm. What is the disadvantage to having two subkeys? Let's first ask ourselves what is the advantage of it? I know only one use case for a signing subkey which is to use the primary key only on an offline machine. > user] to do [X]". However, if you keep making arguments like this, the > overall effect is that a typical user has to tweak a lot of things to > get a maximal level of security, which is not good usability-wise. The typical user shall use the defaults. If you don't like the defaults, please distribute your own modified version of the software. > Another suggestion is, a revocation certificate should be > automatically generated when a key is generated, with clear > instructions on the user what to do with it. Didn't you noticed the ~/.gnupg/openpgp-revocs.d ? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Sep 23 15:00:10 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 23 Sep 2014 15:00:10 +0200 Subject: Why 2.1 is delayed for so long In-Reply-To: <54214AA9.3080300@pwned.gg> (Ximin Luo's message of "Tue, 23 Sep 2014 11:25:45 +0100") References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <87lhpey4iz.fsf@vigenere.g10code.de> <541D69B8.7060606@pwned.gg> <874mw2xwhc.fsf@vigenere.g10code.de> <874mvzybnf.fsf@alice.fifthhorseman.net> <87sijjtxqg.fsf@vigenere.g10code.de> <542071C4.1070408@fifthhorseman.net> <54207369.60904@pwned.gg> <542074A8.1080007@fifthhorseman.net> <54207735.8000200@pwned.gg> <877g0uu9ig.fsf@vigenere.g10code.de> <54214AA9.3080300@pwned.gg> Message-ID: <8738bisd9h.fsf@vigenere.g10code.de> On Tue, 23 Sep 2014 12:25, infinity0 at pwned.gg said: > It's not clear that "GnuPG manual" refers to a system-installed > document, when the system already has man pages. Then please actually READ the man pages, e.g.: $ man gpg2 | tail -15 SEE ALSO gpgv(1), gpgsm(1), gpg-agent(1) The full documentation for this tool is maintained as a Texinfo manual. If GnuPG and the info program are properly installed at your site, the command info gnupg should give you access to the complete manual including a menu struc ture and an index. [...] -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From infinity0 at pwned.gg Tue Sep 23 15:25:15 2014 From: infinity0 at pwned.gg (Ximin Luo) Date: Tue, 23 Sep 2014 14:25:15 +0100 Subject: Why 2.1 is delayed for so long In-Reply-To: <877g0usdcu.fsf@vigenere.g10code.de> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> <54205AE2.40905@pwned.gg> <87fvfiua0v.fsf@vigenere.g10code.de> <54214810.50300@pwned.gg> <877g0usdcu.fsf@vigenere.g10code.de> Message-ID: <542174BB.1080005@pwned.gg> On 23/09/14 13:58, Werner Koch wrote: > On Tue, 23 Sep 2014 12:14, infinity0 at pwned.gg said: > >> "Two subkeys are the exception" because it's not the default and >> people don't know better. If it were made the default, it would become >> the norm. What is the disadvantage to having two subkeys? > > Let's first ask ourselves what is the advantage of it? I know only one > use case for a signing subkey which is to use the primary key only on an > offline machine. > Yes, this is the use-case. It's clearer architecturally. Longer-term benefits include not accidentally using the master key for signing, for a naive program that has access to your master key. If you prefer "less keys", why not default to Certify+Sign+Authenticate? I am not sure Certify+Sign makes sense from any position. >> user] to do [X]". However, if you keep making arguments like this, the >> overall effect is that a typical user has to tweak a lot of things to >> get a maximal level of security, which is not good usability-wise. > > The typical user shall use the defaults. If you don't like the > defaults, please distribute your own modified version of the software. > You are being hasty and this is extremely unproductive logic. We are talking about what the defaults *should be*. You know that it's extremely costly to distribute a fork; I start at a disadvantage if I want to test the validity of my ideas in the market. Your ultimatum is about as short-sighted as saying "if you don't like the laws, get out of the country". >> Another suggestion is, a revocation certificate should be >> automatically generated when a key is generated, with clear >> instructions on the user what to do with it. > > Didn't you noticed the ~/.gnupg/openpgp-revocs.d ? > No, I did not. If you expect people to notice this, you should mention this when a key is generated, and also in the man page. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From infinity0 at pwned.gg Tue Sep 23 15:28:15 2014 From: infinity0 at pwned.gg (Ximin Luo) Date: Tue, 23 Sep 2014 14:28:15 +0100 Subject: Why 2.1 is delayed for so long In-Reply-To: <8738bisd9h.fsf@vigenere.g10code.de> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <87lhpey4iz.fsf@vigenere.g10code.de> <541D69B8.7060606@pwned.gg> <874mw2xwhc.fsf@vigenere.g10code.de> <874mvzybnf.fsf@alice.fifthhorseman.net> <87sijjtxqg.fsf@vigenere.g10code.de> <542071C4.1070408@fifthhorseman.net> <54207369.60904@pwned.gg> <542074A8.1080007@fifthhorseman.net> <54207735.8000200@pwned.gg> <877g0uu9ig.fsf@vigenere.g10code.de> <54214AA9.3080300@pwned.gg> <8738bisd9h.fsf@vigenere.g10code.de> Message-ID: <5421756F.1020107@pwned.gg> On 23/09/14 14:00, Werner Koch wrote: > On Tue, 23 Sep 2014 12:25, infinity0 at pwned.gg said: > >> It's not clear that "GnuPG manual" refers to a system-installed >> document, when the system already has man pages. > > Then please actually READ the man pages, e.g.: > > $ man gpg2 | tail -15 SEE ALSO gpgv(1), gpgsm(1), gpg-agent(1) > > The full documentation for this tool is maintained as a Texinfo > manual. If GnuPG and the info program are properly installed at your > site, the command > > info gnupg > > should give you access to the complete manual including a menu > struc ture and an index. [...] > > I did read this already, which is why I suggested: On 23/09/14 11:25, Ximin Luo wrote: > You can word it better than I did, to make the point that the manual > is also available different formats. At the bottom of the man page, > it already mentions the "Texinfo manual" and "`info gnupg`", so > perhaps you can point to that. The phrase "GnuPG manual" is from DETAILS, which makes no mention of "`info gnupg`". Why bother asking for feedback when all you are going to do is imply I'm stupid for not following double-redirects and understanding ambiguous references? X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Tue Sep 23 15:51:16 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 23 Sep 2014 09:51:16 -0400 Subject: Bug#762397: [PATCH] Allow ./configure to explicitly set libgpg-error's build timestamp In-Reply-To: <87tx3ysuo7.fsf@vigenere.g10code.de> References: <1411414845-5992-1-git-send-email-dkg@fifthhorseman.net> <87tx3ysuo7.fsf@vigenere.g10code.de> Message-ID: <54217AD4.4090707@fifthhorseman.net> On 09/23/2014 02:44 AM, Werner Koch wrote: > Is EXTERNAL_BUILD_TIMESTAMP a de-facto Debian standard for that? If not > I would prefer to use a configure option for this. EXTERNAL_BUILD_TIMESTAMP is not a de-facto debian standard. If you would prefer a configure option, that would be fine as well. I went with an environment variable for my patch because it seemed simplest (and it can be passed as an argument to ./configure as well, e.g. ./configure EXTERNAL_BUILD_TIMESTAMP=2014-09-23T09:49+0000 ) but i have no objection to an explicit configure option. Do you want me to submit a revised patch using a configure option? if so, what would you prefer the name to be? Thanks for considering this, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Tue Sep 23 16:12:10 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 23 Sep 2014 10:12:10 -0400 Subject: Why 2.1 is delayed for so long In-Reply-To: <54214810.50300@pwned.gg> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> <54205AE2.40905@pwned.gg> <87fvfiua0v.fsf@vigenere.g10code.de> <54214810.50300@pwned.gg> Message-ID: <54217FBA.4010002@sixdemonbag.org> > However, if you keep making arguments like this, the overall effect > is that a typical user has to tweak a lot of things to get a maximal > level of security I've got two problems with this: First, "security" is a vague and pretty much meaningless word. It must be contextualized to have any usefulness. Security against which threats? Is it likely is the normal user will encounter these threats, or are these threats unlikely? Second, "maximal level of security" is ... it leads to some extreme and not very helpful 'solutions'. For instance, if you want a maximal level of security against the risk of auto accident, your only choice is to never go within several hundred meters of an automobile. That's why we talk about mitigating risks rather than providing maximal security. You can't get a maximal level of security against auto accidents and still be able to drive to work, but you *can* wear a seat belt, never drive impaired, and have your car regularly checked for safety issues. Risks are to be mitigated to a reasonable degree -- not to a maximal degree. From infinity0 at pwned.gg Tue Sep 23 16:22:15 2014 From: infinity0 at pwned.gg (Ximin Luo) Date: Tue, 23 Sep 2014 15:22:15 +0100 Subject: Why 2.1 is delayed for so long In-Reply-To: <54217FBA.4010002@sixdemonbag.org> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> <54205AE2.40905@pwned.gg> <87fvfiua0v.fsf@vigenere.g10code.de> <54214810.50300@pwned.gg> <54217FBA.4010002@sixdemonbag.org> Message-ID: <54218217.7060503@pwned.gg> On 23/09/14 15:12, Robert J. Hansen wrote: >> However, if you keep making arguments like this, the overall effect >> is that a typical user has to tweak a lot of things to get a maximal >> level of security > > I've got two problems with this: > > First, "security" is a vague and pretty much meaningless word. It must > be contextualized to have any usefulness. Security against which > threats? Is it likely is the normal user will encounter these threats, > or are these threats unlikely? > > Second, "maximal level of security" is ... it leads to some extreme and > not very helpful 'solutions'. For instance, if you want a maximal level > of security against the risk of auto accident, your only choice is to > never go within several hundred meters of an automobile. That's why we > talk about mitigating risks rather than providing maximal security. You > can't get a maximal level of security against auto accidents and still > be able to drive to work, but you *can* wear a seat belt, never drive > impaired, and have your car regularly checked for safety issues. > > Risks are to be mitigated to a reasonable degree -- not to a maximal degree. > We all know this, yes my words could have been more precise. But you're generalising to a degree outside of the original context. As security software developers, we should aim to automate as much as possible that increases a user's security. This means it's cheaper *on the user side* to get the same level of security, than if there was no automation. This is based on the premise that everyone is OK with getting extra security "for free", which I think is a reasonable premise. (Of course everyone has different security levels.) Where there is a trade-off in security, then certain automation shouldn't be done. I don't think that's the case here with 2 subkeys, though. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue Sep 23 16:23:53 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 23 Sep 2014 16:23:53 +0200 Subject: Why 2.1 is delayed for so long In-Reply-To: <542174BB.1080005@pwned.gg> (Ximin Luo's message of "Tue, 23 Sep 2014 14:25:15 +0100") References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> <54205AE2.40905@pwned.gg> <87fvfiua0v.fsf@vigenere.g10code.de> <54214810.50300@pwned.gg> <877g0usdcu.fsf@vigenere.g10code.de> <542174BB.1080005@pwned.gg> Message-ID: <87vboequti.fsf@vigenere.g10code.de> On Tue, 23 Sep 2014 15:25, infinity0 at pwned.gg said: > You are being hasty and this is extremely unproductive logic. We are > talking about what the defaults *should be*. You know that it's You are talking about this. In fact you suggest to change lots of things without taking the standards and the expectations of the existing users in account. I am all in favor for changes to make the use easier. Adding new features and changing the long established defaults is just the opposite. > want to test the validity of my ideas in the market. Your ultimatum is > about as short-sighted as saying "if you don't like the laws, get out > of the country". I am not in a position to issue an ultimatum and won't do that in any case. I merely said that your suggestion of an extra key won't be the default and remarked that you are free to change the defaults. Oh wait: You may also contact me at my company address and ask for a quote to change and maintain a version of GnuPG changed to your suites; or ask someone else for example those listed at https://gnupg.org/service.html . > No, I did not. If you expect people to notice this, you should mention > this when a key is generated, and also in the man page. Care to read the NEWS? Noteworthy changes in version 2.1.0-beta751 (2014-07-03) -------------------------------------------------------- * gpg: Make export of secret keys work again. * gpg: Create revocation certificates during key generation. and please recall that this is about a beta version, we are on a devel list and that there are bugs in the code and definitely in the docs. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rjh at sixdemonbag.org Tue Sep 23 16:31:16 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 23 Sep 2014 10:31:16 -0400 Subject: Why 2.1 is delayed for so long In-Reply-To: <542174BB.1080005@pwned.gg> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> <54205AE2.40905@pwned.gg> <87fvfiua0v.fsf@vigenere.g10code.de> <54214810.50300@pwned.gg> <877g0usdcu.fsf@vigenere.g10code.de> <542174BB.1080005@pwned.gg> Message-ID: <54218434.80202@sixdemonbag.org> > Yes, this is the use-case. It's clearer architecturally. Longer-term > benefits include not accidentally using the master key for signing, > for a naive program that has access to your master key. If you > prefer "less keys", why not default to Certify+Sign+Authenticate? I > am not sure Certify+Sign makes sense from any position. This may require a little bit of history. Most people think of Occam's razor as "the simplest explanation is best," but that's actually not right: William of Ockham's original formulation was "do not multiply objects without necessity." In the PGP 2.6 days there was only a single key which did everything. Then the U.K. passed a law, the Regulation of Investigatory Powers Act, which gave the government a way to demand encryption keys from suspects. This was troubling for PGP, since giving over your encryption key also meant giving the government the ability to impersonate you. In order to defend against RIPA and RIPA-like laws, the OpenPGP community decided to use separate encryption and signing keys. Further, there was (at the time) some talk from the theoretical cryptographic community that using the same key for encryption and signing could lead to attacks on the system. Although this research didn't pan out (at least as applied to OpenPGP), this too caused a lot of people in the community to think separating keys into signing and encryption sets was a good idea. All told, if my memory is right this took a couple of years of argument and people implementing their own testbeds and everything else before things got sorted out. Occam approves. Objects were multiplied, but only because they needed to be -- and it took a good bit of time, which meant the changes were judicious, thoroughly debated, and we had real-world tests before anyone went off adopting them for large systems. I don't think you've made a compelling case for multiplying them yet again. > You are being hasty and this is extremely unproductive logic. We are > talking about what the defaults *should be*. You know that it's > extremely costly to distribute a fork; I start at a disadvantage if > I want to test the validity of my ideas in the market. Every new idea starts at a disadvantage, yet ideas displace other ideas with astonishing speed. It's like Bob Heinlein said: "Of course the game is rigged, but don't let that stop you: you can't win if you don't play." From rjh at sixdemonbag.org Tue Sep 23 16:36:33 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 23 Sep 2014 10:36:33 -0400 Subject: Why 2.1 is delayed for so long In-Reply-To: <54218217.7060503@pwned.gg> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> <54205AE2.40905@pwned.gg> <87fvfiua0v.fsf@vigenere.g10code.de> <54214810.50300@pwned.gg> <54217FBA.4010002@sixdemonbag.org> <54218217.7060503@pwned.gg> Message-ID: <54218571.6060708@sixdemonbag.org> > We all know this... Please forgive me, but I'm not certain that you do. You keep on using that word "security" without ever stating secure against *what*. I'm fairly sure I'm not an idiot. (At least, today I am. Other days...) And if while reading your messages I can't figure out what you mean when you say "security," then I'm pretty sure a good number of other people can't, either. So, please. What is it that you're aiming to secure the system against? What's the precise threat model, and how likely is it that a regular user will encounter this risk? From wk at gnupg.org Tue Sep 23 16:35:01 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 23 Sep 2014 16:35:01 +0200 Subject: Bug#762397: [PATCH] Allow ./configure to explicitly set libgpg-error's build timestamp In-Reply-To: <54217AD4.4090707@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 23 Sep 2014 09:51:16 -0400") References: <1411414845-5992-1-git-send-email-dkg@fifthhorseman.net> <87tx3ysuo7.fsf@vigenere.g10code.de> <54217AD4.4090707@fifthhorseman.net> Message-ID: <87r3z2quay.fsf@vigenere.g10code.de> On Tue, 23 Sep 2014 15:51, dkg at fifthhorseman.net said: > Do you want me to submit a revised patch using a configure option? if > so, what would you prefer the name to be? Hmmm, --enable-external-build-timestamp=foo is quite long. We need to use --enable-something however. Would --enable-build-timestamp=foo be okay and to use --disable-build-timestamp to change the timestamp to "[none]" or "1970-01-01...". While we are already at it, we should also have a --enable-build-hostname which is used by GnuPG to put that info into the Windows versioninfo property. I can implement that, but if you want to do it please send a DCO for gnupg - which might be useful anyway. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From infinity0 at pwned.gg Tue Sep 23 16:49:40 2014 From: infinity0 at pwned.gg (Ximin Luo) Date: Tue, 23 Sep 2014 15:49:40 +0100 Subject: Why 2.1 is delayed for so long In-Reply-To: <54218434.80202@sixdemonbag.org> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> <54205AE2.40905@pwned.gg> <87fvfiua0v.fsf@vigenere.g10code.de> <54214810.50300@pwned.gg> <877g0usdcu.fsf@vigenere.g10code.de> <542174BB.1080005@pwned.gg> <54218434.80202@sixdemonbag.org> Message-ID: <54218884.7040202@pwned.gg> On 23/09/14 15:31, Robert J. Hansen wrote: >> Yes, this is the use-case. It's clearer architecturally. Longer-term >> benefits include not accidentally using the master key for signing, >> for a naive program that has access to your master key. If you >> prefer "less keys", why not default to Certify+Sign+Authenticate? I >> am not sure Certify+Sign makes sense from any position. > > This may require a little bit of history. > > [..] > > Occam approves. Objects were multiplied, but only because they needed > to be -- and it took a good bit of time, which meant the changes were > judicious, thoroughly debated, and we had real-world tests before anyone > went off adopting them for large systems. > > I don't think you've made a compelling case for multiplying them yet again. > Yes, it would seem you're not learning *enough* from this history. New laws are being passed that make it legal (hah!) for intelligence services to hack into computers. I would rather different keys for different purposes be separated, and my master key moved offline. If my signature key gets compromised, at least they can only write emails claiming to be me, not sign fake keys on my behalf. Plenty of skilled people are already using Certify-only master keys. I certainly want to, but it's awkward because I don't want to keep changing my long-term key. As soon as EdDSA is stable, I am going to generate a new one. Many GPG guides propose this. There is very little cost to the user in doing this automatically. The case is as I said - clearer architecture, and less likely to make mistakes writing programs to interact with them. As security developers, we are trying to improve best practises. In the future, it should be easy to put your master key offline. So it is better to prepare for that situation now, instead of asking everyone to generate a new key and refresh everyone else's key when the time comes. >> You are being hasty and this is extremely unproductive logic. We are >> talking about what the defaults *should be*. You know that it's >> extremely costly to distribute a fork; I start at a disadvantage if >> I want to test the validity of my ideas in the market. > > Every new idea starts at a disadvantage, yet ideas displace other ideas > with astonishing speed. It's like Bob Heinlein said: "Of course the > game is rigged, but don't let that stop you: you can't win if you don't > play." > Be careful what you wish for. http://lkml.iu.edu//hypermail/linux/kernel/0210.1/1834.html X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Tue Sep 23 17:17:04 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 23 Sep 2014 11:17:04 -0400 Subject: [PATCH] Add new lock-obj-pub for sparc64-unknown-linux-gnu. Message-ID: <1411485424-4773-1-git-send-email-dkg@fifthhorseman.net> * src/syscfg/lock-obj-pub.sparc64-unknown-linux-gnu.h: New. * src/Makefile.am (lock_obj_pub): Add. -- Helmut Grohne writes: Julien Cristau pointed out that sparc porter machines run 64bit kernels and can execute 64bit executables. So here we go. I crossed gen-posix-lock-obj for sparc64, verified that it is indeed a 64bit executable and attach its output. Debian-bug-id: 762322 --- src/Makefile.am | 1 + .../lock-obj-pub.sparc64-unknown-linux-gnu.h | 25 ++++++++++++++++++++++ 2 files changed, 26 insertions(+) create mode 100644 src/syscfg/lock-obj-pub.sparc64-unknown-linux-gnu.h diff --git a/src/Makefile.am b/src/Makefile.am index def0f45..62579dc 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -61,6 +61,7 @@ lock_obj_pub = \ syscfg/lock-obj-pub.s390x-ibm-linux-gnu.h \ syscfg/lock-obj-pub.sh4-unknown-linux-gnu.h \ syscfg/lock-obj-pub.sparc-unknown-linux-gnu.h \ + syscfg/lock-obj-pub.sparc64-unknown-linux-gnu.h \ syscfg/lock-obj-pub.x86_64-pc-kfreebsd-gnu.h \ syscfg/lock-obj-pub.x86_64-pc-linux-gnu.h \ syscfg/lock-obj-pub.x86_64-pc-linux-gnux32.h \ diff --git a/src/syscfg/lock-obj-pub.sparc64-unknown-linux-gnu.h b/src/syscfg/lock-obj-pub.sparc64-unknown-linux-gnu.h new file mode 100644 index 0000000..ee309a9 --- /dev/null +++ b/src/syscfg/lock-obj-pub.sparc64-unknown-linux-gnu.h @@ -0,0 +1,25 @@ +## lock-obj-pub.sparc64-unknown-linux-gnu.h +## File created by gen-posix-lock-obj - DO NOT EDIT +## To be included by mkheader into gpg-error.h + +typedef struct +{ + long _vers; + union { + volatile char _priv[40]; + long _x_align; + long *_xp_align; + } u; +} gpgrt_lock_t; + +#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0}}} +## +## Local Variables: +## mode: c +## buffer-read-only: t +## End: +## -- 2.1.0 From rjh at sixdemonbag.org Tue Sep 23 17:36:44 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 23 Sep 2014 11:36:44 -0400 Subject: Why 2.1 is delayed for so long In-Reply-To: <54218884.7040202@pwned.gg> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> <54205AE2.40905@pwned.gg> <87fvfiua0v.fsf@vigenere.g10code.de> <54214810.50300@pwned.gg> <877g0usdcu.fsf@vigenere.g10code.de> <542174BB.1080005@pwned.gg> <54218434.80202@sixdemonbag.org> <54218884.7040202@pwned.gg> Message-ID: <5421938C.2010603@sixdemonbag.org> > Yes, it would seem you're not learning *enough* from this history. > New laws are being passed that make it legal (hah!) for intelligence > services to hack into computers. I would rather different keys for > different purposes be separated, and my master key moved offline. If > my signature key gets compromised, at least they can only write > emails claiming to be me, not sign fake keys on my behalf. And for you, that makes perfect sense. But that's not the normal use case, mostly because the difficulties that arise from using an offline master key are large enough to make GnuPG an insurmountable obstacle for users. GnuPG already has a learning curve like the Matterhorn. Let's not make it harder or worse, okay? I know, I know. "But my proposal doesn't make it any worse! It only makes it possible for those who want to do this, to do this, without any tweaking of their certificates!" Sure. But to reach that one user in a thousand who wants to store a certification key offline, you're talking about making the system more complicated for the other nine hundred ninety-nine users. I don't think that's a win. I think that's a loss. > In the future, it should be easy to put your master key offline. An excellent observation. (No, I'm not being sarcastic.) So why not work on that problem? If you come up with an easy way for people to do it, then I'm sure Werner will re-evaluate his decision to not support this. > So it is better to > prepare for that situation now, instead of asking everyone to > generate a new key and refresh everyone else's key when the time > comes. It is amazing how many things that "everyone knew" would come to pass never came to pass at all. It is good to be cautious about writing code to support things that "everyone knows" will come to pass. Most of it turns out to be code written in support of vaporware. > Be careful what you wish for. > http://lkml.iu.edu//hypermail/linux/kernel/0210.1/1834.html Not sarcastic, but humorous, yes -- Holy crap, you mean that by telling you 'no' to your idea we could wind up getting something as neat, as cool, and as genuinely useful as Git? Man. Umm. How am I supposed to ... ah, right. NNN NN OOOOO !!! NNNN NN OOO OOO !!! NN NN NN OO OO !!! NN NNNN OOO OOO NN NNN OOOOO ! Implicitly threatening to replace GnuPG with something better? Man, you must be new here. This is the sort of thing that leads me to dance around hollering, "Bring it, O Lord! Let Thy Kingdom come!" GnuPG does a pretty good job in a pretty hard area, but like any software project it has a finite lifespan. Someday it will be unmaintained. All we can hope for is that what comes after GnuPG learns from GnuPG's experiences, that the code is free and respects people's rights to learn and understand and share, and that it is more useful and better for people than GnuPG was. If you can deliver on that promise I'm pretty sure you'll have a long line of people waiting to buy you a beer, and I'll be at the front with the Dortmunder. :) From infinity0 at pwned.gg Tue Sep 23 17:50:38 2014 From: infinity0 at pwned.gg (Ximin Luo) Date: Tue, 23 Sep 2014 16:50:38 +0100 Subject: Why 2.1 is delayed for so long In-Reply-To: <5421938C.2010603@sixdemonbag.org> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> <54205AE2.40905@pwned.gg> <87fvfiua0v.fsf@vigenere.g10code.de> <54214810.50300@pwned.gg> <877g0usdcu.fsf@vigenere.g10code.de> <542174BB.1080005@pwned.gg> <54218434.80202@sixdemonbag.org> <54218884.7040202@pwned.gg> <5421938C.2010603@sixdemonbag.org> Message-ID: <542196CE.7000500@pwned.gg> On 23/09/14 16:36, Robert J. Hansen wrote: >> Yes, it would seem you're not learning *enough* from this history. >> New laws are being passed that make it legal (hah!) for intelligence >> services to hack into computers. I would rather different keys for >> different purposes be separated, and my master key moved offline. If >> my signature key gets compromised, at least they can only write >> emails claiming to be me, not sign fake keys on my behalf. > > And for you, that makes perfect sense. But that's not the normal use > case, mostly because the difficulties that arise from using an offline > master key are large enough to make GnuPG an insurmountable obstacle for > users. > > GnuPG already has a learning curve like the Matterhorn. Let's not make > it harder or worse, okay? > > I know, I know. "But my proposal doesn't make it any worse! It only > makes it possible for those who want to do this, to do this, without any > tweaking of their certificates!" Sure. But to reach that one user in a > thousand who wants to store a certification key offline, you're talking > about making the system more complicated for the other nine hundred > ninety-nine users. I don't think that's a win. I think that's a loss. > How is this "more complicated"? And how is this different from the single-key to double-key switch? Most people will never get RIPA notices, either. Why not make the default master key C+S+A instead of C+S, then? >> In the future, it should be easy to put your master key offline. > > An excellent observation. (No, I'm not being sarcastic.) So why not > work on that problem? If you come up with an easy way for people to do > it, then I'm sure Werner will re-evaluate his decision to not support this. > I *have* been working on that problem. It involves making caff much easier to use in the offline case. >> So it is better to >> prepare for that situation now, instead of asking everyone to >> generate a new key and refresh everyone else's key when the time >> comes. > > It is amazing how many things that "everyone knew" would come to pass > never came to pass at all. It is good to be cautious about writing code > to support things that "everyone knows" will come to pass. Most of it > turns out to be code written in support of vaporware. > Well, then don't give me history lessons. Hindsight is useless, unless you use it to guide your future decisions. >> Be careful what you wish for. >> http://lkml.iu.edu//hypermail/linux/kernel/0210.1/1834.html > > Not sarcastic, but humorous, yes -- > > Holy crap, you mean that by telling you 'no' to your idea we could wind > up getting something as neat, as cool, and as genuinely useful as Git? > Man. Umm. How am I supposed to ... ah, right. > > > NNN NN OOOOO !!! > NNNN NN OOO OOO !!! > NN NN NN OO OO !!! > NN NNNN OOO OOO > NN NNN OOOOO ! > > > Implicitly threatening to replace GnuPG with something better? Man, you > must be new here. This is the sort of thing that leads me to dance > around hollering, "Bring it, O Lord! Let Thy Kingdom come!" > > GnuPG does a pretty good job in a pretty hard area, but like any > software project it has a finite lifespan. Someday it will be > unmaintained. All we can hope for is that what comes after GnuPG learns > from GnuPG's experiences, that the code is free and respects people's > rights to learn and understand and share, and that it is more useful and > better for people than GnuPG was. If you can deliver on that promise > I'm pretty sure you'll have a long line of people waiting to buy you a > beer, and I'll be at the front with the Dortmunder. :) > If that does come to pass, I would still consider it a loss for society, because it would have been easier to just tweak GPG, and I could have spent that effort on other things. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Tue Sep 23 17:57:37 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 23 Sep 2014 17:57:37 +0200 Subject: Why 2.1 is delayed for so long In-Reply-To: <87fvfiua0v.fsf@vigenere.g10code.de> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> <54205AE2.40905@pwned.gg> <87fvfiua0v.fsf@vigenere.g10code.de> Message-ID: <54219871.5030305@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 09/23/2014 08:27 AM, Werner Koch wrote: > On Mon, 22 Sep 2014 19:22, infinity0 at pwned.gg said: > ... > > I disagree. Two subkeys are the exception and are only used by a > minority of people who want to put extra work into setting up their > WoT. We may ask the keyserver admins whether they can figure out > the percentage of keys which have a separate signing key. > The last time I ran an analysis[0] the number of subkeys was 3,283,781 for 3,526,879 primary keys. These numbers surprised me somewhat as it only account for 93.11 of pairs having a subkey at all on average. Upon looking a bit more into this a fair amount of certificate only and uses such as package signature keys were detected. For instance, analysing primary keys with only one subkey, and subsequently looking into the key usage flags I came up with the following table: +----------+----------+ | flag | COUNT(1) | +----------+----------+ | c | 12 | | ca | 125 | | caCA | 1047 | | cC | 37 | | ec | 38 | | eca | 2 | | ecaECA | 10 | | ecEC | 122 | | esc | 4922 | | esca | 5765 | | escaESCA | 24939 | | escESC | 48296 | | sc | 4713 | | sca | 1128 | | scaSCA | 2815 | | scESCA | 1 | | scSC | 20967 | +----------+----------+ 17 rows in set (0.05 sec) I have not yet had time to look deeper into the data, though. [0] http://blog.sumptuouscapital.com/2014/01/openpgp-key-statistics/ : although the subkey data was subsequent data based on same dump and not reported in that article. - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- "If the facts don't fit the theory, change the facts" (Albert Einstein) -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUIZhpAAoJEPw7F94F4TaghYkP/3w0YVv7RKJyWPqbrSScG6OO ECryLjx2inHNx/vT/c21eee+BqG6RpG2nbwDOlhqg4VqvuvMt6w5NC7t8W80pakI 0WH8k5wq5CNXc1jV0J6i07ImhxuHxUXiJETbYNNMWuRaKgWg4WHOk7rfcaT+IpBi EYm13/96dMy+ICqwj1X0o+1yvwxq9lLJXOEBIs4+CFzL+hfuvrZ7TdK0T8nmntmM B/zslow8NrKZCD90mVac0pBNs5wN6o3IqhQE2LqMUAcLdFSWuaJPAqospX+X6AY7 ncAYMDOA06w3WmoNEsSlPY159bjljN1N7JJOUAezI+itr3VyUya0tUMLZmpVkb8N SbpPmCp/J7klldcC4nbIm0K8y7k0eiczSPGWaZ5BoqWOQ4ouKB4NsFtcgoHNcQcd 0Ok5lmCMPmmcBQ2M5lS8F/DUsJDYcxLz3RDftJsO0uscnlfYOL1b1oY7fG7F9PCw 8bHuN9xwomG9rio5tfhZDnHOwPO6cZK28ejp8sDOZWgvnkv0EG2vMsWPDzIlA3pE +InPQTuwYcQesoETOdzAtfeajyrzKUuZCxmZ/z/o8Yiu8CuP0UaXz15i0WHDP1bb 7ipjnCz7/K56imAsRUg8wg3hEWATJfz9RirusVQCGKZP5tsdW90t6nJ6+dW9pYXL g32+LBXPr1T0S0bQ+9PR =iYTU -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Tue Sep 23 18:10:35 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 23 Sep 2014 12:10:35 -0400 Subject: Why 2.1 is delayed for so long In-Reply-To: <542196CE.7000500@pwned.gg> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> <54205AE2.40905@pwned.gg> <87fvfiua0v.fsf@vigenere.g10code.de> <54214810.50300@pwned.gg> <877g0usdcu.fsf@vigenere.g10code.de> <542174BB.1080005@pwned.gg> <54218434.80202@sixdemonbag.org> <54218884.7040202@pwned.gg> <5421938C.2010603@sixdemonbag.org> <542196CE.7000500@pwned.gg> Message-ID: <54219B7B.50006@sixdemonbag.org> > How is this "more complicated"? And how is this different from the > single-key to double-key switch? Most people will never get RIPA > notices, either. Sorry, I omitted one other (huge!) reason from my history -- IIRC, this is what pushed the community over the top: namely, the RSA patent. RSA was the only algorithm that "do it all" (signing, certifying, authenticating, encrypting), but it was patented and thus unavailable. DSA, Elgamal-Signing and Elgamal-Encryption were the only Free Software alternatives. In order to avoid being tied to the patent, the keys had to be separated. The single-key to double-key switch had several independent lines of argument which all went to the same spot. If you signed on to it because of RIPA, great. If you signed on because of patent issues, great. If you signed onto it because... great. There were an abundance of reasons to switch, some of them in response to very present issues (the RSA patent), some of them in response to anticipated issues (RIPA, which as far as I know has never actually been used against an OpenPGP key). That abundance made it easy for people to get behind the change. You don't have that abundance. And you also want this change to happen *right now*, instead of realizing that changes like this take a couple of years to percolate through. > I *have* been working on that problem. It involves making caff much > easier to use in the offline case. Excellent! I'm glad to hear it. > If that does come to pass, I would still consider it a loss for > society, because it would have been easier to just tweak GPG, and I > could have spent that effort on other things. No one's stopping you from tweaking GnuPG. No one's stopping you from sharing your tweaks with the world. -------------- 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 23 18:46:00 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 23 Sep 2014 12:46:00 -0400 Subject: [PATCH] clean up gpgme's tests/gpg when gpg2.1 is available Message-ID: <1411490760-2427-1-git-send-email-dkg@fifthhorseman.net> * tests/gpg/Makefile.am: clean up .gpg-v21-migrated * tests/gpg/.gitignore: ignore .gpg-v21-migrated --- tests/gpg/.gitignore | 1 + tests/gpg/Makefile.am | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/tests/gpg/.gitignore b/tests/gpg/.gitignore index e60bfe5..d79ace7 100644 --- a/tests/gpg/.gitignore +++ b/tests/gpg/.gitignore @@ -1,4 +1,5 @@ .deps +.gpg-v21-migrated .libs gpg-agent.conf gpg.conf diff --git a/tests/gpg/Makefile.am b/tests/gpg/Makefile.am index e72bd49..b428cf2 100644 --- a/tests/gpg/Makefile.am +++ b/tests/gpg/Makefile.am @@ -43,7 +43,7 @@ TESTS = initial.test $(c_tests) final.test CLEANFILES = secring.gpg pubring.gpg pubring.kbx trustdb.gpg dirmngr.conf \ gpg-agent.conf pubring.kbx~ S.gpg-agent gpg.conf pubring.gpg~ \ - random_seed S.gpg-agent + random_seed S.gpg-agent .gpg-v21-migrated private_keys = \ 13CD0F3BDF24BE53FE192D62F18737256FF6E4FD \ -- 2.1.0 From dkg at fifthhorseman.net Tue Sep 23 19:02:56 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 23 Sep 2014 13:02:56 -0400 Subject: DCO for Daniel Kahn Gillmor Message-ID: <87oau6w9q7.fsf@alice.fifthhorseman.net> GnuPG Developer's Certificate of Origin. Version 1.0 ===================================================== By making a contribution to the GnuPG project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the free software license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate free software license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same free software license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the free software license(s) involved. Signed-off-by: Daniel Kahn Gillmor -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From wk at gnupg.org Tue Sep 23 20:33:48 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 23 Sep 2014 20:33:48 +0200 Subject: Why 2.1 is delayed for so long In-Reply-To: <5421938C.2010603@sixdemonbag.org> (Robert J. Hansen's message of "Tue, 23 Sep 2014 11:36:44 -0400") References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> <54205AE2.40905@pwned.gg> <87fvfiua0v.fsf@vigenere.g10code.de> <54214810.50300@pwned.gg> <877g0usdcu.fsf@vigenere.g10code.de> <542174BB.1080005@pwned.gg> <54218434.80202@sixdemonbag.org> <54218884.7040202@pwned.gg> <5421938C.2010603@sixdemonbag.org> Message-ID: <8738biqj8z.fsf@vigenere.g10code.de> On Tue, 23 Sep 2014 17:36, rjh at sixdemonbag.org said: >> In the future, it should be easy to put your master key offline. > > An excellent observation. (No, I'm not being sarcastic.) So why not > work on that problem? If you come up with an easy way for people to do > it, then I'm sure Werner will re-evaluate his decision to not support this. I will definitely do that as soon as a cheap device is available which can be used to hold and somehow backup the offline key. Using an > 15 year old laptop for this task like me, can't be suggested to average users. I doubt that it is currently possible to design, produce, and sell such a device. It is just not sexy enough for a crowdfunding campaign ("just for storing some part of the key - why can't I use my smartphone for it"?). Such a device needs to be dedicated and resistant to remote exploits (USB stack, side channels) and may not have any extra gadgets. It needs a little screen and a small keyboard, though. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rjh at sixdemonbag.org Tue Sep 23 21:06:24 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 23 Sep 2014 15:06:24 -0400 Subject: Why 2.1 is delayed for so long In-Reply-To: <8738biqj8z.fsf@vigenere.g10code.de> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> <54205AE2.40905@pwned.gg> <87fvfiua0v.fsf@vigenere.g10code.de> <54214810.50300@pwned.gg> <877g0usdcu.fsf@vigenere.g10code.de> <542174BB.1080005@pwned.gg> <54218434.80202@sixdemonbag.org> <54218884.7040202@pwned.gg> <5421938C.2010603@sixdemonbag.org> <8738biqj8z.fsf@vigenere.g10code.de> Message-ID: <5421C4B0.7060709@sixdemonbag.org> > I will definitely do that as soon as... I never said it would be easy for Ximin to solve that problem. I just encouraged him to try solving it. :) From pete at petertodd.org Tue Sep 23 22:35:40 2014 From: pete at petertodd.org (Peter Todd) Date: Tue, 23 Sep 2014 16:35:40 -0400 Subject: Why 2.1 is delayed for so long In-Reply-To: <8738biqj8z.fsf@vigenere.g10code.de> References: <87oau7txio.fsf@vigenere.g10code.de> <54205AE2.40905@pwned.gg> <87fvfiua0v.fsf@vigenere.g10code.de> <54214810.50300@pwned.gg> <877g0usdcu.fsf@vigenere.g10code.de> <542174BB.1080005@pwned.gg> <54218434.80202@sixdemonbag.org> <54218884.7040202@pwned.gg> <5421938C.2010603@sixdemonbag.org> <8738biqj8z.fsf@vigenere.g10code.de> Message-ID: <20140923203540.GA8332@muck> On Tue, Sep 23, 2014 at 08:33:48PM +0200, Werner Koch wrote: > On Tue, 23 Sep 2014 17:36, rjh at sixdemonbag.org said: > > >> In the future, it should be easy to put your master key offline. > > > > An excellent observation. (No, I'm not being sarcastic.) So why not > > work on that problem? If you come up with an easy way for people to do > > it, then I'm sure Werner will re-evaluate his decision to not support this. > > I will definitely do that as soon as a cheap device is available which > can be used to hold and somehow backup the offline key. Using an > 15 > year old laptop for this task like me, can't be suggested to average > users. > > I doubt that it is currently possible to design, produce, and sell such > a device. It is just not sexy enough for a crowdfunding campaign ("just > for storing some part of the key - why can't I use my smartphone for > it"?). Such a device needs to be dedicated and resistant to remote > exploits (USB stack, side channels) and may not have any extra gadgets. > It needs a little screen and a small keyboard, though. I suspect re-using hardware developed for keeping Bitcoins secure would be a good approach, e.g. the Trezor: http://www.bitcointrezor.com/ That also gives ample incentive for attackers to find those remote exploits... -- 'peter'[:-1]@petertodd.org 000000000000000012367d385ad11358a4a1eee86cf8ebe06a76add36dfb4622 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 650 bytes Desc: Digital signature URL: From dkg at fifthhorseman.net Tue Sep 23 23:51:06 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 23 Sep 2014 17:51:06 -0400 Subject: offline primary keys [was: Re: Why 2.1 is delayed for so long] In-Reply-To: <8738biqj8z.fsf@vigenere.g10code.de> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> <54205AE2.40905@pwned.gg> <87fvfiua0v.fsf@vigenere.g10code.de> <54214810.50300@pwned.gg> <877g0usdcu.fsf@vigenere.g10code.de> <542174BB.1080005@pwned.gg> <54218434.80202@sixdemonbag.org> <54218884.7040202@pwned.gg> <5421938C.2010603@sixdemonbag.org> <8738biqj8z.fsf@vigenere.g10code.de> Message-ID: <5421EB4A.2010906@fifthhorseman.net> On 09/23/2014 02:33 PM, Werner Koch wrote: > I will definitely do that as soon as a cheap device is available which > can be used to hold and somehow backup the offline key. Using an > 15 > year old laptop for this task like me, can't be suggested to average > users. i don't know how cheap a "cheap device" needs to be, but having a functional and easy software path to use it would certainly increase the likelihood of uptake. There is a bit of a chicken and egg problem here. > I doubt that it is currently possible to design, produce, and sell such > a device. It is just not sexy enough for a crowdfunding campaign ("just > for storing some part of the key - why can't I use my smartphone for > it"?). Such a device needs to be dedicated and resistant to remote > exploits (USB stack, side channels) and may not have any extra gadgets. > It needs a little screen and a small keyboard, though. fwiw, there is security to be gained just from moving the master key to a USB stick without any screen or keyboard -- just having the key be inaccessible when the USB stick is unplugged defends against one whole class of attack (though obviously there are others that it does not defend against). Using this with a dedicated user account that doesn't have access to a graphical session is a plausible step toward limiting a range of other attacks. Stepping up from there, using a GnuK or a Neo OpenPGP device without any physical UI makes the key itself inaccessible even when online, and reduces attackers to just making requests but not stealing the key itself. an upgraded GnuK or Neo with a single LED lamp (for "i have been asked to make a signature") and a single button (for "ok, make the signature") is still more of an improvement. Anyway, all of this is to say that "offline primary key" is more of a spectrum than a boolean concept, and that software improvements in making it easier to move to offline primary keys are all worth making even if the absolute ideal piece of kit doesn't exist yet. ------- As for Ximin's goals: I think the transition process could look like this: 0) add a signing-capable subkey 1) remove signing-capability from primary key 2) move primary key offline this raises some protocol questions and some usability questions. step 0 is relatively easy to do right now. step 1 i know how to do, but only with hoop-jumping and custom code --not for the faint of heart. i also don't know what would happen to old messages that i had signed with the primary key. are they no longer correctly-signed? I guess i should experiment with this. step 2 i know how to do with hoop-jumping and maybe less custom code than step 1, but i think it's still not for the faint of heart. I think it involves --export-secret-keys, then --export-secret-subkeys, then --delete-secret-key, then --import, then move the full keys, etc. If this is a workflow we want to support for real humans, it needs some serious usability attention (maybe the answer is "that happens outside gnupg", and that's fine, as long as gnupg can be used to do that). If the default certificate was changed to Ximin's proposed C+S+A key (which does address real needs), that would resolve steps 0 and 1. We still have to grapple with step 2 no matter what (unless i'm just ignorant of an already-existing easy process for step 2 -- please tell me!). Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Wed Sep 24 00:23:43 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 23 Sep 2014 18:23:43 -0400 Subject: [PATCH v2] Allow ./configure to explicitly set libgpg-error's build timestamp In-Reply-To: <87r3z2quay.fsf@vigenere.g10code.de> References: <87r3z2quay.fsf@vigenere.g10code.de> Message-ID: <1411511023-29327-1-git-send-email-dkg@fifthhorseman.net> * configure.ac: add --enable-build-timestamp -- A group within Debian is working on making the archive rebuildable in a reproducible way, so that the compiled binary outputs are byte-for-byte identical when built for the same platform using the same toolchain. This is useful in providing auditability and corroboration for users of the operating system. libgpg-error is very close to reproducible except for embedding the build timestamp in the generated binary. This timestamp is set in config.h during ./configure. This patch allows an external build system to set this embedded timestamp explicitly, which appears to make the package build repeatably when ./configure is called with (for example) --enable=build-timestamp=2014-09-23T01:02+0000 Debian-bug-id: 762397 --- configure.ac | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index b32b751..b72856f 100644 --- a/configure.ac +++ b/configure.ac @@ -484,7 +484,13 @@ changequote([,])dnl BUILD_FILEVERSION="${BUILD_FILEVERSION}0,mym4_revision_dec" AC_SUBST(BUILD_FILEVERSION) -BUILD_TIMESTAMP=`date -u +%Y-%m-%dT%H:%M+0000 2>/dev/null || date` + +AC_ARG_ENABLE([build-timestamp], + AC_HELP_STRING([--enable-build-timestamp], + [set an explicit build timestamp for reproducibility. + (default is the current time in ISO-8601 format)]), + [if $enableval = "no"; then BUILD_TIMESTAMP="[none]"; else BUILD_TIMESTAMP=$enableval; fi], + [BUILD_TIMESTAMP=`date -u +%Y-%m-%dT%H:%M+0000 2>/dev/null || date`] ) AC_SUBST(BUILD_TIMESTAMP) AC_DEFINE_UNQUOTED(BUILD_TIMESTAMP, "$BUILD_TIMESTAMP", [The time this package was configured for a build]) -- 2.1.0 From dkg at fifthhorseman.net Wed Sep 24 00:34:32 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 23 Sep 2014 18:34:32 -0400 Subject: [PATCH v3] Allow ./configure to explicitly set libgpg-error's build timestamp In-Reply-To: <1411511023-29327-1-git-send-email-dkg@fifthhorseman.net> References: <1411511023-29327-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <1411511672-22791-1-git-send-email-dkg@fifthhorseman.net> * configure.ac: add --enable-build-timestamp -- A group within Debian is working on making the archive rebuildable in a reproducible way, so that the compiled binary outputs are byte-for-byte identical when built for the same platform using the same toolchain. This is useful in providing auditability and corroboration for users of the operating system. libgpg-error is very close to reproducible except for embedding the build timestamp in the generated binary. This timestamp is set in config.h during ./configure. This patch allows an external build system to set this embedded timestamp explicitly, which appears to make the package build repeatably when ./configure is called with (for example) --enable=build-timestamp=2014-09-23T01:02+0000 Debian-bug-id: 762397 --- configure.ac | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index b32b751..c0435b0 100644 --- a/configure.ac +++ b/configure.ac @@ -484,7 +484,13 @@ changequote([,])dnl BUILD_FILEVERSION="${BUILD_FILEVERSION}0,mym4_revision_dec" AC_SUBST(BUILD_FILEVERSION) -BUILD_TIMESTAMP=`date -u +%Y-%m-%dT%H:%M+0000 2>/dev/null || date` + +AC_ARG_ENABLE([build-timestamp], + AC_HELP_STRING([--enable-build-timestamp], + [set an explicit build timestamp for reproducibility. + (default is the current time in ISO-8601 format)]), + [if test "$enableval" = "no"; then BUILD_TIMESTAMP=""; else BUILD_TIMESTAMP="$enableval"; fi], + [BUILD_TIMESTAMP=`date -u +%Y-%m-%dT%H:%M+0000 2>/dev/null || date`] ) AC_SUBST(BUILD_TIMESTAMP) AC_DEFINE_UNQUOTED(BUILD_TIMESTAMP, "$BUILD_TIMESTAMP", [The time this package was configured for a build]) -- 2.1.0 From dkg at fifthhorseman.net Wed Sep 24 00:38:50 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 23 Sep 2014 18:38:50 -0400 Subject: [PATCH v3] Allow ./configure to explicitly set libgpg-error's build timestamp In-Reply-To: <1411511672-22791-1-git-send-email-dkg@fifthhorseman.net> References: <1411511023-29327-1-git-send-email-dkg@fifthhorseman.net> <1411511672-22791-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <5421F67A.5090504@fifthhorseman.net> On 09/23/2014 06:34 PM, Daniel Kahn Gillmor wrote: > * configure.ac: add --enable-build-timestamp apologies for the multiple versions here. Please disregard v2. The v3 patch (as seen below) is the right one to use, as it handles --disable-build-timestamp appropriately. I find that trying to get it to pass "[none]" through all the autotools business ends up turning into "none", so i went with "" instead, which shouldn't be mistaken for an ISO-8601 date format. --dkg > configure.ac | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/configure.ac b/configure.ac > index b32b751..c0435b0 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -484,7 +484,13 @@ changequote([,])dnl > BUILD_FILEVERSION="${BUILD_FILEVERSION}0,mym4_revision_dec" > AC_SUBST(BUILD_FILEVERSION) > > -BUILD_TIMESTAMP=`date -u +%Y-%m-%dT%H:%M+0000 2>/dev/null || date` > + > +AC_ARG_ENABLE([build-timestamp], > + AC_HELP_STRING([--enable-build-timestamp], > + [set an explicit build timestamp for reproducibility. > + (default is the current time in ISO-8601 format)]), > + [if test "$enableval" = "no"; then BUILD_TIMESTAMP=""; else BUILD_TIMESTAMP="$enableval"; fi], > + [BUILD_TIMESTAMP=`date -u +%Y-%m-%dT%H:%M+0000 2>/dev/null || date`] ) > AC_SUBST(BUILD_TIMESTAMP) > AC_DEFINE_UNQUOTED(BUILD_TIMESTAMP, "$BUILD_TIMESTAMP", > [The time this package was configured for a build]) > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From infinity0 at pwned.gg Wed Sep 24 03:03:57 2014 From: infinity0 at pwned.gg (Ximin Luo) Date: Wed, 24 Sep 2014 02:03:57 +0100 Subject: offline primary keys [was: Re: Why 2.1 is delayed for so long] In-Reply-To: <5421EB4A.2010906@fifthhorseman.net> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> <54205AE2.40905@pwned.gg> <87fvfiua0v.fsf@vigenere.g10code.de> <54214810.50300@pwned.gg> <877g0usdcu.fsf@vigenere.g10code.de> <542174BB.1080005@pwned.gg> <54218434.80202@sixdemonbag.org> <54218884.7040202@pwned.gg> <5421938C.2010603@sixdemonbag.org> <8738biqj8z.fsf@vigenere.g10code.de> <5421EB4A.2010906@fifthhorseman.net> Message-ID: <5422187D.1060906@pwned.gg> On 23/09/14 22:51, Daniel Kahn Gillmor wrote: > fwiw, there is security to be gained just from moving the master key to > a USB stick without any screen or keyboard -- just having the key be > inaccessible when the USB stick is unplugged defends against one whole > class of attack (though obviously there are others that it does not > defend against). Using this with a dedicated user account that doesn't > have access to a graphical session is a plausible step toward limiting a > range of other attacks. > One step better, that is cheaper but less secure than getting a new computer (or the things you mention below), is to put the master key on an encrypted USB device that is only unlocked from a readonly non-networked live OS. Of course this doesn't stop firmware/BIOS malware, but those are more costly to develop and deploy. > Stepping up from there, using a GnuK or a Neo OpenPGP device without any > physical UI makes the key itself inaccessible even when online, and > reduces attackers to just making requests but not stealing the key itself. > > an upgraded GnuK or Neo with a single LED lamp (for "i have been asked > to make a signature") and a single button (for "ok, make the signature") > is still more of an improvement. > > Anyway, all of this is to say that "offline primary key" is more of a > spectrum than a boolean concept, and that software improvements in > making it easier to move to offline primary keys are all worth making > even if the absolute ideal piece of kit doesn't exist yet. > Right. Hardware support would be ideal in the future, but it doesn't mean we should ignore efforts in complementary areas. > ------- > > > As for Ximin's goals: I think the transition process could look like this: > > 0) add a signing-capable subkey > 1) remove signing-capability from primary key > 2) move primary key offline > > this raises some protocol questions and some usability questions. > > step 0 is relatively easy to do right now. > > step 1 i know how to do, but only with hoop-jumping and custom code > --not for the faint of heart. i also don't know what would happen to > old messages that i had signed with the primary key. are they no longer > correctly-signed? I guess i should experiment with this. > > step 2 i know how to do with hoop-jumping and maybe less custom code > than step 1, but i think it's still not for the faint of heart. I think > it involves --export-secret-keys, then --export-secret-subkeys, then > --delete-secret-key, then --import, then move the full keys, etc. If > this is a workflow we want to support for real humans, it needs some > serious usability attention (maybe the answer is "that happens outside > gnupg", and that's fine, as long as gnupg can be used to do that). > Step 0 and 2 can be scripted easily. Step 1 can in theory by script, but it's optional and has the long-lasting caveat you mentioned; I think it would be easier to just generate a new master key, hence my suggestion. > If the default certificate was changed to Ximin's proposed C+S+A key > (which does address real needs), that would resolve steps 0 and 1. We > still have to grapple with step 2 no matter what (unless i'm just > ignorant of an already-existing easy process for step 2 -- please tell me!). > I was not proposing a CSA master key, I think that is a horrible idea. :p Rather, I was pointing out that, arguments in favour of supporting a CS master key can be extended to support a CSA master key, so the fact we don't do the latter means these arguments are not great arguments. (Although it looks like something else, possibly GPGTools for Mac, generates these by default.) Of course you can still move your master key offline if it is CS or CSA, you just have some extra steps to do, your key looks confusing to people, naive software might get confused, and the data scheme is unnecessarily complex. IMO the fact that multiple uses for a key is even allowed is a design flaw in OpenPGP, but especially the fact a key can be used for C and something else. C is for identity management, the others are for 3rd-party applications; so the keys should be separated appropriately. Even without the history of legal bullshit, from a clean-engineering point of view, separate C/S/A keys would be the best design, as well as separate name/email UIDs. But maybe this is just hindsight bias. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Wed Sep 24 04:14:36 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 23 Sep 2014 22:14:36 -0400 Subject: offline primary keys [was: Re: Why 2.1 is delayed for so long] In-Reply-To: <5422187D.1060906@pwned.gg> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> <54205AE2.40905@pwned.gg> <87fvfiua0v.fsf@vigenere.g10code.de> <54214810.50300@pwned.gg> <877g0usdcu.fsf@vigenere.g10code.de> <542174BB.1080005@pwned.gg> <54218434.80202@sixdemonbag.org> <54218884.7040202@pwned.gg> <5421938C.2010603@sixdemonbag.org> <8738biqj8z.fsf@vigenere.g10code.de> <5421EB4A.2010906@fifthhorseman.net> <5422187D.1060906@pwned.gg> Message-ID: <5422290C.40308@fifthhorseman.net> On 09/23/2014 09:03 PM, Ximin Luo wrote: > I was not proposing a CSA master key, I think that is a horrible idea. ftr, when i said C+S+A key, i meant a Certification-capable master key + a Signing-capable subkey + an Encryption-capable subkey. I don't know why i wrote A instead of E, sorry for the confusion. I did not mean to suggest that all those capabilities should be on the primary key. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Wed Sep 24 05:29:34 2014 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 23 Sep 2014 23:29:34 -0400 Subject: Why 2.1 is delayed for so long In-Reply-To: <87oau7txio.fsf@vigenere.g10code.de> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> Message-ID: <00BCD22E-5522-45F6-8C2E-B00C3707B3BF@jabberwocky.com> On Sep 22, 2014, at 12:45 PM, Werner Koch wrote: > On Mon, 22 Sep 2014 17:14, dshaw at jabberwocky.com said: > >> I basically agree with this. > > Me too. > >> Of course, --expert would have everything and give all options, >> including setting key flags, as today. But without --expert, just >> make an RSA (sign+certify) + RSA (encrypt) key, as is the default >> today. > > I wonder whether a sign only key (and then being able to select between > DSA or RSA) makes sense in non-expert mode. What do you think? Hmm. I think it would be best to generate an encryption subkey as well. I strongly suspect most people generating a key would need one, and doing it with one invocation of --gen-key is better than telling them to use --gen-key, then --edit-key to add an encryption subkey. > Shall we add a line "For more options run gpg with --expert"? I think that's a good idea, but giving this whole thing a bit of thought, perhaps not "--expert". That is, make up some new option to show the full key generation list. (or even a different command: "--gen-key" vs "--gen-key-full" perhaps?) The reason why I'm reluctant to use --expert is that it has a pretty defined meaning as the option that allows you to do dangerous / nonstandard / incompatible things. Those things are useful to do, at times, but generating different key types doesn't really fall into any of those buckets. I don't want --expert to be the standard way to do something "normal". So, absolutely in favor of the concept of concealing the non-default options behind some new option, and by all means tell the user about this new option when generating keys, but I'd like to use something other than "--expert" as that new option. David From dshaw at jabberwocky.com Wed Sep 24 07:16:33 2014 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 24 Sep 2014 01:16:33 -0400 Subject: offline primary keys [was: Re: Why 2.1 is delayed for so long] In-Reply-To: <5421EB4A.2010906@fifthhorseman.net> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> <54205AE2.40905@pwned.gg> <87fvfiua0v.fsf@vigenere.g10code.de> <54214810.50300@pwned.gg> <877g0usdcu.fsf@vigenere.g10code.de> <542174BB.1080005@pwned.gg> <54218434.80202@sixdemonbag.org> <54218884.7040202@pwned.gg> <5421938C.2010603@sixdemonbag.org> <8738biqj8z.fsf@vigenere.g10code.de> <5421EB4A.2010906@fifthhorseman.net> Message-ID: <553BA043-F9B6-447B-B71C-F1BFDD753324@jabberwocky.com> On Sep 23, 2014, at 5:51 PM, Daniel Kahn Gillmor wrote: > As for Ximin's goals: I think the transition process could look like this: > > 0) add a signing-capable subkey > 1) remove signing-capability from primary key > 2) move primary key offline I understand the desire for steps 0 and 2, but I do not see the need for step 1. You can do 0 and 2 without doing 1. Can you explain why you want 1? I see actual problems for a primary key that can't issue signatures as well as certifications. David From wk at gnupg.org Wed Sep 24 09:20:14 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 24 Sep 2014 09:20:14 +0200 Subject: offline primary keys In-Reply-To: <5421EB4A.2010906@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 23 Sep 2014 17:51:06 -0400") References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> <54205AE2.40905@pwned.gg> <87fvfiua0v.fsf@vigenere.g10code.de> <54214810.50300@pwned.gg> <877g0usdcu.fsf@vigenere.g10code.de> <542174BB.1080005@pwned.gg> <54218434.80202@sixdemonbag.org> <54218884.7040202@pwned.gg> <5421938C.2010603@sixdemonbag.org> <8738biqj8z.fsf@vigenere.g10code.de> <5421EB4A.2010906@fifthhorseman.net> Message-ID: <874mvxpjrl.fsf@vigenere.g10code.de> On Tue, 23 Sep 2014 23:51, dkg at fifthhorseman.net said: > functional and easy software path to use it would certainly increase the > likelihood of uptake. There is a bit of a chicken and egg problem here. Changing this in GnuPG is really easy as would a change to 8k RSA keys be. But I do not think that this is a good idea. And frankly we have other areas which needs more love that some (now) geeky features. There are already way too many features and I should have spend that time for usability things. > fwiw, there is security to be gained just from moving the master key to > a USB stick without any screen or keyboard -- just having the key be > inaccessible when the USB stick is unplugged defends against one whole You assume that the machine is clean and not compromised. Well, then you can just keep the key on the disk. After all it is passphrase protected and thus not useful unless the machine is compromised. > Stepping up from there, using a GnuK or a Neo OpenPGP device without any > physical UI makes the key itself inaccessible even when online, and > reduces attackers to just making requests but not stealing the key itself. I fully agree and UX improvements should take this in account. For example if a card reader is detected a GUI based key generation dialog may ask whether the key shall be put on a card. That is making support for those tokens more visible. > an upgraded GnuK or Neo with a single LED lamp (for "i have been asked > to make a signature") and a single button (for "ok, make the signature") > is still more of an improvement. Good suggestion. > As for Ximin's goals: I think the transition process could look like this: > > 0) add a signing-capable subkey > 1) remove signing-capability from primary key > 2) move primary key offline IMHO this is worthless. If this would go mainstream, malware will adjust for this scenario immediately. You need to create the high-value primary key on a dedicated offline device. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Sep 24 09:31:37 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 24 Sep 2014 09:31:37 +0200 Subject: Why 2.1 is delayed for so long In-Reply-To: <00BCD22E-5522-45F6-8C2E-B00C3707B3BF@jabberwocky.com> (David Shaw's message of "Tue, 23 Sep 2014 23:29:34 -0400") References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> <00BCD22E-5522-45F6-8C2E-B00C3707B3BF@jabberwocky.com> Message-ID: <87zjdpo4o6.fsf@vigenere.g10code.de> On Wed, 24 Sep 2014 05:29, dshaw at jabberwocky.com said: > I think that's a good idea, but giving this whole thing a bit of > thought, perhaps not "--expert". That is, make up some new option to I also have concerns using --exper for this. > show the full key generation list. (or even a different command: > "--gen-key" vs "--gen-key-full" perhaps?) The reason why I'm Aas of now we have --gen-key --quick-gen-key USERID --quick-gen-key is actually for script use to quickly generate a default key. It does not do any checking on the USERID and thus there is no interactive help on using a de-facto standard user id. --full-gen-key would better match the other command names. One problem with changing the --gen-key is that some scripts and programs may run into problems because they assume a specific order of prompts. But I am willing to risk such a breakage for 2.1 - eventually this software needs to be changed for ECC anyway. > buckets. I don't want --expert to be the standard way to do something > "normal". Agreed. Using --expert would also reveal our new "read-only" algorithms to early. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From infinity0 at pwned.gg Wed Sep 24 12:05:21 2014 From: infinity0 at pwned.gg (Ximin Luo) Date: Wed, 24 Sep 2014 11:05:21 +0100 Subject: offline primary keys In-Reply-To: <874mvxpjrl.fsf@vigenere.g10code.de> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> <54205AE2.40905@pwned.gg> <87fvfiua0v.fsf@vigenere.g10code.de> <54214810.50300@pwned.gg> <877g0usdcu.fsf@vigenere.g10code.de> <542174BB.1080005@pwned.gg> <54218434.80202@sixdemonbag.org> <54218884.7040202@pwned.gg> <5421938C.2010603@sixdemonbag.org> <8738biqj8z.fsf@vigenere.g10code.de> <5421EB4A.2010906@fifthhorseman.net> <874mvxpjrl.fsf@vigenere.g10code.de> Message-ID: <54229761.1060505@pwned.gg> On 24/09/14 08:20, Werner Koch wrote: >> As for Ximin's goals: I think the transition process could look like this: >> >> 0) add a signing-capable subkey >> 1) remove signing-capability from primary key >> 2) move primary key offline > > IMHO this is worthless. If this would go mainstream, malware will > adjust for this scenario immediately. You need to create the high-value > primary key on a dedicated offline device. > No, it's not worthless unless you think all machines are infected all the time. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From infinity0 at pwned.gg Wed Sep 24 12:17:10 2014 From: infinity0 at pwned.gg (Ximin Luo) Date: Wed, 24 Sep 2014 11:17:10 +0100 Subject: offline primary keys [was: Re: Why 2.1 is delayed for so long] In-Reply-To: <553BA043-F9B6-447B-B71C-F1BFDD753324@jabberwocky.com> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> <54205AE2.40905@pwned.gg> <87fvfiua0v.fsf@vigenere.g10code.de> <54214810.50300@pwned.gg> <877g0usdcu.fsf@vigenere.g10code.de> <542174BB.1080005@pwned.gg> <54218434.80202@sixdemonbag.org> <54218884.7040202@pwned.gg> <5421938C.2010603@sixdemonbag.org> <8738biqj8z.fsf@vigenere.g10code.de> <5421EB4A.2010906@fifthhorseman.net> <553BA043-F9B6-447B-B71C-F1BFDD753324@jabberwocky.com> Message-ID: <54229A26.10007@pwned.gg> On 24/09/14 06:16, David Shaw wrote: > On Sep 23, 2014, at 5:51 PM, Daniel Kahn Gillmor wrote: > >> As for Ximin's goals: I think the transition process could look like this: >> >> 0) add a signing-capable subkey >> 1) remove signing-capability from primary key >> 2) move primary key offline > > I understand the desire for steps 0 and 2, but I do not see the need for step 1. You can do 0 and 2 without doing 1. Can you explain why you want 1? > > I see actual problems for a primary key that can't issue signatures as well as certifications. > As I mentioned in the other email, the need for step 1 is long-term and architectural - it's a much cleaner data scheme, and separates independent concerns appropriately. You can update key metadata separately. For example, if you have a CS master key and an S subkey, a signing program might "pick the last key to expire" as logic to select which key to use. But you might want to update the expiry date for your master key, to be longer than your signing key. Different programs might implement different logic. It would be more predictable, to have only one signing key (that is separate). What problems do you see? X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From infinity0 at pwned.gg Wed Sep 24 12:47:26 2014 From: infinity0 at pwned.gg (Ximin Luo) Date: Wed, 24 Sep 2014 11:47:26 +0100 Subject: offline primary keys In-Reply-To: <874mvxpjrl.fsf@vigenere.g10code.de> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> <54205AE2.40905@pwned.gg> <87fvfiua0v.fsf@vigenere.g10code.de> <54214810.50300@pwned.gg> <877g0usdcu.fsf@vigenere.g10code.de> <542174BB.1080005@pwned.gg> <54218434.80202@sixdemonbag.org> <54218884.7040202@pwned.gg> <5421938C.2010603@sixdemonbag.org> <8738biqj8z.fsf@vigenere.g10code.de> <5421EB4A.2010906@fifthhorseman.net> <874mvxpjrl.fsf@vigenere.g10code.de> Message-ID: <5422A13E.9050400@pwned.gg> On 24/09/14 08:20, Werner Koch wrote: >> fwiw, there is security to be gained just from moving the master key to >> a USB stick without any screen or keyboard -- just having the key be >> inaccessible when the USB stick is unplugged defends against one whole > > You assume that the machine is clean and not compromised. Well, then > you can just keep the key on the disk. After all it is passphrase > protected and thus not useful unless the machine is compromised. > > [..] > >> As for Ximin's goals: I think the transition process could look like this: >> >> 0) add a signing-capable subkey >> 1) remove signing-capability from primary key >> 2) move primary key offline > > IMHO this is worthless. If this would go mainstream, malware will > adjust for this scenario immediately. You need to create the high-value > primary key on a dedicated offline device. > To expand on my last email: you are missing time periods from your logic. It's safer to assume "my machine wasn't compromised for the past 2 years" than to assume both this *and* "my machine won't be compromised for the next 10 years". So there is still security value in moving your master key offline ASAP, even if you generated it on an online computer. In terms of a mass transition, of course it's most secure if everyone generated new keys on an airgapped machine. I'm not sure about the uptake on that. The proposed transition is still useful however, since it can be automated so it reduces the user's cost in moving their master key offline. IMO it is quite reasonable to trade the cost of re-establishing your WoT, for the assumption that your machine wasn't compromised in the past few years. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Wed Sep 24 15:06:02 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 24 Sep 2014 09:06:02 -0400 Subject: [PATCH] update gpgme's doc/gpl.texi to match version from gnupg In-Reply-To: <1409979847-31480-1-git-send-email-dkg@fifthhorseman.net> References: <1409979847-31480-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <87bnq5w4lh.fsf@alice.fifthhorseman.net> On Sat 2014-09-06 01:04:07 -0400, Daniel Kahn Gillmor wrote: > Somehow the doc/gpl.texi from gpgme and gnupg drifted out of sync. > This patch to gpgme's file brings it in line with gnupg's master > branch, and avoids the following errors during make: > > ./gpl.texi:667: @section seen before @end enumerate > ./gpl.texi:724: unmatched `@end enumerate' > ./gpl.texi:1: warning: node next `Copying' in menu `Concept Index' and in sectioning `Function and Data Index' differ > --- > doc/gpl.texi | 34 +++++++++++++++++++++------------- > 1 file changed, 21 insertions(+), 13 deletions(-) Any followup on this patch? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From wk at gnupg.org Wed Sep 24 15:00:24 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 24 Sep 2014 15:00:24 +0200 Subject: DCO for Daniel Kahn Gillmor In-Reply-To: <87oau6w9q7.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 23 Sep 2014 13:02:56 -0400") References: <87oau6w9q7.fsf@alice.fifthhorseman.net> Message-ID: <87oau5npg7.fsf@vigenere.g10code.de> On Tue, 23 Sep 2014 19:02, dkg at fifthhorseman.net said: > GnuPG Developer's Certificate of Origin. Version 1.0 > ===================================================== Thanks. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Wed Sep 24 15:07:23 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 24 Sep 2014 09:07:23 -0400 Subject: gpgme DCO for Daniel Kahn Gillmor Message-ID: <878ul9w4j8.fsf@alice.fifthhorseman.net> gpgme Developer's Certificate of Origin. Version 1.0 ===================================================== By making a contribution to the gpgme project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the free software license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate free software license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same free software license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the free software license(s) involved. Signed-off-by: Daniel Kahn Gillmor -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From wk at gnupg.org Wed Sep 24 15:15:14 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 24 Sep 2014 15:15:14 +0200 Subject: [PATCH v3] Allow ./configure to explicitly set libgpg-error's build timestamp In-Reply-To: <5421F67A.5090504@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 23 Sep 2014 18:38:50 -0400") References: <1411511023-29327-1-git-send-email-dkg@fifthhorseman.net> <1411511672-22791-1-git-send-email-dkg@fifthhorseman.net> <5421F67A.5090504@fifthhorseman.net> Message-ID: <87h9zxnorh.fsf@vigenere.g10code.de> On Wed, 24 Sep 2014 00:38, dkg at fifthhorseman.net said: > The v3 patch (as seen below) is the right one to use, as it handles > --disable-build-timestamp appropriately. Nice. Pushed. Will add eventually add it to the other projects. > I find that trying to get it to pass "[none]" through all the autotools > business ends up turning into "none", so i went with "" instead, > which shouldn't be mistaken for an ISO-8601 date format. No problem. You would have to use changequote and such to do that but the actual string is not really important. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Sep 24 15:25:42 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 24 Sep 2014 15:25:42 +0200 Subject: gpgme DCO for Daniel Kahn Gillmor In-Reply-To: <878ul9w4j8.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 24 Sep 2014 09:07:23 -0400") References: <878ul9w4j8.fsf@alice.fifthhorseman.net> Message-ID: <878ul9noa1.fsf@vigenere.g10code.de> On Wed, 24 Sep 2014 15:07, dkg at fifthhorseman.net said: > gpgme Developer's Certificate of Origin. Version 1.0 > ===================================================== Thanks. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Sep 24 15:32:52 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 24 Sep 2014 15:32:52 +0200 Subject: [PATCH] update gpgme's doc/gpl.texi to match version from gnupg In-Reply-To: <87bnq5w4lh.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 24 Sep 2014 09:06:02 -0400") References: <1409979847-31480-1-git-send-email-dkg@fifthhorseman.net> <87bnq5w4lh.fsf@alice.fifthhorseman.net> Message-ID: <874mvxnny3.fsf@vigenere.g10code.de> On Wed, 24 Sep 2014 15:06, dkg at fifthhorseman.net said: > Any followup on this patch? Still ticked in my mail folder. Will thus eventually be processed. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dshaw at jabberwocky.com Wed Sep 24 17:39:33 2014 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 24 Sep 2014 11:39:33 -0400 Subject: offline primary keys [was: Re: Why 2.1 is delayed for so long] In-Reply-To: <54229A26.10007@pwned.gg> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> <54205AE2.40905@pwned.gg> <87fvfiua0v.fsf@vigenere.g10code.de> <54214810.50300@pwned.gg> <877g0usdcu.fsf@vigenere.g10code.de> <542174BB.1080005@pwned.gg> <54218434.80202@sixdemonbag.org> <54218884.7040202@pwned.gg> <5421938C.2010603@sixdemonbag.org> <8738biqj8z.fsf@vigenere.g10code.de> <5421EB4A.2010906@fifthhorseman.net> <553BA043-F9B6-447B-B71C-F1BFDD753324@jabberwocky.com> <54229A26.10007@pwned.gg> Message-ID: <9CBE9754-8159-4733-B4AA-9A3565766C2C@jabberwocky.com> On Sep 24, 2014, at 6:17 AM, Ximin Luo wrote: > On 24/09/14 06:16, David Shaw wrote: >> On Sep 23, 2014, at 5:51 PM, Daniel Kahn Gillmor wrote: >> >>> As for Ximin's goals: I think the transition process could look like this: >>> >>> 0) add a signing-capable subkey >>> 1) remove signing-capability from primary key >>> 2) move primary key offline >> >> I understand the desire for steps 0 and 2, but I do not see the need for step 1. You can do 0 and 2 without doing 1. Can you explain why you want 1? >> >> I see actual problems for a primary key that can't issue signatures as well as certifications. [..] > What problems do you see? When certifying someone's key, you are signing the combination of the primary key and the user ID in question. In addition to the usual checking of IDs and fingerprints, It is reasonable [1] to send a challenge token to the email address (if there is one) in the user ID. Responding to this challenge with a signed message, quoting the token, proves that the email address reaches someone who has access to the private key that matches the primary key you are signing [2]. If the primary key can't sign, they can't respond to this challenge. A signing subkey isn't sufficient here, as it can be attached to any number of keys, so a signature from it does not prove access to the primary key. Backsigs don't help this problem since backsigs only protect against a "stolen" subkey - not against one that is intentionally attached to multiple primary keys. David [1] See, for example, https://dougbarton.us/PGP/PGP-Keysigning.pdf [2] Note I'm not saying that this is necessarily the same entity who you met and checked fingerprints with ;) From mailinglisten at hauke-laging.de Wed Sep 24 18:05:08 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 24 Sep 2014 18:05:08 +0200 Subject: offline primary keys In-Reply-To: <9CBE9754-8159-4733-B4AA-9A3565766C2C@jabberwocky.com> References: <54229A26.10007@pwned.gg> <9CBE9754-8159-4733-B4AA-9A3565766C2C@jabberwocky.com> Message-ID: <2006560.O2m9alhRSH@inno> Am Mi 24.09.2014, 11:39:33 schrieb David Shaw: > If the primary key can't sign, they can't respond to this challenge. > A signing subkey isn't sufficient here, as it can be attached to any > number of keys, so a signature from it does not prove access to the > primary key. Backsigs don't help this problem since backsigs only > protect against a "stolen" subkey - not against one that is > intentionally attached to multiple primary keys. So what difference is this going to make in real life? Somebody proves his identity with an official ID, claims towards witnesses that he owns the key with the respective fingerprint, controls the signing subkey (or not: If you can get a subkey signature from the mainkey why not a data signature?) and has a certification signature for this subkey. And then what? A document appears and the key holder is held responsible for it. And then he just says "I don't own this key. I never did. I have no idea why you believe this was mine" or what? Even your approach is not safe in an automated procedure. You might send the challenge to the wrong person who quotes the text and asks "Why have you sent this so me?". And this email is signed because every mail of this person is signed (not difficult to find such people, and they are not to be blamed for this). The stupid automated tool sees a message with the challenge, signed by the right key... This is the usual problem that you don't know what signatures are supposed to mean. The solution would be a signature notation meaning "This signature is part of a certification check for key $mainkey_fingerprint". > [1] See, for example, https://dougbarton.us/PGP/PGP-Keysigning.pdf Interesting. What is "UID collisions are possible, especially in RSA" supposed to tell me? Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From dshaw at jabberwocky.com Wed Sep 24 18:28:46 2014 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 24 Sep 2014 12:28:46 -0400 Subject: offline primary keys In-Reply-To: <2006560.O2m9alhRSH@inno> References: <54229A26.10007@pwned.gg> <9CBE9754-8159-4733-B4AA-9A3565766C2C@jabberwocky.com> <2006560.O2m9alhRSH@inno> Message-ID: <9EF38F62-D206-45C3-BFBD-F34FB3337ACB@jabberwocky.com> On Sep 24, 2014, at 12:05 PM, Hauke Laging wrote: > Am Mi 24.09.2014, 11:39:33 schrieb David Shaw: > >> If the primary key can't sign, they can't respond to this challenge. >> A signing subkey isn't sufficient here, as it can be attached to any >> number of keys, so a signature from it does not prove access to the >> primary key. Backsigs don't help this problem since backsigs only >> protect against a "stolen" subkey - not against one that is >> intentionally attached to multiple primary keys. > > So what difference is this going to make in real life? > > Somebody proves his identity with an official ID, claims towards > witnesses that he owns the key with the respective fingerprint, controls > the signing subkey (or not: If you can get a subkey signature from the > mainkey why not a data signature?) and has a certification signature for > this subkey. > > And then what? A document appears and the key holder is held responsible > for it. And then he just says "I don't own this key. I never did. I have > no idea why you believe this was mine" or what? That's not a problem that key certifications can solve. Key signing says nothing about the reliability or responsibility of the person. When I make a certification, I'm essentially saying "I checked that there is a binding between this key, and the entity named in the user ID. Here is a URL that says exactly what I checked." For all I know, that person shares his key with dozens of people. For all I know, it was hacked long before or after I signed it. I can't know that and key signing doesn't make any statements as to that. > Even your approach is not safe in an automated procedure. You might send > the challenge to the wrong person who quotes the text and asks "Why have > you sent this so me?". And this email is signed because every mail of > this person is signed (not difficult to find such people, and they are > not to be blamed for this). The stupid automated tool sees a message > with the challenge, signed by the right key... I don't see how this follows. If I sent it to the wrong person, how would they have the right key? In any event, I didn't mention any automation. > This is the usual problem that you don't know what signatures are > supposed to mean. The solution would be a signature notation meaning > "This signature is part of a certification check for key > $mainkey_fingerprint". Sure, that works fine, and is an improvement. But getting back to the original comment, this signature and notation still needs to come from the primary key, and not a subkey. >> [1] See, for example, https://dougbarton.us/PGP/PGP-Keysigning.pdf > > Interesting. What is > > "UID collisions are possible, especially in RSA" > > supposed to tell me? It's often hard to read too much from a powerpoint since the discussion of each step is missing, but I think that's a typo. I suspect he meant "key ID collisions". I read it as "you need to check the whole fingerprint, since it's easy to create a key ID collision". David From infinity0 at pwned.gg Wed Sep 24 20:01:08 2014 From: infinity0 at pwned.gg (Ximin Luo) Date: Wed, 24 Sep 2014 19:01:08 +0100 Subject: offline primary keys [was: Re: Why 2.1 is delayed for so long] In-Reply-To: <9CBE9754-8159-4733-B4AA-9A3565766C2C@jabberwocky.com> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> <54205AE2.40905@pwned.gg> <87fvfiua0v.fsf@vigenere.g10code.de> <54214810.50300@pwned.gg> <877g0usdcu.fsf@vigenere.g10code.de> <542174BB.1080005@pwned.gg> <54218434.80202@sixdemonbag.org> <54218884.7040202@pwned.gg> <5421938C.2010603@sixdemonbag.org> <8738biqj8z.fsf@vigenere.g10code.de> <5421EB4A.2010906@fifthhorseman.net> <553BA043-F9B6-447B-B71C-F1BFDD753324@jabberwocky.com> <54229A26.10007@pwned.gg> <9CBE9754-8159-4733-B4AA-9A3565766C2C@jabberwocky.com> Message-ID: <542306E4.6060705@pwned.gg> On 24/09/14 16:39, David Shaw wrote: > On Sep 24, 2014, at 6:17 AM, Ximin Luo wrote: > >> On 24/09/14 06:16, David Shaw wrote: >>> On Sep 23, 2014, at 5:51 PM, Daniel Kahn Gillmor wrote: >>> >>>> As for Ximin's goals: I think the transition process could look like this: >>>> >>>> 0) add a signing-capable subkey >>>> 1) remove signing-capability from primary key >>>> 2) move primary key offline >>> >>> I understand the desire for steps 0 and 2, but I do not see the need for step 1. You can do 0 and 2 without doing 1. Can you explain why you want 1? >>> >>> I see actual problems for a primary key that can't issue signatures as well as certifications. > > [..] > >> What problems do you see? > > When certifying someone's key, you are signing the combination of the primary key and the user ID in question. In addition to the usual checking of IDs and fingerprints, It is reasonable [1] to send a challenge token to the email address (if there is one) in the user ID. Responding to this challenge with a signed message, quoting the token, proves that the email address reaches someone who has access to the private key that matches the primary key you are signing [2]. > > If the primary key can't sign, they can't respond to this challenge. A signing subkey isn't sufficient here, as it can be attached to any number of keys, so a signature from it does not prove access to the primary key. Backsigs don't help this problem since backsigs only protect against a "stolen" subkey - not against one that is intentionally attached to multiple primary keys. > Why is a signature not enough? Cross-certification is typically considered fine for validation logic. It is not the signature by the subkey that "proves access to the primary key", but the certification of the subkey from the primary key. When you certify a subkey, you mean "I and only I have access to the private component". So a signature from a subkey can be treated as from the primary key owner. IMO, this should actually be formalised into a byte in a packet or something; perhaps it is already. Now, the flaw you mentioned, is valid only if you think some people willingly give their signature keys to other people. If you feel that people don't honour this contract for signature keys, perhaps you have more faith in this contract for encryption keys? You can send a nonce encrypted to their subkey, and wait for the decrypted one to come back. But yes, if OpenPGP does not formalise a meaning for certifications, that is a design flaw, not a problem with my proposal per se. Another way to solve it would be to allow the certify key to be used in formal "proof of possession" protocols such as what you described. But allowing the certify key to sign arbitrary pieces of application-level content is asking for trouble, and not a clean architecture, IMO. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Wed Sep 24 20:45:09 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 24 Sep 2014 14:45:09 -0400 Subject: offline primary keys [was: Re: Why 2.1 is delayed for so long] In-Reply-To: <542306E4.6060705@pwned.gg> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> <54205AE2.40905@pwned.gg> <87fvfiua0v.fsf@vigenere.g10code.de> <54214810.50300@pwned.gg> <877g0usdcu.fsf@vigenere.g10code.de> <542174BB.1080005@pwned.gg> <54218434.80202@sixdemonbag.org> <54218884.7040202@pwned.gg> <5421938C.2010603@sixdemonbag.org> <8738biqj8z.fsf@vigenere.g10code.de> <5421EB4A.2010906@fifthhorseman.net> <553BA043-F9B6-447B-B71C-F1BFDD753324@jabberwocky.com> <54229A26.10007@pwned.gg> <9CBE9754-8159-4733-B4AA-9A3565766C2C@jabberwocky.com> <542306E4.6060705@pwned.gg> Message-ID: <54231135.3090303@sixdemonbag.org> > When you certify a subkey, you mean "I and only I have access to the > private component". Not necessarily. You're introducing policy. > But yes, if OpenPGP does not formalise a meaning for certifications, > that is a design flaw, not a problem with my proposal per se. Be careful: you might be wandering into a thicket here. Some years ago David and I had a vehement argument over on PGP-Basics over whether signatures were interchangeable. The argument fizzled out when we realized we were talking past each other: he was saying (correctly) that *syntactically* signatures across different levels were different and easy to distinguish, and I was saying (correctly) that *semantically* OpenPGP ascribes little difference between signature levels and thus in the absence of specific policy guidelines signatures across different levels are interchangeable. (A persona-level signature is the same as a fully-vetted signature as far as what semantic meaning OpenPGP ascribes to it goes.) The moral of this story: Syntax and semantics are different. OpenPGP cares a lot about the former and almost nothing for the latter. When you talk about "formalize a meaning", that sounds a lot to me like semantics -- and the OpenPGP committee made a deliberate choice to avoid semantics as far as possible. The choice of what semantics should be associated with what syntax in what contexts ... that's policy. From dshaw at jabberwocky.com Wed Sep 24 21:28:01 2014 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 24 Sep 2014 15:28:01 -0400 Subject: offline primary keys [was: Re: Why 2.1 is delayed for so long] In-Reply-To: <542306E4.6060705@pwned.gg> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> <54205AE2.40905@pwned.gg> <87fvfiua0v.fsf@vigenere.g10code.de> <54214810.50300@pwned.gg> <877g0usdcu.fsf@vigenere.g10code.de> <542174BB.1080005@pwned.gg> <54218434.80202@sixdemonbag.org> <54218884.7040202@pwned.gg> <5421938C.2010603@sixdemonbag.org> <8738biqj8z.fsf@vigenere.g10code.de> <5421EB4A.2010906@fifthhorseman.net> <553BA043-F9B6-447B-B71C-F1BFDD753324@jabberwocky.com> <54229A26.10007@pwned.gg> <9CBE9754-8159-4733-B4AA-9A3565766C2C@jabberwocky.com> <542306E4.6060705@pwned.gg> Message-ID: <010D5BCD-F9B9-48A6-88E0-314989CDE168@jabberwocky.com> On Sep 24, 2014, at 2:01 PM, Ximin Luo wrote: > On 24/09/14 16:39, David Shaw wrote: >> >> When certifying someone's key, you are signing the combination of the primary key and the user ID in question. In addition to the usual checking of IDs and fingerprints, It is reasonable [1] to send a challenge token to the email address (if there is one) in the user ID. Responding to this challenge with a signed message, quoting the token, proves that the email address reaches someone who has access to the private key that matches the primary key you are signing [2]. >> >> If the primary key can't sign, they can't respond to this challenge. A signing subkey isn't sufficient here, as it can be attached to any number of keys, so a signature from it does not prove access to the primary key. Backsigs don't help this problem since backsigs only protect against a "stolen" subkey - not against one that is intentionally attached to multiple primary keys. >> > > Why is a signature not enough? Cross-certification is typically considered fine for validation logic. It is not the signature by the subkey that "proves access to the primary key", but the certification of the subkey from the primary key. That's correct, but it's not sufficient, because it does not prove access to a *particular* primary key. Just to *a* primary key. It's perfectly valid in OpenPGP for a given subkey to be owned by multiple primaries (in the sense that there is nothing in RFC-4880 that says you shouldn't do it, and nothing in the crypto that prevents it). I won't argue if this is a good or bad design, or if it should (or even could) be changed at this point, but it is the design we have today. > When you certify a subkey, you mean "I and only I have access to the private component". It proves only "I have access to the private component(s)". It proves you have access to the primary private key and subkey private key because you issued signatures from both of them as part of the certification. It states nothing provable about any other potential people having access to the private keys. > So a signature from a subkey can be treated as from the primary key owner. IMO, this should actually be formalised into a byte in a packet or something; perhaps it is already. Now, the flaw you mentioned, is valid only if you think some people willingly give their signature keys to other people. > > If you feel that people don't honour this contract for signature keys, perhaps you have more faith in this contract for encryption keys? You can send a nonce encrypted to their subkey, and wait for the decrypted one to come back. This has the same issue as a signing subkey. The thing you sign when making a certification is the primary key plus user ID. If you're basing the decision to sign on something other than the primary key plus user ID, you're basing that decision on something that may or may not be cryptographically tied to the thing you are signing. > But yes, if OpenPGP does not formalise a meaning for certifications, that is a design flaw, not a problem with my proposal per se. Another way to solve it would be to allow the certify key to be used in formal "proof of possession" protocols such as what you described. That would be fine as well, but that doesn't exist in OpenPGP today. It's a bit like saying "go ahead and make a signature just for this case" though. David From dkg at fifthhorseman.net Wed Sep 24 22:00:42 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 24 Sep 2014 16:00:42 -0400 Subject: offline primary keys [was: Re: Why 2.1 is delayed for so long] In-Reply-To: <010D5BCD-F9B9-48A6-88E0-314989CDE168@jabberwocky.com> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> <54205AE2.40905@pwned.gg> <87fvfiua0v.fsf@vigenere.g10code.de> <54214810.50300@pwned.gg> <877g0usdcu.fsf@vigenere.g10code.de> <542174BB.1080005@pwned.gg> <54218434.80202@sixdemonbag.org> <54218884.7040202@pwned.gg> <5421938C.2010603@sixdemonbag.org> <8738biqj8z.fsf@vigenere.g10code.de> <5421EB4A.2010906@fifthhorseman.net> <553BA043-F9B6-447B-B71C-F1BFDD753324@jabberwocky.com> <54229A26.10007@pwned.gg> <9CBE9754-8159-4733-B4AA-9A3565766C2C@jabberwocky.com> <542306E4.6060705@pwned.gg> <010D5BCD-F9B9-48A6-88E0-314989CDE168@jabberwocky.com> Message-ID: <542322EA.3070402@fifthhorseman.net> On 09/24/2014 03:28 PM, David Shaw wrote: > On Sep 24, 2014, at 2:01 PM, Ximin Luo wrote: >> > If you feel that people don't honour this contract for signature keys, perhaps you have more faith in this contract for encryption keys? You can send a nonce encrypted to their subkey, and wait for the decrypted one to come back. > This has the same issue as a signing subkey. The thing you sign when making a certification is the primary key plus user ID. If you're basing the decision to sign on something other than the primary key plus user ID, you're basing that decision on something that may or may not be cryptographically tied to the thing you are signing. fwiw, using encryption-capable subkeys in this way is actually pretty common practice in my experience. `caff` in particular (from the `signing-party` package in debian) does this. And encryption-capable subkeys don't even have crossigs (indeed, some can't, if they're used in algorithms that are encryption-only). But i do recognize David's concern about how to prove control over the primary key rather than just a subkey. One approach to resolving David's concern would be to introduce a new sigtype (we're not close to running out of them) that is "primary key challenge-response certification". This would give the possibility of David's proof-of-control round-trip without encouraging most users to sign their daily messages with the same key they use for OpenPGP certification. It might be tricky to define such a sigclass cleanly, though. You certainly don't want to create a system that is effectively a signing-oracle for the primary key. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From infinity0 at pwned.gg Wed Sep 24 22:57:10 2014 From: infinity0 at pwned.gg (Ximin Luo) Date: Wed, 24 Sep 2014 21:57:10 +0100 Subject: offline primary keys [was: Re: Why 2.1 is delayed for so long] In-Reply-To: <010D5BCD-F9B9-48A6-88E0-314989CDE168@jabberwocky.com> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> <54205AE2.40905@pwned.gg> <87fvfiua0v.fsf@vigenere.g10code.de> <54214810.50300@pwned.gg> <877g0usdcu.fsf@vigenere.g10code.de> <542174BB.1080005@pwned.gg> <54218434.80202@sixdemonbag.org> <54218884.7040202@pwned.gg> <5421938C.2010603@sixdemonbag.org> <8738biqj8z.fsf@vigenere.g10code.de> <5421EB4A.2010906@fifthhorseman.net> <553BA043-F9B6-447B-B71C-F1BFDD753324@jabberwocky.com> <54229A26.10007@pwned.gg> <9CBE9754-8159-4733-B4AA-9A3565766C2C@jabberwocky.com> <542306E4.6060705@pwned.gg> <010D5BCD-F9B9-48A6-88E0-314989CDE168@jabberwocky.com> Message-ID: <54233026.1000004@pwned.gg> On 24/09/14 20:28, David Shaw wrote: >> When you certify a subkey, you mean "I and only I have access to the private component". > > It proves only "I have access to the private component(s)". It proves you have access to the primary private key and subkey private key because you issued signatures from both of them as part of the certification. It states nothing provable about any other potential people having access to the private keys. > Actually, it doesn't prove anything about the subkey. It is only a *claim*. Robert mentioned the difference between syntax and semantics in the other email; I do think it is a design flaw not to precisely define the *semantics* of certifications. But granted, this stuff wasn't well-explored when OpenPGP was set in stone. There might be some magical crypto where we can prove mathematically that the same party owns two private signature keys, but I can't think of any way to do that right this minute, at least not with the elementary signature/encryption primitives that OpenPGP supports. And then we'd still have to expand "Certify" to mean "can be used for this purpose". And this is actually beyond your original scenario of merely proving possession of the master private key. So, we have to rely on reasoning about *claims*. And we can only do that if we have precise semantics. "I and only I have access to this private key" is a reasonable definition, but I understand it's not the formal standardised one. I am merely suggesting that in a real-world usage, you don't need to worry about it. > This has the same issue as a signing subkey. > Yes, I know. I was saying that in a realistic scenario, you might more easily be persuaded (:p) to assume that someone would not give their encryption subkey to someone else. >> But yes, if OpenPGP does not formalise a meaning for certifications, that is a design flaw, not a problem with my proposal per se. Another way to solve it would be to allow the certify key to be used in formal "proof of possession" protocols such as what you described. > > That would be fine as well, but that doesn't exist in OpenPGP today. It's a bit like saying "go ahead and make a signature just for this case" though. > Well, proof-of-possession is quite a fundamental thing for a key that is supposed to represent "your identity", so I don't think this is that unnatural. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From isis at patternsinthevoid.net Thu Sep 25 01:13:47 2014 From: isis at patternsinthevoid.net (isis) Date: Wed, 24 Sep 2014 23:13:47 +0000 Subject: [PATCH] doc: Fix --debug-level for all versions. Message-ID: <20140924231347.GP16164@patternsinthevoid.net> Hello GnuPG developers, While fixing an issue in python-gnupg, [0] it was discovered that GnuPG (for 1.4.x, 2.0.x, and 2.1.x branches) actually expects to receive the `--debug-level` argument in the form of `--debug-level=guru`, not `--debug-level guru` (as the current manuals would lead one to believe). I believe the fix is just one-line change [1] to `doc/gpg.texi`, which is attached as a git patch file and separate signature, for your convenience (although if you'd rather make such a simple change yourselves, I'm fine with that too). [0]: https://github.com/isislovecruft/python-gnupg/issues/44 [1]: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/gpg.texi;h=b8c4ab1da3fcb05162bb3d22919156f7e0c4573b;hb=HEAD#l2452 Mit herzlichen Gr??en, -- ?? isis agora lovecruft _________________________________________________________ GPG: 4096R/A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: 00001-g588b7e175-doc-Fix-debug-level-option.patch Type: text/x-diff Size: 851 bytes Desc: not available URL: -------------- next part -------------- -----BEGIN PGP MESSAGE----- owJ42pVUa3ATVRhN+kDYigXEDiDWCwXbkm7aJJtNmoKTpEkHLNYy7fQBlmF3c7NZ muxmdjcvHEqhRQpYgVEUHAUFBgoIKIKDDwbKQ7B02goM0wcdhJEWLQgVeXSUqTcp SunwA++P3bv3fufc853vu7t2ZLQCU46r50/29V6QlHuiV9GaDDQ0OKs3GmkD1Bj0 uENg8BwuiDsg7WNxN/RDNy54ZU7g1V5KZlyFSa8/ywgeDyeD/0Bag4bQUQZKSxOZ esZAMoSDInW0liQNJG0kQMpMu8WWBjyUJEMxFbP4ZJcgmkB4zJI4CcwW/JARfU4Z TOfQt1kWRK8oLISMrBZE9tWHABslQxMohg5QAL1ASwCt1kToTTo0ydAQQBVOBcuO SPsf3AOAp+LGwqTIHxNABgF8sEXAKYiAcruBH4oS8kpSR4Ijj0IXBAsei14AKJH1 eSAvAxj0IikSkAVAQ8AgCqSBkiLAx0EzWJ/oW5AGeEEesgMiO2oMc3BOJ9LFotpQ 6UhoOutl1TIMcoB+7BPjeAcMAtrIEBStUav1lM7hdOgB6gaSIDAcx4fgMZVKNZTD bAa4liAy0wxA9fCNlmQXFCEyAwLIU7QbSoACTlR34OYkmeNZIDjDMWiXEUORtgLl MBS2yyx4B2RxPOoSipE5P8RAvih4vDLyJsKJaikGRC5CRPEh4OTQCQiL4WZOhp4h NTH7KfGtyHQxpnpCwIzBAY/OHxSBoXZwo/pEJEfWwaNyc7wfopxYKiIHNRVK1yOp Bx+LWj6EtGPIBB7VW+QY4KfcPpSICOgQWkW5BwTRYcJWRk+KUSgxZVxsVPiGxVYp L+sqi8ZWKtCYqkgJt65K4lhe8tEIY0ZXEZnES8grF/QLnEPNQzlbm5Oh01lIjQ3d aater9UY9XpLpl1jzNaQ9mx9TmaOxkYadLkDtBMGaJ/MlWEhLXqjRUNY9ZkEabHa EItdm2Gw6Cw2K2mwaLNtVqNVp1dPcMmyVzKlp9NugVU/kSvdK7g5JqSWg3LahqcI D6sKByuwEaP+/Vu9UBrfXzD6Tlyo+GabclbU9ZYHHS/2Tu/pS0jYVdnV3Ntf1Fd2 9K8xqvzx2+MIV3OduZaavLbrc+3ipLL4my3HzXPPctuPFN/uqogjfjj94+jg0Zc7 v133pu2Xu3vzb8w3dnfcajZ52uZOLJjt2zZtS2Bs7upp5MWlpYay75P2nj+1b39K 2bLo5JUHO7c3ujeeqbhZHZ2/+dNfD03CP/w9eK/rp8A3qrO44oOsa6Pb2u9OnPJb Q88sy5Up96cu3ZX7Veffr/Sk1328JPfSpT9L7UV5+0Zdae8pK19WY73cNmxziSsw 5ljVjAuFodV7akoaT+WdqZuw8+ocXZ2qe9OiA6e3BpKInMyW+KatpiX29VUnmzZd 5EcewLhJ8v7E5ovDC5jyL4ZdSGl/O2Zlb/y1ZfY4XcGtL1tizn0yM+q5YpIyvNN9 RjRuqU86teqE4vn1OltF27a82veTJ49LqdhGL++cUjU2/6Oi/iuaqjvH02pdl7Nq fSPeu74OrHuwwrkhj706pzy3teTd457qjo4jOxNbz7cnWLP7t2wtOJARe1SYN3/3 QlsoKvGPg033ofPrRPvihoMxJ3Z3r0q9p86axz4TbU91xX7XWt/QWC3dmJiaUHmu 52RJ9flAl79BWJF1+LM1tyuSLy3aF9hfem75IcWOxvHJ+NyrP8d5+g6PErQjizc2 FVa99FrropjhXfWhNdnKN47VeHb8A6u6ioQ= =HBlG -----END PGP MESSAGE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1154 bytes Desc: Digital signature URL: From dshaw at jabberwocky.com Thu Sep 25 02:45:53 2014 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 24 Sep 2014 20:45:53 -0400 Subject: offline primary keys [was: Re: Why 2.1 is delayed for so long] In-Reply-To: <54233026.1000004@pwned.gg> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> <54205AE2.40905@pwned.gg> <87fvfiua0v.fsf@vigenere.g10code.de> <54214810.50300@pwned.gg> <877g0usdcu.fsf@vigenere.g10code.de> <542174BB.1080005@pwned.gg> <54218434.80202@sixdemonbag.org> <54218884.7040202@pwned.gg> <5421938C.2010603@sixdemonbag.org> <8738biqj8z.fsf@vigenere.g10code.de> <5421EB4A.2010906@fifthhorseman.net> <553BA043-F9B6-447B-B71C-F1BFDD753324@jabberwocky.com> <54229A26.10007@pwned.gg> <9CBE9754-8159-4733-B4AA-9A3565766C2C@jabberwocky.com> <542306E4.6060705@pwned.gg> <010D5BCD-F9B9-48A6-88E0-314989CDE168@jabberwocky.com> <54233026.1000004@pwned.gg> Message-ID: On Sep 24, 2014, at 4:57 PM, Ximin Luo wrote: > On 24/09/14 20:28, David Shaw wrote: >>> When you certify a subkey, you mean "I and only I have access to the private component". >> >> It proves only "I have access to the private component(s)". It proves you have access to the primary private key and subkey private key because you issued signatures from both of them as part of the certification. It states nothing provable about any other potential people having access to the private keys. >> > > Actually, it doesn't prove anything about the subkey. It is only a *claim*. Robert mentioned the difference between syntax and semantics in the other email; I do think it is a design flaw not to precisely define the *semantics* of certifications. But granted, this stuff wasn't well-explored when OpenPGP was set in stone. > > There might be some magical crypto where we can prove mathematically that the same party owns two private signature keys, but I can't think of any way to do that right this minute, at least not with the elementary signature/encryption primitives that OpenPGP supports. And then we'd still have to expand "Certify" to mean "can be used for this purpose". And this is actually beyond your original scenario of merely proving possession of the master private key. Yes. I was responding to your statement that "I and only I have access to the private component", which is subtly incorrect. I agree with you that it is a *claim*, even a common claim, but it is not backed up by the math, which feels like a dangerous path to walk on. Semantics like that need to be backed up reasonably closely by reality, or we can fool ourselves into thinking something is true (or safe) when it is may not be. A safer statement (though still only an approximation) is "I have access to the private component". Take my example of certifying a key only if someone can prove primary key access. I don't, and didn't, say "possession" as in your example above because the math doesn't prove that. I also didn't say that the email reached the owner of the key (or even the owner of the email account). I said "proves that the email address reaches someone who has access to the private key that matches the primary key you are signing". The math does prove that much. The signature may have been obtained under duress, via hacking, via a stolen key, via trickery, or via any number of other means. The email account may have been hacked or the particular mail in question lifted off of the computer (in other words the "access" could be pretty darn tenuous), but that private key plus the challenge were involved. But skip the pedantry: obviously by signing the key I believe that the email reached the key owner (there's my claim), but I'm careful to not assert that as proven. >>> But yes, if OpenPGP does not formalise a meaning for certifications, that is a design flaw, not a problem with my proposal per se. Another way to solve it would be to allow the certify key to be used in formal "proof of possession" protocols such as what you described. >> >> That would be fine as well, but that doesn't exist in OpenPGP today. It's a bit like saying "go ahead and make a signature just for this case" though. >> > > Well, proof-of-possession is quite a fundamental thing for a key that is supposed to represent "your identity", so I don't think this is that unnatural. Or we could just leave things where primary keys can make signatures ;) Seriously, though, I love the symmetry of your suggestion. A key whose only purpose is to make subkeys is appealing, neat, and clean. My own key, in fact, is almost exactly this architecture, chosen over 10 years ago for those same reasons. It makes perfect sense for my use case, but that doesn't make my use case a good default for everyone. David From wk at gnupg.org Thu Sep 25 09:04:20 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 25 Sep 2014 09:04:20 +0200 Subject: [PATCH] doc: Fix --debug-level for all versions. In-Reply-To: <20140924231347.GP16164@patternsinthevoid.net> (isis@patternsinthevoid.net's message of "Wed, 24 Sep 2014 23:13:47 +0000") References: <20140924231347.GP16164@patternsinthevoid.net> Message-ID: <871tr0mb9n.fsf@vigenere.g10code.de> On Thu, 25 Sep 2014 01:13, isis at patternsinthevoid.net said: > While fixing an issue in python-gnupg, [0] it was discovered that GnuPG > (for 1.4.x, 2.0.x, and 2.1.x branches) actually expects to receive the > `--debug-level` argument in the form of `--debug-level=guru`, not > `--debug-level guru` (as the current manuals would lead one to believe). Actually this seems to be a bug in 1.4 only: $ ~/b/gnupg-1.4/g10/gpg --debug-level advanced --version gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! usage: gpg [options] [filename] $ ~/b/gnupg-2.0/g10/gpg2 --debug-level advanced --version gpg (GnuPG) 2.0.23-beta13 [...] I'll take a look at it. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Sep 25 09:48:43 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 25 Sep 2014 09:48:43 +0200 Subject: [PATCH] doc: Fix --debug-level for all versions. In-Reply-To: <871tr0mb9n.fsf@vigenere.g10code.de> (Werner Koch's message of "Thu, 25 Sep 2014 09:04:20 +0200") References: <20140924231347.GP16164@patternsinthevoid.net> <871tr0mb9n.fsf@vigenere.g10code.de> Message-ID: <87r3z0kun8.fsf@vigenere.g10code.de> On Thu, 25 Sep 2014 09:04, wk at gnupg.org said: > I'll take a look at it. The path below will go into 1.4.19. Shalom-Salam, Werner == >From 9b1a78bb541c6c24dc1df8483fcbfe63065a2825 Mon Sep 17 00:00:00 2001 From: Werner Koch Date: Thu, 25 Sep 2014 09:47:28 +0200 Subject: [PATCH] Allow use of --debug-level=LEVEL without '='. * g10/gpg.c (opts): Fix "debug-level". --- NEWS | 2 ++ g10/gpg.c | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index 5e12a86..6fb00cd 100644 --- a/NEWS +++ b/NEWS @@ -1,6 +1,8 @@ Noteworthy changes in version 1.4.19 (unreleased) ------------------------------------------------- + * Fix argument parsing for option --debug-level. + Noteworthy changes in version 1.4.18 (2014-06-30) ------------------------------------------------- diff --git a/g10/gpg.c b/g10/gpg.c index dbf2f40..1b0a364 100644 --- a/g10/gpg.c +++ b/g10/gpg.c @@ -518,7 +518,7 @@ static ARGPARSE_OPTS opts[] = { { oOptions, "options", 2, "@"}, { oDebug, "debug" ,4|16, "@"}, { oDebugAll, "debug-all" ,0, "@"}, - { oDebugLevel, "debug-level" ,0, "@"}, + { oDebugLevel, "debug-level" ,2, "@"}, { oStatusFD, "status-fd" ,1, "@"}, { oStatusFile, "status-file" ,2, "@"}, { oAttributeFD, "attribute-fd" ,1, "@" }, -- 1.8.4.3 -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From infinity0 at pwned.gg Thu Sep 25 12:05:28 2014 From: infinity0 at pwned.gg (Ximin Luo) Date: Thu, 25 Sep 2014 11:05:28 +0100 Subject: offline primary keys [was: Re: Why 2.1 is delayed for so long] In-Reply-To: References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> <54205AE2.40905@pwned.gg> <87fvfiua0v.fsf@vigenere.g10code.de> <54214810.50300@pwned.gg> <877g0usdcu.fsf@vigenere.g10code.de> <542174BB.1080005@pwned.gg> <54218434.80202@sixdemonbag.org> <54218884.7040202@pwned.gg> <5421938C.2010603@sixdemonbag.org> <8738biqj8z.fsf@vigenere.g10code.de> <5421EB4A.2010906@fifthhorseman.net> <553BA043-F9B6-447B-B71C-F1BFDD753324@jabberwocky.com> <54229A26.10007@pwned.gg> <9CBE9754-8159-4733-B4AA-9A3565766C2C@jabberwocky.com> <542306E4.6060705@pwned.gg> <010D5BCD-F9B9-48A6-88E0-314989CDE168@jabberwocky.com> <54233026.1000004@pwned.gg> Message-ID: <5423E8E8.9010504@pwned.gg> On 25/09/14 01:45, David Shaw wrote: > On Sep 24, 2014, at 4:57 PM, Ximin Luo wrote: > >> On 24/09/14 20:28, David Shaw wrote: >>>> When you certify a subkey, you mean "I and only I have access to the private component". >>> >>> It proves only "I have access to the private component(s)". It proves you have access to the primary private key and subkey private key because you issued signatures from both of them as part of the certification. It states nothing provable about any other potential people having access to the private keys. >>> >> >> Actually, it doesn't prove anything about the subkey. It is only a *claim*. Robert mentioned the difference between syntax and semantics in the other email; I do think it is a design flaw not to precisely define the *semantics* of certifications. But granted, this stuff wasn't well-explored when OpenPGP was set in stone. >> >> There might be some magical crypto where we can prove mathematically that the same party owns two private signature keys, but I can't think of any way to do that right this minute, at least not with the elementary signature/encryption primitives that OpenPGP supports. And then we'd still have to expand "Certify" to mean "can be used for this purpose". And this is actually beyond your original scenario of merely proving possession of the master private key. > > Yes. I was responding to your statement that "I and only I have access to the private component", which is subtly incorrect. I agree with you that it is a *claim*, even a common claim, but it is not backed up by the math, which feels like a dangerous path to walk on. Semantics like that need to be backed up reasonably closely by reality, or we can fool ourselves into thinking something is true (or safe) when it is may not be. A safer statement (though still only an approximation) is "I have access to the private component". > It is *totally* incorrect. :) There is no proof mathematically even that "I have access to the private subkey". I could have added someone else's subkey, and they could have completed the verification on my behalf, against common standard. But does anyone have an incentive to do this? I do agree that, ideally we should use maths to prove things whenever possible, but there are many things we cannot prove yet, binding two signature keys being one of them. There are things that seem fundamentally impossible to prove too, such as binding a key to a real-world identity. So, we should formalise semantics about *claims*, and develop reasoning to infer things from these claims. You are right this is dangerous, but it is more dangerous to not have well-defined claims and have fallible humans make vague inferences based on that. With formal semantics, we know the dependency graph of inferences, so we know what goes wrong if a base assumption breaks. And everyone understands what it actually means for an assumption to break. The dependency graph can also help us figure out whether anyone has an incentive to break those assumptions. > Take my example of certifying a key only if someone can prove primary key access. I don't, and didn't, say "possession" as in your example above because the math doesn't prove that. I also didn't say that the email reached the owner of the key (or even the owner of the email account). I said "proves that the email address reaches someone who has access to the private key that matches the primary key you are signing". The math does prove that much. The signature may have been obtained under duress, via hacking, via a stolen key, via trickery, or via any number of other means. The email account may have been hacked or the particular mail in question lifted off of the computer (in other words the "access" could be pretty darn tenuous), but that private key plus the challenge were involved. But skip the pedantry: obviously by signing the key I believe that the email reached the key owner (there's my claim), but I'm careful to not assert that as proven. > What do you think is the difference between "possession" and "access"? By "possession", I mean "can use the private key to perform private-key operations". And what does mathematically proving possession of the master key really gain you? You can never prove possession of the subkeys, unless you perform the verification protocol with the subkeys directly too. As I mentioned, I don't think there is a way to mathematically bind two signature keys, i.e. proving the same party has possession of both of them; all the protocols I can think up right now, can be completed with two separate parties (excluding the challenger) that each only have access to one private key. I do agree with the "mathematically prove whenever possible" principle though, and the master key is the most important thing to prove possession of, so it would be good to solve that. But I don't think an arbitrary-signature capability is worth it, just for this. Better to add things to a whitelist of what "Certify" means. Perhaps OpenPGP already has something that lets us do this, where we can certify a nonce and send it back? (We could certify a bogus public key like 0x000..., and put the nonce in one of the notations?) > Seriously, though, I love the symmetry of your suggestion. A key whose only purpose is to make subkeys is appealing, neat, and clean. My own key, in fact, is almost exactly this architecture, chosen over 10 years ago for those same reasons. It makes perfect sense for my use case, but that doesn't make my use case a good default for everyone. > But I don't see reasons that it wouldn't be a good default for everyone. The use-case you just mentioned, 99% of people won't even do. And even less people will care about the semantic difference between "prove possession/access to master key" vs "prove possession/access of subkey that is attached to a master key". If you are worried, you can just ask your contact "does anyone else have your private subkey" and hope they don't lie, just like you hope they don't lie about "does anyone have access to your email account". X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Thu Sep 25 13:50:03 2014 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 25 Sep 2014 07:50:03 -0400 Subject: offline primary keys [was: Re: Why 2.1 is delayed for so long] In-Reply-To: <5423E8E8.9010504@pwned.gg> References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> <54205AE2.40905@pwned.gg> <87fvfiua0v.fsf@vigenere.g10code.de> <54214810.50300@pwned.gg> <877g0usdcu.fsf@vigenere.g10code.de> <542174BB.1080005@pwned.gg> <54218434.80202@sixdemonbag.org> <54218884.7040202@pwned.gg> <5421938C.2010603@sixdemonbag.org> <8738biqj8z.fsf@vigenere.g10code.de> <5421EB4A.2010906@fifthhorseman.net> <553BA043-F9B6-447B-B71C-F1BFDD753324@jabberwocky.com> <54229A26.10007@pwned.gg> <9CBE9754-8159-4733-B4AA-9A3565766C2C@jabberwocky.com> <542306E4.6060705@pwned.gg> <010D5BCD-F9B9-48A6-88E0-314989CDE168@jabberwocky.com> <54233026.1000004@pwned.gg> <5423E8E8.9010504@pwned.gg> Message-ID: <19E3EB98-051A-43BF-B799-A604A29B9B39@jabberwocky.com> On Sep 25, 2014, at 6:05 AM, Ximin Luo wrote: [..] I'm pretty sure at this point that you're not reading what I'm writing, I'm not reading what you're writing, or we're just vociferously talking past each other. Nice discussing with you, though. David From dkg at fifthhorseman.net Thu Sep 25 20:45:37 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 25 Sep 2014 14:45:37 -0400 Subject: [PATCH] warn about (but don't fail) on scdaemon options in gpg.conf Message-ID: <1411670737-24192-1-git-send-email-dkg@fifthhorseman.net> * g10/gpg.c: add config options that should belong in scdaemon.conf * g10/main.h, g10/misc.c (obsolete_scdaemon_option): new -- In gpg2, the following options are only relevant for scdaemon: reader-port ctapi-driver pcsc-driver disable-ccid but in gpg1, they are options for gpg itself. Some users of gpg1 might have these options in their ~/.gnupg/gpg.conf, which causes gpg2 to fail hard if it reads that config file. gpg2 should not fail hard, though giving a warning (and suggesting a move to scdaemon.conf) seems OK. This patch does *not* reintroduce any documentation for these options in gpg.texi, even to indicate that they are "dummy" options, since scdaemon.texi contains the appropriate documentation. Debian-bug-id: 762844 --- g10/gpg.c | 21 +++++++++++++++++++++ g10/main.h | 2 ++ g10/misc.c | 12 ++++++++++++ 3 files changed, 35 insertions(+) diff --git a/g10/gpg.c b/g10/gpg.c index a9d248d..334b7e0 100644 --- a/g10/gpg.c +++ b/g10/gpg.c @@ -366,6 +366,10 @@ enum cmd_and_opt_values oKeyidFormat, oExitOnStatusWriteError, oLimitCardInsertTries, + oReaderPort, + octapiDriver, + opcscDriver, + oDisableCCID, oRequireCrossCert, oNoRequireCrossCert, oAutoKeyLocate, @@ -764,6 +768,11 @@ static ARGPARSE_OPTS opts[] = { ARGPARSE_s_n (oExitOnStatusWriteError, "exit-on-status-write-error", "@"), ARGPARSE_s_i (oLimitCardInsertTries, "limit-card-insert-tries", "@"), + ARGPARSE_s_s (oReaderPort, "reader-port", "@"), + ARGPARSE_s_s (octapiDriver, "ctapi-driver", "@"), + ARGPARSE_s_s (opcscDriver, "pcsc-driver", "@"), + ARGPARSE_s_n (oDisableCCID, "disable-ccid", "@"), + ARGPARSE_s_n (oAllowMultisigVerification, "allow-multisig-verification", "@"), ARGPARSE_s_n (oEnableDSA2, "enable-dsa2", "@"), @@ -2350,6 +2359,18 @@ main (int argc, char **argv) case oGpgAgentInfo: obsolete_option (configname, configlineno, "--gpg-agent-info"); break; + case oReaderPort: + obsolete_scdaemon_option (configname, configlineno, "--reader-port"); + break; + case octapiDriver: + obsolete_scdaemon_option (configname, configlineno, "--ctapi-driver"); + break; + case opcscDriver: + obsolete_scdaemon_option (configname, configlineno, "--pcsc-driver"); + break; + case oDisableCCID: + obsolete_scdaemon_option (configname, configlineno, "--disable-ccid"); + break; case oAnswerYes: opt.answer_yes = 1; break; case oAnswerNo: opt.answer_no = 1; break; diff --git a/g10/main.h b/g10/main.h index 44c4478..62b770f 100644 --- a/g10/main.h +++ b/g10/main.h @@ -136,6 +136,8 @@ void deprecated_warning(const char *configname,unsigned int configlineno, void deprecated_command (const char *name); void obsolete_option (const char *configname, unsigned int configlineno, const char *name); +void obsolete_scdaemon_option (const char *configname, unsigned int configlineno, + const char *name); int string_to_cipher_algo (const char *string); int string_to_digest_algo (const char *string); diff --git a/g10/misc.c b/g10/misc.c index 54c2f89..825581a 100644 --- a/g10/misc.c +++ b/g10/misc.c @@ -1042,6 +1042,18 @@ obsolete_option (const char *configname, unsigned int configlineno, name); } +void +obsolete_scdaemon_option (const char *configname, unsigned int configlineno, + const char *name) +{ + if(configname) + log_info (_("%s:%u: \"%s\" is obsolete in this file - it only has effect in scdaemon.conf\n"), + configname, configlineno, name); + else + log_info (_("WARNING: \"%s\" is an obsolete option - it has no effect except on scdaemon\n"), + name); +} + /* * Wrapper around gcry_cipher_map_name to provide a fallback using the -- 2.1.0 From wk at gnupg.org Thu Sep 25 22:28:21 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 25 Sep 2014 22:28:21 +0200 Subject: [PATCH] warn about (but don't fail) on scdaemon options in gpg.conf In-Reply-To: <1411670737-24192-1-git-send-email-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 25 Sep 2014 14:45:37 -0400") References: <1411670737-24192-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <874mvvla1m.fsf@vigenere.g10code.de> Hi, thanks, I pushed the change with some minor edits. My first contact with a computer was quite indirect via an IBM 029 and I still keep the habit to not type more than 80 characters per line if possible. Thus I wrapped some lines. Another good feature is to keep certain fixed strings out of translatable strings. Pushed to master and 2.0. Thanks. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rjh at sixdemonbag.org Fri Sep 26 05:42:26 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 25 Sep 2014 23:42:26 -0400 Subject: Why 2.1 is delayed for so long In-Reply-To: References: Message-ID: <5424E0A2.5020807@sixdemonbag.org> On 9/25/2014 10:34 PM, Peter Gutmann wrote: > Just to be pedantic, he never actually used that form either, but > it's attributed to him. The philosopher John Punch came up with the > "entia non sunt multiplicanda praeter necessitatem" form. Huh! I learn something new every day. Thank you! -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3744 bytes Desc: S/MIME Cryptographic Signature URL: From pgut001 at cs.auckland.ac.nz Fri Sep 26 04:34:37 2014 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Fri, 26 Sep 2014 14:34:37 +1200 Subject: Why 2.1 is delayed for so long In-Reply-To: <54218434.80202@sixdemonbag.org> Message-ID: "Robert J. Hansen" writes: >This may require a little bit of history. > >Most people think of Occam's razor as "the simplest explanation is best," but >that's actually not right: William of Ockham's original formulation was "do >not multiply objects without necessity." Just to be pedantic, he never actually used that form either, but it's attributed to him. The philosopher John Punch came up with the "entia non sunt multiplicanda praeter necessitatem" form. Peter. From dkg at fifthhorseman.net Fri Sep 26 21:21:56 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 26 Sep 2014 15:21:56 -0400 Subject: doc/OpenPGP refers to RFC 2440, should refer to RFC 4880 Message-ID: <87fvfeuqzv.fsf@alice.fifthhorseman.net> Hi Werner, other GnuPG folks. doc/OpenPGP says: See RFC2440 for a description of OpenPGP. We have an annotated version of this RFC online: http://www.gnupg.org/rfc2440.html Compatibility Notes =================== GnuPG (>=1.0.3) is in compliance with RFC2440 despite these exceptions: ... But the modern reference for OpenPGP (which GnuPG is compatible with) is RFC 4880. This document should probably be updated to reflect that situation at least (though i haven't verified all the compatibility notes, so i'm not sure what else should change). --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From wk at gnupg.org Sat Sep 27 11:16:38 2014 From: wk at gnupg.org (Werner Koch) Date: Sat, 27 Sep 2014 11:16:38 +0200 Subject: doc/OpenPGP refers to RFC 2440, should refer to RFC 4880 In-Reply-To: <87fvfeuqzv.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 26 Sep 2014 15:21:56 -0400") References: <87fvfeuqzv.fsf@alice.fifthhorseman.net> Message-ID: <87mw9ljudl.fsf@vigenere.g10code.de> On Fri, 26 Sep 2014 21:21, dkg at fifthhorseman.net said: > But the modern reference for OpenPGP (which GnuPG is compatible with) is > RFC 4880. This document should probably be updated to reflect that I pushed this patch: diff --git a/doc/OpenPGP b/doc/OpenPGP index a511ad7..96223d7 100644 --- a/doc/OpenPGP +++ b/doc/OpenPGP @@ -1,9 +1,8 @@ GnuPG and OpenPGP ================= - See RFC2440 for a description of OpenPGP. We have an annotated version - of this RFC online: http://www.gnupg.org/rfc2440.html - + See RFC-4880 for a description of OpenPGP. These notes are older + than RFC-4880 and refer to the predecessor of the specs (RFC-2440). Compatibility Notes @@ -12,7 +11,9 @@ * (9.2) states that IDEA SHOULD be implemented. This is not done due to patent problems. - + UPDATE: Since version 1.4.13 (or GnuPG 2.x with Libgcrypt 1.6) + IDEA support has been added to allow decryption of old + PGP-2 encrypted material. All MAY features are implemented with this exception: @@ -28,17 +29,17 @@ A special format of partial packet length exists for v3 packets which can be considered to be in compliance with RFC1991; this format is only created if a special option is active. + UPDATE: This support has been removed with version 1.3.6. GnuPG uses a S2K mode of 101 for GNU extensions to the secret key protection algorithms. This number is not defined in OpenPGP, but - given the fact that this number is in a range which used at many - other places in OpenPGP for private/experimenat algorithm identifiers, - this should be not a so bad choice. The 3 bytes "GNU" are used - to identify this as a GNU extension - see the file DETAILS for a + given that this number is in a range which is used at many other + places in OpenPGP for private/experimental algorithm identifiers, + this should be not a too bad choice. The 3 bytes "GNU" are used to + identify this as a GNU extension - see the file DETAILS for a definition of the used data formats. Thanks. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Sat Sep 27 15:01:53 2014 From: wk at gnupg.org (Werner Koch) Date: Sat, 27 Sep 2014 15:01:53 +0200 Subject: Why 2.1 is delayed for so long In-Reply-To: <00BCD22E-5522-45F6-8C2E-B00C3707B3BF@jabberwocky.com> (David Shaw's message of "Tue, 23 Sep 2014 23:29:34 -0400") References: <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg> <541CE9FB.7030102@pwned.gg> <542028B4.3070204@sixdemonbag.org> <2F3080ED-710F-40B3-88C1-43459F7C22F1@jabberwocky.com> <87oau7txio.fsf@vigenere.g10code.de> <00BCD22E-5522-45F6-8C2E-B00C3707B3BF@jabberwocky.com> Message-ID: <87wq8pi5dq.fsf@vigenere.g10code.de> On Wed, 24 Sep 2014 05:29, dshaw at jabberwocky.com said: > thought, perhaps not "--expert". That is, make up some new option to > show the full key generation list. (or even a different command: > "--gen-key" vs "--gen-key-full" perhaps?) The reason why I'm I implemented this: $ g10/gpg2 -v --gen-key gpg (GnuPG) 2.1.0-beta849; Copyright (C) 2014 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Note: Use "gpg --full-gen-key" for a full featured key generation dialog. GnuPG needs to construct a user ID to identify your key. Real name: Kit Fielding Email address: kit at dickfrancis.null You selected this USER-ID: "Kit Fielding " Change (N)ame, (E)mail, or (O)kay/(Q)uit? o We need to generate a lot of random bytes. It is a good idea to perform [...] pub rsa2048/7BD0D1C1 2014-09-27 Key fingerprint = 56B6 8B1E 36C5 AD87 148F BDCD 4C4D 9B18 7BD0 D1C1 uid [ unknown] Kit Fielding sub rsa2048/39BAD417 2014-09-27 --gen-full-key is indetical to the old one. Using --gen-key with --batch is also not affected. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From richard.purdie at linuxfoundation.org Sat Sep 27 15:59:20 2014 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Sat, 27 Sep 2014 14:59:20 +0100 Subject: Use of pkg-config In-Reply-To: <20140926234028.GA15364@gaara.hadrons.org> References: <1399985729.31891.165.camel@ted> <87y4y4s7y8.fsf@vigenere.g10code.de> <1400083173.31891.246.camel@ted> <87bnv0s1sx.fsf@vigenere.g10code.de> <20140926234028.GA15364@gaara.hadrons.org> Message-ID: <1411826360.5669.4.camel@ted> On Sat, 2014-09-27 at 01:40 +0200, Guillem Jover wrote: > I think this request is actually two different ones, but Richard might > want to clarify anyway. I'd like to shed some light on an important > distinction that might not have been clear from the initial mail. > > One thing is for GnuPG projects to provide just a pkg-config .pc file, > as part of its public API, so that external users of those libraries > *can* choose to use them instead of the *-config scripts, which would > not impose any additional dependency on the GnuPG projects themselves. > This has many advantages as Richard mentioned in the thread. It also > makes life in Debian's multiarch cross-building world much easier as > the .pc files can be coinstalled on arch qualified paths, so it does > not matter that their contents differ per arch. It also guarantees the > same filename and variables and similar are used in all downstreams, so > that external projects can depend on those instead of possibly unportable > distribution specific .pc files. I'd expect this part to be pretty much > an uncontroversial addition, and I'd like to request for the inclusion > of such files in the upstream GnuPG projects to be reconsidered, please. > > The other thing would be for the GnuPG projects to *use* themselves > such .pc files (or other external ones) through pkg-config, and as I > understand it Richard would also like to see this happen, but this > seems secondary to me given your concerns about dependencies. And > although even if still problematic it seems it would be easier to > be dealt with locally. Given a choice between nothing and some .pc files to help the situation, I'd much rather have the .pc files even if the GnuPG projects don't use them directly themselves. We (as in Yocto Project/OpenEmbedded) are carrying patches to do this since the .pc files make our lives much easier than the -config ones and its worth the pain of carrying them :/. I continue to live in hope that this subject can be revisited. Cheers, Richard From dkg at fifthhorseman.net Mon Sep 29 17:37:55 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 29 Sep 2014 11:37:55 -0400 Subject: [PATCH] GNU calls little-endian powerpc64 powerpc64le, not powerpc64el Message-ID: <1412005075-23676-1-git-send-email-dkg@fifthhorseman.net> * src/Makefile.am (lock_obj_pub): fix powerpc64el to powerpc64le * src/sysconfig/lock-obj-pub.powerpc64el-unknown-linux-gnu.h : move to src/sysconfig/lock-obj-pub.powerpc64le-unknown-linux-gnu.h -- 33e5504fbb5e5e2ff44023c0a22dfb668ff8b10f created lock-obj-pub for little-endian powerpc64, but misnamed the patch file as powerpc64el instead of powerpc64le. Sorry for the earlier mistake, this should correct it. See commentary from Helmut Grohne at https://bugs.debian.org/762322#34 Debian-bug-id: 762322 --- src/Makefile.am | 2 +- .../lock-obj-pub.powerpc64el-unknown-linux-gnu.h | 25 ---------------------- .../lock-obj-pub.powerpc64le-unknown-linux-gnu.h | 25 ++++++++++++++++++++++ 3 files changed, 26 insertions(+), 26 deletions(-) delete mode 100644 src/syscfg/lock-obj-pub.powerpc64el-unknown-linux-gnu.h create mode 100644 src/syscfg/lock-obj-pub.powerpc64le-unknown-linux-gnu.h diff --git a/src/Makefile.am b/src/Makefile.am index 62579dc..65f8513 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -57,7 +57,7 @@ lock_obj_pub = \ syscfg/lock-obj-pub.mipsel-unknown-linux-gnu.h \ syscfg/lock-obj-pub.powerpc-unknown-linux-gnu.h \ syscfg/lock-obj-pub.powerpc64-unknown-linux-gnu.h \ - syscfg/lock-obj-pub.powerpc64el-unknown-linux-gnu.h \ + syscfg/lock-obj-pub.powerpc64le-unknown-linux-gnu.h \ syscfg/lock-obj-pub.s390x-ibm-linux-gnu.h \ syscfg/lock-obj-pub.sh4-unknown-linux-gnu.h \ syscfg/lock-obj-pub.sparc-unknown-linux-gnu.h \ diff --git a/src/syscfg/lock-obj-pub.powerpc64el-unknown-linux-gnu.h b/src/syscfg/lock-obj-pub.powerpc64el-unknown-linux-gnu.h deleted file mode 100644 index 79073d4..0000000 --- a/src/syscfg/lock-obj-pub.powerpc64el-unknown-linux-gnu.h +++ /dev/null @@ -1,25 +0,0 @@ -## lock-obj-pub.powerpc64le-unknown-linux-gnu.h -## File created by gen-posix-lock-obj - DO NOT EDIT -## To be included by mkheader into gpg-error.h - -typedef struct -{ - long _vers; - union { - volatile char _priv[40]; - long _x_align; - long *_xp_align; - } u; -} gpgrt_lock_t; - -#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \ - 0,0,0,0,0,0,0,0, \ - 0,0,0,0,0,0,0,0, \ - 0,0,0,0,0,0,0,0, \ - 0,0,0,0,0,0,0,0}}} -## -## Local Variables: -## mode: c -## buffer-read-only: t -## End: -## diff --git a/src/syscfg/lock-obj-pub.powerpc64le-unknown-linux-gnu.h b/src/syscfg/lock-obj-pub.powerpc64le-unknown-linux-gnu.h new file mode 100644 index 0000000..79073d4 --- /dev/null +++ b/src/syscfg/lock-obj-pub.powerpc64le-unknown-linux-gnu.h @@ -0,0 +1,25 @@ +## lock-obj-pub.powerpc64le-unknown-linux-gnu.h +## File created by gen-posix-lock-obj - DO NOT EDIT +## To be included by mkheader into gpg-error.h + +typedef struct +{ + long _vers; + union { + volatile char _priv[40]; + long _x_align; + long *_xp_align; + } u; +} gpgrt_lock_t; + +#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0}}} +## +## Local Variables: +## mode: c +## buffer-read-only: t +## End: +## -- 2.1.0 From dkg at fifthhorseman.net Mon Sep 29 23:48:39 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 29 Sep 2014 17:48:39 -0400 Subject: [PATCH] use --no-sk-comments, not --no-sk-comment Message-ID: <1412027319-19859-1-git-send-email-dkg@fifthhorseman.net> The --no-sk-comments flag is (or should be) a no-op in modern versions of gnupg, but gpgme should still use its full form rather than the (slightly) abbreviated --no-sk-comment --- src/engine-gpg.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/engine-gpg.c b/src/engine-gpg.c index 8e18253..30c3bfb 100644 --- a/src/engine-gpg.c +++ b/src/engine-gpg.c @@ -779,7 +779,7 @@ build_argv (engine_gpg_t gpg, const char *pgmname) argc++; if (!gpg->cmd.used) argc++; /* --batch */ - argc += 1; /* --no-sk-comment */ + argc += 1; /* --no-sk-comments */ argv = calloc (argc + 1, sizeof *argv); if (!argv) @@ -864,7 +864,7 @@ build_argv (engine_gpg_t gpg, const char *pgmname) } argc++; } - argv[argc] = strdup ("--no-sk-comment"); + argv[argc] = strdup ("--no-sk-comments"); if (!argv[argc]) { int saved_err = gpg_error_from_syserror (); -- 2.1.0 From dkg at fifthhorseman.net Mon Sep 29 23:49:52 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 29 Sep 2014 17:49:52 -0400 Subject: [PATCH 1/2] avoid duplicate declarationof sk-comments and no-sk-comments noops Message-ID: <1412027393-22319-1-git-send-email-dkg@fifthhorseman.net> * g10/gpg.c: cleanup argument parsing -- With c76117f8b0165fe5cec5e7f234f55f5a4cd7f0ab, the GnuPG 2.0.x branch accidentally introduced a second (identical) argument parser for both --sk-comments, and for --no-sk-comments. This caused short versions (e.g. omitting the trailing "s", as gpgme does) of either command to fail with: gpg: option "--sk-comment" is ambiguous --- g10/gpg.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/g10/gpg.c b/g10/gpg.c index 12d4295..eefd4ae 100644 --- a/g10/gpg.c +++ b/g10/gpg.c @@ -538,9 +538,6 @@ static ARGPARSE_OPTS opts[] = { ARGPARSE_s_i (oAttributeFD, "attribute-fd", "@"), ARGPARSE_s_s (oAttributeFile, "attribute-file", "@"), - ARGPARSE_s_n (oNoop, "sk-comments", "@"), - ARGPARSE_s_n (oNoop, "no-sk-comments", "@"), - ARGPARSE_s_i (oCompletesNeeded, "completes-needed", "@"), ARGPARSE_s_i (oMarginalsNeeded, "marginals-needed", "@"), ARGPARSE_s_i (oMaxCertDepth, "max-cert-depth", "@" ), -- 2.1.0 From dkg at fifthhorseman.net Mon Sep 29 23:49:53 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 29 Sep 2014 17:49:53 -0400 Subject: [PATCH 2/2] --compress-sigs and --compress-keys are not no-ops in 2.0.x branch In-Reply-To: <1412027393-22319-1-git-send-email-dkg@fifthhorseman.net> References: <1412027393-22319-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <1412027393-22319-2-git-send-email-dkg@fifthhorseman.net> * g10/gpg.c: cleanup argument parsing -- c76117f8b0165fe5cec5e7f234f55f5a4cd7f0ab mistakenly marked compress-sigs and compress-keys as no-ops on the 2.0.x branch. These options still have an effect on the 2.0.x branch, and the duplicate declaration also causes the gpg argument parser to fail when shortened versions of the option are present, like: gpg: option "--compress-k" is ambiguous --- g10/gpg.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/g10/gpg.c b/g10/gpg.c index eefd4ae..a995796 100644 --- a/g10/gpg.c +++ b/g10/gpg.c @@ -770,8 +770,6 @@ static ARGPARSE_OPTS opts[] = { /* Dummy options. */ ARGPARSE_s_n (oNoop, "sk-comments", "@"), ARGPARSE_s_n (oNoop, "no-sk-comments", "@"), - ARGPARSE_s_n (oNoop, "compress-keys", "@"), - ARGPARSE_s_n (oNoop, "compress-sigs", "@"), ARGPARSE_end () }; -- 2.1.0