From gniibe at fsij.org  Tue May  2 12:18:17 2017
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 02 May 2017 19:18:17 +0900
Subject: [STABLE-BRANCH-1-4 PATCH] g10: secmem leak
In-Reply-To: <20170426145834.GN3854@gnu.org>
References: <20160414161817.GA9527@gnu.org>
 <87r3e85bnp.fsf@wheatstone.g10code.de> <20170217085247.GM18144@gnu.org>
 <87y3uo6k7h.fsf@fifthhorseman.net> <20170426145834.GN3854@gnu.org>
Message-ID: <8737cntvdi.fsf@fsij.org>

Hello,

Ineiev <ineiev at gnu.org> wrote:
> Thank you!  I thought the 1-4 branch is not supported any more.

It is supported.  I'm going to apply your patch to the 1-4 branch.

May I ask you to send your DCO?  It is explained in the "License policy"
section in gnupg/doc/HACKING.  Please check it.
-- 


From albrecht.dress at arcor.de  Thu May  4 21:50:44 2017
From: albrecht.dress at arcor.de (Albrecht =?iso-8859-1?b?RHJl3w==?=)
Date: Thu, 04 May 2017 21:50:44 +0200
Subject: GpgME: doc of function availability vs. version?
Message-ID: <S2ODQW5K.NXZORIED.TG3LKPC7@JHIJDRQG.WJDHV5ZC.3EU3NJGT>

Hi all,

does a GpgME documentation exist which lists the new functions vs. the library version where they have been introduced?  In the manual I only found a list of deprecated functions, but also without the information for which version the replacements have been added.

Thanks,
Albrecht.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: </pipermail/attachments/20170504/9ddbe24d/attachment.sig>

