From dgouttegattat at incenp.org  Sat Jan  2 14:03:10 2016
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Sat,  2 Jan 2016 14:03:10 +0100
Subject: [PATCH] doc: Fix incorrect option name --tofu-set-policy
Message-ID: <1451739790-9477-1-git-send-email-dgouttegattat@incenp.org>

* doc/gpg.texi: Replace --tofu-set-policy by --tofu-policy.

Signed-off-by: Damien Goutte-Gattat <dgouttegattat at incenp.org>
---
 doc/gpg.texi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/gpg.texi b/doc/gpg.texi
index b8fd590..4581f64 100644
--- a/doc/gpg.texi
+++ b/doc/gpg.texi
@@ -525,8 +525,8 @@ Use the source, Luke :-). The output format is still subject to change.
 Pack or unpack an arbitrary input into/from an OpenPGP ASCII armor.
 This is a GnuPG extension to OpenPGP and in general not very useful.
 
- at item --tofu-set-policy @code{auto|good|unknown|bad|ask}  @code{key...}
- at opindex tofu-set-policy
+ at item --tofu-policy @code{auto|good|unknown|bad|ask}  @code{key...}
+ at opindex tofu-policy
 Set the TOFU policy for all the bindings associated with the specified
 keys.  For more information about the meaning of the policies,
 @pxref{trust-model-tofu}.  The keys may be specified either by their
-- 
1.8.4



From dgouttegattat at incenp.org  Sun Jan  3 15:56:23 2016
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Sun,  3 Jan 2016 15:56:23 +0100
Subject: [PATCH] scute: Include sexp-parse.h in source files
Message-ID: <1451832983-6138-1-git-send-email-dgouttegattat@incenp.org>

* src/Makefile.am: Add sexp-parse.h in source files.
--

Omitting sexp-parse.h from the list of source files excludes it
from the archive generated by `make dist'.

Signed-off-by: Damien Goutte-Gattat <dgouttegattat at incenp.org>
---
 src/Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/Makefile.am b/src/Makefile.am
index 43fa086..9ceef93 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -58,7 +58,7 @@ sources = cryptoki.h pkcs11.h debug.c debug.h settings.h support.h	\
 	p11-signrecover.c p11-signrecoverinit.c	p11-signupdate.c	\
 	p11-unwrapkey.c p11-verify.c p11-verifyfinal.c p11-verifyinit.c	\
 	p11-verifyrecover.c p11-verifyrecoverinit.c p11-verifyupdate.c	\
-	p11-waitforslotevent.c p11-wrapkey.c
+	p11-waitforslotevent.c p11-wrapkey.c sexp-parse.h
 
 
 if HAVE_LD_VERSION_SCRIPT
-- 
1.8.4



From castrillo.miguel at gmail.com  Sun Jan  3 15:28:10 2016
From: castrillo.miguel at gmail.com (Miguel Castrillo)
Date: Sun, 3 Jan 2016 15:28:10 +0100
Subject: GPGME failing on XP Embedded
Message-ID: <CAObRnMS=1d6C=aDUhh0P=XwvTMOZ5hqGR+=CqzgTj4kTswi4uQ@mail.gmail.com>

Hello,

I managed to solve my problem with gpgme on Windows by using gpg4win light
DLL's, imps and headers:

https://lists.gnupg.org/pipermail/gnupg-devel/2015-September/030301.html

I could create a C++ program in Visual Studio and run it on Windows 7 32
bit and Windows XP 32 bit. The problem is that on Windows XP Embedded it
happens the same as when I was compiling the DLL's myself. It appears that
the w32spawn cannot get the configuration from the gpg2conf file.

That's why I tried on a Windows XP Home 32 bit machine and all run smoothly
at the first try. But I need it to be working on Windows XP Embedded also.

The logfile is pretty much the same as in my previous thread, with the
invalid crypto engine error.

I don't know if you support Windows XP Embedded or you have seen the same
problems before... any help would be very welcomed.

Regards,

?GPGME 2016-01-03 13:59:57 <0x0910>  gpgme_debug: level=9
GPGME 2016-01-03 13:59:57 <0x0910>  gpgme_debug: gpgme='C:\opt\ai1send'
GPGME 2016-01-03 13:59:57 <0x0910>  gpgme_check_version: call: 0=00000000,
req_v
ersion=(null), VERSION=1.6.0
GPGME 2016-01-03 13:59:57 <0x0910>  gpgme_check_version_internal: call:
0=000000
00, req_version=(null), offset_sig_validity=32
GPGME 2016-01-03 13:59:57 <0x0910>  gpgme_set_locale: enter: ctx=00000000,
categ
ory=2, value=English_United States.1252
GPGME 2016-01-03 13:59:57 <0x0910>  gpgme_set_locale: leave
GPGME 2016-01-03 13:59:57 <0x0910>  gpgme_new: enter: r_ctx=0012F598
GPGME 2016-01-03 13:59:57 <0x0910>  gpgme-dinfo: gpgconf='C:\Program
Files\GNU\G
nuPG\gpgconf.exe'
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_pipe: enter:
filedes=0012EEE8, i
nherit_idx=1 (GPGME uses it for reading)
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_pipe: leave: read=0x0
(0000077C/
0x0), write=0x1 (00000774/0x0)
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_spawn: enter:
path=00A95690, pat
h=C:\Program Files\GNU\GnuPG\gpgconf.exe
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_spawn: check:
path=00A95690, arg
v[ 0] = C:\Program Files\GNU\GnuPG\gpgconf.exe
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_spawn: check:
path=00A95690, arg
v[ 1] = --list-dirs
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_spawn: check:
path=00A95690, tmp
_name = C:\Documents and Settings\ADMINI~1\LOCALS~1\Temp\gpgme-gRRmh9
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_spawn: check:
path=00A95690, Cre
ateProcess ready: hProcess=0000075C, hThread=00000758, dwProcessID=3484,
dwThrea
dId=2584
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_spawn: check:
path=00A95690, pro
cess=0000075C
GPGME 2016-01-03 13:59:57 <0x0910>      _gpgme_io_close: enter: fd=00000001
GPGME 2016-01-03 13:59:57 <0x0910>      _gpgme_io_close: check:
fd=00000001, fd=
1 -> handle=00000774 socket=-1 dupfrom=-1
GPGME 2016-01-03 13:59:57 <0x0910>      _gpgme_io_close: leave: result=0
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_spawn: check:
path=00A95690, fd[
0] = 0x1 -> 0x4 (stdout)
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_spawn: leave: result=0
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_read: enter: fd=00000000,
buffer
=0012EEFC, count=1023
GPGME 2016-01-03 13:59:57 <0x0910>      gpgme:create_reader: enter:
fd=00000000
GPGME 2016-01-03 13:59:57 <0x0910>      gpgme:create_reader: check:
fd=00000000,
 fd=0 -> handle=0000077C socket=-1 dupfrom=-1
GPGME 2016-01-03 13:59:57 <0x0910>
 gpgme:get_desired_thread_priority: cal
l: 0=00000000, 2 (default)
GPGME 2016-01-03 13:59:57 <0x0910>      gpgme:create_reader: leave
GPGME 2016-01-03 13:59:57 <0x052c>  gpgme:reader: enter:
ctx->file_hd=0000077C,
file_sock=-1, thread=00000774
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_read: check: fd=00000000,
waitin
g for data from thread 00000774
GPGME 2016-01-03 13:59:57 <0x052c>  gpgme:reader: check:
ctx->file_hd=0000077C,
reading 4095 bytes
GPGME 2016-01-03 13:59:57 <0x052c>  gpgme:reader: check:
ctx->file_hd=0000077C,
got EOF (broken pipe)
GPGME 2016-01-03 13:59:57 <0x052c>  gpgme:reader: check:
ctx->file_hd=0000077C,
waiting for close
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_read: check: fd=00000000,
data f
rom thread 00000774 available
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_read: leave: result=0
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_close: enter: fd=00000000
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_close: check: fd=00000000,
fd=0
-> handle=0000077C socket=-1 dupfrom=-1
GPGME 2016-01-03 13:59:57 <0x052c>  gpgme:reader: leave
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_close: leave: result=0
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_pipe: enter:
filedes=0012EEE8, i
nherit_idx=1 (GPGME uses it for reading)
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_pipe: leave: read=0x0
(00000774/
0x0), write=0x1 (00000778/0x0)
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_spawn: enter:
path=00A95690, pat
h=C:\Program Files\GNU\GnuPG\gpgconf.exe
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_spawn: check:
path=00A95690, arg
v[ 0] = C:\Program Files\GNU\GnuPG\gpgconf.exe
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_spawn: check:
path=00A95690, arg
v[ 1] = --list-components
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_spawn: check:
path=00A95690, tmp
_name = C:\Documents and Settings\ADMINI~1\LOCALS~1\Temp\gpgme-ylASo8
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_spawn: check:
path=00A95690, Cre
ateProcess ready: hProcess=00000750, hThread=00000748, dwProcessID=2644,
dwThrea
dId=2532
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_spawn: check:
path=00A95690, pro
cess=00000750
GPGME 2016-01-03 13:59:57 <0x0910>      _gpgme_io_close: enter: fd=00000001
GPGME 2016-01-03 13:59:57 <0x0910>      _gpgme_io_close: check:
fd=00000001, fd=
1 -> handle=00000778 socket=-1 dupfrom=-1
GPGME 2016-01-03 13:59:57 <0x0910>      _gpgme_io_close: leave: result=0
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_spawn: check:
path=00A95690, fd[
0] = 0x1 -> 0x4 (stdout)
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_spawn: leave: result=0
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_read: enter: fd=00000000,
buffer
=0012EEFC, count=1023
GPGME 2016-01-03 13:59:57 <0x0910>      gpgme:create_reader: enter:
fd=00000000
GPGME 2016-01-03 13:59:57 <0x0910>      gpgme:create_reader: check:
fd=00000000,
 fd=0 -> handle=00000774 socket=-1 dupfrom=-1
GPGME 2016-01-03 13:59:57 <0x0910>
 gpgme:get_desired_thread_priority: cal
l: 0=00000000, 2 (default)
GPGME 2016-01-03 13:59:57 <0x0910>      gpgme:create_reader: leave
GPGME 2016-01-03 13:59:57 <0x03bc>  gpgme:reader: enter:
ctx->file_hd=00000774,
file_sock=-1, thread=00000778
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_read: check: fd=00000000,
waitin
g for data from thread 00000778
GPGME 2016-01-03 13:59:57 <0x03bc>  gpgme:reader: check:
ctx->file_hd=00000774,
reading 4095 bytes
GPGME 2016-01-03 13:59:57 <0x03bc>  gpgme:reader: check:
ctx->file_hd=00000774,
got EOF (broken pipe)
GPGME 2016-01-03 13:59:57 <0x03bc>  gpgme:reader: check:
ctx->file_hd=00000774,
waiting for close
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_read: check: fd=00000000,
data f
rom thread 00000778 available
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_read: leave: result=0
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_close: enter: fd=00000000
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_close: check: fd=00000000,
fd=0
-> handle=00000774 socket=-1 dupfrom=-1
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_close: leave: result=0
GPGME 2016-01-03 13:59:57 <0x03bc>  gpgme:reader: leave
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_pipe: enter:
filedes=0012F2CC, i
nherit_idx=1 (GPGME uses it for reading)
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_pipe: leave: read=0x0
(00000778/
0x0), write=0x1 (0000075C/0x0)
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_spawn: enter:
path=00A95690, pat
h=C:\Program Files\GNU\GnuPG\gpgconf.exe
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_spawn: check:
path=00A95690, arg
v[ 0] = C:\Program Files\GNU\GnuPG\gpgconf.exe
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_spawn: check:
path=00A95690, arg
v[ 1] = --version
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_spawn: check:
path=00A95690, tmp
_name = C:\Documents and Settings\ADMINI~1\LOCALS~1\Temp\gpgme-uzfqw7
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_spawn: check:
path=00A95690, Cre
ateProcess ready: hProcess=00000758, hThread=0000074C, dwProcessID=2552,
dwThrea
dId=3516
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_spawn: check:
path=00A95690, pro
cess=00000758
GPGME 2016-01-03 13:59:57 <0x0910>      _gpgme_io_close: enter: fd=00000001
GPGME 2016-01-03 13:59:57 <0x0910>      _gpgme_io_close: check:
fd=00000001, fd=
1 -> handle=0000075C socket=-1 dupfrom=-1
GPGME 2016-01-03 13:59:57 <0x0910>      _gpgme_io_close: leave: result=0
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_spawn: check:
path=00A95690, fd[
0] = 0x1 -> 0x4 (stdout)
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_spawn: leave: result=0
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_read: enter: fd=00000000,
buffer
=0012F2D4, count=79
GPGME 2016-01-03 13:59:57 <0x0910>      gpgme:create_reader: enter:
fd=00000000
GPGME 2016-01-03 13:59:57 <0x0910>      gpgme:create_reader: check:
fd=00000000,
 fd=0 -> handle=00000778 socket=-1 dupfrom=-1
GPGME 2016-01-03 13:59:57 <0x0910>
 gpgme:get_desired_thread_priority: cal
l: 0=00000000, 2 (default)
GPGME 2016-01-03 13:59:57 <0x0948>  gpgme:reader: enter:
ctx->file_hd=00000778,
file_sock=-1, thread=0000075C
GPGME 2016-01-03 13:59:57 <0x0910>      gpgme:create_reader: leave
GPGME 2016-01-03 13:59:57 <0x0948>  gpgme:reader: check:
ctx->file_hd=00000778,
reading 4095 bytes
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_read: check: fd=00000000,
waitin
g for data from thread 0000075C
GPGME 2016-01-03 13:59:57 <0x0948>  gpgme:reader: check:
ctx->file_hd=00000778,
got EOF (broken pipe)
GPGME 2016-01-03 13:59:57 <0x0948>  gpgme:reader: check:
ctx->file_hd=00000778,
waiting for close
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_read: check: fd=00000000,
data f
rom thread 0000075C available
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_read: leave: result=0
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_close: enter: fd=00000000
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_close: check: fd=00000000,
fd=0
-> handle=00000778 socket=-1 dupfrom=-1
GPGME 2016-01-03 13:59:57 <0x0948>  gpgme:reader: leave
GPGME 2016-01-03 13:59:57 <0x0910>    _gpgme_io_close: leave: result=0
GPGME 2016-01-03 13:59:57 <0x0910>  gpgme_new: leave: ctx=00A955A0
GPGME 2016-01-03 13:59:57 <0x0910>  gpgme_set_protocol: enter:
ctx=00A955A0, pro
tocol=0 (OpenPGP)
GPGME 2016-01-03 13:59:57 <0x0910>  gpgme_set_protocol: leave
GPGME 2016-01-03 13:59:57 <0x0910>  gpgme_set_armor: call: ctx=00A955A0,
use_arm
or=1 (yes)
GPGME 2016-01-03 13:59:57 <0x0910>  engine.c:365: returning error: Invalid
crypt
o engine
GPGME 2016-01-03 13:59:57 <0x0910>  engine.c:155: returning error: Invalid
crypt
o engine
Encrypter.cpp:103: GPGME: Invalid crypto engine
?

-- 
----------------------------------------------
Miguel Castrillo Melguizo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20160103/832c6448/attachment-0001.html>

From infinity0 at pwned.gg  Mon Jan  4 01:56:58 2016
From: infinity0 at pwned.gg (Ximin Luo)
Date: Mon, 4 Jan 2016 01:56:58 +0100
Subject: weird regressions in 2.1.10 with default-key and local-user options
Message-ID: <5689C35A.2000809@pwned.gg>

Minimal test script attached, works against debian gnupg 2.1.10. It will "rm -rf ./lol" so make sure you don't have anything in there. You need to set envvars "k1" and "k2" to the ids of two different secret keys that have the same uids. (Possibly the last condition is not necessary.)

first test: default-key gets ignored completely, silently!!
second test: local-user gets "applied twice" when given in gpg.conf, resulting in "ambiguity" errors. giving a shorter keyid works, though.

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-gpg2-options.sh
Type: application/x-shellscript
Size: 945 bytes
Desc: not available
URL: </pipermail/attachments/20160104/a5bd7db9/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20160104/a5bd7db9/attachment.sig>

From andreas.sommer87 at googlemail.com  Mon Jan  4 09:42:59 2016
From: andreas.sommer87 at googlemail.com (Andreas Sommer)
Date: Mon, 4 Jan 2016 09:42:59 +0100
Subject: gpgme cannot list keys (gpgme 1.6, FreeBSD)
Message-ID: <568A3093.5090204@googlemail.com>

Hi all,

I've only started using gpgme today and am getting an unknown error status 117456895 (= hex 0x7003fff) from gpgme_op_keylist_next, for which gpgme_strerror_r outputs "End of file". My use case is to first find the recipient key by e-mail address, then encrypt some data. Find attached the error log gpgme.log, as created with `GPGME_DEBUG=9:/tmp/log myprogram`.

Running the same command line as shown in the logs (without --status-fd) works fine:

> $ gpg2 --batch --no-sk-comments --no-tty --charset utf8 --enable-progress-filter --with-colons --fixed-list-mode --with-fingerprint --list-keys --
> gpg: Warning: using insecure memory!
> tru::1:1450870578:0:3:1:5

This is on FreeBSD 10.1-RELEASE with gpgme 1.6 installed as package.

Pseudocode (I'm actually wrapping using C++):

> gpgme_check_version(NULL);
> gpgme_engine_check_version(GPGME_PROTOCOL_OpenPGP);
> gpgme_ctx_t ctx;
> gpgme_new(&ctx);
> 
> // These don't matter, mostly defaults anyway
> gpgme_set_protocol(ctx, GPGME_PROTOCOL_OpenPGP);
> gpgme_set_keylist_mode(ctx, GPGME_KEYLIST_MODE_LOCAL);
> gpgme_set_armor(ctx, 1);
> gpgme_set_textmode(ctx, 0);
> //gpgme_ctx_set_engine_info(ctx, GPGME_PROTOCOL_OpenPGP, NULL, "/home/asommer/.gnupg");
> 
> gpgme_op_keylist_start(ctx, NULL, 0);
> gpgme_key_t key = NULL;
> auto res = gpgme_op_keylist_next(ctx, &key); // returns 117456895 and key is NULL

So I'm doing the same thing as other examples. To dig deeper, I created a pure C example for me/you to test (see attached gpgme-example.c). It works fine on Mac OS X (displays my public key), but not in my FreeBSD 10.1 VM ("Error in res: res=-5232: Unknown system error"). On FreeBSD 9.1, the error is "Error in res: res=-9472: Unknown system error". Both logs are attached.

OSX: gpg2 version 2.0.29, libgcrypt 1.6.4
FreeBSD 10.1: gpg2 version 2.1.8, libgcrypt 1.6.3
FreeBSD 9.1: gpg2 version 2.1.6, libgcrypt 1.6.3

Anything else to try? Does it work for anyone?

Thank you very much,
 Andreas Sommer

-------------- next part --------------
// clang -o gpgme-example gpgme-example.c -lgpgme -I /usr/local/include/ -L /usr/local/lib/ && GPGME_DEBUG=9:/tmp/gpgme-example.log ./gpgme-example
#ifdef __FreeBSD__
#include <gpgme/gpgme.h>
#else
#include <gpgme.h>
#endif

// Just a stupid example
#define check(expr) \
    { \
        printf("check %s\n", #expr); \
        gpgme_error_t res = (expr); \
        if (res != GPG_ERR_NO_ERROR) \
        { \
            printf("Error in %s: res=%d: %s\n", #expr, res, gpgme_strerror(res)); \
            return 1; \
        } \
    }

int main()
{
    gpgme_check_version(NULL);
    check(gpgme_engine_check_version(GPGME_PROTOCOL_OpenPGP));
    gpgme_ctx_t ctx;
    check(gpgme_new(&ctx));

    // These don't matter, mostly defaults anyway
    check(gpgme_set_protocol(ctx, GPGME_PROTOCOL_OpenPGP));
    check(gpgme_set_keylist_mode(ctx, GPGME_KEYLIST_MODE_LOCAL));
    gpgme_set_armor(ctx, 1);
    gpgme_set_textmode(ctx, 0);
    //check(gpgme_ctx_set_engine_info(ctx, GPGME_PROTOCOL_OpenPGP, NULL, "/home/asommer/.gnupg"));

    check(gpgme_op_keylist_start(ctx, NULL, 0));
    gpgme_key_t key = NULL;
    gpgme_error_t res = gpgme_op_keylist_next(ctx, &key); // returns 117456895 and key is NULL
    if (res == GPG_ERR_EOF)
    {
        printf("No more keys (expected error)\n");
    }
    else
    {
        check(res);

        printf("Found key: %s\n", key->uids->email);
    }

    return 0;
}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logs.tgz
Type: application/x-gzip
Size: 5953 bytes
Desc: not available
URL: </pipermail/attachments/20160104/daa3cf8f/attachment.bin>

From justus at g10code.com  Mon Jan  4 11:18:20 2016
From: justus at g10code.com (Justus Winter)
Date: Mon, 04 Jan 2016 11:18:20 +0100
Subject: [PATCH] scute: Include sexp-parse.h in source files
In-Reply-To: <1451832983-6138-1-git-send-email-dgouttegattat@incenp.org>
References: <1451832983-6138-1-git-send-email-dgouttegattat@incenp.org>
Message-ID: <20160104101820.7495.41707@thinkbox.jade-hamburg.de>

Quoting Damien Goutte-Gattat (2016-01-03 15:56:23)
> * src/Makefile.am: Add sexp-parse.h in source files.
> --
> 
> Omitting sexp-parse.h from the list of source files excludes it
> from the archive generated by `make dist'.

Merged, thanks!

Justus


From justus at g10code.com  Mon Jan  4 11:27:34 2016
From: justus at g10code.com (Justus Winter)
Date: Mon, 04 Jan 2016 11:27:34 +0100
Subject: On Scute v1.4.0  support key length up to 4096,
 proceed s-expressions on common way
In-Reply-To: <564CBD34.1030608@gurevich.de>
References: <564CBD34.1030608@gurevich.de>
Message-ID: <20160104102734.7495.38420@thinkbox.jade-hamburg.de>

Hi Oleg,

I did some work on Scute, among other things it should support larger
keys now and support TLS1.2 (i.e. hash functions other than
tls-md5sha1).  Would you be so kind to see if that fixes the issues
you were having?

Thanks,
Justus


From neal at walfield.org  Mon Jan  4 12:17:24 2016
From: neal at walfield.org (Neal H. Walfield)
Date: Mon, 04 Jan 2016 12:17:24 +0100
Subject: weird regressions in 2.1.10 with default-key and local-user
 options
In-Reply-To: <5689C35A.2000809@pwned.gg>
References: <5689C35A.2000809@pwned.gg>
Message-ID: <87egdxy4or.wl-neal@walfield.org>

Hi,

On Mon, 04 Jan 2016 01:56:58 +0100,
Ximin Luo wrote:
> Minimal test script attached, works against debian gnupg 2.1.10. It will "rm -rf ./lol" so make sure you don't have anything in there. You need to set envvars "k1" and "k2" to the ids of two different secret keys that have the same uids. (Possibly the last condition is not necessary.)
> 
> first test: default-key gets ignored completely, silently!!
> second test: local-user gets "applied twice" when given in gpg.conf, resulting in "ambiguity" errors. giving a shorter keyid works, though.

I'm sorry about this.  I added functionality to detect ambiguous keys,
but my implementation was faulty.  Given how invasive this change is,
I've reverted it in git and will resume work on it once we start
development on the 2.3 branch (sometime in the first quarter of 2016).

Nevertheless, thanks for the report!

:) Neal


From wk at gnupg.org  Mon Jan  4 16:34:50 2016
From: wk at gnupg.org (Werner Koch)
Date: Mon, 04 Jan 2016 16:34:50 +0100
Subject: weird regressions in 2.1.10 with default-key and local-user
 options
In-Reply-To: <87egdxy4or.wl-neal@walfield.org> (Neal H. Walfield's message of
 "Mon, 04 Jan 2016 12:17:24 +0100")
References: <5689C35A.2000809@pwned.gg> <87egdxy4or.wl-neal@walfield.org>
Message-ID: <87ziwll5np.fsf@vigenere.g10code.de>

On Mon,  4 Jan 2016 12:17, neal at walfield.org said:

> development on the 2.3 branch (sometime in the first quarter of 2016).

Let's avoid too high expectations: Second quarter seems to be more
realistic.


Shalom-Salam,

   Werner

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



From gniibe at fsij.org  Tue Jan  5 02:53:05 2016
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 5 Jan 2016 10:53:05 +0900
Subject: Alignment issue of iobuf functions
Message-ID: <568B2201.6030805@fsij.org>

Hello,

I'm now using ARMv7 variant.

=========================
$ uname -a
Linux OrangePI 3.4.39 #1 SMP PREEMPT Mon Oct 12 12:02:29 CEST 2015
armv7l GNU/Linux
$ gcc --version
gcc (Debian 5.3.1-4) 5.3.1 20151219
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
=========================

