From robby at rlworkman.net  Fri Jan  2 09:16:01 2015
From: robby at rlworkman.net (Robby Workman)
Date: Fri, 2 Jan 2015 02:16:01 -0600
Subject: gnupg-2.1.x, GPG_AGENT_INFO, claws-mail
Message-ID: <20150102021601.77799299.robby@rlworkman.net>

Since gnupg-2.1.x no longer pays attention to (or even sets) the
GPG_AGENT_INFO variable in the environment, there's a bit of a
problem in claws-mail's usage of the gpg-agent.  Claws allows the
user to let gpg-agent handle passphrases for e.g. mail signing,
encryption, etcetera, or else it will handle it internally.

The check for whether to offer gpg-agent use in its preferences
is wrapped in a check for GPG_AGENT_INFO in the environment, i.e.
if it's unset, then there's not even an option to allow use of 
gpg-agent. At runtime, even if the preference is set to use the
gpg-agent, if GPG_AGENT_INFO is not set, then it will automatically
fall back to the internal handling.

I'm guessing that claws (is not|will not) be the only application
broken in this or a similar fashion, so...

1. How feasible would it be to restore the setting of GPG_AGENT_INFO
   in the environment by gnupg-2.1.x? In other words, populate it on
   startup as in the past to provide a seamless transition for users?

2. Assuming #1 is nixed, what would the suggested way of dealing with
   this be? Keep in mind that both the "old" gnupg and gnupg-2.1.x
   implementations have to be supported - is there a good way of 
   querying this at runtime using some gnupg API?

-RW


From nicholas.cole at gmail.com  Fri Jan  2 10:50:44 2015
From: nicholas.cole at gmail.com (Nicholas Cole)
Date: Fri, 2 Jan 2015 09:50:44 +0000
Subject: gnupg-2.1.x, GPG_AGENT_INFO, claws-mail
In-Reply-To: <20150102021601.77799299.robby@rlworkman.net>
References: <20150102021601.77799299.robby@rlworkman.net>
Message-ID: <CAAu18hcDF7aDYiYdRkkdP0_xvPgnfKUjQEomp6h2KXkZM+Y_Sw@mail.gmail.com>

On Friday, 2 January 2015, Robby Workman <robby at rlworkman.net> wrote:
>
>
> 2. Assuming #1 is nixed, what would the suggested way of dealing with
>    this be? Keep in mind that both the "old" gnupg and gnupg-2.1.x
>    implementations have to be supported - is there a good way of
>    querying this at runtime using some gnupg API?
>
> -RW
>

Checking the version number would do what you want, wouldn't it?

N
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150102/9197364b/attachment.html>

From wk at gnupg.org  Fri Jan  2 13:59:59 2015
From: wk at gnupg.org (Werner Koch)
Date: Fri, 02 Jan 2015 13:59:59 +0100
Subject: gnupg-2.1.x, GPG_AGENT_INFO, claws-mail
In-Reply-To: <20150102021601.77799299.robby@rlworkman.net> (Robby Workman's
 message of "Fri, 2 Jan 2015 02:16:01 -0600")
References: <20150102021601.77799299.robby@rlworkman.net>
Message-ID: <87zja1e3sg.fsf@vigenere.g10code.de>

On Fri,  2 Jan 2015 09:16, robby at rlworkman.net said:

> problem in claws-mail's usage of the gpg-agent.  Claws allows the
> user to let gpg-agent handle passphrases for e.g. mail signing,
> encryption, etcetera, or else it will handle it internally.

Claws uses GPGME and with decent GPGME versions GnuPG 2.x is preferred
if it is installed and thus gpg-agent is used anyway.  Messing around
with GPG_AGENT_INFO is not a good idea at all.

There is another current mail thread on Enigmail which should be used
to discuss the passphrase issue.

I wrote the initial support for GnuPG in Claws/Sylpheed and later helped
to fix things for the Windows port.  In fact we distribute a Claws
version for Windows for many years and there was no problem with it.

The tentative plan now is to have a separate Windows installer for the
GnuPG core which can be checked/installed by any GnuPG frontend and make
use of it.  The frontends should thus make sure that they work with 2.1.
This is a task for all frontends on all platforms and we need to work
out a few details.

> 1. How feasible would it be to restore the setting of GPG_AGENT_INFO
>    in the environment by gnupg-2.1.x? In other words, populate it on
>    startup as in the past to provide a seamless transition for users?

No - it has gone for a reason.

> 2. Assuming #1 is nixed, what would the suggested way of dealing with
>    this be? Keep in mind that both the "old" gnupg and gnupg-2.1.x
>    implementations have to be supported - is there a good way of 
>    querying this at runtime using some gnupg API?

Why do you want to support old versions?  This only leads to complex and
insecure code.  Please go with the stable version (2.0) and be prepared
for the next one.

Please do not use 1.4 with interactive applications. If it is about
decryption ancient PGP-2 mails, a simple filter plugin should be
sufficient and it can also rely on gpg-agent's Pinentry.  Don't do it in
your application - but see the discussion on Enigmail.



Shalom-Salam,

   Werner

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



From wk at gnupg.org  Fri Jan  2 14:05:10 2015
From: wk at gnupg.org (Werner Koch)
Date: Fri, 02 Jan 2015 14:05:10 +0100
Subject: --secret-keyring alternative for gpg 2.1
In-Reply-To: <20141229133656.GA31455@localhost> (Guilhem Moulin's message of
 "Mon, 29 Dec 2014 14:36:56 +0100")
References: <20141229133656.GA31455@localhost>
Message-ID: <87vbkpe3jt.fsf@vigenere.g10code.de>

On Mon, 29 Dec 2014 14:36, guilhem at fripost.org said:

> AFAICT the only fix is to symlink ~/.caff/gnupghome/private-keys-v1.d
> to ${GNUPGHOME:-~/.gnupg}/private-keys-v1.d .  It'd be better if
> --secret-keyring (or a new option) could be used to specify the
> directory in which secret keys are stored, e.g.,

That can't be done for gpg because gpg does not know anything about the
secret keys.  It would be possible to make private-keys-v1.d
configurable in gpg-agent.conf but I doubt that it is worth the trouble.
The symlink approach works quite well and options to distribute the
secret keys over several directories adds more trouble than it would
solve.

BTW, what about changing caff to make use of the new system?  If there
is a need for an export option to include only one subkey and a
signature it should be easy to get that into 2.1.


Salam-Shalom,

   Werner

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



From wk at gnupg.org  Fri Jan  2 14:18:17 2015
From: wk at gnupg.org (Werner Koch)
Date: Fri, 02 Jan 2015 14:18:17 +0100
Subject: gpg-agent and allow-loopback-pinentry
In-Reply-To: <54A3284E.6070300@fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Tue, 30 Dec 2014 17:33:50 -0500")
References: <549D5623.5040602@enigmail.net> <549F9C55.6010508@fsij.org>
 <54A02A8C.4060801@enigmail.net> <87bnmmn5j3.fsf@vigenere.g10code.de>
 <54A1696C.4080502@enigmail.net> <54A3284E.6070300@fifthhorseman.net>
Message-ID: <87r3vde2xy.fsf@vigenere.g10code.de>

On Tue, 30 Dec 2014 23:33, dkg at fifthhorseman.net said:

> to be honest, when i've watched users set up enigmail with GnuPG for the
> first time, they're often confused by the fact of a password for the key
> in the first place.

Right, I bet that 80% of all users do not fully understand for what the
passphrase is used.  It is even questionable whether a passphrase
protected key is useful for a non-mobile computer given that attacker
able to grab a protected key will in most cases also be able to
install a keylogger.

> And an OpenPGP key by default is not the same thing as a web service,
> either.

Right - Documentation should stree that point.

> What about generating the key with no passphrase initially, and
> presenting a big "protect this key with a passphrase" button to the user
> when no passphrase is set?

Given the above scenario I actually kind of like that.

>  * passphraseless keys will be written to the filesystem and might not
> ever be erased.
>
>  * some users will never click the "protect this key with a passphrase"
> button.

As an alternative we could keep the key in memory (gpg-agent is running
in the background) and only write it to the disk once a change
passphrase has been done.  We would also not allow to send the key to a
keyserver before it has not been passphrase protected.

Instead of "please protect your key now" we could use a "you now need to
test your key" and in course of that setup a passphrase.  Creating a
signed message and decrypt an automagically created message would also
help to remember the passphrase.

>  * it's not clear to me whether there's an easy way for enigmail to tell
> whether the secret key in question has a passphrase set on it or not

gpg-agent has this command:

  > help keyinfo
  # KEYINFO [--[ssh-]list] [--data] [--ssh-fpr] [--with-ssh] <keygrip>

  #   KEYINFO <keygrip> <type> <serialno> <idstr> <cached> <protection> <fpr>

  # PROTECTION describes the key protection type:
  #     'P' - The key is protected with a passphrase,
  #     'C' - The key is not protected,
  #     '-' - Unknown protection.

Enigmail can use it via gpg-connect-agent to check for a key or we can
add a wrapper command to gpg.  If a keep-in-memory-until-passwd approach
would be implemented this command can also be used to return relevant
info.

> I don't know if there are any usability studies that would help make
> this decision easier.

Anyone who has time to research this?


Shalom-Salam,

   Werner

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



From patrick at enigmail.net  Fri Jan  2 15:13:31 2015
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Fri, 02 Jan 2015 15:13:31 +0100
Subject: gpg-agent and allow-loopback-pinentry
In-Reply-To: <87r3vde2xy.fsf@vigenere.g10code.de>
References: <549D5623.5040602@enigmail.net>
 <549F9C55.6010508@fsij.org>	<54A02A8C.4060801@enigmail.net>
 <87bnmmn5j3.fsf@vigenere.g10code.de>	<54A1696C.4080502@enigmail.net>
 <54A3284E.6070300@fifthhorseman.net> <87r3vde2xy.fsf@vigenere.g10code.de>
Message-ID: <54A6A78B.6050909@enigmail.net>

On 02.01.15 14:18, Werner Koch wrote:
> On Tue, 30 Dec 2014 23:33, dkg at fifthhorseman.net said:
> 
>> to be honest, when i've watched users set up enigmail with GnuPG for the
>> first time, they're often confused by the fact of a password for the key
>> in the first place.
> 
> Right, I bet that 80% of all users do not fully understand for what the
> passphrase is used.  It is even questionable whether a passphrase
> protected key is useful for a non-mobile computer given that attacker
> able to grab a protected key will in most cases also be able to
> install a keylogger.
> 
>> And an OpenPGP key by default is not the same thing as a web service,
>> either.
> 
> Right - Documentation should stree that point.
> 
>> What about generating the key with no passphrase initially, and
>> presenting a big "protect this key with a passphrase" button to the user
>> when no passphrase is set?
> 
> Given the above scenario I actually kind of like that.
> 
>>  * passphraseless keys will be written to the filesystem and might not
>> ever be erased.
>>
>>  * some users will never click the "protect this key with a passphrase"
>> button.
> 
> As an alternative we could keep the key in memory (gpg-agent is running
> in the background) and only write it to the disk once a change
> passphrase has been done.  We would also not allow to send the key to a
> keyserver before it has not been passphrase protected.
> 
> Instead of "please protect your key now" we could use a "you now need to
> test your key" and in course of that setup a passphrase.  Creating a
> signed message and decrypt an automagically created message would also
> help to remember the passphrase.
> 
>>  * it's not clear to me whether there's an easy way for enigmail to tell
>> whether the secret key in question has a passphrase set on it or not
> 
> gpg-agent has this command:
> 
>   > help keyinfo
>   # KEYINFO [--[ssh-]list] [--data] [--ssh-fpr] [--with-ssh] <keygrip>
> 
>   #   KEYINFO <keygrip> <type> <serialno> <idstr> <cached> <protection> <fpr>
> 
>   # PROTECTION describes the key protection type:
>   #     'P' - The key is protected with a passphrase,
>   #     'C' - The key is not protected,
>   #     '-' - Unknown protection.
> 
> Enigmail can use it via gpg-connect-agent to check for a key or we can
> add a wrapper command to gpg.  If a keep-in-memory-until-passwd approach
> would be implemented this command can also be used to return relevant
> info.
> 
>> I don't know if there are any usability studies that would help make
>> this decision easier.
> 
> Anyone who has time to research this?

We recently had a usability study on Enigmail done by a German
University (I'm not sure if I'm allowed to publish the name, so I
don't). Enigmail has a setup wizard (which generates a key if needed),
and recommendation was to design the key creation dialog as follows:

----------------------------------------
*Key Creation*

Your _public key_ is used by others to send you encrypted messages. You
can be distribute it to anyone."

Your _private key_ is required for you to decrypt received mails and to
send signed mails. You should not give it to anyone. To secure your
private key, please enter a passphrase below.

*Important:* your passphrase is not your private key.

Passphrase        : [         ]
Confirm passphrase: [         ]

Password Quality:   [color bar]
----------------------------------------

I am right now modifying our wizard to look and work exactly this way.

-Patrick


From wk at gnupg.org  Fri Jan  2 16:02:02 2015
From: wk at gnupg.org (Werner Koch)
Date: Fri, 02 Jan 2015 16:02:02 +0100
Subject: gpg-agent and allow-loopback-pinentry
In-Reply-To: <54A6A78B.6050909@enigmail.net> (Patrick Brunschwig's message of
 "Fri, 02 Jan 2015 15:13:31 +0100")
References: <549D5623.5040602@enigmail.net> <549F9C55.6010508@fsij.org>
 <54A02A8C.4060801@enigmail.net> <87bnmmn5j3.fsf@vigenere.g10code.de>
 <54A1696C.4080502@enigmail.net> <54A3284E.6070300@fifthhorseman.net>
 <87r3vde2xy.fsf@vigenere.g10code.de> <54A6A78B.6050909@enigmail.net>
Message-ID: <87r3vdcjkl.fsf@vigenere.g10code.de>

On Fri,  2 Jan 2015 15:13, patrick at enigmail.net said:

> and recommendation was to design the key creation dialog as follows:
>
> ----------------------------------------
> *Key Creation*
>
> Your _public key_ is used by others to send you encrypted messages. You
> can be distribute it to anyone."
>
> Your _private key_ is required for you to decrypt received mails and to
> send signed mails. You should not give it to anyone. To secure your
> private key, please enter a passphrase below.
>
> *Important:* your passphrase is not your private key.
>
> Passphrase        : [         ]
> Confirm passphrase: [         ]
>
> Password Quality:   [color bar]
> ----------------------------------------

I am not a UX expert but with my facebook-user-hat on I see a lot of
text which describes something but does not explain what the passphrase
is.  "is not your private key" - well, what is it then?

The prominent passphrase entry with quality bar and a bold "important"
flag creates the impression that the passphrase is really important for
security.

There is also no exercise to make sure the passphrase is remembered
after a few minutes.  Many people rely on the "forget password? - enter
email" recovery process known from almost all websites.  The idea with
the old Pinentry to enter the passphrase several times during creation
was actually to have such a minimal exercise - however, it failed.  The
user does not known why it was done this way and annoyed.


Shalom-Salam,

   Werner

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



From patrick at enigmail.net  Fri Jan  2 18:01:37 2015
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Fri, 02 Jan 2015 18:01:37 +0100
Subject: gpg-agent and allow-loopback-pinentry
In-Reply-To: <87r3vdcjkl.fsf@vigenere.g10code.de>
References: <549D5623.5040602@enigmail.net>
 <549F9C55.6010508@fsij.org>	<54A02A8C.4060801@enigmail.net>
 <87bnmmn5j3.fsf@vigenere.g10code.de>	<54A1696C.4080502@enigmail.net>
 <54A3284E.6070300@fifthhorseman.net>	<87r3vde2xy.fsf@vigenere.g10code.de>
 <54A6A78B.6050909@enigmail.net> <87r3vdcjkl.fsf@vigenere.g10code.de>
Message-ID: <54A6CEF1.2050002@enigmail.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02.01.15 16:02, Werner Koch wrote:
> On Fri,  2 Jan 2015 15:13, patrick at enigmail.net said:
> 
>> and recommendation was to design the key creation dialog as
>> follows:
>> 
>> ---------------------------------------- *Key Creation*
>> 
>> Your _public key_ is used by others to send you encrypted
>> messages. You can be distribute it to anyone."
>> 
>> Your _private key_ is required for you to decrypt received mails
>> and to send signed mails. You should not give it to anyone. To
>> secure your private key, please enter a passphrase below.
>> 
>> *Important:* your passphrase is not your private key.
>> 
>> Passphrase        : [         ] Confirm passphrase: [         ]
>> 
>> Password Quality:   [color bar] 
>> ----------------------------------------
> 
> I am not a UX expert but with my facebook-user-hat on I see a lot
> of text which describes something but does not explain what the
> passphrase is.  "is not your private key" - well, what is it then?

Yes, I'm aware of this flaws, especially as the authors also suggest
to reduce the amount of text. The design suggests to add symbolic
question marks after the explanation which should display a help
dialog. I'm not yet sure how I should resolve this contradiction.

> The prominent passphrase entry with quality bar and a bold
> "important" flag creates the impression that the passphrase is
> really important for security.

I prefer the term "note" instead, and probably not in bold either.

> There is also no exercise to make sure the passphrase is
> remembered after a few minutes.  Many people rely on the "forget
> password? - enter email" recovery process known from almost all
> websites.  The idea with the old Pinentry to enter the passphrase
> several times during creation was actually to have such a minimal
> exercise - however, it failed.  The user does not known why it was
> done this way and annoyed.

I see. Unfortunately I haven't seen anything other than pinentry-mac
(which is based on pinentry 0.8.1) in the last years ...

- -Patrick

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJUps7vAAoJEMk25cDiHiw+qh8H/jSFImR5xtausFkhMnnOn5zQ
5J9VsKew606KBdX12mL4vLQYAthpGT8+YuIibkYYJ2a50ZFHKAf/N/KKZyas4/c/
Ds2o+Ksh9pSFvQdmcjsxDUcwSu8LXeT6wEtl4S2VGbyki3feAqZzw/lq4v06Q7fM
9bysP2xmF0OjkD7HF/TtgVwqyB7CW3dReY+5N40OzHJ+zIETj2A+frgaNuTUOsII
6J7QVKdhiv54pPBS0puJ479LqXDBD6id1O8k1ABU601uOVMd3e+uyaXiT2ltWCxg
g2fVIn3fO389jW1vnOktk49vcjhtahK3DZOaEv1PJTGOrAYYtQODtVXOh8m2XqM=
=uVXT
-----END PGP SIGNATURE-----


From patrick at enigmail.net  Sat Jan  3 13:10:53 2015
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Sat, 03 Jan 2015 13:10:53 +0100
Subject: pinentry-qt and QT5
Message-ID: <54A7DC4D.1090809@enigmail.net>

I'm trying to build pinentry-qt on OS X to find out if it could serve
as a replacement for pinentry-mac. Is my understanding correct that QT
5.x is not (yet) supported?

I'm asking because it seems that the Qt5 distribution for OS X seems
to be a lot easier to use than the one for Qt4 (e.g. the Qt4 distro
does not provide pkg-config files).

Thanks,
Patrick


From dave.pawson at gmail.com  Mon Jan  5 09:16:54 2015
From: dave.pawson at gmail.com (Dave Pawson)
Date: Mon, 5 Jan 2015 08:16:54 +0000
Subject: build error
Message-ID: <CAEncD4dYX9c8jOHmgVL6=YE0-iQeUrca04_2P5mnPa4n3+iLJw@mail.gmail.com>

running build as per https://www.gnupg.org/download/cvs_access.html

$ ./autogen.sh

....

*** Activating commit log message check hook. ***
?build-aux/git-hooks/commit-msg? -> ?.git/hooks/commit-msg?
autogen.sh: Running aclocal -I m4 ...
autogen.sh: Running autoheader...
autogen.sh: Running automake --gnu ...
parallel-tests: error: required file 'build-aux/test-driver' not found
parallel-tests:   'automake --add-missing' can install 'test-driver'
autogen.sh: Running autoconf ...
autogen.sh: You may now run:
  ./configure --sysconfdir=/etc --enable-maintainer-mode  && make

Note the 'required file error? Is it an error or warning?
Essential or optional?

regards


-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk


From dave.pawson at gmail.com  Mon Jan  5 09:00:57 2015
From: dave.pawson at gmail.com (Dave Pawson)
Date: Mon, 5 Jan 2015 08:00:57 +0000
Subject: docs bug
Message-ID: <CAEncD4e+mfrxW62vVqXym-Vf1OeGU3tc8LUGAQVD9gYTwezmqQ@mail.gmail.com>

https://www.gnupg.org/download/cvs_access.html

says

You must run scripts/autogen.sh before doing the./configure
--enable-maintainer-mode,

The autogen.sh script is in the root directory of the
cloned git repo, not in a 'scripts' directory.

regards

-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk


From dave.pawson at gmail.com  Mon Jan  5 09:11:26 2015
From: dave.pawson at gmail.com (Dave Pawson)
Date: Mon, 5 Jan 2015 08:11:26 +0000
Subject: docs
Message-ID: <CAEncD4cukEM_D_RroDe+E-GpP_ZxisEL5vXqHS=-heD2ciVMaQ@mail.gmail.com>

https://www.gnupg.org/download/cvs_access.html
says

You must run scripts/autogen.sh before doing the./configure
--enable-maintainer-mode

script autgen.rc differs from this, having
final_info="./configure --sysconfdir=/etc --enable-maintainer-mode  && make"

No mention in the docs what the --sysconfdir is used for or what
impact this option has on build.

regards



-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk


From aheinecke at intevation.de  Mon Jan  5 10:24:31 2015
From: aheinecke at intevation.de (Andre Heinecke)
Date: Mon, 05 Jan 2015 10:24:31 +0100
Subject: pinentry-qt and QT5
In-Reply-To: <54A7DC4D.1090809@enigmail.net>
References: <54A7DC4D.1090809@enigmail.net>
Message-ID: <5042257.NXFxccn4oC@esus>

Hi,

On Saturday, January 03, 2015 01:10:53 PM Patrick Brunschwig wrote:
> I'm trying to build pinentry-qt on OS X to find out if it could serve
> as a replacement for pinentry-mac. Is my understanding correct that QT
> 5.x is not (yet) supported?

Yes, it's currently not yet supported. I doubt that there will be big issues 
but so far the buildsystem / configure checks are only tailored for qt3 / qt4.

> 
> I'm asking because it seems that the Qt5 distribution for OS X seems
> to be a lot easier to use than the one for Qt4 (e.g. the Qt4 distro
> does not provide pkg-config files).

You should be able to manually configure QT4  by setting the QT4 ... 
environment variables mentioned at the end of ./configure --help
qt4-moc should be preferred automatically. Otherwise you can overwrite this 
with the environment variable MOC.

Regards,
Andre

-- 
Andre Heinecke |  ++49-541-335083-262  |  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


From git at internot.info  Mon Jan  5 10:37:30 2015
From: git at internot.info (Joshua Rogers)
Date: Mon, 05 Jan 2015 20:37:30 +1100
Subject: build error
In-Reply-To: <CAEncD4dYX9c8jOHmgVL6=YE0-iQeUrca04_2P5mnPa4n3+iLJw@mail.gmail.com>
References: <CAEncD4dYX9c8jOHmgVL6=YE0-iQeUrca04_2P5mnPa4n3+iLJw@mail.gmail.com>
Message-ID: <54AA5B5A.5070703@internot.info>

On 05/01/15 19:16, Dave Pawson wrote:
> parallel-tests: error: required file 'build-aux/test-driver' not found
> parallel-tests:   'automake --add-missing' can install 'test-driver'
If I remember correctly, that's from an incorrect version of automake.
I got the same error, but corrected it using `apt-get build-dep
gnupg-dev', or whatever the package name is.


-- 
-- Joshua Rogers <https://internot.info/>

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

From dave.pawson at gmail.com  Mon Jan  5 10:53:45 2015
From: dave.pawson at gmail.com (Dave Pawson)
Date: Mon, 5 Jan 2015 09:53:45 +0000
Subject: build error
In-Reply-To: <54AA5B5A.5070703@internot.info>
References: <CAEncD4dYX9c8jOHmgVL6=YE0-iQeUrca04_2P5mnPa4n3+iLJw@mail.gmail.com>
 <54AA5B5A.5070703@internot.info>
Message-ID: <CAEncD4f8R_EncJy9tzV4ASMt99nbKEwVbFs=dKQS6-fFi4y_MA@mail.gmail.com>

On 5 January 2015 at 09:37, Joshua Rogers <git at internot.info> wrote:
> On 05/01/15 19:16, Dave Pawson wrote:
>> parallel-tests: error: required file 'build-aux/test-driver' not found
>> parallel-tests:   'automake --add-missing' can install 'test-driver'
> If I remember correctly, that's from an incorrect version of automake.
> I got the same error, but corrected it using `apt-get build-dep
> gnupg-dev', or whatever the package name is.

 automake --version
automake (GNU automake) 1.14.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later
<http://gnu.org/licenses/gpl-2.0.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Tom Tromey <tromey at redhat.com>
       and Alexandre Duret-Lutz <adl at gnu.org>.


I installed it when prompted an hour ago, from Fedora repos.

Is an older version required or is Fedora out of step please?

regards



-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk


From git at internot.info  Mon Jan  5 10:58:38 2015
From: git at internot.info (Joshua Rogers)
Date: Mon, 05 Jan 2015 20:58:38 +1100
Subject: build error
In-Reply-To: <CAEncD4f8R_EncJy9tzV4ASMt99nbKEwVbFs=dKQS6-fFi4y_MA@mail.gmail.com>
References: <CAEncD4dYX9c8jOHmgVL6=YE0-iQeUrca04_2P5mnPa4n3+iLJw@mail.gmail.com>	<54AA5B5A.5070703@internot.info>
 <CAEncD4f8R_EncJy9tzV4ASMt99nbKEwVbFs=dKQS6-fFi4y_MA@mail.gmail.com>
Message-ID: <54AA604E.1070602@internot.info>

On 05/01/15 20:53, Dave Pawson wrote:
> On 5 January 2015 at 09:37, Joshua Rogers <git at internot.info> wrote:
>> > On 05/01/15 19:16, Dave Pawson wrote:
>>> >> parallel-tests: error: required file 'build-aux/test-driver' not found
>>> >> parallel-tests:   'automake --add-missing' can install 'test-driver'
>> > If I remember correctly, that's from an incorrect version of automake.
>> > I got the same error, but corrected it using `apt-get build-dep
>> > gnupg-dev', or whatever the package name is.
>  automake --version
> automake (GNU automake) 1.14.1
I just checked, and I was wrong. I think that problem was for
libgpg-error or something.


I'm getting it too:


# ./autogen.sh

autogen.sh: Running aclocal -I m4 ...
autogen.sh: Running autoheader...
autogen.sh: Running automake --gnu ...
parallel-tests: error: required file 'build-aux/test-driver' not found
parallel-tests:   'automake --add-missing' can install 'test-driver'
autogen.sh: Running autoconf ...
autogen.sh: You may now run:
  ./configure --sysconfdir=/etc --enable-maintainer-mode  && make


It doesn't affect building, though.


Thanks,
-- 
-- Joshua Rogers <https://internot.info/>

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

From wk at gnupg.org  Mon Jan  5 12:36:12 2015
From: wk at gnupg.org (Werner Koch)
Date: Mon, 05 Jan 2015 12:36:12 +0100
Subject: build error
In-Reply-To: <54AA5B5A.5070703@internot.info> (Joshua Rogers's message of
 "Mon, 05 Jan 2015 20:37:30 +1100")
References: <CAEncD4dYX9c8jOHmgVL6=YE0-iQeUrca04_2P5mnPa4n3+iLJw@mail.gmail.com>
 <54AA5B5A.5070703@internot.info>
Message-ID: <878uhh793n.fsf@vigenere.g10code.de>

On Mon,  5 Jan 2015 10:37, git at internot.info said:

> If I remember correctly, that's from an incorrect version of automake.

Right.  Due to backward incompatibilities automake >= 1.13 is not
supported.  The idea was to switch to 1.14 after the release of Debian
Jessie.  However, for other reasons I had to update my laptop to Jessie
anyway (with the drawback that suspend to disk does not work anymore and
wpasupplicant is oscillating) and thus I plan to switch to 1.14 really
soon now.


Salam-Shalom,

   Werner

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



From dave.pawson at gmail.com  Mon Jan  5 13:50:41 2015
From: dave.pawson at gmail.com (Dave Pawson)
Date: Mon, 5 Jan 2015 12:50:41 +0000
Subject: build error
In-Reply-To: <878uhh793n.fsf@vigenere.g10code.de>
References: <CAEncD4dYX9c8jOHmgVL6=YE0-iQeUrca04_2P5mnPa4n3+iLJw@mail.gmail.com>
 <54AA5B5A.5070703@internot.info>
 <878uhh793n.fsf@vigenere.g10code.de>
Message-ID: <CAEncD4frBDLMS0=Abicb+aYVvXu2sDWSff-t4XSwan8YrY1GSQ@mail.gmail.com>

Thanks Werner.

regards

On 5 January 2015 at 11:36, Werner Koch <wk at gnupg.org> wrote:
> On Mon,  5 Jan 2015 10:37, git at internot.info said:
>
>> If I remember correctly, that's from an incorrect version of automake.
>
> Right.  Due to backward incompatibilities automake >= 1.13 is not
> supported.  The idea was to switch to 1.14 after the release of Debian
> Jessie.  However, for other reasons I had to update my laptop to Jessie
> anyway (with the drawback that suspend to disk does not work anymore and
> wpasupplicant is oscillating) and thus I plan to switch to 1.14 really
> soon now.
>
>
> Salam-Shalom,
>
>    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



-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk


From dave.pawson at gmail.com  Tue Jan  6 11:08:04 2015
From: dave.pawson at gmail.com (Dave Pawson)
Date: Tue, 6 Jan 2015 10:08:04 +0000
Subject: lone option? Docs issue
Message-ID: <CAEncD4dk-tQ3PBm-_=+66ms7Nn9y8rf4N3d7ebd7Db0a920Uzg@mail.gmail.com>

https://www.gnupg.org/documentation/manuals/gnupg/Operational-GPG-Commands.html#Operational-GPG-Commands

the --list-sigs option has a statement

" "X" for an eXpired signature (see --ask-cert-expire),"

I can find no documentation for '--ask-certo-expire'
Is this an omission or error?

regards

-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk


From dkg at fifthhorseman.net  Tue Jan  6 12:24:06 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 06 Jan 2015 06:24:06 -0500
Subject: lone option? Docs issue
In-Reply-To: <CAEncD4dk-tQ3PBm-_=+66ms7Nn9y8rf4N3d7ebd7Db0a920Uzg@mail.gmail.com>
References: <CAEncD4dk-tQ3PBm-_=+66ms7Nn9y8rf4N3d7ebd7Db0a920Uzg@mail.gmail.com>
Message-ID: <54ABC5D6.5070105@fifthhorseman.net>

On 01/06/2015 05:08 AM, Dave Pawson wrote:
> https://www.gnupg.org/documentation/manuals/gnupg/Operational-GPG-Commands.html#Operational-GPG-Commands
> 
> the --list-sigs option has a statement
> 
> " "X" for an eXpired signature (see --ask-cert-expire),"
> 
> I can find no documentation for '--ask-certo-expire'
> Is this an omission or error?

if you're looking for --ask-certo-expire, then you won't find it :)

but if that's just a typo in the e-mail and you're actually looking for
--ask-cert-expire, you can find it in the gpg(1) manpage:


  --ask-cert-expire
  --no-ask-cert-expire

    When  making  a key signature, prompt for an expiration time. If
    this option is  not  specified,  the  expiration  time  set  via
    --default-cert-expire  is  used.  --no-ask-cert-expire  disables
    this option.


hth,

	--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/20150106/69912899/attachment.sig>

From dave.pawson at gmail.com  Tue Jan  6 12:38:10 2015
From: dave.pawson at gmail.com (Dave Pawson)
Date: Tue, 6 Jan 2015 11:38:10 +0000
Subject: lone option? Docs issue
In-Reply-To: <54ABC5D6.5070105@fifthhorseman.net>
References: <CAEncD4dk-tQ3PBm-_=+66ms7Nn9y8rf4N3d7ebd7Db0a920Uzg@mail.gmail.com>
 <54ABC5D6.5070105@fifthhorseman.net>
Message-ID: <CAEncD4czKHJhUff+FSWGrqwyJ3oWgaKCzn48Wp5LTKGDcjGt_w@mail.gmail.com>

Thanks (sorry for the typo). I was expecting it to link
to the option (same or alternate document) rather than
having to use a man page?

regards



On 6 January 2015 at 11:24, Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
> On 01/06/2015 05:08 AM, Dave Pawson wrote:
>> https://www.gnupg.org/documentation/manuals/gnupg/Operational-GPG-Commands.html#Operational-GPG-Commands
>>
>> the --list-sigs option has a statement
>>
>> " "X" for an eXpired signature (see --ask-cert-expire),"
>>
>> I can find no documentation for '--ask-certo-expire'
>> Is this an omission or error?
>
> if you're looking for --ask-certo-expire, then you won't find it :)
>
> but if that's just a typo in the e-mail and you're actually looking for
> --ask-cert-expire, you can find it in the gpg(1) manpage:
>
>
>   --ask-cert-expire
>   --no-ask-cert-expire
>
>     When  making  a key signature, prompt for an expiration time. If
>     this option is  not  specified,  the  expiration  time  set  via
>     --default-cert-expire  is  used.  --no-ask-cert-expire  disables
>     this option.
>
>
> hth,
>
>         --dkg
>



-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk


From gniibe at fsij.org  Wed Jan  7 00:36:46 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 07 Jan 2015 08:36:46 +0900
Subject: Questionable / Incorrect Code
In-Reply-To: <549BC26A.7020004@fsij.org>
References: <549AC27C.6050607@internot.info>
 <87oaqsq06d.fsf@vigenere.g10code.de> <549B6364.2010507@internot.info>
 <549BC26A.7020004@fsij.org>
Message-ID: <54AC718E.3050001@fsij.org>

On 12/25/2014 04:53 PM, NIIBE Yutaka wrote:
> I had pinpad related enhancement branch and Marcus had npth
> related branch.  I think that I pushed first, and Marcus had to merge,
> and introduced this bug unfortunately.

It's pushed, as it's obvious fix and double-checked by me of 2014 and
me of 2015.

It is same entity, you'd say.  I wish I am different in 2015 somehow,
_and_ I will be as same.

Sounds Zen-ish?  Well, it's in our daily life.

Here, we will have Dhama Doll Market this week [0].  You can see the
dolls of the founder of the Zen in the picture.

[0] http://www.maebashi-cvb.com/english/events/06.htm


commit 602f17b5a775f02e0e33a54d3155929dc00e4f53
Author: NIIBE Yutaka <gniibe at fsij.org>
Date:   Wed Jan 7 08:15:12 2015 +0900

    scd: fix merge failure.

    * scd/apdu.c (pcsc_pinpad_verify): Remove wrong lines inserted by
    merge.

    --

    Thanks to Joshua Rogers for reviewing and reporting.

diff --git a/scd/apdu.c b/scd/apdu.c
index 476723a..4ec6b4d 100644
--- a/scd/apdu.c
+++ b/scd/apdu.c
@@ -2336,8 +2336,6 @@ pcsc_pinpad_verify (int slot, int class, int ins, int p0, int p1,
                      pin_verify, len, result, &resultlen);
   xfree (pin_verify);
   if (sw || resultlen < 2)
-    return sw? sw : SW_HOST_INCOMPLETE_CARD_RESPONSE;
-  sw = (result[resultlen-2] << 8) | result[resultlen-1];
     {
       log_error ("control_pcsc failed: %d\n", sw);
       return sw? sw: SW_HOST_INCOMPLETE_CARD_RESPONSE;
--


From gniibe at fsij.org  Wed Jan  7 01:20:41 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 07 Jan 2015 09:20:41 +0900
Subject: Bug#773474: [PATCH] * scd/app-openpgp.c: (get_public_key) correctly
 close 'fp' upon use.
In-Reply-To: <1419035933-20411-1-git-send-email-git@internot.info>
References: <1419035933-20411-1-git-send-email-git@internot.info>
Message-ID: <54AC7BD9.4050500@fsij.org>

On 12/20/2014 09:38 AM, Joshua Rogers wrote:
> Inside the get_public_key function, 'fp' was opened using popen, but incorrectly closed using fclose.
> 
> From pclose(2):
>        The return value from popen() is a normal standard I/O stream in
>        all respects save that it must be closed with pclose() rather
>        than fclose(3).

Thank you for your patch.  Good catch.

I review it and I think that it's valid.  The bug is also there in 1.4
and 2.0.  The code path in question is for v1.0 card (which only
supports RSA-1024), so, the impact of this bug is considered not that
big.

After you submitted this patch, you sent DCO.  I'd like to make sure
that your intention can be also applied to this patch?

I will apply this to 2.1 and backport to 1.4 and 2.0.
-- 


From gniibe at fsij.org  Wed Jan  7 05:58:04 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 07 Jan 2015 13:58:04 +0900
Subject: [Pkg-gnupg-maint] Bug#773520: use-after-free
In-Reply-To: <5494208D.1070908@internot.info>
References: <5494208D.1070908@internot.info>
Message-ID: <54ACBCDC.7050402@fsij.org>

Hello,

Thanks for your reviewing and reporting.  This message is Cc-ed to
gnupg-devel.

On 12/19/2014 09:56 PM, Joshua Rogers wrote:
> Package: gnupg2
> Version: 2.1.1
> Severity: normal
[...]
> In ks-engine-hkp.c on line 509 'reftbl' is freed, but it is then
> used on line 511. I'm guessing this is a missing return;.

Right.

Here is my fix along with other fixes in map_host function.


diff --git a/dirmngr/ks-engine-hkp.c b/dirmngr/ks-engine-hkp.c
index 3c6a003..c13cec9 100644
--- a/dirmngr/ks-engine-hkp.c
+++ b/dirmngr/ks-engine-hkp.c
@@ -325,6 +325,7 @@ static gpg_error_t
 map_host (ctrl_t ctrl, const char *name, int force_reselect,
           char **r_host, unsigned int *r_httpflags, char **r_poolname)
 {
+  gpg_error_t err = 0;
   hostinfo_t hi;
   int idx;

@@ -361,8 +362,9 @@ map_host (ctrl_t ctrl, const char *name, int force_reselect,
       idx = create_new_hostinfo (name);
       if (idx == -1)
         {
+          err = gpg_error_from_syserror ();
           xfree (reftbl);
-          return gpg_error_from_syserror ();
+          return err;
         }
       hi = hosttable[idx];

@@ -504,9 +506,11 @@ map_host (ctrl_t ctrl, const char *name, int force_reselect,
           hi->pool = xtryrealloc (reftbl, (refidx+1) * sizeof *reftbl);
           if (!hi->pool)
             {
+              err = gpg_error_from_syserror ();
               log_error ("shrinking index table in map_host failed: %s\n",
                          strerror (errno));
               xfree (reftbl);
+              return err;
             }
           qsort (reftbl, refidx, sizeof *reftbl, sort_hostpool);
         }
@@ -570,12 +574,13 @@ map_host (ctrl_t ctrl, const char *name, int force_reselect,
   *r_host = xtrystrdup (hi->name);
   if (!*r_host)
     {
+      err = gpg_error_from_syserror ();
       if (r_poolname)
         {
           xfree (*r_poolname);
           *r_poolname = NULL;
         }
-      return gpg_error_from_syserror ();
+      return err;
     }
   return 0;
 }
-- 


From gniibe at fsij.org  Wed Jan  7 06:54:34 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 07 Jan 2015 14:54:34 +0900
Subject: [Pkg-gnupg-maint] Bug#773507: explicit buffer overrun
In-Reply-To: <5493FCCA.1070809@internot.info>
References: <5493FCCA.1070809@internot.info>
Message-ID: <54ACCA1A.3060204@fsij.org>

Hello,

Thanks for your reviewing and reporting.  This message is Cc-ed to
gnupg-devel.

On 12/19/2014 07:24 PM, Joshua Rogers wrote:
> Package: gnupg2
> Version: 2.1.1
> Severity: normal
> 
> in dirmngr/ldap.c on line 617, argv may be overflowed.
> 
> 617: argv[argc++] = url;
> 
> a check is made on line 591 that checks to see whether argv is less than or email to 399, and if it does, exit.
> But argv is char *argv[50], while argc is a normal int.
> If argc is 398, it will pass that check.

Right.

Here's my fix.  I'm going to apply this change since it's obvious
simple fix and there will be no conflict.

diff --git a/dirmngr/ldap.c b/dirmngr/ldap.c
index 478fdfd..00df167 100644
--- a/dirmngr/ldap.c
+++ b/dirmngr/ldap.c
@@ -588,7 +588,7 @@ start_cert_fetch_ldap (ctrl_t ctrl, cert_fetch_context_t *context,
       strlist_t sl;
       char *url;

-      if (argc >= sizeof argv -1)
+      if (argc >= DIM (argv) - 1)
         {
           /* Too many patterns.  It does not make sense to allow an
              arbitrary number of patters because the length of the
-- 


From gniibe at fsij.org  Wed Jan  7 09:09:12 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 07 Jan 2015 17:09:12 +0900
Subject: [Pkg-gnupg-maint] Bug#773507: explicit buffer overrun
In-Reply-To: <54ACCA1A.3060204@fsij.org>
References: <5493FCCA.1070809@internot.info> <54ACCA1A.3060204@fsij.org>
Message-ID: <54ACE9A8.7080108@fsij.org>

On 01/07/2015 02:54 PM, NIIBE Yutaka wrote:
> Here's my fix.  I'm going to apply this change since it's obvious
> simple fix and there will be no conflict.
> 
> diff --git a/dirmngr/ldap.c b/dirmngr/ldap.c
> index 478fdfd..00df167 100644
> --- a/dirmngr/ldap.c
> +++ b/dirmngr/ldap.c
> @@ -588,7 +588,7 @@ start_cert_fetch_ldap (ctrl_t ctrl, cert_fetch_context_t *context,
>        strlist_t sl;
>        char *url;
> 
> -      if (argc >= sizeof argv -1)
> +      if (argc >= DIM (argv) - 1)
>          {
>            /* Too many patterns.  It does not make sense to allow an
>               arbitrary number of patters because the length of the

Pushed.
-- 


From wk at gnupg.org  Wed Jan  7 09:22:46 2015
From: wk at gnupg.org (Werner Koch)
Date: Wed, 07 Jan 2015 09:22:46 +0100
Subject: Bug#773474: [PATCH] * scd/app-openpgp.c: (get_public_key)
 correctly close 'fp' upon use.
In-Reply-To: <54AC7BD9.4050500@fsij.org> (NIIBE Yutaka's message of "Wed, 07
 Jan 2015 09:20:41 +0900")
References: <1419035933-20411-1-git-send-email-git@internot.info>
 <54AC7BD9.4050500@fsij.org>
Message-ID: <87d26ryp7t.fsf@vigenere.g10code.de>

On Wed,  7 Jan 2015 01:20, gniibe at fsij.org said:
> On 12/20/2014 09:38 AM, Joshua Rogers wrote:
>> Inside the get_public_key function, 'fp' was opened using popen, but incorrectly closed using fclose.

> Thank you for your patch.  Good catch.

Yeah. After 9 years or so :-).

But there is a portability problem.  From libgcrypt's rndunix.c:

/* Under SunOS popen() doesn't record the pid of the child process.  When
 * pclose() is called, instead of calling waitpid() for the correct child, it
 * calls wait() repeatedly until the right child is reaped.  The problem is
 * that this reaps any other children that happen to have died at that
 * moment, and when their pclose() comes along, the process hangs forever.
 * The fix is to use a wrapper for popen()/pclose() which saves the pid in
 * the dataSources structure (code adapted from GNU-libc's popen() call).
 *
 * Aut viam inveniam aut faciam */

scdaemon may also start other processes (status scripts) and there is a
chance that the above described bug would be triggered.  However, I do
not know up to which SunOS version the problem exists and whether anyone
is using the really old 1.0 card on SunOS.

Thus the fix is better than keeping it as it is.


Shalom-Salam,

   Werner


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



From wk at gnupg.org  Wed Jan  7 09:30:36 2015
From: wk at gnupg.org (Werner Koch)
Date: Wed, 07 Jan 2015 09:30:36 +0100
Subject: [Pkg-gnupg-maint] Bug#773507: explicit buffer overrun
In-Reply-To: <54ACCA1A.3060204@fsij.org> (NIIBE Yutaka's message of "Wed, 07
 Jan 2015 14:54:34 +0900")
References: <5493FCCA.1070809@internot.info> <54ACCA1A.3060204@fsij.org>
Message-ID: <878uhfyour.fsf@vigenere.g10code.de>

On Wed,  7 Jan 2015 06:54, gniibe at fsij.org said:

> -      if (argc >= sizeof argv -1)
> +      if (argc >= DIM (argv) - 1)
>          {

Ooops.  That was probably my fault when I rewrite that function 10 years
ago.


Salam-Shalom,

   Werner

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



From pgut001 at cs.auckland.ac.nz  Wed Jan  7 13:11:32 2015
From: pgut001 at cs.auckland.ac.nz (Peter Gutmann)
Date: Thu, 08 Jan 2015 01:11:32 +1300
Subject: Bug#773474: [PATCH] * scd/app-openpgp.c: (get_public_key)
 correctly close 'fp' upon use.
In-Reply-To: <87d26ryp7t.fsf@vigenere.g10code.de>
Message-ID: <E1Y8pSW-0006N4-Ud@login01.fos.auckland.ac.nz>

Werner Koch <wk at gnupg.org> writes:

>However, I do not know up to which SunOS version the problem exists and
>whether anyone is using the really old 1.0 card on SunOS.

Probably SunOS 4.1.1.  However, doing a custom popen() allows taking care of a
few other things as well, which is why it's still in there.

Having said that, there are some awfully old copies of the cryptlib entropy-
polling code floating around, moving to a current version would be a good
idea.

Oh, and if people make changes, letting me know so I can merge them into the
upstream version would be good.

Peter.


From gniibe at fsij.org  Thu Jan  8 03:53:58 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 08 Jan 2015 11:53:58 +0900
Subject: Bug#773474: [PATCH] * scd/app-openpgp.c: (get_public_key)
 correctly close 'fp' upon use.
In-Reply-To: <87d26ryp7t.fsf@vigenere.g10code.de>
References: <1419035933-20411-1-git-send-email-git@internot.info>	<54AC7BD9.4050500@fsij.org>
 <87d26ryp7t.fsf@vigenere.g10code.de>
Message-ID: <54ADF146.1090207@fsij.org>

On 01/07/2015 05:22 PM, Werner Koch wrote:
> But there is a portability problem.  From libgcrypt's rndunix.c:

Thanks for your information, I see.  I also checked gnulib and found
there are other issues for popen/pclose.  In future, in case we want
to improve OpenPGPcard v1.0 support, we should think about these
portability issues.

Well, the fix is basically for correctness of the code.  I applied it
to all branches (STABLE-BRANCH-1-4, STABLE-BRANCH-2-0, and master).  I
know the code is not used for gpg 1.4, but it's better to have code in
sync.



IIRC, in natural language, "SunOS" usually referred version 4 or
earlier (uname returned "SunOS" on the machine of "Solaris" 2 or
later).  If the bug existed in version 5 or later, it would also exist
in other SVR4 based Operating System.

And...  I don't think version 4 had USB support.  USB 1.0 was in 1996.
-- 


From gniibe at fsij.org  Thu Jan  8 04:40:01 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 08 Jan 2015 12:40:01 +0900
Subject: [Pkg-gnupg-maint] Bug#773520: use-after-free
In-Reply-To: <54ACBCDC.7050402@fsij.org>
References: <5494208D.1070908@internot.info> <54ACBCDC.7050402@fsij.org>
Message-ID: <54ADFC11.5010106@fsij.org>

On 01/07/2015 01:58 PM, NIIBE Yutaka wrote:
> Here is my fix along with other fixes in map_host function.
[...]
> @@ -504,9 +506,11 @@ map_host (ctrl_t ctrl, const char *name, int force_reselect,
>            hi->pool = xtryrealloc (reftbl, (refidx+1) * sizeof *reftbl);
>            if (!hi->pool)
>              {
> +              err = gpg_error_from_syserror ();
>                log_error ("shrinking index table in map_host failed: %s\n",
>                           strerror (errno));
>                xfree (reftbl);
> +              return err;
>              }

Changing the call of strerror (errno) above into gpg_strerror (err), I
committed the change into master.
-- 


From gniibe at fsij.org  Thu Jan  8 05:06:08 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 08 Jan 2015 13:06:08 +0900
Subject: agent: Fix agent_public_key_from_file
In-Reply-To: <549BBAFE.8010605@fsij.org>
References: <54981864.7050005@fsij.org> <87wq5jstc7.fsf@vigenere.g10code.de>
 <54982D3A.1040307@fsij.org> <549BBAFE.8010605@fsij.org>
Message-ID: <54AE0230.6080901@fsij.org>

Hello,

I think that I reviewed recent reports (to gnupg-devel, to Debian BTS,
and to g10code BTS) and I've done what I can.

Then, may I ask to review mine?

On 12/25/2014 04:21 PM, NIIBE Yutaka wrote:
> Here is the part one of ECC key format fixes, fixing
> agent_public_key_from_file function.
[...]
> With this patch, KEYTOCARD works fine, and I believe no regression.

Well, I don't have concrete idea about the part two.  I don't know if
we should support arbitrary curves with parameters (for GnuPG).  I
think that OpenPGP specification for ECC requires OID to use (since
OID is a part of fingerprint calculation).  While we will add a curve
with OID in future, we will surly assign a name to that curve in
libgcrypt.
-- 


From gniibe at fsij.org  Fri Jan  9 01:19:55 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Fri, 09 Jan 2015 09:19:55 +0900
Subject: backporting fixes from master
Message-ID: <54AF1EAB.7090900@fsij.org>

Hello,

Reviewing fixes in the master branch since 2.1.0, I backported
following change to 2.0 and 1.4.

    commit 68b4e7c9e4de0dc3580ca5af3cfd0f20a2691b5e
    Author: Werner Koch <wk at gnupg.org>
    Date:   Fri Dec 12 20:08:45 2014 +0100

        scd: Fix possibly inhibited checkpin of the admin pin.

        * scd/app-openpgp.c (do_check_pin): Do not check a byte of a released
        buffer.

        Signed-off-by: Werner Koch <wk at gnupg.org>

And I think that following eight fixes should be backported to 2.0.

Out of eight, six fixes can be just "git cherry-pick"-ed.

    commit cf88337f8a4f8c98aca4b1da5921d18567b4f474
    Author: Joshua Rogers <git at internot.info>
    Date:   Tue Dec 23 00:47:50 2014 +1100

        tools: Free variable before return

        * tools/gpgconf-comp.c: Free 'dest_filename' before it is returned
        upon error.
        --

        Signed-off-by: Joshua Rogers <git at internot.info>


    commit ed8383c618e124cfa708c9ee87563fcdf2f4649c
    Author: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
    Date:   Fri Dec 19 18:53:34 2014 -0500

        sm: Avoid double-free on iconv failure

        * sm/minip12.c: (p12_build) if jnlib_iconv_open fails, avoid
        double-free of pwbuf.

        --

        Observed by Joshua Rogers <honey at internot.info>, who proposed a
        slightly different fix.

        Debian-Bug-Id: 773472

        Added fix at a second place - wk.


    commit b0b3803e8c2959dd67ca96debc54b5c6464f0d41
    Author: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
    Date:   Fri Dec 19 18:07:55 2014 -0500

        scd: Avoid double-free on error condition in scd

        * scd/command.c (cmd_readkey): avoid double-free of cert

        --

        When ksba_cert_new() fails, cert will be double-freed.

        Debian-Bug-Id: 773471

        Original patch changed by wk to do the free only at leave.


    commit 367b073ab5f439ccf0750461d10c69f36998bd62
    Author: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
    Date:   Fri Dec 19 17:53:36 2014 -0500

        avoid future chance of using uninitialized memory

        * common/iobuf.c: (iobuf_open): initialize len

        --

        In iobuf_open, IOBUFCTRL_DESC and IOBUFCTRL_INIT commands are invoked
        (via file_filter()) on fcx, passing in a pointer to an uninitialized
        len.

        With these two commands, file_filter doesn't actually do anything with
        the value of len, so there's no actual risk of use of uninitialized
        memory in the code as it stands.

        However, some static analysis tools might flag this situation with a
        warning, and initializing the value doesn't hurt anything, so i think
        this trivial cleanup is warranted.

        Debian-Bug-Id: 773469


    commit 351bca9047d748c3c4f7e9a3cdc476af127b1da3
    Author: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
    Date:   Fri Dec 19 17:12:05 2014 -0500

        gpgkey2ssh: clean up varargs

        * tools/gpgkey2ssh.c (key_to_blob) : ensure that va_end is called.

        --

        stdarg(3) says:
               Each invocation of va_start() must be matched by a
               corresponding invocation of va_end() in the same function.

        Observed by Joshua Rogers <honey at internot.info>

        Debian-Bug-Id: 773415


    commit 6056d2467310260ddc0db2fe65b737ace6febcaa
    Author: Werner Koch <wk at gnupg.org>
    Date:   Mon Dec 22 12:44:13 2014 +0100

        doc: Fix memory leak in yat2m.

        * doc/yat2m.c (write_th): Free NAME.
        --

        Reported-by: Joshua Rogers <git at internot.info>


And two requires manual edit, but easy to apply.


****
    commit 193815030d20716d9a97850013ac3cc8749022c9
    Author: Werner Koch <wk at gnupg.org>
    Date:   Fri Dec 12 10:41:25 2014 +0100

        gpg: Fix possible read of unallocated memory

        * g10/parse-packet.c (can_handle_critical): Check content length
        before calling can_handle_critical_notation.
        --

        The problem was found by Jan Bee and gniibe proposed the used fix.
        Thanks.

        This bug can't be exploited: Only if the announced length of the
        notation is 21 or 32 a memcmp against fixed strings using that length
        would be done.  The compared data is followed by the actual signature
        and thus it is highly likely that not even read of unallocated memory
        will happen.  Nevertheless such a bug needs to be fixed.

        Signed-off-by: Werner Koch <wk at gnupg.org>

****
    commit abd5f6752d693b7f313c19604f0723ecec4d39a6
    Author: Werner Koch <wk at gnupg.org>
    Date:   Mon Dec 22 12:16:46 2014 +0100

        dirmngr,gpgsm: Return NULL on fail

        * dirmngr/ldapserver.c (ldapserver_parse_one): Set SERVER to NULL.
        * sm/gpgsm.c (parse_keyserver_line): Ditto.
        --

        Reported-by: Joshua Rogers <git at internot.info>

          "If something inside the ldapserver_parse_one function failed,
           'server' would be freed, then returned, leading to a
           use-after-free.  This code is likely copied from sm/gpgsm.c, which
           was also susceptible to this bug."

        Signed-off-by: Werner Koch <wk at gnupg.org>
-- 


From wk at gnupg.org  Fri Jan  9 12:38:40 2015
From: wk at gnupg.org (Werner Koch)
Date: Fri, 09 Jan 2015 12:38:40 +0100
Subject: backporting fixes from master
In-Reply-To: <54AF1EAB.7090900@fsij.org> (NIIBE Yutaka's message of "Fri, 09
 Jan 2015 09:19:55 +0900")
References: <54AF1EAB.7090900@fsij.org>
Message-ID: <87lhlcqj3z.fsf@vigenere.g10code.de>

On Fri,  9 Jan 2015 01:19, gniibe at fsij.org said:

> Reviewing fixes in the master branch since 2.1.0, I backported
> following change to 2.0 and 1.4.

Thanks.

> And I think that following eight fixes should be backported to 2.0.

Yep.  That also raises the questions on how we can best track patches
which need to be back- or forward ported.  In the bug tracker we have a
"backport" tag but this requires manual inspection to see for which
branch this is relvant and where it has already been done.  And not all
things end up in the tracker.

Adding a "Backport: yes/maybe" line to the commit messages would be the
easiest solution but we won't hav a way to mark that as done.

Using a Wiki would be an easy ad-hoc solution.

I am not sure how to handle this.  A more formal use of the bug tracker
is likely the best solution.

> Out of eight, six fixes can be just "git cherry-pick"-ed.

I assume you take them.


Shalom-Salam,

   Werner

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



From wk at gnupg.org  Fri Jan  9 12:44:27 2015
From: wk at gnupg.org (Werner Koch)
Date: Fri, 09 Jan 2015 12:44:27 +0100
Subject: Bug#773474: [PATCH] * scd/app-openpgp.c: (get_public_key)
 correctly close 'fp' upon use.
In-Reply-To: <E1Y8pSW-0006N4-Ud@login01.fos.auckland.ac.nz> (Peter Gutmann's
 message of "Thu, 08 Jan 2015 01:11:32 +1300")
References: <E1Y8pSW-0006N4-Ud@login01.fos.auckland.ac.nz>
Message-ID: <87h9w0qiuc.fsf@vigenere.g10code.de>

On Wed,  7 Jan 2015 13:11, pgut001 at cs.auckland.ac.nz said:

> Having said that, there are some awfully old copies of the cryptlib entropy-
> polling code floating around, moving to a current version would be a good

Yeah, I know :-(.  No way to run regression tests thus a lot of code
staring or intrumentaion will be required.  Should really be done for
1.7.  I assigned bug 1810 to it.


Salam-Shalom,

   Werner

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



From mailinglist at simondieterle.net  Sat Jan 10 23:46:26 2015
From: mailinglist at simondieterle.net (Simon Dieterle)
Date: Sat, 10 Jan 2015 23:46:26 +0100
Subject: Problem with own pinentry
Message-ID: <54B1ABC2.4080302@simondieterle.net>

Hi,

i started coding a pinentry for use with gnome-shell and gnome-keyring
as optional passphrase storage. When i invoke the pinentry via the terminal

$gnome-shell/pinentry-gnome-shell
OK Your orders please
SETDESC ID1234
OK
GETPIN
D MyTestPin
OK

every thing seems to work. I encountered a problem when i kill the
gpg-agent and let it start again with clicking on an gpg encrypted mail
in thunderbird. gpg-agent starts with

gpg-agent --homedir /home/simon/.gnupg --use-standard-socket --daemon

and thunderbird can not decrypt because s.th. goes wrong with the pinentry.

What i find really strange is that if i kill the agent and start it via
the terminal, pinentry retrieves the information from gnome-keyring and
thunderbird is able to decrypt the message.

Manually invoking the agent leads to different results compared to
letting it start.

I really don't have a idea where the error is. And i also don't know
where to look. How would i compare the exchange between GPG agent and
pinentry in both cases.

Regards,
Simon




From diafygi at gmail.com  Sun Jan 11 01:11:56 2015
From: diafygi at gmail.com (Daniel Roesler)
Date: Sat, 10 Jan 2015 16:11:56 -0800
Subject: Request to add port number to --send-key and --recv-key output
Message-ID: <CA+65Osqrny3AZ6NmgNzcVaFvFysiNFsvkjVgLhWusWtkfGdUng@mail.gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Howdy all,

Previously discussed on moderncrypto[1], I'd like to request that output for
- --send-key and --recv-key contain the port number for keys.gnupg.net. Many of
the servers in the sks pool don't mirror the keyserver interface on port 80[2],
so if you copy and paste keys.gnupg.net in a browser, sometimes you see a random
site (which confused and worried me until I figured it out). If the port number
were include, copying and pasting into a browser would have resulted in the
normal sks keyserver HTTP interface.

Here's the requested change:

From:
$ gpg --recv-key "72EFEE3D"
gpg: requesting key 72EFEE3D from hkp server keys.gnupg.net

To:
$ gpg --recv-key "72EFEE3D"
gpg: requesting key 72EFEE3D from hkp server keys.gnupg.net:11371

AND

From:
$ gpg --send-key "72EFEE3D"
gpg: sending key 72EFEE3D to hkp server keys.gnupg.net

To:
$ gpg --send-key "72EFEE3D"
gpg: sending key 72EFEE3D to hkp server keys.gnupg.net:11371

Untested diff from Andy Isaacson:

diff --git a/g10/keyserver.c b/g10/keyserver.c
index 1b2e128..48d0e07 100644
- --- a/g10/keyserver.c
+++ b/g10/keyserver.c
@@ -1746,9 +1746,10 @@ keyserver_put (ctrl_t ctrl, strlist_t keyspecs,
       else
         {
           if (keyserver->host)
- -            log_info (_("sending key %s to %s server %s\n"),
+            log_info (_("sending key %s to %s server %s:%s\n"),
                       keystr (keyblock->pkt->pkt.public_key->keyid),
- -                      keyserver->scheme, keyserver->host);
+                      keyserver->scheme, keyserver->host,
+                      keyserver->port ? keyserver->port : "");
           else
             log_info (_("sending key %s to %s\n"),
                       keystr (keyblock->pkt->pkt.public_key->keyid),

Cheers!
Daniel

[1]: https://moderncrypto.org/mail-archive/messaging/2014/000992.html
[2]: https://sks-keyservers.net/status/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUsb8HAAoJEOf2+tFy7+49wFcQAI1YTW1UXI5PhgLBxcDF3q9E
aXIpVFsg9MDpo/DP0m6cub/tU47fX+0ZT6lVHWtsAcen2RUUeQ+Rbj1Te+TTcuNO
wXT83LgJq/BTYKPWXf+rvUVpFZgOYZbLjY1PIgR3qnM3oBDIDEwGk0Ov2QXIZWhJ
snb6KRQxcxE/tUUNL4MR1zsQk3r4q2pOtV3Q5BTot81jjFFjhdSGEGIpsxyN/12P
ZrV/HHLeINQpfJjcfsduZ8VMTl6X5WZue0uj1RHSM52/WKC57enL+CYudFNFlapj
bBoNw+nR0tKIdTnsF3mNOZVsuD1XoEEv8DvCTaLFWyoQIgv9pGJHDTJPlYJ5/43U
GSd/hd5qUXkPfqwfJ/pP7fvL+wa270M83EAua7ll7aNSMc4ByxEvnYYGD1I3zwzY
gq+X9hAcXTdAGpMfE6nRn0V/Z9BpHofL48ESG55UbqWnawU99uRqv6fJXJwtOhI9
2JxYzA5/EVFMQbKVrsac0lV6wa6qCWf3IKO8BFG0ZPdnjutuUSX3GMpsMUEtjRSe
FzK88woWim9119fvJb4unf1PksbfVu3dQsZr/6jgqoq2WIUmTvMncJc/jYqtgNMv
ILguOcVIIJsuAXNjKkyMmIuhXjkjXT13ySwMfQ9l4LYB059Yopj4DzD4qAEU7QlC
fxUG7fCy20J4Nb68p0TU
=mzlX
-----END PGP SIGNATURE-----


From kristian.fiskerstrand at sumptuouscapital.com  Sun Jan 11 14:57:04 2015
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Sun, 11 Jan 2015 14:57:04 +0100
Subject: Request to add port number to --send-key and --recv-key output
In-Reply-To: <CA+65Osqrny3AZ6NmgNzcVaFvFysiNFsvkjVgLhWusWtkfGdUng@mail.gmail.com>
References: <CA+65Osqrny3AZ6NmgNzcVaFvFysiNFsvkjVgLhWusWtkfGdUng@mail.gmail.com>
Message-ID: <54B28130.30508@sumptuouscapital.com>

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

On 01/11/2015 01:11 AM, Daniel Roesler wrote:
> Howdy all,
> 
> Previously discussed on moderncrypto[1], I'd like to request that
> output for --send-key and --recv-key contain the port number for
> keys.gnupg.net. Many of the servers in the sks pool don't mirror
> the keyserver interface on port 80[2], so if you copy and paste
> keys.gnupg.net in a browser, sometimes you see a random site (which
> confused and worried me until I figured it out). If the port
> number were include, copying and pasting into a browser would have
> resulted in the normal sks keyserver HTTP interface.

There are no requirements for the keyservers to present a "human
readable" UI. Ok, so I'm putting that in quotes here since it is all
text based and indeed human readable, but the point is that they would
have to know the HKP specs to perform the lookups using the correct
"API calls".

> 
> Here's the requested change:
> 
> From: $ gpg --recv-key "72EFEE3D" gpg: requesting key 72EFEE3D from
> hkp server keys.gnupg.net

HKP defaults to 11371 so that information is already included by the
absence of anything else.

- -- 
- ----------------------------
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
- ----------------------------
"A government that robs Peter to pay Paul can always depend on the
support of Paul."
(George Bernard Shaw)
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUsoEuAAoJEPw7F94F4TagPfQP/AylYrE+ZPFESNKkxFtNGUpV
lyxOWjlcZnnm4VDq2pZAkb8ibkEJFCzARYlS/LOzj6x/71nRdAaKav2DMxxl7GD5
oK56q8+4HcUj3fU/GRFos0UAoxgqI2gfy4svOM/3eUtneJrr5iIIyDnZJxNDrbHX
K0FLtLU5ALmap90PG+qlL2N3hweO+hE1smBDF4YP6QpGw7r668cjdRAeCjuHhFIw
AaPDuGotIMO9SO2Hh+J0+RGLSOQJz3JLDQDgy5J61uhzxURLVBHzyqqeYZ0/nBx3
5HVX/tsI7SaatYyIhrtiSa0I03gXf0NvhT1UdU/DS8StqmNT5R2jCeQmnoKHklgz
CcGQWMHmV1t+AwhFw+cSJG5+VG7umh9ExB9ngAQU8aEf6N2016icWGYn1cc8hCBK
AkvQ50RtZUkHi2viXY2kHwT7QktuVrCvNgPBN/FJvJf50zHdL8tpvPJyHKRph3LX
wv3j+wmeZigVobFHHAmMjEVLisdo0TWsqFloue83GUL9h+BeUvym1vbm+DJwEssl
SD28ZzrSwV92ELwk1+A9vldt1g1Ww/y+FCwp3OFpBHV4n+8Yco5cF5vrabzDmQEX
Qeb2PzuBh9bjjiqnq1pOwpOwjZ6HsDvfsvhbub4dw/dS6jdaIBdELZZGRUpsCMPt
wF5fnscMf6nG1EPhjWPQ
=MB5G
-----END PGP SIGNATURE-----


From gniibe at fsij.org  Tue Jan 13 04:20:59 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 13 Jan 2015 12:20:59 +0900
Subject: backporting fixes from master
In-Reply-To: <87lhlcqj3z.fsf@vigenere.g10code.de>
References: <54AF1EAB.7090900@fsij.org> <87lhlcqj3z.fsf@vigenere.g10code.de>
Message-ID: <54B48F1B.6070405@fsij.org>

On 01/09/2015 09:19 AM (+0900), NIIBE Yutaka wrote:
> And I think that following eight fixes should be backported to 2.0.

I committed the changes to 2.0 and also the ones which are applicable
to 1.4.

While build test, I encountered a failure of makeinfo (with Texinfo
5.2), I backported a part of changes in
ff6115227a1ced14e2fb3d160a12181b9dfbc502 to 1.4.

Then, no build failures with "make check" (for 2.0 and for 1.4).

On 01/09/2015 08:38 PM, Werner Koch wrote:
> I am not sure how to handle this.  A more formal use of the bug tracker
> is likely the best solution.

Agreed.

For specific cases like OpenPGP card manufacturer IDs and supported
card readers, I think that WiKi also helps.
-- 


From gniibe at fsij.org  Tue Jan 13 04:27:43 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 13 Jan 2015 12:27:43 +0900
Subject: Forward-port from 2.0
Message-ID: <54B490AF.3020409@fsij.org>

Scanning log of STABLE-BRANCH-2-0, I forward-ported following
change to master (2.1).

commit 5798673156a66f4c39e1d34e358b03539194d57c
Author: Andreas Schwier <andreas.schwier at cardcontact.de>
Date:   Fri Jul 18 18:22:26 2014 +0200

    scd: Allow for certificates > 1024 with PC/SC.

    * scd/pcsc-wrapper.c (handle_transmit): Enlarge buffer to 4096 too
    allow for larger certificates.
-- 


From wk at gnupg.org  Tue Jan 13 08:57:13 2015
From: wk at gnupg.org (Werner Koch)
Date: Tue, 13 Jan 2015 08:57:13 +0100
Subject: Forward-port from 2.0
In-Reply-To: <54B490AF.3020409@fsij.org> (NIIBE Yutaka's message of "Tue, 13
 Jan 2015 12:27:43 +0900")
References: <54B490AF.3020409@fsij.org>
Message-ID: <87zj9ndsfa.fsf@vigenere.g10code.de>

On Tue, 13 Jan 2015 04:27, gniibe at fsij.org said:
> Scanning log of STABLE-BRANCH-2-0, I forward-ported following
> change to master (2.1).

Thanks.


Salam-Shalom,

   Werner

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



From wk at gnupg.org  Tue Jan 13 12:33:25 2015
From: wk at gnupg.org (Werner Koch)
Date: Tue, 13 Jan 2015 12:33:25 +0100
Subject: Issuer Fingerprint (was: Vanity Keys)
In-Reply-To: <CAAu18hdCBXbvhfAAnzB7yuHP3h+rffwiVLOKK=Ae=z+VA7YAOw@mail.gmail.com>
 (Nicholas Cole's message of "Tue, 13 Jan 2015 09:41:42 +0000")
References: <20150112205104.GA12857@glue.grepular.com>
 <87r3uzdrt3.fsf@vigenere.g10code.de>
 <CAAu18hdCBXbvhfAAnzB7yuHP3h+rffwiVLOKK=Ae=z+VA7YAOw@mail.gmail.com>
Message-ID: <87zj9mdiey.fsf_-_@vigenere.g10code.de>

[Moving discussion to gnupg-devel]

On Tue, 13 Jan 2015 10:41, nicholas.cole at gmail.com said:

> Or a new revision of the standard, I suppose.  But I think that one or

A new key and signature packet version will take years to develop and
deploy.  Thus I think it is better to first do something within the
standard which will be backward compatible.

We currently use this subpacket:

  5.2.3.5.  Issuer

   (8-octet Key ID)

   The OpenPGP Key ID of the key issuing the signature.

A new optional subpacket:

5.2.3.27.  IssuerFingerprint

   (N-octet Key Fingerprint)

   The OpenPGP Fingerprint of the key issuing the signature.  For
   current versions of OpenPGP N has the value 20.  Future versions of
   OpenPGP may specify a different scheme for the fingerprint and thus
   another value for N.  Implementations should thus be prepared for
   other fingerprint lengths but honor this subpacket only if N is 20.

could be used to overcome duplicate key id problems.  The subpacket
type octet for that new subpacket would be 33.  Note that

  Adding a new Signature subpacket MUST be done through the IETF
  CONSENSUS method, as described in [RFC2434].

which takes quite some time.  Should be pursue this task or take a quick
solution by using notation data?

The size of a signature will increase by 22 or even more when using the
notation data approach.  This is noticeable but given that we are anyway
moving to the smaller ECC algorithms I think this is acceptable.


Shalom-Salam,

   Werner

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



From mailinglisten at hauke-laging.de  Tue Jan 13 16:18:48 2015
From: mailinglisten at hauke-laging.de (Hauke Laging)
Date: Tue, 13 Jan 2015 16:18:48 +0100
Subject: Issuer Fingerprint (was: Vanity Keys)
In-Reply-To: <87zj9mdiey.fsf_-_@vigenere.g10code.de>
References: <20150112205104.GA12857@glue.grepular.com>
 <CAAu18hdCBXbvhfAAnzB7yuHP3h+rffwiVLOKK=Ae=z+VA7YAOw@mail.gmail.com>
 <87zj9mdiey.fsf_-_@vigenere.g10code.de>
Message-ID: <44414626.FVqmuR7KOP@inno>

Am Di 13.01.2015, 12:33:25 schrieb Werner Koch:

> A new key and signature packet version will take years to develop and
> deploy.

> Should be pursue this task or take a
> quick solution by using notation data?

I suggest doing it right now because this work would not have to be done 
for the next OpenPGP standard version any more. A notation-based 
solution would not be part of the next standard.


> The size of a signature will increase by 22 or even more

Who cares? Obviously not the average user who turns to 4096 bit keys 
now... In case there are applications which need to avoid this a 
configuration option might be introduced which avoids the additional 
subpacket.


Hauke
-- 
Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/
http://userbase.kde.org/Concepts/OpenPGP_Help_Spread
OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20150113/de49e9f1/attachment.sig>

From dshaw at jabberwocky.com  Tue Jan 13 16:48:39 2015
From: dshaw at jabberwocky.com (David Shaw)
Date: Tue, 13 Jan 2015 10:48:39 -0500
Subject: Issuer Fingerprint (was: Vanity Keys)
In-Reply-To: <87zj9mdiey.fsf_-_@vigenere.g10code.de>
References: <20150112205104.GA12857@glue.grepular.com>
 <87r3uzdrt3.fsf@vigenere.g10code.de>
 <CAAu18hdCBXbvhfAAnzB7yuHP3h+rffwiVLOKK=Ae=z+VA7YAOw@mail.gmail.com>
 <87zj9mdiey.fsf_-_@vigenere.g10code.de>
Message-ID: <1AD8F0BF-2778-44B4-9BAB-E084073D977C@jabberwocky.com>

On Jan 13, 2015, at 6:33 AM, Werner Koch <wk at gnupg.org> wrote:
> 
> [Moving discussion to gnupg-devel]
> 
> On Tue, 13 Jan 2015 10:41, nicholas.cole at gmail.com said:
> 
>> Or a new revision of the standard, I suppose.  But I think that one or
> 
> A new key and signature packet version will take years to develop and
> deploy.  Thus I think it is better to first do something within the
> standard which will be backward compatible.
> 
> We currently use this subpacket:
> 
>  5.2.3.5.  Issuer
> 
>   (8-octet Key ID)
> 
>   The OpenPGP Key ID of the key issuing the signature.
> 
> A new optional subpacket:
> 
> 5.2.3.27.  IssuerFingerprint
> 
>   (N-octet Key Fingerprint)
> 
>   The OpenPGP Fingerprint of the key issuing the signature.  For
>   current versions of OpenPGP N has the value 20.  Future versions of
>   OpenPGP may specify a different scheme for the fingerprint and thus
>   another value for N.  Implementations should thus be prepared for
>   other fingerprint lengths but honor this subpacket only if N is 20.
> 
> could be used to overcome duplicate key id problems.  The subpacket
> type octet for that new subpacket would be 33.  Note that
> 
>  Adding a new Signature subpacket MUST be done through the IETF
>  CONSENSUS method, as described in [RFC2434].
> 
> which takes quite some time.  Should be pursue this task or take a quick
> solution by using notation data?

My feeling is that whether we do a notation or an assigned subpacket, we do it via the IETF process.  FWIW, adding an IETF namespace notation is via EXPERT REVIEW, which may be simpler than CONSENSUS.  I lean somewhat towards a subpacket for several reasons (size, reusability), though.

I don't want to use a notation from the user namespace until we get to the "real" subpacket or notation, as we'll end up with both, ultimately, with some code using the user notation and some using the subpacket/IETF notation.  We can end up stuck in that state for a long time, and have to support both for backwards compatibility reasons for even longer.

David



From wk at gnupg.org  Tue Jan 13 17:58:01 2015
From: wk at gnupg.org (Werner Koch)
Date: Tue, 13 Jan 2015 17:58:01 +0100
Subject: Issuer Fingerprint
In-Reply-To: <1AD8F0BF-2778-44B4-9BAB-E084073D977C@jabberwocky.com> (David
 Shaw's message of "Tue, 13 Jan 2015 10:48:39 -0500")
References: <20150112205104.GA12857@glue.grepular.com>
 <87r3uzdrt3.fsf@vigenere.g10code.de>
 <CAAu18hdCBXbvhfAAnzB7yuHP3h+rffwiVLOKK=Ae=z+VA7YAOw@mail.gmail.com>
 <87zj9mdiey.fsf_-_@vigenere.g10code.de>
 <1AD8F0BF-2778-44B4-9BAB-E084073D977C@jabberwocky.com>
Message-ID: <878uh6d3dy.fsf@vigenere.g10code.de>

On Tue, 13 Jan 2015 16:48, dshaw at jabberwocky.com said:

> My feeling is that whether we do a notation or an assigned subpacket,
> we do it via the IETF process.  FWIW, adding an IETF namespace
> notation is via EXPERT REVIEW, which may be simpler than CONSENSUS.  I

However, it saves only a few bytes and has the same complexity as a user
space.  We can keep this in mind as a fallback solution.

> ultimately, with some code using the user notation and some using the
> subpacket/IETF notation.  We can end up stuck in that state for a long
> time, and have to support both for backwards compatibility reasons for
> even longer.

Indeed this needs to be avoided.  Checking with the PGP guys to see why
some of the subpacket types are marked as reserved and pick one of them
might also be possible.

I see the main problem that we have no WG and everything needs to go
through the indivual submission process.  I have not seen any signs that
the WG will be re-established but this has never been offically
requested.

Move both discussions (WG establishment and IssuerFingerprint) to the
OpenPGP list?


Salam-Shalom,

   Werner

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



From gniibe at fsij.org  Wed Jan 14 02:53:12 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 14 Jan 2015 10:53:12 +0900
Subject: Forward-port from 2.0
In-Reply-To: <54B490AF.3020409@fsij.org>
References: <54B490AF.3020409@fsij.org>
Message-ID: <54B5CC08.4070502@fsij.org>

On 01/13/2015 12:27 PM, NIIBE Yutaka wrote:
>     * scd/pcsc-wrapper.c (handle_transmit): Enlarge buffer to 4096 too
>     allow for larger certificates.

Oops.  While it was applied successfully, it makes no sense, because
we don't use this file any more in 2.1 (With nPth, we don't need this
wrapper).  I should have considered the reason why it was applied to
2.0 branch, in the first place.

Please accept this careless apply/commit of mine, since it's harmless.
I think that it's better not to revert the change.

In future, we will remove this file and remove NEED_PCSC_WRAPPER
things in scd/apdu.c.
-- 


From wk at gnupg.org  Wed Jan 14 09:50:04 2015
From: wk at gnupg.org (Werner Koch)
Date: Wed, 14 Jan 2015 09:50:04 +0100
Subject: Forward-port from 2.0
In-Reply-To: <54B5CC08.4070502@fsij.org> (NIIBE Yutaka's message of "Wed, 14
 Jan 2015 10:53:12 +0900")
References: <54B490AF.3020409@fsij.org> <54B5CC08.4070502@fsij.org>
Message-ID: <871tmxbvb7.fsf@vigenere.g10code.de>

On Wed, 14 Jan 2015 02:53, gniibe at fsij.org said:

> In future, we will remove this file and remove NEED_PCSC_WRAPPER
> things in scd/apdu.c.

Yes, I think this is a good idea.  I doubt that we can still source copy
that file to 1.4 (which was the original idea) and it also does not make
sense to put a lot effort into keeping it source compatible to 2.0.
After all we will add an end-of-life statement to 2.0 after 2.1 is more
matured.


Shalom-Salam,

   Werner

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



From lukele at gpgtools.org  Wed Jan 14 12:42:41 2015
From: lukele at gpgtools.org (Lukas Pitschl)
Date: Wed, 14 Jan 2015 12:42:41 +0100
Subject: Hang in scdaemon or pcsc-wrapper on Yosemite
Message-ID: <53B1D16B-0A47-46F5-8550-A6B3CFF80908@gpgtools.org>

Hi,

many of our users using smart cards (especially YubiKey Neo) are experiencing a problem where the scdaemon hangs on Yosemite after a while.
While the timing is random, the problem seems to be appearing for all of them.

In order to find out what?s going on we were trying to connect to a debug build of scdaemon and pcsc-wrapper. Unfortunately though,as soon as the debugger is connected, scdaemon as well as the pcsc-wrapper exit due to a SIGPIPE signal.

We were wondering if any of you could tell us how to properly debug scdaemon or why it might exit when trying to connect a debugger.
Also if anyone knows what might lead to a hang in scdaemon, that information would be very valuable as well.

Best,

Lukas
GPGTools

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </pipermail/attachments/20150114/93d22d4b/attachment-0001.sig>

From hymie at lactose.homelinux.net  Wed Jan 14 15:39:24 2015
From: hymie at lactose.homelinux.net (hymie!)
Date: Wed, 14 Jan 2015 14:39:24 +0000 (UTC)
Subject: --passphrase and command line
Message-ID: <loom.20150114T153246-949@post.gmane.org>

Greetings.

I suspect that this has already been asked and discussed, but my attempts to
search were all unsuccessful.

When I run my mysql client, I can use this syntax:

mysql -unobody -psecretpassword

and when I do a ps, I see this:

 3606 pts/2    S+     0:00 mysql -unobody -px xxxxx

The password is removed from the ps command as well as from
/proc/3606/cmdline .  If it's anywhere else, I can't find it.

Can this feature be added to the "--passphrase" option of gpg?  It's my
humble opinion that this would improve the security of batch processing over
either --passphrase-fd or --passphrase-file .

Thanks.

--hymie!



From wk at gnupg.org  Wed Jan 14 17:09:09 2015
From: wk at gnupg.org (Werner Koch)
Date: Wed, 14 Jan 2015 17:09:09 +0100
Subject: --passphrase and command line
In-Reply-To: <loom.20150114T153246-949@post.gmane.org> (hymie!'s message of
 "Wed, 14 Jan 2015 14:39:24 +0000 (UTC)")
References: <loom.20150114T153246-949@post.gmane.org>
Message-ID: <8761c94a56.fsf@vigenere.g10code.de>

On Wed, 14 Jan 2015 15:39, hymie at lactose.homelinux.net said:

> Can this feature be added to the "--passphrase" option of gpg?  It's my

No!

The only reason to use --passphrase is for symmetric encryption and for
regression tests.  For the former --passphrase-file and --passphrase-fd
is what you actually want to use.

If you do public key decryption/signing there is no need for a
passphrase - just do not set one for your key.  It is useless and only
needed by check mark style security policies [1].


Shalom-Salam,

   Werner



[1] Something like this ;-):

  [ ] Machine case has no sharp edges
  [ ] Admin knows how to power on the server
  [ ] Admin knows how to escalate problems
  [ ] Password has at least 8 characters and includes a digit
  [ ] Password does not match user name
  [ ] Certificate makes the address bar green
  [ ] Some key size is at least 2048
  [ ] Audit done by 600 EUR/h consultant
  [ ] T?V badge has not expired
  [ ] Passwords are used to protect all keys

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



From wk at gnupg.org  Wed Jan 14 17:16:14 2015
From: wk at gnupg.org (Werner Koch)
Date: Wed, 14 Jan 2015 17:16:14 +0100
Subject: Hang in scdaemon or pcsc-wrapper on Yosemite
In-Reply-To: <53B1D16B-0A47-46F5-8550-A6B3CFF80908@gpgtools.org> (Lukas
 Pitschl's message of "Wed, 14 Jan 2015 12:42:41 +0100")
References: <53B1D16B-0A47-46F5-8550-A6B3CFF80908@gpgtools.org>
Message-ID: <871tmx49td.fsf@vigenere.g10code.de>

On Wed, 14 Jan 2015 12:42, lukele at gpgtools.org said:

> In order to find out what?s going on we were trying to connect to a
> debug build of scdaemon and pcsc-wrapper. Unfortunately though,as soon
> as the debugger is connected, scdaemon as well as the pcsc-wrapper
> exit due to a SIGPIPE signal.

scdaemon can't die due to a SIGPIPE because the handler has been set to
SIG_IGN.  pcsc-wrapper may die though.

I assume your problem is with the pth library.  Note that pth uses a
signal for its own (IIRC, SIGUSR2) and thus you need to tell the
debugger to pass that signal through.   Some debuggers have problems
with pth; gdb works fine.

> Also if anyone knows what might lead to a hang in scdaemon, that
> information would be very valuable as well.

Use strace/truss etc to debug such problems.


Salam-Shalom,

   Werner

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



From hymie at lactose.homelinux.net  Wed Jan 14 17:23:55 2015
From: hymie at lactose.homelinux.net (hymie!)
Date: Wed, 14 Jan 2015 16:23:55 +0000 (UTC)
Subject: --passphrase and command line
References: <loom.20150114T153246-949@post.gmane.org>
 <8761c94a56.fsf@vigenere.g10code.de>
Message-ID: <loom.20150114T171524-672@post.gmane.org>

Can you please expand on your answer?

Werner Koch <wk <at> gnupg.org> writes:
> On Wed, 14 Jan 2015 15:39, hymie <at> lactose.homelinux.net said:
> 
> > Can this feature be added to the "--passphrase" option of gpg?  It's my
> 
> No!
> 
> The only reason to use --passphrase is for symmetric encryption and for
> regression tests.

I'm intrigued by your claim that this is "the only reason".  I'm sure that
some people can think of other reasons.

> For the former --passphrase-file and --passphrase-fd
> is what you actually want to use.

You are claiming that writing my key to a file on my disk is more secure?

I agree that --passphrase-fd is probably the best option.  In my particular
use-case, it comes with an unfortunate side-effect that I'm hoping to avoid.

> If you do public key decryption/signing there is no need for a
> passphrase - just do not set one for your key.  It is useless and only
> needed by check mark style security policies [1].

I'm sorry... "Don't set a passphrase on my key" ?  How is that possibly a
good idea?

--hymie!



From dkg at fifthhorseman.net  Wed Jan 14 18:56:17 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 14 Jan 2015 12:56:17 -0500
Subject: git://git.gnupg.org is down?
Message-ID: <87wq4p456m.fsf@alice.fifthhorseman.net>

Is the git daemon at git.gnupg.org currently offline?

0 $ git clone git://git.gnupg.org/gnupg.git
Cloning into 'gnupg'...
fatal: read error: Connection reset by peer
128 $ 

    --dkg


From git at internot.info  Wed Jan 14 19:04:32 2015
From: git at internot.info (Joshua Rogers)
Date: Thu, 15 Jan 2015 05:04:32 +1100
Subject: git://git.gnupg.org is down?
In-Reply-To: <87wq4p456m.fsf@alice.fifthhorseman.net>
References: <87wq4p456m.fsf@alice.fifthhorseman.net>
Message-ID: <54B6AFB0.2040801@internot.info>

On 15/01/15 04:56, Daniel Kahn Gillmor wrote:
> Is the git daemon at git.gnupg.org currently offline?
Yes. Same from Australia, and Romania.

# git clone git://git.gnupg.org/gnupg.git
Cloning into 'gnupg'...
fatal: read error: Connection reset by peer
128 0j

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=summary is up,
which is weird, I think. Unless there's some cacheing going on. I don't
know how gitweb works.


Thanks,
-- 
-- Joshua Rogers <https://internot.info/>

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

From dkg at fifthhorseman.net  Wed Jan 14 19:24:11 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 14 Jan 2015 13:24:11 -0500
Subject: [PATCH] Re: --passphrase and command line
In-Reply-To: <8761c94a56.fsf@vigenere.g10code.de>
References: <loom.20150114T153246-949@post.gmane.org>
 <8761c94a56.fsf@vigenere.g10code.de>
Message-ID: <87vbk943w4.fsf@alice.fifthhorseman.net>

On Wed 2015-01-14 11:09:09 -0500, Werner Koch wrote:
> On Wed, 14 Jan 2015 15:39, hymie at lactose.homelinux.net said:
>
>> Can this feature be added to the "--passphrase" option of gpg?  It's my
>
> No!

going from "gpg --passphrase password" to "gpg --passphrase xxxxxxxx" in
the process table in a C program is usually done by writing to the
contents of main()'s argv argument.

It's clear to me that this rewrite of the process table isn't fully
safe, for a number of reasons, including at least:

 0) There are some operating systems where writing to argv doesn't
    change how the process appears in the process table.

 1) Even on OSes where this is possible, there is still a window of time
    between when the process starts and when it manages to rewrite
    argv.  Anyone reading the process table at that time can see the
    original data.

 2) it still leaks the length of the password, since there is one x per
    character.

However, the fact that this is not perfectly safe does not mean that gpg
should necessarily avoid the practice (--passphrase itself isn't
perfectly safe, and we don't avoid it).

Put more positively, maybe it's worth considering taking this step for
gpg in spite of its various failure modes.  having extra insecurity
everywhere seems marginally worse.

It would be bad if this encouraged the use of the --passphrase option
*anywhere*, though, since it really is the worst way to use the tools.

Anyway, if this is desirable, the following patch (tested only on Debian
GNU/Linux) provides this minor/dubious improvement:

diff --git a/g10/gpg.c b/g10/gpg.c
index 12fe7b2..589d6c8 100644
--- a/g10/gpg.c
+++ b/g10/gpg.c
@@ -2713,6 +2713,11 @@ main (int argc, char **argv)
 	  case oBZ2DecompressLowmem: opt.bz2_decompress_lowmem=1; break;
 	  case oPassphrase:
 	    set_passphrase_from_string(pargs.r.ret_str);
+            {
+              size_t i, l = strlen(pargs.r.ret_str);
+              for (i=0; i < l; i++)
+                pargs.r.ret_str[i] = 'x';
+            }
 	    break;
 	  case oPassphraseFD:
             pwfd = translate_sys2libc_fd_int (pargs.r.ret_int, 0);


hth,

             --dkg


From wk at gnupg.org  Wed Jan 14 20:34:18 2015
From: wk at gnupg.org (Werner Koch)
Date: Wed, 14 Jan 2015 20:34:18 +0100
Subject: --passphrase and command line
In-Reply-To: <loom.20150114T171524-672@post.gmane.org> (hymie!'s message of
 "Wed, 14 Jan 2015 16:23:55 +0000 (UTC)")
References: <loom.20150114T153246-949@post.gmane.org>
 <8761c94a56.fsf@vigenere.g10code.de>
 <loom.20150114T171524-672@post.gmane.org>
Message-ID: <87iog92m2t.fsf@vigenere.g10code.de>

On Wed, 14 Jan 2015 17:23, hymie at lactose.homelinux.net said:

> I'm intrigued by your claim that this is "the only reason".  I'm sure that
> some people can think of other reasons.

Putting the passphrase on the command line and assuming that this can be
hidden by gpg is false assumption.  The passphrase ends up at a lot of
places - in the shell's memory, in ~/.bash_history, in audit logs, and
so on.

Well, if your write a tool where you retrieve the passpharse from
/dev/somwhere after the fork and before the exec you can make it a bit
more secure.  Hwoever, having already hacked up such code it is similar
easy to use --passphrase-{fd,file}

Slowing down another user's process is easy enough to see the passphrase
before it has been overwritten by gpg.

> You are claiming that writing my key to a file on my disk is more secure?

Yes, Unix has a permssion system which allows you to secure the file
against being accessed by other users.  You can't protect the process
environment in the same way.

> I'm sorry... "Don't set a passphrase on my key" ?  How is that possibly a
> good idea?

Why do you need a passpharse stored somewhere on your system to protect
a key stored somewhere on the system?  As easy as it is to read the key,
as easy it is to read the passphrase.


Shalom-Salam,

   Werner

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



From wk at gnupg.org  Wed Jan 14 21:11:15 2015
From: wk at gnupg.org (Werner Koch)
Date: Wed, 14 Jan 2015 21:11:15 +0100
Subject: git://git.gnupg.org is down?
In-Reply-To: <54B6AFB0.2040801@internot.info> (Joshua Rogers's message of
 "Thu, 15 Jan 2015 05:04:32 +1100")
References: <87wq4p456m.fsf@alice.fifthhorseman.net>
 <54B6AFB0.2040801@internot.info>
Message-ID: <87egqx2kd8.fsf@vigenere.g10code.de>

On Wed, 14 Jan 2015 19:04, git at internot.info said:
> On 15/01/15 04:56, Daniel Kahn Gillmor wrote:
>> Is the git daemon at git.gnupg.org currently offline?
> Yes. Same from Australia, and Romania.

Are you using IPv6 ?  

I added the AAAA record yesterday but forgot to add another --listen to
git-daemon.  I checked from two v6 sites and one v4 and it works for me
now.


Salam-Shalom,

   Werner

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



From dkg at fifthhorseman.net  Wed Jan 14 21:57:54 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 14 Jan 2015 15:57:54 -0500
Subject: git://git.gnupg.org is down?
In-Reply-To: <87egqx2kd8.fsf@vigenere.g10code.de>
References: <87wq4p456m.fsf@alice.fifthhorseman.net>
 <54B6AFB0.2040801@internot.info> <87egqx2kd8.fsf@vigenere.g10code.de>
Message-ID: <87y4p52i7h.fsf@alice.fifthhorseman.net>

On Wed 2015-01-14 15:11:15 -0500, Werner Koch wrote:
> On Wed, 14 Jan 2015 19:04, git at internot.info said:
>> On 15/01/15 04:56, Daniel Kahn Gillmor wrote:
>>> Is the git daemon at git.gnupg.org currently offline?
>> Yes. Same from Australia, and Romania.
>
> Are you using IPv6 ?  
>
> I added the AAAA record yesterday but forgot to add another --listen to
> git-daemon.  I checked from two v6 sites and one v4 and it works for me
> now.

works for me now too.  Maybe just the restart was all it needed?

thanks for the fix, Werner.

      --dkg


From hymie at lactose.homelinux.net  Thu Jan 15 13:33:28 2015
From: hymie at lactose.homelinux.net (hymie!)
Date: Thu, 15 Jan 2015 12:33:28 +0000 (UTC)
Subject: --passphrase and command line
References: <loom.20150114T153246-949@post.gmane.org>
 <8761c94a56.fsf@vigenere.g10code.de>
 <loom.20150114T171524-672@post.gmane.org>
 <87iog92m2t.fsf@vigenere.g10code.de>
Message-ID: <m98c2o$8ui$1@ger.gmane.org>

In our last episode, the evil Dr. Lacto had captured our hero,
  Werner Koch <wk at gnupg.org>, who said:
>On Wed, 14 Jan 2015 17:23, hymie at lactose.homelinux.net said:
>
>> I'm sorry... "Don't set a passphrase on my key" ?  How is that possibly a
>> good idea?
>
>Why do you need a passpharse stored somewhere on your system to protect
>a key stored somewhere on the system?  As easy as it is to read the key,
>as easy it is to read the passphrase.

Ah, OK.  I'm confused because you're making assumptions because I was
trying not to be overly verbose.

My preferred vi clone ("vile") has macros to encrypt, decrypt, and
clearsign buffers.   Part of this macro is to ask the user to type in
the key passpharse, which is then passed to the gpg2 command.
Unfortunately, the method this macro uses is to add the passphrase into
the buffer itself, then use this line (containing only the passphrase)
as "stdin" for an external command "gpg2 blah blah --passphrase-fd 0".

This has two unfortunate side effects:
1. I can sometimes see the passphrase when it is briefly added to the buffer
2. If I "undo" the last command (sign), the passphrase is left in the buffer

I was hoping to see if I could adjust the macro to use a command-line
passphrase instead, which would resolve both side effects.  It worked
correctly, except for the "ps" problem that I originally described.

I'm not storing the passphrase anywhere.  I'm typing it on demand into
a macro that is then going to put it into a command.  The question is,
"What is the most secure way that I can do this?"  I suppose a temp file
could work, but I don't like the idea of having the passphrase written to
the disk.  A temp file on a ram disk would be better, but I don't currently
have any ram disks set up.  I could depend on the gpg-agent and pinentry,
as long as my X client is running properly and reasonably securely.  But
I'm still thinking that --passphrase is the best compromise between
reasonably secure and reasonably portable.

--hymie!    http://lactose.homelinux.net/~hymie    hymie at lactose.homelinux.net



From hymie at lactose.homelinux.net  Thu Jan 15 13:39:06 2015
From: hymie at lactose.homelinux.net (hymie!)
Date: Thu, 15 Jan 2015 12:39:06 +0000 (UTC)
Subject: [PATCH] Re: --passphrase and command line
References: <loom.20150114T153246-949@post.gmane.org>
 <8761c94a56.fsf@vigenere.g10code.de> <87vbk943w4.fsf@alice.fifthhorseman.net>
Message-ID: <m98cda$8ui$2@ger.gmane.org>

Thanks for the patch.  If nothing else, it's something to play with.

In our last episode, the evil Dr. Lacto had captured our hero,
  Daniel Kahn Gillmor <dkg at fifthhorseman.net>, who said:
> 2) it still leaks the length of the password, since there is one x per
>    character.

Being only an amateur programmer, I wonder if you could free the
existing pointer and replace it with a char[6] and always have a
"xxxxx" as the replacement string.

I see from the patch below that you aren't accessing argv itself,
so I don't know if that's feasible or not.  Just an idea.

>It would be bad if this encouraged the use of the --passphrase option
>*anywhere*, though, since it really is the worst way to use the tools.

Worse than not using them at all?

--hymie!

>diff --git a/g10/gpg.c b/g10/gpg.c
>index 12fe7b2..589d6c8 100644
>--- a/g10/gpg.c
>+++ b/g10/gpg.c
>@@ -2713,6 +2713,11 @@ main (int argc, char **argv)
> 	  case oBZ2DecompressLowmem: opt.bz2_decompress_lowmem=1; break;
> 	  case oPassphrase:
> 	    set_passphrase_from_string(pargs.r.ret_str);
>+            {
>+              size_t i, l = strlen(pargs.r.ret_str);
>+              for (i=0; i < l; i++)
>+                pargs.r.ret_str[i] = 'x';
>+            }
> 	    break;
> 	  case oPassphraseFD:
>             pwfd = translate_sys2libc_fd_int (pargs.r.ret_int, 0);
>



From milan.kral at azet.sk  Thu Jan 15 12:54:58 2015
From: milan.kral at azet.sk (Milan Kral)
Date: Thu, 15 Jan 2015 12:54:58 +0100
Subject: Beyond Curve25519
Message-ID: <54B7AA92.5070505@azet.sk>

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

Hi,
the security of Curve25519 is about 2^125. Are there plans to implement
stronger ECC in GnuPG? Good candidate would be E-521, it's one of the
recommended curves on http://safecurves.cr.yp.to/

https://eprint.iacr.org/2013/647.pdf

Kind regards,
Milan
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJUt6qSXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxQUY0RDVDMjhBOEQ2RkM3RjEwOUI1MzQ5
QzIzRDIwRkJGNTk0NTFFAAoJEJwj0g+/WUUeM/cQAJ4/+f/nDutJbmwD2A3WJGpY
ECz4G2X4VdWpJTZBzf4smQxC5IT04ochlE9j2rVtwdGpjzqLf7t+vGkhe7Jvp4jG
q1qj9//Ssvx3bSXBP9j+mogC/O6c+c+7Yb1GGqCCp+U7iXAJmezZZvkVVUlBzNHf
RT8VCz9K2tRMrVJ1uqBz0LveR/P9Tlq76vInuQyhUHTYY4vTvft+vElv0f1NsMPW
YsIx/eXJpI+qaPiWbQVkpJHZb9i6DsXYWls04AgH5rKnpwFulUYdlUJFsBXFUxlR
EAFGknugV0xMTgq7CfTJS9Auqhs9uMyo/CfG2nskxJ2jdHEg6tkRCKnepyTToEwe
gCmx0ZnflseWPriNdv3dLF3tFNJr4d32Rs/PCnzVHcdjvauy5epemHR+7dNCfAmT
UyjVhZddJCZsuw4c+ytkrrE5wLcgcJCkGnJpHGaIAEypq2xu3VZM+a0AMdywOvbq
fpoH2P9iwZZ84YY3H7p6EBnI4ksJOPr2/eqs2OKF6kPfcKmlzWiCXBNKg6sGNWfa
G4apE+wnG8qKbKBveTz/wLMWdUv02vSHSiFkOYqNFCGtaV2XZ6LQLY6w5QOOXKLO
d1XiOtPISjAINqxxB/wt8Io/oPppjgJ2LdA0g2tF6C5db6W8qKjT2zxk5ZnXYWJj
CAsZtpEgBIGBiKtB+unA
=RVo+
-----END PGP SIGNATURE-----


From wk at gnupg.org  Thu Jan 15 15:31:13 2015
From: wk at gnupg.org (Werner Koch)
Date: Thu, 15 Jan 2015 15:31:13 +0100
Subject: --passphrase and command line
In-Reply-To: <m98c2o$8ui$1@ger.gmane.org> (hymie!'s message of "Thu, 15 Jan
 2015 12:33:28 +0000 (UTC)")
References: <loom.20150114T153246-949@post.gmane.org>
 <8761c94a56.fsf@vigenere.g10code.de>
 <loom.20150114T171524-672@post.gmane.org>
 <87iog92m2t.fsf@vigenere.g10code.de> <m98c2o$8ui$1@ger.gmane.org>
Message-ID: <877fwo15fy.fsf@vigenere.g10code.de>

On Thu, 15 Jan 2015 13:33, hymie at lactose.homelinux.net said:

> My preferred vi clone ("vile") has macros to encrypt, decrypt, and
> clearsign buffers.   Part of this macro is to ask the user to type in
> the key passpharse, which is then passed to the gpg2 command.

Do you have any problem to use the ncurses based Pinentry?  If you do
not have the DISPLAY envvar set, the standard pinentries fallback to the
curses mode.  The only thing you may need to do is to redraw the screen
in some cases.  That can be easily done with C-L or by adding an
appropriate command to the macro.   In case you are using screen(1)
there are also ways to lock the Pinentry to one screen.


Salam-Shalom,

   Werner

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



From dkg at fifthhorseman.net  Thu Jan 15 20:44:04 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 15 Jan 2015 14:44:04 -0500
Subject: [PATCH] Re: --passphrase and command line
In-Reply-To: <m98cda$8ui$2@ger.gmane.org>
References: <loom.20150114T153246-949@post.gmane.org>
 <8761c94a56.fsf@vigenere.g10code.de> <87vbk943w4.fsf@alice.fifthhorseman.net>
 <m98cda$8ui$2@ger.gmane.org>
Message-ID: <87mw5j3k3f.fsf@alice.fifthhorseman.net>

On Thu 2015-01-15 07:39:06 -0500, hymie! wrote:
> Being only an amateur programmer, I wonder if you could free the
> existing pointer and replace it with a char[6] and always have a
> "xxxxx" as the replacement string.

free()ing something that was not malloc()ed is a bad idea :)  and i
believe the process table explicitly shows exactly the memory that is
already pointed to by the pointers in argv; resetting those pointers to
point somewhere else shouldn't have the same effect.

> I see from the patch below that you aren't accessing argv itself,
> so I don't know if that's feasible or not.  Just an idea.

it is actually accessing the data pointed to by the pointers referred to
by argv (whew, indirection!), but not argv itself.

>>It would be bad if this encouraged the use of the --passphrase option
>>*anywhere*, though, since it really is the worst way to use the tools.
>
> Worse than not using them at all?

if you're really at that stage, i guess it's better than nothing; but
given the scenario you're working on, Werner's suggestion of
pinentry-curses sounds much better to me than anything else proposed in
this thread so far.

using pinentry-curses would mean that vi (and your plugin) never even
need to see the user's passphrase.  This is a win -- less data for you
to manage, and less of a chance for the sensitive info to leak into
other parts of the OS.

     --dkg


From dkg at fifthhorseman.net  Thu Jan 15 20:49:38 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 15 Jan 2015 14:49:38 -0500
Subject: Beyond Curve25519
In-Reply-To: <54B7AA92.5070505@azet.sk>
References: <54B7AA92.5070505@azet.sk>
Message-ID: <87egqv3ju5.fsf@alice.fifthhorseman.net>

On Thu 2015-01-15 06:54:58 -0500, Milan Kral wrote:
> the security of Curve25519 is about 2^125. Are there plans to implement
> stronger ECC in GnuPG? Good candidate would be E-521, it's one of the
> recommended curves on http://safecurves.cr.yp.to/
>
> https://eprint.iacr.org/2013/647.pdf

The only stronger curves available in GnuPG at the moment are the NIST
curves.  I agree that E-521 would be a reasonable choice for a
high-strength curve, but i don't think anyone has specified or
implemented it yet for OpenPGP.

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

From hanno at hboeck.de  Thu Jan 15 21:53:33 2015
From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=)
Date: Thu, 15 Jan 2015 21:53:33 +0100
Subject: Beyond Curve25519
In-Reply-To: <54B7AA92.5070505@azet.sk>
References: <54B7AA92.5070505@azet.sk>
Message-ID: <20150115215333.03d707f6@pc>

On Thu, 15 Jan 2015 12:54:58 +0100
Milan Kral <milan.kral at azet.sk> wrote:

> the security of Curve25519 is about 2^125. Are there plans to
> implement stronger ECC in GnuPG? Good candidate would be E-521, it's
> one of the recommended curves on http://safecurves.cr.yp.to/

I find the search for "better than curve25119 curves" quite
questionable.

If you're really looking for something stronger you likely want
something post-quantum. However the trouble with post quantum is that
right now nobody really has any confidence in any of the algorithms.
But people work on that, there's been some nice progress lately.

Realistically: Nobody is every going to break 128 bit security level.
When curve25519 breaks it'll very likely be because of quantum
computers. But then e-521 will only provide very little extra
security.



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

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

From dkg at fifthhorseman.net  Thu Jan 15 23:10:19 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 15 Jan 2015 17:10:19 -0500
Subject: Beyond Curve25519
In-Reply-To: <20150115215333.03d707f6@pc>
References: <54B7AA92.5070505@azet.sk> <20150115215333.03d707f6@pc>
Message-ID: <87ppaf1yr8.fsf@alice.fifthhorseman.net>

On Thu 2015-01-15 15:53:33 -0500, Hanno B?ck wrote:

> I find the search for "better than curve25119 curves" quite
> questionable.
>
> If you're really looking for something stronger you likely want
> something post-quantum. However the trouble with post quantum is that
> right now nobody really has any confidence in any of the algorithms.
> But people work on that, there's been some nice progress lately.
>
> Realistically: Nobody is every going to break 128 bit security level.
> When curve25519 breaks it'll very likely be because of quantum
> computers. But then e-521 will only provide very little extra
> security.

I'm not convinced by this argument.  It seems to assume that all
possible non-quantum mathematical advances in elliptic curve
cryptanalysis have already been published.

It's conceivable that there are other cryptanalysis techniques that are
known privately, or that will become known in the years before quantum
computers are actually feasible for real-world problems.  In those
scenarios, effective cryptanalysis will offer a work reduction beyond
the 128-bit security level, but we don't know how much.

It's also possible that quantum machinery becomes feasible for solving
problems of a certain size, but engineering constraints prohibit
constructing a machine with enough qubits to solve larger problems for
several more years.

In either scenario, having a larger curve with a higher security margin
gives a buffer against these currently-unknown attacks.

This is all tea-leaf reading, and seat-of-the-pants flights of fancy --
we don't actually know what the future will hold.  But it seems at least
plausible to me that some advance will be made that put 256-bit curves
into the "dubious" zone without entirely destroying elliptic curve
crypto.

And e-521 should still be far and away cheaper than rsa-2048 for secret
key operations, which are used widely today, while having a *much*
higher security margin.

       --dkg


From lists-gnupgdev at lina.inka.de  Thu Jan 15 23:01:10 2015
From: lists-gnupgdev at lina.inka.de (lists-gnupgdev at lina.inka.de)
Date: Thu, 15 Jan 2015 23:01:10 +0100
Subject: Beyond Curve25519
In-Reply-To: <20150115215333.03d707f6@pc>
References: <54B7AA92.5070505@azet.sk>
 <20150115215333.03d707f6@pc>
Message-ID: <20150115230110.0000013f.lists-gnupgdev@lina.inka.de>

Am Thu, 15 Jan 2015 21:53:33 +0100
schrieb Hanno B?ck <hanno at hboeck.de>:

> On Thu, 15 Jan 2015 12:54:58 +0100
> Milan Kral <milan.kral at azet.sk> wrote:
> 
> > the security of Curve25519 is about 2^125. Are there plans to
> > implement stronger ECC in GnuPG? Good candidate would be E-521, it's
> > one of the recommended curves on http://safecurves.cr.yp.to/
> 
> I find the search for "better than curve25119 curves" quite
> questionable.

I wish we had Curve 25519 and EdDSA with Ed25519 in OpenPGP, then we
can go on with other safe curves. Why are the RFCs  all so NIST
heavy?

Gruss
Bernd


From kristian.fiskerstrand at sumptuouscapital.com  Thu Jan 15 23:50:30 2015
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Thu, 15 Jan 2015 23:50:30 +0100
Subject: Beyond Curve25519
In-Reply-To: <20150115230110.0000013f.lists-gnupgdev@lina.inka.de>
References: <54B7AA92.5070505@azet.sk> <20150115215333.03d707f6@pc>
 <20150115230110.0000013f.lists-gnupgdev@lina.inka.de>
Message-ID: <54B84436.3050408@sumptuouscapital.com>

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

On 01/15/2015 11:01 PM, lists-gnupgdev at lina.inka.de wrote:
> Am Thu, 15 Jan 2015 21:53:33 +0100 schrieb Hanno B?ck
> <hanno at hboeck.de>:
> 
>> On Thu, 15 Jan 2015 12:54:58 +0100 Milan Kral
>> <milan.kral at azet.sk> wrote:
>> 
>>> the security of Curve25519 is about 2^125. Are there plans to 
>>> implement stronger ECC in GnuPG? Good candidate would be E-521,
>>> it's one of the recommended curves on
>>> http://safecurves.cr.yp.to/
>> 
>> I find the search for "better than curve25119 curves" quite 
>> questionable.
> 
> I wish we had Curve 25519 and EdDSA with Ed25519 in OpenPGP, then
> we can go on with other safe curves. Why are the RFCs  all so NIST 
> heavy?
> 

http://www.ietf.org/id/draft-koch-eddsa-for-openpgp-01.txt , but it
isn't yet approved or IANA assigned for algoid 22. It is included in
gnupg 2.1 and supported in the development branch of SKS though

- -- 
- ----------------------------
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
- ----------------------------
Vincit qui se vincit
He who conquers conquers self
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUuEQ1AAoJEPw7F94F4Tagkq8P/3aSJ33eCRdjeX4Yg3HUwVa9
Y1lVQ7BcGxmgM6hXcGjxejQPTRNO7nHDf6ksZrTq6NBM5iu9Mrhb3ECGzXo397+x
RyWOp7D87S6QrASjyqEHl0M2nuaNJzGbVGSUNxMFNFad/PbbPrs7dWt87u0EmZ38
+jRM3clKDD53rBUJ6MN2Q54ICSnNqsR1GUSvEIA8HR+9ZaK7jiu6Np4zzNjshNEf
0xwkpGP5hzdeDFt24qx4bdmvI64+TWx7G+GoscfoNBPV+IG9sM4dL/L4VIjEXdbe
ohT0ex73kxErNFpZYGkA1e0BEowsdMGn/fR8qmRsWwy6rKhFDQxK1AfWcBBt0dge
/kYFm/OIvsFVMdjki4wJmbAhplwt9llgPxa+qWN5xOSBCi1SxFn79RxYYQ3YofXw
kCjbFBj5FGykn10mv3v/IX4+4lDM/UGnv+5MXStxLqd2mR9zctEvCJE8I6QaNZ9O
8nO9lNdsznDJAcDGvhcMr7Wi1gKz2ti0sfuYJe+3RM2guVznDgIaotMrmr7pN7j9
bzv032HIUS6Cb68INTr2pEpNzzC/FRERkWDecRN+FE+6r2s1J5B5N4hoz6TMG2p9
3iVW11fPJzXNi3xLw1KhlqQ1k4RrY3Aw23KD7elPr9WffkGZBWIltqPoRNcxN8EU
0NgYyElTxbU3Twwk1L4B
=fMgp
-----END PGP SIGNATURE-----


From hanno at hboeck.de  Fri Jan 16 00:15:08 2015
From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=)
Date: Fri, 16 Jan 2015 00:15:08 +0100
Subject: Beyond Curve25519
In-Reply-To: <87ppaf1yr8.fsf@alice.fifthhorseman.net>
References: <54B7AA92.5070505@azet.sk> <20150115215333.03d707f6@pc>
 <87ppaf1yr8.fsf@alice.fifthhorseman.net>
Message-ID: <20150116001508.2798f36d@pc>

On Thu, 15 Jan 2015 17:10:19 -0500
Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:

> I'm not convinced by this argument.  It seems to assume that all
> possible non-quantum mathematical advances in elliptic curve
> cryptanalysis have already been published.

Well, it assumes at least that there will be no "really big unexpected
breakthroughs". To get from 128 bit to breakable requires attacks
achieving a security reduction of at least around 40-50 bits. That's a
lot.

> It's also possible that quantum machinery becomes feasible for solving
> problems of a certain size, but engineering constraints prohibit
> constructing a machine with enough qubits to solve larger problems for
> several more years.

That's an interesting line of reasoning, because if you follow it you'd
increase your key size as much as feasible. That means however stay
away from elliptic curves - and use rsa 4096 or more.

However I have discussed this with a couple of people. The usual
opinion in the post-quantum-discussion seems to be that this is not
going to happen. Once qc becomes scalable it'll scale up easily.

> In either scenario, having a larger curve with a higher security
> margin gives a buffer against these currently-unknown attacks.

If I really would want a security buffer against very unlikely future
attacks I'd rather combine different PK algs in a secure way.
I found the ring learning with errors talk on RWC interesting in that
regard that they try to combine ecdh with their new key exchange.

> And e-521 should still be far and away cheaper than rsa-2048 for
> secret key operations, which are used widely today, while having a
> *much* higher security margin.

As said above:
This is only true in the non-quantum-setting.

For gpg generally I'd assume performance really doesn't matter that
much.

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

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

From buanzo at buanzo.com.ar  Fri Jan 16 02:57:06 2015
From: buanzo at buanzo.com.ar (Arturo 'Buanzo' Busleiman)
Date: Thu, 15 Jan 2015 22:57:06 -0300
Subject: Beyond Curve25519
In-Reply-To: <87egqv3ju5.fsf@alice.fifthhorseman.net>
References: <54B7AA92.5070505@azet.sk> <87egqv3ju5.fsf@alice.fifthhorseman.net>
Message-ID: <CAAcS2GomJWHrndVbR9=cqxNyC45071Ha2=7xGTvbWPRM=tFyrQ@mail.gmail.com>

Only the NIST curves? Then there is a real need to implement others I would
imagine, considering?
On Jan 15, 2015 4:49 PM, "Daniel Kahn Gillmor" <dkg at fifthhorseman.net>
wrote:

> On Thu 2015-01-15 06:54:58 -0500, Milan Kral wrote:
> > the security of Curve25519 is about 2^125. Are there plans to implement
> > stronger ECC in GnuPG? Good candidate would be E-521, it's one of the
> > recommended curves on http://safecurves.cr.yp.to/
> >
> > https://eprint.iacr.org/2013/647.pdf
>
> The only stronger curves available in GnuPG at the moment are the NIST
> curves.  I agree that E-521 would be a reasonable choice for a
> high-strength curve, but i don't think anyone has specified or
> implemented it yet for OpenPGP.
>
>             --dkg
>
> _______________________________________________
> 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/20150115/4725e20f/attachment.html>

From calestyo at scientia.net  Fri Jan 16 05:46:57 2015
From: calestyo at scientia.net (Christoph Anton Mitterer)
Date: Fri, 16 Jan 2015 05:46:57 +0100
Subject: Beyond Curve25519
In-Reply-To: <20150115215333.03d707f6@pc>
References: <54B7AA92.5070505@azet.sk> <20150115215333.03d707f6@pc>
Message-ID: <1421383617.4984.4.camel@scientia.net>

On Thu, 2015-01-15 at 21:53 +0100, Hanno B?ck wrote: 
> Realistically: Nobody is every going to break 128 bit security level.
> When curve25519 breaks it'll very likely be because of quantum
> computers. But then e-521 will only provide very little extra
> security.
Funny... people told that as well with RSA key sizes which are nowadays
no longer considered enough... o.O

It's really disturbing to read such statements (i.e. "xxx bit security
level will be secure forever - except for quantum computers)... it seems
as nothing would have been learned from the past :-/

So,... I'm looking forward to both, something stroner than Curve25519
and post-quantum.


Cheers,
Chris.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5313 bytes
Desc: not available
URL: </pipermail/attachments/20150116/2693dbc3/attachment.bin>

From wk at gnupg.org  Fri Jan 16 08:48:34 2015
From: wk at gnupg.org (Werner Koch)
Date: Fri, 16 Jan 2015 08:48:34 +0100
Subject: Beyond Curve25519
In-Reply-To: <20150115215333.03d707f6@pc> ("Hanno =?utf-8?Q?B=C3=B6ck=22's?=
 message of "Thu, 15 Jan 2015 21:53:33 +0100")
References: <54B7AA92.5070505@azet.sk> <20150115215333.03d707f6@pc>
Message-ID: <87mw5jyxm5.fsf@vigenere.g10code.de>

On Thu, 15 Jan 2015 21:53, hanno at hboeck.de said:

> I find the search for "better than curve25119 curves" quite
> questionable.

It is likely that Curve41417 will eventually be added.  However, we
first need to settle for a point compression format for Curve25519.
That is more important that a stronger curve.

> something post-quantum. However the trouble with post quantum is that
> right now nobody really has any confidence in any of the algorithms.

and that the large key size imposes parctical problems today. An
algorithm which can't be used with smart cards is not going to fly.


Shalom-Salam,

   Werner


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



From wk at gnupg.org  Fri Jan 16 08:51:59 2015
From: wk at gnupg.org (Werner Koch)
Date: Fri, 16 Jan 2015 08:51:59 +0100
Subject: Beyond Curve25519
In-Reply-To: <20150116001508.2798f36d@pc> ("Hanno =?utf-8?Q?B=C3=B6ck=22's?=
 message of "Fri, 16 Jan 2015 00:15:08 +0100")
References: <54B7AA92.5070505@azet.sk> <20150115215333.03d707f6@pc>
 <87ppaf1yr8.fsf@alice.fifthhorseman.net> <20150116001508.2798f36d@pc>
Message-ID: <87iog7yxgg.fsf@vigenere.g10code.de>

On Fri, 16 Jan 2015 00:15, hanno at hboeck.de said:

> For gpg generally I'd assume performance really doesn't matter that
> much.

Symmetric encryption performance is actually a problem because the CFB
mode of OpenPGP along with the SHA-1 MDC imposes a limit which could be
lifted by using a different encryption mode.


Salam-Shalom,

   Werner


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



From hanno at hboeck.de  Fri Jan 16 10:52:55 2015
From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=)
Date: Fri, 16 Jan 2015 10:52:55 +0100
Subject: Beyond Curve25519
In-Reply-To: <87mw5jyxm5.fsf@vigenere.g10code.de>
References: <54B7AA92.5070505@azet.sk> <20150115215333.03d707f6@pc>
 <87mw5jyxm5.fsf@vigenere.g10code.de>
Message-ID: <20150116105255.4086c17d@pc>

On Fri, 16 Jan 2015 08:48:34 +0100
Werner Koch <wk at gnupg.org> wrote:

> It is likely that Curve41417 will eventually be added.  However, we
> first need to settle for a point compression format for Curve25519.
> That is more important that a stronger curve.

From my observation of curve debates it seems to me right now that
E-521 has much more support behind it than curve41417. It follows
similar criteria but has been independently discovered by three
different teams afaik. (one of the teams being bernstein/lange, so it
follows the same security criteria as curve25519/curve41417).

Likely CFRG will also choose some larger curve at some point and that
will likely be E-521 and not Curve41417.

Probably makes sense to choose E-521. Or wait with whatever cfrg comes
up.

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

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

From hanno at hboeck.de  Fri Jan 16 13:43:24 2015
From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=)
Date: Fri, 16 Jan 2015 13:43:24 +0100
Subject: Encrypting / Signing the mail subject?
Message-ID: <20150116134324.6d918b4e@pc>

Hi,

I wanted to share some thoghts about a potential change to the PGP mail
format I had. I'm not sure if this is the right place to discuss this,
but afaik there is currently no active openpgp standards list at IETF
and gnupg is likely the only implementation in widespread use. I recall
that I have read something alike already somewhere sometime, however I
don't exactly remember in what context.

One of the things I find unfortunate about OpenPGP encryption is that
the subject of a mail is not encrypted and signed. This is imho very
bad from a usability point of view and also not really neccessary,
because there are ways this could work without changing too much about
the way pgp mails work.

What I have in mind is something like this: Whenever a PGP mail app
creates a mail it replaces the subject with a defined keyword. This
could be something trivial like "__ENCRYPTED_SUBJECT__". It then places
a Subject line inside the encrypted mail body. This is followed by two
newlines and then the real encrypted body of the mail follows.

A mail client supporting this format would then replace the
__ENCRYPTED_SUBJECT__ in the UI with the Subject from the body and it
would hide the Subject: ... and the two newlines from the UI display of
the mail body.

Doing this would provide some kind of backwards compatibility to old
clients. A client not supporting this mechanism would still be able to
read a mail. It would also show the subject as part of the encrypted
mail body. There would even be some compatibility in the other way. A
user aware of how this works could manually set the subject keyword and
the Subject in the mail body in a mail client not supporting this
mechanism.


There are some things that'd need consideration if such a mechanism
would be created:
* This would move the subject to the encrypted part of a message. A
mail client may decide that it needs some kind of caching of mail
subjects available, because it is not feasible to decrypt them on
demand, especially on large mailboxes. Therefore a client might move
data from the encrypted context to a nonencrypted storage. This is a
trade-off, but imho it is still a lot better than not encrypting the
subject at all.
* One would have to make a clear decision how the Subject is encoded to
avoid confusion and incompatibilities. Currently a subject with special
chars has some kind of utf8-prefix-encoding. A mail body has its own
encoding. One would have to decide if the subject encoding is just the
body encoding or if the same format as in the header is used. Technical
detail, but should be done right and should be unambigious.

So far my rough proposal.
What do people think about it? Is this the right place to discuss it?
If you like it do you think it should become a standard/RFC? Anyone
interested in impementing it in whatever mail client implementation?

(and to proove my point why this is desirable just see this mail by dkb
where he explains why it's bad to rely on subject information in the
mail content: http://seclists.org/oss-sec/2015/q1/137 )

cu, Hanno

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

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

From dave at wiredthing.com  Fri Jan 16 14:21:30 2015
From: dave at wiredthing.com (Dave English)
Date: Fri, 16 Jan 2015 13:21:30 +0000
Subject: Encrypting / Signing the mail subject?
In-Reply-To: <20150116134324.6d918b4e@pc>
References: <20150116134324.6d918b4e@pc>
Message-ID: <9A36C3F7-2EDE-4B32-930D-8957EBED32EE@wiredthing.com>

Hi Hanno

I have no real idea whether this is the right place to discuss this, myself.

But here goes:

I?m not sure there is a strong enough need, to justify a change.

At the moment there is a clear split between envelope & body.  Only what is in the body is signed and can be encrypted.  If you start to handle the Subject especially, then you blur the boundary.  That could lead to confusion about the handling of other headers.

Of course, not everyone has a technical view of the structure of an e-mail.  Many users will not have any concept of the envelope, witness use of Cc: versus Bcc: - but I would hope that a user knowledgeable enough to use signing or encryption has at least an idea of a distinction between body & the rest.

The more competent, at least, will always be free to include nothing sensitive or prone to subversion in their Subjects, as and when necessary.

There could be problems with trying to sign what is in the Subject header, some systems will change it, either truncating it because of technical limitations, or amending it, e.g. to tag suspected SPAM.  If the distinction between envelope & body were blurred then users might expect other headers to be protected & that would be problematic to implement.

As an aside, even a signed body presents an opportunity for abuse, because it can contain what is supposed to be the same message in alternative forms, text & html.  Some one can construct a mail with two different texts, albeit unrepudiatably, so that one viewer reads one signed version of what is said & another viewer reads something different.  I can?t see any easy fix to that, other than viewing with suspicion any multi-part.

Never the less - good luck with promoting your change, after all things rarely improve without it.

ATB

> On 16 Jan 2015, at 12:43, Hanno B?ck <hanno at hboeck.de> wrote:
> 
> Hi,
> 
> I wanted to share some thoghts about a potential change to the PGP mail
> format I had. I'm not sure if this is the right place to discuss this,
> but afaik there is currently no active openpgp standards list at IETF
> and gnupg is likely the only implementation in widespread use. I recall
> that I have read something alike already somewhere sometime, however I
> don't exactly remember in what context.
> 
> One of the things I find unfortunate about OpenPGP encryption is that
> the subject of a mail is not encrypted and signed. This is imho very
> bad from a usability point of view and also not really neccessary,
> because there are ways this could work without changing too much about
> the way pgp mails work.
> 
> What I have in mind is something like this: Whenever a PGP mail app
> creates a mail it replaces the subject with a defined keyword. This
> could be something trivial like "__ENCRYPTED_SUBJECT__". It then places
> a Subject line inside the encrypted mail body. This is followed by two
> newlines and then the real encrypted body of the mail follows.
> 
> A mail client supporting this format would then replace the
> __ENCRYPTED_SUBJECT__ in the UI with the Subject from the body and it
> would hide the Subject: ... and the two newlines from the UI display of
> the mail body.
> 
> Doing this would provide some kind of backwards compatibility to old
> clients. A client not supporting this mechanism would still be able to
> read a mail. It would also show the subject as part of the encrypted
> mail body. There would even be some compatibility in the other way. A
> user aware of how this works could manually set the subject keyword and
> the Subject in the mail body in a mail client not supporting this
> mechanism.
> 
> 
> There are some things that'd need consideration if such a mechanism
> would be created:
> * This would move the subject to the encrypted part of a message. A
> mail client may decide that it needs some kind of caching of mail
> subjects available, because it is not feasible to decrypt them on
> demand, especially on large mailboxes. Therefore a client might move
> data from the encrypted context to a nonencrypted storage. This is a
> trade-off, but imho it is still a lot better than not encrypting the
> subject at all.
> * One would have to make a clear decision how the Subject is encoded to
> avoid confusion and incompatibilities. Currently a subject with special
> chars has some kind of utf8-prefix-encoding. A mail body has its own
> encoding. One would have to decide if the subject encoding is just the
> body encoding or if the same format as in the header is used. Technical
> detail, but should be done right and should be unambigious.
> 
> So far my rough proposal.
> What do people think about it? Is this the right place to discuss it?
> If you like it do you think it should become a standard/RFC? Anyone
> interested in impementing it in whatever mail client implementation?
> 
> (and to proove my point why this is desirable just see this mail by dkb
> where he explains why it's bad to rely on subject information in the
> mail content: http://seclists.org/oss-sec/2015/q1/137 )
> 
> cu, Hanno
> 
> --
> Hanno B?ck
> http://hboeck.de/
> 
> mail/jabber: hanno at hboeck.de
> GPG: BBB51E42
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </pipermail/attachments/20150116/b9b0e5c4/attachment.sig>

From dgouttegattat at incenp.org  Fri Jan 16 16:56:35 2015
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Fri, 16 Jan 2015 16:56:35 +0100
Subject: [PATCH] kbx: Call skipfnc callback to filter out keys
Message-ID: <54B934B3.201@incenp.org>


* kbx/keybox-search.c (blob_get_keyid): New.
(keybox-search): Call skipfnc callback function.
--

This patch (tentatively) fixes
GnuPG-bug-id: 1794

The keybox_search function in kbx/keybox-search.c currently ignores the 
skipfnc callback, but the validate_key_list function in g10/trustdb.c 
uses such a callback to exclude ultimately trusted keys.

---
  kbx/keybox-search.c | 33 ++++++++++++++++++++++++++++++---
  1 file changed, 30 insertions(+), 3 deletions(-)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-kbx-Call-skipfnc-callback-to-filter-out-keys.patch
Type: text/x-patch
Size: 1450 bytes
Desc: not available
URL: </pipermail/attachments/20150116/06129370/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20150116/06129370/attachment.sig>

From patrick at enigmail.net  Fri Jan 16 17:41:27 2015
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Fri, 16 Jan 2015 17:41:27 +0100
Subject: Encrypting / Signing the mail subject?
In-Reply-To: <20150116134324.6d918b4e@pc>
References: <20150116134324.6d918b4e@pc>
Message-ID: <54B93F37.6060504@enigmail.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 16.01.15 13:43, Hanno B?ck wrote:
> Hi,
> 
> I wanted to share some thoghts about a potential change to the PGP mail
> format I had. I'm not sure if this is the right place to discuss this,
> but afaik there is currently no active openpgp standards list at IETF
> and gnupg is likely the only implementation in widespread use. I recall
> that I have read something alike already somewhere sometime, however I
> don't exactly remember in what context.
> 
> One of the things I find unfortunate about OpenPGP encryption is that
> the subject of a mail is not encrypted and signed. This is imho very
> bad from a usability point of view and also not really neccessary,
> because there are ways this could work without changing too much about
> the way pgp mails work.
> 
> What I have in mind is something like this: Whenever a PGP mail app
> creates a mail it replaces the subject with a defined keyword. This
> could be something trivial like "__ENCRYPTED_SUBJECT__". It then places
> a Subject line inside the encrypted mail body. This is followed by two
> newlines and then the real encrypted body of the mail follows.
> 
> A mail client supporting this format would then replace the
> __ENCRYPTED_SUBJECT__ in the UI with the Subject from the body and it
> would hide the Subject: ... and the two newlines from the UI display of
> the mail body.
> 
> Doing this would provide some kind of backwards compatibility to old
> clients. A client not supporting this mechanism would still be able to
> read a mail. It would also show the subject as part of the encrypted
> mail body. There would even be some compatibility in the other way. A
> user aware of how this works could manually set the subject keyword and
> the Subject in the mail body in a mail client not supporting this
> mechanism.
> 
> 
> There are some things that'd need consideration if such a mechanism
> would be created:
> * This would move the subject to the encrypted part of a message. A
> mail client may decide that it needs some kind of caching of mail
> subjects available, because it is not feasible to decrypt them on
> demand, especially on large mailboxes. Therefore a client might move
> data from the encrypted context to a nonencrypted storage. This is a
> trade-off, but imho it is still a lot better than not encrypting the
> subject at all.
> * One would have to make a clear decision how the Subject is encoded to
> avoid confusion and incompatibilities. Currently a subject with special
> chars has some kind of utf8-prefix-encoding. A mail body has its own
> encoding. One would have to decide if the subject encoding is just the
> body encoding or if the same format as in the header is used. Technical
> detail, but should be done right and should be unambigious.
> 
> So far my rough proposal.
> What do people think about it? Is this the right place to discuss it?
> If you like it do you think it should become a standard/RFC? Anyone
> interested in impementing it in whatever mail client implementation?

I get this feature request every now and then for Enigmail. I think that
encrypting the subject could prevent inexperienced users from leaking
information because they assume that the subject is encrypted.

However, my response is always the same: I would be willing to implement
this in Enigmail if and only if other mail clients would also implement
it and/or if this would be somehow standardized.

- -Patrick

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJUuT8yAAoJEMk25cDiHiw+N40H/2unTgG3DCm2DGWh1iSUXSsB
mpAQk5uhnab0kbWbsrFaMlwx49ibOh8GD1O9IuMIsNF1DDQCGqTVUcaK4ZXOTe73
cuvdaNUSP2eY7IlabAzObDZM4vCA3GU/IdRRJvmsd+cN2c/B81tduRitHgedt0mG
uctIo+44tZGRPGkDnIpFR7Dxh0OIr0BnBQvlb2WvBdOjRt5OXTZilbBw3ibnSUai
+MntQ51Z4yO/yf8mSCv2OFBZiQU9DQtQFuDZT12gCAT70rqC20F19LvpZ2qwH5GU
lcQ3SkyMKcSE+i5uVXruIfFh8UD7As6kmXKDOGgTpwPr8X3136UjsQB6U6087aU=
=7MzY
-----END PGP SIGNATURE-----


From rjh at sixdemonbag.org  Fri Jan 16 18:12:40 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Fri, 16 Jan 2015 12:12:40 -0500
Subject: REPTILE WISDOM
In-Reply-To: <20150116134324.6d918b4e@pc>
References: <20150116134324.6d918b4e@pc>
Message-ID: <54B94688.2020206@sixdemonbag.org>

> One of the things I find unfortunate about OpenPGP encryption is that
> the subject of a mail is not encrypted and signed.

This is a total nonissue.  Give each new thread a nonsensical name:
STEEL CAMELLIA, ARGENT LUNACY, NEPAL SUNSET, and so forth.  The actual
contents of a subject line are rarely of interest: rather, what's of
interest is that one message belongs to the same thread as another
message, and for that purpose a randomly-chosen identifier works quite
well.  To demonstrate this, I've changed the subject line of this email:
I think you'll find it's very easy to keep threading and so forth
intact, despite the fact the subject line is now content-free.

If your subject lines are sensitive material, then you're doing it wrong.

Further, the entire reason why the subject lines are not
encrypted/signed is because they belong to email metadata, which OpenPGP
doesn't touch.  Protecting metadata is a hard topic.  Rather than come
up with an ad-hoc method that protects one single metadata field, I'd
rather see a solution that protects all metadata.

> This is imho very bad from a usability point of view and also not 
> really neccessary, because there are ways this could work without 
> changing too much about the way pgp mails work.

Take a look at the Enigmail source code, please, before opining about
how your proposal would not necessitate much change to how email
processing works.  Until/unless you've done that, you don't have an
opinion worth listening to on the subject.

> What I have in mind is something like this: Whenever a PGP mail app 
> creates a mail it replaces the subject with a defined keyword. This 
> could be something trivial like "__ENCRYPTED_SUBJECT__". It then 
> places a Subject line inside the encrypted mail body. This is 
> followed by two newlines and then the real encrypted body of the
> mail follows.

It breaks threading.

> What do people think about it?

I think it's a bad idea.

> Is this the right place to discuss it?

As right as anyplace is.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3744 bytes
Desc: S/MIME Cryptographic Signature
URL: </pipermail/attachments/20150116/c99a70b5/attachment-0001.bin>

From rjh at sixdemonbag.org  Fri Jan 16 18:16:41 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Fri, 16 Jan 2015 12:16:41 -0500
Subject: Beyond Curve25519
In-Reply-To: <87iog7yxgg.fsf@vigenere.g10code.de>
References: <54B7AA92.5070505@azet.sk> <20150115215333.03d707f6@pc>
 <87ppaf1yr8.fsf@alice.fifthhorseman.net> <20150116001508.2798f36d@pc>
 <87iog7yxgg.fsf@vigenere.g10code.de>
Message-ID: <54B94779.3070203@sixdemonbag.org>

> Symmetric encryption performance is actually a problem because the
> CFB mode of OpenPGP along with the SHA-1 MDC imposes a limit which
> could be lifted by using a different encryption mode.

Unrelated to the thread, but -- Werner, refresh my memory a moment here.
 Back before PGP implemented Twofish (with ... 7.0, if memory serves),
OpenPGP's CFB mode was basically a tweaked CFB64.  Now that most of the
ciphers in OpenPGP support 128-bit blocks, what's the current mode?
Still tweaked CFB64, or tweaked CFB128?  Or does it keep CFB64 for
64-bit ciphers, and CFB128 for 128-bit ciphers?

(Note to everyone currently panicking about the mention of "64-bit
ciphers" in OpenPGP: this is talking about how many bits the cipher
processes at a time, *not* the size of the key.  All the symmetric
ciphers in OpenPGP support at least 128-bit keys, but some of them
process data 64 bits at a time.)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3744 bytes
Desc: S/MIME Cryptographic Signature
URL: </pipermail/attachments/20150116/ca042b78/attachment.bin>

From rjh at sixdemonbag.org  Fri Jan 16 18:24:25 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Fri, 16 Jan 2015 12:24:25 -0500
Subject: Beyond Curve25519
In-Reply-To: <1421383617.4984.4.camel@scientia.net>
References: <54B7AA92.5070505@azet.sk> <20150115215333.03d707f6@pc>
 <1421383617.4984.4.camel@scientia.net>
Message-ID: <54B94949.1040707@sixdemonbag.org>

> Funny... people told that as well with RSA key sizes which are 
> nowadays no longer considered enough... o.O

Back in the early 1990s, a 1024-bit RSA key was believed to be unassailable.

A 1024-bit key is still today considered unassailable... it just doesn't
have anywhere near the security margin that we want.  We advise at least
2048-bit keys to give us a comfortable margin, not because we believe
people are breaking 1024-bit keys.

To give an idea: for distributed.net to exhaust a 64-shannon keyspace
took them about five years.  They're currently working on exhausting a
72-shannon keyspace, which they project will take about 200 years.
Exhausting an 80-shannon keyspace (about the same as a 1024-bit RSA key)
would take about 5,000 years at that pace, or one year and 5,000 times
the resources of distributed.net.

1024-bit crypto is still strong today.  It's just not as strong as we'd
like and we can do better with few side effects, so let's do better.  :)

> It's really disturbing to read such statements (i.e. "xxx bit 
> security level will be secure forever - except for quantum 
> computers)... it seems as nothing would have been learned from the 
> past :-/

No one will ever exhaust a 128-shannon keyspace until we have
large-scale quantum computers and a few decades in which to operate.

No one will ever exhaust a 256-shannon keyspace.  Ever.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3744 bytes
Desc: S/MIME Cryptographic Signature
URL: </pipermail/attachments/20150116/8295f42f/attachment.bin>

From mnyromyr at tprac.de  Fri Jan 16 19:22:00 2015
From: mnyromyr at tprac.de (=?UTF-8?Q?Karsten_D=c3=bcsterloh?=)
Date: Fri, 16 Jan 2015 19:22:00 +0100
Subject: Encrypting / Signing the mail subject?
In-Reply-To: <54B94688.2020206@sixdemonbag.org>
References: <20150116134324.6d918b4e@pc> <54B94688.2020206@sixdemonbag.org>
Message-ID: <54B956C8.3000500@mid.tprac.de>

[topic reconstructed]

Robert J. Hansen wrote:
>> One of the things I find unfortunate about OpenPGP encryption is 
>> that the subject of a mail is not encrypted and signed.
> 
> This is a total nonissue.  Give each new thread a nonsensical name: 
> STEEL CAMELLIA, ARGENT LUNACY, NEPAL SUNSET, and so forth.

It's just a bad workaround.
Many people (including me) feel it's an unnecessary technical burden.

> The actual contents of a subject line are rarely of interest:

YMMV

> rather, what's of interest is that one message belongs to the same 
> thread as another message, and for that purpose a randomly-chosen 
> identifier works quite well.

Message-ID: and References: work even better.

> If your subject lines are sensitive material, then you're doing it 
> wrong.

No, the protocol is broken.
Or rather, if it's too easy to leak data, it should be fixed.

> Further, the entire reason why the subject lines are not 
> encrypted/signed is because they belong to email metadata, which 
> OpenPGP doesn't touch.

Hence it should evolve.

> Protecting metadata is a hard topic.

Yes.
The way email currently works, you can't avoid having any headers
because they're used in transportation/logging.
But headers can be split into at least two groups:
- used/created in transport
  (like Received:, To:)
- solely passed through from sender to recipient
  (like Subject:, References:)
There may be edge cases (do MTAs need to know about certain headers just
beacause they use it for spam filetering?), but it should be possible to
protect sensitive end-to-end-headers.

> Rather than come up with an ad-hoc method that protects one single 
> metadata field, I'd rather see a solution that protects all 
> metadata.

Yes, insofar that "all" is probably impossible.

>> What I have in mind is something like this: Whenever a PGP mail
>> app creates a mail it replaces the subject with a defined keyword.
>> This could be something trivial like "__ENCRYPTED_SUBJECT__". It
>> then places a Subject line inside the encrypted mail body. This is
>> followed by two newlines and then the real encrypted body of the 
>> mail follows.
> 
> It breaks threading.

Wrong, in this generality.
Threading by subject is broken by design anyway.
But artificially making all subjects the same is making things even
worse, yes.

Brainstorming, I'd rather extend the PGP sections by a private,
encrypted header section. Compliant agents would then put sensitive
(non-transport) headers there and remove them from the normal headers
(if allowed by usual RfCs). A compliant recipient agent would restore
those when displaying the decrypted message.
Or something along that line.

Karsten

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

From rjh at sixdemonbag.org  Fri Jan 16 20:47:26 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Fri, 16 Jan 2015 14:47:26 -0500
Subject: Encrypting / Signing the mail subject?
In-Reply-To: <54B956C8.3000500@mid.tprac.de>
References: <20150116134324.6d918b4e@pc> <54B94688.2020206@sixdemonbag.org>
 <54B956C8.3000500@mid.tprac.de>
Message-ID: <54B96ACE.7050706@sixdemonbag.org>

> It's just a bad workaround.

It's one that's worked quite well for the past 70-odd years in the
military community, since even before there was such a thing as email.

If you want to call something with a 70-year track record a "bad
workaround," well, that's on you.

> Many people (including me) feel it's an unnecessary technical
> burden.

It's not a technical burden.  It doesn't involve any change to
technology.  This is a policy issue, not a technical issue.

> YMMV

Then you're doing it wrong.

>> rather, what's of interest is that one message belongs to the same
>>  thread as another message, and for that purpose a randomly-chosen
>>  identifier works quite well.
> 
> Message-ID: and References: work even better.

Yes.  However, in my experience expecting the whole software ecosystem
to do things the Right Way is folly.  Ad-hoc solutions are at least as
common as the Right Thing, and yes, there are mailing infrastructures
that thread on subject lines.

> Hence [OpenPGP] should evolve.

No, it really shouldn't.  Leave RFC4880 alone, please, it's not an email
protocol.  Put this out in the email RFCs somewhere, like RFC3156.
RFC3156 describes how to use OpenPGP with MIME, but it doesn't actually
define anything about the OpenPGP standard itself.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3744 bytes
Desc: S/MIME Cryptographic Signature
URL: </pipermail/attachments/20150116/5addfd2a/attachment-0001.bin>

From mnyromyr at tprac.de  Fri Jan 16 21:11:19 2015
From: mnyromyr at tprac.de (=?UTF-8?Q?Karsten_D=c3=bcsterloh?=)
Date: Fri, 16 Jan 2015 21:11:19 +0100
Subject: Encrypting / Signing the mail subject?
In-Reply-To: <54B96ACE.7050706@sixdemonbag.org>
References: <20150116134324.6d918b4e@pc> <54B94688.2020206@sixdemonbag.org>
 <54B956C8.3000500@mid.tprac.de> <54B96ACE.7050706@sixdemonbag.org>
Message-ID: <54B97067.10101@mid.tprac.de>

Robert J. Hansen wrote:
> If you want to call something with a 70-year track record a "bad 
> workaround," well, that's on you.

"We always did it like this" is not actually a valid point, but hey ?

>> Hence [OpenPGP] should evolve.

My "it" and "protocol" wasn't exactly meant as "OpenPGP in general", but
"PGP mail", hence I have no problem with:

> Leave RFC4880 alone, please, it's not an
> email protocol.  Put this out in the email RFCs somewhere, like
> RFC3156. RFC3156 describes how to use OpenPGP with MIME, but it
> doesn't actually define anything about the OpenPGP standard itself.

I know.


Karsten
-- 
       Freiheit stirbt        |       Fsayannes SF&F-Bibliothek:
            Mit Sicherheit    |       http://fsayanne.tprac.de/

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

From dkg at fifthhorseman.net  Fri Jan 16 21:29:13 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 16 Jan 2015 15:29:13 -0500
Subject: Encrypting / Signing the mail subject?
In-Reply-To: <20150116134324.6d918b4e@pc>
References: <20150116134324.6d918b4e@pc>
Message-ID: <87mw5ixyee.fsf@alice.fifthhorseman.net>

A non-text attachment was scrubbed...
Name: header
Type: text/rfc822-headers
Size: 201 bytes
Desc: signed headers for this message
URL: </pipermail/attachments/20150116/3be94891/attachment.bin>
-------------- next part --------------
Hi Hanno--

On Fri 2015-01-16 07:43:24 -0500, Hanno B?ck wrote:

> I wanted to share some thoghts about a potential change to the PGP mail
> format I had. I'm not sure if this is the right place to discuss this,
> but afaik there is currently no active openpgp standards list at IETF
> and gnupg is likely the only implementation in widespread use. I recall
> that I have read something alike already somewhere sometime, however I
> don't exactly remember in what context.

despite the fact that the IETF's OpenPGP WG is closed, i think that
openpgp at ietf.org mailing list is still active.  It may be worth
discussing issues like this in that forum as well, to get a wider range
of buy-in.

> One of the things I find unfortunate about OpenPGP encryption is that
> the subject of a mail is not encrypted and signed. This is imho very
> bad from a usability point of view and also not really neccessary,
> because there are ways this could work without changing too much about
> the way pgp mails work.

I agree that this is a problem; however, i'm not sure GnuPG is the place
to solve it, since this is more a question about how to package e-mails,
and GnuPG has traditionally been rather hands-off about e-mail message
handling in particular for OpenPGP (for s/mime there has been a bit more
work within gpgsm proper).

I don't know if there's a good place for that kind of general
discussion, though.

> What I have in mind is something like this: Whenever a PGP mail app
> creates a mail it replaces the subject with a defined keyword. This
> could be something trivial like "__ENCRYPTED_SUBJECT__". It then places
> a Subject line inside the encrypted mail body. This is followed by two
> newlines and then the real encrypted body of the mail follows.
>
> A mail client supporting this format would then replace the
> __ENCRYPTED_SUBJECT__ in the UI with the Subject from the body and it
> would hide the Subject: ... and the two newlines from the UI display of
> the mail body.
>
> Doing this would provide some kind of backwards compatibility to old
> clients. A client not supporting this mechanism would still be able to
> read a mail. It would also show the subject as part of the encrypted
> mail body. There would even be some compatibility in the other way. A
> user aware of how this works could manually set the subject keyword and
> the Subject in the mail body in a mail client not supporting this
> mechanism.
>
>
> There are some things that'd need consideration if such a mechanism
> would be created:
> * This would move the subject to the encrypted part of a message. A
> mail client may decide that it needs some kind of caching of mail
> subjects available, because it is not feasible to decrypt them on
> demand, especially on large mailboxes. Therefore a client might move
> data from the encrypted context to a nonencrypted storage. This is a
> trade-off, but imho it is still a lot better than not encrypting the
> subject at all.
> * One would have to make a clear decision how the Subject is encoded to
> avoid confusion and incompatibilities. Currently a subject with special
> chars has some kind of utf8-prefix-encoding. A mail body has its own
> encoding. One would have to decide if the subject encoding is just the
> body encoding or if the same format as in the header is used. Technical
> detail, but should be done right and should be unambigious.

We'd also need to think about what happens if the mail is only
Content-Type: text/html (or worse: something even further removed from
text/plain) and how to handle line-wrapping, etc. :/  Yuck!

And if a message is wrapped in PGP/MIME (as it probably should be,
esp. if we're trying to infer something about content-type and character
encoding issues), and there are multiple MIME parts, which part should
we be looking in for this info?

I understand the appeal of your proposal in terms of simplicity and
end-user visibility, but i think specifying a whole new range of
logistics around handling this stuff sounds like a lot of nasty work and
room for errors in implementation.

Embedded Header Proposal
========================

Here's a counter-proposal to consider, which relies on PGP/MIME.
PGP/MIME messages are the only reliably structured mail OpenPGP e-mail
messages anyway [0].

A normal PGP/MIME signed text/plain message structure looks like this
(Content-Type of each part is shown) [1]:

A ???multipart/signed
B  ???text/plain 
C  ???application/pgp-signature [signature.asc]

I propose sending a message with an additional text/rfc822-headers [2] part
injected as a sub-part in the message, like this:

D ???multipart/signed
E  ???multipart/mixed
F  ????text/rfc822-headers inline [header] 
G  ????text/plain
H  ???application/pgp-signature [signature.asc]

the text/rfc822-headers mime type is defined here:


In this case, only select headers would be embedded (those headers that
are to be signed/encrypted.  The embedded header part (F, above) should
be Content-Disposition: inline, and should be subject to all the usual
rules of parsing mail message headers.

This allows senders to sign arbitrary headers (not just Subject:), and
it works for both signing and encryption.

For sending and receiving MUAs unaware of this convention, no changes
need to be made; at worst, a receiving MUA can simply ignore the
text/rfc822-headers MIME part.  But since it's of type text/* and
Content-Disposition: inline, they may choose to just render it directly
at the top of the message, which would look very similar to your
proposal.

This e-mail message contains a signed set of embedded headers in the way
i've proposed.  How does it render in your unaware MUA?  feel free to
send me a private report if you like.



for aware MUAs, we'd need to spec out the detailed rules:

Message handling guidelines for embedded-header-aware MUAs
==========================================================


composing (sending) MUAs (signed messages)
------------------------------------------

the composing MUA, when crafting a signed message, needs to know which
header fields should be included.  By default, this might just be
Subject:, though maybe it's worth including Date: as well.

This could be represented in MUA configuration as a simple list of
headers:

signed_headers:
 * Subject
 * Date
 * From
 * To
 * Cc

composing (sending) MUAs (encrypted messages)
---------------------------------------------

the composing MUA, when crafting an encrypted message, needs to know
which header fields should be encrypted, and what the default
replacement for that field should be.

This could be represented in MUA configuration as a list of
(header,value) pairs:

Some headers may have a value marked as <omit>, to indicate that the
header should not be exposed publicly at all, but should only be present
in the embedded header.

encrypted_headers:
 * (Subject,"ENCRYPTED SUBJECT")
 * (In-Reply-To,<omit>)
 * (References,<omit>)

Ideally, these lists would be shared across clients and would have sane
defaults, since shared configuration increases ambiguity to an attacker.

(note that the choices described above would hide threading information
From an attacker)


composing (sending) MUAs (encrypted+signed messages)
----------------------------------------------------

some messages are both signed and encrypted.  an MUA which composes such
a message should craft the embedded headers using the union of all
headers in both signed_headers and encrypted_headers, sign and encrypt
the message, and only then replace or omit the external header fields as
directed by the encrypted_headers configuration.


receiving MUAs (encrypted messages)
-----------------------------------

An MUA that receives an encrypted message with a text/rfc822-headers
part should loop through the embedded headers.  for each embedded
header, it should compare it with the external header of the same label.

If they differ, the MUA should treat the message as though the embedded
header is the correct value.

receiving MUAs (signed messages)
--------------------------------

An MUA that receives a signed message with a text/rfc822-headers part
should loop through the embedded headers.  for each embedded header, it
should compare it with the external header of the same label.

If they differ, the MUA should treat the message as though the embedded
header is the correct value.  The MUA may want to expose the unsigned
value of that header to the user with a warning that it is unsigned.

Whether they differ or not, the MUA should indicate to the user that the
signed parts are signed, and should make a visible distinction between
signed and unsigned headers.


-------

open questions
==============

redundant header parts?
-----------------------

We'd also need to define what happens if more than one
text/rfc822-headers part shows up in a multipart message -- most simply,
we could say that we only process text/rfc822-headers if it happens to
be the first non-multipart part within the multipart/signed or
multipart/encrypted part.  This prevents the receiving MUA from
applying text/rfc822-headers from a forwarded (attached)
signed/encrypted message.


disallowed headers?
-------------------

Are there any headers that *should not* be permitted to be rewritten in
this way?  For example, what would it mean if someone were to embed a
Received: header?  a Message-ID header?

If some are unacceptable, should we have a blocklist (allow arbitrary
headers by default, only reject certain ones) or an allowlist (block
arbitrary headers by default, only accept certain ones like Subject and
date)?


redundant headers
-----------------

within a single header block, there could still be more than one
instance of a given header.  The message itself could also have multiple
copies of a given header (e.g. the Comments and Keywords fields [3]).
If multiple copies of a given header appear in either the exposed header
or the embedded header, and their values differ, how should we resolve
the difference?

-------




What do you think?

        --dkg

[0] https://dkg.fifthhorseman.net/notes/inline-pgp-harmful/

[1] MIME message structure representations shown here are generated from
    actual messages via devel/printmimestructure from the notmuch git
    repository at git://notmuchmail.org/git/notmuch

[2] text/rfc822-headers:   https://tools.ietf.org/html/rfc6522#section-4

[3] Comments and Keywords: https://tools.ietf.org/html/rfc5322#section-3.6.5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: </pipermail/attachments/20150116/3be94891/attachment.sig>

From rjh at sixdemonbag.org  Fri Jan 16 21:44:41 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Fri, 16 Jan 2015 15:44:41 -0500
Subject: Encrypting / Signing the mail subject?
In-Reply-To: <54B97067.10101@mid.tprac.de>
References: <20150116134324.6d918b4e@pc> <54B94688.2020206@sixdemonbag.org>
 <54B956C8.3000500@mid.tprac.de> <54B96ACE.7050706@sixdemonbag.org>
 <54B97067.10101@mid.tprac.de>
Message-ID: <54B97839.7050103@sixdemonbag.org>

>> If you want to call something with a 70-year track record a "bad 
>> workaround," well, that's on you.
> 
> "We always did it like this" is not actually a valid point, but hey 
> ?

The idea of replacing descriptive subject lines with non-descriptive but
unique conversational identifiers is an old and very well-used
technique.  That means it's been thoroughly tested in a variety of
real-world situations, is simple enough for the vast majority of users,
is robust in the face of failures, its failure modes are well-known, and
more.  On top of that, it's a solution that can be implemented *right*
*now*, with no code changes necessary.

What you're proposing has zero implementations, zero track record, and
we have zero knowledge of its failure modes -- just a vague belief that
it will somehow be superior.

This doesn't mean you shouldn't try it.  It might actually be superior,
and if we didn't try new things there would be no progress at all.  But
your fervor for the new needs to be tempered against a serious
understanding of timelines: if you were to have a complete RFC today you
might see this proposal fielded in significant numbers in three years,
and enough feedback for it to be a trusted alternative in five years.

When I weigh a perfect solution that's a minimum of five years out
against a pretty darn good solution that's available *right now* and
involves no code changes and only minor policy changes... well.

Like I said, you're doing it wrong.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3744 bytes
Desc: S/MIME Cryptographic Signature
URL: </pipermail/attachments/20150116/bf70a0a7/attachment.bin>

From buanzo at buanzo.com.ar  Fri Jan 16 23:04:55 2015
From: buanzo at buanzo.com.ar (Arturo 'Buanzo' Busleiman)
Date: Fri, 16 Jan 2015 19:04:55 -0300
Subject: Encrypting / Signing the mail subject?
In-Reply-To: <9A36C3F7-2EDE-4B32-930D-8957EBED32EE@wiredthing.com>
References: <20150116134324.6d918b4e@pc>
 <9A36C3F7-2EDE-4B32-930D-8957EBED32EE@wiredthing.com>
Message-ID: <CAAcS2Gq8GC8oMLmYm3AUsVg9gVa4NF9ep9WWLvRG6kna2C=f4w@mail.gmail.com>

Subjects are considered metadata. I wouldnt sign nor encrypt nor actually
put anything remotely related to the encrypted body in them.
On Jan 16, 2015 12:04 PM, "Dave English" <dave at wiredthing.com> wrote:

> Hi Hanno
>
> I have no real idea whether this is the right place to discuss this,
> myself.
>
> But here goes:
>
> I?m not sure there is a strong enough need, to justify a change.
>
> At the moment there is a clear split between envelope & body.  Only what
> is in the body is signed and can be encrypted.  If you start to handle the
> Subject especially, then you blur the boundary.  That could lead to
> confusion about the handling of other headers.
>
> Of course, not everyone has a technical view of the structure of an
> e-mail.  Many users will not have any concept of the envelope, witness use
> of Cc: versus Bcc: - but I would hope that a user knowledgeable enough to
> use signing or encryption has at least an idea of a distinction between
> body & the rest.
>
> The more competent, at least, will always be free to include nothing
> sensitive or prone to subversion in their Subjects, as and when necessary.
>
> There could be problems with trying to sign what is in the Subject header,
> some systems will change it, either truncating it because of technical
> limitations, or amending it, e.g. to tag suspected SPAM.  If the
> distinction between envelope & body were blurred then users might expect
> other headers to be protected & that would be problematic to implement.
>
> As an aside, even a signed body presents an opportunity for abuse, because
> it can contain what is supposed to be the same message in alternative
> forms, text & html.  Some one can construct a mail with two different
> texts, albeit unrepudiatably, so that one viewer reads one signed version
> of what is said & another viewer reads something different.  I can?t see
> any easy fix to that, other than viewing with suspicion any multi-part.
>
> Never the less - good luck with promoting your change, after all things
> rarely improve without it.
>
> ATB
>
> > On 16 Jan 2015, at 12:43, Hanno B?ck <hanno at hboeck.de> wrote:
> >
> > Hi,
> >
> > I wanted to share some thoghts about a potential change to the PGP mail
> > format I had. I'm not sure if this is the right place to discuss this,
> > but afaik there is currently no active openpgp standards list at IETF
> > and gnupg is likely the only implementation in widespread use. I recall
> > that I have read something alike already somewhere sometime, however I
> > don't exactly remember in what context.
> >
> > One of the things I find unfortunate about OpenPGP encryption is that
> > the subject of a mail is not encrypted and signed. This is imho very
> > bad from a usability point of view and also not really neccessary,
> > because there are ways this could work without changing too much about
> > the way pgp mails work.
> >
> > What I have in mind is something like this: Whenever a PGP mail app
> > creates a mail it replaces the subject with a defined keyword. This
> > could be something trivial like "__ENCRYPTED_SUBJECT__". It then places
> > a Subject line inside the encrypted mail body. This is followed by two
> > newlines and then the real encrypted body of the mail follows.
> >
> > A mail client supporting this format would then replace the
> > __ENCRYPTED_SUBJECT__ in the UI with the Subject from the body and it
> > would hide the Subject: ... and the two newlines from the UI display of
> > the mail body.
> >
> > Doing this would provide some kind of backwards compatibility to old
> > clients. A client not supporting this mechanism would still be able to
> > read a mail. It would also show the subject as part of the encrypted
> > mail body. There would even be some compatibility in the other way. A
> > user aware of how this works could manually set the subject keyword and
> > the Subject in the mail body in a mail client not supporting this
> > mechanism.
> >
> >
> > There are some things that'd need consideration if such a mechanism
> > would be created:
> > * This would move the subject to the encrypted part of a message. A
> > mail client may decide that it needs some kind of caching of mail
> > subjects available, because it is not feasible to decrypt them on
> > demand, especially on large mailboxes. Therefore a client might move
> > data from the encrypted context to a nonencrypted storage. This is a
> > trade-off, but imho it is still a lot better than not encrypting the
> > subject at all.
> > * One would have to make a clear decision how the Subject is encoded to
> > avoid confusion and incompatibilities. Currently a subject with special
> > chars has some kind of utf8-prefix-encoding. A mail body has its own
> > encoding. One would have to decide if the subject encoding is just the
> > body encoding or if the same format as in the header is used. Technical
> > detail, but should be done right and should be unambigious.
> >
> > So far my rough proposal.
> > What do people think about it? Is this the right place to discuss it?
> > If you like it do you think it should become a standard/RFC? Anyone
> > interested in impementing it in whatever mail client implementation?
> >
> > (and to proove my point why this is desirable just see this mail by dkb
> > where he explains why it's bad to rely on subject information in the
> > mail content: http://seclists.org/oss-sec/2015/q1/137 )
> >
> > cu, Hanno
> >
> > --
> > Hanno B?ck
> > http://hboeck.de/
> >
> > mail/jabber: hanno at hboeck.de
> > GPG: BBB51E42
> > _______________________________________________
> > Gnupg-devel mailing list
> > Gnupg-devel at gnupg.org
> > http://lists.gnupg.org/mailman/listinfo/gnupg-devel
>
>
> _______________________________________________
> 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/20150116/44665d0a/attachment-0001.html>

From calestyo at scientia.net  Sat Jan 17 01:46:22 2015
From: calestyo at scientia.net (Christoph Anton Mitterer)
Date: Sat, 17 Jan 2015 01:46:22 +0100
Subject: Beyond Curve25519
In-Reply-To: <54B94949.1040707@sixdemonbag.org>
References: <54B7AA92.5070505@azet.sk> <20150115215333.03d707f6@pc>
 <1421383617.4984.4.camel@scientia.net> <54B94949.1040707@sixdemonbag.org>
Message-ID: <1421455582.4932.19.camel@scientia.net>

On Fri, 2015-01-16 at 12:24 -0500, Robert J. Hansen wrote: 
> > Funny... people told that as well with RSA key sizes which are 
> > nowadays no longer considered enough... o.O
> A 1024-bit key is still today considered unassailable... it just doesn't
> have anywhere near the security margin that we want.
>   We advise at least
> 2048-bit keys to give us a comfortable margin, not because we believe
> people are breaking 1024-bit keys.
Well looking at the recommendations made by several expert groups (e.g.
ECRYPT II, or NIST[0]).. then we see higher sizes even for the mid-term
range only.


Cheers,
Chris.


[0] It somehow hurts calling them experts, given how easily they were
framed by NSA ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5313 bytes
Desc: not available
URL: </pipermail/attachments/20150117/893e0a52/attachment.bin>

From dgouttegattat at incenp.org  Sat Jan 17 12:38:18 2015
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Sat, 17 Jan 2015 12:38:18 +0100
Subject: DCO for Damien Goutte-Gattat
Message-ID: <54BA49AA.2040708@incenp.org>

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: Damien Goutte-Gattat <dgouttegattat at incenp.org>

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

From hanno at hboeck.de  Sat Jan 17 15:26:46 2015
From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=)
Date: Sat, 17 Jan 2015 15:26:46 +0100
Subject: Encrypting / Signing the mail subject?
In-Reply-To: <87mw5ixyee.fsf@alice.fifthhorseman.net>
References: <20150116134324.6d918b4e@pc>
 <87mw5ixyee.fsf@alice.fifthhorseman.net>
Message-ID: <20150117152646.4a8d2f3c@pc>

Hi,

On Fri, 16 Jan 2015 15:29:13 -0500
Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:

> despite the fact that the IETF's OpenPGP WG is closed, i think that
> openpgp at ietf.org mailing list is still active.  It may be worth
> discussing issues like this in that forum as well, to get a wider
> range of buy-in.

Okay, I've now subscribed there, we can move all follow-up discussion
there.

As for your proposal:

> What do you think?

I think it is superior to what I suggested (and the display in my
client is as you expected, it shows the headers above the mail).

I had hoped to solve this with very little complexity, but it turns out
there are probably more things to worry than first thought.

I like your idea of also signing the Date, which seems to make a lot of
sense, however that adds another layer of complication, because now we
have header fields that are hidden in the real mail headers (like
subject) and others that are duplicated in both headers.

What I worry is extending this to stuff that has technical meaning,
like threading info. I can't really see how a client app should handle
that. It wouldn't display the threading when the mail comes in because
it doesn't see it unless the key is unlocked with a password. Would the
messages then flip around once the key is unlocked?

I think we should at least for the start restrict the whole thing to few
headers where we have confidence that it won't create funny
sideeffects. Basically thinking about more headers is nice, but if it
makes the whole thing so complex it won't happen we don't win anything.


To sum up what we have by now:
* 1 very simple proposal by me and one more advanced one by DKG,
  details need to be worked out.
* A statement by Enigmal-dev Patrick Brunschwig that he'd consider
  implementing something like this if it's supported by other clients
  and/or is a proper standard.
* we move the discussion to the ietf openpgp list.

I'll try to reach out the endtoend-people, because most likely that'll
be one of the major other pgp mail implementors beside the
gnupg/enigmail combo.

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

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

From lukele at gpgtools.org  Sat Jan 17 18:23:36 2015
From: lukele at gpgtools.org (Lukas Pitschl)
Date: Sat, 17 Jan 2015 18:23:36 +0100
Subject: Hang in scdaemon or pcsc-wrapper on Yosemite
In-Reply-To: <871tmx49td.fsf@vigenere.g10code.de>
References: <53B1D16B-0A47-46F5-8550-A6B3CFF80908@gpgtools.org>
 <871tmx49td.fsf@vigenere.g10code.de>
Message-ID: <FB457DBC-15D0-42C6-9A68-F5EF7F5B38E2@gpgtools.org>

Thank you very much for this information.
Especially the hint to instruct gdb or lldb to ignore signals might just be what we need to further debug this issue.

On a different not, on Mavericks it appears is not allowed to claim exclusive access to a smart card unless some system files are manipulated.
After reading up a little on possible workaround, it looks like using transactions instead of claiming exclusive access might work.
We?d be happy to add support for this, but wanted to ask you if there are any security or other issues we should be aware of, which make the current solution the better one.

Best,

Lukas

On 14.01.2015, at 17:16, Werner Koch <wk at gnupg.org> wrote:

> On Wed, 14 Jan 2015 12:42, lukele at gpgtools.org said:
> 
>> In order to find out what?s going on we were trying to connect to a
>> debug build of scdaemon and pcsc-wrapper. Unfortunately though,as soon
>> as the debugger is connected, scdaemon as well as the pcsc-wrapper
>> exit due to a SIGPIPE signal.
> 
> scdaemon can't die due to a SIGPIPE because the handler has been set to
> SIG_IGN.  pcsc-wrapper may die though.
> 
> I assume your problem is with the pth library.  Note that pth uses a
> signal for its own (IIRC, SIGUSR2) and thus you need to tell the
> debugger to pass that signal through.   Some debuggers have problems
> with pth; gdb works fine.
> 
>> Also if anyone knows what might lead to a hang in scdaemon, that
>> information would be very valuable as well.
> 
> Use strace/truss etc to debug such problems.
> 
> 
> Salam-Shalom,
> 
>   Werner
> 
> --
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </pipermail/attachments/20150117/2a173436/attachment.sig>

From gpg at nym.mixmin.net  Sun Jan 18 02:11:37 2015
From: gpg at nym.mixmin.net (Stephan Petson)
Date: Sun, 18 Jan 2015 01:11:37 +0000 (GMT)
Subject: Encrypting / Signing the mail subject?
References: <20150116134324.6d918b4e@pc>
 <87mw5ixyee.fsf@alice.fifthhorseman.net> <20150117152646.4a8d2f3c@pc>
Message-ID: <20150118011137.7BB56EAB36@snorky.mixmin.net>

On Sat, 17 Jan 2015 15:26:46 +0100, Hanno B?ck <hanno at hboeck.de>
wrote:

>I had hoped to solve this with very little complexity, but it turns out
>there are probably more things to worry than first thought.

Hi Hanno,

there's the Omnimix proxy server with its Whole Message Encryption.
It encrypts the complete message including the (filtered) header
section, which means the complexity of its MIME structure doesn't
matter at all.  By adding a random quantity of dummy load prior to
encryption even the net size of your mail can't be assessed by an
adversary.  The message to be sent consists of an envelope
containing merely the destination address(es) and optionally a
meaningless subject followed by a body with a single PGP text block.
The recipient finally either also uses that mail proxy to remove the
encoding layer and forward the result, or he manually decrypts the
message with a subsequent import into his mail client.

http://www.danner-net.de/om.htm
https://en.wikipedia.org/wiki/Anonymous_remailer#Remailer_software

Regards, S.P.


From pgut001 at cs.auckland.ac.nz  Sun Jan 18 09:25:24 2015
From: pgut001 at cs.auckland.ac.nz (Peter Gutmann)
Date: Sun, 18 Jan 2015 21:25:24 +1300
Subject: Beyond Curve25519
In-Reply-To: <54B94779.3070203@sixdemonbag.org>
Message-ID: <E1YClAi-0000i2-2x@login01.fos.auckland.ac.nz>

"Robert J. Hansen" <rjh at sixdemonbag.org> writes:

>OpenPGP's CFB mode was basically a tweaked CFB64.  Now that most of the
>ciphers in OpenPGP support 128-bit blocks, what's the current mode? Still
>tweaked CFB64, or tweaked CFB128?  Or does it keep CFB64 for 64-bit ciphers,
>and CFB128 for 128-bit ciphers?

The "tweaked CFB" used in PGP doesn't follow any known standard, it could well 
be an implementation error that was codified in the spec (or at least it looks 
a lot like an implementation error, I can't imagine why you'd do things that 
way deliberately).  Having it fixed at some point if the spec is revised would 
be good, it'd be nice to be able to support a standard mode without having to 
add all sorts of ad-hoc handling for what PGP does.

(Phil Rogaway has offered to make OCB mode freely usable for TLS, if he would 
allow it for PGP as well that would kill two birds with one stone since we 
could get rid of the MDC hack as well).

Peter.


From rjh at sixdemonbag.org  Sun Jan 18 10:16:46 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Sun, 18 Jan 2015 04:16:46 -0500
Subject: Beyond Curve25519
In-Reply-To: <E1YClAi-0000i2-2x@login01.fos.auckland.ac.nz>
References: <E1YClAi-0000i2-2x@login01.fos.auckland.ac.nz>
Message-ID: <54BB79FE.1070400@sixdemonbag.org>

> Having it fixed at some point if the spec is revised would be good,
> it'd be nice to be able to support a standard mode without having to
> add all sorts of ad-hoc handling for what PGP does.

It'd be nice, but I've given up hope on that front; we've had this
conversation in one form or another for fifteen years now.

See, e.g., from 2007:

http://www.imc.org/ietf-openpgp/mail-archive/msg06283.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3744 bytes
Desc: S/MIME Cryptographic Signature
URL: </pipermail/attachments/20150118/db6bea27/attachment.bin>

From wk at gnupg.org  Sun Jan 18 16:20:29 2015
From: wk at gnupg.org (Werner Koch)
Date: Sun, 18 Jan 2015 16:20:29 +0100
Subject: Beyond Curve25519
In-Reply-To: <E1YClAi-0000i2-2x@login01.fos.auckland.ac.nz> (Peter Gutmann's
 message of "Sun, 18 Jan 2015 21:25:24 +1300")
References: <E1YClAi-0000i2-2x@login01.fos.auckland.ac.nz>
Message-ID: <878uh0xghu.fsf@vigenere.g10code.de>

On Sun, 18 Jan 2015 09:25, pgut001 at cs.auckland.ac.nz said:

> way deliberately).  Having it fixed at some point if the spec is
> revised would be good, it'd be nice to be able to support a standard
> mode without having to add all sorts of ad-hoc handling for what PGP
> does.

FWIW: The SYNC bug-feature is not used if MDC is in use.  We use CFB128
for all ciphers with a blocklength of 128.

> (Phil Rogaway has offered to make OCB mode freely usable for TLS, if he would 
With that in mind I added OCB to Libgcrypt last week.  For free
implementations it is thus no problem to replace CFB+MDC-hack by OCB.  I
am not sure how the free OCB licenses relate to the use of an LGPLed
library in a military application - but to me that is more a feature
than a problem.

Another reasons to re-establish the OpenPGP WG.


Salam-Shalom,

   Werner

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



From rjh at sixdemonbag.org  Sun Jan 18 23:38:26 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Sun, 18 Jan 2015 17:38:26 -0500
Subject: Beyond Curve25519
In-Reply-To: <E1YClAi-0000i2-2x@login01.fos.auckland.ac.nz>
References: <E1YClAi-0000i2-2x@login01.fos.auckland.ac.nz>
Message-ID: <54BC35E2.4040307@sixdemonbag.org>

> (Phil Rogaway has offered to make OCB mode freely usable for TLS, if
> he would allow it for PGP as well that would kill two birds with one
> stone since we could get rid of the MDC hack as well).

I don't see the problem.  Historically, the spec has supported software
patents by including such as MAY/SHOULD: see, e.g., RSA in RFC2440.

OCB is free for FOSS use, so it's no trouble for our community.  What's
the problem with keeping the current CFB/MDC setup as a MUST, add OCB as
a MAY, and add a flag to prefs showing whether you're capable of
handling OCB traffic?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3744 bytes
Desc: S/MIME Cryptographic Signature
URL: </pipermail/attachments/20150118/040fa08e/attachment.bin>

From wk at gnupg.org  Mon Jan 19 11:02:07 2015
From: wk at gnupg.org (Werner Koch)
Date: Mon, 19 Jan 2015 11:02:07 +0100
Subject: Beyond Curve25519
In-Reply-To: <54BC35E2.4040307@sixdemonbag.org> (Robert J. Hansen's message of
 "Sun, 18 Jan 2015 17:38:26 -0500")
References: <E1YClAi-0000i2-2x@login01.fos.auckland.ac.nz>
 <54BC35E2.4040307@sixdemonbag.org>
Message-ID: <87d26bw0kg.fsf@vigenere.g10code.de>

On Sun, 18 Jan 2015 23:38, rjh at sixdemonbag.org said:

> OCB is free for FOSS use, so it's no trouble for our community.  What's
> the problem with keeping the current CFB/MDC setup as a MUST, add OCB as
> a MAY, and add a flag to prefs showing whether you're capable of
> handling OCB traffic?

That works for the meantime and is how we need to implement it anyway.
But at some point we need to stop creating old data and the IETF may not
like to make a semi-patented algorithm a MUST.  On the other hand
migration to a new format will anyway take years and the known patents
may have expired by then.


Shalom-Salam,

   Werner

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



From wk at gnupg.org  Mon Jan 19 12:04:59 2015
From: wk at gnupg.org (Werner Koch)
Date: Mon, 19 Jan 2015 12:04:59 +0100
Subject: Encrypting / Signing the mail subject?
In-Reply-To: <87mw5ixyee.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Fri, 16 Jan 2015 15:29:13 -0500")
References: <20150116134324.6d918b4e@pc>
 <87mw5ixyee.fsf@alice.fifthhorseman.net>
Message-ID: <87oapvuj38.fsf@vigenere.g10code.de>

On Fri, 16 Jan 2015 21:29, dkg at fifthhorseman.net said:

> [2] text/rfc822-headers:   https://tools.ietf.org/html/rfc6522#section-4

I was not aware of this.  It is clearly better than my old proposal of
wrapping the entire message into a message/rfc822 container:
 
 - Less overhead.
 - Likely to be more compatible with more mailers.
 - Does exactly what we want to do.
 - Still allows to use a code-phrase subjects so that 
   decrypting only for the thread view is not required.

I do not think there is much need to standardize what headers need to go
there.  MUA authors should decide or make if configurable.  A de-facto
standard will soon show up anyway.


Shalom-Salam,

   Werner

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



From wk at gnupg.org  Mon Jan 19 15:02:27 2015
From: wk at gnupg.org (Werner Koch)
Date: Mon, 19 Jan 2015 15:02:27 +0100
Subject: [PATCH] kbx: Call skipfnc callback to filter out keys
In-Reply-To: <54B934B3.201@incenp.org> (Damien Goutte-Gattat's message of
 "Fri, 16 Jan 2015 16:56:35 +0100")
References: <54B934B3.201@incenp.org>
Message-ID: <87bnluuavg.fsf@vigenere.g10code.de>

On Fri, 16 Jan 2015 16:56, dgouttegattat at incenp.org said:

> The keybox_search function in kbx/keybox-search.c currently ignores
> the skipfnc callback, but the validate_key_list function in
> g10/trustdb.c uses such a callback to exclude ultimately trusted keys.

Good catch.  It is obvious that this led to the regression.  Thanks.

Please used "git format-patch" in the future and then sign the entire
patch so that I can easily apply it.


Salam-Shalom,

   Werner

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



From lists-gnupgdev at lina.inka.de  Tue Jan 20 00:15:33 2015
From: lists-gnupgdev at lina.inka.de (lists-gnupgdev at lina.inka.de)
Date: Tue, 20 Jan 2015 00:15:33 +0100
Subject: Beyond Curve25519
In-Reply-To: <87d26bw0kg.fsf@vigenere.g10code.de>
References: <E1YClAi-0000i2-2x@login01.fos.auckland.ac.nz>
 <54BC35E2.4040307@sixdemonbag.org>
 <87d26bw0kg.fsf@vigenere.g10code.de>
Message-ID: <20150120001533.00004ff0.ecki@lina.inka.de>

Am Mon, 19 Jan 2015 11:02:07 +0100
schrieb Werner Koch <wk at gnupg.org>:

> On Sun, 18 Jan 2015 23:38, rjh at sixdemonbag.org said:
> 
> > OCB is free for FOSS use, so it's no trouble for our community.
> > What's the problem with keeping the current CFB/MDC setup as a
> > MUST, add OCB as a MAY, and add a flag to prefs showing whether
> > you're capable of handling OCB traffic?
> 
> That works for the meantime and is how we need to implement it anyway.
> But at some point we need to stop creating old data and the IETF may
> not like to make a semi-patented algorithm a MUST.  On the other hand
> migration to a new format will anyway take years and the known patents
> may have expired by then.

It would be good if we had an authenticated encryption which worked on
segments so we can actually release only authenticated data to
streams.

And while we are there, everybody seems to be happy with GCM or
CTR+HMAC modes. They might not be the most efficient, but does that
really matter for the symmetric encryption? At least it is not the next
license and patent drama (those we all love in PGP land).

Gruss
Bernd


From dkg at fifthhorseman.net  Tue Jan 20 19:41:11 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 20 Jan 2015 13:41:11 -0500
Subject: [PATCH] fix typo in stable branch gpg.texi
Message-ID: <1421779271-18068-1-git-send-email-dkg@fifthhorseman.net>

* doc/gpg.texi: "teh" should be "the"

--
Debian-Bug-Id: 775815
---
 doc/gpg.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/gpg.texi b/doc/gpg.texi
index 7d08756..acfc026 100644
--- a/doc/gpg.texi
+++ b/doc/gpg.texi
@@ -532,7 +532,7 @@ This section explains the main commands for key management
 
 @item --gen-key
 @opindex gen-key
-Generate a new key pair using teh current default parameters.  This is
+Generate a new key pair using the current default parameters.  This is
 the standard command to create a new key.
 
 There is also a feature which allows you to create keys in batch
-- 
2.1.4



From gniibe at fsij.org  Wed Jan 21 01:11:38 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 21 Jan 2015 09:11:38 +0900
Subject: Forward/Backward compatibility of scdaemon (2.0 and 2.1)
Message-ID: <54BEEEBA.1090905@fsij.org>

Hello,

I got a report that Gnuk Token doesn't work well with GnuPG 2.1,
and it found that the problem is compatibility of scdaemon.

The user in question used scdaemon from 2.0 together with
gpg/gpg-agent from 2.1 (it was not intentional).

Signing and authentication worked with this configuration, but
decryption didn't work well (with RSA).

The reason is that the protocol has been enhanced in 2.1 so that it
can support various public key (other than DSA and RSA, that is, ECC).

In 2.1, the data is in the format of SEXP.  It's built in
g10/pubkey-enc.c:

        err = gcry_sexp_build (&s_data, NULL, "(enc-val(rsa(a%m)))",
                               enc->data[0]);

Here, '%m' specifies standard format which might has a prefix of
'0x00' if the MSB is 1.  gpg-agent receives this data and forwards the
MPI to scdaemon.

Scdaemon of 2.1 takes advantage of the prefix of '0x00' and uses that
byte as is, for different purpose.  However, older scdaemon of 2.0
doesn't know this possibility of the prefix (gpg 2.0 doesn't use SEXP
and format the data with GCRYMPI_FMT_USG (no prefix)), and blindly
adds another prefix, which causes a failure of Gnuk Token (or
smartcard).

How should we fix this issue?

We can just say that use corresponding version of scdaemon.  But it
seems for me that implementing forward compatibility in the scdaemon
in 2.0 would be good.  It's also possible to change gpg in 2.1 so that
it uses %M to specify GCRYMPI_FMT_USG, but this kills the hack of
using prefix byte.
-- 


From dkg at fifthhorseman.net  Wed Jan 21 05:10:18 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 20 Jan 2015 23:10:18 -0500
Subject: agent: Fix agent_public_key_from_file
In-Reply-To: <54AE0230.6080901@fsij.org>
References: <54981864.7050005@fsij.org> <87wq5jstc7.fsf@vigenere.g10code.de>
 <54982D3A.1040307@fsij.org> <549BBAFE.8010605@fsij.org>
 <54AE0230.6080901@fsij.org>
Message-ID: <87fvb4u639.fsf@alice.fifthhorseman.net>

On Wed 2015-01-07 23:06:08 -0500, NIIBE Yutaka wrote:
> Well, I don't have concrete idea about the part two.  I don't know if
> we should support arbitrary curves with parameters (for GnuPG).

fwiw, I don't think that GnuPG should support arbitrary curves with
parameters.  Group choice is a tricky and contentious issue, and GnuPG
should provide known-reasonable groups for its users, rather than
providing them with excessive flexibility that is more likely to cause
harm and confusion than to help.

     --dkg


From dkg at fifthhorseman.net  Wed Jan 21 05:49:00 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 20 Jan 2015 23:49:00 -0500
Subject: [patch] wipe secure memory after iconv failure
In-Reply-To: <OrQgYqUfYMIRGaZAZ8zCII/iqWk@fZuiaDBWAX3Nuww6t5uQq3AO1vY>
References: <OrQgYqUfYMIRGaZAZ8zCII/iqWk@fZuiaDBWAX3Nuww6t5uQq3AO1vY>
Message-ID: <877fwgu4ar.fsf@alice.fifthhorseman.net>

On Sun 2015-01-04 18:48:23 -0500, Eygene Ryabinkin wrote:
> Gentlemen, good day.
>
> Seems like recent fix for sm/minip12.c wasn't totally fine:
> it closed the double-free issue, but left the possibility
> for parts of the translated password to be left in-memory.
>
> The patch at
>   http://codelabs.ru/patches/gnupg/2015-apply-secure-wipe-after-iconv-failure.diff
> should fix that.
>
> Any thoughts on this?

if iconv can choke partway through, I think you're probably correct.
and it's probably safer to do what you're suggesting anyway.

I'm attaching the patch to this e-mail so that it can be processed
offline and it is stored in the mail archive as well.

Werner, WDYT?

        --dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2015-apply-secure-wipe-after-iconv-failure.diff
Type: text/x-diff
Size: 993 bytes
Desc: not available
URL: </pipermail/attachments/20150120/888335df/attachment.diff>

From dkg at fifthhorseman.net  Wed Jan 21 05:52:24 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 20 Jan 2015 23:52:24 -0500
Subject: lock-obj-pub.arm-none-linux-gnueabi.h
In-Reply-To: <CAEQQSVs9HHkGMTQm=BtxQCHDaaVFAyhj+PRYc+B3HZxo8pbeAQ@mail.gmail.com>
References: <CAEQQSVs9HHkGMTQm=BtxQCHDaaVFAyhj+PRYc+B3HZxo8pbeAQ@mail.gmail.com>
Message-ID: <874mrku453.fsf@alice.fifthhorseman.net>

On Sun 2015-01-04 08:28:13 -0500, Rajagopal Aravindan wrote:

> I was successfully able to compile libgpg-error-1.17 for my ARM with the
> attached file.
> The attached file was generated by following the instructions in the
> README, which also suggested sharing it back with the group and hence this
> mail.
> PFB the details of my ARM compiler as well as my target platform.
> Please let me know if any more details would be needed from my side, to
> include this in your next release.
>
> Thanks,
> Rajagopal
>
>
> *[root at FriendlyARM ~]# uname -aLinux FriendlyARM 3.5.0-FriendlyARM #1 SMP
> PREEMPT Tue Dec 23 17:38:40 IST 2014 armv7l GNU/Linux*
> *~/Downloads/libgpg-error-1.17$ arm-none-linux-gnueabi-gcc -v*

Interesting.  This seems to be identical to the already-present
src/syscfg/lock-obj-pub.arm-unknown-linux-gnueabi.h -- do we actually
need both?

     --dkg


From wk at gnupg.org  Wed Jan 21 10:11:32 2015
From: wk at gnupg.org (Werner Koch)
Date: Wed, 21 Jan 2015 10:11:32 +0100
Subject: lock-obj-pub.arm-none-linux-gnueabi.h
In-Reply-To: <874mrku453.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Tue, 20 Jan 2015 23:52:24 -0500")
References: <CAEQQSVs9HHkGMTQm=BtxQCHDaaVFAyhj+PRYc+B3HZxo8pbeAQ@mail.gmail.com>
 <874mrku453.fsf@alice.fifthhorseman.net>
Message-ID: <87sif4o5vf.fsf@vigenere.g10code.de>

On Wed, 21 Jan 2015 05:52, dkg at fifthhorseman.net said:

>> *[root at FriendlyARM ~]# uname -aLinux FriendlyARM 3.5.0-FriendlyARM #1 SMP
>> PREEMPT Tue Dec 23 17:38:40 IST 2014 armv7l GNU/Linux*
>> *~/Downloads/libgpg-error-1.17$ arm-none-linux-gnueabi-gcc -v*
>
> Interesting.  This seems to be identical to the already-present
> src/syscfg/lock-obj-pub.arm-unknown-linux-gnueabi.h -- do we actually
> need both?

config.sub from 2015-01-01 does not yet know

  arm-none-linux-gnueabi

thus we should first get support for it in config.{guess,sub}


Salam-Shalom,

   Werner

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



From wk at gnupg.org  Wed Jan 21 10:19:58 2015
From: wk at gnupg.org (Werner Koch)
Date: Wed, 21 Jan 2015 10:19:58 +0100
Subject: Forward/Backward compatibility of scdaemon (2.0 and 2.1)
In-Reply-To: <54BEEEBA.1090905@fsij.org> (NIIBE Yutaka's message of "Wed, 21
 Jan 2015 09:11:38 +0900")
References: <54BEEEBA.1090905@fsij.org>
Message-ID: <87oapso5hd.fsf@vigenere.g10code.de>

On Wed, 21 Jan 2015 01:11, gniibe at fsij.org said:

> How should we fix this issue?
>
> We can just say that use corresponding version of scdaemon.  But it

Although I expected that older gpg versions are used with a current
gpg-agent, I did not expect that a non-matching scdaemon is in use.  I
think that we should enforce that the major and minor versions match and
also further a warning if the micro version does not match.

When debugging it is really cumbersome if different module versions are
used.  We can't maintain such a test matrix.  I will enhance gpgconf to
detect version mismatches and print appropriate warnings.



Shalom-Salam,

   Werner

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



From wk at gnupg.org  Wed Jan 21 19:06:29 2015
From: wk at gnupg.org (Werner Koch)
Date: Wed, 21 Jan 2015 19:06:29 +0100
Subject: gpg-agent and allow-loopback-pinentry
In-Reply-To: <54A1696C.4080502@enigmail.net> (Patrick Brunschwig's message of
 "Mon, 29 Dec 2014 15:47:08 +0100")
References: <549D5623.5040602@enigmail.net> <549F9C55.6010508@fsij.org>
 <54A02A8C.4060801@enigmail.net> <87bnmmn5j3.fsf@vigenere.g10code.de>
 <54A1696C.4080502@enigmail.net>
Message-ID: <87sif4m2je.fsf@vigenere.g10code.de>

Hi,

today I pushed changes which allow to put the passphrase again into the
parameter file.

You may now also do this

  gpg --batch --passphrase '' --quick-gen-key '<all at keys-belong-to.eu>'

or with a passphrase

  gpg --batch --passphrase 'abc' --quick-gen-key '<all at keys-belong-to.de>'


Shalom-Salam,

   Werner

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



From gnoack at google.com  Thu Jan 22 16:35:27 2015
From: gnoack at google.com (=?UTF-8?q?G=C3=BCnther=20Noack?=)
Date: Thu, 22 Jan 2015 16:35:27 +0100
Subject: [PATCH 1/3] Remove unnecessary duplicate check.
Message-ID: <1421940929-29110-1-git-send-email-gnoack@google.com>

Hello developers,

this and the following two patches are some trivial bugs found with
the Clang static analyzer.  Patch 1 and 2 remove unnecessary duplicate
checks, patch 3 addresses a copy&paste glitch which mixes up int and
unsigned int.

Thanks,
Guenther

---
 sm/verify.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sm/verify.c b/sm/verify.c
index 2e91137..73e0ab4 100644
--- a/sm/verify.c
+++ b/sm/verify.c
@@ -467,7 +467,7 @@ gpgsm_verify (ctrl_t ctrl, int in_fd, int data_fd, estream_t out_fp)
           s = gcry_md_read (data_md, algo);
           if ( !s || !msgdigestlen
                || gcry_md_get_algo_dlen (algo) != msgdigestlen
-               || !s || memcmp (s, msgdigest, msgdigestlen) )
+               || memcmp (s, msgdigest, msgdigestlen) )
             {
               char *fpr;

--
2.2.2


From gnoack at google.com  Thu Jan 22 16:35:28 2015
From: gnoack at google.com (=?UTF-8?q?G=C3=BCnther=20Noack?=)
Date: Thu, 22 Jan 2015 16:35:28 +0100
Subject: [PATCH 2/3] Remove unnecessary duplicate check.
In-Reply-To: <1421940929-29110-1-git-send-email-gnoack@google.com>
References: <1421940929-29110-1-git-send-email-gnoack@google.com>
Message-ID: <1421940929-29110-2-git-send-email-gnoack@google.com>

---
 g10/keygen.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/g10/keygen.c b/g10/keygen.c
index fa466a8..ba7b4c2 100644
--- a/g10/keygen.c
+++ b/g10/keygen.c
@@ -2656,7 +2656,7 @@ ask_user_id (int mode, int full, KBNODE keyblock)
 	    xfree(answer);
 	}
 	xfree(answer);
-	if( !amail && !acomment && !amail )
+	if( !amail && !acomment )
 	    break;
 	xfree(uid); uid = NULL;
     }
--
2.2.2


From gnoack at google.com  Thu Jan 22 16:35:29 2015
From: gnoack at google.com (=?UTF-8?q?G=C3=BCnther=20Noack?=)
Date: Thu, 22 Jan 2015 16:35:29 +0100
Subject: [PATCH 3/3] Fix int/uint copy-and-paste-o.
In-Reply-To: <1421940929-29110-1-git-send-email-gnoack@google.com>
References: <1421940929-29110-1-git-send-email-gnoack@google.com>
Message-ID: <1421940929-29110-3-git-send-email-gnoack@google.com>

---
 tools/gpgconf-comp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/gpgconf-comp.c b/tools/gpgconf-comp.c
index 86e67eb..01c4135 100644
--- a/tools/gpgconf-comp.c
+++ b/tools/gpgconf-comp.c
@@ -2365,7 +2365,7 @@ option_check_validity (gc_option_t *option, unsigned long flags,
 	    gc_error (1, 0, "garbage after argument for option %s",
 		      option->name);
 	}
-      else if (gc_arg_type[option->arg_type].fallback == GC_ARG_TYPE_INT32)
+      else if (gc_arg_type[option->arg_type].fallback == GC_ARG_TYPE_UINT32)
 	{
 	  unsigned long res;

--
2.2.2


From aheinecke at intevation.de  Thu Jan 22 18:14:09 2015
From: aheinecke at intevation.de (Andre Heinecke)
Date: Thu, 22 Jan 2015 18:14:09 +0100
Subject: System wide dirmngr configuration with Gnupg 2.1
In-Reply-To: <7757034.xtvict5H27@esus>
References: <7757034.xtvict5H27@esus>
Message-ID: <2437630.l6MkVdTiIp@esus>

Hi,

To summarize my last mail: As an organization that uses S/MIME we need to 
centrally configure the trusted Root CA's for GnuPG and the ldap server used in 
dirmngr for certificate retrieval.

This worked for us with GnuPG 2.0.x by configuring these in /etc/dirmngr/ but 
with GnuPG 2.1 it appears no longer possible if we don't want to stick with 
the old system deamon mode.

I've wrote the attached small Patch to use the system-wide configuration by 
default if /etc/gnupg/dirmngr.conf exists and is readable.

I don't think it will be a problem with legacy systems as the dirmngr.conf was 
located under /etc/dirmngr/dirmngr.conf in previous versions.

Would this be acceptable?

Regards,
Andre

-- 
Andre Heinecke |  ++49-541-335083-262  |  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-dirmngr-Prefer-system-wide-config-by-default.patch
Type: text/x-patch
Size: 3068 bytes
Desc: not available
URL: </pipermail/attachments/20150122/b99d39a2/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20150122/b99d39a2/attachment.sig>

From dkg at fifthhorseman.net  Thu Jan 22 20:23:11 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 22 Jan 2015 14:23:11 -0500
Subject: System wide dirmngr configuration with Gnupg 2.1
In-Reply-To: <2437630.l6MkVdTiIp@esus>
References: <7757034.xtvict5H27@esus> <2437630.l6MkVdTiIp@esus>
Message-ID: <87d266oc0w.fsf@alice.fifthhorseman.net>

On Thu 2015-01-22 12:14:09 -0500, Andre Heinecke wrote:

> To summarize my last mail: As an organization that uses S/MIME we need to 
> centrally configure the trusted Root CA's for GnuPG and the ldap server used in 
> dirmngr for certificate retrieval.
>
> This worked for us with GnuPG 2.0.x by configuring these in /etc/dirmngr/ but 
> with GnuPG 2.1 it appears no longer possible if we don't want to stick with 
> the old system deamon mode.
>
> I've wrote the attached small Patch to use the system-wide configuration by 
> default if /etc/gnupg/dirmngr.conf exists and is readable.
>
> I don't think it will be a problem with legacy systems as the dirmngr.conf was 
> located under /etc/dirmngr/dirmngr.conf in previous versions.

I generally don't like the idea that system configuration overrides user
configuration; in principle, the other way around is usually preferable:

 * the system administrator sets the defaults
 * the user can customize if they need to.

So this proposal seems backward to me.

I see the trouble you have, though, since dirmngr is being automatically
launched.

What if you just set up the system-wide dirmngr daemon listening on a
unix-domain socket like /run/gnupg/S.dirmngr, and then for users who
want to use it, do:

 ln -s /run/gnupg/S.dirmngr ~/.gnupg/S.dirmngr

Would that solve your use case?

        --dkg


From aheinecke at intevation.de  Fri Jan 23 11:14:22 2015
From: aheinecke at intevation.de (Andre Heinecke)
Date: Fri, 23 Jan 2015 11:14:22 +0100
Subject: System wide dirmngr configuration with Gnupg 2.1
In-Reply-To: <87d266oc0w.fsf@alice.fifthhorseman.net>
References: <7757034.xtvict5H27@esus> <2437630.l6MkVdTiIp@esus>
 <87d266oc0w.fsf@alice.fifthhorseman.net>
Message-ID: <10857837.gJyTAmyjgT@esus>

Hi,

On Thursday, January 22, 2015 02:23:11 PM Daniel Kahn Gillmor wrote:
> On Thu 2015-01-22 12:14:09 -0500, Andre Heinecke wrote:
> > I don't think it will be a problem with legacy systems as the dirmngr.conf
> > was located under /etc/dirmngr/dirmngr.conf in previous versions.
> 
> I generally don't like the idea that system configuration overrides user
> configuration; in principle, the other way around is usually preferable:
> 
>  * the system administrator sets the defaults
>  * the user can customize if they need to.
> 
> So this proposal seems backward to me.

Yes, I agree with you there. I don't want to force users to this configuration. 
Users that have a reason could still start a dirmngr with --homedir ~/.gnupg.

But maybe it really would be better to have dirmngr read the trusted-certs 
from the sysconfig dir and also from the homedir. 

Like:
If --homedir is not explicitly set: Read trusted-certs / config from sysconfig 
dir. Afterwards read trusted-certs / config from homedir and prefer the values 
from the homedir. This would be more similar to freedesktops config_dirs / 
config_home handling. 

I shied away from this as this would be more intrusive and not "GnuPG style" 
(well ok my proposal is neither). But imho this would be nice to have not only 
for dirmngr. As it and would give distributors / admins more options.

> I see the trouble you have, though, since dirmngr is being automatically
> launched.
> 
> What if you just set up the system-wide dirmngr daemon listening on a
> unix-domain socket like /run/gnupg/S.dirmngr, and then for users who
> want to use it, do:
> 
>  ln -s /run/gnupg/S.dirmngr ~/.gnupg/S.dirmngr
> 
> Would that solve your use case?

Not really.
 a) I'm not sure if werner plans to support the system-wide mode forever. And 
I would not like to stray away from debian packaging so far as to still keep 
dirmngr started centrally as a service.

 b) The default should be the system wide config (if it exists) as this is for 
the users that don't know what a dirmngr is. Those who know / care should be 
able to overrule it.


Regards,
Andre

-- 
Andre Heinecke |  ++49-541-335083-262  |  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20150123/e9314ada/attachment.sig>

From wk at gnupg.org  Fri Jan 23 15:43:31 2015
From: wk at gnupg.org (Werner Koch)
Date: Fri, 23 Jan 2015 15:43:31 +0100
Subject: agent: Fix agent_public_key_from_file
In-Reply-To: <87fvb4u639.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Tue, 20 Jan 2015 23:10:18 -0500")
References: <54981864.7050005@fsij.org> <87wq5jstc7.fsf@vigenere.g10code.de>
 <54982D3A.1040307@fsij.org> <549BBAFE.8010605@fsij.org>
 <54AE0230.6080901@fsij.org> <87fvb4u639.fsf@alice.fifthhorseman.net>
Message-ID: <878ugteewc.fsf@vigenere.g10code.de>

On Wed, 21 Jan 2015 05:10, dkg at fifthhorseman.net said:

> fwiw, I don't think that GnuPG should support arbitrary curves with
> parameters.  Group choice is a tricky and contentious issue, and GnuPG

I concur.


Salam-Shalom,

   Werner

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



From wk at gnupg.org  Fri Jan 23 15:41:12 2015
From: wk at gnupg.org (Werner Koch)
Date: Fri, 23 Jan 2015 15:41:12 +0100
Subject: [PATCH 1/3] Remove unnecessary duplicate check.
In-Reply-To: <1421940929-29110-1-git-send-email-gnoack@google.com>
 (=?utf-8?Q?=22G=C3=BCnther?=
 Noack"'s message of "Thu, 22 Jan 2015 16:35:27 +0100")
References: <1421940929-29110-1-git-send-email-gnoack@google.com>
Message-ID: <87fvb1ef07.fsf@vigenere.g10code.de>

On Thu, 22 Jan 2015 16:35, gnoack at google.com said:

> this and the following two patches are some trivial bugs found with
> the Clang static analyzer.  Patch 1 and 2 remove unnecessary duplicate

Thanks.  I applied them as a single pacth.

> checks, patch 3 addresses a copy&paste glitch which mixes up int and
> unsigned int.

This is a real bug which inhibited the validity checking of all uint32
arguments (e.g. cache time).  I also backported it to 2.0.

Thanks,

  Werner

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



From git at internot.info  Fri Jan 23 16:41:43 2015
From: git at internot.info (Joshua Rogers)
Date: Sat, 24 Jan 2015 02:41:43 +1100
Subject: [PATCH] Fix various uninitalized variable values. See CWE-457 for
 info.
Message-ID: <1422027703-2741-1-git-send-email-git@internot.info>

* common/iobuf.c: Fix uninitalized variable(s)
* g10/textfilter.c: Fix uninitalized variable(s)
* sm/keydb.c: Fix uninitalized variables(s)

--

All of these may be used before they are set(or in some cases
they are not set ever, and assumed to be 0/null)

Please note: There are 3 more:
/g10/keyring.c:
1011      byte afp[MAX_FINGERPRINT_LEN];

/g10/keygen.c:
305    byte sym[MAX_PREFS], hash[MAX_PREFS], zip[MAX_PREFS];

/g10/keylist.c:
770          char buf[(MAX_FINGERPRINT_LEN * 2) + 90];

But I do not know how to initialize them.

Signed-off-by: Joshua Rogers <git at internot.info>
---
 common/iobuf.c   | 2 +-
 g10/textfilter.c | 2 +-
 sm/keydb.c       | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/common/iobuf.c b/common/iobuf.c
index badbf78..3b13483 100644
--- a/common/iobuf.c
+++ b/common/iobuf.c
@@ -1476,7 +1476,7 @@ iobuf_openrw (const char *fname)
   iobuf_t a;
   gnupg_fd_t fp;
   file_filter_ctx_t *fcx;
-  size_t len;
+  size_t len = 0;
 
   if (!fname)
     return NULL;
diff --git a/g10/textfilter.c b/g10/textfilter.c
index 394d9c3..c6c4eec 100644
--- a/g10/textfilter.c
+++ b/g10/textfilter.c
@@ -165,7 +165,7 @@ copy_clearsig_text( IOBUF out, IOBUF inp, gcry_md_hd_t md,
 {
     unsigned int maxlen;
     byte *buffer = NULL;    /* malloced buffer */
-    unsigned int bufsize;   /* and size of this buffer */
+    unsigned int bufsize = 0;   /* and size of this buffer */
     unsigned int n;
     int truncated = 0;
     int pending_lf = 0;
diff --git a/sm/keydb.c b/sm/keydb.c
index 974625d..7bbbbec 100644
--- a/sm/keydb.c
+++ b/sm/keydb.c
@@ -958,7 +958,7 @@ int
 keydb_search (KEYDB_HANDLE hd, KEYDB_SEARCH_DESC *desc, size_t ndesc)
 {
   int rc = -1;
-  unsigned long skipped;
+  unsigned long skipped = 0;
 
   if (!hd)
     return gpg_error (GPG_ERR_INV_VALUE);
-- 
1.9.1



From git at internot.info  Fri Jan 23 17:03:33 2015
From: git at internot.info (Joshua Rogers)
Date: Sat, 24 Jan 2015 03:03:33 +1100
Subject: [PATCH] Remove incorrect expression leading to errors.
Message-ID: <1422029013-5769-1-git-send-email-git@internot.info>

* scd/ccid-driver.c: Variable 'rc' in send_escape_cmd was
overwritten before it was returned, leading to incorrect
computation.

--

Signed-off-by: Joshua Rogers <git at internot.info>
---
 scd/ccid-driver.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scd/ccid-driver.c b/scd/ccid-driver.c
index 7a91e09..fdfe1f5 100644
--- a/scd/ccid-driver.c
+++ b/scd/ccid-driver.c
@@ -2230,8 +2230,8 @@ send_escape_cmd (ccid_driver_t handle,
             {
               memcpy (result, msg, msglen);
               *resultlen = msglen;
+              rc = 0;
             }
-          rc = 0;
         }
         break;
       default:
-- 
1.9.1



From dkg at fifthhorseman.net  Fri Jan 23 17:55:00 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 23 Jan 2015 11:55:00 -0500
Subject: [PATCH 1/3] Remove unnecessary duplicate check.
In-Reply-To: <87fvb1ef07.fsf@vigenere.g10code.de>
References: <1421940929-29110-1-git-send-email-gnoack@google.com>
 <87fvb1ef07.fsf@vigenere.g10code.de>
Message-ID: <8761bxl9nf.fsf@alice.fifthhorseman.net>

On Fri 2015-01-23 09:41:12 -0500, Werner Koch wrote:
> On Thu, 22 Jan 2015 16:35, gnoack at google.com said:
>> checks, patch 3 addresses a copy&paste glitch which mixes up int and
>> unsigned int.
>
> This is a real bug which inhibited the validity checking of all uint32
> arguments (e.g. cache time).  I also backported it to 2.0.

Can you give an example of where this might be a problem?  is there any
possible security implication?

         --dkg


From dkg at fifthhorseman.net  Fri Jan 23 18:19:55 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 23 Jan 2015 12:19:55 -0500
Subject: System wide dirmngr configuration with Gnupg 2.1
In-Reply-To: <10857837.gJyTAmyjgT@esus>
References: <7757034.xtvict5H27@esus> <2437630.l6MkVdTiIp@esus>
 <87d266oc0w.fsf@alice.fifthhorseman.net> <10857837.gJyTAmyjgT@esus>
Message-ID: <873871l8hw.fsf@alice.fifthhorseman.net>

On Fri 2015-01-23 05:14:22 -0500, Andre Heinecke wrote:
> Yes, I agree with you there. I don't want to force users to this configuration. 
> Users that have a reason could still start a dirmngr with --homedir ~/.gnupg.

except that it's automatically launched, as you pointed out :/

> But maybe it really would be better to have dirmngr read the trusted-certs 
> from the sysconfig dir and also from the homedir. 
>
> Like:
> If --homedir is not explicitly set: Read trusted-certs / config from sysconfig 
> dir. Afterwards read trusted-certs / config from homedir and prefer the values 
> from the homedir. This would be more similar to freedesktops config_dirs / 
> config_home handling. 

This is is a pretty common configuration pattern for other (non-gnupg)
tools.  In fact, i've often wished for it for gnupg itself, so that
sysadmins could tweak a generic /etc/gnupg/gpg.conf for all their users.
Is there a specific reason why gpg doesn't support this configuration
pattern?

>>  ln -s /run/gnupg/S.dirmngr ~/.gnupg/S.dirmngr
>> 
>> Would that solve your use case?
>
> Not really.
>  a) I'm not sure if werner plans to support the system-wide mode forever. 

The main difference of the system mode is its use of a modified/split
directory layout that meets the LFS requirements, right?

Couldn't this also be done with:

 mkdir -p /var/lib/gnupg/extra-certs /etc/gnupg /var/cache/gnupg/crls.d /var/run/gnupg
 ln -s /var/cache/gnupg/crls.d  /etc/gnupg/dirmngr.conf /var/run/gnupg/S.dirmngr /var/lib/gnupg/

launching dirmngr instead as a system service with:

 dirmngr --homedir=/var/lib/gnupg

That could allow us to remove the system mode entirely and have the same
effect, i think.

> And I would not like to stray away from debian packaging so far as to
> still keep dirmngr started centrally as a service.

The current plan for the debian packaging is to remove dirmngr as a
system service after the release of jessie.  I'd be happy to add a new
binary package that sets up a system service using the above
configuration, if you want to help make sure it works for you, though.

>  b) The default should be the system wide config (if it exists) as this is for 
> the users that don't know what a dirmngr is. Those who know / care should be 
> able to overrule it.

Sure, but to do this approach properly, we should support the
chained/overriden pattern you describe above, since it's a reasonable,
established practice.

        --dkg


From wk at gnupg.org  Sun Jan 25 10:42:21 2015
From: wk at gnupg.org (Werner Koch)
Date: Sun, 25 Jan 2015 10:42:21 +0100
Subject: [PATCH] Remove incorrect expression leading to errors.
In-Reply-To: <1422029013-5769-1-git-send-email-git@internot.info> (Joshua
 Rogers's message of "Sat, 24 Jan 2015 03:03:33 +1100")
References: <1422029013-5769-1-git-send-email-git@internot.info>
Message-ID: <87d263b3i9.fsf@vigenere.g10code.de>

On Fri, 23 Jan 2015 17:03, git at internot.info said:
> * scd/ccid-driver.c: Variable 'rc' in send_escape_cmd was
> overwritten before it was returned, leading to incorrect
> computation.

Thanks.  Pushed to 2.0 and master.


Shalom-Salam,

   Werner

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



From git at internot.info  Sun Jan 25 19:30:32 2015
From: git at internot.info (Joshua Rogers)
Date: Mon, 26 Jan 2015 05:30:32 +1100
Subject: [PATCH] Remove incorrect expression leading to errors.
In-Reply-To: <87d263b3i9.fsf@vigenere.g10code.de>
References: <1422029013-5769-1-git-send-email-git@internot.info>
 <87d263b3i9.fsf@vigenere.g10code.de>
Message-ID: <54C53648.9040301@internot.info>

On 25/01/15 20:42, Werner Koch wrote:
> Thanks.  Pushed to 2.0 and master.
Any idea the implications of this? Doesn't look security related, but it
looks like it wouldn't report that the card is not present, or that it
is inactive, or it has too bit of a response(could this be sec related?
probably not)

I've never actually used cards for GPG before, so I have no idea.

Thanks!
-- 
-- Joshua Rogers <https://internot.info/>

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

From git at internot.info  Sun Jan 25 20:12:18 2015
From: git at internot.info (Joshua Rogers)
Date: Mon, 26 Jan 2015 06:12:18 +1100
Subject: [PATCH] Fix resource leak
Message-ID: <1422213138-4693-1-git-send-email-git@internot.info>

* kbx/keybox-update.c: Fix resource leak of in blob_filecopy
command. On return, it 'fp', and 'newfp' was never closed.

--

Signed-off-by: Joshua Rogers <git at internot.info>
---
 kbx/keybox-update.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/kbx/keybox-update.c b/kbx/keybox-update.c
index 11861ac..4be1377 100644
--- a/kbx/keybox-update.c
+++ b/kbx/keybox-update.c
@@ -340,8 +340,11 @@ blob_filecopy (int mode, const char *fname, KEYBOXBLOB blob,
   if ( mode == FILECOPY_INSERT || mode == FILECOPY_UPDATE )
     {
       rc = _keybox_write_blob (blob, newfp);
-      if (rc)
+      if (rc) {
+          fclose (fp);
+          fclose (newfp);
           return rc;
+      }
     }
 
   /* Copy the rest of the packet for an delete or update. */
-- 
1.9.1



From git at internot.info  Sun Jan 25 20:18:57 2015
From: git at internot.info (Joshua Rogers)
Date: Mon, 26 Jan 2015 06:18:57 +1100
Subject: [PATCH] Fix null pointer dereference
Message-ID: <1422213537-4885-1-git-send-email-git@internot.info>

* sm/certchain.c: Correctly check return value of strpbrk to
make sure null pointer dereferences do not occur.

--

'strpbrk' may return NULL.

Signed-off-by: Joshua Rogers <git at internot.info>
---
 sm/certchain.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sm/certchain.c b/sm/certchain.c
index 5e632f7..f720207 100644
--- a/sm/certchain.c
+++ b/sm/certchain.c
@@ -411,7 +411,7 @@ check_cert_policy (ksba_cert_t cert, int listmode, estream_t fplist)
       for (allowed=line; spacep (allowed); allowed++)
         ;
       p = strpbrk (allowed, " :\n");
-      if (!*p || p == allowed)
+      if (!p || p == allowed)
         {
           fclose (fp);
           xfree (policies);
-- 
1.9.1



From milan.kral at azet.sk  Sun Jan 25 21:16:53 2015
From: milan.kral at azet.sk (Milan Kral)
Date: Sun, 25 Jan 2015 21:16:53 +0100
Subject: Beyond Curve25519
In-Reply-To: <54B94949.1040707@sixdemonbag.org>
References: <54B7AA92.5070505@azet.sk> <20150115215333.03d707f6@pc>
 <1421383617.4984.4.camel@scientia.net> <54B94949.1040707@sixdemonbag.org>
Message-ID: <54C54F35.7090200@azet.sk>

http://cr.yp.to/papers.html#batchnfs

The cryptographic community reached consensus a decade ago that a
1024-bit RSA key can be broken in a year by an attack machine costing
significatly less than 10^9 dollars.

See:

- Adi Shamir, Eran Tromer, Factoring large numbers with the TWIRL
device, in Crypto 2003

- Arjen K. Lenstra, Eran Tromer, Adi Shamir, Wil Kortsmit, Bruce Dodson,
James Hughes, Paul C. Leyland, Factoring estimates for a 1024-bit RSA
modulus, in Asiacrypt 2003

- Willi Geiselmann, Adi Shamir, Rainer Steinwandt, Eran Tromer, Scalable
hardware for sparse systems of linear equations, with applications to
integer factorization, in CHES 2005

- Jens Franke, Thorsten Kleinjung, Christof Paar, Jan Pelzl, Christine
Priplata,Colin Stahlke, SHARK: a realizable special hardware sieving
device for factoring 1024-bit integers, in CHES 2005


On 16.01.2015 18:24, Robert J. Hansen wrote:
>> Funny... people told that as well with RSA key sizes which are 
>> nowadays no longer considered enough... o.O
> 
> Back in the early 1990s, a 1024-bit RSA key was believed to be unassailable.
> 
> A 1024-bit key is still today considered unassailable... it just doesn't
> have anywhere near the security margin that we want.  We advise at least
> 2048-bit keys to give us a comfortable margin, not because we believe
> people are breaking 1024-bit keys.
> 
> To give an idea: for distributed.net to exhaust a 64-shannon keyspace
> took them about five years.  They're currently working on exhausting a
> 72-shannon keyspace, which they project will take about 200 years.
> Exhausting an 80-shannon keyspace (about the same as a 1024-bit RSA key)
> would take about 5,000 years at that pace, or one year and 5,000 times
> the resources of distributed.net.
> 
> 1024-bit crypto is still strong today.  It's just not as strong as we'd
> like and we can do better with few side effects, so let's do better.  :)
> 
>> It's really disturbing to read such statements (i.e. "xxx bit 
>> security level will be secure forever - except for quantum 
>> computers)... it seems as nothing would have been learned from the 
>> past :-/
> 
> No one will ever exhaust a 128-shannon keyspace until we have
> large-scale quantum computers and a few decades in which to operate.
> 
> No one will ever exhaust a 256-shannon keyspace.  Ever.
> 
> 
> 
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
> 


From rjh at sixdemonbag.org  Sun Jan 25 21:57:44 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Sun, 25 Jan 2015 15:57:44 -0500
Subject: Beyond Curve25519
In-Reply-To: <54C54F35.7090200@azet.sk>
References: <54B7AA92.5070505@azet.sk> <20150115215333.03d707f6@pc>
 <1421383617.4984.4.camel@scientia.net> <54B94949.1040707@sixdemonbag.org>
 <54C54F35.7090200@azet.sk>
Message-ID: <54C558C8.1080205@sixdemonbag.org>

> The cryptographic community reached consensus a decade ago that a 
> 1024-bit RSA key can be broken in a year by an attack machine costing
> significatly less than 10^9 dollars.

Yes, but the idea of whether something is assailable involves more than
technical capability.  Economics comes into it.

Secrets tend to lose value over time.  In the early '60s my grandfather
had a secret recipe for venison stew that half the town wanted; today
you'd be hard-pressed to find anyone outside my family who even
remembers.  Even things like 1960s nuclear weapon designs have lost
their value.

So if you have a secret today, its worth a year from now needs to still
be high enough not just to warrant all the electricity bills from
running the keycracker for a year -- but it has to be higher than that
of every other RSA-1024 key which the attacker might also want to break.

I don't recommend using RSA-1024.  I'd rather trust "we have no idea how
to break this" than I would trust "we have no idea how to break this
cost-effectively."  But that said, unless you're trafficking in
extremely high-value secrets you're still safe with RSA-1024.

For today, at least.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3744 bytes
Desc: S/MIME Cryptographic Signature
URL: </pipermail/attachments/20150125/2e912190/attachment-0001.bin>

From gniibe at fsij.org  Mon Jan 26 03:02:20 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Mon, 26 Jan 2015 11:02:20 +0900
Subject: [PATCH] Remove incorrect expression leading to errors.
In-Reply-To: <54C53648.9040301@internot.info>
References: <1422029013-5769-1-git-send-email-git@internot.info>
 <87d263b3i9.fsf@vigenere.g10code.de> <54C53648.9040301@internot.info>
Message-ID: <54C5A02C.4070400@fsij.org>

Thank you for your patch.

On 01/26/2015 03:30 AM, Joshua Rogers wrote:
> On 25/01/15 20:42, Werner Koch wrote:
>> Thanks.  Pushed to 2.0 and master.
> Any idea the implications of this? Doesn't look security related, but it
> looks like it wouldn't report that the card is not present, or that it
> is inactive, or it has too bit of a response(could this be sec related?
> probably not)

The function send_escape_cmd is to send raw command to card readers
(at initialization time, basically).  Since commands to be sent is for
card readers (not cards), we should ignore card status.

The function is exposed by ccid_transceive_escape, but
ccid_transceive_escape is not used at all, in fact.  Thus, we only
need to check internal use of send_escape_cmd in ccid-driver.c.

The function calls are only possible for specific card readers of:

  VEGA_ALPHA, VENDOR_VEGA, VENDOR_CHERRY, VENDOR_GEMPC, VENDOR_SCM

For all of those calls, no return messages are expected.  If a reader
sends back some message (say, after upgraded firmware in future), it
was just ignored (before the patch of yours).  The impact at large
would be such a reader won't work any more, or our intended behavior
of pinpad won't work well.
-- 


From gniibe at fsij.org  Mon Jan 26 03:25:30 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Mon, 26 Jan 2015 11:25:30 +0900
Subject: agent: Fix agent_public_key_from_file for ECC
In-Reply-To: <878ugteewc.fsf@vigenere.g10code.de>
References: <54981864.7050005@fsij.org>
 <87wq5jstc7.fsf@vigenere.g10code.de>	<54982D3A.1040307@fsij.org>
 <549BBAFE.8010605@fsij.org>	<54AE0230.6080901@fsij.org>
 <87fvb4u639.fsf@alice.fifthhorseman.net> <878ugteewc.fsf@vigenere.g10code.de>
Message-ID: <54C5A59A.7070006@fsij.org>

On 01/23/2015 11:43 PM, Werner Koch wrote:
> On Wed, 21 Jan 2015 05:10, dkg at fifthhorseman.net said:
> 
>> fwiw, I don't think that GnuPG should support arbitrary curves with
>> parameters.  Group choice is a tricky and contentious issue, and GnuPG
> 
> I concur.

So, here is the patch of the first part.

OK to commit?

	* agent/cvt-openpgp.c (extract_private_key): New.
	(convert_to_openpgp): Use extract_private_key.
	* agent/findkey.c (agent_public_key_from_file): Use
	extract_private_key.

	--
	
	This patch add support of ECC key with a curve name and flags.  Since
	same functionality is also needed for convert_to_openpgp, it was
	factored out into the extract_private_key function.

---
 agent/agent.h       |   7 +++
 agent/cvt-openpgp.c | 161 +++++++++++++++++++++++++++++++++++++++-------------
 agent/findkey.c     |  77 ++++++++-----------------
 3 files changed, 151 insertions(+), 94 deletions(-)

diff --git a/agent/agent.h b/agent/agent.h
index 4be5925..0560835 100644
--- a/agent/agent.h
+++ b/agent/agent.h
@@ -497,4 +497,11 @@ int agent_card_scd (ctrl_t ctrl, const char *cmdline,
 int agent_handle_learn (ctrl_t ctrl, int send, void *assuan_context);


+/*-- cvt-openpgp.c --*/
+gpg_error_t
+extract_private_key (gcry_sexp_t s_key, int req_private_key_data,
+                     const char **r_algoname, int *r_npkey, int *r_nskey,
+                     const char **r_format, gcry_mpi_t *mpi_array,
+                     gcry_sexp_t *r_curve, gcry_sexp_t *r_flags);
+
 #endif /*AGENT_H*/
diff --git a/agent/cvt-openpgp.c b/agent/cvt-openpgp.c
index 671dd4c..dff6b7c 100644
--- a/agent/cvt-openpgp.c
+++ b/agent/cvt-openpgp.c
@@ -1177,36 +1177,50 @@ apply_protection (gcry_mpi_t *array, int npkey, int nskey,
 }


-/* Convert our key S_KEY into an OpenPGP key transfer format.  On
-   success a canonical encoded S-expression is stored at R_TRANSFERKEY
-   and its length at R_TRANSFERKEYLEN; this S-expression is also
-   padded to a multiple of 64 bits.  */
+/*
+ * Examining S_KEY in S-Expression and extract data.
+ * When REQ_PRIVATE_KEY_DATA == 1, S_KEY's CAR should be 'private-key',
+ * but it also allows shadowed or protected versions.
+ * On success, it returns 0, otherwise error number.
+ * R_ALGONAME is static string which is no need to free by caller.
+ * R_NPKEY is pointer to number of public key data.
+ * R_NSKEY is pointer to number of private key data.
+ * R_ELEMS is static string which is no need to free by caller.
+ * ARRAY contains public and private key data.
+ * R_CURVE is pointer to S-Expression of the curve (can be NULL).
+ * R_FLAGS is pointer to S-Expression of the flags (can be NULL).
+ */
 gpg_error_t
-convert_to_openpgp (ctrl_t ctrl, gcry_sexp_t s_key, const char *passphrase,
-                    unsigned char **r_transferkey, size_t *r_transferkeylen)
+extract_private_key (gcry_sexp_t s_key, int req_private_key_data,
+                     const char **r_algoname, int *r_npkey, int *r_nskey,
+                     const char **r_elems, gcry_mpi_t *array,
+                     gcry_sexp_t *r_curve, gcry_sexp_t *r_flags)
 {
   gpg_error_t err;
   gcry_sexp_t list, l2;
   char *name;
-  const char *algoname;
+  const char *algoname, *format;
   int npkey, nskey;
-  gcry_mpi_t array[10];
   gcry_sexp_t curve = NULL;
-  char protect_iv[16];
-  char salt[8];
-  unsigned long s2k_count;
-  int i, j;
+  gcry_sexp_t flags = NULL;

-  (void)ctrl;
-
-  *r_transferkey = NULL;
-
-  for (i=0; i < DIM (array); i++)
-    array[i] = NULL;
+  if (!req_private_key_data)
+    {
+      list = gcry_sexp_find_token (s_key, "shadowed-private-key", 0 );
+      if (!list)
+        list = gcry_sexp_find_token (s_key, "protected-private-key", 0 );
+      if (!list)
+        list = gcry_sexp_find_token (s_key, "private-key", 0 );
+    }
+  else
+    list = gcry_sexp_find_token (s_key, "private-key", 0);

-  list = gcry_sexp_find_token (s_key, "private-key", 0);
   if (!list)
-    return gpg_error (GPG_ERR_NO_OBJ); /* Does not contain a key object.  */
+    {
+      log_error ("invalid private key format\n");
+      return gpg_error (GPG_ERR_BAD_SECKEY);
+    }
+
   l2 = gcry_sexp_cadr (list);
   gcry_sexp_release (list);
   list = l2;
@@ -1224,66 +1238,81 @@ convert_to_openpgp (ctrl_t ctrl, gcry_sexp_t s_key, const char *passphrase,
   if (!strcmp (name, "rsa"))
     {
       algoname = "rsa";
+      format = "ned?p?q?u?";
       npkey = 2;
       nskey = 6;
-      err = gcry_sexp_extract_param (list, NULL, "nedpqu",
+      err = gcry_sexp_extract_param (list, NULL, format,
                                      array+0, array+1, array+2, array+3,
                                      array+4, array+5, NULL);
     }
   else if (!strcmp (name, "elg"))
     {
       algoname = "elg";
+      format = "pgyx?";
       npkey = 3;
       nskey = 4;
-      err = gcry_sexp_extract_param (list, NULL, "pgyx",
+      err = gcry_sexp_extract_param (list, NULL, format,
                                      array+0, array+1, array+2, array+3,
                                      NULL);
     }
   else if (!strcmp (name, "dsa"))
     {
       algoname = "dsa";
+      format = "pqgyx?";
       npkey = 4;
       nskey = 5;
-      err = gcry_sexp_extract_param (list, NULL, "pqgyx",
+      err = gcry_sexp_extract_param (list, NULL, format,
                                      array+0, array+1, array+2, array+3,
                                      array+4, NULL);
     }
   else if (!strcmp (name, "ecc"))
     {
-      gcry_buffer_t iob;
-      char iobbuf[32];
-
-      algoname = "ecc"; /* Decide later by checking the usage.  */
+      algoname = "ecc";
+      format = "/qd?";
       npkey = 1;
       nskey = 2;
-      iob.data = iobbuf;
-      iob.size = sizeof iobbuf - 1;
-      iob.off = 0;
-      iob.len = 0;
-      err = gcry_sexp_extract_param (list, NULL, "&'curve'/qd",
-                                     &iob, array+0, array+1, NULL);
-      if (!err)
+      curve = gcry_sexp_find_token (list, "curve", 0);
+      flags = gcry_sexp_find_token (list, "flags", 0);
+      err = gcry_sexp_extract_param (list, NULL, format,
+                                     array+0, array+1, NULL);
+      if (flags)
         {
-          assert (iob.len < sizeof iobbuf -1);
-          iobbuf[iob.len] = 0;
-          err = gcry_sexp_build (&curve, NULL, "(curve %s)", iobbuf);
+          gcry_sexp_t param = gcry_sexp_find_token (flags, "param", 0);
+          if (param)
+            {
+              gcry_sexp_release (param);
+              array[6] = array[0];
+              array[7] = array[1];
+              err = gcry_sexp_extract_param (list, NULL, "pabgnh?",
+                                             array+0, array+1, array+2, array+3,
+                                             array+4, array+5, NULL);
+              if (array[5] == NULL)
+                {
+                  array[5] = GCRYMPI_CONST_ONE;
+                  npkey += 6;
+                  nskey += 6;
+                }
+              format = "pabgnhqd?";
+            }
         }
     }
   else if (!strcmp (name, "ecdsa"))
     {
       algoname = "ecdsa";
+      format = "pabgnqd?";
       npkey = 6;
       nskey = 7;
-      err = gcry_sexp_extract_param (list, NULL, "pabgnqd",
+      err = gcry_sexp_extract_param (list, NULL, format,
                                      array+0, array+1, array+2, array+3,
                                      array+4, array+5, array+6, NULL);
     }
   else if (!strcmp (name, "ecdh"))
     {
       algoname = "ecdh";
+      format = "pabgnqd?";
       npkey = 6;
       nskey= 7;
-      err = gcry_sexp_extract_param (list, NULL, "pabgnqd",
+      err = gcry_sexp_extract_param (list, NULL, format,
                                      array+0, array+1, array+2, array+3,
                                      array+4, array+5, array+6, NULL);
     }
@@ -1292,12 +1321,63 @@ convert_to_openpgp (ctrl_t ctrl, gcry_sexp_t s_key, const char *passphrase,
       err = gpg_error (GPG_ERR_PUBKEY_ALGO);
     }
   xfree (name);
-  gcry_sexp_release (list); list = NULL;
+  gcry_sexp_release (list);
   if (err)
     {
       gcry_sexp_release (curve);
+      gcry_sexp_release (flags);
       return err;
     }
+  else
+    {
+      *r_algoname = algoname;
+      if (r_elems)
+        {
+          if (format[0] == '/') /* It is opaque data qualifier, skip it.  */
+            *r_elems = format+1;
+          else
+            *r_elems = format;
+        }
+      *r_npkey = npkey;
+      if (r_nskey)
+        *r_nskey = nskey;
+      *r_curve = curve;
+      *r_flags = flags;
+
+      return 0;
+    }
+}
+
+/* Convert our key S_KEY into an OpenPGP key transfer format.  On
+   success a canonical encoded S-expression is stored at R_TRANSFERKEY
+   and its length at R_TRANSFERKEYLEN; this S-expression is also
+   padded to a multiple of 64 bits.  */
+gpg_error_t
+convert_to_openpgp (ctrl_t ctrl, gcry_sexp_t s_key, const char *passphrase,
+                    unsigned char **r_transferkey, size_t *r_transferkeylen)
+{
+  gpg_error_t err;
+  const char *algoname;
+  int npkey, nskey;
+  gcry_mpi_t array[10];
+  gcry_sexp_t curve = NULL;
+  gcry_sexp_t flags = NULL;
+  char protect_iv[16];
+  char salt[8];
+  unsigned long s2k_count;
+  int i, j;
+
+  (void)ctrl;
+
+  *r_transferkey = NULL;
+
+  for (i=0; i < DIM (array); i++)
+    array[i] = NULL;
+
+  err = extract_private_key (s_key, 1, &algoname, &npkey, &nskey, NULL,
+                             array, &curve, &flags);
+  if (err)
+    return err;

   gcry_create_nonce (protect_iv, sizeof protect_iv);
   gcry_create_nonce (salt, sizeof salt);
@@ -1363,6 +1443,7 @@ convert_to_openpgp (ctrl_t ctrl, gcry_sexp_t s_key, const char *passphrase,
   for (i=0; i < DIM (array); i++)
     gcry_mpi_release (array[i]);
   gcry_sexp_release (curve);
+  gcry_sexp_release (flags);

   return err;
 }
diff --git a/agent/findkey.c b/agent/findkey.c
index fbe3031..064f7d2 100644
--- a/agent/findkey.c
+++ b/agent/findkey.c
@@ -978,18 +978,20 @@ agent_public_key_from_file (ctrl_t ctrl,
   gpg_error_t err;
   int i, idx;
   gcry_sexp_t s_skey;
-  char algoname[6];
-  char elems[7];
+  const char *algoname, *elems;
+  int npkey;
+  gcry_mpi_t array[10];
+  gcry_sexp_t curve = NULL;
+  gcry_sexp_t flags = NULL;
   gcry_sexp_t uri_sexp, comment_sexp;
   const char *uri, *comment;
   size_t uri_length, comment_length;
   char *format, *p;
-  void *args[4+2+2+1]; /* Size is max. # of elements + 2 for uri + 2
-                           for comment + end-of-list.  */
+  void *args[2+7+2+2+1]; /* Size is 2 + max. # of elements + 2 for uri + 2
+                            for comment + end-of-list.  */
   int argidx;
-  gcry_sexp_t list, l2;
+  gcry_sexp_t list = NULL;
   const char *s;
-  gcry_mpi_t *array;

   (void)ctrl;

@@ -999,55 +1001,17 @@ agent_public_key_from_file (ctrl_t ctrl,
   if (err)
     return err;

-  err = key_parms_from_sexp (s_skey, &list,
-                            algoname, sizeof algoname,
-                            elems, sizeof elems);
-  if (err)
-    {
-      gcry_sexp_release (s_skey);
-      return err;
-    }
+  for (i=0; i < DIM (array); i++)
+    array[i] = NULL;

-  /* Allocate an array for the parameters and copy them out of the
-     secret key.   FIXME: We should have a generic copy function. */
-  array = xtrycalloc (strlen(elems) + 1, sizeof *array);
-  if (!array)
+  err = extract_private_key (s_skey, 0, &algoname, &npkey, NULL, &elems,
+                             array, &curve, &flags);
+  if (err)
     {
-      err = gpg_error_from_syserror ();
-      gcry_sexp_release (list);
       gcry_sexp_release (s_skey);
       return err;
     }

-  for (idx=0, s=elems; *s; s++, idx++ )
-    {
-      l2 = gcry_sexp_find_token (list, s, 1);
-      if (!l2)
-        {
-          /* Required parameter not found.  */
-          for (i=0; i<idx; i++)
-            gcry_mpi_release (array[i]);
-          xfree (array);
-          gcry_sexp_release (list);
-          gcry_sexp_release (s_skey);
-          return gpg_error (GPG_ERR_BAD_SECKEY);
-	}
-      array[idx] = gcry_sexp_nth_mpi (l2, 1, GCRYMPI_FMT_USG);
-      gcry_sexp_release (l2);
-      if (!array[idx])
-        {
-          /* Required parameter is invalid. */
-          for (i=0; i<idx; i++)
-            gcry_mpi_release (array[i]);
-          xfree (array);
-          gcry_sexp_release (list);
-          gcry_sexp_release (s_skey);
-          return gpg_error (GPG_ERR_BAD_SECKEY);
-	}
-    }
-  gcry_sexp_release (list);
-  list = NULL;
-
   uri = NULL;
   uri_length = 0;
   uri_sexp = gcry_sexp_find_token (s_skey, "uri", 0);
@@ -1072,13 +1036,14 @@ agent_public_key_from_file (ctrl_t ctrl,
      them.  */
   assert (sizeof (size_t) <= sizeof (void*));

-  format = xtrymalloc (15+7*strlen (elems)+10+15+1+1);
+  format = xtrymalloc (15+4+7*npkey+10+15+1+1);
   if (!format)
     {
       err = gpg_error_from_syserror ();
       for (i=0; array[i]; i++)
         gcry_mpi_release (array[i]);
-      xfree (array);
+      gcry_sexp_release (curve);
+      gcry_sexp_release (flags);
       gcry_sexp_release (uri_sexp);
       gcry_sexp_release (comment_sexp);
       return err;
@@ -1086,10 +1051,13 @@ agent_public_key_from_file (ctrl_t ctrl,

   argidx = 0;
   p = stpcpy (stpcpy (format, "(public-key("), algoname);
-  for (idx=0, s=elems; *s; s++, idx++ )
+  p = stpcpy (p, "%S%S");       /* curve name and flags.  */
+  args[argidx++] = &curve;
+  args[argidx++] = &flags;
+  for (idx=0, s=elems; idx < npkey; idx++)
     {
       *p++ = '(';
-      *p++ = *s;
+      *p++ = *s++;
       p = stpcpy (p, " %m)");
       assert (argidx < DIM (args));
       args[argidx++] = &array[idx];
@@ -1118,7 +1086,8 @@ agent_public_key_from_file (ctrl_t ctrl,
   xfree (format);
   for (i=0; array[i]; i++)
     gcry_mpi_release (array[i]);
-  xfree (array);
+  gcry_sexp_release (curve);
+  gcry_sexp_release (flags);
   gcry_sexp_release (uri_sexp);
   gcry_sexp_release (comment_sexp);

-- 
2.1.3


From milan.kral at azet.sk  Mon Jan 26 08:56:41 2015
From: milan.kral at azet.sk (Milan Kral)
Date: Mon, 26 Jan 2015 08:56:41 +0100
Subject: Beyond Curve25519
In-Reply-To: <54B94949.1040707@sixdemonbag.org>
References: <54B7AA92.5070505@azet.sk> <20150115215333.03d707f6@pc>
 <1421383617.4984.4.camel@scientia.net> <54B94949.1040707@sixdemonbag.org>
Message-ID: <54C5F339.8060402@azet.sk>



On 16.01.2015 18:24, Robert J. Hansen wrote:
>> Funny... people told that as well with RSA key sizes which are 
>> nowadays no longer considered enough... o.O
> 
> Back in the early 1990s, a 1024-bit RSA key was believed to be unassailable.
> 
> A 1024-bit key is still today considered unassailable... it just doesn't
> have anywhere near the security margin that we want.  We advise at least
> 2048-bit keys to give us a comfortable margin, not because we believe
> people are breaking 1024-bit keys.

"A 1024-bit key is still today considered unassailable" depends on how
much do you value the security of your information.

For example according to
https://www.cs.tau.ac.il/~tromer/papers/cbtwirl.pdf

"We presented a new design for a custom-
built hardware implementation of the sieving step,
which relies on algorithms that are highly tuned for
the available technology. With appropriate settings of
the NFS parameters, this design reduces the cost of
sieving to about $10M (plus a one-time cost of $20M).
Recent works [14, 9] indicate that for these NFS pa-
rameters, the cost of the matrix step is even lower."

> 
> To give an idea: for distributed.net to exhaust a 64-shannon keyspace
> took them about five years.  They're currently working on exhausting a
> 72-shannon keyspace, which they project will take about 200 years.
> Exhausting an 80-shannon keyspace (about the same as a 1024-bit RSA key)
> would take about 5,000 years at that pace, or one year and 5,000 times
> the resources of distributed.net.
> 
> 1024-bit crypto is still strong today.  It's just not as strong as we'd
> like and we can do better with few side effects, so let's do better.  :)
> 
>> It's really disturbing to read such statements (i.e. "xxx bit 
>> security level will be secure forever - except for quantum 
>> computers)... it seems as nothing would have been learned from the 
>> past :-/
> 
> No one will ever exhaust a 128-shannon keyspace until we have
> large-scale quantum computers and a few decades in which to operate.
> 
> No one will ever exhaust a 256-shannon keyspace.  Ever.
> 
> 
> 
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
> 


From wk at gnupg.org  Mon Jan 26 11:29:28 2015
From: wk at gnupg.org (Werner Koch)
Date: Mon, 26 Jan 2015 11:29:28 +0100
Subject: [PATCH] Fix null pointer dereference
In-Reply-To: <1422213537-4885-1-git-send-email-git@internot.info> (Joshua
 Rogers's message of "Mon, 26 Jan 2015 06:18:57 +1100")
References: <1422213537-4885-1-git-send-email-git@internot.info>
Message-ID: <87vbjt96nr.fsf@vigenere.g10code.de>

On Sun, 25 Jan 2015 20:18, git at internot.info said:

> 'strpbrk' may return NULL.

But not here because the do--while guarantees that LINE is terminated by
a LF and thus after that do-while

>        for (allowed=line; spacep (allowed); allowed++)
>          ;
>        p = strpbrk (allowed, " :\n");
> -      if (!*p || p == allowed)
> +      if (!p || p == allowed)

the strpbrk will at least detect the LF and thus never return a NULL.


Salam-Shalom,

   Werner

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



From aheinecke at intevation.de  Mon Jan 26 12:17:25 2015
From: aheinecke at intevation.de (Andre Heinecke)
Date: Mon, 26 Jan 2015 12:17:25 +0100
Subject: System wide dirmngr configuration with Gnupg 2.1
In-Reply-To: <873871l8hw.fsf@alice.fifthhorseman.net>
References: <7757034.xtvict5H27@esus> <10857837.gJyTAmyjgT@esus>
 <873871l8hw.fsf@alice.fifthhorseman.net>
Message-ID: <1622726.hNCageQmvt@esus>

Hi,

On Friday, January 23, 2015 12:19:55 PM Daniel Kahn Gillmor wrote:
> On Fri 2015-01-23 05:14:22 -0500, Andre Heinecke wrote:
> > Yes, I agree with you there. I don't want to force users to this
> > configuration. Users that have a reason could still start a dirmngr with
> > --homedir ~/.gnupg.
> except that it's automatically launched, as you pointed out :/
> 
> > But maybe it really would be better to have dirmngr read the trusted-certs
> > from the sysconfig dir and also from the homedir.
> > 
> > Like:
> > If --homedir is not explicitly set: Read trusted-certs / config from
> > sysconfig dir. Afterwards read trusted-certs / config from homedir and
> > prefer the values from the homedir. This would be more similar to
> > freedesktops config_dirs / config_home handling.
> 
> This is is a pretty common configuration pattern for other (non-gnupg)
> tools.  In fact, i've often wished for it for gnupg itself, so that
> sysadmins could tweak a generic /etc/gnupg/gpg.conf for all their users.
> Is there a specific reason why gpg doesn't support this configuration
> pattern?

Werner? Could you comment on this?

> >  a) I'm not sure if werner plans to support the system-wide mode forever.
> 
> The main difference of the system mode is its use of a modified/split
> directory layout that meets the LFS requirements, right?

I'd say that the main difference is that it runs as root / special user and is 
shared by multiple users.

> Couldn't this also be done with:
> 
>  mkdir -p /var/lib/gnupg/extra-certs /etc/gnupg /var/cache/gnupg/crls.d
> /var/run/gnupg ln -s /var/cache/gnupg/crls.d  /etc/gnupg/dirmngr.conf
> /var/run/gnupg/S.dirmngr /var/lib/gnupg/
> 
> launching dirmngr instead as a system service with:
> 
>  dirmngr --homedir=/var/lib/gnupg
> 
> That could allow us to remove the system mode entirely and have the same
> effect, i think. 

Still this would mean that multiple users share a dirmngr service. This is 
what I'd like to avoid as this is no longer the usual case and might create 
new bugs that are not tested in the usual setup. This setup might also not be 
robust enough. E.g. If this service is unreachable new dirmngr processes are 
automatically started (well we could configure this out too) and you get 
different behavior. 

Basically I like the Idea of a dirmngr that is started on demand and runs in 
the user's context. 

> > And I would not like to stray away from debian packaging so far as to
> > still keep dirmngr started centrally as a service.
> 
> The current plan for the debian packaging is to remove dirmngr as a
> system service after the release of jessie.  I'd be happy to add a new
> binary package that sets up a system service using the above
> configuration, if you want to help make sure it works for you, though.

Thanks. But I'm still hoping that we can avoid packaging a Different Mode.  :-)
 
> >  b) The default should be the system wide config (if it exists) as this is
> >  for> 
> > the users that don't know what a dirmngr is. Those who know / care should
> > be able to overrule it.
> 
> Sure, but to do this approach properly, we should support the
> chained/overriden pattern you describe above, since it's a reasonable,
> established practice.

Right. I think this is the best approach at least for trusted CA's. As it's 
standard practice to have them defined on a system level first and then merge 
those with the users choices.

A generic mechanism for all config files would be nice to have but this is 
probably too intrusive. We could work around this by creating a 
dirmngr_ldapservers.conf in the homedir of all users and adding it to the 
skeleton config. This is not worse then the current way to configure e.g. a 
keyserver in gnupg.

Regards,
Andre

-- 
Andre Heinecke |  ++49-541-335083-262  |  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20150126/534b65a3/attachment-0001.sig>

From wk at gnupg.org  Mon Jan 26 17:59:18 2015
From: wk at gnupg.org (Werner Koch)
Date: Mon, 26 Jan 2015 17:59:18 +0100
Subject: [patch] wipe secure memory after iconv failure
In-Reply-To: <877fwgu4ar.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Tue, 20 Jan 2015 23:49:00 -0500")
References: <OrQgYqUfYMIRGaZAZ8zCII/iqWk@fZuiaDBWAX3Nuww6t5uQq3AO1vY>
 <877fwgu4ar.fsf@alice.fifthhorseman.net>
Message-ID: <87zj957a1l.fsf@vigenere.g10code.de>

On Wed, 21 Jan 2015 05:49, dkg at fifthhorseman.net said:

> From: Eygene Ryabinkin <rea at codelabs.ru>
> Date: Mon, 5 Jan 2015 02:38:11 +0300
> Subject: [PATCH] Apply secure wipe after iconv failure
>
> Iconv conversion can fail in the middle of operation, so "pwbuf"
> can have some parts of the password, so it is safer to clean it

Right; but ...


>            log_error ("error converting passphrase to"
>                       " requested charset '%s': %s\n",
>                       charset, strerror (errno));
> -          gcry_free (pwbuf);
> -          pwbuf = NULL;

PWBUF has been allocated using 

      pwbuf = gcry_malloc_secure (pwbufsize);

and thus it has been allocated in secure memory.  Even if it is
questionable whether that mlock()ed memory area is still useful, it has
the property that gcry_free  will overwrite the allocated memory.  The
secure memory allocator knows about the size and thus there is no need
to for the application to keep track of it.

The wipememory at 

  if (pwbuf)
    {
      wipememory (pwbuf, pwbufsize);
      gcry_free (pwbuf);
    }

is just a failsafe method in case the code is being used with an
improper memory allocator.  We could just remove that wipememory.

However your fix removes code which is is a good idea anyway and thus I
will use that (commit 6c87d1c).  Thanks.



Shalom-Salam,

   Werner

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



From wk at gnupg.org  Mon Jan 26 18:17:19 2015
From: wk at gnupg.org (Werner Koch)
Date: Mon, 26 Jan 2015 18:17:19 +0100
Subject: agent: Fix agent_public_key_from_file for ECC
In-Reply-To: <54C5A59A.7070006@fsij.org> (NIIBE Yutaka's message of "Mon, 26
 Jan 2015 11:25:30 +0900")
References: <54981864.7050005@fsij.org> <87wq5jstc7.fsf@vigenere.g10code.de>
 <54982D3A.1040307@fsij.org> <549BBAFE.8010605@fsij.org>
 <54AE0230.6080901@fsij.org> <87fvb4u639.fsf@alice.fifthhorseman.net>
 <878ugteewc.fsf@vigenere.g10code.de> <54C5A59A.7070006@fsij.org>
Message-ID: <87ioft797k.fsf@vigenere.g10code.de>

On Mon, 26 Jan 2015 03:25, gniibe at fsij.org said:

> So, here is the patch of the first part.
>
> OK to commit?

I have not checked it but I think it is okay to commit.  I will run some
tests on it this week.


Shalom-Salam,

   Werner

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



From gniibe at fsij.org  Tue Jan 27 01:35:23 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 27 Jan 2015 09:35:23 +0900
Subject: agent: Fix agent_public_key_from_file for ECC
In-Reply-To: <87ioft797k.fsf@vigenere.g10code.de>
References: <54981864.7050005@fsij.org>
 <87wq5jstc7.fsf@vigenere.g10code.de>	<54982D3A.1040307@fsij.org>
 <549BBAFE.8010605@fsij.org>	<54AE0230.6080901@fsij.org>
 <87fvb4u639.fsf@alice.fifthhorseman.net>	<878ugteewc.fsf@vigenere.g10code.de>
 <54C5A59A.7070006@fsij.org> <87ioft797k.fsf@vigenere.g10code.de>
Message-ID: <54C6DD4B.2070102@fsij.org>

On 01/27/2015 02:17 AM, Werner Koch wrote:
> I have not checked it but I think it is okay to commit.  I will run some
> tests on it this week.

Pushed.  Any problem will be found, I'll do my best.

... actually, I already have found a bug in scdaemon for 64-bit
architecture when we use ECC.  I'm going submit a patch today.
-- 


From gniibe at fsij.org  Tue Jan 27 03:49:58 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 27 Jan 2015 11:49:58 +0900
Subject: scd: Fix varargs call for 64-bit arch on ECC keys
Message-ID: <54C6FCD6.8030807@fsij.org>

Hello,

Here is the bug I found.  Thanks to Bertrand for catching this bug.

    * scd/app-openpgp.c (store_fpr): Remove CARD_VERSION from the
    arguments.
    (rsa_writekey): Follow the change.
    (do_genkey): Likewise.
    (ecc_writekey): Likewise.  Add suffix 'L' for constant of size_t.

    --

    KEYTOCARD caused SEGV of scdaemon on 64-bit arch.  That's because
    int is 32-bit, but size_t is 64-bit.

diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c
index 7f1ec43..1e3ce76 100644
--- a/scd/app-openpgp.c
+++ b/scd/app-openpgp.c
@@ -755,10 +755,8 @@ get_algo_byte (int keynumber, key_type_t key_type)

 /* Note, that FPR must be at least 20 bytes. */
 static gpg_error_t
-store_fpr (app_t app, int keynumber, u32 timestamp,
-           unsigned char *fpr, unsigned int card_version,
-           key_type_t key_type,
-           ...)
+store_fpr (app_t app, int keynumber, u32 timestamp, unsigned char *fpr,
+           key_type_t key_type, ...)
 {
   unsigned int n, nbits;
   unsigned char *buffer, *p;
@@ -821,7 +819,7 @@ store_fpr (app_t app, int keynumber, u32 timestamp,

   xfree (buffer);

-  tag = (card_version > 0x0007? 0xC7 : 0xC6) + keynumber;
+  tag = (app->card_version > 0x0007? 0xC7 : 0xC6) + keynumber;
   flush_cache_item (app, 0xC5);
   tag2 = 0xCE + keynumber;
   flush_cache_item (app, 0xCD);
@@ -830,7 +828,7 @@ store_fpr (app_t app, int keynumber, u32 timestamp,
   if (rc)
     log_error (_("failed to store the fingerprint: %s\n"),gpg_strerror (rc));

-  if (!rc && card_version > 0x0100)
+  if (!rc && app->card_version > 0x0100)
     {
       unsigned char buf[4];

@@ -3196,8 +3194,8 @@ rsa_writekey (app_t app, gpg_error_t (*pincb)(void*, const char *, char **),
       goto leave;
     }

-  err = store_fpr (app, keyno, created_at, fprbuf, app->card_version,
-                   KEY_TYPE_RSA, rsa_n, rsa_n_len, rsa_e, rsa_e_len);
+  err = store_fpr (app, keyno, created_at, fprbuf, KEY_TYPE_RSA,
+                   rsa_n, rsa_n_len, rsa_e, rsa_e_len);
   if (err)
     goto leave;

@@ -3383,16 +3381,16 @@ ecc_writekey (app_t app, gpg_error_t (*pincb)(void*, const char *, char **),
       goto leave;
     }

-  err = store_fpr (app, keyno, created_at, fprbuf, app->card_version,
+  err = store_fpr (app, keyno, created_at, fprbuf,
                    curve == CURVE_ED25519 ? KEY_TYPE_EDDSA : KEY_TYPE_ECC,
                    curve == CURVE_ED25519 ?
                    "\x09\x2b\x06\x01\x04\x01\xda\x47\x0f\x01"
                    : curve == CURVE_NIST_P256 ?
                    "\x08\x2a\x86\x48\xce\x3d\x03\x01\x07"
                    : "\x05\x2b\x81\x04\x00\x0a",
-                   curve == CURVE_ED25519 ? 10
-                   : curve == CURVE_NIST_P256? 9 : 6,
-                   ecc_q, ecc_q_len, "\x03\x01\x08\x07", 4);
+                   curve == CURVE_ED25519 ? 10L
+                   : curve == CURVE_NIST_P256? 9L : 6L,
+                   ecc_q, ecc_q_len, "\x03\x01\x08\x07", 4L);
   if (err)
     goto leave;

@@ -3604,8 +3602,8 @@ do_genkey (app_t app, ctrl_t ctrl,  const char *keynostr, unsigned int flags,
   send_status_info (ctrl, "KEY-CREATED-AT",
                     numbuf, (size_t)strlen(numbuf), NULL, 0);

-  rc = store_fpr (app, keyno, (u32)created_at, fprbuf, app->card_version,
-                  KEY_TYPE_RSA, m, mlen, e, elen);
+  rc = store_fpr (app, keyno, (u32)created_at, fprbuf, KEY_TYPE_RSA,
+                  m, mlen, e, elen);
   if (rc)
     goto leave;
   send_fpr_if_not_null (ctrl, "KEY-FPR", -1, fprbuf);
--


From wk at gnupg.org  Tue Jan 27 11:21:35 2015
From: wk at gnupg.org (Werner Koch)
Date: Tue, 27 Jan 2015 11:21:35 +0100
Subject: scd: Fix varargs call for 64-bit arch on ECC keys
In-Reply-To: <54C6FCD6.8030807@fsij.org> (NIIBE Yutaka's message of "Tue, 27
 Jan 2015 11:49:58 +0900")
References: <54C6FCD6.8030807@fsij.org>
Message-ID: <87vbjs1q34.fsf@vigenere.g10code.de>

On Tue, 27 Jan 2015 03:49, gniibe at fsij.org said:

>     (ecc_writekey): Likewise.  Add suffix 'L' for constant of size_t.

'L' indicates a long but we need a size_t.  On 64 bit Windows we have

  sizeof(int)    == 4
  sizeof(long)   == 4
  sizeof(size_t) == 8

thus using

  curve == CURVE_ED25519 ? (size_t)10
  : curve == CURVE_NIST_P256? (size_t)9 : (size_t)6,
  ecc_q, ecc_q_len, "\x03\x01\x08\x07", (size_t)4);

would be correct.  Or we change store_fpr to take an int.


Salam-Shalom,

   Werner

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



From gniibe at fsij.org  Tue Jan 27 13:05:34 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 27 Jan 2015 21:05:34 +0900
Subject: scd: Fix varargs call for 64-bit arch on ECC keys
In-Reply-To: <87vbjs1q34.fsf@vigenere.g10code.de>
References: <54C6FCD6.8030807@fsij.org> <87vbjs1q34.fsf@vigenere.g10code.de>
Message-ID: <54C77F0E.3040501@fsij.org>

On 01/27/2015 07:21 PM, Werner Koch wrote:
> 'L' indicates a long but we need a size_t.  On 64 bit Windows we have
> 
>   sizeof(int)    == 4
>   sizeof(long)   == 4
>   sizeof(size_t) == 8
> 
> thus using
> 
>   curve == CURVE_ED25519 ? (size_t)10
>   : curve == CURVE_NIST_P256? (size_t)9 : (size_t)6,
>   ecc_q, ecc_q_len, "\x03\x01\x08\x07", (size_t)4);
> 
> would be correct.  Or we change store_fpr to take an int.

My badness.  I only considered LP64 model and didn't consider LLP64
model.

If we change store_fpr to take an int, we need to change the calls for
RSA by casting int.  I'd like to choose less typing.

Not only casting, but OID hard coding and hash/cipher algo hard coding
also look bad.  I will update this code, when I will add Curve25519
support.

Meanwhile, here is updated patch.  OK to commit?


    scd: Fix varargs call for 64-bit arch on ECC keys.

    * scd/app-openpgp.c (store_fpr): Remove CARD_VERSION from the
    arguments.
    (rsa_writekey): Follow the change.
    (do_genkey): Likewise.
    (ecc_writekey): Likewise.  Cast to size_t.

    --

    KEYTOCARD caused SEGV of scdaemon on 64-bit arch.  That's because
    int is 32-bit, but size_t is 64-bit.

diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c
index 7f1ec43..f68813b 100644
--- a/scd/app-openpgp.c
+++ b/scd/app-openpgp.c
@@ -755,10 +755,8 @@ get_algo_byte (int keynumber, key_type_t key_type)

 /* Note, that FPR must be at least 20 bytes. */
 static gpg_error_t
-store_fpr (app_t app, int keynumber, u32 timestamp,
-           unsigned char *fpr, unsigned int card_version,
-           key_type_t key_type,
-           ...)
+store_fpr (app_t app, int keynumber, u32 timestamp, unsigned char *fpr,
+           key_type_t key_type, ...)
 {
   unsigned int n, nbits;
   unsigned char *buffer, *p;
@@ -821,7 +819,7 @@ store_fpr (app_t app, int keynumber, u32 timestamp,

   xfree (buffer);

-  tag = (card_version > 0x0007? 0xC7 : 0xC6) + keynumber;
+  tag = (app->card_version > 0x0007? 0xC7 : 0xC6) + keynumber;
   flush_cache_item (app, 0xC5);
   tag2 = 0xCE + keynumber;
   flush_cache_item (app, 0xCD);
@@ -830,7 +828,7 @@ store_fpr (app_t app, int keynumber, u32 timestamp,
   if (rc)
     log_error (_("failed to store the fingerprint: %s\n"),gpg_strerror (rc));

-  if (!rc && card_version > 0x0100)
+  if (!rc && app->card_version > 0x0100)
     {
       unsigned char buf[4];

@@ -3196,8 +3194,8 @@ rsa_writekey (app_t app, gpg_error_t (*pincb)(void*, const char *, char **),
       goto leave;
     }

-  err = store_fpr (app, keyno, created_at, fprbuf, app->card_version,
-                   KEY_TYPE_RSA, rsa_n, rsa_n_len, rsa_e, rsa_e_len);
+  err = store_fpr (app, keyno, created_at, fprbuf, KEY_TYPE_RSA,
+                   rsa_n, rsa_n_len, rsa_e, rsa_e_len);
   if (err)
     goto leave;

@@ -3383,16 +3381,16 @@ ecc_writekey (app_t app, gpg_error_t (*pincb)(void*, const char *, char **),
       goto leave;
     }

-  err = store_fpr (app, keyno, created_at, fprbuf, app->card_version,
+  err = store_fpr (app, keyno, created_at, fprbuf,
                    curve == CURVE_ED25519 ? KEY_TYPE_EDDSA : KEY_TYPE_ECC,
                    curve == CURVE_ED25519 ?
                    "\x09\x2b\x06\x01\x04\x01\xda\x47\x0f\x01"
                    : curve == CURVE_NIST_P256 ?
                    "\x08\x2a\x86\x48\xce\x3d\x03\x01\x07"
                    : "\x05\x2b\x81\x04\x00\x0a",
-                   curve == CURVE_ED25519 ? 10
-                   : curve == CURVE_NIST_P256? 9 : 6,
-                   ecc_q, ecc_q_len, "\x03\x01\x08\x07", 4);
+                   (size_t)(curve == CURVE_ED25519 ? 10
+                            : curve == CURVE_NIST_P256? 9 : 6),
+                   ecc_q, ecc_q_len, "\x03\x01\x08\x07", (size_t)4);
   if (err)
     goto leave;

@@ -3604,8 +3602,8 @@ do_genkey (app_t app, ctrl_t ctrl,  const char *keynostr, unsigned int flags,
   send_status_info (ctrl, "KEY-CREATED-AT",
                     numbuf, (size_t)strlen(numbuf), NULL, 0);

-  rc = store_fpr (app, keyno, (u32)created_at, fprbuf, app->card_version,
-                  KEY_TYPE_RSA, m, mlen, e, elen);
+  rc = store_fpr (app, keyno, (u32)created_at, fprbuf, KEY_TYPE_RSA,
+                  m, mlen, e, elen);
   if (rc)
     goto leave;
   send_fpr_if_not_null (ctrl, "KEY-FPR", -1, fprbuf);
--


From wk at gnupg.org  Tue Jan 27 16:47:56 2015
From: wk at gnupg.org (Werner Koch)
Date: Tue, 27 Jan 2015 16:47:56 +0100
Subject: scd: Fix varargs call for 64-bit arch on ECC keys
In-Reply-To: <54C77F0E.3040501@fsij.org> (NIIBE Yutaka's message of "Tue, 27
 Jan 2015 21:05:34 +0900")
References: <54C6FCD6.8030807@fsij.org> <87vbjs1q34.fsf@vigenere.g10code.de>
 <54C77F0E.3040501@fsij.org>
Message-ID: <87oapkz0lv.fsf@vigenere.g10code.de>

On Tue, 27 Jan 2015 13:05, gniibe at fsij.org said:

> Meanwhile, here is updated patch.  OK to commit?

Yep.

Shalom-Salam,

   Werner

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



From gniibe at fsij.org  Wed Jan 28 04:17:27 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 28 Jan 2015 12:17:27 +0900
Subject: scd: Fix varargs call for 64-bit arch on ECC keys
In-Reply-To: <87oapkz0lv.fsf@vigenere.g10code.de>
References: <54C6FCD6.8030807@fsij.org>
 <87vbjs1q34.fsf@vigenere.g10code.de>	<54C77F0E.3040501@fsij.org>
 <87oapkz0lv.fsf@vigenere.g10code.de>
Message-ID: <54C854C7.9080503@fsij.org>

On 01/28/2015 12:47 AM, Werner Koch wrote:
> On Tue, 27 Jan 2015 13:05, gniibe at fsij.org said:
> 
>> Meanwhile, here is updated patch.  OK to commit?
> 
> Yep.

Thanks.  Pushed.
--


From Jason at zx2c4.com  Wed Jan 28 15:37:29 2015
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 28 Jan 2015 15:37:29 +0100
Subject: [PATCH] with-colons: proper buffering for group keys
Message-ID: <1422455849-2930-1-git-send-email-Jason@zx2c4.com>

This changes the output of group keys to use the es_ variety of
functions, so that the output is correct.

Previously, the keys would be flushed before the rest:

$ gpg --list-config --with-colons
39E5020CE469141074A374C[..snipped...]A374E4691410cfg:group:big
group:;;;;
cfg:group:group2:
cfg:group:group1:;

This patch restores the correct behavior:

$ gpg --list-config --with-colons
cfg:group:big group:39E5020C;E4691410;EB7D54A8;D774A374;CF90C77B
cfg:group:group2:E4691410
cfg:group:group1:D774A374;E4691410

Signed-off-by: Jason A. Donenfeld <Jason at zx2c4.com>
---
 g10/gpg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/g10/gpg.c b/g10/gpg.c
index 2047e30..6786a13 100644
--- a/g10/gpg.c
+++ b/g10/gpg.c
@@ -1599,7 +1599,7 @@ list_config(char *items)
 
 	      for(sl=iter->values;sl;sl=sl->next)
 		{
-		  print_sanitized_string2 (stdout, sl->d, ':',';');
+		  es_write_sanitized (es_stdout, sl->d, strlen(sl->d), ":;", NULL);
 		  if(sl->next)
                     es_printf(";");
 		}
-- 
2.2.1



From Jason at zx2c4.com  Wed Jan 28 15:39:20 2015
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 28 Jan 2015 15:39:20 +0100
Subject: Two Bugs Affecting passwordstore.org with GnuPG 2.1.1
In-Reply-To: <CAHmME9o6BHK0hWHGJ072ub+twn0CN6cQnmfNJNpS1Ue4mwwnGQ@mail.gmail.com>
References: <CAHmME9o6BHK0hWHGJ072ub+twn0CN6cQnmfNJNpS1Ue4mwwnGQ@mail.gmail.com>
Message-ID: <CAHmME9qMORQ=OYq3aJhKR8TO4dy4=qikrVgAVtFtqCy5v8vvsw@mail.gmail.com>

Hello Werner,

We're running into two bugs with our test harness on GnuPG 2.1.1. I'm
attaching gnupg-home.tar.xz, containing a gnupg/ folder for use as:
    export GNUPGHOME="/path/to/gnupg/"

== Bug 1: --with-colons output is garbled ==

$ gpg --list-config --with-colons
39E5020CE4691410EB7D54A8D774A374CF90C77BE4691410D774A374E4691410cfg:group:big
group:;;;;
cfg:group:group2:
cfg:group:group1:;
cfg:version:2.1.1
[snipped]

As you can see, the key IDs that are supposed to be part of the
cfg:group keys are printed first. I believe this is due to some
buffering issues inside GnuPG. Remember to call flush at the right
moments!

== Bug 2: gpg-agent/pinentry called when it shouldn't be ==

The keys in the attached GnuPG home folder do not have passphrases
(they're used in a test harness). On GnuPG 2.0, the following
succeeds. On GnuPG 2.1, the following fails.

$ unset DISPLAY
$ echo hello > signme
$ gpg -s signme </dev/null
gpg: signing failed: Operation cancelled
gpg: signing failed: Operation cancelled

GnuPG should *not* prompt for a passphrase when keys are not protected
with passphrases.

Looking forward to seeing these fixed in 2.1.2.

Thanks,
Jason Donenfeld
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnupg-home.tar.xz
Type: application/x-xz
Size: 12720 bytes
Desc: not available
URL: </pipermail/attachments/20150128/ebb3d2ed/attachment.bin>

From Jason at zx2c4.com  Wed Jan 28 14:54:15 2015
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 28 Jan 2015 14:54:15 +0100
Subject: Two Bugs Affecting passwordstore.org with GnuPG 2.1.1
Message-ID: <CAHmME9o6BHK0hWHGJ072ub+twn0CN6cQnmfNJNpS1Ue4mwwnGQ@mail.gmail.com>

Hello Werner,

We're running into two bugs with our test harness on GnuPG 2.1.1. I'm
attaching gnupg-home.tar.xz, containing a gnupg/ folder for use as:
    export GNUPGHOME="/path/to/gnupg/"

== Bug 1: --with-colons output is garbled ==

$ gpg --list-config --with-colons
39E5020CE4691410EB7D54A8D774A374CF90C77BE4691410D774A374E4691410cfg:group:big
group:;;;;
cfg:group:group2:
cfg:group:group1:;
cfg:version:2.1.1
[snipped]

As you can see, the key IDs that are supposed to be part of the
cfg:group keys are printed first. I believe this is due to some
buffering issues inside GnuPG. Remember to call flush at the right
moments!

== Bug 2: gpg-agent/pinentry called when it shouldn't be ==

The keys in the attached GnuPG home folder do not have passphrases
(they're used in a test harness). On GnuPG 2.0, the following
succeeds. On GnuPG 2.1, the following fails.

$ unset DISPLAY
$ echo hello > signme
$ gpg -s signme </dev/null
gpg: signing failed: Operation cancelled
gpg: signing failed: Operation cancelled

GnuPG should *not* prompt for a passphrase when keys are not protected
with passphrases.

Looking forward to seeing these fixed in 2.1.2.

Thanks,
Jason Donenfeld
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnupg-home.tar.xz
Type: application/x-xz
Size: 12720 bytes
Desc: not available
URL: </pipermail/attachments/20150128/f0776863/attachment-0001.bin>

From dgouttegattat at incenp.org  Wed Jan 28 17:09:57 2015
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Wed, 28 Jan 2015 17:09:57 +0100
Subject: [PATCH] Scute: remove extra nul byte in signature data
Message-ID: <1422461397-25766-1-git-send-email-dgouttegattat@incenp.org>

* src/agent.c (scute_agent_sign): Check for extra nul byte at the
beginning of signature data.
--

GPG Agent 2.1 prepends a nul byte in the signature value if the first
byte has its most significant bit set, to prevent it from being
interpreted as a sign bit (see agent_pksign_do, in GnuPG's
agent/pksign.c).

But Scute expects the signature to be always of a fixed size (128 or
256 bytes), and it will reject a signature containing this extra nul
byte.

This patch makes Scute read the effective size of the signature from
the S-expression, and remove the prepended nul byte if present.

Signed-off-by: Damien Goutte-Gattat <dgouttegattat at incenp.org>
---
 src/agent.c | 57 ++++++++++++++++++++++++++++++++-------------------------
 1 file changed, 32 insertions(+), 25 deletions(-)

diff --git a/src/agent.c b/src/agent.c
index 9265ca2..547c587 100644
--- a/src/agent.c
+++ b/src/agent.c
@@ -981,13 +981,12 @@ pksign_cb (void *opaque, const void *buffer, size_t length)
 }
 
 
-#define SIG_PREFIX   "(7:sig-val(3:rsa(1:s128:"
-#define SIG_PREFIX_2 "(7:sig-val(3:rsa(1:s256:"
+#define SIG_PREFIX   "(7:sig-val(3:rsa(1:s"
 #define SIG_PREFIX_LEN (sizeof (SIG_PREFIX) - 1)
 #define SIG_POSTFIX ")))"
 #define SIG_POSTFIX_LEN (sizeof (SIG_POSTFIX) - 1)
-#define SIG_LEN 128
-#define SIG_LEN_2 256
+#define SIG_MIN_LEN 128
+#define SIG_MAX_LEN 256
 
 /* Call the agent to learn about a smartcard.  */
 gpg_error_t
@@ -1009,14 +1008,14 @@ scute_agent_sign (char *grip, unsigned char *data, int len,
   if (sig_result == NULL)
     {
       /* FIXME:  We return the largest supported size - is that correct?  */
-      *sig_len = SIG_LEN_2;
+      *sig_len = SIG_MAX_LEN;
       return 0;
     }
 
   if (len > MAX_DATA_LEN)
     return gpg_error (GPG_ERR_INV_ARG);
 
-  if (grip == NULL || sig_result == NULL || *sig_len < SIG_LEN)
+  if (grip == NULL || sig_result == NULL || *sig_len < SIG_MIN_LEN)
     return gpg_error (GPG_ERR_INV_ARG);
 
   snprintf (cmd, sizeof (cmd), "SIGKEY %s", grip);
@@ -1041,30 +1040,38 @@ scute_agent_sign (char *grip, unsigned char *data, int len,
     return err;
 
   /* FIXME: we need a real parser to cope with all kind of S-expressions.  */
-  if (sig.len == SIG_PREFIX_LEN + SIG_LEN_2 + SIG_POSTFIX_LEN)
+  if (!memcmp (sig.data, SIG_PREFIX, SIG_PREFIX_LEN))
     {
-      if (memcmp (sig.data, SIG_PREFIX_2, SIG_PREFIX_LEN))
-        return gpg_error (GPG_ERR_BAD_SIGNATURE);
-      if (memcmp (sig.data + sig.len - SIG_POSTFIX_LEN,
-                  SIG_POSTFIX, SIG_POSTFIX_LEN))
-        return gpg_error (GPG_ERR_BAD_SIGNATURE);
-      memcpy (sig_result, sig.data + SIG_PREFIX_LEN, SIG_LEN_2);
-      *sig_len = SIG_LEN_2;
-    }
-  else
-    {
-      if (sig.len != SIG_PREFIX_LEN + SIG_LEN + SIG_POSTFIX_LEN)
+      unsigned char *sig_val;
+      unsigned int sig_val_len;
+
+      sig_val_len = strtol (sig.data + SIG_PREFIX_LEN, (char **)&sig_val, 10);
+
+      if (*(sig_val++) != ':')
         return gpg_error (GPG_ERR_BAD_SIGNATURE);
-      if (memcmp (sig.data, SIG_PREFIX, SIG_PREFIX_LEN))
+      if (sig.len != sig_val - sig.data + sig_val_len + SIG_POSTFIX_LEN)
         return gpg_error (GPG_ERR_BAD_SIGNATURE);
-      if (memcmp (sig.data + sig.len - SIG_POSTFIX_LEN,
-                  SIG_POSTFIX, SIG_POSTFIX_LEN))
+      if (memcmp (sig.data + sig.len - SIG_POSTFIX_LEN, SIG_POSTFIX,
+                  SIG_POSTFIX_LEN))
         return gpg_error (GPG_ERR_BAD_SIGNATURE);
-      memcpy (sig_result, sig.data + SIG_PREFIX_LEN, SIG_LEN);
-      *sig_len = SIG_LEN;
+
+      if ( *sig_val == 0 && *(sig_val+1) & 0x80 )
+        {
+          /* Remove the extra nul byte that was added to prevent
+           * the signature from being interpreted as a negative value. */
+          sig_val += 1;
+          sig_val_len -= 1;
+        }
+
+      if ( sig_val_len > *sig_len )
+        return gpg_error (GPG_ERR_TOO_LARGE);
+
+      memcpy (sig_result, sig_val, sig_val_len);
+      *sig_len = sig_val_len;
     }
-  
-  
+  else
+    return gpg_error( GPG_ERR_BAD_SIGNATURE );  /* Unexpected prefix. */
+
   return 0;
 }
 
-- 
1.8.4



From dkg at fifthhorseman.net  Wed Jan 28 17:12:32 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 28 Jan 2015 11:12:32 -0500
Subject: Two Bugs Affecting passwordstore.org with GnuPG 2.1.1
In-Reply-To: <CAHmME9o6BHK0hWHGJ072ub+twn0CN6cQnmfNJNpS1Ue4mwwnGQ@mail.gmail.com>
References: <CAHmME9o6BHK0hWHGJ072ub+twn0CN6cQnmfNJNpS1Ue4mwwnGQ@mail.gmail.com>
Message-ID: <87oapig9zj.fsf@alice.fifthhorseman.net>

On Wed 2015-01-28 08:54:15 -0500, Jason A. Donenfeld wrote:
> == Bug 1: --with-colons output is garbled ==
>
> $ gpg --list-config --with-colons
> 39E5020CE4691410EB7D54A8D774A374CF90C77BE4691410D774A374E4691410cfg:group:big
> group:;;;;
> cfg:group:group2:
> cfg:group:group1:;
> cfg:version:2.1.1
> [snipped]
>
> As you can see, the key IDs that are supposed to be part of the
> cfg:group keys are printed first. I believe this is due to some
> buffering issues inside GnuPG. Remember to call flush at the right
> moments!

I can confirm that the --list-config --with-colons output is also wrong
for me in 2.1.1 when groups are defined in gpg.conf.

I've recorded this in the upstream bugtracker here:

  https://bugs.g10code.com/gnupg/issue1822

    --dkg



From Jason at zx2c4.com  Wed Jan 28 17:25:43 2015
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 28 Jan 2015 17:25:43 +0100
Subject: Two Bugs Affecting passwordstore.org with GnuPG 2.1.1
In-Reply-To: <CAHmME9o6BHK0hWHGJ072ub+twn0CN6cQnmfNJNpS1Ue4mwwnGQ@mail.gmail.com>
References: <CAHmME9o6BHK0hWHGJ072ub+twn0CN6cQnmfNJNpS1Ue4mwwnGQ@mail.gmail.com>
Message-ID: <CAHmME9qmjRzDrmkf7dXXbhq9is4kRve8qAsZsgdN19H1d38hjw@mail.gmail.com>

On Wed, Jan 28, 2015 at 2:54 PM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> == Bug 2: gpg-agent/pinentry called when it shouldn't be ==
>
> The keys in the attached GnuPG home folder do not have passphrases
> (they're used in a test harness). On GnuPG 2.0, the following
> succeeds. On GnuPG 2.1, the following fails.
>
> $ unset DISPLAY
> $ echo hello > signme
> $ gpg -s signme </dev/null
> gpg: signing failed: Operation cancelled
> gpg: signing failed: Operation cancelled
>
> GnuPG should *not* prompt for a passphrase when keys are not protected
> with passphrases.

A follow-up on this report. It seems the real problem is that when
GnuPG 2.1 imports keys from 2.0, it marks them as protected, even if
they have no passphrase.


From wk at gnupg.org  Wed Jan 28 20:42:14 2015
From: wk at gnupg.org (Werner Koch)
Date: Wed, 28 Jan 2015 20:42:14 +0100
Subject: Two Bugs Affecting passwordstore.org with GnuPG 2.1.1
In-Reply-To: <CAHmME9o6BHK0hWHGJ072ub+twn0CN6cQnmfNJNpS1Ue4mwwnGQ@mail.gmail.com>
 (Jason A. Donenfeld's message of "Wed, 28 Jan 2015 14:54:15 +0100")
References: <CAHmME9o6BHK0hWHGJ072ub+twn0CN6cQnmfNJNpS1Ue4mwwnGQ@mail.gmail.com>
Message-ID: <8761bqvgix.fsf@vigenere.g10code.de>

On Wed, 28 Jan 2015 14:54, Jason at zx2c4.com said:

> == Bug 1: --with-colons output is garbled ==

Bug 1822.  I just pushed the fixed.  Thanks for the patch.  I took this
opportunity to remove all the stdio based print_sanitized functions
which are not needed anymore.

> == Bug 2: gpg-agent/pinentry called when it shouldn't be ==

Needs to wait until tomorrow.

There won't be a 2.12 release this week, thus shifted it to the next
week.  See also https://gnupg.org/roadmap.html .


Salam-Shalom,

   Werner

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



From mail_kb at yahoo.com  Thu Jan 29 01:33:35 2015
From: mail_kb at yahoo.com (KB Sriram)
Date: Wed, 28 Jan 2015 16:33:35 -0800
Subject: Checksum error importing (unencrypted) ecdsa private key
Message-ID: <1422491615.27984.YahooMailBasic@web125805.mail.ne1.yahoo.com>

I'm getting a checksum error when attempting to import an unencrypted ecdsa private key;
sample key appended to this email.

The interesting part of the debug log from gpg-agent says:
-> INQUIRE KEYDATA
<- [...]
<- END
command 'IMPORT_KEY' failed: Checksum error
etc.

I may be wrong, but it seems like the issue is triggered around here:

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=agent/cvt-openpgp.c;h=8cf00233e4178ee34592273c167875d083406a17;hb=0c2bfd9d5a49a6134188f8f7820f6ccdebd9f181#l831

The line
if (is_enc || curve)
  {

and subsequent comment assumes that encrypted parameters or ecc parameters should be stored as opaque gcry_mpi_t numbers; but seems to me that unencrypted ecc values should not enter this clause?

FWIW, my quick test by removing the || curve from that if statement successfully imports the unencrypted key, which is appended.

version:
gpg (GnuPG) 2.1.0
libgcrypt 1.6.2

Thanks!
-kb

-----BEGIN PGP PRIVATE KEY BLOCK-----
Charset: UTF-8

xf8AAAB3BAAAAAATCCqGSM49AwEHAgMEQ4Yc8qum6fq6FXYXNKsnLHkDB++ddY2J
eGwjBfhL4WTjF/UAlF7OsM5ItqTIe4hEsWddfHgipsQu1/KVlMrm6gAA/096sow+
ihauNzH8gs2tWWHYSNtRpL03c6iE4YscU1kBEGTN/wAAABV1bmVuY3J5cHRlZC10
ZXN0LWVjZHPC/wAAAI0EEBMIAD//AAAABYJUyXUL/wAAAAKLCf8AAAAJkKmj9sai
SBXE/wAAAAWVCAkKC/8AAAADlgEC/wAAAAKbA/8AAAACngEAAFWxAP9WbzI+R7KO
/nWcidHaen9d+ZRQ9HS4y5pN4fO+dvAiGgEA3t7oPbiwvn2GGNS6Id+uu2oyqYsw
UAIjLduj5kJe8cY=
=4Fwn
-----END PGP PRIVATE KEY BLOCK-----


From gniibe at fsij.org  Thu Jan 29 06:21:21 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 29 Jan 2015 14:21:21 +0900
Subject: [PATCH] Fix various uninitalized variable values. See CWE-457
 for info.
In-Reply-To: <1422027703-2741-1-git-send-email-git@internot.info>
References: <1422027703-2741-1-git-send-email-git@internot.info>
Message-ID: <54C9C351.1090005@fsij.org>

Thanks for your report.

Patch could be applied.  But, I'm afraid that it only makes enough
sense to shut up some static analyzer.

On 01/24/2015 12:41 AM, Joshua Rogers wrote:
> diff --git a/common/iobuf.c b/common/iobuf.c
> index badbf78..3b13483 100644
> --- a/common/iobuf.c
> +++ b/common/iobuf.c
> @@ -1476,7 +1476,7 @@ iobuf_openrw (const char *fname)
>    iobuf_t a;
>    gnupg_fd_t fp;
>    file_filter_ctx_t *fcx;
> -  size_t len;
> +  size_t len = 0;
>  
>    if (!fname)
>      return NULL;

It agree to apply this part of your patch for cleanness.

Since the call of 'file_filter' with IOBUFCTRL_DESC or IOBUFCTRL_INIT
doesn't touch its size, uninitialized access has no impact in fact.

> diff --git a/g10/textfilter.c b/g10/textfilter.c
> index 394d9c3..c6c4eec 100644
> --- a/g10/textfilter.c
> +++ b/g10/textfilter.c
> @@ -165,7 +165,7 @@ copy_clearsig_text( IOBUF out, IOBUF inp, gcry_md_hd_t md,
>  {
>      unsigned int maxlen;
>      byte *buffer = NULL;    /* malloced buffer */
> -    unsigned int bufsize;   /* and size of this buffer */
> +    unsigned int bufsize = 0;   /* and size of this buffer */
>      unsigned int n;
>      int truncated = 0;
>      int pending_lf = 0;

Umm...  IIUC, it is intended usage.

The third argument of iobuf_read_line is output-only when the second
argument is NULL.  Semantics of this API would be somehow complicated,
but it's useful for the loop.

It would be OK to initialize bufsize to 0 (or any value), though.

> diff --git a/sm/keydb.c b/sm/keydb.c
> index 974625d..7bbbbec 100644
> --- a/sm/keydb.c
> +++ b/sm/keydb.c
> @@ -958,7 +958,7 @@ int
>  keydb_search (KEYDB_HANDLE hd, KEYDB_SEARCH_DESC *desc, size_t ndesc)
>  {
>    int rc = -1;
> -  unsigned long skipped;
> +  unsigned long skipped = 0;
>  
>    if (!hd)
>      return gpg_error (GPG_ERR_INV_VALUE);

I agree to apply this part of your patch for correctness, even though
the value is not used.  It would be more cleaner API to allow NULL to
be supplied if the value is no interest.

> Please note: There are 3 more:
> /g10/keyring.c:
> 1011      byte afp[MAX_FINGERPRINT_LEN];

This is the output buffer for fingerprint.  With closer look of the
code, you can see it will always have valid fingerprint when accessed.
Initializing doesn't make sense.

> /g10/keygen.c:
> 305    byte sym[MAX_PREFS], hash[MAX_PREFS], zip[MAX_PREFS];

These are the output buffer for preferences.  The buffer SYM will be
used with NSYM, as NSYM limits boundary.  So, initializing NSYM only
is enough.  (Same for HASH and ZIP.)  Initializing the buffer itself
doesn't make sense.

> /g10/keylist.c:
> 770          char buf[(MAX_FINGERPRINT_LEN * 2) + 90];

This is the output buffer for sprintf output.  Initializing doesn't
make sense.
--


From gniibe at fsij.org  Thu Jan 29 06:26:09 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 29 Jan 2015 14:26:09 +0900
Subject: [PATCH] Fix resource leak
In-Reply-To: <1422213138-4693-1-git-send-email-git@internot.info>
References: <1422213138-4693-1-git-send-email-git@internot.info>
Message-ID: <54C9C471.4010004@fsij.org>

On 01/26/2015 04:12 AM, Joshua Rogers wrote:
> * kbx/keybox-update.c: Fix resource leak of in blob_filecopy
> command. On return, it 'fp', and 'newfp' was never closed.

Thank you for your patch.  I found more errors in this function.

Here is updated patch, inspired by your report.

diff --git a/kbx/keybox-update.c b/kbx/keybox-update.c
index 11861ac..7b207a5 100644
--- a/kbx/keybox-update.c
+++ b/kbx/keybox-update.c
@@ -241,11 +241,17 @@ blob_filecopy (int mode, const char *fname, KEYBOXBLOB blob,

       rc = _keybox_write_header_blob (newfp, for_openpgp);
       if (rc)
-        return rc;
+        {
+          fclose (newfp);
+          return rc;
+        }

       rc = _keybox_write_blob (blob, newfp);
       if (rc)
-        return rc;
+        {
+          fclose (newfp);
+          return rc;
+        }

       if ( fclose (newfp) )
         return gpg_error_from_syserror ();
@@ -268,7 +274,8 @@ blob_filecopy (int mode, const char *fname, KEYBOXBLOB blob,
   rc = create_tmp_file (fname, &bakfname, &tmpfname, &newfp);
   if (rc)
     {
-      fclose(fp);
+      fclose (fp);
+      fclose (newfp);
       goto leave;
     }

@@ -292,12 +299,16 @@ blob_filecopy (int mode, const char *fname, KEYBOXBLOB blob,
           if (fwrite (buffer, nread, 1, newfp) != 1)
             {
               rc = gpg_error_from_syserror ();
+              fclose (fp);
+              fclose (newfp);
               goto leave;
             }
         }
       if (ferror (fp))
         {
           rc = gpg_error_from_syserror ();
+          fclose (fp);
+          fclose (newfp);
           goto leave;
         }
     }
@@ -321,19 +332,27 @@ blob_filecopy (int mode, const char *fname, KEYBOXBLOB blob,
           if (fwrite (buffer, nread, 1, newfp) != 1)
             {
               rc = gpg_error_from_syserror ();
+              fclose (fp);
+              fclose (newfp);
               goto leave;
             }
         }
       if (ferror (fp))
         {
           rc = gpg_error_from_syserror ();
+          fclose (fp);
+          fclose (newfp);
           goto leave;
         }

       /* Skip this blob. */
       rc = _keybox_read_blob (NULL, fp);
       if (rc)
-        return rc;
+        {
+          fclose (fp);
+          fclose (newfp);
+          return rc;
+        }
     }

   /* Do an insert or update. */
@@ -341,7 +360,11 @@ blob_filecopy (int mode, const char *fname, KEYBOXBLOB blob,
     {
       rc = _keybox_write_blob (blob, newfp);
       if (rc)
+        {
+          fclose (fp);
+          fclose (newfp);
           return rc;
+        }
     }

   /* Copy the rest of the packet for an delete or update. */
@@ -352,12 +375,16 @@ blob_filecopy (int mode, const char *fname, KEYBOXBLOB blob,
           if (fwrite (buffer, nread, 1, newfp) != 1)
             {
               rc = gpg_error_from_syserror ();
+              fclose (fp);
+              fclose (newfp);
               goto leave;
             }
         }
       if (ferror (fp))
         {
           rc = gpg_error_from_syserror ();
+          fclose (fp);
+          fclose (newfp);
           goto leave;
         }
     }
-- 


From gniibe at fsij.org  Thu Jan 29 07:20:59 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 29 Jan 2015 15:20:59 +0900
Subject: po: Update Japanese Translation
Message-ID: <54C9D14B.4030207@fsij.org>

Hello,

I updated Japanese Translation of messages for GnuPG master.
-- 


From patrick at enigmail.net  Thu Jan 29 08:01:57 2015
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Thu, 29 Jan 2015 08:01:57 +0100
Subject: Key generation error (was: Re: gpg-agent and allow-loopback-pinentry)
In-Reply-To: <87sif4m2je.fsf@vigenere.g10code.de>
References: <549D5623.5040602@enigmail.net>
 <549F9C55.6010508@fsij.org>	<54A02A8C.4060801@enigmail.net>
 <87bnmmn5j3.fsf@vigenere.g10code.de>	<54A1696C.4080502@enigmail.net>
 <87sif4m2je.fsf@vigenere.g10code.de>
Message-ID: <54C9DAE5.8080309@enigmail.net>

On 21.01.15 19:06, Werner Koch wrote:
> Hi,
> 
> today I pushed changes which allow to put the passphrase again into the
> parameter file.
> 
> You may now also do this
> 
>   gpg --batch --passphrase '' --quick-gen-key '<all at keys-belong-to.eu>'
> 
> or with a passphrase
> 
>   gpg --batch --passphrase 'abc' --quick-gen-key '<all at keys-belong-to.de>'

I tried key generation with and without pre-setting a password using git
commit 11142e0ad7bc9a9e3c3dccf958d8dbd3312cb993.

Key generation works fine if used with --batch (like above, and also by
specifying the parameters via stdin). However, when the password should
be queried via pinentry, I get a segfault. Password inquiry via
gpg-agent/pinentry works for all other use-cases.

Below is the output with --debug-level guru:

gpg: DBG: chan_15 <- OK Pleased to meet you
gpg: DBG: connection to agent established
gpg: DBG: chan_15 -> RESET
gpg: DBG: chan_15 <- OK
gpg: DBG: chan_15 -> OPTION ttyname=/dev/ttys003
gpg: DBG: chan_15 <- OK
gpg: DBG: chan_15 -> OPTION ttytype=xterm
gpg: DBG: chan_15 <- OK
gpg: DBG: chan_15 -> OPTION
display=/private/tmp/com.apple.launchd.5VKt4lyW1S/org.macosforge.xquartz:0
gpg: DBG: chan_15 <- OK
gpg: DBG: chan_15 -> OPTION lc-ctype=en_US.UTF-8
gpg: DBG: chan_15 <- OK
gpg: DBG: chan_15 -> OPTION lc-messages=en_US.UTF-8
gpg: DBG: chan_15 <- OK
gpg: DBG: chan_15 -> OPTION allow-pinentry-notify
gpg: DBG: chan_15 <- OK
gpg: DBG: chan_15 -> OPTION agent-awareness=2.1.0
gpg: DBG: chan_15 <- OK
gpg: DBG: chan_15 -> AGENT_ID
gpg: DBG: chan_15 <- ERR 67109139 Unknown IPC command <GPG Agent>
gpg: DBG: chan_15 -> RESET
gpg: DBG: chan_15 <- OK
gpg: DBG: chan_15 -> GENKEY --inq-passwd
gpg: DBG: chan_15 <- S INQUIRE_MAXLEN 1024
gpg: DBG: chan_15 <- INQUIRE KEYPARAM
gpg: DBG: chan_15 -> D (genkey(rsa(nbits 4:2048)))
gpg: DBG: chan_15 -> END
gpg: DBG: chan_15 <- INQUIRE NEWPASSWD

gpg: signal Segmentation fault caught ... exiting
Segmentation fault: 11

-Patrick


From wk at gnupg.org  Thu Jan 29 08:16:41 2015
From: wk at gnupg.org (Werner Koch)
Date: Thu, 29 Jan 2015 08:16:41 +0100
Subject: Key generation error
In-Reply-To: <54C9DAE5.8080309@enigmail.net> (Patrick Brunschwig's message of
 "Thu, 29 Jan 2015 08:01:57 +0100")
References: <549D5623.5040602@enigmail.net> <549F9C55.6010508@fsij.org>
 <54A02A8C.4060801@enigmail.net> <87bnmmn5j3.fsf@vigenere.g10code.de>
 <54A1696C.4080502@enigmail.net> <87sif4m2je.fsf@vigenere.g10code.de>
 <54C9DAE5.8080309@enigmail.net>
Message-ID: <87twzat5t2.fsf@vigenere.g10code.de>

On Thu, 29 Jan 2015 08:01, patrick at enigmail.net said:

> I tried key generation with and without pre-setting a password using git
> commit 11142e0ad7bc9a9e3c3dccf958d8dbd3312cb993.

Are you at that commit or at current head?  In particualr this commit

commit 6eebc56687935f3e993eac374b9f4cc5ad3bcf2b
Author: Werner Koch <wk at gnupg.org>
Date:   Tue Jan 27 09:11:13 2015 +0100

    gpg: Fix segv introduced to commit 4d7c9b0.
    
    * g10/keygen.c (get_parameter_passphrase): Take care of R == NULL.
    
    Signed-off-by: Werner Koch <wk at gnupg.org>

	Modified   g10/keygen.c
diff --git a/g10/keygen.c b/g10/keygen.c
index 6143269..50fb67d 100644
--- a/g10/keygen.c
+++ b/g10/keygen.c
@@ -2826,7 +2826,7 @@ static const char *
 get_parameter_passphrase (struct para_data_s *para)
 {
   struct para_data_s *r = get_parameter (para, pPASSPHRASE);
-  return r->u.value;
+  return r ? r->u.value : NULL;
 }
 
is important.



Shalom-Salam,

   Werner

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



From patrick at enigmail.net  Thu Jan 29 08:27:30 2015
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Thu, 29 Jan 2015 08:27:30 +0100
Subject: Key generation error
In-Reply-To: <87twzat5t2.fsf@vigenere.g10code.de>
References: <549D5623.5040602@enigmail.net>
 <549F9C55.6010508@fsij.org>	<54A02A8C.4060801@enigmail.net>
 <87bnmmn5j3.fsf@vigenere.g10code.de>	<54A1696C.4080502@enigmail.net>
 <87sif4m2je.fsf@vigenere.g10code.de>	<54C9DAE5.8080309@enigmail.net>
 <87twzat5t2.fsf@vigenere.g10code.de>
Message-ID: <54C9E0E2.7080700@enigmail.net>

On 29.01.15 08:16, Werner Koch wrote:
> On Thu, 29 Jan 2015 08:01, patrick at enigmail.net said:
> 
>> I tried key generation with and without pre-setting a password using git
>> commit 11142e0ad7bc9a9e3c3dccf958d8dbd3312cb993.
> 
> Are you at that commit or at current head?  In particualr this commit
> 
> commit 6eebc56687935f3e993eac374b9f4cc5ad3bcf2b
> Author: Werner Koch <wk at gnupg.org>
> Date:   Tue Jan 27 09:11:13 2015 +0100
>  
> is important.

Ah, I see. I was still at the commit I wrote. Key generation works fine
with your commit included.

Sorry for the noise.

-Patrick


From wk at gnupg.org  Thu Jan 29 16:37:42 2015
From: wk at gnupg.org (Werner Koch)
Date: Thu, 29 Jan 2015 16:37:42 +0100
Subject: Two Bugs Affecting passwordstore.org with GnuPG 2.1.1
In-Reply-To: <CAHmME9o6BHK0hWHGJ072ub+twn0CN6cQnmfNJNpS1Ue4mwwnGQ@mail.gmail.com>
 (Jason A. Donenfeld's message of "Wed, 28 Jan 2015 14:54:15 +0100")
References: <CAHmME9o6BHK0hWHGJ072ub+twn0CN6cQnmfNJNpS1Ue4mwwnGQ@mail.gmail.com>
Message-ID: <87386ttx6h.fsf@vigenere.g10code.de>

On Wed, 28 Jan 2015 14:54, Jason at zx2c4.com said:

> GnuPG should *not* prompt for a passphrase when keys are not protected
> with passphrases.

Just fixed.

The reasons for this is, as you also noted, the import of unprotected
openpgp keys.  We import them in the native openpgp format and at the
first use gpg-agent migrates them to its own format (because at that
opportunity it knows the passphrase required for re-encryption).  The
unprotected openpgp format also used the protected format but with an
indicator for no protection.  Now, any protected key triggers the
get-passphrase code even that it was not used later.  The remedy is to
detect that special protected format early enough to not ask for a
passphrase.


Salam-Shalom,

   Werner

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



From Jason at zx2c4.com  Thu Jan 29 16:43:28 2015
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 29 Jan 2015 16:43:28 +0100
Subject: Two Bugs Affecting passwordstore.org with GnuPG 2.1.1
In-Reply-To: <87386ttx6h.fsf@vigenere.g10code.de>
References: <CAHmME9o6BHK0hWHGJ072ub+twn0CN6cQnmfNJNpS1Ue4mwwnGQ@mail.gmail.com>
 <87386ttx6h.fsf@vigenere.g10code.de>
Message-ID: <CAHmME9qKD1RKzPBfHyLjGU5ooMPjiWY_KoFS2m1DxK1vZncnag@mail.gmail.com>

On Thu, Jan 29, 2015 at 4:37 PM, Werner Koch <wk at gnupg.org> wrote:
>
> On Wed, 28 Jan 2015 14:54, Jason at zx2c4.com said:
>
> > GnuPG should *not* prompt for a passphrase when keys are not protected
> > with passphrases.
>
> Just fixed.
>
> The reasons for this is, as you also noted, the import of unprotected
> openpgp keys.  We import them in the native openpgp format and at the
> first use gpg-agent migrates them to its own format (because at that
> opportunity it knows the passphrase required for re-encryption).  The
> unprotected openpgp format also used the protected format but with an
> indicator for no protection.  Now, any protected key triggers the
> get-passphrase code even that it was not used later.  The remedy is to
> detect that special protected format early enough to not ask for a


Great! Thanks Werner. Looking forward to seeing 2.1.2 released next week.


From wk at gnupg.org  Thu Jan 29 16:45:22 2015
From: wk at gnupg.org (Werner Koch)
Date: Thu, 29 Jan 2015 16:45:22 +0100
Subject: [PATCH] Fix resource leak
In-Reply-To: <54C9C471.4010004@fsij.org> (NIIBE Yutaka's message of "Thu, 29
 Jan 2015 14:26:09 +0900")
References: <1422213138-4693-1-git-send-email-git@internot.info>
 <54C9C471.4010004@fsij.org>
Message-ID: <87y4olsi99.fsf@vigenere.g10code.de>

On Thu, 29 Jan 2015 06:26, gniibe at fsij.org said:

> Thank you for your patch.  I found more errors in this function.

Me too ;-).  I actually was preparing a slighly different patch but due to
some other bugs I had to stash it away.  It is not ready, thus feel free
to commit yours.


Shalom-Salam,

   Werner

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



From wk at gnupg.org  Thu Jan 29 16:52:21 2015
From: wk at gnupg.org (Werner Koch)
Date: Thu, 29 Jan 2015 16:52:21 +0100
Subject: Checksum error importing (unencrypted) ecdsa private key
In-Reply-To: <1422491615.27984.YahooMailBasic@web125805.mail.ne1.yahoo.com>
 (KB Sriram's message of "Wed, 28 Jan 2015 16:33:35 -0800")
References: <1422491615.27984.YahooMailBasic@web125805.mail.ne1.yahoo.com>
Message-ID: <87twz9shxm.fsf@vigenere.g10code.de>

On Thu, 29 Jan 2015 01:33, mail_kb at yahoo.com said:

> and subsequent comment assumes that encrypted parameters or ecc
> parameters should be stored as opaque gcry_mpi_t numbers; but seems to
> me that unencrypted ecc values should not enter this clause?

The CURVE is a string and we need to store it somewhere.  GPG has a
features which allows to store arbitrary data in an MPI object which we
call opaque MPI.  This was originally used to store protected v4 keys
which do not resemble an integer.  With ECC we use this also for the
name of the curve because that is a shorthand for a key parameter.

I can replicate your problem and will see how to fix it.


Salam-Shalom,

   Werner

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



From aheinecke at intevation.de  Thu Jan 29 17:54:29 2015
From: aheinecke at intevation.de (Andre Heinecke)
Date: Thu, 29 Jan 2015 17:54:29 +0100
Subject: System wide dirmngr configuration with Gnupg 2.1
In-Reply-To: <1622726.hNCageQmvt@esus>
References: <7757034.xtvict5H27@esus> <873871l8hw.fsf@alice.fifthhorseman.net>
 <1622726.hNCageQmvt@esus>
Message-ID: <18970196.yfkHuGDRUH@esus>

Hi,

On Monday, January 26, 2015 12:17:25 PM Andre Heinecke wrote:
> > This is is a pretty common configuration pattern for other (non-gnupg)
> > tools.  In fact, i've often wished for it for gnupg itself, so that
> > sysadmins could tweak a generic /etc/gnupg/gpg.conf for all their users.
> > Is there a specific reason why gpg doesn't support this configuration
> > pattern?
> 
> Werner? Could you comment on this?

I'd still be interested why not. It could be overriden imho when --homedir or 
GNUPGHOME is set explicitly to still allow "clean" configurations.

> Right. I think this is the best approach at least for trusted CA's. As it's
> standard practice to have them defined on a system level first and then
> merge those with the users choices.

Actually the trustlist.txt format allows for this as it merges the 
trustlist.txt from /etc/gnupg/ with the one in the home dir.

I misunderstood the issue here. It turns out that the certificates under
trusted-certs are not actually trusted certs so it's apperently not a problem 
that the sysconfig trusted-certs are ignored with gnupg2.1.

I assumed that they were needed because our internal procedure for adding a 
Root certificate was to add the fingerprint to /etc/gnupg/trustlist.txt and the 
certificate itself to /etc/dirmngr/trusted-certs that this was somehow needed. 
Yet during testing I noticed now that it is not required to have a trusted-
certificate in the trusted-certs folder at all.

<to quote dirmngrs manpage about the trusted-certs dir>
This  directory  should  be  filled with certificates of Root CAs you are 
trusting in checking the CRLS and signing OCSP Reponses.  
</end quote>

But still I get a valid signature if I just add my root CA's fingerprint to the 
trustlist.txt even with CRL checks enabled.

Sorry for my confusion but at least the name "trusted-certs" is a bit 
suboptimal if those certificates are not involved in trust decisions. ;-)

I still don't really understand  the purpose of the trusted-certs directory 
and would be grateful for an explanation. I currently think that it is there 
to allow cases where CRL's are signed by certificates that are not in a trusted 
in chains rooted in certificates from the trustlist.txt file. But in that case 
the second Sentence in the manual for the trusted-certs directory does not 
make much sense: "Usually these are the same certificates you use with the 
applications making use of dirmngr." By which I think the root ca's from the 
trustlist.txt are meant.


Best regards,
Andre
-- 
Andre Heinecke |  ++49-541-335083-262  |  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20150129/347bcba0/attachment-0001.sig>

From gniibe at fsij.org  Fri Jan 30 03:53:52 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Fri, 30 Jan 2015 11:53:52 +0900
Subject: [PATCH] Fix resource leak
In-Reply-To: <87y4olsi99.fsf@vigenere.g10code.de>
References: <1422213138-4693-1-git-send-email-git@internot.info>	<54C9C471.4010004@fsij.org>
 <87y4olsi99.fsf@vigenere.g10code.de>
Message-ID: <54CAF240.8010205@fsij.org>

On 01/30/2015 12:45 AM, Werner Koch wrote:
> Me too ;-).  I actually was preparing a slighly different patch but due to
> some other bugs I had to stash it away.  It is not ready, thus feel free
> to commit yours.

I see.  Pushed.
-- 


From bjk at luxsci.net  Sat Jan 31 22:57:14 2015
From: bjk at luxsci.net (Ben Kibbey)
Date: Sat, 31 Jan 2015 16:57:14 -0500
Subject: [PATCH] Add macro to test for pthreads.
Message-ID: <1422741481-4652467.67403224.ft0VLvF1v022014@rs146.luxsci.com>

* m4/ax_pthread.m4: New.
* configure.ac: Use AX_PTHREAD to test for pthreads.
* configure.ac: Explicitly set pthread flags for Android.
* src/Makefile.am: Build and link with PTHREAD_CFLAGS and PTHREAD_LIBS.
* src/tests/gpg: Ditto.

Fixes building libgpgme-pthread on Android since pthread functions are
in the bionic C library.
---
 configure.ac          |   6 +-
 m4/ax_pthread.m4      | 332 ++++++++++++++++++++++++++++++++++++++++++++++++++
 src/Makefile.am       |   4 +-
 tests/gpg/Makefile.am |   4 +-
 4 files changed, 342 insertions(+), 4 deletions(-)
 create mode 100644 m4/ax_pthread.m4

diff --git a/configure.ac b/configure.ac
index 4660122..e71d36c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -157,6 +157,8 @@ case "${host}" in
 	;;
     *-linux-androideabi)
         have_android_system=yes
+	PTHREAD_CFLAGS="-pthread"
+	PTHREAD_LIBS="-pthread"
         ;;
 esac
 case "${host}" in
@@ -187,9 +189,11 @@ case "${host}" in
 	    		   build_w32_qt=$enableval)
         ;;
     *)
-	AC_CHECK_LIB(pthread,pthread_create,have_pthread=yes)
+	AX_PTHREAD([have_pthread=yes], [have_pthread=no])
 	if test "$have_pthread" = yes; then
 	  AC_DEFINE(HAVE_PTHREAD, ,[Define if we have pthread.])
+	  AC_SUBST(PTHREAD_LIBS)
+	  AC_SUBST(PTHREAD_CFLAGS)
 	fi
 
 	# XXX: Probably use exec-prefix here?
diff --git a/m4/ax_pthread.m4 b/m4/ax_pthread.m4
new file mode 100644
index 0000000..d383ad5
--- /dev/null
+++ b/m4/ax_pthread.m4
@@ -0,0 +1,332 @@
+# ===========================================================================
+#        http://www.gnu.org/software/autoconf-archive/ax_pthread.html
+# ===========================================================================
+#
+# SYNOPSIS
+#
+#   AX_PTHREAD([ACTION-IF-FOUND[, ACTION-IF-NOT-FOUND]])
+#
+# DESCRIPTION
+#
+#   This macro figures out how to build C programs using POSIX threads. It
+#   sets the PTHREAD_LIBS output variable to the threads library and linker
+#   flags, and the PTHREAD_CFLAGS output variable to any special C compiler
+#   flags that are needed. (The user can also force certain compiler
+#   flags/libs to be tested by setting these environment variables.)
+#
+#   Also sets PTHREAD_CC to any special C compiler that is needed for
+#   multi-threaded programs (defaults to the value of CC otherwise). (This
+#   is necessary on AIX to use the special cc_r compiler alias.)
+#
+#   NOTE: You are assumed to not only compile your program with these flags,
+#   but also link it with them as well. e.g. you should link with
+#   $PTHREAD_CC $CFLAGS $PTHREAD_CFLAGS $LDFLAGS ... $PTHREAD_LIBS $LIBS
+#
+#   If you are only building threads programs, you may wish to use these
+#   variables in your default LIBS, CFLAGS, and CC:
+#
+#     LIBS="$PTHREAD_LIBS $LIBS"
+#     CFLAGS="$CFLAGS $PTHREAD_CFLAGS"
+#     CC="$PTHREAD_CC"
+#
+#   In addition, if the PTHREAD_CREATE_JOINABLE thread-attribute constant
+#   has a nonstandard name, defines PTHREAD_CREATE_JOINABLE to that name
+#   (e.g. PTHREAD_CREATE_UNDETACHED on AIX).
+#
+#   Also HAVE_PTHREAD_PRIO_INHERIT is defined if pthread is found and the
+#   PTHREAD_PRIO_INHERIT symbol is defined when compiling with
+#   PTHREAD_CFLAGS.
+#
+#   ACTION-IF-FOUND is a list of shell commands to run if a threads library
+#   is found, and ACTION-IF-NOT-FOUND is a list of commands to run it if it
+#   is not found. If ACTION-IF-FOUND is not specified, the default action
+#   will define HAVE_PTHREAD.
+#
+#   Please let the authors know if this macro fails on any platform, or if
+#   you have any other suggestions or comments. This macro was based on work
+#   by SGJ on autoconf scripts for FFTW (http://www.fftw.org/) (with help
+#   from M. Frigo), as well as ac_pthread and hb_pthread macros posted by
+#   Alejandro Forero Cuervo to the autoconf macro repository. We are also
+#   grateful for the helpful feedback of numerous users.
+#
+#   Updated for Autoconf 2.68 by Daniel Richard G.
+#
+# LICENSE
+#
+#   Copyright (c) 2008 Steven G. Johnson <stevenj at alum.mit.edu>
+#   Copyright (c) 2011 Daniel Richard G. <skunk at iSKUNK.ORG>
+#
+#   This program is free software: you can redistribute it and/or modify it
+#   under the terms of the GNU General Public License as published by the
+#   Free Software Foundation, either version 3 of the License, or (at your
+#   option) any later version.
+#
+#   This program is distributed in the hope that it will be useful, but
+#   WITHOUT ANY WARRANTY; without even the implied warranty of
+#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General
+#   Public License for more details.
+#
+#   You should have received a copy of the GNU General Public License along
+#   with this program. If not, see <http://www.gnu.org/licenses/>.
+#
+#   As a special exception, the respective Autoconf Macro's copyright owner
+#   gives unlimited permission to copy, distribute and modify the configure
+#   scripts that are the output of Autoconf when processing the Macro. You
+#   need not follow the terms of the GNU General Public License when using
+#   or distributing such scripts, even though portions of the text of the
+#   Macro appear in them. The GNU General Public License (GPL) does govern
+#   all other use of the material that constitutes the Autoconf Macro.
+#
+#   This special exception to the GPL applies to versions of the Autoconf
+#   Macro released by the Autoconf Archive. When you make and distribute a
+#   modified version of the Autoconf Macro, you may extend this special
+#   exception to the GPL to apply to your modified version as well.
+
+#serial 21
+
+AU_ALIAS([ACX_PTHREAD], [AX_PTHREAD])
+AC_DEFUN([AX_PTHREAD], [
+AC_REQUIRE([AC_CANONICAL_HOST])
+AC_LANG_PUSH([C])
+ax_pthread_ok=no
+
+# We used to check for pthread.h first, but this fails if pthread.h
+# requires special compiler flags (e.g. on True64 or Sequent).
+# It gets checked for in the link test anyway.
+
+# First of all, check if the user has set any of the PTHREAD_LIBS,
+# etcetera environment variables, and if threads linking works using
+# them:
+if test x"$PTHREAD_LIBS$PTHREAD_CFLAGS" != x; then
+        save_CFLAGS="$CFLAGS"
+        CFLAGS="$CFLAGS $PTHREAD_CFLAGS"
+        save_LIBS="$LIBS"
+        LIBS="$PTHREAD_LIBS $LIBS"
+        AC_MSG_CHECKING([for pthread_join in LIBS=$PTHREAD_LIBS with CFLAGS=$PTHREAD_CFLAGS])
+        AC_TRY_LINK_FUNC([pthread_join], [ax_pthread_ok=yes])
+        AC_MSG_RESULT([$ax_pthread_ok])
+        if test x"$ax_pthread_ok" = xno; then
+                PTHREAD_LIBS=""
+                PTHREAD_CFLAGS=""
+        fi
+        LIBS="$save_LIBS"
+        CFLAGS="$save_CFLAGS"
+fi
+
+# We must check for the threads library under a number of different
+# names; the ordering is very important because some systems
+# (e.g. DEC) have both -lpthread and -lpthreads, where one of the
+# libraries is broken (non-POSIX).
+
+# Create a list of thread flags to try.  Items starting with a "-" are
+# C compiler flags, and other items are library names, except for "none"
+# which indicates that we try without any flags at all, and "pthread-config"
+# which is a program returning the flags for the Pth emulation library.
+
+ax_pthread_flags="pthreads none -Kthread -kthread lthread -pthread -pthreads -mthreads pthread --thread-safe -mt pthread-config"
+
+# The ordering *is* (sometimes) important.  Some notes on the
+# individual items follow:
+
+# pthreads: AIX (must check this before -lpthread)
+# none: in case threads are in libc; should be tried before -Kthread and
+#       other compiler flags to prevent continual compiler warnings
+# -Kthread: Sequent (threads in libc, but -Kthread needed for pthread.h)
+# -kthread: FreeBSD kernel threads (preferred to -pthread since SMP-able)
+# lthread: LinuxThreads port on FreeBSD (also preferred to -pthread)
+# -pthread: Linux/gcc (kernel threads), BSD/gcc (userland threads)
+# -pthreads: Solaris/gcc
+# -mthreads: Mingw32/gcc, Lynx/gcc
+# -mt: Sun Workshop C (may only link SunOS threads [-lthread], but it
+#      doesn't hurt to check since this sometimes defines pthreads too;
+#      also defines -D_REENTRANT)
+#      ... -mt is also the pthreads flag for HP/aCC
+# pthread: Linux, etcetera
+# --thread-safe: KAI C++
+# pthread-config: use pthread-config program (for GNU Pth library)
+
+case ${host_os} in
+        solaris*)
+
+        # On Solaris (at least, for some versions), libc contains stubbed
+        # (non-functional) versions of the pthreads routines, so link-based
+        # tests will erroneously succeed.  (We need to link with -pthreads/-mt/
+        # -lpthread.)  (The stubs are missing pthread_cleanup_push, or rather
+        # a function called by this macro, so we could check for that, but
+        # who knows whether they'll stub that too in a future libc.)  So,
+        # we'll just look for -pthreads and -lpthread first:
+
+        ax_pthread_flags="-pthreads pthread -mt -pthread $ax_pthread_flags"
+        ;;
+
+        darwin*)
+        ax_pthread_flags="-pthread $ax_pthread_flags"
+        ;;
+esac
+
+# Clang doesn't consider unrecognized options an error unless we specify
+# -Werror. We throw in some extra Clang-specific options to ensure that
+# this doesn't happen for GCC, which also accepts -Werror.
+
+AC_MSG_CHECKING([if compiler needs -Werror to reject unknown flags])
+save_CFLAGS="$CFLAGS"
+ax_pthread_extra_flags="-Werror"
+CFLAGS="$CFLAGS $ax_pthread_extra_flags -Wunknown-warning-option -Wsizeof-array-argument"
+AC_COMPILE_IFELSE([AC_LANG_PROGRAM([int foo(void);],[foo()])],
+                  [AC_MSG_RESULT([yes])],
+                  [ax_pthread_extra_flags=
+                   AC_MSG_RESULT([no])])
+CFLAGS="$save_CFLAGS"
+
+if test x"$ax_pthread_ok" = xno; then
+for flag in $ax_pthread_flags; do
+
+        case $flag in
+                none)
+                AC_MSG_CHECKING([whether pthreads work without any flags])
+                ;;
+
+                -*)
+                AC_MSG_CHECKING([whether pthreads work with $flag])
+                PTHREAD_CFLAGS="$flag"
+                ;;
+
+                pthread-config)
+                AC_CHECK_PROG([ax_pthread_config], [pthread-config], [yes], [no])
+                if test x"$ax_pthread_config" = xno; then continue; fi
+                PTHREAD_CFLAGS="`pthread-config --cflags`"
+                PTHREAD_LIBS="`pthread-config --ldflags` `pthread-config --libs`"
+                ;;
+
+                *)
+                AC_MSG_CHECKING([for the pthreads library -l$flag])
+                PTHREAD_LIBS="-l$flag"
+                ;;
+        esac
+
+        save_LIBS="$LIBS"
+        save_CFLAGS="$CFLAGS"
+        LIBS="$PTHREAD_LIBS $LIBS"
+        CFLAGS="$CFLAGS $PTHREAD_CFLAGS $ax_pthread_extra_flags"
+
+        # Check for various functions.  We must include pthread.h,
+        # since some functions may be macros.  (On the Sequent, we
+        # need a special flag -Kthread to make this header compile.)
+        # We check for pthread_join because it is in -lpthread on IRIX
+        # while pthread_create is in libc.  We check for pthread_attr_init
+        # due to DEC craziness with -lpthreads.  We check for
+        # pthread_cleanup_push because it is one of the few pthread
+        # functions on Solaris that doesn't have a non-functional libc stub.
+        # We try pthread_create on general principles.
+        AC_LINK_IFELSE([AC_LANG_PROGRAM([#include <pthread.h>
+                        static void routine(void *a) { a = 0; }
+                        static void *start_routine(void *a) { return a; }],
+                       [pthread_t th; pthread_attr_t attr;
+                        pthread_create(&th, 0, start_routine, 0);
+                        pthread_join(th, 0);
+                        pthread_attr_init(&attr);
+                        pthread_cleanup_push(routine, 0);
+                        pthread_cleanup_pop(0) /* ; */])],
+                [ax_pthread_ok=yes],
+                [])
+
+        LIBS="$save_LIBS"
+        CFLAGS="$save_CFLAGS"
+
+        AC_MSG_RESULT([$ax_pthread_ok])
+        if test "x$ax_pthread_ok" = xyes; then
+                break;
+        fi
+
+        PTHREAD_LIBS=""
+        PTHREAD_CFLAGS=""
+done
+fi
+
+# Various other checks:
+if test "x$ax_pthread_ok" = xyes; then
+        save_LIBS="$LIBS"
+        LIBS="$PTHREAD_LIBS $LIBS"
+        save_CFLAGS="$CFLAGS"
+        CFLAGS="$CFLAGS $PTHREAD_CFLAGS"
+
+        # Detect AIX lossage: JOINABLE attribute is called UNDETACHED.
+        AC_MSG_CHECKING([for joinable pthread attribute])
+        attr_name=unknown
+        for attr in PTHREAD_CREATE_JOINABLE PTHREAD_CREATE_UNDETACHED; do
+            AC_LINK_IFELSE([AC_LANG_PROGRAM([#include <pthread.h>],
+                           [int attr = $attr; return attr /* ; */])],
+                [attr_name=$attr; break],
+                [])
+        done
+        AC_MSG_RESULT([$attr_name])
+        if test "$attr_name" != PTHREAD_CREATE_JOINABLE; then
+            AC_DEFINE_UNQUOTED([PTHREAD_CREATE_JOINABLE], [$attr_name],
+                               [Define to necessary symbol if this constant
+                                uses a non-standard name on your system.])
+        fi
+
+        AC_MSG_CHECKING([if more special flags are required for pthreads])
+        flag=no
+        case ${host_os} in
+            aix* | freebsd* | darwin*) flag="-D_THREAD_SAFE";;
+            osf* | hpux*) flag="-D_REENTRANT";;
+            solaris*)
+            if test "$GCC" = "yes"; then
+                flag="-D_REENTRANT"
+            else
+                # TODO: What about Clang on Solaris?
+                flag="-mt -D_REENTRANT"
+            fi
+            ;;
+        esac
+        AC_MSG_RESULT([$flag])
+        if test "x$flag" != xno; then
+            PTHREAD_CFLAGS="$flag $PTHREAD_CFLAGS"
+        fi
+
+        AC_CACHE_CHECK([for PTHREAD_PRIO_INHERIT],
+            [ax_cv_PTHREAD_PRIO_INHERIT], [
+                AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include <pthread.h>]],
+                                                [[int i = PTHREAD_PRIO_INHERIT;]])],
+                    [ax_cv_PTHREAD_PRIO_INHERIT=yes],
+                    [ax_cv_PTHREAD_PRIO_INHERIT=no])
+            ])
+        AS_IF([test "x$ax_cv_PTHREAD_PRIO_INHERIT" = "xyes"],
+            [AC_DEFINE([HAVE_PTHREAD_PRIO_INHERIT], [1], [Have PTHREAD_PRIO_INHERIT.])])
+
+        LIBS="$save_LIBS"
+        CFLAGS="$save_CFLAGS"
+
+        # More AIX lossage: compile with *_r variant
+        if test "x$GCC" != xyes; then
+            case $host_os in
+                aix*)
+                AS_CASE(["x/$CC"],
+                  [x*/c89|x*/c89_128|x*/c99|x*/c99_128|x*/cc|x*/cc128|x*/xlc|x*/xlc_v6|x*/xlc128|x*/xlc128_v6],
+                  [#handle absolute path differently from PATH based program lookup
+                   AS_CASE(["x$CC"],
+                     [x/*],
+                     [AS_IF([AS_EXECUTABLE_P([${CC}_r])],[PTHREAD_CC="${CC}_r"])],
+                     [AC_CHECK_PROGS([PTHREAD_CC],[${CC}_r],[$CC])])])
+                ;;
+            esac
+        fi
+fi
+
+test -n "$PTHREAD_CC" || PTHREAD_CC="$CC"
+
+AC_SUBST([PTHREAD_LIBS])
+AC_SUBST([PTHREAD_CFLAGS])
+AC_SUBST([PTHREAD_CC])
+
+# Finally, execute ACTION-IF-FOUND/ACTION-IF-NOT-FOUND:
+if test x"$ax_pthread_ok" = xyes; then
+        ifelse([$1],,[AC_DEFINE([HAVE_PTHREAD],[1],[Define if you have POSIX threads libraries and header files.])],[$1])
+        :
+else
+        ax_pthread_ok=no
+        $2
+fi
+AC_LANG_POP
+])dnl AX_PTHREAD
diff --git a/src/Makefile.am b/src/Makefile.am
index b7ddbc1..9951041 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -180,12 +180,14 @@ libgpgme_la_DEPENDENCIES = @LTLIBOBJS@ $(srcdir)/libgpgme.vers $(gpgme_deps)
 libgpgme_la_LIBADD = $(gpgme_res) @LIBASSUAN_LIBS@ @LTLIBOBJS@ \
 	             @GPG_ERROR_LIBS@
 
+libgpgme_pthread_la_CFLAGS = $(no_undefined) $(export_symbols) \
+	@PTHREAD_CFLAGS@
 libgpgme_pthread_la_LDFLAGS = $(no_undefined) $(export_symbols) \
 	$(libgpgme_version_script_cmd) -version-info \
 	@LIBGPGME_LT_CURRENT@:@LIBGPGME_LT_REVISION@:@LIBGPGME_LT_AGE@
 libgpgme_pthread_la_DEPENDENCIES = @LTLIBOBJS@ $(srcdir)/libgpgme.vers
 libgpgme_pthread_la_LIBADD = $(gpgme_res) @LIBASSUAN_LIBS@ @LTLIBOBJS@ \
-	-lpthread @GPG_ERROR_LIBS@
+	@GPG_ERROR_LIBS@ @PTHREAD_LIBS@
 
 if BUILD_W32_GLIB
 libgpgme_glib_la_LDFLAGS = $(no_undefined) \
diff --git a/tests/gpg/Makefile.am b/tests/gpg/Makefile.am
index 5c1266e..cbc222c 100644
--- a/tests/gpg/Makefile.am
+++ b/tests/gpg/Makefile.am
@@ -59,9 +59,9 @@ EXTRA_DIST = start-stop-agent initial.test final.test \
 
 INCLUDES = -I$(top_builddir)/src
 
-AM_CPPFLAGS = @GPG_ERROR_CFLAGS@
+AM_CPPFLAGS = @GPG_ERROR_CFLAGS@ @PTHREAD_CFLAGS@
 LDADD = ../../src/libgpgme.la
-t_thread1_LDADD = ../../src/libgpgme-pthread.la -lpthread
+t_thread1_LDADD = ../../src/libgpgme-pthread.la @PTHREAD_LIBS@
 
 # We don't run t-genkey in the test suite, because it takes too long
 noinst_PROGRAMS = $(c_tests) t-genkey
-- 
2.1.4