From wk at gnupg.org  Fri May  5 12:17:45 2017
From: wk at gnupg.org (Werner Koch)
Date: Fri, 05 May 2017 12:17:45 +0200
Subject: GpgME: doc of function availability vs. version?
In-Reply-To: <S2ODQW5K.NXZORIED.TG3LKPC7@JHIJDRQG.WJDHV5ZC.3EU3NJGT>
 ("Albrecht =?utf-8?Q?Dre=C3=9F=22's?= message of "Thu, 04 May 2017 21:50:44
 +0200")
References: <S2ODQW5K.NXZORIED.TG3LKPC7@JHIJDRQG.WJDHV5ZC.3EU3NJGT>
Message-ID: <87tw4zobee.fsf@wheatstone.g10code.de>

On Thu,  4 May 2017 21:50, albrecht.dress at arcor.de said:

> does a GpgME documentation exist which lists the new functions vs. the
> library version where they have been introduced?  In the manual I only

You can look this up in the NEWS file.  We document API changes like this:

  Noteworthy changes in version 1.9.0 (2017-03-28)
  ------------------------------------------------
  
   [...]
  
   * Interface changes relative to the 1.8.0 release:
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   gpgme_op_createkey          CHANGED: Meaning of 'expire' parameter.
   gpgme_op_createsubkey       CHANGED: Meaning of 'expire' parameter.
   GPGME_CREATE_NOEXPIRE       NEW.
  

I created https://dev.gnupg.org/T3137 for this.  Thanks.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170505/d2af1a22/attachment.sig>

From albrecht.dress at arcor.de  Fri May  5 19:10:59 2017
From: albrecht.dress at arcor.de (Albrecht =?iso-8859-1?b?RHJl3w==?=)
Date: Fri, 05 May 2017 19:10:59 +0200
Subject: GpgME: doc of function availability vs. version?
In-Reply-To: <87tw4zobee.fsf@wheatstone.g10code.de> (from wk@gnupg.org on
 Fri May  5 12:17:45 2017)
References: <S2ODQW5K.NXZORIED.TG3LKPC7@JHIJDRQG.WJDHV5ZC.3EU3NJGT>
 <87tw4zobee.fsf@wheatstone.g10code.de>
Message-ID: <XXV63CTV.L6LONSUN.EVRTYYV7@XS4SLKFI.GXVE4U2L.QSD72J42>

Am 05.05.17 12:17 schrieb(en) Werner Koch:
> You can look this up in the NEWS file.  We document API changes like this:

Ah!  Thanks, I missed that one.  It's even in the Debian package...

> I created https://dev.gnupg.org/T3137 for this.  Thanks.

This would be *extremely* helpful, IMO.

Cheers
Albrecht.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: </pipermail/attachments/20170505/5097e792/attachment.sig>

From matthew.summers at syapse.com  Fri May  5 19:30:26 2017
From: matthew.summers at syapse.com (Matthew Summers)
Date: Fri, 5 May 2017 12:30:26 -0500
Subject: Follow-up to Crashes with gpg-agent 2.1.18
In-Reply-To: <CAGCOBUxGXh942f+zM5Fxf7EwjeGROiTS_vtmYJWw3Q-xeKm+LA@mail.gmail.com>
References: <VI1PR0801MB1805D17C93D5B88A13CAADF3EB0A0@VI1PR0801MB1805.eurprd08.prod.outlook.com>
 <DB6PR0801MB17986A6C1CD049E789370784EB010@DB6PR0801MB1798.eurprd08.prod.outlook.com>
 <87k26savh5.fsf@fifthhorseman.net>
 <DB6PR0801MB179858DD4816C6A89FE45FE0EB010@DB6PR0801MB1798.eurprd08.prod.outlook.com>
 <CAGCOBUxwv=MnzW+rMEmAWmoR2GJ6Ecq1+-Hfu6_PNW1LePvobQ@mail.gmail.com>
 <87bmrqblrh.fsf@iwagami.gniibe.org>
 <CAGCOBUwM8o=xa2WuD2FXN_LoT+eYF+L7D+Dexm1xCLaq6YutEA@mail.gmail.com>
 <CAGCOBUxGXh942f+zM5Fxf7EwjeGROiTS_vtmYJWw3Q-xeKm+LA@mail.gmail.com>
Message-ID: <CAGCOBUzGym6woCRMPKMHn1w6mxR++Qa8_5O93-bwXELRsKVkdg@mail.gmail.com>

On Fri, Apr 21, 2017 at 11:55 AM, Matthew Summers
<matthew.summers at syapse.com> wrote:
> Testing that patch in the ticket above, I am still encountering
> failures

Hi there, any updates on this lately? I'd really love to test a patch
that would apply against the 2.1.20 release.

Thanks,
Matt


From dkg at fifthhorseman.net  Sat May  6 05:14:43 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 05 May 2017 23:14:43 -0400
Subject: sharing a keybox between 2.1.20 and 2.1.18 : "skipped packet of type
 12 in keybox" (and a proposed patch for 2.1.18)
Message-ID: <87shkioevw.fsf@fifthhorseman.net>

Hi folks--

Revision a8895c99a7d0750132477d80cd66caaf3a709113 ("gpg: Revamp reading
and writing of ring trust packets.") introduces an important overhaul of
the keybox format by stashing ring trust information directly in the
keybox.  It was first released in 2.1.20.

Debian is likely to ship 2.1.18 in stretch (plus a bunch of bugfix
patches that i've cherry-picked from the development since 2.1.18).  In
debian experimental, i've got 2.1.20, and i plan to keep it up-to-date
with the latest upstream release.

What i've discovered is that if i use 2.1.20 on even a relatively small
keybox, and then i revert to 2.1.18, 2.1.18 spews out dozens of lines
like:

    gpg: skipped packet of type 12 in keybox

(packet type 12 is the "trust packet")

While i don't think there's any explicit problem with 2.1.18 operating
on such a keybox, the warnings are definitely distracting and annoying.
Furthermore, there doesn't seem to be any way to clean these trust
packets from a keybox that has been updated from 2.1.20.

It's certainly possible that someone will briefly try out GnuPG 2.1.20
in the future and then revert back to debian stable (2.1.18); or that
they'll use the same homedir for two installations.  I want to make sure
that one system doesn't cause the other one to spew a lot to stderr.

So for debian, i'm currently aiming to apply the following patch to the
2.1.18 series to avoid seeing these warnings.  If anyone sees a problem
with this approach, or sees a better way to resolve this concern, please
let me know!

    --dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-gpg-Avoid-spurious-warnings-about-trust-packets.patch
Type: text/x-diff
Size: 1548 bytes
Desc: not available
URL: </pipermail/attachments/20170505/033afdad/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: </pipermail/attachments/20170505/033afdad/attachment.sig>

From aviso at rockhopper.net  Sun May  7 06:13:41 2017
From: aviso at rockhopper.net (Avram Lubkin)
Date: Sun, 7 May 2017 00:13:41 -0400
Subject: Change in behaviour for invalid crypto engine
Message-ID: <CAHqEdrOGy-NJOxjzo7Jnd=09yWBD-N4vaRmmq-y3cARPDjFK_A@mail.gmail.com>

I'm using GPGME through the pygpgme and noticed a change in behavior from
the Centos 7 version (1.3.2) and the Fedora 25 version (1.8.0) when an
invalid crypto engine path is used. pygpgme hasn't been updated in years
and the versions are the same, so it seems like the difference is farther
down the stack in GPGME.

With the following python code:

>>> import gpgme
>>> gpg = gpgme.Context()
>>> gpg.set_engine_info(gpgme.PROTOCOL_OpenPGP, '/not/a/real/path', None)
>>> gpg.keylist()

I raise an exception with GPGME 1.3.2

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
gpgme.GpgmeError: (7, 150, u'Invalid crypto engine')

And I get an empty list with GPGME 1.8.0

I think the desired behavior would be to throw an error or in some other
way inform the user they aren't using a valid engine.

The gpgme.Context.set_engine_info method maps to gpgme_ctx_set_engine_info
in GPGME and always returns None. I'm not sure if any errors get thrown by
GPGME that aren't properly captured by pygpgme. If so, I can open a bug
there for them to capture it.

I tried looking through the GPGME code, but it was hard to follow so any
help would be appreciated. I'd just like to allow my users to point to a
different executable if desired and properly inform them if they configure
one that isn't invalid.

Thanks,

Avram
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170507/fcb7bb63/attachment.html>

From albrecht.dress at arcor.de  Sun May  7 13:48:12 2017
From: albrecht.dress at arcor.de (Albrecht =?iso-8859-1?b?RHJl3w==?=)
Date: Sun, 07 May 2017 13:48:12 +0200
Subject: Q: gpgme_op_keylist_*() on key server
Message-ID: <Y2M2GFHM.ZRFVCHDG.GZRCEQO3@GDQTXA6W.IJGBFLTA.Q2AY3CI3>

Hi all,

I have a question about using the gpgme_op_keylist_*() functions for listing keys on an external key server.

When I run the attached simple C code to look up a certain key in the local key ring, the gpgme_key_t fields (revoked, expired, etc.) are filled as expected:

albrecht at deneb:~$ ./gpgme-list-test wk at gnupg.org
searching for 'wk at gnupg.org' in local key ring
5DE249965B0358A2: Werner Koch <wk at gnupg.org> [sign][] .E..
F2AD85AC1E42B367: Werner Koch <wk at gnupg.org> [sign][encr] ....

However, looking up the same key on the key server, all keys seem to be unusable as none of them has the can_sign or can_encrypt flag set:

albrecht at deneb:~$ ./gpgme-list-test wk at gnupg.org e
searching for 'wk at gnupg.org' on key servers
6FC4ECF01E42B367: Werner Koch <wk at gnupg.org> [][] R...
2F7998F3DBFC6AD9: Werner Koch <wk at gnupg.org> [][] ....
F2AD85AC1E42B367: Werner Koch <wk at gnupg.org> [][] ....
5DE249965B0358A2: Werner Koch <> [][] ....
6C7EE1B8621CC013: Werner Koch <wk at gnupg.org> [][] ....

I also noticed that the 'expired' flag is missing for 5DE249965B0358A2, although I ran 'gpg2 --refresh-keys' before.

Any idea what I am missing here?

Thanks in advance,
Albrecht.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gpgme-list-test.c
Type: text/x-csrc
Size: 1534 bytes
Desc: not available
URL: </pipermail/attachments/20170507/5599b9d8/attachment-0001.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: </pipermail/attachments/20170507/5599b9d8/attachment-0001.sig>

From alon.barlev at gmail.com  Sun May  7 23:40:51 2017
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Mon, 8 May 2017 00:40:51 +0300
Subject: [GPGME] python t-quick-key-manipulation.py fails
In-Reply-To: <CAOazyz27w5oMtF35boXD1sZKj7dDg0L5HbfM1F26OOU30y5jog@mail.gmail.com>
References: <CAOazyz3qP=oDdF_va7YM57Wy_-mwWNSkzwZigt3MyTyX5VAvEA@mail.gmail.com>
 <5132026.KFn2xqrD00@esus>
 <CAOazyz1EY6HvHuw7vDLHKbzEOr4mxKw8OQ8ghkiC-S+id3=yww@mail.gmail.com>
 <3388219.X9TNJ1pSuZ@esus> <87pogjb5js.fsf@europa.jade-hamburg.de>
 <CAOazyz2YLFRdF9XvxB66EPQgkx8cVq11aCEM-gv4DU0+3qSuXA@mail.gmail.com>
 <87bms3b1wm.fsf@europa.jade-hamburg.de>
 <CAOazyz0F2JTX0W2KHMNC=BEsWJORTRH=x2RT=K=BLL_=_ZR7+g@mail.gmail.com>
 <CAOazyz27w5oMtF35boXD1sZKj7dDg0L5HbfM1F26OOU30y5jog@mail.gmail.com>
Message-ID: <CAOazyz3XNJ-ZW2eVhGQud-m_83txwoyjV8fMO-csWx6-4OFevw@mail.gmail.com>

Hi,
Any chance of gpgme-1.9.1 release?
Thanks!

On 27 April 2017 at 12:16, Alon Bar-Lev <alon.barlev at gmail.com> wrote:
> On 11 April 2017 at 14:49, Alon Bar-Lev <alon.barlev at gmail.com> wrote:
>> On 11 April 2017 at 14:48, Justus Winter <justus at g10code.com> wrote:
>>>
>>> Alon Bar-Lev <alon.barlev at gmail.com> writes:
>>>
>>> > Can we please release 1.9.1 so that I can publish it downstream?
>>>
>>> Unfortunately not until Werner returns from his vacation.  I'd say it
>>> will have to wait to the 24th.  You'll have to use patches for now.
>>
>> Thanks!
>> I will wait, too many patches to publish.
>
> Hi,
> A kind reminder.
> Thanks!


From dominik at dominikschuermann.de  Mon May  8 08:43:11 2017
From: dominik at dominikschuermann.de (Dominik Schuermann)
Date: Mon, 8 May 2017 09:43:11 +0300
Subject: unknown critical bit
In-Reply-To: <87lgrdh4ze.fsf@wheatstone.g10code.de>
References: <20170402135313.GB1130@zeromail.org>
 <877f32zpy6.wl-neal@walfield.org> <87inmmt1w1.fsf@wheatstone.g10code.de>
 <20170405194151.GW1130@zeromail.org>
 <20170406141111.vdoqmspw6mmraqw2@calamity>
 <87lgrdh4ze.fsf@wheatstone.g10code.de>
Message-ID: <b539afb5-1556-e565-2407-e48b7544f9b3@dominikschuermann.de>

To keep the information flow between the projects: This has been fixed
in OpenKeychain v4.3.

Ref:
https://github.com/open-keychain/open-keychain/commit/005f93a4f30a9505093271554a8e7ab79011ace0

Thanks again for pointing this out.

Cheers
Dominik

On 04/06/2017 07:32 PM, Werner Koch wrote:
> On Thu,  6 Apr 2017 16:11, look at my.amazin.horse said:
> 
>> A related question came up when we looked at our implementation: We set
>> the reason as NO_REASON, with an empty string. Dominik says he
>> included
> 
> GnuPG does the same for the revocation certs created with the key.  In
> interactive mode the user is asked for a reason and an optional
> description.
> 
>> the packet for compatibility reasons, but we can't remember the
>> specifics at this point.
> 
> To support v3 keys.
> 
>> We could now either set the flag to false, or drop the subpacket
>> altogether. I have no strong preference, would probably just drop the
>> critical bit to change as little as necessary. Any thoughts?
> 
> That would certainly be helpful.
> 
> 
> Salam-Shalom,
> 
>    Werner
> 
> 
> 
> _______________________________________________
> 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: 473 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170508/5f0103f1/attachment.sig>

From wk at gnupg.org  Mon May  8 12:31:39 2017
From: wk at gnupg.org (Werner Koch)
Date: Mon, 08 May 2017 12:31:39 +0200
Subject: unknown critical bit
In-Reply-To: <b539afb5-1556-e565-2407-e48b7544f9b3@dominikschuermann.de>
 (Dominik Schuermann's message of "Mon, 8 May 2017 09:43:11 +0300")
References: <20170402135313.GB1130@zeromail.org>
 <877f32zpy6.wl-neal@walfield.org>
 <87inmmt1w1.fsf@wheatstone.g10code.de>
 <20170405194151.GW1130@zeromail.org>
 <20170406141111.vdoqmspw6mmraqw2@calamity>
 <87lgrdh4ze.fsf@wheatstone.g10code.de>
 <b539afb5-1556-e565-2407-e48b7544f9b3@dominikschuermann.de>
Message-ID: <87lgq7k5bo.fsf@wheatstone.g10code.de>

On Mon,  8 May 2017 08:43, dominik at dominikschuermann.de said:
> To keep the information flow between the projects: This has been fixed
> in OpenKeychain v4.3.

Thanks.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170508/09226130/attachment.sig>

From wk at gnupg.org  Mon May  8 12:37:58 2017
From: wk at gnupg.org (Werner Koch)
Date: Mon, 08 May 2017 12:37:58 +0200
Subject: sharing a keybox between 2.1.20 and 2.1.18 : "skipped packet of
 type 12 in keybox" (and a proposed patch for 2.1.18)
In-Reply-To: <87shkioevw.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message
 of "Fri, 05 May 2017 23:14:43 -0400")
References: <87shkioevw.fsf@fifthhorseman.net>
Message-ID: <87d1bjk515.fsf@wheatstone.g10code.de>

On Sat,  6 May 2017 05:14, dkg at fifthhorseman.net said:

> Revision a8895c99a7d0750132477d80cd66caaf3a709113 ("gpg: Revamp reading
> and writing of ring trust packets.") introduces an important overhaul of
> the keybox format by stashing ring trust information directly in the
> keybox.  It was first released in 2.1.20.

Actually we always handled them in keyring files and that part of the
patch adds them to keybox files - where they are useless without the
other changes.

> So for debian, i'm currently aiming to apply the following patch to the
> 2.1.18 series to avoid seeing these warnings.  If anyone sees a problem
> with this approach, or sees a better way to resolve this concern, please

I see no problems.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170508/8c253ee2/attachment.sig>

From justus at g10code.com  Mon May  8 15:33:42 2017
From: justus at g10code.com (Justus Winter)
Date: Mon, 08 May 2017 15:33:42 +0200
Subject: [GPGME] python t-quick-key-manipulation.py fails
In-Reply-To: <CAOazyz3XNJ-ZW2eVhGQud-m_83txwoyjV8fMO-csWx6-4OFevw@mail.gmail.com>
References: <CAOazyz3qP=oDdF_va7YM57Wy_-mwWNSkzwZigt3MyTyX5VAvEA@mail.gmail.com>
 <5132026.KFn2xqrD00@esus>
 <CAOazyz1EY6HvHuw7vDLHKbzEOr4mxKw8OQ8ghkiC-S+id3=yww@mail.gmail.com>
 <3388219.X9TNJ1pSuZ@esus> <87pogjb5js.fsf@europa.jade-hamburg.de>
 <CAOazyz2YLFRdF9XvxB66EPQgkx8cVq11aCEM-gv4DU0+3qSuXA@mail.gmail.com>
 <87bms3b1wm.fsf@europa.jade-hamburg.de>
 <CAOazyz0F2JTX0W2KHMNC=BEsWJORTRH=x2RT=K=BLL_=_ZR7+g@mail.gmail.com>
 <CAOazyz27w5oMtF35boXD1sZKj7dDg0L5HbfM1F26OOU30y5jog@mail.gmail.com>
 <CAOazyz3XNJ-ZW2eVhGQud-m_83txwoyjV8fMO-csWx6-4OFevw@mail.gmail.com>
Message-ID: <877f1rqxqh.fsf@europa.jade-hamburg.de>

Hi :)

Alon Bar-Lev <alon.barlev at gmail.com> writes:
> Any chance of gpgme-1.9.1 release?

Thanks for the remainder.  I'll create a task so it won't be lost.

Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: </pipermail/attachments/20170508/7fe3a122/attachment.sig>

From gerhard.poul at gmail.com  Mon May  8 15:51:47 2017
From: gerhard.poul at gmail.com (Gerhard Poul)
Date: Mon, 8 May 2017 15:51:47 +0200
Subject: gpg-agent with OpenSSH on Windows
In-Reply-To: <8737czt5wb.fsf@wheatstone.g10code.de>
References: <CAG=8HF813jvuq8BqkCQEVest__Xmp06=RxCtRN2wtmtR++3onQ@mail.gmail.com>
 <8737czt5wb.fsf@wheatstone.g10code.de>
Message-ID: <CAG=8HF9dkC8SNFeDyyRDHA4-xfAN9PfDBgPrf4a+GfTyvsrixw@mail.gmail.com>

On Sun, Apr 23, 2017 at 7:01 PM, Werner Koch <wk at gnupg.org> wrote:
> On Thu, 20 Apr 2017 09:15, gerhard.poul at gmail.com said:
>
>> I opened an issue [2] and it seems that ssh-add has been adapted to use
>> named pipes on Windows, wheres that is not the mechanism that gpg-agent
>
> Arghh.  Named Pipes under Windows are very hard to use as an emulation
> for local sockets.  The problem is that there is no mechanism to make
> sure that they work only on the local machine.  With the right
> credentials you can use them remotely - which is a bad idea to implement
> a local (ie. non-remote) IPC.

I'm not saying named pipes are the right choice, but that's what
they've currently implemented in this beta. There also seems to be
some documentation or at least newsgroup posts about how to restrict
named pipes to only be used locally, but it requires some specific
settings and I've not tested whether it works as described.

> Frankly, OpenSSH should not use that and resort to our or the new Cygwin
> way of emulating local sockets.

It might be worthwhile to wait and see whether the code is going to
merged as-is or not before planning how to proceed.

> On Unix we use plain local sockets.  On Windows we listen on 127.0.0.1
> for a TCP connection; the port and a cookie is given in a file created
> by the server and thus the connection is secured using file permissions.
> Cygwin does something very similar.

This should work with named pipes as well.

Regards,
Gerhard


From dkg at fifthhorseman.net  Tue May  9 00:07:43 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 08 May 2017 18:07:43 -0400
Subject: sharing a keybox between 2.1.20 and 2.1.18 : "skipped packet of
 type 12 in keybox" (and a proposed patch for 2.1.18)
In-Reply-To: <87d1bjk515.fsf@wheatstone.g10code.de>
References: <87shkioevw.fsf@fifthhorseman.net>
 <87d1bjk515.fsf@wheatstone.g10code.de>
Message-ID: <87y3u7m28g.fsf@fifthhorseman.net>

On Mon 2017-05-08 12:37:58 +0200, Werner Koch wrote:
> On Sat,  6 May 2017 05:14, dkg at fifthhorseman.net said:
>
>> Revision a8895c99a7d0750132477d80cd66caaf3a709113 ("gpg: Revamp reading
>> and writing of ring trust packets.") introduces an important overhaul of
>> the keybox format by stashing ring trust information directly in the
>> keybox.  It was first released in 2.1.20.
>
> Actually we always handled them in keyring files and that part of the
> patch adds them to keybox files - where they are useless without the
> other changes.
>
>> So for debian, i'm currently aiming to apply the following patch to the
>> 2.1.18 series to avoid seeing these warnings.  If anyone sees a problem
>> with this approach, or sees a better way to resolve this concern, please
>
> I see no problems.

Thanks for the review, Werner!

       --dkg


From dkg at fifthhorseman.net  Tue May  9 00:21:08 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 08 May 2017 18:21:08 -0400
Subject: Change in behaviour for invalid crypto engine
In-Reply-To: <CAHqEdrOGy-NJOxjzo7Jnd=09yWBD-N4vaRmmq-y3cARPDjFK_A@mail.gmail.com>
References: <CAHqEdrOGy-NJOxjzo7Jnd=09yWBD-N4vaRmmq-y3cARPDjFK_A@mail.gmail.com>
Message-ID: <87shkfm1m3.fsf@fifthhorseman.net>

Hi Avram--

On Sun 2017-05-07 00:13:41 -0400, Avram Lubkin wrote:
> I'm using GPGME through the pygpgme and noticed a change in behavior from
> the Centos 7 version (1.3.2) and the Fedora 25 version (1.8.0) when an
> invalid crypto engine path is used. pygpgme hasn't been updated in years
> and the versions are the same, so it seems like the difference is farther
> down the stack in GPGME.

fwiw, gpgme itself ships a python binding (named "gpg") as part of
1.8.0.  that binding is maintained upstream, and you're probably better
off in the long term using it instead of pygpgme.

sorry to not have a concrete answer to your question about pygpgme, just
wanted to clarify the support situation going forward.

       --dkg


From ineiev at gnu.org  Tue May  9 14:16:11 2017
From: ineiev at gnu.org (Ineiev)
Date: Tue, 9 May 2017 08:16:11 -0400
Subject: DCO [was: Re: [STABLE-BRANCH-1-4 PATCH] g10: secmem leak]
In-Reply-To: <87d1bi8hu1.fsf@fsij.org>
References: <87r3e85bnp.fsf@wheatstone.g10code.de>
 <20170217085247.GM18144@gnu.org> <87y3uo6k7h.fsf@fifthhorseman.net>
 <20170426145834.GN3854@gnu.org> <8737cntvdi.fsf@fsij.org>
 <20170502180139.GO27246@gnu.org> <87bmr5twv4.fsf@fsij.org>
 <87inlbzlka.fsf@fsij.org> <20170508132025.GE25850@gnu.org>
 <87d1bi8hu1.fsf@fsij.org>
Message-ID: <20170509121611.GH25850@gnu.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: Ineiev <ineiev at gnu.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Digital signature
URL: </pipermail/attachments/20170509/5bb10263/attachment-0001.sig>

From gniibe at fsij.org  Wed May 10 07:25:35 2017
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 10 May 2017 14:25:35 +0900
Subject: DCO [was: Re: [STABLE-BRANCH-1-4 PATCH] g10: secmem leak]
In-Reply-To: <20170509121611.GH25850@gnu.org>
References: <87r3e85bnp.fsf@wheatstone.g10code.de>
 <20170217085247.GM18144@gnu.org> <87y3uo6k7h.fsf@fifthhorseman.net>
 <20170426145834.GN3854@gnu.org> <8737cntvdi.fsf@fsij.org>
 <20170502180139.GO27246@gnu.org> <87bmr5twv4.fsf@fsij.org>
 <87inlbzlka.fsf@fsij.org> <20170508132025.GE25850@gnu.org>
 <87d1bi8hu1.fsf@fsij.org> <20170509121611.GH25850@gnu.org>
Message-ID: <87mvalgu5s.fsf@fsij.org>

Ineiev <ineiev at gnu.org> wrote:
> GnuPG Developer's Certificate of Origin.  Version 1.0

Thanks.  I put an entry to gnugp/AUTHORS and applied your change
to STABLE-BRANCH-1-4.
-- 


From cmmarusich at gmail.com  Wed May 10 10:00:29 2017
From: cmmarusich at gmail.com (Chris Marusich)
Date: Wed, 10 May 2017 01:00:29 -0700
Subject: bug#25328: pinentry-gtk-2 fails after upgrade to 1.0.0:
 "Operation cancelled"
In-Reply-To: <87tw4wtmq4.fsf@gmail.com> (Chris Marusich's message of "Sun, 07
 May 2017 13:50:59 -0700")
References: <877f5o6e1d.fsf@gmail.com> <87tw4wtmq4.fsf@gmail.com>
Message-ID: <87shkd3zvm.fsf@gmail.com>

Chris Marusich <cmmarusich at gmail.com> writes:

> Chris Marusich <cmmarusich at gmail.com> writes:
>
>> Hi,
>>
>> Since upgrading pinentry-gtk-2 from 0.9.7 to 1.0.0, I've noticed some
>> strange behavior.  Whenever I try to do something that requires access
>> to my secret key, no window appears, and I get an error like the
>> following:
>>
>>     $ gpg --sign /tmp/message 
>>     gpg: signing failed: Operation cancelled
>>     gpg: signing failed: Operation cancelled
>>     $ 
>>
>> Is this expected behavior with 1.0.0?
>>
>> This happens about 90% of the time.  About 10% of the time, a pinentry
>> window actually does pop up.  When using version 0.9.7, a pinentry
>> window popped up 100% of the time.  I expected the behavior of 1.0.0 to
>> be the same.
>>
>> My software versions are:
>>
>> * GuixSD 0.12.0
>> * GNOME 3 (GNOME shell 3.22.2)
>> * gnupg 2.1.16
>> * pinentry-gtk-2 1.0.0
>>
>> My ~/.gnupg/gpg-agent.conf file contains the following single line:
>>
>>     pinentry-program /home/marusich/.guix-profile/bin/pinentry-gtk-2
>>
>> When I change my gpg-agent.conf file to use pinentry-gnome3 ,
>> pinentry-curses, or pinentry-tty (and I kill gpg-agent to make sure it
>> uses the modified file), the problem doesn't occur.
>>
>> When I keep pinentry-gtk-2 in my gpg-agent.conf file, and I log into an
>> Xfce session, the problem doesn't occur.  Likewise, when I log in via a
>> virtual terminal (e.g. the kind you can get by pressing Control+Alt+F2),
>> the problem doesn't occur.
>>
>> In other words, the problem only seems to occur when I use
>> pinentry-gtk-2 as my pinentry-program, and I'm logged into a GNOME 3
>> session.  The problem occurs regardless of what program I am running
>> inside of that GNOME 3 session; for example, it happens in emacs when
>> emacs tries to automatically decrypt files ending in ".gpg", too.
>>
>> Here's how to reproduce the issue:
>>
>> * Log into a GNOME session on (a recently updated) GuixSD.
>>
>> * In $HOME/.gnupg/gpg-agent.conf, set pinentry-program to
>>   pinentry-gtk-2, for example:
>>
>>     pinentry-program /home/marusich/.guix-profile/bin/pinentry-gtk-2
>>
>> * If the gpg-agent process is running, kill it to make sure it loads the
>>   new gpg-agent.conf.
>>
>> * Open up any terminal (GNOME terminal and emacs' "M-x term" will both
>>   reproduce the issue) to sign a message, e.g.:
>>
>>     echo hello > /tmp/message
>>     gpg --sign /tmp/message
>>
>> You should get the error very frequently.
>
> Did anybody get this message?  I sent it in January of 2017, but I can't
> find it in the online archives, so I'm worried maybe it never got
> delivered:
>
> https://lists.gnupg.org/pipermail/gnupg-devel/
>
> This time, I've CC'd 25328 at debbugs.gnu.org so that my email gets
> delivered to at least one location for posterity.

I can no longer reproduce this issue.  I tried following the steps above
on my current GuixSD system, and the problem does not occur.  It seems
like pinentry-gtk-2 works fine now, which is curious because the version
is still 1.0.0.  I don't know why it works now but didn't earlier.

My emails never seem to have made it to the gnupg-devel list, but in
this case I suppose it doesn't matter any more.  I think we can resolve
this bug report, unless someone else can reproduce the issue reliably.

-- 
Chris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: </pipermail/attachments/20170510/51fb003c/attachment.sig>

From ineiev at gnu.org  Wed May 10 14:12:28 2017
From: ineiev at gnu.org (Ineiev)
Date: Wed, 10 May 2017 08:12:28 -0400
Subject: DCO [was: Re: [STABLE-BRANCH-1-4 PATCH] g10: secmem leak]
In-Reply-To: <87mvalgu5s.fsf@fsij.org>
References: <87y3uo6k7h.fsf@fifthhorseman.net> <20170426145834.GN3854@gnu.org>
 <8737cntvdi.fsf@fsij.org> <20170502180139.GO27246@gnu.org>
 <87bmr5twv4.fsf@fsij.org> <87inlbzlka.fsf@fsij.org>
 <20170508132025.GE25850@gnu.org> <87d1bi8hu1.fsf@fsij.org>
 <20170509121611.GH25850@gnu.org> <87mvalgu5s.fsf@fsij.org>
Message-ID: <20170510121228.GK25850@gnu.org>

On Wed, May 10, 2017 at 02:25:35PM +0900, NIIBE Yutaka wrote:
> Ineiev <ineiev at gnu.org> wrote:
> > GnuPG Developer's Certificate of Origin.  Version 1.0
> 
> Thanks.  I put an entry to gnugp/AUTHORS and applied your change
> to STABLE-BRANCH-1-4.

Thank you!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Digital signature
URL: </pipermail/attachments/20170510/7d5e1a8e/attachment.sig>

From wlt-ml at o-sinc.com  Wed May 10 22:20:38 2017
From: wlt-ml at o-sinc.com (William L. Thomson Jr.)
Date: Wed, 10 May 2017 16:20:38 -0400
Subject: EFL Pinentry port
Message-ID: <assp.0303dd7454.20170510162038.7f14db1c@o-sinc.com>

Just following up on a bug I opened others may not be aware of[1].
Sometime back Mike Mike Blumenkrantz submitted a patch for a EFL port
of pinetry[2]. My work is not based of his. I have discussed it with
him. I went a different direction, and he requested I just keep my name
on the work. I will be available to support the module long term. Mike
is busy with core things related to EFL.

There is no rush for inclusion. If anything looking for feedback/review
to help with the inclusion process. Along those lines if anyone is
interested, here is the patch[3]. It is a bit big, but if wanted I can
attach it to a post to list.

Otherwise thank you for your time, review, and any feedback!

1. https://dev.gnupg.org/T2905
2. https://lists.gnupg.org/pipermail/gnupg-devel/2016-October/031807.html
3. https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/app-crypt/pinentry/files/efl.patch

-- 
William L. Thomson Jr.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170510/cb3478f7/attachment.sig>

From aviso at rockhopper.net  Thu May 11 00:22:29 2017
From: aviso at rockhopper.net (Avram Lubkin)
Date: Wed, 10 May 2017 18:22:29 -0400
Subject: Change in behaviour for invalid crypto engine
In-Reply-To: <87shkfm1m3.fsf@fifthhorseman.net>
References: <CAHqEdrOGy-NJOxjzo7Jnd=09yWBD-N4vaRmmq-y3cARPDjFK_A@mail.gmail.com>
 <87shkfm1m3.fsf@fifthhorseman.net>
Message-ID: <CAHqEdrNKatYY+bYgL5pf2mY1U5KeC8REdWbndfFCQPL6+HqyyA@mail.gmail.com>

On Mon, May 8, 2017 at 6:21 PM, Daniel Kahn Gillmor <dkg at fifthhorseman.net>
wrote:

> fwiw, gpgme itself ships a python binding (named "gpg") as part of
> 1.8.0.  that binding is maintained upstream, and you're probably better
> off in the long term using it instead of pygpgme.
>

Thanks for the response. I wasn't aware gpgme was including
language-specific bindings. I'll have to make sure the functionality
matches, but it does seem like a good long term strategy. I had been
concerned about the lack of updates from pygpgme.

That said, that won't be something I can tackle in the near future.
Assuming there are no issues, in addition to integration with my code, I
(or someone else) would need to make Fedora/EPEL RPMs available. I write
3rd party enterprise software, so any 3rd party libraries need to be
provided by Red Hat/Centos or Fedora/EPEL. It looks like neither the gpg or
pyme python packages are available as RPMs.

Avram
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170510/b279fab3/attachment.html>

From dkg at fifthhorseman.net  Thu May 11 22:28:43 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 11 May 2017 16:28:43 -0400
Subject: Keyring corruption with GnuPG 2.1.20
In-Reply-To: <877f1ona4r.fsf@europa.jade-hamburg.de>
References: <877f1ona4r.fsf@europa.jade-hamburg.de>
Message-ID: <878tm3i1dw.fsf@fifthhorseman.net>

On Wed 2017-05-10 14:56:20 +0200, Justus Winter wrote:

> unfortunately, GnuPG 2.1.20 has a bug that can lead to keyring
> corruptions when updating or deleting keys.
 [...]
> If you are using GnuPG 2.1.20 with the keyring format, a workaround is
> to convert your keyring to a keybox.  For this, follow:
>
> https://www.gnupg.org/faq/whats-new-in-2.1.html#keybox
>
> (Hat-tip to bmhatfield for the idea.)

on debian and derived systems, you can also use the helper tool:

   migrate-pubring-from-classic-gpg

which should be slightly more robust and also simpler to use than the
multistep sequence outlined in the FAQ.

> For more information see:
>
> https://dev.gnupg.org/T3123
>
> Packagers, please cherry-pick the following fix:
>
> https://dev.gnupg.org/rG22739433e98be80e46fe7d01d52a9627c1aebaae

Debian-specific note: 2.1.20 is only in debian's experimental
repository; the above patch should be present in 2.1.20-4, which was
uploaded to the experimental repo yesterday.  If you're running any
previous version of 2.1.20 from experimental, please upgrade!

thanks for the heads-up, Justus!

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: </pipermail/attachments/20170511/5e0c5645/attachment.sig>

From wlt-ml at o-sinc.com  Fri May 12 03:53:25 2017
From: wlt-ml at o-sinc.com (William L. Thomson Jr.)
Date: Thu, 11 May 2017 21:53:25 -0400
Subject: EFL Pinentry port
In-Reply-To: <assp.0303dd7454.20170510162038.7f14db1c@o-sinc.com>
References: <assp.0303dd7454.20170510162038.7f14db1c@o-sinc.com>
Message-ID: <assp.03058c8704.20170511215325.5d8abbdf@o-sinc.com>

Minor code updates, better link and patch, squashed into a single commit
against master.

https://github.com/Obsidian-StudiosInc/pinentry/commit/398b612696269addb40b4dc6b421bf682f79a400
https://github.com/Obsidian-StudiosInc/pinentry/commit/398b612696269addb40b4dc6b421bf682f79a400.patch

Updated patch in phab as well
https://dev.gnupg.org/D426

Thanks!

On Wed, 10 May 2017 16:20:38 -0400
"William L. Thomson Jr." <wlt-ml at o-sinc.com> wrote:

> Just following up on a bug I opened others may not be aware of[1].
> Sometime back Mike Mike Blumenkrantz submitted a patch for a EFL port
> of pinetry[2]. My work is not based of his. I have discussed it with
> him. I went a different direction, and he requested I just keep my
> name on the work. I will be available to support the module long
> term. Mike is busy with core things related to EFL.
> 
> There is no rush for inclusion. If anything looking for
> feedback/review to help with the inclusion process. Along those lines
> if anyone is interested, here is the patch[3]. It is a bit big, but
> if wanted I can attach it to a post to list.
> 
> Otherwise thank you for your time, review, and any feedback!
> 
> 1. https://dev.gnupg.org/T2905
> 2.
> https://lists.gnupg.org/pipermail/gnupg-devel/2016-October/031807.html
> 3.
> https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/app-crypt/pinentry/files/efl.patch
> 



-- 
William L. Thomson Jr.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170511/79a24fa5/attachment-0001.sig>

From dominyktiller at gmail.com  Fri May 12 03:37:49 2017
From: dominyktiller at gmail.com (Dominyk Tiller)
Date: Fri, 12 May 2017 02:37:49 +0100
Subject: Keyring corruption with GnuPG 2.1.20
In-Reply-To: <878tm3i1dw.fsf@fifthhorseman.net>
References: <877f1ona4r.fsf@europa.jade-hamburg.de>
 <878tm3i1dw.fsf@fifthhorseman.net>
Message-ID: <3f0d1903-e236-2451-1751-8d73f72d3c09@gmail.com>

Hey folks,

Are there any plans for an imminent 2.1.21 with that fix in? It seems
like a pretty major hiccup.

Easy enough to apply the fix to Homebrew's formula for gnupg (which a
while back switched to tracking the 2.1 instead of 2.0 branch) but may
be worth brew holding off on that if a release is imminent.

Dom
===
Sent from macOS.

If you wish to communicate more securely my PGP Public Key is at:
https://pgp.mit.edu/pks/lookup?search=0xE5F21DD98E4DF470&op=index

On 11/05/2017 21:28, Daniel Kahn Gillmor wrote:
> On Wed 2017-05-10 14:56:20 +0200, Justus Winter wrote:
> 
>> unfortunately, GnuPG 2.1.20 has a bug that can lead to keyring
>> corruptions when updating or deleting keys.
>  [...]
>> If you are using GnuPG 2.1.20 with the keyring format, a workaround is
>> to convert your keyring to a keybox.  For this, follow:
>>
>> https://www.gnupg.org/faq/whats-new-in-2.1.html#keybox
>>
>> (Hat-tip to bmhatfield for the idea.)
> 
> on debian and derived systems, you can also use the helper tool:
> 
>    migrate-pubring-from-classic-gpg
> 
> which should be slightly more robust and also simpler to use than the
> multistep sequence outlined in the FAQ.
> 
>> For more information see:
>>
>> https://dev.gnupg.org/T3123
>>
>> Packagers, please cherry-pick the following fix:
>>
>> https://dev.gnupg.org/rG22739433e98be80e46fe7d01d52a9627c1aebaae
> 
> Debian-specific note: 2.1.20 is only in debian's experimental
> repository; the above patch should be present in 2.1.20-4, which was
> uploaded to the experimental repo yesterday.  If you're running any
> previous version of 2.1.20 from experimental, please upgrade!
> 
> thanks for the heads-up, Justus!
> 
>         --dkg
> 
> 
> 
> _______________________________________________
> 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: 833 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170512/01380409/attachment.sig>

From justus at g10code.com  Fri May 12 10:24:01 2017
From: justus at g10code.com (Justus Winter)
Date: Fri, 12 May 2017 10:24:01 +0200
Subject: Keyring corruption with GnuPG 2.1.20
In-Reply-To: <3f0d1903-e236-2451-1751-8d73f72d3c09@gmail.com>
References: <877f1ona4r.fsf@europa.jade-hamburg.de>
 <878tm3i1dw.fsf@fifthhorseman.net>
 <3f0d1903-e236-2451-1751-8d73f72d3c09@gmail.com>
Message-ID: <87k25mmqji.fsf@europa.jade-hamburg.de>

Dominyk Tiller <dominyktiller at gmail.com> writes:

> Are there any plans for an imminent 2.1.21 with that fix in? It seems
> like a pretty major hiccup.

https://dev.gnupg.org/T3150

Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: </pipermail/attachments/20170512/ca6e1a5f/attachment.sig>

From wlt-ml at o-sinc.com  Fri May 12 17:53:15 2017
From: wlt-ml at o-sinc.com (William L. Thomson Jr.)
Date: Fri, 12 May 2017 11:53:15 -0400
Subject: EFL Pinentry port
In-Reply-To: <assp.03058c8704.20170511215325.5d8abbdf@o-sinc.com>
References: <assp.0303dd7454.20170510162038.7f14db1c@o-sinc.com>
 <assp.03058c8704.20170511215325.5d8abbdf@o-sinc.com>
Message-ID: <assp.0305b3eb44.20170512115315.45cde42a@o-sinc.com>

Sorry once again, there was a bug in EFL[1] I thought was in my code.

https://github.com/Obsidian-StudiosInc/pinentry/commit/0adff7bea93274a2f13f725530ff2b814f7cbab4
https://github.com/Obsidian-StudiosInc/pinentry/commit/0adff7bea93274a2f13f725530ff2b814f7cbab4.patch

Updated patch in phab as well
https://dev.gnupg.org/D426


1. https://phab.enlightenment.org/T5481
    ( Issue centering dialog windows )


On Thu, 11 May 2017 21:53:25 -0400
"William L. Thomson Jr." <wlt-ml at o-sinc.com> wrote:

> Minor code updates, better link and patch, squashed into a single
> commit against master.
> 
> https://github.com/Obsidian-StudiosInc/pinentry/commit/398b612696269addb40b4dc6b421bf682f79a400
> https://github.com/Obsidian-StudiosInc/pinentry/commit/398b612696269addb40b4dc6b421bf682f79a400.patch
> 
> Updated patch in phab as well
> https://dev.gnupg.org/D426
> 
> Thanks!
> 
> On Wed, 10 May 2017 16:20:38 -0400
> "William L. Thomson Jr." <wlt-ml at o-sinc.com> wrote:
> 
> > Just following up on a bug I opened others may not be aware of[1].
> > Sometime back Mike Mike Blumenkrantz submitted a patch for a EFL
> > port of pinetry[2]. My work is not based of his. I have discussed
> > it with him. I went a different direction, and he requested I just
> > keep my name on the work. I will be available to support the module
> > long term. Mike is busy with core things related to EFL.
> > 
> > There is no rush for inclusion. If anything looking for
> > feedback/review to help with the inclusion process. Along those
> > lines if anyone is interested, here is the patch[3]. It is a bit
> > big, but if wanted I can attach it to a post to list.
> > 
> > Otherwise thank you for your time, review, and any feedback!
> > 
> > 1. https://dev.gnupg.org/T2905
> > 2.
> > https://lists.gnupg.org/pipermail/gnupg-devel/2016-October/031807.html
> > 3.
> > https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/app-crypt/pinentry/files/efl.patch
> >   
> 
> 
> 



-- 
William L. Thomson Jr.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170512/496bac62/attachment.sig>

From wk at gnupg.org  Mon May 15 19:44:38 2017
From: wk at gnupg.org (Werner Koch)
Date: Mon, 15 May 2017 19:44:38 +0200
Subject: [Announce] GnuPG 2.1.21 released
Message-ID: <87bmquvwu1.fsf@wheatstone.g10code.de>

Hello!

The GnuPG team is pleased to announce the availability of a new release
of GnuPG: version 2.1.21.  See below for a list of new features and bug
fixes.

Note: This release fixes a keyring corruption bug introduced
      with last release.  Users of 2.1.20, who are using the
      old "pubring.gpg" file to store their public keys, are
      asked to update to this new release.


About GnuPG
=============

The GNU Privacy Guard (GnuPG) is a complete and free implementation
of the OpenPGP standard which is commonly abbreviated as PGP.

GnuPG allows to encrypt and sign data and communication, features a
versatile key management system as well as access modules for public key
directories.  GnuPG itself is a command line tool with features for easy
integration with other applications.  A wealth of frontend applications
and libraries making use of GnuPG are available.  As an Universal Crypto
Engine GnuPG provides support for S/MIME and Secure Shell in addition to
OpenPGP.

GnuPG is Free Software (meaning that it respects your freedom).  It can
be freely used, modified and distributed under the terms of the GNU
General Public License.


Noteworthy changes in version 2.1.21
====================================

  * gpg,gpgsm: Fix corruption of old style keyring.gpg files.  This
    bug was introduced with version 2.1.20.  Note that the default
    pubring.kbx format was not affected.

  * gpg,dirmngr: Removed the skeleton config file support.  The
    system's standard methods for providing default configuration
    files should be used instead.

  * w32: The Windows installer now allows installion of GnuPG without
    Administrator permissions.

  * gpg: Fixed import filter property match bug.

  * scd: Removed Linux support for Cardman 4040 PCMCIA reader.

  * scd: Fixed some corner case bugs in resume/suspend handling.

  * Many minor bug fixes and code cleanup.

A detailed description of the changes found in this 2.1 branch can be
found at <https://gnupg.org/faq/whats-new-in-2.1.html>.


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

Please follow the instructions found at <https://gnupg.org/download/> or
read on:

GnuPG 2.1.21 may be downloaded from one of the GnuPG mirror sites or
direct from its primary FTP server.  The list of mirrors can be found at
<https://gnupg.org/download/mirrors.html>.  Note that GnuPG is not
available at ftp.gnu.org.

The GnuPG source code compressed using BZIP2 and its OpenPGP signature
are available here:

 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.21.tar.bz2 (6321k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.21.tar.bz2.sig

or via FTP:

 ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.21.tar.bz2
 ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.21.tar.bz2.sig

An installer for Windows without any graphical frontend except for a
very minimal Pinentry tool is available here:

 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.21_20170515.exe (3762k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.21_20170515.exe.sig

or via FTP:

 ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.21_20170515.exe
 ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.21_20170515.exe.sig

The source used to build the Windows installer can be found in the same
directory with a ".tar.xz" suffix.  The Windows installer comes with
TOFU support, many translations, support for Tor, and support for HKPS
and the Web Key Directory.


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

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

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

     gpg --verify gnupg-2.1.21.tar.bz2.sig gnupg-2.1.21.tar.bz2

   This checks whether the signature file matches the source file.
   You should see a message indicating that the signature is good and
   made by one or more of the release signing keys.  Make sure that
   this is a valid key, either by matching the shown fingerprint
   against a trustworthy list of valid release signing keys or by
   checking that the key has been signed by trustworthy other keys.
   See the end of this mail for information on the signing keys.

 * If you are not able to use an existing version of GnuPG, you have
   to verify the SHA-1 checksum.  On Unix systems the command to do
   this is either "sha1sum" or "shasum".  Assuming you downloaded the
   file gnupg-2.1.21.tar.bz2, you run the command like this:

     sha1sum gnupg-2.1.21.tar.bz2

   and check that the output matches the next line:

1852c066bc21893bc52026ead78edf50fdf15e13  gnupg-2.1.21.tar.bz2
f8a75914e8d82375a89e39fbf45d9f72ed8ab92c  gnupg-w32-2.1.21_20170515.exe
91591e0f197b18b04671c2ca1377f0d195d1fa21  gnupg-w32-2.1.21_20170515.tar.xz


Internationalization
====================

This version of GnuPG has support for 26 languages with Chinese, Czech,
French, German, Japanese, Norwegian, Russian, and Ukrainian being almost
completely translated.  Due to expected changes in forthcoming releases
some strings pertaining to the TOFU code are not yet translated.


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

If you used GnuPG in the past you should read the description of
changes and new features at doc/whats-new-in-2.1.txt or online at

  https://gnupg.org/faq/whats-new-in-2.1.html

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

  https://gnupg.org/documentation/manuals/gnupg/

or in Portable Document Format at

  https://gnupg.org/documentation/manuals/gnupg.pdf .

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

You may also want to follow our postings at <https://gnupg.org/blob/>
and <https://twitter.com/gnupg>.


Support
========

Please consult the archive of the gnupg-users mailing list before
reporting a bug <https://gnupg.org/documentation/mailing-lists.html>.
We suggest to send bug reports for a new release to this list in favor
of filing a bug at <https://bugs.gnupg.org>.  If you need commercial
support check out <https://gnupg.org/service.html>.

If you are a developer and you need a certain feature for your project,
please do not hesitate to bring it to the gnupg-devel mailing list for
discussion.

Maintenance and development of GnuPG is mostly financed by donations.
The GnuPG project employs 4 full-time developers, one part-timer, and
one contractor.  They all work exclusivly on GnuPG and closely related
software like Libgcrypt, GPGME, and GPA.  Please consider to donate via:

                  https://gnupg.org/donate/


Thanks
======

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


The GnuPG hackers,

   Andre, dkg, gniibe, Justus, Kai, Marcus, Neal, and Werner



p.s.
This is an announcement only mailing list.  Please send replies only to
the gnupg-users'at'gnupg.org mailing list.

p.p.s
List of Release Signing Keys:

To guarantee that a downloaded GnuPG version has not been tampered by
malicious entities we provide signature files for all tarballs and
binary versions.  The keys are also signed by the long term keys of
their respective owners.  Current releases are signed by one or more
of these five keys:

  2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31]
  Key fingerprint = D869 2123 C406 5DEA 5E0F  3AB5 249B 39D2 4F25 E3B6
  Werner Koch (dist sig)

  rsa2048/E0856959 2014-10-29 [expires: 2019-12-31]
  Key fingerprint = 46CC 7308 65BB 5C78 EBAB  ADCF 0437 6F3E E085 6959
  David Shaw (GnuPG Release Signing Key) <dshaw 'at' jabberwocky.com>

  rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28]
  Key fingerprint = 031E C253 6E58 0D8E A286  A9F2 2071 B08A 33BD 3F06
  NIIBE Yutaka (GnuPG Release Key) <gniibe 'at' fsij.org>

  rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31]
  Key fingerprint = D238 EA65 D64C 67ED 4C30  73F2 8A86 1B1C 7EFD 60D9
  Werner Koch (Release Signing Key)

  rsa3072/4B092E28 2017-03-17 [expires: 2027-03-15]
  Key fingerprint = 5B80 C575 4298 F0CB 55D8  ED6A BCEF 7E29 4B09 2E28
  Andre Heinecke (Release Signing Key)

You may retrieve these keys from a keyserver using this command

  gpg --keyserver hkp://keys.gnupg.net --recv-keys  \
                  249B39D24F25E3B6 04376F3EE0856959 \
                  2071B08A33BD3F06 8A861B1C7EFD60D9 BCEF7E294B092E28

The keys are also available at https://gnupg.org/signature_key.html and
in any recently released GnuPG tarball in the file g10/distsigkey.gpg .
Note that this mail has been signed by a different key.

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

From bernhard at intevation.de  Tue May 16 09:09:05 2017
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 16 May 2017 09:09:05 +0200
Subject: [communication] 2.1.21 officially "stable" (Re: [Announce] GnuPG
 2.1.21 released)
In-Reply-To: <87bmquvwu1.fsf@wheatstone.g10code.de>
References: <87bmquvwu1.fsf@wheatstone.g10code.de>
Message-ID: <201705160909.09812.bernhard@intevation.de>

Hello,

Am Montag 15 Mai 2017 19:44:38 schrieb Werner Koch:
> The GnuPG team is pleased to announce the availability of a new release
> of GnuPG: version 2.1.21. 

congratulations to the new release!

I couldn't help to notice that GnuPG 2.1.21 is now the official stable
version, in the communication. :)
To me it happened somewhat silently as in the 2.1.19 announcement
on 2017-03-01 there is still a:

| There are two major flavours of GnuPG:
|
| - GnuPG 2.1 (dubbed "modern") comes with the latest features and is
|  suggested for most users.  This announcement is about this branch.
|
|- GnuPG 2.0 is an older but widely used branch which we will maintain
|  until 2017-12-31.

2.1.18 on 2017-01-23 still additionally had:
|| - GnuPG "classic" (1.4) is a simplified version of GnuPG, required on
||   very old platforms or to decrypt data created with PGP-2 keys.
||
|| You may not install "modern" (2.1) and "stable" (2.0) at the same time.
|| However, it is possible to install "classic" (1.4) along with any of the
|| other versions.

For 2.1.20 (2017-04-0) I overread the change, but with 2.1.21 I read:

> About GnuPG
> =============
>
> The GNU Privacy Guard (GnuPG) is a complete and free implementation
> of the OpenPGP standard which is commonly abbreviated as PGP.
>
> GnuPG allows to encrypt and sign data and communication, features a
> versatile key management system as well as access modules for public key
> directories.  GnuPG itself is a command line tool with features for easy
> integration with other applications.  A wealth of frontend applications
> and libraries making use of GnuPG are available.  As an Universal Crypto
> Engine GnuPG provides support for S/MIME and Secure Shell in addition to
> OpenPGP.
>
> GnuPG is Free Software (meaning that it respects your freedom).  It can
> be freely used, modified and distributed under the terms of the GNU
> General Public License.

This is a good development! I had long ago put forward to push more towards 
modern versions to reduce maintenance work and be able to pursue more 
progress.

As this declaration of 2.1.x as stable with 2.1.21 was implicit with a (to me) 
silent change on the webpage and the announcement.
Can you elaborate more on the communication strategy?

Is it okay if this implicit declaration of 2.1.21 as stable is widely 
communicated? 

What does that mean for the version numbering scheme of GnuPG
and the release planning? Is 2.1 not an "experimental" minor release line 
anymore? If it is stable, will 2.2.0 happen and when?

Best Regards,
Bernhard

-- 
www.intevation.de/~bernhard ? +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20170516/02591743/attachment-0001.sig>

From wk at gnupg.org  Tue May 16 13:00:55 2017
From: wk at gnupg.org (Werner Koch)
Date: Tue, 16 May 2017 13:00:55 +0200
Subject: [communication] 2.1.21 officially "stable"
In-Reply-To: <201705160909.09812.bernhard@intevation.de> (Bernhard Reiter's
 message of "Tue, 16 May 2017 09:09:05 +0200")
References: <87bmquvwu1.fsf@wheatstone.g10code.de>
 <201705160909.09812.bernhard@intevation.de>
Message-ID: <874lwlukuw.fsf_-_@wheatstone.g10code.de>

On Tue, 16 May 2017 09:09, bernhard at intevation.de said:

> As this declaration of 2.1.x as stable with 2.1.21 was implicit with a
> (to me) silent change on the webpage and the announcement.  Can you
> elaborate more on the communication strategy?

As long as we don't have a new development branch it does not make much
sense to distinguish between a stable an unstable branch.  I started to
mention the other branches less and less for a couple of months now.
The reason for this is that 2.0 will reach EOL in less than 7 months and
we need to prepare the users to switch to the main version.

We will do a *stable 2.2 branch* when we think it is time to start
working on new features.

> What does that mean for the version numbering scheme of GnuPG
> and the release planning? Is 2.1 not an "experimental" minor release line 

It has never been marked as experimental but as modern ;-)


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170516/ab679c24/attachment.sig>

From dkg at fifthhorseman.net  Wed May 17 04:29:52 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 16 May 2017 22:29:52 -0400
Subject: [Announce] GnuPG 2.1.21 released
In-Reply-To: <87bmquvwu1.fsf@wheatstone.g10code.de>
References: <87bmquvwu1.fsf@wheatstone.g10code.de>
Message-ID: <87shk4dxlr.fsf@fifthhorseman.net>

On Mon 2017-05-15 19:44:38 +0200, Werner Koch wrote:
> The GnuPG team is pleased to announce the availability of a new release
> of GnuPG: version 2.1.21.

Thanks for this release!  The index at
https://gnupg.org/ftp/gcrypt/gnupg/ doesn't appear to be updated,
though.  Could you kick the indexer?

This stale index thing seems to happen with most releases.  Is there
something that can be done to automate the index update upon release?

Regards,

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: </pipermail/attachments/20170516/3fb10585/attachment.sig>

From wk at gnupg.org  Wed May 17 08:40:16 2017
From: wk at gnupg.org (Werner Koch)
Date: Wed, 17 May 2017 08:40:16 +0200
Subject: [Announce] GnuPG 2.1.21 released
In-Reply-To: <87shk4dxlr.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message
 of "Tue, 16 May 2017 22:29:52 -0400")
