From wk at gnupg.org  Mon Feb  1 08:27:54 2016
From: wk at gnupg.org (Werner Koch)
Date: Mon, 01 Feb 2016 08:27:54 +0100
Subject: status of S/MIME and interoperability?
In-Reply-To: <rmih9hvx4jq.fsf@fnord.ir.bbn.com> (Greg Troxel's message of
 "Fri, 29 Jan 2016 20:02:49 -0500")
References: <rmih9hvx4jq.fsf@fnord.ir.bbn.com>
Message-ID: <87vb68j3et.fsf@vigenere.g10code.de>

On Sat, 30 Jan 2016 02:02, gdt at ir.bbn.com said:
> I am using gnus/epg/gpgsm (emacs 24, gpgsm 2.0.29, on NetBSD 6 i386) to
> do S/MIME.  Yes, I know why I should use OpenPGP instead, and the entire

I have had problems with epg and S/MIME.  Without a real need to get
this working I just ignore the problems.  I am still using Emacs 23,
though.


Shalom-Salam,

   Werner

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

From rick at openfortress.nl  Mon Feb  1 17:38:47 2016
From: rick at openfortress.nl (Rick van Rein)
Date: Mon, 01 Feb 2016 17:38:47 +0100
Subject: Failure to import home-brewn public key file
Message-ID: <56AF8A17.3040605@openfortress.nl>

Hello,

I'm trying to generate public keys from PKCS #11 private keys using
https://github.com/arpa2/tlspool/blob/master/tool/pgp11_genkey.c

The public key files look good, but they don't import into GnuPG 1.4.12.

I've compared the file syntax with a freshly created key, and it looks
very similar.  I've double-checked the data that feeds into the
signature, and it seems to conform to RFC 4880.  Do you have any
suggestions on how to resolve this?

Below is output on what I've tried.  Just let me know if you'd like to
see a generated public key.


Thanks for any suggestions!

-Rick


The signed subpacket data in the UserID-signature contained:

05 02 56 af 26 f6  (timestamp)
02 1b 21           (key flags)

while the User ID packet looks like

00000110  cd 2f 4f 70 65 6e 50 47  50 20 54 65 73 74 20 43  |  OpenPGP
Test C|
00000120  6c 69 65 6e 74 20 3c 74  65 73 74 63 6c 69 40 74  |lient
<testcli at t|
00000130  6c 73 70 6f 6f 6c 2e 61  72 70 61 32 2e 6c 61 62 
|lspool.arpa2.lab|
00000140  3e                                               
|>               |


GnuPG is ignoring the self-made key, stating:

gpg: key 3257A80C: no valid user IDs
gpg: this may be caused by a missing self-signature
gpg: Total number processed: 1
gpg:           w/o user IDs: 1

With --debug-all I could not find an underlying problem:

gpg: reading options from `/root/.gnupg/gpg.conf'
gpg: DBG: fd_cache_open (keyout.pgp) not cached
gpg: DBG: iobuf-1.0: open `keyout.pgp' fd=3
gpg: DBG: armor-filter: control: 5
gpg: DBG: iobuf-1.1: push `armor_filter'
gpg: DBG: armor-filter: control: 5
gpg: DBG: iobuf chain: 1.1 `armor_filter' filter_eof=0 start=0 len=0
gpg: DBG: iobuf chain: 1.0 `file_filter(fd)' filter_eof=0 start=0 len=0
gpg: DBG: armor-filter: control: 1
gpg: DBG: iobuf-1.1: underflow: req=8192
gpg: DBG: armor-filter: control: 3
gpg: DBG: iobuf-1.0: underflow: req=8192
gpg: DBG: iobuf-1.0: underflow: got=1173 rc=0
gpg: DBG: iobuf-1.1: underflow: got=37 rc=0
gpg: DBG: parse_packet(iob=1): type=6 length=269 (new_ctb)
(parse.../../g10/import.c.390)
gpg: DBG: mpi_alloc(2048)
gpg: DBG: mpi_alloc_limb_space(2048)
gpg: DBG: iobuf-1.1: underflow: req=8192
gpg: DBG: armor-filter: control: 3
gpg: DBG: iobuf-1.0: underflow: req=8192
gpg: DBG: iobuf-1.0: underflow: got=0 rc=-1
gpg: DBG: keyout.pgp: close fd 3
gpg: DBG: fd_cache_close (keyout.pgp) new slot created
gpg: DBG: iobuf-1.0: underflow: eof
gpg: DBG: iobuf-1.1: underflow: got=1136 rc=0
gpg: DBG: mpi_alloc(64)
gpg: DBG: mpi_alloc_limb_space(64)
gpg: DBG: parse_packet(iob=1): type=13 length=47 (new_ctb)
(parse.../../g10/import.c.390)
gpg: DBG: parse_packet(iob=1): type=2 length=287 (new_ctb)
(parse.../../g10/import.c.390)
gpg: DBG: mpi_alloc(2048)
gpg: DBG: mpi_alloc_limb_space(2048)
gpg: DBG: parse_packet(iob=1): type=14 length=269 (new_ctb)
(parse.../../g10/import.c.390)
gpg: DBG: mpi_alloc(2048)
gpg: DBG: mpi_alloc_limb_space(2048)
gpg: DBG: mpi_alloc(64)
gpg: DBG: mpi_alloc_limb_space(64)
gpg: DBG: parse_packet(iob=1): type=2 length=287 (new_ctb)
(parse.../../g10/import.c.390)
gpg: DBG: mpi_alloc(2048)
gpg: DBG: mpi_alloc_limb_space(2048)
gpg: DBG: iobuf-1.1: underflow: req=8192
gpg: DBG: armor-filter: control: 3
gpg: DBG: iobuf-1.0: underflow: eof (due to filter eof)
gpg: DBG: iobuf-1.1: underflow: got=0 rc=-1
gpg: DBG: armor-filter: control: 2
gpg: DBG: iobuf-1.1: pop in underflow (!len)
gpg: DBG: iobuf chain: 1.0 `[none]' filter_eof=0 start=1173 len=1173
gpg: DBG: iobuf-1.0: underflow: eof
gpg: DBG: free_packet() type=13
gpg: DBG: free_packet() type=2
gpg: DBG: mpi_free
gpg: DBG: dummy m_size called
gpg: DBG: mpi_free_limb_space of size 0
gpg: DBG: free_packet() type=14
gpg: DBG: mpi_free
gpg: DBG: dummy m_size called
gpg: DBG: mpi_free_limb_space of size 0
gpg: DBG: mpi_free
gpg: DBG: dummy m_size called
gpg: DBG: mpi_free_limb_space of size 0
gpg: DBG: free_packet() type=2
gpg: DBG: mpi_free
gpg: DBG: dummy m_size called
gpg: DBG: mpi_free_limb_space of size 0
gpg: key 3257A80C: no valid user IDs
gpg: this may be caused by a missing self-signature
gpg: DBG: free_packet() type=6
gpg: DBG: mpi_free
gpg: DBG: dummy m_size called
gpg: DBG: mpi_free_limb_space of size 0
gpg: DBG: mpi_free
gpg: DBG: dummy m_size called
gpg: DBG: mpi_free_limb_space of size 0
gpg: DBG: iobuf-1.0: underflow: eof (no filter)
gpg: DBG: iobuf-1.0: close `?'
gpg: DBG: iobuf-*.*: ioctl `keyout.pgp' invalidate
gpg: DBG: fd_cache_invalidate (keyout.pgp)
gpg: DBG:                 did (keyout.pgp)
gpg: Total number processed: 1
gpg:           w/o user IDs: 1
random usage: poolsize=600 mixed=0 polls=0/1 added=5/176
              outmix=0 getlvl1=0/0 getlvl2=0/0
secmem usage: 1408/1408 bytes in 2/2 blocks of pool 1408/32768



A home-brewn parser says similar things to GnuPG on the self-made key...

shell$ pgpsplit.py
read keyfile restlen 1173
tag 6 data length 269 restlen 901
no sigdata
tag 13 data length 47 restlen 852
tag 2 data length 287 restlen 562
got sigdata 290 restlen 562
tag 14 data length 269 restlen 290
tag 14 data length 269 restlen 290
tag 2 data length 287 restlen 0
got sigdata 290 restlen 0
Public key 272 #uids 1 #subs 1
 - core.gpg length: 272
 - uid0.gpg length: 339
 - sub0.gpg length: 562
To construct a partial PGP key, combine the following parts:
 - core.pgp
 - one or more uid*.pgp
 - as many sub*.pgp as you like

...and it says virtually the same on an RSA/2048 key generated by OpenPGP...

shell$ pgpsplit.py
read keyfile restlen 1187
tag 6 data length 269 restlen 915
no sigdata
tag 13 data length 36 restlen 877
tag 2 data length 312 restlen 562
got sigdata 315 restlen 562
tag 14 data length 269 restlen 290
tag 14 data length 269 restlen 290
tag 2 data length 287 restlen 0
got sigdata 290 restlen 0
Public key 272 #uids 1 #subs 1
 - core.gpg length: 272
 - uid0.gpg length: 353
 - sub0.gpg length: 562
To construct a partial PGP key, combine the following parts:
 - core.pgp
 - one or more uid*.pgp
 - as many sub*.pgp as you like


This data is traced by wrapping the C_SignUpdate command, which tunnels
the data into SHA256 and RSA:

DEBUG: Initialising signature
DEBUG: Signature hexbytes: 99 01 0d
DEBUG: Signature hexbytes: 04 56 af 26 f6 01 08 00 e2 55 12 3a f6 18 9f
b8 8e a6 2c e6 c5 fc 13 61 72 8c 09 75 f5 9f 76 dd e9 0a 2c cc aa f4 bd
e0 07 88 55 cb 16 5d a2 0d 89 d5 51 67 e7 46 90 cd b2 25 b1 e7 50 3a 33
f3 58 e7 2f fa 87 97 1d 11 52 60 08 d9 dd d3 19 f4 93 a9 95 9f 66 4d a8
25 a1 8b cc f8 9c c7 c7 5a cc 50 78 05 68 3d 63 8d 03 d4 6e 73 27 0b 8d
d3 a1 c1 81 c8 9e 96 49 eb d9 e0 19 4e 82 b5 64 ca 65 2a e4 11 52 f4 4b
a3 f6 ae 34 34 3f 09 e2 8b b0 2f 09 df 49 25 95 a2 e3 e9 1e 32 07 88 ca
2f 89 98 b3 46 7c d2 f5 41 07 b4 18 f7 3f 08 d4 1b d7 7f ae 6e 4f 98 b7
2e 16 4b 08 7a 15 da f0 e2 f0 83 a0 0b b9 26 6b 13 34 74 05 1f b5 1a 6a
8d 25 dd d6 f9 ec 76 77 b9 33 e3 ef 3f 68 61 af 81 07 07 3b a4 b9 47 6c
33 64 45 f5 6a 54 64 58 93 c4 39 79 7f 87 5a 0f a6 84 aa cd ea bd 96 94
4a 6f d0 ea c1 29 31 f2 8f 00 10 00 00 00
DEBUG: Signature hexbytes: b4 00 00 00 2f
DEBUG: Signature hexbytes: 4f 70 65 6e 50 47 50 20 54 65 73 74 20 43 6c
69 65 6e 74 20 3c 74 65 73 74 63 6c 69 40 74 6c 73 70 6f 6f 6c 2e 61 72
70 61 32 2e 6c 61 62 3e
DEBUG: Signature hexbytes: 04 10 01 08 00 09 05 02 56 af 26 f6 02 1b 21
DEBUG: Signature hexbytes: 04 ff 00 00 00 0f
DEBUG: Finalising signature

-------------- next part --------------
A non-text attachment was scrubbed...
Name: home_brewn_key.pgp
Type: application/octet-stream
Size: 1173 bytes
Desc: not available
URL: </pipermail/attachments/20160201/9e0e7081/attachment.obj>

From rick at openfortress.nl  Mon Feb  1 22:11:08 2016
From: rick at openfortress.nl (Rick van Rein)
Date: Mon, 01 Feb 2016 22:11:08 +0100
Subject: Failure to import home-brewn public key file
In-Reply-To: <7E099CAB-EFB6-490C-9BC0-2D6DA463B3B4@jabberwocky.com>
References: <56AF8A17.3040605@openfortress.nl>
 <7E099CAB-EFB6-490C-9BC0-2D6DA463B3B4@jabberwocky.com>
Message-ID: <56AFC9EC.5090000@openfortress.nl>

Hello David,

> GnuPG requires each user ID to have a self-signature to prove that the user ID wasn't added by someone other than the key owner (the self-signature also carries some useful information like cipher choices).  The user ID on this key doesn't have a self-signature - there's a signature there on the user ID, but it's not issued by the key itself:

Ah, that would explain things!

> :public key packet:
> 	version 4, algo 1, created 1454319350, expires 0
> 	pkey[0]: [2048 bits]
> 	pkey[1]: [0 bits]
> 	keyid: F25CA9043257A80C

What did you use to generate this output?

> So the key is F25CA9043257A80C, but the signature was made by 56EA25ACD215439F.
>
> You can override the self-signature check (---allow-non-selfsigned-uid) but this is not recommended as such a user ID is easy to forge.

The override worked, so you clearly spotted the problem in my code.

Thanks a lot, this should prove helpful!

Best wishes,
 -Rick


From dshaw at jabberwocky.com  Mon Feb  1 21:59:08 2016
From: dshaw at jabberwocky.com (David Shaw)
Date: Mon, 1 Feb 2016 15:59:08 -0500
Subject: Failure to import home-brewn public key file
In-Reply-To: <56AF8A17.3040605@openfortress.nl>
References: <56AF8A17.3040605@openfortress.nl>
Message-ID: <7E099CAB-EFB6-490C-9BC0-2D6DA463B3B4@jabberwocky.com>

On Feb 1, 2016, at 11:38 AM, Rick van Rein <rick at openfortress.nl> wrote:
> 
> Hello,
> 
> I'm trying to generate public keys from PKCS #11 private keys using
> https://github.com/arpa2/tlspool/blob/master/tool/pgp11_genkey.c
> 
> The public key files look good, but they don't import into GnuPG 1.4.12.
> 
> I've compared the file syntax with a freshly created key, and it looks
> very similar.  I've double-checked the data that feeds into the
> signature, and it seems to conform to RFC 4880.  Do you have any
> suggestions on how to resolve this?
> 
> Below is output on what I've tried.  Just let me know if you'd like to
> see a generated public key.
> 
> 
> Thanks for any suggestions!
> 
> -Rick
> 
> 
> The signed subpacket data in the UserID-signature contained:
> 
> 05 02 56 af 26 f6  (timestamp)
> 02 1b 21           (key flags)
> 
> while the User ID packet looks like
> 
> 00000110  cd 2f 4f 70 65 6e 50 47  50 20 54 65 73 74 20 43  |  OpenPGP
> Test C|
> 00000120  6c 69 65 6e 74 20 3c 74  65 73 74 63 6c 69 40 74  |lient
> <testcli at t|
> 00000130  6c 73 70 6f 6f 6c 2e 61  72 70 61 32 2e 6c 61 62 
> |lspool.arpa2.lab|
> 00000140  3e                                               
> |>               |
> 
> 
> GnuPG is ignoring the self-made key, stating:
> 
> gpg: key 3257A80C: no valid user IDs
> gpg: this may be caused by a missing self-signature
> gpg: Total number processed: 1
> gpg:           w/o user IDs: 1

GnuPG requires each user ID to have a self-signature to prove that the user ID wasn't added by someone other than the key owner (the self-signature also carries some useful information like cipher choices).  The user ID on this key doesn't have a self-signature - there's a signature there on the user ID, but it's not issued by the key itself:

:public key packet:
	version 4, algo 1, created 1454319350, expires 0
	pkey[0]: [2048 bits]
	pkey[1]: [0 bits]
	keyid: F25CA9043257A80C
:user ID packet: "OpenPGP Test Client <testcli at tlspool.arpa2.lab>"
:signature packet: algo 1, keyid 56EA25ACD215439F
	version 4, created 1454319350, md5len 0, sigclass 0x10
	digest algo 8, begin of digest cd d9
	hashed subpkt 2 len 4 (sig created 2016-02-01)
	hashed subpkt 27 len 1 (key flags: 21)
	subpkt 16 len 8 (issuer key ID 56EA25ACD215439F)
	data: [2048 bits]

So the key is F25CA9043257A80C, but the signature was made by 56EA25ACD215439F.

You can override the self-signature check (---allow-non-selfsigned-uid) but this is not recommended as such a user ID is easy to forge.

David



From justus at g10code.com  Mon Feb  1 20:48:41 2016
From: justus at g10code.com (Justus Winter)
Date: Mon, 01 Feb 2016 20:48:41 +0100
Subject: intermittent failures in tests/openpgp/gpgtar.test
In-Reply-To: <871t91btd9.fsf@alice.fifthhorseman.net>
References: <871t91btd9.fsf@alice.fifthhorseman.net>
Message-ID: <20160201194841.20704.18248@thinkbox.jade-hamburg.de>

Hi Daniel,

Quoting Daniel Kahn Gillmor (2016-01-28 16:45:22)
> I've packaged gnupg 2.1.11 for debian and uploaded it to debian
> unstable.  however, i'm seeing intermittent failures in the gpgtar test
> suite.  Particularly, in tests/openpgp/gpgtar.test.  These are not
> reliable failures -- they just happen sometimes, frustratingly enough.

I have also seen it fail every now and then.  I'll look into that.

Justus


From dshaw at jabberwocky.com  Tue Feb  2 00:30:38 2016
From: dshaw at jabberwocky.com (David Shaw)
Date: Mon, 1 Feb 2016 18:30:38 -0500
Subject: Failure to import home-brewn public key file
In-Reply-To: <56AFC9EC.5090000@openfortress.nl>
References: <56AF8A17.3040605@openfortress.nl>
 <7E099CAB-EFB6-490C-9BC0-2D6DA463B3B4@jabberwocky.com>
 <56AFC9EC.5090000@openfortress.nl>
Message-ID: <3AA46BF6-3094-47B7-9BDD-E148DFF8B33F@jabberwocky.com>

On Feb 1, 2016, at 4:11 PM, Rick van Rein <rick at openfortress.nl> wrote:
> 
> Hello David,
> 
>> GnuPG requires each user ID to have a self-signature to prove that the user ID wasn't added by someone other than the key owner (the self-signature also carries some useful information like cipher choices).  The user ID on this key doesn't have a self-signature - there's a signature there on the user ID, but it's not issued by the key itself:
> 
> Ah, that would explain things!
> 
>> :public key packet:
>> 	version 4, algo 1, created 1454319350, expires 0
>> 	pkey[0]: [2048 bits]
>> 	pkey[1]: [0 bits]
>> 	keyid: F25CA9043257A80C
> 
> What did you use to generate this output?

That's gpg itself.  If you run "gpg --list-packets" on a file, it'll show you the internals of each packet.  It's a super handy debug tool for this sort of thing.

Good luck!

David



From ueno at gnu.org  Tue Feb  2 10:26:17 2016
From: ueno at gnu.org (Daiki Ueno)
Date: Tue, 02 Feb 2016 18:26:17 +0900
Subject: status of S/MIME and interoperability?
In-Reply-To: <87vb68j3et.fsf@vigenere.g10code.de> (Werner Koch's message of
 "Mon, 01 Feb 2016 08:27:54 +0100")
References: <rmih9hvx4jq.fsf@fnord.ir.bbn.com>
 <87vb68j3et.fsf@vigenere.g10code.de>
Message-ID: <m3a8njzcna.fsf-ueno@gnu.org>

Werner Koch <wk at gnupg.org> writes:

> On Sat, 30 Jan 2016 02:02, gdt at ir.bbn.com said:
>> I am using gnus/epg/gpgsm (emacs 24, gpgsm 2.0.29, on NetBSD 6 i386) to
>> do S/MIME.  Yes, I know why I should use OpenPGP instead, and the entire
>
> I have had problems with epg and S/MIME.  Without a real need to get
> this working I just ignore the problems.  I am still using Emacs 23,
> though.

It's not surprising; me too use S/MIME only occasionally to verify
emails from certain senders :-)

Greg Troxel <gdt at ir.bbn.com> writes:

> Sending, my impression is that users of Thunderbird and Mail.app
> following can receive my encrypted messages, at least without large
> attachments.  But Outlook users appear not to be able to process
> encrypted messages from gnus/gpgsm.

For this particular interop issue, I am curious what is causing the
difference.  S/MIME encrypted messages are typically in the
enveloped-data format, which means that the encrypted content is simply
treated as an attachment.

If you have access to an MUA interoperable with Outlook, could you
compare the message structures for the success/failure cases?

Regards,
-- 
Daiki Ueno


From rick at openfortress.nl  Tue Feb  2 11:39:07 2016
From: rick at openfortress.nl (Rick van Rein)
Date: Tue, 02 Feb 2016 11:39:07 +0100
Subject: Failure to import home-brewn public key file
In-Reply-To: <3AA46BF6-3094-47B7-9BDD-E148DFF8B33F@jabberwocky.com>
References: <56AF8A17.3040605@openfortress.nl>
 <7E099CAB-EFB6-490C-9BC0-2D6DA463B3B4@jabberwocky.com>
 <56AFC9EC.5090000@openfortress.nl>
 <3AA46BF6-3094-47B7-9BDD-E148DFF8B33F@jabberwocky.com>
Message-ID: <56B0874B.3070702@openfortress.nl>

Hello David,

> If you run "gpg --list-packets" on a file, it'll show you the
> internals of each packet. It's a super handy debug tool for this sort
> of thing.

Indeed it is!  It showed that my public key was 0 bits wide, which I
improved to get the right key ID.

The signature was also off (was not hashing quite the right range of
bytes) and it surprised me that GnuPG didn't make that explicit, but
rather continue to reject the User ID as unsigned.  But combining your
hint of --allow-non-selfsigned-uid and later --check-sigs taught me that.

> Good luck!
Nailed it :)  The working code is on

https://github.com/arpa2/tlspool/blob/master/tool/pgp11_genkey.c

It is hoped to help to get OpenPGP keys used more in TLS connections!


Thanks for your help!
 -Rick



From rick at openfortress.nl  Tue Feb  2 14:51:43 2016
From: rick at openfortress.nl (Rick van Rein)
Date: Tue, 02 Feb 2016 14:51:43 +0100
Subject: PKCS #11 support for OpenPGP public keys
Message-ID: <56B0B46F.3060206@openfortress.nl>

Hi,

Since I was posting on PKCS #11 and OpenPGP, perhaps this may also be of
interest:

I wrote an extension proposal for storage of OpenPGP transferrable
public keys in PKCS #11,
http://openfortress.nl/doc/spec/pgp-in-pkcs11/

This is implemented in SoftHSMv2; other HSM vendors should find it
interesting as well.  At some point we're hoping to get it incorporated
into the standard.

Why?  Unlike X.509 certificates, several attributes for OpenPGP keys
must be modifiable.  And we need CKC_OPENPGP to know how to interpret
the binaries as OpenPGP public keys.

Cheers,
 -Rick


From edfinnerty at gmx.com  Tue Feb  2 17:56:27 2016
From: edfinnerty at gmx.com (Ed Finnerty)
Date: Tue, 2 Feb 2016 18:56:27 +0200
Subject: status of S/MIME and interoperability?
In-Reply-To: <m3a8njzcna.fsf-ueno@gnu.org>
References: <rmih9hvx4jq.fsf@fnord.ir.bbn.com>
 <87vb68j3et.fsf@vigenere.g10code.de> <m3a8njzcna.fsf-ueno@gnu.org>
Message-ID: <56B0DFBB.3040607@gmx.com>

>> Sending, my impression is that users of Thunderbird and Mail.app
>> following can receive my encrypted messages, at least without large
>> attachments.  But Outlook users appear not to be able to process
>> encrypted messages from gnus/gpgsm.
> 
> For this particular interop issue, I am curious what is causing the
> difference.  S/MIME encrypted messages are typically in the
> enveloped-data format, which means that the encrypted content is simply
> treated as an attachment.
> 
> If you have access to an MUA interoperable with Outlook, could you
> compare the message structures for the success/failure cases?

I've actually logged the problem here and even attached a script that
easily tests for the issue and can be modified to produce trivial test
output for comparison purposes.

Nobody seemed to really care. So if you do S/MIME with GPG, and use
Thunderbird, every once in a while you'll get an undecryptable message
that you have to save to disk and try to deal with in some way with GPG.


From edfinnerty at gmx.com  Tue Feb  2 17:58:59 2016
From: edfinnerty at gmx.com (Ed Finnerty)
Date: Tue, 2 Feb 2016 18:58:59 +0200
Subject: status of S/MIME and interoperability?
In-Reply-To: <56B0DFBB.3040607@gmx.com>
References: <rmih9hvx4jq.fsf@fnord.ir.bbn.com>
 <87vb68j3et.fsf@vigenere.g10code.de> <m3a8njzcna.fsf-ueno@gnu.org>
 <56B0DFBB.3040607@gmx.com>
Message-ID: <56B0E053.6080309@gmx.com>

On 02/02/2016 06:56 PM, Ed Finnerty wrote:
>>> Sending, my impression is that users of Thunderbird and Mail.app
>>> following can receive my encrypted messages, at least without large
>>> attachments.  But Outlook users appear not to be able to process
>>> encrypted messages from gnus/gpgsm.
>>
>> For this particular interop issue, I am curious what is causing the
>> difference.  S/MIME encrypted messages are typically in the
>> enveloped-data format, which means that the encrypted content is simply
>> treated as an attachment.
>>
>> If you have access to an MUA interoperable with Outlook, could you
>> compare the message structures for the success/failure cases?
> 
> I've actually logged the problem here and even attached a script that
> easily tests for the issue and can be modified to produce trivial test
> output for comparison purposes.
> 
> Nobody seemed to really care. So if you do S/MIME with GPG, and use
> Thunderbird, every once in a while you'll get an undecryptable message
> that you have to save to disk and try to deal with in some way with GPG.

Of course, I forgot to add the link:
https://bugzilla.mozilla.org/show_bug.cgi?id=990958




From guilhem at fripost.org  Tue Feb  2 18:39:51 2016
From: guilhem at fripost.org (Guilhem Moulin)
Date: Tue,  2 Feb 2016 18:39:51 +0100
Subject: [PATCH] Fix subkey curve names in --with-colons' output.
Message-ID: <1454434791-31608-1-git-send-email-guilhem@fripost.org>

`gpg --with-colons --list-keys` incorrectly shows the master key's curve
name (or the empty string for non EC master keys) in the 17th field of
"sub" records.

  ~$ gpg2 --list-key 0x0F67969E7F63B344 | grep '^[sp]ub\s'
  pub   rsa2048/7F63B344 2016-02-02 [SC]
  sub   ed25519/6A4AD152 2016-02-02 [S]

  ~$ gpg2 --with-colons --list-key 0x0F67969E7F63B344 | grep '^[sp]ub:'
  pub:u:2048:1:0F67969E7F63B344:1454434424:::u:::scSC:::::::
  sub:u:256:22:443734DA6A4AD152:1454434438::::::s::::::
---
 g10/keylist.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/g10/keylist.c b/g10/keylist.c
index d71bf4f..84ce61d 100644
--- a/g10/keylist.c
+++ b/g10/keylist.c
@@ -1588,11 +1588,11 @@ list_keyblock_colon (KBNODE keyblock, int secret, int has_secret, int fpr)
             }
           es_putc (':', es_stdout);	/* End of field 15. */
           es_putc (':', es_stdout);	/* End of field 16. */