Then, I see compiler warnings like:
=========================
../../gnupg/common/iobuf.c: In function `file_filter':
../../gnupg/common/iobuf.c:581:8: warning: cast increases required
alignment of target type [-Wcast-align]
       *(char **) buf = "file_filter(fd)";
        ^
=========================

This is because of the argument BUF is declared as byte * and we cast
to (char **), where the alignment condition for (byte *) and the one
for (char **) could be different.  So, the warning is relevant.

I think that our usage of (byte *) here is actually (void *).  I'm not
sure if changing to (void *) is better or not.
-- 


From dkg at fifthhorseman.net  Tue Jan  5 05:20:25 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 04 Jan 2016 23:20:25 -0500
Subject: --weak-digest SHA1 causes significant slowdown in --check-trustdb
 (2.1.10)
Message-ID: <87mvsky7w6.fsf@alice.fifthhorseman.net>

Hi folks--

i'm running gnupg 2.1.10 with a large keybox (a couple thousand
certificates).

With a hot filesystem cache, "gpg2 --check-trustdb" on its own takes
about 17 seconds to run.

real	0m17.160s
user	0m15.852s
sys	0m1.308s


If i add --weak-digest RIPEMD160, it's still about 17 seconds.

if i add --weak-digest RIPEMD160 --weak-digest SHA224 --weak-digest
SHA384, it is still about 17 seconds.

(note: i don't actually think sha224 and sha384 should be discarded,
this is just for demonstration)

But if i add --weak-digest SHA1, then check-trustdb runs for about 22
*minutes*, and nearly half of that is in the kernel:

real	22m9.765s
user	9m48.464s
sys	12m21.464s


To try to get a better sense of what's going on here.  I've tried
running with profiling (gprof), and the difference in the gprof
summaries look like this:

==> with-weak-sha1 <==
Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls   s/call   s/call  name    
 40.48     86.29    86.29 264440430     0.00     0.00  unknown_pubkey_warning
 14.53    117.26    30.97    70214     0.00     0.00  iobuf_temp_with_content
  8.90    136.24    18.98 2151046702     0.00     0.00  enum_sig_subpkt
  5.64    148.27    12.03 169702791     0.00     0.00  new_kbnode
  5.37    159.71    11.44 169205168     0.00     0.00  parse_signature
  5.07    170.52    10.81 169772114     0.00     0.00  free_packet
  4.15    179.36     8.84    70144     0.00     0.00  release_kbnode
  3.10    185.97     6.61    88068     0.00     0.00  find_prev_kbnode
  2.06    190.36     4.39    80306     0.00     0.00  keybox_search
  1.51    193.58     3.22 169772114     0.00     0.00  dbg_parse_packet
  1.37    196.50     2.92 124607778     0.00     0.00  _keybox_read_blob2
  1.24    199.15     2.65 346174508     0.00     0.00  parse_one_sig_subpkt
  1.14    201.59     2.44    69323     0.00     0.00  parse_keyblock_image
  0.91    203.53     1.94 330484896     0.00     0.00  iobuf_read
  0.52    204.64     1.11 330484916     0.00     0.00  parse_sig_subpkt2

==> without-weak-sha1 <==
Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls  ms/call  ms/call  name    
 28.99      0.40     0.40  1348642     0.00     0.00  unknown_pubkey_warning
 18.12      0.65     0.25    13853     0.02     0.03  mark_usable_uid_certs
 10.15      0.79     0.14    23060     0.01     0.01  find_prev_kbnode
  8.70      0.91     0.12 10690983     0.00     0.00  enum_sig_subpkt
  7.97      1.02     0.11     6639     0.02     0.02  iobuf_temp_with_content
  5.07      1.09     0.07     5498     0.01     0.02  get_pubkey_fast
  4.35      1.15     0.06   814348     0.00     0.00  parse_signature
  3.62      1.20     0.05   138747     0.00     0.00  tdbio_read_record
  2.90      1.24     0.04                             validate_keys.constprop.5
  2.17      1.27     0.03    65352     0.00     0.00  transform
  1.45      1.29     0.02   850030     0.00     0.00  dbg_parse_packet
  1.45      1.31     0.02   850030     0.00     0.00  free_packet
  0.72      1.32     0.01  1825225     0.00     0.00  parse_one_sig_subpkt
  0.72      1.33     0.01   827276     0.00     0.00  iobuf_skip_rest
  0.72      1.34     0.01    24280     0.00     0.00  check_signature_end


note that that's 2G calls to enum_sig_subpkt with --weak-digest SHA1 and
only 10M invocations without!

The top 3 items in the gprof callgraph summary are:

==> with-weak-sha1 <==
index % time    self  children    called     name
                                                 <spontaneous>
[1]     99.4    0.04  211.85                 validate_keys.constprop.5 [1]
                0.02  211.57       2/2           validate_key_list [2]
                0.09    0.11     727/70144       release_kbnode [14]
                0.00    0.03    1729/1729        update_validity [65]
                0.00    0.02       1/1           get_pubkeyblock [76]
                0.00    0.01       1/1           reset_trust_records [90]
                0.00    0.00     382/22568       tdbio_search_trust_bypk [42]
                0.00    0.00    5215/174077      keyid_from_pk [63]
                0.00    0.00       1/1           tdbio_update_version_record [102]
                0.00    0.00       1/1           tdbio_write_nextcheck [106]
                0.00    0.00       1/198670      keydb_release [62]
                0.00    0.00       1/198670      keydb_new [75]
                0.00    0.00     728/728         tdbio_sync [131]
                0.00    0.00     382/31371       init_trustdb [115]
                0.00    0.00       4/8           log_info [143]
                0.00    0.00       1/10544660     make_timestamp [111]
                0.00    0.00       1/1           keydb_rebuild_caches [160]
                0.00    0.00       1/1           strtimestamp [170]
-----------------------------------------------
                0.02  211.57       2/2           validate_keys.constprop.5 [1]
[2]     99.3    0.02  211.57       2         validate_key_list [2]
                0.48  110.46   14630/14630       mark_usable_uid_certs [9]
                0.20   84.45    5452/12567       get_pubkey_fast <cycle 1> [4]
                0.00   13.59    5452/69323       keydb_get_keyblock [5]
                0.69    0.86    5452/70144       release_kbnode [14]
                0.00    0.69    5454/5549        keydb_search [30]
                0.00    0.10   14630/22568       tdbio_search_trust_bypk [42]
                0.02    0.00    5452/5452        clear_kbnode_flags [71]
                0.00    0.02   14630/16359       namehash_from_uid [69]
                0.01    0.00   19544/171718      tdbio_read_record [45]
                0.00    0.00    6491/174077      keyid_from_pk [63]
                0.00    0.00       2/2           keydb_search_reset [108]
                0.00    0.00   29260/31371       init_trustdb [115]
                0.00    0.00    5452/5452        merge_keys_and_selfsig [127]
-----------------------------------------------
[3]     91.5    0.46  194.67   12567+180615  <cycle 1 as a whole> [3]
                0.43  187.68    5547+199354      get_pubkey_fast <cycle 1> [4]
                0.03    6.67  119456             check_key_signature2 <cycle 1> [20]
                0.00    0.28      95             lookup.constprop.11 <cycle 1> [35]
                0.00    0.03    6591             get_pubkey <cycle 1> [60]
                0.00    0.00    6591             check_signature2 <cycle 1> [99]
                0.00    0.00       2             check_revocation_keys <cycle 1> [107]
                0.00    0.00   54900             check_key_signature <cycle 1> [114]
-----------------------------------------------


==> without-weak-sha1 <==
index % time    self  children    called     name
                                                 <spontaneous>
[1]     99.9    0.04    1.34                 validate_keys.constprop.5 [1]
                0.01    1.31       2/2           validate_key_list [2]
                0.00    0.01    1993/1993        update_validity [26]
                0.00    0.00     823/6423        release_kbnode [22]
                0.00    0.00       1/1           reset_trust_records [32]
                0.00    0.00     408/16254       tdbio_search_trust_bypk [18]
                0.00    0.00       1/1           get_pubkeyblock [38]
                0.00    0.00     408/16254       tdbio_search_trust_bypk [18]
                0.00    0.00       1/1           get_pubkeyblock [38]
                0.00    0.00       1/1           tdbio_update_version_record [39]
                0.00    0.00       1/1           tdbio_write_nextcheck [45]
                0.00    0.00    5896/45984       keyid_from_pk [55]
                0.00    0.00     824/824         tdbio_sync [81]
                0.00    0.00     408/30107       init_trustdb [58]
                0.00    0.00       4/7           log_info [104]
                0.00    0.00       1/146691      make_timestamp [51]
                0.00    0.00       1/1           keydb_rebuild_caches [123]
                0.00    0.00       1/104         keydb_new [89]
                0.00    0.00       1/104         keydb_release [90]
                0.00    0.00       1/1           strtimestamp [134]
-----------------------------------------------
                0.01    1.31       2/2           validate_keys.constprop.5 [1]
[2]     95.6    0.01    1.31       2         validate_key_list [2]
                0.00    0.70    5395/5498        keydb_get_keyblock [3]
                0.25    0.15   13853/13853       mark_usable_uid_certs [7]
                0.03    0.08    5395/12407       get_pubkey_fast <cycle 1> [14]
                0.00    0.03   13853/16254       tdbio_search_trust_bypk [18]
                0.00    0.03   13853/15846       namehash_from_uid [20]
                0.01    0.02    5395/6423        release_kbnode [22]
                0.01    0.00   17549/138747      tdbio_read_record [16]
                0.00    0.00   27706/30107       init_trustdb [58]
                0.00    0.00    6517/45984       keyid_from_pk [55]
                0.00    0.00    5397/5500        keydb_search [73]
                0.00    0.00    5395/5395        merge_keys_and_selfsig [76]
                0.00    0.00    5395/5395        clear_kbnode_flags [75]
                0.00    0.00       2/2           keydb_search_reset [115]
-----------------------------------------------
                0.00    0.01     103/5498        lookup.constprop.11 <cycle 1> [25]
                0.00    0.70    5395/5498        validate_key_list [2]
[3]     52.1    0.00    0.72    5498         keydb_get_keyblock [3]
                0.01    0.62    5498/5498        parse_keyblock_image [4]
                0.00    0.09    5498/5498        keybox_get_keyblock [15]
                0.00    0.00   10996/17639       iobuf_close [63]
-----------------------------------------------


I can provide more info or do more debugging if it would be useful to
track this down?

Regards,

      --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/20160104/087263a1/attachment.sig>

From dkg at fifthhorseman.net  Tue Jan  5 06:11:07 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 05 Jan 2016 00:11:07 -0500
Subject: --weak-digest SHA1 causes significant slowdown in --check-trustdb
 (2.1.10)
In-Reply-To: <87mvsky7w6.fsf@alice.fifthhorseman.net>
References: <87mvsky7w6.fsf@alice.fifthhorseman.net>
Message-ID: <87fuycy5jo.fsf@alice.fifthhorseman.net>

On Mon 2016-01-04 23:20:25 -0500, Daniel Kahn Gillmor wrote:

> i'm running gnupg 2.1.10 with a large keybox (a couple thousand
> certificates).

a few more datapoints:

My first reports were from tests with ~/.gnupg/pubring.kbx alongside a
similarly-sized ~/.gnupg/pubring.gpg.

The keyring is ~91MiB and the keybox is ~93MiB in size.

I've cleared the trustdb between each test with:

   gpg2 --export-ownertrust > otrust.txt
   rm ~/.gnupg/trustdb.gpg
   gpg2 --import-ownertrust < otrust.txt

the explicit ownertrust db has only about a dozen entries: one ultimate
(6 in otrust.txt), a few marginals (4 in otrust.txt), a few explicitly
untrusted ("never", 3 in otrust.txt), and a few disabled keys (128 in
otrust.txt).

Subsequently, i tried with an empty ~/.gnupg/pubring.gpg while leaving
the keybox the same.  I got the same results as before:

           SHA1 OK: ~17s, mostly userland
--weak-digest SHA1: ~22m, ~half-kernelspace 

Then i tried creating a fresh pubring.gpg and moving the .kbx out of the
way.

With only a pubring.gpg and SHA1 OK (and a hot cache), i get ~20s, mostly userland:

real	0m20.369s
user	0m19.052s
sys	0m1.316s

With only a pubring.gpg and --weak-digest SHA1, i get about the same
thing:

real	0m20.265s
user	0m18.908s
sys	0m1.356s

So it appears to be an issue that only happens with a keybox and with
--weak-digest SHA1.

Hopefully these are helpful details,

    --dkg


From dkg at fifthhorseman.net  Tue Jan  5 06:36:05 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 05 Jan 2016 00:36:05 -0500
Subject: --weak-digest SHA1 causes significant slowdown in --check-trustdb
 (2.1.10)
In-Reply-To: <87fuycy5jo.fsf@alice.fifthhorseman.net>
References: <87mvsky7w6.fsf@alice.fifthhorseman.net>
 <87fuycy5jo.fsf@alice.fifthhorseman.net>
Message-ID: <87d1tgy4e2.fsf@alice.fifthhorseman.net>

On Tue 2016-01-05 00:11:07 -0500, Daniel Kahn Gillmor wrote:
> On Mon 2016-01-04 23:20:25 -0500, Daniel Kahn Gillmor wrote:
>
>> i'm running gnupg 2.1.10 with a large keybox (a couple thousand
>> certificates).
>
> a few more datapoints:
>
> My first reports were from tests with ~/.gnupg/pubring.kbx alongside a
> similarly-sized ~/.gnupg/pubring.gpg.
>
> The keyring is ~91MiB and the keybox is ~93MiB in size.

there are about 3100 certificates in the keyring.  And about 500 or 600
reachable via ownertrusted keys (depending on whether SHA1
certifications are acceptable or not).

I also just tried rebuilding the keybox from scratch, with:

gpg2 --export-ownertrust > otrust.txt
gpg2 --export-options export-local --export > keyring.backup
mv ~/.gnupg/pubring.kbx{,.bak}
mv ~/.gnupg/pubring.gpg{,.bak}
rm ~/.gnupg/trustdb.gpg
gpg2 --import-options import-local --import < keyring.backup
gpg2 --import-ownertrust < otrust.txt

and now the timings for --check-trustdb are:

SHA1 OK:

real	0m5.910s
user	0m4.720s
sys	0m1.188s

--weak-digest SHA1:

real	0m47.636s
user	0m12.352s
sys	0m35.288s


So with that explicit keybox rebuild, it's still significantly different
to rule out SHA1 certifications, but it's more like a power of 10 than a
power of 60.  And the userspace/kernelspace difference is still present.

        --dkg


From wk at gnupg.org  Tue Jan  5 11:59:04 2016
From: wk at gnupg.org (Werner Koch)
Date: Tue, 05 Jan 2016 11:59:04 +0100
Subject: --weak-digest SHA1 causes significant slowdown in --check-trustdb
 (2.1.10)
In-Reply-To: <87mvsky7w6.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Mon, 04 Jan 2016 23:20:25 -0500")
References: <87mvsky7w6.fsf@alice.fifthhorseman.net>
Message-ID: <87a8okl2br.fsf@vigenere.g10code.de>

On Tue,  5 Jan 2016 05:20, dkg at fifthhorseman.net said:

> With a hot filesystem cache, "gpg2 --check-trustdb" on its own takes
> about 17 seconds to run.

Can you please also try

  gpg2 --no-sig-cache --check-trustdb

I assume this will get you the same timing as with --weak-digest SHA1.
At least for my tests.

I tried a quick fix for this which improves the speed but it is not all
to it.


Shalom-Salam,

   Werner


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



From dkg at fifthhorseman.net  Tue Jan  5 17:42:13 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 05 Jan 2016 11:42:13 -0500
Subject: --weak-digest SHA1 causes significant slowdown in --check-trustdb
 (2.1.10)
In-Reply-To: <87a8okl2br.fsf@vigenere.g10code.de>
References: <87mvsky7w6.fsf@alice.fifthhorseman.net>
 <87a8okl2br.fsf@vigenere.g10code.de>
Message-ID: <8760z8vuze.fsf@alice.fifthhorseman.net>

On Tue 2016-01-05 05:59:04 -0500, Werner Koch wrote:
> On Tue,  5 Jan 2016 05:20, dkg at fifthhorseman.net said:
>
>> With a hot filesystem cache, "gpg2 --check-trustdb" on its own takes
>> about 17 seconds to run.
>
> Can you please also try
>
>   gpg2 --no-sig-cache --check-trustdb
>
> I assume this will get you the same timing as with --weak-digest SHA1.
> At least for my tests.

Hm, the sig-cache definitely speeds things up, but it seems orthogonal
to the --weak-digest SHA1 situation:

$ time gpg2 --check-trustdb
real	0m5.855s
user	0m4.652s
sys	0m1.200s
$ time gpg2 --weak-digest SHA1 --check-trustdb
real	0m51.010s
user	0m12.988s
sys	0m38.028s
$ time gpg2 --no-sig-cache --check-trustdb
real	0m30.979s
user	0m29.740s
sys	0m1.244s
$ time gpg2 --no-sig-cache --weak-digest SHA1 --check-trustdb
real	57m26.022s
user	26m57.472s
sys	30m28.892s
$

yikes!

I observe that the kernel/userspace split doesn't seem to be affected at
all by --no-sig-cache, either.

Regards,

        --dkg


From dgouttegattat at incenp.org  Tue Jan  5 19:33:51 2016
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Tue, 5 Jan 2016 19:33:51 +0100
Subject: On Scute v1.4.0 support key length up to 4096, proceed
 s-expressions on common way
In-Reply-To: <20160104102734.7495.38420@thinkbox.jade-hamburg.de>
References: <564CBD34.1030608@gurevich.de>
 <20160104102734.7495.38420@thinkbox.jade-hamburg.de>
Message-ID: <568C0C8F.8030802@incenp.org>

Hi Justus,

On 01/04/2016 11:27 AM, Justus Winter wrote:
> I did some work on Scute, among other things it should support larger
> keys now and support TLS1.2 (i.e. hash functions other than
> tls-md5sha1).

For information, with your recent changes I have been able to successfully

* authenticate to a TLS 1.2 web server with Firefox, but also
* sign S/MIME emails with Thunderbird,
* sign OpenDocument files with LibreOffice.

Nice work!

Damien

-------------- 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/20160105/83b5887c/attachment-0001.sig>

From wk at gnupg.org  Wed Jan  6 09:05:32 2016
From: wk at gnupg.org (Werner Koch)
Date: Wed, 06 Jan 2016 09:05:32 +0100
Subject: --weak-digest SHA1 causes significant slowdown in --check-trustdb
 (2.1.10)
In-Reply-To: <8760z8vuze.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Tue, 05 Jan 2016 11:42:13 -0500")
References: <87mvsky7w6.fsf@alice.fifthhorseman.net>
 <87a8okl2br.fsf@vigenere.g10code.de>
 <8760z8vuze.fsf@alice.fifthhorseman.net>
Message-ID: <874merjfoz.fsf@vigenere.g10code.de>

On Tue,  5 Jan 2016 17:42, dkg at fifthhorseman.net said:

> Hm, the sig-cache definitely speeds things up, but it seems orthogonal
> to the --weak-digest SHA1 situation:

Thanks.  This is consistent with my tests although my test setting is
simpler.  I need to setup a test similar to yours.


Shalom-Salam,

   Werner

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



From dkg at fifthhorseman.net  Wed Jan  6 10:44:24 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 06 Jan 2016 01:44:24 -0800
Subject: --weak-digest SHA1 causes significant slowdown in --check-trustdb
 (2.1.10)
In-Reply-To: <874merjfoz.fsf@vigenere.g10code.de>
References: <87mvsky7w6.fsf@alice.fifthhorseman.net>
 <87a8okl2br.fsf@vigenere.g10code.de> <8760z8vuze.fsf@alice.fifthhorseman.net>
 <874merjfoz.fsf@vigenere.g10code.de>
Message-ID: <87y4c3t53b.fsf@alice.fifthhorseman.net>

On Wed 2016-01-06 00:05:32 -0800, Werner Koch <wk at gnupg.org> wrote:
> On Tue,  5 Jan 2016 17:42, dkg at fifthhorseman.net said:
>
>> Hm, the sig-cache definitely speeds things up, but it seems orthogonal
>> to the --weak-digest SHA1 situation:
>
> Thanks.  This is consistent with my tests although my test setting is
> simpler.  I need to setup a test similar to yours.

fwiw, my test setup has a fair number of local (non-exportable)
certifications as well.  (i haven't counted how many of them are made
with SHA1) I don't know whether that has any relevance to the tests,
though.

here's a separate test that i ran using keys from the debian-keyring
package:

---------------
export GNUPGHOME="$(mktemp -d)"
otrust="$GNUPGHOME/otrust.txt"
gpgconf="$GNUPGHOME/gpg.conf"
echo no-auto-check-trustdb > "$gpgconf"
cat /usr/share/keyrings/* | gpg2 --import
add_trust() {
  count="$1"
  level="$2"

  for fpr in $(gpg2 --fingerprint --with-colons | \
               awk -F:  '/^fpr/{ print $10 }' | \
               sort -R | head -n "$count"); do
    printf '%s:%d:\n' "$fpr" "$level"
  done
}
echo '# randomly-generated ownertrust' > "$otrust"
add_trust 1 6    >> "$otrust" # one ultimate
add_trust 2 5    >> "$otrust" # two full
add_trust 3 4    >> "$otrust" # three marginal
add_trust 4 3    >> "$otrust" # four never
add_trust 5 128  >> "$otrust" # five disabled keys
try() {
 rm -f "$GNUPGHOME/trustdb.gpg"
 gpg2 --import-ownertrust < "$otrust" 2>/dev/null
 printf "==> gpg2 %s --check-trustdb <==\n" "$*"
 time gpg2 "$@" --check-trustdb
}
try
try --weak-digest SHA1
try --no-sig-cache
try --no-sig-cache  --weak-digest SHA1
---------------

interestingly, this shows severe performance degradation (and a lot of
kernel-space activity) the --no-sig-cache --weak-digest SHA1 case, but
doesn't show any degradation in the plain --weak-digest SHA1 case for
me.

The random otrust.txt i generated was:

--------
2517B724C5F6CA9953296E612FF9CD59612616B5:6:
F962EF7FBF67B18C96108BFAE7E6F782283D6300:5:
B82CDC351FC8191C3B75290DBE5CF687DC5AB7C2:5:
9A303F9907A03230D188B75A2EF5710914C6A712:4:
35E876FAB4D3732E93B4D237631DE7553BE8AFD4:4:
D95C32042EE54FFDB25EC3489F2733F40928D23A:4:
6791403B68AE2690517C42EAE6FFF1E38DC968B0:3:
5919FC3BDC30CE4135F1DC070F5E1ED4664196E2:3:
AC297E5C46B9D0B61C717681D6D09BE48405BBF6:3:
4C8F6B0D121EB15F076FEB1704EE131AE6D621BE:3:
8A7F208C6D9E73291657414D2135D123D8C19BEC:128:
AC297E5C46B9D0B61C717681D6D09BE48405BBF6:128:
4D1B7796C03E0831991BDD423F490DEB871EF9FA:128:
BBBD45EA818AB86FF67E7285D3E17383CFA7FF06:128:
276D7B77B69B756C7CB68669DD29F88442839ED3:128:
--------

and, also interestingly, i note that --weak-digest SHA1 --check-trustdb
thinks it can reach one fewer key with --no-sig-cache  is set :/

==> gpg2 --weak-digest SHA1 --check-trustdb <==
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: Note: signatures using the SHA1 algorithm are rejected
gpg: depth: 0  valid:   1  signed:   9  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1  valid:   9  signed: 283  trust: 9-, 0q, 0n, 0m, 0f, 0u
gpg: next trustdb check due at 2016-01-15


==> gpg2 --no-sig-cache --weak-digest SHA1 --check-trustdb <==
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: Note: signatures using the SHA1 algorithm are rejected
gpg: Note: signatures using the MD5 algorithm are rejected
gpg: depth: 0  valid:   1  signed:   9  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1  valid:   9  signed: 284  trust: 9-, 0q, 0n, 0m, 0f, 0u
gpg: next trustdb check due at 2016-01-15

sorry for just reporting weird corner cases here without helping to fix
them.

thanks for looking into it,

     --dkg


From neal at walfield.org  Wed Jan  6 11:13:06 2016
From: neal at walfield.org (Neal H. Walfield)
Date: Wed, 06 Jan 2016 11:13:06 +0100
Subject: [PATCH] fix keystrlen when no keyid-format option has been given
In-Reply-To: <87bn9ygtbt.fsf@vigenere.g10code.de>
References: <1449684064-18144-1-git-send-email-dkg@fifthhorseman.net>
 <87bn9ygtbt.fsf@vigenere.g10code.de>
Message-ID: <8760z7xbgt.wl-neal@walfield.org>

Hi Werner,

On Thu, 10 Dec 2015 17:29:58 +0100,
Werner Koch wrote:
> On Wed,  9 Dec 2015 19:01, dkg at fifthhorseman.net said:
> > * g10/keyid.c (keystrlen): if opt.keyid_format has not been set,
> >   default to 0xLONG, as is done in format_keyid.
> 
> > gpgv: Ohhhh jeeee: ... this is a bug (keyid.c:342:keystrlen)
> 
> Neal, why did you introduced the KF_DEFAULT at all?  I can't immediately
> the the reason.

In a052c30, I introduced format_keyid, which is a generalized keystr
and changed keystr to call it (passing OPT.KEYID_FORMAT as the desired
format).

In the next commit (11ec478), I use the ability to specify the format
in keydb_search_desc_dump to format the search descriptions.  Clearly,
if the search description is a long key id, we should print out a long
key id even if OPT.KEYID_FORMAT is KF_SHORT.

I'm not entirely sure why I introduced KF_DEFAULT.  It currently isn't
used.  I suspect my thinking was that it would be useful to pass
KF_DEFAULT to format_keyid instead of OPT.KEYID_FORMAT if the default
format is preferred, but I didn't bother to do that in keystr.

> While looking at the code I also wonder why we do this:
> 
>       if (keyid[0])
> 	snprintf (buffer, len, "%08lX%08lX",
>                   (ulong)keyid[0], (ulong)keyid[1]);
>       else
> 	snprintf (buffer, len, "%08lX", (ulong)keyid[1]);
>       break;
> 
> This break the column alignment for keyis 0x00000000xxxxxxxxx . Granted,
> this is a rare case but why should be do that at all, the commit message
> from 2004 says:
> 
>     * keyid.c (keystr): If printing a keyid that lacks the high 4 bytes, print
>     the low 4 alone. (keystr_from_desc): Handle short keyids and warn on v3
>     fingerprints.
> 
> However, last year I fixed the indentation in some messages to match the
> current keyid format - this requires that keyid has a constant length.

I wondered this myself and conservatively left the code alone.

:) Neal


From neal at walfield.org  Wed Jan  6 11:19:52 2016
From: neal at walfield.org (Neal H. Walfield)
Date: Wed, 06 Jan 2016 11:19:52 +0100
Subject: [PATCH] fix keystrlen when no keyid-format option has been given
In-Reply-To: <1449684064-18144-1-git-send-email-dkg@fifthhorseman.net>
References: <1449684064-18144-1-git-send-email-dkg@fifthhorseman.net>
Message-ID: <874merxb5j.wl-neal@walfield.org>

Hi Daniel,

Sorry for the delayed response.

On Wed, 09 Dec 2015 19:01:04 +0100,
Daniel Kahn Gillmor wrote:
> * g10/keyid.c (keystrlen): if opt.keyid_format has not been set,
>   default to 0xLONG, as is done in format_keyid.
> 
> --
> Without this fix, gpgv2 fails with:
> 
> gpgv: Ohhhh jeeee: ... this is a bug (keyid.c:342:keystrlen)
> 
> Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
> ---
>  g10/keyid.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/g10/keyid.c b/g10/keyid.c
> index cb237ef..bb5c7b9 100644
> --- a/g10/keyid.c
> +++ b/g10/keyid.c
> @@ -324,7 +324,11 @@ format_keyid (u32 *keyid, int format, char *buffer, int len)
>  size_t
>  keystrlen(void)
>  {
> -  switch(opt.keyid_format)
> +  int format = opt.keyid_format;
> +  if (format == KF_DEFAULT)
> +    format = KF_0xLONG;
> +
> +  switch(format)
>      {
>      case KF_SHORT:
>        return 8;

Do we want to change the default to 0xLONG?  Currently, gpg defaults
to SHORT.  I realized in format_keyid I have:

  if (format == KF_DEFAULT)
    format = KF_0xLONG;

But, at least for gpg, that is dead code and should probably be
KF_SHORT to reflect the actual behavior.

Thanks,

:) Neal


From neal at walfield.org  Wed Jan  6 11:36:06 2016
From: neal at walfield.org (Neal H. Walfield)
Date: Wed, 06 Jan 2016 11:36:06 +0100
Subject: Alignment issue of iobuf functions
In-Reply-To: <568B2201.6030805@fsij.org>
References: <568B2201.6030805@fsij.org>
Message-ID: <871t9vxaeh.wl-neal@walfield.org>

Hi Niibe,

On Tue, 05 Jan 2016 02:53:05 +0100,
NIIBE Yutaka wrote:
> Then, I see compiler warnings like:
> =========================
> ../../gnupg/common/iobuf.c: In function `file_filter':
> ../../gnupg/common/iobuf.c:581:8: warning: cast increases required
> alignment of target type [-Wcast-align]
>        *(char **) buf = "file_filter(fd)";
>         ^
> =========================
> 
> This is because of the argument BUF is declared as byte * and we cast
> to (char **), where the alignment condition for (byte *) and the one
> for (char **) could be different.  So, the warning is relevant.
> 
> I think that our usage of (byte *) here is actually (void *).  I'm not
> sure if changing to (void *) is better or not.

Unfortunately, we are overloading the buf parameter too much.

I'm guessing this is not the only warning that you getting for this,
right?  file_es_filter and block_filter, for instance, use the same
pattern.

:) Neal


From neal at walfield.org  Wed Jan  6 11:40:36 2016
From: neal at walfield.org (Neal H. Walfield)
Date: Wed, 06 Jan 2016 11:40:36 +0100
Subject: --weak-digest SHA1 causes significant slowdown in --check-trustdb
 (2.1.10)
In-Reply-To: <87y4c3t53b.fsf@alice.fifthhorseman.net>
References: <87mvsky7w6.fsf@alice.fifthhorseman.net>
 <87a8okl2br.fsf@vigenere.g10code.de>
 <8760z8vuze.fsf@alice.fifthhorseman.net>
 <874merjfoz.fsf@vigenere.g10code.de>
 <87y4c3t53b.fsf@alice.fifthhorseman.net>
Message-ID: <87ziwjvvmj.wl-neal@walfield.org>

Hi Daniel,

On Wed, 06 Jan 2016 10:44:24 +0100,
Daniel Kahn Gillmor wrote:
> and, also interestingly, i note that --weak-digest SHA1 --check-trustdb
> thinks it can reach one fewer key with --no-sig-cache  is set :/
> 
> ==> gpg2 --weak-digest SHA1 --check-trustdb <==
> gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
> gpg: Note: signatures using the SHA1 algorithm are rejected
> gpg: depth: 0  valid:   1  signed:   9  trust: 0-, 0q, 0n, 0m, 0f, 1u
> gpg: depth: 1  valid:   9  signed: 283  trust: 9-, 0q, 0n, 0m, 0f, 0u
> gpg: next trustdb check due at 2016-01-15
> 
> 
> ==> gpg2 --no-sig-cache --weak-digest SHA1 --check-trustdb <==
> gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
> gpg: Note: signatures using the SHA1 algorithm are rejected
> gpg: Note: signatures using the MD5 algorithm are rejected
> gpg: depth: 0  valid:   1  signed:   9  trust: 0-, 0q, 0n, 0m, 0f, 1u
> gpg: depth: 1  valid:   9  signed: 284  trust: 9-, 0q, 0n, 0m, 0f, 0u
> gpg: next trustdb check due at 2016-01-15
> 
> sorry for just reporting weird corner cases here without helping to fix
> them.

Ouch!  I appreciate you not only reporting this bug, but providing a
reproducible test case!

Unfortunately, the caches in gpg are often not completely transparent.
Finding the corner cases is hard and, thus far, consistent with "don't
change a working system," we've been conservative in fixing their
semantics.  I think this provides strong evidence that we really need
to nail down the caches so that they are transparent.

Thanks!

:) Neal


From oleg at gurevich.de  Wed Jan  6 13:12:24 2016
From: oleg at gurevich.de (Oleg Gurevich)
Date: Wed, 6 Jan 2016 13:12:24 +0100
Subject: On Scute v1.4.0 support key length up to 4096, proceed
 s-expressions on common way
In-Reply-To: <20160104102734.7495.38420@thinkbox.jade-hamburg.de>
References: <564CBD34.1030608@gurevich.de>
 <20160104102734.7495.38420@thinkbox.jade-hamburg.de>
Message-ID: <568D04A8.4020103@gurevich.de>

Hi Justus,

thank you for your work. It works for me fine with GnuPG modern. Lot of respect.



Mit freundlichen Gr??en/ ? ?????????/ best regards

Oleg Gurevich


On 01/04/2016 11:27 AM, Justus Winter wrote:
> Hi Oleg,
> 
> I did some work on Scute, among other things it should support larger
> keys now and support TLS1.2 (i.e. hash functions other than
> tls-md5sha1).  Would you be so kind to see if that fixes the issues
> you were having?
> 
> Thanks,
> Justus
> 


From wk at gnupg.org  Wed Jan  6 13:26:47 2016
From: wk at gnupg.org (Werner Koch)
Date: Wed, 06 Jan 2016 13:26:47 +0100
Subject: [PATCH] fix keystrlen when no keyid-format option has been given
In-Reply-To: <874merxb5j.wl-neal@walfield.org> (Neal H. Walfield's message of
 "Wed, 06 Jan 2016 11:19:52 +0100")
References: <1449684064-18144-1-git-send-email-dkg@fifthhorseman.net>
 <874merxb5j.wl-neal@walfield.org>
Message-ID: <87fuyaj3lk.fsf@vigenere.g10code.de>

On Wed,  6 Jan 2016 11:19, neal at walfield.org said:

> Do we want to change the default to 0xLONG?  Currently, gpg defaults

Better not; it will break too much existing installations (yeah, they
should use --with-colons, but reality isdifferent).  However, what we
can do is to put

keyid-format long

into gpg-conf.skel so that the long format is used for new
installations.


Salam-Shalom,

   Werner

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



From gniibe at fsij.org  Fri Jan  8 03:16:10 2016
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Fri, 8 Jan 2016 11:16:10 +0900
Subject: Alignment issue of iobuf functions
In-Reply-To: <871t9vxaeh.wl-neal@walfield.org>
References: <568B2201.6030805@fsij.org> <871t9vxaeh.wl-neal@walfield.org>
Message-ID: <568F1BEA.4040605@fsij.org>

Hello, again,

On 01/06/2016 07:36 PM, Neal H. Walfield wrote:
> Unfortunately, we are overloading the buf parameter too much.

Yesterday's version which changes byte * to void * was lost in the SMTP
communication.  I make another version, which avoids overloading.

Instead of returning the pointer to string, it fills the description
to the buffer.  Since IOBUFCTRL_DESC is only used for debugging
purpose, this small change of behavior is OK, I suppose.

The API of the function iobuf_desc is somewhat ugly.  And I don't like
strncpy in general, though.  Since it is an internal function, the
impact of iobuf_desc ugliness is limited to common/iobuf.c.  I think
that we can pay something like that for the justice of compiler type
checking and its benefits.

Since this change is needed to GnuPG 1.4 and 2.0 as well, I'd like
to confirm if this patch is OK to commit.

For me, I prefer this one to the change (byte *) -> (void *), even
with small change of runtime behavior.