References: <87bmquvwu1.fsf@wheatstone.g10code.de>
 <87shk4dxlr.fsf@fifthhorseman.net>
Message-ID: <87vap0t29b.fsf@wheatstone.g10code.de>

On Wed, 17 May 2017 04:29, dkg at fifthhorseman.net said:

> Thanks for this release!  The index at
> https://gnupg.org/ftp/gcrypt/gnupg/ doesn't appear to be updated,
> though.  Could you kick the indexer?

Will do.  Frankly, I did not do it right away to see whether it failed
again.  https://dev.gnupg.org/T3035


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170517/e54bc815/attachment.sig>

From wk at gnupg.org  Wed May 17 09:58:58 2017
From: wk at gnupg.org (Werner Koch)
Date: Wed, 17 May 2017 09:58:58 +0200
Subject: [Announce] GnuPG 2.1.21 released
In-Reply-To: <87shk4dxlr.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message
 of "Tue, 16 May 2017 22:29:52 -0400")
References: <87bmquvwu1.fsf@wheatstone.g10code.de>
 <87shk4dxlr.fsf@fifthhorseman.net>
Message-ID: <87o9urud6l.fsf@wheatstone.g10code.de>

On Wed, 17 May 2017 04:29, dkg at fifthhorseman.net said:

> This stale index thing seems to happen with most releases.  Is there
> something that can be done to automate the index update upon release?

