From cp at axs.org  Wed Oct  1 13:19:02 2014
From: cp at axs.org (Chuck Peters)
Date: Wed, 1 Oct 2014 11:19:02 +0000
Subject: [Pkg-gnupg-maint] Why 2.1 is delayed for so long
In-Reply-To: <541C3F41.3050107@fifthhorseman.net>
References: <c7c5753a-8a67-4a25-807c-733a7076918f@email.android.com>
 <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg>
 <541C3F41.3050107@fifthhorseman.net>
Message-ID: <20141001111902.GA6870@xen.axs.org>

Daniel Kahn Gillmor said:
> 
> 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).

Great, I look forward to trying it out.  I would also like to make it 
available in a Launchpad PPA for other Ubuntu users to try out.
 
> 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 ../

On Ubuntu Trusty, or 14.04, and we have dependency issues with curl and 
the older libgnutls.  When I build the beta with ./configure ; make ; 
make install it works fine except that I needed to install the newer 
libgpg-error-dev and libgpg-error0 from Debian.  In 2007 Eric Dorland 
added the libcurl4-gnutls-dev build dep.

  * debian/control:
    - Add libcurl4-gnutls-dev build dep, to use the real curl.

I haven't figure out why we need to the older GnuTLS yet and I would 
like to minimize the number of depends in the PPA to avoid other 
possible issues.  Do you have any suggestions?

I'm sure I'll have more questions, for example are you planning on 
including a gpgtar man page?

Thanks,
Chuck


cp at ubuntu:~/gitbuild/gnupg2$ git-buildpackage -uc -us
 dpkg-buildpackage -rfakeroot -D -us -uc -i -I
dpkg-buildpackage: source package gnupg2
dpkg-buildpackage: source version 2.1.0~beta834-1
dpkg-buildpackage: source distribution experimental
dpkg-buildpackage: source changed by Daniel Kahn Gillmor <dkg at fifthhorseman.net>
 dpkg-source -i -I --before-build gnupg2
dpkg-buildpackage: host architecture amd64
dpkg-source: info: using options from gnupg2/debian/source/options: --compression=bzip2 --compression-level=9
dpkg-checkbuilddeps: Unmet build dependencies: automake1.11 ghostscript libbz2-dev libcurl4-gnutls-dev libusb-dev texinfo transfig
dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
dpkg-buildpackage: warning: (Use -d flag to override.)
debuild: fatal error at line 1364:
dpkg-buildpackage -rfakeroot -D -us -uc -i -I failed
gbp:error: Couldn't run 'debuild -i -I -uc -us': debuild -i -I returned 29
cp at ubuntu:~/gitbuild/gnupg2$ sudo apt-get install automake1.11 ghostscript libbz2-dev libcurl4-gnutls-dev libusb-dev texinfo transfig
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libcurl4-gnutls-dev : Depends: libgnutls-dev but it is not going to be installed
                       Depends: librtmp-dev but it is not going to be installed
E: Unable to correct problems, you have held broken packages.




From dkg at fifthhorseman.net  Wed Oct  1 16:20:25 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 01 Oct 2014 10:20:25 -0400
Subject: gnupg beta packaging for debian/ubuntu [was: Re: Why 2.1 is
 delayed for so long]
In-Reply-To: <20141001111902.GA6870@xen.axs.org>
References: <c7c5753a-8a67-4a25-807c-733a7076918f@email.android.com>
 <871tr86lm2.fsf@vigenere.g10code.de> <541C21ED.2090602@pwned.gg>
 <541C3F41.3050107@fifthhorseman.net> <20141001111902.GA6870@xen.axs.org>
Message-ID: <542C0DA9.7000801@fifthhorseman.net>

On 10/01/2014 07:19 AM, Chuck Peters wrote:
> Daniel Kahn Gillmor said:
>>
>> 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).
> 
> Great, I look forward to trying it out.  I would also like to make it 
> available in a Launchpad PPA for other Ubuntu users to try out.

that sounds great, but please be aware of the issues raised earlier, in
particular the dirmngr concerns.

>> 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 ../
> 
> On Ubuntu Trusty, or 14.04, and we have dependency issues with curl and 
> the older libgnutls.  When I build the beta with ./configure ; make ; 
> make install it works fine except that I needed to install the newer 
> libgpg-error-dev and libgpg-error0 from Debian.  In 2007 Eric Dorland 
> added the libcurl4-gnutls-dev build dep.
> 
>   * debian/control:
>     - Add libcurl4-gnutls-dev build dep, to use the real curl.
> 
> I haven't figure out why we need to the older GnuTLS yet and I would 
> like to minimize the number of depends in the PPA to avoid other 
> possible issues.  Do you have any suggestions?

you shouldn't need to use the older gnutls, which is unsupported
upstream -- if at all possible, please use gnutls 3.x.  I don't know
enough about ubuntu's gnutls packaging to know what you're running into
here though, hopefully someone with more ubuntu knowledge can weigh in.

> I'm sure I'll have more questions, for example are you planning on 
> including a gpgtar man page?

i don't think we're currently shipping gpgtar at all, let alone a
manpage for it.

We do aim to ship man pages for all executables we ship, as part of
debian policy, but i don't think anyone has made a manpage for gpgtar
yet.  ideally, that sort of thing would be contributed upstream, maybe
as doc/gpgtar.texi?

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20141001/0d60c3ca/attachment.sig>

From steve at gpgtools.org  Wed Oct  1 18:48:57 2014
From: steve at gpgtools.org (steve)
Date: Wed, 1 Oct 2014 18:48:57 +0200
Subject: better error message if too many results are found on key servers
Message-ID: <51D49D2B-0D99-40F7-8FDF-B936AB0C74B1@gpgtools.org>

Hi team,

if I search for ?steve? gnupg tells me Not found on key server. Which is very misleading. It would be better to output ?Too many results found for your query. Please enter a more detailed search term.?

What do you think?

If you agree, feel free to create a ticket for this request.

All the best,
steve


From wk at gnupg.org  Wed Oct  1 22:51:38 2014
From: wk at gnupg.org (Werner Koch)
Date: Wed, 01 Oct 2014 22:51:38 +0200
Subject: better error message if too many results are found on key servers
In-Reply-To: <51D49D2B-0D99-40F7-8FDF-B936AB0C74B1@gpgtools.org>
 (steve@gpgtools.org's message of "Wed, 1 Oct 2014 18:48:57 +0200")
References: <51D49D2B-0D99-40F7-8FDF-B936AB0C74B1@gpgtools.org>
Message-ID: <87tx3nfr8l.fsf@vigenere.g10code.de>

On Wed,  1 Oct 2014 18:48, steve at gpgtools.org said:

> if I search for ?steve? gnupg tells me Not found on key server. Which
> is very misleading. It would be better to output ?Too many results

That is a keyserver thing.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From wk at gnupg.org  Thu Oct  2 20:52:41 2014
From: wk at gnupg.org (Werner Koch)
Date: Thu, 02 Oct 2014 20:52:41 +0200
Subject: GPGME 1.5.1:  Invalid crypto engine
In-Reply-To: <54169438.5030804@chili-radiology.com> (Florian Schwind's message
 of "Mon, 15 Sep 2014 09:24:40 +0200")
References: <54169438.5030804@chili-radiology.com>
Message-ID: <878ukyfgn9.fsf@vigenere.g10code.de>

On Mon, 15 Sep 2014 09:24, f.schwind at chili-radiology.com said:

> 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

Actually this is not a crypto-engine but the configuration tool for
GnuPG-2.  If gpgme finds this program, it uses the GnuPG-2 mode, which
means that the engines as reported by running gpgconf like

  $ gpgconf --list-components
  gpg:GPG for OpenPGP:/usr/local/bin/gpg2
  gpg-agent:GPG Agent:/usr/local/bin/gpg-agent
  scdaemon:Smartcard Daemon:/usr/local/libexec/scdaemon
  gpgsm:GPG for S/MIME:/usr/local/bin/gpgsm
  dirmngr:Directory Manager:/usr/local/bin/dirmngr
  pinentry:PIN and Passphrase Entry:/usr/local/bin/pinentry
  
are used.  Only if gpgconf is not found gpgme will fallback to use
gpg-1.  However, sometimes you may want to use gpg 1 anyway.  To
achieve that you must use 

 -- Function: int gpgme_set_global_flag (const char *NAME,
          const char *VALUE)
     On some systems it is not easy to set environment variables and
     thus hard to use GPGME's internal trace facility for debugging.
     This function has been introduced as an alternative way to enable
     debugging and for a couple of other rarely used tweaks.  It is
     important to assure that only one thread accesses GPGME functions
     between a call to this function and after the return from the call
     to `gpgme_check_version'.

     All currently supported features require that this function is
     called as early as possible -- even before `gpgme_check_version'.
     The features are identified by the following values for NAME:

[...]

    `"disable-gpgconf"'
          Using this feature with any VALUE disables the detection of
          the gpgconf program and thus forces GPGME to fallback into
          the simple OpenPGP only mode.  It may be used to force the
          use of GnuPG-1 on systems which have both GPG versions
          installed.  Note that in general the use of
          `gpgme_set_engine_info' is a better way to select a specific
          engine version.




Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From wk at gnupg.org  Fri Oct  3 16:35:52 2014
From: wk at gnupg.org (Werner Koch)
Date: Fri, 03 Oct 2014 16:35:52 +0200
Subject: [Announce] The maybe final Beta for GnuPG 2.1
Message-ID: <87sij5cjav.fsf@vigenere.g10code.de>

Hello!
    
I just released another *beta* version of GnuPG *2.1*.  It has been
released to give you the opportunity to check out new features and to
help fixing bugs.

  If you need a stable and fully maintained version of GnuPG,
  you should use version 2.0.26 or 1.4.18.

This version is marked as BETA and as such it should in general not be
used for real work.  However, the functionality is solid enough and thus
this may actually be the last beta before we release 2.1.0 some time
this year.


What's new in 2.1.0-beta864 since beta784
=========================================

 * gpg: Removed the GPG_AGENT_INFO related code.  GnuPG does now only
   use a fixed socket name in its home directory.

 * gpg: Renamed --gen-key to --full-gen-key and re-added a --gen-key
   command using less prompts.

 * gpg: Use SHA-256 for all signature types also on RSA keys.

 * gpg: Default keyring is now created with a .kbx suffix.

 * gpg: Add a shortcut to the key capabilies menu (e.g. "=e" sets the
   encryption capabilities).

 * gpg: Fixed obsolete options parsing.

 * speedo: Improved the quick build system.

 Already released with beta834:

 * 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.


Getting the Software
====================

GnuPG 2.1.0-beta864 is available at

 ftp://ftp.gnupg.org/gcrypt/gnupg/unstable/gnupg-2.1.0-beta864.tar.bz2
 ftp://ftp.gnupg.org/gcrypt/gnupg/unstable/gnupg-2.1.0-beta864.tar.bz2.sig

and soon on all mirrors <http://www.gnupg.org/mirrors.html>.

Please read the README file !


Checking the Integrity
======================

In order to check that the version of GnuPG which you are going to
install is an original and unmodified one, you can do it in one of
the following ways:

 * If you already have a trusted version of GnuPG installed, you
   can simply check the supplied signature.  For example to check the
   signature of the file gnupg-2.1.0-beta864.tar.bz2 you would use
   this command:

     gpg --verify gnupg-2.1.0-beta864.tar.bz2.sig

   Depending on your installation you may use "gpg2" instead of "gpg".
   This checks whether the signature file matches the source file.  You
   should see a message indicating that the signature is good and made
   by that signing key.  Make sure that you have the right key, either
   by checking the fingerprint of that key with other sources or by
   checking that the key has been signed by a trustworthy other key.
   Note, that you can retrieve the signing key using the command

     finger wk ,at' g10code.com

   or using a keyserver like

     gpg --keyserver keys.gnupg.net --recv-key 4F25E3B6

   The distribution key 4F25E3B6 is signed by the well known key:

     pub   dsa2048/1E42B367 2007-12-31 [expires: 2018-12-31]
     Key fingerprint = 8061 5870 F5BA D690 3336  86D0 F2AD 85AC 1E42 B367
     uid                  Werner Koch <wk at gnupg.org>

   Never use a GnuPG version you just downloaded to check the
   integrity of the source - use an existing GnuPG installation!


Building
========

GnuPG requires a couple of extra libraries, which need to be build and
installed before GnuPG.  The configure script will tell you about the
requirements.

You may try the Speedo system as an alternative build method:

  make -f build-aux/speedo.mk native INSTALL_PREFIX=/usr/local

This method downloads all required libraries and does a native build of
GnuPG to "/usr/local" (or to "PLAY/inst/" if you do not specify the
INSTALL_PREFIX).  Note that you need installation privileges on the
install directory, GNU make, and a decent Unix system.  Building for
Windows is in theory possible but has not been tested for this release.


Documentation
=============

The file gnupg.info has the complete user manual of the system.
Separate man pages are included as well; however they have not all the
details available in the manual.  It is also possible to read the
complete manual online in HTML format at

  https://www.gnupg.org/documentation/manuals/gnupg-devel/

The chapters on gpg-agent, gpg and gpgsm include information on how
to set up the whole thing.  You may also want search the GnuPG mailing
list archives or ask on the gnupg-users mailing lists for advise on
how to solve problems.  Many of the new features are around for
several years and thus enough public knowledge is already available.

Almost all mail clients support GnuPG-2.  Mutt users may want to use
the configure option "--enable-gpgme" during build time and put a "set
use_crypt_gpgme" in ~/.muttrc to enable S/MIME support along with the
reworked OpenPGP support.


Support
=======

Please consult the archive of the gnupg-users mailing list before
reporting a bug <https://gnupg.org/documentation/mailing-lists.html>.
We suggest to send bug reports for a new release to this list in favor
of filing a bug at <https://bugs.gnupg.org>.  We also have a dedicated
service directory at:

  https://www.gnupg.org/service.html

Maintaining and improving GnuPG is costly.  For more than a decade,
g10 Code GmbH, a German company owned and headed by GnuPG's principal
author Werner Koch, is bearing the majority of these costs.  To help
them carry on this work, they need your support.  See

  https://gnupg.org/donate/

For reasons why donating to free software projects is beneficial for
everyone, please read Poul-Henning Kamp's "Quality Software Costs Money
- Heartbleed Was Free" at https://queue.acm.org/detail.cfm?id=2636165 .


Thanks
======

We have to thank all the people who helped with this release, be it
testing, coding, translating, suggesting, auditing, administering the
servers, spreading the word, and answering questions on the mailing
lists.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 180 bytes
Desc: not available
URL: </pipermail/attachments/20141003/7e0751ed/attachment-0001.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From dkg at fifthhorseman.net  Fri Oct  3 18:52:11 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 03 Oct 2014 12:52:11 -0400
Subject: [PATCH] correct "trusted" to "valid" for trust-model always
In-Reply-To: <1398206775-23106-1-git-send-email-dkg@fifthhorseman.net>
References: <1398206775-23106-1-git-send-email-dkg@fifthhorseman.net>
Message-ID: <87tx3lt7t0.fsf@alice.fifthhorseman.net>

On Tue 2014-04-22 18:46:15 -0400, Daniel Kahn Gillmor wrote:
> With --trust-model=always, all keys and user IDs are considered
> automatically valid; they are not automatically trusted (setting
> universal ownertrust to anything other than "ultimate" would be
> insufficient to acheive the effect of --trust-model=always, due to
> --max-cert-depth and certificate path reachability).
>
> Thanks to Nicolai Josuttis for pointing out this documentation error.
> ---
>  doc/gpg.texi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/doc/gpg.texi b/doc/gpg.texi
> index 26179bd..8274da5 100644
> --- a/doc/gpg.texi
> +++ b/doc/gpg.texi
> @@ -1428,7 +1428,7 @@ Set what trust model GnuPG should follow. The models are:
>    @item always
>    @opindex trust-mode:always
>    Skip key validation and assume that used keys are always fully
> -  trusted. You generally won't use this unless you are using some
> +  valid. You generally won't use this unless you are using some
>    external validation scheme. This option also suppresses the
>    "[uncertain]" tag printed with signature checks when there is no
>    evidence that the user ID is bound to the key.
> -- 
> 1.9.2

Any followup on this?  This patch appears to be still unapplied on
STABLE-BRANCH-1-4, STABLE-BRANCH-2-0, and master.

                   --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: </pipermail/attachments/20141003/f058ab13/attachment.sig>

From dkg at fifthhorseman.net  Fri Oct  3 19:59:34 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri,  3 Oct 2014 13:59:34 -0400
Subject: [PATCH] gpg 2.0.x: Add build and runtime support for larger RSA keys
Message-ID: <1412359174-19670-1-git-send-email-dkg@fifthhorseman.net>

* configure.ac: Added --enable-large-secmem option.
* g10/options.h: Add opt.flags.large_rsa.
* g10/gpg.c: Contingent on configure option: adjust secmem size,
add gpg --enable-large-rsa, bound to opt.flags.large_rsa.
* g10/keygen.c: Adjust max RSA size based on opt.flags.large_rsa
* doc/gpg.texi: Document --enable-large-rsa.

--

This is a cherry-pick of 534e2876acc05f9f8d9b54c18511fe768d77dfb5 from
STABLE-BRANCH-1-4 against STABLE-BRANCH-2-0

Some older implementations built and used RSA keys up to 16Kib, but
the larger secret keys now fail when used by more recent GnuPG, due to
secure memory limitations.

Building with ./configure --enable-large-secmem will make gpg
capable of working with those secret keys, as well as permitting the
use of a new gpg option --enable-large-rsa, which let gpg generate RSA
keys up to 8Kib when used with --batch --gen-key.

Debian-bug-id: 739424

Minor edits by wk.

GnuPG-bug-id: 1732
---
 configure.ac  | 17 +++++++++++++++++
 doc/gpg.texi  |  9 +++++++++
 g10/gpg.c     | 22 +++++++++++++++++++++-
 g10/keygen.c  |  5 +++--
 g10/options.h |  1 +
 5 files changed, 51 insertions(+), 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index 7137e3f..3f83bdc 100644
--- a/configure.ac
+++ b/configure.ac
@@ -83,6 +83,7 @@ use_exec=yes
 disable_keyserver_path=no
 use_ccid_driver=yes
 use_standard_socket=no
+large_secmem=no
 
 GNUPG_BUILD_PROGRAM(gpg, yes)
 GNUPG_BUILD_PROGRAM(gpgsm, yes)
@@ -174,6 +175,22 @@ AC_ARG_ENABLE(selinux-support,
               selinux_support=$enableval, selinux_support=no)
 AC_MSG_RESULT($selinux_support)
 
+
+AC_MSG_CHECKING([whether to allocate extra secure memory])
+AC_ARG_ENABLE(large-secmem,
+              AC_HELP_STRING([--enable-large-secmem],
+                             [allocate extra secure memory]),
+              large_secmem=$enableval, large_secmem=no)
+AC_MSG_RESULT($large_secmem)
+if test "$large_secmem" = yes ; then
+   SECMEM_BUFFER_SIZE=65536
+else
+   SECMEM_BUFFER_SIZE=32768
+fi
+AC_DEFINE_UNQUOTED(SECMEM_BUFFER_SIZE,$SECMEM_BUFFER_SIZE,
+                   [Size of secure memory buffer])
+
+
 # Allow disabling of bzib2 support.
 # It is defined only after we confirm the library is available later
 AC_MSG_CHECKING([whether to enable the BZIP2 compression algorithm])
diff --git a/doc/gpg.texi b/doc/gpg.texi
index d66259e..b2c956e 100644
--- a/doc/gpg.texi
+++ b/doc/gpg.texi
@@ -1192,6 +1192,15 @@ the opposite meaning. The options are:
   validation. This option is only meaningful if pka-lookups is set.
 @end table
 
+ at item --enable-large-rsa
+ at itemx --disable-large-rsa
+ at opindex enable-large-rsa
+ at opindex disable-large-rsa
+With --gen-key and --batch, enable the creation of larger RSA secret
+keys than is generally recommended (up to 8192 bits).  These large
+keys are more expensive to use, and their signatures and
+certifications are also larger.
+
 @item --enable-dsa2
 @itemx --disable-dsa2
 @opindex enable-dsa2
diff --git a/g10/gpg.c b/g10/gpg.c
index a995796..576b88e 100644
--- a/g10/gpg.c
+++ b/g10/gpg.c
@@ -367,6 +367,8 @@ enum cmd_and_opt_values
     oAutoKeyLocate,
     oNoAutoKeyLocate,
     oAllowMultisigVerification,
+    oEnableLargeRSA,
+    oDisableLargeRSA,
     oEnableDSA2,
     oDisableDSA2,
     oAllowMultipleMessages,
@@ -736,6 +738,8 @@ static ARGPARSE_OPTS opts[] = {
 
   ARGPARSE_s_n (oAllowMultisigVerification,
                 "allow-multisig-verification", "@"),
+  ARGPARSE_s_n (oEnableLargeRSA, "enable-large-rsa", "@"),
+  ARGPARSE_s_n (oDisableLargeRSA, "disable-large-rsa", "@"),
   ARGPARSE_s_n (oEnableDSA2, "enable-dsa2", "@"),
   ARGPARSE_s_n (oDisableDSA2, "disable-dsa2", "@"),
   ARGPARSE_s_n (oAllowMultipleMessages,      "allow-multiple-messages", "@"),
@@ -2069,7 +2073,7 @@ main (int argc, char **argv)
 #endif
 
     /* Initialize the secure memory. */
-    if (!gcry_control (GCRYCTL_INIT_SECMEM, 32768, 0))
+    if (!gcry_control (GCRYCTL_INIT_SECMEM, SECMEM_BUFFER_SIZE, 0))
       got_secmem = 1;
 #if defined(HAVE_GETUID) && defined(HAVE_GETEUID)
     /* There should be no way to get to this spot while still carrying
@@ -2964,6 +2968,22 @@ main (int argc, char **argv)
 	    release_akl();
 	    break;
 
+	  case oEnableLargeRSA:
+#if SECMEM_BUFFER_SIZE >= 65536
+            opt.flags.large_rsa=1;
+#else
+            if (configname)
+              log_info("%s:%d: WARNING: gpg not built with large secure "
+                         "memory buffer.  Ignoring enable-large-rsa\n",
+                        configname,configlineno);
+            else
+              log_info("WARNING: gpg not built with large secure "
+                         "memory buffer.  Ignoring --enable-large-rsa\n");
+#endif /* SECMEM_BUFFER_SIZE >= 65536 */
+            break;
+	  case oDisableLargeRSA: opt.flags.large_rsa=0;
+            break;
+
 	  case oEnableDSA2: opt.flags.dsa2=1; break;
 	  case oDisableDSA2: opt.flags.dsa2=0; break;
 
diff --git a/g10/keygen.c b/g10/keygen.c
index 5841ad8..17fde7f 100644
--- a/g10/keygen.c
+++ b/g10/keygen.c
@@ -1431,6 +1431,7 @@ gen_rsa (int algo, unsigned nbits, KBNODE pub_root, KBNODE sec_root, DEK *dek,
   PKT_secret_key *sk;
   PKT_public_key *pk;
   gcry_sexp_t s_parms, s_key;
+  const unsigned maxsize = (opt.flags.large_rsa ? 8192 : 4096);
 
   assert (is_RSA(algo));
 
@@ -1442,9 +1443,9 @@ gen_rsa (int algo, unsigned nbits, KBNODE pub_root, KBNODE sec_root, DEK *dek,
       nbits = 2048;
       log_info (_("keysize invalid; using %u bits\n"), nbits );
     }
-  else if (nbits > 4096)
+  else if (nbits > maxsize)
     {
-      nbits = 4096;
+      nbits = maxsize;
       log_info (_("keysize invalid; using %u bits\n"), nbits );
     }
 
diff --git a/g10/options.h b/g10/options.h
index 1a13841..e9c540d 100644
--- a/g10/options.h
+++ b/g10/options.h
@@ -232,6 +232,7 @@ struct
     unsigned int dsa2:1;
     unsigned int allow_multiple_messages:1;
     unsigned int allow_weak_digest_algos:1;
+    unsigned int large_rsa:1;
   } flags;
 
   /* Linked list of ways to find a key if the key isn't on the local
-- 
2.1.0



From dkg at fifthhorseman.net  Fri Oct  3 20:13:14 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 03 Oct 2014 14:13:14 -0400
Subject: [PATCH] gpg 2.0.x: Add build and runtime support for
 larger RSA keys
In-Reply-To: <1412359174-19670-1-git-send-email-dkg@fifthhorseman.net>
References: <1412359174-19670-1-git-send-email-dkg@fifthhorseman.net>
Message-ID: <542EE73A.5060407@fifthhorseman.net>

On 10/03/2014 01:59 PM, Daniel Kahn Gillmor wrote:
> * configure.ac: Added --enable-large-secmem option.
> * g10/options.h: Add opt.flags.large_rsa.
> * g10/gpg.c: Contingent on configure option: adjust secmem size,
> add gpg --enable-large-rsa, bound to opt.flags.large_rsa.
> * g10/keygen.c: Adjust max RSA size based on opt.flags.large_rsa
> * doc/gpg.texi: Document --enable-large-rsa.
> 
> --
> 
> This is a cherry-pick of 534e2876acc05f9f8d9b54c18511fe768d77dfb5 from
> STABLE-BRANCH-1-4 against STABLE-BRANCH-2-0

This patch (or something like it) should probably be applied to the
2.0.x branch so that gpg.conf is option-for-option compatible with 1.4.x.

fwiw, using a modern amd64 system, i tried using a 16Kib RSA secret key
with debian's 2.0.26-3 gnupg2 package (without this patch) and did not
get an out-of-memory fatal alert, even though the same operation *does*
give a fatal alert with an unpatched 1.4.18 .

I think this means that gpg1 is using more secure memory for the same
operations, which means that the #if SECMEM_BUFFER_SIZE >= 65536 test is
as unprincipled as we expected it to be :)

So another option would be to just introduce --disable-large-rsa as a
no-op, and --enable-large-rsa as an obsolete option, and not adjust
configure.ac at all.  let me know if you'd like to see that patch instead.

I also note that this patchset only adjusts the secmem choices for
g10/gpg.c, but not for any of the following:

 * agent/gpg-agent.c (currently 32768)
 * agent/protect-tool.c (currently 16384)
 * scd/scdaemon.c (currently 16384)
 * sm/gpgsm.c (currently 16384)
 * tools/gpg-check-pattern.c (currently 4096(!))
 * tools/symcryptrun.c (currently 16384

Let me know what you think.

Once i see how it settles on the 2.0.x branch, and once i've imported
the latest 2.1.x beta for debian, i can take a look at applying these
something similar to master.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20141003/e1f278a9/attachment.sig>

From wk at gnupg.org  Fri Oct  3 20:20:25 2014
From: wk at gnupg.org (Werner Koch)
Date: Fri, 03 Oct 2014 20:20:25 +0200
Subject: [PATCH] correct "trusted" to "valid" for trust-model always
In-Reply-To: <87tx3lt7t0.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Fri, 03 Oct 2014 12:52:11 -0400")
References: <1398206775-23106-1-git-send-email-dkg@fifthhorseman.net>
 <87tx3lt7t0.fsf@alice.fifthhorseman.net>
Message-ID: <8738b5c8wm.fsf@vigenere.g10code.de>

On Fri,  3 Oct 2014 18:52, dkg at fifthhorseman.net said:

> Any followup on this?  This patch appears to be still unapplied on
> STABLE-BRANCH-1-4, STABLE-BRANCH-2-0, and master.

Just pushed to master and 1.4.  Will propagate to 2.0 with the next
release.

Thanks,

  Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From wk at gnupg.org  Fri Oct  3 20:22:55 2014
From: wk at gnupg.org (Werner Koch)
Date: Fri, 03 Oct 2014 20:22:55 +0200
Subject: [PATCH] gpg 2.0.x: Add build and runtime support for larger RSA
 keys
In-Reply-To: <1412359174-19670-1-git-send-email-dkg@fifthhorseman.net> (Daniel
 Kahn Gillmor's message of "Fri, 3 Oct 2014 13:59:34 -0400")
References: <1412359174-19670-1-git-send-email-dkg@fifthhorseman.net>
Message-ID: <87y4sxau80.fsf@vigenere.g10code.de>

On Fri,  3 Oct 2014 19:59, dkg at fifthhorseman.net said:
> This is a cherry-pick of 534e2876acc05f9f8d9b54c18511fe768d77dfb5 from
> STABLE-BRANCH-1-4 against STABLE-BRANCH-2-0

Thanks.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From alphazo at gmail.com  Mon Oct  6 17:38:16 2014
From: alphazo at gmail.com (Alphazo)
Date: Mon, 6 Oct 2014 17:38:16 +0200
Subject: Curve41417
Message-ID: <CAHJqNbwRuLgf=3rizbyrwHjhMfdix7R95K+FFGWJBAmF=RQNgw@mail.gmail.com>

Recently introduced Curve41417 from Daniel J. Bernstein (the one behind
Curve25519) seems appealing for long term security.

http://cr.yp.to/ecdh/curve41417-20140706.pdf

I guess it now needs to get reviewed before it gets adopted.

Alphazo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20141006/3d0926e3/attachment.html>

From dkg at fifthhorseman.net  Mon Oct  6 23:42:00 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 06 Oct 2014 17:42:00 -0400
Subject: [PATCH] gpg 2.0.x: Add build and runtime support for larger RSA
 keys
In-Reply-To: <87y4sxau80.fsf@vigenere.g10code.de>
References: <1412359174-19670-1-git-send-email-dkg@fifthhorseman.net>
 <87y4sxau80.fsf@vigenere.g10code.de>
Message-ID: <878uksub87.fsf@alice.fifthhorseman.net>

On Fri 2014-10-03 14:22:55 -0400, Werner Koch wrote:
> On Fri,  3 Oct 2014 19:59, dkg at fifthhorseman.net said:
>> This is a cherry-pick of 534e2876acc05f9f8d9b54c18511fe768d77dfb5 from
>> STABLE-BRANCH-1-4 against STABLE-BRANCH-2-0
>
> Thanks.

What do you think we should do about this for the master branch?

I can do the same cherry-pick (or a similar one) to the master branch if
you think that's the right thing to do.

    --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: </pipermail/attachments/20141006/08ed9bbe/attachment.sig>

From dkg at fifthhorseman.net  Tue Oct  7 01:27:50 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 06 Oct 2014 19:27:50 -0400
Subject: packaging dirmngr from 2.1.0
Message-ID: <8761fwu6bt.fsf@alice.fifthhorseman.net>

Hi GnuPG folks--

I'm still working on the debian experimental packaging for gnupg2's
2.1.0 beta, in particular on the dirmngr package.  I have some questions
about the transition to the dirmngr from 2.1.0, and what seems sensible
From an upstream perspective.  If any of these questions are more
complicated and need to wait for a later response, i'm happy to get the
easy answers first, and an "i'll deal with this later" for the others :)

 0) in the old dirmngr source, doc/examples/trusted-certs/ and
    doc/examples/extra-certs/ contained a bunch of X.509 certificates
    which we shipped in the debian package.  In the source for the 2.1.0
    beta, i only see doc/com-certs.pem and common/tls-ca.pem (and some
    test certs in tests/) -- should we be shipping any of these certs in
    debian or should we be relying instead on the operating system's
    ca-certificates package (or equivalent) ?

 1) The existing dirmngr 1.1.1 package provides a system service,
    running as the dedicated dirmngr user, listening on
    /var/run/dirmngr/socket.  The new one looks like it would run
    /var/run/gnupg2/S.dirmngr.  Is the system service something that you
    expect to be used in general, or should users just run their own
    dirmngr instances?

 2) Whether the system service is relevant or not, it seems like it
    would be useful (at least on linux-based systems) to enable it to be
    handed its listening socket at runtime (e.g. systemd socket-based
    activation, either for system-level services, or for user services).
    Would you be interested in patches that provide socket-handoff at
    runtime?  (i'm imagining something like "dirmngr --listen-fd 4")

 3) it looks like dirmngr has taken over all keyserver interactions,
    which is nice.  But the old keyserver interaction mechanism was
    extensible with drop-in programs
    (e.g. /usr/lib/gnupg2/gpg2keys_whatever).  Is there a way to provide
    similar extensibility to the new dirmngr?  I see
    /usr/lib/gnupg2/dirmngr_ldap, but is there a specification for how
    one can write sometihng similar for other transports?

 4) I'm trying to generate dirmngr.info from doc/dirmngr.texi, but
    having trouble doing so.  "(cd doc && make dirmngr.info)" results in
    a long list of texinfo complaints.  Should we be shipping an info
    file for dirmngr, or are the man pages (dirmngr.8 and
    dirmngr-client.1) sufficient and complete?  If we should ship a
    .info file, how should i build it?

 5) The new dirmngr deliberately fails if /etc/dirmngr/ exists (even for
    non-privileged users running dirmngr on their own).  This makes a
    transition from the old package to the new package difficult, since
    it's possible that config files from the older package are still
    present.  Can this check be relaxed to a warning?

 6) logging by default seems to go to /var/log/dirmngr/dirmngr.log, but
    can be reset with --log-file -- but most uses don't have write
    access to /var/log/dirmngr/dirmngr.log (and we probably wouldn't
    want them to).  I'm inclined to make it default to logging to
    stderr, and then people who prefer to override the logging (e.g. in
    a system service file, or whatever) can do so explicitly.  Does this
    sound reasonable?
 
Sorry if i've missed any obvious answers.  Pointers are welcome!

Regards,

    --dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: </pipermail/attachments/20141006/e0715a08/attachment-0001.sig>

From eric at debian.org  Tue Oct  7 05:37:49 2014
From: eric at debian.org (Eric Dorland)
Date: Mon, 6 Oct 2014 23:37:49 -0400
Subject: [Pkg-gnupg-maint] packaging dirmngr from 2.1.0
In-Reply-To: <8761fwu6bt.fsf@alice.fifthhorseman.net>
References: <8761fwu6bt.fsf@alice.fifthhorseman.net>
Message-ID: <20141007033749.GO24040@gambit>

* Daniel Kahn Gillmor (dkg at fifthhorseman.net) wrote:
> Hi GnuPG folks--
> 
> I'm still working on the debian experimental packaging for gnupg2's
> 2.1.0 beta, in particular on the dirmngr package.  I have some questions
> about the transition to the dirmngr from 2.1.0, and what seems sensible
> From an upstream perspective.  If any of these questions are more
> complicated and need to wait for a later response, i'm happy to get the
> easy answers first, and an "i'll deal with this later" for the others :)
> 
>  0) in the old dirmngr source, doc/examples/trusted-certs/ and
>     doc/examples/extra-certs/ contained a bunch of X.509 certificates
>     which we shipped in the debian package.  In the source for the 2.1.0
>     beta, i only see doc/com-certs.pem and common/tls-ca.pem (and some
>     test certs in tests/) -- should we be shipping any of these certs in
>     debian or should we be relying instead on the operating system's
>     ca-certificates package (or equivalent) ?

Seems like it would be obviously bad to use anything other than the
system certs?
 
>  1) The existing dirmngr 1.1.1 package provides a system service,
>     running as the dedicated dirmngr user, listening on
>     /var/run/dirmngr/socket.  The new one looks like it would run
>     /var/run/gnupg2/S.dirmngr.  Is the system service something that you
>     expect to be used in general, or should users just run their own
>     dirmngr instances?

Are we sure that there are no other users of dirmngr that this change
will break?

>  2) Whether the system service is relevant or not, it seems like it
>     would be useful (at least on linux-based systems) to enable it to be
>     handed its listening socket at runtime (e.g. systemd socket-based
>     activation, either for system-level services, or for user services).
>     Would you be interested in patches that provide socket-handoff at
>     runtime?  (i'm imagining something like "dirmngr --listen-fd 4")

+1, although does it need to run continuously to keep CRLs up to date?
Does socket activation allow for that?

>  3) it looks like dirmngr has taken over all keyserver interactions,
>     which is nice.  But the old keyserver interaction mechanism was
>     extensible with drop-in programs
>     (e.g. /usr/lib/gnupg2/gpg2keys_whatever).  Is there a way to provide
>     similar extensibility to the new dirmngr?  I see
>     /usr/lib/gnupg2/dirmngr_ldap, but is there a specification for how
>     one can write sometihng similar for other transports?
> 
>  4) I'm trying to generate dirmngr.info from doc/dirmngr.texi, but
>     having trouble doing so.  "(cd doc && make dirmngr.info)" results in
>     a long list of texinfo complaints.  Should we be shipping an info
>     file for dirmngr, or are the man pages (dirmngr.8 and
>     dirmngr-client.1) sufficient and complete?  If we should ship a
>     .info file, how should i build it?
> 
>  5) The new dirmngr deliberately fails if /etc/dirmngr/ exists (even for
>     non-privileged users running dirmngr on their own).  This makes a
>     transition from the old package to the new package difficult, since
>     it's possible that config files from the older package are still
>     present.  Can this check be relaxed to a warning?

Are those config files no longer used in the newer version?

>  6) logging by default seems to go to /var/log/dirmngr/dirmngr.log, but
>     can be reset with --log-file -- but most uses don't have write
>     access to /var/log/dirmngr/dirmngr.log (and we probably wouldn't
>     want them to).  I'm inclined to make it default to logging to
>     stderr, and then people who prefer to override the logging (e.g. in
>     a system service file, or whatever) can do so explicitly.  Does this
>     sound reasonable?
>  
> Sorry if i've missed any obvious answers.  Pointers are welcome!
> 
> Regards,
> 
>     --dkg
> 



> _______________________________________________
> Pkg-gnupg-maint mailing list
> Pkg-gnupg-maint at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-gnupg-maint


-- 
Eric Dorland <eric at kuroneko.ca>
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: </pipermail/attachments/20141006/452ee54a/attachment.sig>

From dkg at fifthhorseman.net  Tue Oct  7 08:52:03 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 07 Oct 2014 02:52:03 -0400
Subject: [Pkg-gnupg-maint] packaging dirmngr from 2.1.0
In-Reply-To: <20141007033749.GO24040@gambit>
References: <8761fwu6bt.fsf@alice.fifthhorseman.net>
 <20141007033749.GO24040@gambit>
Message-ID: <54338D93.2070605@fifthhorseman.net>

Hi Eric--

On 10/06/2014 11:37 PM, Eric Dorland wrote:
> * Daniel Kahn Gillmor (dkg at fifthhorseman.net) wrote:
>>  0) in the old dirmngr source, doc/examples/trusted-certs/ and
>>     doc/examples/extra-certs/ contained a bunch of X.509 certificates
>>     which we shipped in the debian package.  In the source for the 2.1.0
>>     beta, i only see doc/com-certs.pem and common/tls-ca.pem (and some
>>     test certs in tests/) -- should we be shipping any of these certs in
>>     debian or should we be relying instead on the operating system's
>>     ca-certificates package (or equivalent) ?
> 
> Seems like it would be obviously bad to use anything other than the
> system certs?

It would be good to know from upstream whether there is any expectation
of built-in certs, specific formats desired/needed, etc.

>>  1) The existing dirmngr 1.1.1 package provides a system service,
>>     running as the dedicated dirmngr user, listening on
>>     /var/run/dirmngr/socket.  The new one looks like it would run
>>     /var/run/gnupg2/S.dirmngr.  Is the system service something that you
>>     expect to be used in general, or should users just run their own
>>     dirmngr instances?
> 
> Are we sure that there are no other users of dirmngr that this change
> will break?

0 dkg at alice:~$ apt-cache rdepends dirmngr
dirmngr
Reverse Depends:
  gpgsm
  dirmngr:i386
  kleopatra
  gpgsm
0 dkg at alice:~$

So the only package outside of gnupg2 that we need to think about is
kleopatra.  I don't think that kleopatra depends on the system service
-- looking at the kdepim source code, it appears to try to invoke
dirmngr on its own, directly, rather than looking for a system socket.

>>  2) Whether the system service is relevant or not, it seems like it
>>     would be useful (at least on linux-based systems) to enable it to be
>>     handed its listening socket at runtime (e.g. systemd socket-based
>>     activation, either for system-level services, or for user services).
>>     Would you be interested in patches that provide socket-handoff at
>>     runtime?  (i'm imagining something like "dirmngr --listen-fd 4")
> 
> +1, although does it need to run continuously to keep CRLs up to date?
> Does socket activation allow for that?

the idea behind socket activation is that the service doesn't need to be
started until someone actually queries it.

But once queried, it can persist and keep doing whatever it needs to do
in the background (like checking CRLs).

>>  5) The new dirmngr deliberately fails if /etc/dirmngr/ exists (even for
>>     non-privileged users running dirmngr on their own).  This makes a
>>     transition from the old package to the new package difficult, since
>>     it's possible that config files from the older package are still
>>     present.  Can this check be relaxed to a warning?
> 
> Are those config files no longer used in the newer version?

Those config files are now moved to /etc/gnupg2/ instead of
/etc/dirmngr/, but by default i don't know that they need to be present
at all.  However, if they aren't present, the dirmngr system service
does complain about the lack of /etc/gnupg2/ldapservers.conf

For simplicity, i'm considering setting up the experimental dirmngr
package to not have the system service at all, since it makes the
packaging simpler and clearer.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20141007/69aaacfb/attachment.sig>

From wk at gnupg.org  Tue Oct  7 09:27:11 2014
From: wk at gnupg.org (Werner Koch)
Date: Tue, 07 Oct 2014 09:27:11 +0200
Subject: packaging dirmngr from 2.1.0
In-Reply-To: <8761fwu6bt.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Mon, 06 Oct 2014 19:27:50 -0400")
References: <8761fwu6bt.fsf@alice.fifthhorseman.net>
Message-ID: <87zjd89w6o.fsf@vigenere.g10code.de>

On Tue,  7 Oct 2014 01:27, dkg at fifthhorseman.net said:

>  0) in the old dirmngr source, doc/examples/trusted-certs/ and
>     doc/examples/extra-certs/ contained a bunch of X.509 certificates
>     which we shipped in the debian package.  In the source for the 2.1.0
>     beta, i only see doc/com-certs.pem and common/tls-ca.pem (and some
>     test certs in tests/) -- should we be shipping any of these certs in
>     debian or should we be relying instead on the operating system's
>     ca-certificates package (or equivalent) ?

Most of the certificates in com-certs.pem are expired and thus useless.
I will remove most of them for the release anyway.  However I have no
problems to replace that with a mechanism to use the standard CA
certificate bundle.  The original idea by a customer of mine was to be
able to setup a dedicated list of CAs so not not be vulnerable to the
X.509 mess.  Those certificates are automatically installed by gpgsm and
dirmngr falls back to them (for CRLs) if it can't find a trusted
certificate in its own store.  (I like to keep the ca-cert, though ;-).

tls-ca.pem has the root certificate for the hkps keyservers and it
should actually be used by default.  As of now it needs to be explicitly
set using the --hkp-cacert option.  Given that there is some strict
control over the hkps server pool I consider the use of a dedicated
certificate here useful.

>  1) The existing dirmngr 1.1.1 package provides a system service,
>     running as the dedicated dirmngr user, listening on
>     /var/run/dirmngr/socket.  The new one looks like it would run
>     /var/run/gnupg2/S.dirmngr.  Is the system service something that you
>     expect to be used in general, or should users just run their own
>     dirmngr instances?

I would like to get rid of the system service at all but it might be
useful in some rare palces (Squid CRL checking).  The idea for the
design was to avoid the overhead of downloading CRLs for each user and
instead use a system service.  However, multi-user machines used for
trusted communications are a bad idea anyway.

The default shall be the on-demand started dirmngr as a user service
similar to gpg-agent  (using ~/.gnupg/S.dirmgr).

>  2) Whether the system service is relevant or not, it seems like it
>     would be useful (at least on linux-based systems) to enable it to be
>     handed its listening socket at runtime (e.g. systemd socket-based
>     activation, either for system-level services, or for user services).
>     Would you be interested in patches that provide socket-handoff at
>     runtime?  (i'm imagining something like "dirmngr --listen-fd 4")

(You better don't ask me about helping systemd; I like Unix too much)

>  3) it looks like dirmngr has taken over all keyserver interactions,
>     which is nice.  But the old keyserver interaction mechanism was
>     extensible with drop-in programs
>     (e.g. /usr/lib/gnupg2/gpg2keys_whatever).  Is there a way to provide
>     similar extensibility to the new dirmngr?  I see
>     /usr/lib/gnupg2/dirmngr_ldap, but is there a specification for how
>     one can write sometihng similar for other transports?

No.  There is an internal API in dirmngr which should make it easy to
add new helpers.  But dlopening stuff is too troublesome to maintain and
I am glad that we don't need that anymore in GnuPG.  I know that for
Debian it would be easier if users could add there plugins instead of
waiting for the next Debian release.  But from my experience any plugin
system is really troublesome.  I can offer to host a Debian package of
the latest dirmngr at gnupg.org but there is the backports repo anyway.

>  4) I'm trying to generate dirmngr.info from doc/dirmngr.texi, but
>     having trouble doing so.  "(cd doc && make dirmngr.info)" results in
>     a long list of texinfo complaints.  Should we be shipping an info
>     file for dirmngr, or are the man pages (dirmngr.8 and
>     dirmngr-client.1) sufficient and complete?  If we should ship a
>     .info file, how should i build it?

You need to write a wrapper texti like what we did for gnupg-1.  I would
suggest to go wityh just the man pagaes.  If there is something missing
we can easily extract more stuff from the texi file.

>  5) The new dirmngr deliberately fails if /etc/dirmngr/ exists (even for
>     non-privileged users running dirmngr on their own).  This makes a
>     transition from the old package to the new package difficult, since
>     it's possible that config files from the older package are still
>     present.  Can this check be relaxed to a warning?

IIRC, this is so that the main functionality of the new dirmngr
(keyserver access) is not harmed.  But it is a warning anyway:

  if (!access ("/etc/"DIRMNGR_NAME, F_OK) && !strncmp (opt.homedir, "/etc/", 5))
    log_info
      ("NOTE: DirMngr is now a proper part of %s.  The configuration and"
       " other directory names changed.  Please check that no other version"
       " of dirmngr is still installed.  To disable this warning, remove the"
       " directory '/etc/dirmngr'.\n", GNUPG_NAME);

or did I miss something?

>  6) logging by default seems to go to /var/log/dirmngr/dirmngr.log, but
>     can be reset with --log-file -- but most uses don't have write
>     access to /var/log/dirmngr/dirmngr.log (and we probably wouldn't
>     want them to).  I'm inclined to make it default to logging to
>     stderr, and then people who prefer to override the logging (e.g. in
>     a system service file, or whatever) can do so explicitly.  Does this
>     sound reasonable?

I can't see that a log file is used by default, thus any logging should
already go to stderr.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From wk at gnupg.org  Tue Oct  7 09:31:46 2014
From: wk at gnupg.org (Werner Koch)
Date: Tue, 07 Oct 2014 09:31:46 +0200
Subject: [Pkg-gnupg-maint] packaging dirmngr from 2.1.0
In-Reply-To: <20141007033749.GO24040@gambit> (Eric Dorland's message of "Mon, 
 6 Oct 2014 23:37:49 -0400")
References: <8761fwu6bt.fsf@alice.fifthhorseman.net>
 <20141007033749.GO24040@gambit>
Message-ID: <87vbnw9vz1.fsf@vigenere.g10code.de>

On Tue,  7 Oct 2014 05:37, eric at debian.org said:

> +1, although does it need to run continuously to keep CRLs up to date?
> Does socket activation allow for that?

No, there is no need for it.  The CRLs are downloaded, verified, and
stored in a cache file as needed.  Timestamps are used to check whether
an update is required. 

It would save us a lot of trouble if we could do with a per-user
dirmngr.

>  5) The new dirmngr deliberately fails if /etc/dirmngr/ exists (even for
>>     non-privileged users running dirmngr on their own).  This makes a
>>     transition from the old package to the new package difficult, since
>>     it's possible that config files from the older package are still
>>     present.  Can this check be relaxed to a warning?
>
> Are those config files no longer used in the newer version?

Not from this directory.  But the old config file themself should still
work.  Thus a symlink to /etc/gnupg would do.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From dkg at fifthhorseman.net  Tue Oct  7 20:54:19 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 07 Oct 2014 14:54:19 -0400
Subject: 2.1.0~beta864 bugfixes [was: re: packaging dirmngr from 2.1.0]
In-Reply-To: <20141007180653.GP24040@gambit>
References: <8761fwu6bt.fsf@alice.fifthhorseman.net>
 <20141007033749.GO24040@gambit> <87vbnw9vz1.fsf@vigenere.g10code.de>
 <5433FF51.5080405@fifthhorseman.net> <20141007180653.GP24040@gambit>
Message-ID: <543436DB.7090406@fifthhorseman.net>

[readding gnupg-devel, since these are upstream-relevant questions]

On 10/07/2014 02:06 PM, Eric Dorland wrote:

> Did the upgrading to keybox [get fixed]?

The originally-reported problem (creating ~/.gnupg/pubring.gpg as a
keybox format) is fixed -- new keyrings created by gpg2 (2.1.x) are
created as ~/.gnupg/pubring.kbx instead.

I just discovered a new problem, though, which will affect people on
systems that have gpg and gpg2 coinstalled:

 0) create a new keyring with gpg2, and use it exclusively with gpg2 for
a while.
 1) somehow (accidentally?) use gpg (1.4.x) again -- this creates
~/.gnupg/pubring.gpg
 2) future runs of gpg2 now only look at pubring.gpg and ignore
pubring.kbx -- the keys you had accumulated in the keybox are no longer
listed in the output of gpg2 --list-keys

Not sure what the right thing to do about this is.  Would it be possible
for gpg2 to work by default with the union of both ~/.gnupg/pubring.gpg
and ~/.gnupg/pubring.kbx where they exist?

Or should gpg2 default to using .kbx when the .gpg file exists?

> [Did the] gnupg-agent problems get fixed?

upgrading gpg-agent:

gpg-agent-related code in 2.1.0~beta864 appears to always use the
standard socket by default (~/.gnupg/S.gpg-agent) and ignores
$GPG_AGENT_INFO.

This means that if you were running gpg-agent from 2.0.26, and finding
its socket with $GPG_AGENT_INFO (e.g. how the current session scripts
work), then invocations from gpg 2.1 will notice that the "standard
socket" isn't in use, and will launch their own gpg-agent, so you'll
have both of them running in parallel.  This is suboptimal, but probably
not a terrible outcome.

If the old gpg-agent was listning on the standard socket in the first
place, then invocations of the gpg 2.1.0 beta that need access to the
newer agent will fail with the following message:


0 foo at alice:~$ gpg2 --list-secret-keys
gpg: starting migration from earlier GnuPG versions
gpg: error: GnuPG agent version "2.0.26" is too old.
gpg: Please install an updated GnuPG agent.
gpg: migration aborted
2 foo at alice:~$

This happens even though the updated agent is *installed*, but it just
happens to not be running.  The wording is slightly misleading, but the
problem should go away after a reboot (or just after a restart of the
user's session)

I'm also a little bit concerned that gpg 1.4.x will *not* try to start
up a gpg-agent by default if it does not find one running, which means
effectively that we still need to launch a gpg-agent during X11 session
startup when use-agent is set, just to be sure that gpg1 users have a
functional agent.

-------

I know the above problems are transitional problems, and won't crop up
for users who have moved entirely to gpg 2.1.0.  This transitional work
is the cost of supporting multiple versions simultaneously, though, and
we seem to be committed to doing that, at least in the jessie timeframe,
so we need to get at least the dual keyring issue 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: </pipermail/attachments/20141007/93b01f1e/attachment-0001.sig>

From kristian.fiskerstrand at sumptuouscapital.com  Tue Oct  7 20:50:29 2014
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Tue, 07 Oct 2014 20:50:29 +0200
Subject: [PATCH] doc: gpg-agent: Add missing entry for allow-preset-passphase
Message-ID: <543435F5.2070908@sumptuouscapital.com>

Please find enclosed a patch for missing entry of allow-preset-passphase
in man page.

-- 
----------------------------
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
----------------------------
"Be a yardstick of quality. Some people aren't used to an environment
where excellence is expected."
(Steve Jobs)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-doc-gpg-agent-Add-missing-entry-for-allow-preset-pas.patch
Type: text/x-patch
Size: 1006 bytes
Desc: not available
URL: </pipermail/attachments/20141007/7835311c/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20141007/7835311c/attachment.sig>

From wk at gnupg.org  Tue Oct  7 22:27:30 2014
From: wk at gnupg.org (Werner Koch)
Date: Tue, 07 Oct 2014 22:27:30 +0200
Subject: 2.1.0~beta864 bugfixes
In-Reply-To: <543436DB.7090406@fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Tue, 07 Oct 2014 14:54:19 -0400")
References: <8761fwu6bt.fsf@alice.fifthhorseman.net>
 <20141007033749.GO24040@gambit> <87vbnw9vz1.fsf@vigenere.g10code.de>
 <5433FF51.5080405@fifthhorseman.net> <20141007180653.GP24040@gambit>
 <543436DB.7090406@fifthhorseman.net>
Message-ID: <87h9zfaaml.fsf@vigenere.g10code.de>

On Tue,  7 Oct 2014 20:54, dkg at fifthhorseman.net said:

>  2) future runs of gpg2 now only look at pubring.gpg and ignore
> pubring.kbx -- the keys you had accumulated in the keybox are no longer
> listed in the output of gpg2 --list-keys

Aihh, that should not happen.  I need to think about a strategy for
this.  The problem is that pubring.kbx has always been used by gpgsm and
and it is quite legal to have a pubring.gpg for gpg.  An idea is to add
a flag to the Keybox header indicating that OpenPGP keys are available.



Shalom-Salam,

   Werner


p.s
I am mostly offline this week, thus please have some patience.

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From dkg at fifthhorseman.net  Wed Oct  8 09:05:43 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 08 Oct 2014 03:05:43 -0400
Subject: g13 status [was: Re: 2.1.0beta3 missing man pages?]
In-Reply-To: <878vj35yar.fsf@vigenere.g10code.de>
References: <4F6040CD.5050003@fifthhorseman.net>
 <878vj35yar.fsf@vigenere.g10code.de>
Message-ID: <87wq8brqgo.fsf@alice.fifthhorseman.net>

[replying to an old thread]

On Wed 2012-03-14 05:27:04 -0400, Werner Koch wrote:
> On Wed, 14 Mar 2012 07:55, dkg at fifthhorseman.net said:
>>  g13
>
> Don't install it, it is currently not very useful.

Is g13 still something we shouldn't include in the debian packages, or
has it become useful enough to ship?

   --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: </pipermail/attachments/20141008/de8814b6/attachment.sig>

From dkg at fifthhorseman.net  Wed Oct  8 09:12:51 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed,  8 Oct 2014 03:12:51 -0400
Subject: [PATCH] Avoid unnecessary library linkage
Message-ID: <1412752371-7986-1-git-send-email-dkg@fifthhorseman.net>

dirmngr/Makefile.am: avoid $(DNSLIBS) for dirmngr_ldap
g10/Makefile.am: $(LIBREADLINE) is only for gpg2;
   gpgv2 does not need $(LIBASSUAN_LIBS)
sm/Makefile.am: gpgsm does not need $(ZLIBS)
tools/Makefile.am: gpgconf does not need $(NPTH_LIBS)

--

In the course of building GnuPG 2.1.0 beta864 on debian, i found that
several of the installed executables were linked to libraries that
they did not need to be linked to, which would cause unnecessary
package dependencies at runtime.

The changeset here removes these unnecessary libraries from linking.

Something similar could possibly also be done by passing --as-needed
to the linker, but trimming the depenencies seems more parsimonious.
---
 dirmngr/Makefile.am | 2 +-
 g10/Makefile.am     | 6 +++---
 sm/Makefile.am      | 2 +-
 tools/Makefile.am   | 2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/dirmngr/Makefile.am b/dirmngr/Makefile.am
index d0226a3..632e525 100644
--- a/dirmngr/Makefile.am
+++ b/dirmngr/Makefile.am
@@ -73,7 +73,7 @@ if USE_LDAPWRAPPER
 dirmngr_ldap_SOURCES = dirmngr_ldap.c $(ldap_url)
 dirmngr_ldap_CFLAGS = $(GPG_ERROR_CFLAGS) $(LIBGCRYPT_CFLAGS)
 dirmngr_ldap_LDFLAGS =
-dirmngr_ldap_LDADD = $(libcommon) no-libgcrypt.o ../gl/libgnu.a $(DNSLIBS) \
+dirmngr_ldap_LDADD = $(libcommon) no-libgcrypt.o ../gl/libgnu.a \
 		     $(GPG_ERROR_LIBS) $(LDAPLIBS) $(LBER_LIBS) $(LIBINTL) \
 		     $(LIBICONV)
 endif
diff --git a/g10/Makefile.am b/g10/Makefile.am
index 6fa7a5c..d0343fa 100644
--- a/g10/Makefile.am
+++ b/g10/Makefile.am
@@ -138,14 +138,14 @@ gpgv2_SOURCES = gpgv.c           \
 # here, even that it is not used by gpg.  A proper solution would
 # either to split up libkeybox.a or to use a separate keybox daemon.
 LDADD =  $(needed_libs) ../common/libgpgrl.a \
-         $(ZLIBS) $(DNSLIBS) $(LIBREADLINE) \
+         $(ZLIBS) $(DNSLIBS) \
          $(LIBINTL) $(CAPLIBS) $(NETLIBS)
-gpg2_LDADD = $(LDADD) $(LIBGCRYPT_LIBS) \
+gpg2_LDADD = $(LDADD) $(LIBGCRYPT_LIBS) $(LIBREADLINE) \
              $(KSBA_LIBS) $(LIBASSUAN_LIBS) $(GPG_ERROR_LIBS) \
 	     $(LIBICONV) $(resource_objs) $(extra_sys_libs)
 gpg2_LDFLAGS = $(extra_bin_ldflags)
 gpgv2_LDADD = $(LDADD) $(LIBGCRYPT_LIBS) \
-              $(KSBA_LIBS) $(LIBASSUAN_LIBS) $(GPG_ERROR_LIBS) \
+              $(KSBA_LIBS) $(GPG_ERROR_LIBS) \
 	      $(LIBICONV) $(resource_objs) $(extra_sys_libs)
 gpgv2_LDFLAGS = $(extra_bin_ldflags)
 
diff --git a/sm/Makefile.am b/sm/Makefile.am
index 7fff752..12b85ab 100644
--- a/sm/Makefile.am
+++ b/sm/Makefile.am
@@ -61,7 +61,7 @@ common_libs = ../kbx/libkeybox.a $(libcommon) ../gl/libgnu.a
 
 gpgsm_LDADD = $(common_libs) ../common/libgpgrl.a \
               $(LIBGCRYPT_LIBS) $(KSBA_LIBS) $(LIBASSUAN_LIBS) \
-              $(GPG_ERROR_LIBS) $(LIBREADLINE) $(LIBINTL) $(ZLIBS) \
+              $(GPG_ERROR_LIBS) $(LIBREADLINE) $(LIBINTL) \
 	      $(LIBICONV) $(resource_objs) $(extra_sys_libs)
 gpgsm_LDFLAGS = $(extra_bin_ldflags)
 
diff --git a/tools/Makefile.am b/tools/Makefile.am
index 946ae4a..340901a 100644
--- a/tools/Makefile.am
+++ b/tools/Makefile.am
@@ -98,7 +98,7 @@ gpgconf_SOURCES = gpgconf.c gpgconf.h gpgconf-comp.c no-libgcrypt.c
 # common sucks in gpg-error, will they, nil they (some compilers
 # do not eliminate the supposed-to-be-unused-inline-functions).
 gpgconf_LDADD = $(maybe_commonpth_libs) $(opt_libassuan_libs) \
-                $(LIBINTL) $(GPG_ERROR_LIBS) $(NPTH_LIBS) $(NETLIBS) \
+                $(LIBINTL) $(GPG_ERROR_LIBS) $(NETLIBS) \
 	        $(LIBICONV) $(W32SOCKLIBS)
 gpgconf_LDFLAGS = $(extra_bin_ldflags)
 
-- 
2.1.1



From wk at gnupg.org  Wed Oct  8 09:47:35 2014
From: wk at gnupg.org (Werner Koch)
Date: Wed, 08 Oct 2014 09:47:35 +0200
Subject: g13 status
In-Reply-To: <87wq8brqgo.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Wed, 08 Oct 2014 03:05:43 -0400")
References: <4F6040CD.5050003@fifthhorseman.net>
 <878vj35yar.fsf@vigenere.g10code.de>
 <87wq8brqgo.fsf@alice.fifthhorseman.net>
Message-ID: <87a9579f54.fsf@vigenere.g10code.de>

On Wed,  8 Oct 2014 09:05, dkg at fifthhorseman.net said:

> Is g13 still something we shouldn't include in the debian packages, or
> has it become useful enough to ship?

No.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From dkg at fifthhorseman.net  Wed Oct  8 20:47:47 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 08 Oct 2014 14:47:47 -0400
Subject: 2.1.0~beta864: gpg2 --list-secret-keys fails if gniibe's key is in
 pubring.kbx
Message-ID: <871tqi2yb0.fsf@alice.fifthhorseman.net>

Hi GnuPG folks--

i'm trying to use 2.1.0 beta864.  gpg2 --list-secret-keys fails (returns
a non-zero return code) if any of the *public* keys it knows about fail
to have a proper keygrip.

Gniibe's key has such a subkey (for some reason i don't understand).

This means that anyone who has gniibe's key in their pubring won't be
able to get gpg2 --list-secret-keys to return a non-zero error.

Enigmail apparently regularly does gpg --list-secret-keys in the
background before sending signed mail, and returns an error if the
process terminates abnormally.

This means that anyone with gniibe's key in their public keyring can't
sign messages in enigmail.

Below is a transcript of the problem, from a clean slate.  the numbers
before the shell prompt are the return code of the previous invocation.

Its also worth noting that the output of --with-keygrip appears to
publish something that changes each time it's run -- this may be an
information leak of memory that isn't properly initialized or cleared.

       --dkg


0 demo at saturn:~$ rm -rf .gnupg
0 demo at saturn:~$ gpg2 --list-secret-keys
gpg: directory '/home/demo/.gnupg' created
gpg: new configuration file '/home/demo/.gnupg/gpg.conf' created
gpg: WARNING: options in '/home/demo/.gnupg/gpg.conf' are not yet active during this run
gpg: keybox '/home/demo/.gnupg/pubring.kbx' created
gpg: /home/demo/.gnupg/trustdb.gpg: trustdb created
0 demo at saturn:~$ gpg2 --list-secret-keys
0 demo at saturn:~$ gpg2 --recv 124124BD3B4862AF7A0A42F100B45EBD4CA7BABE
gpg: key 4CA7BABE: public key "NIIBE Yutaka <gniibe at fsij.org>" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
0 demo at saturn:~$ gpg2 --list-secret-keys
gpg: error computing keygrip
2 demo at saturn:~$ gpg2 --list-keys --with-keygrip
gpg: error computing keygrip
/home/demo/.gnupg/pubring.kbx
------------------------------
pub   rsa2048/4CA7BABE 2010-10-15
      Keygrip = 101DE7B639FE29F4636BDEECF442A9273AFA6565
uid       [ unknown] NIIBE Yutaka <gniibe at fsij.org>
uid       [ unknown] NIIBE Yutaka <gniibe at debian.org>
sub   secp256k1/975B9053 2014-01-16 secp256k1
      Keygrip = 00000000000000000000000000000000A0021C13
sub   rsa2048/084239CF 2010-10-15
      Keygrip = 65F67E742101C7FE6D5B33FCEFCF4F65EAF0688C
sub   rsa2048/5BB065DC 2010-10-22
      Keygrip = 5D6C89682D07CCFC034AF508420BF2276D8018ED

2 demo at saturn:~$ gpg2 --list-keys --with-keygrip
gpg: error computing keygrip
/home/demo/.gnupg/pubring.kbx
------------------------------
pub   rsa2048/4CA7BABE 2010-10-15
      Keygrip = 101DE7B639FE29F4636BDEECF442A9273AFA6565
uid       [ unknown] NIIBE Yutaka <gniibe at fsij.org>
uid       [ unknown] NIIBE Yutaka <gniibe at debian.org>
sub   secp256k1/975B9053 2014-01-16 secp256k1
      Keygrip = 00000000000000000000000000000000A0A26DAD
sub   rsa2048/084239CF 2010-10-15
      Keygrip = 65F67E742101C7FE6D5B33FCEFCF4F65EAF0688C
sub   rsa2048/5BB065DC 2010-10-22
      Keygrip = 5D6C89682D07CCFC034AF508420BF2276D8018ED

2 demo at saturn:~$  diff -u <(gpg2 --with-colons --list-keys --with-keygrip)  <(gpg2 --with-colons --list-keys --with-keygrip)
gpg: gpg: error computing keygrip
error computing keygrip
--- /dev/fd/63	2014-10-08 14:43:27.084783772 -0400
+++ /dev/fd/62	2014-10-08 14:43:27.084783772 -0400
@@ -4,7 +4,7 @@
 uid:-::::1290131210::95E10B8292AEC7A07277EBF8853FF9C6647CAAEB::NIIBE Yutaka <gniibe at fsij.org>:
 uid:-::::1290130668::449322114961C0A907E070744D791FEF23AB63D4::NIIBE Yutaka <gniibe at debian.org>:
 sub:-:0:19:824E72CE975B9053:1389837376::::::sa::::::
-grp:::::::::0000000000000000106FBC00057F0000A0B2BB00:
+grp:::::::::000000000000000010CFA2B3597F0000A012A2B3:
 sub:-:2048:1:79A79093084239CF:1287125193::::::e::::::
 grp:::::::::65F67E742101C7FE6D5B33FCEFCF4F65EAF0688C:
 sub:-:2048:1:9C33B6BA5BB065DC:1287727596::::::a::::::
1 jj955 at alice:~$ 
gpg2 --version
gpg (GnuPG) 2.1.0
libgcrypt 1.6.2
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
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
0 demo at saturn:~$ 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: </pipermail/attachments/20141008/392a5c99/attachment.sig>

From wk at gnupg.org  Wed Oct  8 21:45:28 2014
From: wk at gnupg.org (Werner Koch)
Date: Wed, 08 Oct 2014 21:45:28 +0200
Subject: 2.1.0~beta864: gpg2 --list-secret-keys fails if gniibe's key is
 in pubring.kbx
In-Reply-To: <871tqi2yb0.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Wed, 08 Oct 2014 14:47:47 -0400")
References: <871tqi2yb0.fsf@alice.fifthhorseman.net>
Message-ID: <87y4sq5orr.fsf@vigenere.g10code.de>

On Wed,  8 Oct 2014 20:47, dkg at fifthhorseman.net said:

> i'm trying to use 2.1.0 beta864.  gpg2 --list-secret-keys fails (returns
> a non-zero return code) if any of the *public* keys it knows about fail
> to have a proper keygrip.

Okay, changed to use log_info to avoid a process exit with failure.

> Its also worth noting that the output of --with-keygrip appears to
> publish something that changes each time it's run -- this may be an
> information leak of memory that isn't properly initialized or cleared.

Also cleared the keygrip on error to not show a random value.



Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From dkg at fifthhorseman.net  Thu Oct  9 01:31:10 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 08 Oct 2014 19:31:10 -0400
Subject: --export-options export-reset-subkey-passwd in gpg 2.1.x (compat.
 with ssh-agent)
Message-ID: <87y4sq16m9.fsf@alice.fifthhorseman.net>

Hi GnuPG folks--

doc/gpg.texi contains:

  @c Since GnuPG 2.1 gpg-agent manages the secret key and thus the
  @c export-reset-subkey-passwd hack is not anymore justified.  Such use
  @c cases need to be implemented using a specialized secret key export
  @c tool.
@ifclear gpgtwoone
  @item export-reset-subkey-passwd
  When using the @option{--export-secret-subkeys} command, this option resets
  the passphrases for all exported subkeys to empty. This is useful
  when the exported subkey is to be used on an unattended machine where
  a passphrase doesn't necessarily make sense. Defaults to no.
@end ifclear


It's not clear to me what the "specialized secret key export tool" is --
does this tool exist or is it hypothetical at the moment?

The Monkeysphere project has been using export-reset-subkey-passwd to
hand off the specific subkey to OpenSSH's ssh-agent during "monkeysphere
subkey-to-ssh-agent" Switching to gpg 2.1 means breaking that current
behavior.

I know that gpg-agent offers some a roughly similar functionality to
ssh-agent, but the semantics of ssh-add between talking to gpg-agent and
talking to OpenSSH's ssh-agent are quite different, enough that some
people (myself included) currently prefer the ssh-agent semantics.

For example, OpenSSH's ssh-agent supports several options to ssh-add
that GnuPG's agent implementation does not:

  -c (require confirmation -- gpg-agent accepts but does not honor this flag)
  -d (delete key -- gpg-agent accepts but does not honor this flag)
  -D (delete all keys -- gpg-agent rejects this flag with an error)
  -t N (limit key lifetime to N seconds -- gpg-agent accepts but does not honor this flag)
  -x (lock agent with password -- gpg-agent accepts but does not honor this flag)

So, are there pointers for the secret subkey export tool?  or is there
another way that i can get this key material into another ssh-agent
implementation cleanly with GnuPG 2.1 ?  I'd really like to switch to
2.1.x for all my gpg-specific workflows, but this part is blocking me.

Regards,

     --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: </pipermail/attachments/20141008/c77e7bc6/attachment.sig>

From wk at gnupg.org  Thu Oct  9 08:13:26 2014
From: wk at gnupg.org (Werner Koch)
Date: Thu, 09 Oct 2014 08:13:26 +0200
Subject: --export-options export-reset-subkey-passwd in gpg 2.1.x
In-Reply-To: <87y4sq16m9.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Wed, 08 Oct 2014 19:31:10 -0400")
References: <87y4sq16m9.fsf@alice.fifthhorseman.net>
Message-ID: <87h9zd6a9l.fsf@vigenere.g10code.de>

On Thu,  9 Oct 2014 01:31, dkg at fifthhorseman.net said:

> It's not clear to me what the "specialized secret key export tool" is --
> does this tool exist or is it hypothetical at the moment?

Hypothetical.  I guess I was only too lazy to implement that given that
I only had the use case in mind for which I created it.

The real problem is that we can't export with a passphrase right now.
gpg-agent would need to be extended to export the key without a
passphrase.

>   -c (require confirmation -- gpg-agent accepts but does not honor this flag)

This used to work but I have not tested it recently:

      prompt = xtryasprintf (_("An ssh process requested the use of key%%0A"
                               "  %s%%0A"
                               "  (%s)%%0A"
                               "Do you want to allow this?"),

>   -d (delete key -- gpg-agent accepts but does not honor this flag)
>   -D (delete all keys -- gpg-agent rejects this flag with an error)

Indeed the semantics are different: gpg-agent stores the key permanently
and thus all keys are always available.  The passphrase chaching comes
on top of it.

>   -t N (limit key lifetime to N seconds -- gpg-agent accepts but does not honor this flag)

That could be translated into: store a default caching time for ssh use
with that key.  For example by putting that into ~/.gnupg/sshcontrol

>   -x (lock agent with password -- gpg-agent accepts but does not honor this flag)

Doesn't match the way gpg-agent works.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From wk at gnupg.org  Thu Oct  9 08:20:53 2014
From: wk at gnupg.org (Werner Koch)
Date: Thu, 09 Oct 2014 08:20:53 +0200
Subject: [PATCH] gpg 2.0.x: Add build and runtime support for larger RSA
 keys
In-Reply-To: <878uksub87.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Mon, 06 Oct 2014 17:42:00 -0400")
References: <1412359174-19670-1-git-send-email-dkg@fifthhorseman.net>
 <87y4sxau80.fsf@vigenere.g10code.de>
 <878uksub87.fsf@alice.fifthhorseman.net>
Message-ID: <87d2a169x6.fsf@vigenere.g10code.de>

On Mon,  6 Oct 2014 23:42, dkg at fifthhorseman.net said:

> What do you think we should do about this for the master branch?
>
> I can do the same cherry-pick (or a similar one) to the master branch if
> you think that's the right thing to do.

Yes, better keep that part identical on all branches.  It is more
relaxing for me than to get another bunch of insulting mails.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From wk at gnupg.org  Thu Oct  9 10:47:38 2014
From: wk at gnupg.org (Werner Koch)
Date: Thu, 09 Oct 2014 10:47:38 +0200
Subject: 2.1.0~beta864 bugfixes
In-Reply-To: <543436DB.7090406@fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Tue, 07 Oct 2014 14:54:19 -0400")
References: <8761fwu6bt.fsf@alice.fifthhorseman.net>
 <20141007033749.GO24040@gambit> <87vbnw9vz1.fsf@vigenere.g10code.de>
 <5433FF51.5080405@fifthhorseman.net> <20141007180653.GP24040@gambit>
 <543436DB.7090406@fifthhorseman.net>
Message-ID: <87oatl4ok5.fsf@vigenere.g10code.de>

On Tue,  7 Oct 2014 20:54, dkg at fifthhorseman.net said:

> upgrading gpg-agent:

> socket" isn't in use, and will launch their own gpg-agent, so you'll
> have both of them running in parallel.  This is suboptimal, but probably
> not a terrible outcome.

Indeed, it should not harm and it is easier to expect a user to restart
the session than to code around the problem and late be bugged with
race conditions.

> gpg: starting migration from earlier GnuPG versions
> gpg: error: GnuPG agent version "2.0.26" is too old.
> gpg: Please install an updated GnuPG agent.
> gpg: migration aborted
> 2 foo at alice:~$
>
> This happens even though the updated agent is *installed*, but it just
> happens to not be running.  The wording is slightly misleading, but the

I see whether I can up with a different wording.

> I'm also a little bit concerned that gpg 1.4.x will *not* try to start
> up a gpg-agent by default if it does not find one running, which means
> effectively that we still need to launch a gpg-agent during X11 session
> startup when use-agent is set, just to be sure that gpg1 users have a

I suggest to use

  gpg-connect-agent /bye

or better the new

  gpgconf --launch gpg-agent

> for users who have moved entirely to gpg 2.1.0.  This transitional work
> is the cost of supporting multiple versions simultaneously, though, and
> we seem to be committed to doing that, at least in the jessie timeframe,
> so we need to get at least the dual keyring issue sorted out.

I'll take care of this.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From dkg at fifthhorseman.net  Thu Oct  9 18:26:03 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 09 Oct 2014 12:26:03 -0400
Subject: --export-options export-reset-subkey-passwd in gpg 2.1.x
In-Reply-To: <87h9zd6a9l.fsf@vigenere.g10code.de>
References: <87y4sq16m9.fsf@alice.fifthhorseman.net>
 <87h9zd6a9l.fsf@vigenere.g10code.de>
Message-ID: <5436B71B.40804@fifthhorseman.net>

On 10/09/2014 02:13 AM, Werner Koch wrote:
> On Thu,  9 Oct 2014 01:31, dkg at fifthhorseman.net said:
> 
>> It's not clear to me what the "specialized secret key export tool" is --
>> does this tool exist or is it hypothetical at the moment?
> 
> Hypothetical.  I guess I was only too lazy to implement that given that
> I only had the use case in mind for which I created it.

ok, that makes sense.

> The real problem is that we can't export with a passphrase right now.
> gpg-agent would need to be extended to export the key without a
> passphrase.

This is a bit confusing, but it makes sense if i read the first sentence
as "without a passphrase" instead of "with a passphrase" -- is that
right?  certainly when i look at the output, the exported secret keys
are indeed encrypted.

It's also a little weird to me that i get prompted for my key's
passphrase when i do "gpg2 --export-secret-subkey 0x${SUBKEYID}\!"

if the emitted key is passphrase-locked already, then why do i need to
provide my passphrase in the first place for the export?

from monkeysphere's perspective, i'd prefer to just reinstate the
export-reset-subkey-passwd directive, to maintain compatibility.

Would you be open to a patch that does that for 2.1?  I'd be fine if it
only works for --export-secret-subkey when the subkey is specified
explicitly.

>>   -c (require confirmation -- gpg-agent accepts but does not honor this flag)
> 
> This used to work but I have not tested it recently:
> 
>       prompt = xtryasprintf (_("An ssh process requested the use of key%%0A"
>                                "  %s%%0A"
>                                "  (%s)%%0A"
>                                "Do you want to allow this?"),
> 
>>   -d (delete key -- gpg-agent accepts but does not honor this flag)
>>   -D (delete all keys -- gpg-agent rejects this flag with an error)
> 
> Indeed the semantics are different: gpg-agent stores the key permanently
> and thus all keys are always available.  The passphrase chaching comes
> on top of it.
> 
>>   -t N (limit key lifetime to N seconds -- gpg-agent accepts but does not honor this flag)
> 
> That could be translated into: store a default caching time for ssh use
> with that key.  For example by putting that into ~/.gnupg/sshcontrol
> 
>>   -x (lock agent with password -- gpg-agent accepts but does not honor this flag)
> 
> Doesn't match the way gpg-agent works.

To be clear, i'm not proposing that we should implement all of these
things in gpg-agent -- ssh-agent works for me and matches the workflow
that i expect.  And i know how you feel about agents hijacking other
agents when their semantics and operational behaviors are different :)

i just want to be able to keep my current work habits while moving to
the newer GnuPG. :)

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20141009/95e4d2f8/attachment.sig>

From dkg at fifthhorseman.net  Thu Oct  9 20:09:27 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 09 Oct 2014 14:09:27 -0400
Subject: gpg-agent 2.1.x interop with gpg 1.4.x
Message-ID: <5436CF57.9060907@fifthhorseman.net>

The 1.4 stable branch of gpg supports --use-agent, which makes it want
to talk to gpg-agent.

It does this by inspecting the local environment for $GPG_AGENT_INFO, or
by using the --gpg-agent-info argument.

In gpg 2.1, we're using the "standard socket" (~/.gnupg/S.gpg-agent) and
not expecting to use $GPG_AGENT_INFO at all any more, so gpg-agent does
not bother exporting any environment variables.

for example, with gpg-agent 2.1, the --sh and --csh arguments produce no
output, and "gpg-agent --daemon bash" yields a shell process that does
not have $GPG_AGENT_INFO set.

This means that attempts to use gpg --use-agent version 1.4.x from this
shell will fail, because gpg 1.4.x doesn't know to try to find the agent
on the standard socket.

I see a few possible ways of fixing this:

 0) add the following line to gpg.conf for use by the 1.4.x branch:
    gpg-agent-info /home/username/.gnupg/S.gpg-agent:0:1

 1) have users export GPG_AGENT_INFO=/home/username/.gnupg/S.gpg-agent
themselves when they launch gpg-agent

 2) have gpg-agent 2.1 export
GPG_AGENT_INFO=/home/username/.gnupg/S.gpg-agent:0:1 even though gpg 2.1
doesn't care about that environment variable


Analysis:

(0) is problematic for several reasons:

 * when gpg2.1 reads the shared configfile,  complains that
gpg-agent-info is obsolete

 * the value will be different for each user, since it embeds the home
directory

 * users are unlikely to know to do this

(1) is problematic because (again) it seems unlikely that users will
know to do this.

(2) is ugly, because it would be simpler to just get rid of
$GPG_AGENT_INFO altogether.

That said, if we aim to support mixed installations (apparently we do
for now), and people want to use gpg 1.4.x with the agent (they
certainly do), i think option (2) is the way to go.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20141009/0feb0c51/attachment.sig>

From wk at gnupg.org  Thu Oct  9 21:09:41 2014
From: wk at gnupg.org (Werner Koch)
Date: Thu, 09 Oct 2014 21:09:41 +0200
Subject: Large keys and the keybox (was: 2.1.0~beta864 bugfixes)
In-Reply-To: <543436DB.7090406@fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Tue, 07 Oct 2014 14:54:19 -0400")
References: <8761fwu6bt.fsf@alice.fifthhorseman.net>
 <20141007033749.GO24040@gambit> <87vbnw9vz1.fsf@vigenere.g10code.de>
 <5433FF51.5080405@fifthhorseman.net> <20141007180653.GP24040@gambit>
 <543436DB.7090406@fifthhorseman.net>
Message-ID: <87bnpl3vre.fsf_-_@vigenere.g10code.de>

On Tue,  7 Oct 2014 20:54, dkg at fifthhorseman.net said:

>  0) create a new keyring with gpg2, and use it exclusively with gpg2 for
> a while.
>  1) somehow (accidentally?) use gpg (1.4.x) again -- this creates
> ~/.gnupg/pubring.gpg
>  2) future runs of gpg2 now only look at pubring.gpg and ignore
> pubring.kbx -- the keys you had accumulated in the keybox are no longer
> listed in the output of gpg2 --list-keys

Okay, this should be fixed now.  I also also found another problem which
is fixed for now (overlong keys):

2ca90f78 * gpg: Skip overlong keys and a print a warning.
60e21d8b * gpg: Sync keylist output and warning messages.
b6507bb8 * kbx: Fix handling of overlong keys.
ec332d58 * gpg: Take care to use pubring.kbx if it has ever been used.
d8c01d82 * gpg: Change wording of a migration error message.
6be5c4fe * doc: Add missing entry for allow-preset-passphase
27fe067e * Avoid unnecessary library linkage

The largest Key currently allowed are 2 MiB (formerly 1 MB).  With this
patch and reducing the limit for testing to 1 MiB I get this on my test
ring:

  gpg: Note: signatures using the MD5 algorithm are rejected
  gpg: Warning: 4 key(s) skipped due to their large size

Before that a large key stopped the key listing early when using the
keybox.  Eventually we may need to add an option to increase the limit,
but we should really keep one to not eat up all memory on small devices.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From wk at gnupg.org  Thu Oct  9 21:14:17 2014
From: wk at gnupg.org (Werner Koch)
Date: Thu, 09 Oct 2014 21:14:17 +0200
Subject: --export-options export-reset-subkey-passwd in gpg 2.1.x
In-Reply-To: <5436B71B.40804@fifthhorseman.net> (Daniel Kahn Gillmor's message
 of "Thu, 09 Oct 2014 12:26:03 -0400")
References: <87y4sq16m9.fsf@alice.fifthhorseman.net>
 <87h9zd6a9l.fsf@vigenere.g10code.de>
 <5436B71B.40804@fifthhorseman.net>
Message-ID: <877g093vjq.fsf@vigenere.g10code.de>

On Thu,  9 Oct 2014 18:26, dkg at fifthhorseman.net said:

> This is a bit confusing, but it makes sense if i read the first sentence
> as "without a passphrase" instead of "with a passphrase" -- is that
> right?  certainly when i look at the output, the exported secret keys

Sure, that is what I meant.

> if the emitted key is passphrase-locked already, then why do i need to
> provide my passphrase in the first place for the export?

gpg-agent does not store the key in the OpenPGP format and thus wee need
a passphrase to convert it back. 

> Would you be open to a patch that does that for 2.1?  I'd be fine if it
> only works for --export-secret-subkey when the subkey is specified
> explicitly.

Sure. 

> To be clear, i'm not proposing that we should implement all of these
> things in gpg-agent -- ssh-agent works for me and matches the workflow

I was just tossing ideas.  Definitely not a goal for 2.1.0.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From wk at gnupg.org  Thu Oct  9 21:28:14 2014
From: wk at gnupg.org (Werner Koch)
Date: Thu, 09 Oct 2014 21:28:14 +0200
Subject: gpg-agent 2.1.x interop with gpg 1.4.x
In-Reply-To: <5436CF57.9060907@fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Thu, 09 Oct 2014 14:09:27 -0400")
References: <5436CF57.9060907@fifthhorseman.net>
Message-ID: <8738ax3uwh.fsf@vigenere.g10code.de>

On Thu,  9 Oct 2014 20:09, dkg at fifthhorseman.net said:

> not expecting to use $GPG_AGENT_INFO at all any more, so gpg-agent does
> not bother exporting any environment variables.

It still prints some for --enable-ssh-support.

>  2) have gpg-agent 2.1 export
> GPG_AGENT_INFO=/home/username/.gnupg/S.gpg-agent:0:1 even though gpg 2.1
> doesn't care about that environment variable

> That said, if we aim to support mixed installations (apparently we do
> for now), and people want to use gpg 1.4.x with the agent (they
> certainly do), i think option (2) is the way to go.

So we need to take care of the user's login scripts but we can't change
them.  Changing gpg-1 to autostart the agent and use a fixed socket is a
bit too much work.  Seems you are right.  Unless you want to install a
wrapper for gpg-agent to do just this. 

So what shall we do about --write-env-file?


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From dkg at fifthhorseman.net  Thu Oct  9 21:47:40 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 09 Oct 2014 15:47:40 -0400
Subject: Large keys and the keybox
In-Reply-To: <87bnpl3vre.fsf_-_@vigenere.g10code.de>
References: <8761fwu6bt.fsf@alice.fifthhorseman.net>	<20141007033749.GO24040@gambit>
 <87vbnw9vz1.fsf@vigenere.g10code.de>	<5433FF51.5080405@fifthhorseman.net>
 <20141007180653.GP24040@gambit>	<543436DB.7090406@fifthhorseman.net>
 <87bnpl3vre.fsf_-_@vigenere.g10code.de>
Message-ID: <5436E65C.5030208@fifthhorseman.net>

On 10/09/2014 03:09 PM, Werner Koch wrote:
> The largest Key currently allowed are 2 MiB (formerly 1 MB).  With this
> patch and reducing the limit for testing to 1 MiB I get this on my test
> ring:

Does this limit size of an entire OpenPGP certificate, or just the key
itself?

> Eventually we may need to add an option to increase the limit,
> but we should really keep one to not eat up all memory on small devices.

yeah, there are DoS tradeoffs in both directions, unfortunately.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20141009/27837b6d/attachment.sig>

From dkg at fifthhorseman.net  Thu Oct  9 22:17:21 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 09 Oct 2014 16:17:21 -0400
Subject: gpg-agent 2.1.x interop with gpg 1.4.x
In-Reply-To: <8738ax3uwh.fsf@vigenere.g10code.de>
References: <5436CF57.9060907@fifthhorseman.net>
 <8738ax3uwh.fsf@vigenere.g10code.de>
Message-ID: <5436ED51.5000800@fifthhorseman.net>

On 10/09/2014 03:28 PM, Werner Koch wrote:
> On Thu,  9 Oct 2014 20:09, dkg at fifthhorseman.net said:
> 
>> not expecting to use $GPG_AGENT_INFO at all any more, so gpg-agent does
>> not bother exporting any environment variables.
> 
> It still prints some for --enable-ssh-support.
> 
>>  2) have gpg-agent 2.1 export
>> GPG_AGENT_INFO=/home/username/.gnupg/S.gpg-agent:0:1 even though gpg 2.1
>> doesn't care about that environment variable
> 
>> That said, if we aim to support mixed installations (apparently we do
>> for now), and people want to use gpg 1.4.x with the agent (they
>> certainly do), i think option (2) is the way to go.
> 
> So we need to take care of the user's login scripts but we can't change
> them.  Changing gpg-1 to autostart the agent and use a fixed socket is a
> bit too much work.  Seems you are right.  Unless you want to install a
> wrapper for gpg-agent to do just this. 

i don't think a wrapper for gpg-agent would be sufficient, would it?
gpg1 never invokes gpg-agent directly.

> So what shall we do about --write-env-file?

Hm, yeah, that's another one that doesn't seem to do anything right now.

Maybe we want a gpg1-compatibility mode?


Another alternative, if you don't want to change anything in gpg 2.1
itself, is that we can modify the Xsession startup script
(/etc/X11/Xsession.d/90gpg-agent) that debian ships that enbles the
agent conditionally on the presence of use-agent in ~/gnupg.conf, by
just having it set GPG_AGENT_INFO=$HOME/.gnupg/S.gpg-agent, write the
standard env-file (on debian, that's
~/.gnupg/gpg-agent-info-$(hostname), and then start up the agent
directly with:

 gpgconf --launch gpg-agent

Maybe that's the simplest approach -- it leaves the distros that want to
maintain co-installability with the responsibility of maintaining it,
while leaving gpg 2.1 with less cruft that will eventually need pruning.


	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20141009/765e9796/attachment.sig>

From dkg at fifthhorseman.net  Thu Oct  9 22:54:15 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu,  9 Oct 2014 16:54:15 -0400
Subject: [PATCH] gpg: Add build and runtime support for larger RSA keys
In-Reply-To: <877g093vjq.fsf@vigenere.g10code.de>
References: <877g093vjq.fsf@vigenere.g10code.de>
Message-ID: <1412888055-25091-1-git-send-email-dkg@fifthhorseman.net>

* configure.ac: Added --enable-large-secmem option.
* g10/options.h: Add opt.flags.large_rsa.
* g10/gpg.c: Contingent on configure option: adjust secmem size,
add gpg --enable-large-rsa, bound to opt.flags.large_rsa.
* g10/keygen.c: Adjust max RSA size based on opt.flags.large_rsa
* doc/gpg.texi: Document --enable-large-rsa.

--

This is a cherry-pick of 534e2876acc05f9f8d9b54c18511fe768d77dfb5 from
STABLE-BRANCH-1-4 against master

Some older implementations built and used RSA keys up to 16Kib, but
the larger secret keys now fail when used by more recent GnuPG, due to
secure memory limitations.

Building with ./configure --enable-large-secmem will make gpg
capable of working with those secret keys, as well as permitting the
use of a new gpg option --enable-large-rsa, which let gpg generate RSA
keys up to 8Kib when used with --batch --gen-key.

Debian-bug-id: 739424

Minor edits by wk.

GnuPG-bug-id: 1732
---
 configure.ac  | 15 +++++++++++++++
 doc/gpg.texi  |  9 +++++++++
 g10/gpg.c     | 22 +++++++++++++++++++++-
 g10/keygen.c  |  5 +++--
 g10/options.h |  1 +
 5 files changed, 49 insertions(+), 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index 28268f1..7ce8c09 100644
--- a/configure.ac
+++ b/configure.ac
@@ -107,6 +107,7 @@ card_support=yes
 use_ccid_driver=yes
 dirmngr_auto_start=yes
 use_tls_library=no
+large_secmem=no
 
 GNUPG_BUILD_PROGRAM(gpg, yes)
 GNUPG_BUILD_PROGRAM(gpgsm, yes)
@@ -223,6 +224,20 @@ AC_ARG_ENABLE(selinux-support,
 AC_MSG_RESULT($selinux_support)
 
 
+AC_MSG_CHECKING([whether to allocate extra secure memory])
+AC_ARG_ENABLE(large-secmem,
+              AC_HELP_STRING([--enable-large-secmem],
+                             [allocate extra secure memory]),
+              large_secmem=$enableval, large_secmem=no)
+AC_MSG_RESULT($large_secmem)
+if test "$large_secmem" = yes ; then
+   SECMEM_BUFFER_SIZE=65536
+else
+   SECMEM_BUFFER_SIZE=32768
+fi
+AC_DEFINE_UNQUOTED(SECMEM_BUFFER_SIZE,$SECMEM_BUFFER_SIZE,
+                   [Size of secure memory buffer])
+
 AC_MSG_CHECKING([whether to enable trust models])
 AC_ARG_ENABLE(trust-models,
               AC_HELP_STRING([--disable-trust-models],
diff --git a/doc/gpg.texi b/doc/gpg.texi
index 002e888..e7360e9 100644
--- a/doc/gpg.texi
+++ b/doc/gpg.texi
@@ -1181,6 +1181,15 @@ the opposite meaning. The options are:
   validation. This option is only meaningful if pka-lookups is set.
 @end table
 
+ at item --enable-large-rsa
+ at itemx --disable-large-rsa
+ at opindex enable-large-rsa
+ at opindex disable-large-rsa
+With --gen-key and --batch, enable the creation of larger RSA secret
+keys than is generally recommended (up to 8192 bits).  These large
+keys are more expensive to use, and their signatures and
+certifications are also larger.
+
 @item --enable-dsa2
 @itemx --disable-dsa2
 @opindex enable-dsa2
diff --git a/g10/gpg.c b/g10/gpg.c
index f586042..e7d6d00 100644
--- a/g10/gpg.c
+++ b/g10/gpg.c
@@ -376,6 +376,8 @@ enum cmd_and_opt_values
     oAutoKeyLocate,
     oNoAutoKeyLocate,
     oAllowMultisigVerification,
+    oEnableLargeRSA,
+    oDisableLargeRSA,
     oEnableDSA2,
     oDisableDSA2,
     oAllowMultipleMessages,
@@ -770,6 +772,8 @@ static ARGPARSE_OPTS opts[] = {
 
   ARGPARSE_s_n (oAllowMultisigVerification,
                 "allow-multisig-verification", "@"),
+  ARGPARSE_s_n (oEnableLargeRSA, "enable-large-rsa", "@"),
+  ARGPARSE_s_n (oDisableLargeRSA, "disable-large-rsa", "@"),
   ARGPARSE_s_n (oEnableDSA2, "enable-dsa2", "@"),
   ARGPARSE_s_n (oDisableDSA2, "disable-dsa2", "@"),
   ARGPARSE_s_n (oAllowMultipleMessages,      "allow-multiple-messages", "@"),
@@ -2181,7 +2185,7 @@ main (int argc, char **argv)
 #endif
 
     /* Initialize the secure memory. */
-    if (!gcry_control (GCRYCTL_INIT_SECMEM, 32768, 0))
+    if (!gcry_control (GCRYCTL_INIT_SECMEM, SECMEM_BUFFER_SIZE, 0))
       got_secmem = 1;
 #if defined(HAVE_GETUID) && defined(HAVE_GETEUID)
     /* There should be no way to get to this spot while still carrying
@@ -3099,6 +3103,22 @@ main (int argc, char **argv)
 	    release_akl();
 	    break;
 
+	  case oEnableLargeRSA:
+#if SECMEM_BUFFER_SIZE >= 65536
+            opt.flags.large_rsa=1;
+#else
+            if (configname)
+              log_info("%s:%d: WARNING: gpg not built with large secure "
+                         "memory buffer.  Ignoring enable-large-rsa\n",
+                        configname,configlineno);
+            else
+              log_info("WARNING: gpg not built with large secure "
+                         "memory buffer.  Ignoring --enable-large-rsa\n");
+#endif /* SECMEM_BUFFER_SIZE >= 65536 */
+            break;
+	  case oDisableLargeRSA: opt.flags.large_rsa=0;
+            break;
+
 	  case oEnableDSA2: opt.flags.dsa2=1; break;
 	  case oDisableDSA2: opt.flags.dsa2=0; break;
 
diff --git a/g10/keygen.c b/g10/keygen.c
index 229f2bf..1c8d70e 100644
--- a/g10/keygen.c
+++ b/g10/keygen.c
@@ -1555,6 +1555,7 @@ gen_rsa (int algo, unsigned int nbits, KBNODE pub_root,
   int err;
   char *keyparms;
   char nbitsstr[35];
+  const unsigned maxsize = (opt.flags.large_rsa ? 8192 : 4096);
 
   assert (is_RSA(algo));
 
@@ -1566,9 +1567,9 @@ gen_rsa (int algo, unsigned int nbits, KBNODE pub_root,
       nbits = 2048;
       log_info (_("keysize invalid; using %u bits\n"), nbits );
     }
-  else if (nbits > 4096)
+  else if (nbits > maxsize)
     {
-      nbits = 4096;
+      nbits = maxsize;
       log_info (_("keysize invalid; using %u bits\n"), nbits );
     }
 
diff --git a/g10/options.h b/g10/options.h
index 7efb3d6..edd31a9 100644
--- a/g10/options.h
+++ b/g10/options.h
@@ -229,6 +229,7 @@ struct
     unsigned int dsa2:1;
     unsigned int allow_multiple_messages:1;
     unsigned int allow_weak_digest_algos:1;
+    unsigned int large_rsa:1;
   } flags;
 
   /* Linked list of ways to find a key if the key isn't on the local
-- 
2.1.1



From dkg at fifthhorseman.net  Thu Oct  9 23:00:49 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 09 Oct 2014 17:00:49 -0400
Subject: [PATCH] gpg: Add build and runtime support for larger RSA keys
In-Reply-To: <1412888055-25091-1-git-send-email-dkg@fifthhorseman.net>
References: <877g093vjq.fsf@vigenere.g10code.de>
 <1412888055-25091-1-git-send-email-dkg@fifthhorseman.net>
Message-ID: <87tx3d0xha.fsf@alice.fifthhorseman.net>

On Thu 2014-10-09 16:54:15 -0400, Daniel Kahn Gillmor wrote:
> * configure.ac: Added --enable-large-secmem option.
> * g10/options.h: Add opt.flags.large_rsa.
> * g10/gpg.c: Contingent on configure option: adjust secmem size,
> add gpg --enable-large-rsa, bound to opt.flags.large_rsa.
> * g10/keygen.c: Adjust max RSA size based on opt.flags.large_rsa
> * doc/gpg.texi: Document --enable-large-rsa.
>
> --
>
> This is a cherry-pick of 534e2876acc05f9f8d9b54c18511fe768d77dfb5 from
> STABLE-BRANCH-1-4 against master
>

sorry, i posted this to the wrong thread.  It should have been posted
in-reply-to: 87d2a169x6.fsf at vigenere.g10code.de

             --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: </pipermail/attachments/20141009/facb25bf/attachment.sig>

From coruus at gmail.com  Fri Oct 10 08:01:03 2014
From: coruus at gmail.com (David Leon Gil)
Date: Fri, 10 Oct 2014 02:01:03 -0400
Subject: [PATCH] Disable importing V3 public keys from keyservers
Message-ID: <CAA7UWsXLAUjT7XoL_mXT+mbAv=4aSjTcznpH0S7r4t49fOf=RQ@mail.gmail.com>

This patch is against HEAD. It would be nice to see it backported to
the next point releases.

>From 49cae65b8d1a0e5d8dd53465de501ba36f849f39 Mon Sep 17 00:00:00 2001
From: David Leon Gil <coruus at gmail.com>
Date: Thu, 9 Oct 2014 17:35:39 -0400
Subject: [PATCH] Disable importing V3 or older public keys from keyservers.

---
 g10/keyserver.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/g10/keyserver.c b/g10/keyserver.c
index 1b2e128..b866f38 100644
--- a/g10/keyserver.c
+++ b/g10/keyserver.c
@@ -1089,6 +1089,11 @@ keyserver_retrieval_screener (kbnode_t
keyblock, void *opaque)
       fingerprint_from_pk (pk, fpr, &fpr_len);
       keyid_from_pk (pk, keyid);

+      if (pk.version != 4) {
+ log_error(_("importing v3 or older keys from keyservers is unsafe:
skipping a returned v3 public key\n"))
+  continue;
+      }
+
       /* Compare requested and returned fingerprints if available. */
       for (n = 0; n < ndesc; n++)
         {
-- 
1.9.3 (Apple Git-50)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Disable-importing-V3-or-older-public-keys-from-keyse.patch
Type: application/octet-stream
Size: 887 bytes
Desc: not available
URL: </pipermail/attachments/20141010/ddc17595/attachment.obj>

From dkg at fifthhorseman.net  Fri Oct 10 09:01:28 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 10 Oct 2014 03:01:28 -0400
Subject: performance of gpg --list-secret-keys with large keyrings
Message-ID: <87r3yg1k8n.fsf@alice.fifthhorseman.net>

I'm noticing a serious degradation in performance on large public
keyrings from gpg 1.4.x to 2.1.x for the command:

 gpg --list-secret-keys

This is in a demo account that has 13 secret keys and over 2600 public
keys in the keyring.  The public keys are in pubring.gpg and not
pubring.kbx (no conversion has happened yet).  Here's the timings:

0 demo at saturn:~$ time gpg --with-colons --list-secret-keys  | grep -c '^sec:'
13

real	0m0.014s
user	0m0.008s
sys	0m0.004s
0 demo at saturn:~$ time gpg2 --with-colons --list-secret-keys  | grep -c '^sec:'
13

real	0m7.886s
user	0m7.544s
sys	0m0.172s
0 demo at saturn:~$ time gpg --with-colons --list-keys  | grep -c '^pub:'
2637

real	0m8.958s
user	0m8.812s
sys	0m0.160s
0 demo at saturn:~$ time gpg2 --with-colons --list-keys  | grep -c '^pub:'
2637

real	0m8.602s
user	0m8.420s
sys	0m0.188s
0 demo at saturn:~$ 


I think the move from 0.014s to >7s for --list-secret-keys is because
gpg 2.1 implements --list-secret-keys by asking the agent about every
known public key to see if it has the secret material for it.

Surely it would be more efficient if the agent could just list the keys
directly.  But maybe there are security reasons that we don't want to
expose such a list through the agent's interface?  If so, what are the
reasons?

Regards,

         --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: </pipermail/attachments/20141010/dccdbfbe/attachment-0001.sig>

From nicholas.cole at gmail.com  Fri Oct 10 08:33:32 2014
From: nicholas.cole at gmail.com (Nicholas Cole)
Date: Fri, 10 Oct 2014 07:33:32 +0100
Subject: [PATCH] Disable importing V3 public keys from keyservers
In-Reply-To: <CAA7UWsXLAUjT7XoL_mXT+mbAv=4aSjTcznpH0S7r4t49fOf=RQ@mail.gmail.com>
References: <CAA7UWsXLAUjT7XoL_mXT+mbAv=4aSjTcznpH0S7r4t49fOf=RQ@mail.gmail.com>
Message-ID: <CAAu18heu-kV4xLge=M0Gyq6BQ6GR0A14cm_kvsyZ9U9TV=x5Rg@mail.gmail.com>

On Fri, Oct 10, 2014 at 7:01 AM, David Leon Gil <coruus at gmail.com> wrote:
> This patch is against HEAD. It would be nice to see it backported to
> the next point releases.
>
> From 49cae65b8d1a0e5d8dd53465de501ba36f849f39 Mon Sep 17 00:00:00 2001
> From: David Leon Gil <coruus at gmail.com>
> Date: Thu, 9 Oct 2014 17:35:39 -0400
> Subject: [PATCH] Disable importing V3 or older public keys from keyservers.

What's the thinking behind this patch?


From wk at gnupg.org  Fri Oct 10 10:44:39 2014
From: wk at gnupg.org (Werner Koch)
Date: Fri, 10 Oct 2014 10:44:39 +0200
Subject: [PATCH] Disable importing V3 public keys from keyservers
In-Reply-To: <CAA7UWsXLAUjT7XoL_mXT+mbAv=4aSjTcznpH0S7r4t49fOf=RQ@mail.gmail.com>
 (David Leon Gil's message of "Fri, 10 Oct 2014 02:01:03 -0400")
References: <CAA7UWsXLAUjT7XoL_mXT+mbAv=4aSjTcznpH0S7r4t49fOf=RQ@mail.gmail.com>
Message-ID: <87y4so2u14.fsf@vigenere.g10code.de>

On Fri, 10 Oct 2014 08:01, coruus at gmail.com said:
> This patch is against HEAD. It would be nice to see it backported to
> the next point releases.

Actually v3 keys are not anymore usable in 2.x unless you use
--allow-weak-digest-algos (or --pgp2 in 2.0).  However, allowing to
import v3 keys is important so to be able to decrypt old mails.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From wk at gnupg.org  Fri Oct 10 10:49:47 2014
From: wk at gnupg.org (Werner Koch)
Date: Fri, 10 Oct 2014 10:49:47 +0200
Subject: [PATCH] Disable importing V3 public keys from keyservers
In-Reply-To: <CAA7UWsXLAUjT7XoL_mXT+mbAv=4aSjTcznpH0S7r4t49fOf=RQ@mail.gmail.com>
 (David Leon Gil's message of "Fri, 10 Oct 2014 02:01:03 -0400")
References: <CAA7UWsXLAUjT7XoL_mXT+mbAv=4aSjTcznpH0S7r4t49fOf=RQ@mail.gmail.com>
Message-ID: <87tx3c2tsk.fsf@vigenere.g10code.de>

Hi again,

sorry, of course being able to import a v3 key from a keyserver to allow
decryption does not make any sense.  OTOH, everything received form a
keyserver is not checked at that point and thus the version number my
also be bogus.  Having MD5 disabled is sufficient to reject this key.
Adding extra code and more translatable strings is not needed.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From wk at gnupg.org  Fri Oct 10 11:23:52 2014
From: wk at gnupg.org (Werner Koch)
Date: Fri, 10 Oct 2014 11:23:52 +0200
Subject: performance of gpg --list-secret-keys with large keyrings
In-Reply-To: <87r3yg1k8n.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Fri, 10 Oct 2014 03:01:28 -0400")
References: <87r3yg1k8n.fsf@alice.fifthhorseman.net>
Message-ID: <87ppe02s7r.fsf@vigenere.g10code.de>

On Fri, 10 Oct 2014 09:01, dkg at fifthhorseman.net said:

> keys in the keyring.  The public keys are in pubring.gpg and not
> pubring.kbx (no conversion has happened yet).  Here's the timings:

Yeah, you should do that conversion first ;-)

> I think the move from 0.014s to >7s for --list-secret-keys is because
> gpg 2.1 implements --list-secret-keys by asking the agent about every
> known public key to see if it has the secret material for it.

I have not had this experience but it is quite plausible.  Wi would like
to delay a fix for that to 2.1.1 - if we keep on fixing everything for
2.1.0 we will never see a release.

> Surely it would be more efficient if the agent could just list the keys
> directly.  But maybe there are security reasons that we don't want to

It can't becuase the agent does not now about the OpenPGP protocol and
thus does not know which of its keys belong to an OpenPGP key.  What we
do instead is to compute the "keygrip" from each key and ask the agent
whether it knows the matching private key:

  gpg:
  For each key
     Compute keygrip for each subkey
     Send a HAVEKEY command with all these keygrips to gpg-agent
     gpg-agent:
     For each keygrip
        Build filename
        if access(filename) possible
           return okay to gpg
     gpg:   
     if okay
        list as secret key.

Thus for the command case of a primary and a subkey we have two
directory lookups which should be fast.  Two keygrip computations
(parsing and SHA-1) and the IPC overhead.

There are several places were we could improve things:

- gpg-agent could cache the keygrips to avoid a file system operation.
  But on Linux this should not really matter.

- If the keygrip will be listed caching it with the key like we do for
  the fingerprint would be useful.  Can you run 2.1 using --with-keygrip
  to see whether the numbers are noticeable different than without that
  option?

- We could send a HAVEKEY command for each single keygrip, so that we do
  not need to compute the keygrip for the subkey in advance assuming
  that the agent has the primary key.  IIRC, I did this initially
  but the current solutions was faster.

- We could ask the agent for a list of all private keys it knows
  (KEYINFO --list) and compare against this list.  That makes sense if we
  have to check a lot of public keys but not for just a few ones.  There
  is also the problem what to do if the agent holds a huge numbers of
  keys and does not need to do a full secret key listing (I know of an
  authentication system which does this).

My guess is that the last option would be the best one for the general
case.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From wk at gnupg.org  Fri Oct 10 11:35:28 2014
From: wk at gnupg.org (Werner Koch)
Date: Fri, 10 Oct 2014 11:35:28 +0200
Subject: Large keys and the keybox
In-Reply-To: <5436E65C.5030208@fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Thu, 09 Oct 2014 15:47:40 -0400")
References: <8761fwu6bt.fsf@alice.fifthhorseman.net>
 <20141007033749.GO24040@gambit> <87vbnw9vz1.fsf@vigenere.g10code.de>
 <5433FF51.5080405@fifthhorseman.net> <20141007180653.GP24040@gambit>
 <543436DB.7090406@fifthhorseman.net>
 <87bnpl3vre.fsf_-_@vigenere.g10code.de>
 <5436E65C.5030208@fifthhorseman.net>
Message-ID: <87lhoo2rof.fsf@vigenere.g10code.de>

On Thu,  9 Oct 2014 21:47, dkg at fifthhorseman.net said:

> Does this limit size of an entire OpenPGP certificate, or just the key
> itself?

The certificate (aka keyblock) plus some keybox created meta
information.

I'd really like to have a limit here although all gpg versions don't
have a real memory limit at all (the keyblock is parsed into a linked
list and thus a large keyblock (i.e. with images) may eat up lots of
memory.  Which is the reason why it might be useful to add an API to
gpgme to set an rlimit for GnuPG processes.

Having a limit on import, as we have now with the keybox, would sort out
possible made up large keys (modulo schmorpness).


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From coruus at gmail.com  Fri Oct 10 15:00:24 2014
From: coruus at gmail.com (David Leon Gil)
Date: Fri, 10 Oct 2014 09:00:24 -0400
Subject: [PATCH] Disable importing V3 public keys from keyservers
In-Reply-To: <CAAu18heu-kV4xLge=M0Gyq6BQ6GR0A14cm_kvsyZ9U9TV=x5Rg@mail.gmail.com>
References: <CAA7UWsXLAUjT7XoL_mXT+mbAv=4aSjTcznpH0S7r4t49fOf=RQ@mail.gmail.com>
 <CAAu18heu-kV4xLge=M0Gyq6BQ6GR0A14cm_kvsyZ9U9TV=x5Rg@mail.gmail.com>
Message-ID: <CAA7UWsXA2rPoZ264WnaEuNGCv+1Qw43BEZk3fjU3eKWdRr=K7Q@mail.gmail.com>

On Fri, Oct 10, 2014 at 2:33 AM, Nicholas Cole <nicholas.cole at gmail.com> wrote:
> What's the thinking behind this patch?

There's little point in having a filter for long keyids if GnuPG will
import V3 keys from a keyserver; V3 long (and short) keyids are
trivially spoofable. (The 0xdeadbeef "attack".)

V3 keys make up fewer than 3% of the keys in SKS and are mostly very,
very old. A patch with slightly less impact: Only allow V3 keys if a
V3 fingerprint is given.


From coruus at gmail.com  Fri Oct 10 15:41:21 2014
From: coruus at gmail.com (David Leon Gil)
Date: Fri, 10 Oct 2014 09:41:21 -0400
Subject: [PATCH] Disable importing V3 public keys from keyservers
In-Reply-To: <87tx3c2tsk.fsf@vigenere.g10code.de>
References: <CAA7UWsXLAUjT7XoL_mXT+mbAv=4aSjTcznpH0S7r4t49fOf=RQ@mail.gmail.com>
 <87tx3c2tsk.fsf@vigenere.g10code.de>
Message-ID: <CAA7UWsVe_StEdh2nmWOo3EY9MCk=NhAG3Fsf4bXtF1XXrzCMFg@mail.gmail.com>

On Fri, Oct 10, 2014 at 4:44 AM, Werner Koch <wk at gnupg.org> wrote:
(quoting from multiple emails)
> On Fri, 10 Oct 2014 08:01, coruus at gmail.com said:
> Actually v3 keys are not anymore usable in 2.x unless you use
> --allow-weak-digest-algos (or --pgp2 in 2.0).

I don't think that this is, in fact, correct. Using default settings
(by creating a new blank home directory), GnuPG 2.0.26 (and 1.0.18)
will import V3 keys from keyservers. (Note: my test keys have V4
signatures.)

There's some test code here:
https://github.com/coruus/cooperpair/tree/master/keysteak

And a keyring with spoofed keys here:
https://github.com/coruus/cooperpair/raw/master/keysteak/test/pubring.gpg

The output of --list-packets for one of the keys:

    :public key packet:
    version 3, algo 1, created 1375731712, expires 0
    pkey[0]: [4091 bits]
    pkey[1]: [17 bits]
    keyid: 1202821CBE2CD9C1
    :user ID packet: "Tails developers (signing key) <tails at boum.org>"
    :signature packet: algo 1, keyid 1202821CBE2CD9C1
    version 4, created 1412873043, md5len 0, sigclass 0x13
    digest algo 10, begin of digest cf a6
    hashed subpkt 2 len 4 (sig created 2014-10-09)
    hashed subpkt 27 len 1 (key flags: 03)
    hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 3)
    hashed subpkt 21 len 4 (pref-hash-algos: 10 9 8 11)
    hashed subpkt 22 len 4 (pref-zip-algos: 2 3 1 0)
    hashed subpkt 30 len 1 (features: 01)
    hashed subpkt 23 len 1 (key server preferences: 80)
    subpkt 16 len 8 (issuer key ID 1202821CBE2CD9C1)
    data: [4090 bits]

(You can retrieve the real key from
https://tails.boum.org/tails-signing.key to confirm it is a V4 public
key.)

If the current behavior isn't the intended one (particularly for
import via --import), then this may be CVE-worthy; it's a classic
protocol-format crossgrade.

> Having MD5 disabled is sufficient to reject this key.

Is there any way to disable it completely? Only some operations seem
to warn when using MD5.

(Note: I may be missing something in the code of GnuPG 2.1; I'm
struggling with getting bits of 2.1 to build at the moment, so this
has only been tested to not cause a build error HEAD.)

> Adding extra code and more translatable strings is not needed.

Sorry; I forgot about translation. Silently failing (or reusing a
current string, though I didn't see anything quite right) would be
fine. (Corrected patch attached.)

I'd rather see V3 import from external sources -- even for key refresh
-- disabled entirely. There's some other code that could be removed in
that case.

> OTOH, everything received form a
> keyserver is not checked at that point and thus the version number my
> also be bogus.

Yes; but won't a V3 key with version number set to 4 be treated by
hash_public_key as a V4 key? (In that case, the keyid/fingerprint will
still be a -- meaningless -- SHA1 hash of the key.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Disable-importing-V3-or-older-public-keys-from-keyse.patch
Type: application/octet-stream
Size: 887 bytes
Desc: not available
URL: </pipermail/attachments/20141010/fae2d405/attachment.obj>

From dkg at fifthhorseman.net  Fri Oct 10 16:05:40 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 10 Oct 2014 10:05:40 -0400
Subject: [PATCH] Disable importing V3 public keys from keyservers
In-Reply-To: <CAA7UWsXA2rPoZ264WnaEuNGCv+1Qw43BEZk3fjU3eKWdRr=K7Q@mail.gmail.com>
References: <CAA7UWsXLAUjT7XoL_mXT+mbAv=4aSjTcznpH0S7r4t49fOf=RQ@mail.gmail.com>
 <CAAu18heu-kV4xLge=M0Gyq6BQ6GR0A14cm_kvsyZ9U9TV=x5Rg@mail.gmail.com>
 <CAA7UWsXA2rPoZ264WnaEuNGCv+1Qw43BEZk3fjU3eKWdRr=K7Q@mail.gmail.com>
Message-ID: <5437E7B4.1050407@fifthhorseman.net>

On 10/10/2014 09:00 AM, David Leon Gil wrote:
> On Fri, Oct 10, 2014 at 2:33 AM, Nicholas Cole <nicholas.cole at gmail.com> wrote:
>> What's the thinking behind this patch?
> 
> There's little point in having a filter for long keyids if GnuPG will
> import V3 keys from a keyserver; V3 long (and short) keyids are
> trivially spoofable. (The 0xdeadbeef "attack".)

full v3 fingerprints are also spoofable ?

> V3 keys make up fewer than 3% of the keys in SKS and are mostly very,
> very old. A patch with slightly less impact: Only allow V3 keys if a
> V3 fingerprint is given.

So this proposal won't help either.

I am happy that the MD5 limit will make it impossible to import v3 keys
at all with 2.1.


I just tested this with Ben Laurie's old v3 key (0x1B080C452719AF35),
and it's correct that gpg 2.1 won't import it.  But there was some
non-repeatable problem with gpg2.1 initially *removing* the key for some
reason, so i had to fall back to gpg1 to remove it:

2 dkg at alice:~$ gpg2 --delete-key 0x1B080C452719AF35
gpg: there is a secret key for public key "0x1B080C452719AF35"!
gpg: use option "--delete-secret-keys" to delete it first.
2 dkg at alice:~$ gpg --list-keys 0x1B080C452719AF35
pub   1024R/0x1B080C452719AF35 1995-05-13
      Key fingerprint = 3F D9 FA 49 8B 6D 60 95  5B E3 AD 83 67 7F 9E 69
uid                 [ unknown] Ben Laurie <ben at apache.org>
uid                 [  undef ] Ben Laurie <ben at algroup.co.uk>
uid                 [ unknown] Ben Laurie <ben at links.org>
uid                 [ unknown] Ben Laurie <ben at thebunker.net>

0 dkg at alice:~$ gpg --delete-keys 0x1B080C452719AF35

pub  1024R/0x1B080C452719AF35 1995-05-13 Ben Laurie <ben at apache.org>

Delete this key from the keyring? (y/N) y
0 dkg at alice:~$


weird, eh?  I swear i don't have a copy of ben laurie's secret key! :)

i haven't been able to replicate that error yet either.  But once i did
remove the key, gpg 2.1 doesn't import it:


2 dkg at alice:~$ gpg2 --recv 0x1B080C452719AF35
gpg: Note: signatures using the MD5 algorithm are rejected
gpg: key 0x1B080C452719AF35: no valid user IDs
gpg: this may be caused by a missing self-signature
gpg: Total number processed: 1
gpg:           w/o user IDs: 1
2 dkg at alice:~$ gpg2 --list-keys 0x1B080C452719AF35
gpg: error reading key: No public key
2 dkg at alice:~$


However, using the same keyring with gpg1, it will import:

2 dkg at alice:~$ gpg --recv 0x1B080C452719AF35
gpg: WARNING: digest algorithm MD5 is deprecated
gpg: please see http://www.gnupg.org/faq/weak-digest-algos.html for more
information
gpg: key 0x1B080C452719AF35: public key "Ben Laurie <ben at apache.org>"
imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
0 dkg at alice:~$ gpg --list-keys 0x1B080C452719AF35
gpg: please do a --check-trustdb
pub   1024R/0x1B080C452719AF35 1995-05-13
      Key fingerprint = 3F D9 FA 49 8B 6D 60 95  5B E3 AD 83 67 7F 9E 69
uid                 [ unknown] Ben Laurie <ben at apache.org>
uid                 [ unknown] Ben Laurie <ben at links.org>
uid                 [  undef ] Ben Laurie <ben at algroup.co.uk>
uid                 [ unknown] Ben Laurie <ben at thebunker.net>

0 dkg at alice:~$

And then it will be visible to gpg 2.1 again:

0 dkg at alice:~$ gpg2 --list-keys 0x1B080C452719AF35
gpg: please do a --check-trustdb
pub   rsa1024/0x1B080C452719AF35 1995-05-13
      Key fingerprint = 3F D9 FA 49 8B 6D 60 95  5B E3 AD 83 67 7F 9E 69
uid                 [ unknown] Ben Laurie <ben at apache.org>
uid                 [ unknown] Ben Laurie <ben at links.org>
uid                 [  undef ] Ben Laurie <ben at algroup.co.uk>
uid                 [ unknown] Ben Laurie <ben at thebunker.net>

0 dkg at alice:~$

Of course, now it does delete:

0 dkg at alice:~$ gpg2 --delete-keys 0x1B080C452719AF35
pub  rsa1024/0x1B080C452719AF35 1995-05-13 Ben Laurie <ben at apache.org>

Delete this key from the keyring? (y/N) y
0 dkg at alice:~$ gpg2 --list-keys 0x1B080C452719AF35
gpg: please do a --check-trustdb
gpg: error reading key: No public key
2 dkg at alice:~$

weird,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20141010/ba0a99c6/attachment-0001.sig>

From coruus at gmail.com  Fri Oct 10 16:10:54 2014
From: coruus at gmail.com (David Leon Gil)
Date: Fri, 10 Oct 2014 10:10:54 -0400
Subject: [PATCH] Disable importing V3 public keys from keyservers
In-Reply-To: <5437E7B4.1050407@fifthhorseman.net>
References: <CAA7UWsXLAUjT7XoL_mXT+mbAv=4aSjTcznpH0S7r4t49fOf=RQ@mail.gmail.com>
 <CAAu18heu-kV4xLge=M0Gyq6BQ6GR0A14cm_kvsyZ9U9TV=x5Rg@mail.gmail.com>
 <CAA7UWsXA2rPoZ264WnaEuNGCv+1Qw43BEZk3fjU3eKWdRr=K7Q@mail.gmail.com>
 <5437E7B4.1050407@fifthhorseman.net>
Message-ID: <CAA7UWsU951rYvcqDjX4P0bLGCBUUP+rKFvhwssdXzNTRDOwMLA@mail.gmail.com>

Yes; V3 keys with V3 signatures get a warning / don't work. Have you
tried this with a V3 key with a *V4* signature?

Here's Ben Laurie's key. Results of gpg2 --import:

gpg: pub  4090R/0x1B080C452719AF35 2013-08-05  Ben Laurie <ben at links.org>
gpg: using PGP trust model
gpg: key 0x1B080C452719AF35: public key "Ben Laurie <ben at links.org>" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
-------------- next part --------------
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1

mQIPA1IAAAAAAAEP+gKdGdF6NFdddRYaTp2QvgsAGgE9uel2UL1dPN8Z/gSXPjBe
p30g+Pzc7+6L4Le/+ObpuQ6Npp88C8+BYQH+vo5xBCr14tVQ/8WubtOj/gHKGsjK
Tcnae4ls6UXp+E3Ihh6vjfY12pOgevhlDt/H8oRiba9AKaklZlhJYS8/UHk0T4rA
h49q/H3/u2HYPThjbXPv8iVf+oWZsCm8SNDtHVfpJQCkuI61N56UHWzZxR6Rk0gS
DERMlbf2tRNCXq2Q8ifZg4E5dw7Idq1m33rwA/KNQ67t4BWsnhBBcT5s8FAokz7t
KmE/8u/PrrhADnW3hB95TLlznHqjWRURY3sLC6xIbxxFO0Nx4hQa1rquDsf8tkBM
UQBhFCVVdXI2/y+S/ZMr04MUIDg9dZqCT3tZl0QWXV6U3/alUYNXWlEoHbwqAo1y
9+YOAzqe5nYc2YNAJDFvH97BoO5RUezAOKHpUdXxQKmMHnQsx/WqV+ba38YPP4dF
Zhj3r/vsmRDVls+gFu6R5JXNCgkmD2adhnjVtZJ7dv1HC4M5pd1B1LsA0Tr3nRIA
C2lbWlquU8m630Fm064t2hJPCXeLDUu6it6pI8DhQGZpxUrjHq9lMwFEHQN6olI5
jGOF9T2IN7VEq0vmoxNTTjHrRdV8eaWWleJLpjfXknEBlaq89hsIDEUnGa81ABEB
AAG0GkJlbiBMYXVyaWUgPGJlbkBsaW5rcy5vcmc+iQI3BBMBCgAhBQJUN+hAAhsD
BQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAAoJEBsIDEUnGa81rmsP+QE0HCS1AP3+
OVKz/oJxet8bHl8MVonZ5TjktBDm11Mm5YVmW2ng3wDsNFzg3GCxW2AJOc9IQjzM
+q3khZrPI9m//npAmdG0DltklTTlQGq2QRRY5m3RgRTXOwJGBtIHOy9fMQvzQQ/C
k+pCxnd5X8QaebQrxX7sca66SEzVbRPW8f8py6Rf23kAdKcrjP/a+2YO4vLgbOUx
9BwZqwDOmwcMtQL+SMTBSG5+xAnuV/ZX+h5slg8FEZ+ZHh3QJlUCkjKxPcQrJRpe
jei5IUEmWTjKK+6Cb2p0n3jvZKeRJmv2n8bCIG30X1k/su8D5h9tF7riBqjqHFtx
RLwhedm+uDZzMC5PAeb8WwBIQacZZDdKoNHAhvbMvLMK7y+A/Lrs9GLn6OGTc3uw
cxhdGoQzJNyx6V15gW0x0+XRfWKdQZpKGuxLq7MlT/vpz7Gr9ONXTG/S76RGc4A8
Qtp+wE5oj/N2ac+n2Ku2RzXOXpcEuGqSrkA7pAPNmAAplgWUIGTYL2FoT+6wmQTk
S6d8jZN/huLQ7cPvVxxQDcfMqbz/w3JAYVrpvLxXjMGfLi0NMdi/8dPV1Zf2/GiH
OhWvrHQ1XjcYxI4j2aNlOdthoxk10WgfOPvns7j8hufdBg6+uvr1Sh4CO7H7Sqeh
M2rz/+jixn7VtqDSurvoM/LqZa9QTiK7
=JLsD
-----END PGP PUBLIC KEY BLOCK-----

From coruus at gmail.com  Fri Oct 10 16:17:13 2014
From: coruus at gmail.com (David Leon Gil)
Date: Fri, 10 Oct 2014 10:17:13 -0400
Subject: [PATCH] Disable importing V3 public keys from keyservers
In-Reply-To: <CAA7UWsU951rYvcqDjX4P0bLGCBUUP+rKFvhwssdXzNTRDOwMLA@mail.gmail.com>
References: <CAA7UWsXLAUjT7XoL_mXT+mbAv=4aSjTcznpH0S7r4t49fOf=RQ@mail.gmail.com>
 <CAAu18heu-kV4xLge=M0Gyq6BQ6GR0A14cm_kvsyZ9U9TV=x5Rg@mail.gmail.com>
 <CAA7UWsXA2rPoZ264WnaEuNGCv+1Qw43BEZk3fjU3eKWdRr=K7Q@mail.gmail.com>
 <5437E7B4.1050407@fifthhorseman.net>
 <CAA7UWsU951rYvcqDjX4P0bLGCBUUP+rKFvhwssdXzNTRDOwMLA@mail.gmail.com>
Message-ID: <CAA7UWsXTRTj1X3yY0dvKZapzF9HuiOS9Ob0WOHRY=NsUssJifw@mail.gmail.com>

On Fri, Oct 10, 2014 at 10:10 AM, David Leon Gil <coruus at gmail.com> wrote:
> Here's Ben Laurie's key. Results of gpg2 --import:

(Note! It's not the real key, it's a fake. Please don't import it into
your real keyring; do --home ./test or something.)


From coruus at gmail.com  Fri Oct 10 16:22:51 2014
From: coruus at gmail.com (David Leon Gil)
Date: Fri, 10 Oct 2014 10:22:51 -0400
Subject: [PATCH] Disable importing V3 public keys from keyservers
In-Reply-To: <5437E7B4.1050407@fifthhorseman.net>
References: <CAA7UWsXLAUjT7XoL_mXT+mbAv=4aSjTcznpH0S7r4t49fOf=RQ@mail.gmail.com>
 <CAAu18heu-kV4xLge=M0Gyq6BQ6GR0A14cm_kvsyZ9U9TV=x5Rg@mail.gmail.com>
 <CAA7UWsXA2rPoZ264WnaEuNGCv+1Qw43BEZk3fjU3eKWdRr=K7Q@mail.gmail.com>
 <5437E7B4.1050407@fifthhorseman.net>
Message-ID: <CAA7UWsUPE8P9rm1NUHNAZRwYF31dkW13bFw1ZCUEg=vLLWAzrA@mail.gmail.com>

On Fri, Oct 10, 2014 at 10:05 AM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:
> full v3 fingerprints are also spoofable ?

You can generate collisions easily enough. Is there another way of
spoofing them? They're the MD5 hash of the modulus, no?


From dkg at fifthhorseman.net  Fri Oct 10 16:25:20 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 10 Oct 2014 10:25:20 -0400
Subject: [PATCH] Disable importing V3 public keys from keyservers
In-Reply-To: <CAA7UWsU951rYvcqDjX4P0bLGCBUUP+rKFvhwssdXzNTRDOwMLA@mail.gmail.com>
References: <CAA7UWsXLAUjT7XoL_mXT+mbAv=4aSjTcznpH0S7r4t49fOf=RQ@mail.gmail.com>
 <CAAu18heu-kV4xLge=M0Gyq6BQ6GR0A14cm_kvsyZ9U9TV=x5Rg@mail.gmail.com>
 <CAA7UWsXA2rPoZ264WnaEuNGCv+1Qw43BEZk3fjU3eKWdRr=K7Q@mail.gmail.com>
 <5437E7B4.1050407@fifthhorseman.net>
 <CAA7UWsU951rYvcqDjX4P0bLGCBUUP+rKFvhwssdXzNTRDOwMLA@mail.gmail.com>
Message-ID: <5437EC50.1060700@fifthhorseman.net>

On 10/10/2014 10:10 AM, David Leon Gil wrote:
> Yes; V3 keys with V3 signatures get a warning / don't work. Have you
> tried this with a V3 key with a *V4* signature?
> 
> Here's Ben Laurie's key. Results of gpg2 --import:
> 
> gpg: pub  4090R/0x1B080C452719AF35 2013-08-05  Ben Laurie <ben at links.org>
> gpg: using PGP trust model
> gpg: key 0x1B080C452719AF35: public key "Ben Laurie <ben at links.org>" imported
> gpg: Total number processed: 1
> gpg:               imported: 1  (RSA: 1)

sorry, i hadn't tested this part, and you're quite right.  I agree that
we should reject v3 keys on import entirely.

Just blocking MD5 is insufficient, and gpg 2.1 does successfully import
your demonstration key.

	--dkg

PS if Ben Laurie is reading this, sorry that you got used as an example!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20141010/e8bfa7e8/attachment.sig>

From dkg at fifthhorseman.net  Fri Oct 10 16:29:56 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 10 Oct 2014 10:29:56 -0400
Subject: [PATCH] Disable importing V3 public keys from keyservers
In-Reply-To: <CAA7UWsUPE8P9rm1NUHNAZRwYF31dkW13bFw1ZCUEg=vLLWAzrA@mail.gmail.com>
References: <CAA7UWsXLAUjT7XoL_mXT+mbAv=4aSjTcznpH0S7r4t49fOf=RQ@mail.gmail.com>
 <CAAu18heu-kV4xLge=M0Gyq6BQ6GR0A14cm_kvsyZ9U9TV=x5Rg@mail.gmail.com>
 <CAA7UWsXA2rPoZ264WnaEuNGCv+1Qw43BEZk3fjU3eKWdRr=K7Q@mail.gmail.com>
 <5437E7B4.1050407@fifthhorseman.net>
 <CAA7UWsUPE8P9rm1NUHNAZRwYF31dkW13bFw1ZCUEg=vLLWAzrA@mail.gmail.com>
Message-ID: <5437ED64.9080900@fifthhorseman.net>

On 10/10/2014 10:22 AM, David Leon Gil wrote:
> On Fri, Oct 10, 2014 at 10:05 AM, Daniel Kahn Gillmor
> <dkg at fifthhorseman.net> wrote:
>> full v3 fingerprints are also spoofable ?
> 
> You can generate collisions easily enough. Is there another way of
> spoofing them?

yep.

> They're the MD5 hash of the modulus, no?

No, v3 fingerprints include the exponent as well:

 https://tools.ietf.org/html/rfc4880#section-12.2

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20141010/53004cde/attachment.sig>

From coruus at gmail.com  Fri Oct 10 16:32:36 2014
From: coruus at gmail.com (David Leon Gil)
Date: Fri, 10 Oct 2014 10:32:36 -0400
Subject: [PATCH] Disable importing V3 public keys from keyservers
In-Reply-To: <5437ED64.9080900@fifthhorseman.net>
References: <CAA7UWsXLAUjT7XoL_mXT+mbAv=4aSjTcznpH0S7r4t49fOf=RQ@mail.gmail.com>
 <CAAu18heu-kV4xLge=M0Gyq6BQ6GR0A14cm_kvsyZ9U9TV=x5Rg@mail.gmail.com>
 <CAA7UWsXA2rPoZ264WnaEuNGCv+1Qw43BEZk3fjU3eKWdRr=K7Q@mail.gmail.com>
 <5437E7B4.1050407@fifthhorseman.net>
 <CAA7UWsUPE8P9rm1NUHNAZRwYF31dkW13bFw1ZCUEg=vLLWAzrA@mail.gmail.com>
 <5437ED64.9080900@fifthhorseman.net>
Message-ID: <CAA7UWsXn5=mapauUb_+KkDwn8_jd3kyOAk9woeWr0ohFHMvtcg@mail.gmail.com>

On Fri, Oct 10, 2014 at 10:29 AM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:
> No, v3 fingerprints include the exponent as well:
>
>  https://tools.ietf.org/html/rfc4880#section-12.2

Sorry, of course you're right. The exponent at the end actually makes
them much easier to forge (since it can be almost any number); you
don't need to perform any bignum muls if you use Steven's
chosen-prefix attack.


From dkg at fifthhorseman.net  Fri Oct 10 16:36:12 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 10 Oct 2014 10:36:12 -0400
Subject: [PATCH] Disable importing V3 public keys from keyservers
In-Reply-To: <CAA7UWsXn5=mapauUb_+KkDwn8_jd3kyOAk9woeWr0ohFHMvtcg@mail.gmail.com>
References: <CAA7UWsXLAUjT7XoL_mXT+mbAv=4aSjTcznpH0S7r4t49fOf=RQ@mail.gmail.com>
 <CAAu18heu-kV4xLge=M0Gyq6BQ6GR0A14cm_kvsyZ9U9TV=x5Rg@mail.gmail.com>
 <CAA7UWsXA2rPoZ264WnaEuNGCv+1Qw43BEZk3fjU3eKWdRr=K7Q@mail.gmail.com>
 <5437E7B4.1050407@fifthhorseman.net>
 <CAA7UWsUPE8P9rm1NUHNAZRwYF31dkW13bFw1ZCUEg=vLLWAzrA@mail.gmail.com>
 <5437ED64.9080900@fifthhorseman.net>
 <CAA7UWsXn5=mapauUb_+KkDwn8_jd3kyOAk9woeWr0ohFHMvtcg@mail.gmail.com>
Message-ID: <5437EEDC.80000@fifthhorseman.net>

On 10/10/2014 10:32 AM, David Leon Gil wrote:
> On Fri, Oct 10, 2014 at 10:29 AM, Daniel Kahn Gillmor
> <dkg at fifthhorseman.net> wrote:
>> No, v3 fingerprints include the exponent as well:
>>
>>  https://tools.ietf.org/html/rfc4880#section-12.2
> 
> Sorry, of course you're right. The exponent at the end actually makes
> them much easier to forge (since it can be almost any number); you
> don't need to perform any bignum muls if you use Steven's
> chosen-prefix attack.

of course, if you do this, the keyids won't match (it'd be even worse
than it already is if the exponent was placed in front of the modulus --
then it'd be trivial to spoof both at once!)

but anyway, v3 keys need to die already.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20141010/87ca6352/attachment.sig>

From coruus at gmail.com  Fri Oct 10 17:06:07 2014
From: coruus at gmail.com (David Leon Gil)
Date: Fri, 10 Oct 2014 11:06:07 -0400
Subject: 0xdeadbeef comes of age: making keysteak with GnuPG
Message-ID: <CAA7UWsWGJtQ111BJECd9fhdYp3drPU62c89c7S6tUSJs4gjDqg@mail.gmail.com>

Replying a little late to Thijs's message to oss-security. First:

"keysteak", a PoC keyserver-in-the-middle that generates fake V3
public keys with the same long keyid as V4 public keys requested from
a keyserver. It uses the classic 0xdeadbeef attack and a (novel?) V3
key/V4 signature  crossgrade.*) Available at:
https://github.com/coruus/cooperpair/tree/master/keysteak

As an example, a spoofed key for a Linux distro is attached. You can
confirm that the spoofed key is *not* the real key (which is available
at https://tails.boum.org/tails-signing.key) by doing either
       gpg2 --list-packets spoofed_tails.asc
or,
       mkdir test; chmod go-rwx test
       gpg2 --home ./test --import spoofed_tails.asc
       gpg2 --home ./test -k --fingerprint

* V3 signatures are not accepted without an explicit option in 2.1;
they produce a warning in 2.0 (and maybe recent 1.x as well).

(In summary: If you don't use the WoT, get OpenPGP keys via HTTPS.
E.g.: keybase.io or pgp.mit.edu (the latter thanks to Yan Zhu's
lobbying).)

Some details/comments:

Date: Mon, 1 Sep 2014 20:33:20 +0200
From: Thijs Kinkhorst <thijs at ...ian.org>
Subject: gpg blindly imports keys from keyserver responses

> It is however argued that . . . specifying the full fingerprint is a safe way to retreive
> a key for a known-good fingerprint. But this argument is again somewhat countered
> by an attack on V3 [fingerprints] making such a request dubious again.

This isn't quite right.

- V3 fingerprints are 16 bytes (32 hex digits) long; they're an MD5
digest of the RSA modulus.
- V4 fingerprints are 20 bytes (40 hex digits) long; they're an SHA1
digest of the public key packet (kind of).

So: V3 and V4 fingerprints are easily distinguishable. Long keyids aren't:

- V3 long keyids are 8 bytes long. They're the low 8 bytes of the RSA modulus.
- V4 long keyids are 8 bytes long. They're the low 8 bytes of the V4
fingerprint.

As Greg Rose demonstrated (and Paul Leyland had earlier noted)[1],
this makes it trivial to forge long V3 keyids: You can control up to
about half the bits of an RSA modulus without affecting the strength
of the resulting key.

Note: Once you have a key with a given 64-bit keyid in your keychain,
GnuPG will not import any other key with the same 64-bit keyid.[2]
Even if you specify the new key by fingerprint.

It's been 18 years since the 0xdeadbeef attack. Maybe it's time to
deprecate V3 OpenPGP keys?

(There's a discussion on gnupg-devel on this presently; I am hopeful...)

[1] Raph Levien's excellent explanation of the history and math of the
0xdeadbeef attack:
https://groups.google.com/forum/#!topic/sci.crypt/JSSM6NbfweQ

[2] Thus the spoofed key and the real key are a "cooper pair".
-------------- next part --------------
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2

mQIPA1IAAAAAAAEP+wTjDob0f11hgMumSe9OA3z05hFwsgDpr152QACoZYVt4rRp
YVqBFCv3cckvd6mgldmxe7MdSa5C+IgWRiMYt8xIJKCN4gF/tNumsOjshptVLkiO
bdb2XI+AqwuUbVIzNzKr+zYVhHOUwm87QA5HapVo1Mm4zE2i99YLV30BfDxQMQOV
Ux6cnxLicS6edSvHqwO0rlOJGwp8XJT/DLJvfmkdHtkv4FNLKDEHLhsC9xSnm5y6
hrkwghRDJO69NenJWJbqAK63NIEGZhdgyaFBwls3JDIqKPenOjORoybuqw69MPcM
snk3Z0cXHD+bHUPm0cQNhFiZYEWXQMjm9RTW5AvP0JeW2RFBPBzqtxUKntQBrdRF
GU8Voas9SXUyBiaebrx5wzFBzBjbKZByTOA3T90S5FKTWJ3l4FBfSsSVjT/4WXn4
4QF26ATy0iowAe4l/089mp7qzEKSLCmTQPhhcPz1gX9OZOpkgBBi7dm55R08OX5y
4W98nnSiPQXNVf5DRWmKuWmrJHY7xan2E1A19z+7R/mG3AxUKboNerl3mD+3vLmk
HAwZKo0bA297oOhZAY4TXnUNhwLazcGIgctETfuw63HMNvj7hbYAoJb7ghH1cpw9
6NNrVOMoz6A6JFFUYz3L0GPkP/lCukn637Zy9uixBtzss/QyFhICghy+LNnBABEB
AAG0L1RhaWxzIGRldmVsb3BlcnMgKHNpZ25pbmcga2V5KSA8dGFpbHNAYm91bS5v
cmc+iQI3BBMBCgAhBQJUNrtTAhsDBQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAAoJ
EBICghy+LNnBz6YP+gLUXsvi+4IwNxTt/8yQWAwo5C7yVYq4t7X4Z9LTU/v4BQ2u
Ogs2E+E8Jd4u9bpTk9RWxg+wc3dm9BpsM3Mfsk23ryO6xqVS2/s+OiKMlK8C6QUT
shGw2Kd7FwbSUEHvzSO7f6oIpWs0HC/B1DNsIYCVMHj9xWHOF6osYkumVikVlYzJ
70dNlDNFvLiOR2kmneZ/8/q8NAcBLmPknE/m9iV9QBb4a8UIWhqbrUPoF5MKilCG
FgJW85pzWT9Q9SPlwvE7+UqrSBiRmG6EFKWFqGf4bPXZBaBsDHxBcc+UOGQDwHD7
3KfYV5arB6LdNPiF1eeJPscJxmIf6H9PNZ2DDU6BDmN6wK+L8V2fDo4TlLsWGOKH
rY8Ga6G0xuGWvIb5uL4nShMkF3E4PP3Z00mawx/cVQbrrH8UY4F51y9WKBRzdbw9
BuCzKBXxkymHVR3V01mEzBLVb80iBFBcOpyS/U66Dk6VsvtCF1g8JnxeRlg/UENp
+G6vdSUYKQdxQmY5Imlw64ote8/SHxAPlGnWBmT3eBsqaJpwV84zlBEncZS/WcCr
Gn+EzVr0MqRG8DvOfgqsBcgoxhUxldtqsOqTHBLjgwdOHIJnEv3nfEDus8PtMFZk
s3ixRFVikd0LSKV/F+02iEDLXQRIsha5Fb5BGodkr/IlaZhLYtqXaReLkKhQ
=PPAV
-----END PGP PUBLIC KEY BLOCK-----

From dkg at fifthhorseman.net  Fri Oct 10 17:47:28 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 10 Oct 2014 11:47:28 -0400
Subject: 0xdeadbeef comes of age: making keysteak with GnuPG
In-Reply-To: <CAA7UWsWGJtQ111BJECd9fhdYp3drPU62c89c7S6tUSJs4gjDqg@mail.gmail.com>
References: <CAA7UWsWGJtQ111BJECd9fhdYp3drPU62c89c7S6tUSJs4gjDqg@mail.gmail.com>
Message-ID: <5437FF90.7030404@fifthhorseman.net>

On 10/10/2014 11:06 AM, David Leon Gil wrote:
> (In summary: If you don't use the WoT, get OpenPGP keys via HTTPS.
> E.g.: keybase.io or pgp.mit.edu (the latter thanks to Yan Zhu's
> lobbying).)

If we're going to advocate for accessing keyservers via https (which i
think is a lovely idea, even if it doesn't mitigate all possible
attacks), it's worth advocating for the well-curated
hkps.pool.sks-keyservers.net [0], rather than encouraging everyone to
flood either https://keybase.io or https://pgp.mit.edu with traffic.

I agree with David and Thijs that OpenPGP v3 keys are long overdue for
the chopping block.

	--dkg

[0] https://sks-keyservers.net/overview-of-pools.php#pool_hkps

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20141010/f8a5409a/attachment.sig>

From coruus at gmail.com  Fri Oct 10 18:01:52 2014
From: coruus at gmail.com (David Leon Gil)
Date: Fri, 10 Oct 2014 12:01:52 -0400
Subject: 0xdeadbeef comes of age: making keysteak with GnuPG
In-Reply-To: <5437FF90.7030404@fifthhorseman.net>
References: <CAA7UWsWGJtQ111BJECd9fhdYp3drPU62c89c7S6tUSJs4gjDqg@mail.gmail.com>
 <5437FF90.7030404@fifthhorseman.net>
Message-ID: <CAA7UWsXsgRg7tODj4AZddz38hnQcNTwPu5PV0oX77GZ1K1RY0g@mail.gmail.com>

On Fri, Oct 10, 2014 at 11:47 AM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:
> If we're going to advocate for accessing keyservers via https (which i
> think is a lovely idea, even if it doesn't mitigate all possible
> attacks), it's worth advocating for the well-curated
> hkps.pool.sks-keyservers.net [0], rather than encouraging everyone to
> flood either https://keybase.io or https://pgp.mit.edu with traffic.

My problem with the HKPS pool is that I don't know Kristian.[1] And I
don't have any reason to believe that he'd suffer serious financial
damage if the private key for the "sks-keyservers.net CA" got used
maliciously.[2]

(While I know that if a root CA were caught intentionally issuing an
MitM cert for keybase.io or pgp.mit.edu would face likely
delisting/bankruptcy.)

I'd be really happy if Kristian published a GPG-signed log of every
valid certificate for servers in the HKPS pool; then it would be
possible for the distrustful -- or targeted -- to, say, query multiple
HKPS keyservers. This is even better than trusting Root CAs +
Kristian.[3])

[1] Most hkps.pool.sks-keyservers.net don't have an alternative trust
path to a standard root CA.

[2] This is different from saying that I think he *would
intentionally* sign a malicious cert, which I don't. I just have no
idea how secure the private key for that CA is. And I know that a
fully isolated, physically secure facility, and a good HSM are really
expensive. (But maybe he is doing this?)

[3] If this is already available somewhere, apologies; I haven't
managed to find anything like it.


From dkg at fifthhorseman.net  Fri Oct 10 18:23:57 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 10 Oct 2014 12:23:57 -0400
Subject: 0xdeadbeef comes of age: making keysteak with GnuPG
In-Reply-To: <CAA7UWsXsgRg7tODj4AZddz38hnQcNTwPu5PV0oX77GZ1K1RY0g@mail.gmail.com>
References: <CAA7UWsWGJtQ111BJECd9fhdYp3drPU62c89c7S6tUSJs4gjDqg@mail.gmail.com>
 <5437FF90.7030404@fifthhorseman.net>
 <CAA7UWsXsgRg7tODj4AZddz38hnQcNTwPu5PV0oX77GZ1K1RY0g@mail.gmail.com>
Message-ID: <5438081D.1080606@fifthhorseman.net>

On 10/10/2014 12:01 PM, David Leon Gil wrote:
> (While I know that if a root CA were caught intentionally issuing an
> MitM cert for keybase.io or pgp.mit.edu would face likely
> delisting/bankruptcy.)

I'd like to believe that also, but i think that some of the members of
the CA cartel might be "too big to fail" in the current infrastructure.
 There's no chance that the CA will go bankrupt if they aren't delisted
(since the CA market is a lemon market), and every web site certified by
the bigger CAs has an incentive to argue against that CAs' delisting
(because it will break their web site).

And you're still relying on the targeted keyserver operators themselves
to resist malicious intrusions on their keyservers (whether via legal or
financial or technical coercion).

Furthermore, pointing everyone at one or two servers which may not have
the capacity to withstand heavy load (or reliable uptime) runs the risk
of DoS of all those users, and increases the likelihood that OpenPGP
certificates simply won't get updated when those heavily-targeted
machines go down.

For years, a lot of people suggested pgp.mit.edu because it was
well-known, short, and easy to transmit.  in practice, pgp.mit.edu was
often bogged down, and wasn't even brought up to a recent version of the
modern keyserver implementation (sks) until sometime last year, i think.
 (many thanks to the current pgp.mit.edu admins, btw, who appear to be
currently doing a great job and providing an often-unappreciated public
service!)

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20141010/ac3c4f80/attachment.sig>

From kristian.fiskerstrand at sumptuouscapital.com  Fri Oct 10 18:27:31 2014
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Fri, 10 Oct 2014 18:27:31 +0200
Subject: 0xdeadbeef comes of age: making keysteak with GnuPG
In-Reply-To: <CAA7UWsXsgRg7tODj4AZddz38hnQcNTwPu5PV0oX77GZ1K1RY0g@mail.gmail.com>
References: <CAA7UWsWGJtQ111BJECd9fhdYp3drPU62c89c7S6tUSJs4gjDqg@mail.gmail.com>
 <5437FF90.7030404@fifthhorseman.net>
 <CAA7UWsXsgRg7tODj4AZddz38hnQcNTwPu5PV0oX77GZ1K1RY0g@mail.gmail.com>
Message-ID: <543808F3.7070103@sumptuouscapital.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 10/10/2014 06:01 PM, David Leon Gil wrote:
> On Fri, Oct 10, 2014 at 11:47 AM, Daniel Kahn Gillmor 
> <dkg at fifthhorseman.net> wrote:
>> If we're going to advocate for accessing keyservers via https
>> (which i think is a lovely idea, even if it doesn't mitigate all
>> possible attacks), it's worth advocating for the well-curated 
>> hkps.pool.sks-keyservers.net [0], rather than encouraging
>> everyone to flood either https://keybase.io or
>> https://pgp.mit.edu with traffic.
> 
> My problem with the HKPS pool is that I don't know Kristian.[1] And
> I don't have any reason to believe that he'd suffer serious
> financial damage if the private key for the "sks-keyservers.net CA"
> got used maliciously.[2]

You are quite correct that I probably wouldn't, and my primary income
is from another industry, but at the same time that does bring a
protection as I wouldn't be discouraged to fight any oppression. Of
course, you can't know my motives and integrity, which is a very fair
argument.

> 
> (While I know that if a root CA were caught intentionally issuing
> an MitM cert for keybase.io or pgp.mit.edu would face likely 
> delisting/bankruptcy.)

The cases we've seen where this happens (turktrust, diginotar) doesn't
really speak to a large financial hit either. Although for the root
CAs the major problem is simply the amount of CAs accepted by standard
implementations, several of which are run by various governments. In
the end it comes down to what the threat model is and whom you're
protecting yourself from.

Currently the only criteria for whether someone gets a certificate for
a server in the pool is based on technical merits and that they are in
control of the server in question. If no such agency were to run a
perfectly valid keyserver under a pseudonym it would not be part of
the current model to exclude this keyserver. However the goal is
primarily to avoid information leakage on transport, in particular
during a refresh of the keyring.

I certainly wouldn't mind coming to the point to have verified each
keyserver operator's identity before issuing a certificate, but we're
not there yet. This might change over time as things mature, but that
is the status today.

> 
> I'd be really happy if Kristian published a GPG-signed log of
> every valid certificate for servers in the HKPS pool; then it would
> be possible for the distrustful -- or targeted -- to, say, query
> multiple HKPS keyservers. This is even better than trusting Root
> CAs + Kristian.[3])

This is certainly something I can consider if there is a wish for it
in the community. But mainly you will see the servers included with a
HKPS flag in the status page of the pool[0] as I wouldn't sign a
server not included here. You'll run into a catch-22 here as well, as
you'd (i) need to have a valid OpenPGP trust path (ii) trust that the
information I provide in that log is accurate. As I use sequential
serial-numbers, the latter should be possible, but in theory I could
generate an out-of-scope certificate and choose not to include it in
that log. So the question boils down to trust in the first place. For
better or for worse.

> 
> [1] Most hkps.pool.sks-keyservers.net don't have an alternative
> trust path to a standard root CA.

Is this really something we wish to have, given the lack of
credibility of the global PKIX model? It is also one of the purposes
of the more user-controlled web of trust possibilities (both due to
everyone being their own CA, or through explicitly granting others
this trust) of OpenPGP that we're tryign to operate in. So personally
I'm more focused on the possibility to verify operators and indeed the
CA through this protocol. That said I'm making an effort to create
better trust paths to my own OpenPGP key that signs the X.509 CA key
in the first place.

> 
> [2] This is different from saying that I think he *would 
> intentionally* sign a malicious cert, which I don't. I just have
> no idea how secure the private key for that CA is. And I know that
> a fully isolated, physically secure facility, and a good HSM are
> really expensive. (But maybe he is doing this?)

Sorry, but no, I don't keep it in a physical facility, it is on an
older laptop used for such operations.

Hardware modules I don't necessarily believe to be any better for
security as verifying the firmware brings its own set of problems, but
that is a discussion out of scope for this thread.

> 
> [3] If this is already available somewhere, apologies; I haven't 
> managed to find anything like it.
> 


References:
[0] https://sks-keyservers.net/status/

- -- 
- ----------------------------
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
- ----------------------------
"Expect the best. Prepare for the worst. Capitalize on what comes."
(Zig Ziglar)
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUOAjsAAoJEPw7F94F4TagRtMQAK00DJRqXRpXum3Cz1Uv+TVX
W72mZWheeek8nW6B66dMSPi46FetpXn8h80gs2YGvke7OeauDnmpxz74AmeghiZS
H0dhCutVl7m7PH7d0DPrgczBifHgj9+9kJFS+/RJh/BH0ptCkUg7aG/97HSPLDnJ
4pqPHanp8glyciobJn+Oo1FNVD0JmcqGB1TLA74g7EruGcwshZYF8dlW0ZjJGWj4
f4Zo6sG5jTc3Hr0lpYeFcCZd/zCFMfgiJpBdr0QD8Ux6iljvDv5uKAf9NSiXOfbm
JePd/Psbix8x9qe67rTP8+5uBJQHeH3pTbGHSAfGmM+rHglz5Q27Dkk241r2xRU/
VOgsPwHAvPuLyz3JWoP+6oGQbtmmpuze1XI6nplJ+tO/2bBvcWRTDV/S6SlBEUA5
n9TwwNqaGLO/RUfwnpQZGN/WwLfyb5lZ9GdxGtlppdnV1vj3J5OxhDmup3bDXrYg
ThrZza7xz8mvgwex8IoPsl8gGiiHETlahBHexSiyYGcKrEeA8XZrP3+RlRfogr7g
jvAzCqbAv21r5GRMUznjoQ2Fl8eDJ5TIzSO9YVZ+oY2/RomZXl9C/2B5akEYBw/U
6yJkSMfBsphfV3CC/NrvB90BDR62MDbJPjQJ3af6uV4icSoseuwrVKNbYUQsgx5a
FQj/hCmmCeGrTF2/d0T2
=vy6k
-----END PGP SIGNATURE-----


From dkg at fifthhorseman.net  Fri Oct 10 18:37:28 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 10 Oct 2014 12:37:28 -0400
Subject: [oss-security] Re: 0xdeadbeef comes of age: making
 keysteak with GnuPG
In-Reply-To: <5438081D.1080606@fifthhorseman.net>
References: <CAA7UWsWGJtQ111BJECd9fhdYp3drPU62c89c7S6tUSJs4gjDqg@mail.gmail.com>
 <5437FF90.7030404@fifthhorseman.net>
 <CAA7UWsXsgRg7tODj4AZddz38hnQcNTwPu5PV0oX77GZ1K1RY0g@mail.gmail.com>
 <5438081D.1080606@fifthhorseman.net>
Message-ID: <54380B48.9060501@fifthhorseman.net>

On 10/10/2014 12:23 PM, Daniel Kahn Gillmor wrote:
> On 10/10/2014 12:01 PM, David Leon Gil wrote:
>> > (While I know that if a root CA were caught intentionally issuing an
>> > MitM cert for keybase.io or pgp.mit.edu would face likely
>> > delisting/bankruptcy.)
> I'd like to believe that also, but i think that some of the members of
> the CA cartel might be "too big to fail" in the current infrastructure.
>  There's no chance that the CA will go bankrupt if they aren't delisted
> (since the CA market is a lemon market), and every web site certified by
> the bigger CAs has an incentive to argue against that CAs' delisting
> (because it will break their web site).

And, even when we can burn a small CA, the larger organization often
carries on unharmed:

  http://www.links.org/?p=1268

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20141010/9d9dadd8/attachment.sig>

From wk at gnupg.org  Fri Oct 10 19:34:00 2014
From: wk at gnupg.org (Werner Koch)
Date: Fri, 10 Oct 2014 19:34:00 +0200
Subject: [PATCH] Disable importing V3 public keys from keyservers
In-Reply-To: <5437EEDC.80000@fifthhorseman.net> (Daniel Kahn Gillmor's message
 of "Fri, 10 Oct 2014 10:36:12 -0400")
References: <CAA7UWsXLAUjT7XoL_mXT+mbAv=4aSjTcznpH0S7r4t49fOf=RQ@mail.gmail.com>
 <CAAu18heu-kV4xLge=M0Gyq6BQ6GR0A14cm_kvsyZ9U9TV=x5Rg@mail.gmail.com>
 <CAA7UWsXA2rPoZ264WnaEuNGCv+1Qw43BEZk3fjU3eKWdRr=K7Q@mail.gmail.com>
 <5437E7B4.1050407@fifthhorseman.net>
 <CAA7UWsUPE8P9rm1NUHNAZRwYF31dkW13bFw1ZCUEg=vLLWAzrA@mail.gmail.com>
 <5437ED64.9080900@fifthhorseman.net>
 <CAA7UWsXn5=mapauUb_+KkDwn8_jd3kyOAk9woeWr0ohFHMvtcg@mail.gmail.com>
 <5437EEDC.80000@fifthhorseman.net>
Message-ID: <87k34725iv.fsf@vigenere.g10code.de>

On Fri, 10 Oct 2014 16:36, dkg at fifthhorseman.net said:

> but anyway, v3 keys need to die already.

Tell that the people who complained for years about the missing IDEA and
PGP2 support for their v3 keys.  Apparently they want to be able to read
their old messages - which I can understand.

Thus there is no way to get rid of v3 anytime soon - well unless we
declare that all v3 support will be removed from GnuPG-2 and those who
have not come around to re-encrypt their old stuff need to use 1.4.
This is worth a discussion.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From dkg at fifthhorseman.net  Fri Oct 10 19:42:43 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 10 Oct 2014 13:42:43 -0400
Subject: [PATCH] Disable importing V3 public keys from keyservers
In-Reply-To: <87k34725iv.fsf@vigenere.g10code.de>
References: <CAA7UWsXLAUjT7XoL_mXT+mbAv=4aSjTcznpH0S7r4t49fOf=RQ@mail.gmail.com>	<CAAu18heu-kV4xLge=M0Gyq6BQ6GR0A14cm_kvsyZ9U9TV=x5Rg@mail.gmail.com>	<CAA7UWsXA2rPoZ264WnaEuNGCv+1Qw43BEZk3fjU3eKWdRr=K7Q@mail.gmail.com>	<5437E7B4.1050407@fifthhorseman.net>	<CAA7UWsUPE8P9rm1NUHNAZRwYF31dkW13bFw1ZCUEg=vLLWAzrA@mail.gmail.com>	<5437ED64.9080900@fifthhorseman.net>	<CAA7UWsXn5=mapauUb_+KkDwn8_jd3kyOAk9woeWr0ohFHMvtcg@mail.gmail.com>	<5437EEDC.80000@fifthhorseman.net>
 <87k34725iv.fsf@vigenere.g10code.de>
Message-ID: <54381A93.5050101@fifthhorseman.net>

On 10/10/2014 01:34 PM, Werner Koch wrote:
> On Fri, 10 Oct 2014 16:36, dkg at fifthhorseman.net said:
> 
>> but anyway, v3 keys need to die already.
> 
> Tell that the people who complained for years about the missing IDEA and
> PGP2 support for their v3 keys.  Apparently they want to be able to read
> their old messages - which I can understand.

sure, i can understand that, and maybe i should temper my earlier remark.

how about "v3 public keys for which you do not have the secret part need
to die already"?

This would mean that v3 signatures couldn't be checked (except by people
who control the given key).  but no one should probably be relying on v3
signatures anyway, since they're all MD5-based.

> Thus there is no way to get rid of v3 anytime soon - well unless we
> declare that all v3 support will be removed from GnuPG-2 and those who
> have not come around to re-encrypt their old stuff need to use 1.4.
> This is worth a discussion.

That's more radical than what i wrote above, but i think i wouldn't mind
doing it.

People who really want to dig back through an old encrypted archive that
they haven't re-encrypted can always build from older source
specifically for their re-encryption stage.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20141010/1962515a/attachment-0001.sig>

From kristian.fiskerstrand at sumptuouscapital.com  Fri Oct 10 19:41:14 2014
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Fri, 10 Oct 2014 19:41:14 +0200
Subject: [PATCH] Disable importing V3 public keys from keyservers
In-Reply-To: <87k34725iv.fsf@vigenere.g10code.de>
References: <CAA7UWsXLAUjT7XoL_mXT+mbAv=4aSjTcznpH0S7r4t49fOf=RQ@mail.gmail.com>
 <CAAu18heu-kV4xLge=M0Gyq6BQ6GR0A14cm_kvsyZ9U9TV=x5Rg@mail.gmail.com>
 <CAA7UWsXA2rPoZ264WnaEuNGCv+1Qw43BEZk3fjU3eKWdRr=K7Q@mail.gmail.com>
 <5437E7B4.1050407@fifthhorseman.net>
 <CAA7UWsUPE8P9rm1NUHNAZRwYF31dkW13bFw1ZCUEg=vLLWAzrA@mail.gmail.com>
 <5437ED64.9080900@fifthhorseman.net>
 <CAA7UWsXn5=mapauUb_+KkDwn8_jd3kyOAk9woeWr0ohFHMvtcg@mail.gmail.com>
 <5437EEDC.80000@fifthhorseman.net> <87k34725iv.fsf@vigenere.g10code.de>
Message-ID: <54381A3A.9060409@sumptuouscapital.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 10/10/2014 07:34 PM, Werner Koch wrote:
> On Fri, 10 Oct 2014 16:36, dkg at fifthhorseman.net said:
> 
>> but anyway, v3 keys need to die already.
> 
> Tell that the people who complained for years about the missing
> IDEA and PGP2 support for their v3 keys.  Apparently they want to
> be able to read their old messages - which I can understand.

Indeed, and I used to be one myself [0], but see below for further
comments.

> 
> Thus there is no way to get rid of v3 anytime soon - well unless
> we declare that all v3 support will be removed from GnuPG-2 and
> those who have not come around to re-encrypt their old stuff need
> to use 1.4. This is worth a discussion.

I second removing support for V3 wherever possible. And to the
opposite only enable it upon explicit configuration option, but
primarily just remove the thing as they represent <5% of the available
public keys[1] while weakening the WoT for everyone, and that numberr
is before taking into consideration people moving away from these keys
in the first place. In particular, remove support in gnupg 2.1.

References:
[0] http://www.kfwebs.net/articles/article/42/GnuPG-2.0---IDEA-support
[1] http://blog.sumptuouscapital.com/2014/01/openpgp-key-statistics/

- -- 
- ----------------------------
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
- ----------------------------
Audaces fortuna iuvat
Fortune favors the brave
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUOBo5AAoJEPw7F94F4Tag2YcP/RFS18GYC5YKPZ4ODz4aIIHP
f3cuCrjzbNbOL0s+2R4eXTdz+bBZlWDCnEPLwKHKcdAS3BIJ5Kso1hsCFB9Ei7y/
usazhNU+ZQimdt/wr7Omjj+k/0HQGRfJjwSqvk/g8M44u0CYzbGszDqTxDL0S2jR
j54lx3GEIlct1Jv/71D2kShmCvvkQiwEdNRuqVj2rJvxPo5TD5Ssx52GPdExRslG
Lgz7u/eOPldEREgse9cVow+cKoHNgkdY8luk9k2xnBI+Z/RpY6r/djDdxnVl+Dpu
syTTdQku9u3J3rBz1OA0avPauKJ0PUtkRRnHZGCY+KBQAeaaAA1fSl5ZAApOX486
IJxZZBf4d+GhGdMgRxBt3et6M0ZE1Z8O/tVMo9I2VQa8sPMLHJO+0nRI3f7IdUr+
6b4FCAQapLHIHQ8TTQCgW1M7YE8MSdxY8QzZuTrycG43n+GnbIhsavOzvPeLb9E7
FFNQbNBofmup6rgqxk4nuLjNFlntfxqjXrJf2DyG1t3/5w+tkA8YxKeaqBd7ezto
TZm0rU49xqK7DlyuJgLKjq+mX77aR+UCS5OCByNtFnFSkHJkTEkKF7tCuYCbysuM
AmD7fz10L+uO7S7BMv11KDBnvbi0hT1kQoMmewDFqf/AhuDrklzgSgNt6o3FJkA3
i0/sJAB+tg/+QIiBanar
=lNV8
-----END PGP SIGNATURE-----


From wk at gnupg.org  Fri Oct 10 20:13:00 2014
From: wk at gnupg.org (Werner Koch)
Date: Fri, 10 Oct 2014 20:13:00 +0200
Subject: Disable importing V3 public keys from keyservers
In-Reply-To: <CAA7UWsVe_StEdh2nmWOo3EY9MCk=NhAG3Fsf4bXtF1XXrzCMFg@mail.gmail.com>
 (David Leon Gil's message of "Fri, 10 Oct 2014 09:41:21 -0400")
References: <CAA7UWsXLAUjT7XoL_mXT+mbAv=4aSjTcznpH0S7r4t49fOf=RQ@mail.gmail.com>
 <87tx3c2tsk.fsf@vigenere.g10code.de>
 <CAA7UWsVe_StEdh2nmWOo3EY9MCk=NhAG3Fsf4bXtF1XXrzCMFg@mail.gmail.com>
Message-ID: <87fvev23pv.fsf_-_@vigenere.g10code.de>

On Fri, 10 Oct 2014 15:41, coruus at gmail.com said:

> I don't think that this is, in fact, correct. Using default settings
> (by creating a new blank home directory), GnuPG 2.0.26 (and 1.0.18)
> will import V3 keys from keyservers. (Note: my test keys have V4
> signatures.)

Sure, gpg will import those keys - but they are not usable:

  $ ~/b/gnupg-2.0/g10/gpg2 --fingerprint 
  gpg: keyring `/home/wk/b/gnupg/tmp2/pubring.gpg' created
  gpg: /home/wk/b/gnupg/tmp2/trustdb.gpg: trustdb created

This is using 2.0 HEAD with devevelopment warning notices removed and
running under a 2.1 agent.
  
  $ ~/b/gnupg-2.0/g10/gpg2 --import foo.keys 
  gpg: keyring `/home/wk/b/gnupg/tmp2/secring.gpg' created
  gpg: key 1E42B367: public key "Werner Koch <wk at gnupg.org>" imported
  gpg: key BE2CD9C1: public key "Tails developers (signing key) <tails at boum.org>" imported
  gpg: Total number processed: 2
  gpg:               imported: 2  (RSA: 2)
  
Imported as expected.  Lets look at the keys:

  $ ~/b/gnupg-2.0/g10/gpg2 --fingerprint     
  /home/wk/b/gnupg/tmp2/pubring.gpg
  ---------------------------------
  pub   4093R/1E42B367 2013-08-05
        Key fingerprint = EE B9 99 D0 78 3A 36 C8  90 8A 0B A0 72 82 93 F2
  uid       [ unknown] Werner Koch <wk at gnupg.org>
  
  pub   4091R/BE2CD9C1 2013-08-05
        Key fingerprint = DB A5 C7 C2 62 21 16 25  A9 A5 59 ED 42 5D 7D 99
  uid       [ unknown] Tails developers (signing key) <tails at boum.org>
  
Aihh, those old broken v3 keys.  The usual practice of checking creation
date and key length in addition to the fingerprint comes to mind of old
timers.  Everyone else wonders why this fingerprint does not match the
one on the business card etc and why it is formatted in that strange
way.  But well, if that guy want me to encrypt to this key let's do it:

  $ fortune | ~/b/gnupg-2.0/g10/gpg2 --no-encrypt-to -vear 1E42B367 
  gpg: 1E42B367: skipped: Unusable public key
  gpg: [stdin]: encryption failed: Unusable public key
  
Ooops.  Now to make it even more clear to newbies I propose a change
which leads to 

  $ ~/b/gnupg-2.0/g10/gpg2 --fingerprint 
  /home/wk/b/gnupg/tmp2/pubring.gpg
  ---------------------------------
  pub   4093R/1E42B367 2013-08-05
        Key fingerprint = 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
  uid       [ unknown] Werner Koch <wk at gnupg.org>
  
  pub   4091R/BE2CD9C1 2013-08-05
        Key fingerprint = 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
  uid       [ unknown] Tails developers (signing key) <tails at boum.org>
  
That should make it pretty clear that there is something wrong with the
key.

> If the current behavior isn't the intended one (particularly for
> import via --import), then this may be CVE-worthy; it's a classic
> protocol-format crossgrade.

No it is not: You accept an arbitrary key without checking the
fingerprint (direct or via the WoT) - any responsible user won't let you
use his old v3 key.  But to make it easier to notice a v3 key, I suggest
to do the above change (--allow-weak-digest-algos will revert that of
course).

> Is there any way to disable it completely? Only some operations seem
> to warn when using MD5.

I can't see that there is only a warning.

> (Note: I may be missing something in the code of GnuPG 2.1; I'm

The above is 2.0 and the MD5 rejection is there since 2.0.23 (June this
year).  2.1 is similar.  1.4 has only a warning.

> I'd rather see V3 import from external sources -- even for key refresh
> -- disabled entirely. There's some other code that could be removed in

This whole thing has nothing to do with keyservers or import.  The whole
idea of putting any trust in the source of the key is broken.

The real bug with faked keys is that they will clog the keyring because
we take the first matching _keyid_.  But the very same problem exists
with v4 keys.  Indeed, we better fix that problem for 2.1.0.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From wk at gnupg.org  Fri Oct 10 20:28:03 2014
From: wk at gnupg.org (Werner Koch)
Date: Fri, 10 Oct 2014 20:28:03 +0200
Subject: 0xdeadbeef comes of age: making keysteak with GnuPG
In-Reply-To: <CAA7UWsXsgRg7tODj4AZddz38hnQcNTwPu5PV0oX77GZ1K1RY0g@mail.gmail.com>
 (David Leon Gil's message of "Fri, 10 Oct 2014 12:01:52 -0400")
References: <CAA7UWsWGJtQ111BJECd9fhdYp3drPU62c89c7S6tUSJs4gjDqg@mail.gmail.com>
 <5437FF90.7030404@fifthhorseman.net>
 <CAA7UWsXsgRg7tODj4AZddz38hnQcNTwPu5PV0oX77GZ1K1RY0g@mail.gmail.com>
Message-ID: <874mvb230s.fsf@vigenere.g10code.de>

On Fri, 10 Oct 2014 18:01, coruus at gmail.com said:

> My problem with the HKPS pool is that I don't know Kristian.[1] And I
> don't have any reason to believe that he'd suffer serious financial

X.509 is entirely broken and we can't do anything about it.  However, it
gives you some assurance that it is harder to read the requests.  But it
is not really hard, they just need to compromise a few well known
keyservers.  Let's use hkps to raise the surveilance costs - that is
worth the little trouble.

But do not trust any keyserver!  Use your own way to validate the key.

> [2] This is different from saying that I think he *would
> intentionally* sign a malicious cert, which I don't. I just have no
> idea how secure the private key for that CA is. And I know that a
> fully isolated, physically secure facility, and a good HSM are really
> expensive. (But maybe he is doing this?)

Why attacking a certain "high-security" CA if you can easily convice
another of the 1300 (?) primary root CAs to issue a certifciate to your
needs.

BTW: Using a pool with 2.1 will be more reliable because 2.1 tracks
failures of the current server and switches to another one in that
case.  Thus you do not need to rely on the DNS round-robin.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From coruus at gmail.com  Fri Oct 10 20:47:36 2014
From: coruus at gmail.com (David Leon Gil)
Date: Fri, 10 Oct 2014 14:47:36 -0400
Subject: Disable importing V3 public keys from keyservers
In-Reply-To: <87fvev23pv.fsf_-_@vigenere.g10code.de>
References: <CAA7UWsXLAUjT7XoL_mXT+mbAv=4aSjTcznpH0S7r4t49fOf=RQ@mail.gmail.com>
 <87tx3c2tsk.fsf@vigenere.g10code.de>
 <CAA7UWsVe_StEdh2nmWOo3EY9MCk=NhAG3Fsf4bXtF1XXrzCMFg@mail.gmail.com>
 <87fvev23pv.fsf_-_@vigenere.g10code.de>
Message-ID: <CAA7UWsV=oQKdVtUiBnfhSNdMui+KTW1FyVj-briEB=nQ6EoKpw@mail.gmail.com>

On Fri, Oct 10, 2014 at 2:13 PM, Werner Koch <wk at gnupg.org> wrote:
> Sure, gpg will import those keys - but they are not usable:

The reason GnuPG can't encrypt to those keys is because the signature
packet does not have the "encrypt" key usage flag set, as doing gpg
--list-packets would show you. (I didn't set these flags in the sample
code so that people wouldn't inadvertently encrypt to these spoofed
keys.)

If I set those bits, this works:

     gpg2 --home ./test --keyserver 127.0.0.1 -r wk at gnupg.org  -e
test/pubring.gpg
    gpg: 621CC013: There is no assurance this key belongs to the named user

    pub  3839R/621CC013 2013-08-05 Werner Koch <wk at gnupg.org>
    Primary key fingerprint: F5 05 05 91 B3 2C F2 E2  DB 25 4C 41 D4 16 4A 13

(It obviously isn't your key: it's >> 2048 bits.)

Attached. Try it for yourself.

> The real bug with faked keys is that they will clog the keyring because
> we take the first matching _keyid_.  But the very same problem exists
> with v4 keys.  Indeed, we better fix that problem for 2.1.0.

Very much agree; this is why I'm particularly concerned about
keyservers. (It's just an easy way for anyone on a public wifi
network, say, to generate a key that will make verifying downloaded
software impossible for anyone without a lot of experience using
GnuPG.)

> Aihh, those old broken v3 keys.  The usual practice of checking creation
> date and key length in addition to the fingerprint comes to mind of old
> timers.

Agreed. Is showing fingerprints the default in 2.1.0 then? (Maybe this
could get added to point releases too.)
-------------- next part --------------
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2

mQHvA1IAAAAAAAEO/1bY5PWpst3uIuXFkn2VINXE/kY6geBXZEJFVv3IRtmrlIRL
wVBGNXYIv4h8Ra9WyaVcz11mI0e+EV0q6LVxao6tUfrTyPU01onWog+vczSHJrsR
JTrC/uVSUCj+FgZruWmM2sO90qtQqt61NEsDP55B0F4Vuf6Rii9rI0vjgZ0yOREg
V65PKWO4E3pMuIhqYqNYfOc6P+64ietlWf0cWbQPWeI5dRUL0VQsExWxl5NzDAkK
k2hjUOCqQsq8v42Ft25vR/ZrZF7XHpCt9v1pD5rtXu4H6uzCfj1+DA2vxrHd69PX
u5elDIWDA+6un8eeRfej3oCdc980gL6yNsz5O6tpq1VrJolcHZt2pkIM1S2XRAND
EmIHa+jtMGyGob9wzJoNUmD/qGX+ayjkSr/ldB4AxNl1UtXejzwA4V3K3Pkx7tjL
sLLl/2M/xBQhOfTA6m5AAt6bGtxnHxTFTwrTOmIU0Msqj5+VSFRIaldeTvaN4WtC
ToD+Fwimc8yi2jdVWGQF4iLa2SOFJEd+eWml5OvpGPJfyG4nv2ff6LfFKZ79vA0l
gw0iX/vEx1Fs7JqtZfawgdrf3WUZFrDnFu0rYKlVNPYPhOCKObtLbRHCXi9CmizY
7zjXo6RsfuG4YhzAEwARAQABtBpXZXJuZXIgS29jaCA8d2tAZ251cGcub3JnPokC
FwQTAQoAIQUCVDgoXQIbDwULCQgHAwUVCgkICwUWAgMAAAIeAQIXgAAKCRBsfuG4
YhzAExPWDv4j1/RBRoe6+F+dF3+ls1vsAnMXO0bgxwoRgIuDw8YG8q5K1CcGnu7t
2g4VT/sYeHnJp9TyFCwSps31TBsrZUNkMS/1NBEpalOK+E1sqjLn6twTgeh6b9o+
9Z8ZgmEvRIkxweEepQbqadk+xv9Y3qKUCx7k5igajv7osznfQcPIKUf0snC8Gpgi
DTVsU9b06Ehod/yvODjNU3PUdXv+Dx31uO9sKi0+TBnn5pm7h5DpuL2DnWZBsm0d
x82HeT6DYTPjhTRxiws/GnKB5WvE1O8veq2Ssa5wU/Lhuu7jN9ZgzY7fCSDYsdV/
m5Dg3LBA55+JBl0PbdF8hY6B74Xek6EV36pUxCGA+k0xuwu1qR0p7ojZN/X/ZYwt
4bgrGNh12YibNW7j3cmZ71KwObI92C/gWAKT7MVmsuRWwu2BjYja3jPsLLehxLeb
jDDZJbqeDzFM8jOlMH/M1OhJLNUuWmrlIr46tRZ7tZXlBib8tzpbTUHH/gltRILc
AKfaKbAe8bYQcO/odyxJKXU/HQZzEy8/RmLhrzIXWtHqW6+mHN20US1Mgx8VgM89
Z7ea0YexS+hoMl9pE7rVBuaDvj68J/qe5irXK+5i+cVHKPhlaAMtzVXrNg2i37cT
hrPQs0V1E2c=
=4dum
-----END PGP PUBLIC KEY BLOCK-----

From coruus at gmail.com  Fri Oct 10 21:15:46 2014
From: coruus at gmail.com (David Leon Gil)
Date: Fri, 10 Oct 2014 15:15:46 -0400
Subject: HKPS [was 0xdeadbeef]
Message-ID: <CAA7UWsW7jo9fE3NTv7QbRLHt33BpBPyuwX_b_2fU2P+Ce+P5ZQ@mail.gmail.com>

So this doesn't get lost: I'm convinced by dkg and Kristian's
arguments: Use hkps with hkps.pool.sks-keyservers.net

GnuPG 2.1 will ship with hkps enabled by default, I believe, and
Kristian's CA. (I don't think 2.0 does yet.)

On Fri, Oct 10, 2014 at 12:27 PM, Kristian Fiskerstrand
<kristian.fiskerstrand at sumptuouscapital.com> wrote:
> You are quite correct that I probably wouldn't, and my primary income
> is from another industry, but at the same time that does bring a
> protection as I wouldn't be discouraged to fight any oppression.

I do agree about that.

And, in fact: I failed to thank you! I've used the SKS pool you
operate for many years. You provide a critical public service.

> Although for the root
> CAs the major problem is simply the amount of CAs accepted by standard
> implementations, several of which are run by various governments. In
> the end it comes down to what the threat model is and whom you're
> protecting yourself from.

Very much agreed; my particular threat model for this *isn't*
protection against the NSA. (Aside from perhaps protection from
traffic analysis.) It's protection against much weaker threats.

> Currently the only criteria for whether someone gets a certificate for
> a server in the pool is based on technical merits . . .

One thing that one can do (which I do when I don't have a copy of a
key in one of my local keydumps) is use the strategy of Tor's
"tlsdate": use a set of servers which are unlikely to be controlled by
the same adversary.


From flapflap at riseup.net  Fri Oct 10 20:45:24 2014
From: flapflap at riseup.net (flapflap)
Date: Fri, 10 Oct 2014 18:45:24 +0000
Subject: [oss-security] Re: 0xdeadbeef comes of age: making keysteak with
 GnuPG
In-Reply-To: <54380B48.9060501@fifthhorseman.net>
References: <CAA7UWsWGJtQ111BJECd9fhdYp3drPU62c89c7S6tUSJs4gjDqg@mail.gmail.com>
 <5437FF90.7030404@fifthhorseman.net>
 <CAA7UWsXsgRg7tODj4AZddz38hnQcNTwPu5PV0oX77GZ1K1RY0g@mail.gmail.com>
 <5438081D.1080606@fifthhorseman.net> <54380B48.9060501@fifthhorseman.net>
Message-ID: <54382944.7090801@riseup.net>

Daniel Kahn Gillmor:
> On 10/10/2014 12:23 PM, Daniel Kahn Gillmor wrote:
>> On 10/10/2014 12:01 PM, David Leon Gil wrote:
>>>> (While I know that if a root CA were caught intentionally issuing an
>>>> MitM cert for keybase.io or pgp.mit.edu would face likely
>>>> delisting/bankruptcy.)
>> I'd like to believe that also, but i think that some of the members of
>> the CA cartel might be "too big to fail" in the current infrastructure.
>>  There's no chance that the CA will go bankrupt if they aren't delisted
>> (since the CA market is a lemon market), and every web site certified by
>> the bigger CAs has an incentive to argue against that CAs' delisting
>> (because it will break their web site).
> 
> And, even when we can burn a small CA, the larger organization often
> carries on unharmed:
> 
>   http://www.links.org/?p=1268
> 
> 	--dkg

if interested, see also
  https://en.wikipedia.org/wiki/Comodo_Group#Controversies
and about the first 12min of Moxie Marlinspike's talk (regarding COMODO)
  https://www.youtube.com/watch?v=Z7Wl2FW2TcA

~flapflap



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 630 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20141010/aa1d3251/attachment-0001.sig>

From djhaskin987 at gmail.com  Fri Oct 10 21:58:25 2014
From: djhaskin987 at gmail.com (Dan Haskin)
Date: Fri, 10 Oct 2014 13:58:25 -0600
Subject: Disable importing V3 public keys from keyservers
In-Reply-To: <CAA7UWsV=oQKdVtUiBnfhSNdMui+KTW1FyVj-briEB=nQ6EoKpw@mail.gmail.com>
References: <CAA7UWsXLAUjT7XoL_mXT+mbAv=4aSjTcznpH0S7r4t49fOf=RQ@mail.gmail.com>
 <87tx3c2tsk.fsf@vigenere.g10code.de>
 <CAA7UWsVe_StEdh2nmWOo3EY9MCk=NhAG3Fsf4bXtF1XXrzCMFg@mail.gmail.com>
 <87fvev23pv.fsf_-_@vigenere.g10code.de>
 <CAA7UWsV=oQKdVtUiBnfhSNdMui+KTW1FyVj-briEB=nQ6EoKpw@mail.gmail.com>
Message-ID: <CA+gNq50ii84uav4eObh4Zu8bSRnUM248oE=DTGcHQMna-Wx1JA@mail.gmail.com>

It seems to me that if people want to read their old mail, they can simply
use GPG 1.4 . It feels like a lot of effort is being put into making sure
2.1 (mostly) works with GPG 1.4 . Even if it doesn't, it would not be hard
for someone to use GPG 1.4 to import their old keys, decrypt their mail,
and encrypt it using a new home folder and a new, better key.

v3 was deprecated back in version 1.4. This is the way it works in most
modern software <http://semver.org/>: the old feature is deprecated back in
the previous major release (1), and is erased in the next major release
(2). The DEPRECATED message in 1.4 is clear. People therefore have known
that they should probably switch away from it.  Users have been given
adequate time to re-encrypt their old mail, since this deprecation was done
a long time ago. Further, 1.4 still works and is still actively maintained,
making it easy for them to re-encrypt their old mail even after the 2.1
release.  I feel like removing it completely in 2.1 is the way to go.

Daniel Jay Haskin
http://djhaskin987.github.io/

On Fri, Oct 10, 2014 at 12:47 PM, David Leon Gil <coruus at gmail.com> wrote:

> On Fri, Oct 10, 2014 at 2:13 PM, Werner Koch <wk at gnupg.org> wrote:
> > Sure, gpg will import those keys - but they are not usable:
>
> The reason GnuPG can't encrypt to those keys is because the signature
> packet does not have the "encrypt" key usage flag set, as doing gpg
> --list-packets would show you. (I didn't set these flags in the sample
> code so that people wouldn't inadvertently encrypt to these spoofed
> keys.)
>
> If I set those bits, this works:
>
>      gpg2 --home ./test --keyserver 127.0.0.1 -r wk at gnupg.org  -e
> test/pubring.gpg
>     gpg: 621CC013: There is no assurance this key belongs to the named user
>
>     pub  3839R/621CC013 2013-08-05 Werner Koch <wk at gnupg.org>
>     Primary key fingerprint: F5 05 05 91 B3 2C F2 E2  DB 25 4C 41 D4 16 4A
> 13
>
> (It obviously isn't your key: it's >> 2048 bits.)
>
> Attached. Try it for yourself.
>
> > The real bug with faked keys is that they will clog the keyring because
> > we take the first matching _keyid_.  But the very same problem exists
> > with v4 keys.  Indeed, we better fix that problem for 2.1.0.
>
> Very much agree; this is why I'm particularly concerned about
> keyservers. (It's just an easy way for anyone on a public wifi
> network, say, to generate a key that will make verifying downloaded
> software impossible for anyone without a lot of experience using
> GnuPG.)
>
> > Aihh, those old broken v3 keys.  The usual practice of checking creation
> > date and key length in addition to the fingerprint comes to mind of old
> > timers.
>
> Agreed. Is showing fingerprints the default in 2.1.0 then? (Maybe this
> could get added to point releases too.)
>
> _______________________________________________
> 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: </pipermail/attachments/20141010/00a7a6ad/attachment.html>

From wk at gnupg.org  Sat Oct 11 14:35:16 2014
From: wk at gnupg.org (Werner Koch)
Date: Sat, 11 Oct 2014 14:35:16 +0200
Subject: Removing v3 support from 2.1 (was: Disable importing V3 public keys
 from keyservers)
In-Reply-To: <CA+gNq50ii84uav4eObh4Zu8bSRnUM248oE=DTGcHQMna-Wx1JA@mail.gmail.com>
 (Dan Haskin's message of "Fri, 10 Oct 2014 13:58:25 -0600")
References: <CAA7UWsXLAUjT7XoL_mXT+mbAv=4aSjTcznpH0S7r4t49fOf=RQ@mail.gmail.com>
 <87tx3c2tsk.fsf@vigenere.g10code.de>
 <CAA7UWsVe_StEdh2nmWOo3EY9MCk=NhAG3Fsf4bXtF1XXrzCMFg@mail.gmail.com>
 <87fvev23pv.fsf_-_@vigenere.g10code.de>
 <CAA7UWsV=oQKdVtUiBnfhSNdMui+KTW1FyVj-briEB=nQ6EoKpw@mail.gmail.com>
 <CA+gNq50ii84uav4eObh4Zu8bSRnUM248oE=DTGcHQMna-Wx1JA@mail.gmail.com>
Message-ID: <878ukmzsvv.fsf_-_@vigenere.g10code.de>

On Fri, 10 Oct 2014 21:58, djhaskin987 at gmail.com said:

> release.  I feel like removing it completely in 2.1 is the way to go.

If my counting is correct, your are the third voice agerring to remove
all v3 support from 2.1.  I am also in favor of this.

Any contras?


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From wk at gnupg.org  Sat Oct 11 14:37:43 2014
From: wk at gnupg.org (Werner Koch)
Date: Sat, 11 Oct 2014 14:37:43 +0200
Subject: Disable importing V3 public keys from keyservers
In-Reply-To: <CAA7UWsV=oQKdVtUiBnfhSNdMui+KTW1FyVj-briEB=nQ6EoKpw@mail.gmail.com>
 (David Leon Gil's message of "Fri, 10 Oct 2014 14:47:36 -0400")
References: <CAA7UWsXLAUjT7XoL_mXT+mbAv=4aSjTcznpH0S7r4t49fOf=RQ@mail.gmail.com>
 <87tx3c2tsk.fsf@vigenere.g10code.de>
 <CAA7UWsVe_StEdh2nmWOo3EY9MCk=NhAG3Fsf4bXtF1XXrzCMFg@mail.gmail.com>
 <87fvev23pv.fsf_-_@vigenere.g10code.de>
 <CAA7UWsV=oQKdVtUiBnfhSNdMui+KTW1FyVj-briEB=nQ6EoKpw@mail.gmail.com>
Message-ID: <874mvazsrs.fsf@vigenere.g10code.de>

On Fri, 10 Oct 2014 20:47, coruus at gmail.com said:

> If I set those bits, this works:

Yes, due to the v4 self-signature.  But you can't use that key with pgp-2.

> Agreed. Is showing fingerprints the default in 2.1.0 then? (Maybe this
> could get added to point releases too.)

Not in the key listing.  The default is the to use the WoT and thus we
show the validity of the key now in the key listing by default.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From wk at gnupg.org  Sun Oct 12 20:29:14 2014
From: wk at gnupg.org (Werner Koch)
Date: Sun, 12 Oct 2014 20:29:14 +0200
Subject: Removing v3 support from 2.1
In-Reply-To: <878ukmzsvv.fsf_-_@vigenere.g10code.de> (Werner Koch's message of
 "Sat, 11 Oct 2014 14:35:16 +0200")
References: <CAA7UWsXLAUjT7XoL_mXT+mbAv=4aSjTcznpH0S7r4t49fOf=RQ@mail.gmail.com>
 <87tx3c2tsk.fsf@vigenere.g10code.de>
 <CAA7UWsVe_StEdh2nmWOo3EY9MCk=NhAG3Fsf4bXtF1XXrzCMFg@mail.gmail.com>
 <87fvev23pv.fsf_-_@vigenere.g10code.de>
 <CAA7UWsV=oQKdVtUiBnfhSNdMui+KTW1FyVj-briEB=nQ6EoKpw@mail.gmail.com>
 <CA+gNq50ii84uav4eObh4Zu8bSRnUM248oE=DTGcHQMna-Wx1JA@mail.gmail.com>
 <878ukmzsvv.fsf_-_@vigenere.g10code.de>
Message-ID: <87lholxhtx.fsf@vigenere.g10code.de>

Hi,

I removed all code pertaining to v3 keys and also forced using v4
signatures.  If you want to test this, please checkout the
"wk/test-master" branch.


commit bb961e062bbf1011ef3430afdf2075561ba400ab
Author: Werner Koch <wk at gnupg.org>
Date:   Sun Oct 12 20:07:12 2014 +0200

    gpg: Remove all support for v3 keys and always create v4-signatures.
    
    * g10/build-packet.c (do_key): Remove support for building v3 keys.
    * g10/parse-packet.c (read_protected_v3_mpi): Remove.
    (parse_key): Remove support for v3-keys.  Add dedicated warnings for
    v3-key packets.
    * g10/keyid.c (hash_public_key): Remove v3-key support.
    (keyid_from_pk): Ditto.
    (fingerprint_from_pk): Ditto.
    
    * g10/options.h (opt): Remove fields force_v3_sigs and force_v4_certs.
    * g10/gpg.c (cmd_and_opt_values): Remove oForceV3Sigs, oNoForceV3Sigs,
    oForceV4Certs, oNoForceV4Certs.
    (opts): Turn --force-v3-sigs, --no-force-v3-sigs, --force-v4-certs,
    --no-force-v4-certs int dummy options.
    (main): Remove setting of the force_v3_sigs force_v4_certs flags.
    * g10/revoke.c (gen_revoke, create_revocation): Always create v4 certs.
    * g10/sign.c (hash_uid): Remove support for v3-signatures
    (hash_sigversion_to_magic): Ditto.
    (only_old_style): Remove this v3-key function.
    (write_signature_packets): Remove support for creating v3-signatures.
    (sign_file): Ditto.
    (sign_symencrypt_file): Ditto.
    (clearsign_file): Ditto.  Remove code to emit no Hash armor line if
    only v3-keys are used.
    (make_keysig_packet): Remove arg SIGVERSION and force using
    v4-signatures.  Change all callers to not pass a value for this arg.
    Remove all v3-key related code.
    (update_keysig_packet): Remove v3-signature support.
    * g10/keyedit.c (sign_uids): Always create v4-signatures.
    
    * g10/textfilter.c (copy_clearsig_text): Remove arg pgp2mode and
    change caller.
    --
    
    v3 keys are deprecated for about 15 years and due the severe
    weaknesses of MD5 it does not make any sense to keep code around to
    use these old and broken keys.  Users who need to decrypt old messages
    should use gpg 1.4 and best re-encrypt them to modern standards.
    verification of old (i.e. PGP2) created signatures is thus also not
    anymore possible but such signatures have no values anyway - MD5 is
    just too broken.
    
    We have also kept support for v3 signatures until now.  With the
    removal of support for v3 keys it is questionable whether it makes any
    sense to keep support for v3-signatures.  What we do now is to keep
    support for verification of v3-signatures but we force the use of
    v4-signatures.  The latter makes the --pgp6 and --pgp7 switch a bit
    obsolete because those PGP versions require v3-signatures for
    messages.  These versions of PGP are also really old and not anymore
    maintained so they have not received any bug fixes and should not be
    used anyway.
    



Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From lists-gnupgdev at lina.inka.de  Mon Oct 13 02:47:31 2014
From: lists-gnupgdev at lina.inka.de (lists-gnupgdev at lina.inka.de)
Date: Mon, 13 Oct 2014 02:47:31 +0200
Subject: Removing v3 support from 2.1 (was: Disable importing V3 public
 keys from keyservers)
In-Reply-To: <878ukmzsvv.fsf_-_@vigenere.g10code.de>
References: <CAA7UWsXLAUjT7XoL_mXT+mbAv=4aSjTcznpH0S7r4t49fOf=RQ@mail.gmail.com>
 <87tx3c2tsk.fsf@vigenere.g10code.de>
 <CAA7UWsVe_StEdh2nmWOo3EY9MCk=NhAG3Fsf4bXtF1XXrzCMFg@mail.gmail.com>
 <87fvev23pv.fsf_-_@vigenere.g10code.de>
 <CAA7UWsV=oQKdVtUiBnfhSNdMui+KTW1FyVj-briEB=nQ6EoKpw@mail.gmail.com>
 <CA+gNq50ii84uav4eObh4Zu8bSRnUM248oE=DTGcHQMna-Wx1JA@mail.gmail.com>
 <878ukmzsvv.fsf_-_@vigenere.g10code.de>
Message-ID: <20141013024731.000007f1.ecki@lina.inka.de>

Am Sat, 11 Oct 2014 14:35:16 +0200
schrieb Werner Koch <wk at gnupg.org>:

> If my counting is correct, your are the third voice agerring to remove
> all v3 support from 2.1.  I am also in favor of this.

I am all for removing it, but I think this warrants a major verion
bump. And since we should not come up with more stuff to delay 2.1, why
not release it quickly with only a deprecation warning and follow up
with a clean 3.0

Gruss
Bernd


From djhaskin987 at gmail.com  Mon Oct 13 03:54:37 2014
From: djhaskin987 at gmail.com (Dan Haskin)
Date: Sun, 12 Oct 2014 19:54:37 -0600
Subject: Removing v3 support from 2.1 (was: Disable importing V3 public
 keys from keyservers)
In-Reply-To: <20141013024731.000007f1.ecki@lina.inka.de>
References: <CAA7UWsXLAUjT7XoL_mXT+mbAv=4aSjTcznpH0S7r4t49fOf=RQ@mail.gmail.com>
 <87tx3c2tsk.fsf@vigenere.g10code.de>
 <CAA7UWsVe_StEdh2nmWOo3EY9MCk=NhAG3Fsf4bXtF1XXrzCMFg@mail.gmail.com>
 <87fvev23pv.fsf_-_@vigenere.g10code.de>
 <CAA7UWsV=oQKdVtUiBnfhSNdMui+KTW1FyVj-briEB=nQ6EoKpw@mail.gmail.com>
 <CA+gNq50ii84uav4eObh4Zu8bSRnUM248oE=DTGcHQMna-Wx1JA@mail.gmail.com>
 <878ukmzsvv.fsf_-_@vigenere.g10code.de>
 <20141013024731.000007f1.ecki@lina.inka.de>
Message-ID: <CA+gNq51WiBgQ33x=s+a0oTXfEfGA9Z=C8ambf8mSKx5=wz=-Fg@mail.gmail.com>

Bear in mind, it was already deprecated in 1.4. The argument could be made
that we don't need to deprecate it in the 2.x line, as it was already
deprecated in the 1.x line, and therefore a version bump is not needed.

Daniel Jay Haskin
http://djhaskin987.github.io/

On Sun, Oct 12, 2014 at 6:47 PM, <lists-gnupgdev at lina.inka.de> wrote:

> Am Sat, 11 Oct 2014 14:35:16 +0200
> schrieb Werner Koch <wk at gnupg.org>:
>
> > If my counting is correct, your are the third voice agerring to remove
> > all v3 support from 2.1.  I am also in favor of this.
>
> I am all for removing it, but I think this warrants a major verion
> bump. And since we should not come up with more stuff to delay 2.1, why
> not release it quickly with only a deprecation warning and follow up
> with a clean 3.0
>
> Gruss
> Bernd
>
> _______________________________________________
> 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: </pipermail/attachments/20141012/d1ea57fc/attachment.html>

From rjh at sixdemonbag.org  Mon Oct 13 06:06:32 2014
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Mon, 13 Oct 2014 00:06:32 -0400
Subject: Removing v3 support from 2.1
In-Reply-To: <20141013024731.000007f1.ecki@lina.inka.de>
References: <CAA7UWsXLAUjT7XoL_mXT+mbAv=4aSjTcznpH0S7r4t49fOf=RQ@mail.gmail.com>
 <87tx3c2tsk.fsf@vigenere.g10code.de>
 <CAA7UWsVe_StEdh2nmWOo3EY9MCk=NhAG3Fsf4bXtF1XXrzCMFg@mail.gmail.com>
 <87fvev23pv.fsf_-_@vigenere.g10code.de>
 <CAA7UWsV=oQKdVtUiBnfhSNdMui+KTW1FyVj-briEB=nQ6EoKpw@mail.gmail.com>
 <CA+gNq50ii84uav4eObh4Zu8bSRnUM248oE=DTGcHQMna-Wx1JA@mail.gmail.com>
 <878ukmzsvv.fsf_-_@vigenere.g10code.de>
 <20141013024731.000007f1.ecki@lina.inka.de>
Message-ID: <543B4FC8.4060503@sixdemonbag.org>

> I am all for removing it, but I think this warrants a major verion 
> bump.

I disagree, but mostly because I think version numbers are increasingly
irrelevant nowadays.  What does it matter if we call the new model 2.1,
2.2, 3.0 or Claudette, so long as we make it clear precisely which Git
checkin it's branched from and when the branching occurred?

And just to be difficult, I hereby nominate the next version be named,
simply, "Claudette."  :)


From wk at gnupg.org  Mon Oct 13 20:10:06 2014
From: wk at gnupg.org (Werner Koch)
Date: Mon, 13 Oct 2014 20:10:06 +0200
Subject: gpg-agent 2.1.x interop with gpg 1.4.x
In-Reply-To: <5436ED51.5000800@fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Thu, 09 Oct 2014 16:17:21 -0400")
References: <5436CF57.9060907@fifthhorseman.net>
 <8738ax3uwh.fsf@vigenere.g10code.de>
 <5436ED51.5000800@fifthhorseman.net>
Message-ID: <8738arrgch.fsf@vigenere.g10code.de>

On Thu,  9 Oct 2014 22:17, dkg at fifthhorseman.net said:

> i don't think a wrapper for gpg-agent would be sufficient, would it?
> gpg1 never invokes gpg-agent directly.

Just so that user script keep on working as expected. Bit see below.

> Another alternative, if you don't want to change anything in gpg 2.1
> itself, is that we can modify the Xsession startup script
> (/etc/X11/Xsession.d/90gpg-agent) that debian ships that enbles the

That would indeed be the easiest way and better future-proof.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From wk at gnupg.org  Mon Oct 13 20:24:35 2014
From: wk at gnupg.org (Werner Koch)
Date: Mon, 13 Oct 2014 20:24:35 +0200
Subject: [Pkg-gnupg-maint] packaging dirmngr from 2.1.0
In-Reply-To: <54338D93.2070605@fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Tue, 07 Oct 2014 02:52:03 -0400")
References: <8761fwu6bt.fsf@alice.fifthhorseman.net>
 <20141007033749.GO24040@gambit> <54338D93.2070605@fifthhorseman.net>
Message-ID: <87y4sjq13w.fsf@vigenere.g10code.de>

On Tue,  7 Oct 2014 08:52, dkg at fifthhorseman.net said:

>> Seems like it would be obviously bad to use anything other than the
>> system certs?
>
> It would be good to know from upstream whether there is any expectation
> of built-in certs, specific formats desired/needed, etc.

The cert for the keyserver pool would be a good idea, but it is probably
better to install it separately.  As of now there is no default and

     --hkp-cacert FILE   use the CA certificates in FILE for HKP over TLS

must be used.  I consider PKIX broken, thus I won't make any suggestion
what to install.

> So the only package outside of gnupg2 that we need to think about is
> kleopatra.  I don't think that kleopatra depends on the system service
> -- looking at the kdepim source code, it appears to try to invoke
> dirmngr on its own, directly, rather than looking for a system socket.

IIRC, Kleopatra has a feature to trigger a CRL download so that you can
use S/MIME offline for some time.  Dirmngr has these options

     --list-crls                  list the contents of the CRL cache
     --load-crl FILE              load CRL from FILE into cache
     --fetch-crl URL              fetch a CRL from URL

which may be used by Kleo.  But it is not really important and I do not
known whether it is still used.  In any case it Kleo can be changed to
run dirmngr-client or gpg-connect-agent.  Running dirmngr directly is
pretty old fashioned. 

@andre: Can you remember any details?

> the idea behind socket activation is that the service doesn't need to be
> started until someone actually queries it.

The Hurd folks call this feature a translator ;-)

> Those config files are now moved to /etc/gnupg2/ instead of
> /etc/dirmngr/, but by default i don't know that they need to be present
> at all.  However, if they aren't present, the dirmngr system service
> does complain about the lack of /etc/gnupg2/ldapservers.conf

Turn this into a warning or silent it?  If you don't use LDAP it is not
required.  The old dirmngr's main task was to query LDAP servers, thus this
warning.  With the new support for PGP keyservers, I consider LDAP an
optional feature.

> For simplicity, i'm considering setting up the experimental dirmngr
> package to not have the system service at all, since it makes the
> packaging simpler and clearer.

Yeah.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From coruus at gmail.com  Mon Oct 13 21:03:44 2014
From: coruus at gmail.com (David Leon Gil)
Date: Mon, 13 Oct 2014 15:03:44 -0400
Subject: Removing v3 support from 2.1
In-Reply-To: <87lholxhtx.fsf@vigenere.g10code.de>
References: <CAA7UWsXLAUjT7XoL_mXT+mbAv=4aSjTcznpH0S7r4t49fOf=RQ@mail.gmail.com>
 <87tx3c2tsk.fsf@vigenere.g10code.de>
 <CAA7UWsVe_StEdh2nmWOo3EY9MCk=NhAG3Fsf4bXtF1XXrzCMFg@mail.gmail.com>
 <87fvev23pv.fsf_-_@vigenere.g10code.de>
 <CAA7UWsV=oQKdVtUiBnfhSNdMui+KTW1FyVj-briEB=nQ6EoKpw@mail.gmail.com>
 <CA+gNq50ii84uav4eObh4Zu8bSRnUM248oE=DTGcHQMna-Wx1JA@mail.gmail.com>
 <878ukmzsvv.fsf_-_@vigenere.g10code.de> <87lholxhtx.fsf@vigenere.g10code.de>
Message-ID: <CAA7UWsX+X-=62wK80y2gVeqB55raHYrTni26cJ-XLz97iNJMUQ@mail.gmail.com>

On Sun, Oct 12, 2014 at 2:29 PM, Werner Koch <wk at gnupg.org> wrote:
> Hi,
>
> I removed all code pertaining to v3 keys and also forced using v4
> signatures.  If you want to test this, please checkout the
> "wk/test-master" branch.

This looks terrific!

Patch against g10/keyid.c of wk/test-master to add explicit casts to
unsigned ints attached. Explanation in patch.

-dlg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-g10-keyid.c-add-casts-to-unsigned-int.patch
Type: application/octet-stream
Size: 4124 bytes
Desc: not available
URL: </pipermail/attachments/20141013/34a7fc35/attachment.obj>

From mk at mkoskar.com  Tue Oct 14 14:10:17 2014
From: mk at mkoskar.com (Miroslav Koskar)
Date: Tue, 14 Oct 2014 14:10:17 +0200
Subject: [PATCH] pinentry-curses: Make sure we've got a real terminal
Message-ID: <20141014121017.GA29832@mirci>

Hello,

I've came across following issue while using GPG with pinentry-curses.

I have a script which I run interactively but also as a part of systemd user
timer. That script is invoking gpg, and hence pinentry if passphrase in the
cache is stale. Inside systemd service/timer I can't reasonably set GPG_TTY,
so I keep it unset assuming gpg will fail gracefully. To my surprise pinentry
process will spin-up CPU to 100% not wanting to finish. As a workaround I could
run gpg with --batch for that special case.

I think more robust solution is for pinentry to make sure it "talks" to real
terminal device, hence following patch. It is solving problem above, having
pinentry to fail right away as expected.

It seems to me as pretty reasonable change, though I might have overlooked
some consequences. Please consider merging.

Thanks ;)

--
Miroslav Koskar
http://miroslavkoskar.com/

-- 8< --
---
 pinentry/pinentry-curses.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/pinentry/pinentry-curses.c b/pinentry/pinentry-curses.c
index 58da255..c1000d9 100644
--- a/pinentry/pinentry-curses.c
+++ b/pinentry/pinentry-curses.c
@@ -745,11 +745,15 @@ dialog_run (pinentry_t pinentry, const char *tty_name, const char *tty_type)
 	  errno = err;
 	  return -1;
 	}
+      if (!isatty(fileno(ttyfi)) || !isatty(fileno(ttyfo)))
+        return -1;
       screen = newterm (tty_type, ttyfo, ttyfi);
       set_term (screen);
     }
   else
     {
+      if (!isatty(0) || !isatty(1))
+        return -1;
       if (!init_screen)
 	{
 	  init_screen = 1;



From guilhem at fripost.org  Tue Oct 14 21:57:25 2014
From: guilhem at fripost.org (Guilhem Moulin)
Date: Tue, 14 Oct 2014 21:57:25 +0200
Subject: [PATCH] Display key UIDs in key listing even when
 --fast-list-mode is set.
In-Reply-To: <1413315850-19799-1-git-send-email-guilhem@fripost.org>
References: <1410333320-4408-1-git-send-email-guilhem@fripost.org>
 <1413315850-19799-1-git-send-email-guilhem@fripost.org>
Message-ID: <20141014195725.GA10663@localhost>

(Updated the previous patch to make it apply seamlessly to master.)  If
there is a reason to make --fast-list-mode skip the UID (but not with
--edit-key!), I'd be eager to know.

FWIW, the modification makes it possible to use --fast-list-mode in some
of the tools included in the signing-party Debian package [1] (eg,
gpgsigs(1) or gpglist(1)) which are typically applied to a large
keyring.  The performance boost is huge.

Cheers,
-- 
Guilhem.

[1] https://packages.debian.org/sid/signing-party
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: </pipermail/attachments/20141014/dc48c604/attachment.sig>

From guilhem at fripost.org  Tue Oct 14 21:44:10 2014
From: guilhem at fripost.org (Guilhem Moulin)
Date: Tue, 14 Oct 2014 21:44:10 +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: <1413315850-19799-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 e7360e9..01abd1f 100644
--- a/doc/gpg.texi
+++ b/doc/gpg.texi
@@ -2762,11 +2762,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 b5ea84d..29d7286 100644
--- a/g10/keylist.c
+++ b/g10/keylist.c
@@ -890,7 +890,7 @@ list_keyblock_print (KBNODE keyblock, int secret, int fpr, void *opaque)
 
   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;
 
@@ -907,7 +907,7 @@ list_keyblock_print (KBNODE keyblock, int secret, int fpr, void *opaque)
 	    dump_attribs (uid, pk);
 
 	  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;
@@ -1262,7 +1262,7 @@ list_keyblock_colon (KBNODE keyblock, int secret, int has_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)
 	{
 	  char *str;
 	  PKT_user_id *uid = node->pkt->pkt.user_id;
@@ -1277,7 +1277,7 @@ list_keyblock_colon (KBNODE keyblock, int secret, int has_secret, int fpr)
 	    es_fprintf (es_stdout, "%s:r::::", str);
 	  else if (uid->is_expired)
 	    es_fprintf (es_stdout, "%s:e::::", str);
-	  else if (opt.no_expensive_trust_checks)
+	  else if (opt.fast_list_mode || opt.no_expensive_trust_checks)
 	    es_fprintf (es_stdout, "%s:::::", str);
 	  else
 	    {
-- 
2.1.1



From wk at gnupg.org  Wed Oct 15 16:43:48 2014
From: wk at gnupg.org (Werner Koch)
Date: Wed, 15 Oct 2014 16:43:48 +0200
Subject: Removing v3 support from 2.1
In-Reply-To: <87lholxhtx.fsf@vigenere.g10code.de> (Werner Koch's message of
 "Sun, 12 Oct 2014 20:29:14 +0200")
References: <CAA7UWsXLAUjT7XoL_mXT+mbAv=4aSjTcznpH0S7r4t49fOf=RQ@mail.gmail.com>
 <87tx3c2tsk.fsf@vigenere.g10code.de>
 <CAA7UWsVe_StEdh2nmWOo3EY9MCk=NhAG3Fsf4bXtF1XXrzCMFg@mail.gmail.com>
 <87fvev23pv.fsf_-_@vigenere.g10code.de>
 <CAA7UWsV=oQKdVtUiBnfhSNdMui+KTW1FyVj-briEB=nQ6EoKpw@mail.gmail.com>
 <CA+gNq50ii84uav4eObh4Zu8bSRnUM248oE=DTGcHQMna-Wx1JA@mail.gmail.com>
 <878ukmzsvv.fsf_-_@vigenere.g10code.de>
 <87lholxhtx.fsf@vigenere.g10code.de>
Message-ID: <871tq9o0kb.fsf@vigenere.g10code.de>

On Sun, 12 Oct 2014 20:29, wk at gnupg.org said:

> I removed all code pertaining to v3 keys and also forced using v4
> signatures.  If you want to test this, please checkout the
> "wk/test-master" branch.

I plan to move that to master soon.  If you want to send a "Please
consider not to do that" comment, you should hurry up.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From nicholas.cole at gmail.com  Wed Oct 15 17:05:29 2014
From: nicholas.cole at gmail.com (Nicholas Cole)
Date: Wed, 15 Oct 2014 16:05:29 +0100
Subject: Removing v3 support from 2.1
In-Reply-To: <871tq9o0kb.fsf@vigenere.g10code.de>
References: <CAA7UWsXLAUjT7XoL_mXT+mbAv=4aSjTcznpH0S7r4t49fOf=RQ@mail.gmail.com>
 <87tx3c2tsk.fsf@vigenere.g10code.de>
 <CAA7UWsVe_StEdh2nmWOo3EY9MCk=NhAG3Fsf4bXtF1XXrzCMFg@mail.gmail.com>
 <87fvev23pv.fsf_-_@vigenere.g10code.de>
 <CAA7UWsV=oQKdVtUiBnfhSNdMui+KTW1FyVj-briEB=nQ6EoKpw@mail.gmail.com>
 <CA+gNq50ii84uav4eObh4Zu8bSRnUM248oE=DTGcHQMna-Wx1JA@mail.gmail.com>
 <878ukmzsvv.fsf_-_@vigenere.g10code.de>
 <87lholxhtx.fsf@vigenere.g10code.de>
 <871tq9o0kb.fsf@vigenere.g10code.de>
Message-ID: <CAAu18he+nP8tXahpUWuH-h6jjQxXZTvNC6-umPZT8P9ifhkxDA@mail.gmail.com>

On Wed, Oct 15, 2014 at 3:43 PM, Werner Koch <wk at gnupg.org> wrote:
> On Sun, 12 Oct 2014 20:29, wk at gnupg.org said:
>
>> I removed all code pertaining to v3 keys and also forced using v4
>> signatures.  If you want to test this, please checkout the
>> "wk/test-master" branch.
>
> I plan to move that to master soon.  If you want to send a "Please
> consider not to do that" comment, you should hurry up.

There are still some V3 keys in real-world usage (I agree with the
list that this is something to discourage).  I suppose as long as 1.4
is available for migration or for emergency use, I'm +0 on this
change.


From rose-indorf at gmx.de  Wed Oct 15 22:15:55 2014
From: rose-indorf at gmx.de (Sebastian Rose-Indorf)
Date: Wed, 15 Oct 2014 22:15:55 +0200
Subject: AW: Removing v3 support from 2.1
In-Reply-To: <871tq9o0kb.fsf@vigenere.g10code.de>
References: <CAA7UWsXLAUjT7XoL_mXT+mbAv=4aSjTcznpH0S7r4t49fOf=RQ@mail.gmail.com>
 <87tx3c2tsk.fsf@vigenere.g10code.de>
 <CAA7UWsVe_StEdh2nmWOo3EY9MCk=NhAG3Fsf4bXtF1XXrzCMFg@mail.gmail.com>
 <87fvev23pv.fsf_-_@vigenere.g10code.de>
 <CAA7UWsV=oQKdVtUiBnfhSNdMui+KTW1FyVj-briEB=nQ6EoKpw@mail.gmail.com>
 <CA+gNq50ii84uav4eObh4Zu8bSRnUM248oE=DTGcHQMna-Wx1JA@mail.gmail.com>
 <878ukmzsvv.fsf_-_@vigenere.g10code.de> <87lholxhtx.fsf@vigenere.g10code.de>
 <871tq9o0kb.fsf@vigenere.g10code.de>
Message-ID: <000101cfe8b4$d3e8a430$7bb9ec90$@de>

Hello,
 
what about to make the v3 support depending on the allow-weak-digest-algos
switch?

Cheers
Sebastian


> -----Urspr?ngliche Nachricht-----
> Von: Gnupg-devel [mailto:gnupg-devel-bounces+rose-
> indorf=gmx.de at gnupg.org] Im Auftrag von Werner Koch
> Gesendet: Mittwoch, 15. Oktober 2014 16:44
> An: gnupg-devel at gnupg.org
> Betreff: Re: Removing v3 support from 2.1
> 
> On Sun, 12 Oct 2014 20:29, wk at gnupg.org said:
> 
> > I removed all code pertaining to v3 keys and also forced using v4
> > signatures.  If you want to test this, please checkout the
> > "wk/test-master" branch.
> 
> I plan to move that to master soon.  If you want to send a "Please
> consider not to do that" comment, you should hurry up.
> 
> 
> Shalom-Salam,
> 
>    Werner
> 
> --
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
> 
> 
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel



From wk at gnupg.org  Wed Oct 15 23:22:34 2014
From: wk at gnupg.org (Werner Koch)
Date: Wed, 15 Oct 2014 23:22:34 +0200
Subject: AW: Removing v3 support from 2.1
In-Reply-To: <000101cfe8b4$d3e8a430$7bb9ec90$@de> (Sebastian Rose-Indorf's
 message of "Wed, 15 Oct 2014 22:15:55 +0200")
References: <CAA7UWsXLAUjT7XoL_mXT+mbAv=4aSjTcznpH0S7r4t49fOf=RQ@mail.gmail.com>
 <87tx3c2tsk.fsf@vigenere.g10code.de>
 <CAA7UWsVe_StEdh2nmWOo3EY9MCk=NhAG3Fsf4bXtF1XXrzCMFg@mail.gmail.com>
 <87fvev23pv.fsf_-_@vigenere.g10code.de>
 <CAA7UWsV=oQKdVtUiBnfhSNdMui+KTW1FyVj-briEB=nQ6EoKpw@mail.gmail.com>
 <CA+gNq50ii84uav4eObh4Zu8bSRnUM248oE=DTGcHQMna-Wx1JA@mail.gmail.com>
 <878ukmzsvv.fsf_-_@vigenere.g10code.de>
 <87lholxhtx.fsf@vigenere.g10code.de>
 <871tq9o0kb.fsf@vigenere.g10code.de>
 <000101cfe8b4$d3e8a430$7bb9ec90$@de>
Message-ID: <87fvepm3j9.fsf@vigenere.g10code.de>

On Wed, 15 Oct 2014 22:15, rose-indorf at gmx.de said:

> what about to make the v3 support depending on the allow-weak-digest-algos
> switch?

Because that would actually increase code complexity.  Reducing code
complexity is a actually what one should aim for.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From dkg at fifthhorseman.net  Wed Oct 15 23:35:51 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 15 Oct 2014 17:35:51 -0400
Subject: AW: Removing v3 support from 2.1
In-Reply-To: <87fvepm3j9.fsf@vigenere.g10code.de>
References: <CAA7UWsXLAUjT7XoL_mXT+mbAv=4aSjTcznpH0S7r4t49fOf=RQ@mail.gmail.com>
 <87tx3c2tsk.fsf@vigenere.g10code.de>
 <CAA7UWsVe_StEdh2nmWOo3EY9MCk=NhAG3Fsf4bXtF1XXrzCMFg@mail.gmail.com>
 <87fvev23pv.fsf_-_@vigenere.g10code.de>
 <CAA7UWsV=oQKdVtUiBnfhSNdMui+KTW1FyVj-briEB=nQ6EoKpw@mail.gmail.com>
 <CA+gNq50ii84uav4eObh4Zu8bSRnUM248oE=DTGcHQMna-Wx1JA@mail.gmail.com>
 <878ukmzsvv.fsf_-_@vigenere.g10code.de> <87lholxhtx.fsf@vigenere.g10code.de>
 <871tq9o0kb.fsf@vigenere.g10code.de> <000101cfe8b4$d3e8a430$7bb9ec90$@de>
 <87fvepm3j9.fsf@vigenere.g10code.de>
Message-ID: <543EE8B7.7030103@fifthhorseman.net>

On 10/15/2014 05:22 PM, Werner Koch wrote:
> On Wed, 15 Oct 2014 22:15, rose-indorf at gmx.de said:
> 
>> what about to make the v3 support depending on the allow-weak-digest-algos
>> switch?
> 
> Because that would actually increase code complexity.  Reducing code
> complexity is a actually what one should aim for.

I agree that the cost of code complexity isn't worth the flexibility
Sebastian proposes here.

i'd much prefer to be running code that i know can't be forced into
using these known-bad keys.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20141015/4641020a/attachment.sig>

From bjk at luxsci.net  Sat Oct 18 00:46:14 2014
From: bjk at luxsci.net (Ben Kibbey)
Date: Fri, 17 Oct 2014 18:46:14 -0400
Subject: GPGME and custom memory allocators
Message-ID: <1413586022-2320331.35254661.fs9HMkEB9030223@rs146.luxsci.com>

Hello,

I'm hoping people can test the bjk/master branch of
git://git.gnupg.org/gpgme.git before being pulled into master. It adds
custom memory allocators to gpgme much like libassuan and libgcrypt.
vasprintf was being difficult so I'd like to make sure I dont break
anything before requesting a pull.

Thanks,

-- 
Ben Kibbey


From georgiytreyvus at riseup.net  Sat Oct 18 21:37:42 2014
From: georgiytreyvus at riseup.net (Georgiy Treyvus)
Date: Sat, 18 Oct 2014 15:37:42 -0400
Subject: I want to help improve the documentation.
Message-ID: <5442C186.8060409@riseup.net>

Hey all,

While I genuinely appreciate your work and GnuPG is great I don't know
how else to put this politely but the core documentation/manual be it
the man or info pages is horrendous. There are many places where it is
either ambiguous or lacks what I feel are critical details. Many things
I found out not from the official documentation but from either trial
and error or from reading tutorials written by others(how they found out
the stuff they teach there I don't know but to them I tip my hat).
There's really something wrong with this picture.

Thus what I'd like to do is help improve the documentation. If I were to
take the time to expand, update, and rewrite more clearly various
portions of the manual bit by bit as my time permits would you folks be
willing to integrate these improvements into the official documentation?
Also it would be nice if all of these submitted improvements were
reviewed to make sure my understanding of the critical facts is
correct(usually it is, but again I can't be sure short of diving into as
the source code, the man/info pages suck, and trial/error experiments
aren't the best at leading to fully correct conclusions). I might not be
able to fix all the problems with the docs but whatever I can fix will
help people especially newer users.

GnuPG is a great piece of software but even the best program in the
world is useless if someone can't easily figure out how to use it.
Documentation is every bit as important as the actual functionality of
the software itself. I'm willing to experiment and get my hands dirty to
an extent. Unfortunately many other users are not and will just say
quite literally "fuck this shit". :-( Though I have managed to get some
of my friends to use crypto my success rate has been been quite dismal.
Only about 5-10% I'm sorry to say. Contrary to all the whining about how
difficult crypto is to use GnuPG and especially other front ends are
quite easy once one gets the feel of them. However for one to get the
feel good, detailed, and unambiguous documentation is needed. Thus I
really want to help improve the documentation. If you folks are willing
to integrate my various rewrites as I send them out that would be truly
great. I want to help with this as it's something that desperately needs
to be done. Please let me know how I can be of help on this front and
how to best integrate myself with the overall workflow here.

Regards,
Georgiy


From dkg at fifthhorseman.net  Sun Oct 19 13:39:57 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sun, 19 Oct 2014 07:39:57 -0400
Subject: [PATCH 1/2] add lock-obj for new arch triplet for x86
Message-ID: <1413718798-5398-1-git-send-email-dkg@fifthhorseman.net>

* src/sysconfig/lock-obj-pub.i586-pc-linux-gnu.h: New.

--

Helmut Grohne writes:

Observe that the detected GNU triplet is now i586-pc-linux-gnu (gcc
bumped it from i486-pc-linux-gnu recently), so the corresponding lock
obj header in the syscfg folder needs to be moved or linked.

Debian-Bug-Id: 764881
---
 src/syscfg/lock-obj-pub.i586-pc-linux-gnu.h | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 src/syscfg/lock-obj-pub.i586-pc-linux-gnu.h

diff --git a/src/syscfg/lock-obj-pub.i586-pc-linux-gnu.h b/src/syscfg/lock-obj-pub.i586-pc-linux-gnu.h
new file mode 100644
index 0000000..fc2d132
--- /dev/null
+++ b/src/syscfg/lock-obj-pub.i586-pc-linux-gnu.h
@@ -0,0 +1,23 @@
+## lock-obj-pub.i586-pc-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[24];
+    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}}}
+##
+## Local Variables:
+## mode: c
+## buffer-read-only: t
+## End:
+##
-- 
2.1.1



From dkg at fifthhorseman.net  Sun Oct 19 13:39:58 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sun, 19 Oct 2014 07:39:58 -0400
Subject: [PATCH 2/2] add lock-obj header for or1k-unknown-linux-gnu
In-Reply-To: <1413718798-5398-1-git-send-email-dkg@fifthhorseman.net>
References: <1413718798-5398-1-git-send-email-dkg@fifthhorseman.net>
Message-ID: <1413718798-5398-2-git-send-email-dkg@fifthhorseman.net>

* src/syscfg/lock-obj-pub.or1k-unknown-linux-gnu.h: new

This architecture-specific header information was sourced from
http://wannabuild.cmd.nu/fetch.php?pkg=libgpg-error&arch=or1k&ver=1.13-2&stamp=1407320768
---
 src/syscfg/lock-obj-pub.or1k-unknown-linux-gnu.h | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 src/syscfg/lock-obj-pub.or1k-unknown-linux-gnu.h

diff --git a/src/syscfg/lock-obj-pub.or1k-unknown-linux-gnu.h b/src/syscfg/lock-obj-pub.or1k-unknown-linux-gnu.h
new file mode 100644
index 0000000..60eadab
--- /dev/null
+++ b/src/syscfg/lock-obj-pub.or1k-unknown-linux-gnu.h
@@ -0,0 +1,24 @@
+## lock-obj-pub.or1k-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[32];
+    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}}}
+##
+## Local Variables:
+## mode: c
+## buffer-read-only: t
+## End:
+##
-- 
2.1.1



From coruus at gmail.com  Tue Oct 21 20:34:49 2014
From: coruus at gmail.com (David Leon Gil)
Date: Tue, 21 Oct 2014 14:34:49 -0400
Subject: GPGME and custom memory allocators
In-Reply-To: <1413586022-2320331.35254661.fs9HMkEB9030223@rs146.luxsci.com>
References: <1413586022-2320331.35254661.fs9HMkEB9030223@rs146.luxsci.com>
Message-ID: <CAA7UWsURqmevjNbm4yHUdSkjqko04i4e5dkVqtt+SRZwGgJ6Vw@mail.gmail.com>

On Fri, Oct 17, 2014 at 6:46 PM, Ben Kibbey <bjk at luxsci.net> wrote:
> Hello,
>
> I'm hoping people can test the bjk/master branch of
> git://git.gnupg.org/gpgme.git before being pulled into master. It adds
> custom memory allocators to gpgme much like libassuan and libgcrypt.

Why?


From rjh at sixdemonbag.org  Tue Oct 21 22:00:20 2014
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Tue, 21 Oct 2014 16:00:20 -0400
Subject: GPGME and custom memory allocators
In-Reply-To: <CAA7UWsURqmevjNbm4yHUdSkjqko04i4e5dkVqtt+SRZwGgJ6Vw@mail.gmail.com>
References: <1413586022-2320331.35254661.fs9HMkEB9030223@rs146.luxsci.com>
 <CAA7UWsURqmevjNbm4yHUdSkjqko04i4e5dkVqtt+SRZwGgJ6Vw@mail.gmail.com>
Message-ID: <5446BB54.6020202@sixdemonbag.org>

>> I'm hoping people can test the bjk/master branch of 
>> git://git.gnupg.org/gpgme.git before being pulled into master. It
>> adds custom memory allocators to gpgme much like libassuan and
>> libgcrypt.
> 
> Why?

There are lots of reasons to do this -- maybe you're on a Beowulf
cluster and you want to make sure memory gets allocated on the same
machine the process is running on, to minimize access time.  Maybe
you've got memory with some really exotic security safeguard, like
embedded in tamper-resistant epoxy to make various forensic techniques
more difficult, and you want to make sure memory gets allocated there
and not in an easier-to-attack DIMM.  Maybe...

Writing custom memory allocators sounds really exotic, but it's a fairly
common bit of systems-level programming.  GnuPG has its own custom
allocator built into it, for instance, to provide some software-based
security guarantees to the memory block.


From bjk at luxsci.net  Tue Oct 21 23:40:50 2014
From: bjk at luxsci.net (Ben Kibbey)
Date: Tue, 21 Oct 2014 17:40:50 -0400
Subject: GPGME and custom memory allocators
In-Reply-To: <5446BB54.6020202@sixdemonbag.org>
References: <1413586022-2320331.35254661.fs9HMkEB9030223@rs146.luxsci.com>
 <CAA7UWsURqmevjNbm4yHUdSkjqko04i4e5dkVqtt+SRZwGgJ6Vw@mail.gmail.com>
 <5446BB54.6020202@sixdemonbag.org>
Message-ID: <1413927665-4419037.34018625.fs9LLeojl000600@rs146.luxsci.com>

On Tue, Oct 21, 2014 at 04:00:20PM -0400, Robert J. Hansen wrote:
> >> I'm hoping people can test the bjk/master branch of 
> >> git://git.gnupg.org/gpgme.git before being pulled into master. It
> >> adds custom memory allocators to gpgme much like libassuan and
> >> libgcrypt.
> > 
> > Why?
> 
> There are lots of reasons to do this -- maybe you're on a Beowulf
> cluster and you want to make sure memory gets allocated on the same
> machine the process is running on, to minimize access time.  Maybe
> you've got memory with some really exotic security safeguard, like
> embedded in tamper-resistant epoxy to make various forensic techniques
> more difficult, and you want to make sure memory gets allocated there
> and not in an easier-to-attack DIMM.  Maybe...
> 
> Writing custom memory allocators sounds really exotic, but it's a fairly
> common bit of systems-level programming.  GnuPG has its own custom
> allocator built into it, for instance, to provide some software-based
> security guarantees to the memory block.

It's also useful for memory allocation tracking and leak detection and
zero'ing before free().

-- 
Ben Kibbey


From lists-gnupgdev at lina.inka.de  Tue Oct 21 23:55:30 2014
From: lists-gnupgdev at lina.inka.de (lists-gnupgdev at lina.inka.de)
Date: Tue, 21 Oct 2014 23:55:30 +0200
Subject: GPGME and custom memory allocators
In-Reply-To: <1413927665-4419037.34018625.fs9LLeojl000600@rs146.luxsci.com>
References: <1413586022-2320331.35254661.fs9HMkEB9030223@rs146.luxsci.com>
 <CAA7UWsURqmevjNbm4yHUdSkjqko04i4e5dkVqtt+SRZwGgJ6Vw@mail.gmail.com>
 <5446BB54.6020202@sixdemonbag.org>
 <1413927665-4419037.34018625.fs9LLeojl000600@rs146.luxsci.com>
Message-ID: <20141021235530.00006608.ecki@lina.inka.de>

Am Tue, 21 Oct 2014 17:40:50 -0400
schrieb Ben Kibbey <bjk at luxsci.net>:
> It's also useful for memory allocation tracking and leak detection and
> zero'ing before free().

And for sabotaging system level safeguards :) (see OpenSSL) 

Gruss
Bernd


> 



From bjk at luxsci.net  Wed Oct 22 00:08:00 2014
From: bjk at luxsci.net (Ben Kibbey)
Date: Tue, 21 Oct 2014 18:08:00 -0400
Subject: GPGME and custom memory allocators
In-Reply-To: <20141021235530.00006608.ecki@lina.inka.de>
References: <1413586022-2320331.35254661.fs9HMkEB9030223@rs146.luxsci.com>
 <CAA7UWsURqmevjNbm4yHUdSkjqko04i4e5dkVqtt+SRZwGgJ6Vw@mail.gmail.com>
 <5446BB54.6020202@sixdemonbag.org>
 <1413927665-4419037.34018625.fs9LLeojl000600@rs146.luxsci.com>
 <20141021235530.00006608.ecki@lina.inka.de>
Message-ID: <1413929282-8284378.3857337.fs9LM80rc032751@rs146.luxsci.com>

On Tue, Oct 21, 2014 at 11:55:30PM +0200, lists-gnupgdev at lina.inka.de wrote:
> Am Tue, 21 Oct 2014 17:40:50 -0400
> schrieb Ben Kibbey <bjk at luxsci.net>:
> > It's also useful for memory allocation tracking and leak detection and
> > zero'ing before free().
> 
> And for sabotaging system level safeguards :) (see OpenSSL) 

Well, at least there's the option. Both libassuan and libgcrypt provide
this feature and I have used it with both without problems. I'm not sure
why it isn't included in gpgme.

-- 
Ben Kibbey


From wk at gnupg.org  Thu Oct 23 14:27:47 2014
From: wk at gnupg.org (Werner Koch)
Date: Thu, 23 Oct 2014 14:27:47 +0200
Subject: GPGME and custom memory allocators
In-Reply-To: <1413929282-8284378.3857337.fs9LM80rc032751@rs146.luxsci.com>
 (Ben Kibbey's message of "Tue, 21 Oct 2014 18:08:00 -0400")
References: <1413586022-2320331.35254661.fs9HMkEB9030223@rs146.luxsci.com>
 <CAA7UWsURqmevjNbm4yHUdSkjqko04i4e5dkVqtt+SRZwGgJ6Vw@mail.gmail.com>
 <5446BB54.6020202@sixdemonbag.org>
 <1413927665-4419037.34018625.fs9LLeojl000600@rs146.luxsci.com>
 <20141021235530.00006608.ecki@lina.inka.de>
 <1413929282-8284378.3857337.fs9LM80rc032751@rs146.luxsci.com>
Message-ID: <87wq7rc6nw.fsf@vigenere.g10code.de>

On Wed, 22 Oct 2014 00:08, bjk at luxsci.net said:

> Well, at least there's the option. Both libassuan and libgcrypt provide
> this feature and I have used it with both without problems. I'm not sure
> why it isn't included in gpgme.

The reason why Libgcrypt has this function is that we have this "secure"
memory block which automagically works.  However that requires that the
same allocation function is used everywhere.

GPGME does in general not handle the secret key stuff and thus Marcus
once decided to go with standard malloc.  However, we later learned that
this sometimes also problematic: On Windows it may happen that DLLs use
different C-runtimes and the malloc functions won't interoperate and
lead to strange crashes.  We fixed this by adding gpgme_free so that the
caller can release malloced memory returned from gpgme with the proper
function.

BTW, I'd prefer to use a realloc based interface for the setting the
global malloc functions.  See the PM I sent today.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From wk at gnupg.org  Thu Oct 23 14:36:01 2014
From: wk at gnupg.org (Werner Koch)
Date: Thu, 23 Oct 2014 14:36:01 +0200
Subject: [PATCH 2/2] add lock-obj header for or1k-unknown-linux-gnu
In-Reply-To: <1413718798-5398-2-git-send-email-dkg@fifthhorseman.net> (Daniel
 Kahn Gillmor's message of "Sun, 19 Oct 2014 07:39:58 -0400")
References: <1413718798-5398-1-git-send-email-dkg@fifthhorseman.net>
 <1413718798-5398-2-git-send-email-dkg@fifthhorseman.net>
Message-ID: <87siifc6a6.fsf@vigenere.g10code.de>

Thanks,

I also added thme to the Makefile.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From wk at gnupg.org  Fri Oct 24 16:51:20 2014
From: wk at gnupg.org (Werner Koch)
Date: Fri, 24 Oct 2014 16:51:20 +0200
Subject: 2.1 beta or release
Message-ID: <87fvedbjx3.fsf@vigenere.g10code.de>

Hi!

shall I do another beta before doing the release or shall I declare it
ready, wait for some folks to report problems from a git build, and do
the release after fixing them?

In any case I expect that 2.1.0 will have a couple of build and runtime
problems.  We simply do not enough testers.  A 2.1.1 will thus likely
follow in shortly after 2.1.0.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From pgut001 at cs.auckland.ac.nz  Fri Oct 24 17:02:58 2014
From: pgut001 at cs.auckland.ac.nz (Peter Gutmann)
Date: Sat, 25 Oct 2014 04:02:58 +1300
Subject: 2.1 beta or release
In-Reply-To: <87fvedbjx3.fsf@vigenere.g10code.de>
Message-ID: <E1XhgOI-0001rt-6w@login01.fos.auckland.ac.nz>

Werner Koch <wk at gnupg.org> writes:

>shall I do another beta before doing the release or shall I declare it ready,
>wait for some folks to report problems from a git build, and do the release
>after fixing them?

Probably the latter.  I've found that that's the only way that really flushes
out the problems :-).

Peter.


From rjh at sixdemonbag.org  Fri Oct 24 17:18:34 2014
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Fri, 24 Oct 2014 11:18:34 -0400
Subject: 2.1 beta or release
In-Reply-To: <87fvedbjx3.fsf@vigenere.g10code.de>
References: <87fvedbjx3.fsf@vigenere.g10code.de>
Message-ID: <544A6DCA.80806@sixdemonbag.org>

> shall I do another beta before doing the release or shall I declare it
> ready, wait for some folks to report problems from a git build, and do
> the release after fixing them?

I say go for broke.  Make the release and follow it up with a 2.1.1
early next year, once bug reports from end users start rolling in.



From dkg at fifthhorseman.net  Fri Oct 24 17:25:24 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 24 Oct 2014 11:25:24 -0400
Subject: 2.1 beta or release
In-Reply-To: <87fvedbjx3.fsf@vigenere.g10code.de>
References: <87fvedbjx3.fsf@vigenere.g10code.de>
Message-ID: <87d29hxzff.fsf@alice.fifthhorseman.net>

On Fri 2014-10-24 10:51:20 -0400, Werner Koch wrote:
> shall I do another beta before doing the release or shall I declare it
> ready, wait for some folks to report problems from a git build, and do
> the release after fixing them?

having explicitly tagged explicit releases (beta or otherwise) makes it
more straightforward for me to package it for debian, so i prefer that
over trying to package the git head.

> In any case I expect that 2.1.0 will have a couple of build and runtime
> problems.  We simply do not enough testers.  A 2.1.1 will thus likely
> follow in shortly after 2.1.0.

Is the implication that if we call it 2.1.0, the 2.0.x branch will no
longer be supported?  Will there be a separate "master" branch created
that will also need to be supported?  In practice, we're maintaining 3
branches right now: 1.4.x, 2.0.x, and master -- if calling the release
2.1.0 just says "master is ready to be used by the public", and doesn't
mean we have to support an extra branch, then I think 2.1.0 is
preferable, even if there are known regressions [0].

This code will get more attention if it is known to be released, and
more attention means more testers and more feedback.

Regards,

     --dkg

[0] for me, the worst regression is the export-reset-subkey-passwd
situation, which is blocking my personal adoption; i'm sorry i haven't
had time to fix it yet.  Any help fixing it would be welcome.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: </pipermail/attachments/20141024/b0395156/attachment-0001.sig>

From dkg at fifthhorseman.net  Fri Oct 24 20:03:10 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 24 Oct 2014 14:03:10 -0400
Subject: [PATCH] Add new lock-obj-pub for mips64el-unknown-linux-gnuabi64.
Message-ID: <1414173790-17859-1-git-send-email-dkg@fifthhorseman.net>

* src/syscfg/lock-obj-pub.mips64el-unknown-linux-gnuabi64.h: New.
* src/Makefile.am (lock_obj_pub): Add.

--

native lock obj header for 64-bit little-endian MIPS, taken from
debian mips64el port buildd, see:

http://mips64el.debian.net/debian/buildlog/libg/libgpg-error_1.16-2/libgpg-error_1.16-2_mips64el-20140928-1753.build

Debian-Bug-Id: 766135
---
 src/Makefile.am                                    |  1 +
 .../lock-obj-pub.mips64el-unknown-linux-gnuabi64.h | 25 ++++++++++++++++++++++
 2 files changed, 26 insertions(+)
 create mode 100644 src/syscfg/lock-obj-pub.mips64el-unknown-linux-gnuabi64.h

diff --git a/src/Makefile.am b/src/Makefile.am
index 903feae..b91876b 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -55,6 +55,7 @@ lock_obj_pub = \
         syscfg/lock-obj-pub.i586-pc-linux-gnu.h             \
         syscfg/lock-obj-pub.m68k-unknown-linux-gnu.h        \
         syscfg/lock-obj-pub.mips-unknown-linux-gnu.h        \
+        syscfg/lock-obj-pub.mips64el-unknown-linux-gnuabi64.h \
         syscfg/lock-obj-pub.mipsel-unknown-linux-gnu.h      \
         syscfg/lock-obj-pub.or1k-unknown-linux-gnu.h        \
         syscfg/lock-obj-pub.powerpc-unknown-linux-gnu.h     \
diff --git a/src/syscfg/lock-obj-pub.mips64el-unknown-linux-gnuabi64.h b/src/syscfg/lock-obj-pub.mips64el-unknown-linux-gnuabi64.h
new file mode 100644
index 0000000..8a81e3f
--- /dev/null
+++ b/src/syscfg/lock-obj-pub.mips64el-unknown-linux-gnuabi64.h
@@ -0,0 +1,25 @@
+## lock-obj-pub.mips64el-unknown-linux-gnuabi64.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.1



From wk at gnupg.org  Fri Oct 24 20:46:56 2014
From: wk at gnupg.org (Werner Koch)
Date: Fri, 24 Oct 2014 20:46:56 +0200
Subject: 2.1 beta or release
In-Reply-To: <E1XhgOI-0001rt-6w@login01.fos.auckland.ac.nz> (Peter Gutmann's
 message of "Sat, 25 Oct 2014 04:02:58 +1300")
References: <E1XhgOI-0001rt-6w@login01.fos.auckland.ac.nz>
Message-ID: <87zjcl9ufz.fsf@vigenere.g10code.de>

On Fri, 24 Oct 2014 17:02, pgut001 at cs.auckland.ac.nz said:

> Probably the latter.  I've found that that's the only way that really flushes
> out the problems :-).

Back in the 90ies it was quite different but now that even OpenSSL has a
1 as major version beta releases and 0.x are more or less useless :-(.
This reminds me of GPA and Pinentry.

Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From wk at gnupg.org  Fri Oct 24 20:54:36 2014
From: wk at gnupg.org (Werner Koch)
Date: Fri, 24 Oct 2014 20:54:36 +0200
Subject: 2.1 beta or release
In-Reply-To: <87d29hxzff.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Fri, 24 Oct 2014 11:25:24 -0400")
References: <87fvedbjx3.fsf@vigenere.g10code.de>
 <87d29hxzff.fsf@alice.fifthhorseman.net>
Message-ID: <87vbn99u37.fsf@vigenere.g10code.de>

On Fri, 24 Oct 2014 17:25, dkg at fifthhorseman.net said:

> having explicitly tagged explicit releases (beta or otherwise) makes it
> more straightforward for me to package it for debian, so i prefer that
> over trying to package the git head.

Hmmm, the last one build, right?

> Is the implication that if we call it 2.1.0, the 2.0.x branch will no
> longer be supported?  Will there be a separate "master" branch created

2.1 will stay as master ...

  My plan is to offer 2.1 as the new feature branch of GnuPG which may
  actually be used but might not be as stable as the, well, stable branch.
  As soon as this has stabilized the version will be bumped up to 2.2 and
  earmarked as the new stable branch (LTS in modern parlance).  At that
  time an end-of-life date will be announced for 2.0.
  
  The question is on how long it will take until we can do that.  Maybe we
  can look at the number of ECC keys on the keyservers to decide whether
  ECC and thus 2.2 can go mainstream.

Google End-toEnd team is working on a new-keys-are-ECC and that might
help us to get some momentum for a migration to 2.1

> mean we have to support an extra branch, then I think 2.1.0 is
> preferable, even if there are known regressions [0].

Yeah, sorry.  There are probably a lot of other regressions.  But at
some point we need to say stop adding features.  Thus today's pinentry
with Passphrase+Repeat-Passphrase should be the last feature.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From wk at gnupg.org  Fri Oct 24 21:01:01 2014
From: wk at gnupg.org (Werner Koch)
Date: Fri, 24 Oct 2014 21:01:01 +0200
Subject: [PATCH] pinentry-curses: Make sure we've got a real terminal
In-Reply-To: <20141014121017.GA29832@mirci> (Miroslav Koskar's message of
 "Tue, 14 Oct 2014 14:10:17 +0200")
References: <20141014121017.GA29832@mirci>
Message-ID: <87r3xx9tsi.fsf@vigenere.g10code.de>

On Tue, 14 Oct 2014 14:10, mk at mkoskar.com said:

> I think more robust solution is for pinentry to make sure it "talks" to real
> terminal device, hence following patch. It is solving problem above, having
> pinentry to fail right away as expected.

Any other opinons on this?

> +      if (!isatty(fileno(ttyfi)) || !isatty(fileno(ttyfo)))
> +        return -1;
>        screen = newterm (tty_type, ttyfo, ttyfi);

Hmmm, we don't check for an error from newterm?  At least for memory
problems it will return NULL.  That code is pretty old , I can't
remember the details.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From kristian.fiskerstrand at sumptuouscapital.com  Fri Oct 24 21:52:28 2014
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian fiskerstrand)
Date: Fri, 24 Oct 2014 12:52:28 -0700
Subject: 2.1 beta or release
In-Reply-To: <87fvedbjx3.fsf@vigenere.g10code.de>
References: <87fvedbjx3.fsf@vigenere.g10code.de>
Message-ID: <94C516AD-DA93-49B8-82DF-D380A0B1C435@sumptuouscapital.com>



Sent from my iPad

> On 24 Oct 2014, at 07:51, Werner Koch <wk at gnupg.org> wrote:
> 
> Hi!
> 
> shall I do another beta before doing the release or shall I declare it
> ready, wait for some folks to report problems from a git build, and do
> the release after fixing them?
> 

Any ETA for IANA assignment of algoid for the Ed25519 / EdDSA I-D? If this is within a reasonable timeframe, it might make sense to wait for it before it is officially marked stable. I've been waiting for this before including the patches for it in SKS


From hanno at hboeck.de  Fri Oct 24 22:21:08 2014
From: hanno at hboeck.de (Hanno =?ISO-8859-1?B?QvZjaw==?=)
Date: Fri, 24 Oct 2014 22:21:08 +0200
Subject: 2.1 beta or release
In-Reply-To: <87fvedbjx3.fsf@vigenere.g10code.de>
References: <87fvedbjx3.fsf@vigenere.g10code.de>
Message-ID: <20141024222108.3eff0ba4@pc>

Am Fri, 24 Oct 2014 16:51:20 +0200
schrieb Werner Koch <wk at gnupg.org>:

> In any case I expect that 2.1.0 will have a couple of build and
> runtime problems.  We simply do not enough testers.  A 2.1.1 will
> thus likely follow in shortly after 2.1.0.

What's the current status of ECC support?

The latest beta I checked had support for the NIST curves but not for
curve25519. As far as I followed discussions (also around google's
endtoend) curve25519 seems to be the thing people generally want to use
in the future. Will 2.1 have curve25519 support? (and is this sign-only
or also for encryption?)
Is there a consensus how to implement it in a compatible way between
different pgp-implementations (that's probably mainly gpg and endtoend)?

-- 
Hanno B?ck
http://hboeck.de/

mail/jabber: hanno at hboeck.de
GPG: BBB51E42
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: </pipermail/attachments/20141024/47203c58/attachment.sig>

From dkg at fifthhorseman.net  Fri Oct 24 23:17:20 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 24 Oct 2014 17:17:20 -0400
Subject: 2.1 beta or release
In-Reply-To: <20141024222108.3eff0ba4@pc>
References: <87fvedbjx3.fsf@vigenere.g10code.de> <20141024222108.3eff0ba4@pc>
Message-ID: <544AC1E0.9090600@fifthhorseman.net>

On 10/24/2014 04:21 PM, Hanno B?ck wrote:
> What's the current status of ECC support?
> 
> The latest beta I checked had support for the NIST curves but not for
> curve25519. As far as I followed discussions (also around google's
> endtoend) curve25519 seems to be the thing people generally want to use
> in the future. Will 2.1 have curve25519 support? (and is this sign-only
> or also for encryption?)

curve25519 is available in the current master branch (signing only, not
encryption).

> Is there a consensus how to implement it in a compatible way between
> different pgp-implementations (that's probably mainly gpg and endtoend)?

afaict, endtoend isn't planning on using 25519, but i'd be happy to hear
that i'm wrong.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20141024/620eb7a1/attachment.sig>

From wk at gnupg.org  Sat Oct 25 12:08:01 2014
From: wk at gnupg.org (Werner Koch)
Date: Sat, 25 Oct 2014 12:08:01 +0200
Subject: 2.1 beta or release
In-Reply-To: <544AC1E0.9090600@fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Fri, 24 Oct 2014 17:17:20 -0400")
References: <87fvedbjx3.fsf@vigenere.g10code.de> <20141024222108.3eff0ba4@pc>
 <544AC1E0.9090600@fifthhorseman.net>
Message-ID: <87h9ysa2da.fsf@vigenere.g10code.de>

On Fri, 24 Oct 2014 23:17, dkg at fifthhorseman.net said:

> afaict, endtoend isn't planning on using 25519, but i'd be happy to hear
> that i'm wrong.

They want to do it and told me that they will use whatever GnuPG
implements.  Unfortuntaley they communicate mostly off-list.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From wk at gnupg.org  Sat Oct 25 12:21:34 2014
From: wk at gnupg.org (Werner Koch)
Date: Sat, 25 Oct 2014 12:21:34 +0200
Subject: 2.1 beta or release
In-Reply-To: <94C516AD-DA93-49B8-82DF-D380A0B1C435@sumptuouscapital.com>
 (Kristian fiskerstrand's message of "Fri, 24 Oct 2014 12:52:28 -0700")
References: <87fvedbjx3.fsf@vigenere.g10code.de>
 <94C516AD-DA93-49B8-82DF-D380A0B1C435@sumptuouscapital.com>
Message-ID: <87d29ga1qp.fsf@vigenere.g10code.de>

On Fri, 24 Oct 2014 21:52, kristian.fiskerstrand at sumptuouscapital.com
said:

> Any ETA for IANA assignment of algoid for the Ed25519 / EdDSA I-D? If

No.  I have an advise that I need to forward my request to the Security
Area Advisory Group for discussion for comments.  If there are no
problems and the CFRG has finished its curve selection job one of the
area directors is willing to sponsor the draft.  Unfortunately we do not
have a WG for OpenPGP anymore and thus everything has to pass the
individual submission process.  The IETF has no plans to reestablish the
OpenPGP WG.

I have some fear the curve discussion process of the CFRG has been
filibustered by parties which are not necessary friends of privacy.
Thus I do not want to wait for them any longer.  We have the informal
OpenPGP (non-)WG list agreement that 22 shall be used for EdDSA.  Thus
signing is all fine.

What about keyservers and EdDSA (22)?


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From nicholas.cole at gmail.com  Sat Oct 25 12:53:52 2014
From: nicholas.cole at gmail.com (Nicholas Cole)
Date: Sat, 25 Oct 2014 11:53:52 +0100
Subject: 2.1 beta or release
In-Reply-To: <87fvedbjx3.fsf@vigenere.g10code.de>
References: <87fvedbjx3.fsf@vigenere.g10code.de>
Message-ID: <CAAu18hcvohae=wqP4GxDpU=wfY_y+29SgG_kcGyAzVu3O1urUg@mail.gmail.com>

On Friday, 24 October 2014, Werner Koch <wk at gnupg.org> wrote:

> Hi!
>
> shall I do another beta before doing the release or shall I declare it
> ready, wait for some folks to report problems from a git build, and do
> the release after fixing them?
>
> In any case I expect that 2.1.0 will have a couple of build and runtime
> problems.  We simply do not enough testers.  A 2.1.1 will thus likely
> follow in shortly after 2.1.0.
>

Is there any advance on getting a build script together?  You'd get many
more testers if there were a script that would download all of the various
components and build them. I know various people have talked about this. If
not, I'll try to put something together myself.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20141025/98bc2b50/attachment-0001.html>

From kristian.fiskerstrand at sumptuouscapital.com  Sat Oct 25 13:08:42 2014
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian fiskerstrand)
Date: Sat, 25 Oct 2014 04:08:42 -0700
Subject: 2.1 beta or release
In-Reply-To: <CAAu18hcvohae=wqP4GxDpU=wfY_y+29SgG_kcGyAzVu3O1urUg@mail.gmail.com>
References: <87fvedbjx3.fsf@vigenere.g10code.de>
 <CAAu18hcvohae=wqP4GxDpU=wfY_y+29SgG_kcGyAzVu3O1urUg@mail.gmail.com>
Message-ID: <3FF88B13-7E7F-42FE-BBA3-D5F70DB2DF3F@sumptuouscapital.com>



Sent from my iPad

> On 25 Oct 2014, at 03:53, Nicholas Cole <nicholas.cole at gmail.com> wrote:
> 


..

> 
>> 
>> In any case I expect that 2.1.0 will have a couple of build and runtime
>> problems.  We simply do not enough testers.  A 2.1.1 will thus likely
>> follow in shortly after 2.1.0.
> 
> Is there any advance on getting a build script together?  You'd get many more testers if there were a script that would download all of the various components and build them. I know various people have talked about this. If not, I'll try to put something together myself.  

This is already handled if you're using a sane package manager for your distribution. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20141025/d0efbdb0/attachment.html>

From kristian.fiskerstrand at sumptuouscapital.com  Sat Oct 25 13:16:39 2014
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian fiskerstrand)
Date: Sat, 25 Oct 2014 04:16:39 -0700
Subject: 2.1 beta or release
In-Reply-To: <87d29ga1qp.fsf@vigenere.g10code.de>
References: <87fvedbjx3.fsf@vigenere.g10code.de>
 <94C516AD-DA93-49B8-82DF-D380A0B1C435@sumptuouscapital.com>
 <87d29ga1qp.fsf@vigenere.g10code.de>
Message-ID: <20C8B62C-9CC1-4AF4-9A63-504ABA197BC9@sumptuouscapital.com>



Sent from my iPad

> On 25 Oct 2014, at 03:21, Werner Koch <wk at gnupg.org> wrote:
> 
> On Fri, 24 Oct 2014 21:52, kristian.fiskerstrand at sumptuouscapital.com
> said:
> 
>> Any ETA for IANA assignment of algoid for the Ed25519 / EdDSA I-D? If
> 
> 

..

> What about keyservers and EdDSA (22)?
> 
> 

It works fine, but is currently only included in my mercurial patch queue and not part of the main repo. That said, it seems consensus is strong enough for algoid 22 that we can move that to the main developer branch and let it live there. atm there is no ETA for a new release of SKS, though. What I expect to do is to set the minimum requirement of the subset.pool.sks-keyservers.net to something support Ed25519 and test for the availability of proper parsing of this. In terms of actual downloading of keys, it should be available also from the older keyservers if using the option &clean=off for the op=get request

From wk at gnupg.org  Sat Oct 25 14:34:30 2014
From: wk at gnupg.org (Werner Koch)
Date: Sat, 25 Oct 2014 14:34:30 +0200
Subject: 2.1 beta or release
In-Reply-To: <20C8B62C-9CC1-4AF4-9A63-504ABA197BC9@sumptuouscapital.com>
 (Kristian fiskerstrand's message of "Sat, 25 Oct 2014 04:16:39 -0700")
References: <87fvedbjx3.fsf@vigenere.g10code.de>
 <94C516AD-DA93-49B8-82DF-D380A0B1C435@sumptuouscapital.com>
 <87d29ga1qp.fsf@vigenere.g10code.de>
 <20C8B62C-9CC1-4AF4-9A63-504ABA197BC9@sumptuouscapital.com>
Message-ID: <877fzo9vl5.fsf@vigenere.g10code.de>

On Sat, 25 Oct 2014 13:16, kristian.fiskerstrand at sumptuouscapital.com
said:

> Ed25519 and test for the availability of proper parsing of this. In
> terms of actual downloading of keys, it should be available also from
> the older keyservers if using the option &clean=off for the op=get

We do not have a way to enable this option in GnuPG, right?


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From wk at gnupg.org  Sat Oct 25 14:39:18 2014
From: wk at gnupg.org (Werner Koch)
Date: Sat, 25 Oct 2014 14:39:18 +0200
Subject: 2.1 beta or release
In-Reply-To: <CAAu18hcvohae=wqP4GxDpU=wfY_y+29SgG_kcGyAzVu3O1urUg@mail.gmail.com>
 (Nicholas Cole's message of "Sat, 25 Oct 2014 11:53:52 +0100")
References: <87fvedbjx3.fsf@vigenere.g10code.de>
 <CAAu18hcvohae=wqP4GxDpU=wfY_y+29SgG_kcGyAzVu3O1urUg@mail.gmail.com>
Message-ID: <8738ac9vd5.fsf@vigenere.g10code.de>

On Sat, 25 Oct 2014 12:53, nicholas.cole at gmail.com said:

> Is there any advance on getting a build script together?  You'd get many

Any serious problems with 

  make -f build-aux/speedo native INSTALL_DIR=/usr/local

?  Well, you need some standard developer's packages installed but that
is not different from other programs.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From wk at gnupg.org  Sat Oct 25 14:41:31 2014
From: wk at gnupg.org (Werner Koch)
Date: Sat, 25 Oct 2014 14:41:31 +0200
Subject: [PATCH] Add new lock-obj-pub for mips64el-unknown-linux-gnuabi64.
In-Reply-To: <1414173790-17859-1-git-send-email-dkg@fifthhorseman.net> (Daniel
 Kahn Gillmor's message of "Fri, 24 Oct 2014 14:03:10 -0400")
References: <1414173790-17859-1-git-send-email-dkg@fifthhorseman.net>
Message-ID: <87y4s48gp0.fsf@vigenere.g10code.de>

On Fri, 24 Oct 2014 20:03, dkg at fifthhorseman.net said:
> * src/syscfg/lock-obj-pub.mips64el-unknown-linux-gnuabi64.h: New.
> * src/Makefile.am (lock_obj_pub): Add.

Thanks.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From coruus at gmail.com  Sat Oct 25 15:39:41 2014
From: coruus at gmail.com (David Leon Gil)
Date: Sat, 25 Oct 2014 09:39:41 -0400
Subject: 2.1 beta or release
In-Reply-To: <87d29ga1qp.fsf@vigenere.g10code.de>
References: <87fvedbjx3.fsf@vigenere.g10code.de>
 <94C516AD-DA93-49B8-82DF-D380A0B1C435@sumptuouscapital.com>
 <87d29ga1qp.fsf@vigenere.g10code.de>
Message-ID: <CAA7UWsUvTAs+mM4Fz9-XxH8LVjZoK8pBm8fXKSSL0pJp0==S-A@mail.gmail.com>

On Sat, Oct 25, 2014 at 6:21 AM, Werner Koch <wk at gnupg.org> wrote:
> On Fri, 24 Oct 2014 21:52, kristian.fiskerstrand at sumptuouscapital.com
> said:
>
>> Any ETA for IANA assignment of algoid for the Ed25519 / EdDSA I-D? If
>
> No.  I have an advise that I need to forward my request to the Security
> Area Advisory Group for discussion for comments.  If there are no
> problems and the CFRG has finished its curve selection job one of the
> area directors is willing to sponsor the draft.  Unfortunately we do not
> have a WG for OpenPGP anymore and thus everything has to pass the
> individual submission process.  The IETF has no plans to reestablish the
> OpenPGP WG.

I think there will be difficulties with the Ed25519 draft.

The problem is that signing hashes with Ed25519 is not as secure as
signing *messages* with Ed25519. As it stands, at present, there is
nothing to prevent (for example) a signature on a RIPEMD-160 hash from
verifying as a signature on a colliding SHA-1 hash, or vice versa, as
I understand the code/proposal.

One of my previous comments on the draft was incorrect: I stated that
the security proof requires 512-bit (or longer) output. I've reviewed
the relevant paper; I believe that 256-bit output satisfies its
conditions. (So SHA-256 would be fine for Curve25519.)

I would like to avoid seeing the Ed25519 part too widely deployed
before this is fixed.

> I have some fear the curve discussion process of the CFRG has been
> filibustered by parties which are not necessary friends of privacy.
> Thus I do not want to wait for them any longer.  We have the informal
> OpenPGP (non-)WG list agreement that 22 shall be used for EdDSA.  Thus
> signing is all fine.

Yes. The CFRG process is...unpleasant. But it looks like (as one could
have predicted) Curve25519 will be selected, as well as an Edwards
curve mod 2^521-1.[1]

If anyone is interested in a non-NSA higher-security-strength curve
than Curve25519 at the moment, Bos et al. found a new "rigid"[2]]
Weierstrass curve modulo 2^521-1.

(It just requires adding new curve parameters, and fits without
modification into RFC 6637's ECDH and ECDSA specs.)

[1] The difficulty in proceeding with implementing the Edwards curve
is that there are several different ways you can take the twisted
Edwards proposal and map it to an Edwards curve.

[2]  It is the curve over Fq(2^521-1) with the smallest in absolute
value short-Weierstrass "b" that satisfies djb's SafeCurves
conditions. (b=167884)

(secp521's quadratic twist has cofactors 5, 7, 69697531, and
635884237. w-521-mers has cofactor 1 on both the curve and its twist.)

Page 5 of http://eprint.iacr.org/2014/130 has the details. (It's not
in the NUMS I-D.)


From wk at gnupg.org  Sat Oct 25 18:39:18 2014
From: wk at gnupg.org (Werner Koch)
Date: Sat, 25 Oct 2014 18:39:18 +0200
Subject: 2.1 beta or release
In-Reply-To: <CAA7UWsUvTAs+mM4Fz9-XxH8LVjZoK8pBm8fXKSSL0pJp0==S-A@mail.gmail.com>
 (David Leon Gil's message of "Sat, 25 Oct 2014 09:39:41 -0400")
References: <87fvedbjx3.fsf@vigenere.g10code.de>
 <94C516AD-DA93-49B8-82DF-D380A0B1C435@sumptuouscapital.com>
 <87d29ga1qp.fsf@vigenere.g10code.de>
 <CAA7UWsUvTAs+mM4Fz9-XxH8LVjZoK8pBm8fXKSSL0pJp0==S-A@mail.gmail.com>
Message-ID: <87tx2s85op.fsf@vigenere.g10code.de>

On Sat, 25 Oct 2014 15:39, coruus at gmail.com said:

> I would like to avoid seeing the Ed25519 part too widely deployed
> before this is fixed.

Sorry, there is nothing to fix.  Ed25519 is an algorithms which you
should not split up into hashing and signing part.  For OpenPGP we need
to be able to separate this.

Further, and probably most important, you won?t be able to do this with
a smartcard or any other token - passing the entire data to be signed
through the token is not possible due to limited I/O bandwidth.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From kristian.fiskerstrand at sumptuouscapital.com  Sat Oct 25 19:46:36 2014
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Sat, 25 Oct 2014 10:46:36 -0700
Subject: 2.1 beta or release
In-Reply-To: <877fzo9vl5.fsf@vigenere.g10code.de>
References: <87fvedbjx3.fsf@vigenere.g10code.de>	<94C516AD-DA93-49B8-82DF-D380A0B1C435@sumptuouscapital.com>	<87d29ga1qp.fsf@vigenere.g10code.de>	<20C8B62C-9CC1-4AF4-9A63-504ABA197BC9@sumptuouscapital.com>
 <877fzo9vl5.fsf@vigenere.g10code.de>
Message-ID: <544BE1FC.30109@sumptuouscapital.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 10/25/2014 05:34 AM, Werner Koch wrote:
> On Sat, 25 Oct 2014 13:16,
> kristian.fiskerstrand at sumptuouscapital.com said:
> 
>> Ed25519 and test for the availability of proper parsing of this.
>> In terms of actual downloading of keys, it should be available
>> also from the older keyservers if using the option &clean=off for
>> the op=get
> 
> We do not have a way to enable this option in GnuPG, right?

Not that I'm aware of at this point.

- -- 
- ----------------------------
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
- ----------------------------
"Whenever you find yourself on the side of the majority, it is time to
pause and reflect."
(Mark Twain)
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUS+H6AAoJEPw7F94F4Tag5CIQAJtoba3Xv3HlDcdLRTARSlEv
nxQHJJ2xoN9xXut4Vabt9fRd3uejVDMrrymiS4yot+ZPF5LNGl9j4hqeG5d6TW64
M1l1qZ3BdawC9UxAHUV29c/Oss2EO5BuW7VqV8JnDzclu3/eDh0o9Qe1VCXRqNbY
EN0vNU7FBZBWSzMqOTZQ5tjpFAZ5D6KnScWw2wv65AbfAIwQSNsetVMFT/S7EpUC
GSOXhCVYHUVrbmcCxAOG5rzy7OQVva3rnCq8IFcBf6aBLrfC1AwgORdQkTxmP5Ty
Y8uNy9S4mao6Z1+Rh4eta4cGoqw+bSyByfCR2aImCvjKanOr2/vuSHkSueU7Wdne
PfzUnHggePvjazENeuoaH3FMatHUKT3AqlXE18Gj38WRcWwntohkO5hwYbklaNkB
Kfsw7JKuPgqGVf3yhiFiCEeOJ61hk1spZvULMPNkgD77hyUAIrp9b6Nv+yB/qbor
59ZXz+q7L7e8RTGXItENOJoDLn7hVUo1DnsTYLxbQ/qL5M6nvxLKtOGTCxySsIV3
FjVNlZX5g3YfqfB890qOkGHjjtkvvAqxSxAOegcGe11NNk70IcQJVtq49kK+OvzU
IM4sLJwK6pPcb36jHzi/77WNslpnLkZZQxNwUQo1S2BHOue8Hn9CdYwmwJ8gX/nB
TTUi6Xj6tBab/4BKq/ne
=vVDe
-----END PGP SIGNATURE-----


From coruus at gmail.com  Sat Oct 25 20:09:55 2014
From: coruus at gmail.com (David Leon Gil)
Date: Sat, 25 Oct 2014 14:09:55 -0400
Subject: 2.1 beta or release
In-Reply-To: <87tx2s85op.fsf@vigenere.g10code.de>
References: <87fvedbjx3.fsf@vigenere.g10code.de>
 <94C516AD-DA93-49B8-82DF-D380A0B1C435@sumptuouscapital.com>
 <87d29ga1qp.fsf@vigenere.g10code.de>
 <CAA7UWsUvTAs+mM4Fz9-XxH8LVjZoK8pBm8fXKSSL0pJp0==S-A@mail.gmail.com>
 <87tx2s85op.fsf@vigenere.g10code.de>
Message-ID: <CAA7UWsUFZbfEBxnJOfAg0wMn=k0y_mYgMVZc7810wstY_T50XQ@mail.gmail.com>

On Sat, Oct 25, 2014 at 12:39 PM, Werner Koch <wk at gnupg.org> wrote:
> On Sat, 25 Oct 2014 15:39, coruus at gmail.com said:
>
>> I would like to avoid seeing the Ed25519 part too widely deployed
>> before this is fixed.
>
> Sorry, there is nothing to fix.  Ed25519 is an algorithms which you
> should not split up into hashing and signing part.  For OpenPGP we need
> to be able to separate this.
>
> Further, and probably most important, you won?t be able to do this with
> a smartcard or any other token - passing the entire data to be signed
> through the token is not possible due to limited I/O bandwidth.

There is a very simple way to fix any problems: Require that a
specific digest algorithm be used. (Just pick SHA-2-256 or SHA-2-512
at your preference; SHA-2-256 is faster in JS, SHA-2-512 is obviously
stronger.)

This remains compatible with hardware tokens with limited bandwidth,
it avoids any possibility of crossgrade attacks, and it simplifies
implementations. (It is not clear to me the relevance of hardware
tokens here, however: Do any support Ed25519?)

(There is a slightly more complicated way as well: let the input to
Ed25519 be HASH_OID||DIGEST.)


From wk at gnupg.org  Sat Oct 25 20:16:54 2014
From: wk at gnupg.org (Werner Koch)
Date: Sat, 25 Oct 2014 20:16:54 +0200
Subject: 2.1 beta or release
In-Reply-To: <CAA7UWsUFZbfEBxnJOfAg0wMn=k0y_mYgMVZc7810wstY_T50XQ@mail.gmail.com>
 (David Leon Gil's message of "Sat, 25 Oct 2014 14:09:55 -0400")
References: <87fvedbjx3.fsf@vigenere.g10code.de>
 <94C516AD-DA93-49B8-82DF-D380A0B1C435@sumptuouscapital.com>
 <87d29ga1qp.fsf@vigenere.g10code.de>
 <CAA7UWsUvTAs+mM4Fz9-XxH8LVjZoK8pBm8fXKSSL0pJp0==S-A@mail.gmail.com>
 <87tx2s85op.fsf@vigenere.g10code.de>
 <CAA7UWsUFZbfEBxnJOfAg0wMn=k0y_mYgMVZc7810wstY_T50XQ@mail.gmail.com>
Message-ID: <87ppdg8161.fsf@vigenere.g10code.de>

On Sat, 25 Oct 2014 20:09, coruus at gmail.com said:

> There is a very simple way to fix any problems: Require that a
> specific digest algorithm be used. (Just pick SHA-2-256 or SHA-2-512

It is your choice but GnuPG defaults to SHA-256 in this this case (and
most others.

> implementations. (It is not clear to me the relevance of hardware
> tokens here, however: Do any support Ed25519?)

Not yet but that is not the point.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From coruus at gmail.com  Sat Oct 25 20:55:38 2014
From: coruus at gmail.com (David Leon Gil)
Date: Sat, 25 Oct 2014 14:55:38 -0400
Subject: 2.1 beta or release
In-Reply-To: <87ppdg8161.fsf@vigenere.g10code.de>
References: <87fvedbjx3.fsf@vigenere.g10code.de>
 <94C516AD-DA93-49B8-82DF-D380A0B1C435@sumptuouscapital.com>
 <87d29ga1qp.fsf@vigenere.g10code.de>
 <CAA7UWsUvTAs+mM4Fz9-XxH8LVjZoK8pBm8fXKSSL0pJp0==S-A@mail.gmail.com>
 <87tx2s85op.fsf@vigenere.g10code.de>
 <CAA7UWsUFZbfEBxnJOfAg0wMn=k0y_mYgMVZc7810wstY_T50XQ@mail.gmail.com>
 <87ppdg8161.fsf@vigenere.g10code.de>
Message-ID: <CAA7UWsWSBbgNQyg+hsGOvmVjMMGC1HF9VF66eJB4J4skdFaMZw@mail.gmail.com>

On Sat, Oct 25, 2014 at 2:16 PM, Werner Koch <wk at gnupg.org> wrote:
> On Sat, 25 Oct 2014 20:09, coruus at gmail.com said:
>
>> There is a very simple way to fix any problems: Require that a
>> specific digest algorithm be used. (Just pick SHA-2-256 or SHA-2-512
>
> It is your choice but GnuPG defaults to SHA-256 in this this case (and
> most others.

If you want to provide a choice, you need to ensure that the inputs to
Ed25519 are domain-separated; the mechanism provided in RFC4880 (which
is rather bulky) is adding an OID. (Consider, e.g., if Blake2s or
SHA3-256 are specified for use with OpenPGP: the problem of forging a
colliding signature reduces to the difficulty of finding a collision
for the weakest hash-function with the same output length.)

I would also be quite content with prepending or appending the name of
the hash function as a character string.

I am also reasonably hopeful that other implementations will not
support verifying Ed25519-SHA1/RIPEMD160 signatures.


From pgut001 at cs.auckland.ac.nz  Sun Oct 26 10:31:23 2014
From: pgut001 at cs.auckland.ac.nz (Peter Gutmann)
Date: Sun, 26 Oct 2014 22:31:23 +1300
Subject: 2.1 beta or release
In-Reply-To: <87zjcl9ufz.fsf@vigenere.g10code.de>
Message-ID: <E1XiKAV-0000RA-O3@login01.fos.auckland.ac.nz>

Werner Koch <wk at gnupg.org> writes:

>Back in the 90ies it was quite different but now that even OpenSSL has a 1 as
>major version beta releases and 0.x are more or less useless :-(. This
>reminds me of GPA and Pinentry.

And Windows 8.1.  There was one component that MS had to re-release five times
over a period of about six months, and people are still reporting problems
with it.

So I think as long as you can limit yourself to less than five releases of 2.1
final you're still doing better than Microsoft.

Peter.


From wk at gnupg.org  Sun Oct 26 13:41:13 2014
From: wk at gnupg.org (Werner Koch)
Date: Sun, 26 Oct 2014 13:41:13 +0100
Subject: 2.1 beta or release
In-Reply-To: <87d29hxzff.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Fri, 24 Oct 2014 11:25:24 -0400")
References: <87fvedbjx3.fsf@vigenere.g10code.de>
 <87d29hxzff.fsf@alice.fifthhorseman.net>
Message-ID: <87bnoz80ly.fsf@vigenere.g10code.de>

On Fri, 24 Oct 2014 17:25, dkg at fifthhorseman.net said:
> On Fri 2014-10-24 10:51:20 -0400, Werner Koch wrote:
>> shall I do another beta before doing the release or shall I declare it
>> ready, wait for some folks to report problems from a git build, and do
>> the release after fixing them?
>
> having explicitly tagged explicit releases (beta or otherwise) makes it
> more straightforward for me to package it for debian, so i prefer that
> over trying to package the git head.

 ftp://ftp.gnupg.org/gcrypt/gnupg/unstable/gnupg-2.1.0-beta895.tar.bz2

with 

Noteworthy changes in version 2.1.0 (unreleased)
------------------------------------------------

 * gpg: All support for v3 (PGP 2) keys has been dropped.  All
   signatures are now creates as v4 signatures.

 * gpg: With pinentry-0.9.0 the passphrase "enter again" prompt shows
   up in the same window as the "new passphrase" prompt.

 * gpg: Allow importing keys with duplicated long key ids.

 * Dirmngr may now be build without support for LDAP.

 * For a complete list of changes see the lists of changes for the
   2.1.0 beta versions below.


You may also want to checkout pinentry-0.9.0.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From wk at gnupg.org  Mon Oct 27 22:38:10 2014
From: wk at gnupg.org (Werner Koch)
Date: Mon, 27 Oct 2014 22:38:10 +0100
Subject: 2.1 beta or release
In-Reply-To: <544E8858.9060208@enigmail.net> (Patrick Brunschwig's message of
 "Mon, 27 Oct 2014 19:00:56 +0100")
References: <87fvedbjx3.fsf@vigenere.g10code.de>
 <87d29hxzff.fsf@alice.fifthhorseman.net>
 <87bnoz80ly.fsf@vigenere.g10code.de> <544E8858.9060208@enigmail.net>
Message-ID: <87vbn55h31.fsf@vigenere.g10code.de>

On Mon, 27 Oct 2014 19:00, patrick at enigmail.net said:

> Assertion failed: (!res), function leave_npth, file npth.c, line 129.
> Abort trap: 6

That is due to an error returned by 

    res = sem_wait (&sceptre);

you need to check the ERRNO.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From bernhard at intevation.de  Tue Oct 28 14:45:42 2014
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 28 Oct 2014 14:45:42 +0100
Subject: I want to help improve the documentation.
In-Reply-To: <5442C186.8060409@riseup.net>
References: <5442C186.8060409@riseup.net>
Message-ID: <201410281445.48506.bernhard@intevation.de>

Hi Georgiy,

On Saturday 18 October 2014 at 21:37:42, Georgiy Treyvus wrote:
> Please let me know how I can be of help on this front and
> how to best integrate myself with the overall workflow here.

welcome as part of the GnuPG Initiative!
It is great that you want to help, we need all hands that we can get. :)

There are probably a number of places you could start
or where you can contribute directly.
When in doubt, it is always fine to ask here or on gnupg-users 
on how to progress a thing.

If you find obvious issues in the documentation coming with gnupg
just try to create a suggestion and a diff to the latest git-master.
You can probably use the issue tracker.

The website also needs help, I currently don't know how Werner organises
help there.

In addition I've started wiki.gnupg.org just pick a few TODOs there,
if you like. E.g. complete the listing of the already familiar types of 
documentation to get an overview.

You can also read here or on gnupg-users and try to answer questions by 
others.

Best Regards,
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: </pipermail/attachments/20141028/aa5e36d3/attachment.sig>

From dkg at fifthhorseman.net  Tue Oct 28 17:01:29 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 28 Oct 2014 12:01:29 -0400
Subject: I want to help improve the documentation.
In-Reply-To: <5442C186.8060409@riseup.net>
References: <5442C186.8060409@riseup.net>
Message-ID: <544FBDD9.1010005@fifthhorseman.net>

Hi Georgiy--

On 10/18/2014 03:37 PM, Georgiy Treyvus wrote:

> Thus what I'd like to do is help improve the documentation. If I were to
> take the time to expand, update, and rewrite more clearly various
> portions of the manual bit by bit as my time permits would you folks be
> willing to integrate these improvements into the official documentation?

I send patches to this mailing list, and many of them are merged.  I
don't think there's a guarantee that they'll all be merged, but it's
worth sending them so that there is something concrete to discuss.

I agree that the documentation could be improved, but i'm not sure that
"expanding" is the right direction in most cases :)

At any rate, if there are problems that you see that need to be
addressed, mailing patches to this list is a great way to start.

Using git should be useful.  Most of the generated documentation is
derived from doc/, which you should be able to edit with your editor of
choice:

 git clone git://git.gnupg.org/gnupg.git
 cd gnupg/doc
 $EDITOR gpg.texi

While it might be tempting to read through the whole thing and edit it
all at once, i recommend sending smaller patches that target a specific
issue first, since they are easier to review and accept (or reject, with
a concrete explanation) than a large rambling patch would be.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20141028/faec9ce5/attachment.sig>

From dkg at fifthhorseman.net  Tue Oct 28 21:40:18 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 28 Oct 2014 16:40:18 -0400
Subject: gpg-agent 2.1.x interop with gpg 1.4.x
In-Reply-To: <8738arrgch.fsf@vigenere.g10code.de>
References: <5436CF57.9060907@fifthhorseman.net>
 <8738ax3uwh.fsf@vigenere.g10code.de> <5436ED51.5000800@fifthhorseman.net>
 <8738arrgch.fsf@vigenere.g10code.de>
Message-ID: <87d29cudvx.fsf@alice.fifthhorseman.net>

On Mon 2014-10-13 14:10:06 -0400, Werner Koch wrote:
> On Thu,  9 Oct 2014 22:17, dkg at fifthhorseman.net said:
>
>> i don't think a wrapper for gpg-agent would be sufficient, would it?
>> gpg1 never invokes gpg-agent directly.
>
> Just so that user script keep on working as expected. Bit see below.
>
>> Another alternative, if you don't want to change anything in gpg 2.1
>> itself, is that we can modify the Xsession startup script
>> (/etc/X11/Xsession.d/90gpg-agent) that debian ships that enbles the
>
> That would indeed be the easiest way and better future-proof.

OK, so i'm taking this approach, i think it's sensible.

however, i'm now trying to use gpg-agent from 2.1.0~beta895 with gpg
1.4.18, and i'm seeing "gpg-agent protocol version 0 is not supported"

0 test at testmachine:~$ gpg-agent --daemon
0 test at testmachine:~$ export GPG_AGENT_INFO=${HOME}/.gnupg/.S.gpg-agent:0
0 test at testmachine:~$ echo test | gpg --clearsign

You need a passphrase to unlock the secret key for
user: "test user <test at example.org>"
2048-bit RSA key, ID 495CD78F, created 2014-10-28

gpg: gpg-agent protocol version 0 is not supported
Enter passphrase: 
gpg: Interrupt caught ... exiting

130 test at testmachine:~$ 


This suggests that we won't be able to mix and match the agent with gpg
1.4.x at all -- is that the plan for 2.1.0, or am i testing or building
something wrong?  Should i be able to use the gpg-agent from 2.1.0 with
gpg 1.4.x?

        --dkg

PS I'm concerned that all this work for the sake of co-installability
   and interoperability between local versions is distracting from the
   goal of getting 2.1.0 more widely, but (at least in debian) we've
   made a commitment to this strategy for the moment.

   Maybe that goal needs to be re-thought?  That's probably a topic for
   a separate thread of discussion.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: </pipermail/attachments/20141028/31c3d65c/attachment.sig>

From wk at gnupg.org  Tue Oct 28 21:44:51 2014
From: wk at gnupg.org (Werner Koch)
Date: Tue, 28 Oct 2014 21:44:51 +0100
Subject: 2.1 beta or release
In-Reply-To: <544F55F5.2000209@enigmail.net> (Patrick Brunschwig's message of
 "Tue, 28 Oct 2014 09:38:13 +0100")
References: <87fvedbjx3.fsf@vigenere.g10code.de>
 <87d29hxzff.fsf@alice.fifthhorseman.net>
 <87bnoz80ly.fsf@vigenere.g10code.de> <544E8858.9060208@enigmail.net>
 <87vbn55h31.fsf@vigenere.g10code.de> <544F55F5.2000209@enigmail.net>
Message-ID: <87vbn33ovw.fsf@vigenere.g10code.de>

On Tue, 28 Oct 2014 09:38, patrick at enigmail.net said:

> errno == ENOSYS /* Function not implemented */

Arghh.  Some AIX versions seem to have the same problem (I tested on
AIX 7).  POSIX says that sem_open is optional but not sem_init ;-).

So what do do?  The unnamed semaphore is what we actually want. Using
System V semaphores would call for a lot of trouble.  Should we try to
use sem_open ?  Is there anyone with OS X or old AIX access would would
like to implement that?


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From dkg at fifthhorseman.net  Tue Oct 28 22:50:56 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 28 Oct 2014 17:50:56 -0400
Subject: gpg-agent 2.1.x interop with gpg 1.4.x
In-Reply-To: <87d29cudvx.fsf@alice.fifthhorseman.net>
References: <5436CF57.9060907@fifthhorseman.net>
 <8738ax3uwh.fsf@vigenere.g10code.de> <5436ED51.5000800@fifthhorseman.net>
 <8738arrgch.fsf@vigenere.g10code.de> <87d29cudvx.fsf@alice.fifthhorseman.net>
Message-ID: <874munvp6n.fsf@alice.fifthhorseman.net>

On Tue 2014-10-28 16:40:18 -0400, Daniel Kahn Gillmor wrote:
> 0 test at testmachine:~$ gpg-agent --daemon
> 0 test at testmachine:~$ export GPG_AGENT_INFO=${HOME}/.gnupg/.S.gpg-agent:0
> 0 test at testmachine:~$ echo test | gpg --clearsign
>
> You need a passphrase to unlock the secret key for
> user: "test user <test at example.org>"
> 2048-bit RSA key, ID 495CD78F, created 2014-10-28
>
> gpg: gpg-agent protocol version 0 is not supported
> Enter passphrase: 
> gpg: Interrupt caught ... exiting
>
> 130 test at testmachine:~$ 
>
>
> This suggests that we won't be able to mix and match the agent with gpg
> 1.4.x at all -- is that the plan for 2.1.0, or am i testing or building
> something wrong?

Sigh.  Yes, i'm testing this wrong.

I should have been doing:

 export GPG_AGENT_INFO=${HOME}/.gnupg/S.gpg-agent:0:1

instead of:

 export GPG_AGENT_INFO=${HOME}/.gnupg/.S.gpg-agent:0

Carry on, nothing to see here.

(i did run into some funny business with pinentry-curses, but that's a
separate issue, which i'll report separately when i can figure it out)

      --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: </pipermail/attachments/20141028/1613894f/attachment.sig>

From wk at gnupg.org  Wed Oct 29 12:35:45 2014
From: wk at gnupg.org (Werner Koch)
Date: Wed, 29 Oct 2014 12:35:45 +0100
Subject: 2.1 beta or release
In-Reply-To: <544F55F5.2000209@enigmail.net> (Patrick Brunschwig's message of
 "Tue, 28 Oct 2014 09:38:13 +0100")
References: <87fvedbjx3.fsf@vigenere.g10code.de>
 <87d29hxzff.fsf@alice.fifthhorseman.net>
 <87bnoz80ly.fsf@vigenere.g10code.de> <544E8858.9060208@enigmail.net>
 <87vbn55h31.fsf@vigenere.g10code.de> <544F55F5.2000209@enigmail.net>
Message-ID: <871tpr2jn2.fsf@vigenere.g10code.de>

Hi,

[Patrick told me that he send a patch to the list but it doesn't made
it].

I have taken your patched as base for my patch.  My version is not OSX
specific but relies on the fact that sem_init returns ENOSYS.  That
seems to be used on other platforms as well.  POSIX is a bit unclear on
this.

I tested this on Linux by replacing sem_init with (-1) and setting
errno.  I also loop over sem_open using a counter for the name, so that
it is hard for another process to DoS us by guessing our pid and
creating a semaphore with that name.  Also the use of more than one '/'
in the name is implementation defined and does for example not work on
Linux.

Can you or the other OS X folks please test the attached patch to npth?


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Allow-use-on-systems-which-return-ENOSYS-for-sem_ini.patch
Type: text/x-diff
Size: 4036 bytes
Desc: not available
URL: </pipermail/attachments/20141029/89694e9d/attachment.patch>

From iomartin at iomartin.net  Wed Oct 29 12:48:34 2014
From: iomartin at iomartin.net (Martin Ichilevici de Oliveira)
Date: Wed, 29 Oct 2014 09:48:34 -0200
Subject: DCO for Martin Ichilevici de Oliveira
Message-ID: <20141029114834.GL31696@gamayun>

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: Martin Ichilevici de Oliveira <iomartin at iomartin dot net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: </pipermail/attachments/20141029/7ae28078/attachment.sig>

From iomartin at iomartin.net  Wed Oct 29 14:04:25 2014
From: iomartin at iomartin.net (Martin Ichilevici de Oliveira)
Date: Wed, 29 Oct 2014 11:04:25 -0200
Subject: [PATCH] doc: elaborate on --default-cache-ttl and --max-cache-ttl
Message-ID: <20141029130312.GN31696@gamayun>

The gpg-agent cache supports infinite ttl, through the --default-cache-ttl
option, which was not documented. That, however, is still subject to
--max-cache-ttl. This patch adds this documentation.

Inspired by Issue 1615: https://bugs.g10code.com/gnupg/issue1615
--

Signed-off-by: Martin Ichilevici de Oliveira <iomartin at iomartin dot net>
---
 doc/gpg-agent.texi | 19 ++++++++++++-------
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/doc/gpg-agent.texi b/doc/gpg-agent.texi
index 7eadf59..ff6f5e9 100644
--- a/doc/gpg-agent.texi
+++ b/doc/gpg-agent.texi
@@ -371,28 +371,33 @@ control this behaviour but this command line option takes precedence.
 
 @item --default-cache-ttl @var{n}
 @opindex default-cache-ttl
-Set the time a cache entry is valid to @var{n} seconds.  The default is
-600 seconds.
+Set the time a cache entry is valid to @var{n} seconds.  A value of
+-1 means infinite, but it is still subject to @option{--max-cache-ttl}.  The
+default is 600 seconds.
 
 @item --default-cache-ttl-ssh @var{n}
 @opindex default-cache-ttl
 Set the time a cache entry used for SSH keys is valid to @var{n}
-seconds.  The default is 1800 seconds.
+seconds.  A value of -1 means infinite, but it is still subject to
+ at option{--max-cache-ttl-ssh}.  The default is 1800 seconds.
 
 @item --max-cache-ttl @var{n}
 @opindex max-cache-ttl
 Set the maximum time a cache entry is valid to @var{n} seconds.  After
 this time a cache entry will be expired even if it has been accessed
-recently or has been set using @command{gpg-preset-passphrase}.  The
+recently or if it was set not to expire (either by using
+ at command{gpg-preset-passphrase} or with infinite time to live, as set by
+ at option{--default-cache-ttl}).  It should be a positive value.  The
 default is 2 hours (7200 seconds).
 
 @item --max-cache-ttl-ssh @var{n}
 @opindex max-cache-ttl-ssh
 Set the maximum time a cache entry used for SSH keys is valid to
 @var{n} seconds.  After this time a cache entry will be expired even
-if it has been accessed recently or has been set using
- at command{gpg-preset-passphrase}.  The default is 2 hours (7200
-seconds).
+if it has been accessed recently or if it was set not to expire (either by
+using @command{gpg-preset-passphrase} or with infinite time to live, as set by
+ at option{--default-cache-ttl-ssh}).  It should be a positive value.  The default
+is 2 hours (7200 seconds).
 
 @item --enforce-passphrase-constraints
 @opindex enforce-passphrase-constraints
-- 
2.1.2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: </pipermail/attachments/20141029/c7ab9529/attachment.sig>

From patrick at enigmail.net  Wed Oct 29 14:47:53 2014
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Wed, 29 Oct 2014 14:47:53 +0100
Subject: 2.1 beta or release
In-Reply-To: <871tpr2jn2.fsf@vigenere.g10code.de>
References: <87fvedbjx3.fsf@vigenere.g10code.de>	<87d29hxzff.fsf@alice.fifthhorseman.net>	<87bnoz80ly.fsf@vigenere.g10code.de>
 <544E8858.9060208@enigmail.net>	<87vbn55h31.fsf@vigenere.g10code.de>
 <544F55F5.2000209@enigmail.net> <871tpr2jn2.fsf@vigenere.g10code.de>
Message-ID: <5450F009.9030701@enigmail.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 29.10.14 12:35, Werner Koch wrote:
> Hi,
> 
> [Patrick told me that he send a patch to the list but it doesn't 
> made it].
> 
> I have taken your patched as base for my patch.  My version is not 
> OSX specific but relies on the fact that sem_init returns ENOSYS. 
> That seems to be used on other platforms as well.  POSIX is a bit 
> unclear on this.
> 
> I tested this on Linux by replacing sem_init with (-1) and setting
>  errno.  I also loop over sem_open using a counter for the name,
> so that it is hard for another process to DoS us by guessing our
> pid and creating a semaphore with that name.  Also the use of more
> than one '/' in the name is implementation defined and does for
> example not work on Linux.
> 
> Can you or the other OS X folks please test the attached patch to 
> npth?

I applied the patch the patch -- it works fine on OS X :-).

- -Patrick

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJUUPAIAAoJEMk25cDiHiw+XnUIAIlL73VYZeR6k3NySLy0H0a1
ePUyOku+uY54KoJSP2Uderb2VCwrwvD3+ss7QfDjUbesrI3G4VNK1IxJhks1NTol
UCNZyGEc/7npytO3Jz90P21wrHswnh+qAlE2czIIYXCXcPL7RdcnKPSB19XkFanW
kX5Goy57gFj1KlkABWtAxlgLuiifloovdSybkRyAIMeW9foV2vkV5C19Uixn1UuS
tGsJQtiTcljJom+OIr4pqc2J022iTqol9R4TtoY5FZRyHD9fDJfac4HF2xoTriUX
N7QT5QEFNboNzQdFDOYal3MckhqUW6vmVkW0gZPha73BfcvGITSPxwESnQyPsmk=
=0uUj
-----END PGP SIGNATURE-----


From patrick at enigmail.net  Wed Oct 29 15:23:47 2014
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Wed, 29 Oct 2014 15:23:47 +0100
Subject: GnuPG 2.1.0 beta 895 for Mac OS X
Message-ID: <5450F873.6030304@enigmail.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I started a new project to prepare GnuPG 2.1.x distributions on Mac OS
X. The 1st beta of my work, based on GnuPG 2.1.0-beta895 is now
available (still pending documentation and a lot more) from:
https://sourceforge.net/projects/gpgosx/files/

I'd be happy if some people install and test it to see if also works
on other computers than my own.

Requirements
============
Mac OS X 10.7 or newer with 64-bit Intel processor.

Notes
=====
The installation package is not (yet) signed; on Mavericks (and I
guess on Yosemite as well) you'll need to install it using
Right-Mouse-Click -> Open

- -Patrick
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJUUPhuAAoJEMk25cDiHiw+gwkH/iqZwBpCHeODXzK+fPq7Kb28
JoJ9usycD5J/abmQU3vzzqn6DiEmS7uCeZnfWilTq84nDpnxUqQEy6mrccYlX7zV
EhHdKYtvZ82XelTafPVaPY52YaiB4rptdPN9pN0OgcMv0uhsydBXsMtqK+uKTIxo
NuwJ9Zy84+vAGvVMwNqwyDjLR3Zd9BXIfYwSd+GDmIGX5ms4CJ3cLWhzBTp9lamO
lYm78cZ4R0EvqWv2C/qkmh0gB0/2lm3yDrcazOOcsP/VIiUiYTz8rAPnzVD2ROl7
X75XLuohTO5CYlbdsFBu40O31xpvbDC3tp7lxB5wkc1kon1w0sSvKyW33k5Zqz0=
=QMMs
-----END PGP SIGNATURE-----


From wk at gnupg.org  Wed Oct 29 15:43:49 2014
From: wk at gnupg.org (Werner Koch)
Date: Wed, 29 Oct 2014 15:43:49 +0100
Subject: 2.1 beta or release
In-Reply-To: <5450F009.9030701@enigmail.net> (Patrick Brunschwig's message of
 "Wed, 29 Oct 2014 14:47:53 +0100")
References: <87fvedbjx3.fsf@vigenere.g10code.de>
 <87d29hxzff.fsf@alice.fifthhorseman.net>
 <87bnoz80ly.fsf@vigenere.g10code.de> <544E8858.9060208@enigmail.net>
 <87vbn55h31.fsf@vigenere.g10code.de> <544F55F5.2000209@enigmail.net>
 <871tpr2jn2.fsf@vigenere.g10code.de> <5450F009.9030701@enigmail.net>
Message-ID: <87bnov0wd6.fsf@vigenere.g10code.de>

On Wed, 29 Oct 2014 14:47, patrick at enigmail.net said:

> I applied the patch the patch -- it works fine on OS X :-).

great.  I'll prepare a new npth.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From wk at gnupg.org  Wed Oct 29 16:08:46 2014
From: wk at gnupg.org (Werner Koch)
Date: Wed, 29 Oct 2014 16:08:46 +0100
Subject: [PATCH] doc: elaborate on --default-cache-ttl and --max-cache-ttl
In-Reply-To: <20141029130312.GN31696@gamayun> (Martin Ichilevici de Oliveira's
 message of "Wed, 29 Oct 2014 11:04:25 -0200")
References: <20141029130312.GN31696@gamayun>
Message-ID: <877fzi29s1.fsf@vigenere.g10code.de>

On Wed, 29 Oct 2014 14:04, iomartin at iomartin.net said:
> The gpg-agent cache supports infinite ttl, through the --default-cache-ttl
> option, which was not documented. That, however, is still subject to
> --max-cache-ttl. This patch adds this documentation.

Well, what you see is a buglet.  It is not intentional.

What happens is that the argument is converted to an unsigned long using
strtoul but at some point that value is assigned to an int which may
then turn to a negative.  This is due to a strange strtoul feature which
I almost always forget about: a sign in the string is legal.

I also do not think that it makes sense to have such a feature in
particular not due to the explict limit set by --max-cache-ttl.
However, if this is desired the argument parser needs to be changed to
explicitly take a signed argument.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From iomartin at iomartin.net  Wed Oct 29 16:34:02 2014
From: iomartin at iomartin.net (Martin Ichilevici de Oliveira)
Date: Wed, 29 Oct 2014 13:34:02 -0200
Subject: [PATCH] doc: elaborate on --default-cache-ttl and --max-cache-ttl
In-Reply-To: <877fzi29s1.fsf@vigenere.g10code.de>
References: <20141029130312.GN31696@gamayun>
 <877fzi29s1.fsf@vigenere.g10code.de>
Message-ID: <20141029153402.GQ31696@gamayun>

On Wed, Oct 29, 2014 at 04:08:46PM +0100, Werner Koch wrote:
> On Wed, 29 Oct 2014 14:04, iomartin at iomartin.net said:
> > The gpg-agent cache supports infinite ttl, through the --default-cache-ttl
> > option, which was not documented. That, however, is still subject to
> > --max-cache-ttl. This patch adds this documentation.
> 
> Well, what you see is a buglet.  It is not intentional.
> 
> What happens is that the argument is converted to an unsigned long using
> strtoul but at some point that value is assigned to an int which may
> then turn to a negative.  This is due to a strange strtoul feature which
> I almost always forget about: a sign in the string is legal.

Hello, Werner.

I'm not sure I'm following you here. On agent/cache.c, the declaration
of struct cache_item_s is

    struct cache_item_s {
      ITEM next;
      time_t created;
      time_t accessed;
      int ttl;  /* max. lifetime given in seconds, -1 one means infinite */
      struct secret_data_s *pw;
      cache_mode_t cache_mode;
      char key[1];
    };

on what situations could we have ttl < 0 then if not with
default-cache-ttl? Is that what gpg-set-passphrase is for?

Also, on the housekeeping function we check if r->ttl >= 0 before expiring a
passphrase.

> I also do not think that it makes sense to have such a feature in
> particular not due to the explict limit set by --max-cache-ttl.
> However, if this is desired the argument parser needs to be changed to
> explicitly take a signed argument.

From what I understood (please correct me if I'm wrong), using
default-cache-ttl = -1 is essentialy the same as using gpg-set-passphrase
for all passphrases. So that was the idea behind this patch, given the
decision on the patch 

Do you mean that if you someone wants to have all passphrases to have
infinite ttl, then they should explicitly use gpg-set-passphrase for all
of them?

Finally, what is the rationale behind max-cache-ttl not allowing
"infinite"? Afterall, in practice, it could be achieved by setting an
extremely high value for max-cache-ttl. I'd be happy to work on a patch
to support this, if you think it's OK.

Cheers,
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: </pipermail/attachments/20141029/b0f3cee1/attachment.sig>

From bernhard at intevation.de  Wed Oct 29 16:57:19 2014
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 29 Oct 2014 16:57:19 +0100
Subject: key length/size RSA discussion/recommendations in the wiki
Message-ID: <201410291657.24769.bernhard@intevation.de>

Because this gets asked quite often, I've started to capture
some arguments of the debate how long RSAs could/should/can be
at http://wiki.gnupg.org/LargeKeys

Werner seems to repeat his arguments too often, so I believe we need a place
to collect a really good reasoning to point people to. Let me know what I've 
missed or enter it directly.

(It is easy to edit in the wiki, just use your bugs.gnupg.org credentials.) 

-- 
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: </pipermail/attachments/20141029/8da3952a/attachment.sig>

From wk at gnupg.org  Wed Oct 29 17:35:05 2014
From: wk at gnupg.org (Werner Koch)
Date: Wed, 29 Oct 2014 17:35:05 +0100
Subject: [PATCH] doc: elaborate on --default-cache-ttl and --max-cache-ttl
In-Reply-To: <20141029153402.GQ31696@gamayun> (Martin Ichilevici de Oliveira's
 message of "Wed, 29 Oct 2014 13:34:02 -0200")
References: <20141029130312.GN31696@gamayun>
 <877fzi29s1.fsf@vigenere.g10code.de> <20141029153402.GQ31696@gamayun>
Message-ID: <8738a625s6.fsf@vigenere.g10code.de>

On Wed, 29 Oct 2014 16:34, iomartin at iomartin.net said:

> I'm not sure I'm following you here. On agent/cache.c, the declaration
> of struct cache_item_s is

That one is for the internal API.  The command line optiosn are a
different thing.  Actually, I just pushed a patch which checks the
ranges of numerical arguments.  With that using -1 is not any long
possible.

> on what situations could we have ttl < 0 then if not with
> default-cache-ttl? Is that what gpg-set-passphrase is for?

For example via cmd_preset_passphrase().

> Do you mean that if you someone wants to have all passphrases to have
> infinite ttl, then they should explicitly use gpg-set-passphrase for all
> of them?

If you want set, you should simply remove the passpharses from the keys.

> Finally, what is the rationale behind max-cache-ttl not allowing
> "infinite"? Afterall, in practice, it could be achieved by setting an
> extremely high value for max-cache-ttl. I'd be happy to work on a patch

Exactly, use something like 0x00ffffff (194 days).  There is small bug
lingering in the code if you use a too high value, though.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From dkg at fifthhorseman.net  Thu Oct 30 00:05:33 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 29 Oct 2014 19:05:33 -0400
Subject: genkey1024.test hanging on low-entropy systems
Message-ID: <87y4rytr2a.fsf@alice.fifthhorseman.net>

hi GnuPG folks--

When i "make check", it looks to me like genkey1024.test is hanging on
low-entropy systems while executing:

  ../../g10/gpg2 --no-permission-warning --quiet --batch --gen-key

should the tests use --debug-quick-random to avoid a hang?  Is there any
reason that we should need to use strong entropy during the make check
process?

       --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: </pipermail/attachments/20141029/ea517f66/attachment.sig>

From wk at gnupg.org  Thu Oct 30 09:56:30 2014
From: wk at gnupg.org (Werner Koch)
Date: Thu, 30 Oct 2014 09:56:30 +0100
Subject: genkey1024.test hanging on low-entropy systems
In-Reply-To: <87y4rytr2a.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Wed, 29 Oct 2014 19:05:33 -0400")
References: <87y4rytr2a.fsf@alice.fifthhorseman.net>
Message-ID: <87ioj2ylz5.fsf@vigenere.g10code.de>

On Thu, 30 Oct 2014 00:05, dkg at fifthhorseman.net said:

> should the tests use --debug-quick-random to avoid a hang?  Is there any

That does not works because gpg-agent creates the key.  It is a bit
complicated to start gpg-agent in lower random quality mode.  I added a
command line only option --debug-quick-random to gpg-agent and some
hacks to allow passing it to the start-the-agent-on-the-fly code.

Pushed.

Thanks for reminding about this.  I usuallay resort to the rngd hack ;-).


Salam-Shalom,

   Werner

==
commit 9546aa3cc87fc83a40768a12fbbceb19496ce129 (HEAD, refs/heads/wk-master)
Author: Werner Koch <wk at gnupg.org>
Date:   Thu Oct 30 09:55:51 2014 +0100

    tests: Speed up the genkey1024.test by using not so strong random.
    
    * agent/gpg-agent.c (oDebugQuickRandom): New.
    (opts): New option --debug-quick-random.
    (main): Use new option.
    * common/asshelp.c (start_new_gpg_agent): Add hack to pass an
    additional argument for the agent name.
    * tests/openpgp/defs.inc: Pass --debug-quick-random to the gpg-agent
    starting parameters.
    * tests/openpgp/version.test: Ditto.
    
    Signed-off-by: Werner Koch <wk at gnupg.org>

	Modified   agent/gpg-agent.c
diff --git a/agent/gpg-agent.c b/agent/gpg-agent.c
index af91506..3f03ff4 100644
--- a/agent/gpg-agent.c
+++ b/agent/gpg-agent.c
@@ -81,6 +81,7 @@ enum cmd_and_opt_values
   oDebugAll,
   oDebugLevel,
   oDebugWait,
+  oDebugQuickRandom,
   oNoGreeting,
   oNoOptions,
   oHomedir,
@@ -149,6 +150,7 @@ static ARGPARSE_OPTS opts[] = {
   { oDebugAll, "debug-all"     ,0, "@"},
   { oDebugLevel, "debug-level" ,2, "@"},
   { oDebugWait,"debug-wait",1, "@"},
+  ARGPARSE_s_n (oDebugQuickRandom, "debug-quick-random", "@"),
   { oNoDetach, "no-detach" ,0, N_("do not detach from the console")},
   { oNoGrab, "no-grab"     ,0, N_("do not grab keyboard and mouse")},
   { oLogFile, "log-file"   ,2, N_("use a log file for the server")},
@@ -730,6 +732,11 @@ main (int argc, char **argv )
           default_config = 0; /* --no-options */
 	else if (pargs.r_opt == oHomedir)
           opt.homedir = pargs.r.ret_str;
+	else if (pargs.r_opt == oDebugQuickRandom)
+          {
+            gcry_control (GCRYCTL_ENABLE_QUICK_RANDOM, 0);
+          }
+
     }
 
   /* Initialize the secure memory. */
@@ -847,6 +854,10 @@ main (int argc, char **argv )
 #        endif
           break;
 
+        case oDebugQuickRandom:
+          /* Only used by the first stage command line parser.  */
+          break;
+
         case oWriteEnvFile: /* dummy */ break;
 
         default : pargs.err = configfp? 1:2; break;
	Modified   common/asshelp.c
diff --git a/common/asshelp.c b/common/asshelp.c
index e97d396..3fc28a1 100644
--- a/common/asshelp.c
+++ b/common/asshelp.c
@@ -363,7 +363,7 @@ start_new_gpg_agent (assuan_context_t *r_ctx,
   assuan_context_t ctx;
   int did_success_msg = 0;
   char *sockname;
-  const char *argv[5];
+  const char *argv[6];
 
   *r_ctx = NULL;
 
@@ -380,10 +380,31 @@ start_new_gpg_agent (assuan_context_t *r_ctx,
     {
       char *abs_homedir;
       lock_spawn_t lock;
+      char *program = NULL;
+      const char *program_arg = NULL;
+      char *p;
+      const char *s;
+      int i;
 
       /* With no success start a new server.  */
       if (!agent_program || !*agent_program)
         agent_program = gnupg_module_name (GNUPG_MODULE_NAME_AGENT);
+      else if ((s=strchr (agent_program, '|')) && s[1] == '-' && s[2]=='-')
+        {
+          /* Hack to insert an additional option on the command line.  */
+          program = xtrystrdup (agent_program);
+          if (!program)
+            {
+              gpg_error_t tmperr = gpg_err_make (errsource,
+                                                 gpg_err_code_from_syserror ());
+              xfree (sockname);
+              assuan_release (ctx);
+              return tmperr;
+            }
+          p = strchr (program, '|');
+          *p++ = 0;
+          program_arg = p;
+        }
 
       if (verbose)
         log_info (_("no running gpg-agent - starting '%s'\n"),
@@ -404,6 +425,7 @@ start_new_gpg_agent (assuan_context_t *r_ctx,
           log_error ("error building filename: %s\n",gpg_strerror (tmperr));
           xfree (sockname);
           assuan_release (ctx);
+          xfree (program);
           return tmperr;
         }
 
@@ -416,30 +438,32 @@ start_new_gpg_agent (assuan_context_t *r_ctx,
           xfree (sockname);
           assuan_release (ctx);
           xfree (abs_homedir);
+          xfree (program);
           return tmperr;
         }
 
       /* If the agent has been configured for use with a standard
          socket, an environment variable is not required and thus
          we we can savely start the agent here.  */
-
-      argv[0] = "--homedir";
-      argv[1] = abs_homedir;
-      argv[2] = "--use-standard-socket";
-      argv[3] = "--daemon";
-      argv[4] = NULL;
+      i = 0;
+      argv[i++] = "--homedir";
+      argv[i++] = abs_homedir;
+      argv[i++] = "--use-standard-socket";
+      if (program_arg)
+        argv[i++] = program_arg;
+      argv[i++] = "--daemon";
+      argv[i++] = NULL;
 
       if (!(err = lock_spawning (&lock, homedir, "agent", verbose))
           && assuan_socket_connect (ctx, sockname, 0, 0))
         {
-          err = gnupg_spawn_process_detached (agent_program, argv,NULL);
+          err = gnupg_spawn_process_detached (program? program : agent_program,
+                                              argv, NULL);
           if (err)
             log_error ("failed to start agent '%s': %s\n",
                        agent_program, gpg_strerror (err));
           else
             {
-              int i;
-
               for (i=0; i < SECS_TO_WAIT_FOR_AGENT; i++)
                 {
                   if (verbose)
@@ -462,6 +486,7 @@ start_new_gpg_agent (assuan_context_t *r_ctx,
 
       unlock_spawning (&lock, "agent");
       xfree (abs_homedir);
+      xfree (program);
     }
   xfree (sockname);
   if (err)
	Modified   doc/gpg-agent.texi
diff --git a/doc/gpg-agent.texi b/doc/gpg-agent.texi
index 7eadf59..a4079d7 100644
--- a/doc/gpg-agent.texi
+++ b/doc/gpg-agent.texi
@@ -293,6 +293,14 @@ When running in server mode, wait @var{n} seconds before entering the
 actual processing loop and print the pid.  This gives time to attach a
 debugger.
 
+ at item --debug-quick-random
+ at opindex debug-quick-random
+This option inhibits the use the very secure random quality level
+(Libgcrypt?s @code{GCRY_VERY_STRONG_RANDOM}) and degrades all request
+down to standard random quality.  It is only used for testing and
+shall not be used for any production quality keys.  This option is
+only effective when given on the command line.
+
 @item --no-detach
 @opindex no-detach
 Don't detach the process from the console.  This is mainly useful for
	Modified   doc/gpg.texi
diff --git a/doc/gpg.texi b/doc/gpg.texi
index cddf462..e894f5c 100644
--- a/doc/gpg.texi
+++ b/doc/gpg.texi
@@ -1710,7 +1710,10 @@ This is dummy option. It has no effect when used with @command{gpg2}.
 @item --agent-program @var{file}
 @opindex agent-program
 Specify an agent program to be used for secret key operations.  The
-default value is the @file{/usr/bin/gpg-agent}.
+default value is determined by running @command{gpgconf} with the
+option @option{--list-dirs}.  Note that the pipe symbol (@code{|}) is
+used for a regression test suite hack and may thus not be used in the
+file name.
 @ifclear gpgtwoone
 This is only used
 as a fallback when the environment variable @code{GPG_AGENT_INFO} is not
	Modified   doc/gpgsm.texi
diff --git a/doc/gpgsm.texi b/doc/gpgsm.texi
index bc6326c..34b6024 100644
--- a/doc/gpgsm.texi
+++ b/doc/gpgsm.texi
@@ -358,7 +358,9 @@ Change the default name of the policy file to @var{filename}.
 @item --agent-program @var{file}
 @opindex agent-program
 Specify an agent program to be used for secret key operations.  The
-default value is the @file{/usr/local/bin/gpg-agent}.
+default value is determined by running the command @command{gpgconf}.
+Note that the pipe symbol (@code{|}) is used for a regression test
+suite hack and may thus not be used in the file name.
 @ifclear gpgtwoone
 This is only used
 as a fallback when the environment variable @code{GPG_AGENT_INFO} is not
	Modified   doc/tools.texi
diff --git a/doc/tools.texi b/doc/tools.texi
index d9ce81e..d556b6d 100644
--- a/doc/tools.texi
+++ b/doc/tools.texi
@@ -1199,7 +1199,11 @@ Try to be as quiet as possible.
 
 @item --agent-program @var{file}
 @opindex agent-program
-Specify the agent program to be started if none is running.
+Specify the agent program to be started if none is running.  The
+default value is determined by running @command{gpgconf} with the
+option @option{--list-dirs}.  Note that the pipe symbol (@code{|}) is
+used for a regression test suite hack and may thus not be used in the
+file name.
 
 @ifset gpgtwoone
 @item --dirmngr-program @var{file}
	Modified   tests/openpgp/defs.inc
diff --git a/tests/openpgp/defs.inc b/tests/openpgp/defs.inc
index b7320d5..941f786 100755
--- a/tests/openpgp/defs.inc
+++ b/tests/openpgp/defs.inc
@@ -244,10 +244,9 @@ for f in gpg.conf gpg-agent.conf ; do
     case "$f" in
       gpg.conf)
         [ -n "${opt_always}" ] && echo "no-auto-check-trustdb" >>"$f"
-        echo "agent-program $GPG_AGENT" >>"$f"
+        echo "agent-program ${GPG_AGENT}|--debug-quick-random" >>"$f"
         echo "allow-weak-digest-algos" >>"$f"
-
-      ;;
+        ;;
       gpg-agent.conf)
         echo "pinentry-program $PINENTRY" >>"$f"
         ;;
	Modified   tests/openpgp/version.test
diff --git a/tests/openpgp/version.test b/tests/openpgp/version.test
index cae8b68..057bcf0 100755
--- a/tests/openpgp/version.test
+++ b/tests/openpgp/version.test
@@ -39,9 +39,12 @@ done
 # create a faked random seed file.  Note that we need to set the
 # agent-program so that gpg-connect-agent is able to start the agent
 # we are currently testing and not an already installed one.
+# The "|--debug-quick-random" is a hack to start gpg-agent with
+# that option on the command line.
 info "Starting the agent"
 $MKTDATA 600 >random_seed
-if $GPG_CONNECT_AGENT -v --agent-program="$GPG_AGENT" /bye; then
+if $GPG_CONNECT_AGENT -v \
+    --agent-program="${GPG_AGENT}|--debug-quick-random" /bye; then
     :
 else
     error "starting the gpg-agent failed"



-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From iomartin at iomartin.net  Thu Oct 30 14:32:55 2014
From: iomartin at iomartin.net (Martin Ichilevici de Oliveira)
Date: Thu, 30 Oct 2014 11:32:55 -0200
Subject: [PATCH] doc: elaborate on --default-cache-ttl and --max-cache-ttl
In-Reply-To: <8738a625s6.fsf@vigenere.g10code.de>
References: <20141029130312.GN31696@gamayun>
 <877fzi29s1.fsf@vigenere.g10code.de>
 <20141029153402.GQ31696@gamayun>
 <8738a625s6.fsf@vigenere.g10code.de>
Message-ID: <20141030133255.GA8638@gamayun>

On Wed, Oct 29, 2014 at 05:35:05PM +0100, Werner Koch wrote:
> On Wed, 29 Oct 2014 16:34, iomartin at iomartin.net said:
> 
> > I'm not sure I'm following you here. On agent/cache.c, the declaration
> > of struct cache_item_s is
> 
> That one is for the internal API.  The command line optiosn are a
> different thing.  Actually, I just pushed a patch which checks the
> ranges of numerical arguments.  With that using -1 is not any long
> possible.
> 
> > on what situations could we have ttl < 0 then if not with
> > default-cache-ttl? Is that what gpg-set-passphrase is for?
> 
> For example via cmd_preset_passphrase().

Ok, got it.

> > Finally, what is the rationale behind max-cache-ttl not allowing
> > "infinite"? Afterall, in practice, it could be achieved by setting an
> > extremely high value for max-cache-ttl. I'd be happy to work on a patch
> 
> Exactly, use something like 0x00ffffff (194 days).  There is small bug
> lingering in the code if you use a too high value, though.

Werner,

I'm sorry (and I don't mean to be annoying), but I still don't
understand why gnupg doesn't support infinite ttl? Is it by design or
just because it was never implemented?

Thanks,
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: </pipermail/attachments/20141030/9cecfe98/attachment.sig>

From wk at gnupg.org  Thu Oct 30 15:22:31 2014
From: wk at gnupg.org (Werner Koch)
Date: Thu, 30 Oct 2014 15:22:31 +0100
Subject: [PATCH] doc: elaborate on --default-cache-ttl and --max-cache-ttl
In-Reply-To: <20141030133255.GA8638@gamayun> (Martin Ichilevici de Oliveira's
 message of "Thu, 30 Oct 2014 11:32:55 -0200")
References: <20141029130312.GN31696@gamayun>
 <877fzi29s1.fsf@vigenere.g10code.de> <20141029153402.GQ31696@gamayun>
 <8738a625s6.fsf@vigenere.g10code.de> <20141030133255.GA8638@gamayun>
Message-ID: <87tx2ly6vs.fsf@vigenere.g10code.de>

On Thu, 30 Oct 2014 14:32, iomartin at iomartin.net said:

> I'm sorry (and I don't mean to be annoying), but I still don't
> understand why gnupg doesn't support infinite ttl? Is it by design or

What is the use case case for this?  I can't see one except to work
around a bogus security policy.  If you do not have a need for a
passphrase you should not use a passphrase for the protection of your
secret key.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From iomartin at iomartin.net  Thu Oct 30 15:48:30 2014
From: iomartin at iomartin.net (Martin Ichilevici de Oliveira)
Date: Thu, 30 Oct 2014 12:48:30 -0200
Subject: [PATCH] doc: elaborate on --default-cache-ttl and --max-cache-ttl
In-Reply-To: <87tx2ly6vs.fsf@vigenere.g10code.de>
References: <20141029130312.GN31696@gamayun>
 <877fzi29s1.fsf@vigenere.g10code.de>
 <20141029153402.GQ31696@gamayun>
 <8738a625s6.fsf@vigenere.g10code.de>
 <20141030133255.GA8638@gamayun>
 <87tx2ly6vs.fsf@vigenere.g10code.de>
Message-ID: <20141030144830.GB8638@gamayun>

On Thu, Oct 30, 2014 at 03:22:31PM +0100, Werner Koch wrote:
> On Thu, 30 Oct 2014 14:32, iomartin at iomartin.net said:
> 
> > I'm sorry (and I don't mean to be annoying), but I still don't
> > understand why gnupg doesn't support infinite ttl? Is it by design or
> 
> What is the use case case for this?  I can't see one except to work
> around a bogus security policy.  If you do not have a need for a
> passphrase you should not use a passphrase for the protection of your
> secret key.

I see what you mean.

Personally, I use gnupg mostly for signing email, and once in a while
for encrypting it. I don't want to enter my passphrase every so often,
but at the same time I didn't like the idea of using no passhprase at
all.

Given that I usually reboot my computer around once a week, I found it
to be a good compromise (in my case), to enter it once and then not
worrying. I achieved that with a high ttl, but this just feels clumsy to
me. Maybe that's what you'll call a bogus security policy - and you
might be right - but it just seems cleaner to use -1 instead.

Cheers,
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: </pipermail/attachments/20141030/c7fefe93/attachment.sig>

From patrick at enigmail.net  Thu Oct 30 16:22:31 2014
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Thu, 30 Oct 2014 16:22:31 +0100
Subject: Lots of "packet(6) too short" errors with gpg 2.1
Message-ID: <545257B7.4080905@enigmail.net>

After migration to gpg 2.1, I get lots of "packet(6) too short" when
doing e.g. gpg --list-keys. Furthermore, gpg exits with exit code=2.

Is there anything I'm doing wrong, or are these old v3 keys that are
not supported anymore?

-Patrick





From patrick at enigmail.net  Thu Oct 30 16:36:43 2014
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Thu, 30 Oct 2014 16:36:43 +0100
Subject: Lots of "packet(6) too short" errors with gpg 2.1
In-Reply-To: <545257B7.4080905@enigmail.net>
References: <545257B7.4080905@enigmail.net>
Message-ID: <54525B0B.8000202@enigmail.net>

On 30.10.14 16:22, Patrick Brunschwig wrote:
> After migration to gpg 2.1, I get lots of "packet(6) too short" when
> doing e.g. gpg --list-keys. Furthermore, gpg exits with exit code=2.
> 
> Is there anything I'm doing wrong, or are these old v3 keys that are
> not supported anymore?

Sorry to reply to myself. I exported all public and secret keys using
gpg 2.0, moved away my old .gnupg directory and re-imported all keys.
Now I don't have any error messages anymore.

Is there a recommended strategy to move from gpg2.0 to gpg2.1 key storage?

-Patrick



From hw42 at ipsumj.de  Thu Oct 30 16:16:40 2014
From: hw42 at ipsumj.de (HW42)
Date: Thu, 30 Oct 2014 16:16:40 +0100
Subject: [PATCH] doc: elaborate on --default-cache-ttl and --max-cache-ttl
In-Reply-To: <20141030144830.GB8638@gamayun>
References: <20141029130312.GN31696@gamayun>
 <877fzi29s1.fsf@vigenere.g10code.de>
 <20141029153402.GQ31696@gamayun>
 <8738a625s6.fsf@vigenere.g10code.de>
 <20141030133255.GA8638@gamayun>
 <87tx2ly6vs.fsf@vigenere.g10code.de>
 <20141030144830.GB8638@gamayun>
Message-ID: <20141030161640.388422d8@ipsumj.de>

Am Thu, 30 Oct 2014 12:48:30 -0200
schrieb Martin Ichilevici de Oliveira <iomartin at iomartin.net>:

> On Thu, Oct 30, 2014 at 03:22:31PM +0100, Werner Koch wrote:
> > On Thu, 30 Oct 2014 14:32, iomartin at iomartin.net said:
> > 
> > > I'm sorry (and I don't mean to be annoying), but I still don't
> > > understand why gnupg doesn't support infinite ttl? Is it by
> > > design or
> > 
> > What is the use case case for this?  I can't see one except to work
> > around a bogus security policy.  If you do not have a need for a
> > passphrase you should not use a passphrase for the protection of
> > your secret key.

One use case would be if you don't want to store it unencrypted on disk
- but in keep in in RAM is ok (this works of course only if you don't
 use hibernation or similar). 

> 
> I see what you mean.
> 
> Personally, I use gnupg mostly for signing email, and once in a while
> for encrypting it. I don't want to enter my passphrase every so often,
> but at the same time I didn't like the idea of using no passhprase at
> all.
> 
> Given that I usually reboot my computer around once a week, I found it
> to be a good compromise (in my case), to enter it once and then not
> worrying. I achieved that with a high ttl, but this just feels clumsy
> to me. Maybe that's what you'll call a bogus security policy - and you
> might be right - but it just seems cleaner to use -1 instead.
> 
> Cheers,
> Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: Digitale Signatur von OpenPGP
URL: </pipermail/attachments/20141030/9560beb7/attachment.sig>

From dkg at fifthhorseman.net  Thu Oct 30 19:20:46 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 30 Oct 2014 14:20:46 -0400
Subject: errant emacs backup files in beta895 build-aux/speedo
Message-ID: <87h9ylto5d.fsf@alice.fifthhorseman.net>

Hi Werner--

just a heads-up: the beta895 tarball appears to include three emacs
backup files:

 build-aux/speedo/w32/README.txt~
 build-aux/speedo/w32/inst.nsi~
 build-aux/speedo/w32/pkg-copyright.txt~

This isn't important, of course, but they're probably not something you
want shipped in general, so you might want to tune your release scripts
to avoid including them.

Regards,

   --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: </pipermail/attachments/20141030/24f8ab3c/attachment.sig>

From dkg at fifthhorseman.net  Thu Oct 30 19:42:32 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 30 Oct 2014 14:42:32 -0400
Subject: gnupg 2.1.0 beta 895 in debian experimental
Message-ID: <87egtptn53.fsf@alice.fifthhorseman.net>

hi folks--

GnuPG 2.1.0 beta 895 is now in debian experimental, for those who want
to play around with it without sorting out a proper build setup.

the package has only been tested on systems running jessie (testing) and
sid, so if you're running wheezy (stable) it's probably not for you just
yet.

You'll need to add the experimental repo to your sources.list first, so
installation might look something like:

 echo 'deb http://ftp.debian.org/debian experimental main' > /etc/apt/sources.list.d/experimental.list
 apt update
 apt install gnupg2/experimental

Please direct bug reports related to the debian packaging to the debian
BTS, since that will help us make the package much smoother for people
who aren't as interested in living on the edge.

Happy hacking,

     --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: </pipermail/attachments/20141030/6ea6a9cf/attachment.sig>

From wk at gnupg.org  Thu Oct 30 21:39:05 2014
From: wk at gnupg.org (Werner Koch)
Date: Thu, 30 Oct 2014 21:39:05 +0100
Subject: gnupg 2.1.0 beta 895 in debian experimental
In-Reply-To: <87egtptn53.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Thu, 30 Oct 2014 14:42:32 -0400")
References: <87egtptn53.fsf@alice.fifthhorseman.net>
Message-ID: <87h9ylxpg6.fsf@vigenere.g10code.de>

On Thu, 30 Oct 2014 19:42, dkg at fifthhorseman.net said:

> GnuPG 2.1.0 beta 895 is now in debian experimental, for those who want
> to play around with it without sorting out a proper build setup.

Cool.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From eric at debian.org  Thu Oct 30 22:41:19 2014
From: eric at debian.org (Eric Dorland)
Date: Thu, 30 Oct 2014 17:41:19 -0400
Subject: gnupg 2.1.0 beta 895 in debian experimental
In-Reply-To: <87egtptn53.fsf@alice.fifthhorseman.net>
References: <87egtptn53.fsf@alice.fifthhorseman.net>
Message-ID: <20141030214119.GB16744@gambit>

* Daniel Kahn Gillmor (dkg at fifthhorseman.net) wrote:
> hi folks--
> 
> GnuPG 2.1.0 beta 895 is now in debian experimental, for those who want
> to play around with it without sorting out a proper build setup.
> 
> the package has only been tested on systems running jessie (testing) and
> sid, so if you're running wheezy (stable) it's probably not for you just
> yet.
> 
> You'll need to add the experimental repo to your sources.list first, so
> installation might look something like:
> 
>  echo 'deb http://ftp.debian.org/debian experimental main' > /etc/apt/sources.list.d/experimental.list
>  apt update
>  apt install gnupg2/experimental
> 
> Please direct bug reports related to the debian packaging to the debian
> BTS, since that will help us make the package much smoother for people
> who aren't as interested in living on the edge.
> 
> Happy hacking,
> 
>      --dkg

I think you mean ++dkg. Thanks for making this happen.

-- 
Eric Dorland <eric at kuroneko.ca>
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: </pipermail/attachments/20141030/7634b8c6/attachment.sig>

From wk at gnupg.org  Fri Oct 31 08:11:03 2014
From: wk at gnupg.org (Werner Koch)
Date: Fri, 31 Oct 2014 08:11:03 +0100
Subject: errant emacs backup files in beta895 build-aux/speedo
In-Reply-To: <87h9ylto5d.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Thu, 30 Oct 2014 14:20:46 -0400")
References: <87h9ylto5d.fsf@alice.fifthhorseman.net>
Message-ID: <87a94cyarc.fsf@vigenere.g10code.de>

On Thu, 30 Oct 2014 19:20, dkg at fifthhorseman.net said:

> just a heads-up: the beta895 tarball appears to include three emacs
> backup files:

My fault: I listed directories in EXTRA_DIST and automake uses cp -R for
each item listed there.  Fixed.

Thanks,

 Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From wk at gnupg.org  Fri Oct 31 10:39:36 2014
From: wk at gnupg.org (Werner Koch)
Date: Fri, 31 Oct 2014 10:39:36 +0100
Subject: Lots of "packet(6) too short" errors with gpg 2.1
In-Reply-To: <545257B7.4080905@enigmail.net> (Patrick Brunschwig's message of
 "Thu, 30 Oct 2014 16:22:31 +0100")
References: <545257B7.4080905@enigmail.net>
Message-ID: <87zjccwpbb.fsf@vigenere.g10code.de>

On Thu, 30 Oct 2014 16:22, patrick at enigmail.net said:
> After migration to gpg 2.1, I get lots of "packet(6) too short" when
> doing e.g. gpg --list-keys. Furthermore, gpg exits with exit code=2.

Found and fixed: The --keydb-rebuild-caches function which is also used
internally before checking the trustdb, caused the trouble.  It parsed
the key and wrote it back.  Now v3 keys are not anymore supported and
thus a garbled package was written.  The parsing is required to check
actually check the key signatures and write cache packets.  My solution
is to drop v3 keys from the keyring while rebuilding the caches.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.