diff --git a/common/iobuf.c b/common/iobuf.c
index d149e2e..d12252c 100644
--- a/common/iobuf.c
+++ b/common/iobuf.c
@@ -578,7 +578,7 @@ file_filter (void *opaque, int control, iobuf_t
chain, byte * buf,
     }
   else if (control == IOBUFCTRL_DESC)
     {
-      *(char **) buf = "file_filter(fd)";
+      strncpy (buf, "file_filter(fd)", *ret_len);
     }
   else if (control == IOBUFCTRL_FREE)
     {
@@ -667,7 +667,7 @@ file_es_filter (void *opaque, int control, iobuf_t
chain, byte * buf,
     }
   else if (control == IOBUFCTRL_DESC)
     {
-      *(char **) buf = "estream_filter";
+      strncpy (buf, "estream_filter", *ret_len);
     }
   else if (control == IOBUFCTRL_FREE)
     {
@@ -765,7 +765,7 @@ sock_filter (void *opaque, int control, iobuf_t
chain, byte * buf,
     }
   else if (control == IOBUFCTRL_DESC)
     {
-      *(char **) buf = "sock_filter";
+      strncpy (buf, "sock_filter", *ret_len);
     }
   else if (control == IOBUFCTRL_FREE)
     {
@@ -993,7 +993,7 @@ block_filter (void *opaque, int control, iobuf_t
chain, byte * buffer,
     }
   else if (control == IOBUFCTRL_DESC)
     {
-      *(char **) buf = "block_filter";
+      strncpy (buf, "block_filter", *ret_len);
     }
   else if (control == IOBUFCTRL_FREE)
     {
@@ -1057,19 +1057,25 @@ block_filter (void *opaque, int control, iobuf_t
chain, byte * buffer,
   return rc;
 }

+#define MAX_IOBUF_DESC 32
+/*
+ * Fill the buffer by the description of iobuf A.
+ * The buffer size should be MAX_IOBUF_DESC (or larger).
+ * Returns BUF as (const char *).
+ */
 static const char *
-iobuf_desc (iobuf_t a)
+iobuf_desc (iobuf_t a, byte *buf)
 {
-  size_t dummy_len = 0;
-  const char *desc = "?";
+  size_t len = MAX_IOBUF_DESC - 1;

-  if (! a || ! a->filter)
-    return desc;
+  buf[MAX_IOBUF_DESC - 1] = '\0';

-  a->filter (a->filter_ov, IOBUFCTRL_DESC, NULL,
-	     (byte *) & desc, &dummy_len);
+  if (! a || ! a->filter)
+    memcpy (buf, "?", 2);
+  else
+    a->filter (a->filter_ov, IOBUFCTRL_DESC, NULL, buf, &len);

-  return desc;
+  return buf;
 }

 static void
@@ -1079,9 +1085,10 @@ print_chain (iobuf_t a)
     return;
   for (; a; a = a->chain)
     {
+      byte desc[MAX_IOBUF_DESC];

       log_debug ("iobuf chain: %d.%d '%s' filter_eof=%d start=%d len=%d\n",
-		 a->no, a->subno, iobuf_desc (a), a->filter_eof,
+		 a->no, a->subno, iobuf_desc (a, desc), a->filter_eof,
 		 (int) a->d.start, (int) a->d.len);
     }
 }
@@ -1126,6 +1133,7 @@ iobuf_close (iobuf_t a)

   for (; a; a = a_chain)
     {
+      byte desc[MAX_IOBUF_DESC];
       int rc2 = 0;

       a_chain = a->chain;
@@ -1135,7 +1143,7 @@ iobuf_close (iobuf_t a)

       if (DBG_IOBUF)
 	log_debug ("iobuf-%d.%d: close '%s'\n",
-		   a->no, a->subno, iobuf_desc (a));
+		   a->no, a->subno, iobuf_desc (a, desc));

       if (a->filter && (rc2 = a->filter (a->filter_ov, IOBUFCTRL_FREE,
 					 a->chain, NULL, &dummy_len)))
@@ -1275,6 +1283,7 @@ do_open (const char *fname, int special_filenames,
   size_t len = 0;
   int print_only = 0;
   int fd;
+  byte desc[MAX_IOBUF_DESC];

   assert (use == IOBUF_INPUT || use == IOBUF_OUTPUT);

@@ -1321,7 +1330,7 @@ do_open (const char *fname, int special_filenames,
   file_filter (fcx, IOBUFCTRL_INIT, NULL, NULL, &len);
   if (DBG_IOBUF)
     log_debug ("iobuf-%d.%d: open '%s' desc=%s fd=%d\n",
-	       a->no, a->subno, fname, iobuf_desc (a), FD2INT (fcx->fp));
+	       a->no, a->subno, fname, iobuf_desc (a, desc), FD2INT (fcx->fp));

   return a;
 }
@@ -1439,6 +1448,8 @@ iobuf_sockopen (int fd, const char *mode)
 int
 iobuf_ioctl (iobuf_t a, iobuf_ioctl_t cmd, int intval, void *ptrval)
 {
+  byte desc[MAX_IOBUF_DESC];
+
   if (cmd == IOBUF_IOCTL_KEEP_OPEN)
     {
       /* Keep system filepointer/descriptor open.  This was used in
@@ -1446,7 +1457,7 @@ iobuf_ioctl (iobuf_t a, iobuf_ioctl_t cmd, int
intval, void *ptrval)
          anymore.  */
       if (DBG_IOBUF)
 	log_debug ("iobuf-%d.%d: ioctl '%s' keep_open=%d\n",
-		   a ? a->no : -1, a ? a->subno : -1, iobuf_desc (a),
+		   a ? a->no : -1, a ? a->subno : -1, iobuf_desc (a, desc),
 		   intval);
       for (; a; a = a->chain)
 	if (!a->chain && a->filter == file_filter)
@@ -1480,7 +1491,7 @@ iobuf_ioctl (iobuf_t a, iobuf_ioctl_t cmd, int
intval, void *ptrval)
     {
       if (DBG_IOBUF)
 	log_debug ("iobuf-%d.%d: ioctl '%s' no_cache=%d\n",
-		   a ? a->no : -1, a ? a->subno : -1, iobuf_desc (a),
+		   a ? a->no : -1, a ? a->subno : -1, iobuf_desc (a, desc),
 		   intval);
       for (; a; a = a->chain)
 	if (!a->chain && a->filter == file_filter)
@@ -1658,8 +1669,9 @@ iobuf_push_filter2 (iobuf_t a,

   if (DBG_IOBUF)
     {
+      byte desc[MAX_IOBUF_DESC];
       log_debug ("iobuf-%d.%d: push '%s'\n",
-		 a->no, a->subno, iobuf_desc (a));
+		 a->no, a->subno, iobuf_desc (a, desc));
       print_chain (a);
     }

@@ -1681,10 +1693,11 @@ pop_filter (iobuf_t a, int (*f) (void *opaque,
int control,
   iobuf_t b;
   size_t dummy_len = 0;
   int rc = 0;
+  byte desc[MAX_IOBUF_DESC];

   if (DBG_IOBUF)
     log_debug ("iobuf-%d.%d: pop '%s'\n",
-	       a->no, a->subno, iobuf_desc (a));
+	       a->no, a->subno, iobuf_desc (a, desc));
   if (a->use == IOBUF_INPUT_TEMP || a->use == IOBUF_OUTPUT_TEMP)
     {
       /* This should be the last filter in the pipeline.  */
@@ -2188,6 +2201,7 @@ iobuf_write_temp (iobuf_t dest, iobuf_t source)
 size_t
 iobuf_temp_to_buffer (iobuf_t a, byte * buffer, size_t buflen)
 {
+  byte desc[MAX_IOBUF_DESC];
   size_t n;

   while (1)
@@ -2195,7 +2209,7 @@ iobuf_temp_to_buffer (iobuf_t a, byte * buffer,
size_t buflen)
       int rc = filter_flush (a);
       if (rc)
 	log_bug ("Flushing iobuf %d.%d (%s) from iobuf_temp_to_buffer failed.
 Ignoring.\n",
-		 a->no, a->subno, iobuf_desc (a));
+		 a->no, a->subno, iobuf_desc (a, desc));
       if (! a->chain)
 	break;
       a = a->chain;
diff --git a/common/iobuf.h b/common/iobuf.h
index cb79105..69764d6 100644
--- a/common/iobuf.h
+++ b/common/iobuf.h
@@ -404,10 +404,10 @@ int iobuf_cancel (iobuf_t iobuf);
        called on the pipeline.

      IOBUFCTRL_DESC: Called with this value to get a human-readable
-       description of the filter.  * (char **) BUF should set to the
-       NUL-terminated string.  Note: you need to keep track of this
-       value and, if necessary, free it when the filter function is
-       called with control set to IOBUFCTRL_FREE.
+       description of the filter.  *LEN is the size of the buffer.
+       The description is filled into BUF, NUL-terminated.  Always
+       returns 0.  When the size of the buffer is shorter than the
+       description, it is truncated and not NUL-terminated.
   */
 int iobuf_push_filter (iobuf_t a, int (*f) (void *opaque, int control,
 					    iobuf_t chain, byte * buf,
diff --git a/common/t-iobuf.c b/common/t-iobuf.c
index 99581b9..4b5c935 100644
--- a/common/t-iobuf.c
+++ b/common/t-iobuf.c
@@ -16,7 +16,7 @@ every_other_filter (void *opaque, int control,

   if (control == IOBUFCTRL_DESC)
     {
-      *(char **) buf = "every_other_filter";
+      strncpy (buf, "every_other_filter", *len);
     }
   if (control == IOBUFCTRL_UNDERFLOW)
     {
@@ -52,7 +52,7 @@ double_filter (void *opaque, int control,

   if (control == IOBUFCTRL_DESC)
     {
-      * (char **) buf = "double_filter";
+      strncpy (buf, "double_filter", *len);
     }
   if (control == IOBUFCTRL_FLUSH)
     {
diff --git a/g10/armor.c b/g10/armor.c
index 6c133a2..e468e7e 100644
--- a/g10/armor.c
+++ b/g10/armor.c
@@ -1251,7 +1251,7 @@ armor_filter( void *opaque, int control,
         release_armor_context (afx);
     }
     else if( control == IOBUFCTRL_DESC )
-	*(char**)buf = "armor_filter";
+        strncpy (buf, "armor_filter", *ret_len);
     return rc;
 }

diff --git a/g10/cipher.c b/g10/cipher.c
index b72b144..d47d52b 100644
--- a/g10/cipher.c
+++ b/g10/cipher.c
@@ -157,7 +157,7 @@ cipher_filter( void *opaque, int control,
 	gcry_cipher_close (cfx->cipher_hd);
     }
     else if( control == IOBUFCTRL_DESC ) {
-	*(char**)buf = "cipher_filter";
+        strncpy (buf, "cipher_filter", *ret_len);
     }
     return rc;
 }
diff --git a/g10/compress-bz2.c b/g10/compress-bz2.c
index ea80956..d684c51 100644
--- a/g10/compress-bz2.c
+++ b/g10/compress-bz2.c
@@ -248,6 +248,6 @@ compress_filter_bz2( void *opaque, int control,
 	zfx->release (zfx);
     }
   else if( control == IOBUFCTRL_DESC )
-    *(char**)buf = "compress_filter";
+    strncpy (buf, "compress_filter", *ret_len);
   return rc;
 }
diff --git a/g10/compress.c b/g10/compress.c
index 8047dbb..e5819db 100644
--- a/g10/compress.c
+++ b/g10/compress.c
@@ -288,7 +288,7 @@ compress_filter( void *opaque, int control,
           zfx->release (zfx);
     }
     else if( control == IOBUFCTRL_DESC )
-	*(char**)buf = "compress_filter";
+        strncpy (buf, "compress_filter", *ret_len);
     return rc;
 }
 #endif /*HAVE_ZIP*/
diff --git a/g10/decrypt-data.c b/g10/decrypt-data.c
index 2d9f54f..a46f366 100644
--- a/g10/decrypt-data.c
+++ b/g10/decrypt-data.c
@@ -425,7 +425,7 @@ mdc_decode_filter (void *opaque, int control, IOBUF a,
     }
   else if ( control == IOBUFCTRL_DESC )
     {
-      *(char**)buf = "mdc_decode_filter";
+      strncpy (buf, "mdc_decode_filter", *ret_len);
     }
   return rc;
 }
@@ -496,7 +496,7 @@ decode_filter( void *opaque, int control, IOBUF a,
byte *buf, size_t *ret_len)
     }
   else if ( control == IOBUFCTRL_DESC )
     {
-      *(char**)buf = "decode_filter";
+      strncpy (buf, "decode_filter", *ret_len);
     }
   return rc;
 }
diff --git a/g10/encrypt.c b/g10/encrypt.c
index eca1c27..afeaf28 100644
--- a/g10/encrypt.c
+++ b/g10/encrypt.c
@@ -848,7 +848,7 @@ encrypt_filter (void *opaque, int control,
     }
   else if ( control == IOBUFCTRL_DESC )
     {
-      *(char**)buf = "encrypt_filter";
+      strncpy (buf, "encrypt_filter", *ret_len);
     }
   return rc;
 }
diff --git a/g10/mdfilter.c b/g10/mdfilter.c
index 708bdcd..2c3b2ec 100644
--- a/g10/mdfilter.c
+++ b/g10/mdfilter.c
@@ -58,7 +58,7 @@ md_filter( void *opaque, int control,
 	*ret_len = i;
     }
     else if( control == IOBUFCTRL_DESC )
-	*(char**)buf = "md_filter";
+        strncpy (buf, "md_filter", *ret_len);
     return rc;
 }

diff --git a/g10/progress.c b/g10/progress.c
index ca20223..e8159e9 100644
--- a/g10/progress.c
+++ b/g10/progress.c
@@ -131,7 +131,7 @@ progress_filter (void *opaque, int control,
       release_progress_context (pfx);
     }
   else if (control == IOBUFCTRL_DESC)
-    *(char**)buf = "progress_filter";
+    strncpy (buf, "progress_filter", *ret_len);
   return rc;
 }

diff --git a/g10/textfilter.c b/g10/textfilter.c
index 394d9c3..dbef2af 100644
--- a/g10/textfilter.c
+++ b/g10/textfilter.c
@@ -150,7 +150,7 @@ text_filter( void *opaque, int control,
 	tfx->buffer = NULL;
     }
     else if( control == IOBUFCTRL_DESC )
-	*(char**)buf = "text_filter";
+        strncpy (buf, "text_filter", *ret_len);
     return rc;
 }

--


From wk at gnupg.org  Fri Jan  8 12:19:57 2016
From: wk at gnupg.org (Werner Koch)
Date: Fri, 08 Jan 2016 12:19:57 +0100
Subject: Alignment issue of iobuf functions
In-Reply-To: <568F1BEA.4040605@fsij.org> (NIIBE Yutaka's message of "Fri, 8
 Jan 2016 11:16:10 +0900")
References: <568B2201.6030805@fsij.org> <871t9vxaeh.wl-neal@walfield.org>
 <568F1BEA.4040605@fsij.org>
Message-ID: <87bn8wgvxe.fsf@vigenere.g10code.de>

On Fri,  8 Jan 2016 03:16, gniibe at fsij.org said:

> The API of the function iobuf_desc is somewhat ugly.  And I don't like
> strncpy in general, though.  Since it is an internal function, the

Please use mem2str instead:

   char *mem2str (char *dest, const void *src, size_t n);

   This function is similar to strncpy().  However it won't copy more
   than N - 1 characters and makes sure that a '\0' is appended. With
   N given as 0, nothing will happen.  With DEST given as NULL, memory
   will be allocated using xmalloc (i.e. if it runs out of core
   the function terminates).  Returns DES or a pointer to the
   allocated memory.

> Since this change is needed to GnuPG 1.4 and 2.0 as well, I'd like
> to confirm if this patch is OK to commit.

I don't see a reason to backport it to 2.0.


Salam-Shalom,

   Werner

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



From dashohoxha at gmail.com  Fri Jan  8 23:26:06 2016
From: dashohoxha at gmail.com (Dashamir Hoxha)
Date: Fri, 8 Jan 2016 23:26:06 +0100
Subject: Secret Sharing in GPG
Message-ID: <CAMucfLwLHJiFXwjA8Rc1j8a-ohfOnvs_JrtfzubmVGu-QEO6sA@mail.gmail.com>

Hi,

I think that secret sharing in GPG would be quite a useful feature.
The idea is to split the secret key into 3 (or more) parts, so that any
two parts are enough to reconstruct the original secret key, but any
one of them alone is not sufficient to reconstruct it.

There is already a free library and tool that has an implementation of it:
 - http://point-at-infinity.org/ssss/
If someone wants to do shared secrets he can use both gpg and
ssss-split/ssss-combine. Or he can can write wrapper shell scripts
that combine both of them.
However it would be more convenient if gpg can do it out of the box.

I think that using secret sharing has some advantages. For example
imagine some scenarios like these:

 - A user generates a new key and he tells `gpg` to share the secret key
   (or it can be the default option). Then `gpg` saves a share of the key
locally,
   saves another share on a removabe device (smard card or usb), and uploads
   a third share somewhere on the cloud, where only the user has access.

 - When the user needs to do something with the private key (sign or
decrypt),
   he has to insert first the removable device with the key share. Then
`gpg`
   will combine this share with the one stored locally, will reconstruct
the private
   key, will use it, and then will erase the key again.

 - If somebody gets temporary access to your removable device, they cannot
   find your private key, because the one share that is stored in it is not
enough
   to reconstruct the private key. The same if someone gets access to your
   computer. They need to have access both to your computer and your dongle
   in order to be able to sign with your key, and then maybe they will also
need
   to know the passphrase of the private key.

   The same can be said if somebody gets access to the share of the key that
   is stored on the cloud. They need to get another share (either the
dongle or
   your pc), in order to reconstruct the key.

 - If the dongle is lost or stolen, your private key is not compromised.
   In this case you can get the share of the key from the cloud, combine it
   with the share of the key on the pc in order to reconstruct the key,
   then rigenerate three new shares: one for the pc, one for the dongle
   and one for the cloud, and delete the old shares from the pc and the
cloud.
   Destroying the old shares effectively invalidates the lost share, because
   alone it is useless for reconstructing the key.

 - If the pc is lost or changed, you can get the share stored on the cloud,
   combine it with the share stored on the dongle, reconstruct the key,
   rigenerate three new shares, store them on the pc, dongle and cloud,
   and finally delete the old shares from the dongle and the cloud.

I think that this would make key management safer and more robust.
Maybe it is not the ultimate solution, but at least it could prevent some
cases like loosing the private key because you lost the smart-card,
or because you changed the pc and forgot to transfer the keys from
the old one to the new one (or you just lost the pc).

I hope that the idea that I am trying to explain is clear, but if needed I
may
also try to draw some diagrams, to make it easier to understand.

However I have no idea about how this can be implemented on GPG, or how
to get started. I even know a student who is interested in trying to
implement
this as his master project, I have promissed to help and guide him, but I
am not
able to give him any advice or hint at all about how to get started.

Would somebody be willing to help and guide this student to implement this?
Or maybe this should be managed as a "Google Summer of Code" project?

Thanks and regards,
Dashamir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20160108/bb9515fa/attachment.html>

From wk at gnupg.org  Sat Jan  9 11:40:03 2016
From: wk at gnupg.org (Werner Koch)
Date: Sat, 09 Jan 2016 11:40:03 +0100
Subject: gpgkey2ssh has gone, --export-ssh-key is here.
Message-ID: <8760z3ghoc.fsf@vigenere.g10code.de>

Hi!

gpgkey2ssh was more or less a debugging tool but turned out to be useful
to many.  However, it was pretty limited and did not support modern ssh
keys.  An easier solution to export OpenPGP's public keys in the SSH
public key format is by adding a command to gpg.  This has now been done
in master: 

  --export-ssh-key

    This command is used to export a key in the OpenSSH public key
    format.  It requires the specification of one key by the usual
    means and exports the lat- est valid subkey which has an
    authentication capability to STDOUT or to the file given with
    option --output.  That output can directly be added to ssh's
    'authorized_key' file.

    By specifying the key to export using a key ID or a fingerprint
    suffixed with an exclamation mark (!), a specific subkey or the
    primary key can be exported.  This does not even require that
    the key has the authentication capability flag set.  To view the
    capability flags of a key use --list- options show-usage along
    with a key listing command.



Shalom-Salam,

   Werner

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



From dkg at fifthhorseman.net  Sat Jan  9 16:59:40 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sat, 09 Jan 2016 07:59:40 -0800
Subject: gpgkey2ssh has gone, --export-ssh-key is here.
In-Reply-To: <8760z3ghoc.fsf@vigenere.g10code.de>
References: <8760z3ghoc.fsf@vigenere.g10code.de>
Message-ID: <87d1tapwur.fsf@alice.fifthhorseman.net>

On Sat 2016-01-09 02:40:03 -0800, Werner Koch wrote:

>   --export-ssh-key

Very cool, thanks for doing this!

     --dkg


From sergi at calcurco.cat  Sat Jan  9 21:52:03 2016
From: sergi at calcurco.cat (=?UTF-8?Q?Sergi_Blanch-Torn=c3=a9?=)
Date: Sat, 9 Jan 2016 21:52:03 +0100
Subject: Secret Sharing in GPG
In-Reply-To: <CAMucfLwLHJiFXwjA8Rc1j8a-ohfOnvs_JrtfzubmVGu-QEO6sA@mail.gmail.com>
References: <CAMucfLwLHJiFXwjA8Rc1j8a-ohfOnvs_JrtfzubmVGu-QEO6sA@mail.gmail.com>
Message-ID: <569172F3.7030402@calcurco.cat>

Hello Dashamir,

I think you have pointer many scenarios. Perhaps they can be reduced.
The key generation in a (k,n)-threshold, I think, should be made at
once. The key is the 'n' elements produced as an output. Later when the
secret key will be used, only 'k' fragments are needed to recover the
secret. (k<=n)

Correct me if I'm wrong, but to open the locker, the 'k' elements needed
have to be present at the same time to recover the secret that will be
used like a secret key for the cryptographic operation. Perhaps there
are some research that proposes how it can be made with offline
interaction between the participants. Besides that, I'm not sure if your
idea is only for a single user with a key split in many places.

You can do a code proposal based on the schema of secret sharing. But be
sure to learn in an early stage how to proceed for an appropriate
contribution. Imho, it should follow an standardization process and peer
review. My contribution, long a go, didn't follow well the path and I
think this has slowed the process to have it publicly available.

Regards

/Sergi.

On 08/01/16 23:26, Dashamir Hoxha wrote:
> Hi,
> 
> I think that secret sharing in GPG would be quite a useful feature.
> The idea is to split the secret key into 3 (or more) parts, so that any
> two parts are enough to reconstruct the original secret key, but any
> one of them alone is not sufficient to reconstruct it.
> 
> There is already a free library and tool that has an implementation of it:
>  - http://point-at-infinity.org/ssss/
> If someone wants to do shared secrets he can use both gpg and
> ssss-split/ssss-combine. Or he can can write wrapper shell scripts
> that combine both of them.
> However it would be more convenient if gpg can do it out of the box.
> 
> I think that using secret sharing has some advantages. For example
> imagine some scenarios like these:
> 
>  - A user generates a new key and he tells `gpg` to share the secret key
>    (or it can be the default option). Then `gpg` saves a share of the
> key locally,
>    saves another share on a removabe device (smard card or usb), and uploads
>    a third share somewhere on the cloud, where only the user has access.
> 
>  - When the user needs to do something with the private key (sign or
> decrypt),
>    he has to insert first the removable device with the key share. Then
> `gpg`
>    will combine this share with the one stored locally, will reconstruct
> the private
>    key, will use it, and then will erase the key again.
> 
>  - If somebody gets temporary access to your removable device, they cannot
>    find your private key, because the one share that is stored in it is
> not enough
>    to reconstruct the private key. The same if someone gets access to your
>    computer. They need to have access both to your computer and your dongle
>    in order to be able to sign with your key, and then maybe they will
> also need
>    to know the passphrase of the private key.
> 
>    The same can be said if somebody gets access to the share of the key that
>    is stored on the cloud. They need to get another share (either the
> dongle or
>    your pc), in order to reconstruct the key. 
> 
>  - If the dongle is lost or stolen, your private key is not compromised.
>    In this case you can get the share of the key from the cloud, combine it
>    with the share of the key on the pc in order to reconstruct the key,
>    then rigenerate three new shares: one for the pc, one for the dongle
>    and one for the cloud, and delete the old shares from the pc and the
> cloud.
>    Destroying the old shares effectively invalidates the lost share, because
>    alone it is useless for reconstructing the key.
> 
>  - If the pc is lost or changed, you can get the share stored on the cloud,
>    combine it with the share stored on the dongle, reconstruct the key,
>    rigenerate three new shares, store them on the pc, dongle and cloud,
>    and finally delete the old shares from the dongle and the cloud.
> 
> I think that this would make key management safer and more robust.
> Maybe it is not the ultimate solution, but at least it could prevent some
> cases like loosing the private key because you lost the smart-card,
> or because you changed the pc and forgot to transfer the keys from
> the old one to the new one (or you just lost the pc).
> 
> I hope that the idea that I am trying to explain is clear, but if needed
> I may
> also try to draw some diagrams, to make it easier to understand.
> 
> However I have no idea about how this can be implemented on GPG, or how
> to get started. I even know a student who is interested in trying to
> implement
> this as his master project, I have promissed to help and guide him, but
> I am not
> able to give him any advice or hint at all about how to get started.
> 
> Would somebody be willing to help and guide this student to implement this?
> Or maybe this should be managed as a "Google Summer of Code" project?
> 
> Thanks and regards,
> Dashamir
> 
> 
> 
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
> 

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

From dashohoxha at gmail.com  Sat Jan  9 22:10:27 2016
From: dashohoxha at gmail.com (Dashamir Hoxha)
Date: Sat, 9 Jan 2016 22:10:27 +0100
Subject: Secret Sharing in GPG
In-Reply-To: <569172F3.7030402@calcurco.cat>
References: <CAMucfLwLHJiFXwjA8Rc1j8a-ohfOnvs_JrtfzubmVGu-QEO6sA@mail.gmail.com>
 <569172F3.7030402@calcurco.cat>
Message-ID: <56917743.6040500@gmail.com>



On 01/09/2016 09:52 PM, Sergi Blanch-Torn? wrote:
> Hello Dashamir,
> 
> I think you have pointer many scenarios. Perhaps they can be reduced.
> The key generation in a (k,n)-threshold, I think, should be made at
> once. The key is the 'n' elements produced as an output. Later when the
> secret key will be used, only 'k' fragments are needed to recover the
> secret. (k<=n)
> 
> Correct me if I'm wrong, but to open the locker, the 'k' elements needed
> have to be present at the same time to recover the secret that will be
> used like a secret key for the cryptographic operation. Perhaps there
> are some research that proposes how it can be made with offline
> interaction between the participants. Besides that, I'm not sure if your
> idea is only for a single user with a key split in many places.

Yes, my idea is for a single user, with a key split in 3 (or more)
places. Then any two pieces need to be present in order to use the
private key. Similar to 2-step verification, but technically different.

> 
> You can do a code proposal based on the schema of secret sharing. But be
> sure to learn in an early stage how to proceed for an appropriate
> contribution. Imho, it should follow an standardization process and peer

I expect help on this (code proposal, process, etc.)

Regards,
Dashamir

> review. My contribution, long a go, didn't follow well the path and I
> think this has slowed the process to have it publicly available.
> 
> Regards
> 
> /Sergi.
> 
> On 08/01/16 23:26, Dashamir Hoxha wrote:
>> Hi,
>>
>> I think that secret sharing in GPG would be quite a useful feature.
>> The idea is to split the secret key into 3 (or more) parts, so that any
>> two parts are enough to reconstruct the original secret key, but any
>> one of them alone is not sufficient to reconstruct it.
>>
>> There is already a free library and tool that has an implementation of it:
>>  - http://point-at-infinity.org/ssss/
>> If someone wants to do shared secrets he can use both gpg and
>> ssss-split/ssss-combine. Or he can can write wrapper shell scripts
>> that combine both of them.
>> However it would be more convenient if gpg can do it out of the box.
>>
>> I think that using secret sharing has some advantages. For example
>> imagine some scenarios like these:
>>
>>  - A user generates a new key and he tells `gpg` to share the secret key
>>    (or it can be the default option). Then `gpg` saves a share of the
>> key locally,
>>    saves another share on a removabe device (smard card or usb), and uploads
>>    a third share somewhere on the cloud, where only the user has access.
>>
>>  - When the user needs to do something with the private key (sign or
>> decrypt),
>>    he has to insert first the removable device with the key share. Then
>> `gpg`
>>    will combine this share with the one stored locally, will reconstruct
>> the private
>>    key, will use it, and then will erase the key again.
>>
>>  - If somebody gets temporary access to your removable device, they cannot
>>    find your private key, because the one share that is stored in it is
>> not enough
>>    to reconstruct the private key. The same if someone gets access to your
>>    computer. They need to have access both to your computer and your dongle
>>    in order to be able to sign with your key, and then maybe they will
>> also need
>>    to know the passphrase of the private key.
>>
>>    The same can be said if somebody gets access to the share of the key that
>>    is stored on the cloud. They need to get another share (either the
>> dongle or
>>    your pc), in order to reconstruct the key. 
>>
>>  - If the dongle is lost or stolen, your private key is not compromised.
>>    In this case you can get the share of the key from the cloud, combine it
>>    with the share of the key on the pc in order to reconstruct the key,
>>    then rigenerate three new shares: one for the pc, one for the dongle
>>    and one for the cloud, and delete the old shares from the pc and the
>> cloud.
>>    Destroying the old shares effectively invalidates the lost share, because
>>    alone it is useless for reconstructing the key.
>>
>>  - If the pc is lost or changed, you can get the share stored on the cloud,
>>    combine it with the share stored on the dongle, reconstruct the key,
>>    rigenerate three new shares, store them on the pc, dongle and cloud,
>>    and finally delete the old shares from the dongle and the cloud.
>>
>> I think that this would make key management safer and more robust.
>> Maybe it is not the ultimate solution, but at least it could prevent some
>> cases like loosing the private key because you lost the smart-card,
>> or because you changed the pc and forgot to transfer the keys from
>> the old one to the new one (or you just lost the pc).
>>
>> I hope that the idea that I am trying to explain is clear, but if needed
>> I may
>> also try to draw some diagrams, to make it easier to understand.
>>
>> However I have no idea about how this can be implemented on GPG, or how
>> to get started. I even know a student who is interested in trying to
>> implement
>> this as his master project, I have promissed to help and guide him, but
>> I am not
>> able to give him any advice or hint at all about how to get started.
>>
>> Would somebody be willing to help and guide this student to implement this?
>> Or maybe this should be managed as a "Google Summer of Code" project?
>>
>> Thanks and regards,
>> Dashamir
>>
>>
>>
>> _______________________________________________
>> Gnupg-devel mailing list
>> Gnupg-devel at gnupg.org
>> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
>>
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x8D6414F9.asc
Type: application/pgp-keys
Size: 23949 bytes
Desc: not available
URL: </pipermail/attachments/20160109/563ece63/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20160109/563ece63/attachment-0001.sig>

From gniibe at fsij.org  Tue Jan 12 02:44:24 2016
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 12 Jan 2016 10:44:24 +0900
Subject: Alignment issue of iobuf functions
In-Reply-To: <87bn8wgvxe.fsf@vigenere.g10code.de>
References: <568B2201.6030805@fsij.org> <871t9vxaeh.wl-neal@walfield.org>
 <568F1BEA.4040605@fsij.org> <87bn8wgvxe.fsf@vigenere.g10code.de>
Message-ID: <56945A78.9060309@fsij.org>

On 01/08/2016 08:19 PM, Werner Koch wrote:
> On Fri,  8 Jan 2016 03:16, gniibe at fsij.org said:
> 
>> The API of the function iobuf_desc is somewhat ugly.  And I don't like
>> strncpy in general, though.  Since it is an internal function, the
> 
> Please use mem2str instead:

Yes.  mem2str is better.

I'm going to push the commit now.
--


From wk at gnupg.org  Wed Jan 13 17:49:08 2016
From: wk at gnupg.org (Werner Koch)
Date: Wed, 13 Jan 2016 17:49:08 +0100
Subject: [PATCH] libgpg-error: Add nios2 support
In-Reply-To: <201601122028.17768.marex@denx.de> (Marek Vasut's message of
 "Tue, 12 Jan 2016 20:28:17 +0100")
References: <1442495254-5911-1-git-send-email-marex@denx.de>
 <201601122028.17768.marex@denx.de>
Message-ID: <87fuy1a0hn.fsf@vigenere.g10code.de>

On Tue, 12 Jan 2016 20:28, marex at denx.de said:
> On Thursday, September 17, 2015 at 03:07:34 PM, Marek Vasut wrote:
>> Add configuration for the NIOS2 processor.
>> 
>> Signed-off-by: Marek Vasut <marex at denx.de>
>> ---
>
> Bump ?

I can't see such message in the September archives.  Can you please post
it again (keep it below 40k)


Shalom-Salam,

   Werner

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



From wk at gnupg.org  Wed Jan 13 21:25:46 2016
From: wk at gnupg.org (Werner Koch)
Date: Wed, 13 Jan 2016 21:25:46 +0100
Subject: [PATCH] libgpg-error: Add nios2 support
In-Reply-To: <1452705178-6379-1-git-send-email-marex@denx.de> (Marek Vasut's
 message of "Wed, 13 Jan 2016 18:12:58 +0100")
References: <1452705178-6379-1-git-send-email-marex@denx.de>
Message-ID: <878u3t9qgl.fsf@vigenere.g10code.de>

On Wed, 13 Jan 2016 18:12, marex at denx.de said:
> Add configuration for the NIOS2 processor.

Pushed.  Thanks.


Shalom-Salam,

   Werner

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



From wk at gnupg.org  Thu Jan 14 11:17:46 2016
From: wk at gnupg.org (Werner Koch)
Date: Thu, 14 Jan 2016 11:17:46 +0100
Subject: Secret Sharing in GPG
In-Reply-To: <CAMucfLwLHJiFXwjA8Rc1j8a-ohfOnvs_JrtfzubmVGu-QEO6sA@mail.gmail.com>
 (Dashamir Hoxha's message of "Fri, 8 Jan 2016 23:26:06 +0100")
References: <CAMucfLwLHJiFXwjA8Rc1j8a-ohfOnvs_JrtfzubmVGu-QEO6sA@mail.gmail.com>
Message-ID: <87vb6w8nxx.fsf@vigenere.g10code.de>

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.


Salam-Shalom,

   Werner

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



From wk at gnupg.org  Thu Jan 14 13:42:56 2016
From: wk at gnupg.org (Werner Koch)
Date: Thu, 14 Jan 2016 13:42:56 +0100
Subject: adns and TOR
In-Reply-To: <22083.42471.21873.170334@chiark.greenend.org.uk> (Ian Jackson's
 message of "Wed, 11 Nov 2015 20:32:39 +0000")
References: <87vba1n0nc.fsf@vigenere.g10code.de>
 <22054.22959.951094.201969@chiark.greenend.org.uk>
 <87h9llmk1m.fsf@vigenere.g10code.de>
 <22055.30470.407246.973906@chiark.greenend.org.uk>
 <87a8rchuku.fsf@vigenere.g10code.de>
 <22055.62681.859262.777669@chiark.greenend.org.uk>
 <8737wcnv77.fsf@vigenere.g10code.de>
 <22083.42471.21873.170334@chiark.greenend.org.uk>
Message-ID: <871t9k72nj.fsf@vigenere.g10code.de>

On Wed, 11 Nov 2015 21:32, ijackson at chiark.greenend.org.uk said:

>> I have finished my Tor code for ADNS. See
>
> Hi.  I got your mail, thanks.  I will try to look at this properly
> soon.  If I don't, please chase me.

Ian, how shall be proceed with this.  Would it be helpful if I post a
Debian bug?

The alternative for GnuPG would be to rip the needed code and make it
part of GnuPG.  After all we need a subset of ADNS.


Salam-Shalom,

   Werner

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



From oleg at gurevich.de  Fri Jan 15 16:19:01 2016
From: oleg at gurevich.de (Oleg Gurevich)
Date: Fri, 15 Jan 2016 16:19:01 +0100
Subject: Scute on master branch. Build for Windows. Improvment for autogen.sh
 --build-wXX and autogen.rc
Message-ID: <56990DE5.1010300@gurevich.de>

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

Hello,

could you please take a look on this. By doing this autogen.sh --build-w32 for example configures properly for
execution of make command.

Reasonable ?

Mit freundlichen Gr??en/ ? ?????????/ best regards

Oleg Gurevich
PGP fingerprint: 38A0 D0CC BD23 1707 B0AF D158 E9D7 6E3F E74A 0B0C


diff --git a/autogen.rc b/autogen.rc
index 881f658..f5856c8 100644
- --- a/autogen.rc
+++ b/autogen.rc
@@ -1,4 +1,19 @@
 # autogen.sh configuration for Scute                           -*- sh -*-
+case "$myhost" in
+  w32)
+    configure_opts="
+      --with-gpg-error-prefix=@SYSROOT@
+      --with-libassuan-prefix=@SYSROOT@
+      "
+    ;;
+
+  amd64)
+    configure_opts="
+      --with-gpg-error-prefix=@SYSROOT@
+      --with-libassuan-prefix=@SYSROOT@
+     "
+    ;;
+esac

 extra_aclocal_flags=""
 final_info="./configure --enable-maintainer-mode  && make"
diff --git a/autogen.sh b/autogen.sh
index 3fe24ea..90e7d7f 100755
- --- a/autogen.sh
+++ b/autogen.sh
@@ -310,8 +310,7 @@ if [ "$myhost" = "w32" ]; then

     $tsdir/configure --enable-maintainer-mode ${SILENT} \
              --prefix=${w32root}  \
- -             --host=${host} --build=${build} SYSROOT=${w32root} \
- -             PKG_CONFIG_LIBDIR=${w32root} \
+             --host=${host} --build=${build} \
              ${configure_opts} ${extraoptions} "$@"
     rc=$?
     exit $rc




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

iQIcBAEBCAAGBQJWmQ3dAAoJEH5u5dDzfOKiFWcP+wTUdMiEqH0DP5GnD5JTDZNI
AEAg57L9sSv6/AQuP4ErteELI1iDiHphzOFqD3msfdScNpWDgp0U51YlZMtRnVrc
Av4N98861/1eLwQgoKaYahBeVv1EaMf/BnchNfwJ/UTMvSgM2/Yzp4AH8r6jnwkE
oHEZ8/NX+w3z/164DoYYwWOyFk8/z7P2WgAJXYwRzZqf3TROG82cV7vvKoZbLknB
JF7ky5UmFIAqOdQobLSsJ4swYEmRY9iMgg1SMy3z3Tmkqk+iVEB5A1NBImOp3kyW
UInjZuueFxnhGyxUifiC2Y0IiXkC1Agot7qsj29YWP+QVKQsgywHD9GMkdJe5bVE
5FVlVl8xakW0BM1CJK4Ew2sgAsvJSwmsc2bNnA6pSIFGVkTfXmujhNyOqx0c9ygY
BokijPc3wKs52mYf3/cqoPSlbSu3XRzrVJNWc0ySgFu8leP9DMPcWGTDz8SSTH2E
z8TRguR3tQELL+aUGwTv0TdSgYvlWPGl4FHhQz5V5ryEos/Szi12QpuV6E3lCPlX
JxeBlc3uwe82hJiNc9FRtxot4vomNWavt5DoQEHoMUJTIfjsF9aifhf+/8Nkiw1+
PygSaIxYQ6MbXiiL00eRYi394y5WGeoL8F8J/s1XbBcysfxAqf6sU1JjpM+hbalx
Xn0vNHFV28X2ERBwwfVk
=EeGr
-----END PGP SIGNATURE-----


From wk at gnupg.org  Fri Jan 15 20:39:15 2016
From: wk at gnupg.org (Werner Koch)
Date: Fri, 15 Jan 2016 20:39:15 +0100
Subject: Scute on master branch. Build for Windows. Improvment for
 autogen.sh --build-wXX and autogen.rc
In-Reply-To: <56990DE5.1010300@gurevich.de> (Oleg Gurevich's message of "Fri, 
 15 Jan 2016 16:19:01 +0100")
References: <56990DE5.1010300@gurevich.de>
Message-ID: <87h9ie63a4.fsf@vigenere.g10code.de>

On Fri, 15 Jan 2016 16:19, oleg at gurevich.de said:

> could you please take a look on this. By doing this autogen.sh --build-w32 for example configures properly for
> execution of make command.

That is basically correct.

> diff --git a/autogen.sh b/autogen.sh

> -             --host=${host} --build=${build} SYSROOT=${w32root} \
> -             PKG_CONFIG_LIBDIR=${w32root} \
> +             --host=${host} --build=${build} \

That change is not needed if a recent autogen.sh is used.
Justus: can you please take care of it?


Salam-Shalom,

   Werner

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



From dashohoxha at gmail.com  Sun Jan 17 23:03:56 2016
From: dashohoxha at gmail.com (Dashamir Hoxha)
Date: Sun, 17 Jan 2016 23:03:56 +0100
Subject: Secret Sharing in GPG
In-Reply-To: <87vb6w8nxx.fsf@vigenere.g10code.de>
References: <CAMucfLwLHJiFXwjA8Rc1j8a-ohfOnvs_JrtfzubmVGu-QEO6sA@mail.gmail.com>
 <87vb6w8nxx.fsf@vigenere.g10code.de>
Message-ID: <CAMucfLx_bt2SPujanObzjbiKbkCG+=XdBpw3rDuPCjncmXpDWw@mail.gmail.com>

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/20160117/f71746d6/attachment-0001.html>

From dashohoxha at gmail.com  Sun Jan 17 23:23:35 2016
From: dashohoxha at gmail.com (Dashamir Hoxha)
Date: Sun, 17 Jan 2016 23:23:35 +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: <CAMucfLy4x42mkFT2EC8=9DY2ah6gCtRUXuVZi6pg7PkzWYm0KQ@mail.gmail.com>

If the idea of secret-key spliting seems like interesting and achievable,
maybe it can be submited as a project to GSOC-2016:
 - https://developers.google.com/open-source/gsoc/
 -
https://developers.google.com/open-source/gsoc/faq#mentoring_organizations

By the way, I don't see GnuPG on the list of mentoring organizations
at GSOC-2015 (however the GNU Project is):
 - https://www.google-melange.com/gsoc/projects/list/google/gsoc2015


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/20160117/b7ddb361/attachment.html>

From dgouttegattat at incenp.org  Mon Jan 18 00:19:05 2016
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Mon, 18 Jan 2016 00:19:05 +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: <569C2169.2070902@incenp.org>

On 01/17/2016 11:03 PM, Dashamir Hoxha wrote:
> 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"

FYI, there is another implementation [1] in which the secret to share is 
not restricted to ?128 ASCII characters?.

Damien


[1] http://www.digital-scurf.org/software/libgfshare

-------------- 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/20160118/f937f825/attachment.sig>

From justus at g10code.com  Mon Jan 18 11:26:13 2016
From: justus at g10code.com (Justus Winter)
Date: Mon, 18 Jan 2016 11:26:13 +0100
Subject: Scute on master branch. Build for Windows. Improvment for
 autogen.sh --build-wXX and autogen.rc
In-Reply-To: <87h9ie63a4.fsf@vigenere.g10code.de>
References: <56990DE5.1010300@gurevich.de> <87h9ie63a4.fsf@vigenere.g10code.de>
Message-ID: <20160118102613.26743.59187@thinkbox.jade-hamburg.de>

Quoting Werner Koch (2016-01-15 20:39:15)
> On Fri, 15 Jan 2016 16:19, oleg at gurevich.de said:
> 
> > could you please take a look on this. By doing this autogen.sh --build-w32 for example configures properly for
> > execution of make command.
> 
> That is basically correct.

Ok, I will merge it then.

For the record, I merely set PATH so that the appropriate xyz-config
programs are found, and everything works as expected.

> > diff --git a/autogen.sh b/autogen.sh
> 
> > -             --host=${host} --build=${build} SYSROOT=${w32root} \
> > -             PKG_CONFIG_LIBDIR=${w32root} \
> > +             --host=${host} --build=${build} \
> 
> That change is not needed if a recent autogen.sh is used.
> Justus: can you please take care of it?

We do use a recent autogen.sh in Scute (modulo Niibes latest change).

Justus


From dashohoxha at gmail.com  Mon Jan 18 15:50:58 2016
From: dashohoxha at gmail.com (Dashamir Hoxha)
Date: Mon, 18 Jan 2016 15:50:58 +0100
Subject: Secret Sharing in GPG
In-Reply-To: <569C2169.2070902@incenp.org>
References: <CAMucfLwLHJiFXwjA8Rc1j8a-ohfOnvs_JrtfzubmVGu-QEO6sA@mail.gmail.com>
 <87vb6w8nxx.fsf@vigenere.g10code.de>
 <CAMucfLx_bt2SPujanObzjbiKbkCG+=XdBpw3rDuPCjncmXpDWw@mail.gmail.com>
 <569C2169.2070902@incenp.org>
Message-ID: <CAMucfLxixtkcUQcAKtCoiW9FhfojeuwqKKXEJ7QqOWr+S_8QOw@mail.gmail.com>

On Mon, Jan 18, 2016 at 12:19 AM, Damien Goutte-Gattat <
dgouttegattat at incenp.org> wrote:

>
> FYI, there is another implementation [1] in which the secret to share is
> not restricted to ?128 ASCII characters?.
>
> Damien
>
>
> [1] http://www.digital-scurf.org/software/libgfshare


This seems to be a better library. Thanks Damien.
It can also be installed conveniently with `apt-get install libgfshare-bin
libgfshare-dev`.

Dashamir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20160118/55710374/attachment.html>

From dashohoxha at gmail.com  Mon Jan 18 15:57:38 2016
From: dashohoxha at gmail.com (Dashamir Hoxha)
Date: Mon, 18 Jan 2016 15:57:38 +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: <CAMucfLzYBqA3OxYxfZikpFN8TOhcPSC7pacfrmuBycTt8Sq7QA@mail.gmail.com>

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

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

A usage case that I have missed is this:

4. When editing a solid private key, the user can have an option (command)
to convert it
    to a split key. It will save a partial key on the smart-card, a partial
key on the key-ring,
    and a third partial on a backup file. Then erase the solid private key
from the key-ring.
    The reverse should also be possible: converting a split key into a
solid key.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20160118/3133ad87/attachment-0001.html>

From gniibe at fsij.org  Tue Jan 19 09:12:27 2016
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 19 Jan 2016 17:12:27 +0900
Subject: [PATCH] migration to libusb-1.0
Message-ID: <569DEFEB.4000401@fsij.org>

Hello,

Here is an attempt to migrate libusb library to libusb-1.0 API.

This patch builds successfully.  Only lightly tested but works for me.

diff --git a/configure.ac b/configure.ac
index 266eae5..c6a1ec7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -783,15 +783,52 @@
AM_PATH_KSBA("$NEED_KSBA_API:$NEED_KSBA_VERSION",have_ksba=yes,have_ksba=no)
 #
 # FiXME: Use GNUPG_CHECK_LIBUSB and modify to use separate AC_SUBSTs.
 if test "$use_ccid_driver" = yes ; then
-  AC_CHECK_LIB(usb, usb_bulk_write,
-                [ LIBUSB_LIBS="$LIBUSB_LIBS -lusb"
-                  AC_DEFINE(HAVE_LIBUSB,1,
-                           [defined if libusb is available])
+   case $target in
+     *-*-darwin*)
+       LIBUSB_LIBS="-lusb-1.0 -framework CoreFoundation -framework IOKit"
+       ;;
+     *-*-freebsd*)
+       # FreeBSD has a native 1.0 compatible library by -lusb.
+       LIBUSB_LIBS="-lusb"
+       ;;
+     *)
+       LIBUSB_LIBS="-lusb-1.0"
+       ;;
+   esac
+   AC_CHECK_LIB(usb-1.0, libusb_init,
+                [ LIBUSB_LIBS="$LIBUSB_LIBS"
+                  AC_DEFINE(HAVE_LIBUSB,1, [defined if libusb is
available])
                   have_libusb=yes
                ])
-  AC_CHECK_FUNCS(usb_create_match)
+   AC_DEFINE([HAVE_LIBUSB])
+   AC_MSG_CHECKING([libusb include dir])
+   usb_incdir_found="no"
+   for _incdir in "" "/usr/include/libusb-1.0"
"/usr/local/include/libusb-1.0"; do
+     _libusb_save_cppflags=$CPPFLAGS
+     if test -n "${_incdir}"; then
+       CPPFLAGS="-I${_incdir} ${CPPFLAGS}"
+     fi
+     AC_PREPROC_IFELSE([AC_LANG_SOURCE([[@%:@include <libusb.h>]])],
+     [usb_incdir=${_incdir}; usb_incdir_found="yes"], [])
+     CPPFLAGS=${_libusb_save_cppflags}
+     if test "$usb_incdir_found" = "yes"; then
+       break
+     fi
+   done
+   if test "$usb_incdir_found" = "yes"; then
+     AC_MSG_RESULT([${usb_incdir}])
+   else
+     AC_MSG_RESULT([not found])
+     use_ccid_driver=no
+   fi
+   if test "$usb_incdir" = ""; then
+     LIBUSB_CPPFLAGS=""
+   else
+     LIBUSB_CPPFLAGS="-I${usb_incdir}"
+   fi
 fi
 AC_SUBST(LIBUSB_LIBS)
+AC_SUBST(LIBUSB_CPPFLAGS)

 #
 # Check wether it is necessary to link against libdl.
diff --git a/scd/Makefile.am b/scd/Makefile.am
index 80e4c0f..912c368 100644
--- a/scd/Makefile.am
+++ b/scd/Makefile.am
@@ -21,7 +21,7 @@ EXTRA_DIST = ChangeLog-2011 scdaemon-w32info.rc

 libexec_PROGRAMS = scdaemon

-AM_CPPFLAGS = -I$(top_srcdir)/common
+AM_CPPFLAGS = -I$(top_srcdir)/common @LIBUSB_CPPFLAGS@

 include $(top_srcdir)/am/cmacros.am

diff --git a/scd/ccid-driver.c b/scd/ccid-driver.c
index 7f83f80..fa7c039 100644
--- a/scd/ccid-driver.c
+++ b/scd/ccid-driver.c
@@ -83,11 +83,12 @@
 #include <sys/stat.h>
 #include <fcntl.h>
 #include <time.h>
+#include <unistd.h>
 #ifdef HAVE_NPTH
 # include <npth.h>
 #endif /*HAVE_NPTH*/

-#include <usb.h>
+#include <libusb.h>

 #include "scdaemon.h"
 #include "iso7816.h"
@@ -237,7 +238,7 @@ static struct
    structure is used as handle for most functions. */
 struct ccid_driver_s
 {
-  usb_dev_handle *idev;
+  libusb_device_handle *idev;
   char *rid;
   int dev_fd;  /* -1 for USB transport or file descriptor of the
                    transport device. */
@@ -985,7 +986,7 @@ parse_ccid_descriptor (ccid_driver_t handle,


 static char *
-get_escaped_usb_string (usb_dev_handle *idev, int idx,
+get_escaped_usb_string (libusb_device_handle *idev, int idx,
                         const char *prefix, const char *suffix)
 {
   int rc;
@@ -1005,18 +1006,20 @@ get_escaped_usb_string (usb_dev_handle *idev,
int idx,
   /* First get the list of supported languages and use the first one.
      If we do don't find it we try to use English.  Note that this is
      all in a 2 bute Unicode encoding using little endian. */
-  rc = usb_control_msg (idev, USB_ENDPOINT_IN, USB_REQ_GET_DESCRIPTOR,
-                        (USB_DT_STRING << 8), 0,
-                        (char*)buf, sizeof buf, 1000 /* ms timeout */);
+  rc = libusb_control_transfer (idev, LIBUSB_ENDPOINT_IN,
+                                LIBUSB_REQUEST_GET_DESCRIPTOR,
+                                (LIBUSB_DT_STRING << 8), 0,
+                                (char*)buf, sizeof buf, 1000 /* ms
timeout */);
   if (rc < 4)
     langid = 0x0409; /* English.  */
   else
     langid = (buf[3] << 8) | buf[2];

-  rc = usb_control_msg (idev, USB_ENDPOINT_IN, USB_REQ_GET_DESCRIPTOR,
-                        (USB_DT_STRING << 8) + idx, langid,
-                        (char*)buf, sizeof buf, 1000 /* ms timeout */);
-  if (rc < 2 || buf[1] != USB_DT_STRING)
+  rc = libusb_control_transfer (idev, LIBUSB_ENDPOINT_IN,
+                                LIBUSB_REQUEST_GET_DESCRIPTOR,
+                                (LIBUSB_DT_STRING << 8) + idx, langid,
+                                (char*)buf, sizeof buf, 1000 /* ms
timeout */);
+  if (rc < 2 || buf[1] != LIBUSB_DT_STRING)
     return NULL; /* Error or not a string. */
   len = buf[0];
   if (len > rc)
@@ -1059,7 +1062,7 @@ get_escaped_usb_string (usb_dev_handle *idev, int idx,
    physical reader after a reset.  It returns an allocated and possibly
    percent escaped string or NULL if not enough memory is available. */
 static char *
-make_reader_id (usb_dev_handle *idev,
+make_reader_id (libusb_device_handle *idev,
                 unsigned int vendor, unsigned int product,
                 unsigned char serialno_index)
 {
@@ -1082,7 +1085,7 @@ make_reader_id (usb_dev_handle *idev,

 /* Helper to find the endpoint from an interface descriptor.  */
 static int
-find_endpoint (struct usb_interface_descriptor *ifcdesc, int mode)
+find_endpoint (const struct libusb_interface_descriptor *ifcdesc, int mode)
 {
   int no;
   int want_bulk_in = 0;
@@ -1091,21 +1094,21 @@ find_endpoint (struct usb_interface_descriptor
*ifcdesc, int mode)
     want_bulk_in = 0x80;
   for (no=0; no < ifcdesc->bNumEndpoints; no++)
     {
-      struct usb_endpoint_descriptor *ep = ifcdesc->endpoint + no;
-      if (ep->bDescriptorType != USB_DT_ENDPOINT)
+      const struct libusb_endpoint_descriptor *ep = ifcdesc->endpoint + no;
+      if (ep->bDescriptorType != LIBUSB_DT_ENDPOINT)
         ;
       else if (mode == 2
-          && ((ep->bmAttributes & USB_ENDPOINT_TYPE_MASK)
-              == USB_ENDPOINT_TYPE_INTERRUPT)
-          && (ep->bEndpointAddress & 0x80))
-        return (ep->bEndpointAddress & 0x0f);
-      else if (((ep->bmAttributes & USB_ENDPOINT_TYPE_MASK)
-                == USB_ENDPOINT_TYPE_BULK)
+	       && ((ep->bmAttributes & LIBUSB_TRANSFER_TYPE_MASK)
+		   == LIBUSB_TRANSFER_TYPE_INTERRUPT)
+	       && (ep->bEndpointAddress & 0x80))
+        return ep->bEndpointAddress;
+      else if (((ep->bmAttributes & LIBUSB_TRANSFER_TYPE_MASK)
+                == LIBUSB_TRANSFER_TYPE_BULK)
                && (ep->bEndpointAddress & 0x80) == want_bulk_in)
-        return (ep->bEndpointAddress & 0x0f);
+        return ep->bEndpointAddress;
     }
-  /* Should never happen.  */
-  return mode == 2? 0x83 : mode == 1? 0x82 :1;
+
+  return -1;
 }


@@ -1116,10 +1119,10 @@ static int
 scan_or_find_usb_device (int scan_mode,
                          int *readerno, int *count, char **rid_list,
                          const char *readerid,
-                         struct usb_device *dev,
+                         struct libusb_device *dev,
                          char **r_rid,
-                         struct usb_device **r_dev,
-                         usb_dev_handle **r_idev,
+                         struct libusb_device_descriptor *desc,
+                         libusb_device_handle **r_idev,
                          unsigned char **ifcdesc_extra,
                          size_t *ifcdesc_extra_len,
                          int *interface_number,
@@ -1128,29 +1131,33 @@ scan_or_find_usb_device (int scan_mode,
   int cfg_no;
   int ifc_no;
   int set_no;
-  struct usb_config_descriptor *config;
-  struct usb_interface *interface;
-  struct usb_interface_descriptor *ifcdesc;
+  const struct libusb_interface_descriptor *ifcdesc;
   char *rid;
-  usb_dev_handle *idev;
+  libusb_device_handle *idev;
+  int err;
+
+  err = libusb_get_device_descriptor (dev, desc);
+  if (err < 0)
+    return err;

   *r_idev = NULL;

-  for (cfg_no=0; cfg_no < dev->descriptor.bNumConfigurations; cfg_no++)
+  for (cfg_no=0; cfg_no < desc->bNumConfigurations; cfg_no++)
     {
-      config = dev->config + cfg_no;
-      if(!config)
-        continue;
+      struct libusb_config_descriptor *config;
+
+      err = libusb_get_config_descriptor (dev, cfg_no, &config);
+      if (err < 0)
+	{
+	  libusb_free_config_descriptor (config);
+	  continue;
+	}

       for (ifc_no=0; ifc_no < config->bNumInterfaces; ifc_no++)
         {
-          interface = config->interface + ifc_no;
-          if (!interface)
-            continue;
-
-          for (set_no=0; set_no < interface->num_altsetting; set_no++)
+          for (set_no=0; set_no < config->interface->num_altsetting;
set_no++)
             {
-              ifcdesc = (interface->altsetting + set_no);
+              ifcdesc = (config->interface->altsetting + set_no);
               /* The second condition is for older SCM SPR 532 who did
                  not know about the assigned CCID class.  The third
                  condition does the same for a Cherry SmartTerminal
@@ -1161,24 +1168,24 @@ scan_or_find_usb_device (int scan_mode,
                        && ifcdesc->bInterfaceSubClass == 0
                        && ifcdesc->bInterfaceProtocol == 0)
                       || (ifcdesc->bInterfaceClass == 255
-                          && dev->descriptor.idVendor == VENDOR_SCM
-                          && dev->descriptor.idProduct == SCM_SPR532)
+                          && desc->idVendor == VENDOR_SCM
+                          && desc->idProduct == SCM_SPR532)
                       || (ifcdesc->bInterfaceClass == 255
-                          && dev->descriptor.idVendor == VENDOR_CHERRY
-                          && dev->descriptor.idProduct == CHERRY_ST2000)))
+                          && desc->idVendor == VENDOR_CHERRY
+                          && desc->idProduct == CHERRY_ST2000)))
                 {
-                  idev = usb_open (dev);
-                  if (!idev)
+		  err = libusb_open (dev, &idev);
+                  if (err < 0)
                     {
                       DEBUGOUT_1 ("usb_open failed: %s\n",
-                                  strerror (errno));
+                                  libusb_error_name (err));
                       continue; /* with next setting. */
                     }

                   rid = make_reader_id (idev,
-                                        dev->descriptor.idVendor,
-                                        dev->descriptor.idProduct,
-                                        dev->descriptor.iSerialNumber);
+                                        desc->idVendor,
+                                        desc->idProduct,
+                                        desc->iSerialNumber);
                   if (rid)
                     {
                       if (scan_mode)
@@ -1219,16 +1226,16 @@ scan_or_find_usb_device (int scan_mode,
                           if (ifcdesc_extra && ifcdesc_extra_len)
                             {
                               *ifcdesc_extra = malloc (ifcdesc
-                                                       ->extralen);
+                                                       ->extra_length);
                               if (!*ifcdesc_extra)
                                 {
-                                  usb_close (idev);
+                                  libusb_close (idev);
                                   free (rid);
                                   return 1; /* Out of core. */
                                 }
                               memcpy (*ifcdesc_extra, ifcdesc->extra,
-                                      ifcdesc->extralen);
-                              *ifcdesc_extra_len = ifcdesc->extralen;
+                                      ifcdesc->extra_length);
+                              *ifcdesc_extra_len = ifcdesc->extra_length;
                             }

                           if (interface_number)
@@ -1241,8 +1248,6 @@ scan_or_find_usb_device (int scan_mode,
                           if (ep_intr)
                             *ep_intr = find_endpoint (ifcdesc, 2);

-                          if (r_dev)
-                            *r_dev = dev;
                           if (r_rid)
                             {
                               *r_rid = rid;
@@ -1265,7 +1270,7 @@ scan_or_find_usb_device (int scan_mode,
                       free (rid);
                     }

-                  usb_close (idev);
+                  libusb_close (idev);
                   idev = NULL;
                   return 0;
                 }
@@ -1316,27 +1321,27 @@ scan_or_find_usb_device (int scan_mode,
 static int
 scan_or_find_devices (int readerno, const char *readerid,
                       char **r_rid,
-                      struct usb_device **r_dev,
+                      struct libusb_device_descriptor *r_desc,
                       unsigned char **ifcdesc_extra,
                       size_t *ifcdesc_extra_len,
                       int *interface_number,
                       int *ep_bulk_out, int *ep_bulk_in, int *ep_intr,
-                      usb_dev_handle **r_idev,
+                      libusb_device_handle **r_idev,
                       int *r_fd)
 {
   char *rid_list = NULL;
   int count = 0;
-  struct usb_bus *busses, *bus;
-  struct usb_device *dev = NULL;
-  usb_dev_handle *idev = NULL;
+  libusb_device **dev_list = NULL;
+  libusb_device *dev;
+  libusb_device_handle *idev = NULL;
   int scan_mode = (readerno == -1 && !readerid);
   int i;
+  ssize_t n;
+  struct libusb_device_descriptor desc;

   /* Set return values to a default. */
   if (r_rid)
     *r_rid = NULL;
-  if (r_dev)
-    *r_dev = NULL;
   if (ifcdesc_extra)
     *ifcdesc_extra = NULL;
   if (ifcdesc_extra_len)
@@ -1354,40 +1359,33 @@ scan_or_find_devices (int readerno, const char
*readerid,
       assert (r_rid);
     }

-  usb_find_busses();
-  usb_find_devices();
-
-#ifdef HAVE_USB_GET_BUSSES
-  busses = usb_get_busses();
-#else
-  busses = usb_busses;
-#endif
-
-  for (bus = busses; bus; bus = bus->next)
-    {
-      for (dev = bus->devices; dev; dev = dev->next)
-        {
-          if (scan_or_find_usb_device (scan_mode, &readerno, &count,
&rid_list,
-                                       readerid,
-                                       dev,
-                                       r_rid,
-                                       r_dev,
-                                       &idev,
-                                       ifcdesc_extra,
-                                       ifcdesc_extra_len,
-                                       interface_number,
-                                       ep_bulk_out, ep_bulk_in, ep_intr))
-            {
-              /* Found requested device or out of core. */
-              if (!idev)
-                {
-                  free (rid_list);
-                  return -1; /* error */
-                }
-              *r_idev = idev;
-              return 0;
-            }
-        }
+  n = libusb_get_device_list (NULL, &dev_list);
+
+  for (i = 0; i < n; i++)
+    {
+      dev = dev_list[i];
+      if (scan_or_find_usb_device (scan_mode, &readerno, &count, &rid_list,
+				   readerid,
+				   dev,
+				   r_rid,
+				   &desc,
+				   &idev,
+				   ifcdesc_extra,
+				   ifcdesc_extra_len,
+				   interface_number,
+				   ep_bulk_out, ep_bulk_in, ep_intr))
+	{
+	  /* Found requested device or out of core. */
+	  if (!idev)
+	    {
+	      free (rid_list);
+	      return -1; /* error */
+	    }
+	  *r_idev = idev;
+	  if (r_desc)
+	    memcpy (r_desc, &desc, sizeof (struct libusb_device_descriptor));
+	  return 0;
+	}
     }

   /* Now check whether there are any devices with special transport
types. */
@@ -1501,7 +1499,7 @@ ccid_get_reader_list (void)

   if (!initialized_usb)
     {
-      usb_init ();
+      libusb_init (NULL);
       initialized_usb = 1;
     }

@@ -1546,20 +1544,20 @@ ccid_open_reader (ccid_driver_t *handle, const
char *readerid,
                   const char **rdrname_p)
 {
   int rc = 0;
-  struct usb_device *dev = NULL;
-  usb_dev_handle *idev = NULL;
+  libusb_device_handle *idev = NULL;
   int dev_fd = -1;
   char *rid = NULL;
   unsigned char *ifcdesc_extra = NULL;
   size_t ifcdesc_extra_len;
   int readerno;
   int ifc_no, ep_bulk_out, ep_bulk_in, ep_intr;
+  struct libusb_device_descriptor desc;

   *handle = NULL;

   if (!initialized_usb)
     {
-      usb_init ();
+      libusb_init (NULL);
       initialized_usb = 1;
     }

@@ -1581,7 +1579,7 @@ ccid_open_reader (ccid_driver_t *handle, const
char *readerid,
   else
     readerno = 0;  /* Default. */

-  if (scan_or_find_devices (readerno, readerid, &rid, &dev,
+  if (scan_or_find_devices (readerno, readerid, &rid, &desc,
                             &ifcdesc_extra, &ifcdesc_extra_len,
                             &ifc_no, &ep_bulk_out, &ep_bulk_in, &ep_intr,
                             &idev, &dev_fd) )
@@ -1607,13 +1605,16 @@ ccid_open_reader (ccid_driver_t *handle, const
char *readerid,
     {
       (*handle)->idev = idev;
       (*handle)->dev_fd = -1;
-      (*handle)->id_vendor = dev->descriptor.idVendor;
-      (*handle)->id_product = dev->descriptor.idProduct;
-      (*handle)->bcd_device = dev->descriptor.bcdDevice;
+      (*handle)->id_vendor = desc.idVendor;
+      (*handle)->id_product = desc.idProduct;
+      (*handle)->bcd_device = desc.bcdDevice;
       (*handle)->ifc_no = ifc_no;
       (*handle)->ep_bulk_out = ep_bulk_out;
       (*handle)->ep_bulk_in = ep_bulk_in;
       (*handle)->ep_intr = ep_intr;
+      DEBUGOUT_1 ("endpont bulk_out: %02x\n", (*handle)->ep_bulk_out);
+      DEBUGOUT_1 ("endpont bulk_in : %02x\n", (*handle)->ep_bulk_in);
+      DEBUGOUT_1 ("endpont intr    : %02x\n", (*handle)->ep_intr);
     }
   else if (dev_fd != -1) /* Device transport. */
     {
@@ -1639,13 +1640,23 @@ ccid_open_reader (ccid_driver_t *handle, const
char *readerid,
           goto leave;
         }

-      rc = usb_claim_interface (idev, ifc_no);
-      if (rc)
+      rc = libusb_claim_interface (idev, ifc_no);
+      if (rc < 0)
         {
           DEBUGOUT_1 ("usb_claim_interface failed: %d\n", rc);
           rc = CCID_DRIVER_ERR_CARD_IO_ERROR;
           goto leave;
         }
+      /* Since usb_claim_interface doesn't emit USB_REQUEST_SET_INTERFACE,
+       * we need to call by ourselves.
+       */
+      rc = libusb_set_interface_alt_setting (idev, ifc_no, 0);
+      if (rc < 0)
+        {
+          DEBUGOUT_1 ("usb_set_interface_alt_setting failed: %d\n", rc);
+          rc = CCID_DRIVER_ERR_CARD_IO_ERROR;
+          goto leave;
+        }
     }

   rc = ccid_vendor_specific_init (*handle);
@@ -1656,7 +1667,7 @@ ccid_open_reader (ccid_driver_t *handle, const
char *readerid,
     {
       free (rid);
       if (idev)
-        usb_close (idev);
+        libusb_close (idev);
       if (dev_fd != -1)
         close (dev_fd);
       free (*handle);
@@ -1697,8 +1708,8 @@ do_close_reader (ccid_driver_t handle)
     }
   if (handle->idev)
     {
-      usb_release_interface (handle->idev, handle->ifc_no);
-      usb_close (handle->idev);
+      libusb_release_interface (handle->idev, handle->ifc_no);
+      libusb_close (handle->idev);
       handle->idev = NULL;
     }
   if (handle->dev_fd != -1)
@@ -1721,8 +1732,7 @@ int
 ccid_shutdown_reader (ccid_driver_t handle)
 {
   int rc = 0;
-  struct usb_device *dev = NULL;
-  usb_dev_handle *idev = NULL;
+  libusb_device_handle *idev = NULL;
   unsigned char *ifcdesc_extra = NULL;
   size_t ifcdesc_extra_len;
   int ifc_no, ep_bulk_out, ep_bulk_in, ep_intr;
@@ -1732,7 +1742,7 @@ ccid_shutdown_reader (ccid_driver_t handle)

   do_close_reader (handle);

-  if (scan_or_find_devices (-1, handle->rid, NULL, &dev,
+  if (scan_or_find_devices (-1, handle->rid, NULL, NULL,
                             &ifcdesc_extra, &ifcdesc_extra_len,
                             &ifc_no, &ep_bulk_out, &ep_bulk_in, &ep_intr,
                             &idev, NULL) || !idev)
@@ -1756,7 +1766,7 @@ ccid_shutdown_reader (ccid_driver_t handle)
           goto leave;
         }

-      rc = usb_claim_interface (idev, ifc_no);
+      rc = libusb_claim_interface (idev, ifc_no);
       if (rc)
         {
           DEBUGOUT_1 ("usb_claim_interface failed: %d\n", rc);
@@ -1770,7 +1780,7 @@ ccid_shutdown_reader (ccid_driver_t handle)
   if (rc)
     {
       if (handle->idev)
-        usb_close (handle->idev);
+        libusb_close (handle->idev);
       handle->idev = NULL;
       if (handle->dev_fd != -1)
         close (handle->dev_fd);
@@ -1843,11 +1853,6 @@ writen (int fd, const void *buf, size_t nbytes)
   return 0;
 }

-#if defined(ENXIO) && !defined(LIBUSB_PATH_MAX) && defined(__GNU_LIBRARY__)
-#define LIBUSB_ERRNO_NO_SUCH_DEVICE ENXIO       /* libusb-compat */
-#elif defined(ENODEV)
-#define LIBUSB_ERRNO_NO_SUCH_DEVICE ENODEV      /* Original libusb */
-#endif

 /* Write a MSG of length MSGLEN to the designated bulk out endpoint.
    Returns 0 on success. */
@@ -1916,35 +1921,23 @@ bulk_out (ccid_driver_t handle, unsigned char
*msg, size_t msglen,

   if (handle->idev)
     {
-      rc = usb_bulk_write (handle->idev,
-                           handle->ep_bulk_out,
-                           (char*)msg, msglen,
-                           5000 /* ms timeout */);
-      if (rc == msglen)
+      int transferred;
+
+      rc = libusb_bulk_transfer (handle->idev, handle->ep_bulk_out,
+                                 (char*)msg, msglen, &transferred,
+                                 5000 /* ms timeout */);
+      if (rc == 0 && transferred == msglen)
         return 0;
-#ifdef LIBUSB_ERRNO_NO_SUCH_DEVICE
-      if (rc == -(LIBUSB_ERRNO_NO_SUCH_DEVICE))
-        {
-          /* The Linux libusb returns a negative error value.  Catch
-             the most important one.  */
-          errno = LIBUSB_ERRNO_NO_SUCH_DEVICE;
-          rc = -1;
-        }
-#endif /*LIBUSB_ERRNO_NO_SUCH_DEVICE*/

-      if (rc == -1)
+      if (rc < 0)
         {
-          DEBUGOUT_1 ("usb_bulk_write error: %s\n", strerror (errno));
-#ifdef LIBUSB_ERRNO_NO_SUCH_DEVICE
-          if (errno == LIBUSB_ERRNO_NO_SUCH_DEVICE)
+          DEBUGOUT_1 ("usb_bulk_write error: %s\n", libusb_error_name
(rc));
+          if (rc == LIBUSB_ERROR_NO_DEVICE)
             {
               handle->enodev_seen = 1;
               return CCID_DRIVER_ERR_NO_READER;
             }
-#endif /*LIBUSB_ERRNO_NO_SUCH_DEVICE*/
         }
-      else
-        DEBUGOUT_1 ("usb_bulk_write failed: %d\n", rc);
     }
   else
     {
@@ -1981,14 +1974,11 @@ bulk_in (ccid_driver_t handle, unsigned char
*buffer, size_t length,
  retry:
   if (handle->idev)
     {
-      rc = usb_bulk_read (handle->idev,
-                          handle->ep_bulk_in,
-                          (char*)buffer, length,
-                          timeout);
+      rc = libusb_bulk_transfer (handle->idev, handle->ep_bulk_in,
+                                 (char*)buffer, length, &msglen, timeout);
       if (rc < 0)
         {
-          rc = errno;
-          DEBUGOUT_1 ("usb_bulk_read error: %s\n", strerror (rc));
+          DEBUGOUT_1 ("usb_bulk_read error: %s\n", libusb_error_name (rc));
           if (rc == EAGAIN && eagain_retries++ < 3)
             {
               my_sleep (1);
@@ -1996,7 +1986,7 @@ bulk_in (ccid_driver_t handle, unsigned char
*buffer, size_t length,
             }
           return CCID_DRIVER_ERR_CARD_IO_ERROR;
         }
-      *nread = msglen = rc;
+      *nread = msglen;
     }
   else
     {
@@ -2117,17 +2107,17 @@ abort_cmd (ccid_driver_t handle, int seqno)
   /* Send the abort command to the control pipe.  Note that we don't
      need to keep track of sent abort commands because there should
      never be another thread using the same slot concurrently.  */
-  rc = usb_control_msg (handle->idev,
-                        0x21,/* bmRequestType: host-to-device,
-                                class specific, to interface.  */
-                        1,   /* ABORT */
-                        (seqno << 8 | 0 /* slot */),
-                        handle->ifc_no,
-                        dummybuf, 0,
-                        1000 /* ms timeout */);
+  rc = libusb_control_transfer (handle->idev,
+                                0x21,/* bmRequestType: host-to-device,
+                                        class specific, to interface.  */
+                                1,   /* ABORT */
+                                (seqno << 8 | 0 /* slot */),
+                                handle->ifc_no,
+                                dummybuf, 0,
+                                1000 /* ms timeout */);
   if (rc < 0)
     {
-      DEBUGOUT_1 ("usb_control_msg error: %s\n", strerror (errno));
+      DEBUGOUT_1 ("usb_control_msg error: %s\n", libusb_error_name (rc));
       return CCID_DRIVER_ERR_CARD_IO_ERROR;
     }

@@ -2137,6 +2127,8 @@ abort_cmd (ccid_driver_t handle, int seqno)
   seqno--;  /* Adjust for next increment.  */
   do
     {
+      int transferred;
+
       seqno++;
       msg[0] = PC_to_RDR_Abort;
       msg[5] = 0; /* slot */
@@ -2147,32 +2139,27 @@ abort_cmd (ccid_driver_t handle, int seqno)
       msglen = 10;
       set_msg_len (msg, 0);

-      rc = usb_bulk_write (handle->idev,
-                           handle->ep_bulk_out,
-                           (char*)msg, msglen,
-                           5000 /* ms timeout */);
-      if (rc == msglen)
+      rc = libusb_bulk_transfer (handle->idev, handle->ep_bulk_out,
+                                 (char*)msg, msglen, &transferred,
+                                 5000 /* ms timeout */);
+      if (rc == 0 && transferred == msglen)
         rc = 0;
-      else if (rc == -1)
+      else if (rc < 0)
         DEBUGOUT_1 ("usb_bulk_write error in abort_cmd: %s\n",
-                    strerror (errno));
-      else
-        DEBUGOUT_1 ("usb_bulk_write failed in abort_cmd: %d\n", rc);
+                    libusb_error_name (rc));

       if (rc)
         return rc;

-      rc = usb_bulk_read (handle->idev,
-                          handle->ep_bulk_in,
-                          (char*)msg, sizeof msg,
-                          5000 /*ms timeout*/);
+      rc = libusb_bulk_transfer (handle->idev, handle->ep_bulk_in,
+                                 (char*)msg, sizeof msg, &msglen,
+                                 5000 /*ms timeout*/);
       if (rc < 0)
         {
           DEBUGOUT_1 ("usb_bulk_read error in abort_cmd: %s\n",
-                      strerror (errno));
+                      libusb_error_name (rc));
           return CCID_DRIVER_ERR_CARD_IO_ERROR;
         }
-      msglen = rc;

       if (msglen < 10)
         {
@@ -2283,11 +2270,10 @@ ccid_poll (ccid_driver_t handle)

   if (handle->idev)
     {
-      rc = usb_bulk_read (handle->idev,
-                          handle->ep_intr,
-                          (char*)msg, sizeof msg,
-                          0 /* ms timeout */ );
-      if (rc < 0 && errno == ETIMEDOUT)
+      rc = libusb_bulk_transfer (handle->idev, handle->ep_intr,
+                                 (char*)msg, sizeof msg, &msglen,
+                                 0 /* ms timeout */ );
+      if (rc == LIBUSB_ERROR_TIMEOUT)
         return 0;
     }
   else
@@ -2295,13 +2281,10 @@ ccid_poll (ccid_driver_t handle)

   if (rc < 0)
     {
-      DEBUGOUT_1 ("usb_intr_read error: %s\n", strerror (errno));
+      DEBUGOUT_1 ("usb_intr_read error: %s\n", libusb_error_name (rc));
       return CCID_DRIVER_ERR_CARD_IO_ERROR;
     }

-  msglen = rc;
-  rc = 0;
-
   if (msglen < 1)
     {
       DEBUGOUT ("intr-in msg too short\n");
@@ -2365,8 +2348,8 @@ ccid_slot_status (ccid_driver_t handle, int
*statusbits)
       if (!retries)
         {
           DEBUGOUT ("USB: CALLING USB_CLEAR_HALT\n");
-          usb_clear_halt (handle->idev, handle->ep_bulk_in);
-          usb_clear_halt (handle->idev, handle->ep_bulk_out);
+          libusb_clear_halt (handle->idev, handle->ep_bulk_in);
+          libusb_clear_halt (handle->idev, handle->ep_bulk_out);
         }
       else
           DEBUGOUT ("USB: RETRYING bulk_in AGAIN\n");
@@ -3112,7 +3095,7 @@ ccid_transceive (ccid_driver_t handle,

       if (tpdulen < 4)
         {
-          usb_clear_halt (handle->idev, handle->ep_bulk_in);
+          libusb_clear_halt (handle->idev, handle->ep_bulk_in);
           return CCID_DRIVER_ERR_ABORTED;
         }

@@ -3546,7 +3529,7 @@ ccid_transceive_secure (ccid_driver_t handle,

   if (tpdulen < 4)
     {
-      usb_clear_halt (handle->idev, handle->ep_bulk_in);
+      libusb_clear_halt (handle->idev, handle->ep_bulk_in);
       return CCID_DRIVER_ERR_ABORTED;
     }
   if (debug_level > 1)
--


From wk at gnupg.org  Wed Jan 20 10:21:39 2016
From: wk at gnupg.org (Werner Koch)
Date: Wed, 20 Jan 2016 10:21:39 +0100
Subject: [PATCH] migration to libusb-1.0
In-Reply-To: <569DEFEB.4000401@fsij.org> (NIIBE Yutaka's message of "Tue, 19
 Jan 2016 17:12:27 +0900")
References: <569DEFEB.4000401@fsij.org>
Message-ID: <878u3k4ndo.fsf@vigenere.g10code.de>

Hi,

thanks for working on this.  A lot of chnages but they look quite
starightforward.  We should consider this for 2.1._12_.

On Tue, 19 Jan 2016 09:12, gniibe at fsij.org said:

> -AM_CPPFLAGS = -I$(top_srcdir)/common
> +AM_CPPFLAGS = -I$(top_srcdir)/common @LIBUSB_CPPFLAGS@

Please use $(LIBUSB_CPPFLAGS) - automake creates that variable.


Shalom-Salam,

   Werner

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



From wub at partyvan.eu  Thu Jan 21 21:31:24 2016
From: wub at partyvan.eu (Juuso Lapinlampi)
Date: Thu, 21 Jan 2016 20:31:24 +0000 (UTC)
Subject: FTP mirrors page is outdated (was: New GnuPG FTP mirror:
 mirror.se.partyvan.eu)
Message-ID: <1718723137336129905.enqueue@partyvan.eu>

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

Hey gnupg-devel,

I am lost. Where does one report issues relating to gnupg.org website?
webmaster@, this list or gnupg-doc? The last one hasn't seen a message
in 1.5 years.

I tried looking for help from gnupg-users twice [1][2], but nobody has
answered or guided where to post. IRC wasn't very helpful last December
either. I've not found the source code for gnupg.org website to submit
patches. CVS for gnupg-www is refusing connections. Thus, I am trying my
luck here.

As I pointed out in my first message [1], the FTP mirrors page [3] has
had its better days. Today it sits outdated. I offered to setup a mirror
and after initial hurdle to find a way to do that (no instructions
provided), I managed to setup one [4].

Could somebody update the mirrors list? Some projects also have a
mailing list for mirrors like OpenBSD and Tor, considering that may be a
good idea for GnuPG.

[1]: https://lists.gnupg.org/pipermail/gnupg-users/2015-December/054893.html
[2]: https://lists.gnupg.org/pipermail/gnupg-users/2016-January/055020.html
[3]: https://gnupg.org/download/mirrors.html
[4]: https://mirror.se.partyvan.eu/pub/ftp.gnupg.org/gcrypt/
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJWoT+CAAoJEJiZcbKmt69L7PsQAKwc8ppRZ44peG9CIqhMr5Am
xkdT7BNIUOkf5z3ZEPUEFnjl91RmHspND1p9Xj6HqJzrnL4eQJiTslAksFcjYW5j
YVCgXAIEZ5n/b6DG69wS98oXDPMSmz3TZUVLJKM8MOWBCqucHTUr6ELR4fTBjY0g
dBoNv22wZ8ogvmhBNXs7ZdVyscSseUullXiQLC6wGVocw9ysPeXNuov7Aca0DMax
rq1FVNPE6V4R9ZKsoaW1deG/V26Vq3TL/UiE1XQWMueEZNzl3AqdKiKSiLDv6FS3
7YjrCl3hLEpAQNS1Ss7AE7Z4bbk2XY22sr/33FCZ8+MMksJKQxL9K+c/3WdrylbM
u2Q7Yeupj+HW4tK/PQi6Hll5Ji+5uE5PxnFrEfDrboVO2m5ztnpckI2+AMw4Wuta
ytnrf+fKZPSE9GUEECwf9Cb4fmVe8z7bBFqliJSAuYNPdIyjps7XVZhyxNAzVoMt
sT92t/Cqc4oJE72hbWNiZdVWBUFWkVYxt+ffCauYlogHlksJ/PVkVKUKYgthIdCF
3SktnKCqgqOQKYrBPRvzcen9NkmyTQxipNZAnLD4Uf7nw1h3QQk279sbQWxGKdO2
hkKPF/5XbVyGtVs1rftRUZVoq5Yli3N4JQcOAd4fA0SOqfLQJxdMpR0hBkZWEZh7
Wvu3rBPhFt5T8j9bgLC+
=D+lM
-----END PGP SIGNATURE-----


From leo at gaspard.io  Fri Jan 22 01:47:03 2016
From: leo at gaspard.io (Leo Gaspard)
Date: Fri, 22 Jan 2016 01:47:03 +0100
Subject: FTP mirrors page is outdated (was: New GnuPG FTP mirror:
 mirror.se.partyvan.eu)
In-Reply-To: <1718723137336129905.enqueue@partyvan.eu>
References: <1718723137336129905.enqueue@partyvan.eu>
Message-ID: <56A17C07.6040109@gaspard.io>

Hello,

My answer is in no way authoritative, but I think that, if you don't get
any answer, you may try to send, to this mailing list, a patch that
applies to [1].

If you still have no answer (which would amaze me), then I believe it
would be time to go where gnupg developers work [2], given you would
have a patch to link to and it would not take too much time.

That being said, I hope someone will correct me if I'm wrong.

Cheers,

Leo


[1] http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg-doc.git;a=summary

[2] https://lists.gnupg.org/pipermail/gnupg-devel/2015-December/030599.html


On 01/21/2016 09:31 PM, Juuso Lapinlampi wrote:
> Hey gnupg-devel,
> 
> I am lost. Where does one report issues relating to gnupg.org website?
> webmaster@, this list or gnupg-doc? The last one hasn't seen a message
> in 1.5 years.
> 
> I tried looking for help from gnupg-users twice [1][2], but nobody has
> answered or guided where to post. IRC wasn't very helpful last December
> either. I've not found the source code for gnupg.org website to submit
> patches. CVS for gnupg-www is refusing connections. Thus, I am trying my
> luck here.
> 
> As I pointed out in my first message [1], the FTP mirrors page [3] has
> had its better days. Today it sits outdated. I offered to setup a mirror
> and after initial hurdle to find a way to do that (no instructions
> provided), I managed to setup one [4].
> 
> Could somebody update the mirrors list? Some projects also have a
> mailing list for mirrors like OpenBSD and Tor, considering that may be a
> good idea for GnuPG.
> 
> [1]: https://lists.gnupg.org/pipermail/gnupg-users/2015-December/054893.html
> [2]: https://lists.gnupg.org/pipermail/gnupg-users/2016-January/055020.html
> [3]: https://gnupg.org/download/mirrors.html
> [4]: https://mirror.se.partyvan.eu/pub/ftp.gnupg.org/gcrypt/
> 
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
> 

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

From wk at gnupg.org  Fri Jan 22 13:21:51 2016
From: wk at gnupg.org (Werner Koch)
Date: Fri, 22 Jan 2016 13:21:51 +0100
Subject: FTP mirrors page is outdated
In-Reply-To: <1718723137336129905.enqueue@partyvan.eu> (Juuso Lapinlampi's
 message of "Thu, 21 Jan 2016 20:31:24 +0000 (UTC)")
References: <1718723137336129905.enqueue@partyvan.eu>
Message-ID: <871t99249s.fsf@vigenere.g10code.de>

On Thu, 21 Jan 2016 21:31, wub at partyvan.eu said:

> I am lost. Where does one report issues relating to gnupg.org website?
> webmaster@, this list or gnupg-doc? The last one hasn't seen a message
> in 1.5 years.


http://bugs.gnupg.org, category "gpgweb".

> I tried looking for help from gnupg-users twice [1][2], but nobody has
> answered or guided where to post. IRC wasn't very helpful last December

Sorry, the mails are ticked in my folder but I have not yet come around
to take care of them,

> either. I've not found the source code for gnupg.org website to submit

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg-doc.git

> As I pointed out in my first message [1], the FTP mirrors page [3] has

I'll continue there.


Shalom-Salam,

   Werner

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



From wub at partyvan.eu  Fri Jan 22 15:47:13 2016
From: wub at partyvan.eu (Juuso Lapinlampi)
Date: Fri, 22 Jan 2016 14:47:13 +0000
Subject: [PATCH 1/8] web: Remove dead WWW mirrors
Message-ID: <1453474040-8759-1-git-send-email-wub@partyvan.eu>

- gnupg.ca redirects to qmail.org or gnupg.org.
- snu.ac.kr (SNU) is 404 - Not Found.
- gnupg.cz is a parked domain/advertisement.
- gnupg.dk is refusing connections.
- crysys.hu was last synced around end of year 2007. It also has a file
  "DO_NOT_USE_THIS_SERVER~" for the FTP mirror.
- gnupg.pt is not a registered domain.
---
 web/mirrors.org | 13 +------------
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/web/mirrors.org b/web/mirrors.org
index 99d7727..f903bdf 100644
--- a/web/mirrors.org
+++ b/web/mirrors.org
@@ -16,24 +16,13 @@ are seeking mirrors for source or binary packages, please consult the
   |----------------+-----------------------+-----------+--------|
   | The Americas   |                       |           |        |
   |----------------+-----------------------+-----------+--------|
-  | Canada         | [[http://www.gnupg.ca/][GnuPG.ca]]              | [[http://www.gnupg.ca/][http]]      | 2/day  |
-  |                | [[http://www.raffsoftware.com/][RaffSoftware]]          | [[http://gnupg.raffsoftware.com/][http]]      | daily  |
+  | Canada         | [[http://www.raffsoftware.com/][RaffSoftware]]          | [[http://gnupg.raffsoftware.com/][http]]      | daily  |
   |                | [[http://www.parentinginformed.com/][parentinginformed]]     | [[http://gnupg.parentinginformed.com/][http]]      | 2/day  |
   |                |                       |           |        |
   |----------------+-----------------------+-----------+--------|
-  | Asia           |                       |           |        |
-  |----------------+-----------------------+-----------+--------|
-  | Korea          | [[http://www.snu.ac.kr/][SNU]]                   | [[http://musicone.snu.ac.kr/webmirror/gnupg/][http]]      | weekly |
-  |                |                       |           |        |
-  |----------------+-----------------------+-----------+--------|
   | Europe         |                       |           |        |
   |----------------+-----------------------+-----------+--------|
   | Austria        | [[http://gd.tuwien.ac.at/][TU Wien]]               | [[http://gd.tuwien.ac.at/www.gnupg.org/][http]]      |        |
-  | Czechia        | [[http://www.gnupg.cz/][GnuPG.cz]]              | [[http://www.gnupg.cz/][http]]      |        |
-  | Denmark        | [[http://www.gnupg.dk/][GnuPG.dk]]              | [[http://www.gnupg.dk/][http]]      |        |
-  | France         | [[http://mirror.cict.fr/][CICT Mirror, Toulouse]] | [[http://gnupg.cict.fr/][http]]      | daily  |
-  | Hungary        | [[http://www.crysys.hu/][CrySyS Lab., Bute]]     | [[http://gnupg.mirrors.crysys.hu/][http]]      | daily  |
-  | Portugal       | [[http://5coluna.com][5? Coluna]]             | [[http://mirror.gnupg.pt/][http]]      | 2/day  |
   | United Kingdom | [[http://mirror.tje.me.uk/][mirror.tje.me.uk]]      | [[http://mirror.tje.me.uk/pub/mirrors/www.gnupg.org/][http]]  [[ftp://mirror.tje.me.uk/pub/mirrors/www.gnupg.org][ftp]] | 4/day  |
   |                | [[http://www.mirrorservice.org/][UK Mirror Service]]     | [[http://www.mirrorservice.org/sites/www.gnupg.org/][http]]      |        |
   |                |                       |           |        |
-- 
2.7.0.rc3



From wub at partyvan.eu  Fri Jan 22 15:47:14 2016
From: wub at partyvan.eu (Juuso Lapinlampi)
Date: Fri, 22 Jan 2016 14:47:14 +0000
Subject: [PATCH 2/8] web: Remove "dead mirrors" comment from FTP mirrors
In-Reply-To: <1453474040-8759-1-git-send-email-wub@partyvan.eu>
References: <1453474040-8759-1-git-send-email-wub@partyvan.eu>
Message-ID: <1453474040-8759-2-git-send-email-wub@partyvan.eu>

Remove comment clutter. Git is your version control. If you need to
bring these alive sometime later, look in the git history.
---
 web/download/mirrors.org | 9 ---------
 1 file changed, 9 deletions(-)

diff --git a/web/download/mirrors.org b/web/download/mirrors.org
index b4ee159..9aea352 100644
--- a/web/download/mirrors.org
+++ b/web/download/mirrors.org
@@ -40,12 +40,3 @@ web site mirrors, please consult the [[../mirrors.html][WWW mirror page]] .
   | United Kingdom | [[http://mirror.tje.me.uk/][mirror.tje.me.uk]]           | [[ftp://mirror.tje.me.uk/pub/mirrors/ftp.gnupg.org][ftp]]  [[http://mirror.tje.me.uk/pub/mirrors/ftp.gnupg.org/][http]]                                                                        | 4/day |
   |                | [[http://www.mirrorservice.org/][UK Mirror Service]]          | [[ftp://ftp.mirrorservice.org/sites/ftp.gnupg.org/gcrypt][ftp]]  [[http://www.mirrorservice.org/sites/ftp.gnupg.org/gcrypt][http]]  {{{rsync(rsync://rsync.mirrorservice.org/ftp.gnupg.org/gcrypt/)}}}    |       |
   |----------------+----------------------------+----------------------------------------------------------------------------------+-------|
-
-# dead mirrors as of 2016-01-22:
-#
-# | Finland        | [[http://www.jyu.fi/][JYU]]                        | [[ftp://ftp.jyu.fi/pub/crypt/gcrypt/][ftp]]                                                                              |       |
-# | France         | [[http://mirror.cict.fr/][CICT Mirror, Toulouse]]      | [[ftp://mirror.cict.fr/gnupg/][ftp]]                                                                              | daily |
-# | Iceland        | [[http://www.hi.is/][HI]]                         | [[ftp://ftp.hi.is/pub/mirrors/gnupg/][ftp]]                                                                              |       |
-# | Portugal       | [[http://5coluna.com][5? Coluna]]                  | [[http://dist.gnupg.pt/][http]]                                                                             | 2/day |
-# | United Kingdom | [[http://gnupg.org.favoritelinks.net/][favoritelinks]]              | [[http://gnupg.org.favoritelinks.net/][http]]                                                                             | daily |
-#
-- 
2.7.0.rc3



From wub at partyvan.eu  Fri Jan 22 15:47:16 2016
From: wub at partyvan.eu (Juuso Lapinlampi)
Date: Fri, 22 Jan 2016 14:47:16 +0000
Subject: [PATCH 4/8] web: Add HTTP download to partyvan.eu FTP mirror
In-Reply-To: <1453474040-8759-1-git-send-email-wub@partyvan.eu>
References: <1453474040-8759-1-git-send-email-wub@partyvan.eu>
Message-ID: <1453474040-8759-4-git-send-email-wub@partyvan.eu>

mirror.se.partyvan.eu supports HTTP in addition to HTTPS. Browsers with
HSTS preloading support will be redirected to HTTPS version for their
own benefit. Browsers with HSTS support (but no preloading) will be
forced to HTTPS after accessing HTTPS.
---
 web/download/mirrors.org | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/web/download/mirrors.org b/web/download/mirrors.org
index 03a65c9..49d0e2e 100644
--- a/web/download/mirrors.org
+++ b/web/download/mirrors.org
@@ -33,7 +33,7 @@ web site mirrors, please consult the [[../mirrors.html][WWW mirror page]] .
   | Netherlands    | [[http://www.bit.nl/][BIT]]                        | [[ftp://ftp.bit.nl/mirror/gnupg/][ftp]]                                                                              |       |
   |                | [[http://www.surfnet.nl/][SurfNet]]                    | [[ftp://ftp.surfnet.nl/pub/security/gnupg/][ftp]]                                                                              |       |
   | Romania        | [[http://www.iasi.roedu.net/][Romanian Edu., Iasi Branch]] | [[ftp://ftp.iasi.roedu.net/pub/mirrors/ftp.gnupg.org/][ftp]]                                                                              |       |
-  | Sweden         | [[https://partyvan.eu][Partyvan]]                   | [[https://mirror.se.partyvan.eu/pub/ftp.gnupg.org/gcrypt/][https]] [[http://tpvj6abq225m5pcf.onion/pub/ftp.gnupg.org/gcrypt/][onion]] {{{rsync(rsync://mirror.se.partyvan.eu/pub/ftp.gnupg.org/gcrypt/)}}} | daily |
+  | Sweden         | [[https://partyvan.eu][Partyvan]]                   | [[http://mirror.se.partyvan.eu/pub/ftp.gnupg.org/gcrypt/][http]]  [[https://mirror.se.partyvan.eu/pub/ftp.gnupg.org/gcrypt/][https]] [[http://tpvj6abq225m5pcf.onion/pub/ftp.gnupg.org/gcrypt/][onion]] {{{rsync(rsync://mirror.se.partyvan.eu/pub/ftp.gnupg.org/gcrypt/)}}} | daily |
   | Switzerland    | [[http://mirror.switch.ch/][SWITCHmirror]]               | [[ftp://mirror.switch.ch/mirror/gnupg/][ftp]]                                                                              |       |
   | United Kingdom | [[http://mirror.tje.me.uk/][mirror.tje.me.uk]]           | [[ftp://mirror.tje.me.uk/pub/mirrors/ftp.gnupg.org][ftp]]  [[http://mirror.tje.me.uk/pub/mirrors/ftp.gnupg.org/][http]]                                                                        | 4/day |
   |                | [[http://www.mirrorservice.org/][UK Mirror Service]]          | [[ftp://ftp.mirrorservice.org/sites/ftp.gnupg.org/gcrypt][ftp]]  [[http://www.mirrorservice.org/sites/ftp.gnupg.org/gcrypt][http]]  {{{rsync(rsync://rsync.mirrorservice.org/ftp.gnupg.org/gcrypt/)}}}    |       |
-- 
2.7.0.rc3



From wub at partyvan.eu  Fri Jan 22 15:47:18 2016
From: wub at partyvan.eu (Juuso Lapinlampi)
Date: Fri, 22 Jan 2016 14:47:18 +0000
Subject: [PATCH 6/8] web: Add HTTP download for bit.nl FTP mirror
In-Reply-To: <1453474040-8759-1-git-send-email-wub@partyvan.eu>
References: <1453474040-8759-1-git-send-email-wub@partyvan.eu>
Message-ID: <1453474040-8759-6-git-send-email-wub@partyvan.eu>

---
 web/download/mirrors.org | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/web/download/mirrors.org b/web/download/mirrors.org
index 29d6738..caac5f0 100644
--- a/web/download/mirrors.org
+++ b/web/download/mirrors.org
@@ -30,7 +30,7 @@ web site mirrors, please consult the [[../mirrors.html][WWW mirror page]] .
   |                | [[http://www.franken.de/][Franken]]                    | [[ftp://ftp.franken.de/pub/crypt/mirror/ftp.gnupg.org/gcrypt/][ftp]]                                                                              | daily |
   |                | [[http://www.freenet.de/][Freenet.de]]                 | [[ftp://ftp.freenet.de/pub/ftp.gnupg.org/gcrypt/][ftp]]                                                                              |       |
   | Ireland        | [[http://ftp.heanet.ie/about/][HEAnet]]                     | [[ftp://ftp.heanet.ie/mirrors/ftp.gnupg.org/gcrypt/][ftp]]  [[http://ftp.heanet.ie/mirrors/ftp.gnupg.org/gcrypt/][http]]  {{{rsync(rsync://ftp.heanet.ie/mirrors/ftp.gnupg.org/gcrypt/)}}}      | 4/day |
-  | Netherlands    | [[http://www.bit.nl/][BIT]]                        | [[ftp://ftp.bit.nl/mirror/gnupg/][ftp]]                                                                              |       |
+  | Netherlands    | [[http://www.bit.nl/][BIT]]                        | [[ftp://ftp.bit.nl/mirror/gnupg/][ftp]]  [[http://ftp.bit.nl/mirror/gnupg/][http]]                                                                              |       |
   |                | [[http://www.surfnet.nl/][SurfNet]]                    | [[ftp://ftp.surfnet.nl/pub/security/gnupg/][ftp]]                                                                              |       |
   | Romania        | [[http://www.iasi.roedu.net/][Romanian Edu., Iasi Branch]] | [[ftp://ftp.iasi.roedu.net/pub/mirrors/ftp.gnupg.org/][ftp]]                                                                              |       |
   | Sweden         | [[https://partyvan.eu][Partyvan]]                   | [[http://mirror.se.partyvan.eu/pub/ftp.gnupg.org/gcrypt/][http]]  [[https://mirror.se.partyvan.eu/pub/ftp.gnupg.org/gcrypt/][https]]  [[http://tpvj6abq225m5pcf.onion/pub/ftp.gnupg.org/gcrypt/][onion]]  {{{rsync(rsync://mirror.se.partyvan.eu/pub/ftp.gnupg.org/gcrypt/)}}} | daily |
-- 
2.7.0.rc3



From wub at partyvan.eu  Fri Jan 22 15:47:20 2016
From: wub at partyvan.eu (Juuso Lapinlampi)
Date: Fri, 22 Jan 2016 14:47:20 +0000
Subject: [PATCH 8/8] web: Add HTTP download to freenet.de FTP mirror
In-Reply-To: <1453474040-8759-1-git-send-email-wub@partyvan.eu>
References: <1453474040-8759-1-git-send-email-wub@partyvan.eu>
Message-ID: <1453474040-8759-8-git-send-email-wub@partyvan.eu>

---
 web/download/mirrors.org | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/web/download/mirrors.org b/web/download/mirrors.org
index 9e07744..780c9ec 100644
--- a/web/download/mirrors.org
+++ b/web/download/mirrors.org
@@ -28,7 +28,7 @@ web site mirrors, please consult the [[../mirrors.html][WWW mirror page]] .
   | Denmark        | [[http://dotsrc.org/][dotsrc.org]]                 | [[ftp://mirrors.dotsrc.org/gcrypt/][ftp]]  [[http://mirrors.dotsrc.org/gcrypt/][http]]                                                                        | daily |
   | Germany        | [[http://www.artfiles.de][Artfiles New Media GmbH]]    | [[ftp://artfiles.org/gnupg.org][ftp]]  [[http://artfiles.org/gnupg.org][http]]                                                                             | daily |
   |                | [[http://www.franken.de/][Franken]]                    | [[ftp://ftp.franken.de/pub/crypt/mirror/ftp.gnupg.org/gcrypt/][ftp]]                                                                              | daily |
-  |                | [[http://www.freenet.de/][Freenet.de]]                 | [[ftp://ftp.freenet.de/pub/ftp.gnupg.org/gcrypt/][ftp]]                                                                              |       |
+  |                | [[http://www.freenet.de/][Freenet.de]]                 | [[ftp://ftp.freenet.de/pub/ftp.gnupg.org/gcrypt/][ftp]]  [[http://ftp.freenet.de/pub/ftp.gnupg.org/gcrypt/][http]]                                                                              |       |
   | Ireland        | [[http://ftp.heanet.ie/about/][HEAnet]]                     | [[ftp://ftp.heanet.ie/mirrors/ftp.gnupg.org/gcrypt/][ftp]]  [[http://ftp.heanet.ie/mirrors/ftp.gnupg.org/gcrypt/][http]]  {{{rsync(rsync://ftp.heanet.ie/mirrors/ftp.gnupg.org/gcrypt/)}}}      | 4/day |
   | Netherlands    | [[http://www.bit.nl/][BIT]]                        | [[ftp://ftp.bit.nl/mirror/gnupg/][ftp]]  [[http://ftp.bit.nl/mirror/gnupg/][http]]                                                                              |       |
   |                | [[http://www.surfnet.nl/][SurfNet]]                    | [[ftp://ftp.surfnet.nl/pub/security/gnupg/][ftp]]                                                                              |       |
-- 
2.7.0.rc3



From wub at partyvan.eu  Fri Jan 22 15:47:19 2016
From: wub at partyvan.eu (Juuso Lapinlampi)
Date: Fri, 22 Jan 2016 14:47:19 +0000
Subject: [PATCH 7/8] web: Add FTP download to Artfiles FTP mirror
In-Reply-To: <1453474040-8759-1-git-send-email-wub@partyvan.eu>
References: <1453474040-8759-1-git-send-email-wub@partyvan.eu>
Message-ID: <1453474040-8759-7-git-send-email-wub@partyvan.eu>

---
 web/download/mirrors.org | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/web/download/mirrors.org b/web/download/mirrors.org
index caac5f0..9e07744 100644
--- a/web/download/mirrors.org
+++ b/web/download/mirrors.org
@@ -26,7 +26,7 @@ web site mirrors, please consult the [[../mirrors.html][WWW mirror page]] .
   |----------------+----------------------------+----------------------------------------------------------------------------------+-------|
   | Austria        | [[http://gd.tuwien.ac.at/][TU Wien]]                    | [[ftp://gd.tuwien.ac.at/privacy/gnupg/][ftp]]  [[http://gd.tuwien.ac.at/privacy/gnupg/][http]]                                                                        |       |
   | Denmark        | [[http://dotsrc.org/][dotsrc.org]]                 | [[ftp://mirrors.dotsrc.org/gcrypt/][ftp]]  [[http://mirrors.dotsrc.org/gcrypt/][http]]                                                                        | daily |
-  | Germany        | [[http://www.artfiles.de][Artfiles New Media GmbH]]    | [[http://artfiles.org/gnupg.org][http]]                                                                             | daily |
+  | Germany        | [[http://www.artfiles.de][Artfiles New Media GmbH]]    | [[ftp://artfiles.org/gnupg.org][ftp]]  [[http://artfiles.org/gnupg.org][http]]                                                                             | daily |
   |                | [[http://www.franken.de/][Franken]]                    | [[ftp://ftp.franken.de/pub/crypt/mirror/ftp.gnupg.org/gcrypt/][ftp]]                                                                              | daily |
   |                | [[http://www.freenet.de/][Freenet.de]]                 | [[ftp://ftp.freenet.de/pub/ftp.gnupg.org/gcrypt/][ftp]]                                                                              |       |
   | Ireland        | [[http://ftp.heanet.ie/about/][HEAnet]]                     | [[ftp://ftp.heanet.ie/mirrors/ftp.gnupg.org/gcrypt/][ftp]]  [[http://ftp.heanet.ie/mirrors/ftp.gnupg.org/gcrypt/][http]]  {{{rsync(rsync://ftp.heanet.ie/mirrors/ftp.gnupg.org/gcrypt/)}}}      | 4/day |
-- 
2.7.0.rc3



From wub at partyvan.eu  Fri Jan 22 15:47:15 2016
From: wub at partyvan.eu (Juuso Lapinlampi)
Date: Fri, 22 Jan 2016 14:47:15 +0000
Subject: [PATCH 3/8] web: Remove gnupg.ca and crysys.hu FTP mirrors
In-Reply-To: <1453474040-8759-1-git-send-email-wub@partyvan.eu>
References: <1453474040-8759-1-git-send-email-wub@partyvan.eu>
Message-ID: <1453474040-8759-3-git-send-email-wub@partyvan.eu>

- gnupg.ca is unresponsive.
- crysys.hu has a file saying "DO_NOT_USE_THIS_SERVER~".
---
 web/download/mirrors.org | 2 --
 1 file changed, 2 deletions(-)

diff --git a/web/download/mirrors.org b/web/download/mirrors.org
index 9aea352..03a65c9 100644
--- a/web/download/mirrors.org
+++ b/web/download/mirrors.org
@@ -15,7 +15,6 @@ web site mirrors, please consult the [[../mirrors.html][WWW mirror page]] .
   |----------------+----------------------------+----------------------------------------------------------------------------------+-------|
   | The Americas   |                            |                                                                                  |       |
   |----------------+----------------------------+----------------------------------------------------------------------------------+-------|
-  | Canada         | [[http://www.gnupg.ca/][GnuPG.ca]]                   | [[ftp://ftp.gnupg.ca/][ftp]]                                                                              | 2/day |
   |                |                            |                                                                                  |       |
   |----------------+----------------------------+----------------------------------------------------------------------------------+-------|
   | Asia           |                            |                                                                                  |       |
@@ -30,7 +29,6 @@ web site mirrors, please consult the [[../mirrors.html][WWW mirror page]] .
   | Germany        | [[http://www.artfiles.de][Artfiles New Media GmbH]]    | [[http://artfiles.org/gnupg.org][http]]                                                                             | daily |
   |                | [[http://www.franken.de/][Franken]]                    | [[ftp://ftp.franken.de/pub/crypt/mirror/ftp.gnupg.org/gcrypt/][ftp]]                                                                              | daily |
   |                | [[http://www.freenet.de/][Freenet.de]]                 | [[ftp://ftp.freenet.de/pub/ftp.gnupg.org/gcrypt/][ftp]]                                                                              |       |
-  | Hungary        | [[http://www.crysys.hu/][CrySyS Lab., Bute]]          | [[ftp://ftp.crysys.hu/pub/gnupg/][ftp]]                                                                              | daily |
   | Ireland        | [[http://ftp.heanet.ie/about/][HEAnet]]                     | [[ftp://ftp.heanet.ie/mirrors/ftp.gnupg.org/gcrypt/][ftp]]  [[http://ftp.heanet.ie/mirrors/ftp.gnupg.org/gcrypt/][http]]  {{{rsync(rsync://ftp.heanet.ie/mirrors/ftp.gnupg.org/gcrypt/)}}}      | 4/day |
   | Netherlands    | [[http://www.bit.nl/][BIT]]                        | [[ftp://ftp.bit.nl/mirror/gnupg/][ftp]]                                                                              |       |
   |                | [[http://www.surfnet.nl/][SurfNet]]                    | [[ftp://ftp.surfnet.nl/pub/security/gnupg/][ftp]]                                                                              |       |
-- 
2.7.0.rc3



From wub at partyvan.eu  Fri Jan 22 15:47:17 2016
From: wub at partyvan.eu (Juuso Lapinlampi)
Date: Fri, 22 Jan 2016 14:47:17 +0000
Subject: [PATCH 5/8] web: Fix partyvan.eu FTP mirror whitespace
In-Reply-To: <1453474040-8759-1-git-send-email-wub@partyvan.eu>
References: <1453474040-8759-1-git-send-email-wub@partyvan.eu>
Message-ID: <1453474040-8759-5-git-send-email-wub@partyvan.eu>

Download URLs are seperated with two spaces. Fixes consistency.

This bug was introduced in commit
86b046ac120b5b05539dce4cfdfc3dbdfc1823f7.
---
 web/download/mirrors.org | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/web/download/mirrors.org b/web/download/mirrors.org
index 49d0e2e..29d6738 100644
--- a/web/download/mirrors.org
+++ b/web/download/mirrors.org
@@ -33,7 +33,7 @@ web site mirrors, please consult the [[../mirrors.html][WWW mirror page]] .
   | Netherlands    | [[http://www.bit.nl/][BIT]]                        | [[ftp://ftp.bit.nl/mirror/gnupg/][ftp]]                                                                              |       |
   |                | [[http://www.surfnet.nl/][SurfNet]]                    | [[ftp://ftp.surfnet.nl/pub/security/gnupg/][ftp]]                                                                              |       |
   | Romania        | [[http://www.iasi.roedu.net/][Romanian Edu., Iasi Branch]] | [[ftp://ftp.iasi.roedu.net/pub/mirrors/ftp.gnupg.org/][ftp]]                                                                              |       |
-  | Sweden         | [[https://partyvan.eu][Partyvan]]                   | [[http://mirror.se.partyvan.eu/pub/ftp.gnupg.org/gcrypt/][http]]  [[https://mirror.se.partyvan.eu/pub/ftp.gnupg.org/gcrypt/][https]] [[http://tpvj6abq225m5pcf.onion/pub/ftp.gnupg.org/gcrypt/][onion]] {{{rsync(rsync://mirror.se.partyvan.eu/pub/ftp.gnupg.org/gcrypt/)}}} | daily |
+  | Sweden         | [[https://partyvan.eu][Partyvan]]                   | [[http://mirror.se.partyvan.eu/pub/ftp.gnupg.org/gcrypt/][http]]  [[https://mirror.se.partyvan.eu/pub/ftp.gnupg.org/gcrypt/][https]]  [[http://tpvj6abq225m5pcf.onion/pub/ftp.gnupg.org/gcrypt/][onion]]  {{{rsync(rsync://mirror.se.partyvan.eu/pub/ftp.gnupg.org/gcrypt/)}}} | daily |
   | Switzerland    | [[http://mirror.switch.ch/][SWITCHmirror]]               | [[ftp://mirror.switch.ch/mirror/gnupg/][ftp]]                                                                              |       |
   | United Kingdom | [[http://mirror.tje.me.uk/][mirror.tje.me.uk]]           | [[ftp://mirror.tje.me.uk/pub/mirrors/ftp.gnupg.org][ftp]]  [[http://mirror.tje.me.uk/pub/mirrors/ftp.gnupg.org/][http]]                                                                        | 4/day |
   |                | [[http://www.mirrorservice.org/][UK Mirror Service]]          | [[ftp://ftp.mirrorservice.org/sites/ftp.gnupg.org/gcrypt][ftp]]  [[http://www.mirrorservice.org/sites/ftp.gnupg.org/gcrypt][http]]  {{{rsync(rsync://rsync.mirrorservice.org/ftp.gnupg.org/gcrypt/)}}}    |       |
-- 
2.7.0.rc3



From wk at gnupg.org  Fri Jan 22 20:39:56 2016
From: wk at gnupg.org (Werner Koch)
Date: Fri, 22 Jan 2016 20:39:56 +0100
Subject: [PATCH 2/8] web: Remove "dead mirrors" comment from FTP mirrors
In-Reply-To: <1453474040-8759-2-git-send-email-wub@partyvan.eu> (Juuso
 Lapinlampi's message of "Fri, 22 Jan 2016 14:47:14 +0000")
References: <1453474040-8759-1-git-send-email-wub@partyvan.eu>
 <1453474040-8759-2-git-send-email-wub@partyvan.eu>
Message-ID: <87fuxpz9mb.fsf@vigenere.g10code.de>

On Fri, 22 Jan 2016 15:47, wub at partyvan.eu said:
> Remove comment clutter. Git is your version control. If you need to
> bring these alive sometime later, look in the git history.

Nope.  Sometimes it is better to have code commented out than lurking
somewhere in the repo - you simply forget about it.


Salam-Shalom,

   Werner

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



From wk at gnupg.org  Fri Jan 22 20:41:52 2016
From: wk at gnupg.org (Werner Koch)
Date: Fri, 22 Jan 2016 20:41:52 +0100
Subject: [PATCH 4/8] web: Add HTTP download to partyvan.eu FTP mirror
In-Reply-To: <1453474040-8759-4-git-send-email-wub@partyvan.eu> (Juuso
 Lapinlampi's message of "Fri, 22 Jan 2016 14:47:16 +0000")
References: <1453474040-8759-1-git-send-email-wub@partyvan.eu>
 <1453474040-8759-4-git-send-email-wub@partyvan.eu>
Message-ID: <87bn8dz9j3.fsf@vigenere.g10code.de>

On Fri, 22 Jan 2016 15:47, wub at partyvan.eu said:
> mirror.se.partyvan.eu supports HTTP in addition to HTTPS. Browsers with

I do not want to add any new http URLs unless it is technically
required.


Shalom-Salam,

   Werner

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



From wk at gnupg.org  Mon Jan 25 11:52:51 2016
From: wk at gnupg.org (Werner Koch)
Date: Mon, 25 Jan 2016 11:52:51 +0100
Subject: [PATCH] agent, gpg: Forward progress output for --gen-key
In-Reply-To: <87vb9lnp5n.fsf-ueno@gnu.org> (Daiki Ueno's message of "Mon, 02
 Nov 2015 10:52:36 +0900")
References: <871tcav62l.fsf-ueno@gnu.org> <87h9l52371.fsf@vigenere.g10code.de>
 <87vb9lnp5n.fsf-ueno@gnu.org>
Message-ID: <87si1mvsl8.fsf@vigenere.g10code.de>

Hi,

On Mon,  2 Nov 2015 02:52, ueno at gnu.org said:
> Thanks for the comments.  I am attaching a revised patch.

I looked at your patch but it has two problems:
gcry_set_progress_handler may only be used once during the process
initialization.  The progress lines are not associated with a connection
and thus a client might see progress lines triggered by another client.

I had to add a dispatcher for these problems to gpg-agent (commit
ee87c65) and also simplified the gpg part of the patch (commit
fbe1cf6).  Will got into 2.1.11.

What still needs to be done is to change gpgme to always pass
--exit-on-status-write-error.  I re-opened bug 1415 for that.


Salam-Shalom,

   Werner

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



From patrick at enigmail.net  Mon Jan 25 16:53:09 2016
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Mon, 25 Jan 2016 16:53:09 +0100
Subject: TOFU: Slow list-keys
Message-ID: <56A644E5.3020108@enigmail.net>

I use gpg 2.1.10. I noticed that with TOFU enabled, key listing became
quite slow. My keyring (keybox) contains around 550 public keys.

I run the command: gpg2 --fixed-list-mode --with-fingerprint \
--with-colons --status-fd 2 --list-key

With trust-model pgp: 7 seconds

With trust-model tofu and tofu+pgp: 18 seconds

I'm also seeing lots of "gpg: TOFU: Ignoring revoked user id ... "
output. I believe this should better be debugging output only.

-Patrick


From wk at gnupg.org  Mon Jan 25 18:08:08 2016
From: wk at gnupg.org (Werner Koch)
Date: Mon, 25 Jan 2016 18:08:08 +0100
Subject: TOFU: Slow list-keys
In-Reply-To: <56A644E5.3020108@enigmail.net> (Patrick Brunschwig's message of
 "Mon, 25 Jan 2016 16:53:09 +0100")
References: <56A644E5.3020108@enigmail.net>
Message-ID: <87oac9vb7r.fsf@vigenere.g10code.de>

On Mon, 25 Jan 2016 16:53, patrick at enigmail.net said:
> I use gpg 2.1.10. I noticed that with TOFU enabled, key listing became
> quite slow. My keyring (keybox) contains around 550 public keys.

See also Debian Bug#811549 from Jan 18.

> I'm also seeing lots of "gpg: TOFU: Ignoring revoked user id ... "
> output. I believe this should better be debugging output only.

I have fixed that already.


Salam-Shalom,

   Werner

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



From ueno at gnu.org  Tue Jan 26 02:54:46 2016
From: ueno at gnu.org (Daiki Ueno)
Date: Tue, 26 Jan 2016 10:54:46 +0900
Subject: [PATCH] agent, gpg: Forward progress output for --gen-key
In-Reply-To: <87si1mvsl8.fsf@vigenere.g10code.de> (Werner Koch's message of
 "Mon, 25 Jan 2016 11:52:51 +0100")
References: <871tcav62l.fsf-ueno@gnu.org> <87h9l52371.fsf@vigenere.g10code.de>
 <87vb9lnp5n.fsf-ueno@gnu.org> <87si1mvsl8.fsf@vigenere.g10code.de>
Message-ID: <m3k2mxrtp5.fsf-ueno@gnu.org>

Werner Koch <wk at gnupg.org> writes:

> gcry_set_progress_handler may only be used once during the process
> initialization.  The progress lines are not associated with a connection
> and thus a client might see progress lines triggered by another client.

Oh, I haven't thought of that multi-client case.  Thanks for fixing!

Regards,
-- 
Daiki Ueno


From dkg at fifthhorseman.net  Tue Jan 26 17:30:09 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 26 Jan 2016 11:30:09 -0500
Subject: difference in key import counting between GnuPG 1.4 and 2.1
Message-ID: <87bn888fse.fsf@alice.fifthhorseman.net>

Hi folks--

GnuPG 2.1 seems to count files differently when doing imports than 1.4.

Consider the comparison below (using the attached files, taken from
pygpgme/tests/keys).  In particular, note stats starting at "total
number processed:" and ending at "secret keys imported:"

I believe that gpg 2.1 is counting some of the keys multiple times (once
per subkey?) , but (for example), i'm not sure why it would claim 3
secret keys read and 2 secret keys imported, while 1.4 just say 1 in
each category.

This is one of the causes of test suite failure for pygpgme, because
pygpgme expects the values produced by 1.4.x (and presumably by 2.0.x,
though i haven't tested it).

Any pointers on how this should be resolved?  If they're "both right"
due to architectural differences, then i might just try to tune the
pygpgme test suite to ignore the differences.

       --dkg


0 dkg at alice:~/tmp$ for x in gpg gpg2; do \
>  GNUPGHOME=$(pwd)/$x $x --version; \
>  for f in key1.sec collected.gpg; do \
>   printf '=== %s ===\n' "$f" ; \
>   rm -rf $x; \
>   mkdir -m 0700 $x; \
>   GNUPGHOME=$(pwd)/$x $x --import < "$f"; \
>  done; \
> done
gpg (GnuPG) 1.4.20
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/dkg/tmp/gpg
Supported algorithms:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
=== key1.sec ===
gpg: keyring `/home/dkg/tmp/gpg/secring.gpg' created
gpg: keyring `/home/dkg/tmp/gpg/pubring.gpg' created
gpg: key 885C65A4: secret key imported
gpg: /home/dkg/tmp/gpg/trustdb.gpg: trustdb created
gpg: key 885C65A4: public key "Key 1 <key1 at example.org>" imported
gpg: Total number processed: 1
gpg:               imported: 1
gpg:       secret keys read: 1
gpg:   secret keys imported: 1
=== collected.gpg ===
gpg: keyring `/home/dkg/tmp/gpg/secring.gpg' created
gpg: keyring `/home/dkg/tmp/gpg/pubring.gpg' created
gpg: /home/dkg/tmp/gpg/trustdb.gpg: trustdb created
gpg: key 885C65A4: public key "Key 1 <key1 at example.org>" imported
gpg: key 885C65A4: secret key imported
gpg: key 885C65A4: "Key 1 <key1 at example.org>" 1 new signature
gpg: key C97E6B0F: public key "Key 2 <key2 at example.org>" imported
gpg: Total number processed: 3
gpg:               imported: 2  (RSA: 1)
gpg:         new signatures: 1
gpg:       secret keys read: 1
gpg:   secret keys imported: 1
gpg: no ultimately trusted keys found
gpg (GnuPG) 2.1.10
libgcrypt 1.6.4
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/dkg/tmp/gpg2
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
=== key1.sec ===
gpg: keybox '/home/dkg/tmp/gpg2/pubring.kbx' created
gpg: /home/dkg/tmp/gpg2/trustdb.gpg: trustdb created
gpg: key 885C65A4: public key "Key 1 <key1 at example.org>" imported
gpg: key 885C65A4: secret key imported
gpg: Total number processed: 3
gpg:               imported: 1
gpg:       secret keys read: 3
gpg:   secret keys imported: 2
=== collected.gpg ===
gpg: keybox '/home/dkg/tmp/gpg2/pubring.kbx' created
gpg: /home/dkg/tmp/gpg2/trustdb.gpg: trustdb created
gpg: key 885C65A4: public key "Key 1 <key1 at example.org>" imported
gpg: key 885C65A4: "Key 1 <key1 at example.org>" 1 new signature
gpg: key 885C65A4: secret key imported
gpg: key C97E6B0F: public key "Key 2 <key2 at example.org>" imported
gpg: Total number processed: 5
gpg:               imported: 2
gpg:         new signatures: 1
gpg:       secret keys read: 3
gpg:   secret keys imported: 2
gpg: no ultimately trusted keys found
0 dkg at alice:~/tmp$



-------------- next part --------------
A non-text attachment was scrubbed...
Name: key1.sec
Type: application/pgp-keys
Size: 1769 bytes
Desc: not available
URL: </pipermail/attachments/20160126/e5a53967/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: collected.gpg
Type: application/pgp-keys
Size: 6615 bytes
Desc: not available
URL: </pipermail/attachments/20160126/e5a53967/attachment-0001.key>

From dkg at fifthhorseman.net  Tue Jan 26 20:37:28 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 26 Jan 2016 14:37:28 -0500
Subject: difference in key import counting between GnuPG 1.4 and 2.1
In-Reply-To: <87bn888fse.fsf@alice.fifthhorseman.net>
References: <87bn888fse.fsf@alice.fifthhorseman.net>
Message-ID: <87oac86sjr.fsf@alice.fifthhorseman.net>

On Tue 2016-01-26 11:30:09 -0500, Daniel Kahn Gillmor wrote:

> This is one of the causes of test suite failure for pygpgme, because
> pygpgme expects the values produced by 1.4.x (and presumably by 2.0.x,
> though i haven't tested it).
>
> Any pointers on how this should be resolved?  If they're "both right"
> due to architectural differences, then i might just try to tune the
> pygpgme test suite to ignore the differences.

fwiw, the patch below is what tuning the pygpgme test suite to conform
to gnupg 2.1 would look like.

        --dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-reflect-2.1-reporting-for-key-imports.patch
Type: text/x-diff
Size: 4089 bytes
Desc: not available
URL: </pipermail/attachments/20160126/daac4a8c/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: </pipermail/attachments/20160126/daac4a8c/attachment.sig>

From dgouttegattat at incenp.org  Tue Jan 26 23:17:25 2016
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Tue, 26 Jan 2016 23:17:25 +0100
Subject: Set TOFU policy in the key editor?
Message-ID: <1453846646-26460-1-git-send-email-dgouttegattat@incenp.org>

Hi GnuPG developers,

I think it would be nice to be able to assign a TOFU policy to a
key using the interactive key editor, in pretty much the same
way we can set the ownertrust.

I have implemented a quick draft of a "tofu" command for the key
editor to do that (patch in the next email).

What do you think? Is anyone else interested in such a command?

Cheers,


Damien Goutte-Gattat (1):
  gpg: Allow to set TOFU policy in the key editor.

 g10/keyedit.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 68 insertions(+)

-- 
1.8.4



From dgouttegattat at incenp.org  Tue Jan 26 23:17:26 2016
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Tue, 26 Jan 2016 23:17:26 +0100
Subject: [PATCH] gpg: Allow to set TOFU policy in the key editor.
In-Reply-To: <1453846646-26460-1-git-send-email-dgouttegattat@incenp.org>
References: <1453846646-26460-1-git-send-email-dgouttegattat@incenp.org>
Message-ID: <1453846646-26460-2-git-send-email-dgouttegattat@incenp.org>

* g10/keydit.c (keyedit_menu): Add a tofu command.
(tofu_policy_prompt): New.

--
Currently, the only way to explicitly assign a TOFU policy is
through the --tofu-policy option on the command line.

This patch allows to set TOFU policy through the interactive
key editor.

Signed-off-by: Damien Goutte-Gattat <dgouttegattat at incenp.org>
---
 g10/keyedit.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 68 insertions(+)

diff --git a/g10/keyedit.c b/g10/keyedit.c
index 30f52a4..35da1ef 100644
--- a/g10/keyedit.c
+++ b/g10/keyedit.c
@@ -448,6 +448,47 @@ sign_mk_attrib (PKT_signature * sig, void *opaque)
 }
 
 
+#ifdef USE_TOFU
+static enum tofu_policy
+tofu_policy_prompt (void)
+{
+  char *p;
+  enum tofu_policy policy = TOFU_POLICY_NONE;
+
+  tty_printf (_("Please assign a TOFU policy to this key\n"));
+  tty_printf ("\n");
+  tty_printf (_("  %d = Use the default policy\n"), 1);
+  tty_printf (_("  %d = This key belongs to the stated owner\n"), 2);
+  tty_printf (_("  %d = I do not know\n"), 3);
+  tty_printf (_("  %d = This key is a forgery\n"), 4);
+  tty_printf (_("  %d = Ask me next time\n"), 5);
+  tty_printf ("\n");
+
+  while (policy == TOFU_POLICY_NONE)
+    {
+      p = cpr_get ("tofu_policy_prompt.policy", _("Your selection? "));
+      trim_spaces (p);
+      cpr_kill_prompt ();
+      if (*p && !p[1])
+        {
+	  switch (*p)
+	    {
+	    case '1': policy = TOFU_POLICY_AUTO   ; break;
+	    case '2': policy = TOFU_POLICY_GOOD   ; break;
+	    case '3': policy = TOFU_POLICY_UNKNOWN; break;
+	    case '4': policy = TOFU_POLICY_BAD    ; break;
+	    case '5': policy = TOFU_POLICY_ASK    ; break;
+	    }
+	}
+
+      xfree (p);
+    }
+
+  return policy;
+}
+#endif /*!USE_TOFU*/
+
+
 static void
 trustsig_prompt (byte * trust_value, byte * trust_depth, char **regexp)
 {
@@ -1366,6 +1407,9 @@ enum cmdids
 #ifndef NO_TRUST_MODELS
   cmdENABLEKEY, cmdDISABLEKEY,
 #endif /*!NO_TRUST_MODELS*/
+#ifdef USE_TOFU
+  cmdTOFUPOLICY,
+#endif /*!USE_TOFU*/
   cmdSHOWPREF,
   cmdSETPREF, cmdPREFKS, cmdNOTATION, cmdINVCMD, cmdSHOWPHOTO, cmdUPDTRUST,
   cmdCHKTRUST, cmdADDCARDKEY, cmdKEYTOCARD, cmdBKUPTOCARD,
@@ -1447,6 +1491,9 @@ static struct
 #ifndef NO_TRUST_MODELS
   { "trust", cmdTRUST, KEYEDIT_NOT_SK, N_("change the ownertrust")},
 #endif /*!NO_TRUST_MODELS*/
+#ifdef USE_TOFU
+  { "tofu", cmdTOFUPOLICY, 0, N_("set TOFU policy")},
+#endif /*!USE_TOFU*/
   { "revsig", cmdREVSIG, KEYEDIT_NOT_SK,
     N_("revoke signatures on the selected user IDs")},
   { "revuid", cmdREVUID, KEYEDIT_NOT_SK | KEYEDIT_NEED_SK,
@@ -2167,6 +2214,27 @@ keyedit_menu (ctrl_t ctrl, const char *username, strlist_t locusr,
 	  break;
 #endif /*!NO_TRUST_MODELS*/
 
+#ifdef USE_TOFU
+	case cmdTOFUPOLICY:
+	  if (opt.trust_model != TM_TOFU && opt.trust_model != TM_TOFU_PGP)
+	    {
+	      tty_printf (_("TOFU policy can only be set while "
+			    "using a TOFU-enabled trust model\n"));
+	      break;
+	    }
+
+	  {
+	    enum tofu_policy policy = tofu_policy_prompt ();
+	    err = tofu_set_policy (keyblock, policy);
+	    if (err)
+	      {
+		tty_printf (_("Error setting TOFU policy: %s\n"),
+			    gpg_strerror (err));
+	      }
+	  }
+	  break;
+#endif /*!USE_TOFU*/
+
 	case cmdPREF:
 	  {
 	    int count = count_selected_uids (keyblock);
-- 
1.8.4



From jan at nitrokey.com  Tue Jan 26 22:51:14 2016
From: jan at nitrokey.com (Jan Suhr)
Date: Tue, 26 Jan 2016 22:51:14 +0100
Subject: USB CCID issue
In-Reply-To: <041001d15767$e23d2100$a6b76300$@enves.de>
References: <041001d15767$e23d2100$a6b76300$@enves.de>
Message-ID: <56A7EA52.1040705@nitrokey.com>

Hi!

An error happens when using:
- Linux,
- GPG2.0,
- Nitrokey Storage (beta)
- connected via USB3.0
- to perform a signature with SHA224 or SHA256.

It works well when using USB1.1, USB2.0, SHA1, a non-Linux operating
system, or any Nitrokey model other than Storage.

The issue ticket is here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775559

We analyzed the issue by starting with the Nitrokey. We figured that the
issue is caused by an oversized USB packet send from the computer (GPG2)
to the Nitrokey. The failed APDU send by GPG2 has a length of 60 byte.
The length of the resulting CCID packet is 74 byte:

CCID packet = CCID header (10 Byte) + T1 header (3 Byte) + APDU (60
Byte) + T1 CRC (1 Byte) = 74 Byte

This CCID packet is send in a single USB packet. Because the receive
buffer of the Nitrokey is 64 byte large the last 10 bytes of the payload
are lost and replaced by random bytes. This causes a parity error when
the data was send to Nitrokey's OpenPGP Card. The 64 byte buffer is
declared in Nitrokey's USB descriptor. It seems that this declaration is
ignored by the computer. I'm not sure whether this is Linux kernel,
SCDaemon or GPG2 responsibility. Could someone with better knowledge of
the GPG stack help to localize the root cause?

Best regards,
Jan


Logs of the failed APDU (with different payloads because I couldn't log
all traces at the same time)


Failed APDU - Length 60 byte
2016-01-25 11:49:23 scdaemon[9614] DBG: send apdu: c=00 i=2A p1=9E p2=9A
lc=51 le=2048 em=1
2016-01-25 11:49:23 scdaemon[9614] DBG:  raw apdu: 00 2A 9E 9A 00 00 33 30
31 30 0D 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 DD 34 2C 81 12 C7 49
DF 74 65 A1 2D A0 25 0A E9 62 CE 6C F8 66 A8 B7 55 94 04 DA 7C 55 AD D5 3F
08 00
2016-01-25 11:49:46 scdaemon[9614] ccid_transceive failed: (0x1000a)
2016-01-25 11:49:46 scdaemon[9614] apdu_send_simple(0) failed: card I/O
error
2016-01-25 11:49:46 scdaemon[9614] operation sign result: Input/output error
2016-01-25 11:49:46 scdaemon[9614] app_sign failed: Input/output error


USB CCID packet - payload length 74 Byte

No.     Time           Source                Destination           Protocol
Length Info
   3511 38.413647000   host                  8.4                   USB
138    URB_BULK out

Frame 3511: 138 bytes on wire (1104 bits), 138 bytes captured (1104 bits) on
interface 0
    Interface id: 0
    Encapsulation type: USB packets with Linux header and padding (115)
    Arrival Time: Jan 25, 2016 09:16:34.839335000 CET
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1453709794.839335000 seconds
    [Time delta from previous captured frame: 0.000037000 seconds]
    [Time delta from previous displayed frame: 0.000037000 seconds]
    [Time since reference or first frame: 38.413647000 seconds]
    Frame Number: 3511
    Frame Length: 138 bytes (1104 bits)
    Capture Length: 138 bytes (1104 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: usb]
USB URB
    URB id: 0xffff8803d34c9780
    URB type: URB_SUBMIT ('S')
    URB transfer type: URB_BULK (0x03)
    Endpoint: 0x04, Direction: OUT
        0... .... = Direction: OUT (0)
        .000 0100 = Endpoint value: 4
    Device: 8
    URB bus id: 3
    Device setup request: not relevant ('-')
    Data: present (0)
    URB sec: 1453709794
    URB usec: 839335
    URB status: Operation now in progress (-EINPROGRESS) (-115)
    URB length [bytes]: 74
    Data length [bytes]: 74
    [Response in: 3512]
    [bInterfaceClass: Unknown (0xffff)]
Leftover Capture Data: 6f40000000003d04000000403c002a9e9a0000333031300d...

USB block:
0000  80 97 4c d3 03 88 ff ff 53 03 04 08 03 00 2d 00   ..L.....S.....-.
0010  e2 d9 a5 56 00 00 00 00 a7 ce 0c 00 8d ff ff ff   ...V............
0020  4a 00 00 00 4a 00 00 00 00 00 00 00 00 00 00 00   J...J...........
0030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
Payload: CCID block = CCID header (10 Byte) + T1 header (3 Byte) + APDU (60
Byte) + T1 CRC (1 Byte) = 74 Byte
0040  6f 40 00 00 00 00 3d 04 00 00 00 40 3c 00 2a 9e   o at ....=....@<.*.
0050  9a 00 00 33 30 31 30 0d 06 09 60 86 48 01 65 03   ...3010...`.H.e.
0060  04 02 01 05 00 04 20 da e5 62 1a cf f5 4a e8 b4   ...... ..b...J..
0070  a8 2e 69 5b ea 88 f1 eb c5 04 3e 08 5a 51 b8 d8   ..i[......>.ZQ..
0080  11 24 cf c4 b5 bd a7 08 00 1f                     .$........


Nitrokey log:
  25176 CCID USB EP_CCID_OUT buffer overflow
  25176 Get CCID USB block  74 byte

Received T1 block = T1 header (3 Byte) + APDU (60 Byte) + T1 CRC (1 Byte) =
64 Byte - the last 10 bytes from the USB packet are lost and filled by
random bytes
  50355 : Send T1 block - Comand len  64 -  Answer len  4  -   140 ms
Command - 00 40 3c 00 2a 9e 9a 00 00 33 30 31 30 0d 06 09 60 86 48 01 65 03
04 02 01 05 00 04 20 dd 34 2c 81 12 c7 49 df 74 65 a1 2d a0 25 0a e9 62 ce
6c f8 66 a8 b7 55 94 80 04 00 00 00 00 3d 00 00 00
          I-Block
          PERFORM SECURITY OPERATION
Answer  - 00 91 00 91
          R-Block
          00 91 00 91 = EDC- / parity error


Nitrokey USB descriptor - USB CCID buffer size = 64 byte

Bus 003 Device 032: ID 20a0:4109 Clay Logic
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x20a0 Clay Logic
  idProduct          0x4109
  bcdDevice            1.00
  iManufacturer           1 Nitrokey
  iProduct                2 Nitrokey Storage
  iSerial                 3 0000000000000
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength          141
    bNumInterfaces          3
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass        11 Chip/SmartCard
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              0
      ChipCard Interface Descriptor:
        bLength                54
        bDescriptorType        33
        bcdCCID              1.10  (Warning: Only accurate for version 1.0)
        nMaxSlotIndex           0
        bVoltageSupport         2  3.0V
        dwProtocols             2  T=1
        dwDefaultClock       3600
        dwMaxiumumClock      3600
        bNumClockSupported      0
        dwDataRate           9677 bps
        dwMaxDataRate      116129 bps
        bNumDataRatesSupp.      0
        dwMaxIFSD              48
        dwSyncProtocols  00000000
        dwMechanical     00000000
        dwFeatures       000104BA
          Auto configuration based on ATR
          Auto voltage selection
          Auto clock change
          Auto baud rate change
          Auto PPS made by CCID
          Auto IFSD exchange
          TPDU level exchange
        dwMaxCCIDMsgLen        48
        bClassGetResponse      00
        bClassEnvelope         00
        wlcdLayout           none
        bPINSupport             0
        bMaxCCIDBusySlots       1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0010  1x 16 bytes
        bInterval              16
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x85  EP 5 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0 No Subclass
      bInterfaceProtocol      1 Keyboard
      iInterface              0
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.10
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      71
         Report Descriptors:
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x86  EP 6 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               5
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0000
  (Bus Powered)






Am 25.01.2016 12:59, schrieb rudbo:
> Hi Jan,
> 
> the problem from the ticket
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775559 is in my 
> opinion an
> oversized USB packet.
> The failed APDU send by gpg2 has a length of 60 byte. The length of the 
> CCID
> packet is then 74 byte:
> 
> CCID packet = CCID header (10 Byte) + T1 header (3 Byte) + APDU (60 
> Byte) +
> T1 CRC (1 Byte) = 74 Byte
> 
> this CCID packet is send via 1 USB packet. Because the receive buffer 
> our
> USB device is only 64 byte large (send by the Nitrokey USB descriptor 
> to the
> system)
> the last 10 bytes of the payload are lost and replaced by random bytes. 
> This
> causes a  parity error when the data was send to the smartcard.
> 
> Greetings
> Rudolf
> 
> 
> Logs of the failed APDU (with different payloads because I couldn't log 
> all
> traces at the same time)
> 
> 
> Failed APDU - Length 60 byte
> 2016-01-25 11:49:23 scdaemon[9614] DBG: send apdu: c=00 i=2A p1=9E 
> p2=9A
> lc=51 le=2048 em=1
> 2016-01-25 11:49:23 scdaemon[9614] DBG:  raw apdu: 00 2A 9E 9A 00 00 33 
> 30
> 31 30 0D 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 DD 34 2C 81 12 C7 
> 49
> DF 74 65 A1 2D A0 25 0A E9 62 CE 6C F8 66 A8 B7 55 94 04 DA 7C 55 AD D5 
> 3F
> 08 00
> 2016-01-25 11:49:46 scdaemon[9614] ccid_transceive failed: (0x1000a)
> 2016-01-25 11:49:46 scdaemon[9614] apdu_send_simple(0) failed: card I/O
> error
> 2016-01-25 11:49:46 scdaemon[9614] operation sign result: Input/output 
> error
> 2016-01-25 11:49:46 scdaemon[9614] app_sign failed: Input/output error
> 
> 
> USB CCID packet - payload length 74 Byte
> 
> No.     Time           Source                Destination           
> Protocol
> Length Info
>    3511 38.413647000   host                  8.4                   USB
> 138    URB_BULK out
> 
> Frame 3511: 138 bytes on wire (1104 bits), 138 bytes captured (1104 
> bits) on
> interface 0
>     Interface id: 0
>     Encapsulation type: USB packets with Linux header and padding (115)
>     Arrival Time: Jan 25, 2016 09:16:34.839335000 CET
>     [Time shift for this packet: 0.000000000 seconds]
>     Epoch Time: 1453709794.839335000 seconds
>     [Time delta from previous captured frame: 0.000037000 seconds]
>     [Time delta from previous displayed frame: 0.000037000 seconds]
>     [Time since reference or first frame: 38.413647000 seconds]
>     Frame Number: 3511
>     Frame Length: 138 bytes (1104 bits)
>     Capture Length: 138 bytes (1104 bits)
>     [Frame is marked: False]
>     [Frame is ignored: False]
>     [Protocols in frame: usb]
> USB URB
>     URB id: 0xffff8803d34c9780
>     URB type: URB_SUBMIT ('S')
>     URB transfer type: URB_BULK (0x03)
>     Endpoint: 0x04, Direction: OUT
>         0... .... = Direction: OUT (0)
>         .000 0100 = Endpoint value: 4
>     Device: 8
>     URB bus id: 3
>     Device setup request: not relevant ('-')
>     Data: present (0)
>     URB sec: 1453709794
>     URB usec: 839335
>     URB status: Operation now in progress (-EINPROGRESS) (-115)
>     URB length [bytes]: 74
>     Data length [bytes]: 74
>     [Response in: 3512]
>     [bInterfaceClass: Unknown (0xffff)]
> Leftover Capture Data: 
> 6f40000000003d04000000403c002a9e9a0000333031300d...
> 
> USB block:
> 0000  80 97 4c d3 03 88 ff ff 53 03 04 08 03 00 2d 00   
> ..L.....S.....-.
> 0010  e2 d9 a5 56 00 00 00 00 a7 ce 0c 00 8d ff ff ff   
> ...V............
> 0020  4a 00 00 00 4a 00 00 00 00 00 00 00 00 00 00 00   
> J...J...........
> 0030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   
> ................
> Payload: CCID block = CCID header (10 Byte) + T1 header (3 Byte) + APDU 
> (60
> Byte) + T1 CRC (1 Byte) = 74 Byte
> 0040  6f 40 00 00 00 00 3d 04 00 00 00 40 3c 00 2a 9e   
> o at ....=....@<.*.
> 0050  9a 00 00 33 30 31 30 0d 06 09 60 86 48 01 65 03   
> ...3010...`.H.e.
> 0060  04 02 01 05 00 04 20 da e5 62 1a cf f5 4a e8 b4   ...... 
> ..b...J..
> 0070  a8 2e 69 5b ea 88 f1 eb c5 04 3e 08 5a 51 b8 d8   
> ..i[......>.ZQ..
> 0080  11 24 cf c4 b5 bd a7 08 00 1f                     .$........
> 
> 
> Nitrokey log:
>   25176 CCID USB EP_CCID_OUT buffer overflow
>   25176 Get CCID USB block  74 byte
> 
> Received T1 block = T1 header (3 Byte) + APDU (60 Byte) + T1 CRC (1 
> Byte) =
> 64 Byte - the last 10 bytes from the USB packet are lost and filled by
> random bytes
>   50355 : Send T1 block - Comand len  64 -  Answer len  4  -   140 ms
> Command - 00 40 3c 00 2a 9e 9a 00 00 33 30 31 30 0d 06 09 60 86 48 01 
> 65 03
> 04 02 01 05 00 04 20 dd 34 2c 81 12 c7 49 df 74 65 a1 2d a0 25 0a e9 62 
> ce
> 6c f8 66 a8 b7 55 94 80 04 00 00 00 00 3d 00 00 00
>           I-Block
>           PERFORM SECURITY OPERATION
> Answer  - 00 91 00 91
>           R-Block
>           00 91 00 91 = EDC- / parity error
> 
> 
> Nitrokey USB descriptor - USB CCID buffer size = 64 byte
> 
> Bus 003 Device 032: ID 20a0:4109 Clay Logic
> Device Descriptor:
>   bLength                18
>   bDescriptorType         1
>   bcdUSB               2.00
>   bDeviceClass            0 (Defined at Interface level)
>   bDeviceSubClass         0
>   bDeviceProtocol         0
>   bMaxPacketSize0        64
>   idVendor           0x20a0 Clay Logic
>   idProduct          0x4109
>   bcdDevice            1.00
>   iManufacturer           1 Nitrokey
>   iProduct                2 Nitrokey Storage
>   iSerial                 3 0000000000000
>   bNumConfigurations      1
>   Configuration Descriptor:
>     bLength                 9
>     bDescriptorType         2
>     wTotalLength          141
>     bNumInterfaces          3
>     bConfigurationValue     1
>     iConfiguration          0
>     bmAttributes         0x80
>       (Bus Powered)
>     MaxPower              100mA
>     Interface Descriptor:
>       bLength                 9
>       bDescriptorType         4
>       bInterfaceNumber        0
>       bAlternateSetting       0
>       bNumEndpoints           2
>       bInterfaceClass         8 Mass Storage
>       bInterfaceSubClass      6 SCSI
>       bInterfaceProtocol     80 Bulk-Only
>       iInterface              0
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x81  EP 1 IN
>         bmAttributes            2
>           Transfer Type            Bulk
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0200  1x 512 bytes
>         bInterval               0
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x02  EP 2 OUT
>         bmAttributes            2
>           Transfer Type            Bulk
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0200  1x 512 bytes
>         bInterval               0
>     Interface Descriptor:
>       bLength                 9
>       bDescriptorType         4
>       bInterfaceNumber        1
>       bAlternateSetting       0
>       bNumEndpoints           3
>       bInterfaceClass        11 Chip/SmartCard
>       bInterfaceSubClass      0
>       bInterfaceProtocol      0
>       iInterface              0
>       ChipCard Interface Descriptor:
>         bLength                54
>         bDescriptorType        33
>         bcdCCID              1.10  (Warning: Only accurate for version 
> 1.0)
>         nMaxSlotIndex           0
>         bVoltageSupport         2  3.0V
>         dwProtocols             2  T=1
>         dwDefaultClock       3600
>         dwMaxiumumClock      3600
>         bNumClockSupported      0
>         dwDataRate           9677 bps
>         dwMaxDataRate      116129 bps
>         bNumDataRatesSupp.      0
>         dwMaxIFSD              48
>         dwSyncProtocols  00000000
>         dwMechanical     00000000
>         dwFeatures       000104BA
>           Auto configuration based on ATR
>           Auto voltage selection
>           Auto clock change
>           Auto baud rate change
>           Auto PPS made by CCID
>           Auto IFSD exchange
>           TPDU level exchange
>         dwMaxCCIDMsgLen        48
>         bClassGetResponse      00
>         bClassEnvelope         00
>         wlcdLayout           none
>         bPINSupport             0
>         bMaxCCIDBusySlots       1
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x83  EP 3 IN
>         bmAttributes            3
>           Transfer Type            Interrupt
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0010  1x 16 bytes
>         bInterval              16
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x04  EP 4 OUT
>         bmAttributes            2
>           Transfer Type            Bulk
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0040  1x 64 bytes
>         bInterval               0
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x85  EP 5 IN
>         bmAttributes            2
>           Transfer Type            Bulk
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0040  1x 64 bytes
>         bInterval               0
>     Interface Descriptor:
>       bLength                 9
>       bDescriptorType         4
>       bInterfaceNumber        2
>       bAlternateSetting       0
>       bNumEndpoints           1
>       bInterfaceClass         3 Human Interface Device
>       bInterfaceSubClass      0 No Subclass
>       bInterfaceProtocol      1 Keyboard
>       iInterface              0
>         HID Device Descriptor:
>           bLength                 9
>           bDescriptorType        33
>           bcdHID               1.10
>           bCountryCode            0 Not supported
>           bNumDescriptors         1
>           bDescriptorType        34 Report
>           wDescriptorLength      71
>          Report Descriptors:
>            ** UNAVAILABLE **
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x86  EP 6 IN
>         bmAttributes            3
>           Transfer Type            Interrupt
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0040  1x 64 bytes
>         bInterval               5
> Device Qualifier (for other device speed):
>   bLength                10
>   bDescriptorType         6
>   bcdUSB               2.00
>   bDeviceClass            0 (Defined at Interface level)
>   bDeviceSubClass         0
>   bDeviceProtocol         0
>   bMaxPacketSize0        64
>   bNumConfigurations      1
> Device Status:     0x0000
>   (Bus Powered)

-- 
Jan Suhr

Nitrokey UG (haftungsbeschr?nkt)
Web: https://www.nitrokey.com

Email: jan at nitrokey.com
Phone: +49 163 7010 408

Berliner Str. 166, 10715 Berlin, Germany
CEO / Gesch?ftsf?hrer: Jan Suhr
Register Record: AG Charlottenburg, HRB 164549 B
VAT ID / USt-IdNr.: DE300136599


From wk at gnupg.org  Tue Jan 26 23:50:21 2016
From: wk at gnupg.org (Werner Koch)
Date: Tue, 26 Jan 2016 23:50:21 +0100
Subject: [Announce] GnuPG 2.1.11 released
Message-ID: <87r3h4t0pe.fsf@vigenere.g10code.de>

Hello!

The GnuPG team is pleased to announce the availability of a new release
of GnuPG modern: Version 2.1.11.  See below for new features and bug
fixes.

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

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

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

Three different branches of GnuPG are actively maintained:

- GnuPG "modern" (2.1) is the latest development with a lot of new
  features.  This announcement is about this branch.

- GnuPG "stable" (2.0) is the current stable version for general use.
  This is what most users are currently using.

- GnuPG "classic" (1.4) is the old standalone version which is most
  suitable for older or embedded platforms.

You may not install "modern" (2.1) and "stable" (2.0) at the same
time.  However, it is possible to install "classic" (1.4) along with
any of the other versions.


Noteworthy changes in version 2.1.11
====================================

 * gpg: New command --export-ssh-key to replace the gpgkey2ssh tool.

 * gpg: Allow to generate mail address only keys with --gen-key.

 * gpg: "--list-options show-usage" is now the default.

 * gpg: Make lookup of DNS CERT records holding an URL work.

 * gpg: Emit PROGRESS status lines during key generation.

 * gpg: Don't check for ambigious or non-matching key specification in
   the config file or given to --encrypt-to.  This feature will return
   in 2.3.x.

 * gpg: Lock keybox files while updating them.

 * gpg: Solve rare error on Windows during keyring and Keybox updates.

 * gpg: Fix possible keyring corruption. (bug#2193)

 * gpg: Fix regression of "bkuptocard" sub-command in --edit-key and
   remove "checkbkupkey" sub-command introduced with 2.1.  (bug#2169)

 * gpg: Fix internal error in gpgv when using default keyid-format.

 * gpg: Fix --auto-key-retrieve to work with dirmngr.conf configured
   keyservers. (bug#2147).

 * agent: New option --pinentry-timeout.

 * scd: Improve unplugging of USB readers under Windows.

 * scd: Fix regression for generating RSA keys on card.

 * dirmmgr: All configured keyservers are now searched.

 * dirmngr: Install CA certificate for hkps.pool.sks-keyservers.net.
   Use this certiticate even if --hkp-cacert is not used.

 * gpgtar: Add actual encryption code.  gpgtar does now fully replace
   gpg-zip.

 * gpgtar: Fix filename encoding problem on Windows.

 * Print a warning if a GnuPG component is using an older version of
   gpg-agent, dirmngr, or scdaemon.

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

Please be aware that there are still known bugs which we are working on.
Check https://bugs.gnupg.org, https://wiki.gnupg.org, and the mailing
list archives for known problems and workarounds.


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

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

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

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

 ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.11.tar.bz2  (5102k)
 ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.11.tar.bz2.sig

or here:

 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.11.tar.bz2  (5102k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.11.tar.bz2.sig

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

 ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.11_20160126.exe  (2630k)
 ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.11_20160126.exe.sig

or here

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

The source used to build the Windows installer can be found in the same
directory with a ".tar.xz" suffix.  This Windows installer is missing
translations, it has no TOFU support, and no HKPS support.  However, it
fully supports Tor and the Tor browser.


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

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

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

     gpg --verify gnupg-2.1.11.tar.bz2.sig gnupg-2.1.11.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 an existing version of GnuPG, you have
   to verify the SHA-1 checksum.  On Unix systems the command to do
   this is either "sha1sum" or "shasum".  Assuming you downloaded the
   file gnupg-2.1.11.tar.bz2, you run the command like this:

     sha1sum gnupg-2.1.11.tar.bz2

   and check that the output matches the next line:

4af2032a60ff22e322b1c5b270d6d2228f59a3a3  gnupg-2.1.11.tar.bz2
ed237ba7bf8fd4fd3f2688ddd46b949dd15ebdd6  gnupg-w32-2.1.11_20160126.exe
6e7e5f6e296dc4b2317ce2023afa08b5a721e243  gnupg-w32-2.1.11_20160126.tar.xz


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

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


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

This version of GnuPG has support for 26 languages with Chinese,
Czech, French, German, Japanese, Russian, and Ukrainian being almost
completely translated (2156 different strings).


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

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

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

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

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

or in Portable Document Format at

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

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

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


Support
========

Please consult the archive of the gnupg-users mailing list before
reporting a bug <https://gnupg.org/documentation/mailing-lists.html>.
We suggest to send bug reports for a new release to this list in favor
of filing a bug at <https://bugs.gnupg.org>.  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 gnupg-devel mailing list for
discussion.

Maintenance and development of GnuPG is mostly financed by donations.
As of today we employ 3 full-time developers, one part-timer, and one
contractor.  They all work on GnuPG and closely related software like
Enigmail.  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, translating, suggesting, auditing, administering the
servers, spreading the word, answering questions on the mailing
lists, and donating money.


For the GnuPG hackers,

   Werner


p.s.
This is an announcement only mailing list.  Please send replies only to
the gnupg-users'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/20160126/a77c082d/attachment-0001.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From gniibe at fsij.org  Wed Jan 27 01:41:44 2016
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 27 Jan 2016 09:41:44 +0900
Subject: USB CCID issue
In-Reply-To: <56A7EA52.1040705@nitrokey.com>
References: <041001d15767$e23d2100$a6b76300$@enves.de>
 <56A7EA52.1040705@nitrokey.com>
Message-ID: <56A81248.8050308@fsij.org>

On 01/27/2016 06:51 AM, Jan Suhr wrote:
> The issue ticket is here:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775559

What I saw here is:

    http://pcsclite.alioth.debian.org/ccid/readers/Nitrokey_Storage.txt

    dwMaxCCIDMessageLength: 271 bytes

... which is common value for reader/token implementations.

Today, in your message it says:

    dwMaxCCIDMsgLen        48

That's quite unusual value.

If it's under development, I'd understand the situation.  After you
ship to users, please control your version of firmware.  It confuses
(at least) me.

> Could someone with better knowledge of the GPG stack help to
> localize the root cause?

For internal ccid driver of GnuPG, it cares the value of
dwMaxCCIDMessageLength, only for extended APDU level exchange.
Current code doesn't check dwMaxCCIDMessageLength for TPDU level
exchange.

It seems for me that your firmware of Nitrokey Storage tries to avoid
buffering (just using 64-byte buffer of USB directly) and expects host
PC to handle things (kindly on behalf of the device).

Well, once in 2010, when I was learning USB function implementation, I
had tried like that.  I was wrongly considered that simpler
implementation of USB stack on device side is better.  For the record,
you can see (dwMaxCCIDMessageLength = 64) in:
    http://pcsclite.alioth.debian.org/ccid/readers/Fsij_gnuk.txt


I think you also have some reason(s) (possibly, different than me) to
have this value and avoiding buffering.  But, I sincerely recommend to
support buffering in your firmware, as almost all device
implementations do, and let it have usual value like 271 for
dwMaxCCIDMessageLength.  Or else, it means that you have to take your
own risk to ask modification of CCID software on PC.
-- 


From gniibe at fsij.org  Wed Jan 27 04:30:31 2016
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 27 Jan 2016 12:30:31 +0900
Subject: [PATCH] migration to libusb-1.0
In-Reply-To: <878u3k4ndo.fsf@vigenere.g10code.de>
References: <569DEFEB.4000401@fsij.org> <878u3k4ndo.fsf@vigenere.g10code.de>
Message-ID: <56A839D7.3060301@fsij.org>

On 01/20/2016 06:21 PM, Werner Koch wrote:
> Please use $(LIBUSB_CPPFLAGS) - automake creates that variable.

I did.

I pushed the change.
-- 


From dkg at fifthhorseman.net  Wed Jan 27 07:34:00 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 27 Jan 2016 01:34:00 -0500
Subject: default keyid format
Message-ID: <87egd37cpz.fsf@alice.fifthhorseman.net>

hey all--

thanks for the 2.1.11 release.  I'm packaging it up for debian now, and
reviewing the changes.

i just noticed that 2c3e67430d9b523c85c81ae562223fd51e3608cc claims to
be signed-off-by me, but it also includes a change in the default
keyid-format, from 0xlong to short.

I actually think that the format should be 0xlong, *not* short [0] (or
keyids shouldn't be displayed at all, but that's probably a separate
discussion), so i was a little surprised to see this change as
attributed to me.

What about moving explicitly to 0xlong by default in the future?

     --dkg

[0] https://www.debian-administration.org/users/dkg/weblog/105


From wk at gnupg.org  Wed Jan 27 09:34:18 2016
From: wk at gnupg.org (Werner Koch)
Date: Wed, 27 Jan 2016 09:34:18 +0100
Subject: default keyid format
In-Reply-To: <87egd37cpz.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Wed, 27 Jan 2016 01:34:00 -0500")
References: <87egd37cpz.fsf@alice.fifthhorseman.net>
Message-ID: <87mvrrto8l.fsf@vigenere.g10code.de>

On Wed, 27 Jan 2016 07:34, dkg at fifthhorseman.net said:

> i just noticed that 2c3e67430d9b523c85c81ae562223fd51e3608cc claims to
> be signed-off-by me, but it also includes a change in the default
> keyid-format, from 0xlong to short.

Actually this new enum KF_DEFAULT is pretty useless: In keyid.c we have

  if (format == KF_DEFAULT)
    format = opt.keyid_format;
  if (format == KF_DEFAULT)
    format = KF_SHORT;

but in gpg.c we set opt.keyid_format to KF_SHORT. 

> I actually think that the format should be 0xlong, *not* short [0] (or

Well, I still hesitate to change this because it will break some users
applications (which are broken anyway by not using --with-colons).
Wouldn't it be better to always print the fingerprint with keylistings -
the fingerprint is the real identity of the key and not the kludge withe
long keyid.  This is what the option --with-fingerprint does.

> discussion), so i was a little surprised to see this change as
> attributed to me.

It was commited by Neal and he added another Signed-off-by line.


Shalom-Salam,

   Werner

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



From wk at gnupg.org  Wed Jan 27 10:06:46 2016
From: wk at gnupg.org (Werner Koch)
Date: Wed, 27 Jan 2016 10:06:46 +0100
Subject: [PATCH] gpg: Allow to set TOFU policy in the key editor.
In-Reply-To: <1453846646-26460-2-git-send-email-dgouttegattat@incenp.org>
 (Damien Goutte-Gattat's message of "Tue, 26 Jan 2016 23:17:26 +0100")
References: <1453846646-26460-1-git-send-email-dgouttegattat@incenp.org>
 <1453846646-26460-2-git-send-email-dgouttegattat@incenp.org>
Message-ID: <87io2ftmqh.fsf@vigenere.g10code.de>


> This patch allows to set TOFU policy through the interactive
> key editor.

Okay. ...

> +  tty_printf (_("Please assign a TOFU policy to this key\n"));
> +  tty_printf ("\n");
> +  tty_printf (_("  %d = Use the default policy\n"), 1);
> +  tty_printf (_("  %d = This key belongs to the stated owner\n"), 2);
> +  tty_printf (_("  %d = I do not know\n"), 3);
> +  tty_printf (_("  %d = This key is a forgery\n"), 4);
> +  tty_printf (_("  %d = Ask me next time\n"), 5);

In the other menus we use this format: 

    tty_printf (_("  (%d) Ask me next time\n"), 5);

Please use that too.  Can you also add something like

     tty_printf (_("  (%c) Cancel\n"), '0');

and return TOFU_POLICY_NONE in that case?  Using 'q' instead of '0'
would be nicer but it is alien to the other choices and we would also
need to have a translation entry for this.  I know that most menus miss
such an easy way to return to the previous menu but having such a choice
is more convenient.  Or should we return silently on an empty string?


Salam-Shalom,

   Werner

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



From cmt at burggraben.net  Wed Jan 27 09:32:41 2016
From: cmt at burggraben.net (Christoph Moench-Tegeder)
Date: Wed, 27 Jan 2016 09:32:41 +0100
Subject: build fixes for 2.1.11 - EAI_NODATA, EAI_ADDRFAMILY
Message-ID: <20160127083241.GA1518@elch.exwg.net>

Hi,

when compiling gnupg 2.1.11 on FreeBSD 10.2, the build fails in
dirmngr/dns-stuff.c as EAI_NODATA and EAI_ADDRFAMILY are not
defined on FreeBSD:

dns-stuff.c:180:10: error: use of undeclared identifier 'EAI_NODATA'
    case EAI_NODATA:    err = gpg_error (GPG_ERR_NO_DATA); break;
         ^
dns-stuff.c:186:10: error: use of undeclared identifier 'EAI_ADDRFAMILY'
    case EAI_ADDRFAMILY:err = gpg_error (GPG_ERR_EADDRNOTAVAIL); break;

In fact, those defines are disabled as "obsoleted" in netdb.h, and
IEEE 1003.1-2013 does not mention those constants.
NOTE: the code in question was already in 2.1.10, but I missed that
release.

To work around this, I propose the following patch:

--- dirmngr/dns-stuff.c.orig	2016-01-27 09:08:32.073992000 +0100
+++ dirmngr/dns-stuff.c	2016-01-27 09:09:23.454463000 +0100
@@ -177,13 +177,17 @@
     case EAI_BADFLAGS:  err = gpg_error (GPG_ERR_INV_FLAG); break;
     case EAI_FAIL:      err = gpg_error (GPG_ERR_SERVER_FAILED); break;
     case EAI_MEMORY:    err = gpg_error (GPG_ERR_ENOMEM); break;
+#ifdef EAI_NODATA
     case EAI_NODATA:    err = gpg_error (GPG_ERR_NO_DATA); break;
+#endif 
     case EAI_NONAME:    err = gpg_error (GPG_ERR_NO_NAME); break;
     case EAI_SERVICE:   err = gpg_error (GPG_ERR_NOT_SUPPORTED); break;
     case EAI_FAMILY:    err = gpg_error (GPG_ERR_EAFNOSUPPORT); break;
     case EAI_SOCKTYPE:  err = gpg_error (GPG_ERR_ESOCKTNOSUPPORT); break;
 #ifndef HAVE_W32_SYSTEM
+#ifdef EAI_ADDRFAMILY
     case EAI_ADDRFAMILY:err = gpg_error (GPG_ERR_EADDRNOTAVAIL); break;
+#endif
     case EAI_SYSTEM:    err = gpg_error_from_syserror (); break;
 #endif
     default:            err = gpg_error (GPG_ERR_UNKNOWN_ERRNO); break;

Regards,
Christoph

-- 
Spare Space


From wk at gnupg.org  Wed Jan 27 12:54:44 2016
From: wk at gnupg.org (Werner Koch)
Date: Wed, 27 Jan 2016 12:54:44 +0100
Subject: difference in key import counting between GnuPG 1.4 and 2.1
In-Reply-To: <87bn888fse.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Tue, 26 Jan 2016 11:30:09 -0500")
References: <87bn888fse.fsf@alice.fifthhorseman.net>
Message-ID: <87twlzs0e3.fsf@vigenere.g10code.de>

On Tue, 26 Jan 2016 17:30, dkg at fifthhorseman.net said:

> I believe that gpg 2.1 is counting some of the keys multiple times (once
> per subkey?) , but (for example), i'm not sure why it would claim 3
> secret keys read and 2 secret keys imported, while 1.4 just say 1 in
> each category.

Indeed, secret keys are counted in a different way in 2.1.  We count the
secret keys parts which are sent to the gpg-agent - this is done subkey
by subkey and thus we count subkeys.

So you imported 3 primary or subkeys but only 2 of them are new.
According to the code the other might be ausbkey - but you don't have
one.  I need to replicate your case.  Stay tuned.

I think the information about the secret subkeys is interesting but
clearly this is messing up the count.


Shalom-Salam,

   Werner

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



From wk at gnupg.org  Wed Jan 27 13:52:01 2016
From: wk at gnupg.org (Werner Koch)
Date: Wed, 27 Jan 2016 13:52:01 +0100
Subject: [Announce] GnuPG 2.1.11 released
In-Reply-To: <20160127073616.GA23989@fugu.vesath.org> (Gaetan Bisson's message
 of "Tue, 26 Jan 2016 21:36:16 -1000")
References: <87r3h4t0pe.fsf@vigenere.g10code.de>
 <20160127073616.GA23989@fugu.vesath.org>
Message-ID: <87pownrxqm.fsf@vigenere.g10code.de>

On Wed, 27 Jan 2016 08:36, bisson at archlinux.org said:

> make[3]: Entering directory '/opt/arch/svn-packages/gnupg/trunk/gnupg-2.1.11/tests/openpgp'
> FAIL: version.test

Please cat the file  version.test.log from the
/opt/arch/svn-packages/gnupg/trunk/gnupg-2.1.11/tests/openpgp
directory.


Salam-Shalom,

   Werner

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



From wk at gnupg.org  Wed Jan 27 14:36:10 2016
From: wk at gnupg.org (Werner Koch)
Date: Wed, 27 Jan 2016 14:36:10 +0100
Subject: build fixes for 2.1.11 - EAI_NODATA, EAI_ADDRFAMILY
In-Reply-To: <20160127083241.GA1518@elch.exwg.net> (Christoph Moench-Tegeder's
 message of "Wed, 27 Jan 2016 09:32:41 +0100")
References: <20160127083241.GA1518@elch.exwg.net>
Message-ID: <87h9hzrvp1.fsf@vigenere.g10code.de>

On Wed, 27 Jan 2016 09:32, cmt at burggraben.net said:

> To work around this, I propose the following patch:

Applied.  Thanks.

  4d67144 dirmngr: Build fix for FreeBSD (EAI macros)



Salam-Shalom,

   Werner

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



From wk at gnupg.org  Wed Jan 27 17:10:18 2016
From: wk at gnupg.org (Werner Koch)
Date: Wed, 27 Jan 2016 17:10:18 +0100
Subject: New regression test driver
Message-ID: <87d1snrok5.fsf@vigenere.g10code.de>

Hi!

Justus started to work on a new regression test system for GnuPG.
Although the old system works nicely it has one one major problem: We
can't run the regression tests on the target platform if we are
cross-compiling.  In particular for Windows this is a major drawback
because we can only do manual tests.

The old test system is a pure Unix one and requires a POSIX shell.  Such
a shell is not easily available on Windows and the rest of the test
framework is also not easy to port to Windows (or other target
platforms).  So instead of writing a Bourne shell for Windows we came up
with the idea to use something simpler: A Scheme interpreter is much
easy to do than a shell and chaning the existing tests to Scheme is
doable [1].

We do not want a full fledged Scheme system but the simplest thing we
can use - speed is not an issue here.  Thus gpgscm is based in
TinySCHEME (~7000 lines of C code).  The GnuPG branch justus/scm-3 has
the current code with all tests converted to Scheme.  This basically
works except that the output needs some cleanup.  Some of the tests may
now also be run on Windows and we are working to get the other tests
running there.  The final goal is that a user should be able to run the
regression tests on the target platform without installing extra tools.

This test driver is now limited to GnuPG but our other libraries and
tools may also benefit from a portable way of running the tests.  The
libraries mostly use test programs written in C and are run using the
standard automake generated driver.  Those test programs themself are
runable on the target platform but they miss the framework to run the
entire suite on the target platform.

The question is whether to move the new test framework (gpgscm and the
supporting Scheme code) from GnuPG to Libgpg-error.  Libgpg-error is
anyway a build dependency for all our software and thus it would the
logical place for shared code.



Shalom-Salam,

   Werner


[1] Before you ask: No, we don't want to re-write GnuPG in Scheme.

-- 
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/20160127/b50e9a84/attachment-0001.sig>

From marcoagpinto at mail.telepac.pt  Wed Jan 27 16:40:26 2016
From: marcoagpinto at mail.telepac.pt (Marco A.G.Pinto)
Date: Wed, 27 Jan 2016 15:40:26 +0000
Subject: Gpg4win - Improve pt_PT translation
Message-ID: <56A8E4EA.2090604@mail.telepac.pt>

Hello!

Maybe around the year 2010 I translated to Portuguese several files 
using Pootle.

Back then the encoding used wasn't UTF-8 and because of that the accents 
appear corrupted on Windows.

Just wondering what I can do to work again on the files.

Not sure how long it will take to revise/update all. Also, I have 
forgotten where to take them from.

Thanks!

Kind regards,
      >Marco A.G.Pinto
        -----------------------


-- 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20160127/a98833c8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: emails_signature2014c.png
Type: image/png
Size: 18633 bytes
Desc: not available
URL: </pipermail/attachments/20160127/a98833c8/attachment.png>

From dgouttegattat at incenp.org  Wed Jan 27 17:40:35 2016
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Wed, 27 Jan 2016 17:40:35 +0100
Subject: [PATCH] gpg: Allow to set TOFU policy in the key editor
In-Reply-To: <87io2ftmqh.fsf@vigenere.g10code.de>
References: <87io2ftmqh.fsf@vigenere.g10code.de>
Message-ID: <1453912835-16900-1-git-send-email-dgouttegattat@incenp.org>

Hi Werner,

> In the other menus we use this format: 
>
>     tty_printf (_("  (%d) Ask me next time\n"), 5);
>
> Please use that too.

OK, please find modified patch under the scissors below.


> Can you also add something like
>
>      tty_printf (_("  (%c) Cancel\n"), '0');
>
> and return TOFU_POLICY_NONE in that case?

Likewise.

Cheers,


-- >8 --
* g10/keyedit.c (keyedit_menu): Add a tofu command.
(tofu_policy_prompt): New.

--
Currently, the only way to explicitly assign a TOFU policy is
through the --tofu-policy option on the command line.

This patch allows to set TOFU policy through the interactive
key editor.

Signed-off-by: Damien Goutte-Gattat <dgouttegattat at incenp.org>
---
 g10/keyedit.c | 73 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 73 insertions(+)

diff --git a/g10/keyedit.c b/g10/keyedit.c
index 30f52a4..8018130 100644
--- a/g10/keyedit.c
+++ b/g10/keyedit.c
@@ -448,6 +448,49 @@ sign_mk_attrib (PKT_signature * sig, void *opaque)
 }
 
 
+#ifdef USE_TOFU
+static enum tofu_policy
+tofu_policy_prompt (void)
+{
+  char *p;
+  enum tofu_policy policy = -1;
+
+  tty_printf (_("Please assign a TOFU policy to this key\n"));
+  tty_printf ("\n");
+  tty_printf (_("  (%d) Use the default policy\n"), 1);
+  tty_printf (_("  (%d) This key belongs to the stated owner\n"), 2);
+  tty_printf (_("  (%d) I do not know\n"), 3);
+  tty_printf (_("  (%d) This key is a forgery\n"), 4);
+  tty_printf (_("  (%d) Ask me next time\n"), 5);
+  tty_printf (_("  (%c) Cancel\n"), '0');
+  tty_printf ("\n");
+
+  while (policy == -1)
+    {
+      p = cpr_get ("tofu_policy_prompt.policy", _("Your selection? "));
+      trim_spaces (p);
+      cpr_kill_prompt ();
+      if (*p && !p[1])
+        {
+	  switch (*p)
+	    {
+	    case '0': policy = TOFU_POLICY_NONE   ; break;
+	    case '1': policy = TOFU_POLICY_AUTO   ; break;
+	    case '2': policy = TOFU_POLICY_GOOD   ; break;
+	    case '3': policy = TOFU_POLICY_UNKNOWN; break;
+	    case '4': policy = TOFU_POLICY_BAD    ; break;
+	    case '5': policy = TOFU_POLICY_ASK    ; break;
+	    }
+	}
+
+      xfree (p);
+    }
+
+  return policy;
+}
+#endif /*!USE_TOFU*/
+
+
 static void
 trustsig_prompt (byte * trust_value, byte * trust_depth, char **regexp)
 {
@@ -1366,6 +1409,9 @@ enum cmdids
 #ifndef NO_TRUST_MODELS
   cmdENABLEKEY, cmdDISABLEKEY,
 #endif /*!NO_TRUST_MODELS*/
+#ifdef USE_TOFU
+  cmdTOFUPOLICY,
+#endif /*!USE_TOFU*/
   cmdSHOWPREF,
   cmdSETPREF, cmdPREFKS, cmdNOTATION, cmdINVCMD, cmdSHOWPHOTO, cmdUPDTRUST,
   cmdCHKTRUST, cmdADDCARDKEY, cmdKEYTOCARD, cmdBKUPTOCARD,
@@ -1447,6 +1493,9 @@ static struct
 #ifndef NO_TRUST_MODELS
   { "trust", cmdTRUST, KEYEDIT_NOT_SK, N_("change the ownertrust")},
 #endif /*!NO_TRUST_MODELS*/
+#ifdef USE_TOFU
+  { "tofu", cmdTOFUPOLICY, 0, N_("set TOFU policy")},
+#endif /*!USE_TOFU*/
   { "revsig", cmdREVSIG, KEYEDIT_NOT_SK,
     N_("revoke signatures on the selected user IDs")},
   { "revuid", cmdREVUID, KEYEDIT_NOT_SK | KEYEDIT_NEED_SK,
@@ -2167,6 +2216,30 @@ keyedit_menu (ctrl_t ctrl, const char *username, strlist_t locusr,
 	  break;
 #endif /*!NO_TRUST_MODELS*/
 
+#ifdef USE_TOFU
+	case cmdTOFUPOLICY:
+	  if (opt.trust_model != TM_TOFU && opt.trust_model != TM_TOFU_PGP)
+	    {
+	      tty_printf (_("TOFU policy can only be set while "
+			    "using a TOFU-enabled trust model\n"));
+	      break;
+	    }
+
+	  {
+	    enum tofu_policy policy = tofu_policy_prompt ();
+	    if (policy != TOFU_POLICY_NONE)
+	      {
+		err = tofu_set_policy (keyblock, policy);
+		if (err)
+		  {
+		    tty_printf (_("Error setting TOFU policy: %s\n"),
+				gpg_strerror (err));
+		  }
+	      }
+	  }
+	  break;
+#endif /*!USE_TOFU*/
+
 	case cmdPREF:
 	  {
 	    int count = count_selected_uids (keyblock);
-- 
1.8.4



From dgouttegattat at incenp.org  Wed Jan 27 17:43:57 2016
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Wed, 27 Jan 2016 17:43:57 +0100
Subject: [PATCH] gpgsm: Fix loading of CRLs with Auth Keyid extension.
Message-ID: <1453913037-17711-1-git-send-email-dgouttegattat@incenp.org>

* sm/call-dirmngr.c (run_command_inq_cb): Reply to SENDCERT_SKI
inquiries.

--
Trying to load a CRL with the following command:

  gpgsm --call-dirmngr loadcrl crl_file

fails with the following messgaes:

  gpgsm: unsupported inquiry 'SENDCERT_SKI ...'
  gpgsm: response of dirmngr: Unknown IPC inquire

if the CRL has a Authority Key Identifier extension.

This is because the callback used when passing commands to
dirmngr replies only to SENDCERT inquiries but not to
SENDCERT_SKI inquiries.

This patch fixes that behavior by replying to both types of
inquiries.

Signed-off-by: Damien Goutte-Gattat <dgouttegattat at incenp.org>
---
 sm/call-dirmngr.c | 16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/sm/call-dirmngr.c b/sm/call-dirmngr.c
index 881c484..46ffa51 100644
--- a/sm/call-dirmngr.c
+++ b/sm/call-dirmngr.c
@@ -921,18 +921,28 @@ run_command_inq_cb (void *opaque, const char *line)
   const char *s;
   int rc = 0;
 
-  if ((s = has_leading_keyword (line, "SENDCERT")))
+  if ((s = has_leading_keyword (line, "SENDCERT")) ||
+      (s = has_leading_keyword (line, "SENDCERT_SKI")))
     { /* send the given certificate */
       int err;
       ksba_cert_t cert;
+      ksba_sexp_t ski = NULL;
       const unsigned char *der;
-      size_t derlen;
+      size_t derlen, skilen;
+
+      if (has_leading_keyword (line, "SENDCERT_SKI"))
+        {
+          ski = make_simple_sexp_from_hexstr (s, &skilen);
+          s += skilen;
+          while (*s == ' ')
+            s++;
+        }
 
       line = s;
       if (!*line)
         return gpg_error (GPG_ERR_ASS_PARAMETER);
 
-      err = gpgsm_find_cert (line, NULL, &cert);
+      err = gpgsm_find_cert (line, ski, &cert);
       if (err)
         {
           log_error ("certificate not found: %s\n", gpg_strerror (err));
-- 
1.8.4



From dkg at fifthhorseman.net  Wed Jan 27 18:59:44 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 27 Jan 2016 12:59:44 -0500
Subject: gpgme and passprhases
Message-ID: <877fiu7vjj.fsf@alice.fifthhorseman.net>

Hi all--

I'm trying to get the pygpgme test suite in shape when working with gpg
2.1, and the remaining problems i see with it have to do with failed
attempts to set the passphrase with a callback.

Is there an expectation that gpgme should work without the agent?
should gpgme's passphrase callbacks work in 2.1 at all?

Below are the errors i'm seeing in the test suite when i run it with
"make check".

fwiw, the underlying command is:
   DISPLAY= DBUS_SESSION_BUS_ADDRESS= GPG_AGENT_INFO= python test_all.py -v



======================================================================
ERROR: test_encrypt_symmetric (tests.test_encrypt_decrypt.EncryptDecryptTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dkg/src/pygpgme/pygpgme/tests/test_encrypt_decrypt.py", line 136, in test_encrypt_symmetric
    ctx.encrypt(None, 0, plaintext, ciphertext)
GpgmeError: (7, 11, u'Bad passphrase')

======================================================================
ERROR: test_sign_with_passphrase_cb (tests.test_passphrase.PassphraseTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dkg/src/pygpgme/pygpgme/tests/test_passphrase.py", line 65, in test_sign_with_passphrase_cb
    new_sigs = ctx.sign(plaintext, signature, gpgme.SIG_MODE_CLEAR)
GpgmeError: (5, 99, u'Operation cancelled')

======================================================================
FAIL: test_sign_without_passphrase_cb (tests.test_passphrase.PassphraseTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dkg/src/pygpgme/pygpgme/tests/test_passphrase.py", line 43, in test_sign_without_passphrase_cb
    self.assertEqual(exc.args[0], gpgme.ERR_SOURCE_GPGME)
AssertionError: 5 != 7

----------------------------------------------------------------------

(fwiw, the latter failure shows that the error source is
gpgme.GPG_ERR_SOURCE_PINENTRY instead of gpgme.ERR_SOURCE_GPGME).

so i see a couple potential approaches:

 a) strip these tests from the test suite

 b) modify the test suite to use a loopback pinentry somehow

 c) make a custom pinentry specifically for use with the test suite

(a) is obviously the easiest, but maybe the least responsible.

Any suggestions for what the right thing to do is here?

    --dkg


From dkg at fifthhorseman.net  Wed Jan 27 19:40:59 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 27 Jan 2016 13:40:59 -0500
Subject: New regression test driver
In-Reply-To: <87d1snrok5.fsf@vigenere.g10code.de>
References: <87d1snrok5.fsf@vigenere.g10code.de>
Message-ID: <87zivq6f2c.fsf@alice.fifthhorseman.net>

On Wed 2016-01-27 11:10:18 -0500, Werner Koch wrote:

> Justus started to work on a new regression test system for GnuPG.
> Although the old system works nicely it has one one major problem: We
> can't run the regression tests on the target platform if we are
> cross-compiling.  In particular for Windows this is a major drawback
> because we can only do manual tests.
>
> The old test system is a pure Unix one and requires a POSIX shell.  Such
> a shell is not easily available on Windows and the rest of the test
> framework is also not easy to port to Windows (or other target
> platforms).  So instead of writing a Bourne shell for Windows we came up
> with the idea to use something simpler: A Scheme interpreter is much
> easy to do than a shell and chaning the existing tests to Scheme is
> doable [1].

I'm really glad to see this work, and happy that the project is thinking
about cross-platform testing as well.  hopefully a more comprehensive
test suite will help avoid regressions in the future, and will encourage
more bold refactorings/enhancements.

For debian, i'm inclined to run such a test suite via autopkgtest
because it will be useful for cross-compiled archives.

> We do not want a full fledged Scheme system but the simplest thing we
> can use - speed is not an issue here.  Thus gpgscm is based in
> TinySCHEME (~7000 lines of C code).  The GnuPG branch justus/scm-3 has
> the current code with all tests converted to Scheme.  This basically
> works except that the output needs some cleanup.  Some of the tests may
> now also be run on Windows and we are working to get the other tests
> running there.  The final goal is that a user should be able to run the
> regression tests on the target platform without installing extra tools.
>
> This test driver is now limited to GnuPG but our other libraries and
> tools may also benefit from a portable way of running the tests.  The
> libraries mostly use test programs written in C and are run using the
> standard automake generated driver.  Those test programs themself are
> runable on the target platform but they miss the framework to run the
> entire suite on the target platform.
>
> The question is whether to move the new test framework (gpgscm and the
> supporting Scheme code) from GnuPG to Libgpg-error.  Libgpg-error is
> anyway a build dependency for all our software and thus it would the
> logical place for shared code.

I'm fine with having it in libgpg-error, but i'm not sure i'd build it
for the debian packages.  In particular, tinyscheme is already packaged
for debian, and i'd just as soon rely on it during build and autopkgtest
rather than trying to maintain a fork explicitly.  do you expect gpgscm
to diverge at all from features available in tinyscheme?

   --dkg


From bisson at archlinux.org  Wed Jan 27 21:22:18 2016
From: bisson at archlinux.org (Gaetan Bisson)
Date: Wed, 27 Jan 2016 10:22:18 -1000
Subject: [Announce] GnuPG 2.1.11 released
In-Reply-To: <87pownrxqm.fsf@vigenere.g10code.de>
References: <87r3h4t0pe.fsf@vigenere.g10code.de>
 <20160127073616.GA23989@fugu.vesath.org>
 <87pownrxqm.fsf@vigenere.g10code.de>
Message-ID: <20160127202218.GA5523@fugu.vesath.org>

[2016-01-27 13:52:01 +0100] Werner Koch:
> On Wed, 27 Jan 2016 08:36, bisson at archlinux.org said:
> 
> > make[3]: Entering directory '/opt/arch/svn-packages/gnupg/trunk/gnupg-2.1.11/tests/openpgp'
> > FAIL: version.test
> 
> Please cat the file  version.test.log from the
> /opt/arch/svn-packages/gnupg/trunk/gnupg-2.1.11/tests/openpgp
> directory.

Here it is:

Test: version.test
GNUPGHOME=/opt/arch/svn-packages/gnupg/trunk/gnupg-2.1.11/tests/openpgp
gpg-agent[5761]: /opt/arch/svn-packages/gnupg/trunk/gnupg-2.1.11/tests/openpgp/gpg-agent.conf:1: obsolete option "use-standard-socket" - it has no effect
gpg-agent[5761]: no gpg-agent running in this session
version.test: Deleting old files
version.test: Starting the agent
gpg-connect-agent: no running gpg-agent - starting '/opt/arch/svn-packages/gnupg/trunk/gnupg-2.1.11/agent/gpg-agent|--debug-quick-random'
gpg-connect-agent: waiting for the agent to come up ... (5s)
gpg-connect-agent: connection to agent established
gpg-connect-agent: closing connection to agent
version.test: Creating sample data files
version.test: Unpacking samples
version.test: Storing private keys
version.test: Importing public demo and test keys
gpg: key 68697734: "Alfa Test (demo key) <alfa at example.net>" not changed
gpg: key 1AFDAB6C: "Charlie Test (demo key) <charlie at example.net>" not changed
gpg: key FAEF6D1B: "Echelon (demo key)" not changed
gpg: key 8FC282E6: "Golf Test (demo key) <golf at example.net>" not changed
gpg: key 04259677: "India Test (demo key) <india at example.net>" not changed
gpg: key 43C2D0C7: "Kilo Test (demo key) <kilo at example.net>" not changed
gpg: key A9E3B0B2: "Bob (demo key)" not changed
gpg: key EB9DC9E6: "Delta Test (demo key) <delta at example.net>" not changed
gpg: key 7372E243: "Foxtrot Test (demo key) <foxtrot at example.net>" not changed
gpg: key 34C6E3F1: "Hotel Test (demo key) <hotel at example.net>" not changed
gpg: key D2699313: "Juliet Test (demo key) <juliet at example.net>" not changed
gpg: key B79103F8: "Lima Test (demo key) <lima at example.net>" not changed
gpg: key BE5CF886: "Mallory (demo key)" not changed
gpg: key 30CEC684: "November Test (demo key) <november at example.net>" not changed
gpg: key 6D9732AC: "Oscar Test (demo key) <oscar at example.net>" not changed
gpg: key 3FF13206: "Papa test (demo key) <papa at example.net>" not changed
gpg: key 3C661C84: "Quebec Test (demo key) <quebec at example.net>" not changed
gpg: key 777FBED3: "Romeo Test (demo key) <romeo at example.net>" not changed
gpg: key A3AE3EA1: "Sierra Test (demo key) <sierra at example.net>" not changed
gpg: key 85A81F38: "Tango Test (demo key) <tango at example.net>" not changed
gpg: key 653244D6: "Uniform Test (demo key) <uniform at example.net>" not changed
gpg: key 61F04784: "Victor Test (demo key) <victor at example.org>" not changed
gpg: key EC67DBDE: "Whisky Test (demo key) <whisky at example.net>" not changed
gpg: key 567FB34A: "XRay Test (demo key) <xray at example.net>" not changed
gpg: key 4B11B25F: "Yankee Test (demo key) <yankee at example.net>" not changed
gpg: key 54ACD246: "Zulu Test (demo key) <zulu at example.net>" not changed
gpg: key D74C5F22: "Test one (pp=def) <one at example.com>" not changed
gpg: key C40FDECF: "Test two (no pp) <two at example.com>" not changed
gpg: key ECABF51D: "Test three (no pp) <three at example.com>" not changed
gpg: key 68697734: "Alfa Test (demo key) <alfa at example.net>" not changed
gpg: key 1AFDAB6C: "Charlie Test (demo key) <charlie at example.net>" not changed
gpg: key FAEF6D1B: "Echelon (demo key)" not changed
gpg: key 8FC282E6: "Golf Test (demo key) <golf at example.net>" not changed
gpg: key 04259677: "India Test (demo key) <india at example.net>" not changed
gpg: key 43C2D0C7: "Kilo Test (demo key) <kilo at example.net>" not changed
gpg: key A9E3B0B2: "Bob (demo key)" not changed
gpg: key EB9DC9E6: "Delta Test (demo key) <delta at example.net>" not changed
gpg: key 7372E243: "Foxtrot Test (demo key) <foxtrot at example.net>" not changed
gpg: key 34C6E3F1: "Hotel Test (demo key) <hotel at example.net>" not changed
gpg: key D2699313: "Juliet Test (demo key) <juliet at example.net>" not changed
gpg: key B79103F8: "Lima Test (demo key) <lima at example.net>" not changed
gpg: key BE5CF886: "Mallory (demo key)" not changed
gpg: key 30CEC684: "November Test (demo key) <november at example.net>" not changed
gpg: key 6D9732AC: "Oscar Test (demo key) <oscar at example.net>" not changed
gpg: key 3FF13206: "Papa test (demo key) <papa at example.net>" not changed
gpg: key 3C661C84: "Quebec Test (demo key) <quebec at example.net>" not changed
gpg: key 777FBED3: "Romeo Test (demo key) <romeo at example.net>" not changed
gpg: key A3AE3EA1: "Sierra Test (demo key) <sierra at example.net>" not changed
gpg: key 85A81F38: "Tango Test (demo key) <tango at example.net>" not changed
gpg: key 653244D6: "Uniform Test (demo key) <uniform at example.net>" not changed
gpg: key 61F04784: "Victor Test (demo key) <victor at example.org>" not changed
gpg: key EC67DBDE: "Whisky Test (demo key) <whisky at example.net>" not changed
gpg: key 567FB34A: "XRay Test (demo key) <xray at example.net>" not changed
gpg: key 4B11B25F: "Yankee Test (demo key) <yankee at example.net>" not changed
gpg: key 54ACD246: "Zulu Test (demo key) <zulu at example.net>" not changed
gpg: key 9D563E56: "Harry H. (test key) <hh@@ddorf.de>" not changed
gpg: key CED854FF: "Harry A. (RSA test key) <hh@@ddorf.de>" not changed
gpg: key 63FB5311: "Harry H. (test key) <hh@@ddorf.de>" not changed
gpg: key 8A772B08: "Harry A. (RSA test key) <hh@@ddorf.de>" not changed
gpg: key CBCABAE9: "Harry H. (test key) <hh@@ddorf.de>" not changed
gpg: key 35707037: "Harry A. (RSA test key) <hh@@ddorf.de>" not changed
gpg: key 82525B66: "Harry H. (test key) <hh@@ddorf.de>" not changed
gpg: key 5314D721: "Harry A. (RSA test key) <hh@@ddorf.de>" not changed
gpg: key E4984083: "Harry H. (test key) <hh@@ddorf.de>" not changed
gpg: key 7403F589: "Harry A. (RSA test key) <hh@@ddorf.de>" not changed
gpg: key 2A8B0840: "Harry H. (test key) <hh@@ddorf.de>" not changed
gpg: key 2A129899: "Harry A. (RSA test key) <hh@@ddorf.de>" not changed
gpg: Total number processed: 67
gpg:              unchanged: 67
gpg: key 439F02CA: "pgp5 test <pgp5 at dev.null>" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1
version.test: Preset passphrases
gpg-preset-passphrase: problem with the agent
gpg-preset-passphrase: caching passphrase failed: Invalid response

Thanks.

-- 
Gaetan


From dkg at fifthhorseman.net  Wed Jan 27 22:36:15 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 27 Jan 2016 16:36:15 -0500
Subject: default keyid format
In-Reply-To: <87mvrrto8l.fsf@vigenere.g10code.de>
References: <87egd37cpz.fsf@alice.fifthhorseman.net>
 <87mvrrto8l.fsf@vigenere.g10code.de>
Message-ID: <877fiu66y8.fsf@alice.fifthhorseman.net>

On Wed 2016-01-27 03:34:18 -0500, Werner Koch wrote:
> On Wed, 27 Jan 2016 07:34, dkg at fifthhorseman.net said:
>
>> i just noticed that 2c3e67430d9b523c85c81ae562223fd51e3608cc claims to
>> be signed-off-by me, but it also includes a change in the default
>> keyid-format, from 0xlong to short.
>
> Actually this new enum KF_DEFAULT is pretty useless: In keyid.c we have
>
>   if (format == KF_DEFAULT)
>     format = opt.keyid_format;
>   if (format == KF_DEFAULT)
>     format = KF_SHORT;
>
> but in gpg.c we set opt.keyid_format to KF_SHORT. 

hm, confusing.  but this is relevant for more than gpg, right?  it's
also relevant in gpgv at least.

>> I actually think that the format should be 0xlong, *not* short [0] (or
>
> Well, I still hesitate to change this because it will break some users
> applications (which are broken anyway by not using --with-colons).

I'm not particularly worried about those script -- if they're doing
parsing of non-machine-readable output, they are going to have fix that.

> Wouldn't it be better to always print the fingerprint with keylistings -
> the fingerprint is the real identity of the key and not the kludge withe
> long keyid.  This is what the option --with-fingerprint does.

I agree -- this was kind of what i was proposing about not showing any
keyids at all, but removing the keyid entirely seemed like it might be
too radical a suggestion.  I'm all for it if other people are up for it
though :)

More conservatively, i guess we could introduce a "none" option for
--keyid-format; and make "none" the default, while enabling
--with-fingerprint automatically.

>> discussion), so i was a little surprised to see this change as
>> attributed to me.
>
> It was commited by Neal and he added another Signed-off-by line.

I see that, but the commit lists me as the author, and the presence of
my own Signed-off-by line implies that i signed off on the whole piece,
including the switch back to short keyIDs.  This isn't a big deal (i'm
not proposing that git history needs to be rewritten), but if anyone
cares about using these things for attribution, it's probably something
to be more careful about in the future.

   --dkg


From dkg at fifthhorseman.net  Thu Jan 28 00:07:02 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 27 Jan 2016 18:07:02 -0500
Subject: [PATCH 2/2] with-fingerprint is automatic,
 and none is default keyid-format
In-Reply-To: <1453936022-16371-1-git-send-email-dkg@fifthhorseman.net>
References: <877fiu66y8.fsf@alice.fifthhorseman.net>
 <1453936022-16371-1-git-send-email-dkg@fifthhorseman.net>
Message-ID: <1453936022-16371-2-git-send-email-dkg@fifthhorseman.net>

---
 doc/DETAILS   |  4 ++--
 doc/gpg.texi  | 16 +++++++++-------
 g10/gpg.c     |  3 +--
 g10/keyid.c   |  4 ++--
 g10/options.h |  1 -
 g10/pkclist.c | 12 ++++--------
 6 files changed, 18 insertions(+), 22 deletions(-)

diff --git a/doc/DETAILS b/doc/DETAILS
index 7d5a5a8..7bab5cd 100644
--- a/doc/DETAILS
+++ b/doc/DETAILS
@@ -20,7 +20,7 @@ parts of the external API for GPG and GPGSM.
   example:
 #+begin_example
 $ gpg --with-colons --list-keys \
-      --with-fingerprint --with-fingerprint wk at gnupg.org
+      --with-fingerprint wk at gnupg.org
 pub:f:1024:17:6C7EE1B8621CC013:899817715:1055898235::m:::scESC:
 fpr:::::::::ECAF7590EB3443B5C7CF3ACB6C7EE1B8621CC013:
 uid:f::::::::Werner Koch <wk at g10code.com>:
@@ -31,7 +31,7 @@ sub:r:1536:20:5CE086B5B5A18FF4:899817788:1025961788:::::esc:
 fpr:::::::::AB059359A3B81F410FCFF97F5CE086B5B5A18FF4:
 #+end_example
 
-The double =--with-fingerprint= prints the fingerprint for the subkeys
+The =--with-fingerprint= prints the fingerprint for the subkeys
 too.  Old versions of gpg used a slightly different format and required
 the use of the option =--fixed-list-mode= to conform to the format
 described here.
diff --git a/doc/gpg.texi b/doc/gpg.texi
index 40eb8db..8fbb778 100644
--- a/doc/gpg.texi
+++ b/doc/gpg.texi
@@ -309,12 +309,11 @@ be used to locate a key.  Only public keys are listed.
 
 @item --fingerprint
 @opindex fingerprint
-List all keys (or the specified ones) along with their
-fingerprints. This is the same output as @option{--list-keys} but with
-the additional output of a line with the fingerprint. May also be
-combined with @option{--list-sigs} or @option{--check-sigs}.  If this
-command is given twice, the fingerprints of all secondary keys are
-listed too.
+List all keys (or the specified ones) along with the fingerprints of
+their subkeys. This is the same output as @option{--list-keys} but
+with the additional output of a line with the fingerprint for each
+subkey. May also be combined with @option{--list-sigs} or
+ at option{--check-sigs}.
 
 @item --list-packets
 @opindex list-packets
@@ -1602,7 +1601,10 @@ Select how to display key IDs. "short" is the traditional 8-character
 key ID. "long" is the more accurate (but less convenient)
 16-character key ID. Add an "0x" to either to include an "0x" at the
 beginning of the key ID, as in 0x99242560.  Note that this option is
-ignored if the option --with-colons is used.
+ignored if the option --with-colons is used.  The default is "none"
+because key IDs are rarely the best choice.  For cryptographically
+strong unique identifiers, use the fingerprint.  For human-memorable
+identifiers, use the User ID.
 
 @item --keyserver @code{name}
 @opindex keyserver
diff --git a/g10/gpg.c b/g10/gpg.c
index d660d47..699075b 100644
--- a/g10/gpg.c
+++ b/g10/gpg.c
@@ -2238,7 +2238,7 @@ main (int argc, char **argv)
     opt.mangle_dos_filenames = 0;
     opt.min_cert_level = 2;
     set_screen_dimensions ();
-    opt.keyid_format = KF_SHORT;
+    opt.fingerprint = 1;
     opt.def_sig_expire = "0";
     opt.def_cert_expire = "0";
     set_homedir (default_homedir ());
@@ -2554,7 +2554,6 @@ main (int argc, char **argv)
             break;
 
 	  case oWithFingerprint:
-            opt.with_fingerprint = 1;
             opt.fingerprint++;
             break;
 	  case oWithICAOSpelling:
diff --git a/g10/keyid.c b/g10/keyid.c
index 0bbd05d..b02f046 100644
--- a/g10/keyid.c
+++ b/g10/keyid.c
@@ -284,7 +284,7 @@ format_keyid (u32 *keyid, int format, char *buffer, int len)
   if (format == KF_DEFAULT)
     format = opt.keyid_format;
   if (format == KF_DEFAULT)
-    format = KF_SHORT;
+    format = KF_NONE;
 
   switch (format)
     {
@@ -331,7 +331,7 @@ keystrlen(void)
 {
   int format = opt.keyid_format;
   if (format == KF_DEFAULT)
-    format = KF_SHORT;
+    format = KF_NONE;
 
   switch(format)
     {
diff --git a/g10/options.h b/g10/options.h
index f8550d1..774e15e 100644
--- a/g10/options.h
+++ b/g10/options.h
@@ -70,7 +70,6 @@ struct
   int with_colons;
   int with_key_data;
   int with_icao_spelling; /* Print ICAO spelling with fingerprints.  */
-  int with_fingerprint; /* Option --with-fingerprint active.  */
   int with_keygrip;     /* Option --with-keygrip active.  */
   int with_secret;      /* Option --with-secret active.  */
   int fingerprint; /* list fingerprints */
diff --git a/g10/pkclist.c b/g10/pkclist.c
index d9ada59..21fdacb 100644
--- a/g10/pkclist.c
+++ b/g10/pkclist.c
@@ -529,8 +529,7 @@ check_signatures_trust( PKT_signature *sig )
     {
       if( !opt.quiet )
         log_info(_("WARNING: Using untrusted key!\n"));
-      if (opt.with_fingerprint)
-        print_fingerprint (NULL, pk, 1);
+      print_fingerprint (NULL, pk, 1);
       goto leave;
     }
 
@@ -640,8 +639,7 @@ check_signatures_trust( PKT_signature *sig )
       write_status( STATUS_TRUST_NEVER );
       log_info(_("WARNING: We do NOT trust this key!\n"));
       log_info(_("         The signature is probably a FORGERY.\n"));
-      if (opt.with_fingerprint)
-        print_fingerprint (NULL, pk, 1);
+      print_fingerprint (NULL, pk, 1);
       rc = gpg_error (GPG_ERR_BAD_SIGNATURE);
       break;
 
@@ -656,14 +654,12 @@ check_signatures_trust( PKT_signature *sig )
 
     case TRUST_FULLY:
       write_status( STATUS_TRUST_FULLY );
-      if (opt.with_fingerprint)
-        print_fingerprint (NULL, pk, 1);
+      print_fingerprint (NULL, pk, 1);
       break;
 
     case TRUST_ULTIMATE:
       write_status( STATUS_TRUST_ULTIMATE );
-      if (opt.with_fingerprint)
-        print_fingerprint (NULL, pk, 1);
+      print_fingerprint (NULL, pk, 1);
       break;
     }
 
-- 
2.7.0.rc3



From dkg at fifthhorseman.net  Thu Jan 28 00:07:01 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 27 Jan 2016 18:07:01 -0500
Subject: [PATCH 1/2] add --keyid-format=none
In-Reply-To: <877fiu66y8.fsf@alice.fifthhorseman.net>
References: <877fiu66y8.fsf@alice.fifthhorseman.net>
Message-ID: <1453936022-16371-1-git-send-email-dkg@fifthhorseman.net>

---
 doc/gpg.texi  | 2 +-
 g10/gpg.c     | 4 +++-
 g10/keyid.c   | 8 ++++++++
 g10/options.h | 2 +-
 4 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/doc/gpg.texi b/doc/gpg.texi
index e1835cf..40eb8db 100644
--- a/doc/gpg.texi
+++ b/doc/gpg.texi
@@ -1596,7 +1596,7 @@ mechanisms, in the order they are to be tried:
 
 @end table
 
- at item --keyid-format @code{short|0xshort|long|0xlong}
+ at item --keyid-format @code{none|short|0xshort|long|0xlong}
 @opindex keyid-format
 Select how to display key IDs. "short" is the traditional 8-character
 key ID. "long" is the more accurate (but less convenient)
diff --git a/g10/gpg.c b/g10/gpg.c
index 56bbd0d..d660d47 100644
--- a/g10/gpg.c
+++ b/g10/gpg.c
@@ -3235,7 +3235,9 @@ main (int argc, char **argv)
           case oEnableProgressFilter: opt.enable_progress_filter = 1; break;
 	  case oMultifile: multifile=1; break;
 	  case oKeyidFormat:
-	    if(ascii_strcasecmp(pargs.r.ret_str,"short")==0)
+	    if(ascii_strcasecmp(pargs.r.ret_str,"none")==0)
+	      opt.keyid_format=KF_NONE;
+	    else if(ascii_strcasecmp(pargs.r.ret_str,"short")==0)
 	      opt.keyid_format=KF_SHORT;
 	    else if(ascii_strcasecmp(pargs.r.ret_str,"long")==0)
 	      opt.keyid_format=KF_LONG;
diff --git a/g10/keyid.c b/g10/keyid.c
index f684276..0bbd05d 100644
--- a/g10/keyid.c
+++ b/g10/keyid.c
@@ -288,6 +288,11 @@ format_keyid (u32 *keyid, int format, char *buffer, int len)
 
   switch (format)
     {
+    case KF_NONE:
+      if (len > 0)
+        buffer[0] = '\0';
+      break;
+      
     case KF_SHORT:
       snprintf (buffer, len, "%08lX", (ulong)keyid[1]);
       break;
@@ -330,6 +335,9 @@ keystrlen(void)
 
   switch(format)
     {
+    case KF_NONE:
+      return 0;
+      
     case KF_SHORT:
       return 8;
 
diff --git a/g10/options.h b/g10/options.h
index 1407b2f..f8550d1 100644
--- a/g10/options.h
+++ b/g10/options.h
@@ -136,7 +136,7 @@ struct
     } compliance;
   enum
     {
-      KF_DEFAULT, KF_SHORT, KF_LONG, KF_0xSHORT, KF_0xLONG
+      KF_DEFAULT, KF_SHORT, KF_LONG, KF_0xSHORT, KF_0xLONG, KF_NONE
     } keyid_format;
   int shm_coprocess;
   const char *set_filename;
-- 
2.7.0.rc3



From liulk at likai.org  Thu Jan 28 07:24:37 2016
From: liulk at likai.org (Likai Liu)
Date: Thu, 28 Jan 2016 02:24:37 -0400
Subject: [PATCH] {dirmngr,tools}/Makefile.am add missing CFLAGS.
Message-ID: <1453962277-10608-1-git-send-email-liulk@likai.org>

---
 dirmngr/Makefile.am | 5 +++--
 tools/Makefile.am   | 4 ++--
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/dirmngr/Makefile.am b/dirmngr/Makefile.am
index 1c74d10..70321b9 100644
--- a/dirmngr/Makefile.am
+++ b/dirmngr/Makefile.am
@@ -140,10 +140,11 @@ t_ldap_parse_uri_SOURCES = \
 	t-ldap-parse-uri.c ldap-parse-uri.c ldap-parse-uri.h \
         http.c dns-stuff.c \
         $(ldap_url) $(t_common_src)
-t_ldap_parse_uri_CFLAGS = -DWITHOUT_NPTH=1
+t_ldap_parse_uri_CFLAGS = -DWITHOUT_NPTH=1 \
+			  $(GPG_ERROR_CFLAGS) $(LIBGCRYPT_CFLAGS)
 t_ldap_parse_uri_LDADD = $(ldaplibs) $(t_common_ldadd) $(DNSLIBS)
 
-t_dns_stuff_CFLAGS = -DWITHOUT_NPTH=1
+t_dns_stuff_CFLAGS = -DWITHOUT_NPTH=1 $(LIBGCRYPT_CFLAGS)
 t_dns_stuff_SOURCES = t-dns-stuff.c dns-stuff.c
 t_dns_stuff_LDADD   = $(t_common_ldadd) $(DNSLIBS)
 
diff --git a/tools/Makefile.am b/tools/Makefile.am
index 39c0f9c..87d0df5 100644
--- a/tools/Makefile.am
+++ b/tools/Makefile.am
@@ -132,8 +132,8 @@ gpgtar_SOURCES = \
 	gpgtar-extract.c \
 	gpgtar-list.c \
 	no-libgcrypt.c
-gpgtar_CFLAGS = $(GPG_ERROR_CFLAGS)
-gpgtar_LDADD = $(libcommon) $(GPG_ERROR_LIBS) \
+gpgtar_CFLAGS = $(GPG_ERROR_CFLAGS) $(NPTH_CFLAGS)
+gpgtar_LDADD = $(libcommon) $(GPG_ERROR_LIBS) $(NPTH_LIBS) \
                $(LIBINTL) $(NETLIBS) $(LIBICONV) $(W32SOCKLIBS)
 
 
-- 
2.5.4 (Apple Git-61)



From dkg at fifthhorseman.net  Thu Jan 28 16:45:22 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 28 Jan 2016 10:45:22 -0500
Subject: intermittent failures in tests/openpgp/gpgtar.test
Message-ID: <871t91btd9.fsf@alice.fifthhorseman.net>

Hi GnuPG folks--

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've modified the debian packaging to send the test output to the build
logs when the tests fail (it would be useful to do this automatically
upstream, btw -- if a test fails, and its log isn't insanely large, just
dump the log to the console on which the build is happening).

Here's the log of a build on an amd64 buildd where the build failed:

https://buildd.debian.org/status/fetch.php?pkg=gnupg2&arch=amd64&ver=2.1.11-3&stamp=1453989951

The contents of tests/openpgp/gpgtar.test.log is between the 'xxx'
lines:

xxx
Test: gpgtar.test
GNUPGHOME=/?PKGBUILDDIR?/tests/openpgp
gpgtar: gpg2: gpg: encrypted with 1024-bit ELG key, ID B27907AA, created 2003-12-31
gpgtar: gpg2:       "Test two (no pp) <two at example.com>"
gpgtar: gpg2: gpg: block_filter 0x00007eff22557d80: read error (size=12273,a->size=12273)
gpgtar: gpg2: gpg: block_filter 0x00007eff22559160: read error (size=13891,a->size=13891)
gpgtar: gpg2: gpg: WARNING: encrypted message has been manipulated!
gpgtar: gpg2: gpg: block_filter: pending bytes!
gpgtar: gpg2: gpg: block_filter: pending bytes!
gpgtar: error running '../../g10/gpg2': exit status 2
xxx

Sorry that it doesn't seem very informative -- if there's anything i can
do to provide more useful debug information, that would be great.
Unfortunately, i don't have an environment i can point to where this
happens reliably.  I've seen it happen once on my own build daemon, but
i can't seem to get it to repeat there.

Any ideas?

    --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/20160128/69aa019d/attachment.sig>

From wub at partyvan.eu  Fri Jan 29 06:50:10 2016
From: wub at partyvan.eu (Juuso Lapinlampi)
Date: Fri, 29 Jan 2016 05:50:10 +0000
Subject: [PATCH 1/1] Fix grammar and typos in source and changelog
Message-ID: <1454046610-32153-1-git-send-email-wub@partyvan.eu>

- occured -> occurred
- Tripple-DES -> Triple-DES

Fixes Lintian spelling-error-in-binary issues (for Debian).
---
 checks/armor.test        | 2 +-
 cipher/des.c             | 2 +-
 g10/ccid-driver.c        | 2 +-
 g10/pkclist.c            | 2 +-
 keyserver/ChangeLog-2011 | 2 +-
 util/regcomp.c           | 4 ++--
 util/regex_internal.c    | 4 ++--
 7 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/checks/armor.test b/checks/armor.test
index cfd2359..a23f8d8 100755
--- a/checks/armor.test
+++ b/checks/armor.test
@@ -734,7 +734,7 @@ wg7Md81a5RI3F2FG8747t9gX
 '
 
 # Bug 1179 solved 2010-05-12:
-# It occured for messages of a multiple of the iobuf block size where
+# It occurred for messages of a multiple of the iobuf block size where
 # the last line had no pad character.  Due to premature popping of the
 # armor filter gpg swalled the CRC line and passed the '-----END...'
 # line on to the decryption layer.
diff --git a/cipher/des.c b/cipher/des.c
index 756c146..5484076 100644
--- a/cipher/des.c
+++ b/cipher/des.c
@@ -104,7 +104,7 @@
  *
  *     if ( (error_msg = selftest()) )
  *     {
- *	   fprintf(stderr, "An error in the DES/Tripple-DES implementation occured: %s\n", error_msg);
+ *	   fprintf(stderr, "An error in the DES/Triple-DES implementation occurred: %s\n", error_msg);
  *	   abort();
  *     }
  */
diff --git a/g10/ccid-driver.c b/g10/ccid-driver.c
index 515b15a..6f7c9b2 100644
--- a/g10/ccid-driver.c
+++ b/g10/ccid-driver.c
@@ -2264,7 +2264,7 @@ ccid_poll (ccid_driver_t handle)
     }
   else if (msg[0] == RDR_to_PC_HardwareError)    
     {
-      DEBUGOUT ("hardware error occured\n");
+      DEBUGOUT ("hardware error occurred\n");
     }
   else
     {
diff --git a/g10/pkclist.c b/g10/pkclist.c
index 198e307..b78070e 100644
--- a/g10/pkclist.c
+++ b/g10/pkclist.c
@@ -952,7 +952,7 @@ build_pk_list( STRLIST rcpts, PK_LIST *ret_pk_list, unsigned int use )
             }
 
           /* Do group expand here too.  The trick here is to continue
-             the loop if any expansion occured.  The code above will
+             the loop if any expansion occurred.  The code above will
              then list all expanded keys. */
           if (expand_id(answer,&backlog,0))
             continue;
diff --git a/keyserver/ChangeLog-2011 b/keyserver/ChangeLog-2011
index 58a207d..e6e5a79 100644
--- a/keyserver/ChangeLog-2011
+++ b/keyserver/ChangeLog-2011
@@ -215,7 +215,7 @@
 	to avoid license conflicts if OpenLDAP or cURL is linked against
 	OpenSSL and we would thus indirectly link to OpenSSL.  This is
 	considered a bug fix and forgives all possible violations,
-	pertaining to this issue, possibly occured in the past.
+	pertaining to this issue, possibly occurred in the past.
 
 2006-07-26  David Shaw  <dshaw at jabberwocky.com>
 
diff --git a/util/regcomp.c b/util/regcomp.c
index 6964df9..aafb9c8 100644
--- a/util/regcomp.c
+++ b/util/regcomp.c
@@ -1764,7 +1764,7 @@ peek_token_bracket (token, input, syntax)
 
 /* Entry point of the parser.
    Parse the regular expression REGEXP and return the structure tree.
-   If an error is occured, ERR is set by error code, and return NULL.
+   If an error is occurred, ERR is set by error code, and return NULL.
    This function build the following tree, from regular expression <reg_exp>:
            CAT
            / \
@@ -3349,7 +3349,7 @@ build_word_op (dfa, not, err)
 /* This is intended for the expressions like "a{1,3}".
    Fetch a number from `input', and return the number.
    Return -1, if the number field is empty like "{,1}".
-   Return -2, If an error is occured.  */
+   Return -2, If an error is occurred.  */
 
 static int
 fetch_number (input, token, syntax)
diff --git a/util/regex_internal.c b/util/regex_internal.c
index 6f3a96e..4349f1b 100644
--- a/util/regex_internal.c
+++ b/util/regex_internal.c
@@ -793,7 +793,7 @@ re_node_set_merge (dest, src)
 
 /* Insert the new element ELEM to the re_node_set* SET.
    return 0 if SET already has ELEM,
-   return -1 if an error is occured, return 1 otherwise.  */
+   return -1 if an error is occurred, return 1 otherwise.  */
 
 static int
 re_node_set_insert (set, elem)
@@ -909,7 +909,7 @@ re_node_set_remove_at (set, idx)
 
 
 /* Add the token TOKEN to dfa->nodes, and return the index of the token.
-   Or return -1, if an error will be occured.  */
+   Or return -1, if an error will be occurred.  */
 
 static int
 re_dfa_add_node (dfa, token, mode)
-- 
2.7.0



From wk at gnupg.org  Fri Jan 29 09:17:12 2016
From: wk at gnupg.org (Werner Koch)
Date: Fri, 29 Jan 2016 09:17:12 +0100
Subject: [PATCH 1/1] Fix grammar and typos in source and changelog
In-Reply-To: <1454046610-32153-1-git-send-email-wub@partyvan.eu> (Juuso
 Lapinlampi's message of "Fri, 29 Jan 2016 05:50:10 +0000")
References: <1454046610-32153-1-git-send-email-wub@partyvan.eu>
Message-ID: <871t90ol4n.fsf@vigenere.g10code.de>

Hi,

Please specify for which software this patch is - best in the subject
and attach the patch.

You should also follow the doc/HACKING guidelines on how to send a
patch.  For such typo fixes no ChangeLog entries are required in the
commit log but a single "--" line is suggested so that the generated
ChangeLog is not flooded with unimportant (for the function of the
code) entries.

A DCO and a Signed-off-by line is not required for a typo fix, but if
you plan to send more patches you should follow the DCO rules.

I guess this patch is for gnupg 1.4 - fixing typos which are not user
visible in an old branch does not really make sense - there are more
important things to do.  Please check only the master branch for this.

Anyway, thanks for looking into this.


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/20160129/7d0d9af4/attachment.sig>

From wub at partyvan.eu  Fri Jan 29 10:56:48 2016
From: wub at partyvan.eu (Juuso Lapinlampi)
Date: Fri, 29 Jan 2016 09:56:48 +0000 (UTC)
Subject: [PATCH 1/8] web: Remove dead WWW mirrors
Message-ID: <190250007686438211.enqueue@partyvan.eu>

Ping, anyone merging or reviewing these patches? And yes, gnupg.ca is 
dead. All of these are dead.


From wk at gnupg.org  Fri Jan 29 14:35:07 2016
From: wk at gnupg.org (Werner Koch)
Date: Fri, 29 Jan 2016 14:35:07 +0100
Subject: default keyid format
In-Reply-To: <877fiu66y8.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Wed, 27 Jan 2016 16:36:15 -0500")
References: <87egd37cpz.fsf@alice.fifthhorseman.net>
 <87mvrrto8l.fsf@vigenere.g10code.de>
 <877fiu66y8.fsf@alice.fifthhorseman.net>
Message-ID: <87lh78ld9w.fsf@vigenere.g10code.de>

On Wed, 27 Jan 2016 22:36, dkg at fifthhorseman.net said:

>> but in gpg.c we set opt.keyid_format to KF_SHORT. 
>
> hm, confusing.  but this is relevant for more than gpg, right?  it's
> also relevant in gpgv at least.

Right.

> I'm not particularly worried about those script -- if they're doing
> parsing of non-machine-readable output, they are going to have fix that.

I just wanted to mentione this.  I am using long keyid for quite some
time now w/o problems and given that 2.1 changed the format anyway
(to "rsa2048/12345678") I agree that it is not a real world problem.

> More conservatively, i guess we could introduce a "none" option for
> --keyid-format; and make "none" the default, while enabling
> --with-fingerprint automatically.

"none" is a problem becuase the keyid is also used at other places and
wheere we do not have a fingerprint available.  Thus your original plan
to make "long" the default seems to be better.

Let me do this along with --with-fingerprint being the default and a new
option --without-fingerprint.

> I see that, but the commit lists me as the author, and the presence of
> my own Signed-off-by line implies that i signed off on the whole piece,
> including the switch back to short keyIDs.  This isn't a big deal (i'm

I'll woull add a comment about this to the change-to-long-keyid change
for historical correctness.


Salam-Shalom,

   Werner

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



From wk at gnupg.org  Fri Jan 29 16:07:02 2016
From: wk at gnupg.org (Werner Koch)
Date: Fri, 29 Jan 2016 16:07:02 +0100
Subject: [PATCH 1/8] web: Remove dead WWW mirrors
In-Reply-To: <190250007686438211.enqueue@partyvan.eu> (Juuso Lapinlampi's
 message of "Fri, 29 Jan 2016 09:56:48 +0000 (UTC)")
References: <190250007686438211.enqueue@partyvan.eu>
Message-ID: <87oac4jug9.fsf@vigenere.g10code.de>

On Fri, 29 Jan 2016 10:56, wub at partyvan.eu said:
> Ping, anyone merging or reviewing these patches? And yes, gnupg.ca is 
> dead. All of these are dead.

Not dead but redirects to gnupg.org - have some patience, I wrote the
admin.


Shalom-Salam,

   Werner

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



From gdt at ir.bbn.com  Sat Jan 30 02:02:49 2016
From: gdt at ir.bbn.com (Greg Troxel)
Date: Fri, 29 Jan 2016 20:02:49 -0500
Subject: status of S/MIME and interoperability?
Message-ID: <rmih9hvx4jq.fsf@fnord.ir.bbn.com>


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
issue of X.509 trust anchors with S/MIME in practice has been an
adventure.

Generally, I find that gnus/gpgsm works well.  I can process on receive
pretty much all S/MIME messages I receive.

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.

I wonder if anyone has done a more thorough investigation of MUA
interoperability, and if it is known whether the gnus/gpgsm->Outlook
lack of interop can be fairly pinned on Outlook, or whether it is a bug
on the free software side and should be fixed.

I have had no issues with OpenPGP.  However it appears that OpenPGP
tends to leave out Outlook users :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 180 bytes
Desc: not available
URL: </pipermail/attachments/20160129/c7fcab23/attachment-0001.sig>