Fixed.  Bad cron specifications and the log didn't show them (like I was
used to)


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170517/d24e947e/attachment.sig>

From ineiev at gnu.org  Thu May 18 14:50:21 2017
From: ineiev at gnu.org (Ineiev)
Date: Thu, 18 May 2017 08:50:21 -0400
Subject: [GNUPG HEAD] sqlite3 compatibility issue
Message-ID: <20170518125021.GL25850@gnu.org>

Hello,

GnuPG doesn't build with sqlite 3.7.9 because it has
no sqlite3_errstr ().  I wonder if it could be worked around like

diff --git a/g10/gpgsql.c b/g10/gpgsql.c
index 5b75569..3bade5c 100644
--- a/g10/gpgsql.c
+++ b/g10/gpgsql.c
@@ -64,7 +64,8 @@ gpgsql_stepx (sqlite3 *db,
               const char *sql, ...)
 {
   int rc;
-  int err = 0;
+  int err = SQLITE_OK;
+  const char *errstr = NULL;
   sqlite3_stmt *stmt = NULL;
 
   va_list va;
@@ -161,7 +162,7 @@ gpgsql_stepx (sqlite3 *db,
               log_fatal ("Bad value for parameter type %d.\n", t);
             }
 
-          if (err)
+          if (err != SQLITE_OK)
             {
               log_fatal ("Error binding parameter %d\n", i);
               goto out;
@@ -203,6 +204,7 @@ gpgsql_stepx (sqlite3 *db,
             /* Out of memory.  */
             {
               err = SQLITE_NOMEM;
+              errstr = "out of memory";
               break;
             }
         }
@@ -211,6 +213,7 @@ gpgsql_stepx (sqlite3 *db,
         /* A non-zero result means to abort.  */
         {
           err = SQLITE_ABORT;
+          errstr = "callback requested query abort";
           break;
         }
     }
@@ -218,33 +221,26 @@ gpgsql_stepx (sqlite3 *db,
  out:
   xfree (azColName);
 
+  if (err != SQLITE_OK && errmsg && !errstr)
+    errstr = sqlite3_errmsg (db);
+
   if (stmtp)
     rc = sqlite3_reset (stmt);
   else
     rc = sqlite3_finalize (stmt);
-  if (rc == SQLITE_OK && err)
-    /* Local error.  */
-    {
-      rc = err;
-      if (errmsg)
-        {
-          const char *e = sqlite3_errstr (err);
-          size_t l = strlen (e) + 1;
-          *errmsg = sqlite3_malloc (l);
-          if (! *errmsg)
-            log_fatal ("Out of memory.\n");
-          memcpy (*errmsg, e, l);
-        }
-    }
-  else if (rc != SQLITE_OK && errmsg)
-    /* Error reported by sqlite.  */
+
+  if (rc != SQLITE_OK)
+    errstr = sqlite3_errmsg (db);
+  else
+    rc = err;
+
+  if (rc != SQLITE_OK && errmsg)
     {
-      const char * e = sqlite3_errmsg (db);
-      size_t l = strlen (e) + 1;
+      size_t l = strlen (errstr) + 1;
       *errmsg = sqlite3_malloc (l);
       if (! *errmsg)
         log_fatal ("Out of memory.\n");
-      memcpy (*errmsg, e, l);
+      memcpy (*errmsg, errstr, l);
     }
 
   return rc;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Digital signature
URL: </pipermail/attachments/20170518/9a71c5e6/attachment.sig>

From dkg at fifthhorseman.net  Thu May 18 14:59:06 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 18 May 2017 08:59:06 -0400
Subject: [GNUPG HEAD] sqlite3 compatibility issue
In-Reply-To: <20170518125021.GL25850@gnu.org>
References: <20170518125021.GL25850@gnu.org>
Message-ID: <87shk29v8l.fsf@fifthhorseman.net>

On Thu 2017-05-18 08:50:21 -0400, Ineiev wrote:

> GnuPG doesn't build with sqlite 3.7.9 because it has
> no sqlite3_errstr ().

sqlite3 3.7.9 is positively ancient.  even debian oldstable has 3.7.13.

why should we support such an old version of this library?  I'd imagine
there are sqlite3 security problems that have been fixed since the
release of 3.7.9 (though i haven't dug in that project's archives to
verify).

I'd rather not add compatibility cruft just to support people who
are still running a broken library and really should upgrade.

    --dkg


From astieger at suse.com  Thu May 18 15:19:05 2017
From: astieger at suse.com (Andreas Stieger)
Date: Thu, 18 May 2017 15:19:05 +0200
Subject: [GNUPG HEAD] sqlite3 compatibility issue
In-Reply-To: <20170518125021.GL25850@gnu.org>
References: <20170518125021.GL25850@gnu.org>
Message-ID: <d6dca6ff-ee0e-234c-6f06-f96e9a9e0682@suse.com>

Hi,


On 05/18/2017 02:50 PM, Ineiev wrote:
> GnuPG doesn't build with sqlite 3.7.9 because it has
> no sqlite3_errstr ().  I wonder if it could be worked around like
> [...]
>
>
> @@ -218,33 +221,26 @@ gpgsql_stepx (sqlite3 *db,
>   out:
>    xfree (azColName);
>  
> +  if (err != SQLITE_OK && errmsg && !errstr)
> +    errstr = sqlite3_errmsg (db);
> +
>    if (stmtp)
>      rc = sqlite3_reset (stmt);
>    else
>      rc = sqlite3_finalize (stmt);
> -  if (rc == SQLITE_OK && err)
> -    /* Local error.  */
> -    {
> -      rc = err;
> -      if (errmsg)
> -        {
> -          const char *e = sqlite3_errstr (err);
> -          size_t l = strlen (e) + 1;
> -          *errmsg = sqlite3_malloc (l);
> -          if (! *errmsg)
> -            log_fatal ("Out of memory.\n");
> -          memcpy (*errmsg, e, l);
> -        }
> -    }
> -  else if (rc != SQLITE_OK && errmsg)
> -    /* Error reported by sqlite.  */
> +
> +  if (rc != SQLITE_OK)
> +    errstr = sqlite3_errmsg (db);
> +  else
> +    rc = err;
> +
> +  if (rc != SQLITE_OK && errmsg)
>      {
> -      const char * e = sqlite3_errmsg (db);
> -      size_t l = strlen (e) + 1;
> +      size_t l = strlen (errstr) + 1;
>        *errmsg = sqlite3_malloc (l);
>        if (! *errmsg)
>          log_fatal ("Out of memory.\n");
> -      memcpy (*errmsg, e, l);
> +      memcpy (*errmsg, errstr, l);
>      }
>  
>    return rc;

Too complex. Why not use AC_CHECK_FUNCS to check for the availability of
the function, and conditionally define a stub function matching the
signature of sqlite3_errstr()?

Andreas

-- 
Andreas Stieger <astieger at suse.com>
Project Manager Security
SUSE Linux GmbH, GF: Felix Imend?rffer, Jane Smithard, Graham Norton,
HRB 21284 (AG N?rnberg)




From ineiev at gnu.org  Thu May 18 18:14:18 2017
From: ineiev at gnu.org (Ineiev)
Date: Thu, 18 May 2017 12:14:18 -0400
Subject: [GNUPG HEAD] sqlite3 compatibility issue
In-Reply-To: <87shk29v8l.fsf@fifthhorseman.net>
References: <20170518125021.GL25850@gnu.org> <87shk29v8l.fsf@fifthhorseman.net>
Message-ID: <20170518161418.GM25850@gnu.org>

On Thu, May 18, 2017 at 08:59:06AM -0400, Daniel Kahn Gillmor wrote:
> On Thu 2017-05-18 08:50:21 -0400, Ineiev wrote:
> 
> > GnuPG doesn't build with sqlite 3.7.9 because it has
> > no sqlite3_errstr ().
> 
> sqlite3 3.7.9 is positively ancient.  even debian oldstable has 3.7.13.

3.7.13 doesn't seem to have sqlite3_errstr (), either.

> why should we support such an old version of this library?

3.7.9 is what comes with Trisquel 6.0, and Trisquel 6.0 is still
supported by Trisquel maintainers.  I believe there must be
other distros who provide at least equally old libraries.

> I'd imagine
> there are sqlite3 security problems that have been fixed since the
> release of 3.7.9 (though i haven't dug in that project's archives to
> verify).

I guess they either backported the fixes, or there have been
no real ones.

Thank you!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Digital signature
URL: </pipermail/attachments/20170518/a4a90052/attachment.sig>

From ineiev at gnu.org  Thu May 18 18:19:09 2017
From: ineiev at gnu.org (Ineiev)
Date: Thu, 18 May 2017 12:19:09 -0400
Subject: [GNUPG HEAD] sqlite3 compatibility issue
In-Reply-To: <d6dca6ff-ee0e-234c-6f06-f96e9a9e0682@suse.com>
References: <20170518125021.GL25850@gnu.org>
 <d6dca6ff-ee0e-234c-6f06-f96e9a9e0682@suse.com>
Message-ID: <20170518161909.GN25850@gnu.org>

On Thu, May 18, 2017 at 03:19:05PM +0200, Andreas Stieger wrote:
> 
> Too complex. Why not use AC_CHECK_FUNCS to check for the availability of
> the function, and conditionally define a stub function matching the
> signature of sqlite3_errstr()?

I think that would be more complex. my patch only changes one file,
it doesn't use conditional compilation, and it actually reduces code
size. with AC_CHECK_FUNCS, the number of lines would likely increase.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Digital signature
URL: </pipermail/attachments/20170518/a7a775e4/attachment-0001.sig>

From wk at gnupg.org  Fri May 19 08:21:00 2017
From: wk at gnupg.org (Werner Koch)
Date: Fri, 19 May 2017 08:21:00 +0200
Subject: [GNUPG HEAD] sqlite3 compatibility issue
In-Reply-To: <20170518161909.GN25850@gnu.org> (ineiev@gnu.org's message of
 "Thu, 18 May 2017 12:19:09 -0400")
References: <20170518125021.GL25850@gnu.org>
 <d6dca6ff-ee0e-234c-6f06-f96e9a9e0682@suse.com>
 <20170518161909.GN25850@gnu.org>
Message-ID: <87mva9s6yb.fsf@wheatstone.g10code.de>

On Thu, 18 May 2017 18:19, ineiev at gnu.org said:

> I think that would be more complex. my patch only changes one file,
> it doesn't use conditional compilation, and it actually reduces code
> size. with AC_CHECK_FUNCS, the number of lines would likely increase.

Nope.  We use or will use SQLite also at other places and thus a generic
solution would be the way to go.  However, as of now you can build GnuPG
without SQLite and thus I don't see why we should add backward
compatibility for a niche OS.

As a workaround you could link statically to a decent SQLite version.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170519/e7908d50/attachment.sig>

From ineiev at gnu.org  Fri May 19 10:00:24 2017
From: ineiev at gnu.org (Ineiev)
Date: Fri, 19 May 2017 04:00:24 -0400
Subject: [GNUPG HEAD] sqlite3 compatibility issue
In-Reply-To: <87mva9s6yb.fsf@wheatstone.g10code.de>
References: <20170518125021.GL25850@gnu.org>
 <d6dca6ff-ee0e-234c-6f06-f96e9a9e0682@suse.com>
 <20170518161909.GN25850@gnu.org>
 <87mva9s6yb.fsf@wheatstone.g10code.de>
Message-ID: <20170519080024.GP25850@gnu.org>

On Fri, May 19, 2017 at 08:21:00AM +0200, Werner Koch wrote:
> On Thu, 18 May 2017 18:19, ineiev at gnu.org said:
> 
> > I think that would be more complex. my patch only changes one file,
> > it doesn't use conditional compilation, and it actually reduces code
> > size. with AC_CHECK_FUNCS, the number of lines would likely increase.
> 
> Nope.  We use or will use SQLite also at other places and thus a generic
> solution would be the way to go.  However, as of now you can build GnuPG
> without SQLite and thus I don't see why we should add backward
> compatibility for a niche OS.

Thank you; do you see why configure could detect old versions
and suggest the user that they won't do?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Digital signature
URL: </pipermail/attachments/20170519/a2f33694/attachment.sig>

From ineiev at gnu.org  Fri May 19 10:57:21 2017
From: ineiev at gnu.org (Ineiev)
Date: Fri, 19 May 2017 04:57:21 -0400
Subject: [PINENTRY PATCH] tty button-related fixes and refinements
In-Reply-To: <20161003154952.GK30569@gnu.org>
References: <20160408174738.GA26817@gnu.org> <20160927040242.GM30569@gnu.org>
 <4806cab2-483e-48f2-7807-9866d81ab1d2@fsij.org>
 <20161003154952.GK30569@gnu.org>
Message-ID: <20170519085721.GQ25850@gnu.org>

On Mon, Oct 03, 2016 at 11:49:52AM -0400, Ineiev wrote:
>
> > The patch:
> >
> >     0003-tty-Show-supplied-message-when-using-default.patch
> >
> > is introducing a new feature.  Let me have (more) time to review this
> > closely.
>
> It may be thought of as a new feature, but I think it's essential
> for making pinentry work reliably, especially when the translator
> doesn't care of pinentry-tty.

Rebased against current HEAD.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-tty-Show-supplied-message-when-using-default.patch
Type: text/x-diff
Size: 2294 bytes
Desc: not available
URL: </pipermail/attachments/20170519/362b1e08/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Digital signature
URL: </pipermail/attachments/20170519/362b1e08/attachment.sig>

From steve at gpgtools.org  Fri May 19 14:42:35 2017
From: steve at gpgtools.org (steve (GPGTools))
Date: Fri, 19 May 2017 14:42:35 +0200
Subject: gpg 2.1.21
Message-ID: <821F8390-790F-44A0-B8AF-BA2ABFCDFCA6@gpgtools.org>

Dear all,

we are internally testing gpg 2.1 and ran into an issue with pinentry, when using gpg 2.1.21.

When generating a new subkey for an existing key and canceling the pinentry dialog, a secondary pinentry dialog shows up.

The bug in our ticket system can be found here:
https://gpgtools.lighthouseapp.com/projects/66001/tickets/693 <https://gpgtools.lighthouseapp.com/projects/66001/tickets/693>
There?s a screencast included showing what?s going on.

Are you able to reproduce the problem of the secondary pinentry dialog?

Kind regards,
steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170519/e011e68f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: </pipermail/attachments/20170519/e011e68f/attachment.sig>

From gniibe at fsij.org  Mon May 22 02:39:38 2017
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Mon, 22 May 2017 09:39:38 +0900
Subject: local-user required to avoid card key (was: [Announce] GnuPG
 2.1.21 released)
In-Reply-To: <87h90jtp0r.fsf_-_@wheatstone.g10code.de>
References: <87bmquvwu1.fsf@wheatstone.g10code.de>
 <87shk4dxlr.fsf@fifthhorseman.net> <87o9urud6l.fsf@wheatstone.g10code.de>
 <87o9urd64a.fsf@fifthhorseman.net> <87h90jtp0r.fsf_-_@wheatstone.g10code.de>
Message-ID: <87wp99afn9.fsf@fsij.org>

Hello,

(Cc-ed to gnupg-devel at gnupg.org)

97a2394 was not good.  I was too optimistic and careless about the
change.  I should have been more conservative to introduce such a
change.  Here is a fix. 

With this change, GnuPG only uses the signing key on the card (to sign
or to certify) when default-key is not specified or it's a subkey of
default-key.
-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-g10-Fix-default-key-selection-for-signing-possibly-b.patch
Type: text/x-diff
Size: 6117 bytes
Desc: key selection for signing (when card is available)
URL: </pipermail/attachments/20170522/98f04ab7/attachment.patch>

From wlt-ml at o-sinc.com  Tue May 23 15:36:23 2017
From: wlt-ml at o-sinc.com (William L. Thomson Jr.)
Date: Tue, 23 May 2017 09:36:23 -0400
Subject: DCO for William Thomson
Message-ID: <assp.0316398ca8.20170523093623.00a17d03@o-sinc.com>

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: "William L. Thomson Jr." <wlt at o-sinc.com>

-- 
William L. Thomson Jr.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170523/6262acaa/attachment-0001.sig>

From wk at gnupg.org  Wed May 24 16:03:20 2017
From: wk at gnupg.org (Werner Koch)
Date: Wed, 24 May 2017 16:03:20 +0200
Subject: Paypal donations
Message-ID: <877f16nyhj.fsf@wheatstone.g10code.de>

Hi!

although we are a bit less active in bug fixing these days, that does
not mean we are plain lazy: Instead we are preparing a new donation
campaign and a small technical part of that are recurring donations.

Meanwhile this seems to works for credit cards using Stripe as provider.

However, we have problems to properly test the same thing for Paypal (it
worked in their sandbox, though).  Several tries using German Paypal
accounts failed with a message saying "country not allowed for
recurring" - despite that the Paypal docs say that this is possible for
Germany.  So until now we had only one successful live test using an
Austria based account.

I would appreciate if someone with an US Paypal account could do us a
favor and enter a small recurring donation via Paypal using
https://gnupg.org/donate .  I will cancel and refund that subscription
then in a few days - if it gets through.

Please let us know at donations at gnupg dot org if you can help with
that.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170524/3e818513/attachment.sig>

From thibault at thb.lt  Wed May 24 15:49:59 2017
From: thibault at thb.lt (Thibault Polge)
Date: Wed, 24 May 2017 15:49:59 +0200
Subject: [Question] How to submit translation patch?
Message-ID: <87efve2wl4.fsf@thb.lt>

Hi,

I'm in the process of fixing multiple errors in the French translation
of gpa, and would like to contribute my fixes to the project when I'm
done (that is, probably later today.

Is this the correct place to do so (ie, is there someone here with
commit access and the ability to review a French translation), or is
there somewhere else where I should submit my changes?

Thanks,
Thibault


From wk at gnupg.org  Wed May 24 21:00:08 2017
From: wk at gnupg.org (Werner Koch)
Date: Wed, 24 May 2017 21:00:08 +0200
Subject: [Question] How to submit translation patch?
In-Reply-To: <87efve2wl4.fsf@thb.lt> (Thibault Polge's message of "Wed, 24 May
 2017 15:49:59 +0200")
References: <87efve2wl4.fsf@thb.lt>
Message-ID: <87poeym66f.fsf@wheatstone.g10code.de>

On Wed, 24 May 2017 15:49, thibault at thb.lt said:

> Is this the correct place to do so (ie, is there someone here with
> commit access and the ability to review a French translation), or is

You can do that here, but remember that postings are limited to ~40k.

> there somewhere else where I should submit my changes?

You can open a a task on dev.gnupg.org or post a patch for review there.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170524/d9b40cc5/attachment.sig>

From wlt-ml at o-sinc.com  Thu May 25 02:28:50 2017
From: wlt-ml at o-sinc.com (William L. Thomson Jr.)
Date: Wed, 24 May 2017 20:28:50 -0400
Subject: Pinentry grabbing keyboard and mouse
In-Reply-To: <assp.02766ee152.20170413162612.0ee34678@o-sinc.com>
References: <assp.02766ee152.20170413162612.0ee34678@o-sinc.com>
Message-ID: <assp.03187604e8.20170524202850.0e63fca7@o-sinc.com>

I sent the below message a while back with no response. Though having
looked into the situation more. I have further relevant information.

As stated below, I am pretty sure the Qt 4 and 5, nor FLTK version of
pinentry grab the keyboard and mouse. Only the GTK one, and maybe Gnome
ones do grab keyboard and mouse.

Without going into discussion on such. There is one technical reason
why such may be the case. It is a technical reason why I feel the EFL
version of pinentry should not at this time grab keyboard or mouse.

I have to confirm, but seems grabbing keyboard and/or mouse is not
possible, and/or code exists for such when using Wayland. Which makes
such feature only X specific. That may be why Qt and/or FLTK does not
have grab support. It would not work under Wayland, only X, if both
can be supported without issue.

Regarding the EFL version of pinentry. To support X grab, requires X
specific code. Which can cause crash and issues under Wayland. Or nasty
if define conditionals. Which cannot always prevent some situations, and
still have crash/issues.  For EFL applications it is best to not use
platform specific code. It maybe running under Windows, or Apple cocoa,
in addition to X or Wayland, as an example. Not applicable to
EFL pinentry.

Either way I rather not bind EFL pinentry to X if it is not a
must. Thus for now, till at least Wayland has support for such, and an
abstract layer for both in EFL. The grab code will likely have to be
omitted from EFL pinentry. As it seems to be from QT and FLTK.

On Thu, 13 Apr 2017 16:26:12 -0400
"William L. Thomson Jr." <wlt-ml at o-sinc.com> wrote:

> I was recently discussing the EFL/Enlightenment version of Pinentry
> with the author of the patches previously sent to list, Mike
> Blumenkrantz. Mike based his work off the GTK version. I opened a
> task/ticket on the issue[1].
> 
> In looking at the QT and the newly added FLTK versions. I noticed
> neither seem to be, unless I missed something, grabbing the keyboard
> and mouse as the GTK version does.
> 
> I am not sure if that is legacy or the proper way. Or why other
> versions do not seem to have that feature. Not sure if it is a
> requirement that pinentry be blocking, take over keyboard and mouse.
> Such that the window cannot be moved, nothing else done till
> passphrase entered, confirmation, etc. Or that was just the choice of
> the GTK author at the time of making that version.
> 
> Which is the correct way?
> Is there a requirement on grabbing keyboard and mouse?
> How come other versions seem to lack such feature?
> 
> I just want to be consistent with other versions. Also meet project
> requirements, etc. I will be looking to further Mike's work to get it
> accepted into Pinentry. Hopefully sooner than later, but I understand
> this process can take some time.
> 
> Any information or assistance is greatly appreciated. Thank you!
> 

-- 
William L. Thomson Jr.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170524/f035e580/attachment.sig>

From thibault at thb.lt  Thu May 25 14:25:42 2017
From: thibault at thb.lt (Thibault Polge)
Date: Thu, 25 May 2017 14:25:42 +0200
Subject: [PATCH] [gpa] [i18n] Multiple corrections in fr.po
Message-ID: <87vaopgm3h.fsf@thb.lt>

This patch fixes multiple issues in the current French translation of
GPA, the most important ones being:

 - The original translation used "confiance du propri?taire" for
   "owner trust".  This is really obscure, and literally means the
   trust the owner *has*, not the one you have in them.  This has been
   correct to "confiance dans le propri?taire".

 - The original translation for "Signing keys" was "Cl?s de
   signature", literally "keys used for signing", instead of "Signer
   des cl?s", which corresponds to the action of the menu entry (it is used
   to sign some keys)

Some minor mistakes have also been corrected, For example I've replaced
"fa?tes" (the ridge, the higher edge of a roof) by "faites" (the
imperative form of the verb to do).

I'm not very experienced with git patches, please let me know if I'm
doing something wrong.  If/when all is good with this one, I'll try to
complete the French translation.  Also please let me know if I have to
send a DCO to the list.

Thanks!
Thibault

---
 po/fr.po | 59 +++++++++++++++++++++++++++++------------------------------
 1 file changed, 29 insertions(+), 30 deletions(-)

diff --git a/po/fr.po b/po/fr.po
index 6c42b04..988060b 100644
--- a/po/fr.po
+++ b/po/fr.po
@@ -1,8 +1,9 @@
 # GPA French NLS File.
 # Copyright (C) 2001 Free Software Foundation, Inc.
 # Tranlation updated by
-#  ?ric lassauge <lassauge {AT} users {dot} sourceforge {dot} net>, 2008
+# Thibault Polge <thibault at thb.lt>, 2017.
 # Previous Translators
+# ?ric lassauge <lassauge {AT} users {dot} sourceforge {dot} net>, 2008.
 # pplf <pplf at geocities.com>, 2001.
 # Fabian Rodriguez <fabian at legoutdulibre.com>
 #
@@ -10,7 +11,7 @@ msgid ""
 msgstr ""
 "Project-Id-Version: GPA 0.8.0\n"
 "Report-Msgid-Bugs-To: translations at gnupg.org\n"
-"PO-Revision-Date: 2014-12-08 17:37+0100\n"
+"PO-Revision-Date: 2017-05-25 14:02+0200\n"
 "Last-Translator: Eric Lassauge <lassauge at users.sf.net>\n"
 "Language-Team:  <fr at li.org>\n"
 "Language: fr\n"
@@ -1193,16 +1194,17 @@ msgstr ""
 "valide."

 msgid "Owner Trust"
-msgstr "Confiance du propri?taire"
+msgstr "Confiance dans le propri?taire"

 msgid ""
 "The Owner Trust has been set by you and describes how far you trust the "
 "holder of the certificate to correctly sign (certify) other certificates.  "
 "It is only meaningful for OpenPGP."
 msgstr ""
-"Vous avez indiqu? la Confiance du Propri?taire , cela d?crit le niveau de "
-"confiance que vous apportez au d?tenteur du certificat lorsqu'il signe "
-"(certifie) d'autres certificats. Ceci n'est tenu en compte que par OpenPGP."
+"Vous avez indiqu? la Confiance dans le propri?taire , cela d?crit le"
+"niveau de confiance que vous apportez au d?tenteur du certificat"
+"lorsqu'il signe (certifie) d'autres certificats. Ceci n'est pris en"
+"compte que par OpenPGP."

 msgid "Validity"
 msgstr "Validit?"
@@ -1218,8 +1220,7 @@ msgstr ""
 msgid ""
 "The User Name is the name and often also the email address  of the "
 "certificate."
-msgstr ""
-"Le Nom d'Usager est le nom mais aussi l'adresse courriel de ce certificat. "
+msgstr "Le nom d'usager est compos? du nom et souvent de l'adresse de courriel associ?s ? ce certificat."

 msgid "No keys selected for signing."
 msgstr "Aucune clef s?lectionn?e pour signer."
@@ -1269,16 +1270,16 @@ msgid "Remove the selected key"
 msgstr "Supprimer la clef s?lectionn?e"

 msgid "_Sign Keys..."
-msgstr "Clefs de _signature?"
+msgstr "_Signer des clefs?"

 msgid "Sign the selected key"
 msgstr "Signer la clef s?lectionn?e"

 msgid "Set _Owner Trust..."
-msgstr "Changer la c_onfiance du propri?taire?"
+msgstr "Changer la c_onfiance dans le propri?taire?"

 msgid "Set owner trust of the selected key"
-msgstr "Changer la confiance du propri?taire de la clef s?lectionn?e"
+msgstr "Changer la confiance dans le propri?taire de la clef s?lectionn?e"

 msgid "_Edit Private Key..."
 msgstr "_?diter une clef priv?e?"
@@ -1386,7 +1387,7 @@ msgid "Expires at:"
 msgstr "Expire le :"

 msgid "Owner Trust:"
-msgstr "Confiance du propri?taire :"
+msgstr "Confiance dans le propri?taire :"

 #, fuzzy
 msgid "Key validity:"
@@ -1482,8 +1483,8 @@ msgid ""
 "You don't trust this user at all to verify the validity of other people's "
 "keys at all.\n"
 msgstr ""
-"Vous ne fa?tes pas confiance du tout ? cet utilisateur pour v?rifier la "
-"validit? de la clef des autres\n"
+"Vous ne faites pas confiance du tout ? cet utilisateur pour v?rifier\n"
+"la validit? de la clef des autres\n"

 msgid "_Marginal"
 msgstr "_Marginale"
@@ -1495,12 +1496,12 @@ msgid ""
 "by this user valid if it is also signed by at least other two marginally "
 "trusted users with valid keys\n"
 msgstr ""
-"Vous n'avez pas assez confiance dans la capacit? de cet utilisateur ? "
-"v?rifier la validit? des clefs des autres personnes, pour consid?rer valides "
-"des clefs fond?es sur sa seule parole.\n"
-"Cependant, sachant que la clef de cet utilisateur est valide, vous "
-"consid?rerez comme valide une clef sign?e par cet utilisateur, si elle a "
-"aussi ?t? sign?e au moins par deux utilisateurs auxquels vous accordez une "
+"Vous n'avez pas assez confiance dans la capacit? de cet utilisateur ?"
+"v?rifier la validit? des clefs des autres personnes pour consid?rer"
+"des clefs comme valides du fait de sa seule parole.  Cependant,"
+"si la clef de cet utilisateur est valide, vous consid?rerez"
+"comme valide une clef sign?e par cet utilisateur, si elle a aussi ?t?"
+"sign?e au moins par deux utilisateurs auxquels vous accordez une"
 "confiance marginale et ayant des clefs valides\n"

 msgid "_Full"
@@ -1525,13 +1526,13 @@ msgid ""
 "(Warning: This is intended to be used for keys you own. Don't use it with "
 "other people's keys unless you really know what you are doing)\n"
 msgstr ""
-"Vous consid?rez cette clef comme valide, et fa?tes une telle confiance ? cet "
-"utilisateur que vous consid?rerez toute clef sign?e par lui comme "
-"compl?tement valide.\n"
+"Vous consid?rez cette clef comme valide, et faites une telle confiance"
+"? cet utilisateur que vous consid?rerez toute clef sign?e par lui"
+"comme compl?tement valide.\n"
 "\n"
-"(Attention: Ceci est destin? ? ?tre utilis? pour des clefs que vous "
-"poss?dez. Ne l'utilisez pas avec les clefs des autres personnes, ? moins que "
-"vous sachiez r?ellement ce que vous fa?tes)\n"
+"(Attention: Ceci est destin? ? ?tre utilis? sur des clefs que vous"
+"poss?dez. Ne l'utilisez pas avec les clefs des autres personnes, ?"
+"moins de savoir r?ellement ce que vous faites)\n"

 msgid ""
 "In \"Passphrase\" and \"Repeat passphrase\",\n"
@@ -1852,9 +1853,8 @@ msgstr "Clef expir?e"
 msgid "Key NOT valid"
 msgstr "Clef INVALIDE"

-#, fuzzy
 msgid "Description"
-msgstr "D?chiffrement?"
+msgstr "Description"

 #, c-format
 msgid "Verified data in file: %s"
@@ -1867,9 +1867,8 @@ msgstr "Signatures : %s"
 msgid "Signatures:"
 msgstr "Signatures :"

-#, fuzzy
 msgid "Card Manager"
-msgstr "Gestionnaire de fichiers"
+msgstr "Gestionnaire de cartes"

 #, c-format
 msgid "%s card detected."
--
2.11.0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: </pipermail/attachments/20170525/5bcd3a9c/attachment.sig>

From thibault at thb.lt  Thu May 25 14:35:56 2017
From: thibault at thb.lt (Thibault Polge)
Date: Thu, 25 May 2017 14:35:56 +0200
Subject: [PATCH] [gpa] [i18n] Multiple corrections in fr.po
Message-ID: <87o9uhgllf.fsf@thb.lt>

My apologies: for some reason, the previous message was signed by a
throwaway key.  I must have done something stupid my MUA.  Here's
exactly the same message with a correct signature:

This patch fixes multiple issues in the current French translation of
GPA, the most important ones being:

 - The original translation used "confiance du propri?taire" for
   "owner trust".  This is really obscure, and literally means the
   trust the owner *has*, not the one you have in them.  This has been
   correct to "confiance dans le propri?taire".

 - The original translation for "Signing keys" was "Cl?s de
   signature", literally "keys used for signing", instead of "Signer
   des cl?s", which corresponds to the action of the menu entry (it is used
   to sign some keys)

Some minor mistakes have also been corrected, For example I've replaced
"fa?tes" (the ridge, the higher edge of a roof) by "faites" (the
imperative form of the verb to do).

I'm not very experienced with git patches, please let me know if I'm
doing something wrong.  If/when all is good with this one, I'll try to
complete the French translation.  Also please let me know if I have to
send a DCO to the list.

Thanks!
Thibault

---
 po/fr.po | 59 +++++++++++++++++++++++++++++------------------------------
 1 file changed, 29 insertions(+), 30 deletions(-)

diff --git a/po/fr.po b/po/fr.po
index 6c42b04..988060b 100644
--- a/po/fr.po
+++ b/po/fr.po
@@ -1,8 +1,9 @@
 # GPA French NLS File.
 # Copyright (C) 2001 Free Software Foundation, Inc.
 # Tranlation updated by
-#  ?ric lassauge <lassauge {AT} users {dot} sourceforge {dot} net>, 2008
+# Thibault Polge <thibault at thb.lt>, 2017.
 # Previous Translators
+# ?ric lassauge <lassauge {AT} users {dot} sourceforge {dot} net>, 2008.
 # pplf <pplf at geocities.com>, 2001.
 # Fabian Rodriguez <fabian at legoutdulibre.com>
 #
@@ -10,7 +11,7 @@ msgid ""
 msgstr ""
 "Project-Id-Version: GPA 0.8.0\n"
 "Report-Msgid-Bugs-To: translations at gnupg.org\n"
-"PO-Revision-Date: 2014-12-08 17:37+0100\n"
+"PO-Revision-Date: 2017-05-25 14:02+0200\n"
 "Last-Translator: Eric Lassauge <lassauge at users.sf.net>\n"
 "Language-Team:  <fr at li.org>\n"
 "Language: fr\n"
@@ -1193,16 +1194,17 @@ msgstr ""
 "valide."

 msgid "Owner Trust"
-msgstr "Confiance du propri?taire"
+msgstr "Confiance dans le propri?taire"

 msgid ""
 "The Owner Trust has been set by you and describes how far you trust the "
 "holder of the certificate to correctly sign (certify) other certificates.  "
 "It is only meaningful for OpenPGP."
 msgstr ""
-"Vous avez indiqu? la Confiance du Propri?taire , cela d?crit le niveau de "
-"confiance que vous apportez au d?tenteur du certificat lorsqu'il signe "
-"(certifie) d'autres certificats. Ceci n'est tenu en compte que par OpenPGP."
+"Vous avez indiqu? la Confiance dans le propri?taire , cela d?crit le"
+"niveau de confiance que vous apportez au d?tenteur du certificat"
+"lorsqu'il signe (certifie) d'autres certificats. Ceci n'est pris en"
+"compte que par OpenPGP."

 msgid "Validity"
 msgstr "Validit?"
@@ -1218,8 +1220,7 @@ msgstr ""
 msgid ""
 "The User Name is the name and often also the email address  of the "
 "certificate."
-msgstr ""
-"Le Nom d'Usager est le nom mais aussi l'adresse courriel de ce certificat. "
+msgstr "Le nom d'usager est compos? du nom et souvent de l'adresse de courriel associ?s ? ce certificat."

 msgid "No keys selected for signing."
 msgstr "Aucune clef s?lectionn?e pour signer."
@@ -1269,16 +1270,16 @@ msgid "Remove the selected key"
 msgstr "Supprimer la clef s?lectionn?e"

 msgid "_Sign Keys..."
-msgstr "Clefs de _signature?"
+msgstr "_Signer des clefs?"

 msgid "Sign the selected key"
 msgstr "Signer la clef s?lectionn?e"

 msgid "Set _Owner Trust..."
-msgstr "Changer la c_onfiance du propri?taire?"
+msgstr "Changer la c_onfiance dans le propri?taire?"

 msgid "Set owner trust of the selected key"
-msgstr "Changer la confiance du propri?taire de la clef s?lectionn?e"
+msgstr "Changer la confiance dans le propri?taire de la clef s?lectionn?e"

 msgid "_Edit Private Key..."
 msgstr "_?diter une clef priv?e?"
@@ -1386,7 +1387,7 @@ msgid "Expires at:"
 msgstr "Expire le :"

 msgid "Owner Trust:"
-msgstr "Confiance du propri?taire :"
+msgstr "Confiance dans le propri?taire :"

 #, fuzzy
 msgid "Key validity:"
@@ -1482,8 +1483,8 @@ msgid ""
 "You don't trust this user at all to verify the validity of other people's "
 "keys at all.\n"
 msgstr ""
-"Vous ne fa?tes pas confiance du tout ? cet utilisateur pour v?rifier la "
-"validit? de la clef des autres\n"
+"Vous ne faites pas confiance du tout ? cet utilisateur pour v?rifier\n"
+"la validit? de la clef des autres\n"

 msgid "_Marginal"
 msgstr "_Marginale"
@@ -1495,12 +1496,12 @@ msgid ""
 "by this user valid if it is also signed by at least other two marginally "
 "trusted users with valid keys\n"
 msgstr ""
-"Vous n'avez pas assez confiance dans la capacit? de cet utilisateur ? "
-"v?rifier la validit? des clefs des autres personnes, pour consid?rer valides "
-"des clefs fond?es sur sa seule parole.\n"
-"Cependant, sachant que la clef de cet utilisateur est valide, vous "
-"consid?rerez comme valide une clef sign?e par cet utilisateur, si elle a "
-"aussi ?t? sign?e au moins par deux utilisateurs auxquels vous accordez une "
+"Vous n'avez pas assez confiance dans la capacit? de cet utilisateur ?"
+"v?rifier la validit? des clefs des autres personnes pour consid?rer"
+"des clefs comme valides du fait de sa seule parole.  Cependant,"
+"si la clef de cet utilisateur est valide, vous consid?rerez"
+"comme valide une clef sign?e par cet utilisateur, si elle a aussi ?t?"
+"sign?e au moins par deux utilisateurs auxquels vous accordez une"
 "confiance marginale et ayant des clefs valides\n"

 msgid "_Full"
@@ -1525,13 +1526,13 @@ msgid ""
 "(Warning: This is intended to be used for keys you own. Don't use it with "
 "other people's keys unless you really know what you are doing)\n"
 msgstr ""
-"Vous consid?rez cette clef comme valide, et fa?tes une telle confiance ? cet "
-"utilisateur que vous consid?rerez toute clef sign?e par lui comme "
-"compl?tement valide.\n"
+"Vous consid?rez cette clef comme valide, et faites une telle confiance"
+"? cet utilisateur que vous consid?rerez toute clef sign?e par lui"
+"comme compl?tement valide.\n"
 "\n"
-"(Attention: Ceci est destin? ? ?tre utilis? pour des clefs que vous "
-"poss?dez. Ne l'utilisez pas avec les clefs des autres personnes, ? moins que "
-"vous sachiez r?ellement ce que vous fa?tes)\n"
+"(Attention: Ceci est destin? ? ?tre utilis? sur des clefs que vous"
+"poss?dez. Ne l'utilisez pas avec les clefs des autres personnes, ?"
+"moins de savoir r?ellement ce que vous faites)\n"

 msgid ""
 "In \"Passphrase\" and \"Repeat passphrase\",\n"
@@ -1852,9 +1853,8 @@ msgstr "Clef expir?e"
 msgid "Key NOT valid"
 msgstr "Clef INVALIDE"

-#, fuzzy
 msgid "Description"
-msgstr "D?chiffrement?"
+msgstr "Description"

 #, c-format
 msgid "Verified data in file: %s"
@@ -1867,9 +1867,8 @@ msgstr "Signatures : %s"
 msgid "Signatures:"
 msgstr "Signatures :"

-#, fuzzy
 msgid "Card Manager"
-msgstr "Gestionnaire de fichiers"
+msgstr "Gestionnaire de cartes"

 #, c-format
 msgid "%s card detected."
--
2.11.0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: </pipermail/attachments/20170525/2cd9ac98/attachment-0001.sig>

From wlt-ml at o-sinc.com  Fri May 26 22:04:29 2017
From: wlt-ml at o-sinc.com (William L. Thomson Jr.)
Date: Fri, 26 May 2017 16:04:29 -0400
Subject: Pinentry grabbing keyboard and mouse
In-Reply-To: <87d1avo6os.fsf@fifthhorseman.net>
References: <assp.02766ee152.20170413162612.0ee34678@o-sinc.com>
 <assp.03187604e8.20170524202850.0e63fca7@o-sinc.com>
 <87d1avo6os.fsf@fifthhorseman.net>
Message-ID: <assp.0319b90222.20170526160429.13b629a3@o-sinc.com>

On Fri, 26 May 2017 13:42:59 -0400
Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:

> On Wed 2017-05-24 20:28:50 -0400, William L. Thomson Jr. wrote:
> > I sent the below message a while back with no response.   
> 
> It looks to me like Andre Heinecke responded on Tuesday, April 18th.
> Did you not get that message?

I did not receive that message. I see it in the archives though. Thank
you for mentioning! The comments seem to go inline with my thoughts and
what I experienced using the QT version for a few years.

> > As stated below, I am pretty sure the Qt 4 and 5, nor FLTK version
> > of pinentry grab the keyboard and mouse. Only the GTK one, and
> > maybe Gnome ones do grab keyboard and mouse.  
> 
> pinentry-gnome3 relies on gcr to do the system prompting, so takes its
> lead from that system.
> 
> If your prompting system cannot grab the keyboard or mouse, then it
> makes sense to not support that feature ;)

Seems that Wayland lacks such ability to grab, or has grab API. Which
would make it an X only feature. Rather be consistent.

> pinentry-tty also does not grab the mouse, for example!
> 
> if your prompting system is often used under X11, though, and the
> underlying program has asked to grab the kbd and/or mouse, then it's
> probably worthwhile to try to respect that request, if possible.

Ideally trying to make it portable between X and Wayland, without
having anything special for either.

> does that make sense?  I don't think anyone will blame you for not
> implementing something that is impossible to implement!

Sure, and it seems something that is very much personal preference.
Some prefer the blocking grab, others do not. A technical limitation
makes that easy :)

-- 
William L. Thomson Jr.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170526/f85d8d26/attachment.sig>

From gdt at lexort.com  Mon May 29 20:30:11 2017
From: gdt at lexort.com (Greg Troxel)
Date: Mon, 29 May 2017 14:30:11 -0400
Subject: S/MIME interoperability and libksba (ping on pending patch)
Message-ID: <smur2z7frd8.fsf@linuxpal.mit.edu>


In early 2016 I posted about interoperability issues with S/MIME between
gnus/epg/gpgsm and MS Outlook.  At first I was not clear where the
problem was.   A helpful discussion ensued:

  https://lists.gnupg.org/pipermail/gnupg-devel/2016-February/thread.html#30751

and in particular Daiki Ueno posted a patch to libksba that avoids
truncating leading zeros from the encrypted session key:

  https://lists.gnupg.org/pipermail/gnupg-devel/2016-February/030825.html



I applied the patch locally, and I think things are better, perhaps
entirely better.  However, for the most part I no longer have the
occasion to use gnus/epg/gpgsm.

So I wonder if people think this patch ought to be committed to libksba,
or if not why not?   If it isn't committed, would anyone find it
objectionable if I include that patch into pkgsrc's entry for libksba?

Because the archives don't seem to have Daiki Ueno's patch, I'm
including the version of it that I'm carrying (locally, uncommitted) in
pkgsrc.

Thanks,
Greg


--- src/cms.c.orig	2013-03-15 19:26:38.000000000 +0000
+++ src/cms.c
@@ -87,6 +87,8 @@ static const char oid_signingTime[9] = "
 
 static const char oidstr_smimeCapabilities[] = "1.2.840.113549.1.9.15";
 
+static const char oidstr_rsaEncryption[] = "1.2.840.113549.1.1.1";
+
 
 
 /* Helper for read_and_hash_cont().  */
@@ -1621,7 +1623,7 @@ ksba_cms_set_sig_val (ksba_cms_t cms, in
     return gpg_error (GPG_ERR_ENOMEM);
   if (n==3 && s[0] == 'r' && s[1] == 's' && s[2] == 'a')
     { /* kludge to allow "rsa" to be passed as algorithm name */
-      sv->algo = xtrystrdup ("1.2.840.113549.1.1.1");
+      sv->algo = xtrystrdup (oidstr_rsaEncryption);
       if (!sv->algo)
         {
           xfree (sv);
@@ -1674,9 +1676,10 @@ ksba_cms_set_sig_val (ksba_cms_t cms, in
       return gpg_error (GPG_ERR_INV_SEXP);
     }
 
-  if (n > 1 && !*s)
+  if (strcmp (sv->algo, oidstr_rsaEncryption) != 0 && n > 1 && !*s)
     { /* We might have a leading zero due to the way we encode
-         MPIs - this zero should not go into the OCTECT STRING.  */
+         MPIs - this zero should not go into the OCTECT STRING,
+         unless it is explicitly allowed in the signature scheme.  */
       s++;
       n--;
     }
@@ -1798,7 +1801,7 @@ ksba_cms_set_enc_val (ksba_cms_t cms, in
   xfree (cl->enc_val.algo);
   if (n==3 && s[0] == 'r' && s[1] == 's' && s[2] == 'a')
     { /* kludge to allow "rsa" to be passed as algorithm name */
-      cl->enc_val.algo = xtrystrdup ("1.2.840.113549.1.1.1");
+      cl->enc_val.algo = xtrystrdup (oidstr_rsaEncryption);
       if (!cl->enc_val.algo)
         return gpg_error (GPG_ERR_ENOMEM);
     }
@@ -1831,9 +1834,10 @@ ksba_cms_set_enc_val (ksba_cms_t cms, in
   if (!n || *s != ':')
     return gpg_error (GPG_ERR_INV_SEXP);
   s++;
-  if (n > 1 && !*s)
+  if (strcmp (cl->enc_val.algo, oidstr_rsaEncryption) != 0 && n > 1 && !*s)
     { /* We might have a leading zero due to the way we encode
-         MPIs - this zero should not go into the OCTECT STRING.  */
+         MPIs - this zero should not go into the OCTECT STRING,
+         unless it is explicitly allowed in the encryption scheme.  */
       s++;
       n--;
     }
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 162 bytes
Desc: not available
URL: </pipermail/attachments/20170529/54b0c5ad/attachment.sig>

From myonium at gmail.com  Wed May 31 21:18:00 2017
From: myonium at gmail.com (Myonium)
Date: Wed, 31 May 2017 21:18:00 +0200
Subject: Fwd: card_status - change-request to update allways
References: <558E1C26-A190-48FE-ACFB-A050A7FC812E@gmail.com>
Message-ID: <AA59DBEB-67BA-4A7D-8CAC-CAA16F93DF95@gmail.com>

Hi Werner

Any chance to get this change pushed into the next build?
----------------------snip-------------------------
diff --git a/g10/card-util.c b/g10/card-util.c
index 78cd52b..950b76f 100644
--- a/g10/card-util.c
+++ b/g10/card-util.c
@@ -376,7 +376,7 @@ current_card_status (ctrl_t ctrl, estream_t fp,
   if (serialno && serialnobuflen)
     *serialno = 0;
 
-  rc = agent_scd_learn (&info, 0);
+  rc = agent_scd_learn (&info, 1);
   if (rc)
     {
       if (opt.with_colons)
----------------------snip????????????

Best,
Ben

> Begin forwarded message:
> 
> From: Myonium <myonium at gmail.com>
> Subject: card_status - change-request to update allways
> Date: May 14, 2017 at 11:29:32 GMT+2
> To: gnupg-devel at gnupg.org
> 
> Hi all
> 
> I would love to change the ?card_status? behavior to always update the "key stubs?. (It's only a 1 character change ;-) 
> 
> Is there anything which would speak against making the following change:
> 
> diff --git a/g10/card-util.c b/g10/card-util.c
> index 78cd52b..950b76f 100644
> --- a/g10/card-util.c
> +++ b/g10/card-util.c
> @@ -376,7 +376,7 @@ current_card_status (ctrl_t ctrl, estream_t fp,
>  if (serialno && serialnobuflen)
>    *serialno = 0;
> 
> -  rc = agent_scd_learn (&info, 0);
> +  rc = agent_scd_learn (&info, 1);
> 
> With ?force=true? agent_scd_learn will always update the ?key stub?. I.e. if a new card is attached containing the ?private key? of an already known keygrip it will update the stub so that the newly attached token can be used for crypto-operations.
> I cannot think of any scenario where somebody does not want such a behavior or where this could brake anything. In case the user would shuffle back the old token the system would be reverted back to the old key stub. 
> 
> Please advise. Many thanks,
> Ben

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170531/6b52a677/attachment.html>