-          if (pk->pubkey_algo == PUBKEY_ALGO_ECDSA
-              || pk->pubkey_algo == PUBKEY_ALGO_EDDSA
-              || pk->pubkey_algo == PUBKEY_ALGO_ECDH)
+          if (pk2->pubkey_algo == PUBKEY_ALGO_ECDSA
+              || pk2->pubkey_algo == PUBKEY_ALGO_EDDSA
+              || pk2->pubkey_algo == PUBKEY_ALGO_ECDH)
             {
-              char *curve = openpgp_oid_to_str (pk->pkey[0]);
+              char *curve = openpgp_oid_to_str (pk2->pkey[0]);
               const char *name = openpgp_oid_to_curve (curve, 0);
               if (!name)
                 name = curve;
-- 
2.7.0



From ueno at gnu.org  Wed Feb  3 10:25:56 2016
From: ueno at gnu.org (Daiki Ueno)
Date: Wed, 03 Feb 2016 18:25:56 +0900
Subject: status of S/MIME and interoperability?
In-Reply-To: <56B0E053.6080309@gmx.com> (Ed Finnerty's message of "Tue, 2 Feb
 2016 18:58:59 +0200")
References: <rmih9hvx4jq.fsf@fnord.ir.bbn.com>
 <87vb68j3et.fsf@vigenere.g10code.de> <m3a8njzcna.fsf-ueno@gnu.org>
 <56B0DFBB.3040607@gmx.com> <56B0E053.6080309@gmx.com>
Message-ID: <m3oaby9mcb.fsf-ueno@gnu.org>

Ed Finnerty <edfinnerty at gmx.com> writes:

>> I've actually logged the problem here and even attached a script that
>> easily tests for the issue and can be modified to produce trivial test
>> output for comparison purposes.
>> 
>> Nobody seemed to really care. So if you do S/MIME with GPG, and use
>> Thunderbird, every once in a while you'll get an undecryptable message
>> that you have to save to disk and try to deal with in some way with GPG.
>
> Of course, I forgot to add the link:
> https://bugzilla.mozilla.org/show_bug.cgi?id=990958

Although I am not sure if this is related to the original issue of this
thread, I have the same impression that this is an NSS bug.

In my test, it happens only when the encrypted session key is shorter
than 256 bytes.  However, I don't see any problem in the CMS data which
gpgsm produced.

Regards,
-- 
Daiki Ueno


From gniibe at fsij.org  Thu Feb  4 04:01:57 2016
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 4 Feb 2016 12:01:57 +0900
Subject: [PATCH] libgpg-error: fix for Solaris
Message-ID: <56B2BF25.1080103@fsij.org>

Hello,

Here is a possible patch for Solaris.  No, I can't test on Solaris.

    Issue 1671:
    https://bugs.gnupg.org/gnupg/issue1671

diff --git a/configure.ac b/configure.ac
index aec3685..a501c9b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -416,6 +416,25 @@ else
   fi
 fi

+# Default value for GPG_ERROR_CONFIG_LIBS
+config_libs="-lgpg-error"
+
+#
+# Check for other libraries (now only for -lrt).
+#
+# Save and restore LIBS so e.g., -lrt, isn't added to it.  Otherwise, *all*
+# programs in the package would end up linked with that potentially-shared
+# library, inducing unnecessary run-time overhead.
+LIB_SCHED_YIELD=
+AC_SUBST([LIB_SCHED_YIELD])
+gl_saved_libs=$LIBS
+AC_SEARCH_LIBS([sched_yield], [rt posix4],
+               [if test "$ac_cv_search_sched_yield" != "none required";
then
+                  LIB_SCHED_YIELD=$ac_cv_search_sched_yield
+                  config_libs="$config_libs $LIB_SCHED_YIELD"
+                fi])
+LIBS=$gl_saved_libs
+
 #
 # Prepare building of estream
 #
@@ -424,7 +443,7 @@ estream_INIT
 #
 # Substitution used for gpg-error-config
 #
-GPG_ERROR_CONFIG_LIBS="-lgpg-error"
+GPG_ERROR_CONFIG_LIBS="$config_libs"
 if test "x$LIBTHREAD" != x; then
   GPG_ERROR_CONFIG_LIBS="${GPG_ERROR_CONFIG_LIBS} ${LIBTHREAD}"
 fi
diff --git a/src/gen-posix-lock-obj.c b/src/gen-posix-lock-obj.c
index 595d379..3453106 100644
--- a/src/gen-posix-lock-obj.c
+++ b/src/gen-posix-lock-obj.c
@@ -49,6 +49,11 @@
 # define USE_16BYTE_ALIGNMENT 0
 #endif

+#if (defined (__ILP32__) || defined(_ILP32)) && defined(__solaris__)
+# define USE_DOUBLE_FOR_ALIGNMENT 1
+#else
+# define USE_DOUBLE_FOR_ALIGNMENT 0
+#endif

 #if USE_16BYTE_ALIGNMENT && !HAVE_GCC_ATTRIBUTE_ALIGNED
 # error compiler is not able to enforce a 16 byte alignment
@@ -118,6 +123,8 @@ main (void)
           SIZEOF_PTHREAD_MUTEX_T,
 # if USE_16BYTE_ALIGNMENT
           "    int _x16_align __attribute__ ((aligned (16)));\n",
+# elif USE_DOUBLE_FOR_ALIGNMENT
+          "    double _xd_align;\n",
 # else
           "",
 # endif
-- 


From dkg at fifthhorseman.net  Thu Feb  4 22:07:38 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu,  4 Feb 2016 16:07:38 -0500
Subject: [PATCH] avoid gpgtar.test when --disable-gpgtar is configured
Message-ID: <1454620058-12840-1-git-send-email-dkg@fifthhorseman.net>

Gbp-Pq: Name 0004-avoid-gpgtar.test-when-disable-gpgtar-is-configured.patch
---
 tests/openpgp/Makefile.am | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/tests/openpgp/Makefile.am b/tests/openpgp/Makefile.am
index a04b62c..92b4097 100644
--- a/tests/openpgp/Makefile.am
+++ b/tests/openpgp/Makefile.am
@@ -31,6 +31,13 @@ else
 sqlite3_dependent_tests =
 endif
 
+if BUILD_GPGTAR
+gpgtar_tests = gpgtar.test
+else
+gpgtar_tests =
+endif
+
+
 # Note: version.test needs to be the first test to run and finish.test
 # the last one
 TESTS = version.test mds.test \
@@ -46,7 +53,7 @@ TESTS = version.test mds.test \
 	multisig.test verify.test armor.test \
 	import.test ecc.test 4gb-packet.test \
 	$(sqlite3_dependent_tests) \
-	gpgtar.test use-exact-key.test default-key.test \
+	$(gpgtar_tests) use-exact-key.test default-key.test \
 	finish.test
 
 
-- 
2.7.0



From ueno at gnu.org  Fri Feb  5 07:41:43 2016
From: ueno at gnu.org (Daiki Ueno)
Date: Fri,  5 Feb 2016 15:41:43 +0900
Subject: [PATCH gpgme 1/3] gpg: Add option --exit-on-status-write-error
Message-ID: <1454654505-8601-1-git-send-email-ueno@gnu.org>

* src/engine-gpg.c (gpg_new): Add --exit-on-status-write-error.

GnuPG-bug-id: 1415
Signed-off-by: Daiki Ueno <ueno at gnu.org>
---
 src/engine-gpg.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/engine-gpg.c b/src/engine-gpg.c
index 9efced2..3226340 100644
--- a/src/engine-gpg.c
+++ b/src/engine-gpg.c
@@ -500,6 +500,8 @@ gpg_new (void **engine, const char *file_name, const char *home_dir)
     rc = add_arg (gpg, "utf8");
   if (!rc)
     rc = add_arg (gpg, "--enable-progress-filter");
+  if (!rc)
+    rc = add_arg (gpg, "--exit-on-status-write-error");
   if (rc)
     goto leave;
 
-- 
2.5.0



From ueno at gnu.org  Fri Feb  5 07:41:44 2016
From: ueno at gnu.org (Daiki Ueno)
Date: Fri,  5 Feb 2016 15:41:44 +0900
Subject: [PATCH gpgme 2/3] doc: Fix minor errors in I/O callback example
In-Reply-To: <1454654505-8601-1-git-send-email-ueno@gnu.org>
References: <1454654505-8601-1-git-send-email-ueno@gnu.org>
Message-ID: <1454654505-8601-2-git-send-email-ueno@gnu.org>

* gpgme.texi (I/O Callback Example): Fix typos and add missing return in
do_select when there is no FD to monitor.

Signed-off-by: Daiki Ueno <ueno at gnu.org>
---
 doc/gpgme.texi | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/doc/gpgme.texi b/doc/gpgme.texi
index db94617..6a2e77e 100644
--- a/doc/gpgme.texi
+++ b/doc/gpgme.texi
@@ -5838,7 +5838,11 @@ do_select (struct event_loop *loop)
   for (i = 0; i < MAX_FDS; i++)
     if (fdlist[i].fd != -1)
       FD_SET (fdlist[i].fd, fdlist[i].dir ? &rfds : &wfds);
-  pthread_mutex_unlock (&loop->unlock);
+  pthread_mutex_unlock (&loop->lock);
+
+  /* No FD to watch.  */
+  if (i == MAX_FDS)
+    return -1;
 
   do
     @{
@@ -5905,7 +5909,7 @@ main (int argc, char *argv[])
     &result
   @};
 
-  init_gpgme (void);
+  init_gpgme ();
 
   /* Initialize the loop structure.  */
   pthread_mutex_init (&loop.lock, NULL);
-- 
2.5.0



From ueno at gnu.org  Fri Feb  5 07:41:45 2016
From: ueno at gnu.org (Daiki Ueno)
Date: Fri,  5 Feb 2016 15:41:45 +0900
Subject: [PATCH gpgme 3/3] tests: Add test for cancellation
In-Reply-To: <1454654505-8601-1-git-send-email-ueno@gnu.org>
References: <1454654505-8601-1-git-send-email-ueno@gnu.org>
Message-ID: <1454654505-8601-3-git-send-email-ueno@gnu.org>

* tests/gpg/t-cancel.c: New file.
* tests/gpg/Makefile.am (tests_skipped): New variable, default to
t-genkey and t-cancel.
(noinst_PROGRAMS): Add $(tests_skipped).

Signed-off-by: Daiki Ueno <ueno at gnu.org>
---
 tests/gpg/Makefile.am |  12 ++-
 tests/gpg/t-cancel.c  | 258 ++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 268 insertions(+), 2 deletions(-)
 create mode 100644 tests/gpg/t-cancel.c

diff --git a/tests/gpg/Makefile.am b/tests/gpg/Makefile.am
index 107397b..4148ea2 100644
--- a/tests/gpg/Makefile.am
+++ b/tests/gpg/Makefile.am
@@ -62,9 +62,17 @@ AM_CPPFLAGS = -I$(top_builddir)/src @GPG_ERROR_CFLAGS@
 AM_LDFLAGS = -no-install
 LDADD = ../../src/libgpgme.la
 t_thread1_LDADD = ../../src/libgpgme-pthread.la -lpthread
+t_cancel_LDADD = ../../src/libgpgme-pthread.la -lpthread
+
+# We don't run t-genkey and t-cancel in the test suite, because it
+# takes too long
+tests_skipped = t-genkey
+if !HAVE_W32_SYSTEM
+tests_skipped += t-cancel
+endif
+
+noinst_PROGRAMS = $(c_tests) $(tests_skipped)
 
-# We don't run t-genkey in the test suite, because it takes too long
-noinst_PROGRAMS = $(c_tests) t-genkey
 
 clean-local:
 	-$(top_srcdir)/tests/start-stop-agent --stop
diff --git a/tests/gpg/t-cancel.c b/tests/gpg/t-cancel.c
new file mode 100644
index 0000000..cc8362a
--- /dev/null
+++ b/tests/gpg/t-cancel.c
@@ -0,0 +1,258 @@
+/* t-thread-cancel.c - Regression test.
+   Copyright (C) 2000 Werner Koch (dd9jn)
+   Copyright (C) 2001, 2003, 2004 g10 Code GmbH
+
+   This file is part of GPGME.
+
+   GPGME is free software; you can redistribute it and/or modify it
+   under the terms of the GNU Lesser General Public License as
+   published by the Free Software Foundation; either version 2.1 of
+   the License, or (at your option) any later version.
+
+   GPGME is distributed in the hope that it will be useful, but
+   WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with this program; if not, write to the Free Software
+   Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
+   02111-1307, USA.  */
+
+/* We need to include config.h so that we know whether we are building
+   with large file system (LFS) support. */
+#ifdef HAVE_CONFIG_H
+#include <config.h>
+#endif
+
+#include <stdlib.h>
+#include <stdio.h>
+#include <string.h>
+#include <assert.h>
+#include <limits.h>
+#include <ctype.h>
+#include <errno.h>
+#include <unistd.h>
+#include <pthread.h>
+
+#include <gpgme.h>
+
+#include "t-support.h"
+
+struct op_result
+{
+  int done;
+  gpgme_error_t err;
+};
+
+static struct op_result op_result;
+
+struct one_fd
+{
+  int fd;
+  int dir;
+  gpgme_io_cb_t fnc;
+  void *fnc_data;
+};
+
+#define FDLIST_MAX 32
+static struct one_fd fdlist[FDLIST_MAX];
+
+static pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
+
+static gpgme_error_t
+add_io_cb (void *data, int fd, int dir, gpgme_io_cb_t fnc, void *fnc_data,
+           void **r_tag)
+{
+  struct one_fd *fds = data;
+  int i;
+
+  pthread_mutex_lock (&lock);
+  for (i = 0; i < FDLIST_MAX; i++)
+    {
+      if (fds[i].fd == -1)
+        {
+          fds[i].fd = fd;
+          fds[i].dir = dir;
+          fds[i].fnc = fnc;
+          fds[i].fnc_data = fnc_data;
+          break;
+        }
+    }
+  pthread_mutex_unlock (&lock);
+  if (i == FDLIST_MAX)
+    return gpgme_err_make (GPG_ERR_SOURCE_USER_1, GPG_ERR_GENERAL);
+  *r_tag = &fds[i];
+  return 0;
+}
+
+static void
+remove_io_cb (void *tag)
+{
+  struct one_fd *fd = tag;
+
+  pthread_mutex_lock (&lock);
+  fd->fd = -1;
+  pthread_mutex_unlock (&lock);
+}
+
+static void
+io_event (void *data, gpgme_event_io_t type, void *type_data)
+{
+  struct op_result *result = data;
+
+  if (type == GPGME_EVENT_DONE)
+    {
+      result->done = 1;
+      result->err = * (gpgme_error_t *) type_data;
+  }
+}
+
+
+static int
+do_select (void)
+{
+  fd_set rfds;
+  fd_set wfds;
+  int i, n;
+  int any = 0;
+
+  pthread_mutex_lock (&lock);
+  FD_ZERO (&rfds);
+  FD_ZERO (&wfds);
+  for (i = 0; i < FDLIST_MAX; i++)
+    if (fdlist[i].fd != -1)
+      FD_SET (fdlist[i].fd, fdlist[i].dir ? &rfds : &wfds);
+  pthread_mutex_unlock (&lock);
+
+  /* No FD to watch.  */
+  if (i == FDLIST_MAX)
+    return -1;
+
+  do
+    {
+      n = select (FD_SETSIZE, &rfds, &wfds, NULL, NULL);
+    }
+  while (n < 0 && errno == EINTR);
+
+  if (n < 0)
+    return n;   /* Error or timeout.  */
+
+  pthread_mutex_lock (&lock);
+  for (i = 0; i < FDLIST_MAX && n; i++)
+    {
+      if (fdlist[i].fd != -1)
+        {
+          if (FD_ISSET (fdlist[i].fd, fdlist[i].dir ? &rfds : &wfds))
+            {
+              assert (n);
+              n--;
+              any = 1;
+              (*fdlist[i].fnc) (fdlist[i].fnc_data, fdlist[i].fd);
+            }
+        }
+    }
+  pthread_mutex_unlock (&lock);
+  return any;
+}
+
+static int
+my_wait (void)
+{
+  int n;
+
+  do
+    {
+      n = do_select ();
+    }
+  while (n >= 0 && !op_result.done);
+  return 0;
+}
+
+
+static struct gpgme_io_cbs io_cbs =
+  {
+    add_io_cb,
+    fdlist,
+    remove_io_cb,
+    io_event,
+    &op_result
+  };
+
+
+static void *
+thread_cancel (void *data)
+{
+  gpgme_ctx_t ctx = data;
+  gpgme_error_t err;
+
+  usleep (100000);
+  err = gpgme_cancel (ctx);
+  fail_if_err (err);
+
+  return NULL;
+}
+
+int
+main (int argc, char *argv[])
+{
+  gpgme_ctx_t ctx;
+  gpgme_error_t err;
+  gpgme_engine_info_t info;
+  int i;
+  pthread_t tcancel;
+  const char *parms = "<GnupgKeyParms format=\"internal\">\n"
+    "Key-Type: RSA\n"
+    "Key-Length: 2048\n"
+    "Subkey-Type: RSA\n"
+    "Subkey-Length: 2048\n"
+    "Name-Real: Joe Tester\n"
+    "Name-Comment: (pp=abc)\n"
+    "Name-Email: joe at foo.bar\n"
+    "Expire-Date: 0\n"
+    "Passphrase: abc\n"
+    "</GnupgKeyParms>\n";
+
+  init_gpgme (GPGME_PROTOCOL_OpenPGP);
+
+  err = gpgme_get_engine_info (&info);
+  fail_if_err (err);
+
+  for (i = 0; i < FDLIST_MAX; i++)
+    fdlist[i].fd = -1;
+
+  err = gpgme_new (&ctx);
+  fail_if_err (err);
+  gpgme_set_armor (ctx, 1);
+  gpgme_set_io_cbs (ctx, &io_cbs);
+  op_result.done = 0;
+
+  pthread_create (&tcancel, NULL, thread_cancel, ctx);
+
+  err = gpgme_op_genkey_start (ctx, parms, NULL, NULL);
+  fail_if_err (err);
+
+  my_wait ();
+
+  pthread_join (tcancel, NULL);
+
+  if (op_result.err)
+    {
+      if (gpgme_err_code (op_result.err) == GPG_ERR_CANCELED)
+	{
+	  fflush (NULL);
+	  fputs ("Successfully cancelled\n", stdout);
+	}
+      else
+	{
+	  fprintf (stderr,
+		   "%s:%i: Operation finished with unexpected error: %s\n",
+		   __FILE__, __LINE__, gpgme_strerror (op_result.err));
+	  exit (1);
+	}
+    }
+
+  gpgme_release (ctx);
+
+  return 0;
+}
-- 
2.5.0



From ueno at gnu.org  Fri Feb  5 09:17:29 2016
From: ueno at gnu.org (Daiki Ueno)
Date: Fri,  5 Feb 2016 17:17:29 +0900
Subject: [PATCH gpgme v2 1/3] gpg: Add option --exit-on-status-write-error
Message-ID: <1454660251-18619-1-git-send-email-ueno@gnu.org>

* src/engine-gpg.c (gpg_new): Add --exit-on-status-write-error.

GnuPG-bug-id: 1415
Signed-off-by: Daiki Ueno <ueno at gnu.org>
---
 src/engine-gpg.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/engine-gpg.c b/src/engine-gpg.c
index 9efced2..3226340 100644
--- a/src/engine-gpg.c
+++ b/src/engine-gpg.c
@@ -500,6 +500,8 @@ gpg_new (void **engine, const char *file_name, const char *home_dir)
     rc = add_arg (gpg, "utf8");
   if (!rc)
     rc = add_arg (gpg, "--enable-progress-filter");
+  if (!rc)
+    rc = add_arg (gpg, "--exit-on-status-write-error");
   if (rc)
     goto leave;
 
-- 
2.5.0



From ueno at gnu.org  Fri Feb  5 09:17:31 2016
From: ueno at gnu.org (Daiki Ueno)
Date: Fri,  5 Feb 2016 17:17:31 +0900
Subject: [PATCH gpgme v2 3/3] tests: Add test for cancellation
In-Reply-To: <1454660251-18619-1-git-send-email-ueno@gnu.org>
References: <1454660251-18619-1-git-send-email-ueno@gnu.org>
Message-ID: <1454660251-18619-3-git-send-email-ueno@gnu.org>

* tests/gpg/t-cancel.c: New file.
* tests/gpg/Makefile.am (tests_skipped): New variable, default to
t-genkey and t-cancel.
(noinst_PROGRAMS): Add $(tests_skipped).

Signed-off-by: Daiki Ueno <ueno at gnu.org>
---
 tests/gpg/Makefile.am |  12 ++-
 tests/gpg/t-cancel.c  | 263 ++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 273 insertions(+), 2 deletions(-)
 create mode 100644 tests/gpg/t-cancel.c

diff --git a/tests/gpg/Makefile.am b/tests/gpg/Makefile.am
index 107397b..4148ea2 100644
--- a/tests/gpg/Makefile.am
+++ b/tests/gpg/Makefile.am
@@ -62,9 +62,17 @@ AM_CPPFLAGS = -I$(top_builddir)/src @GPG_ERROR_CFLAGS@
 AM_LDFLAGS = -no-install
 LDADD = ../../src/libgpgme.la
 t_thread1_LDADD = ../../src/libgpgme-pthread.la -lpthread
+t_cancel_LDADD = ../../src/libgpgme-pthread.la -lpthread
+
+# We don't run t-genkey and t-cancel in the test suite, because it
+# takes too long
+tests_skipped = t-genkey
+if !HAVE_W32_SYSTEM
+tests_skipped += t-cancel
+endif
+
+noinst_PROGRAMS = $(c_tests) $(tests_skipped)
 
-# We don't run t-genkey in the test suite, because it takes too long
-noinst_PROGRAMS = $(c_tests) t-genkey
 
 clean-local:
 	-$(top_srcdir)/tests/start-stop-agent --stop
diff --git a/tests/gpg/t-cancel.c b/tests/gpg/t-cancel.c
new file mode 100644
index 0000000..57f304b
--- /dev/null
+++ b/tests/gpg/t-cancel.c
@@ -0,0 +1,263 @@
+/* t-thread-cancel.c - Regression test.
+   Copyright (C) 2000 Werner Koch (dd9jn)
+   Copyright (C) 2001, 2003, 2004 g10 Code GmbH
+
+   This file is part of GPGME.
+
+   GPGME is free software; you can redistribute it and/or modify it
+   under the terms of the GNU Lesser General Public License as
+   published by the Free Software Foundation; either version 2.1 of
+   the License, or (at your option) any later version.
+
+   GPGME is distributed in the hope that it will be useful, but
+   WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with this program; if not, write to the Free Software
+   Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
+   02111-1307, USA.  */
+
+/* We need to include config.h so that we know whether we are building
+   with large file system (LFS) support. */
+#ifdef HAVE_CONFIG_H
+#include <config.h>
+#endif
+
+#include <stdlib.h>
+#include <stdio.h>
+#include <string.h>
+#include <assert.h>
+#include <limits.h>
+#include <ctype.h>
+#include <errno.h>
+#include <unistd.h>
+#include <pthread.h>
+
+#include <gpgme.h>
+
+#include "t-support.h"
+
+struct op_result
+{
+  int done;
+  gpgme_error_t err;
+};
+
+static struct op_result op_result;
+
+struct one_fd
+{
+  int fd;
+  int dir;
+  gpgme_io_cb_t fnc;
+  void *fnc_data;
+};
+
+#define FDLIST_MAX 32
+static struct one_fd fdlist[FDLIST_MAX];
+
+static pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
+
+static gpgme_error_t
+add_io_cb (void *data, int fd, int dir, gpgme_io_cb_t fnc, void *fnc_data,
+           void **r_tag)
+{
+  struct one_fd *fds = data;
+  int i;
+
+  pthread_mutex_lock (&lock);
+  for (i = 0; i < FDLIST_MAX; i++)
+    {
+      if (fds[i].fd == -1)
+        {
+          fds[i].fd = fd;
+          fds[i].dir = dir;
+          fds[i].fnc = fnc;
+          fds[i].fnc_data = fnc_data;
+          break;
+        }
+    }
+  pthread_mutex_unlock (&lock);
+  if (i == FDLIST_MAX)
+    return gpgme_err_make (GPG_ERR_SOURCE_USER_1, GPG_ERR_GENERAL);
+  *r_tag = &fds[i];
+  return 0;
+}
+
+static void
+remove_io_cb (void *tag)
+{
+  struct one_fd *fd = tag;
+
+  pthread_mutex_lock (&lock);
+  fd->fd = -1;
+  pthread_mutex_unlock (&lock);
+}
+
+static void
+io_event (void *data, gpgme_event_io_t type, void *type_data)
+{
+  struct op_result *result = data;
+
+  if (type == GPGME_EVENT_DONE)
+    {
+      result->done = 1;
+      result->err = * (gpgme_error_t *) type_data;
+    }
+}
+
+
+static int
+do_select (void)
+{
+  fd_set rfds;
+  fd_set wfds;
+  int i, n;
+  int any = 0;
+  int nfds = 0;
+  struct timeval tv;
+
+  pthread_mutex_lock (&lock);
+  FD_ZERO (&rfds);
+  FD_ZERO (&wfds);
+  for (i = 0; i < FDLIST_MAX; i++)
+    if (fdlist[i].fd != -1)
+      {
+	FD_SET (fdlist[i].fd, fdlist[i].dir ? &rfds : &wfds);
+	if (nfds < fdlist[i].fd)
+	  nfds = fdlist[i].fd;
+      }
+  pthread_mutex_unlock (&lock);
+
+  tv.tv_sec = 0;
+  tv.tv_usec = 1000;
+
+  do
+    {
+      n = select (nfds, &rfds, &wfds, NULL, &tv);
+    }
+  while (n < 0 && errno == EINTR);
+
+  if (n < 0)
+    return n;   /* Error or timeout.  */
+
+  pthread_mutex_lock (&lock);
+  for (i = 0; i < FDLIST_MAX && n; i++)
+    {
+      if (fdlist[i].fd != -1)
+        {
+          if (FD_ISSET (fdlist[i].fd, fdlist[i].dir ? &rfds : &wfds))
+            {
+              assert (n);
+              n--;
+              any = 1;
+              (*fdlist[i].fnc) (fdlist[i].fnc_data, fdlist[i].fd);
+            }
+        }
+    }
+  pthread_mutex_unlock (&lock);
+  return any;
+}
+
+static int
+my_wait (void)
+{
+  int n;
+
+  do
+    {
+      n = do_select ();
+    }
+  while (n >= 0 && !op_result.done);
+  return 0;
+}
+
+
+static struct gpgme_io_cbs io_cbs =
+  {
+    add_io_cb,
+    fdlist,
+    remove_io_cb,
+    io_event,
+    &op_result
+  };
+
+
+static void *
+thread_cancel (void *data)
+{
+  gpgme_ctx_t ctx = data;
+  gpgme_error_t err;
+
+  usleep (100000);
+  err = gpgme_cancel (ctx);
+  fail_if_err (err);
+
+  return NULL;
+}
+
+int
+main (int argc, char *argv[])
+{
+  gpgme_ctx_t ctx;
+  gpgme_error_t err;
+  gpgme_engine_info_t info;
+  int i;
+  pthread_t tcancel;
+  const char *parms = "<GnupgKeyParms format=\"internal\">\n"
+    "Key-Type: RSA\n"
+    "Key-Length: 2048\n"
+    "Subkey-Type: RSA\n"
+    "Subkey-Length: 2048\n"
+    "Name-Real: Joe Tester\n"
+    "Name-Comment: (pp=abc)\n"
+    "Name-Email: joe at foo.bar\n"
+    "Expire-Date: 0\n"
+    "Passphrase: abc\n"
+    "</GnupgKeyParms>\n";
+
+  init_gpgme (GPGME_PROTOCOL_OpenPGP);
+
+  err = gpgme_get_engine_info (&info);
+  fail_if_err (err);
+
+  for (i = 0; i < FDLIST_MAX; i++)
+    fdlist[i].fd = -1;
+
+  err = gpgme_new (&ctx);
+  fail_if_err (err);
+  gpgme_set_armor (ctx, 1);
+  gpgme_set_io_cbs (ctx, &io_cbs);
+  op_result.done = 0;
+
+  pthread_create (&tcancel, NULL, thread_cancel, ctx);
+
+  err = gpgme_op_genkey_start (ctx, parms, NULL, NULL);
+  fail_if_err (err);
+
+  my_wait ();
+
+  pthread_join (tcancel, NULL);
+
+  if (op_result.err)
+    {
+      if (gpgme_err_code (op_result.err) == GPG_ERR_CANCELED)
+	{
+	  fflush (NULL);
+	  fputs ("Successfully cancelled\n", stdout);
+	}
+      else
+	{
+	  fprintf (stderr,
+		   "%s:%i: Operation finished with unexpected error: %s\n",
+		   __FILE__, __LINE__, gpgme_strerror (op_result.err));
+	  exit (1);
+	}
+    }
+
+  gpgme_release (ctx);
+
+  return 0;
+}
-- 
2.5.0



From ueno at gnu.org  Fri Feb  5 09:17:30 2016
From: ueno at gnu.org (Daiki Ueno)
Date: Fri,  5 Feb 2016 17:17:30 +0900
Subject: [PATCH gpgme v2 2/3] doc: Fix minor errors in I/O callback example
In-Reply-To: <1454660251-18619-1-git-send-email-ueno@gnu.org>
References: <1454660251-18619-1-git-send-email-ueno@gnu.org>
Message-ID: <1454660251-18619-2-git-send-email-ueno@gnu.org>

* gpgme.texi (I/O Callback Example): Fix typos and the select usage.

Signed-off-by: Daiki Ueno <ueno at gnu.org>
---
 doc/gpgme.texi | 17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/doc/gpgme.texi b/doc/gpgme.texi
index db94617..28aa5e7 100644
--- a/doc/gpgme.texi
+++ b/doc/gpgme.texi
@@ -5830,6 +5830,8 @@ do_select (struct event_loop *loop)
   fd_set wfds;
   int i, n;
   int any = 0;
+  int nfds = 0;
+  struct timeval tv;
   struct one_fd *fdlist = loop->fds;
 
   pthread_mutex_lock (&loop->lock);
@@ -5837,12 +5839,19 @@ do_select (struct event_loop *loop)
   FD_ZERO (&wfds);
   for (i = 0; i < MAX_FDS; i++)
     if (fdlist[i].fd != -1)
-      FD_SET (fdlist[i].fd, fdlist[i].dir ? &rfds : &wfds);
-  pthread_mutex_unlock (&loop->unlock);
+      @{
+        FD_SET (fdlist[i].fd, fdlist[i].dir ? &rfds : &wfds);
+	if (nfds < fdlist[i].fd)
+	  nfds = fdlist[i].fd;
+      @}
+  pthread_mutex_unlock (&loop->lock);
+
+  tv.tv_sec = 0;
+  tv.tv_usec = 1000;
 
   do
     @{
-      n = select (FD_SETSIZE, &rfds, &wfds, NULL, 0);
+      n = select (nfds, &rfds, &wfds, NULL, &tv);
     @}
   while (n < 0 && errno == EINTR);
 
@@ -5905,7 +5914,7 @@ main (int argc, char *argv[])
     &result
   @};
 
-  init_gpgme (void);
+  init_gpgme ();
 
   /* Initialize the loop structure.  */
   pthread_mutex_init (&loop.lock, NULL);
-- 
2.5.0



From ueno at gnu.org  Fri Feb  5 09:21:49 2016
From: ueno at gnu.org (Daiki Ueno)
Date: Fri, 05 Feb 2016 17:21:49 +0900
Subject: [PATCH gpgme 2/3] doc: Fix minor errors in I/O callback example
In-Reply-To: <1454654505-8601-2-git-send-email-ueno@gnu.org> (Daiki Ueno's
 message of "Fri, 5 Feb 2016 15:41:44 +0900")
References: <1454654505-8601-1-git-send-email-ueno@gnu.org>
 <1454654505-8601-2-git-send-email-ueno@gnu.org>
Message-ID: <m3oabvlg82.fsf-ueno@gnu.org>

Daiki Ueno <ueno at gnu.org> writes:

> * gpgme.texi (I/O Callback Example): Fix typos and add missing return in
> do_select when there is no FD to monitor.

Sorry, please disregard this series and consider using v2.  There was a
misuse of select in both documentation and the test.  It seems
t-eventloop.c has the same problem; will try to fix it too.

Regards,
-- 
Daiki Ueno


From ueno at gnu.org  Fri Feb  5 09:45:05 2016
From: ueno at gnu.org (Daiki Ueno)
Date: Fri,  5 Feb 2016 17:45:05 +0900
Subject: [PATCH gpgme] tests: Fix select usage in t-eventloop
Message-ID: <1454661905-29031-1-git-send-email-ueno@gnu.org>

* tests/gpg/t-eventloop.c (do_select): Use the highest fd number plus 1,
as the first argument of select, and supply timeout value as struct
timeval.

Signed-off-by: Daiki Ueno <ueno at gnu.org>
---
 tests/gpg/t-eventloop.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/tests/gpg/t-eventloop.c b/tests/gpg/t-eventloop.c
index cb1e57c..a6918a8 100644
--- a/tests/gpg/t-eventloop.c
+++ b/tests/gpg/t-eventloop.c
@@ -111,16 +111,25 @@ do_select (void)
   fd_set wfds;
   int i, n;
   int any = 0;
+  int nfds = 0;
+  struct timeval tv;
 
   FD_ZERO (&rfds);
   FD_ZERO (&wfds);
   for (i = 0; i < FDLIST_MAX; i++)
     if (fdlist[i].fd != -1)
-      FD_SET (fdlist[i].fd, fdlist[i].dir ? &rfds : &wfds);
+      {
+	FD_SET (fdlist[i].fd, fdlist[i].dir ? &rfds : &wfds);
+	if (nfds < fdlist[i].fd)
+	  nfds = fdlist[i].fd;
+      }
+
+  tv.tv_sec = 0;
+  tv.tv_usec = 1000;
 
   do
     {
-      n = select (FD_SETSIZE, &rfds, &wfds, NULL, 0);
+      n = select (nfds + 1, &rfds, &wfds, NULL, &tv);
     }
   while (n < 0 && errno == EINTR);
 
-- 
2.5.0



From justus at g10code.com  Fri Feb  5 11:42:44 2016
From: justus at g10code.com (Justus Winter)
Date: Fri, 05 Feb 2016 11:42:44 +0100
Subject: [PATCH] avoid gpgtar.test when --disable-gpgtar is configured
In-Reply-To: <1454620058-12840-1-git-send-email-dkg@fifthhorseman.net>
References: <1454620058-12840-1-git-send-email-dkg@fifthhorseman.net>
Message-ID: <20160205104244.30536.13541@thinkbox.jade-hamburg.de>

Hi,

Quoting Daniel Kahn Gillmor (2016-02-04 22:07:38)
>         $(sqlite3_dependent_tests) \
> -       gpgtar.test use-exact-key.test default-key.test \
> +       $(gpgtar_tests) use-exact-key.test default-key.test \

I don't like it.  I know that we do the same for the tofu test.  There
is a better way to skip a test, just return 77.

Thanks,
Justus


From dkg at fifthhorseman.net  Fri Feb  5 20:16:24 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri,  5 Feb 2016 14:16:24 -0500
Subject: [LIBGPG-ERROR PATCH 03/12] use https to refer to creativecommons.org
In-Reply-To: <1454699793-25137-1-git-send-email-dkg@fifthhorseman.net>
References: <1454699793-25137-1-git-send-email-dkg@fifthhorseman.net>
Message-ID: <1454699793-25137-4-git-send-email-dkg@fifthhorseman.net>

---
 doc/ldap2gpgerr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/ldap2gpgerr.c b/doc/ldap2gpgerr.c
index 515bf40..f6fd3cf 100644
--- a/doc/ldap2gpgerr.c
+++ b/doc/ldap2gpgerr.c
@@ -8,7 +8,7 @@
  *
  * You should have received a copy of the CC0 Public Domain Dedication
  * along with this software.  If not, see
- *                 <http://creativecommons.org/publicdomain/zero/1.0/>.
+ *                 <https://creativecommons.org/publicdomain/zero/1.0/>.
  */
 
 /*
-- 
2.7.0



From dkg at fifthhorseman.net  Fri Feb  5 20:16:25 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri,  5 Feb 2016 14:16:25 -0500
Subject: [LIBGPG-ERROR PATCH 04/12] use https to refer to
 translationproject.org
In-Reply-To: <1454699793-25137-1-git-send-email-dkg@fifthhorseman.net>
References: <1454699793-25137-1-git-send-email-dkg@fifthhorseman.net>
Message-ID: <1454699793-25137-5-git-send-email-dkg@fifthhorseman.net>

---
 ABOUT-NLS | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ABOUT-NLS b/ABOUT-NLS
index b1de1b6..3b879cb 100644
--- a/ABOUT-NLS
+++ b/ABOUT-NLS
@@ -111,7 +111,7 @@ people who like their own language and write it well, and who are also
 able to synergize with other translators speaking the same language.
 Each translation team has its own mailing list.  The up-to-date list of
 teams can be found at the Free Translation Project's homepage,
-`http://translationproject.org/', in the "Teams" area.
+`https://translationproject.org/', in the "Teams" area.
 
    If you'd like to volunteer to _work_ at translating messages, you
 should become a member of the translating team for your own language.
@@ -1259,7 +1259,7 @@ distribution.
    If June 2010 seems to be old, you may fetch a more recent copy of
 this `ABOUT-NLS' file on most GNU archive sites.  The most up-to-date
 matrix with full percentage details can be found at
-`http://translationproject.org/extra/matrix.html'.
+`https://translationproject.org/extra/matrix.html'.
 
 1.5 Using `gettext' in new packages
 ===================================
-- 
2.7.0



From dkg at fifthhorseman.net  Fri Feb  5 20:16:26 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri,  5 Feb 2016 14:16:26 -0500
Subject: [LIBGPG-ERROR PATCH 05/12] use https to refer to mail.gnome.org
In-Reply-To: <1454699793-25137-1-git-send-email-dkg@fifthhorseman.net>
References: <1454699793-25137-1-git-send-email-dkg@fifthhorseman.net>
Message-ID: <1454699793-25137-6-git-send-email-dkg@fifthhorseman.net>

---
 autogen.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/autogen.sh b/autogen.sh
index 24da40c..91f35a6 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -347,7 +347,7 @@ if [ -d .git ]; then
     [ -z "${SILENT}" ] && cat <<EOF
 *** Activating trailing whitespace git pre-commit hook. ***
     For more information see this thread:
-      http://mail.gnome.org/archives/desktop-devel-list/2009-May/msg00084.html
+      https://mail.gnome.org/archives/desktop-devel-list/2009-May/msg00084.html
     To deactivate this pre-commit hook again move .git/hooks/pre-commit
     and .git/hooks/pre-commit.sample out of the way.
 EOF
-- 
2.7.0



From dkg at fifthhorseman.net  Fri Feb  5 20:16:21 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri,  5 Feb 2016 14:16:21 -0500
Subject: libgpg-error: refer to network resource using https where possible
Message-ID: <1454699793-25137-1-git-send-email-dkg@fifthhorseman.net>

This is a simple series of patches that cleans up references in the
source to network resources, using https:// where possible instead of
http://.  the final patch actually cleans up an old FIXME comment
instead of re-pointing the results to https.  I can provde these all
in single a squashed commit if you prefer it.



From dkg at fifthhorseman.net  Fri Feb  5 20:16:23 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri,  5 Feb 2016 14:16:23 -0500
Subject: [LIBGPG-ERROR PATCH 02/12] refer to https://www.gnu.org instead of
 http://www.gnu.org
In-Reply-To: <1454699793-25137-1-git-send-email-dkg@fifthhorseman.net>
References: <1454699793-25137-1-git-send-email-dkg@fifthhorseman.net>
Message-ID: <1454699793-25137-3-git-send-email-dkg@fifthhorseman.net>

---
 Makefile.am                | 2 +-
 build-aux/compile          | 2 +-
 build-aux/config.guess     | 2 +-
 build-aux/config.sub       | 2 +-
 build-aux/depcomp          | 2 +-
 build-aux/ltmain.sh        | 6 +++---
 build-aux/mdate-sh         | 2 +-
 build-aux/missing          | 4 ++--
 build-aux/texinfo.tex      | 6 +++---
 configure.ac               | 2 +-
 doc/Makefile.am            | 2 +-
 doc/yat2m.c                | 2 +-
 m4/ac_prog_cc_for_build.m4 | 2 +-
 m4/libtool.m4              | 2 +-
 src/Makefile.am            | 2 +-
 src/estream-printf.c       | 2 +-
 src/estream-printf.h       | 2 +-
 src/estream.c              | 2 +-
 src/estream.h              | 2 +-
 src/gen-posix-lock-obj.c   | 2 +-
 src/gen-w32-lock-obj.c     | 2 +-
 src/gpg-error.def.in       | 2 +-
 src/gpg-error.h.in         | 2 +-
 src/gpg-error.vers         | 2 +-
 src/gpgrt-int.h            | 2 +-
 src/init.c                 | 2 +-
 src/init.h                 | 2 +-
 src/lock.h                 | 2 +-
 src/mkw32errmap.c          | 2 +-
 src/posix-lock-obj.h       | 2 +-
 src/posix-lock.c           | 2 +-
 src/posix-thread.c         | 2 +-
 src/thread.h               | 2 +-
 src/version.c              | 2 +-
 src/visibility.c           | 2 +-
 src/visibility.h           | 2 +-
 src/w32-gettext.c          | 2 +-
 src/w32-lock-obj.h         | 2 +-
 src/w32-lock.c             | 2 +-
 src/w32-thread.c           | 2 +-
 tests/t-common.h           | 2 +-
 tests/t-lock.c             | 2 +-
 tests/t-poll.c             | 2 +-
 tests/t-printf.c           | 2 +-
 tests/t-version.c          | 2 +-
 45 files changed, 50 insertions(+), 50 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index e5f3f56..4f9f094 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -14,7 +14,7 @@
 # GNU Lesser General Public License for more details.
 #
 # You should have received a copy of the GNU Lesser General Public
-# License along with this program; if not, see <http://www.gnu.org/licenses/>.
+# License along with this program; if not, see <https://www.gnu.org/licenses/>.
 
 ACLOCAL_AMFLAGS = -I m4
 DISTCHECK_CONFIGURE_FLAGS = --enable-doc
diff --git a/build-aux/compile b/build-aux/compile
index 531136b..52f8f94 100755
--- a/build-aux/compile
+++ b/build-aux/compile
@@ -17,7 +17,7 @@ scriptversion=2012-10-14.11; # UTC
 # GNU General Public License for more details.
 #
 # You should have received a copy of the GNU General Public License
-# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+# along with this program.  If not, see <https://www.gnu.org/licenses/>.
 
 # As a special exception to the GNU General Public License, if you
 # distribute this file as part of a program that contains a
diff --git a/build-aux/config.guess b/build-aux/config.guess
index dbfb978..7adf147 100755
--- a/build-aux/config.guess
+++ b/build-aux/config.guess
@@ -15,7 +15,7 @@ timestamp='2015-01-01'
 # General Public License for more details.
 #
 # You should have received a copy of the GNU General Public License
-# along with this program; if not, see <http://www.gnu.org/licenses/>.
+# along with this program; if not, see <https://www.gnu.org/licenses/>.
 #
 # As a special exception to the GNU General Public License, if you
 # distribute this file as part of a program that contains a
diff --git a/build-aux/config.sub b/build-aux/config.sub
index 6d2e94c..0b2d816 100755
--- a/build-aux/config.sub
+++ b/build-aux/config.sub
@@ -15,7 +15,7 @@ timestamp='2015-01-01'
 # General Public License for more details.
 #
 # You should have received a copy of the GNU General Public License
-# along with this program; if not, see <http://www.gnu.org/licenses/>.
+# along with this program; if not, see <https://www.gnu.org/licenses/>.
 #
 # As a special exception to the GNU General Public License, if you
 # distribute this file as part of a program that contains a
diff --git a/build-aux/depcomp b/build-aux/depcomp
index 4ebd5b3..f0a474c 100755
--- a/build-aux/depcomp
+++ b/build-aux/depcomp
@@ -16,7 +16,7 @@ scriptversion=2013-05-30.07; # UTC
 # GNU General Public License for more details.
 
 # You should have received a copy of the GNU General Public License
-# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+# along with this program.  If not, see <https://www.gnu.org/licenses/>.
 
 # As a special exception to the GNU General Public License, if you
 # distribute this file as part of a program that contains a
diff --git a/build-aux/ltmain.sh b/build-aux/ltmain.sh
index f8c3614..c3bcdc0 100644
--- a/build-aux/ltmain.sh
+++ b/build-aux/ltmain.sh
@@ -24,7 +24,7 @@
 #
 # You should have received a copy of the GNU General Public License
 # along with GNU Libtool; see the file COPYING.  If not, a copy
-# can be downloaded from http://www.gnu.org/licenses/gpl.html,
+# can be downloaded from https://www.gnu.org/licenses/gpl.html,
 # or obtained by writing to the Free Software Foundation, Inc.,
 # 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 
@@ -75,8 +75,8 @@
 #         autoconf:	$autoconf_version
 #
 # Report bugs to <bug-libtool at gnu.org>.
-# GNU libtool home page: <http://www.gnu.org/software/libtool/>.
-# General help using GNU software: <http://www.gnu.org/gethelp/>.
+# GNU libtool home page: <https://www.gnu.org/software/libtool/>.
+# General help using GNU software: <https://www.gnu.org/gethelp/>.
 
 PROGRAM=libtool
 PACKAGE=libtool
diff --git a/build-aux/mdate-sh b/build-aux/mdate-sh
index b3719cf..39f48bb 100755
--- a/build-aux/mdate-sh
+++ b/build-aux/mdate-sh
@@ -17,7 +17,7 @@ scriptversion=2010-08-21.06; # UTC
 # GNU General Public License for more details.
 #
 # You should have received a copy of the GNU General Public License
-# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+# along with this program.  If not, see <https://www.gnu.org/licenses/>.
 
 # As a special exception to the GNU General Public License, if you
 # distribute this file as part of a program that contains a
diff --git a/build-aux/missing b/build-aux/missing
index db98974..43e37bd 100755
--- a/build-aux/missing
+++ b/build-aux/missing
@@ -17,7 +17,7 @@ scriptversion=2013-10-28.13; # UTC
 # GNU General Public License for more details.
 
 # You should have received a copy of the GNU General Public License
-# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+# along with this program.  If not, see <https://www.gnu.org/licenses/>.
 
 # As a special exception to the GNU General Public License, if you
 # distribute this file as part of a program that contains a
@@ -103,7 +103,7 @@ fi
 
 perl_URL=http://www.perl.org/
 flex_URL=http://flex.sourceforge.net/
-gnu_software_URL=http://www.gnu.org/software
+gnu_software_URL=https://www.gnu.org/software
 
 program_details ()
 {
diff --git a/build-aux/texinfo.tex b/build-aux/texinfo.tex
index a181898..6f48781 100644
--- a/build-aux/texinfo.tex
+++ b/build-aux/texinfo.tex
@@ -21,7 +21,7 @@
 %
 % You should have received a copy of the GNU General Public License
 % along with this texinfo.tex file; see the file COPYING.  If not,
-% see <http://www.gnu.org/licenses/>.
+% see <https://www.gnu.org/licenses/>.
 %
 % As a special exception, when this file is read by TeX when processing
 % a Texinfo source document, you may use the result without
@@ -29,7 +29,7 @@
 %
 % Please try the latest version of texinfo.tex before submitting bug
 % reports; you can get the latest version from:
-%   http://www.gnu.org/software/texinfo/ (the Texinfo home page), or
+%   https://www.gnu.org/software/texinfo/ (the Texinfo home page), or
 %   ftp://tug.org/tex/texinfo.tex
 %     (and all CTAN mirrors, see http://www.ctan.org).
 % The texinfo.tex in any given distribution could well be out
@@ -55,7 +55,7 @@
 % extent.  You can get the existing language-specific files from the
 % full Texinfo distribution.
 %
-% The GNU Texinfo home page is http://www.gnu.org/software/texinfo.
+% The GNU Texinfo home page is https://www.gnu.org/software/texinfo.
 
 
 \message{Loading texinfo [version \texinfoversion]:}
diff --git a/configure.ac b/configure.ac
index 0ce6cc2..19ae9c8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -14,7 +14,7 @@
 # GNU Lesser General Public License for more details.
 #
 # You should have received a copy of the GNU General Public License
-# along with this program; if not, see <http://www.gnu.org/licenses/>.
+# along with this program; if not, see <https://www.gnu.org/licenses/>.
 
 # (Process this file with autoconf to produce a configure script.)
 # The following lines are used by ./autogen.sh.
diff --git a/doc/Makefile.am b/doc/Makefile.am
index 8949f81..ddb7e48 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -14,7 +14,7 @@
 # GNU Lesser General Public License for more details.
 #
 # You should have received a copy of the GNU Lesser General Public
-# License along with this program; if not, see <http://www.gnu.org/licenses/>.
+# License along with this program; if not, see <https://www.gnu.org/licenses/>.
 
 
 EXTRA_DIST = HACKING errorref.txt \
diff --git a/doc/yat2m.c b/doc/yat2m.c
index f780952..5039cc2 100644
--- a/doc/yat2m.c
+++ b/doc/yat2m.c
@@ -13,7 +13,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, see <http://www.gnu.org/licenses/>.
+ * along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 /*
diff --git a/m4/ac_prog_cc_for_build.m4 b/m4/ac_prog_cc_for_build.m4
index 42c91ce..32329c7 100644
--- a/m4/ac_prog_cc_for_build.m4
+++ b/m4/ac_prog_cc_for_build.m4
@@ -1,5 +1,5 @@
 dnl Available from the GNU Autoconf Macro Archive at:
-dnl http://www.gnu.org/software/ac-archive/htmldoc/ac_prog_cc_for_build.html
+dnl https://www.gnu.org/software/ac-archive/htmldoc/ac_prog_cc_for_build.html
 dnl
 dnl All content of this archive is free software;
 dnl you can redistribute it and/or modify it under the terms of the GNU
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 1d62b05..0cd84af 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -34,7 +34,7 @@ m4_define([_LT_COPYING], [dnl
 #
 # You should have received a copy of the GNU General Public License
 # along with GNU Libtool; see the file COPYING.  If not, a copy
-# can be downloaded from http://www.gnu.org/licenses/gpl.html, or
+# can be downloaded from https://www.gnu.org/licenses/gpl.html, or
 # obtained by writing to the Free Software Foundation, Inc.,
 # 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 ])
diff --git a/src/Makefile.am b/src/Makefile.am
index 8aca7df..b7cb023 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -14,7 +14,7 @@
 # GNU Lesser General Public License for more details.
 #
 # You should have received a copy of the GNU Lesser General Public
-# License along with this program; if not, see <http://www.gnu.org/licenses/>.
+# License along with this program; if not, see <https://www.gnu.org/licenses/>.
 
 # We distribute the generated sources err-sources.h and err-codes.h,
 # because they are needed to build the po directory, and they don't
diff --git a/src/estream-printf.c b/src/estream-printf.c
index 39a813f..091ff7d 100644
--- a/src/estream-printf.c
+++ b/src/estream-printf.c
@@ -14,7 +14,7 @@
  * Lesser General Public License for more details.
  *
  * You should have received a copy of the GNU Lesser General Public
- * License along with Libestream; if not, see <http://www.gnu.org/licenses/>.
+ * License along with Libestream; if not, see <https://www.gnu.org/licenses/>.
  *
  * ALTERNATIVELY, Libestream may be distributed under the terms of the
  * following license, in which case the provisions of this license are
diff --git a/src/estream-printf.h b/src/estream-printf.h
index e82d8fb..ae303a7 100644
--- a/src/estream-printf.h
+++ b/src/estream-printf.h
@@ -14,7 +14,7 @@
  * Lesser General Public License for more details.
  *
  * You should have received a copy of the GNU Lesser General Public
- * License along with Libestream; if not, see <http://www.gnu.org/licenses/>.
+ * License along with Libestream; if not, see <https://www.gnu.org/licenses/>.
  *
  * ALTERNATIVELY, Libestream may be distributed under the terms of the
  * following license, in which case the provisions of this license are
diff --git a/src/estream.c b/src/estream.c
index 3a89868..abce0bf 100644
--- a/src/estream.c
+++ b/src/estream.c
@@ -15,7 +15,7 @@
  * Lesser General Public License for more details.
  *
  * You should have received a copy of the GNU Lesser General Public
- * License along with Libestream; if not, see <http://www.gnu.org/licenses/>.
+ * License along with Libestream; if not, see <https://www.gnu.org/licenses/>.
  *
  * ALTERNATIVELY, Libestream may be distributed under the terms of the
  * following license, in which case the provisions of this license are
diff --git a/src/estream.h b/src/estream.h
index cfb7eec..91f2bc0 100644
--- a/src/estream.h
+++ b/src/estream.h
@@ -14,7 +14,7 @@
  * Lesser General Public License for more details.
  *
  * You should have received a copy of the GNU Lesser General Public
- * License along with this program; if not, see <http://www.gnu.org/licenses/>.
+ * License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #ifndef ESTREAM_H
diff --git a/src/gen-posix-lock-obj.c b/src/gen-posix-lock-obj.c
index 595d379..22de456 100644
--- a/src/gen-posix-lock-obj.c
+++ b/src/gen-posix-lock-obj.c
@@ -14,7 +14,7 @@
    Lesser General Public License for more details.
 
    You should have received a copy of the GNU Lesser General Public
-   License along with this program; if not, see <http://www.gnu.org/licenses/>.
+   License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #if HAVE_CONFIG_H
diff --git a/src/gen-w32-lock-obj.c b/src/gen-w32-lock-obj.c
index 9e49d1e..f8da67f 100644
--- a/src/gen-w32-lock-obj.c
+++ b/src/gen-w32-lock-obj.c
@@ -14,7 +14,7 @@
    Lesser General Public License for more details.
 
    You should have received a copy of the GNU Lesser General Public
-   License along with this program; if not, see <http://www.gnu.org/licenses/>.
+   License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #if HAVE_CONFIG_H
diff --git a/src/gpg-error.def.in b/src/gpg-error.def.in
index 16de809..f8b9ebc 100644
--- a/src/gpg-error.def.in
+++ b/src/gpg-error.def.in
@@ -14,7 +14,7 @@
  * GNU Lesser General Public License for more details.
  *
  * You should have received a copy of the GNU Lesser General Public
- * License along with this program; if not, see <http://www.gnu.org/licenses/>.
+ * License along with this program; if not, see <https://www.gnu.org/licenses/>.
  *
  * Note: This file should be updated manually and the ordinals shall
  * never be changed.  Also check gpg-error.vers and visibility.h.
diff --git a/src/gpg-error.h.in b/src/gpg-error.h.in
index 28581e0..b32b4c4 100644
--- a/src/gpg-error.h.in
+++ b/src/gpg-error.h.in
@@ -14,7 +14,7 @@
  * Lesser General Public License for more details.
  *
  * You should have received a copy of the GNU Lesser General Public
- * License along with this program; if not, see <http://www.gnu.org/licenses/>.
+ * License along with this program; if not, see <https://www.gnu.org/licenses/>.
  *
  * @configure_input@
  */
diff --git a/src/gpg-error.vers b/src/gpg-error.vers
index 067bb29..cdff0e3 100644
--- a/src/gpg-error.vers
+++ b/src/gpg-error.vers
@@ -14,7 +14,7 @@
 # GNU Lesser General Public License for more details.
 #
 # You should have received a copy of the GNU Lesser General Public
-# License along with this program; if not, see <http://www.gnu.org/licenses/>.
+# License along with this program; if not, see <https://www.gnu.org/licenses/>.
 #
 # NOTE: When adding new functions, please make sure to add them to
 #       visibility.h and gpg-error.def.in as well.
diff --git a/src/gpgrt-int.h b/src/gpgrt-int.h
index 0f7b29b..d69fe2c 100644
--- a/src/gpgrt-int.h
+++ b/src/gpgrt-int.h
@@ -14,7 +14,7 @@
  * Lesser General Public License for more details.
  *
  * You should have received a copy of the GNU Lesser General Public
- * License along with this program; if not, see <http://www.gnu.org/licenses/>.
+ * License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #ifndef _GPGRT_GPGRT_INT_H
diff --git a/src/init.c b/src/init.c
index 7abb6ff..8de54b6 100644
--- a/src/init.c
+++ b/src/init.c
@@ -14,7 +14,7 @@
    Lesser General Public License for more details.
 
    You should have received a copy of the GNU Lesser General Public
-   License along with this program; if not, see <http://www.gnu.org/licenses/>.
+   License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #if HAVE_CONFIG_H
diff --git a/src/init.h b/src/init.h
index 0a31fd7..90a716a 100644
--- a/src/init.h
+++ b/src/init.h
@@ -14,7 +14,7 @@
    Lesser General Public License for more details.
  
    You should have received a copy of the GNU Lesser General Public
-   License along with this program; if not, see <http://www.gnu.org/licenses/>.
+   License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #ifndef INIT_H
diff --git a/src/lock.h b/src/lock.h
index b60f2c2..a830b36 100644
--- a/src/lock.h
+++ b/src/lock.h
@@ -14,7 +14,7 @@
    Lesser General Public License for more details.
 
    You should have received a copy of the GNU Lesser General Public
-   License along with this program; if not, see <http://www.gnu.org/licenses/>.
+   License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #ifndef LOCK_H
diff --git a/src/mkw32errmap.c b/src/mkw32errmap.c
index 68d0f05..508a513 100644
--- a/src/mkw32errmap.c
+++ b/src/mkw32errmap.c
@@ -14,7 +14,7 @@
    Lesser General Public License for more details.
  
    You should have received a copy of the GNU Lesser General Public
-   License along with this program; if not, see <http://www.gnu.org/licenses/>.
+   License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #ifdef RESOLVE_MACROS
diff --git a/src/posix-lock-obj.h b/src/posix-lock-obj.h
index 872e55a..08e0bac 100644
--- a/src/posix-lock-obj.h
+++ b/src/posix-lock-obj.h
@@ -14,7 +14,7 @@
    Lesser General Public License for more details.
 
    You should have received a copy of the GNU Lesser General Public
-   License along with this program; if not, see <http://www.gnu.org/licenses/>.
+   License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #ifndef POSIX_LOCK_OBJ_H
diff --git a/src/posix-lock.c b/src/posix-lock.c
index d8f5465..2e0ae92 100644
--- a/src/posix-lock.c
+++ b/src/posix-lock.c
@@ -15,7 +15,7 @@
    Lesser General Public License for more details.
 
    You should have received a copy of the GNU Lesser General Public
-   License along with this program; if not, see <http://www.gnu.org/licenses/>.
+   License along with this program; if not, see <https://www.gnu.org/licenses/>.
 
    Parts of the code, in particular use_pthreads_p, are based on code
    from gettext, written by Bruno Haible <bruno at clisp.org>, 2005.
diff --git a/src/posix-thread.c b/src/posix-thread.c
index bef0386..270dc91 100644
--- a/src/posix-thread.c
+++ b/src/posix-thread.c
@@ -14,7 +14,7 @@
    Lesser General Public License for more details.
 
    You should have received a copy of the GNU Lesser General Public
-   License along with this program; if not, see <http://www.gnu.org/licenses/>.
+   License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #if HAVE_CONFIG_H
diff --git a/src/thread.h b/src/thread.h
index 0b2cf04..c650a99 100644
--- a/src/thread.h
+++ b/src/thread.h
@@ -14,7 +14,7 @@
    Lesser General Public License for more details.
 
    You should have received a copy of the GNU Lesser General Public
-   License along with this program; if not, see <http://www.gnu.org/licenses/>.
+   License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #ifndef THREAD_H
diff --git a/src/version.c b/src/version.c
index 216fee4..d0c408d 100644
--- a/src/version.c
+++ b/src/version.c
@@ -14,7 +14,7 @@
  * Lesser General Public License for more details.
  *
  * You should have received a copy of the GNU Lesser General Public
- * License along with this program; if not, see <http://www.gnu.org/licenses/>.
+ * License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #if HAVE_CONFIG_H
diff --git a/src/visibility.c b/src/visibility.c
index 4750685..e3ac8a7 100644
--- a/src/visibility.c
+++ b/src/visibility.c
@@ -14,7 +14,7 @@
  * Lesser General Public License for more details.
  *
  * You should have received a copy of the GNU Lesser General Public
- * License along with this program; if not, see <http://www.gnu.org/licenses/>.
+ * License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #include <config.h>
diff --git a/src/visibility.h b/src/visibility.h
index ec3a124..1de6c62 100644
--- a/src/visibility.h
+++ b/src/visibility.h
@@ -14,7 +14,7 @@
  * Lesser General Public License for more details.
  *
  * You should have received a copy of the GNU Lesser General Public
- * License along with this program; if not, see <http://www.gnu.org/licenses/>.
+ * License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #ifndef _GPGRT_VISIBILITY_H
diff --git a/src/w32-gettext.c b/src/w32-gettext.c
index 146de53..973a0c3 100644
--- a/src/w32-gettext.c
+++ b/src/w32-gettext.c
@@ -15,7 +15,7 @@
    Lesser General Public License for more details.
 
    You should have received a copy of the GNU Lesser General Public
-   License along with this program; if not, see <http://www.gnu.org/licenses/>.
+   License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #if HAVE_CONFIG_H
diff --git a/src/w32-lock-obj.h b/src/w32-lock-obj.h
index ef53546..8ed3084 100644
--- a/src/w32-lock-obj.h
+++ b/src/w32-lock-obj.h
@@ -14,7 +14,7 @@
    Lesser General Public License for more details.
 
    You should have received a copy of the GNU Lesser General Public
-   License along with this program; if not, see <http://www.gnu.org/licenses/>.
+   License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #ifndef W32_LOCK_OBJ_H
diff --git a/src/w32-lock.c b/src/w32-lock.c
index 8c086f9..d1decc9 100644
--- a/src/w32-lock.c
+++ b/src/w32-lock.c
@@ -14,7 +14,7 @@
    Lesser General Public License for more details.
 
    You should have received a copy of the GNU Lesser General Public
-   License along with this program; if not, see <http://www.gnu.org/licenses/>.
+   License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #if HAVE_CONFIG_H
diff --git a/src/w32-thread.c b/src/w32-thread.c
index 53d26b4..6860075 100644
--- a/src/w32-thread.c
+++ b/src/w32-thread.c
@@ -14,7 +14,7 @@
    Lesser General Public License for more details.
 
    You should have received a copy of the GNU Lesser General Public
-   License along with this program; if not, see <http://www.gnu.org/licenses/>.
+   License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #if HAVE_CONFIG_H
diff --git a/tests/t-common.h b/tests/t-common.h
index c6dcd12..e11bca9 100644
--- a/tests/t-common.h
+++ b/tests/t-common.h
@@ -14,7 +14,7 @@
  * Lesser General Public License for more details.
  *
  * You should have received a copy of the GNU Lesser General Public
- * License along with this program; if not, see <http://www.gnu.org/licenses/>.
+ * License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #include <stdarg.h>
diff --git a/tests/t-lock.c b/tests/t-lock.c
index 1ccf815..38c9cec 100644
--- a/tests/t-lock.c
+++ b/tests/t-lock.c
@@ -14,7 +14,7 @@
  * Lesser General Public License for more details.
  *
  * You should have received a copy of the GNU Lesser General Public
- * License along with this program; if not, see <http://www.gnu.org/licenses/>.
+ * License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #if HAVE_CONFIG_H
diff --git a/tests/t-poll.c b/tests/t-poll.c
index 57cdb75..56b29c8 100644
--- a/tests/t-poll.c
+++ b/tests/t-poll.c
@@ -14,7 +14,7 @@
  * Lesser General Public License for more details.
  *
  * You should have received a copy of the GNU Lesser General Public
- * License along with this program; if not, see <http://www.gnu.org/licenses/>.
+ * License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 /* FIXME: We need much better tests that this very basic one.  */
diff --git a/tests/t-printf.c b/tests/t-printf.c
index 069bdc6..7fba012 100644
--- a/tests/t-printf.c
+++ b/tests/t-printf.c
@@ -14,7 +14,7 @@
  * Lesser General Public License for more details.
  *
  * You should have received a copy of the GNU Lesser General Public
- * License along with this program; if not, see <http://www.gnu.org/licenses/>.
+ * License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 /* Note that these tests check against glibc behaviour.  On non glibc
diff --git a/tests/t-version.c b/tests/t-version.c
index ce8f41b..4606dbc 100644
--- a/tests/t-version.c
+++ b/tests/t-version.c
@@ -14,7 +14,7 @@
  * Lesser General Public License for more details.
  *
  * You should have received a copy of the GNU Lesser General Public
- * License along with this program; if not, see <http://www.gnu.org/licenses/>.
+ * License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #ifdef HAVE_CONFIG_H
-- 
2.7.0



From dkg at fifthhorseman.net  Fri Feb  5 20:16:22 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri,  5 Feb 2016 14:16:22 -0500
Subject: [LIBGPG-ERROR PATCH 01/12] use https for bug reporting
In-Reply-To: <1454699793-25137-1-git-send-email-dkg@fifthhorseman.net>
References: <1454699793-25137-1-git-send-email-dkg@fifthhorseman.net>
Message-ID: <1454699793-25137-2-git-send-email-dkg@fifthhorseman.net>

---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index aec3685..0ce6cc2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -44,7 +44,7 @@ m4_define([mym4_betastring],
 m4_define([mym4_isgit],m4_if(mym4_betastring,[],[no],[yes]))
 m4_define([mym4_full_version],[mym4_version[]mym4_betastring])
 
-AC_INIT([libgpg-error],[mym4_full_version],[http://bugs.gnupg.org])
+AC_INIT([libgpg-error],[mym4_full_version],[https://bugs.gnupg.org])
 # LT Version numbers, remember to change them just *before* a release.
 #   (Code changed:			REVISION++)
 #   (Interfaces added/removed/changed:	CURRENT++, REVISION=0)
-- 
2.7.0



From dkg at fifthhorseman.net  Fri Feb  5 20:16:30 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri,  5 Feb 2016 14:16:30 -0500
Subject: [LIBGPG-ERROR PATCH 09/12] use https to refer to www.ntg.nl
In-Reply-To: <1454699793-25137-1-git-send-email-dkg@fifthhorseman.net>
References: <1454699793-25137-1-git-send-email-dkg@fifthhorseman.net>
Message-ID: <1454699793-25137-10-git-send-email-dkg@fifthhorseman.net>

---
 build-aux/texinfo.tex | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/build-aux/texinfo.tex b/build-aux/texinfo.tex
index 0e9e749..b1f0d2e 100644
--- a/build-aux/texinfo.tex
+++ b/build-aux/texinfo.tex
@@ -1209,7 +1209,7 @@ where each line of input produces a line of output.}
 % for display in the outlines, and in other places.  Thus, we have to
 % double any backslashes.  Otherwise, a name like "\node" will be
 % interpreted as a newline (\n), followed by o, d, e.  Not good.
-% http://www.ntg.nl/pipermail/ntg-pdftex/2004-July/000654.html
+% https://www.ntg.nl/pipermail/ntg-pdftex/2004-July/000654.html
 % (and related messages, the final outcome is that it is up to the TeX
 % user to double the backslashes and otherwise make the string valid, so
 % that's what we do).
-- 
2.7.0



From dkg at fifthhorseman.net  Fri Feb  5 20:16:27 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri,  5 Feb 2016 14:16:27 -0500
Subject: [LIBGPG-ERROR PATCH 06/12] use https to refer to www.perl.org
In-Reply-To: <1454699793-25137-1-git-send-email-dkg@fifthhorseman.net>
References: <1454699793-25137-1-git-send-email-dkg@fifthhorseman.net>
Message-ID: <1454699793-25137-7-git-send-email-dkg@fifthhorseman.net>

---
 build-aux/missing | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/build-aux/missing b/build-aux/missing
index 43e37bd..295de3f 100755
--- a/build-aux/missing
+++ b/build-aux/missing
@@ -101,7 +101,7 @@ else
   exit $st
 fi
 
-perl_URL=http://www.perl.org/
+perl_URL=https://www.perl.org/
 flex_URL=http://flex.sourceforge.net/
 gnu_software_URL=https://www.gnu.org/software
 
-- 
2.7.0



From dkg at fifthhorseman.net  Fri Feb  5 20:16:29 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri,  5 Feb 2016 14:16:29 -0500
Subject: [LIBGPG-ERROR PATCH 08/12] use https to refer to www.cl.cam.ac.uk
In-Reply-To: <1454699793-25137-1-git-send-email-dkg@fifthhorseman.net>
References: <1454699793-25137-1-git-send-email-dkg@fifthhorseman.net>
Message-ID: <1454699793-25137-9-git-send-email-dkg@fifthhorseman.net>

---
 po/en at boldquot.header | 2 +-
 po/en at quot.header     | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/po/en at boldquot.header b/po/en at boldquot.header
index fedb6a0..506ca9e 100644
--- a/po/en at boldquot.header
+++ b/po/en at boldquot.header
@@ -2,7 +2,7 @@
 # The msgids must be ASCII and therefore cannot contain real quotation
 # characters, only substitutes like grave accent (0x60), apostrophe (0x27)
 # and double quote (0x22). These substitutes look strange; see
-# http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html
+# https://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html
 #
 # This catalog translates grave accent (0x60) and apostrophe (0x27) to
 # left single quotation mark (U+2018) and right single quotation mark (U+2019).
diff --git a/po/en at quot.header b/po/en at quot.header
index a9647fc..6522f0c 100644
--- a/po/en at quot.header
+++ b/po/en at quot.header
@@ -2,7 +2,7 @@
 # The msgids must be ASCII and therefore cannot contain real quotation
 # characters, only substitutes like grave accent (0x60), apostrophe (0x27)
 # and double quote (0x22). These substitutes look strange; see
-# http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html
+# https://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html
 #
 # This catalog translates grave accent (0x60) and apostrophe (0x27) to
 # left single quotation mark (U+2018) and right single quotation mark (U+2019).
-- 
2.7.0



From dkg at fifthhorseman.net  Fri Feb  5 20:16:28 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri,  5 Feb 2016 14:16:28 -0500
Subject: [LIBGPG-ERROR PATCH 07/12] use https to refer to www.ctan.org
In-Reply-To: <1454699793-25137-1-git-send-email-dkg@fifthhorseman.net>
References: <1454699793-25137-1-git-send-email-dkg@fifthhorseman.net>
Message-ID: <1454699793-25137-8-git-send-email-dkg@fifthhorseman.net>

---
 build-aux/texinfo.tex | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/build-aux/texinfo.tex b/build-aux/texinfo.tex
index 6f48781..0e9e749 100644
--- a/build-aux/texinfo.tex
+++ b/build-aux/texinfo.tex
@@ -31,7 +31,7 @@
 % reports; you can get the latest version from:
 %   https://www.gnu.org/software/texinfo/ (the Texinfo home page), or
 %   ftp://tug.org/tex/texinfo.tex
-%     (and all CTAN mirrors, see http://www.ctan.org).
+%     (and all CTAN mirrors, see https://www.ctan.org).
 % The texinfo.tex in any given distribution could well be out
 % of date, so if that's what you're using, please check.
 %
@@ -2560,7 +2560,7 @@ end
 % We use the free feym* fonts from the eurosym package by Henrik
 % Theiling, which support regular, slanted, bold and bold slanted (and
 % "outlined" (blackboard board, sort of) versions, which we don't need).
-% It is available from http://www.ctan.org/tex-archive/fonts/eurosym.
+% It is available from https://www.ctan.org/tex-archive/fonts/eurosym.
 %
 % Although only regular is the truly official Euro symbol, we ignore
 % that.  The Euro is designed to be slightly taller than the regular
-- 
2.7.0



From dkg at fifthhorseman.net  Fri Feb  5 20:16:31 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri,  5 Feb 2016 14:16:31 -0500
Subject: [LIBGPG-ERROR PATCH 10/12] use https to refer to cygwin.com
In-Reply-To: <1454699793-25137-1-git-send-email-dkg@fifthhorseman.net>
References: <1454699793-25137-1-git-send-email-dkg@fifthhorseman.net>
Message-ID: <1454699793-25137-11-git-send-email-dkg@fifthhorseman.net>

---
 m4/threadlib.m4 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/m4/threadlib.m4 b/m4/threadlib.m4
index b015365..32c2ea5 100644
--- a/m4/threadlib.m4
+++ b/m4/threadlib.m4
@@ -67,7 +67,7 @@ changequote(,)dnl
          dnl child process gets an endless segmentation fault inside execvp().
          dnl Disable multithreading by default on Cygwin 1.5.x, because it has
          dnl bugs that lead to endless loops or crashes. See
-         dnl <http://cygwin.com/ml/cygwin/2009-08/msg00283.html>.
+         dnl <https://cygwin.com/ml/cygwin/2009-08/msg00283.html>.
          osf*) gl_use_threads=no ;;
          cygwin*)
                case `uname -r` in
-- 
2.7.0



From dkg at fifthhorseman.net  Fri Feb  5 20:16:33 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri,  5 Feb 2016 14:16:33 -0500
Subject: [LIBGPG-ERROR PATCH 12/12] confirm the 639-1 code for venda is ve
In-Reply-To: <1454699793-25137-1-git-send-email-dkg@fifthhorseman.net>
References: <1454699793-25137-1-git-send-email-dkg@fifthhorseman.net>
Message-ID: <1454699793-25137-13-git-send-email-dkg@fifthhorseman.net>

https://www.loc.gov/standards/iso639-2/php/code_changes.php says that
ve is indeed the 2-character code for Venda:

>> This alpha-2 ISO 639-1 code was approved in 1999 and included in
>> ISO 639-1: 2002. It was mistakenly missing in earlier versions of
>> the tables on the ISO639-2 web site. As of January 2003, it has
>> been included.
---
 src/w32-gettext.c | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/src/w32-gettext.c b/src/w32-gettext.c
index 734b9c1..8168e30 100644
--- a/src/w32-gettext.c
+++ b/src/w32-gettext.c
@@ -1039,11 +1039,7 @@ my_nl_locale_name (const char *categoryname)
 	}
       return "uz";
     case LANG_VENDA:
-      /* FIXME: It's not clear whether Venda has the ISO 639-2 two-letter code
-	 "ve" or not.
-	 http://www.loc.gov/standards/iso639-2/englangn.html has it, but
-	 http://lcweb.loc.gov/standards/iso639-2/codechanges.html doesn't,  */
-      return "ven_ZA"; /* or "ve_ZA"? */
+      return "ve_ZA";
     case LANG_VIETNAMESE: return "vi_VN";
     case LANG_WELSH: return "cy_GB";
     case LANG_XHOSA: return "xh_ZA";
-- 
2.7.0



From dkg at fifthhorseman.net  Fri Feb  5 20:16:32 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri,  5 Feb 2016 14:16:32 -0500
Subject: [LIBGPG-ERROR PATCH 11/12] use https to refer to www.ethnologue.com
In-Reply-To: <1454699793-25137-1-git-send-email-dkg@fifthhorseman.net>
References: <1454699793-25137-1-git-send-email-dkg@fifthhorseman.net>
Message-ID: <1454699793-25137-12-git-send-email-dkg@fifthhorseman.net>

---
 src/w32-gettext.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/w32-gettext.c b/src/w32-gettext.c
index 973a0c3..734b9c1 100644
--- a/src/w32-gettext.c
+++ b/src/w32-gettext.c
@@ -681,7 +681,7 @@ my_nl_locale_name (const char *categoryname)
 
   /* Dispatch on language.
      See also http://www.unicode.org/unicode/onlinedat/languages.html .
-     For details about languages, see http://www.ethnologue.com/ .  */
+     For details about languages, see https://www.ethnologue.com/ .  */
   switch (primary)
     {
     case LANG_AFRIKAANS: return "af_ZA";
-- 
2.7.0



From gniibe at fsij.org  Mon Feb  8 06:51:12 2016
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Mon, 8 Feb 2016 14:51:12 +0900
Subject: [PATCH] libgpg-error: fix for Solaris and HPPA
In-Reply-To: <56B2BF25.1080103@fsij.org>
References: <56B2BF25.1080103@fsij.org>
Message-ID: <56B82CD0.7020309@fsij.org>

On 02/04/2016 12:01 PM, NIIBE Yutaka wrote:
> Here is a possible patch for Solaris.  No, I can't test on Solaris.
> 
>     Issue 1671:
>     https://bugs.gnupg.org/gnupg/issue1671

Here is update.  I believe that HPPA requires 16-byte alignment even
on HP-UX.  Dependency to GCC style __attribute__((aligned(16)) is
removed, but use "long double" to get same result.

diff --git a/configure.ac b/configure.ac
index aec3685..d35c944 100644
--- a/configure.ac
+++ b/configure.ac
@@ -274,20 +274,6 @@ if test "$GCC" = yes; then
 fi

 #
-# Check whether the compiler supports the GCC style aligned attribute
-#
-AC_CACHE_CHECK([whether the GCC style aligned attribute is supported],
-       [gcry_cv_gcc_attribute_aligned],
-       [gcry_cv_gcc_attribute_aligned=no
-        AC_COMPILE_IFELSE([AC_LANG_SOURCE(
-          [[struct { int a; } foo __attribute__ ((aligned (16)));]])],
-          [gcry_cv_gcc_attribute_aligned=yes])])
-if test "$gcry_cv_gcc_attribute_aligned" = "yes" ; then
-   AC_DEFINE(HAVE_GCC_ATTRIBUTE_ALIGNED,1,
-     [Defined if a GCC style "__attribute__ ((aligned (n))" is supported])
-fi
-
-#
 # Check for ELF visibility support.
 #
 AC_CACHE_CHECK(whether the visibility attribute is supported,
@@ -416,6 +402,25 @@ else
   fi
 fi

+# Default value for GPG_ERROR_CONFIG_LIBS
+config_libs="-lgpg-error"
+
+#
+# Check for other libraries (now only for -lrt).
+#
+# Save and restore LIBS so e.g., -lrt, isn't added to it.  Otherwise, *all*
+# programs in the package would end up linked with that potentially-shared
+# library, inducing unnecessary run-time overhead.
+LIB_SCHED_YIELD=
+AC_SUBST([LIB_SCHED_YIELD])
+gl_saved_libs=$LIBS
+AC_SEARCH_LIBS([sched_yield], [rt posix4],
+               [if test "$ac_cv_search_sched_yield" != "none required";
then
+                  LIB_SCHED_YIELD=$ac_cv_search_sched_yield
+                  config_libs="$config_libs $LIB_SCHED_YIELD"
+                fi])
+LIBS=$gl_saved_libs
+
 #
 # Prepare building of estream
 #
@@ -424,7 +429,7 @@ estream_INIT
 #
 # Substitution used for gpg-error-config
 #
-GPG_ERROR_CONFIG_LIBS="-lgpg-error"
+GPG_ERROR_CONFIG_LIBS="$config_libs"
 if test "x$LIBTHREAD" != x; then
   GPG_ERROR_CONFIG_LIBS="${GPG_ERROR_CONFIG_LIBS} ${LIBTHREAD}"
 fi
@@ -544,11 +549,3 @@ echo "
         Revision: mym4_revision  (mym4_revision_dec)
         Platform: $host$tmp
 "
-if test "$gcry_cv_gcc_attribute_aligned" != "yes" ; then
-cat <<G10EOF
-***
-***  Please note that your compiler does not support the GCC style
-***  aligned attribute.  Using this software may evoke bus errors.
-***
-G10EOF
-fi
diff --git a/src/gen-posix-lock-obj.c b/src/gen-posix-lock-obj.c
index 595d379..d424137 100644
--- a/src/gen-posix-lock-obj.c
+++ b/src/gen-posix-lock-obj.c
@@ -43,15 +43,15 @@
 #endif

 /* Special requirements for certain platforms.  */
-#if defined(__hppa__) && defined(__linux__)
-# define USE_16BYTE_ALIGNMENT 1
+#if defined(__solaris__) && (defined (__ILP32__) || defined(_ILP32))
+# define USE_DOUBLE_FOR_ALIGNMENT 1
 #else
-# define USE_16BYTE_ALIGNMENT 0
+# define USE_DOUBLE_FOR_ALIGNMENT 0
 #endif
-
-
-#if USE_16BYTE_ALIGNMENT && !HAVE_GCC_ATTRIBUTE_ALIGNED
-# error compiler is not able to enforce a 16 byte alignment
+#if defined(__hppa__)
+# define USE_LONG_DOUBLE_FOR_ALIGNMENT 1
+#else
+# define USE_LONG_DOUBLE_FOR_ALIGNMENT 0
 #endif

 #ifdef USE_POSIX_THREADS
@@ -116,8 +116,10 @@ main (void)
           "\n"
           "#define GPGRT_LOCK_INITIALIZER {%d,{{",
           SIZEOF_PTHREAD_MUTEX_T,
-# if USE_16BYTE_ALIGNMENT
-          "    int _x16_align __attribute__ ((aligned (16)));\n",
+# if USE_DOUBLE_FOR_ALIGNMENT
+          "    double _xd_align;\n",
+# elif USE_LONG_DOUBLE_FOR_ALIGNMENT
+          "    long double _xld_align;\n",
 # else
           "",
 # endif
diff --git a/src/syscfg/lock-obj-pub.hppa-unknown-linux-gnu.h
b/src/syscfg/lock-obj-pub.hppa-unknown-linux-gnu.h
index b57bb76..3682577 100644
--- a/src/syscfg/lock-obj-pub.hppa-unknown-linux-gnu.h
+++ b/src/syscfg/lock-obj-pub.hppa-unknown-linux-gnu.h
@@ -7,7 +7,7 @@ typedef struct
   long _vers;
   union {
     volatile char _priv[48];
-    int _x16_align __attribute__ ((aligned (16)));
+    long double _xld_align;
     long _x_align;
     long *_xp_align;
   } u;
--


From wk at gnupg.org  Mon Feb  8 11:58:26 2016
From: wk at gnupg.org (Werner Koch)
Date: Mon, 08 Feb 2016 11:58:26 +0100
Subject: libgpg-error: refer to network resource using https where possible
In-Reply-To: <1454699793-25137-1-git-send-email-dkg@fifthhorseman.net> (Daniel
 Kahn Gillmor's message of "Fri, 5 Feb 2016 14:16:21 -0500")
References: <1454699793-25137-1-git-send-email-dkg@fifthhorseman.net>
Message-ID: <87h9hjfoz1.fsf@vigenere.g10code.de>

On Fri,  5 Feb 2016 20:16, dkg at fifthhorseman.net said:

> instead of re-pointing the results to https.  I can provde these all
> in single a squashed commit if you prefer it.

Yes, please make just two (1..11 and 12) out of them.


Salam-Shalom,

   Werner

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



From dashohoxha at gmail.com  Mon Feb  8 16:40:37 2016
From: dashohoxha at gmail.com (Dashamir Hoxha)
Date: Mon, 8 Feb 2016 16:40:37 +0100
Subject: Secret Sharing in GPG
In-Reply-To: <CAMucfLx_bt2SPujanObzjbiKbkCG+=XdBpw3rDuPCjncmXpDWw@mail.gmail.com>
References: <CAMucfLwLHJiFXwjA8Rc1j8a-ohfOnvs_JrtfzubmVGu-QEO6sA@mail.gmail.com>
 <87vb6w8nxx.fsf@vigenere.g10code.de>
 <CAMucfLx_bt2SPujanObzjbiKbkCG+=XdBpw3rDuPCjncmXpDWw@mail.gmail.com>
Message-ID: <CAMucfLyZP69Pytj-tu7qw0qf=a_L2hQ=c9FTKY10Mp0+Q-pNRg@mail.gmail.com>

GNU is participating in Google Summer of Code again this year,
and it can act as an umbrella organization for all of its subprojects:
 - http://www.gnu.org/software/soc-projects/guidelines.html
 - http://www.gnu.org/software/soc-projects/ideas-2015.html
 - http://lists.gnu.org/archive/html/summer-of-code/2016-02/msg00000.html

Can we propose the idea of adding key splitting support as a summer project?
Or maybe it is too difficult for a student to do in 2-3 months? Or maybe
sensitive
programs (like gpg) should not be trusted to the students? What do you
think?

Anyway, it is not clear to me how to proceed, who should submit the project
proposal, etc. But maybe subscribing and asking to this mailing list:
 - https://lists.gnu.org/mailman/listinfo/summer-of-code/
can clarify some questions.

As author of the idea I can volunteer to be a mentor, since I would like
to see this feature implemented. But it definitely needs some other
mentor(s) as well, who know the code and can guide the student,
check the quality of his code, etc.

Salam-Shalom-Peace,
Dashamir

On Sun, Jan 17, 2016 at 11:03 PM, Dashamir Hoxha <dashohoxha at gmail.com>
wrote:

> Thanks Werner.
>
> On Thu, Jan 14, 2016 at 11:17 AM, Werner Koch <wk at gnupg.org> wrote:
>
>> Hi,
>>
>> if you are interested in Secret Sharing you may want to look in Phil
>> Sutter's implementaion of a secret sharing daemon for GnuPG from 2008:
>>
>>   http://nwl.cc/cgi-bin/git/gitweb.cgi?p=ssd.git;a=summary
>>   git://nwl.cc/ssd.git
>>
>> There has not been much interested in it back then but it may give you
>> some ideas and code.
>>
>
> From the code and the README files, it is not clear to me what "Phil
> Sutter <phil at nwl.cc>" was trying to accomplish:
>  -
> http://nwl.cc/cgi-bin/git/gitweb.cgi?p=ssd.git;a=tree;f=ssd;h=f8a4290d79f42792ae91889e721ee10aec605fea;hb=HEAD
>  -
> http://nwl.cc/cgi-bin/git/gitweb.cgi?p=ssd.git;a=blob_plain;f=secret-sharing.patch;hb=HEAD
>
> My idea was about using SS (Secret Sharing) to make private key management
> easier and more reliable. This would envolve storing a partial key on the
> local PC/laptop
> where the work (sign/decrypt) is normally done, and storing a second
> partial on a smart-card.
> So, without the smart-card the key cannot be used. But the smart-card
> alone is not sufficient
> for using the key (for example if it used in a different PC/laptop).
>
> To protect against key loss (for example when the smart-card or the laptop
> is lost),
> we also generate a third partial key and store it in a backup media. This
> backup media
> can be a usb device locked in a safe. However it is also Ok to store it in
> the cloud
> (for example I am using Google Drive to store my data).
> We can also store the third partial in two different backup media (for
> example both
> on usb and on cloud).
>
> In terms of `gpg` commands and options it could be decsribed like this:
>
> 1. When generating a new key use the option `--split` like this:
>      `gpg --gen-key --split`
>
>     Without the option `--split` the command will have the normal behaviour
>     of just generating a new key pair.
>     With `--split` it will require a smart-card to be present, otherwise
> it will fail.
>     After generating the key pair, it will split the private key into 3
> shares,
>     will save one partial key locally (on the keyring), one on the
> smart-card,
>     and one on `private-key-backup.tgz`, and then will erase the private
> key.
>     It is the responsibility of the user to store `private-key-backup.tgz`
>     on a proper backup device (cloud, usb or whatever).
>
> 2. When an operation that needs the private key is requested (either sign
> or decrypt),
>     if only a partial key is available (not the whole private key), then
> the presence of the
>     smart-card will be required. Then the partial key of the smart-card
> will be combined
>     with the local partial key in order to reconstruct the private key,
> the private key will
>     be used to complete the operation, then the private key will be erased.
>
> 3. Assuming that the smart-card or the laptop has been lost (one of the
> partial keys
>     has been lost), we should be able to recover the private key like this:
>     `gpg --recover-key --backup-file=private-key-backup.tgz`
>
>     This will get the partial key from `private-key-backup.tgz`, will get
> another
>     partial key from the smart-card or from the local key ring, will
> reconstruct
>     the private key, will generate three other partial keys, will save one
> of them
>     on the local key ring (replacing the old partial, if it is there),
> will store
>     the second one on the smart-card (replacing the old partial if it is
> there),
>     will store the third partial on the file `private-key-new-backup.tgz`
> (and will
>     delete `private-key-backup.tgz`), and finally will erase the private
> key.
>     Then, it is the responsibility of the user to store the file
> `private-key-new-backup.tgz`
>     on the backup device (cloud or usb).
>
> I thought initially that this secret-key spliting and combining can be
> accomplished
> using the libraries or functions of this implementation:
> http://point-at-infinity.org/ssss/
> (just port them to gpg).
>
> However I noticed at the example at the end of the page that it says:
> "Enter the secret, at most 128 ASCII characters"
> So, it is not possible to use it for spliting a RSA private key, which is
> much longer
> than this. I don't know whether this is a limitation of the algorithm, or
> it is just
> a limitation of the implementation, and it can be fixed.
>
> However, it says at the end of the page that for large keys, instead of
> spliting
> the key itself, we can split the password. This could complicate a bit the
> implementation, but I think that it is still can be done.
>
> Salam-Shalom-Peace,
>
> Dashamir
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20160208/4dcde38b/attachment.html>

From dkg at fifthhorseman.net  Mon Feb  8 17:06:38 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon,  8 Feb 2016 11:06:38 -0500
Subject: [LIBGPG-ERROR PATCH v2 2/2] confirm the 639-1 code for venda is ve
In-Reply-To: <1454947598-2920-1-git-send-email-dkg@fifthhorseman.net>
References: <87h9hjfoz1.fsf@vigenere.g10code.de>
 <1454947598-2920-1-git-send-email-dkg@fifthhorseman.net>
Message-ID: <1454947598-2920-2-git-send-email-dkg@fifthhorseman.net>

https://www.loc.gov/standards/iso639-2/php/code_changes.php says that
ve is indeed the 2-character code for Venda:

>> This alpha-2 ISO 639-1 code was approved in 1999 and included in
>> ISO 639-1: 2002. It was mistakenly missing in earlier versions of
>> the tables on the ISO639-2 web site. As of January 2003, it has
>> been included.
---
 src/w32-gettext.c | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/src/w32-gettext.c b/src/w32-gettext.c
index 734b9c1..8168e30 100644
--- a/src/w32-gettext.c
+++ b/src/w32-gettext.c
@@ -1039,11 +1039,7 @@ my_nl_locale_name (const char *categoryname)
 	}
       return "uz";
     case LANG_VENDA:
-      /* FIXME: It's not clear whether Venda has the ISO 639-2 two-letter code
-	 "ve" or not.
-	 http://www.loc.gov/standards/iso639-2/englangn.html has it, but
-	 http://lcweb.loc.gov/standards/iso639-2/codechanges.html doesn't,  */
-      return "ven_ZA"; /* or "ve_ZA"? */
+      return "ve_ZA";
     case LANG_VIETNAMESE: return "vi_VN";
     case LANG_WELSH: return "cy_GB";
     case LANG_XHOSA: return "xh_ZA";
-- 
2.7.0



From dkg at fifthhorseman.net  Mon Feb  8 17:06:37 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon,  8 Feb 2016 11:06:37 -0500
Subject: [LIBGPG-ERROR PATCH v2 1/2] convert http to https where possible in
 the source.
In-Reply-To: <87h9hjfoz1.fsf@vigenere.g10code.de>
References: <87h9hjfoz1.fsf@vigenere.g10code.de>
Message-ID: <1454947598-2920-1-git-send-email-dkg@fifthhorseman.net>

 * use https for bug reporting
 * in comments and docs, use https to refer to:
    - www.gnu.org
    - creativecommons.org
    - translationproject.org
    - mail.gnome.org
    - www.perl.org
    - www.ctan.org
    - www.cl.cam.ac.uk
    - www.ntg.nl
    - cygwin.com
    - www.ethnologue.com
---
 ABOUT-NLS                  |  4 ++--
 Makefile.am                |  2 +-
 autogen.sh                 |  2 +-
 build-aux/compile          |  2 +-
 build-aux/config.guess     |  2 +-
 build-aux/config.sub       |  2 +-
 build-aux/depcomp          |  2 +-
 build-aux/ltmain.sh        |  6 +++---
 build-aux/mdate-sh         |  2 +-
 build-aux/missing          |  6 +++---
 build-aux/texinfo.tex      | 12 ++++++------
 configure.ac               |  4 ++--
 doc/Makefile.am            |  2 +-
 doc/ldap2gpgerr.c          |  2 +-
 doc/yat2m.c                |  2 +-
 m4/ac_prog_cc_for_build.m4 |  2 +-
 m4/libtool.m4              |  2 +-
 m4/threadlib.m4            |  2 +-
 po/en at boldquot.header      |  2 +-
 po/en at quot.header          |  2 +-
 src/Makefile.am            |  2 +-
 src/estream-printf.c       |  2 +-
 src/estream-printf.h       |  2 +-
 src/estream.c              |  2 +-
 src/estream.h              |  2 +-
 src/gen-posix-lock-obj.c   |  2 +-
 src/gen-w32-lock-obj.c     |  2 +-
 src/gpg-error.def.in       |  2 +-
 src/gpg-error.h.in         |  2 +-
 src/gpg-error.vers         |  2 +-
 src/gpgrt-int.h            |  2 +-
 src/init.c                 |  2 +-
 src/init.h                 |  2 +-
 src/lock.h                 |  2 +-
 src/mkw32errmap.c          |  2 +-
 src/posix-lock-obj.h       |  2 +-
 src/posix-lock.c           |  2 +-
 src/posix-thread.c         |  2 +-
 src/thread.h               |  2 +-
 src/version.c              |  2 +-
 src/visibility.c           |  2 +-
 src/visibility.h           |  2 +-
 src/w32-gettext.c          |  4 ++--
 src/w32-lock-obj.h         |  2 +-
 src/w32-lock.c             |  2 +-
 src/w32-thread.c           |  2 +-
 tests/t-common.h           |  2 +-
 tests/t-lock.c             |  2 +-
 tests/t-poll.c             |  2 +-
 tests/t-printf.c           |  2 +-
 tests/t-version.c          |  2 +-
 51 files changed, 63 insertions(+), 63 deletions(-)

diff --git a/ABOUT-NLS b/ABOUT-NLS
index b1de1b6..3b879cb 100644
--- a/ABOUT-NLS
+++ b/ABOUT-NLS
@@ -111,7 +111,7 @@ people who like their own language and write it well, and who are also
 able to synergize with other translators speaking the same language.
 Each translation team has its own mailing list.  The up-to-date list of
 teams can be found at the Free Translation Project's homepage,
-`http://translationproject.org/', in the "Teams" area.
+`https://translationproject.org/', in the "Teams" area.
 
    If you'd like to volunteer to _work_ at translating messages, you
 should become a member of the translating team for your own language.
@@ -1259,7 +1259,7 @@ distribution.
    If June 2010 seems to be old, you may fetch a more recent copy of
 this `ABOUT-NLS' file on most GNU archive sites.  The most up-to-date
 matrix with full percentage details can be found at
-`http://translationproject.org/extra/matrix.html'.
+`https://translationproject.org/extra/matrix.html'.
 
 1.5 Using `gettext' in new packages
 ===================================
diff --git a/Makefile.am b/Makefile.am
index e5f3f56..4f9f094 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -14,7 +14,7 @@
 # GNU Lesser General Public License for more details.
 #
 # You should have received a copy of the GNU Lesser General Public
-# License along with this program; if not, see <http://www.gnu.org/licenses/>.
+# License along with this program; if not, see <https://www.gnu.org/licenses/>.
 
 ACLOCAL_AMFLAGS = -I m4
 DISTCHECK_CONFIGURE_FLAGS = --enable-doc
diff --git a/autogen.sh b/autogen.sh
index 24da40c..91f35a6 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -347,7 +347,7 @@ if [ -d .git ]; then
     [ -z "${SILENT}" ] && cat <<EOF
 *** Activating trailing whitespace git pre-commit hook. ***
     For more information see this thread:
-      http://mail.gnome.org/archives/desktop-devel-list/2009-May/msg00084.html
+      https://mail.gnome.org/archives/desktop-devel-list/2009-May/msg00084.html
     To deactivate this pre-commit hook again move .git/hooks/pre-commit
     and .git/hooks/pre-commit.sample out of the way.
 EOF
diff --git a/build-aux/compile b/build-aux/compile
index 531136b..52f8f94 100755
--- a/build-aux/compile
+++ b/build-aux/compile
@@ -17,7 +17,7 @@ scriptversion=2012-10-14.11; # UTC
 # GNU General Public License for more details.
 #
 # You should have received a copy of the GNU General Public License
-# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+# along with this program.  If not, see <https://www.gnu.org/licenses/>.
 
 # As a special exception to the GNU General Public License, if you
 # distribute this file as part of a program that contains a
diff --git a/build-aux/config.guess b/build-aux/config.guess
index dbfb978..7adf147 100755
--- a/build-aux/config.guess
+++ b/build-aux/config.guess
@@ -15,7 +15,7 @@ timestamp='2015-01-01'
 # General Public License for more details.
 #
 # You should have received a copy of the GNU General Public License
-# along with this program; if not, see <http://www.gnu.org/licenses/>.
+# along with this program; if not, see <https://www.gnu.org/licenses/>.
 #
 # As a special exception to the GNU General Public License, if you
 # distribute this file as part of a program that contains a
diff --git a/build-aux/config.sub b/build-aux/config.sub
index 6d2e94c..0b2d816 100755
--- a/build-aux/config.sub
+++ b/build-aux/config.sub
@@ -15,7 +15,7 @@ timestamp='2015-01-01'
 # General Public License for more details.
 #
 # You should have received a copy of the GNU General Public License
-# along with this program; if not, see <http://www.gnu.org/licenses/>.
+# along with this program; if not, see <https://www.gnu.org/licenses/>.
 #
 # As a special exception to the GNU General Public License, if you
 # distribute this file as part of a program that contains a
diff --git a/build-aux/depcomp b/build-aux/depcomp
index 4ebd5b3..f0a474c 100755
--- a/build-aux/depcomp
+++ b/build-aux/depcomp
@@ -16,7 +16,7 @@ scriptversion=2013-05-30.07; # UTC
 # GNU General Public License for more details.
 
 # You should have received a copy of the GNU General Public License
-# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+# along with this program.  If not, see <https://www.gnu.org/licenses/>.
 
 # As a special exception to the GNU General Public License, if you
 # distribute this file as part of a program that contains a
diff --git a/build-aux/ltmain.sh b/build-aux/ltmain.sh
index f8c3614..c3bcdc0 100644
--- a/build-aux/ltmain.sh
+++ b/build-aux/ltmain.sh
@@ -24,7 +24,7 @@
 #
 # You should have received a copy of the GNU General Public License
 # along with GNU Libtool; see the file COPYING.  If not, a copy
-# can be downloaded from http://www.gnu.org/licenses/gpl.html,
+# can be downloaded from https://www.gnu.org/licenses/gpl.html,
 # or obtained by writing to the Free Software Foundation, Inc.,
 # 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 
@@ -75,8 +75,8 @@
 #         autoconf:	$autoconf_version
 #
 # Report bugs to <bug-libtool at gnu.org>.
-# GNU libtool home page: <http://www.gnu.org/software/libtool/>.
-# General help using GNU software: <http://www.gnu.org/gethelp/>.
+# GNU libtool home page: <https://www.gnu.org/software/libtool/>.
+# General help using GNU software: <https://www.gnu.org/gethelp/>.
 
 PROGRAM=libtool
 PACKAGE=libtool
diff --git a/build-aux/mdate-sh b/build-aux/mdate-sh
index b3719cf..39f48bb 100755
--- a/build-aux/mdate-sh
+++ b/build-aux/mdate-sh
@@ -17,7 +17,7 @@ scriptversion=2010-08-21.06; # UTC
 # GNU General Public License for more details.
 #
 # You should have received a copy of the GNU General Public License
-# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+# along with this program.  If not, see <https://www.gnu.org/licenses/>.
 
 # As a special exception to the GNU General Public License, if you
 # distribute this file as part of a program that contains a
diff --git a/build-aux/missing b/build-aux/missing
index db98974..295de3f 100755
--- a/build-aux/missing
+++ b/build-aux/missing
@@ -17,7 +17,7 @@ scriptversion=2013-10-28.13; # UTC
 # GNU General Public License for more details.
 
 # You should have received a copy of the GNU General Public License
-# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+# along with this program.  If not, see <https://www.gnu.org/licenses/>.
 
 # As a special exception to the GNU General Public License, if you
 # distribute this file as part of a program that contains a
@@ -101,9 +101,9 @@ else
   exit $st
 fi
 
-perl_URL=http://www.perl.org/
+perl_URL=https://www.perl.org/
 flex_URL=http://flex.sourceforge.net/
-gnu_software_URL=http://www.gnu.org/software
+gnu_software_URL=https://www.gnu.org/software
 
 program_details ()
 {
diff --git a/build-aux/texinfo.tex b/build-aux/texinfo.tex
index a181898..b1f0d2e 100644
--- a/build-aux/texinfo.tex
+++ b/build-aux/texinfo.tex
@@ -21,7 +21,7 @@
 %
 % You should have received a copy of the GNU General Public License
 % along with this texinfo.tex file; see the file COPYING.  If not,
-% see <http://www.gnu.org/licenses/>.
+% see <https://www.gnu.org/licenses/>.
 %
 % As a special exception, when this file is read by TeX when processing
 % a Texinfo source document, you may use the result without
@@ -29,9 +29,9 @@
 %
 % Please try the latest version of texinfo.tex before submitting bug
 % reports; you can get the latest version from:
-%   http://www.gnu.org/software/texinfo/ (the Texinfo home page), or
+%   https://www.gnu.org/software/texinfo/ (the Texinfo home page), or
 %   ftp://tug.org/tex/texinfo.tex
-%     (and all CTAN mirrors, see http://www.ctan.org).
+%     (and all CTAN mirrors, see https://www.ctan.org).
 % The texinfo.tex in any given distribution could well be out
 % of date, so if that's what you're using, please check.
 %
@@ -55,7 +55,7 @@
 % extent.  You can get the existing language-specific files from the
 % full Texinfo distribution.
 %
-% The GNU Texinfo home page is http://www.gnu.org/software/texinfo.
+% The GNU Texinfo home page is https://www.gnu.org/software/texinfo.
 
 
 \message{Loading texinfo [version \texinfoversion]:}
@@ -1209,7 +1209,7 @@ where each line of input produces a line of output.}
 % for display in the outlines, and in other places.  Thus, we have to
 % double any backslashes.  Otherwise, a name like "\node" will be
 % interpreted as a newline (\n), followed by o, d, e.  Not good.
-% http://www.ntg.nl/pipermail/ntg-pdftex/2004-July/000654.html
+% https://www.ntg.nl/pipermail/ntg-pdftex/2004-July/000654.html
 % (and related messages, the final outcome is that it is up to the TeX
 % user to double the backslashes and otherwise make the string valid, so
 % that's what we do).
@@ -2560,7 +2560,7 @@ end
 % We use the free feym* fonts from the eurosym package by Henrik
 % Theiling, which support regular, slanted, bold and bold slanted (and
 % "outlined" (blackboard board, sort of) versions, which we don't need).
-% It is available from http://www.ctan.org/tex-archive/fonts/eurosym.
+% It is available from https://www.ctan.org/tex-archive/fonts/eurosym.
 %
 % Although only regular is the truly official Euro symbol, we ignore
 % that.  The Euro is designed to be slightly taller than the regular
diff --git a/configure.ac b/configure.ac
index aec3685..19ae9c8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -14,7 +14,7 @@
 # GNU Lesser General Public License for more details.
 #
 # You should have received a copy of the GNU General Public License
-# along with this program; if not, see <http://www.gnu.org/licenses/>.
+# along with this program; if not, see <https://www.gnu.org/licenses/>.
 
 # (Process this file with autoconf to produce a configure script.)
 # The following lines are used by ./autogen.sh.
@@ -44,7 +44,7 @@ m4_define([mym4_betastring],
 m4_define([mym4_isgit],m4_if(mym4_betastring,[],[no],[yes]))
 m4_define([mym4_full_version],[mym4_version[]mym4_betastring])
 
-AC_INIT([libgpg-error],[mym4_full_version],[http://bugs.gnupg.org])
+AC_INIT([libgpg-error],[mym4_full_version],[https://bugs.gnupg.org])
 # LT Version numbers, remember to change them just *before* a release.
 #   (Code changed:			REVISION++)
 #   (Interfaces added/removed/changed:	CURRENT++, REVISION=0)
diff --git a/doc/Makefile.am b/doc/Makefile.am
index 8949f81..ddb7e48 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -14,7 +14,7 @@
 # GNU Lesser General Public License for more details.
 #
 # You should have received a copy of the GNU Lesser General Public
-# License along with this program; if not, see <http://www.gnu.org/licenses/>.
+# License along with this program; if not, see <https://www.gnu.org/licenses/>.
 
 
 EXTRA_DIST = HACKING errorref.txt \
diff --git a/doc/ldap2gpgerr.c b/doc/ldap2gpgerr.c
index 515bf40..f6fd3cf 100644
--- a/doc/ldap2gpgerr.c
+++ b/doc/ldap2gpgerr.c
@@ -8,7 +8,7 @@
  *
  * You should have received a copy of the CC0 Public Domain Dedication
  * along with this software.  If not, see
- *                 <http://creativecommons.org/publicdomain/zero/1.0/>.
+ *                 <https://creativecommons.org/publicdomain/zero/1.0/>.
  */
 
 /*
diff --git a/doc/yat2m.c b/doc/yat2m.c
index f780952..5039cc2 100644
--- a/doc/yat2m.c
+++ b/doc/yat2m.c
@@ -13,7 +13,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, see <http://www.gnu.org/licenses/>.
+ * along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 /*
diff --git a/m4/ac_prog_cc_for_build.m4 b/m4/ac_prog_cc_for_build.m4
index 42c91ce..32329c7 100644
--- a/m4/ac_prog_cc_for_build.m4
+++ b/m4/ac_prog_cc_for_build.m4
@@ -1,5 +1,5 @@
 dnl Available from the GNU Autoconf Macro Archive at:
-dnl http://www.gnu.org/software/ac-archive/htmldoc/ac_prog_cc_for_build.html
+dnl https://www.gnu.org/software/ac-archive/htmldoc/ac_prog_cc_for_build.html
 dnl
 dnl All content of this archive is free software;
 dnl you can redistribute it and/or modify it under the terms of the GNU
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 1d62b05..0cd84af 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -34,7 +34,7 @@ m4_define([_LT_COPYING], [dnl
 #
 # You should have received a copy of the GNU General Public License
 # along with GNU Libtool; see the file COPYING.  If not, a copy
-# can be downloaded from http://www.gnu.org/licenses/gpl.html, or
+# can be downloaded from https://www.gnu.org/licenses/gpl.html, or
 # obtained by writing to the Free Software Foundation, Inc.,
 # 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 ])
diff --git a/m4/threadlib.m4 b/m4/threadlib.m4
index b015365..32c2ea5 100644
--- a/m4/threadlib.m4
+++ b/m4/threadlib.m4
@@ -67,7 +67,7 @@ changequote(,)dnl
          dnl child process gets an endless segmentation fault inside execvp().
          dnl Disable multithreading by default on Cygwin 1.5.x, because it has
          dnl bugs that lead to endless loops or crashes. See
-         dnl <http://cygwin.com/ml/cygwin/2009-08/msg00283.html>.
+         dnl <https://cygwin.com/ml/cygwin/2009-08/msg00283.html>.
          osf*) gl_use_threads=no ;;
          cygwin*)
                case `uname -r` in
diff --git a/po/en at boldquot.header b/po/en at boldquot.header
index fedb6a0..506ca9e 100644
--- a/po/en at boldquot.header
+++ b/po/en at boldquot.header
@@ -2,7 +2,7 @@
 # The msgids must be ASCII and therefore cannot contain real quotation
 # characters, only substitutes like grave accent (0x60), apostrophe (0x27)
 # and double quote (0x22). These substitutes look strange; see
-# http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html
+# https://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html
 #
 # This catalog translates grave accent (0x60) and apostrophe (0x27) to
 # left single quotation mark (U+2018) and right single quotation mark (U+2019).
diff --git a/po/en at quot.header b/po/en at quot.header
index a9647fc..6522f0c 100644
--- a/po/en at quot.header
+++ b/po/en at quot.header
@@ -2,7 +2,7 @@
 # The msgids must be ASCII and therefore cannot contain real quotation
 # characters, only substitutes like grave accent (0x60), apostrophe (0x27)
 # and double quote (0x22). These substitutes look strange; see
-# http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html
+# https://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html
 #
 # This catalog translates grave accent (0x60) and apostrophe (0x27) to
 # left single quotation mark (U+2018) and right single quotation mark (U+2019).
diff --git a/src/Makefile.am b/src/Makefile.am
index 8aca7df..b7cb023 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -14,7 +14,7 @@
 # GNU Lesser General Public License for more details.
 #
 # You should have received a copy of the GNU Lesser General Public
-# License along with this program; if not, see <http://www.gnu.org/licenses/>.
+# License along with this program; if not, see <https://www.gnu.org/licenses/>.
 
 # We distribute the generated sources err-sources.h and err-codes.h,
 # because they are needed to build the po directory, and they don't
diff --git a/src/estream-printf.c b/src/estream-printf.c
index 39a813f..091ff7d 100644
--- a/src/estream-printf.c
+++ b/src/estream-printf.c
@@ -14,7 +14,7 @@
  * Lesser General Public License for more details.
  *
  * You should have received a copy of the GNU Lesser General Public
- * License along with Libestream; if not, see <http://www.gnu.org/licenses/>.
+ * License along with Libestream; if not, see <https://www.gnu.org/licenses/>.
  *
  * ALTERNATIVELY, Libestream may be distributed under the terms of the
  * following license, in which case the provisions of this license are
diff --git a/src/estream-printf.h b/src/estream-printf.h
index e82d8fb..ae303a7 100644
--- a/src/estream-printf.h
+++ b/src/estream-printf.h
@@ -14,7 +14,7 @@
  * Lesser General Public License for more details.
  *
  * You should have received a copy of the GNU Lesser General Public
- * License along with Libestream; if not, see <http://www.gnu.org/licenses/>.
+ * License along with Libestream; if not, see <https://www.gnu.org/licenses/>.
  *
  * ALTERNATIVELY, Libestream may be distributed under the terms of the
  * following license, in which case the provisions of this license are
diff --git a/src/estream.c b/src/estream.c
index 3a89868..abce0bf 100644
--- a/src/estream.c
+++ b/src/estream.c
@@ -15,7 +15,7 @@
  * Lesser General Public License for more details.
  *
  * You should have received a copy of the GNU Lesser General Public
- * License along with Libestream; if not, see <http://www.gnu.org/licenses/>.
+ * License along with Libestream; if not, see <https://www.gnu.org/licenses/>.
  *
  * ALTERNATIVELY, Libestream may be distributed under the terms of the
  * following license, in which case the provisions of this license are
diff --git a/src/estream.h b/src/estream.h
index cfb7eec..91f2bc0 100644
--- a/src/estream.h
+++ b/src/estream.h
@@ -14,7 +14,7 @@
  * Lesser General Public License for more details.
  *
  * You should have received a copy of the GNU Lesser General Public
- * License along with this program; if not, see <http://www.gnu.org/licenses/>.
+ * License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #ifndef ESTREAM_H
diff --git a/src/gen-posix-lock-obj.c b/src/gen-posix-lock-obj.c
index 595d379..22de456 100644
--- a/src/gen-posix-lock-obj.c
+++ b/src/gen-posix-lock-obj.c
@@ -14,7 +14,7 @@
    Lesser General Public License for more details.
 
    You should have received a copy of the GNU Lesser General Public
-   License along with this program; if not, see <http://www.gnu.org/licenses/>.
+   License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #if HAVE_CONFIG_H
diff --git a/src/gen-w32-lock-obj.c b/src/gen-w32-lock-obj.c
index 9e49d1e..f8da67f 100644
--- a/src/gen-w32-lock-obj.c
+++ b/src/gen-w32-lock-obj.c
@@ -14,7 +14,7 @@
    Lesser General Public License for more details.
 
    You should have received a copy of the GNU Lesser General Public
-   License along with this program; if not, see <http://www.gnu.org/licenses/>.
+   License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #if HAVE_CONFIG_H
diff --git a/src/gpg-error.def.in b/src/gpg-error.def.in
index 16de809..f8b9ebc 100644
--- a/src/gpg-error.def.in
+++ b/src/gpg-error.def.in
@@ -14,7 +14,7 @@
  * GNU Lesser General Public License for more details.
  *
  * You should have received a copy of the GNU Lesser General Public
- * License along with this program; if not, see <http://www.gnu.org/licenses/>.
+ * License along with this program; if not, see <https://www.gnu.org/licenses/>.
  *
  * Note: This file should be updated manually and the ordinals shall
  * never be changed.  Also check gpg-error.vers and visibility.h.
diff --git a/src/gpg-error.h.in b/src/gpg-error.h.in
index 28581e0..b32b4c4 100644
--- a/src/gpg-error.h.in
+++ b/src/gpg-error.h.in
@@ -14,7 +14,7 @@
  * Lesser General Public License for more details.
  *
  * You should have received a copy of the GNU Lesser General Public
- * License along with this program; if not, see <http://www.gnu.org/licenses/>.
+ * License along with this program; if not, see <https://www.gnu.org/licenses/>.
  *
  * @configure_input@
  */
diff --git a/src/gpg-error.vers b/src/gpg-error.vers
index 067bb29..cdff0e3 100644
--- a/src/gpg-error.vers
+++ b/src/gpg-error.vers
@@ -14,7 +14,7 @@
 # GNU Lesser General Public License for more details.
 #
 # You should have received a copy of the GNU Lesser General Public
-# License along with this program; if not, see <http://www.gnu.org/licenses/>.
+# License along with this program; if not, see <https://www.gnu.org/licenses/>.
 #
 # NOTE: When adding new functions, please make sure to add them to
 #       visibility.h and gpg-error.def.in as well.
diff --git a/src/gpgrt-int.h b/src/gpgrt-int.h
index 0f7b29b..d69fe2c 100644
--- a/src/gpgrt-int.h
+++ b/src/gpgrt-int.h
@@ -14,7 +14,7 @@
  * Lesser General Public License for more details.
  *
  * You should have received a copy of the GNU Lesser General Public
- * License along with this program; if not, see <http://www.gnu.org/licenses/>.
+ * License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #ifndef _GPGRT_GPGRT_INT_H
diff --git a/src/init.c b/src/init.c
index 7abb6ff..8de54b6 100644
--- a/src/init.c
+++ b/src/init.c
@@ -14,7 +14,7 @@
    Lesser General Public License for more details.
 
    You should have received a copy of the GNU Lesser General Public
-   License along with this program; if not, see <http://www.gnu.org/licenses/>.
+   License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #if HAVE_CONFIG_H
diff --git a/src/init.h b/src/init.h
index 0a31fd7..90a716a 100644
--- a/src/init.h
+++ b/src/init.h
@@ -14,7 +14,7 @@
    Lesser General Public License for more details.
  
    You should have received a copy of the GNU Lesser General Public
-   License along with this program; if not, see <http://www.gnu.org/licenses/>.
+   License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #ifndef INIT_H
diff --git a/src/lock.h b/src/lock.h
index b60f2c2..a830b36 100644
--- a/src/lock.h
+++ b/src/lock.h
@@ -14,7 +14,7 @@
    Lesser General Public License for more details.
 
    You should have received a copy of the GNU Lesser General Public
-   License along with this program; if not, see <http://www.gnu.org/licenses/>.
+   License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #ifndef LOCK_H
diff --git a/src/mkw32errmap.c b/src/mkw32errmap.c
index 68d0f05..508a513 100644
--- a/src/mkw32errmap.c
+++ b/src/mkw32errmap.c
@@ -14,7 +14,7 @@
    Lesser General Public License for more details.
  
    You should have received a copy of the GNU Lesser General Public
-   License along with this program; if not, see <http://www.gnu.org/licenses/>.
+   License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #ifdef RESOLVE_MACROS
diff --git a/src/posix-lock-obj.h b/src/posix-lock-obj.h
index 872e55a..08e0bac 100644
--- a/src/posix-lock-obj.h
+++ b/src/posix-lock-obj.h
@@ -14,7 +14,7 @@
    Lesser General Public License for more details.
 
    You should have received a copy of the GNU Lesser General Public
-   License along with this program; if not, see <http://www.gnu.org/licenses/>.
+   License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #ifndef POSIX_LOCK_OBJ_H
diff --git a/src/posix-lock.c b/src/posix-lock.c
index d8f5465..2e0ae92 100644
--- a/src/posix-lock.c
+++ b/src/posix-lock.c
@@ -15,7 +15,7 @@
    Lesser General Public License for more details.
 
    You should have received a copy of the GNU Lesser General Public
-   License along with this program; if not, see <http://www.gnu.org/licenses/>.
+   License along with this program; if not, see <https://www.gnu.org/licenses/>.
 
    Parts of the code, in particular use_pthreads_p, are based on code
    from gettext, written by Bruno Haible <bruno at clisp.org>, 2005.
diff --git a/src/posix-thread.c b/src/posix-thread.c
index bef0386..270dc91 100644
--- a/src/posix-thread.c
+++ b/src/posix-thread.c
@@ -14,7 +14,7 @@
    Lesser General Public License for more details.
 
    You should have received a copy of the GNU Lesser General Public
-   License along with this program; if not, see <http://www.gnu.org/licenses/>.
+   License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #if HAVE_CONFIG_H
diff --git a/src/thread.h b/src/thread.h
index 0b2cf04..c650a99 100644
--- a/src/thread.h
+++ b/src/thread.h
@@ -14,7 +14,7 @@
    Lesser General Public License for more details.
 
    You should have received a copy of the GNU Lesser General Public
-   License along with this program; if not, see <http://www.gnu.org/licenses/>.
+   License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #ifndef THREAD_H
diff --git a/src/version.c b/src/version.c
index 216fee4..d0c408d 100644
--- a/src/version.c
+++ b/src/version.c
@@ -14,7 +14,7 @@
  * Lesser General Public License for more details.
  *
  * You should have received a copy of the GNU Lesser General Public
- * License along with this program; if not, see <http://www.gnu.org/licenses/>.
+ * License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #if HAVE_CONFIG_H
diff --git a/src/visibility.c b/src/visibility.c
index 4750685..e3ac8a7 100644
--- a/src/visibility.c
+++ b/src/visibility.c
@@ -14,7 +14,7 @@
  * Lesser General Public License for more details.
  *
  * You should have received a copy of the GNU Lesser General Public
- * License along with this program; if not, see <http://www.gnu.org/licenses/>.
+ * License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #include <config.h>
diff --git a/src/visibility.h b/src/visibility.h
index ec3a124..1de6c62 100644
--- a/src/visibility.h
+++ b/src/visibility.h
@@ -14,7 +14,7 @@
  * Lesser General Public License for more details.
  *
  * You should have received a copy of the GNU Lesser General Public
- * License along with this program; if not, see <http://www.gnu.org/licenses/>.
+ * License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #ifndef _GPGRT_VISIBILITY_H
diff --git a/src/w32-gettext.c b/src/w32-gettext.c
index 146de53..734b9c1 100644
--- a/src/w32-gettext.c
+++ b/src/w32-gettext.c
@@ -15,7 +15,7 @@
    Lesser General Public License for more details.
 
    You should have received a copy of the GNU Lesser General Public
-   License along with this program; if not, see <http://www.gnu.org/licenses/>.
+   License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #if HAVE_CONFIG_H
@@ -681,7 +681,7 @@ my_nl_locale_name (const char *categoryname)
 
   /* Dispatch on language.
      See also http://www.unicode.org/unicode/onlinedat/languages.html .
-     For details about languages, see http://www.ethnologue.com/ .  */
+     For details about languages, see https://www.ethnologue.com/ .  */
   switch (primary)
     {
     case LANG_AFRIKAANS: return "af_ZA";
diff --git a/src/w32-lock-obj.h b/src/w32-lock-obj.h
index ef53546..8ed3084 100644
--- a/src/w32-lock-obj.h
+++ b/src/w32-lock-obj.h
@@ -14,7 +14,7 @@
    Lesser General Public License for more details.
 
    You should have received a copy of the GNU Lesser General Public
-   License along with this program; if not, see <http://www.gnu.org/licenses/>.
+   License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #ifndef W32_LOCK_OBJ_H
diff --git a/src/w32-lock.c b/src/w32-lock.c
index 8c086f9..d1decc9 100644
--- a/src/w32-lock.c
+++ b/src/w32-lock.c
@@ -14,7 +14,7 @@
    Lesser General Public License for more details.
 
    You should have received a copy of the GNU Lesser General Public
-   License along with this program; if not, see <http://www.gnu.org/licenses/>.
+   License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #if HAVE_CONFIG_H
diff --git a/src/w32-thread.c b/src/w32-thread.c
index 53d26b4..6860075 100644
--- a/src/w32-thread.c
+++ b/src/w32-thread.c
@@ -14,7 +14,7 @@
    Lesser General Public License for more details.
 
    You should have received a copy of the GNU Lesser General Public
-   License along with this program; if not, see <http://www.gnu.org/licenses/>.
+   License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #if HAVE_CONFIG_H
diff --git a/tests/t-common.h b/tests/t-common.h
index c6dcd12..e11bca9 100644
--- a/tests/t-common.h
+++ b/tests/t-common.h
@@ -14,7 +14,7 @@
  * Lesser General Public License for more details.
  *
  * You should have received a copy of the GNU Lesser General Public
- * License along with this program; if not, see <http://www.gnu.org/licenses/>.
+ * License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #include <stdarg.h>
diff --git a/tests/t-lock.c b/tests/t-lock.c
index 1ccf815..38c9cec 100644
--- a/tests/t-lock.c
+++ b/tests/t-lock.c
@@ -14,7 +14,7 @@
  * Lesser General Public License for more details.
  *
  * You should have received a copy of the GNU Lesser General Public
- * License along with this program; if not, see <http://www.gnu.org/licenses/>.
+ * License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #if HAVE_CONFIG_H
diff --git a/tests/t-poll.c b/tests/t-poll.c
index 57cdb75..56b29c8 100644
--- a/tests/t-poll.c
+++ b/tests/t-poll.c
@@ -14,7 +14,7 @@
  * Lesser General Public License for more details.
  *
  * You should have received a copy of the GNU Lesser General Public
- * License along with this program; if not, see <http://www.gnu.org/licenses/>.
+ * License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 /* FIXME: We need much better tests that this very basic one.  */
diff --git a/tests/t-printf.c b/tests/t-printf.c
index 069bdc6..7fba012 100644
--- a/tests/t-printf.c
+++ b/tests/t-printf.c
@@ -14,7 +14,7 @@
  * Lesser General Public License for more details.
  *
  * You should have received a copy of the GNU Lesser General Public
- * License along with this program; if not, see <http://www.gnu.org/licenses/>.
+ * License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 /* Note that these tests check against glibc behaviour.  On non glibc
diff --git a/tests/t-version.c b/tests/t-version.c
index ce8f41b..4606dbc 100644
--- a/tests/t-version.c
+++ b/tests/t-version.c
@@ -14,7 +14,7 @@
  * Lesser General Public License for more details.
  *
  * You should have received a copy of the GNU Lesser General Public
- * License along with this program; if not, see <http://www.gnu.org/licenses/>.
+ * License along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #ifdef HAVE_CONFIG_H
-- 
2.7.0



From dkg at fifthhorseman.net  Mon Feb  8 19:31:31 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon,  8 Feb 2016 13:31:31 -0500
Subject: [LIBGPG-ERROR PATCH] refer to --with-libgpg-error-prefix,
 instead of --with-gpg-error-prefix
Message-ID: <1454956291-3542-1-git-send-email-dkg@fifthhorseman.net>

* src/gpg-error.m4: announce the preferred form of configuration,
  since --with-gpg-error-prefix is deprecated earlier in the file.
---
 src/gpg-error.m4 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gpg-error.m4 b/src/gpg-error.m4
index 1661204..60c88d8 100644
--- a/src/gpg-error.m4
+++ b/src/gpg-error.m4
@@ -100,7 +100,7 @@ AC_DEFUN([AM_PATH_GPG_ERROR],
 *** The config script $GPG_ERROR_CONFIG was
 *** built for $gpg_error_config_host and thus may not match the
 *** used host $host.
-*** You may want to use the configure option --with-gpg-error-prefix
+*** You may want to use the configure option --with-libgpg-error-prefix
 *** to specify a matching config script or use \$SYSROOT.
 ***]])
         gpg_config_script_warn="$gpg_config_script_warn libgpg-error"
-- 
2.7.0



From wk at gnupg.org  Mon Feb  8 19:47:29 2016
From: wk at gnupg.org (Werner Koch)
Date: Mon, 08 Feb 2016 19:47:29 +0100
Subject: [LIBGPG-ERROR PATCH v2 1/2] convert http to https where possible
 in the source.
In-Reply-To: <1454947598-2920-1-git-send-email-dkg@fifthhorseman.net> (Daniel
 Kahn Gillmor's message of "Mon, 8 Feb 2016 11:06:37 -0500")
References: <87h9hjfoz1.fsf@vigenere.g10code.de>
 <1454947598-2920-1-git-send-email-dkg@fifthhorseman.net>
Message-ID: <87oabrdoou.fsf@vigenere.g10code.de>

Thanks for the two patches.  I applied both.


Salam-Shalom,

   Werner


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



From wk at gnupg.org  Mon Feb  8 21:17:01 2016
From: wk at gnupg.org (Werner Koch)
Date: Mon, 08 Feb 2016 21:17:01 +0100
Subject: [PATCH gpgme v2 1/3] gpg: Add option --exit-on-status-write-error
In-Reply-To: <1454660251-18619-1-git-send-email-ueno@gnu.org> (Daiki Ueno's
 message of "Fri, 5 Feb 2016 17:17:29 +0900")
References: <1454660251-18619-1-git-send-email-ueno@gnu.org>
Message-ID: <87k2mfdkjm.fsf@vigenere.g10code.de>

On Fri,  5 Feb 2016 09:17, ueno at gnu.org said:

> +  if (!rc)
> +    rc = add_arg (gpg, "--exit-on-status-write-error");

You can't do this w/o checking the gpg version.  Checking the here is
not yet supported.  This requires to do something like

  if (!gpg->version)
     gpg->version = gpg_get_version (file_name);

  if (!rc && gpg->version && _gpgme_compare_versions (gpg->version, "2.1.11"))
     rc = add_arg (gpg, "--exit-on-status-write-error");

plus code to release ->version.  However, this simple solution will
run an extra gpg before the acualt gpg call.  A better solution is to
store the version in the higher level engine info and pass it down to
gpg_new.



Shalom-Salam,

   Werner

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



From dkg at fifthhorseman.net  Mon Feb  8 21:44:07 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon,  8 Feb 2016 15:44:07 -0500
Subject: [PATCH] allow weirdly-mixed pkcs7 signatures
Message-ID: <1454964247-19930-1-git-send-email-dkg@fifthhorseman.net>

* tools/gpgparsemail.c: add and check info->signing_protocol_2

Some mailers in the wild will generate messages that have the a weird
structure where they use the x- prefix in one part and drop it in
another.

For example, the main MIME part as a whole has:

Content-Type: multipart/signed;
   protocol="application/x-pkcs7-signature"

but the signature sub-part has:

  Content-Type: application/pkcs7-signature

(or vice versa, where the x- prefix is in the sub-part but not the
protocol= section on the main MIME object)

This change also avoids allocating strings for these comparisons,
since the const strings in question are already available in the built
executable, and no dynamic labels are needed.
---
 tools/gpgparsemail.c | 40 +++++++++++++++++++++++-----------------
 1 file changed, 23 insertions(+), 17 deletions(-)

diff --git a/tools/gpgparsemail.c b/tools/gpgparsemail.c
index 98bbad0..fc449c3 100644
--- a/tools/gpgparsemail.c
+++ b/tools/gpgparsemail.c
@@ -67,7 +67,9 @@ struct parse_info_s {
   int smfm_state;              /* State of PGP/MIME or S/MIME parsing.  */
   int is_smime;                /* This is S/MIME and not PGP/MIME. */
 
-  char *signing_protocol;
+  const char *signing_protocol;
+  const char *signing_protocol_2; /* there are two ways to present
+                                     PKCS7 */
   int hashing_level;           /* The nesting level we are hashing. */
   int hashing;
   FILE *hash_file;
@@ -139,15 +141,15 @@ xmalloc (size_t n)
 /*   return p; */
 /* } */
 
-static char *
-xstrdup (const char *string)
-{
-  void *p = malloc (strlen (string)+1);
-  if (!p)
-    die ("out of core: %s", strerror (errno));
-  strcpy (p, string);
-  return p;
-}
+/* static char * */
+/* xstrdup (const char *string) */
+/* { */
+/*   void *p = malloc (strlen (string)+1); */
+/*   if (!p) */
+/*     die ("out of core: %s", strerror (errno)); */
+/*   strcpy (p, string); */
+/*   return p; */
+/* } */
 
 #ifndef HAVE_STPCPY
 static char *
@@ -364,8 +366,8 @@ mime_signed_begin (struct parse_info_s *info, rfc822parse_t msg,
             {
               info->smfm_state = 1;
               info->is_smime = 0;
-              free (info->signing_protocol);
-              info->signing_protocol = xstrdup (s);
+              info->signing_protocol = "application/pgp-signature";
+              info->signing_protocol_2 = NULL;
             }
         }
       else if (!strcmp (s, "application/pkcs7-signature")
@@ -377,8 +379,8 @@ mime_signed_begin (struct parse_info_s *info, rfc822parse_t msg,
             {
               info->smfm_state = 1;
               info->is_smime = 1;
-              free (info->signing_protocol);
-              info->signing_protocol = xstrdup (s);
+              info->signing_protocol = "application/pkcs7-signature";
+              info->signing_protocol_2 = "application/x-pkcs7-signature";
             }
         }
       else if (verbose)
@@ -516,10 +518,14 @@ message_cb (void *opaque, rfc822parse_event_t event, rfc822parse_t msg)
                   char *buf = xmalloc (strlen (s1) + strlen (s2) + 2);
                   strcpy (stpcpy (stpcpy (buf, s1), "/"), s2);
                   assert (info->signing_protocol);
-                  if (strcmp (buf, info->signing_protocol))
-                    err ("invalid %s structure; expected '%s', found '%s'",
+                  if (strcmp (buf, info->signing_protocol) &&
+                      (!info->signing_protocol_2 || strcmp (buf,info->signing_protocol_2)))
+                    err ("invalid %s structure; expected %s%s%s, found '%s'",
                          info->is_smime? "S/MIME":"PGP/MIME",
-                         info->signing_protocol, buf);
+                         info->signing_protocol,
+                         info->signing_protocol_2 ? " or " : "",
+                         info->signing_protocol_2 ? info->signing_protocol_2 : "",
+                         buf);
                   else
                     {
                       printf ("c begin_signature\n");
-- 
2.7.0



From aheinecke at intevation.de  Mon Feb  8 21:42:43 2016
From: aheinecke at intevation.de (Andre Heinecke)
Date: Mon, 08 Feb 2016 21:42:43 +0100
Subject: [PATCH] gnupg doc: Fix typo in trustlist.txt example
Message-ID: <1760787.rFSt4gGpYA@esus>

Hi,

Noticed that there were two certificates with usage "de" in the example 
trustlist.txt I found this confusing, before I realized it's a copy / paste 
typo from qualified.txt

Btw. both certificates are expired (as are a lot of the certificates in 
trustlist.txt and all in qualified.txt) but I guess for examples that's ok.

Regards,
Andre

-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-doc-Fix-typo-in-trustlist.txt-example.patch
Type: text/x-patch
Size: 1305 bytes
Desc: not available
URL: </pipermail/attachments/20160208/71d068e7/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160208/71d068e7/attachment.sig>

From dkg at fifthhorseman.net  Tue Feb  9 05:42:24 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon,  8 Feb 2016 23:42:24 -0500
Subject: [LIBGPG-ERROR PATCH] avoid whitespace in gpg-error.def linker script
 for mingw32
Message-ID: <1454992944-25398-1-git-send-email-dkg@fifthhorseman.net>

When cross-building for Windows with ./configure --host
i686-w64-mingw32 on recent versions of debian, the library doesn't get
built properly because of a difference in the whitespace produced in
the library's .def linker script.

The errors look like:

/bin/bash ../libtool  --tag=CC   --mode=link i686-w64-mingw32-gcc  -g -Os -Wall -Wpointer-arith -Wno-psabi -no-undefined -export-symbols gpg-error.def  -XCClinker -static-libgcc -version-info 17:0:17 -Xlinker --no-insert-timestamp -o libgpg-error.la -rpath /usr/share/win32/lib libgpg_error_la-w32-gettext.lo libgpg_error_la-w32-lock.lo libgpg_error_la-w32-thread.lo libgpg_error_la-init.lo libgpg_error_la-version.lo libgpg_error_la-estream.lo libgpg_error_la-estream-printf.lo libgpg_error_la-strsource.lo libgpg_error_la-strerror.lo libgpg_error_la-code-to-errno.lo libgpg_error_la-code-from-errno.lo libgpg_error_la-visibility.lo  versioninfo.lo
libtool: link: /usr/bin/i686-w64-mingw32-nm -B  .libs/libgpg_error_la-w32-gettext.o .libs/libgpg_error_la-w32-lock.o .libs/libgpg_error_la-w32-thread.o .libs/libgpg_error_la-init.o .libs/libgpg_error_la-version.o .libs/libgpg_error_la-estream.o .libs/libgpg_error_la-estream-printf.o .libs/libgpg_error_la-strsource.o .libs/libgpg_error_la-strerror.o .libs/libgpg_error_la-code-to-errno.o .libs/libgpg_error_la-code-from-errno.o .libs/libgpg_error_la-visibility.o .libs/versioninfo.o   | sed -n -e 's/^.*[	 ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[	 ][	 ]*_\([_A-Za-z][_A-Za-z0-9]*\)$/\1 _\2 \2/p' | sed '/ __gnu_lto/d' | /bin/sed -e '/^[BCDGRS][ ]/s/.*[ ]\([^ ]*\)/\1 DATA/;s/^.*[ ]__nm__\([^ ]*\)[ ][^ ]*/\1 DATA/;/^I[ ]/d;/^[AITW][ ]/s/.* //' | sort | uniq > .libs/libgpg-error.exp
libtool: link: if test "x`/bin/sed 1q .libs/libgpg-error.def`" = xEXPORTS; then cp .libs/libgpg-error.def .libs/libgpg-error-0.dll.def; else echo EXPORTS > .libs/libgpg-error-0.dll.def; cat .libs/libgpg-error.def >> .libs/libgpg-error-0.dll.def; fi
libtool: link:  i686-w64-mingw32-gcc -shared .libs/libgpg-error-0.dll.def  .libs/libgpg_error_la-w32-gettext.o .libs/libgpg_error_la-w32-lock.o .libs/libgpg_error_la-w32-thread.o .libs/libgpg_error_la-init.o .libs/libgpg_error_la-version.o .libs/libgpg_error_la-estream.o .libs/libgpg_error_la-estream-printf.o .libs/libgpg_error_la-strsource.o .libs/libgpg_error_la-strerror.o .libs/libgpg_error_la-code-to-errno.o .libs/libgpg_error_la-code-from-errno.o .libs/libgpg_error_la-visibility.o .libs/versioninfo.o    -Os -static-libgcc -Wl,--no-insert-timestamp   -o .libs/libgpg-error-0.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libgpg-error.dll.a
/usr/bin/i686-w64-mingw32-ld: .libs/libgpg-error-0.dll.def:4: syntax error
/usr/bin/i686-w64-mingw32-ld:.libs/libgpg-error-0.dll.def: file format not recognized; treating as linker script
/usr/bin/i686-w64-mingw32-ld:.libs/libgpg-error-0.dll.def:3: syntax error
collect2: error: ld returned 1 exit status
Makefile:654: recipe for target 'libgpg-error.la' failed
make[5]: *** [libgpg-error.la] Error 1
make[5]: Leaving directory '/home/dkg/src/pkg-gnupg/libgpg-error/build-win32/src'

With this patch, the "/usr/bin/sed 1q" line recognizes that the file
is already a valid linker script and doesn't try to tweak it further.
---
 src/gpg-error.def.in | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/gpg-error.def.in b/src/gpg-error.def.in
index f8b9ebc..ab1a8b9 100644
--- a/src/gpg-error.def.in
+++ b/src/gpg-error.def.in
@@ -23,7 +23,6 @@
  */
 
 #include <config.h>
-
 EXPORTS
  gpg_strerror                 @1
  gpg_strerror_r               @2
-- 
2.7.0



From ueno at gnu.org  Tue Feb  9 09:03:49 2016
From: ueno at gnu.org (Daiki Ueno)
Date: Tue,  9 Feb 2016 17:03:49 +0900
Subject: [PATCH gpgme v3 0/5] gpg: Add option --exit-on-status-write-error
Message-ID: <1455005034-31303-1-git-send-email-ueno@gnu.org>

Changes from v2 are:
- add VERSION argument to engine->ops->new
- add version check around --exit-on-status-write-error, as suggested
- use recursive mutex for pthread I/O callback example and test, this
  is necessary to avoid deadlock between the dispatch part of
  do_select() and remove_io_cb()
- revert the adjustment of the first argument of select(), which
  turned out to be unnecessary

Daiki Ueno (5):
  doc: Fix minor errors in I/O callback example
  tests: Fix select usage in t-eventloop
  Supply engine version to engine->ops->new
  gpg: Add option --exit-on-status-write-error
  tests: Add test for cancellation

 doc/gpgme.texi          |  22 +++-
 src/engine-assuan.c     |   3 +-
 src/engine-backend.h    |   3 +-
 src/engine-g13.c        |   3 +-
 src/engine-gpg.c        |   5 +-
 src/engine-gpgconf.c    |   3 +-
 src/engine-gpgsm.c      |   3 +-
 src/engine-spawn.c      |   3 +-
 src/engine-uiserver.c   |   3 +-
 src/engine.c            |   3 +-
 tests/gpg/.gitignore    |   1 +
 tests/gpg/Makefile.am   |  12 ++-
 tests/gpg/t-cancel.c    | 265 ++++++++++++++++++++++++++++++++++++++++++++++++
 tests/gpg/t-eventloop.c |   6 +-
 14 files changed, 318 insertions(+), 17 deletions(-)
 create mode 100644 tests/gpg/t-cancel.c

-- 
2.5.0



From ueno at gnu.org  Tue Feb  9 09:03:50 2016
From: ueno at gnu.org (Daiki Ueno)
Date: Tue,  9 Feb 2016 17:03:50 +0900
Subject: [PATCH gpgme v3 1/5] doc: Fix minor errors in I/O callback example
In-Reply-To: <1455005034-31303-1-git-send-email-ueno@gnu.org>
References: <1455005034-31303-1-git-send-email-ueno@gnu.org>
Message-ID: <1455005034-31303-2-git-send-email-ueno@gnu.org>

* gpgme.texi (I/O Callback Example): Fix typos, add timeout to select,
and initialize mutex as recursive.

Signed-off-by: Daiki Ueno <ueno at gnu.org>
---
 doc/gpgme.texi | 22 +++++++++++++++++-----
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/doc/gpgme.texi b/doc/gpgme.texi
index db94617..c7ed615 100644
--- a/doc/gpgme.texi
+++ b/doc/gpgme.texi
@@ -5830,6 +5830,7 @@ do_select (struct event_loop *loop)
   fd_set wfds;
   int i, n;
   int any = 0;
+  struct timeval tv;
   struct one_fd *fdlist = loop->fds;
 
   pthread_mutex_lock (&loop->lock);
@@ -5838,11 +5839,14 @@ do_select (struct event_loop *loop)
   for (i = 0; i < MAX_FDS; i++)
     if (fdlist[i].fd != -1)
       FD_SET (fdlist[i].fd, fdlist[i].dir ? &rfds : &wfds);
-  pthread_mutex_unlock (&loop->unlock);
+  pthread_mutex_unlock (&loop->lock);
+
+  tv.tv_sec = 0;
+  tv.tv_usec = 1000;
 
   do
     @{
-      n = select (FD_SETSIZE, &rfds, &wfds, NULL, 0);
+      n = select (FD_SETSIZE, &rfds, &wfds, NULL, &tv);
     @}
   while (n < 0 && errno == EINTR);
 
@@ -5896,6 +5900,7 @@ main (int argc, char *argv[])
   gpgme_error_t err;
   gpgme_data_t sig, text;
   int i;
+  pthread_mutexattr_t attr;
   struct gpgme_io_cbs io_cbs =
   @{
     add_io_cb,
@@ -5905,12 +5910,19 @@ main (int argc, char *argv[])
     &result
   @};
 
-  init_gpgme (void);
+  init_gpgme ();
 
   /* Initialize the loop structure.  */
-  pthread_mutex_init (&loop.lock, NULL);
+
+  /* The mutex must be recursive, since remove_io_cb (which acquires a
+     lock) can be called while holding a lock acquired in do_select.  */
+  pthread_mutexattr_init (&attr);
+  pthread_mutexattr_settype (&attr, PTHREAD_MUTEX_RECURSIVE);
+  pthread_mutex_init (&loop.lock, &attr);
+  pthread_mutexattr_destroy (&attr);
+
   for (i = 0; i < MAX_FDS; i++)
-    loop->fds[i].fd = -1;
+    loop.fds[i].fd = -1;
 
   /* Initialize the result structure.  */
   result.done = 0;
-- 
2.5.0



From ueno at gnu.org  Tue Feb  9 09:03:52 2016
From: ueno at gnu.org (Daiki Ueno)
Date: Tue,  9 Feb 2016 17:03:52 +0900
Subject: [PATCH gpgme v3 3/5] Supply engine version to engine->ops->new
In-Reply-To: <1455005034-31303-1-git-send-email-ueno@gnu.org>
References: <1455005034-31303-1-git-send-email-ueno@gnu.org>
Message-ID: <1455005034-31303-4-git-send-email-ueno@gnu.org>

* src/engine-backend.h (struct engine_ops): Add VERSION argument in new
member.  Change all implementations.
* src/engine.c (_gpgme_engine_new): Pass VERSION to engine->ops->new.

Signed-off-by: Daiki Ueno <ueno at gnu.org>
---
 src/engine-assuan.c   | 3 ++-
 src/engine-backend.h  | 3 ++-
 src/engine-g13.c      | 3 ++-
 src/engine-gpg.c      | 3 ++-
 src/engine-gpgconf.c  | 3 ++-
 src/engine-gpgsm.c    | 3 ++-
 src/engine-spawn.c    | 3 ++-
 src/engine-uiserver.c | 3 ++-
 src/engine.c          | 3 ++-
 9 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/src/engine-assuan.c b/src/engine-assuan.c
index 9902467..81fed31 100644
--- a/src/engine-assuan.c
+++ b/src/engine-assuan.c
@@ -212,7 +212,8 @@ llass_release (void *engine)
 /* Create a new instance. If HOME_DIR is NULL standard options for use
    with gpg-agent are issued.  */
 static gpgme_error_t
-llass_new (void **engine, const char *file_name, const char *home_dir)
+llass_new (void **engine, const char *file_name, const char *home_dir,
+	   const char *version)
 {
   gpgme_error_t err = 0;
   engine_llass_t llass;
diff --git a/src/engine-backend.h b/src/engine-backend.h
index 4f4519c..6f8bb1f 100644
--- a/src/engine-backend.h
+++ b/src/engine-backend.h
@@ -44,7 +44,8 @@ struct engine_ops
   const char *(*get_req_version) (void);
 
   gpgme_error_t (*new) (void **r_engine,
-			const char *file_name, const char *home_dir);
+			const char *file_name, const char *home_dir,
+			const char *version);
 
   /* Member functions.  */
   void (*release) (void *engine);
diff --git a/src/engine-g13.c b/src/engine-g13.c
index 4a7b75c..5c99465 100644
--- a/src/engine-g13.c
+++ b/src/engine-g13.c
@@ -212,7 +212,8 @@ g13_release (void *engine)
 
 
 static gpgme_error_t
-g13_new (void **engine, const char *file_name, const char *home_dir)
+g13_new (void **engine, const char *file_name, const char *home_dir,
+	 const char *version)
 {
   gpgme_error_t err = 0;
   engine_g13_t g13;
diff --git a/src/engine-gpg.c b/src/engine-gpg.c
index 9efced2..f2d6613 100644
--- a/src/engine-gpg.c
+++ b/src/engine-gpg.c
@@ -414,7 +414,8 @@ gpg_release (void *engine)
 
 
 static gpgme_error_t
-gpg_new (void **engine, const char *file_name, const char *home_dir)
+gpg_new (void **engine, const char *file_name, const char *home_dir,
+	 const char *version)
 {
   engine_gpg_t gpg;
   gpgme_error_t rc = 0;
diff --git a/src/engine-gpgconf.c b/src/engine-gpgconf.c
index a2407ac..051f1e9 100644
--- a/src/engine-gpgconf.c
+++ b/src/engine-gpgconf.c
@@ -90,7 +90,8 @@ gpgconf_release (void *engine)
 
 
 static gpgme_error_t
-gpgconf_new (void **engine, const char *file_name, const char *home_dir)
+gpgconf_new (void **engine, const char *file_name, const char *home_dir,
+	     const char *version)
 {
   gpgme_error_t err = 0;
   engine_gpgconf_t gpgconf;
diff --git a/src/engine-gpgsm.c b/src/engine-gpgsm.c
index 476e9ef..5b4ca40 100644
--- a/src/engine-gpgsm.c
+++ b/src/engine-gpgsm.c
@@ -235,7 +235,8 @@ gpgsm_release (void *engine)
 
 
 static gpgme_error_t
-gpgsm_new (void **engine, const char *file_name, const char *home_dir)
+gpgsm_new (void **engine, const char *file_name, const char *home_dir,
+	   const char *version)
 {
   gpgme_error_t err = 0;
   engine_gpgsm_t gpgsm;
diff --git a/src/engine-spawn.c b/src/engine-spawn.c
index eb4e038..f0fe1f0 100644
--- a/src/engine-spawn.c
+++ b/src/engine-spawn.c
@@ -324,7 +324,8 @@ engspawn_get_req_version (void)
 
 
 static gpgme_error_t
-engspawn_new (void **engine, const char *file_name, const char *home_dir)
+engspawn_new (void **engine, const char *file_name, const char *home_dir,
+	      const char *version)
 {
   engine_spawn_t esp;
 
diff --git a/src/engine-uiserver.c b/src/engine-uiserver.c
index e4fd47c..4923c3a 100644
--- a/src/engine-uiserver.c
+++ b/src/engine-uiserver.c
@@ -236,7 +236,8 @@ uiserver_release (void *engine)
 
 
 static gpgme_error_t
-uiserver_new (void **engine, const char *file_name, const char *home_dir)
+uiserver_new (void **engine, const char *file_name, const char *home_dir,
+	      const char *version)
 {
   gpgme_error_t err = 0;
   engine_uiserver_t uiserver;
diff --git a/src/engine.c b/src/engine.c
index 8e84da9..8b1e7df 100644
--- a/src/engine.c
+++ b/src/engine.c
@@ -463,7 +463,8 @@ _gpgme_engine_new (gpgme_engine_info_t info, engine_t *r_engine)
     {
       gpgme_error_t err;
       err = (*engine->ops->new) (&engine->engine,
-				 info->file_name, info->home_dir);
+				 info->file_name, info->home_dir,
+				 info->version);
       if (err)
 	{
 	  free (engine);
-- 
2.5.0



From ueno at gnu.org  Tue Feb  9 09:03:51 2016
From: ueno at gnu.org (Daiki Ueno)
Date: Tue,  9 Feb 2016 17:03:51 +0900
Subject: [PATCH gpgme v3 2/5] tests: Fix select usage in t-eventloop
In-Reply-To: <1455005034-31303-1-git-send-email-ueno@gnu.org>
References: <1455005034-31303-1-git-send-email-ueno@gnu.org>
Message-ID: <1455005034-31303-3-git-send-email-ueno@gnu.org>

* tests/gpg/t-eventloop.c (do_select): Supply timeout value to select.

Signed-off-by: Daiki Ueno <ueno at gnu.org>
---
 tests/gpg/t-eventloop.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tests/gpg/t-eventloop.c b/tests/gpg/t-eventloop.c
index cb1e57c..fc1a7db 100644
--- a/tests/gpg/t-eventloop.c
+++ b/tests/gpg/t-eventloop.c
@@ -111,6 +111,7 @@ do_select (void)
   fd_set wfds;
   int i, n;
   int any = 0;
+  struct timeval tv;
 
   FD_ZERO (&rfds);
   FD_ZERO (&wfds);
@@ -118,9 +119,12 @@ do_select (void)
     if (fdlist[i].fd != -1)
       FD_SET (fdlist[i].fd, fdlist[i].dir ? &rfds : &wfds);
 
+  tv.tv_sec = 0;
+  tv.tv_usec = 1000;
+
   do
     {
-      n = select (FD_SETSIZE, &rfds, &wfds, NULL, 0);
+      n = select (FD_SETSIZE, &rfds, &wfds, NULL, &tv);
     }
   while (n < 0 && errno == EINTR);
 
-- 
2.5.0



From ueno at gnu.org  Tue Feb  9 09:03:54 2016
From: ueno at gnu.org (Daiki Ueno)
Date: Tue,  9 Feb 2016 17:03:54 +0900
Subject: [PATCH gpgme v3 5/5] tests: Add test for cancellation
In-Reply-To: <1455005034-31303-1-git-send-email-ueno@gnu.org>
References: <1455005034-31303-1-git-send-email-ueno@gnu.org>
Message-ID: <1455005034-31303-6-git-send-email-ueno@gnu.org>

* tests/gpg/t-cancel.c: New file.
* tests/gpg/Makefile.am (tests_skipped): New variable, default to
t-genkey and t-cancel.
(noinst_PROGRAMS): Add $(tests_skipped).
* tests/gpg/.gitignore: Add t-cancel.

Signed-off-by: Daiki Ueno <ueno at gnu.org>
---
 tests/gpg/.gitignore  |   1 +
 tests/gpg/Makefile.am |  12 ++-
 tests/gpg/t-cancel.c  | 265 ++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 276 insertions(+), 2 deletions(-)
 create mode 100644 tests/gpg/t-cancel.c

diff --git a/tests/gpg/.gitignore b/tests/gpg/.gitignore
index d79ace7..cd193f7 100644
--- a/tests/gpg/.gitignore
+++ b/tests/gpg/.gitignore
@@ -6,6 +6,7 @@ gpg.conf
 pubring.gpg
 pubring.gpg~
 secring.gpg
+t-cancel
 t-decrypt
 t-decrypt-verify
 t-edit
diff --git a/tests/gpg/Makefile.am b/tests/gpg/Makefile.am
index 107397b..4148ea2 100644
--- a/tests/gpg/Makefile.am
+++ b/tests/gpg/Makefile.am
@@ -62,9 +62,17 @@ AM_CPPFLAGS = -I$(top_builddir)/src @GPG_ERROR_CFLAGS@
 AM_LDFLAGS = -no-install
 LDADD = ../../src/libgpgme.la
 t_thread1_LDADD = ../../src/libgpgme-pthread.la -lpthread
+t_cancel_LDADD = ../../src/libgpgme-pthread.la -lpthread
+
+# We don't run t-genkey and t-cancel in the test suite, because it
+# takes too long
+tests_skipped = t-genkey
+if !HAVE_W32_SYSTEM
+tests_skipped += t-cancel
+endif
+
+noinst_PROGRAMS = $(c_tests) $(tests_skipped)
 
-# We don't run t-genkey in the test suite, because it takes too long
-noinst_PROGRAMS = $(c_tests) t-genkey
 
 clean-local:
 	-$(top_srcdir)/tests/start-stop-agent --stop
diff --git a/tests/gpg/t-cancel.c b/tests/gpg/t-cancel.c
new file mode 100644
index 0000000..f92ef16
--- /dev/null
+++ b/tests/gpg/t-cancel.c
@@ -0,0 +1,265 @@
+/* t-thread-cancel.c - Regression test.
+   Copyright (C) 2000 Werner Koch (dd9jn)
+   Copyright (C) 2001, 2003, 2004 g10 Code GmbH
+
+   This file is part of GPGME.
+
+   GPGME is free software; you can redistribute it and/or modify it
+   under the terms of the GNU Lesser General Public License as
+   published by the Free Software Foundation; either version 2.1 of
+   the License, or (at your option) any later version.
+
+   GPGME is distributed in the hope that it will be useful, but
+   WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with this program; if not, write to the Free Software
+   Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
+   02111-1307, USA.  */
+
+/* We need to include config.h so that we know whether we are building
+   with large file system (LFS) support. */
+#ifdef HAVE_CONFIG_H
+#include <config.h>
+#endif
+
+#include <stdlib.h>
+#include <stdio.h>
+#include <string.h>
+#include <assert.h>
+#include <limits.h>
+#include <ctype.h>
+#include <errno.h>
+#include <unistd.h>
+#include <pthread.h>
+
+#include <gpgme.h>
+
+#include "t-support.h"
+
+struct op_result
+{
+  int done;
+  gpgme_error_t err;
+};
+
+static struct op_result op_result;
+
+struct one_fd
+{
+  int fd;
+  int dir;
+  gpgme_io_cb_t fnc;
+  void *fnc_data;
+};
+
+#define FDLIST_MAX 32
+static struct one_fd fdlist[FDLIST_MAX];
+
+static pthread_mutex_t lock;
+
+static gpgme_error_t
+add_io_cb (void *data, int fd, int dir, gpgme_io_cb_t fnc, void *fnc_data,
+           void **r_tag)
+{
+  struct one_fd *fds = data;
+  int i;
+
+  pthread_mutex_lock (&lock);
+  for (i = 0; i < FDLIST_MAX; i++)
+    {
+      if (fds[i].fd == -1)
+        {
+          fds[i].fd = fd;
+          fds[i].dir = dir;
+          fds[i].fnc = fnc;
+          fds[i].fnc_data = fnc_data;
+          break;
+        }
+    }
+  pthread_mutex_unlock (&lock);
+  if (i == FDLIST_MAX)
+    return gpgme_err_make (GPG_ERR_SOURCE_USER_1, GPG_ERR_GENERAL);
+  *r_tag = &fds[i];
+  return 0;
+}
+
+static void
+remove_io_cb (void *tag)
+{
+  struct one_fd *fd = tag;
+
+  pthread_mutex_lock (&lock);
+  fd->fd = -1;
+  pthread_mutex_unlock (&lock);
+}
+
+static void
+io_event (void *data, gpgme_event_io_t type, void *type_data)
+{
+  struct op_result *result = data;
+
+  if (type == GPGME_EVENT_DONE)
+    {
+      result->done = 1;
+      result->err = * (gpgme_error_t *) type_data;
+    }
+}
+
+
+static int
+do_select (void)
+{
+  fd_set rfds;
+  fd_set wfds;
+  int i, n;
+  int any = 0;
+  struct timeval tv;
+
+  pthread_mutex_lock (&lock);
+  FD_ZERO (&rfds);
+  FD_ZERO (&wfds);
+  for (i = 0; i < FDLIST_MAX; i++)
+    if (fdlist[i].fd != -1)
+      FD_SET (fdlist[i].fd, fdlist[i].dir ? &rfds : &wfds);
+  pthread_mutex_unlock (&lock);
+
+  tv.tv_sec = 0;
+  tv.tv_usec = 1000;
+
+  do
+    {
+      n = select (FD_SETSIZE, &rfds, &wfds, NULL, &tv);
+    }
+  while (n < 0 && errno == EINTR);
+
+  if (n < 0)
+    return n;   /* Error or timeout.  */
+
+  pthread_mutex_lock (&lock);
+  for (i = 0; i < FDLIST_MAX && n; i++)
+    {
+      if (fdlist[i].fd != -1)
+        {
+          if (FD_ISSET (fdlist[i].fd, fdlist[i].dir ? &rfds : &wfds))
+            {
+              assert (n);
+              n--;
+              any = 1;
+              (*fdlist[i].fnc) (fdlist[i].fnc_data, fdlist[i].fd);
+            }
+        }
+    }
+  pthread_mutex_unlock (&lock);
+  return any;
+}
+
+static int
+my_wait (void)
+{
+  int n;
+
+  do
+    {
+      n = do_select ();
+    }
+  while (n >= 0 && !op_result.done);
+  return 0;
+}
+
+
+static struct gpgme_io_cbs io_cbs =
+  {
+    add_io_cb,
+    fdlist,
+    remove_io_cb,
+    io_event,
+    &op_result
+  };
+
+
+static void *
+thread_cancel (void *data)
+{
+  gpgme_ctx_t ctx = data;
+  gpgme_error_t err;
+
+  usleep (100000);
+  err = gpgme_cancel (ctx);
+  fail_if_err (err);
+
+  return NULL;
+}
+
+int
+main (int argc, char *argv[])
+{
+  gpgme_ctx_t ctx;
+  gpgme_error_t err;
+  gpgme_engine_info_t info;
+  int i;
+  pthread_mutexattr_t attr;
+  pthread_t tcancel;
+  const char *parms = "<GnupgKeyParms format=\"internal\">\n"
+    "Key-Type: RSA\n"
+    "Key-Length: 2048\n"
+    "Subkey-Type: RSA\n"
+    "Subkey-Length: 2048\n"
+    "Name-Real: Joe Tester\n"
+    "Name-Comment: (pp=abc)\n"
+    "Name-Email: joe at foo.bar\n"
+    "Expire-Date: 0\n"
+    "Passphrase: abc\n"
+    "</GnupgKeyParms>\n";
+
+  init_gpgme (GPGME_PROTOCOL_OpenPGP);
+
+  err = gpgme_get_engine_info (&info);
+  fail_if_err (err);
+
+  /* The mutex must be recursive, since remove_io_cb (which acquires a
+     lock) can be called while holding a lock acquired in do_select.  */
+  pthread_mutexattr_init (&attr);
+  pthread_mutexattr_settype (&attr, PTHREAD_MUTEX_RECURSIVE);
+  pthread_mutex_init (&lock, &attr);
+  pthread_mutexattr_destroy (&attr);
+
+  for (i = 0; i < FDLIST_MAX; i++)
+    fdlist[i].fd = -1;
+
+  err = gpgme_new (&ctx);
+  fail_if_err (err);
+  gpgme_set_armor (ctx, 1);
+  gpgme_set_io_cbs (ctx, &io_cbs);
+  op_result.done = 0;
+
+  pthread_create (&tcancel, NULL, thread_cancel, ctx);
+
+  err = gpgme_op_genkey_start (ctx, parms, NULL, NULL);
+  fail_if_err (err);
+
+  my_wait ();
+
+  pthread_join (tcancel, NULL);
+
+  if (op_result.err)
+    {
+      if (gpgme_err_code (op_result.err) == GPG_ERR_CANCELED)
+	fputs ("Successfully cancelled\n", stdout);
+      else
+	{
+	  fprintf (stderr,
+		   "%s:%i: Operation finished with unexpected error: %s\n",
+		   __FILE__, __LINE__, gpgme_strerror (op_result.err));
+	  exit (1);
+	}
+    }
+  else
+    fputs ("Successfully finished before cancellation\n", stdout);
+
+  gpgme_release (ctx);
+
+  return 0;
+}
-- 
2.5.0



From ueno at gnu.org  Tue Feb  9 09:03:53 2016
From: ueno at gnu.org (Daiki Ueno)
Date: Tue,  9 Feb 2016 17:03:53 +0900
Subject: [PATCH gpgme v3 4/5] gpg: Add option --exit-on-status-write-error
In-Reply-To: <1455005034-31303-1-git-send-email-ueno@gnu.org>
References: <1455005034-31303-1-git-send-email-ueno@gnu.org>
Message-ID: <1455005034-31303-5-git-send-email-ueno@gnu.org>

* src/engine-gpg.c (gpg_new): Add --exit-on-status-write-error if the
engine version is latest enough to expect progress output from gpg.

GnuPG-bug-id: 1415
Signed-off-by: Daiki Ueno <ueno at gnu.org>
---
 src/engine-gpg.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/engine-gpg.c b/src/engine-gpg.c
index f2d6613..2f200f1 100644
--- a/src/engine-gpg.c
+++ b/src/engine-gpg.c
@@ -501,6 +501,8 @@ gpg_new (void **engine, const char *file_name, const char *home_dir,
     rc = add_arg (gpg, "utf8");
   if (!rc)
     rc = add_arg (gpg, "--enable-progress-filter");
+  if (!rc && version && _gpgme_compare_versions (version, "2.1.11"))
+    rc = add_arg (gpg, "--exit-on-status-write-error");
   if (rc)
     goto leave;
 
-- 
2.5.0



From wk at gnupg.org  Tue Feb  9 09:35:55 2016
From: wk at gnupg.org (Werner Koch)
Date: Tue, 09 Feb 2016 09:35:55 +0100
Subject: [LIBGPG-ERROR PATCH] avoid whitespace in gpg-error.def linker
 script for mingw32
In-Reply-To: <1454992944-25398-1-git-send-email-dkg@fifthhorseman.net> (Daniel
 Kahn Gillmor's message of "Mon, 8 Feb 2016 23:42:24 -0500")
References: <1454992944-25398-1-git-send-email-dkg@fifthhorseman.net>
Message-ID: <87fux2e0wk.fsf@vigenere.g10code.de>

On Tue,  9 Feb 2016 05:42, dkg at fifthhorseman.net said:
> When cross-building for Windows with ./configure --host
> i686-w64-mingw32 on recent versions of debian, the library doesn't get
> built properly because of a difference in the whitespace produced in
> the library's .def linker script.

I can't replicate this problem on Jessie.  Did you update libtool before
building libgpg-error?  You should not do that - we patched the included
libtool to fix a couple of problems.  Libtool for Windows is pretty
fragile and replacing it may introduce new bugs.


Salam-Shalom,

   Werner

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



From dgouttegattat at incenp.org  Tue Feb  9 12:51:36 2016
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Tue, 9 Feb 2016 12:51:36 +0100
Subject: Secret Sharing in GPG
In-Reply-To: <CAMucfLyZP69Pytj-tu7qw0qf=a_L2hQ=c9FTKY10Mp0+Q-pNRg@mail.gmail.com>
References: <CAMucfLwLHJiFXwjA8Rc1j8a-ohfOnvs_JrtfzubmVGu-QEO6sA@mail.gmail.com>
 <87vb6w8nxx.fsf@vigenere.g10code.de>
 <CAMucfLx_bt2SPujanObzjbiKbkCG+=XdBpw3rDuPCjncmXpDWw@mail.gmail.com>
 <CAMucfLyZP69Pytj-tu7qw0qf=a_L2hQ=c9FTKY10Mp0+Q-pNRg@mail.gmail.com>
Message-ID: <56B9D2C8.8010108@incenp.org>

On 02/08/2016 04:40 PM, Dashamir Hoxha wrote:
> What do you think?

Well, I can?t say anything about a participation in GSoC, but since I 
already use a secret sharing scheme for my private master key, allow me 
to share some thoughts about GnuPG and secret sharing.


> My idea was about using SS (Secret Sharing) to make private key
> management easier and more reliable. This would envolve storing a
> partial key on the local PC/laptop where the work (sign/decrypt) is
> normally done, and storing a second partial on a smart-card.

The point of storing private keys on a smartcard is that your PC/laptop 
never sees the private keys. When a private key is needed, GnuPG sends 
to the card the data it wants to decrypt or sign, the smartcard then 
performs the operation itsef and sends the result back to GnuPG.

What you?re proposing would imply to fetch the partial key from the 
smartcard back to the computer, where it could be merged with another 
share of the key.

First, it?s not possible with the current specification of the OpenPGP 
smartcard (by design, you cannot *retrieve* a private key stored on the 
card, you can only *use it*). And second, this completely defeats the 
purpose of using a smartcard in the first place.

My private subkeys are on a smartcard and I do not use (or plan to use) 
secret sharing for them. I use secret sharing only for:

* the master private key (which is *not* on the smartcard);
* the backup of my whole private keyring (master- and sub-keys).


> In terms of `gpg` commands and options it could be decsribed like
> this: [?]

I am not sure whether secret sharing needs to be implemented directly 
inside GnuPG.

Another approach is to use an external program solely responsible for 
reconstructing the private key and place it into GnuPG?s 
private-keys-v1.d directory where the GPG Agent will find it.

That?s the approach I use, with a small program I wrote for that purpose 
[1]. When I need my master private key (say, for certifying Bob?s key), 
I run GnuPG like this:

    $ gfsec-use -- gpg2 --edit-key bob at example.com

That gfsec-use program will reconstruct my private key if possible, 
spawn gpg2, and wait for its termination. When I am done, it will remove 
the private key file.

I believe there are two benefits with that approach:

1) there is no need to modify GnuPG;

2) the external program is in no way tied to GnuPG, it?s a generic tool 
that can be used to reconstruct any kind of secret, instead of only a 
GnuPG private key.

Now if your goal is to make secret sharing *easier*, I will readily 
admit that there is still a long way to go. The user still needs to 
manually split her key, dispatch the shares on her various devices, and 
fill in the configuration file required by gfsec-use. All of that could 
be automated, but again, it can be done *outside* of GnuPG, which would 
probably be much easier.

Some more remarks about this method:

*) It depends on GnuPG storing each private key in a separate file in a 
precise location (currently $GNUPGHOME/private-keys-v1.d/keygrip.key). 
If a future GnuPG version changes the location of the private key files, 
this method would break. But I assume that such a change would probably 
be discussed (or at the very least, announced) beforehand on that list.

*) It is mostly intended for *occasional* use, and it is probably not 
suited for the private subkeys you use on a daily basis. I only use it 
for my *master* key.

Anyway, that was just my thoughts on the matter. I do not know the 
position of GnuPG developers on secret sharing, and whether they would 
rather have that feature implemented in GnuPG itself.

Cheers,

Damien

[1] http://www.incenp.org/dvlpt/gfsecret.html
     (warning: ugly and under-tested code ahead ;)

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

From dashohoxha at gmail.com  Tue Feb  9 14:35:31 2016
From: dashohoxha at gmail.com (Dashamir Hoxha)
Date: Tue, 9 Feb 2016 14:35:31 +0100
Subject: Secret Sharing in GPG
In-Reply-To: <56B9D2C8.8010108@incenp.org>
References: <CAMucfLwLHJiFXwjA8Rc1j8a-ohfOnvs_JrtfzubmVGu-QEO6sA@mail.gmail.com>
 <87vb6w8nxx.fsf@vigenere.g10code.de>
 <CAMucfLx_bt2SPujanObzjbiKbkCG+=XdBpw3rDuPCjncmXpDWw@mail.gmail.com>
 <CAMucfLyZP69Pytj-tu7qw0qf=a_L2hQ=c9FTKY10Mp0+Q-pNRg@mail.gmail.com>
 <56B9D2C8.8010108@incenp.org>
Message-ID: <CAMucfLxw0p7Qn8cHvtC=4znuYJ-7isL3BB=mymrOkOQ-9qHnHA@mail.gmail.com>

Damien, thanks for sharing your insights and experience.

On Tue, Feb 9, 2016 at 12:51 PM, Damien Goutte-Gattat <
dgouttegattat at incenp.org> wrote:
>
>
> The point of storing private keys on a smartcard is that your PC/laptop
> never sees the private keys. When a private key is needed, GnuPG sends to
> the card the data it wants to decrypt or sign, the smartcard then performs
> the operation itsef and sends the result back to GnuPG.
>

I didn't know how a smartcard works, thanks for explaining it.


> What you?re proposing would imply to fetch the partial key from the
> smartcard back to the computer, where it could be merged with another share
> of the key.
>

Yes, indeed, this is what I had in mind. But if the smartcard has a
processor and it can decrypt or sign messages, maybe the computer can send
the partial key along with the data, and the smartcard can reconstruct the
key before processing the data. I don't know whether it can work this way
and whether it is possible.


>
> First, it?s not possible with the current specification of the OpenPGP
> smartcard (by design, you cannot *retrieve* a private key stored on the
> card, you can only *use it*). And second, this completely defeats the
> purpose of using a smartcard in the first place.
>

I don't think it defeats the purpose of using a smartcard, it only improves
it. One of the benefits would be that the passphrase or the pin that is
used to secure the secret key now becomes totally optional, and it can be
omitted without reducing the security. If the card is lost, no problem,
nobody will be able to use the key, even though it has no pin or
passphrase. Another benefit is the secure backup. If your card is lost,
your key is not lost, and you can use a brand new card with the same key.
In my opinion, not having to remember a pin or a passphrase is very
important, because it is used very rarely and it is quite possible to
forget it (I have forgotten myself a bunch of important passwords during my
life).


> I am not sure whether secret sharing needs to be implemented directly
> inside GnuPG.
>


> I believe there are two benefits with that approach:
>
> 1) there is no need to modify GnuPG;
>
> 2) the external program is in no way tied to GnuPG, it?s a generic tool
> that can be used to reconstruct any kind of secret, instead of only a GnuPG
> private key.
>

However, implementing it directly in GnuPG does have some benefits:

1) you don't need any extra tools to handle it

2) it can be much easier to use than any extra external tools

3) any programs that depend on GnuPG (and there are lots of them) can
directly benefit from it, without having to reimplement it each one of them
on its own

In my opinion, the last one is the most important.


>
> Now if your goal is to make secret sharing *easier*, I will readily admit
> that there is still a long way to go. The user still


Yes, this is one of the goals too, to make gpg key management easier in
general.


> *) It depends on GnuPG storing each private key in a separate file in a
> precise location (currently $GNUPGHOME/private-keys-v1.d/keygrip.key). If a
> future GnuPG version changes the location of the private key files, this
> method would break. But I assume that such a change would probably be
> discussed (or at the very least, announced) beforehand on that list.
>

A suggestion: why don't you use gpg commands for import, export and delete?
This way you don't need to worry about implementation details (where and
how does GnuPG stores the private keys, etc.)


> [1] http://www.incenp.org/dvlpt/gfsecret.html
>     (warning: ugly and under-tested code ahead ;)
>

Thanks for sharing it anyway.
By the way, I am thinking of starting a project for simplifying the gpg key
management for the beginners. This will be a shell script (or a bunch of
shell scripts) that will wrap gpg commands, trying to make the workflow
easier and more understandable. I am thinking to start by cloning this
project: https://github.com/nyarly/simplekey
Is anybody interested in joining, helping, providing feedback, etc.?

Cheers,
Dashamir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20160209/9c2900c4/attachment.html>

From uldis.ansmits at tieto.com  Tue Feb  9 15:23:47 2016
From: uldis.ansmits at tieto.com (=?UTF-8?Q?Uldis_An=C5=A1mits?=)
Date: Tue, 9 Feb 2016 16:23:47 +0200
Subject: gpg-preset-passphrase not opening redirected socket.
Message-ID: <CAL=27uSn6rxw2DvfKU9yBfi1WLL+_1BcduZB1wyNNttLq80hWg@mail.gmail.com>

Hello!

On my build environment I hit the sun_path socket length limit.
This leads to gnupg2 unit test failure.

I was trying to work around the limit by configuring socket redirect in
tests/openpgp.

The configuration file is:
cat <long path to gnupg2 build folder>/test/opengpg/S.gpg-agent
%Assuan%
socket=<short path>/S.gpg-agent
-------
Now tests are starting gpg-agent.

Unfortunately gpg-preset-passphrase does not read socket redirect
configuration and most tests still fail.

What is the reason not to use libassuan socket redirect implementation in
gpg-preset-passphrase?

How to work correctly with GNUPGHOME longer than 108 (actually
96+"/S.gpg-agent") ?

Regard
Uldis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20160209/868a8aa1/attachment.html>

From wk at gnupg.org  Tue Feb  9 16:25:04 2016
From: wk at gnupg.org (Werner Koch)
Date: Tue, 09 Feb 2016 16:25:04 +0100
Subject: [Announce] Libgcrypt 1.6.5 with security fix released
Message-ID: <87h9hhdhyn.fsf@vigenere.g10code.de>

Hello!

The GNU project is pleased to announce the availability of Libgcrypt
version 1.6.5.  This is a security fix release to mitigate a new side
channel attack.

Libgcrypt is a general purpose library of cryptographic building blocks.
It does not provide any implementation of OpenPGP or other protocols.
Thorough understanding of applied cryptography is required for proper
use Libgcrypt.


Noteworthy changes in version 1.6.5
===================================

 * Mitigate side-channel attack on ECDH with Weierstrass curves
   [CVE-2015-7511].  See http://www.cs.tau.ac.IL/~tromer/ecdh/ for
   details.

 * Fix build problem on Solaris.


Download
========

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

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

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

 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.5.tar.bz2 (2490k)
 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.5.tar.bz2.sig
or here:
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.6.5.tar.bz2 (2490k)
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.6.5.tar.bz2.sig

The same source code but compressed with the older GZIP algorithm is
available here:

 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.5.tar.gz (2901k)
 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.5.tar.gz.sig

The affected ECDH algorithm is for example used by GnuPG 2.1 (modern).
An update of Libgcrypt is sufficient to fix this for GnuPG.  We have
also updated the Windows installer of that GnuPG version to include this
fixed version of Libgcrypt:

 ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.11_20160209.exe  (2630k)
 ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.11_20160209.exe.sig
or here:
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.11_20160209.exe  (2630k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.11_20160209.exe.sig

The source used to build that Windows installer can be found in the same
directory with a ".tar.xz" suffix.


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

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

 * Check the supplied OpenPGP signature.  For example to check the
   signature of the file libgcrypt-1.6.5.tar.bz2 you would use this
   command:

     gpg --verify libgcrypt-1.6.5.tar.bz2.sig libgcrypt-1.6.5.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 below for information on the signing keys.

 * If you are not able to use 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
   libgcrypt-1.6.5.tar.bz2, you run the command like this:

     sha1sum libgcrypt-1.6.5.tar.bz2

   and check that the output matches the first line from the
   following list:

c3a5a13e717f7b3e3895650afc1b6e0d3fe9c726  libgcrypt-1.6.5.tar.bz2
765370d9ee9e858c257dc06c3f0621bda8acaf69  libgcrypt-1.6.5.tar.gz
89bd31652d370ba69ac27b42b4d474d7edd9e0ea  gnupg-w32-2.1.11_20160209.exe
0a81d3a7b404299f651bf6f6540176b00d0a3967  gnupg-w32-2.1.11_20160209.tar.xz


Release Signing Keys
====================

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

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

  rsa2048/E0856959 2014-10-29 [expires: 2019-12-31]
  Key fingerprint = 46CC 7308 65BB 5C78 EBAB  ADCF 0437 6F3E E085 6959
  David Shaw (GnuPG Release Signing Key) <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)

You may retrieve these keys from a keyserver using this command

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

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


Copying
=======

Libgcrypt is distributed under the terms of the GNU Lesser General
Public License (LGPLv2.1+).  The helper programs as well as the
documentation are distributed under the terms of the GNU General Public
License (GPLv2+).  The file LICENSES has notices about contributions
that require these additional notices are distributed.


Support
=======

For help on developing with Libgcrypt you should read the included
manual and optional ask on the gcrypt-devel mailing list [1].  A
listing with commercial support offers for Libgcrypt and related
software is available at the GnuPG web site [2].

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

Please consult the archive of the gcrypt-devel 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>.  For commercial support
requests we keep a list of known service companies at:

  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 gcrypt-devel mailing list for
discussion.

Maintenance and development of Libgcrypt is mostly financed by donations.
We currently employ 3 full-time developers, one part-timer, and one
contractor.  They all work on GnuPG and closely related software like
Libgcrypt.  Please see

  https://gnupg.org/donate/

on how you can help.



Thanks
======

We have to thank all the people who helped with this release, be it
testing, coding, suggesting, auditing, administering the servers,
spreading the word, answering questions on the mailing lists, and
donating money.  Niibe Yutaka did most of the work on fixing the side
channel attack.  Special thanks to Daniel Genkin, Lev Pachmanov, Itamar
Pipman, and Eran Tromer for notifying us about their attack in advance
and testing the fix.


For the Libgcrypt hackers,

  Werner


p.s.
This is a announcement only mailing list.  Please send replies only to
the gcrypt-devel at gnupg.org mailing list.

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

From dkg at fifthhorseman.net  Wed Feb 10 01:17:16 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 09 Feb 2016 19:17:16 -0500
Subject: [LIBGPG-ERROR PATCH] avoid whitespace in gpg-error.def linker
 script for mingw32
In-Reply-To: <87fux2e0wk.fsf@vigenere.g10code.de>
References: <1454992944-25398-1-git-send-email-dkg@fifthhorseman.net>
 <87fux2e0wk.fsf@vigenere.g10code.de>
Message-ID: <87wpqdo1v7.fsf@alice.fifthhorseman.net>

On Tue 2016-02-09 03:35:55 -0500, Werner Koch wrote:
> On Tue,  9 Feb 2016 05:42, dkg at fifthhorseman.net said:
>> When cross-building for Windows with ./configure --host
>> i686-w64-mingw32 on recent versions of debian, the library doesn't get
>> built properly because of a difference in the whitespace produced in
>> the library's .def linker script.
>
> I can't replicate this problem on Jessie.

hm, i haven't tried it on jessie, i've only tried it on
testing/unstable.

> Did you update libtool before building libgpg-error?

I did autoreconf the package, yes.  This is generally considered good
practice on debian for a number of reasons, many of which are described
here:

   https://wiki.debian.org/Autoreconf

> You should not do that - we patched the included libtool to fix a
> couple of problems.

Are these fixes documented or pushed upstream anywhere?  If they're
causing problems for GnuPG, we should get them upstreamed into libtool.

Similarly, GnuPG would benefit from being able to use the bugfixes that
made their way into upstream versions of libtool and other autotools
packages.

> Libtool for Windows is pretty fragile and replacing it may introduce
> new bugs.

i'm hoping that in debian we can have an automated system that finds
those bugs and reports them so that they can be fixed for everyone.
With the patch supplied, an autoreconf'ed libgpg-error can be built for
Windows directly from debian.  I plan to introduce autopkgtest rules as
well to ensure that the builds actually work (at least that they work
under wine, we don't have any sort of actual-MS-Windows CI set up within
debian).

The reason i care about this is that there is a variant of
debian-installer that runs on windows [0], and part of that installer is
a gpgv.exe that is used to verify files after the installer bootstrap.
I want to ensure that this tool can be built using modern versions of
GnuPG.  And of course, i want to ensure that it builds cleanly (and in
an automated fashion) on debian systems without the need for any
external process.

If the patch works to acheive this goal, you see any problem with it?

        --dkg

[0] https://packages.qa.debian.org/w/win32-loader.html


From dkg at fifthhorseman.net  Thu Feb 11 13:08:55 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 11 Feb 2016 07:08:55 -0500
Subject: [PATCH] clean up dangling agent_open and agent_closed declarations
Message-ID: <1455192535-5023-1-git-send-email-dkg@fifthhorseman.net>

* g10/keydb.h: remove agent_open, agent_close declarations
* g10/migrate.c: #include <unistd.h> for access()

agent_open() is only defined statically in common/simple-pw-query.c,
it is neither used nor referenced anywhere else.  agent_close doesn't
exist anywhere.  The removal of these declarations removes an
unecessary inclusion of libassuan.h.

migrate.c was relying on keydb.h -> libassuan.h -> unistd.h for the
declaration of access(), so we now handle that explicitly instead.
---
 g10/keydb.h   | 4 ----
 g10/migrate.c | 1 +
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/g10/keydb.h b/g10/keydb.h
index e679d94..2da358f 100644
--- a/g10/keydb.h
+++ b/g10/keydb.h
@@ -22,8 +22,6 @@
 #ifndef G10_KEYDB_H
 #define G10_KEYDB_H
 
-#include <assuan.h>
-
 #include "types.h"
 #include "util.h"
 #include "packet.h"
@@ -248,8 +246,6 @@ gpg_error_t build_sk_list (ctrl_t ctrl, strlist_t locusr,
 
 /*-- passphrase.h --*/
 unsigned char encode_s2k_iterations (int iterations);
-assuan_context_t agent_open (int try, const char *orig_codeset);
-void agent_close (assuan_context_t ctx);
 int  have_static_passphrase(void);
 const char *get_static_passphrase (void);
 void set_passphrase_from_string(const char *pass);
diff --git a/g10/migrate.c b/g10/migrate.c
index 96ca5c2..48cbdd0 100644
--- a/g10/migrate.c
+++ b/g10/migrate.c
@@ -22,6 +22,7 @@
 #include <stdlib.h>
 #include <string.h>
 #include <errno.h>
+#include <unistd.h>
 #include <assert.h>
 
 #include "gpg.h"
-- 
2.7.0



From uldis.ansmits at tieto.com  Thu Feb 11 14:19:04 2016
From: uldis.ansmits at tieto.com (=?UTF-8?Q?Uldis_An=C5=A1mits?=)
Date: Thu, 11 Feb 2016 15:19:04 +0200
Subject: Missing Npth test
Message-ID: <CAL=27uQyCetd0MgRKZJouFT_RJaLiG-11LswPm+XrQ9-gfDH8w@mail.gmail.com>

Hello!

I believe, npth project is missing test for resource locking after for.
Please see patch at the end of message.

gnupg-2.1.11 tests fail on AIX. gpg-agent fails on semaphore operations
during startup.

Following important npth library functions are executed by gpg-agent on
startup:
1. npth_init
2. npth_unportect
3. npth_protect
4. fork
5. npth_pselect <- here things go wrong

Tested on following AIX versions

AIX 5.3 ---------
$ oslevel -s
5300-12-02-1036
$ truss -f gpg-agent --daemon 2>&1 |grep -E '(sem|SIGHUP|fork)'
413790: sem_init(0x09001000A0276C60, 0, 1)              = 0
413790: _sem_wait(0x09001000A0276C60, 0x0000000000000000, 0) = 0
413790: sem_post(0x09001000A0276C60)                    = 0
413790: _sem_wait(0x09001000A0276C60, 0x0000000000000000, 0) = 0
413790: kfork()                                         = 3621076
3621076:         L`kfork()              (returning as child ...)        = 0
3621076:        4710521: sem_post(0x09001000A0276C60)           =
0xFFFFFFFFFFFFFFFF

npth test output:
PASS: t-mutex
PASS: t-thread
Assertion failed: res == 0, file  ../../npth-1.2/src/npth.c, line 123
FAIL: t-fork

AIX 7.1 --------
$ oslevel -s
7100-00-03-1115

$ truss -f gpg-agent --daemon 2>&1 |grep -E '(sem|SIGHUP|fork)'
46858388: 36372657: sem_init(0x09001000A0B243A8, 0, 1)  = 0
46858388: 36372657: _sem_wait(0x09001000A0B243A8, 0x0000000000000000, 0) = 0
46858388: 36372657: sem_post(0x09001000A0B243A8)                = 0
46858388: 36372657: _sem_wait(0x09001000A0B243A8, 0x0000000000000000, 0) = 0
46858388: 36372657: kfork()                             = 54132990
54132990:       kfork()         (returning as child ...)        = 0
54132990:       69140619: sem_post(0x09001000A0B243A8)          Err#13
EACCES

npth test output:
PASS: t-mutex
PASS: t-thread
Assertion failed: __EX, file  ../../npth-1.2/src/npth.c, line 123
FAIL: t-fork

AIX 7.1 --------
$ oslevel -s
7100-00-10-1334

$ truss -f gpg-agent --daemon 2>&1 |grep -E '(sem|SIGHUP|fork)'
41353330: 69599333: sem_init(0x09001000A06C3BD8, 0, 1)  = 0
41353330: 69599333: _sem_wait(0x09001000A06C3BD8, 0x0000000000000000, 0) = 0
41353330: 69599333: sem_post(0x09001000A06C3BD8)                = 0
41353330: 69599333: _sem_wait(0x09001000A06C3BD8, 0x0000000000000000, 0) = 0
41353330: 69599333: kfork()                             = 44892354
44892354:       kfork()         (returning as child ...)        = 0
44892354:           Received signal #1, SIGHUP [default]

For reason unknown to me, on last machine child receives SIGHUP soon after
fork.
Workaround for this is to set signal handler right after fork but this is
nothing to do with Npth.

npth test output:
PASS: t-mutex
PASS: t-thread
Assertion failed: __EX, file  ../../npth-1.2/src/npth.c, line 123
FAIL: t-fork

If i change sem_init(,pshared=1,) in npth_init, semaphore operations works.

Please consider following patch for testing Npth behaviour after fork.

diff --git a/tests/Makefile.am b/tests/Makefile.am
index 0dd436e..4b39ff6 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -28,7 +28,7 @@

 ## Process this file with automake to produce Makefile.in

-TESTS = t-mutex t-thread
+TESTS = t-mutex t-thread t-fork

 # We explicitly require POSIX.1-2001 so that pthread_rwlock_t is
 # available when build with c99.
diff --git a/tests/t-fork.c b/tests/t-fork.c
new file mode 100644
index 0000000..b6a0a17
--- /dev/null
+++ b/tests/t-fork.c
@@ -0,0 +1,49 @@
+/* t-mutex.c
+ * Copyright 2011, 2012 g10 Code GmbH
+ *
+ * This file is free software; as a special exception the author gives
+ * unlimited permission to copy and/or distribute it, with or without
+ * modifications, as long as this notice is preserved.
+ *
+ * This file is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY, to the extent permitted by law; without even the
+ * implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ */
+
+#include "t-support.h"
+
+
+int
+main (int argc, char *argv[])
+{
+  int rc;
+
+  rc = npth_init ();
+  fail_if_err (rc);
+  npth_unprotect ();
+  npth_protect ();
+  pid_t pid;
+  npth_sigev_init ();
+  npth_sigev_add (SIGHUP);
+  npth_sigev_fini ();
+  pid = fork ();
+  if (pid == (pid_t)-1)
+    {
+      fail_msg ("fork failed");
+      exit (1);
+    }
+  else if (pid)
+   {
+     int status;
+     info_msg("forked");
+     waitpid(-1,&status,0);
+     if(status) {
+       exit(1);
+     }
+   } else {
+     npth_unprotect ();
+     info_msg("child exit");
+     exit(0);
+   }
+  return 0;
+}

Thank you.
Uldis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20160211/27446668/attachment.html>

From dashohoxha at gmail.com  Mon Feb 15 08:34:34 2016
From: dashohoxha at gmail.com (Dashamir Hoxha)
Date: Mon, 15 Feb 2016 08:34:34 +0100
Subject: Automated testing with Sharness
Message-ID: <CAMucfLwu1v_SEfZsJSHhN0vGK5E+D-Sg2cgr7XCp62te+S4QMg@mail.gmail.com>

Hi,

I have recently written some automated testing scripts
for a small utility that I am developing:
 - https://github.com/dashohoxha/pw/tree/master/tests

They are based on Sharness:
 - https://github.com/mlafeldt/sharness
which is derived from the testing framework of Git:
 - https://github.com/git/git/blob/master/t/README

I wonder whether it would be interesting to use Sharness
for writting testing scripts for GnuPG as well.

I have seen that GnuPG already has its own testing scripts:
 -
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=tree;f=tests;h=cf656724618e3db83a89ce1a19f80687370651c0;hb=HEAD
So, in a sense writing new testing scripts could be considered
unnecessary work. It can also be a bit tedious and boring.

However I think that it may be a good task for a student
(as a summer project). It doesn't hurt to write some new
testing scripts besides the existing ones. And it doesn't need
a lot of knowledge and skills to get started (just basic shell scripting
skills and getting familiar with GnuPG). So, I believe that any
hardworking student that is able to work systematically, can do it.

I can also volunteer to be a mentor for this project, but first I need
the support/approval/endorsement of GnuPG developers and
maintainers. Then we also have to find out how to register
this project on Google Summer of Code (so that the students
can find it and apply).

What do you think?

Salam-Shalom-Peace,
Dashamir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20160215/2d97d82e/attachment.html>

From justus at g10code.com  Mon Feb 15 12:50:41 2016
From: justus at g10code.com (Justus Winter)
Date: Mon, 15 Feb 2016 12:50:41 +0100
Subject: Automated testing with Sharness
In-Reply-To: <CAMucfLwu1v_SEfZsJSHhN0vGK5E+D-Sg2cgr7XCp62te+S4QMg@mail.gmail.com>
References: <CAMucfLwu1v_SEfZsJSHhN0vGK5E+D-Sg2cgr7XCp62te+S4QMg@mail.gmail.com>
Message-ID: <20160215115041.29991.91725@thinkbox.jade-hamburg.de>

Hi,

Quoting Dashamir Hoxha (2016-02-15 08:34:34)
> They are based on Sharness:
>  - https://github.com/mlafeldt/sharness
> which is derived from the testing framework of Git:
>  - https://github.com/git/git/blob/master/t/README
> 
> I wonder whether it would be interesting to use Sharness
> for writting testing scripts for GnuPG as well.

We are in the process of replacing our test suite.  One important
motivation for that switch is that we need to run the tests on systems
that have no Bourne shell.  Sharness wouldn't solve that.

You can find our prototype in the branch 'justus/scm-6'.

Cheers,
Justus


From dashohoxha at gmail.com  Mon Feb 15 13:53:37 2016
From: dashohoxha at gmail.com (Dashamir Hoxha)
Date: Mon, 15 Feb 2016 13:53:37 +0100
Subject: Automated testing with Sharness
In-Reply-To: <20160215115041.29991.91725@thinkbox.jade-hamburg.de>
References: <CAMucfLwu1v_SEfZsJSHhN0vGK5E+D-Sg2cgr7XCp62te+S4QMg@mail.gmail.com>
 <20160215115041.29991.91725@thinkbox.jade-hamburg.de>
Message-ID: <CAMucfLypXAd4cNiG3CP58pfNpJ=ghCYDkWQMdGBmATa3Y=RKTQ@mail.gmail.com>

On Mon, Feb 15, 2016 at 12:50 PM, Justus Winter <justus at g10code.com> wrote:
>
> We are in the process of replacing our test suite.  One important
> motivation for that switch is that we need to run the tests on systems
> that have no Bourne shell.  Sharness wouldn't solve that.
>
> You can find our prototype in the branch 'justus/scm-6'.
>

Ok. You can try to involve any students on the new test suit,
unless it is almost finished.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20160215/33faaf85/attachment.html>

From marcel.tunnissen at axis.com  Mon Feb 15 14:47:58 2016
From: marcel.tunnissen at axis.com (=?UTF-8?Q?Marcel_T=c3=bcnnissen?=)
Date: Mon, 15 Feb 2016 14:47:58 +0100
Subject: libgpg-error: generated two new syscfg files for Axis cameras
In-Reply-To: <56BB2C04.9080607@axis.com>
References: <56BB2C04.9080607@axis.com>
Message-ID: <56C1D70E.1060805@axis.com>

Hi,

I upgraded libgpg-error for Axis cameras and I was forced to create two
new syscfg files that could be added to the lib. I attached the files in
a tgz file with content:

src/syscfg/lock-obj-pub.arm-axis-linux-gnueabi.h
src/syscfg/lock-obj-pub.mipsisa32r2el-axis-linux-gnu.h

Note that neither of the two files contain anything new, really. Both
the ARM and the MIPS file have the same content as another ARM or MIPS file.

Best regards,
Marcel
-- 
Marcel T?nnissen,
M.Sc. Computer Science
Axis Communications AB
Emdalav?gen 14, SE-223 69 LUND, SWEDEN
Phone: +46 (0)46 272 2448
       +46 (0)729 890 369
Email: marcel.tunnissen at axis.com,
WWW: http://www.axis.com



-------------- next part --------------
A non-text attachment was scrubbed...
Name: axis-syscfg.tgz
Type: application/x-compressed-tar
Size: 478 bytes
Desc: not available
URL: </pipermail/attachments/20160215/b20e9825/attachment.bin>

From dkg at fifthhorseman.net  Tue Feb 16 10:33:05 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 16 Feb 2016 04:33:05 -0500
Subject: does gpgv.exe need to depend on gpgconf?
Message-ID: <877fi5j8z2.fsf@alice.fifthhorseman.net>

i'm trying to build gpgv from 2.1.x for windows as a standalone,
statically-linked artifact.

when running it with the expected arguments to verify a file, i see:

 gpgv: required binary 'C:\Users\dkg\Downloads\gpgconfig.exe` is not installed

and i get no valid response.

This appears to come from common/homedir.c, and is only on the win32
platform.

Is this intentional?  It seems like a shame to need gpgconf.exe just to
be able to run gpgv.exe, which can often be run explicitly without a
homedir.

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

From justus at g10code.com  Tue Feb 16 10:38:17 2016
From: justus at g10code.com (Justus Winter)
Date: Tue, 16 Feb 2016 10:38:17 +0100
Subject: libgpg-error: generated two new syscfg files for Axis cameras
In-Reply-To: <56C1D70E.1060805@axis.com>
References: <56BB2C04.9080607@axis.com> <56C1D70E.1060805@axis.com>
Message-ID: <20160216093817.20726.70844@thinkbox.jade-hamburg.de>

Hello Marcel,

Quoting Marcel T?nnissen (2016-02-15 14:47:58)
> I upgraded libgpg-error for Axis cameras and I was forced to create two
> new syscfg files that could be added to the lib. I attached the files in
> a tgz file [..]

Your company produces surveillance equipment ("Cameras with ears") and
advertises them as suitable for round-the-clock surveillance at
schools and universities in the name of security.

Your contribution fosters compatibility with surveillance equipment
that makes this world a worse place.  So NACK.

Regards,
Justus


From dkg at fifthhorseman.net  Tue Feb 16 10:40:39 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 16 Feb 2016 04:40:39 -0500
Subject: finding libiconv during static builds for windows
Message-ID: <8760xpj8mg.fsf@alice.fifthhorseman.net>

When trying to build statically-linked executables for Windows, the
./configure script appears to prefer to find libiconv.dll.a instead of
libiconv.a.

checking if the linker (/usr/bin/i686-w64-mingw32-ld) is GNU ld... yes
checking for shared library run path origin... done
checking for iconv... yes
checking for working iconv... guessing yes
checking how to link with libiconv... /usr/i686-w64-mingw32/lib/libiconv.dll.a -L/usr/i686-w64-mingw32/lib
checking for iconv declaration... 
         extern size_t iconv (iconv_t cd, const char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft);
configure: checking for gettext


the result of this is that a statically-linked executable isn't fully
statically-linked -- it still needs iconv.dll to be shipped alongside
it.

i'm supplying ./configure --with-libiconv-prefix=/usr/i686-w64-mingw32
as expected, and /usr/i686-w64-mingw32/lib/libiconv.a is definitely
present in the filesystem when ./configure is run.

i'm not sure how to convince ./configure that the correct flags are
-liconv -L/usr/i686-w64-mingw32/lib instead of the explicit path to the
libiconv.dll.a file.  Any pointers to the right place for this sort of
documentation?

        --dkg

PS i'm doing this build with win-iconv, fwiw.  I haven't tried it with
GNU iconv.


From astieger at suse.com  Tue Feb 16 11:25:01 2016
From: astieger at suse.com (Andreas Stieger)
Date: Tue, 16 Feb 2016 11:25:01 +0100
Subject: libgpg-error: generated two new syscfg files for Axis cameras
In-Reply-To: <20160216093817.20726.70844@thinkbox.jade-hamburg.de>
References: <56BB2C04.9080607@axis.com> <56C1D70E.1060805@axis.com>
 <20160216093817.20726.70844@thinkbox.jade-hamburg.de>
Message-ID: <56C2F8FD.1070303@suse.com>

Hello,

On 02/16/2016 10:38 AM, Justus Winter wrote:
> Quoting Marcel T?nnissen (2016-02-15 14:47:58)
>> I upgraded libgpg-error for Axis cameras and I was forced to create two
>> new syscfg files that could be added to the lib. I attached the files in
>> a tgz file [..]
> 
> Your company produces surveillance equipment ("Cameras with ears") and
> advertises them as suitable for round-the-clock surveillance at
> schools and universities in the name of security.
> 
> Your contribution fosters compatibility with surveillance equipment
> that makes this world a worse place.  So NACK.

Whatever happened to disagreeing with someone while still using their
code, based on technical merit? I am not sure if you'd want to argue
with the intent or practical use a particular technology, while at the
same cryptography is being discredited on the ground of being used for
dis-likable activities, with an outlook to establishing investigative
powers, restrictions of use or mandated back-doors?

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)

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

From justus at g10code.com  Tue Feb 16 14:35:53 2016
From: justus at g10code.com (Justus Winter)
Date: Tue, 16 Feb 2016 14:35:53 +0100
Subject: libgpg-error: generated two new syscfg files for Axis cameras
In-Reply-To: <56C2F8FD.1070303@suse.com>
References: <56BB2C04.9080607@axis.com> <56C1D70E.1060805@axis.com>
 <20160216093817.20726.70844@thinkbox.jade-hamburg.de>
 <56C2F8FD.1070303@suse.com>
Message-ID: <20160216133553.20726.5656@thinkbox.jade-hamburg.de>

Hi,

Quoting Andreas Stieger (2016-02-16 11:25:01)
> On 02/16/2016 10:38 AM, Justus Winter wrote:
> > Quoting Marcel T?nnissen (2016-02-15 14:47:58)
> >> I upgraded libgpg-error for Axis cameras and I was forced to create two
> >> new syscfg files that could be added to the lib. I attached the files in
> >> a tgz file [..]
> > 
> > Your company produces surveillance equipment ("Cameras with ears") and
> > advertises them as suitable for round-the-clock surveillance at
> > schools and universities in the name of security.
> > 
> > Your contribution fosters compatibility with surveillance equipment
> > that makes this world a worse place.  So NACK.
> 
> Whatever happened to disagreeing with someone while still using their
> code, based on technical merit?

Nothing.  They are free to use the code however they want, provided
they are in compliance with the license and local laws.

Justus


From rjh at sixdemonbag.org  Tue Feb 16 13:36:45 2016
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Tue, 16 Feb 2016 07:36:45 -0500
Subject: libgpg-error: generated two new syscfg files for Axis cameras
In-Reply-To: <56C2F8FD.1070303@suse.com>
References: <56BB2C04.9080607@axis.com> <56C1D70E.1060805@axis.com>
 <20160216093817.20726.70844@thinkbox.jade-hamburg.de>
 <56C2F8FD.1070303@suse.com>
Message-ID: <56C317DD.1080603@sixdemonbag.org>

> Whatever happened to disagreeing with someone while still using their
> code, based on technical merit?

This.  In my day job I pull AES256 keys out of memory images to attack
ciphertext and recover traffic.  Some people here would think that's
kind of sketchy in that I'm helping to subvert crypto.  Some people
would be really happy that I'm helping the authorities put together
evidence against child pornographers.

Everything in this space is dual-use.  Yes, 24x7 surveillance can be
used by universities like Cornell to create a surveillance state.  But
it can also be used to keep the plutonium in Cornell's radioisotope lab
secure from theft.



From wk at gnupg.org  Tue Feb 16 14:17:08 2016
From: wk at gnupg.org (Werner Koch)
Date: Tue, 16 Feb 2016 14:17:08 +0100
Subject: does gpgv.exe need to depend on gpgconf?
In-Reply-To: <877fi5j8z2.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Tue, 16 Feb 2016 04:33:05 -0500")
References: <877fi5j8z2.fsf@alice.fifthhorseman.net>
Message-ID: <87y4akg5gr.fsf@wheatstone.g10code.de>

On Tue, 16 Feb 2016 10:33, dkg at fifthhorseman.net said:

> Is this intentional?  It seems like a shame to need gpgconf.exe just to

No.  We can relax this requirement for gpgv.  It is only for Windows
because we use gpgconf to test for a portable application.  gpgconf is
used because it guarantees that a full gpg installation is there.

The easiest fix would be to remove

  fname = xstrconcat (dir, DIRSEP_S "gpgconf.exe", NULL);
  if (access (fname, F_OK))
    log_error ("required binary '%s' is not installed\n", fname);
  else
    {
      strcpy (fname + strlen (fname) - 3, "ctl");
      if (!access (fname, F_OK))
        {
          /* gpgconf.ctl file found.  Record this fact.  */
          w32_portable_app = 1;

the error message.  It was useful during development but I think we can
do just fine without it.


Salam-Shalom,

   Werner

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



From wk at gnupg.org  Tue Feb 16 17:42:42 2016
From: wk at gnupg.org (Werner Koch)
Date: Tue, 16 Feb 2016 17:42:42 +0100
Subject: does gpgv.exe need to depend on gpgconf?
In-Reply-To: <87y4akg5gr.fsf@wheatstone.g10code.de> (Werner Koch's message of
 "Tue, 16 Feb 2016 14:17:08 +0100")
References: <877fi5j8z2.fsf@alice.fifthhorseman.net>
 <87y4akg5gr.fsf@wheatstone.g10code.de>
Message-ID: <87mvr0fvy5.fsf@wheatstone.g10code.de>

On Tue, 16 Feb 2016 14:17, wk at gnupg.org said:

> the error message.  It was useful during development but I think we can
> do just fine without it.

I pushed a fix to remove the error message.


Salam-Shalom,

   Werner

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



From ueno at gnu.org  Thu Feb 18 04:33:42 2016
From: ueno at gnu.org (Daiki Ueno)
Date: Thu, 18 Feb 2016 12:33:42 +0900
Subject: status of S/MIME and interoperability?
In-Reply-To: <m3oaby9mcb.fsf-ueno@gnu.org> (Daiki Ueno's message of "Wed, 03
 Feb 2016 18:25:56 +0900")
References: <rmih9hvx4jq.fsf@fnord.ir.bbn.com>
 <87vb68j3et.fsf@vigenere.g10code.de> <m3a8njzcna.fsf-ueno@gnu.org>
 <56B0DFBB.3040607@gmx.com> <56B0E053.6080309@gmx.com>
 <m3oaby9mcb.fsf-ueno@gnu.org>
Message-ID: <m360xmpua9.fsf-ueno-ueno-ueno@gnu.org>

Daiki Ueno <ueno at gnu.org> writes:

> Ed Finnerty <edfinnerty at gmx.com> writes:
>
>>> I've actually logged the problem here and even attached a script that
>>> easily tests for the issue and can be modified to produce trivial test
>>> output for comparison purposes.
>>> 
>>> Nobody seemed to really care. So if you do S/MIME with GPG, and use
>>> Thunderbird, every once in a while you'll get an undecryptable message
>>> that you have to save to disk and try to deal with in some way with GPG.
>>
>> Of course, I forgot to add the link:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=990958
>
> Although I am not sure if this is related to the original issue of this
> thread, I have the same impression that this is an NSS bug.

Actually, reading the CMS specification more closely, my initial
impression seems wrong, and this looks really like an issue in gpgsm
(actually in libksba, see below).

> In my test, it happens only when the encrypted session key is shorter
> than 256 bytes.  However, I don't see any problem in the CMS data which
> gpgsm produced.

When rsaEncryption is used, the length of the encrypted session key
should never change, as long as the same key is used.

The rationale is:

- The section 4.2 of RFC3370 states:

   The RSA key transport algorithm is the RSA encryption scheme defined
   in RFC 2313 [PKCS#1], block type is 02, where the message to be
   encrypted is the content-encryption key.

  ...

   Note that the same RSA encryption scheme is also defined in RFC 2437
   [NEWPKCS#1].  Within RFC 2437, this RSA encryption scheme is called
   RSAES-PKCS1-v1_5.
  
- In the section 7.2.1 of RFC2437, the step 4 of RSAES-PKCS1-v1_5 calls
  I2OPS as:

   4. Convert the ciphertext representative c to a ciphertext C of
   length k octets: C = I2OSP (c, k)

  where k is the length in octets of the modulus n

- I2OSP(x,l) adds leading zeros if the length of x in octets is shorter
  than l, as noted in the step 2 of I2OSP
  
In libksba/src/cms.c, ksba_cms_set_enc_val removes the first leading
zero:

  1834    if (n > 1 && !*s)
  1835      { /* We might have a leading zero due to the way we encode
  1836           MPIs - this zero should not go into the OCTECT STRING.  */
  1837        s++;
  1838        n--;
  1839      }

I think this should be bypassed, at least when rsaEncryption is used.
With the attached patch, I could no longer reproduce the issue with the
provided test_nss.sh script (with ~1000 iterations).

Regards,
-- 
Daiki Ueno
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Preserve-leading-zero-resulting-from-PKCS-1-scheme.patch
Type: text/x-patch
Size: 3064 bytes
Desc: not available
URL: </pipermail/attachments/20160218/576555c8/attachment.bin>

From ueno at gnu.org  Thu Feb 18 08:21:21 2016
From: ueno at gnu.org (Daiki Ueno)
Date: Thu, 18 Feb 2016 16:21:21 +0900
Subject: [PATCH pinentry] emacs: Forward PINENTRY_USER_DATA
Message-ID: <1455780081-18428-1-git-send-email-ueno@gnu.org>

* pinentry/pinentry-emacs.c (set_label): Add missing 'static'.
(pinentry_emacs_init): If PINENTRY_USER_DATA envvar is set, send it to
Emacs upon connection.  This is useful to pass around context
information, such as a file name or buffer, for instance.

Signed-off-by: Daiki Ueno <ueno at gnu.org>
---
 pinentry/pinentry-emacs.c | 26 +++++++++++++++++++++++++-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/pinentry/pinentry-emacs.c b/pinentry/pinentry-emacs.c
index 9ced8da..53c779b 100644
--- a/pinentry/pinentry-emacs.c
+++ b/pinentry/pinentry-emacs.c
@@ -438,7 +438,7 @@ read_from_emacs (int s, int timeout, char *buffer, size_t capacity)
   return result;
 }
 
-int
+static int
 set_label (pinentry_t pe, const char *name, const char *value)
 {
   char buffer[16], *escaped;
@@ -675,6 +675,7 @@ pinentry_emacs_init (void)
 {
   char buffer[256];
   gpg_error_t error;
+  const char *envvar;
 
   assert (emacs_socket < 0);
 
@@ -691,5 +692,28 @@ pinentry_emacs_init (void)
       emacs_socket = -1;
       return 0;
     }
+
+  /* If PINENTRY_USER_DATA envvar is set, send it to the server.  */
+  envvar = getenv ("PINENTRY_USER_DATA");
+  if (envvar && *envvar)
+    {
+      char *escaped = escape (envvar);
+
+      if (!escaped
+	  || !send_to_emacs (emacs_socket, "OPTION")
+	  || !send_to_emacs (emacs_socket, " ")
+	  || !send_to_emacs (emacs_socket, "pinentry-user-data=")
+	  || !send_to_emacs (emacs_socket, escaped)
+	  || !send_to_emacs (emacs_socket, "\n"))
+	{
+	  free (escaped);
+	  close (emacs_socket);
+	  emacs_socket = -1;
+	  return 0;
+	}
+
+      free (escaped);
+    }
+
   return 1;
 }
-- 
2.5.0



From wk at gnupg.org  Thu Feb 18 12:17:34 2016
From: wk at gnupg.org (Werner Koch)
Date: Thu, 18 Feb 2016 12:17:34 +0100
Subject: [PATCH] allow weirdly-mixed pkcs7 signatures
In-Reply-To: <1454964247-19930-1-git-send-email-dkg@fifthhorseman.net> (Daniel
 Kahn Gillmor's message of "Mon, 8 Feb 2016 15:44:07 -0500")
References: <1454964247-19930-1-git-send-email-dkg@fifthhorseman.net>
Message-ID: <87lh6ib73l.fsf@wheatstone.g10code.de>

Hi!

Thanks for the patch.  Please remember the next time to add a
Signed-off-line.


Salam-Shalom,

   Werner

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



From edfinnerty at gmx.com  Thu Feb 18 13:13:17 2016
From: edfinnerty at gmx.com (Ed Finnerty)
Date: Thu, 18 Feb 2016 14:13:17 +0200
Subject: status of S/MIME and interoperability?
In-Reply-To: <m360xmpua9.fsf-ueno-ueno-ueno@gnu.org>
References: <rmih9hvx4jq.fsf@fnord.ir.bbn.com>
 <87vb68j3et.fsf@vigenere.g10code.de> <m3a8njzcna.fsf-ueno@gnu.org>
 <56B0DFBB.3040607@gmx.com> <56B0E053.6080309@gmx.com>
 <m3oaby9mcb.fsf-ueno@gnu.org> <m360xmpua9.fsf-ueno-ueno-ueno@gnu.org>
Message-ID: <56C5B55D.60403@gmx.com>

On 02/18/2016 05:33 AM, Daiki Ueno wrote:
> Daiki Ueno <ueno at gnu.org> writes:
> 
>> Ed Finnerty <edfinnerty at gmx.com> writes:
>>
>>>> I've actually logged the problem here and even attached a script that
>>>> easily tests for the issue and can be modified to produce trivial test
>>>> output for comparison purposes.
>>>>
>>>> Nobody seemed to really care. So if you do S/MIME with GPG, and use
>>>> Thunderbird, every once in a while you'll get an undecryptable message
>>>> that you have to save to disk and try to deal with in some way with GPG.
>>>
>>> Of course, I forgot to add the link:
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=990958
>>
>> Although I am not sure if this is related to the original issue of this
>> thread, I have the same impression that this is an NSS bug.
> 
> Actually, reading the CMS specification more closely, my initial
> impression seems wrong, and this looks really like an issue in gpgsm
> (actually in libksba, see below).
> 
>> In my test, it happens only when the encrypted session key is shorter
>> than 256 bytes.  However, I don't see any problem in the CMS data which
>> gpgsm produced.
> 
> When rsaEncryption is used, the length of the encrypted session key
> should never change, as long as the same key is used.
> 
> The rationale is:
> 
> - The section 4.2 of RFC3370 states:
> 
>    The RSA key transport algorithm is the RSA encryption scheme defined
>    in RFC 2313 [PKCS#1], block type is 02, where the message to be
>    encrypted is the content-encryption key.
> 
>   ...
> 
>    Note that the same RSA encryption scheme is also defined in RFC 2437
>    [NEWPKCS#1].  Within RFC 2437, this RSA encryption scheme is called
>    RSAES-PKCS1-v1_5.
>   
> - In the section 7.2.1 of RFC2437, the step 4 of RSAES-PKCS1-v1_5 calls
>   I2OPS as:
> 
>    4. Convert the ciphertext representative c to a ciphertext C of
>    length k octets: C = I2OSP (c, k)
> 
>   where k is the length in octets of the modulus n
> 
> - I2OSP(x,l) adds leading zeros if the length of x in octets is shorter
>   than l, as noted in the step 2 of I2OSP
>   
> In libksba/src/cms.c, ksba_cms_set_enc_val removes the first leading
> zero:
> 
>   1834    if (n > 1 && !*s)
>   1835      { /* We might have a leading zero due to the way we encode
>   1836           MPIs - this zero should not go into the OCTECT STRING.  */
>   1837        s++;
>   1838        n--;
>   1839      }
> 
> I think this should be bypassed, at least when rsaEncryption is used.
> With the attached patch, I could no longer reproduce the issue with the
> provided test_nss.sh script (with ~1000 iterations).

Thanks! Hopefully this patch will make it into GPG.



From phoenyx33 at gmail.com  Thu Feb 18 18:51:18 2016
From: phoenyx33 at gmail.com (Kenneth Benson)
Date: Thu, 18 Feb 2016 12:51:18 -0500
Subject: new RFC 7748
Message-ID: <CACGLP4NugsytGfPK8neJGhEP24mPh2xw2wHEbZEdgyquqgdLiA@mail.gmail.com>

I don't know how often anyone checks the RFC's, so I thought I'd mention
this one. Titled "Elliptic Curves for Security", it's an informational RFC
that's very interesting. It refers to Curves 25519 and 448 and their
Edwards versions and includes Python code for implementing Scalars
(including test vectors) along with a discussion on usage of the code in
implementing ECDH. Released late last month as far as I can tell. Would
this help with EC implementation in GPG?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20160218/17d8fd55/attachment.html>

From wk at gnupg.org  Thu Feb 18 20:47:32 2016
From: wk at gnupg.org (Werner Koch)
Date: Thu, 18 Feb 2016 20:47:32 +0100
Subject: new RFC 7748
In-Reply-To: <CACGLP4NugsytGfPK8neJGhEP24mPh2xw2wHEbZEdgyquqgdLiA@mail.gmail.com>
 (Kenneth Benson's message of "Thu, 18 Feb 2016 12:51:18 -0500")
References: <CACGLP4NugsytGfPK8neJGhEP24mPh2xw2wHEbZEdgyquqgdLiA@mail.gmail.com>
Message-ID: <8760xlby23.fsf@wheatstone.g10code.de>

On Thu, 18 Feb 2016 18:51, phoenyx33 at gmail.com said:

> implementing ECDH. Released late last month as far as I can tell. Would
> this help with EC implementation in GPG?

We already have a complete implementations.  That RFC is useful for
reference so that an RFC describing a protocol does not need to refer to
an external specification.

Thanks for telling.


Shalom-Salam,

   Werner

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



From wk at gnupg.org  Tue Feb 23 15:57:47 2016
From: wk at gnupg.org (Werner Koch)
Date: Tue, 23 Feb 2016 15:57:47 +0100
Subject: g13 with DM-Crypt and suspend/remove
Message-ID: <87oab75v9w.fsf@wheatstone.g10code.de>

Hi!

I am now using a the g13 tool to encrypt my Maildir partition.  There is
not much documentation right now except for some comments in commit
messages.  To make this actual useful I also implemented suspend/remove
to avoid unmounting the partition before hibernating.  The commit
f7968db describes how this can be done. 

Just in case you like the high risk of losing all your data and actually
want to play with the new g13 code, you also need a patch for dmsetup
which I attach.  Ask here if you have any questions.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-dmsetup-command-message-may-now-read-the-message-fro.patch
Type: text/x-diff
Size: 4737 bytes
Desc: not available
URL: </pipermail/attachments/20160223/c2b8b369/attachment-0001.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 180 bytes
Desc: not available
URL: </pipermail/attachments/20160223/c2b8b369/attachment-0001.sig>

From wk at gnupg.org  Tue Feb 23 16:24:45 2016
From: wk at gnupg.org (Werner Koch)
Date: Tue, 23 Feb 2016 16:24:45 +0100
Subject: Moving the agent's socket to /var/run ?
Message-ID: <87k2lv5u0y.fsf@wheatstone.g10code.de>

Hi!

GnuPG 2.x makes extensive use of Unix domain sockets for interprocess
communication.  For example gpg-agent is listenening for requests from
gpg or gpgsm on the socket ~/.gnupg/S.gpg-agent .  We have received a
couple of reports from folks who have to install GnuPG in GnuPG home
directory with a long file name.  This does not work well with sockets
which usually have a limit on the length of their name.  The workaround
for this is to use the re-direction file kludge to tell the client that
the actual socket is at some other place.  That require manual
configuration, though.

I am also not sure whether there are really default GnuPG home
directories which suffer from the problem.  That is a $HOME which is
longer than about 75 bytes.

Another problem with having the socket in the home directory are
encrypted home partition.  gpg-agent, scdaemon, and dirmngr have by
default an open socket in ~/.gnupg and thus unmounting the partition is
not possible without killing those processes.

What about changing the _default_ name for the sockets from, say,
~/.gnupg/S.gpg-agent to /var/run/user/<uid>/S.gpg-agent ?  This is
similar to what system daemons use for their socket names and has the
further advantage that /var/run is always locally mounted and would thus
avoid the re-direction file hack used for NFS etc.  This would only be
done if GNUPGHOME/--homedir is not set so that it is still possible to
run a second instance of gnupg.

What do you think?


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: 180 bytes
Desc: not available
URL: </pipermail/attachments/20160223/ad217c59/attachment.sig>

From neal at walfield.org  Tue Feb 23 16:33:29 2016
From: neal at walfield.org (Neal H. Walfield)
Date: Tue, 23 Feb 2016 16:33:29 +0100
Subject: Moving the agent's socket to /var/run ?
In-Reply-To: <87k2lv5u0y.fsf@wheatstone.g10code.de>
References: <87k2lv5u0y.fsf@wheatstone.g10code.de>
Message-ID: <87bn77a1bq.wl-neal@walfield.org>

On Tue, 23 Feb 2016 16:24:45 +0100,
Werner Koch wrote:
> What about changing the _default_ name for the sockets from, say,
> ~/.gnupg/S.gpg-agent to /var/run/user/<uid>/S.gpg-agent ?  This is
> similar to what system daemons use for their socket names and has the
> further advantage that /var/run is always locally mounted and would thus
> avoid the re-direction file hack used for NFS etc.  This would only be
> done if GNUPGHOME/--homedir is not set so that it is still possible to
> run a second instance of gnupg.

Why not use something like:

  /var/run/user/<uid>/S.gpg-agent-hash

where hash is the hash of GNUPGHOME?

:) Neal


From dgouttegattat at incenp.org  Tue Feb 23 16:54:18 2016
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Tue, 23 Feb 2016 16:54:18 +0100
Subject: Moving the agent's socket to /var/run ?
In-Reply-To: <87k2lv5u0y.fsf@wheatstone.g10code.de>
References: <87k2lv5u0y.fsf@wheatstone.g10code.de>
Message-ID: <56CC80AA.7020901@incenp.org>

On 02/23/2016 04:24 PM, Werner Koch wrote:
> What about changing the _default_ name for the sockets from, say,
> ~/.gnupg/S.gpg-agent to /var/run/user/<uid>/S.gpg-agent ?

May I suggest that instead of hardcoding /var/run/..., we honor the 
XDG_RUNTIME_DIR variable (from the XDG Base Directory Specification [1]) 
if it is set?

It seems specifically designed for that usage:

   $XDG_RUNTIME_DIR defines the base directory relative to which
   user-specific non-essential runtime files and other file objects
   (such as sockets, named pipes, ...) should be stored.


Damien

[1] 
https://specifications.freedesktop.org/basedir-spec/basedir-spec-0.8.html

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

From wk at gnupg.org  Tue Feb 23 19:29:39 2016
From: wk at gnupg.org (Werner Koch)
Date: Tue, 23 Feb 2016 19:29:39 +0100
Subject: Moving the agent's socket to /var/run ?
In-Reply-To: <87bn77a1bq.wl-neal@walfield.org> (Neal H. Walfield's message of
 "Tue, 23 Feb 2016 16:33:29 +0100")
References: <87k2lv5u0y.fsf@wheatstone.g10code.de>
 <87bn77a1bq.wl-neal@walfield.org>
Message-ID: <871t835lgs.fsf@wheatstone.g10code.de>

On Tue, 23 Feb 2016 16:33, neal at walfield.org said:

>   /var/run/user/<uid>/S.gpg-agent-hash
>
> where hash is the hash of GNUPGHOME?

Clever idea.  Do we need to truncate the hash?

/var/run/user/65535/S.gpg-agent-823125cb68e88fabb56828d6a090df0211228809

would be short enough but I doubt we need 160 bit to differentiate
between one users gnupg home directories.


Shalom-Salam,

   Werner

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



From wk at gnupg.org  Tue Feb 23 19:25:39 2016
From: wk at gnupg.org (Werner Koch)
Date: Tue, 23 Feb 2016 19:25:39 +0100
Subject: Moving the agent's socket to /var/run ?
In-Reply-To: <56CC80AA.7020901@incenp.org> (Damien Goutte-Gattat's message of
 "Tue, 23 Feb 2016 16:54:18 +0100")
References: <87k2lv5u0y.fsf@wheatstone.g10code.de>
 <56CC80AA.7020901@incenp.org>
Message-ID: <8760xf5lng.fsf@wheatstone.g10code.de>

On Tue, 23 Feb 2016 16:54, dgouttegattat at incenp.org said:

> May I suggest that instead of hardcoding /var/run/..., we honor the
> XDG_RUNTIME_DIR variable (from the XDG Base Directory Specification
> [1]) if it is set?

Sure, that can be done in this case because there won't be any need for
backward compatibility.  What do you think in general about such a
change?


Salam-Shalom,

   Werner

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



From neal at walfield.org  Tue Feb 23 20:19:18 2016
From: neal at walfield.org (Neal H. Walfield)
Date: Tue, 23 Feb 2016 20:19:18 +0100
Subject: Moving the agent's socket to /var/run ?
In-Reply-To: <871t835lgs.fsf@wheatstone.g10code.de>
References: <87k2lv5u0y.fsf@wheatstone.g10code.de>
 <87bn77a1bq.wl-neal@walfield.org>
 <871t835lgs.fsf@wheatstone.g10code.de>
Message-ID: <878u2b9qvd.wl-neal@walfield.org>

On Tue, 23 Feb 2016 19:29:39 +0100,
Werner Koch wrote:
> On Tue, 23 Feb 2016 16:33, neal at walfield.org said:
> 
> >   /var/run/user/<uid>/S.gpg-agent-hash
> >
> > where hash is the hash of GNUPGHOME?
> 
> Clever idea.  Do we need to truncate the hash?
> 
> /var/run/user/65535/S.gpg-agent-823125cb68e88fabb56828d6a090df0211228809
> 
> would be short enough but I doubt we need 160 bit to differentiate
> between one users gnupg home directories.

I suspect that 32 bits would be sufficient and 64 bits are definately
more than enough.  The only adversary in this scenario is the birthday
paradox.

:) Neal


From ametzler at bebt.de  Tue Feb 23 19:50:10 2016
From: ametzler at bebt.de (Andreas Metzler)
Date: Tue, 23 Feb 2016 19:50:10 +0100
Subject: Moving the agent's socket to /var/run ?
References: <87k2lv5u0y.fsf@wheatstone.g10code.de>
Message-ID: <08mupc-otk.ln1@argenau.bebt.de>

Werner Koch <wk at gnupg.org> wrote:
[...]
> GnuPG 2.x makes extensive use of Unix domain sockets for interprocess
> communication.  For example gpg-agent is listenening for requests from
> gpg or gpgsm on the socket ~/.gnupg/S.gpg-agent .  We have received a
> couple of reports from folks who have to install GnuPG in GnuPG home
> directory with a long file name.  This does not work well with sockets
> which usually have a limit on the length of their name.  The workaround
[...]
> What about changing the _default_ name for the sockets from, say,
> ~/.gnupg/S.gpg-agent to /var/run/user/<uid>/S.gpg-agent ?  This is
> similar to what system daemons use for their socket names and has the
> further advantage that /var/run is always locally mounted and would thus
> avoid the re-direction file hack used for NFS etc.  This would only be
> done if GNUPGHOME/--homedir is not set so that it is still possible to
> run a second instance of gnupg.
[...]

Hello,

/var/run typically is a symlink to /run. Are per-user
subdirectories of /run common practise on other ditributions nowadays?
(I only know that Debian does not have them.) Having a default that
would not work for most of the users is probably not desirable.

You could use (a subdirectory of) /tmp.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'



From neal at walfield.org  Tue Feb 23 21:09:13 2016
From: neal at walfield.org (Neal H. Walfield)
Date: Tue, 23 Feb 2016 21:09:13 +0100
Subject: Moving the agent's socket to /var/run ?
In-Reply-To: <08mupc-otk.ln1@argenau.bebt.de>
References: <87k2lv5u0y.fsf@wheatstone.g10code.de>
 <08mupc-otk.ln1@argenau.bebt.de>
Message-ID: <877fhv9ok6.wl-neal@walfield.org>

On Tue, 23 Feb 2016 19:50:10 +0100,
Andreas Metzler wrote:
> /var/run typically is a symlink to /run. Are per-user
> subdirectories of /run common practise on other ditributions nowadays?
> (I only know that Debian does not have them.) Having a default that
> would not work for most of the users is probably not desirable.

I think Debian has them.  At least my install has them and I didn't do
anything special.

Thanks,

:) Neal


From wk at gnupg.org  Tue Feb 23 21:21:33 2016
From: wk at gnupg.org (Werner Koch)
Date: Tue, 23 Feb 2016 21:21:33 +0100
Subject: Moving the agent's socket to /var/run ?
In-Reply-To: <08mupc-otk.ln1@argenau.bebt.de> (Andreas Metzler's message of
 "Tue, 23 Feb 2016 19:50:10 +0100")
References: <87k2lv5u0y.fsf@wheatstone.g10code.de>
 <08mupc-otk.ln1@argenau.bebt.de>
Message-ID: <87vb5f41pu.fsf@wheatstone.g10code.de>

On Tue, 23 Feb 2016 19:50, ametzler at bebt.de said:

> /var/run typically is a symlink to /run. Are per-user

Yes on mopdern platforms.  I am not sure whether this is the case for
AIX.  Actually, I was asking myself whether to write /run for please the
young hackers and Gnus but the  wrote /var/run becuase that is more
common to me.  In any case, using XDG specs make a lot of sense.

> subdirectories of /run common practise on other ditributions nowadays?

No idea.  I ddged that this is sometimes used for databases and such on
Ubuntu.

> (I only know that Debian does not have them.) Having a default that
> would not work for most of the users is probably not desirable.

Why should that not work for all users?  It is just a matter of creating
that directory for each user in advance or creating it on demand using a
little userv script.


Salam-Shalom,

   Werner

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



From chdiza at gmail.com  Tue Feb 23 23:00:56 2016
From: chdiza at gmail.com (Charles Diza)
Date: Tue, 23 Feb 2016 17:00:56 -0500
Subject: Moving the agent's socket to /var/run ?
In-Reply-To: <87vb5f41pu.fsf@wheatstone.g10code.de>
References: <87k2lv5u0y.fsf@wheatstone.g10code.de>
 <08mupc-otk.ln1@argenau.bebt.de>
 <87vb5f41pu.fsf@wheatstone.g10code.de>
Message-ID: <CADv8sCX5oSkhpn5_Zvs3oU1e6r8fGBk_Mm+u=nNVqC_ZRDa6DA@mail.gmail.com>

On Tue, Feb 23, 2016 at 3:21 PM, Werner Koch <wk at gnupg.org> wrote:

> On Tue, 23 Feb 2016 19:50, ametzler at bebt.de said:
>
> > /var/run typically is a symlink to /run. Are per-user
>
> Yes on mopdern platforms.  I am not sure whether this is the case for
> AIX.  Actually, I was asking myself whether to write /run for please the
> young hackers and Gnus but the  wrote /var/run becuase that is more
> common to me.  In any case, using XDG specs make a lot of sense.
>
> > subdirectories of /run common practise on other ditributions nowadays?
>
> No idea.  I ddged that this is sometimes used for databases and such on
> Ubuntu.
>
> > (I only know that Debian does not have them.) Having a default that
> > would not work for most of the users is probably not desirable.
>
> Why should that not work for all users?  It is just a matter of creating
> that directory for each user in advance or creating it on demand using a
> little userv script.


Mac OS X doesn't have per-user sudirectories of /var/run.  And putting
anything there requires sudo.  Plus, the new SIP "feature" in 10.11 and up
might not let anything go there even with sudo (I can't recall whether
/var/run is one of the exceptions; I disabled SIP long ago).

Also, Mac OS X doesn't have /run, not even as a symlink.

Please be careful with this.  I don't think Mac users should be forced to
set some $XDG_* stuff just to use gpg-agent.

-Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20160223/1d2d509e/attachment-0001.html>

From kristian.fiskerstrand at sumptuouscapital.com  Wed Feb 24 00:13:52 2016
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Wed, 24 Feb 2016 00:13:52 +0100
Subject: Moving the agent's socket to /var/run ?
In-Reply-To: <08mupc-otk.ln1@argenau.bebt.de>
References: <87k2lv5u0y.fsf@wheatstone.g10code.de>
 <08mupc-otk.ln1@argenau.bebt.de>
Message-ID: <56CCE7B0.1000709@sumptuouscapital.com>

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

On 02/23/2016 07:50 PM, Andreas Metzler wrote:
> Werner Koch <wk at gnupg.org> wrote: [...]


..

> 
> /var/run typically is a symlink to /run. Are per-user 
> subdirectories of /run common practise on other ditributions
> nowadays? (I only know that Debian does not have them.) Having a
> default that

Its not common in with per user dir in /run in Gentoo at least (and
indeed, it is a symlink from /var/run to /run)

- -- 
- ----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Public OpenPGP key at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- ----------------------------
Aquila non capit muscas
The eagle does not hunt flies
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJWzOerAAoJECULev7WN52F+1cIAKzau6h+HsJEndV5peldNBM+
7UIwoiYyNzfY3peRXEt4fB4SgDBQLUWxtxirFIO4WP8zu5f7r0GA0KNAWNOPh92A
vK7Jje2cvTPR1uXM7lTUgTI5R9EehFy/Ck+HIL2L8EVuFPvOHexv1Nh2EKrgvXVg
b0ptbHzzAVsVOf3hoYa3y52BZAjPtPwVLdOqgroeRPA6IhII7CaIJfYpJM3cw3F7
4/rBoPwtuh8HEi2Ovefx2iIeQ2J8979Qx4p/A7kaoVUWtr6fprtZFg32UYvvfOkK
lXJIA1gO07peDiPLsK58ursLXv9oyRpM8iPpg8JnXmli7kIbU5IgBGmh65PD95k=
=FuVl
-----END PGP SIGNATURE-----


From bertrand at jacquin.bzh  Wed Feb 24 00:15:14 2016
From: bertrand at jacquin.bzh (Bertrand Jacquin)
Date: Tue, 23 Feb 2016 23:15:14 +0000
Subject: Moving the agent's socket to /var/run ?
In-Reply-To: <87k2lv5u0y.fsf@wheatstone.g10code.de>
References: <87k2lv5u0y.fsf@wheatstone.g10code.de>
Message-ID: <a604cccc11e05fb5d6f37c4d865450bb@mail.meleeweb.net>

Hi,

What about using abstract sockets ?

These sockets are the same as Unix sockets except that there's no need 
for any filesystem access. The address may be whatever string both sides 
agree upon. This can be really convenient for inter-process 
communications. Also, there is no need to take care about permissions. 
Technically it's like a Unix socket with a zero in the first byte of the 
address.

abstract namespace were introduced with Linux. See man 7 unix.

Cheers,

On 23/02/2016 15:24, Werner Koch wrote:
> Hi!
> 
> GnuPG 2.x makes extensive use of Unix domain sockets for interprocess
> communication.  For example gpg-agent is listenening for requests from
> gpg or gpgsm on the socket ~/.gnupg/S.gpg-agent .  We have received a
> couple of reports from folks who have to install GnuPG in GnuPG home
> directory with a long file name.  This does not work well with sockets
> which usually have a limit on the length of their name.  The workaround
> for this is to use the re-direction file kludge to tell the client that
> the actual socket is at some other place.  That require manual
> configuration, though.
> 
> I am also not sure whether there are really default GnuPG home
> directories which suffer from the problem.  That is a $HOME which is
> longer than about 75 bytes.
> 
> Another problem with having the socket in the home directory are
> encrypted home partition.  gpg-agent, scdaemon, and dirmngr have by
> default an open socket in ~/.gnupg and thus unmounting the partition is
> not possible without killing those processes.
> 
> What about changing the _default_ name for the sockets from, say,
> ~/.gnupg/S.gpg-agent to /var/run/user/<uid>/S.gpg-agent ?  This is
> similar to what system daemons use for their socket names and has the
> further advantage that /var/run is always locally mounted and would 
> thus
> avoid the re-direction file hack used for NFS etc.  This would only be
> done if GNUPGHOME/--homedir is not set so that it is still possible to
> run a second instance of gnupg.
> 
> What do you think?
> 
> 
> Shalom-Salam,
> 
>    Werner
> 
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel

-- 
Bertrand


From gniibe at fsij.org  Wed Feb 24 02:25:31 2016
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 24 Feb 2016 10:25:31 +0900
Subject: stub-key migration from gpg 1.4/2.0 to 2.1
Message-ID: <56CD068B.4090305@fsij.org>

Hello,

While GnuPG 2.1 has g10/migrate.c, it doesn't support migrating
private key stub for smartcard/token.  Last year, I put the
message to the user in g10/import.c:

                  log_info (_("To migrate '%s', with each smartcard, "
                              "run: %s\n"), "secring.gpg", "gpg --card-status");

So that user can notice.  Still, this could be easily ignored.

I'd understand that extending gpg-agent to support importing stub
doesn't sound good.  Even so, I think that it's a developers' view
point.  For users, it's better not to be requested any user
intervention in migration, if possible.

If extending gpg-agent further would not be good, is it OK to offer
some other way to convert stub in secring.gpg to
private-keys-v1.d/*.key?  If violating the roles between gpg-frontend
and gpg-agent is ok for migration process, it will be simple file
format conversion.
-- 


From kristian.fiskerstrand at sumptuouscapital.com  Wed Feb 24 01:42:21 2016
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Wed, 24 Feb 2016 01:42:21 +0100
Subject: Moving the agent's socket to /var/run ?
In-Reply-To: <a604cccc11e05fb5d6f37c4d865450bb@mail.meleeweb.net>
References: <87k2lv5u0y.fsf@wheatstone.g10code.de>
 <a604cccc11e05fb5d6f37c4d865450bb@mail.meleeweb.net>
Message-ID: <56CCFC6D.8060705@sumptuouscapital.com>

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

On 02/24/2016 12:15 AM, Bertrand Jacquin wrote:
> Hi,
> 
> What about using abstract sockets ?
> 
> These sockets are the same as Unix sockets except that there's no
> need for any filesystem access. The address may be whatever string
> both sides agree upon. This can be really convenient for
> inter-process communications. Also, there is no need to take care
> about permissions. Technically it's like a Unix socket with a zero
> in the first byte of the address.
> 
> abstract namespace were introduced with Linux. See man 7 unix.

I'm asking because I'm not familiar with abstract sockets but. Ok, its
implemented in Linux, but is it portable? is it POSIX? How would this
work with socket forwarading over SSH for gpg-agent ?

- -- 
- ----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Public OpenPGP key at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- ----------------------------
Aquila non capit muscas
The eagle does not hunt flies
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJWzPxpAAoJECULev7WN52FCqUH/jqDXDh5OHjOZKutmHeVDvcU
UP5yC7DsZQNAEwz0oiyKbtLWeZjO5AR/khaIKAcMX37EWmEBkweefDk8a5MLDvvo
N4jTSNU6c7IKvK2qQuXg2GlhApawKIre9wWRs/9tWBIJe8enlFhzqf9mCLaZi5RB
FgnXhYEHLKQmPeYMMMvbzG95auWwEv8yM6n4EnklHk0edhJr4BSpSG5uW0LuzRAO
HVKHwI92Yi8N/hDkhgg4vyVbDZpyEzex5FpGEfPAD6LbRJtVx+m0iLUJ6eWerNo9
HxVf3uQ6mftSajKV278brmLToFhhMVNDeOuw/+CgrROnYYNxoUceAfjpYVFihNA=
=s6UU
-----END PGP SIGNATURE-----


From ueno at gnu.org  Wed Feb 24 03:41:48 2016
From: ueno at gnu.org (Daiki Ueno)
Date: Wed, 24 Feb 2016 11:41:48 +0900
Subject: Moving the agent's socket to /var/run ?
In-Reply-To: <56CCFC6D.8060705@sumptuouscapital.com> (Kristian Fiskerstrand's
 message of "Wed, 24 Feb 2016 01:42:21 +0100")
References: <87k2lv5u0y.fsf@wheatstone.g10code.de>
 <a604cccc11e05fb5d6f37c4d865450bb@mail.meleeweb.net>
 <56CCFC6D.8060705@sumptuouscapital.com>
Message-ID: <m3twkyesnn.fsf-ueno@gnu.org>

Kristian Fiskerstrand <kristian.fiskerstrand at sumptuouscapital.com>
writes:

> On 02/24/2016 12:15 AM, Bertrand Jacquin wrote:
>> Hi,
>>
>> What about using abstract sockets ?
>>
>> These sockets are the same as Unix sockets except that there's no
>> need for any filesystem access. The address may be whatever string
>> both sides agree upon. This can be really convenient for
>> inter-process communications. Also, there is no need to take care
>> about permissions. Technically it's like a Unix socket with a zero
>> in the first byte of the address.
>>
>> abstract namespace were introduced with Linux. See man 7 unix.
>
> I'm asking because I'm not familiar with abstract sockets but. Ok, its
> implemented in Linux, but is it portable? is it POSIX? How would this
> work with socket forwarading over SSH for gpg-agent ?

In addition to portability, abstract sockets cannot take advantage of
file system based access control, and require client authentication (I
recall I got a CVE regarding this).  I would rather not mess with it.

Regards,
-- 
Daiki Ueno


From uldis.ansmits at tieto.com  Wed Feb 24 07:39:57 2016
From: uldis.ansmits at tieto.com (=?UTF-8?Q?Uldis_An=C5=A1mits?=)
Date: Wed, 24 Feb 2016 08:39:57 +0200
Subject: Moving the agent's socket to /var/run ?
In-Reply-To: <87k2lv5u0y.fsf@wheatstone.g10code.de>
References: <87k2lv5u0y.fsf@wheatstone.g10code.de>
Message-ID: <CAL=27uSqHZFWv5RzwqNM+yBt8RTBGbc=mh_Z7SJbn1c+Y0BAKg@mail.gmail.com>

> which usually have a limit on the length of their name.  The workaround
> for this is to use the re-direction file kludge to tell the client that
> the actual socket is at some other place.  That require manual
> configuration, though.

I believe, socket redirection is good feature.
Maybe automatic socket redirect to $TMPDIR for long home is acceptable solution.

> What about changing the _default_ name for the sockets from, say,
> ~/.gnupg/S.gpg-agent to /var/run/user/<uid>/S.gpg-agent ?  This is

There is no /var/run/user on AIX or Solaris
Would be nice if GNUPG software can run by user right away without
setup requiring admin access.

Uldis


From wk at gnupg.org  Wed Feb 24 09:08:25 2016
From: wk at gnupg.org (Werner Koch)
Date: Wed, 24 Feb 2016 09:08:25 +0100
Subject: stub-key migration from gpg 1.4/2.0 to 2.1
In-Reply-To: <56CD068B.4090305@fsij.org> (NIIBE Yutaka's message of "Wed, 24
 Feb 2016 10:25:31 +0900")
References: <56CD068B.4090305@fsij.org>
Message-ID: <87wppu34zq.fsf@wheatstone.g10code.de>

On Wed, 24 Feb 2016 02:25, gniibe at fsij.org said:

> I'd understand that extending gpg-agent to support importing stub
> doesn't sound good.  Even so, I think that it's a developers' view
> point.  For users, it's better not to be requested any user

Coincidentally I thought about this yesterday and I am pondering with
the idea of not requiring a stub key at all for a currently inserted
card.  That is actually the same thing we do in command-ssh.c - the
currently inserted card is treated specially by always trying to use it.

Sure this does not help if you need to juggle with a bunch of cards but
the most common case is that there is just one card.

On a somewhat related issue: 

There is the request to handle the case where keys are stored on several
cards which we can't easily solve with the current system at all (or
well, only with a lot of nasty code).  I have two ideas on how to handle
this:

A editable file <keygrip.meta> alongside the <keygrip>.key file to store
additional information like the set of card numbers, a human readable
description of the card or key, flags to replace the use of sshcontrol.

Or the same but but with one file where we change the <keygrip>.key file
to a format like:

  Name: Key used to ssh to Colossus
  Card: D276000124010200FFFE123450000000
        D276000124010200FFFE127890000000
  Ssh: yes
  Key: (private-key 
   (ecc 
   (curve Ed25519)
   (flags eddsa)
   (q #403F098994BDD916ED4053197934E4A87C80733A1280D62F8010992E43EE3B2406#)
   (d #1A8B1FF05DED48E18BF50166C664AB023EA70003D78D9E41F5758A91D850F8D2#)))

Thus instead of using the canonical representation of the S-expression
(binary) as we do right now, we would use the advanced transport
representation which is plain ascii and fits nicely into the RFC-822
like name value format.  The advantage is that a simple text editor can
be used to change the fields.  Detecting the new format would be easy
because the canonical representation always starts with a '('.


Salam-Shalom,

   Werner

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



From patrick at enigmail.net  Wed Feb 24 09:15:22 2016
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Wed, 24 Feb 2016 09:15:22 +0100
Subject: Moving the agent's socket to /var/run ?
In-Reply-To: <87k2lv5u0y.fsf@wheatstone.g10code.de>
References: <87k2lv5u0y.fsf@wheatstone.g10code.de>
Message-ID: <f8cdc226-5c01-e784-7850-35f81a429bf3@enigmail.net>

On 23.02.16 16:24, Werner Koch wrote:
[...]
> What about changing the _default_ name for the sockets from, say,
> ~/.gnupg/S.gpg-agent to /var/run/user/<uid>/S.gpg-agent ?  This is
> similar to what system daemons use for their socket names and has the
> further advantage that /var/run is always locally mounted and would thus
> avoid the re-direction file hack used for NFS etc.  This would only be
> done if GNUPGHOME/--homedir is not set so that it is still possible to
> run a second instance of gnupg.
> 
> What do you think?

Just please make the default path a parameter that can be changed when
running ./configure - some systems like Mac OS X don't have a
/var/run/user/<uid>/ directory.

-Patrick



From kristian.fiskerstrand at sumptuouscapital.com  Wed Feb 24 09:35:23 2016
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Wed, 24 Feb 2016 09:35:23 +0100
Subject: stub-key migration from gpg 1.4/2.0 to 2.1
In-Reply-To: <87wppu34zq.fsf@wheatstone.g10code.de>
References: <56CD068B.4090305@fsij.org> <87wppu34zq.fsf@wheatstone.g10code.de>
Message-ID: <56CD6B4B.6060808@sumptuouscapital.com>

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

On 02/24/2016 09:08 AM, Werner Koch wrote:
> On Wed, 24 Feb 2016 02:25, gniibe at fsij.org said:
> 
>> I'd understand that extending gpg-agent to support importing stub
>> doesn't sound good.  Even so, I think that it's a developers'
>> view point.  For users, it's better not to be requested any user
> 
> Coincidentally I thought about this yesterday and I am pondering 
> with the idea of not requiring a stub key at all for a currently 
> inserted card.  That is actually the same thing we do in 
> command-ssh.c - the currently inserted card is treated specially
> by always trying to use it.
> 
> Sure this does not help if you need to juggle with a bunch of
> cards but the most common case is that there is just one card.

Are you sure about that?

> 
> On a somewhat related issue:
> 
> There is the request to handle the case where keys are stored on 
> several cards which we can't easily solve with the current system 
> at all (or well, only with a lot of nasty code).  I have two ideas 
> on how to handle this:

Isn't this case pretty much solved already if the first part is
implemented? At least if the stub data generated isn't stored
persistently but in a cache of some sort separate from the secret
keyring.

At least the use case where you'd switch from smartcard with only
subkeys (for daily use) to smartcard with a primary key (to certify
some certificates using a smartcard stored more securely) seems to be
void if the keygrip and cardno isn't stored as regular stub to begin
with.

- -- 
- ----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Public OpenPGP key at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- ----------------------------
Aquila non capit muscas
The eagle does not hunt flies
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJWzWtHAAoJECULev7WN52F+qkIAKAZaexAnRhpXl6cutq+htDd
8TMR0atrmZ5L3IGpTAtKLJTLmks1lc4DbJAmShZbh2U5/l0iK+4KpGDs1Lp2APC6
4UDrkuzzK5CwQ8Om8MpxLz0cJBZM4Pe+h1B5klvEnk2Skk0RuB4uWn8qcbRPfkE1
vYPOgfGCD9qNVi+g4wQtEWDpfX5QfKAEKDyZYIwmTSpzOI8GyFsMwjnS9CTxv2oB
5/ECUIlgYulcizsg8Gb+Hf7AknwFkKJW+Xd1uQKLiU+dtIRCauNQ5owiP1XYgYOj
2gKXW9zA6ix70DkRySUmTeB+Ilyjquc1d0+mo1P1+7giLrthL8+cpXUlSLY6LHo=
=Y/XZ
-----END PGP SIGNATURE-----


From wk at gnupg.org  Wed Feb 24 09:20:12 2016
From: wk at gnupg.org (Werner Koch)
Date: Wed, 24 Feb 2016 09:20:12 +0100
Subject: Moving the agent's socket to /var/run ?
In-Reply-To: <CAL=27uSqHZFWv5RzwqNM+yBt8RTBGbc=mh_Z7SJbn1c+Y0BAKg@mail.gmail.com>
 ("Uldis =?utf-8?Q?An=C5=A1mits=22's?= message of "Wed, 24 Feb 2016 08:39:57
 +0200")
References: <87k2lv5u0y.fsf@wheatstone.g10code.de>
 <CAL=27uSqHZFWv5RzwqNM+yBt8RTBGbc=mh_Z7SJbn1c+Y0BAKg@mail.gmail.com>
Message-ID: <87si0i34g3.fsf@wheatstone.g10code.de>

On Wed, 24 Feb 2016 07:39, uldis.ansmits at tieto.com said:

> I believe, socket redirection is good feature.

Sure, I  do not plan to remove it.

> Maybe automatic socket redirect to $TMPDIR for long home is acceptable solution.

Too complicated because it is not clear where to set the threshold and
by using tmpdir or any other directory you run into similar problems as
with /var/run.

> There is no /var/run/user on AIX or Solaris

All the better, then tehre won't be any conflict.

> Would be nice if GNUPG software can run by user right away without
> setup requiring admin access.

Of course there would be a configure option to keep the current
behaviour.  The creation of the /var/run/user/<uid> directory would be
done by a small program run by root using userv [1].


Shalom-Salam,

   Werner


[1] In case you don't know userv:
 `user services' - program call across trust boundaries
 userv allows one program to invoke another when only limited trust
 exists between them.  It is a tool which can be used to avoid having
 to give other system services root privilege, and which allows users
 to more securely have programs provide services to others.
 .
 userv can be useful as `glue' for system administrators; there are
 not many full-blown userv-using applications yet.

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



From me at nerade.de  Wed Feb 24 11:42:19 2016
From: me at nerade.de (me at nerade.de)
Date: Wed, 24 Feb 2016 11:42:19 +0100
Subject: libgpg-error MinGW compile error
Message-ID: <c71b44056f9e6847d06985837a29befa@nerade.de>

Hello,

I hope this is the appropriate channel for this report/question.

Currently I am trying to develop a software using gpgme as library. My 
first question is if it is still recommended for new designs since it is 
based on gpg 1.4 as far as I understood.

Secondly my attempt to compile the libgpg-error on Windows 7 (64bit) 
with MinGW fails with error in estream.c "EWOULDBLOCK undeclared"

The summary information of the autogen script on my system is as follow:

libgpg-error-1.21 prepared for make
Revision: 425b768
Platform: i686-pc-mingw32

Complete autogen.sh --build-w32 output:
http://pastebin.com/Zbihq2Rg

Complete make output:
http://pastebin.com/PzvQXNiR

I have followed the install instructions but this lead me to this point. 
I guess you can help me with the step I am missing.

Best regards and thanks in advance
Marcel


From dkg at fifthhorseman.net  Wed Feb 24 03:18:29 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 23 Feb 2016 18:18:29 -0800
Subject: Moving the agent's socket to /var/run ?
In-Reply-To: <56CCFC6D.8060705@sumptuouscapital.com>
References: <87k2lv5u0y.fsf@wheatstone.g10code.de>
 <a604cccc11e05fb5d6f37c4d865450bb@mail.meleeweb.net>
 <56CCFC6D.8060705@sumptuouscapital.com>
Message-ID: <87io1e26mi.fsf@alice.fifthhorseman.net>

On Tue 2016-02-23 16:42:21 -0800, Kristian Fiskerstrand wrote:
> On 02/24/2016 12:15 AM, Bertrand Jacquin wrote:
>> abstract namespace were introduced with Linux. See man 7 unix.
>
> I'm asking because I'm not familiar with abstract sockets but. Ok, its
> implemented in Linux, but is it portable? is it POSIX?

from unix(7):

    The abstract socket  namespace is a nonportable Linux extension.

What are the permissions on sockets? is each peer supposed to do its own
authorization on the basis of PEERCRED or something like that?  I'm not
convinced this is a good idea.

> How would this work with socket forwarading over SSH for gpg-agent ?

i don't think that OpenSSH supports forwarding abstract sockets at all.

  --dkg


From dkg at fifthhorseman.net  Wed Feb 24 03:13:53 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 23 Feb 2016 18:13:53 -0800
Subject: Moving the agent's socket to /var/run ?
In-Reply-To: <877fhv9ok6.wl-neal@walfield.org>
References: <87k2lv5u0y.fsf@wheatstone.g10code.de>
 <08mupc-otk.ln1@argenau.bebt.de> <877fhv9ok6.wl-neal@walfield.org>
Message-ID: <87lh6a26u6.fsf@alice.fifthhorseman.net>

On Tue 2016-02-23 12:09:13 -0800, Neal H. Walfield wrote:
> On Tue, 23 Feb 2016 19:50:10 +0100,
> Andreas Metzler wrote:
>> /var/run typically is a symlink to /run. Are per-user
>> subdirectories of /run common practise on other ditributions nowadays?
>> (I only know that Debian does not have them.) Having a default that
>> would not work for most of the users is probably not desirable.
>
> I think Debian has them.  At least my install has them and I didn't do
> anything special.

Debian definitely has them.  they're a good idea, and i'd be happy to
use them.

The right place to try if XDG_RUNTIME_DIR is not available is
/run/user/<uid>/

Is this going to be the new "standard socket" location?  If so, how
should we help people transition who have already been running with the
old "standard socket" location?

    --dkg


From wk at gnupg.org  Wed Feb 24 10:08:18 2016
From: wk at gnupg.org (Werner Koch)
Date: Wed, 24 Feb 2016 10:08:18 +0100
Subject: stub-key migration from gpg 1.4/2.0 to 2.1
In-Reply-To: <56CD6B4B.6060808@sumptuouscapital.com> (Kristian Fiskerstrand's
 message of "Wed, 24 Feb 2016 09:35:23 +0100")
References: <56CD068B.4090305@fsij.org> <87wppu34zq.fsf@wheatstone.g10code.de>
 <56CD6B4B.6060808@sumptuouscapital.com>
Message-ID: <87lh6a327x.fsf@wheatstone.g10code.de>

On Wed, 24 Feb 2016 09:35, kristian.fiskerstrand at sumptuouscapital.com
said:

>> Sure this does not help if you need to juggle with a bunch of
>> cards but the most common case is that there is just one card.
>
> Are you sure about that?

Well it would work or we can make it work.  You won't have a prompt with
the serial number of the smartcard to be inserted then.  I actually like
that prompt ("Please insert the card with S/N xyz").

> Isn't this case pretty much solved already if the first part is
> implemented? At least if the stub data generated isn't stored
> persistently but in a cache of some sort separate from the secret

Yes, with the above mentioned exception.  We could of course keep a
cache of seen cards which works as long as you don't restart the agent.

There is another use case I forgot to tell: OpenSSH supports
certificates for the public keys to ease administration tasks.  These
are special ssh certificates and not any complicated stuff like X.509 or
OpenPGP.  Meanwhile gpg-agent can take the keys from the certificates
but gpg-agent is not yet able to return the certificate on request from
ssh.  To fix this within the model we use in our ssh-agent protocol
implementation, we need to persistently store those certificates along
with the private key (or stub key). A field "Ssh-cert:" in the proposed
meta data format could be used for that.


Salam-Shalom,

   Werner


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



From aheinecke at intevation.de  Wed Feb 24 18:14:11 2016
From: aheinecke at intevation.de (Andre Heinecke)
Date: Wed, 24 Feb 2016 18:14:11 +0100
Subject: [PATCH] migration to libusb-1.0
In-Reply-To: <56A839D7.3060301@fsij.org>
References: <569DEFEB.4000401@fsij.org> <878u3k4ndo.fsf@vigenere.g10code.de>
 <56A839D7.3060301@fsij.org>
Message-ID: <4732366.hfvhY9Bxy9@esus>

Hi,

On Wednesday 27 January 2016 12:30:31 NIIBE Yutaka wrote:
> I pushed the change.

Starting with this change smartcard operations are not working for me.
With git master (rev 75861b6) I'm seeing:
2016-02-24 16:49:13 scdaemon[17303] DBG: chan_5 <- SERIALNO
2016-02-24 16:49:13 scdaemon[17303] pcsc_establish_context failed: no service 
(0x8010001d)
2016-02-24 16:49:13 scdaemon[17303] DBG: chan_5 -> ERR 100663404 Card error 
<SCD>

With only this patch (rev d0d9708) I get slightly different errors (see 
attached log.)

2.1.11 (or rev 167558a) works. This is debian jessie with an SPR532 reader.

Regards,
Andre

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

From eric at debian.org  Wed Feb 24 04:07:22 2016
From: eric at debian.org (Eric Dorland)
Date: Tue, 23 Feb 2016 22:07:22 -0500
Subject: Moving the agent's socket to /var/run ?
In-Reply-To: <08mupc-otk.ln1@argenau.bebt.de>
References: <87k2lv5u0y.fsf@wheatstone.g10code.de>
 <08mupc-otk.ln1@argenau.bebt.de>
Message-ID: <20160224030722.GV23333@gambit>

* Andreas Metzler (ametzler at bebt.de) wrote:
> Werner Koch <wk at gnupg.org> wrote:
> [...]
> > GnuPG 2.x makes extensive use of Unix domain sockets for interprocess
> > communication.  For example gpg-agent is listenening for requests from
> > gpg or gpgsm on the socket ~/.gnupg/S.gpg-agent .  We have received a
> > couple of reports from folks who have to install GnuPG in GnuPG home
> > directory with a long file name.  This does not work well with sockets
> > which usually have a limit on the length of their name.  The workaround
> [...]
> > What about changing the _default_ name for the sockets from, say,
> > ~/.gnupg/S.gpg-agent to /var/run/user/<uid>/S.gpg-agent ?  This is
> > similar to what system daemons use for their socket names and has the
> > further advantage that /var/run is always locally mounted and would thus
> > avoid the re-direction file hack used for NFS etc.  This would only be
> > done if GNUPGHOME/--homedir is not set so that it is still possible to
> > run a second instance of gnupg.
> [...]
> 
> Hello,
> 
> /var/run typically is a symlink to /run. Are per-user
> subdirectories of /run common practise on other ditributions nowadays?
> (I only know that Debian does not have them.) Having a default that
> would not work for most of the users is probably not desirable.
> 
> You could use (a subdirectory of) /tmp.

As far as I know, they're only create by pam_systemd
(http://man7.org/linux/man-pages/man8/pam_systemd.8.html). So Debian
does have them, if you're using systemd.

-- 
Eric Dorland <eric at kuroneko.ca>
43CF 1228 F726 FD5B 474C  E962 C256 FBD5 0022 1E93
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: </pipermail/attachments/20160223/d9f57b93/attachment.sig>

From eric at debian.org  Wed Feb 24 04:07:22 2016
From: eric at debian.org (Eric Dorland)
Date: Tue, 23 Feb 2016 22:07:22 -0500
Subject: Moving the agent's socket to /var/run ?
In-Reply-To: <08mupc-otk.ln1@argenau.bebt.de>
References: <87k2lv5u0y.fsf@wheatstone.g10code.de>
 <08mupc-otk.ln1@argenau.bebt.de>
Message-ID: <20160224030722.GV23333@gambit>

* Andreas Metzler (ametzler at bebt.de) wrote:
> Werner Koch <wk at gnupg.org> wrote:
> [...]
> > GnuPG 2.x makes extensive use of Unix domain sockets for interprocess
> > communication.  For example gpg-agent is listenening for requests from
> > gpg or gpgsm on the socket ~/.gnupg/S.gpg-agent .  We have received a
> > couple of reports from folks who have to install GnuPG in GnuPG home
> > directory with a long file name.  This does not work well with sockets
> > which usually have a limit on the length of their name.  The workaround
> [...]
> > What about changing the _default_ name for the sockets from, say,
> > ~/.gnupg/S.gpg-agent to /var/run/user/<uid>/S.gpg-agent ?  This is
> > similar to what system daemons use for their socket names and has the
> > further advantage that /var/run is always locally mounted and would thus
> > avoid the re-direction file hack used for NFS etc.  This would only be
> > done if GNUPGHOME/--homedir is not set so that it is still possible to
> > run a second instance of gnupg.
> [...]
> 
> Hello,
> 
> /var/run typically is a symlink to /run. Are per-user
> subdirectories of /run common practise on other ditributions nowadays?
> (I only know that Debian does not have them.) Having a default that
> would not work for most of the users is probably not desirable.
> 
> You could use (a subdirectory of) /tmp.

As far as I know, they're only create by pam_systemd
(http://man7.org/linux/man-pages/man8/pam_systemd.8.html). So Debian
does have them, if you're using systemd.

-- 
Eric Dorland <eric at kuroneko.ca>
43CF 1228 F726 FD5B 474C  E962 C256 FBD5 0022 1E93
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: </pipermail/attachments/20160223/d9f57b93/attachment-0001.sig>

From wk at gnupg.org  Wed Feb 24 16:55:24 2016
From: wk at gnupg.org (Werner Koch)
Date: Wed, 24 Feb 2016 16:55:24 +0100
Subject: Moving the agent's socket to /var/run ?
In-Reply-To: <87lh6a26u6.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Tue, 23 Feb 2016 18:13:53 -0800")
References: <87k2lv5u0y.fsf@wheatstone.g10code.de>
 <08mupc-otk.ln1@argenau.bebt.de> <877fhv9ok6.wl-neal@walfield.org>
 <87lh6a26u6.fsf@alice.fifthhorseman.net>
Message-ID: <874mcy2jdf.fsf@wheatstone.g10code.de>

On Wed, 24 Feb 2016 03:13, dkg at fifthhorseman.net said:

> Debian definitely has them.  they're a good idea, and i'd be happy to
> use them.

Great.  Do you expect a name conflict due to our socket names:

  S.gpg-agent
  S.gpg-agent.ssh
  S.scdaemon
  S.dirmngr
  S.uiserver


> The right place to try if XDG_RUNTIME_DIR is not available is
> /run/user/<uid>/

We would figure that out at runtime so that it will also work work if
/var/run is not a symlink to run.

> Is this going to be the new "standard socket" location?  If so, how

For Unix it should be the default for 2.1 unless a configure option is
used to revert to the old behaviour.  For Windows there is no need to
change it.

> should we help people transition who have already been running with the
> old "standard socket" location?

All proper applications should use gpgconf to find the agents sockets,
Except for redirect sockets the only problem I see is that an already
running agent would not be used by 2.1 and a running scdaemon might have
locked the smartcard.  However running an old agent with a newer gpg is
in any case not a good idea.

What to do with gnupg 2.0 ?  Backport the changes or keep using the old
system?  I'd say to keep the old system.

For 1.4, which uses gpg-agent mainly as a passphrase cache, I would
suggest to backport the change in a way that /var/run is tried before
~/.gnupg - it is only about the client code.


Shalom-Salam,

   Werner

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



From gniibe at fsij.org  Thu Feb 25 03:36:57 2016
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 25 Feb 2016 11:36:57 +0900
Subject: [PATCH] migration to libusb-1.0
In-Reply-To: <4732366.hfvhY9Bxy9@esus>
References: <569DEFEB.4000401@fsij.org> <878u3k4ndo.fsf@vigenere.g10code.de>
 <56A839D7.3060301@fsij.org> <4732366.hfvhY9Bxy9@esus>
Message-ID: <56CE68C9.90404@fsij.org>

Hello,

Thank you for testing.  (It works for me on a machine Jessie, as
well as on a machine testing, with Gnuk Tokens.)

Please help locate the bug.

On 02/25/2016 02:14 AM, Andre Heinecke wrote:
> Starting with this change smartcard operations are not working for me.
> With git master (rev 75861b6) I'm seeing:
> 2016-02-24 16:49:13 scdaemon[17303] DBG: chan_5 <- SERIALNO
> 2016-02-24 16:49:13 scdaemon[17303] pcsc_establish_context failed: no service 
> (0x8010001d)
> 2016-02-24 16:49:13 scdaemon[17303] DBG: chan_5 -> ERR 100663404 Card error 
> <SCD>

I believe that this is failure of PC/SC (after failure of
ccid-driver).  I need the log for ccid-driver.

> With only this patch (rev d0d9708) I get slightly different errors (see 
> attached log.)

This is the failure of ccid-driver.  Please put a line:

	debug-ccid-driver

into .gnupg/scdaemon.conf to locate the exact issue.
--

-------------- 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/20160225/45210f85/attachment.sig>

From aheinecke at intevation.de  Thu Feb 25 10:16:01 2016
From: aheinecke at intevation.de (Andre Heinecke)
Date: Thu, 25 Feb 2016 10:16:01 +0100
Subject: [PATCH] migration to libusb-1.0
In-Reply-To: <56CE68C9.90404@fsij.org>
References: <569DEFEB.4000401@fsij.org> <4732366.hfvhY9Bxy9@esus>
 <56CE68C9.90404@fsij.org>
Message-ID: <91028011.X08QZ88c6s@esus>

Hi,

On Thursday 25 February 2016 11:36:57 NIIBE Yutaka wrote:
> Hello,
> 
> Thank you for testing.  (It works for me on a machine Jessie, as
> well as on a machine testing, with Gnuk Tokens.)
> 
> Please help locate the bug.

I've restarted my Computer since yesterday and while I was able to reliably 
reproduce the problem by switching between 2.1.11 and master yesterday today 
it works fine with master. :-(
So maybe it was just related to the state of my system?

> I believe that this is failure of PC/SC (after failure of
> ccid-driver).  I need the log for ccid-driver.
> 
> > With only this patch (rev d0d9708) I get slightly different errors (see
> > attached log.)

With d0d9708 and debug-ccid-driver I now get a different failure
signing failed: No SmartCard daemon
(If i remove the debug line I'm getting invalid value again)

I'm not sure if it helps as master already shows a different behavior
but the log is here:

http://files.intevation.de/users/aheinecke/scdaemon-d0d9708.log.gpg

It's so huge that I think parts of memory are dumped and I'm not sure if there 
is private information in there so I've encrypted it to you.

Regards,
Andre

-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160225/0d38d53a/attachment.sig>

From gniibe at fsij.org  Thu Feb 25 12:20:25 2016
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 25 Feb 2016 20:20:25 +0900
Subject: [PATCH] migration to libusb-1.0
In-Reply-To: <91028011.X08QZ88c6s@esus>
References: <569DEFEB.4000401@fsij.org> <4732366.hfvhY9Bxy9@esus>
 <56CE68C9.90404@fsij.org> <91028011.X08QZ88c6s@esus>
Message-ID: <56CEE379.1050008@fsij.org>

On 02/25/2016 06:16 PM, Andre Heinecke wrote:
> I've restarted my Computer since yesterday and while I was able to reliably 
> reproduce the problem by switching between 2.1.11 and master yesterday today 
> it works fine with master. :-(
> So maybe it was just related to the state of my system?

When something is going wrong, the behavior of new libusb could be
easily fatal, since USB packets and meta data (length, direction,
etc.) is all in user space.

I guess that scdaemon has issues and new libusb just reveals that.
I've been using scdaemon with new libusb daily.  Perhaps, my use
cases are limited.

> With d0d9708 and debug-ccid-driver I now get a different failure
> signing failed: No SmartCard daemon
> (If i remove the debug line I'm getting invalid value again)
> 
> I'm not sure if it helps as master already shows a different behavior
> but the log is here:
> 
> http://files.intevation.de/users/aheinecke/scdaemon-d0d9708.log.gpg
> 
> It's so huge that I think parts of memory are dumped and I'm not sure if there 
> is private information in there so I've encrypted it to you.

In the situations of "invalid value" and the (huge) log, the size
returned by libusb_bulk_transfer is negative or very big.  I don't
know how it happens.

Let us test further.
-- 

-------------- 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/20160225/202a429f/attachment.sig>

From justus at g10code.com  Thu Feb 25 12:27:34 2016
From: justus at g10code.com (Justus Winter)
Date: Thu, 25 Feb 2016 12:27:34 +0100
Subject: Moving the agent's socket to /var/run ?
In-Reply-To: <20160224030722.GV23333@gambit>
References: <87k2lv5u0y.fsf@wheatstone.g10code.de>
 <08mupc-otk.ln1@argenau.bebt.de> <20160224030722.GV23333@gambit>
Message-ID: <20160225112734.22889.97969@thinkbox.jade-hamburg.de>

Quoting Eric Dorland (2016-02-24 04:07:22)
> As far as I know, they're only create by pam_systemd
> (http://man7.org/linux/man-pages/man8/pam_systemd.8.html). So Debian
> does have them, if you're using systemd.

Good catch.  While my Debian/Linux systems do have them in spite of
using sysvinit as pid 1, neither my Debian/Hurd systems nor my
Debian/kFreeBSD system have /run/user.

Justus


From kristian.fiskerstrand at sumptuouscapital.com  Thu Feb 25 13:28:54 2016
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Thu, 25 Feb 2016 13:28:54 +0100
Subject: Moving the agent's socket to /var/run ?
In-Reply-To: <874mcy2jdf.fsf@wheatstone.g10code.de>
References: <87k2lv5u0y.fsf@wheatstone.g10code.de>
 <08mupc-otk.ln1@argenau.bebt.de> <877fhv9ok6.wl-neal@walfield.org>
 <87lh6a26u6.fsf@alice.fifthhorseman.net>
 <874mcy2jdf.fsf@wheatstone.g10code.de>
Message-ID: <56CEF386.10900@sumptuouscapital.com>

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

On 02/24/2016 04:55 PM, Werner Koch wrote:
> What to do with gnupg 2.0 ?  Backport the changes or keep using
> the old system?  I'd say to keep the old system.

I agree; keep the old system for 2.0

- -- 
- ----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Public OpenPGP key at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- ----------------------------
Aquila non capit muscas
The eagle does not hunt flies
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJWzvOBAAoJECULev7WN52FaEQH/ieU11k6KOxmfXZsQIyhUbMc
T/pCGRCUsmaVo4IuuXaxyNG1UjtGztEBCeD1QECTRdMXTG1oFPRBCInlAbNGd8pz
D3mv+F5d+JAVz2FeFwJskl85wLvIpJICjQqna+kiaky/zBy/3xoO1itgpHeoaemS
cnPwh8FMIfKezNP1xFzLHkzggNjbD1XkFyewvJDxbdV3maBut5t6wL+geKOsAY+2
y5JEVRW6+G8UJ9PEO3CgQmNnGKTQXLZTbRKlnm9rmgfC+XkN+mp0wPSo4V3DNRxz
iA6mKeH3WgfQxm+EWBpZxaNw6HZ87R+hVEHdYKuj/d34l+p0qPHRQXox/v4P9wg=
=2izx
-----END PGP SIGNATURE-----


From gniibe at fsij.org  Fri Feb 26 01:22:04 2016
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Fri, 26 Feb 2016 09:22:04 +0900
Subject: [PATCH] migration to libusb-1.0
In-Reply-To: <56CEE379.1050008@fsij.org>
References: <569DEFEB.4000401@fsij.org> <4732366.hfvhY9Bxy9@esus>
 <56CE68C9.90404@fsij.org> <91028011.X08QZ88c6s@esus>
 <56CEE379.1050008@fsij.org>
Message-ID: <56CF9AAC.7000207@fsij.org>

Hello,

I've look through the changes.  I think that the change by Werner
(3d952a2) over d0d9708 is important for 64-bit architecture.

If you encountered a problem with d0d9708-only but not master, it is
normal.

If you see any problem with d0d9708 + 3d952a2, please let me know.
I also keep using master to see if there will issues.
-- 

-------------- 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/20160226/00c42b9b/attachment.sig>

From gniibe at fsij.org  Fri Feb 26 01:53:10 2016
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Fri, 26 Feb 2016 09:53:10 +0900
Subject: [PATCH] libgpg-error: fix for Solaris and HPPA
In-Reply-To: <56B82CD0.7020309@fsij.org>
References: <56B2BF25.1080103@fsij.org> <56B82CD0.7020309@fsij.org>
Message-ID: <56CFA1F6.1020203@fsij.org>

On 02/08/2016 02:51 PM, NIIBE Yutaka wrote:
> On 02/04/2016 12:01 PM, NIIBE Yutaka wrote:
>> Here is a possible patch for Solaris.  No, I can't test on Solaris.
>>
>>     Issue 1671:
>>     https://bugs.gnupg.org/gnupg/issue1671
> 
> Here is update.  I believe that HPPA requires 16-byte alignment even
> on HP-UX.  Dependency to GCC style __attribute__((aligned(16)) is
> removed, but use "long double" to get same result.

I pushed the changes.

I don't have access to those environments, though.
-- 


From dkg at fifthhorseman.net  Fri Feb 26 04:16:35 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 26 Feb 2016 04:16:35 +0100
Subject: Moving the agent's socket to /var/run ?
In-Reply-To: <20160225112734.22889.97969@thinkbox.jade-hamburg.de>
References: <87k2lv5u0y.fsf@wheatstone.g10code.de>
 <08mupc-otk.ln1@argenau.bebt.de> <20160224030722.GV23333@gambit>
 <20160225112734.22889.97969@thinkbox.jade-hamburg.de>
Message-ID: <87wppsxiss.fsf@alice.fifthhorseman.net>

On Thu 2016-02-25 12:27:34 +0100, Justus Winter <justus at g10code.com> wrote:
> Quoting Eric Dorland (2016-02-24 04:07:22)
>> As far as I know, they're only create by pam_systemd
>> (http://man7.org/linux/man-pages/man8/pam_systemd.8.html). So Debian
>> does have them, if you're using systemd.
>
> Good catch.  While my Debian/Linux systems do have them in spite of
> using sysvinit as pid 1,

pam_systemd(8) says:

       If the system was not booted up with systemd as init system, this
       module does nothing and immediately returns PAM_SUCCESS.

So if they're being created by pam_systemd, and you are not using
systemd as the init system, either the documentation or the code is
wrong, and a bug should probably be filed.

> neither my Debian/Hurd systems nor my Debian/kFreeBSD system have
> /run/user.

Is there a reason we shouldn't try to add /run/user/$USER to those
systems?  having an XDG_RUNTIME_DIR is quite useful from an OS
perspective.

        --dkg


From dkg at fifthhorseman.net  Fri Feb 26 04:23:48 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 26 Feb 2016 04:23:48 +0100
Subject: Moving the agent's socket to /var/run ?
In-Reply-To: <874mcy2jdf.fsf@wheatstone.g10code.de>
References: <87k2lv5u0y.fsf@wheatstone.g10code.de>
 <08mupc-otk.ln1@argenau.bebt.de> <877fhv9ok6.wl-neal@walfield.org>
 <87lh6a26u6.fsf@alice.fifthhorseman.net>
 <874mcy2jdf.fsf@wheatstone.g10code.de>
Message-ID: <87si0gxigr.fsf@alice.fifthhorseman.net>

On Wed 2016-02-24 16:55:24 +0100, Werner Koch <wk at gnupg.org> wrote:
> On Wed, 24 Feb 2016 03:13, dkg at fifthhorseman.net said:
>
>> Debian definitely has them.  they're a good idea, and i'd be happy to
>> use them.
>
> Great.  Do you expect a name conflict due to our socket names:
>
>   S.gpg-agent
>   S.gpg-agent.ssh
>   S.scdaemon
>   S.dirmngr
>   S.uiserver

I don't forsee a name conflict with those names, but currently
everything else on my own (admittedly non-standard system) uses a
subdirectory (e.g. /run/user/$(id -u)/dconf/ and /run/user/$(id
-u)/pulse/).

>> The right place to try if XDG_RUNTIME_DIR is not available is
>> /run/user/<uid>/
>
> We would figure that out at runtime so that it will also work work if
> /var/run is not a symlink to run.

Sounds fine.  If both /run and /var/run exist, and one is not a symlink
or a bind-mount of the other, and XDG_RUNTIME_DIR is not set, i'd prefer
to default to /run/user over /var/run/user, but that is such a corner
case that i'm not particularly concerned about it.

>> Is this going to be the new "standard socket" location?  If so, how
>
> For Unix it should be the default for 2.1 unless a configure option is
> used to revert to the old behaviour.  For Windows there is no need to
> change it.

sounds great to me.

>> should we help people transition who have already been running with the
>> old "standard socket" location?
>
> All proper applications should use gpgconf to find the agents sockets,
> Except for redirect sockets the only problem I see is that an already
> running agent would not be used by 2.1 and a running scdaemon might have
> locked the smartcard.

right, in the worst case for this newer-gpg and older-agent, gpg will
just fire up a new instance of the agent and forget about/ignore the old
one.

For smartcard users, they would need to manually kill off the old agent
once, right?

What about for older-gpg and newer-agent combinations, though?  if an
older gpg 2.1 tries to auto-launch a newer agent, and the agent listens
on a different socket than gpg was expecting, they might never
connect...

> What to do with gnupg 2.0 ?  Backport the changes or keep using the old
> system?  I'd say to keep the old system.

by "the old system" you mean looking at $GPG_AGENT_INFO? or looking
somewhere else?

> For 1.4, which uses gpg-agent mainly as a passphrase cache, I would
> suggest to backport the change in a way that /var/run is tried before
> ~/.gnupg - it is only about the client code.

that sounds reasonable to me.

     --dkg


From neal at walfield.org  Fri Feb 26 10:11:32 2016
From: neal at walfield.org (Neal H. Walfield)
Date: Fri, 26 Feb 2016 10:11:32 +0100
Subject: Moving the agent's socket to /var/run ?
In-Reply-To: <87si0gxigr.fsf@alice.fifthhorseman.net>
References: <87k2lv5u0y.fsf@wheatstone.g10code.de>
 <08mupc-otk.ln1@argenau.bebt.de> <877fhv9ok6.wl-neal@walfield.org>
 <87lh6a26u6.fsf@alice.fifthhorseman.net>
 <874mcy2jdf.fsf@wheatstone.g10code.de>
 <87si0gxigr.fsf@alice.fifthhorseman.net>
Message-ID: <874mcvala3.wl-neal@walfield.org>

On Fri, 26 Feb 2016 04:23:48 +0100,
Daniel Kahn Gillmor wrote:
> 
> On Wed 2016-02-24 16:55:24 +0100, Werner Koch <wk at gnupg.org> wrote:
> > On Wed, 24 Feb 2016 03:13, dkg at fifthhorseman.net said:
> >
> >> Debian definitely has them.  they're a good idea, and i'd be happy to
> >> use them.
> >
> > Great.  Do you expect a name conflict due to our socket names:
> >
> >   S.gpg-agent
> >   S.gpg-agent.ssh
> >   S.scdaemon
> >   S.dirmngr
> >   S.uiserver
> 
> I don't forsee a name conflict with those names, but currently
> everything else on my own (admittedly non-standard system) uses a
> subdirectory (e.g. /run/user/$(id -u)/dconf/ and /run/user/$(id
> -u)/pulse/).

I think it would be a good idea to put the sockets in a gnupg
directory.NA

> What about for older-gpg and newer-agent combinations, though?  if an
> older gpg 2.1 tries to auto-launch a newer agent, and the agent listens
> on a different socket than gpg was expecting, they might never
> connect...

At least v2.0 and v2.1 are not supported together, so that scenario
shouldn't be a problem.  To support an old v1.4 with a new v2.1, we
could use assuan's socket redirection hack.

:) Neal


From wk at gnupg.org  Fri Feb 26 12:18:59 2016
From: wk at gnupg.org (Werner Koch)
Date: Fri, 26 Feb 2016 12:18:59 +0100
Subject: Moving the agent's socket to /var/run ?
In-Reply-To: <874mcvala3.wl-neal@walfield.org> (Neal H. Walfield's message of
 "Fri, 26 Feb 2016 10:11:32 +0100")
References: <87k2lv5u0y.fsf@wheatstone.g10code.de>
 <08mupc-otk.ln1@argenau.bebt.de> <877fhv9ok6.wl-neal@walfield.org>
 <87lh6a26u6.fsf@alice.fifthhorseman.net>
 <874mcy2jdf.fsf@wheatstone.g10code.de>
 <87si0gxigr.fsf@alice.fifthhorseman.net>
 <874mcvala3.wl-neal@walfield.org>
Message-ID: <874mcvyb18.fsf@wheatstone.g10code.de>

On Fri, 26 Feb 2016 10:11, neal at walfield.org said:

> I think it would be a good idea to put the sockets in a gnupg
> directory.NA

Well, okay that should not be a problem, a socket name with a
non-default GNUPGHOME would be in its longest form mlike

/var/run/user/65535/gnupg/S.gpg-agent-1234567812345678

and thus short enough for a socket.  Well, unless $XDG_RUNTIME_DIR is
too long.

> At least v2.0 and v2.1 are not supported together, so that scenario
> shouldn't be a problem.  To support an old v1.4 with a new v2.1, we
> could use assuan's socket redirection hack.

1.4. does not use libassuan and thus socket redirection does not work.
Simply trying to use the /run /var/run etc. is not too complicated.


Salam-Shalom,

   Werner

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



From aheinecke at intevation.de  Fri Feb 26 12:55:45 2016
From: aheinecke at intevation.de (Andre Heinecke)
Date: Fri, 26 Feb 2016 12:55:45 +0100
Subject: [PATCH] migration to libusb-1.0
In-Reply-To: <56CF9AAC.7000207@fsij.org>
References: <569DEFEB.4000401@fsij.org> <56CEE379.1050008@fsij.org>
 <56CF9AAC.7000207@fsij.org>
Message-ID: <1737652.HOYKdJfheH@esus>

Hi,

On Friday 26 February 2016 09:22:04 NIIBE Yutaka wrote:
> If you see any problem with d0d9708 + 3d952a2, please let me know.
> I also keep using master to see if there will issues.

Today I was using master (75861b6) and at first everything worked normally.
Then it stopped working. I'm not sure what I did at the time the error is in 
the log. I might have started a Windows VM in VirtualBox. But shutting it down 
did not help with the error. And starting it again after the error was 
resolved also did not cause it again.

The error in the log is:

2016-02-26 11:40:52 scdaemon[3727] DBG: ccid-driver: usb_bulk_write error: 
LIBUSB_ERROR_NO_DEVICE
2016-02-26 11:40:52 scdaemon[3727] updating reader 0 (-1) status: 0x0007-
>0x0000 (1->1)
2016-02-26 11:40:52 scdaemon[3727] sending signal 12 to client 3410


I have not removed the smartcard or the reader at that point. There might be 
something wrong with my cable though. I see a disconnect with immediate 
reconnect in dmesg log.

Sometime later I wanted to use the card for auth and the error is then:

2016-02-26 12:37:50 scdaemon[3727] DBG: ccid-driver: usb_claim_interface 
failed: -6
2016-02-26 12:37:50 scdaemon[3727] DBG: chan_5 -> ERR 100663404 Card error 
<SCD>
2016-02-26 12:37:51 scdaemon[3727] DBG: chan_5 <- SERIALNO

I'm sending you the full log of todays scdaemon session off list.
This time just restarting gpg-agent (and so scdaemon) fixed the problem which 
it did not the first time I've had this problem.

Regards,
Andre

-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160226/fa442762/attachment-0001.sig>

From neal at walfield.org  Fri Feb 26 14:09:28 2016
From: neal at walfield.org (Neal H. Walfield)
Date: Fri, 26 Feb 2016 14:09:28 +0100
Subject: Moving the agent's socket to /var/run ?
In-Reply-To: <874mcvyb18.fsf@wheatstone.g10code.de>
References: <87k2lv5u0y.fsf@wheatstone.g10code.de>
 <08mupc-otk.ln1@argenau.bebt.de> <877fhv9ok6.wl-neal@walfield.org>
 <87lh6a26u6.fsf@alice.fifthhorseman.net>
 <874mcy2jdf.fsf@wheatstone.g10code.de>
 <87si0gxigr.fsf@alice.fifthhorseman.net>
 <874mcvala3.wl-neal@walfield.org>
 <874mcvyb18.fsf@wheatstone.g10code.de>
Message-ID: <8737sfaa9j.wl-neal@walfield.org>

On Fri, 26 Feb 2016 12:18:59 +0100,
Werner Koch wrote:
> > At least v2.0 and v2.1 are not supported together, so that scenario
> > shouldn't be a problem.  To support an old v1.4 with a new v2.1, we
> > could use assuan's socket redirection hack.
> 
> 1.4. does not use libassuan and thus socket redirection does not work.
> Simply trying to use the /run /var/run etc. is not too complicated.

Ok.  I guess 1.4 does not try to autostart gpg-agent either.  Is that
correct?

:) Neal


From wk at gnupg.org  Fri Feb 26 15:09:27 2016
From: wk at gnupg.org (Werner Koch)
Date: Fri, 26 Feb 2016 15:09:27 +0100
Subject: Moving the agent's socket to /var/run ?
In-Reply-To: <8737sfaa9j.wl-neal@walfield.org> (Neal H. Walfield's message of
 "Fri, 26 Feb 2016 14:09:28 +0100")
References: <87k2lv5u0y.fsf@wheatstone.g10code.de>
 <08mupc-otk.ln1@argenau.bebt.de> <877fhv9ok6.wl-neal@walfield.org>
 <87lh6a26u6.fsf@alice.fifthhorseman.net>
 <874mcy2jdf.fsf@wheatstone.g10code.de>
 <87si0gxigr.fsf@alice.fifthhorseman.net>
 <874mcvala3.wl-neal@walfield.org>
 <874mcvyb18.fsf@wheatstone.g10code.de>
 <8737sfaa9j.wl-neal@walfield.org>
Message-ID: <87si0fwoko.fsf@wheatstone.g10code.de>

On Fri, 26 Feb 2016 14:09, neal at walfield.org said:

> Ok.  I guess 1.4 does not try to autostart gpg-agent either.  Is that
> correct?

Ack.


Salam-Shalom,

   Werner

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