From ueno at gnu.org  Sun Nov  1 02:53:06 2015
From: ueno at gnu.org (Daiki Ueno)
Date: Sun, 01 Nov 2015 10:53:06 +0900
Subject: [PATCH] agent, gpg: Forward progress output for --gen-key
Message-ID: <871tcav62l.fsf-ueno@gnu.org>

Hello,

I noticed that gpg --gen-key does not output any progress feedback, even
when it is invoked with --enable-progress-filter, despite the mention of
it in doc/DETAILS:

  *** PROGRESS <what> <char> <cur> <total>
  [...]
      Well known values for WHAT are:

             - pk_dsa   :: DSA key generation
             - pk_elg   :: Elgamal key generation
             - primegen :: Prime generation
             - need_entropy :: Waiting for new entropy in the RNG

With the attached patch, gpg-agent connects to the libgcrypt's progress
handler and forward the output to the caller, and gpg writes it if
requested.  I think this would also give GPGME an opportunity to
terminate the running gpg process with gpgme_cancel:

https://bugs.gnupg.org/gnupg/issue1415

(If I understand correctly, GPGME does not explictly kill the running gpg
process, but expects that it is terminated on write error.)

Regards,
-- 
Daiki Ueno
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-agent-gpg-Forward-progress-output-for-gen-key.patch
Type: text/x-patch
Size: 2885 bytes
Desc: not available
URL: </pipermail/attachments/20151101/50fa543c/attachment.bin>

From ueno at gnu.org  Sun Nov  1 03:04:43 2015
From: ueno at gnu.org (Daiki Ueno)
Date: Sun, 1 Nov 2015 11:04:43 +0900
Subject: [PATCH] dirmngr: Fix t-http compile error
Message-ID: <87si4qtqez.fsf-ueno@gnu.org>

* dirmngr/Makefile.am (t_http_CFLAGS): Add LIBASSUAN_CFLAGS.
(t_http_LDADD): Add LIBASSUAN_LIBS.

--
Now that assuan_sock_init is called in t-http.c (since commit 1e34007c),
the CFLAGS/LDADD need to be adjusted.

Signed-off-by: Daiki Ueno <ueno at gnu.org>
---
 dirmngr/Makefile.am | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/dirmngr/Makefile.am b/dirmngr/Makefile.am
index 009802a..9ed5878 100644
--- a/dirmngr/Makefile.am
+++ b/dirmngr/Makefile.am
@@ -131,9 +131,9 @@ endif
 t_http_SOURCES = t-http.c http.c dns-stuff.c
 t_http_CFLAGS  = -DWITHOUT_NPTH=1 \
 	         $(LIBGCRYPT_CFLAGS) $(NTBTLS_CFLAGS) $(LIBGNUTLS_CFLAGS) \
-                 $(GPG_ERROR_CFLAGS)
+                 $(GPG_ERROR_CFLAGS) $(LIBASSUAN_CFLAGS)
 t_http_LDADD   = $(t_common_ldadd) \
-	         $(NTBTLS_LIBS) $(LIBGNUTLS_LIBS) $(DNSLIBS)
+	         $(NTBTLS_LIBS) $(LIBGNUTLS_LIBS) $(DNSLIBS) $(LIBASSUAN_LIBS)
 
 t_ldap_parse_uri_SOURCES = \
 	t-ldap-parse-uri.c ldap-parse-uri.c ldap-parse-uri.h \
-- 
2.4.3



From ueno at gnu.org  Sun Nov  1 03:35:41 2015
From: ueno at gnu.org (Daiki Ueno)
Date: Sun, 1 Nov 2015 11:35:41 +0900
Subject: [PATCH] build: Use check_PROGRAMS for test programs
Message-ID: <87d1vutofr.fsf-ueno@gnu.org>

* agent/Makefile.am (check_PROGRAMS): Add test programs here, instead to
noinst_PROGRAMS.
* common/Makefile.am (check_PROGRAMS): Likewise.
dirmngr/Makefile.am (check_PROGRAMS): Likewise.
g10/Makefile.am (check_PROGRAMS): Likewise.

--
To reduce build time, defer compilation of test programs to the "make
check" phase.

Signed-off-by: Daiki Ueno <ueno at gnu.org>
---
 agent/Makefile.am   | 2 +-
 common/Makefile.am  | 2 +-
 dirmngr/Makefile.am | 2 +-
 g10/Makefile.am     | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/agent/Makefile.am b/agent/Makefile.am
index b33593d..3a3ec18 100644
--- a/agent/Makefile.am
+++ b/agent/Makefile.am
@@ -23,7 +23,7 @@ if !HAVE_W32CE_SYSTEM
 # fixme: Do no use simple-pwquery for preset-passphrase.
 libexec_PROGRAMS += gpg-preset-passphrase
 endif
-noinst_PROGRAMS = $(TESTS)
+check_PROGRAMS = $(TESTS)
 
 EXTRA_DIST = ChangeLog-2011 gpg-agent-w32info.rc
 
diff --git a/common/Makefile.am b/common/Makefile.am
index f84cea1..f296a8d 100644
--- a/common/Makefile.am
+++ b/common/Makefile.am
@@ -26,7 +26,7 @@ noinst_LIBRARIES = libcommon.a libcommonpth.a libgpgrl.a
 if !HAVE_W32CE_SYSTEM
 noinst_LIBRARIES += libsimple-pwquery.a
 endif
-noinst_PROGRAMS = $(module_tests) $(module_maint_tests)
+check_PROGRAMS = $(module_tests) $(module_maint_tests)
 TESTS = $(module_tests)
 
 BUILT_SOURCES = audit-events.h status-codes.h
diff --git a/dirmngr/Makefile.am b/dirmngr/Makefile.am
index 9ed5878..0d220a4 100644
--- a/dirmngr/Makefile.am
+++ b/dirmngr/Makefile.am
@@ -27,7 +27,7 @@ if USE_LDAPWRAPPER
 libexec_PROGRAMS = dirmngr_ldap
 endif
 
-noinst_PROGRAMS = $(module_tests) $(module_maint_tests)
+check_PROGRAMS = $(module_tests) $(module_maint_tests)
 TESTS = $(module_tests)
 
 AM_CPPFLAGS = -I$(top_srcdir)/common
diff --git a/g10/Makefile.am b/g10/Makefile.am
index 2fe5c9a..af8b8d8 100644
--- a/g10/Makefile.am
+++ b/g10/Makefile.am
@@ -35,7 +35,7 @@ bin_PROGRAMS = gpg2
 if !HAVE_W32CE_SYSTEM
 bin_PROGRAMS += gpgv2
 endif
-noinst_PROGRAMS = $(module_tests)
+check_PROGRAMS = $(module_tests)
 TESTS = $(module_tests)
 
 if ENABLE_BZIP2_SUPPORT
-- 
2.4.3



From ueno at gnu.org  Sun Nov  1 07:02:23 2015
From: ueno at gnu.org (Daiki Ueno)
Date: Sun, 01 Nov 2015 15:02:23 +0900
Subject: status code for gpgme_op_delete
Message-ID: <87fv0qs1e8.fsf-ueno@gnu.org>

Hello,

When trying to delete a key from GPGME, I am asked through Pinentry:

  Do you really want to permanently delete the OpenPGP secret key ...?

If I answer "No" to this, gpgme_op_delete does not return any error,
since there is no status output for this case.  Maybe DELETE_PROBLEM
could be extended or a new status code could be added?

Regards,
-- 
Daiki Ueno


From andreas.schwier.ml at cardcontact.de  Sun Nov  1 10:52:46 2015
From: andreas.schwier.ml at cardcontact.de (Andreas Schwier)
Date: Sun, 01 Nov 2015 10:52:46 +0100
Subject: Integrating n-of-m threshold scheme
In-Reply-To: <55EDD9DA.9080406@cardcontact.de>
References: <55EB2AB9.50506@cardcontact.de>
 <87lhcidtwy.fsf@vigenere.g10code.de> <55EDD9DA.9080406@cardcontact.de>
Message-ID: <5635E0EE.2090802@cardcontact.de>

Hi,

I've added a blog entry that explains the concept with more details.

http://www.smartcard-hsm.com/2015/10/10/Shared_Control_over_Key_Usage.html

Andreas

On 09/07/2015 08:39 PM, Andreas Schwier wrote:
>> What are the use cases you have in mind?
> The feature was actually developed based on a customer request. It will
> be used for 3 different use cases
> 
> 1. Protect access to CA signing keys
> In the CA procedure the CA key store may only be activated by two key
> custodians acting together. Because key custodians have different times
> on duty, a group of 6 persons are authorized and two must act together
> to enable CA keys.
> 
> 2. Key escrow
> User documents are encrypted for a private key controlled by the
> document owner. If the document owner can no longer take control, a
> group of people come together to enable access to the escrow key, for
> which a copy of each document is encrypted. In the scheme 5 out of 10
> key custodians must work together.
> 
> 3. Shared control SSH access
> There exists a dedicated and quite expensive hardware box that allows to
> share control for important SSH keys. Using a SmartCard-HSM to store the
> SSH key and the a n-of-m scheme allows a less costly alternative using
> standard tools.
> 
> Of course there are more applications, like safeguarding code signing
> keys for example. The other application is remote activation where the
> SmartCard-HSM connects to an authentication server for activation.
> 
> For the PKCS#11 interface we are looking to use the remote management
> interface available in the ScriptingServer of the OpenSCDP project. That
> is basically a HTTP protocol (RAMoverHTTP from Global Platform) that
> connects the SmartCard-HSM via the P11 module with a remote server.
> Purpose of the server is to manage the authentication protocol, i.e.
> provide a website to the key custodian and support the authentication
> protocol for both sides, the SmartCard-HSM performing the n-of-m scheme
> and the device with the private authentication key.
> 
> Sounds to me like the remote APDU feature is similar. Where would I find
> the code ?
> 
> 
>>
>>
>> Salam-Shalom,
>>
>>    Werner
>>
> 
> 


-- 

    ---------    CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#       #|   Sch?lerweg 38
   |#       #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 571 56149
    ---------    http://www.cardcontact.de
                 http://www.tscons.de
                 http://www.openscdp.org
                 http://www.smartcard-hsm.com



From wk at gnupg.org  Sun Nov  1 15:29:18 2015
From: wk at gnupg.org (Werner Koch)
Date: Sun, 01 Nov 2015 15:29:18 +0100
Subject: [PATCH] build: Use check_PROGRAMS for test programs
In-Reply-To: <87d1vutofr.fsf-ueno@gnu.org> (Daiki Ueno's message of "Sun, 1
 Nov 2015 11:35:41 +0900")
References: <87d1vutofr.fsf-ueno@gnu.org>
Message-ID: <87r3k923pd.fsf@vigenere.g10code.de>

On Sun,  1 Nov 2015 03:35, ueno at gnu.org said:

> To reduce build time, defer compilation of test programs to the "make
> check" phase.

I don think this is useful:

"make check" is only rarely run in contrast to "make".  Thus always
building the test programs helps finding build problems early.

For a final build this does not matter because a "make check" should be
run anyway.


Shalom-Salam,

   Werner

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



From wk at gnupg.org  Sun Nov  1 15:40:18 2015
From: wk at gnupg.org (Werner Koch)
Date: Sun, 01 Nov 2015 15:40:18 +0100
Subject: [PATCH] agent, gpg: Forward progress output for --gen-key
In-Reply-To: <871tcav62l.fsf-ueno@gnu.org> (Daiki Ueno's message of "Sun, 01
 Nov 2015 10:53:06 +0900")
References: <871tcav62l.fsf-ueno@gnu.org>
Message-ID: <87h9l52371.fsf@vigenere.g10code.de>

Hi!

Thanks for the patch.  Some comments:

On Sun,  1 Nov 2015 02:53, ueno at gnu.org said:

> +  if ( printchar == '\n' )
> +    snprintf (buf, sizeof buf -1, "%.20s X 100 100", what );
> +  else
> +    snprintf (buf, sizeof buf -1, "%.20s %c %d %d",
> +              what, printchar=='\n'?'X':printchar, current, total );
                       ^^^^^^^^^^^^^^^
This test will always be false - see above.  Can you please send a
revised patch?

> +  gcry_set_progress_handler (progress_cb, ctrl);

This changes a global variable in libgcrypt - should be set only once.

> +static gpg_error_t
> +agent_genkey_status_cb (void *opaque, const char *line)

Minor thing: I would prefer to have this named without the "agent_"
prefix.  I know that it is a little bit annoying if you have several
functions with the same name and gtags-mode presents an extra selection
screen. OTOH, "agent_" may indicate a global function.

Also please add a
GnuPG-bug-id: 1415
line to your commit message and add you explanations.


Salam-Shalom,

   Werner


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



From guilhem at fripost.org  Sun Nov  1 19:49:06 2015
From: guilhem at fripost.org (Guilhem Moulin)
Date: Sun, 1 Nov 2015 19:49:06 +0100
Subject: Proposal: New keydb format
In-Reply-To: <87vb9n7t2f.wl-neal@walfield.org>
References: <87a8r27xq9.wl-neal@walfield.org>
 <20151029142828.GA9973@localhost.localdomain>
 <87vb9n7t2f.wl-neal@walfield.org>
Message-ID: <20151101184906.GA28098@localhost.localdomain>

Hi again,

On Sat, 31 Oct 2015 at 01:58:00 +0100, Neal H. Walfield wrote:
> At Thu, 29 Oct 2015 15:28:28 +0100, Guilhem Moulin wrote:
>> Care to look into that?  I'd be happy to resume the benchmark later.
> 
> I spent a little bit of time on this this evening and found the bug.
> I think --with-colons --list-sigs should now work.

Thanks a lot!  Yes indeed it does, and for my use case the performance is just
amazing, especially with --list-sigs \o/  See the details below.

However note that in order to create a keyring in keydb format I had to
to apply to apply the following patch.  (But I guess the proper fix
would be to remove everything from and including the ?;? at the end of
each SQL statement.)

-8<-------------------------------------------------------------------------->8-
diff --git a/g10/sqlite.c b/g10/sqlite.c
index ee7514c..82577b4 100644
--- a/g10/sqlite.c
+++ b/g10/sqlite.c
@@ -105,7 +105,7 @@ sqlite3_stepx (sqlite3 *db,
       /* We can only process a single statement.  */
       if (tail)
         {
-          while (*tail == ' ' || *tail == ';')
+          while (*tail == '\n' || *tail == ' ' || *tail == ';')
             tail ++;
 
           if (*tail)
-8<-------------------------------------------------------------------------->8-

> Please feel free to run some benchmarks.

* Setup environment *

/run/shm is mounted in memory (tmpfs).  Benchmark is done on a x86_64,
4x Core i7-4770S @ 3.1GHz, 16GiB DDR3 PC3-12800.  (As shown in issue1938
the keybox is mostly problematic when using --list-sigs on a slower
32-bits CPU's such as my X60s' L2400.)

?gpg? is GnuPG 1.4.19
?gpg2? is GnuPG 2.1.9
?./g10/gpg2? is GnuPG neal/next branch (3ad5c81)

  for x in ring kbx kdb; do
    mkdir -m0700 /run/shm/"gnupg-$x"
    echo trusted-key 0x39278DA8109E6244 >/run/shm/"gnupg-$x"/gpg.conf
    echo trust-model always >>/run/shm/"gnupg-$x"/gpg.conf
    echo no-auto-check-trustdb >>/run/shm/"gnupg-$x"/gpg.conf
  done
  echo no-autostart | tee -a /run/shm/gnupg-kbx/gpg.conf >>/run/shm/gnupg-kdb/gpg.conf
  { echo no-default-keyring; echo primary-keyring gnupg-kdb:pubring.kdb; } >>/run/shm/gnupg-kdb/gpg.conf
  alias time="/usr/bin/time -f '%E (%U user, %S sys)  %Mk maxres'"


* Importing the keyring *

(From the same `gpg2 --export` command so that all three gnupg-*
keyrings contain the same keys, and in the same order.)

  ~$ gpg2 --export | time gpg --homedir /run/shm/gnupg-ring --import
  1:29.91 (61.68 user, 27.82 sys)  19148k maxres
  ~$ gpg2 --export | time gpg2 --homedir /run/shm/gnupg-kbx --import
  0:55.38 (12.74 user, 42.48 sys)  189444k maxres
  ~$ gpg2 --export | time ./g10/gpg2 --homedir /run/shm/gnupg-kdb --import
  0:09.76 (9.46 user, 0.18 sys)  31724k maxres


VERDICT: keybox format is faster that the legacy one, at the expense of
memory usage (20M vs almost 200M of max res set size); also the fact
that it spends most of its time in kernel space is suspicious.  Anyway,
the keydb format yields an impressive performance boost in (both kernel-
and userspace) CPU time and blow them both.


* Listing keys *

1293 public keys: `gpg2 --homedir /run/shm/gnupg-kbx --with-colons --list-keys | grep -c '^pub:'`

  ~$ time gpg --homedir /run/shm/gnupg-ring --list-keys >/dev/null
  0:01.94 (1.92 user, 0.01 sys)  11192k maxres
  ~$ strace -c gpg --homedir /run/shm/gnupg-ring --list-keys >/dev/null
  % time     seconds  usecs/call     calls    errors syscall
  ------ ----------- ----------- --------- --------- ----------------
   76.47    0.000013           0     21958           read
   23.53    0.000004           0      2586           lseek
    0.00    0.000000           0        91           write
    0.00    0.000000           0        22         6 open
    0.00    0.000000           0        14           close
  [?]
  ------ ----------- ----------- --------- --------- ----------------
  100.00    0.000017                 34466        23 total

  ~$ time gpg2 --homedir /run/shm/gnupg-kbx --list-keys >/dev/null
  0:00.60 (0.60 user, 0.00 sys)  16464k maxres
  ~$ strace -c gpg2 --homedir /run/shm/gnupg-kbx --list-keys >/dev/null
  % time     seconds  usecs/call     calls    errors syscall
  ------ ----------- ----------- --------- --------- ----------------
    0.00    0.000000           0      2051           read
    0.00    0.000000           0        96           write
    0.00    0.000000           0        26         9 open
    0.00    0.000000           0        17           close
    0.00    0.000000           0         6         1 stat
  [?]
  ------ ----------- ----------- --------- --------- ----------------
  100.00    0.000000                  2388        28 total

  ~$ time ./g10/gpg2 --homedir /run/shm/gnupg-kdb --list-keys >/dev/null
  0:00.73 (0.66 user, 0.07 sys)  108716k maxres
  ~$ strace -c ./g10/gpg2 --homedir /run/shm/gnupg-kdb --list-keys >/dev/null
  % time     seconds  usecs/call     calls    errors syscall
  ------ ----------- ----------- --------- --------- ----------------
   54.23    0.000231           0    171112           read
   40.38    0.000172           0    171094           lseek
    5.40    0.000023           1        38           munmap
    0.00    0.000000           0       102           write
    0.00    0.000000           0        28         8 open
  [?]
  ------ ----------- ----------- --------- --------- ----------------
  100.00    0.000426                354634      2628 total

VERDICT: keybox format is the fastest, both in terms of CPU time and
memory usage.  keydb comes close second in execution time, but needs
much more memory (16M vs over 100M of max res set size).  It also makes
significantly more read(2) and lseek(2), but it doesn't seem to have a
significant impact on the execution time.


* Listing sigs without nested lookups (--fast-list-mode) *

242993 sigs: `gpg2 --homedir /run/shm/gnupg-kbx --with-colons --list-sigs | grep -Ec '^(sig|rev):'`

  ~$ time gpg --homedir /run/shm/gnupg-ring --fast-list-mode --list-sigs >/dev/null
  0:02.06 (2.05 user, 0.00 sys)  11008k maxres
  $ strace -c gpg --homedir /run/shm/gnupg-ring --fast-list-mode --list-sigs >/dev/null
  % time     seconds  usecs/call     calls    errors syscall
  ------ ----------- ----------- --------- --------- ----------------
    0.00    0.000000           0     21958           read
    0.00    0.000000           0      2098           write
    0.00    0.000000           0        22         6 open
    0.00    0.000000           0        14           close
    0.00    0.000000           0         2           stat
  [?]
  ------ ----------- ----------- --------- --------- ----------------
  100.00    0.000000                 36473        23 total

  ~$ time gpg2 --homedir /run/shm/gnupg-kbx --fast-list-mode --list-sigs >/dev/null
  0:00.80 (0.80 user, 0.00 sys)  16420k maxres
  ~$ strace -c gpg2 --homedir /run/shm/gnupg-kbx --fast-list-mode --list-sigs >/dev/null
  % time     seconds  usecs/call     calls    errors syscall
  ------ ----------- ----------- --------- --------- ----------------
    0.00    0.000000           0      2051           read
    0.00    0.000000           0      1964           write
    0.00    0.000000           0        26         9 open
    0.00    0.000000           0        17           close
    0.00    0.000000           0         6         1 stat
  [?]
  ------ ----------- ----------- --------- --------- ----------------
  100.00    0.000000                  4256        28 total

  ~$ time ./g10/gpg2 --homedir /run/shm/gnupg-kdb --fast-list-mode --list-sigs >/dev/null
  0:00.96 (0.88 user, 0.08 sys)  108692k maxres
  ~$ strace -c ./g10/gpg2 --homedir /run/shm/gnupg-kdb --fast-list-mode --list-sigs >/dev/null
  % time     seconds  usecs/call     calls    errors syscall
  ------ ----------- ----------- --------- --------- ----------------
   46.36    0.000223           0    171112           read
   34.30    0.000165           0    171094           lseek
   19.33    0.000093           2        38           munmap
    0.00    0.000000           0      1970           write
    0.00    0.000000           0        28         8 open
  [?]
  ------ ----------- ----------- --------- --------- ----------------
  100.00    0.000481                356502      2628 total

VERDICT: pretty much the same as --list-keys, not surprisingly.


* Listing sigs with nested lookups *

166214 sigs from an unknown signer: `gpg2 --homedir /run/shm/gnupg-kbx --with-colons --list-sigs | grep -Ec '^(sig|rev):([^:]*:){8}\[User ID not found\]:'`
14340 unknown signers: `gpg2 --homedir /run/shm/gnupg-kbx --with-colons --list-sigs | sed -nr 's/(sig|rev):([^:]*:){3}([0-9A-F]{16}):([^:]*:){4}\[User ID not found\]:.*/\3/p' | sort -u | wc -l`

  ~$ time gpg --homedir /run/shm/gnupg-ring --list-sigs >/dev/null
  0:32.07 (25.26 user, 6.80 sys)  11612k maxres
  ~$ strace -c gpg --homedir /run/shm/gnupg-ring --list-sigs >/dev/null
  % time     seconds  usecs/call     calls    errors syscall
  ------ ----------- ----------- --------- --------- ----------------
   74.45    0.010518           0   7820193           read
   14.18    0.002004           0   2281813           getrusage
   11.13    0.001572           0   2281813           clock_gettime
    0.24    0.000034           0    154135           lseek
    0.00    0.000000           0      3307           write
  [?]
  ------ ----------- ----------- --------- --------- ----------------
  100.00    0.014128              12541477        23 total

  ~$ time gpg2 --homedir /run/shm/gnupg-kbx --list-sigs >/dev/null
  2:31.89 (14.51 user, 137.29 sys)  18724k maxres
  ~$ strace -c gpg2 --homedir /run/shm/gnupg-kbx --list-sigs >/dev/null
  % time     seconds  usecs/call     calls    errors syscall
  ------ ----------- ----------- --------- --------- ----------------
   99.95    1.729099           0  30097047           read
    0.02    0.000385           0     15461         9 open
    0.02    0.000356           0     15445           munmap
    0.00    0.000063           0     15473           mmap
    0.00    0.000044           0     15452           close
  [?]
  ------ ----------- ----------- --------- --------- ----------------
  100.00    1.729969              30193211        28 total

  ~$ time ./g10/gpg2 --homedir /run/shm/gnupg-kdb --list-sigs >/dev/null
  0:05.93 (5.75 user, 0.18 sys)  107972k maxres
  ~$ strace -c ./g10/gpg2 --homedir /run/shm/gnupg-kdb --list-sigs >/dev/null
  % time     seconds  usecs/call     calls    errors syscall
  ------ ----------- ----------- --------- --------- ----------------
   47.44    0.000269           0    270111           read
   32.45    0.000184           0    270093           lseek
    9.88    0.000056           0     34850     34848 access
    7.76    0.000044           0     69652           fcntl
    2.47    0.000014           0     52262           fstat
  [?]
  ------ ----------- ----------- --------- --------- ----------------
  100.00    0.000567                700901     34858 total

VERDICT: Nested lookups yield a quadratic complexity on the legacy
keyring and the keybox format. Again, it's weird that gpg takes most its
time in kernel mode (30000000 reads(2), really?); furthermore a read(2)
takes 57.45ns on the keybox vs 1.34ns on the legacy format.  Thanks to
the caching 2.1.9 brings the execution time from 20min to 2.5min.  But
*YAY* for the keydb format, which delivers its promises, and brings a
fantastic performance boost (at the expense of memory usage)!


* Building ownertrust *

  ~$ time gpg --homedir /run/shm/gnupg-ring --trust-model=pgp --check-trustdb
  0:08.01 (7.78 user, 0.22 sys)  104384k maxres
  ~$ rm -f /run/shm/gnupg-ring/trustdb.gpg 
  ~$ strace -c gpg --homedir /run/shm/gnupg-ring --trust-model=pgp --check-trustdb
  % time     seconds  usecs/call     calls    errors syscall
  ------ ----------- ----------- --------- --------- ----------------
   94.71    0.006102        3051         2           rename
    1.51    0.000097           0    189215           clock_gettime
    1.41    0.000091           0    188974           lseek
    1.16    0.000075           0     84746           read
    1.15    0.000074           0    189215           getrusage
  [?]
  ------ ----------- ----------- --------- --------- ----------------
  100.00    0.006443                671914        22 total

  ~$ time gpg2 --homedir /run/shm/gnupg-kbx --trust-model=pgp --check-trustdb
  0:06.81 (5.84 user, 0.97 sys)  102568k maxres
  ~$ rm -f /run/shm/gnupg-kbx/trustdb.gpg 
  ~$ strace -c gpg2 --homedir /run/shm/gnupg-kbx --trust-model=pgp --check-trustdb
  % time     seconds  usecs/call     calls    errors syscall
  ------ ----------- ----------- --------- --------- ----------------
   99.71    0.009584           0    180151           read
    0.12    0.000012           0       815         9 open
    0.10    0.000010           0       218           munmap
    0.03    0.000003           0      5283           write
    0.03    0.000003           0     15587           lseek
  [?]
  ------ ----------- ----------- --------- --------- ----------------
  100.00    0.009612                205584        28 total

  ~$ time ./g10/gpg2 --homedir /run/shm/gnupg-kdb --trust-model=pgp --check-trustdb
  0:11.35 (11.18 user, 0.16 sys)  248604k maxres
  ~$ rm -f /run/shm/gnupg-kdb/trustdb.gpg 
  ~$ strace -c ./g10/gpg2 --homedir /run/shm/gnupg-kdb --trust-model=pgp --check-trustdb
  % time     seconds  usecs/call     calls    errors syscall
  ------ ----------- ----------- --------- --------- ----------------
   51.40    0.000367           0    387421           read
   43.56    0.000311           0    394650           lseek
    1.26    0.000009           0      1088           brk
    1.12    0.000008           0      5760           write
    0.98    0.000007           0      9091           fstat
  [?]
  ------ ----------- ----------- --------- --------- ----------------
  100.00    0.000714                820003      6078 total

VERDICT: keydb format is slower than the other two, but overall either format
has comparable performance.


> FWIW, I probably won't be working on this much in the near future as
> it is not currently a priority for us.

Thanks for being honest about it and saying so; as for myself I'll
follow updates in your branch and eagerly wait for the new format :-)

-- 
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: </pipermail/attachments/20151101/69ace1ca/attachment.sig>

From neal at walfield.org  Sun Nov  1 21:51:40 2015
From: neal at walfield.org (Neal H. Walfield)
Date: Sun, 01 Nov 2015 21:51:40 +0100
Subject: Proposal: New keydb format
In-Reply-To: <20151101184906.GA28098@localhost.localdomain>
References: <87a8r27xq9.wl-neal@walfield.org>
 <20151029142828.GA9973@localhost.localdomain>
 <87vb9n7t2f.wl-neal@walfield.org>
 <20151101184906.GA28098@localhost.localdomain>
Message-ID: <87r3k9789v.wl-neal@walfield.org>

Hi,

At Sun, 1 Nov 2015 19:49:06 +0100,
Guilhem Moulin wrote:
> On Sat, 31 Oct 2015 at 01:58:00 +0100, Neal H. Walfield wrote:
> > At Thu, 29 Oct 2015 15:28:28 +0100, Guilhem Moulin wrote:
> >> Care to look into that?  I'd be happy to resume the benchmark later.
> > 
> > I spent a little bit of time on this this evening and found the bug.
> > I think --with-colons --list-sigs should now work.
> 
> Thanks a lot!  Yes indeed it does, and for my use case the performance is just
> amazing, especially with --list-sigs \o/  See the details below.
> 
> However note that in order to create a keyring in keydb format I had to
> to apply to apply the following patch.  (But I guess the proper fix
> would be to remove everything from and including the ?;? at the end of
> each SQL statement.)

I applied a patch similar to this to master, but I forgot to apply it
to the branch.  I'm sorry about that.

> > Please feel free to run some benchmarks.

Thanks for these benchmarks.  The results are overall very good, I
think.  Particularly given that I haven't actually spent time
optimizing the code.  Thanks to your work, you've given me a few
places to start.

FWIW, I think I know where the memory problem is and it should be
relatively easy to fix with little additional CPU overhead.

Thanks,

:) Neal


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

Thanks for the comments.  I am attaching a revised patch.

>> +  if ( printchar == '\n' )
>> +    snprintf (buf, sizeof buf -1, "%.20s X 100 100", what );
>> +  else
>> +    snprintf (buf, sizeof buf -1, "%.20s %c %d %d",
>> +              what, printchar=='\n'?'X':printchar, current, total );
>                        ^^^^^^^^^^^^^^^
> This test will always be false - see above.  Can you please send a
> revised patch?

Ugh, it seems like a copy and paste error.  The first condition actually
had !strcmp (what, "primegen"), as special PRINTCHAR values are used for
primegen.

>> +  gcry_set_progress_handler (progress_cb, ctrl);
>
> This changes a global variable in libgcrypt - should be set only once.

Yes, moved it to the startup.

>> +static gpg_error_t
>> +agent_genkey_status_cb (void *opaque, const char *line)
>
> Minor thing: I would prefer to have this named without the "agent_"
> prefix.  I know that it is a little bit annoying if you have several
> functions with the same name and gtags-mode presents an extra selection
> screen. OTOH, "agent_" may indicate a global function.

Sure, that makes sense.

> Also please add a
> GnuPG-bug-id: 1415
> line to your commit message and add you explanations.

Done.

Regards,
-- 
Daiki Ueno
-------------- next part --------------
A non-text attachment was scrubbed...
Name: v2-0001-agent-gpg-Forward-progress-output-for-gen-key.patch
Type: text/x-patch
Size: 3243 bytes
Desc: not available
URL: </pipermail/attachments/20151102/ee0e1114/attachment-0001.bin>

From gniibe at fsij.org  Mon Nov  2 06:55:53 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Mon, 02 Nov 2015 14:55:53 +0900
Subject: 2.1 migration and smartcard stub
In-Reply-To: <5621116B.6010609@fsij.org>
References: <5621116B.6010609@fsij.org>
Message-ID: <5636FAE9.6020004@fsij.org>

Hello,

I pushed my change for this with message changed and adding comments
for TRANSLATORS.

On 10/17/2015 12:02 AM, NIIBE Yutaka wrote:
> Hello,
> 
> At Debconf15, I was asked about 2.1 migration.  The bug is filed
> in Debian:
> 
>     gnupg2: gnupg 2.1 secret keys migration skips keys on smartcard
>     https://bugs.debian.org/795881
> 
> I think that GnuPG 2.1 should emit some message for smartkey stub.
> 
> In the end of this message, I put my proposal patch.  It memorizes if
> there were stub in private key migration, and if so, emit a message
> which suggests invocation of "gpg --card-status" with smartcard.
> Currently, the message is:
> 
>     To migrate private key stubs for smartcard, run: gpg --card-status with smartcard
> 
> But, I'm not sure if new PO message is worth for that.  I'm not sure
> if "gpg" in the message would be better than "gpg2" (there are
> instances of "gpg" as well as "gpg2" in existing code to emit
> messages), or not.
> 
> I'm not good at using plural form.  Please correct the message string.
> 
> Situation is: Private key (or private sub key) for smartcard has a
> stub (reference) to the specific card, instead of key material (which
> is on the card).  A single smartcard can have multiple private
> (sub)keys.  A user can use multiple smartcards.  If a user uses
> multiple smartcards, invocation should be done for each smartcard.
> 
> Perhaps, it would be good not to expose internal term "stub", and
> following would be better:
> 
>     To migrate secring.gpg for smartcard, with each smartcard, run:
>        gpg --card-status
--


From neal at walfield.org  Mon Nov  2 13:56:16 2015
From: neal at walfield.org (Neal H. Walfield)
Date: Mon, 02 Nov 2015 13:56:16 +0100
Subject: Fwd: Re: The --use-tor option
In-Reply-To: <5626B83B.3010708@riseup.net>
References: <56260A43.5090500@riseup.net> <87d1w9ojv5.fsf@vigenere.g10code.de>
 <CAFggDF1fWNBiRy18H_EDpefRMq8H6S1KKtKk-8uOKQEtEfry6g@mail.gmail.com>
 <5626448D.3070804@riseup.net> <87oaftmtjn.fsf@vigenere.g10code.de>
 <5626836F.7020709@riseup.net> <878u6xmiyc.fsf@vigenere.g10code.de>
 <5626B83B.3010708@riseup.net>
Message-ID: <87pozs7e6n.wl-neal@walfield.org>

At Tue, 20 Oct 2015 21:55:07 +0000,
Ivan Markin wrote:
> > That is called dirmmgr ;-).  You can even script that
> > 
> >   $ gpg-connect-agent --dirmngr \
> >       '/datafile -' 'dns_cert --dane wk at gnupg.org' /bye >1e42b367.pub
> 
> dirmngr is too GnuPG-specific, so I can't use it for my chat app for
> example. What is reason to reimplement it for each app (I mean what
> you're going to implement :) )?
> 
> 
> btw, this script doen't work for me.

This should work if you are running 2.1.  Are you?

Thanks,

:) Neal


From twim at riseup.net  Mon Nov  2 18:21:47 2015
From: twim at riseup.net (Ivan Markin)
Date: Mon, 2 Nov 2015 17:21:47 +0000
Subject: Fwd: Re: The --use-tor option
In-Reply-To: <87pozs7e6n.wl-neal@walfield.org>
References: <56260A43.5090500@riseup.net> <87d1w9ojv5.fsf@vigenere.g10code.de>
 <CAFggDF1fWNBiRy18H_EDpefRMq8H6S1KKtKk-8uOKQEtEfry6g@mail.gmail.com>
 <5626448D.3070804@riseup.net> <87oaftmtjn.fsf@vigenere.g10code.de>
 <5626836F.7020709@riseup.net> <878u6xmiyc.fsf@vigenere.g10code.de>
 <5626B83B.3010708@riseup.net> <87pozs7e6n.wl-neal@walfield.org>
Message-ID: <56379BAB.1070709@riseup.net>

Neal H. Walfield:
> Ivan Markin wrote:
>> btw, this script doen't work for me.
> 
> This should work if you are running 2.1.  Are you?

I am. 2.1.9. :)

-- 
Ivan Markin

-------------- 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/20151102/f31bb59d/attachment.sig>

From mmercer at twinprime.com  Tue Nov  3 23:06:10 2015
From: mmercer at twinprime.com (Marc Mercer)
Date: Tue, 3 Nov 2015 14:06:10 -0800
Subject: Smartcard Hotplug?
Message-ID: <CABygG_B+wfmbDUTDNcdu8oXHS+-FTgKyTH5qcOpArAC-+-hZjw@mail.gmail.com>

GPG Developers,
Hello.  I am hoping one of you might be able to provide some insight into
an issue I am having.  First, I will admit that I know this is not normally
where I would hope to find assistance, and that I should try the
gnupg-users list.  I have, and have not received any response there, or had
any luck in the freenode IRC room other than to direct me here.

Second, I appreciate any possible insight or ideas that may result from
this.

--
OSX:
We use gpg-agent with smartcards to establish ssh connections, so of
course,  --enable-ssh-support is being used.  In OSX, the behavior is as I
expect... plug the card in, the agent loads the SC data, caches the *pin*
after you have entered it, etc.  When you unplug, it removes the cached
data, and of course also loses access to the SC itself, so no more secure
key.  Now, plug it back in, and the agent is able to reload the key data
(not the pin of course).  This is how I *expect* it to work.

Fedora/Other Linuxes:
When we use the same setup as above, we get similar results, but with one
major difference.  On the linux distributions, I have been forced to kill
the gpg-agent and restart it to force the agent to reload the "replugged"
card.  Everything else works, except the "hotplug" support.

I have been unable to find any setting or any information about what to do
regarding the hotplug support, it isn't documented anywhere, and I can't
seem to find a flag to pass in gpg-agent.conf or to the cli...

Any insight into how to fix this issue on the linux distributions (even if
I have to work with the packaging team for fedora, and submit bugs to
ubuntu to package with the proper one) would be greatly appreciated.

Additional info:
GPG on OSX:  GPG2-2.0.29
GPG on Fedora: GPG2-2.19
GPG on Ubuntu: GPG2-2.0.22

Thanks!

Marc Mercer | *DevOps Architect*
M: (408) 470 - 9256 | E: mmercer at twinprime.com
805 Veterans Blvd, Redwood City CA 94063 | http://www.twinprime.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20151103/4a00d82e/attachment.html>

From gniibe at fsij.org  Wed Nov  4 00:45:15 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 04 Nov 2015 08:45:15 +0900
Subject: Smartcard Hotplug?
In-Reply-To: <CABygG_B+wfmbDUTDNcdu8oXHS+-FTgKyTH5qcOpArAC-+-hZjw@mail.gmail.com>
References: <CABygG_B+wfmbDUTDNcdu8oXHS+-FTgKyTH5qcOpArAC-+-hZjw@mail.gmail.com>
Message-ID: <5639470B.4070509@fsij.org>

Hello,

Thank you for your report and I'm sorry I couldn't respond to your
question in gnupg-users, in time.

On 11/04/2015 07:06 AM, Marc Mercer wrote:
> Fedora/Other Linuxes:
> When we use the same setup as above, we get similar results, but with one
> major difference.  On the linux distributions, I have been forced to kill
> the gpg-agent and restart it to force the agent to reload the "replugged"
> card.  Everything else works, except the "hotplug" support.

It should just work with no special configuration.  And it works for
me (at least) on Debian for three years (squeeze, wheezy, jessie,
current sid).

We need more information to figure out what's wrong on in your
environemnt.

Please let me know if you use PC/SC or not.  For GnuPG, there are two
ways to access smartcard; one is through PC/SC service and another is
accessing directly with libusb.

If you have other applications which use PC/SC service, you need to
use PC/SC service.  If not, you can just use smartcard with GnuPG (not
to install PC/SC at all).  For the latter, you need udev configuration
for your smartcard reader.  An example configuration can be seen in the
bug report of Debian:

    https://bugs.debian.org/bug=543217

In my case, it's in /lib/udev/rules.d/60-gnupg.rules
(Similar configuration is done by PC/SC service.)

You can get debug output of scdaemon by configuration of:

============================= .gnupg/scdaemon.conf
debug-level guru
debug-all
log-file /run/user/1000/scd-debug.log
=============================

Please note that it may include your passphrase for smartcard, so be
careful to share the debug output.

(1) With card inserted, invoke gpg --card-status
    Works or not?

(2) Remove the card

(3) With card inserted, again, invoke gpg --card-status
    Works or not?

Please give me your /run/user/1000/scd-debug.log
-- 


From gniibe at fsij.org  Wed Nov  4 01:48:58 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 04 Nov 2015 09:48:58 +0900
Subject: Smartcard Hotplug?
In-Reply-To: <CABygG_Cq=hbZxWnA0+=ZP2FLmWHf743-Cs23WpG+nAoYat5FTQ@mail.gmail.com>
References: <CABygG_B+wfmbDUTDNcdu8oXHS+-FTgKyTH5qcOpArAC-+-hZjw@mail.gmail.com>	<5639470B.4070509@fsij.org>
 <CABygG_Cq=hbZxWnA0+=ZP2FLmWHf743-Cs23WpG+nAoYat5FTQ@mail.gmail.com>
Message-ID: <563955FA.1040103@fsij.org>

Hello, Marc, thank you for your time.

On 11/04/2015 09:22 AM, Marc Mercer wrote:
> Manufacturer .....: Yubico

OK.  That's Yubikey.  I'm going to reproduce with Yubikey.  (My claim
in the previous mail (saying no problem) is not for Yubikey, but other
OpenPGPcard/token.)

Yubikey has applications other than GnuPG.  For authentication, there
are OTP and UDF.  I think that it is likely those features interfere
somehow.

Do you install some other packages for OTP/UDF/PIV?  Are there any
difference between your Fedora and Mac OS/X with regards to
OTP/UDF/PIV usage?

> Unfortunately, I cannot get scdaemon to output any debug logs.  I have
> adjusted the path, killed and restarted the scdaemon (or rather, let gpg2
> restart it), etc.  No output data via that medium.  (Have used
> /var/run/user/myuid/scd-debug.log,  ~/.gnupg/scd-debug.log and a few
> others,  no change -- no logs)

Actually, killing scdaemon is a bit difficult (we need to invoke kill
two times).  If it's 2.1.x, please do: gpgconf reload scdaemon

Also, let me try with my Yubikey.
-- 


From mmercer at twinprime.com  Wed Nov  4 02:03:22 2015
From: mmercer at twinprime.com (Marc Mercer)
Date: Tue, 3 Nov 2015 17:03:22 -0800
Subject: Smartcard Hotplug?
In-Reply-To: <563955FA.1040103@fsij.org>
References: <CABygG_B+wfmbDUTDNcdu8oXHS+-FTgKyTH5qcOpArAC-+-hZjw@mail.gmail.com>
 <5639470B.4070509@fsij.org>
 <CABygG_Cq=hbZxWnA0+=ZP2FLmWHf743-Cs23WpG+nAoYat5FTQ@mail.gmail.com>
 <563955FA.1040103@fsij.org>
Message-ID: <CABygG_DBrXhtfjMQJZCBcBn3jxJ-+1RzfWQDE9K7RBGsF+DK2g@mail.gmail.com>

Niibe,
I have both yubikey and "cryptostick" (now called NitroKey), and both
behave the same way.

I have not configured them for OTP/U2F or any of their other supported
methods/protocols, only use them for ssh authentication, for now.

For OSX, its simply install gpg-tools via brew cask install, ( no changes
to the actual package, it just bundles it and makes it a cli install
instead of having to go, download, etc).  OSX is a slightly older version
though (2.0 branch).

I'll try the gpgconf reload scdaemon in a second.


Marc Mercer | *DevOps Architect*
M: (408) 470 - 9256 | E: mmercer at twinprime.com
805 Veterans Blvd, Redwood City CA 94063 | http://www.twinprime.com


On Tue, Nov 3, 2015 at 4:48 PM, NIIBE Yutaka <gniibe at fsij.org> wrote:

> Hello, Marc, thank you for your time.
>
> On 11/04/2015 09:22 AM, Marc Mercer wrote:
> > Manufacturer .....: Yubico
>
> OK.  That's Yubikey.  I'm going to reproduce with Yubikey.  (My claim
> in the previous mail (saying no problem) is not for Yubikey, but other
> OpenPGPcard/token.)
>
> Yubikey has applications other than GnuPG.  For authentication, there
> are OTP and UDF.  I think that it is likely those features interfere
> somehow.
>
> Do you install some other packages for OTP/UDF/PIV?  Are there any
> difference between your Fedora and Mac OS/X with regards to
> OTP/UDF/PIV usage?
>
> > Unfortunately, I cannot get scdaemon to output any debug logs.  I have
> > adjusted the path, killed and restarted the scdaemon (or rather, let gpg2
> > restart it), etc.  No output data via that medium.  (Have used
> > /var/run/user/myuid/scd-debug.log,  ~/.gnupg/scd-debug.log and a few
> > others,  no change -- no logs)
>
> Actually, killing scdaemon is a bit difficult (we need to invoke kill
> two times).  If it's 2.1.x, please do: gpgconf reload scdaemon
>
> Also, let me try with my Yubikey.
> --
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20151103/78a6c369/attachment-0001.html>

From mmercer at twinprime.com  Wed Nov  4 01:22:01 2015
From: mmercer at twinprime.com (Marc Mercer)
Date: Tue, 3 Nov 2015 16:22:01 -0800
Subject: Smartcard Hotplug?
In-Reply-To: <5639470B.4070509@fsij.org>
References: <CABygG_B+wfmbDUTDNcdu8oXHS+-FTgKyTH5qcOpArAC-+-hZjw@mail.gmail.com>
 <5639470B.4070509@fsij.org>
Message-ID: <CABygG_Cq=hbZxWnA0+=ZP2FLmWHf743-Cs23WpG+nAoYat5FTQ@mail.gmail.com>

Niibe,
Thank you for the response :).

Below is the information I have based on what you were looking for (For
now, I will focus on Fedora, and assuming I can get it working, I can
handle ubuntu from there):


Showing no existing gpg-agent or scdaemon:

?[Tue Nov  3 16:09:04]-(mmercer at localhost)-[?]
?[~/.gnupg]> ps aux | grep gpg
mmercer  22438  0.0  0.0 114332  2264 pts/3    S+   16:09   0:00 grep
--color=auto --exclude-dir=.bzr --exclude-dir=.cvs --exclude-dir=.git
--exclude-dir=.hg --exclude-dir=.svn gpg
?[Tue Nov  3 16:09:08]-(mmercer at localhost)-[?]
?[~/.gnupg]> ps aux | grep scd
mmercer  22485  0.0  0.0 114332  2316 pts/3    S+   16:09   0:00 grep
--color=auto --exclude-dir=.bzr --exclude-dir=.cvs --exclude-dir=.git
--exclude-dir=.hg --exclude-dir=.svn scd

Plug in the card:

?[Tue Nov  3 16:09:13]-(mmercer at localhost)-[?]
?[~/.gnupg]> gpg2 --card-status

Application ID ...: D2760001240102000006002DCDD90000
Version ..........: 2.0
Manufacturer .....: Yubico
Serial number ....: 002DCDD9
Name of cardholder: Marc Mercer
Language prefs ...: en
Sex ..............: male
URL of public key : [not set]
Login data .......: ec2-user
Signature PIN ....: forced
Key attributes ...: rsa2048 rsa2048 rsa2048
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 4
Signature key ....: 740B 6B95 61A9 63C4 5165  D211 E909 31CA 2BFD 523A
      created ....: 2015-10-23 22:31:58
Encryption key....: A56E 701A C61B D8DC 4711  95BD D05C 0510 1565 738B
      created ....: 2015-10-23 22:32:52
Authentication key: 47EA 327C DB5D DD0F F38E  145E C74A 2066 D586 B7A3
      created ....: 2015-10-23 22:33:15
General key info..: sub  rsa2048/2BFD523A 2015-10-23 Marc Mercer <
mmercer at twinprime.com>
sec#  rsa2048/3DC2FE11  created: 2015-10-23  expires: 2020-10-21
ssb>  rsa2048/2BFD523A  created: 2015-10-23  expires: 2020-10-21
                        card-no: 0006 002DCDD9
ssb>  rsa2048/1565738B  created: 2015-10-23  expires: 2020-10-21
                        card-no: 0006 002DCDD9
ssb>  rsa2048/D586B7A3  created: 2015-10-23  expires: 2020-10-21
                        card-no: 0006 002DCDD9


We can now see that there are running gpg-agents and scdaemon:

?[Tue Nov  3 16:09:20]-(mmercer at localhost)-[?]
?[~/.gnupg]> ps aux | grep gpg
mmercer  22535  0.0  0.0 197076   864 ?        Ss   16:09   0:00 gpg-agent
--homedir /home/mmercer/.gnupg --use-standard-socket --daemon
mmercer  22587  0.0  0.0 114332  2112 pts/3    S+   16:09   0:00 grep
--color=auto --exclude-dir=.bzr --exclude-dir=.cvs --exclude-dir=.git
--exclude-dir=.hg --exclude-dir=.svn gpg
?[Tue Nov  3 16:09:27]-(mmercer at localhost)-[?]
?[~/.gnupg]> ps aux |grep scd
mmercer  22538  0.0  0.0 234324  4480 ?        SLl  16:09   0:00 scdaemon
--multi-server
mmercer  22634  0.0  0.0 114332  2304 pts/3    S+   16:09   0:00 grep
--color=auto --exclude-dir=.bzr --exclude-dir=.cvs --exclude-dir=.git
--exclude-dir=.hg --exclude-dir=.svn scd


Unplug the card:
?[Tue Nov  3 16:09:47]-(mmercer at localhost)-[?]
?[~/.gnupg]> gpg2 --card-status
gpg: selecting openpgp failed: Card error
gpg: OpenPGP card not available: Card error

Replug the card in:
?[Tue Nov  3 16:09:57]-(mmercer at localhost)-[?]
?[~/.gnupg]> gpg2 --card-status
gpg: selecting openpgp failed: Card error
gpg: OpenPGP card not available: Card error


Additional info:
Using pcsc:
Installed Packages
Name        : pcsc-lite-libs
Arch        : x86_64
Epoch       : 0
Version     : 1.8.13
Release     : 1.fc22
Size        : 51 k
Repo        : @System
Summary     : PC/SC Lite libraries
URL         : http://pcsclite.alioth.debian.org/
License     : BSD
Description : PC/SC Lite libraries.

The only udev rules I have in place are ones that I had to write in order
to obtain access to the device due to permissions:

?[/usr/lib/udev/rules.d]> cat 70-yubikey.rules
SUBSYSTEMS=="usb", DRIVERS=="usb", ATTRS{idVendor}=="1050", \
ATTRS{version}==" 2.00", ATTRS{manufacturer}=="Yubico", \
ATTRS{removable}=="removable", ATTRS{idProduct}=="0111", \
ATTRS{product}=="Yubikey NEO OTP+CCID", \
OWNER="mmercer", GROUP="mmercer"


Unfortunately, I cannot get scdaemon to output any debug logs.  I have
adjusted the path, killed and restarted the scdaemon (or rather, let gpg2
restart it), etc.  No output data via that medium.  (Have used
/var/run/user/myuid/scd-debug.log,  ~/.gnupg/scd-debug.log and a few
others,  no change -- no logs)

Let me know what to do/where to go next.

Thank you,

Marc Mercer | *DevOps Architect*
M: (408) 470 - 9256 | E: mmercer at twinprime.com
805 Veterans Blvd, Redwood City CA 94063 | http://www.twinprime.com


On Tue, Nov 3, 2015 at 3:45 PM, NIIBE Yutaka <gniibe at fsij.org> wrote:

> Hello,
>
> Thank you for your report and I'm sorry I couldn't respond to your
> question in gnupg-users, in time.
>
> On 11/04/2015 07:06 AM, Marc Mercer wrote:
> > Fedora/Other Linuxes:
> > When we use the same setup as above, we get similar results, but with one
> > major difference.  On the linux distributions, I have been forced to kill
> > the gpg-agent and restart it to force the agent to reload the "replugged"
> > card.  Everything else works, except the "hotplug" support.
>
> It should just work with no special configuration.  And it works for
> me (at least) on Debian for three years (squeeze, wheezy, jessie,
> current sid).
>
> We need more information to figure out what's wrong on in your
> environemnt.
>
> Please let me know if you use PC/SC or not.  For GnuPG, there are two
> ways to access smartcard; one is through PC/SC service and another is
> accessing directly with libusb.
>
> If you have other applications which use PC/SC service, you need to
> use PC/SC service.  If not, you can just use smartcard with GnuPG (not
> to install PC/SC at all).  For the latter, you need udev configuration
> for your smartcard reader.  An example configuration can be seen in the
> bug report of Debian:
>
>     https://bugs.debian.org/bug=543217
>
> In my case, it's in /lib/udev/rules.d/60-gnupg.rules
> (Similar configuration is done by PC/SC service.)
>
> You can get debug output of scdaemon by configuration of:
>
> ============================= .gnupg/scdaemon.conf
> debug-level guru
> debug-all
> log-file /run/user/1000/scd-debug.log
> =============================
>
> Please note that it may include your passphrase for smartcard, so be
> careful to share the debug output.
>
> (1) With card inserted, invoke gpg --card-status
>     Works or not?
>
> (2) Remove the card
>
> (3) With card inserted, again, invoke gpg --card-status
>     Works or not?
>
> Please give me your /run/user/1000/scd-debug.log
> --
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20151103/dfcc3ad0/attachment.html>

From gniibe at fsij.org  Wed Nov  4 07:55:25 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 04 Nov 2015 15:55:25 +0900
Subject: Smartcard Hotplug?
In-Reply-To: <CABygG_DBrXhtfjMQJZCBcBn3jxJ-+1RzfWQDE9K7RBGsF+DK2g@mail.gmail.com>
References: <CABygG_B+wfmbDUTDNcdu8oXHS+-FTgKyTH5qcOpArAC-+-hZjw@mail.gmail.com>
 <5639470B.4070509@fsij.org>
 <CABygG_Cq=hbZxWnA0+=ZP2FLmWHf743-Cs23WpG+nAoYat5FTQ@mail.gmail.com>
 <563955FA.1040103@fsij.org>
 <CABygG_DBrXhtfjMQJZCBcBn3jxJ-+1RzfWQDE9K7RBGsF+DK2g@mail.gmail.com>
Message-ID: <1446620125.4747.1.camel@fsij.org>

Another possibility is: there are multiple gpg-agent(s) running by
some configuration mistake.??When you encounter a problem, please also
check if there is only a single gpg-agent.
-- 


From mmercer at twinprime.com  Wed Nov  4 09:15:42 2015
From: mmercer at twinprime.com (Marc Mercer)
Date: Wed, 4 Nov 2015 00:15:42 -0800
Subject: Smartcard Hotplug?
In-Reply-To: <1446620125.4747.1.camel@fsij.org>
References: <CABygG_B+wfmbDUTDNcdu8oXHS+-FTgKyTH5qcOpArAC-+-hZjw@mail.gmail.com>
 <5639470B.4070509@fsij.org>
 <CABygG_Cq=hbZxWnA0+=ZP2FLmWHf743-Cs23WpG+nAoYat5FTQ@mail.gmail.com>
 <563955FA.1040103@fsij.org>
 <CABygG_DBrXhtfjMQJZCBcBn3jxJ-+1RzfWQDE9K7RBGsF+DK2g@mail.gmail.com>
 <1446620125.4747.1.camel@fsij.org>
Message-ID: <CABygG_C7OADqGYbvc=nx3FCH_pKpRVMbV-9bm-KKM=NhjA32+A@mail.gmail.com>

Niibe,
I have checked the dual gpg-agent,  that's a no go.

Happily, after issuing the reload scdaemon, we now have a scd-debug.log.

I looked through it, and did not see any particular information that I
would be concerned by, but of course I didn't take the time to try to
convert the dump data either.  If I need to I can regenerate keys later.

That said, I am not sure what the proper protocol is for when attaching a
log to the mailing list, if it should be inline, linked somewhere, etc.

For now, I didn't want to make the posting itself too clumsy, so I have
linked the logfile here:
https://gist.github.com/Daemoen/e079a7d0617526661e25

I figure gist is just as good a place as any.

If you need more information, let me know and I will try to get it to you
quickly.

Thanks,


Marc Mercer | *DevOps Architect*
M: (408) 470 - 9256 | E: mmercer at twinprime.com
805 Veterans Blvd, Redwood City CA 94063 | http://www.twinprime.com


On Tue, Nov 3, 2015 at 10:55 PM, NIIBE Yutaka <gniibe at fsij.org> wrote:

> Another possibility is: there are multiple gpg-agent(s) running by
> some configuration mistake.  When you encounter a problem, please also
> check if there is only a single gpg-agent.
> --
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20151104/88ad79ab/attachment-0001.html>

From gniibe at fsij.org  Wed Nov  4 11:05:27 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 04 Nov 2015 19:05:27 +0900
Subject: Smartcard Hotplug?
In-Reply-To: <CABygG_C7OADqGYbvc=nx3FCH_pKpRVMbV-9bm-KKM=NhjA32+A@mail.gmail.com>
References: <CABygG_B+wfmbDUTDNcdu8oXHS+-FTgKyTH5qcOpArAC-+-hZjw@mail.gmail.com>
 <5639470B.4070509@fsij.org>
 <CABygG_Cq=hbZxWnA0+=ZP2FLmWHf743-Cs23WpG+nAoYat5FTQ@mail.gmail.com>
 <563955FA.1040103@fsij.org>
 <CABygG_DBrXhtfjMQJZCBcBn3jxJ-+1RzfWQDE9K7RBGsF+DK2g@mail.gmail.com>
 <1446620125.4747.1.camel@fsij.org>
 <CABygG_C7OADqGYbvc=nx3FCH_pKpRVMbV-9bm-KKM=NhjA32+A@mail.gmail.com>
Message-ID: <1446631527.14879.1.camel@fsij.org>

Hello,

For a while, please configure your scdaemon.conf with a line.

==================== .gnupg/scdaemon.conf
disable-ccid
====================

With this option, scdaemon always use PC/SC service and I believe that
it will improve the situation of yours.

			*	*	*

On 2015-11-04 at 00:15 -0800, Marc Mercer wrote:
> For now, I didn't want to make the posting itself too clumsy, so I
> have linked the logfile here: ?https://gist.github.com/Daemoen/e079a7
> d0617526661e25

Thanks a lot.??I think that I've finally got a clue to solve this
issue of Yubikey and Cryptostick; I got some complaints but none was
reproducible.

IIUC, I think that the situation is like this:

(1) With the configuration of Yubikey and Cryptostick, a user actually
uses GnuPG's internal CCID driver (instead of PC/SC), if a user
doesn't specify disable-ccid.

That's because current scdaemon's logic is trying internal CCID driver
at first and then, going to PC/SC.

Because of Yubikey and Cryptostick's recommended configuration of udev
(which has other use something like OTP/U2F/PIV), the access by
internal CCID driver (unfortunately) doesn't fail.

Usually for other card readers, the access by internal CCID fails ang
goes to PC/SC, but this doesn't happen for Yubikey and Cryptostick.


(2) On Fedora, we would have some compatibility issue of old libusb.
GnuPG's ccid-driver.c expects return value of -ENODEV for bulk write
when it's gone, but it looks like the return value is different.??So,
internal CCID driver can't detect unplugging of tokens/reders.


While I ask you running scdaemon with disable-ccid option, I should
fix the problem of internal CCID driver.
-- 


From mmercer at twinprime.com  Wed Nov  4 18:08:49 2015
From: mmercer at twinprime.com (Marc Mercer)
Date: Wed, 4 Nov 2015 09:08:49 -0800
Subject: Smartcard Hotplug?
In-Reply-To: <1446631527.14879.1.camel@fsij.org>
References: <CABygG_B+wfmbDUTDNcdu8oXHS+-FTgKyTH5qcOpArAC-+-hZjw@mail.gmail.com>
 <5639470B.4070509@fsij.org>
 <CABygG_Cq=hbZxWnA0+=ZP2FLmWHf743-Cs23WpG+nAoYat5FTQ@mail.gmail.com>
 <563955FA.1040103@fsij.org>
 <CABygG_DBrXhtfjMQJZCBcBn3jxJ-+1RzfWQDE9K7RBGsF+DK2g@mail.gmail.com>
 <1446620125.4747.1.camel@fsij.org>
 <CABygG_C7OADqGYbvc=nx3FCH_pKpRVMbV-9bm-KKM=NhjA32+A@mail.gmail.com>
 <1446631527.14879.1.camel@fsij.org>
Message-ID: <CABygG_AaZS6CBEy1fTmA-=TeSY6d7CO6DdDPXPd+6BYB9Ghuuw@mail.gmail.com>

Niibe,
Ok, have done that and done some testing this morning.

With disable-ccid, I of course had no actual pcscd service, so determined I
needed to install pcsc-lite,
not just the libs.  Installed that, enabled the service, set disable-ccid
in the scdaemon.conf and attempted
to use gpg2 --card-status, and we are not loading at all at this point.  I
would imagine that has to do with
the fact that there is no pscs configuration for this card right now, so I
will see if I can dig around and find that.

Here is what I am seeing in the debug log with disable-ccid%:

2015-11-04 09:06:56 scdaemon[29294] listening on socket
'/home/mmercer/.gnupg/S.scdaemon'
2015-11-04 09:06:56 scdaemon[29294] handler for fd -1 started
2015-11-04 09:06:56 scdaemon[29294] DBG: enter: apdu_open_reader:
portstr=(null)
2015-11-04 09:06:56 scdaemon[29294] pcsc_list_readers failed: unknown PC/SC
error code (0x8010002e)
2015-11-04 09:06:56 scdaemon[29294] DBG: leave: apdu_open_reader => slot=-1
[pc/sc]
2015-11-04 09:06:56 scdaemon[29294] DBG: chan_5 -> OK GNU Privacy Guard's
Smartcard server ready
2015-11-04 09:06:56 scdaemon[29294] DBG: chan_5 <- GETINFO socket_name
2015-11-04 09:06:56 scdaemon[29294] DBG: chan_5 -> D
/home/mmercer/.gnupg/S.scdaemon
2015-11-04 09:06:56 scdaemon[29294] DBG: chan_5 -> OK
2015-11-04 09:06:56 scdaemon[29294] DBG: chan_5 <- OPTION event-signal=12
2015-11-04 09:06:56 scdaemon[29294] DBG: chan_5 -> OK
2015-11-04 09:06:56 scdaemon[29294] DBG: chan_5 <- SERIALNO openpgp
2015-11-04 09:06:56 scdaemon[29294] DBG: enter: apdu_open_reader:
portstr=(null)
2015-11-04 09:06:56 scdaemon[29294] pcsc_list_readers failed: unknown PC/SC
error code (0x8010002e)
2015-11-04 09:06:56 scdaemon[29294] DBG: leave: apdu_open_reader => slot=-1
[pc/sc]
2015-11-04 09:06:56 scdaemon[29294] DBG: chan_5 -> ERR 100663404 Card error
<SCD>
2015-11-04 09:06:56 scdaemon[29294] DBG: chan_5 <- RESTART
2015-11-04 09:06:56 scdaemon[29294] DBG: chan_5 -> OK

This was after I cleared up all services and the log so that it would be
easy to see what was happening.

I will continue to see if I can find the settings, but hope this proves to
be useful in the meantime.

Thank you for your assistance and attention to this,


Marc Mercer | *DevOps Architect*
M: (408) 470 - 9256 | E: mmercer at twinprime.com
805 Veterans Blvd, Redwood City CA 94063 | http://www.twinprime.com


On Wed, Nov 4, 2015 at 2:05 AM, NIIBE Yutaka <gniibe at fsij.org> wrote:

> Hello,
>
> For a while, please configure your scdaemon.conf with a line.
>
> ==================== .gnupg/scdaemon.conf
> disable-ccid
> ====================
>
> With this option, scdaemon always use PC/SC service and I believe that
> it will improve the situation of yours.
>
>                         *       *       *
>
> On 2015-11-04 at 00:15 -0800, Marc Mercer wrote:
> > For now, I didn't want to make the posting itself too clumsy, so I
> > have linked the logfile here:  https://gist.github.com/Daemoen/e079a7
> > d0617526661e25
>
> Thanks a lot.  I think that I've finally got a clue to solve this
> issue of Yubikey and Cryptostick; I got some complaints but none was
> reproducible.
>
> IIUC, I think that the situation is like this:
>
> (1) With the configuration of Yubikey and Cryptostick, a user actually
> uses GnuPG's internal CCID driver (instead of PC/SC), if a user
> doesn't specify disable-ccid.
>
> That's because current scdaemon's logic is trying internal CCID driver
> at first and then, going to PC/SC.
>
> Because of Yubikey and Cryptostick's recommended configuration of udev
> (which has other use something like OTP/U2F/PIV), the access by
> internal CCID driver (unfortunately) doesn't fail.
>
> Usually for other card readers, the access by internal CCID fails ang
> goes to PC/SC, but this doesn't happen for Yubikey and Cryptostick.
>
>
> (2) On Fedora, we would have some compatibility issue of old libusb.
> GnuPG's ccid-driver.c expects return value of -ENODEV for bulk write
> when it's gone, but it looks like the return value is different.  So,
> internal CCID driver can't detect unplugging of tokens/reders.
>
>
> While I ask you running scdaemon with disable-ccid option, I should
> fix the problem of internal CCID driver.
> --
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20151104/25847060/attachment.html>

From gniibe at fsij.org  Thu Nov  5 01:03:48 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 05 Nov 2015 09:03:48 +0900
Subject: Smartcard Hotplug?
In-Reply-To: <CABygG_AaZS6CBEy1fTmA-=TeSY6d7CO6DdDPXPd+6BYB9Ghuuw@mail.gmail.com>
References: <CABygG_B+wfmbDUTDNcdu8oXHS+-FTgKyTH5qcOpArAC-+-hZjw@mail.gmail.com>	<5639470B.4070509@fsij.org>	<CABygG_Cq=hbZxWnA0+=ZP2FLmWHf743-Cs23WpG+nAoYat5FTQ@mail.gmail.com>	<563955FA.1040103@fsij.org>	<CABygG_DBrXhtfjMQJZCBcBn3jxJ-+1RzfWQDE9K7RBGsF+DK2g@mail.gmail.com>	<1446620125.4747.1.camel@fsij.org>	<CABygG_C7OADqGYbvc=nx3FCH_pKpRVMbV-9bm-KKM=NhjA32+A@mail.gmail.com>	<1446631527.14879.1.camel@fsij.org>
 <CABygG_AaZS6CBEy1fTmA-=TeSY6d7CO6DdDPXPd+6BYB9Ghuuw@mail.gmail.com>
Message-ID: <563A9CE4.9020808@fsij.org>

Hello,

I pushed my change for the issue of internal CCID driver of GnuPG.

    http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=1e94a672efb8bf66f416bc63bf6670e509a21fe5

It will be in the next release (2.1.10).  I think that this change
fix the issue on Fedora with internal CCID driver of GnuPG.

I tried with my Yubikey, but I realized that my device is

	Yubico Yubikey NEO OTP+U2F

... with lack of CCID (and OpenPGPcard) support.


On 11/05/2015 02:08 AM, Marc Mercer wrote:
> With disable-ccid, I of course had no actual pcscd service, so determined I
> needed to install pcsc-lite,
> not just the libs.  Installed that, enabled the service, set disable-ccid
> in the scdaemon.conf and attempted
> to use gpg2 --card-status, and we are not loading at all at this point.  I
> would imagine that has to do with
> the fact that there is no pscs configuration for this card right now, so I
> will see if I can dig around and find that.

Looking the repository (pkgs.fedoraproject.org), I think that you also
need to install "pcsc-lite-ccid" package to access the device.

> Here is what I am seeing in the debug log with disable-ccid%:
> 
> 2015-11-04 09:06:56 scdaemon[29294] listening on socket
> '/home/mmercer/.gnupg/S.scdaemon'
> 2015-11-04 09:06:56 scdaemon[29294] handler for fd -1 started
> 2015-11-04 09:06:56 scdaemon[29294] DBG: enter: apdu_open_reader:
> portstr=(null)
> 2015-11-04 09:06:56 scdaemon[29294] pcsc_list_readers failed: unknown PC/SC
> error code (0x8010002e)
> 2015-11-04 09:06:56 scdaemon[29294] DBG: leave: apdu_open_reader => slot=-1
> [pc/sc]
> 2015-11-04 09:06:56 scdaemon[29294] DBG: chan_5 -> OK GNU Privacy Guard's
> Smartcard server ready
> 2015-11-04 09:06:56 scdaemon[29294] DBG: chan_5 <- GETINFO socket_name
> 2015-11-04 09:06:56 scdaemon[29294] DBG: chan_5 -> D
> /home/mmercer/.gnupg/S.scdaemon
> 2015-11-04 09:06:56 scdaemon[29294] DBG: chan_5 -> OK
> 2015-11-04 09:06:56 scdaemon[29294] DBG: chan_5 <- OPTION event-signal=12
> 2015-11-04 09:06:56 scdaemon[29294] DBG: chan_5 -> OK
> 2015-11-04 09:06:56 scdaemon[29294] DBG: chan_5 <- SERIALNO openpgp
> 2015-11-04 09:06:56 scdaemon[29294] DBG: enter: apdu_open_reader:
> portstr=(null)
> 2015-11-04 09:06:56 scdaemon[29294] pcsc_list_readers failed: unknown PC/SC
> error code (0x8010002e)
> 2015-11-04 09:06:56 scdaemon[29294] DBG: leave: apdu_open_reader => slot=-1
> [pc/sc]
> 2015-11-04 09:06:56 scdaemon[29294] DBG: chan_5 -> ERR 100663404 Card error
> <SCD>
> 2015-11-04 09:06:56 scdaemon[29294] DBG: chan_5 <- RESTART
> 2015-11-04 09:06:56 scdaemon[29294] DBG: chan_5 -> OK

Thanks.  It is expected result (given the condition there's no libccid).
--


From mmercer at twinprime.com  Thu Nov  5 09:06:47 2015
From: mmercer at twinprime.com (Marc Mercer)
Date: Thu, 5 Nov 2015 00:06:47 -0800
Subject: Smartcard Hotplug?
In-Reply-To: <563A9CE4.9020808@fsij.org>
References: <CABygG_B+wfmbDUTDNcdu8oXHS+-FTgKyTH5qcOpArAC-+-hZjw@mail.gmail.com>
 <5639470B.4070509@fsij.org>
 <CABygG_Cq=hbZxWnA0+=ZP2FLmWHf743-Cs23WpG+nAoYat5FTQ@mail.gmail.com>
 <563955FA.1040103@fsij.org>
 <CABygG_DBrXhtfjMQJZCBcBn3jxJ-+1RzfWQDE9K7RBGsF+DK2g@mail.gmail.com>
 <1446620125.4747.1.camel@fsij.org>
 <CABygG_C7OADqGYbvc=nx3FCH_pKpRVMbV-9bm-KKM=NhjA32+A@mail.gmail.com>
 <1446631527.14879.1.camel@fsij.org>
 <CABygG_AaZS6CBEy1fTmA-=TeSY6d7CO6DdDPXPd+6BYB9Ghuuw@mail.gmail.com>
 <563A9CE4.9020808@fsij.org>
Message-ID: <CABygG_BC2PmDjPvL5T8XtLNyZY1GGWrQUmy80nxJy2yscNPJfg@mail.gmail.com>

Niibe,
Thank you so much for your help!  I now have a working hotplug scenario via
pcscd, and the rest of my functions are working now as well.  I could not
be happier.

I will document the process on my blog later tonight so that others can
benefit from the info.  Hopefully it should save you some troubles as users
struggle to get the right combination of configs in place.

It fixed my cryptostick as well, so I am ecstatic :)

-Marc


Marc Mercer | *DevOps Architect*
M: (408) 470 - 9256 | E: mmercer at twinprime.com
805 Veterans Blvd, Redwood City CA 94063 | http://www.twinprime.com


On Wed, Nov 4, 2015 at 4:03 PM, NIIBE Yutaka <gniibe at fsij.org> wrote:

> Hello,
>
> I pushed my change for the issue of internal CCID driver of GnuPG.
>
>
> http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=1e94a672efb8bf66f416bc63bf6670e509a21fe5
>
> It will be in the next release (2.1.10).  I think that this change
> fix the issue on Fedora with internal CCID driver of GnuPG.
>
> I tried with my Yubikey, but I realized that my device is
>
>         Yubico Yubikey NEO OTP+U2F
>
> ... with lack of CCID (and OpenPGPcard) support.
>
>
> On 11/05/2015 02:08 AM, Marc Mercer wrote:
> > With disable-ccid, I of course had no actual pcscd service, so
> determined I
> > needed to install pcsc-lite,
> > not just the libs.  Installed that, enabled the service, set disable-ccid
> > in the scdaemon.conf and attempted
> > to use gpg2 --card-status, and we are not loading at all at this point.
> I
> > would imagine that has to do with
> > the fact that there is no pscs configuration for this card right now, so
> I
> > will see if I can dig around and find that.
>
> Looking the repository (pkgs.fedoraproject.org), I think that you also
> need to install "pcsc-lite-ccid" package to access the device.
>
> > Here is what I am seeing in the debug log with disable-ccid%:
> >
> > 2015-11-04 09:06:56 scdaemon[29294] listening on socket
> > '/home/mmercer/.gnupg/S.scdaemon'
> > 2015-11-04 09:06:56 scdaemon[29294] handler for fd -1 started
> > 2015-11-04 09:06:56 scdaemon[29294] DBG: enter: apdu_open_reader:
> > portstr=(null)
> > 2015-11-04 09:06:56 scdaemon[29294] pcsc_list_readers failed: unknown
> PC/SC
> > error code (0x8010002e)
> > 2015-11-04 09:06:56 scdaemon[29294] DBG: leave: apdu_open_reader =>
> slot=-1
> > [pc/sc]
> > 2015-11-04 09:06:56 scdaemon[29294] DBG: chan_5 -> OK GNU Privacy Guard's
> > Smartcard server ready
> > 2015-11-04 09:06:56 scdaemon[29294] DBG: chan_5 <- GETINFO socket_name
> > 2015-11-04 09:06:56 scdaemon[29294] DBG: chan_5 -> D
> > /home/mmercer/.gnupg/S.scdaemon
> > 2015-11-04 09:06:56 scdaemon[29294] DBG: chan_5 -> OK
> > 2015-11-04 09:06:56 scdaemon[29294] DBG: chan_5 <- OPTION event-signal=12
> > 2015-11-04 09:06:56 scdaemon[29294] DBG: chan_5 -> OK
> > 2015-11-04 09:06:56 scdaemon[29294] DBG: chan_5 <- SERIALNO openpgp
> > 2015-11-04 09:06:56 scdaemon[29294] DBG: enter: apdu_open_reader:
> > portstr=(null)
> > 2015-11-04 09:06:56 scdaemon[29294] pcsc_list_readers failed: unknown
> PC/SC
> > error code (0x8010002e)
> > 2015-11-04 09:06:56 scdaemon[29294] DBG: leave: apdu_open_reader =>
> slot=-1
> > [pc/sc]
> > 2015-11-04 09:06:56 scdaemon[29294] DBG: chan_5 -> ERR 100663404 Card
> error
> > <SCD>
> > 2015-11-04 09:06:56 scdaemon[29294] DBG: chan_5 <- RESTART
> > 2015-11-04 09:06:56 scdaemon[29294] DBG: chan_5 -> OK
>
> Thanks.  It is expected result (given the condition there's no libccid).
> --
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20151105/be33e9ee/attachment-0001.html>

From wk at gnupg.org  Thu Nov  5 10:30:50 2015
From: wk at gnupg.org (Werner Koch)
Date: Thu, 05 Nov 2015 10:30:50 +0100
Subject: Smartcard Hotplug?
In-Reply-To: <1446631527.14879.1.camel@fsij.org> (NIIBE Yutaka's message of
 "Wed, 04 Nov 2015 19:05:27 +0900")
References: <CABygG_B+wfmbDUTDNcdu8oXHS+-FTgKyTH5qcOpArAC-+-hZjw@mail.gmail.com>
 <5639470B.4070509@fsij.org>
 <CABygG_Cq=hbZxWnA0+=ZP2FLmWHf743-Cs23WpG+nAoYat5FTQ@mail.gmail.com>
 <563955FA.1040103@fsij.org>
 <CABygG_DBrXhtfjMQJZCBcBn3jxJ-+1RzfWQDE9K7RBGsF+DK2g@mail.gmail.com>
 <1446620125.4747.1.camel@fsij.org>
 <CABygG_C7OADqGYbvc=nx3FCH_pKpRVMbV-9bm-KKM=NhjA32+A@mail.gmail.com>
 <1446631527.14879.1.camel@fsij.org>
Message-ID: <874mh0u71x.fsf@vigenere.g10code.de>

On Wed,  4 Nov 2015 11:05, gniibe at fsij.org said:

> With this option, scdaemon always use PC/SC service and I believe that
> it will improve the situation of yours.

Do you think it would be useful to add a line to --card-status
describing the used driver and reader?


Shalom-Salam,

   Werner

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



From gniibe at fsij.org  Thu Nov  5 12:39:27 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 05 Nov 2015 20:39:27 +0900
Subject: Smartcard Hotplug?
In-Reply-To: <874mh0u71x.fsf@vigenere.g10code.de>
References: <CABygG_B+wfmbDUTDNcdu8oXHS+-FTgKyTH5qcOpArAC-+-hZjw@mail.gmail.com>
 <5639470B.4070509@fsij.org>
 <CABygG_Cq=hbZxWnA0+=ZP2FLmWHf743-Cs23WpG+nAoYat5FTQ@mail.gmail.com>
 <563955FA.1040103@fsij.org>
 <CABygG_DBrXhtfjMQJZCBcBn3jxJ-+1RzfWQDE9K7RBGsF+DK2g@mail.gmail.com>
 <1446620125.4747.1.camel@fsij.org>
 <CABygG_C7OADqGYbvc=nx3FCH_pKpRVMbV-9bm-KKM=NhjA32+A@mail.gmail.com>
 <1446631527.14879.1.camel@fsij.org> <874mh0u71x.fsf@vigenere.g10code.de>
Message-ID: <1446723567.1834.2.camel@fsij.org>

On 2015-11-05 at 10:30 +0100, Werner Koch wrote:
> Do you think it would be useful to add a line to --card-status
> describing the used driver and reader?

Yes, that's good idea.??I'll implement, perhaps in next week.
-- 


From patrick at enigmail.net  Sun Nov  8 20:04:32 2015
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Sun, 8 Nov 2015 20:04:32 +0100
Subject: Exporting secret keys with gpg 2.1
Message-ID: <563F9CC0.20603@enigmail.net>

If you export secret keys with
gpg2 --batch --no-tty --status-fd 2 --export-secret-keys ...

then pinentry will ask for each and every key to export. That's OK,
however, gpg does not report to the status-fd if the passphrase was OK
or not. In other words, it's not possible for tools to know if a key was
really exported or not, unless you want to parse the packets in the
resulting file.

Would it be possible to add something like:
[GNUPG:] SECRET_KEY_EXPORTED KEYID
[GNUPG:] EXPORT_SECRET_KEY_FAILED KEYID

Thanks,
Patrick


From gniibe at fsij.org  Mon Nov  9 08:24:34 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Mon, 09 Nov 2015 16:24:34 +0900
Subject: Smartcard Hotplug?
In-Reply-To: <1446723567.1834.2.camel@fsij.org>
References: <CABygG_B+wfmbDUTDNcdu8oXHS+-FTgKyTH5qcOpArAC-+-hZjw@mail.gmail.com>
 <5639470B.4070509@fsij.org>
 <CABygG_Cq=hbZxWnA0+=ZP2FLmWHf743-Cs23WpG+nAoYat5FTQ@mail.gmail.com>
 <563955FA.1040103@fsij.org>
 <CABygG_DBrXhtfjMQJZCBcBn3jxJ-+1RzfWQDE9K7RBGsF+DK2g@mail.gmail.com>
 <1446620125.4747.1.camel@fsij.org>
 <CABygG_C7OADqGYbvc=nx3FCH_pKpRVMbV-9bm-KKM=NhjA32+A@mail.gmail.com>
 <1446631527.14879.1.camel@fsij.org> <874mh0u71x.fsf@vigenere.g10code.de>
 <1446723567.1834.2.camel@fsij.org>
Message-ID: <56404A32.90200@fsij.org>

On 11/05/2015 08:39 PM, NIIBE Yutaka wrote:
> On 2015-11-05 at 10:30 +0100, Werner Koch wrote:
>> Do you think it would be useful to add a line to --card-status
>> describing the used driver and reader?
> 
> Yes, that's good idea.  I'll implement, perhaps in next week.
> 

Done in the bce0e3f71df0709a7d323a688ddf2690c1727a6c.  Built, tested
(both for internal CCID and PC/SC), and pushed.
-- 


From ueno at gnu.org  Tue Nov 10 02:34:23 2015
From: ueno at gnu.org (Daiki Ueno)
Date: Tue, 10 Nov 2015 10:34:23 +0900
Subject: [PATCH] dirmngr: Fix t-http compile error
In-Reply-To: <87si4qtqez.fsf-ueno@gnu.org> (Daiki Ueno's message of "Sun, 1
 Nov 2015 11:04:43 +0900")
References: <87si4qtqez.fsf-ueno@gnu.org>
Message-ID: <m37flqbpsw.fsf-ueno@gnu.org>

Daiki Ueno <ueno at gnu.org> writes:

> * dirmngr/Makefile.am (t_http_CFLAGS): Add LIBASSUAN_CFLAGS.

I should have explain a bit more in detail (I thought it is obvious
enough for the developers to replicate the error).

The current git master doesn't compile on systems where assuan.h is not
installed in the standard include directory.  For example, Fedora
installs it in /usr/include/libassuan2:

  gcc -DHAVE_CONFIG_H -I. -I..  -I../common -DLOCALEDIR=\"/usr/local/share/locale\" -DGNUPG_BINDIR="\"/usr/local/bin\"" -DGNUPG_LIBEXECDIR="\"/usr/local/libexec\"" -DGNUPG_LIBDIR="\"/usr/local/lib/gnupg\"" -DGNUPG_DATADIR="\"/usr/local/share/gnupg\"" -DGNUPG_SYSCONFDIR="\"/usr/local/etc/gnupg\"" -DGNUPG_LOCALSTATEDIR="\"/usr/local/var\""        -DWITHOUT_NPTH=1 -g -O2 -O3 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wformat -Wno-format-y2k -Wformat-security -W -Wno-sign-compare -Wno-missing-field-initializers -Wdeclaration-after-statement -Wno-pointer-sign -Wpointer-arith -MT t_ldap_parse_uri-http.o -MD -MP -MF .deps/t_ldap_parse_uri-http.Tpo -c -o t_ldap_parse_uri-http.o `test -f 'http.c' || echo './'`http.c
  http.c:97:56: fatal error: assuan.h: No such file or directory
  compilation terminated.

I am attaching a slightly modified patch, since I noticed that it is
also the case for t-ldap-parse-uri.

Werner Koch <wk at gnupg.org> writes:

> On Sun,  1 Nov 2015 03:35, ueno at gnu.org said:
>
>> To reduce build time, defer compilation of test programs to the "make
>> check" phase.
>
> I don think this is useful:
>
> "make check" is only rarely run in contrast to "make".  Thus always
> building the test programs helps finding build problems early.

About the development policy, I defer to you, of course.  However, such
build problems could also be observed by building the main programs (the
"dirmngr" executable in this case)?  I was actually not interested in
compiling the dirmngr test programs and rather wanted to skip them.

Regards,
-- 
Daiki Ueno
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-dirmngr-Fix-http.c-compilation-for-tests.patch
Type: text/x-patch
Size: 1701 bytes
Desc: not available
URL: </pipermail/attachments/20151110/55aaf2af/attachment.bin>

From Gatis.Paeglis at theqtcompany.com  Tue Nov 10 20:27:24 2015
From: Gatis.Paeglis at theqtcompany.com (Paeglis Gatis)
Date: Tue, 10 Nov 2015 19:27:24 +0000
Subject: Change prefix in gpgconf
In-Reply-To: <HE1PR02MB0668B62965CD42AFCC7C81B08D140@HE1PR02MB0668.eurprd02.prod.outlook.com>
References: <HE1PR02MB0668B62965CD42AFCC7C81B08D140@HE1PR02MB0668.eurprd02.prod.outlook.com>
Message-ID: <HE1PR02MB0668D917AFF43432D4AF84E68D140@HE1PR02MB0668.eurprd02.prod.outlook.com>



Hello,


After looking at the code it seems like there is no way to change paths in gpgconf after it has been build. Is this correct?

I was wondering would patch that adds envvar for adding a custom prefix in gpgconf would be accepted in gnupg project?


Ref:


https://bugzilla.yoctoproject.org/show_bug.cgi?id=8672


Gatis Paeglis.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20151110/6581208c/attachment.html>

From gniibe at fsij.org  Wed Nov 11 04:11:10 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 11 Nov 2015 12:11:10 +0900
Subject: keyring search regression in master
Message-ID: <5642B1CE.7020103@fsij.org>

Hello,

I found a problem in master.  2.1.9 works fine.

To reproduce:

# Setup
$ mkdir /tmp/gpghome; chmod og-rwx /tmp/gpghome
$ echo "default-key 00B45EBD4CA7BABE" >/tmp/gpghome/gpg.conf

# Get the public key
$ gpg --homedir=/tmp/gpghome --keyserver pool.sks-keyservers.net --recv-key 00b45ebd4ca7babe

# List with LONG-ID doesn't work
$ gpg2 --homedir=/tmp/gpghome --list-key 79A79093084239CF
gpg: error reading key: No public key

# ... while list with SHORT-ID works
$ gpg2 --homedir=/tmp/gpghome --list-key 084239CF
pub   rsa2048/4CA7BABE 2010-10-15
uid         [ unknown] NIIBE Yutaka <gniibe at fsij.org>
uid         [ unknown] NIIBE Yutaka <gniibe at debian.org>
sub   secp256k1/975B9053 2014-01-16
sub   rsa2048/084239CF 2010-10-15
sub   rsa2048/5BB065DC 2010-10-22

-- 


From gniibe at fsij.org  Wed Nov 11 07:57:28 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 11 Nov 2015 15:57:28 +0900
Subject: keyring search regression in master
In-Reply-To: <5642B1CE.7020103@fsij.org>
References: <5642B1CE.7020103@fsij.org>
Message-ID: <1447225048.10452.1.camel@fsij.org>

On 2015-11-11 at 12:11 +0900, NIIBE Yutaka wrote:
> # List with LONG-ID doesn't work
> $ gpg2 --homedir=/tmp/gpghome --list-key 79A79093084239CF
> gpg: error reading key: No public key

I think I located the problem, but I don't know how to fix.

It was introduced by the function check_user_ids.??It searches once,
and then, in the line 2198, it searches again.??Here, packets up to
the next PKT_PUBLIC_KEY will be skipped and subkeys are not registered
to the hash table.??Next time keyring_search will be called, the call
to lookup_offset_hash_table will fail (as the subkey is not
registered) and returns -1.

I think that this bug should be fixed before the release of 2.1.10.

I tried the following patch and it works well again, but this is
not the proper fix.

============================
diff --git a/g10/keyring.c b/g10/keyring.c
index 81d2174..6756320 100644
--- a/g10/keyring.c
+++ b/g10/keyring.c
@@ -1056,7 +1056,7 @@ keyring_search (KEYRING_HANDLE hd,
KEYDB_SEARCH_DESC *desc,
???????????pk_no = uid_no = 0;
???????????initial_skip = 0;
?????????}
-??????if (initial_skip)
+??????if (0 && initial_skip)
?????????{
???????????free_packet (&pkt);
???????????continue;
============================
-- 


From wk at gnupg.org  Wed Nov 11 08:41:00 2015
From: wk at gnupg.org (Werner Koch)
Date: Wed, 11 Nov 2015 08:41:00 +0100
Subject: keyring search regression in master
In-Reply-To: <1447225048.10452.1.camel@fsij.org> (NIIBE Yutaka's message of
 "Wed, 11 Nov 2015 15:57:28 +0900")
References: <5642B1CE.7020103@fsij.org> <1447225048.10452.1.camel@fsij.org>
Message-ID: <87r3jxouer.fsf@vigenere.g10code.de>

On Wed, 11 Nov 2015 07:57, gniibe at fsij.org said:

> It was introduced by the function check_user_ids.??It searches once,
> and then, in the line 2198, it searches again.??Here, packets up to
> the next PKT_PUBLIC_KEY will be skipped and subkeys are not registered
> to the hash table.??Next time keyring_search will be called, the call
> to lookup_offset_hash_table will fail (as the subkey is not
> registered) and returns -1.

Thanks for the analysis.  Actually I was bugged by the problem myself
and resorted to revert commit e8c53fc for my own use.

See  https://bugs.gnupg.org/gnupg/issue1128

> I think that this bug should be fixed before the release of 2.1.10.

I won't be able to do the monthly release this week anyway.  Thus there
is time left to sort this out (Neal is on vacation, though)


Shalom-Salam,

   Werner

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



From wk at gnupg.org  Wed Nov 11 08:45:25 2015
From: wk at gnupg.org (Werner Koch)
Date: Wed, 11 Nov 2015 08:45:25 +0100
Subject: Change prefix in gpgconf
In-Reply-To: <HE1PR02MB0668D917AFF43432D4AF84E68D140@HE1PR02MB0668.eurprd02.prod.outlook.com>
 (Paeglis Gatis's message of "Tue, 10 Nov 2015 19:27:24 +0000")
References: <HE1PR02MB0668B62965CD42AFCC7C81B08D140@HE1PR02MB0668.eurprd02.prod.outlook.com>
 <HE1PR02MB0668D917AFF43432D4AF84E68D140@HE1PR02MB0668.eurprd02.prod.outlook.com>
Message-ID: <87mvulou7e.fsf@vigenere.g10code.de>

On Tue, 10 Nov 2015 20:27, Gatis.Paeglis at theqtcompany.com said:

> After looking at the code it seems like there is no way to change paths in gpgconf after it has been build. Is this correct?

Right, it is a common Unix thing to hardwire certain locations so to
glue things together.  There should never be a need for a user to weak
this after installation.  Use appropriate configure and make options
instead.

Why do you want this?


Salam-Shalom,

   Werner

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



From bernhard at intevation.de  Wed Nov 11 11:02:23 2015
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 11 Nov 2015 11:02:23 +0100
Subject: web: gnupg roadmap slightly outdated
Message-ID: <201511111102.28584.bernhard@intevation.de>

Hi, 
it take some work to keep a roadmap updated, 
but if we have one, it should be kept current.

https://gnupg.org/roadmap.html#gnupg  
needs at least some work
   """The next GnuPG modern release will be 2.1.3 and is planned for mid to 
end of March."""

This is linked from http://wiki.gnupg.org/Tasks where I saw it.
Obviously the next release will be 2.1.10 or something else,
in some development contexts I am using links to tracker issues
to keep the effort low. However with the raising number of people
working on GnuPG (and Gpg4win) we probably need some more effort
into keeping the overview. :)

Gpg4win uses the wiki and we try to write the roadmap and the release
from the user point of view (not from the technical tasks).
https://wiki.gnupg.org/Gpg4win/Roadmap

Bernhard

-- 
www.intevation.de/~bernhard (CEO)    www.fsfe.org (Founding GA Member)
Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998
Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20151111/17b24d1d/attachment.sig>

From bernhard at intevation.de  Wed Nov 11 11:17:34 2015
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 11 Nov 2015 11:17:34 +0100
Subject: poldi in Debian and its homepage
Message-ID: <201511111117.39555.bernhard@intevation.de>

Dear Niibe-San,

just saw that https://sources.debian.net/src/poldi/0.4.1-3/debian/control/
still has Homepage: 
  http://www.g10code.com/p-poldi.html
which does not exist currently. 
It also seems like there is a critcial defect in the Debian packaging
related to the texinfo manual, should be easy to fix.
Thanks for contributing to Debian GNU/L. :)

http://wiki.gnupg.org/Tasks has an entry for Poldi.
Overall it seems to be a good idea to have some official 
information about Poldi more readily available. Right now
it seems hidden a bit in the doc dir of the git repo.

Best,
Bernhard

-- 
www.intevation.de/~bernhard (CEO)    www.fsfe.org (Founding GA Member)
Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998
Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20151111/aa234e83/attachment.sig>

From neal at walfield.org  Wed Nov 11 11:22:22 2015
From: neal at walfield.org (Neal H. Walfield)
Date: Wed, 11 Nov 2015 11:22:22 +0100
Subject: keyring search regression in master
In-Reply-To: <1447225048.10452.1.camel@fsij.org>
References: <5642B1CE.7020103@fsij.org>
	<1447225048.10452.1.camel@fsij.org>
Message-ID: <87ziykrg2p.wl-neal@walfield.org>

At Wed, 11 Nov 2015 15:57:28 +0900,
NIIBE Yutaka wrote:
> On 2015-11-11 at 12:11 +0900, NIIBE Yutaka wrote:
> > # List with LONG-ID doesn't work
> > $ gpg2 --homedir=/tmp/gpghome --list-key 79A79093084239CF
> > gpg: error reading key: No public key
> 
> I think I located the problem, but I don't know how to fix.
> 
> It was introduced by the function check_user_ids.??It searches once,
> and then, in the line 2198, it searches again.

FWIW, this is not a bug.  The second search (which is just a
continuation of the previous search) makes sure that the search
returns a single result, i.e., that the key specification is not
ambiguous relative to the DB's contents.

> ??Here, packets up to
> the next PKT_PUBLIC_KEY will be skipped and subkeys are not registered
> to the hash table.??Next time keyring_search will be called, the call
> to lookup_offset_hash_table will fail (as the subkey is not
> registered) and returns -1.

It sounds like the bug is in the keyring code and this patch simply
uncovered it.  (I did a quick test and I don't think the problem
occurs when using a keybox.)


Thanks,

:) Neal


From neal at walfield.org  Wed Nov 11 11:23:33 2015
From: neal at walfield.org (Neal H. Walfield)
Date: Wed, 11 Nov 2015 11:23:33 +0100
Subject: keyring search regression in master
In-Reply-To: <87r3jxouer.fsf@vigenere.g10code.de>
References: <5642B1CE.7020103@fsij.org> <1447225048.10452.1.camel@fsij.org>
 <87r3jxouer.fsf@vigenere.g10code.de>
Message-ID: <87y4e4rg0q.wl-neal@walfield.org>

Hi Werner,

At Wed, 11 Nov 2015 08:41:00 +0100,
Werner Koch wrote:
> On Wed, 11 Nov 2015 07:57, gniibe at fsij.org said:
> 
> > It was introduced by the function check_user_ids.??It searches once,
> > and then, in the line 2198, it searches again.??Here, packets up to
> > the next PKT_PUBLIC_KEY will be skipped and subkeys are not registered
> > to the hash table.??Next time keyring_search will be called, the call
> > to lookup_offset_hash_table will fail (as the subkey is not
> > registered) and returns -1.
> 
> Thanks for the analysis.  Actually I was bugged by the problem myself
> and resorted to revert commit e8c53fc for my own use.
>
> See  https://bugs.gnupg.org/gnupg/issue1128

Could you describe the failure scenario?

Thanks,

:) Neal


From bernhard at intevation.de  Wed Nov 11 11:48:31 2015
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 11 Nov 2015 11:48:31 +0100
Subject: contract "gpg4all" details in wiki
In-Reply-To: <201510120912.47383.bernhard@intevation.de>
References: <201504171106.56223.bernhard@intevation.de>
 <201510120912.47383.bernhard@intevation.de>
Message-ID: <201511111148.36162.bernhard@intevation.de>

On Monday 12 October 2015 at 09:12:40, Bernhard Reiter wrote:
> A large part of this contract is about researching how things could be
> done, especially for the web browser, android and about how to strengthen
> the security of the existing implementation.
> In the other parts it is planned to do some general maintance of Kleopatra
> and Gpg4win in addition to the integration of GnuPG 2.1 (modern).
> We are also optimistic to come up
> with a working prototype about how PGP/MIME can be implemented in GpgOL.
>
> We aim to add details about planning and progress to the wiki.gnupg.org.

http://wiki.gnupg.org/gpg4all
now has a list of workpackages, timeline and team info.

Best,
Bernhard

-- 
www.intevation.de/~bernhard (CEO)    www.fsfe.org (Founding GA Member)
Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998
Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20151111/94a7964a/attachment.sig>

From wk at gnupg.org  Wed Nov 11 13:01:02 2015
From: wk at gnupg.org (Werner Koch)
Date: Wed, 11 Nov 2015 13:01:02 +0100
Subject: keyring search regression in master
In-Reply-To: <87ziykrg2p.wl-neal@walfield.org> (Neal H. Walfield's message of
 "Wed, 11 Nov 2015 11:22:22 +0100")
References: <5642B1CE.7020103@fsij.org> <1447225048.10452.1.camel@fsij.org>
 <87ziykrg2p.wl-neal@walfield.org>
Message-ID: <87d1vgpwxt.fsf@vigenere.g10code.de>

On Wed, 11 Nov 2015 11:22, neal at walfield.org said:

> It sounds like the bug is in the keyring code and this patch simply
> uncovered it.  (I did a quick test and I don't think the problem
> occurs when using a keybox.)

Nope.  I am not able to use gpg anymore and I am using a keybox.


Salam-Shalom,

   Werner

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



From wk at gnupg.org  Wed Nov 11 13:03:33 2015
From: wk at gnupg.org (Werner Koch)
Date: Wed, 11 Nov 2015 13:03:33 +0100
Subject: web: gnupg roadmap slightly outdated
In-Reply-To: <201511111102.28584.bernhard@intevation.de> (Bernhard Reiter's
 message of "Wed, 11 Nov 2015 11:02:23 +0100")
References: <201511111102.28584.bernhard@intevation.de>
Message-ID: <878u64pwtm.fsf@vigenere.g10code.de>

On Wed, 11 Nov 2015 11:02, bernhard at intevation.de said:
> it take some work to keep a roadmap updated, 
> but if we have one, it should be kept current.

  This page has information on what we plan to do and what new
  features will go into which version.  This is _not_ a list of
  guaranteed milestones or with fixed release dates.  This page should
  better be viewed as a scratchpad with notes of GnuPG developers.
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Actually I don't consider it very useful right now.


Shalom-Salam,

   Werner

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



From Gatis.Paeglis at theqtcompany.com  Wed Nov 11 13:38:00 2015
From: Gatis.Paeglis at theqtcompany.com (Paeglis Gatis)
Date: Wed, 11 Nov 2015 12:38:00 +0000
Subject: Change prefix in gpgconf
In-Reply-To: <87mvulou7e.fsf@vigenere.g10code.de>
References: <HE1PR02MB0668B62965CD42AFCC7C81B08D140@HE1PR02MB0668.eurprd02.prod.outlook.com>
 <HE1PR02MB0668D917AFF43432D4AF84E68D140@HE1PR02MB0668.eurprd02.prod.outlook.com>,
 <87mvulou7e.fsf@vigenere.g10code.de>
Message-ID: <HE1PR02MB0668D9984C17784CCC63CE008D130@HE1PR02MB0668.eurprd02.prod.outlook.com>

> There should never be a need for a user to weak this after installation. 

There is a need for tweaking a prefix quite frequently, especially in cross compilation environments. I don't know the details on how this works in yocto,
but the general idea is that you export new environment that defines a new root for a sysroot, for example:

export SDKTARGETSYSROOT=/home/gp/iMX6-eLinux/toolchain/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/
where cortexa9hf-vfp-neon-poky-linux-gnueabi has the standard paths, like /usr/ /bin/.

It should be possible to install the generated toolchain in any path, or even several paths at the same time. And later all operations (looking for include headers, linking libraries)
happen in the SDKTARGETSYSROOT.

Does this clarify why gpgconf is inflexible for this use case?

________________________________________
From: Werner Koch <wk at gnupg.org>
Sent: Wednesday, November 11, 2015 8:45 AM
To: Paeglis Gatis
Cc: gnupg-devel at gnupg.org
Subject: Re: Change prefix in gpgconf

On Tue, 10 Nov 2015 20:27, Gatis.Paeglis at theqtcompany.com said:

> After looking at the code it seems like there is no way to change paths in gpgconf after it has been build. Is this correct?

Right, it is a common Unix thing to hardwire certain locations so to
glue things together.  There should never be a need for a user to weak
this after installation.  Use appropriate configure and make options
instead.

Why do you want this?


Salam-Shalom,

   Werner

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



From bernhard at intevation.de  Wed Nov 11 14:00:22 2015
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 11 Nov 2015 14:00:22 +0100
Subject: web: gnupg roadmap slightly outdated
In-Reply-To: <878u64pwtm.fsf@vigenere.g10code.de>
References: <201511111102.28584.bernhard@intevation.de>
 <878u64pwtm.fsf@vigenere.g10code.de>
Message-ID: <201511111400.27908.bernhard@intevation.de>

On Wednesday 11 November 2015 at 13:03:33, Werner Koch wrote:
> On Wed, 11 Nov 2015 11:02, bernhard at intevation.de said:
> > it take some work to keep a roadmap updated,
> > but if we have one, it should be kept current.
>
> ? This page has information on what we plan to do and what new
> ? features will go into which version. ?This is _not_ a list of
> ? guaranteed milestones or with fixed release dates. ?This page should
> ? better be viewed as a scratchpad with notes of GnuPG developers.
> ? ? ? ? ? ? ? ? ? ? ? ? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Actually I don't consider it very useful right now.

Then take https://gnupg.org/roadmap.html#gnupg down (aka "scratch it" :) )
or move it to the wiki.

-- 
www.intevation.de/~bernhard (CEO)    www.fsfe.org (Founding GA Member)
Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998
Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20151111/cccf1629/attachment.sig>

From wk at gnupg.org  Wed Nov 11 14:37:11 2015
From: wk at gnupg.org (Werner Koch)
Date: Wed, 11 Nov 2015 14:37:11 +0100
Subject: Change prefix in gpgconf
In-Reply-To: <HE1PR02MB0668D9984C17784CCC63CE008D130@HE1PR02MB0668.eurprd02.prod.outlook.com>
 (Paeglis Gatis's message of "Wed, 11 Nov 2015 12:38:00 +0000")
References: <HE1PR02MB0668B62965CD42AFCC7C81B08D140@HE1PR02MB0668.eurprd02.prod.outlook.com>
 <HE1PR02MB0668D917AFF43432D4AF84E68D140@HE1PR02MB0668.eurprd02.prod.outlook.com>
 <87mvulou7e.fsf@vigenere.g10code.de>
 <HE1PR02MB0668D9984C17784CCC63CE008D130@HE1PR02MB0668.eurprd02.prod.outlook.com>
Message-ID: <87si4codx4.fsf@vigenere.g10code.de>

On Wed, 11 Nov 2015 13:38, Gatis.Paeglis at theqtcompany.com said:

> Does this clarify why gpgconf is inflexible for this use case?

No.

For ages we use DESTDIR to do this:

  ./configure --prefix=/ROOTDIR
  make
  make install DESTDIR=/foo/bar/PLATFORMROOT/ROOTDIR

See the Automake manual or the GNU coding standards for more details.


Salam-Shalom,

   Werner

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



From Gatis.Paeglis at theqtcompany.com  Wed Nov 11 14:56:18 2015
From: Gatis.Paeglis at theqtcompany.com (Paeglis Gatis)
Date: Wed, 11 Nov 2015 13:56:18 +0000
Subject: Change prefix in gpgconf
In-Reply-To: <87si4codx4.fsf@vigenere.g10code.de>
References: <HE1PR02MB0668B62965CD42AFCC7C81B08D140@HE1PR02MB0668.eurprd02.prod.outlook.com>
 <HE1PR02MB0668D917AFF43432D4AF84E68D140@HE1PR02MB0668.eurprd02.prod.outlook.com>
 <87mvulou7e.fsf@vigenere.g10code.de>
 <HE1PR02MB0668D9984C17784CCC63CE008D130@HE1PR02MB0668.eurprd02.prod.outlook.com>,
 <87si4codx4.fsf@vigenere.g10code.de>
Message-ID: <HE1PR02MB066870EDB44FFB60A3F0F0AC8D130@HE1PR02MB0668.eurprd02.prod.outlook.com>

I know about the --prefix from GNU std.
The problem here is that gpgconf can not be reallocated.

Anyways, I will do a quick fix for myself. I will paste my solution in https://bugzilla.yoctoproject.org/show_bug.cgi?id=8672 in case somebody
experiences the same issues. 

________________________________________
From: Werner Koch <wk at gnupg.org>
Sent: Wednesday, November 11, 2015 2:37 PM
To: Paeglis Gatis
Cc: gnupg-devel at gnupg.org
Subject: Re: Change prefix in gpgconf

On Wed, 11 Nov 2015 13:38, Gatis.Paeglis at theqtcompany.com said:

> Does this clarify why gpgconf is inflexible for this use case?

No.

For ages we use DESTDIR to do this:

  ./configure --prefix=/ROOTDIR
  make
  make install DESTDIR=/foo/bar/PLATFORMROOT/ROOTDIR

See the Automake manual or the GNU coding standards for more details.


Salam-Shalom,

   Werner

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



From wk at gnupg.org  Wed Nov 11 17:27:09 2015
From: wk at gnupg.org (Werner Koch)
Date: Wed, 11 Nov 2015 17:27:09 +0100
Subject: Change prefix in gpgconf
In-Reply-To: <HE1PR02MB066870EDB44FFB60A3F0F0AC8D130@HE1PR02MB0668.eurprd02.prod.outlook.com>
 (Paeglis Gatis's message of "Wed, 11 Nov 2015 13:56:18 +0000")
References: <HE1PR02MB0668B62965CD42AFCC7C81B08D140@HE1PR02MB0668.eurprd02.prod.outlook.com>
 <HE1PR02MB0668D917AFF43432D4AF84E68D140@HE1PR02MB0668.eurprd02.prod.outlook.com>
 <87mvulou7e.fsf@vigenere.g10code.de>
 <HE1PR02MB0668D9984C17784CCC63CE008D130@HE1PR02MB0668.eurprd02.prod.outlook.com>
 <87si4codx4.fsf@vigenere.g10code.de>
 <HE1PR02MB066870EDB44FFB60A3F0F0AC8D130@HE1PR02MB0668.eurprd02.prod.outlook.com>
Message-ID: <87h9kso61u.fsf@vigenere.g10code.de>

On Wed, 11 Nov 2015 14:56, Gatis.Paeglis at theqtcompany.com said:
> I know about the --prefix from GNU std.
> The problem here is that gpgconf can not be reallocated.

I doubt that.  Let's see:

  $ /home/wk/s/gnupg/configure \
        --sysconfdir=/etc --enable-maintainer-mode --disable-ntbtls \
        --enable-g13 --prefix=/home/wk/fooroot

  $ make

  $ tools/gpgconf
  gpg:GPG for OpenPGP:/home/wk/fooroot/bin/gpg2
  gpg-agent:GPG Agent:/home/wk/fooroot/bin/gpg-agent
[...]

  $ tools/gpgconf --list-dirs
  sysconfdir:/etc/gnupg
  bindir:/home/wk/fooroot/bin
  libexecdir:/home/wk/fooroot/libexec
  libdir:/home/wk/fooroot/lib/gnupg
[...]  


Thus gpg knows very well where to find its comrades.  (The --sysconfdir
option is just a standard one of mine, you would not use it.)  I have
not installed the software but using DESTDIR does not rebuild the
binaries.

The code to retrieve for example the bin dir is in common/homedir.c and
pretty simple for Unix:

  const char *
  gnupg_bindir (void)
  {
  [...]
  #else /*!HAVE_W32_SYSTEM*/
    return GNUPG_BINDIR;
  #endif /*!HAVE_W32_SYSTEM*/
  }

and GNUPG_BINDIR is set directly from the configure options.  Via
$(bindir) and the @bindir@ AC_SUBST.

  

Salam-Shalom,

   Werner


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



From neal at walfield.org  Wed Nov 11 17:42:58 2015
From: neal at walfield.org (Neal H. Walfield)
Date: Wed, 11 Nov 2015 17:42:58 +0100
Subject: keyring search regression in master
In-Reply-To: <87d1vgpwxt.fsf@vigenere.g10code.de>
References: <5642B1CE.7020103@fsij.org> <1447225048.10452.1.camel@fsij.org>
 <87ziykrg2p.wl-neal@walfield.org>
 <87d1vgpwxt.fsf@vigenere.g10code.de>
Message-ID: <87wptoqygd.wl-neal@walfield.org>

At Wed, 11 Nov 2015 13:01:02 +0100,
Werner Koch wrote:
> 
> On Wed, 11 Nov 2015 11:22, neal at walfield.org said:
> 
> > It sounds like the bug is in the keyring code and this patch simply
> > uncovered it.  (I did a quick test and I don't think the problem
> > occurs when using a keybox.)
> 
> Nope.  I am not able to use gpg anymore and I am using a keybox.

Your bug report gets an F :-).  Can you please provide some more
details.  I'm using a keybox and I can't reproduce your problem.

:) Neal


From Gatis.Paeglis at theqtcompany.com  Wed Nov 11 17:49:16 2015
From: Gatis.Paeglis at theqtcompany.com (Paeglis Gatis)
Date: Wed, 11 Nov 2015 16:49:16 +0000
Subject: Change prefix in gpgconf
In-Reply-To: <87h9kso61u.fsf@vigenere.g10code.de>
References: <HE1PR02MB0668B62965CD42AFCC7C81B08D140@HE1PR02MB0668.eurprd02.prod.outlook.com>
 <HE1PR02MB0668D917AFF43432D4AF84E68D140@HE1PR02MB0668.eurprd02.prod.outlook.com>
 <87mvulou7e.fsf@vigenere.g10code.de>
 <HE1PR02MB0668D9984C17784CCC63CE008D130@HE1PR02MB0668.eurprd02.prod.outlook.com>
 <87si4codx4.fsf@vigenere.g10code.de>
 <HE1PR02MB066870EDB44FFB60A3F0F0AC8D130@HE1PR02MB0668.eurprd02.prod.outlook.com>,
 <87h9kso61u.fsf@vigenere.g10code.de>
Message-ID: <HE1PR02MB06686F6F85E9D7050F104EF08D130@HE1PR02MB0668.eurprd02.prod.outlook.com>

I know all that. I will try to explain with another example:

1) Company A builds a toolchain with some custom tools and provides this toolchain for installation. The same toolchain contains gpgconf with some hardcoded path (provided with the --prefix
    when building the toolchain).

2) Each user can install this toolchain in any path they want. 

If the hardcoded location was /opt/toolchain

But user installs in

/home/username/board-x/toolchain  <----- gpgconf won't be able to find binaries.

Does this clarify the problem? 

________________________________________
From: Werner Koch <wk at gnupg.org>
Sent: Wednesday, November 11, 2015 5:27 PM
To: Paeglis Gatis
Cc: gnupg-devel at gnupg.org
Subject: Re: Change prefix in gpgconf

On Wed, 11 Nov 2015 14:56, Gatis.Paeglis at theqtcompany.com said:
> I know about the --prefix from GNU std.
> The problem here is that gpgconf can not be reallocated.

I doubt that.  Let's see:

  $ /home/wk/s/gnupg/configure \
        --sysconfdir=/etc --enable-maintainer-mode --disable-ntbtls \
        --enable-g13 --prefix=/home/wk/fooroot

  $ make

  $ tools/gpgconf
  gpg:GPG for OpenPGP:/home/wk/fooroot/bin/gpg2
  gpg-agent:GPG Agent:/home/wk/fooroot/bin/gpg-agent
[...]

  $ tools/gpgconf --list-dirs
  sysconfdir:/etc/gnupg
  bindir:/home/wk/fooroot/bin
  libexecdir:/home/wk/fooroot/libexec
  libdir:/home/wk/fooroot/lib/gnupg
[...]


Thus gpg knows very well where to find its comrades.  (The --sysconfdir
option is just a standard one of mine, you would not use it.)  I have
not installed the software but using DESTDIR does not rebuild the
binaries.

The code to retrieve for example the bin dir is in common/homedir.c and
pretty simple for Unix:

  const char *
  gnupg_bindir (void)
  {
  [...]
  #else /*!HAVE_W32_SYSTEM*/
    return GNUPG_BINDIR;
  #endif /*!HAVE_W32_SYSTEM*/
  }

and GNUPG_BINDIR is set directly from the configure options.  Via
$(bindir) and the @bindir@ AC_SUBST.



Salam-Shalom,

   Werner


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



From neal at walfield.org  Wed Nov 11 18:34:00 2015
From: neal at walfield.org (Neal H. Walfield)
Date: Wed, 11 Nov 2015 18:34:00 +0100
Subject: keyring search regression in master
In-Reply-To: <87ziykrg2p.wl-neal@walfield.org>
References: <5642B1CE.7020103@fsij.org> <1447225048.10452.1.camel@fsij.org>
 <87ziykrg2p.wl-neal@walfield.org>
Message-ID: <87vb98qw3b.wl-neal@walfield.org>

At Wed, 11 Nov 2015 11:22:22 +0100,
Neal H. Walfield wrote:
> 
> At Wed, 11 Nov 2015 15:57:28 +0900,
> NIIBE Yutaka wrote:
> > On 2015-11-11 at 12:11 +0900, NIIBE Yutaka wrote:
> > > # List with LONG-ID doesn't work
> > > $ gpg2 --homedir=/tmp/gpghome --list-key 79A79093084239CF
> > > gpg: error reading key: No public key
> > 
> > I think I located the problem, but I don't know how to fix.
> > 
> > It was introduced by the function check_user_ids.??It searches once,
> > and then, in the line 2198, it searches again.
> 
> FWIW, this is not a bug.  The second search (which is just a
> continuation of the previous search) makes sure that the search
> returns a single result, i.e., that the key specification is not
> ambiguous relative to the DB's contents.
> 
> > ??Here, packets up to
> > the next PKT_PUBLIC_KEY will be skipped and subkeys are not registered
> > to the hash table.??Next time keyring_search will be called, the call
> > to lookup_offset_hash_table will fail (as the subkey is not
> > registered) and returns -1.
> 
> It sounds like the bug is in the keyring code and this patch simply
> uncovered it.  (I did a quick test and I don't think the problem
> occurs when using a keybox.)

The problem is straightforward to understand, I think.

When we look for a key on the keyring, we iterate over each of the
keyblocks starting with the keyblock following the last result.  For
each keyblock, we iterate over the public key and any subkeys.  As we
iterate over each key, we first insert it into the cache and then
check if the key matches.  If so, we are done.

In pseudo code:

  for (i = last_result + 1; i < num_records; i ++)
    keyblock = get_keyblock (i)
    for (j = 1; j < len(keyblock); j ++)
      key = keyblock[j]
      update_cache (key)
      if (compare (key, search_terms))
        return ok
  cache_filled = true
  return ENOFOUND

When we look for the next match, we start with the following keyblock.
The result is that any subkeys following the key that matched are not
added to the cache (in other words, when a keyblock matches, the inner
loop did not necessarily complete and the subsequent search doesn't
resume it).

7546e81 includes a straightforward fix: only indicate the cache as
complete if we started the scan from the beginning of the keyring and
really didn't find anything.


Thanks for the helpful bug report!  make check still works and your
example works for me as well.

Thanks!

:) Neal


From ijackson at chiark.greenend.org.uk  Wed Nov 11 21:32:39 2015
From: ijackson at chiark.greenend.org.uk (Ian Jackson)
Date: Wed, 11 Nov 2015 20:32:39 +0000
Subject: adns and TOR
In-Reply-To: <8737wcnv77.fsf@vigenere.g10code.de>
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>
Message-ID: <22083.42471.21873.170334@chiark.greenend.org.uk>

Werner Koch writes ("Re: adns and TOR"):
> 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.

Regards,
Ian.


From gniibe at fsij.org  Thu Nov 12 03:57:37 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 12 Nov 2015 11:57:37 +0900
Subject: keyring search regression in master
In-Reply-To: <87vb98qw3b.wl-neal@walfield.org>
References: <5642B1CE.7020103@fsij.org>	<1447225048.10452.1.camel@fsij.org>	<87ziykrg2p.wl-neal@walfield.org>
 <87vb98qw3b.wl-neal@walfield.org>
Message-ID: <56440021.40604@fsij.org>

On 11/12/2015 02:34 AM, Neal H. Walfield wrote:
> 7546e81 includes a straightforward fix: only indicate the cache as
> complete if we started the scan from the beginning of the keyring and
> really didn't find anything.

It works fine, and I can decrypt encrypted messages again (for the
machine where my key is actually in pubring.gpg).

Thank you.
-- 


From wk at gnupg.org  Thu Nov 12 08:54:07 2015
From: wk at gnupg.org (Werner Koch)
Date: Thu, 12 Nov 2015 08:54:07 +0100
Subject: keyring search regression in master
In-Reply-To: <87wptoqygd.wl-neal@walfield.org> (Neal H. Walfield's message of
 "Wed, 11 Nov 2015 17:42:58 +0100")
References: <5642B1CE.7020103@fsij.org> <1447225048.10452.1.camel@fsij.org>
 <87ziykrg2p.wl-neal@walfield.org> <87d1vgpwxt.fsf@vigenere.g10code.de>
 <87wptoqygd.wl-neal@walfield.org>
Message-ID: <87si4bmz4w.fsf@vigenere.g10code.de>

On Wed, 11 Nov 2015 17:42, neal at walfield.org said:

> Your bug report gets an F :-).  Can you please provide some more
> details.  I'm using a keybox and I can't reproduce your problem.

Well, something like this is run when I do a commit or stash:

  $ ../g10/gpg2 -vsbau 0xE3FDFF218E45B72B </etc/motd >/dev/null
  [...]
  gpg: Error: the key specification '0xE3FDFF218E45B72B' is ambiguous.
  gpg: (check argument of option '--local-user')
  gpg: error reading key block for '0xE3FDFF218E45B72B': Unknown system error.
  gpg: Error: the key specification '1E42B367' is ambiguous.
  gpg: (check argument of option '--encrypt-to')
  gpg: error reading key block for '1E42B367': Unknown system error.
  gpg: Warning: value '1E42B367' for --default-key should be a long keyid or a fingerprint.
  gpg: Error: the key specification '1E42B367' is ambiguous.
  gpg: (check argument of option '--default-key')
  gpg: error reading key block for '1E42B367': Unknown system error.
  gpg: writing to stdout
  gpg: EDDSA/SHA256 signature from: "E3FDFF218E45B72B Werner Koch (wheatstone commit signing)"
  wk at wheatstone:~/b/gnupg/tmp$ echo $?
  2

Note that I have only specified a short key id because this is pretty
common and gpg prints only a warning.  Okay.

The real problem is that there are several error messages - one is
sufficient to let gpg exit with a failure and git won't continue.  There
are 2 different kinds of errors:

  gpg: Error: the key specification '0xE3FDFF218E45B72B' is ambiguous.

This is the keyid I specified on the command line.  Let's check it:

  $ ../g10/gpg2 -k 0xE3FDFF218E45B72B
  [...]
  gpg: Error: the key specification '1E42B367' is ambiguous.
  gpg: (check argument of option '--encrypt-to')
  gpg: error reading key block for '1E42B367': Unknown system error.
  gpg: Warning: value '1E42B367' for --default-key should be a long keyid or a fingerprint.
  gpg: Error: the key specification '1E42B367' is ambiguous.
  gpg: (check argument of option '--default-key')
  gpg: error reading key block for '1E42B367': Unknown system error.
  gpg: please do a --check-trustdb
  pub   ed25519/E3FDFF218E45B72B 2015-02-18 [expires: 2025-02-15]
  uid                 [ultimate] Werner Koch (wheatstone commit signing)
  
(and -k shows the same result).
What is the ambiguity here?

The other two error messages are identical one for --encrypt-to and one
for --default-key:

  gpg: Error: the key specification '1E42B367' is ambiguous.

Let's check it:

  $ ../g10/gpg2 -k 1E42B367
  [...]
  gpg: Error: the key specification '1E42B367' is ambiguous.
  gpg: (check argument of option '--encrypt-to')
  gpg: error reading key block for '1E42B367': Unknown system error.
  gpg: Warning: value '1E42B367' for --default-key should be a long keyid or a fingerprint.
  gpg: Error: the key specification '1E42B367' is ambiguous.
  gpg: (check argument of option '--default-key')
  gpg: error reading key block for '1E42B367': Unknown system error.
  gpg: please do a --check-trustdb
  pub   dsa2048/F2AD85AC1E42B367 2007-12-31 [expires: 2018-12-31]
  uid                 [ unknown] Werner Koch <wk at gnupg.org>
  uid                 [ unknown] Werner Koch <wk at g10code.com>
  uid                 [ unknown] Werner Koch <werner at eifzilla.de>
  sub   dsa1024/4F0540D577F95F95 2011-11-02
  sub   rsa2048/1E0FE11D664D7444 2014-01-02 [expires: 2016-12-31]

Also not ambiguous.


Shalom-Salam,

   Werner

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



From bernhard at intevation.de  Thu Nov 12 09:31:25 2015
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 12 Nov 2015 09:31:25 +0100
Subject: [Gpg4win-users-de] contract "gpg4all" details in wiki
In-Reply-To: <201511111148.36162.bernhard@intevation.de>
References: <201504171106.56223.bernhard@intevation.de>
 <201510120912.47383.bernhard@intevation.de>
 <201511111148.36162.bernhard@intevation.de>
Message-ID: <201511120931.30340.bernhard@intevation.de>

On Wednesday 11 November 2015 at 11:48:31, Bernhard Reiter wrote:
> On Monday 12 October 2015 at 09:12:40, Bernhard Reiter wrote:
> > A large part of this contract is about researching how things could be
> > done, especially for the web browser, android and about how to strengthen
> > the security of the existing implementation.
> > In the other parts it is planned to do some general maintance of
> > Kleopatra and Gpg4win in addition to the integration of GnuPG 2.1
> > (modern). We are also optimistic to come up
> > with a working prototype about how PGP/MIME can be implemented in GpgOL.
> >
> > We aim to add details about planning and progress to the wiki.gnupg.org.

http://wiki.gnupg.org/Gpg4all2015

> now has a list of workpackages, timeline and team info.


-- 
www.intevation.de/~bernhard (CEO)    www.fsfe.org (Founding GA Member)
Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998
Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20151112/16571fd5/attachment.sig>

From wk at gnupg.org  Thu Nov 12 17:11:53 2015
From: wk at gnupg.org (Werner Koch)
Date: Thu, 12 Nov 2015 17:11:53 +0100
Subject: Exporting secret keys with gpg 2.1
In-Reply-To: <563F9CC0.20603@enigmail.net> (Patrick Brunschwig's message of
 "Sun, 8 Nov 2015 20:04:32 +0100")
References: <563F9CC0.20603@enigmail.net>
Message-ID: <878u63mc3a.fsf@vigenere.g10code.de>

On Sun,  8 Nov 2015 20:04, patrick at enigmail.net said:

> or not. In other words, it's not possible for tools to know if a key was
> really exported or not, unless you want to parse the packets in the

Right, there is no --status-fd output at all.  I have justed pushed two
changes:

  EXPORTED  <fingerprint>
    The key with <fingerprint> has been exported.  The fingerprint is
    the fingerprint of the primary key even if the primary key has
    been replaced by a stub key during secret key export.

  EXPORT_RES <args>

    Final statistics on export process (this is one long line). The
    args are a list of unsigned numbers separated by white space:

    - <count>
    - <secret_count>
    - <exported>

I don't think that it makes sense to distinguish between secret and
public for "EXPORTED".  You always know what you requested.

> Would it be possible to add something like:
> [GNUPG:] SECRET_KEY_EXPORTED KEYID
> [GNUPG:] EXPORT_SECRET_KEY_FAILED KEYID

The gpg-agent is a different component and it can't be clear to gpg
whether this failed due to a wrong passphrase, missing smartcard, or
whatever.  Thus I do not think that a failed secret key export is a good
idea.

If you want to export just one secret key you can simply watch out for
the corresponding "EXPORTED" line.


Shalom-Salam,

   Werner

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



From patrick at enigmail.net  Thu Nov 12 17:51:22 2015
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Thu, 12 Nov 2015 17:51:22 +0100
Subject: Exporting secret keys with gpg 2.1
In-Reply-To: <878u63mc3a.fsf@vigenere.g10code.de>
References: <563F9CC0.20603@enigmail.net> <878u63mc3a.fsf@vigenere.g10code.de>
Message-ID: <5644C38A.9020000@enigmail.net>

On 12.11.15 17:11, Werner Koch wrote:
> On Sun,  8 Nov 2015 20:04, patrick at enigmail.net said:
> 
>> or not. In other words, it's not possible for tools to know if a key was
>> really exported or not, unless you want to parse the packets in the
> 
> Right, there is no --status-fd output at all.  I have justed pushed two
> changes:
> 
>   EXPORTED  <fingerprint>
>     The key with <fingerprint> has been exported.  The fingerprint is
>     the fingerprint of the primary key even if the primary key has
>     been replaced by a stub key during secret key export.
> 
>   EXPORT_RES <args>
> 
>     Final statistics on export process (this is one long line). The
>     args are a list of unsigned numbers separated by white space:
> 
>     - <count>
>     - <secret_count>
>     - <exported>
> 
> I don't think that it makes sense to distinguish between secret and
> public for "EXPORTED".  You always know what you requested.
> 
>> Would it be possible to add something like:
>> [GNUPG:] SECRET_KEY_EXPORTED KEYID
>> [GNUPG:] EXPORT_SECRET_KEY_FAILED KEYID
> 
> The gpg-agent is a different component and it can't be clear to gpg
> whether this failed due to a wrong passphrase, missing smartcard, or
> whatever.  Thus I do not think that a failed secret key export is a good
> idea.
> 
> If you want to export just one secret key you can simply watch out for
> the corresponding "EXPORTED" line.

Great, thanks!

-Patrick



From gniibe at fsij.org  Fri Nov 13 05:47:33 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Fri, 13 Nov 2015 13:47:33 +0900
Subject: keyring search regression in master
In-Reply-To: <87si4bmz4w.fsf@vigenere.g10code.de>
References: <5642B1CE.7020103@fsij.org>
 <1447225048.10452.1.camel@fsij.org>	<87ziykrg2p.wl-neal@walfield.org>
 <87d1vgpwxt.fsf@vigenere.g10code.de>	<87wptoqygd.wl-neal@walfield.org>
 <87si4bmz4w.fsf@vigenere.g10code.de>
Message-ID: <56456B65.3020307@fsij.org>

On 11/12/2015 04:54 PM, Werner Koch wrote:
> The real problem is that there are several error messages - one is
> sufficient to let gpg exit with a failure and git won't continue.  There
> are 2 different kinds of errors:
> 
>   gpg: Error: the key specification '0xE3FDFF218E45B72B' is ambiguous.
> 
> This is the keyid I specified on the command line.  Let's check it:
> 
>   $ ../g10/gpg2 -k 0xE3FDFF218E45B72B
>   [...]
>   gpg: Error: the key specification '1E42B367' is ambiguous.
>   gpg: (check argument of option '--encrypt-to')
>   gpg: error reading key block for '1E42B367': Unknown system error.
>   gpg: Warning: value '1E42B367' for --default-key should be a long keyid or a fingerprint.
>   gpg: Error: the key specification '1E42B367' is ambiguous.
>   gpg: (check argument of option '--default-key')
>   gpg: error reading key block for '1E42B367': Unknown system error.
>   gpg: please do a --check-trustdb
>   pub   ed25519/E3FDFF218E45B72B 2015-02-18 [expires: 2025-02-15]
>   uid                 [ultimate] Werner Koch (wheatstone commit signing)
>   
> (and -k shows the same result).
> What is the ambiguity here?
> 
> The other two error messages are identical one for --encrypt-to and one
> for --default-key:
> 
>   gpg: Error: the key specification '1E42B367' is ambiguous.
> 
> Let's check it:
> 
>   $ ../g10/gpg2 -k 1E42B367
>   [...]
>   gpg: Error: the key specification '1E42B367' is ambiguous.
>   gpg: (check argument of option '--encrypt-to')
>   gpg: error reading key block for '1E42B367': Unknown system error.
>   gpg: Warning: value '1E42B367' for --default-key should be a long keyid or a fingerprint.
>   gpg: Error: the key specification '1E42B367' is ambiguous.
>   gpg: (check argument of option '--default-key')
>   gpg: error reading key block for '1E42B367': Unknown system error.
>   gpg: please do a --check-trustdb
>   pub   dsa2048/F2AD85AC1E42B367 2007-12-31 [expires: 2018-12-31]
>   uid                 [ unknown] Werner Koch <wk at gnupg.org>
>   uid                 [ unknown] Werner Koch <wk at g10code.com>
>   uid                 [ unknown] Werner Koch <werner at eifzilla.de>
>   sub   dsa1024/4F0540D577F95F95 2011-11-02
>   sub   rsa2048/1E0FE11D664D7444 2014-01-02 [expires: 2016-12-31]
> 
> Also not ambiguous.

It is not reproducible here.  Reading the code, I can't find error
return path from keybox_search (if we assume the condition keybox data
is correct).

Any case, I think that the following would make sense; it should only
proceed on the success of keydb_search.  When it's other than success,
it's not ambiguous.

diff --git a/g10/gpg.c b/g10/gpg.c
index 36e6542..46a7fb9 100644
--- a/g10/gpg.c
+++ b/g10/gpg.c
@@ -2196,8 +2196,7 @@ check_user_ids (strlist_t *sp,

       /* Continue the search.  */
       err = keydb_search (hd, &desc, 1, NULL);
-      if (! (gpg_err_code (err) == GPG_ERR_NOT_FOUND
-             || gpg_err_code (err) == GPG_ERR_EOF))
+      if (! err)
         {
           char fingerprint_bin2[MAX_FINGERPRINT_LEN];
           size_t fingerprint_bin2_len = sizeof (fingerprint_bin2);
-- 


From wk at gnupg.org  Fri Nov 13 09:54:11 2015
From: wk at gnupg.org (Werner Koch)
Date: Fri, 13 Nov 2015 09:54:11 +0100
Subject: keyring search regression in master
In-Reply-To: <56456B65.3020307@fsij.org> (NIIBE Yutaka's message of "Fri, 13
 Nov 2015 13:47:33 +0900")
References: <5642B1CE.7020103@fsij.org> <1447225048.10452.1.camel@fsij.org>
 <87ziykrg2p.wl-neal@walfield.org> <87d1vgpwxt.fsf@vigenere.g10code.de>
 <87wptoqygd.wl-neal@walfield.org> <87si4bmz4w.fsf@vigenere.g10code.de>
 <56456B65.3020307@fsij.org>
Message-ID: <87pozel1os.fsf@vigenere.g10code.de>

On Fri, 13 Nov 2015 05:47, gniibe at fsij.org said:

> It is not reproducible here.  Reading the code, I can't find error
> return path from keybox_search (if we assume the condition keybox data

Sorry. I just checked and I was in error that I used a keybox:

  $ kbxutil .gnupg/pubring.kbx | head | grep 'Flags:.*openpgp'

shows that pubring.kbx is not used for OpenPGP.

Anyway, the problem still exists with the keyring.  I checked the
keyring with gpg1 and it has only one copy of 1E42B367.

This is a blocker for 2.1.10 and given that this is a fix for a 6 year
old "wish" I consider to either revert the two commits, disable the
code, or leave it in master and not include it in 2.1.10.


Shalom-Salam,

   Werner

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



From Mento at gpgtools.org  Sat Nov 14 10:47:41 2015
From: Mento at gpgtools.org (Roman Zechmeister)
Date: Sat, 14 Nov 2015 10:47:41 +0100
Subject: Integrate pinentry-mac into pinentry
In-Reply-To: <87h9u9t6hd.fsf@vigenere.g10code.de>
References: <ADECD045-2809-4362-8D5A-43EBA9428C33@mykolab.com>
 <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com>
 <DD18C5EF-523B-4E99-9C84-55C2D8F862B8@gpgtools.org>
 <EB263EDB-EF9B-4702-98A7-212F0C1046EC@webkeks.org>
 <87sie3i7kb.fsf@vigenere.g10code.de>
 <AB173B31-D818-41A6-B7B7-5978C52211CE@webkeks.org>
 <873861d8eq.fsf@vigenere.g10code.de>
 <483FE4A0-C58E-44AB-AD78-EA5E1A80C8D1@gpgtools.org>
 <2786DC31-AEAC-4406-9143-94F32C74A644@webkeks.org>
 <EF669FD7-889C-49C4-AC86-728B6A94B94A@dressyvagabonds.com>
 <B8217C71-71D1-4134-AD58-A6B9E5FFEA08@webkeks.org>
 <A413BC4D-B3A3-4DF3-8134-80950BCAC798@gpgtools.org>
 <54E9F20F.9040506@enigmail.net> <87ioery4oe.fsf@vigenere.g10code.de>
 <54EDDBF9.3030108@guardianproject.info> <87bnkiuh37.fsf@vigenere.g10code.de>
 <C5DC1C67-2B50-4B96-A581-56DF85266D33@mento.at>
 <87h9u9t6hd.fsf@vigenere.g10code.de>
Message-ID: <09F12993-5464-4156-8C7D-0D40435A3935@gpgtools.org>

Now there is a fork of pinentry with a pinentry for Mac OS X on https://github.com/GPGTools/pinentry
It compiles without Xcode on OS X >= 10.7. There are no changes for older system.

Please have a look at the changes and tell me what do you think.
I would be happy to see it merged in upstream.


Regards, Mento

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

From guilhem at fripost.org  Sun Nov 15 19:52:44 2015
From: guilhem at fripost.org (Guilhem Moulin)
Date: Sun, 15 Nov 2015 19:52:44 +0100
Subject: Adding notations to subkey binding signatures to limit their scope
Message-ID: <20151115185244.GA31540@localhost.localdomain>

Hi there,

The OpenPGP standard (RFC 4880) allows the owner of the private part of
the primary key to add a notation on a subkey binding signature.  With
GnuPG this can be achieved upon subkey creation with the following
command:

    gpg --cert-notation my at notation=xxx --edit-key $KEYID addkey save

In theory, such subkeys with notations could be used by the owner to
limit their scope.  For instance, after an IRC discussion with dkg and a
private chat with Werner, the following use cases came to mind:

  - Two encryption subkeys, one stored on laptops and other devices for
    every day use, and another stored offline for extra secure
    communications.

  - Three signing subkeys, one stored on the development platform for
    signing Git commits, one for everyday use (eg used to sign emails),
    and the last one stored offline to sign packages and release
    tarballs.

In fact such isolation is already possible using multiple primary keys
instead of multiple subkeys.  However the master+subkey model has the
advantage of enabling subkey rotation, and avoids duplicating
trust-paths in the WoT.

Unfortunately these use cases can be hard to achieve without standard
notations.  However in the context of a keyring managed centrally by a
single entity, such as the Debian project, the standard can also be
managed by said entity.  For instance as a Debian maintainer, I would
create a signing subkey (dedicated to package signing) with the
Debian-specific notation and keep it securely.  Any uploaded package
signed with my other signing subkey (for everyday use hence easier to
compromise) would be automatically rejected.

In fact from a technical point of view, the only thing missing is an
option for gpg(1) and gpgv(1) to consider a data signature valid *only*
if the signing (sub)key had the specified notation.  For instance

    gpg --assert-notation my at notation=xxx --verify /path/to/data.sig /path/to/data

Of course, the feature might not be suitable for everyone, so for
backward compatibility, ideally gpg(1) and gpgv(1) should also have a
flag --assert-notation-fallback to also consider a data signature valid
if *none* of the signing (sub)key had the specified notation.

Or perhaps someone here would have a better suggestion to limit the
scope of subkeys?

Cheers,
-- 
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: </pipermail/attachments/20151115/1d5bd7a1/attachment.sig>

From neal at walfield.org  Mon Nov 16 10:37:42 2015
From: neal at walfield.org (Neal H. Walfield)
Date: Mon, 16 Nov 2015 10:37:42 +0100
Subject: keyring search regression in master
In-Reply-To: <56456B65.3020307@fsij.org>
References: <5642B1CE.7020103@fsij.org> <1447225048.10452.1.camel@fsij.org>
 <87ziykrg2p.wl-neal@walfield.org>
 <87d1vgpwxt.fsf@vigenere.g10code.de>
 <87wptoqygd.wl-neal@walfield.org>
 <87si4bmz4w.fsf@vigenere.g10code.de> <56456B65.3020307@fsij.org>
Message-ID: <87r3jqwahl.wl-neal@walfield.org>

At Fri, 13 Nov 2015 13:47:33 +0900,
NIIBE Yutaka wrote:
> Any case, I think that the following would make sense; it should only
> proceed on the success of keydb_search.  When it's other than success,
> it's not ambiguous.

You're right.  But, we also need to error out if the error is
something other than NOT_FOUND or EOF.  I've checked in something
to address both of these issues.

Thanks!

:) Neal


From neal at walfield.org  Mon Nov 16 11:00:07 2015
From: neal at walfield.org (Neal H. Walfield)
Date: Mon, 16 Nov 2015 11:00:07 +0100
Subject: Integrate pinentry-mac into pinentry
In-Reply-To: <09F12993-5464-4156-8C7D-0D40435A3935@gpgtools.org>
References: <ADECD045-2809-4362-8D5A-43EBA9428C33@mykolab.com>
 <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com>
 <DD18C5EF-523B-4E99-9C84-55C2D8F862B8@gpgtools.org>
 <EB263EDB-EF9B-4702-98A7-212F0C1046EC@webkeks.org>
 <87sie3i7kb.fsf@vigenere.g10code.de>
 <AB173B31-D818-41A6-B7B7-5978C52211CE@webkeks.org>
 <873861d8eq.fsf@vigenere.g10code.de>
 <483FE4A0-C58E-44AB-AD78-EA5E1A80C8D1@gpgtools.org>
 <2786DC31-AEAC-4406-9143-94F32C74A644@webkeks.org>
 <EF669FD7-889C-49C4-AC86-728B6A94B94A@dressyvagabonds.com>
 <B8217C71-71D1-4134-AD58-A6B9E5FFEA08@webkeks.org>
 <A413BC4D-B3A3-4DF3-8134-80950BCAC798@gpgtools.org>
 <54E9F20F.9040506@enigmail.net>
 <87ioery4oe.fsf@vigenere.g10code.de>
 <54EDDBF9.3030108@guardianproject.info>
 <87bnkiuh37.fsf@vigenere.g10code.de>
 <C5DC1C67-2B50-4B96-A581-56DF85266D33@mento.at>
 <87h9u9t6hd.fsf@vigenere.g10code.de>
 <09F12993-5464-4156-8C7D-0D40435A3935@gpgtools.org>
Message-ID: <87pozaw9g8.wl-neal@walfield.org>

Hi Roman,

At Sat, 14 Nov 2015 10:47:41 +0100,
Roman Zechmeister wrote:
> Now there is a fork of pinentry with a pinentry for Mac OS X on https://github.com/GPGTools/pinentry
> It compiles without Xcode on OS X >= 10.7. There are no changes for older system.
> 
> Please have a look at the changes and tell me what do you think.
> I would be happy to see it merged in upstream.

Thanks for contributing this.  I pulled your changes and they build on
GNU/Linux so there is no obvious regression :-).

Werner: do you want to pull this into our tree?  The main problem that
I see is that none of us (= g10 people) have access to a Mac machine
to test this.

Assuming Werner agrees, there are a couple of technical things that
you need to take care of before we can merge this.  First, please
don't use merge commits.  Rebase your changes on top of the current
head.  Also, please collapse your bug fixes into the appropriate
commits.  Finally, please be a bit more careful with your change log
entries.

Thanks!

:) Neal


From neal at walfield.org  Mon Nov 16 12:54:46 2015
From: neal at walfield.org (Neal H. Walfield)
Date: Mon, 16 Nov 2015 12:54:46 +0100
Subject: Integrate pinentry-mac into pinentry
In-Reply-To: <87pozaw9g8.wl-neal@walfield.org>
References: <ADECD045-2809-4362-8D5A-43EBA9428C33@mykolab.com>
 <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com>
 <DD18C5EF-523B-4E99-9C84-55C2D8F862B8@gpgtools.org>
 <EB263EDB-EF9B-4702-98A7-212F0C1046EC@webkeks.org>
 <87sie3i7kb.fsf@vigenere.g10code.de>
 <AB173B31-D818-41A6-B7B7-5978C52211CE@webkeks.org>
 <873861d8eq.fsf@vigenere.g10code.de>
 <483FE4A0-C58E-44AB-AD78-EA5E1A80C8D1@gpgtools.org>
 <2786DC31-AEAC-4406-9143-94F32C74A644@webkeks.org>
 <EF669FD7-889C-49C4-AC86-728B6A94B94A@dressyvagabonds.com>
 <B8217C71-71D1-4134-AD58-A6B9E5FFEA08@webkeks.org>
 <A413BC4D-B3A3-4DF3-8134-80950BCAC798@gpgtools.org>
 <54E9F20F.9040506@enigmail.net>
 <87ioery4oe.fsf@vigenere.g10code.de>
 <54EDDBF9.3030108@guardianproject.info>
 <87bnkiuh37.fsf@vigenere.g10code.de>
 <C5DC1C67-2B50-4B96-A581-56DF85266D33@mento.at>
 <87h9u9t6hd.fsf@vigenere.g10code.de>
 <09F12993-5464-4156-8C7D-0D40435A3935@gpgtools.org>
 <87pozaw9g8.wl-neal@walfield.org>
Message-ID: <87mvuew455.wl-neal@walfield.org>

At Mon, 16 Nov 2015 11:00:07 +0100,
Neal H. Walfield wrote:
> At Sat, 14 Nov 2015 10:47:41 +0100,
> Roman Zechmeister wrote:
> Thanks for contributing this.  I pulled your changes and they build on
> GNU/Linux so there is no obvious regression :-).
> 
> Werner: do you want to pull this into our tree?  The main problem that
> I see is that none of us (= g10 people) have access to a Mac machine
> to test this.

I spoke with Werner about this offline and we agreed that it would be
good if the code for the MaxOS X pinentry was integrated into our
repo.  But since we don't have access to Mac, we need you to commit to
testing and maintaining it.  Let me know if this is acceptable.

Thanks!

:) Neal


From dashamitabh1 at yahoo.co.in  Tue Nov 17 01:37:14 2015
From: dashamitabh1 at yahoo.co.in (amit das)
Date: Tue, 17 Nov 2015 00:37:14 +0000 (UTC)
Subject: Question about sliding window implementation in gnupg1.4.19
References: <1119769257.4730848.1447720634205.JavaMail.yahoo.ref@mail.yahoo.com>
Message-ID: <1119769257.4730848.1447720634205.JavaMail.yahoo@mail.yahoo.com>


Hi,?I am trying to study the implementation of the sliding window algorithm. Please let me know if a sliding window method has been implemented in gnupg1.4.19 mpi-pow.c for RSA and El Gamal Modular Exponentiation. Please point me to the relevant line number.?Thanks & Regards,Amitabh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20151117/7e9312af/attachment-0001.html>

From oleg at gurevich.de  Wed Nov 18 19:02:28 2015
From: oleg at gurevich.de (Oleg Gurevich)
Date: Wed, 18 Nov 2015 19:02:28 +0100
Subject: On Scute v1.4.0  support key length up to 4096, proceed s-expressions
 on common way
Message-ID: <564CBD34.1030608@gurevich.de>


Hello,

would you please take a look on following patch.

This way supports key sizes up to 4096 bit.
And, as Werner wrote, proceeds s-expressions on common way.

It would be greate to hear your opinion about it.



mit freundlichen Gr??en/ ? ?????????/ best regards

Oleg Gurevich

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



diff --git a/src/agent.c b/src/agent.c
index 9265ca2..39d554b 100644
--- a/src/agent.c
+++ b/src/agent.c
@@ -954,8 +954,8 @@ scute_agent_check_status (void)
 }

 ^L
-/* Enough space to hold a 2048 bit RSA signature in an S-expression.  */
-#define MAX_SIGNATURE_LEN 350
+/* Enough space to hold a 4096 bit RSA signature in an S-expression.  */
+#define MAX_SIGNATURE_LEN 640

 struct signature
 {
@@ -981,13 +981,27 @@ pksign_cb (void *opaque, const void *buffer,
size_t length)
 }


-#define SIG_PREFIX   "(7:sig-val(3:rsa(1:s128:"
-#define SIG_PREFIX_2 "(7:sig-val(3:rsa(1:s256:"
-#define SIG_PREFIX_LEN (sizeof (SIG_PREFIX) - 1)
+#define SIG_PREFIX_1024   "(7:sig-val(3:rsa(1:s128:"
+#define SIG_PREFIX_2048   "(7:sig-val(3:rsa(1:s256:"
+#define SIG_PREFIX_3076   "(7:sig-val(3:rsa(1:s384:"
+#define SIG_PREFIX_4096   "(7:sig-val(3:rsa(1:s512:"
+
 #define SIG_POSTFIX ")))"
 #define SIG_POSTFIX_LEN (sizeof (SIG_POSTFIX) - 1)
-#define SIG_LEN 128
-#define SIG_LEN_2 256
+
+struct s_expression {
+    unsigned int sig_len;
+    char *prefix;
+    unsigned int prefix_len;
+
+} supported_expr[] = {
+  128, SIG_PREFIX_1024, sizeof (SIG_PREFIX_1024) - 1,
+  256, SIG_PREFIX_2048, sizeof (SIG_PREFIX_2048) - 1,
+  384, SIG_PREFIX_3076, sizeof (SIG_PREFIX_3076) - 1,
+  512, SIG_PREFIX_4096, sizeof (SIG_PREFIX_4096) - 1,
+};
+#define MAX_SIG_LEN 512
+#define MIN_SIG_LEN 128

 /* Call the agent to learn about a smartcard.  */
 gpg_error_t
@@ -996,7 +1010,7 @@ scute_agent_sign (char *grip, unsigned char *data,
int len,
 {
   char cmd[150];
   gpg_error_t err;
-#define MAX_DATA_LEN 36
+#define MAX_DATA_LEN 128
   unsigned char pretty_data[2 * MAX_DATA_LEN + 1];
   int i;
   struct signature sig;
@@ -1009,14 +1023,14 @@ scute_agent_sign (char *grip, unsigned char
*data, int len,
   if (sig_result == NULL)
     {
       /* FIXME:  We return the largest supported size - is that
correct?  */
-      *sig_len = SIG_LEN_2;
+      *sig_len = MAX_SIG_LEN;
       return 0;
     }

   if (len > MAX_DATA_LEN)
     return gpg_error (GPG_ERR_INV_ARG);

-  if (grip == NULL || sig_result == NULL || *sig_len < SIG_LEN)
+  if (grip == NULL || sig_result == NULL || *sig_len < MIN_SIG_LEN)
     return gpg_error (GPG_ERR_INV_ARG);

   snprintf (cmd, sizeof (cmd), "SIGKEY %s", grip);
@@ -1041,31 +1055,30 @@ scute_agent_sign (char *grip, unsigned char
*data, int len,
     return err;

   /* FIXME: we need a real parser to cope with all kind of
S-expressions.  */
-  if (sig.len == SIG_PREFIX_LEN + SIG_LEN_2 + SIG_POSTFIX_LEN)
-    {
-      if (memcmp (sig.data, SIG_PREFIX_2, SIG_PREFIX_LEN))
-        return gpg_error (GPG_ERR_BAD_SIGNATURE);
-      if (memcmp (sig.data + sig.len - SIG_POSTFIX_LEN,
-                  SIG_POSTFIX, SIG_POSTFIX_LEN))
-        return gpg_error (GPG_ERR_BAD_SIGNATURE);
-      memcpy (sig_result, sig.data + SIG_PREFIX_LEN, SIG_LEN_2);
-      *sig_len = SIG_LEN_2;
-    }
-  else
+  /* FIXME: better ? */
+  err = GPG_ERR_BAD_SIGNATURE;
+  for(i = 0; i < sizeof(supported_expr) / sizeof(struct s_expression); i++)
     {
-      if (sig.len != SIG_PREFIX_LEN + SIG_LEN + SIG_POSTFIX_LEN)
-        return gpg_error (GPG_ERR_BAD_SIGNATURE);
-      if (memcmp (sig.data, SIG_PREFIX, SIG_PREFIX_LEN))
-        return gpg_error (GPG_ERR_BAD_SIGNATURE);
-      if (memcmp (sig.data + sig.len - SIG_POSTFIX_LEN,
-                  SIG_POSTFIX, SIG_POSTFIX_LEN))
-        return gpg_error (GPG_ERR_BAD_SIGNATURE);
-      memcpy (sig_result, sig.data + SIG_PREFIX_LEN, SIG_LEN);
-      *sig_len = SIG_LEN;
+      if( sig.len == supported_expr[i].prefix_len +
supported_expr[i].sig_len + SIG_POSTFIX_LEN )
+        {
+          // check prefix matching
+          if (memcmp (sig.data, supported_expr[i].prefix,
supported_expr[i].prefix_len))
+            return gpg_error (GPG_ERR_BAD_SIGNATURE);
+          // check postfix matching
+          if(memcmp(sig.data + sig.len - SIG_POSTFIX_LEN, SIG_POSTFIX,
SIG_POSTFIX_LEN))
+            return gpg_error (GPG_ERR_BAD_SIGNATURE);
+          // copy sig into result
+          memcpy (sig_result, sig.data + supported_expr[i].prefix_len,
supported_expr[i].sig_len);
+          *sig_len = supported_expr[i].sig_len;
+          err = 0;
+          break;
+
+        }
     }
-
-
+  if(err)
+    return gpg_error (err);
   return 0;
+
 }

-------------- 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/20151118/a36ae198/attachment.sig>

From mike at flyn.org  Mon Nov 23 03:00:38 2015
From: mike at flyn.org (W. Michael Petullo)
Date: Sun, 22 Nov 2015 21:00:38 -0500
Subject: libgpg-error-1.20 on OpenWrt
Message-ID: <20151123020038.GA3471@imp.flyn.org>

I am the maintainer of the OpenWrt libgpg-error package. OpenWrt
is a Linux distribution that targets a number of router
platforms. libgpg-error-1.20 fails to cross compile for some of OpenWrt's
platforms, producing the following error:

./mkheader linux-gnu arm-openwrt-linux-gnu  ./gpg-error.h.in \
                   ../config.h 1.20 0x011400 >gpg-error.h
./gpg-error.h.in:402: error including `./syscfg/lock-obj-pub.linux-gnu.h': No such file or directory
Makefile:1299: recipe for target 'gpg-error.h' failed
make[6]: *** [gpg-error.h] Error 1
make[6]: Leaving directory '/home/mike/Source/openwrt/openwrt/build_dir/target-arm_arm1176jzf-s+vfp_musl-1.1.11_eabi/libgpg-error-1.20/src'

The compiler I am using to build OpenWrt says:

$ ./arm-openwrt-linux-muslgnueabi-gcc -dumpmachine
arm-openwrt-linux-muslgnueabi

Of course, I do not see this target triplet in
libgpg-error-1.20/src/syscfg/. Is there something that can be done to
support niche architectures, or am I doing something wrong?

-- 
Mike

:wq


From wk at gnupg.org  Mon Nov 23 10:54:08 2015
From: wk at gnupg.org (Werner Koch)
Date: Mon, 23 Nov 2015 10:54:08 +0100
Subject: libgpg-error-1.20 on OpenWrt
In-Reply-To: <20151123020038.GA3471@imp.flyn.org> (W. Michael Petullo's
 message of "Sun, 22 Nov 2015 21:00:38 -0500")
References: <20151123020038.GA3471@imp.flyn.org>
Message-ID: <87lh9p9h33.fsf@vigenere.g10code.de>

On Mon, 23 Nov 2015 03:00, mike at flyn.org said:

> arm-openwrt-linux-muslgnueabi
>
> Of course, I do not see this target triplet in
> libgpg-error-1.20/src/syscfg/. Is there something that can be done to
> support niche architectures, or am I doing something wrong?

Is that architecture identical to an already supported one?  Check the
src/syscfg directory of libgcrypt.  If it is identical to one of those
we can add it to the alias list in src/mkheader.c:canon_host_triplet .
Otherwise, please follow the instruction in the README file, section
Cross-Compiling


Shalom-Salam,

   Werner


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



From neal at walfield.org  Mon Nov 23 15:15:19 2015
From: neal at walfield.org (Neal H. Walfield)
Date: Mon, 23 Nov 2015 15:15:19 +0100
Subject: Proposal: New keydb format
In-Reply-To: <87r3k9789v.wl-neal@walfield.org>
References: <87a8r27xq9.wl-neal@walfield.org>
 <20151029142828.GA9973@localhost.localdomain>
 <87vb9n7t2f.wl-neal@walfield.org>
 <20151101184906.GA28098@localhost.localdomain>
 <87r3k9789v.wl-neal@walfield.org>
Message-ID: <87d1v0x0nc.wl-neal@walfield.org>

Hi Guilhem,

At Sun, 01 Nov 2015 21:51:40 +0100,
Neal H. Walfield wrote:
> At Sun, 1 Nov 2015 19:49:06 +0100,
> Guilhem Moulin wrote:
> > On Sat, 31 Oct 2015 at 01:58:00 +0100, Neal H. Walfield wrote:
> > > At Thu, 29 Oct 2015 15:28:28 +0100, Guilhem Moulin wrote:
> > >> Care to look into that?  I'd be happy to resume the benchmark later.
> > > 
> > > I spent a little bit of time on this this evening and found the bug.
> > > I think --with-colons --list-sigs should now work.
> > 
> > Thanks a lot!  Yes indeed it does, and for my use case the performance is just
> > amazing, especially with --list-sigs \o/  See the details below.
> > 
> > However note that in order to create a keyring in keydb format I had to
> > to apply to apply the following patch.  (But I guess the proper fix
> > would be to remove everything from and including the ?;? at the end of
> > each SQL statement.)
> 
> I applied a patch similar to this to master, but I forgot to apply it
> to the branch.  I'm sorry about that.

I rebased against master and fixed a few bugs including the large
memory use that you reported.  Please get the latest code from the
neal/kdb branch.

Thanks!

Neal


From guilhem at fripost.org  Mon Nov 23 20:55:36 2015
From: guilhem at fripost.org (Guilhem Moulin)
Date: Mon, 23 Nov 2015 20:55:36 +0100
Subject: Proposal: New keydb format
In-Reply-To: <87d1v0x0nc.wl-neal@walfield.org>
References: <87a8r27xq9.wl-neal@walfield.org>
 <20151029142828.GA9973@localhost.localdomain>
 <87vb9n7t2f.wl-neal@walfield.org>
 <20151101184906.GA28098@localhost.localdomain>
 <87r3k9789v.wl-neal@walfield.org> <87d1v0x0nc.wl-neal@walfield.org>
Message-ID: <20151123195536.GA17976@localhost.localdomain>

Hi Neal,

On Mon, 23 Nov 2015 at 15:15:19 +0100, Neal H. Walfield wrote:
> I rebased against master and fixed a few bugs including the large
> memory use that you reported.  Please get the latest code from the
> neal/kdb branch.

Awesome, thanks a lot for looking into this!  Yeah, the max res set is
kept small now.  I ran the whole benchmark from
<20151101184906.GA28098 at localhost.localdomain>, but only write down the
updates worth mentioning here

>> * Listing keys *
>>[?]
>>  ~$ time ./g10/gpg2 --homedir /run/shm/gnupg-kdb --list-keys >/dev/null
>>  0:00.73 (0.66 user, 0.07 sys)  108716k maxres
0:00.74 (0.68 user, 0.05 sys)  35192k maxres

>> * Listing sigs without nested lookups (--fast-list-mode) *
>>[?]
>>  ~$ time ./g10/gpg2 --homedir /run/shm/gnupg-kdb --fast-list-mode --list-sigs >/dev/null
>>  0:00.96 (0.88 user, 0.08 sys)  108692k maxres
0:00.97 (0.89 user, 0.07 sys)  35116k maxres

>> * Listing sigs with nested lookups *
>>[?]
>>  ~$ time ./g10/gpg2 --homedir /run/shm/gnupg-kdb --list-sigs >/dev/null
>>  0:05.93 (5.75 user, 0.18 sys)  107972k maxres
0:06.01 (5.84 user, 0.16 sys)  41888k maxres


So all in all, while the the running time is unchanged, the memory usage
is reduced by a factor of 2 or 3.  Sweet!

I've also benchmarked keyring merges (only new sigs) and key import.  No
bad surprise here either:

  $ time gpg --homedir /run/shm/gnupg-ring --import </tmp/key.gpg
  0:00.14 (0.12 user, 0.02 sys)  6784k maxres
  $ time gpg2 --homedir /run/shm/gnupg-kbx --import </tmp/key.gpg
  0:00.15 (0.09 user, 0.06 sys)  13420k maxres
  $ time ./g10/gpg2 --homedir /run/shm/gnupg-kdb --import </tmp/key.gpg
  0:00.07 (0.06 user, 0.00 sys)  10112k maxres

  $ time gpg --homedir /run/shm/gnupg-ring --import </tmp/newkey.asc
  0:00.19 (0.12 user, 0.07 sys)  3788k maxres
  $ time gpg2 --homedir /run/shm/gnupg-kbx --import </tmp/newkey.asc
  0:00.14 (0.03 user, 0.10 sys)  6516k maxres
  $ time ./g10/gpg2 --homedir /run/shm/gnupg-kdb --import </tmp/newkey.asc
  0:00.01 (0.00 user, 0.00 sys)  5240k maxres


There is however a typo which fails any attempt to delete a key.  The
patch is trivial:

-8<-------------------------------------------------------------------------->8-
diff --git a/g10/kdb.c b/g10/kdb.c
index da99573..b1c5544 100644
--- a/g10/kdb.c
+++ b/g10/kdb.c
@@ -909,8 +909,8 @@ kdb_delete (KDB_HANDLE hd)
 
   rc = sqlite3_exec_printf
     (hd->resource->db, NULL, NULL, &err,
-     "delete from keys where primary = %d;\n"
-     "delete from uids where primary = %d;\n"
+     "delete from keys where primary_key = %d;\n"
+     "delete from uids where primary_key = %d;\n"
      "delete from primaries where oid = %d;\n",
      hd->found.key, hd->found.key, hd->found.key);
   if (rc)
-8<-------------------------------------------------------------------------->8-

Cheers,
-- 
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: </pipermail/attachments/20151123/ab8a96eb/attachment.sig>

From neal at walfield.org  Mon Nov 23 21:26:06 2015
From: neal at walfield.org (Neal H. Walfield)
Date: Mon, 23 Nov 2015 21:26:06 +0100
Subject: Proposal: New keydb format
In-Reply-To: <20151123195536.GA17976@localhost.localdomain>
References: <87a8r27xq9.wl-neal@walfield.org>
 <20151029142828.GA9973@localhost.localdomain>
 <87vb9n7t2f.wl-neal@walfield.org>
 <20151101184906.GA28098@localhost.localdomain>
 <87r3k9789v.wl-neal@walfield.org> <87d1v0x0nc.wl-neal@walfield.org>
 <20151123195536.GA17976@localhost.localdomain>
Message-ID: <87bnakwjhd.wl-neal@walfield.org>

Hi Guilhem,

At Mon, 23 Nov 2015 20:55:36 +0100,
Guilhem Moulin wrote:
> On Mon, 23 Nov 2015 at 15:15:19 +0100, Neal H. Walfield wrote:
> > I rebased against master and fixed a few bugs including the large
> > memory use that you reported.  Please get the latest code from the
> > neal/kdb branch.
> 
> Awesome, thanks a lot for looking into this!

:)

> Yeah, the max res set is
> kept small now.  I ran the whole benchmark from
> <20151101184906.GA28098 at localhost.localdomain>, but only write down the
> updates worth mentioning here
> 
> >> * Listing keys *
> >>[?]
> >>  ~$ time ./g10/gpg2 --homedir /run/shm/gnupg-kdb --list-keys >/dev/null
> >>  0:00.73 (0.66 user, 0.07 sys)  108716k maxres
> 0:00.74 (0.68 user, 0.05 sys)  35192k maxres
> 
> >> * Listing sigs without nested lookups (--fast-list-mode) *
> >>[?]
> >>  ~$ time ./g10/gpg2 --homedir /run/shm/gnupg-kdb --fast-list-mode --list-sigs >/dev/null
> >>  0:00.96 (0.88 user, 0.08 sys)  108692k maxres
> 0:00.97 (0.89 user, 0.07 sys)  35116k maxres
> 
> >> * Listing sigs with nested lookups *
> >>[?]
> >>  ~$ time ./g10/gpg2 --homedir /run/shm/gnupg-kdb --list-sigs >/dev/null
> >>  0:05.93 (5.75 user, 0.18 sys)  107972k maxres
> 0:06.01 (5.84 user, 0.16 sys)  41888k maxres
> 
> 
> So all in all, while the the running time is unchanged, the memory usage
> is reduced by a factor of 2 or 3.  Sweet!

Thanks for rerunning these.  This is good news.  FWIW, the memory
usage is now O(1) instead of O(N).  And, if necessary, it sounds like
we could reduce the amount of read ahead cache to save even more space
(but I'm not sure this is necessary in practice).

> There is however a typo which fails any attempt to delete a key.  The
> patch is trivial:

Whoops!  Thanks, I'll fix this soon.

Are there are specific situations that the new format doesn't handle
well for you?

Thanks,

:) Neal


From guilhem at fripost.org  Mon Nov 23 21:40:32 2015
From: guilhem at fripost.org (Guilhem Moulin)
Date: Mon, 23 Nov 2015 21:40:32 +0100
Subject: Proposal: New keydb format
In-Reply-To: <87bnakwjhd.wl-neal@walfield.org>
References: <87a8r27xq9.wl-neal@walfield.org>
 <20151029142828.GA9973@localhost.localdomain>
 <87vb9n7t2f.wl-neal@walfield.org>
 <20151101184906.GA28098@localhost.localdomain>
 <87r3k9789v.wl-neal@walfield.org> <87d1v0x0nc.wl-neal@walfield.org>
 <20151123195536.GA17976@localhost.localdomain>
 <87bnakwjhd.wl-neal@walfield.org>
Message-ID: <20151123204032.GA6615@localhost.localdomain>

On Mon, 23 Nov 2015 at 21:26:06 +0100, Neal H. Walfield wrote:
> Are there are specific situations that the new format doesn't handle
> well for you?

Nope :-)  Of course I didn't measure every situation, but among the ones
I perform daily keydb's performance ranges between mind-blowing (for
--list-sigs) and acceptable (for --update-trustdb).

-- 
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: </pipermail/attachments/20151123/499e3540/attachment.sig>

From gniibe at fsij.org  Thu Nov 26 04:02:50 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 26 Nov 2015 12:02:50 +0900
Subject: Curve25519 with the prefix 0x40
Message-ID: <5656765A.7020800@fsij.org>

Hello,

I review our implementation of Curve25519 again, and I think that we
should add the prefix 0x40 so that it matches the practice of Ed25519.

While my patch for libgcrypt is on review, and here is the patch for
GnuPG.  Well, it seems that only change for scdaemon.


diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c
index 0fcfffe..ed1bce6 100644
--- a/scd/app-openpgp.c
+++ b/scd/app-openpgp.c
@@ -4114,7 +4114,8 @@ do_decipher (app_t app, const char *keyidstr,
   if (rc)
     return rc;

-  if (indatalen == 16 + 1 || indatalen == 32 + 1)
+  if (indatalen == 16 + 1 || indatalen == 32 + 1
+      && ((char *)indata)[0] == 0x02)
     /* PSO:DECIPHER with symmetric key.  */
     padind = -1;
   else if (app->app_local->keyattr[1].key_type == KEY_TYPE_RSA)
@@ -4172,6 +4173,16 @@ do_decipher (app_t app, const char *keyidstr,
     }
   else if (app->app_local->keyattr[1].key_type == KEY_TYPE_ECC)
     {
+      if (app->app_local->keyattr[1].ecc.flags
+          && (indatalen%2))
+        { /*
+           * Skip the prefix.  It may be 0x40 (in new format), or MPI
+           * head of 0x00 (in old format).
+           */
+          indata++;
+          indatalen--;
+        }
+
       fixuplen = 7;
       fixbuf = xtrymalloc (fixuplen + indatalen);
       if (!fixbuf)
@@ -4211,6 +4222,20 @@ do_decipher (app_t app, const char *keyidstr,
                          indata, indatalen, le_value, padind,
                          outdata, outdatalen);
   xfree (fixbuf);
+  if (app->app_local->keyattr[1].key_type == KEY_TYPE_ECC
+      && app->app_local->keyattr[1].ecc.flags)
+    { /* Add the prefix 0x40 */
+      fixbuf = xtrymalloc (*outdatalen + 1);
+      if (!fixbuf)
+        {
+          xfree (outdata);
+          return gpg_error_from_syserror ();
+        }
+      xfree (outdata);
+      outdata = fixbuf;
+      outdata[0] = 0x40;
+      *outdatalen = *outdatalen + 1;
+    }

   if (gpg_err_code (rc) == GPG_ERR_CARD /* actual SW is 0x640a */
       && app->app_local->manufacturer == 5
--


From Mento at gpgtools.org  Fri Nov 27 16:56:00 2015
From: Mento at gpgtools.org (Roman Zechmeister)
Date: Fri, 27 Nov 2015 16:56:00 +0100
Subject: Integrate pinentry-mac into pinentry
In-Reply-To: <87mvuew455.wl-neal@walfield.org>
References: <ADECD045-2809-4362-8D5A-43EBA9428C33@mykolab.com>
 <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com>
 <DD18C5EF-523B-4E99-9C84-55C2D8F862B8@gpgtools.org>
 <EB263EDB-EF9B-4702-98A7-212F0C1046EC@webkeks.org>
 <87sie3i7kb.fsf@vigenere.g10code.de>
 <AB173B31-D818-41A6-B7B7-5978C52211CE@webkeks.org>
 <873861d8eq.fsf@vigenere.g10code.de>
 <483FE4A0-C58E-44AB-AD78-EA5E1A80C8D1@gpgtools.org>
 <2786DC31-AEAC-4406-9143-94F32C74A644@webkeks.org>
 <EF669FD7-889C-49C4-AC86-728B6A94B94A@dressyvagabonds.com>
 <B8217C71-71D1-4134-AD58-A6B9E5FFEA08@webkeks.org>
 <A413BC4D-B3A3-4DF3-8134-80950BCAC798@gpgtools.org>
 <54E9F20F.9040506@enigmail.net> <87ioery4oe.fsf@vigenere.g10code.de>
 <54EDDBF9.3030108@guardianproject.info> <87bnkiuh37.fsf@vigenere.g10code.de>
 <C5DC1C67-2B50-4B96-A581-56DF85266D33@mento.at>
 <87h9u9t6hd.fsf@vigenere.g10code.de>
 <09F12993-5464-4156-8C7D-0D40435A3935@gpgtools.org>
 <87pozaw9g8.wl-neal@walfield.org> <87mvuew455.wl-neal@walfield.org>
Message-ID: <514E159D-C26D-47BF-AB2F-E36ACA75DBC1@gpgtools.org>

Hi Neal,

how would the whole process of maintaining look like?
Would we maintain our fork and you pull the changes?
I've found your rules for commit messages. What are your other rules (coding style, etc.)?
How should we handle the additional strings? Currently there are two simple strings files for englisch and german in the macosx subdir.


Regards, Mento


Am 16.11.2015 um 12:54 schrieb Neal H. Walfield <neal at walfield.org>:

> I spoke with Werner about this offline and we agreed that it would be
> good if the code for the MaxOS X pinentry was integrated into our
> repo.  But since we don't have access to Mac, we need you to commit to
> testing and maintaining it.  Let me know if this is acceptable.

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

From wk at gnupg.org  Fri Nov 27 18:49:37 2015
From: wk at gnupg.org (Werner Koch)
Date: Fri, 27 Nov 2015 18:49:37 +0100
Subject: Integrate pinentry-mac into pinentry
In-Reply-To: <514E159D-C26D-47BF-AB2F-E36ACA75DBC1@gpgtools.org> (Roman
 Zechmeister's message of "Fri, 27 Nov 2015 16:56:00 +0100")
References: <ADECD045-2809-4362-8D5A-43EBA9428C33@mykolab.com>
 <DD18C5EF-523B-4E99-9C84-55C2D8F862B8@gpgtools.org>
 <EB263EDB-EF9B-4702-98A7-212F0C1046EC@webkeks.org>
 <87sie3i7kb.fsf@vigenere.g10code.de>
 <AB173B31-D818-41A6-B7B7-5978C52211CE@webkeks.org>
 <873861d8eq.fsf@vigenere.g10code.de>
 <483FE4A0-C58E-44AB-AD78-EA5E1A80C8D1@gpgtools.org>
 <2786DC31-AEAC-4406-9143-94F32C74A644@webkeks.org>
 <EF669FD7-889C-49C4-AC86-728B6A94B94A@dressyvagabonds.com>
 <B8217C71-71D1-4134-AD58-A6B9E5FFEA08@webkeks.org>
 <A413BC4D-B3A3-4DF3-8134-80950BCAC798@gpgtools.org>
 <54E9F20F.9040506@enigmail.net> <87ioery4oe.fsf@vigenere.g10code.de>
 <54EDDBF9.3030108@guardianproject.info>
 <87bnkiuh37.fsf@vigenere.g10code.de>
 <C5DC1C67-2B50-4B96-A581-56DF85266D33@mento.at>
 <87h9u9t6hd.fsf@vigenere.g10code.de>
 <09F12993-5464-4156-8C7D-0D40435A3935@gpgtools.org>
 <87pozaw9g8.wl-neal@walfield.org> <87mvuew455.wl-neal@walfield.org>
 <514E159D-C26D-47BF-AB2F-E36ACA75DBC1@gpgtools.org>
Message-ID: <87k2p3s572.fsf@vigenere.g10code.de>

On Fri, 27 Nov 2015 16:56, Mento at gpgtools.org said:

> Would we maintain our fork and you pull the changes?

Send patches if something breaks or you want a change.  And well, you
need to test it.

> I've found your rules for commit messages. What are your other rules
> (coding style, etc.)?

See gnupg/doc/HACKING.

> How should we handle the additional strings? Currently there are two simple strings files for englisch and german in the macosx subdir.

Pinentry must not have any strings.  All strings are provided by gnupg
so that we have a consistent translation.  If you need a new string
please ask for it.


Shalom-Salam,

   Werner

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



From dkg at fifthhorseman.net  Fri Nov 27 20:19:30 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 27 Nov 2015 14:19:30 -0500
Subject: Integrate pinentry-mac into pinentry
In-Reply-To: <87k2p3s572.fsf@vigenere.g10code.de>
References: <ADECD045-2809-4362-8D5A-43EBA9428C33@mykolab.com>
 <EB263EDB-EF9B-4702-98A7-212F0C1046EC@webkeks.org>
 <87sie3i7kb.fsf@vigenere.g10code.de>
 <AB173B31-D818-41A6-B7B7-5978C52211CE@webkeks.org>
 <873861d8eq.fsf@vigenere.g10code.de>
 <483FE4A0-C58E-44AB-AD78-EA5E1A80C8D1@gpgtools.org>
 <2786DC31-AEAC-4406-9143-94F32C74A644@webkeks.org>
 <EF669FD7-889C-49C4-AC86-728B6A94B94A@dressyvagabonds.com>
 <B8217C71-71D1-4134-AD58-A6B9E5FFEA08@webkeks.org>
 <A413BC4D-B3A3-4DF3-8134-80950BCAC798@gpgtools.org>
 <54E9F20F.9040506@enigmail.net> <87ioery4oe.fsf@vigenere.g10code.de>
 <54EDDBF9.3030108@guardianproject.info> <87bnkiuh37.fsf@vigenere.g10code.de>
 <C5DC1C67-2B50-4B96-A581-56DF85266D33@mento.at>
 <87h9u9t6hd.fsf@vigenere.g10code.de>
 <09F12993-5464-4156-8C7D-0D40435A3935@gpgtools.org>
 <87pozaw9g8.wl-neal@walfield.org> <87mvuew455.wl-neal@walfield.org>
 <514E159D-C26D-47BF-AB2F-E36ACA75DBC1@gpgtools.org>
 <87k2p3s572.fsf@vigenere.g10code.de>
Message-ID: <8737vrtflp.fsf@alice.fifthhorseman.net>

On Fri 2015-11-27 12:49:37 -0500, Werner Koch wrote:
> On Fri, 27 Nov 2015 16:56, Mento at gpgtools.org said:
>> How should we handle the additional strings? Currently there are two
>> simple strings files for englisch and german in the macosx subdir.
>
> Pinentry must not have any strings.  All strings are provided by gnupg
> so that we have a consistent translation.  If you need a new string
> please ask for it.

fwiw, i've been working with pinentry for a while now and hadn't
explicitly understood this constraint (though it makes sense now that i
read it and think about it).

And pinentry does use gettext in pinentry/argparse.c and secmem/util.c
(both copied from other projects, so maybe we can ignore that?).

This also makes pinentry less easily useful for non-GnuPG projects (or
rather, requires that non-GnuPG projects provide well-localized strings
directly to pinentry instead of depending on its defaults).

It would be good to add this caveat to doc/HACKING so people better
understand the constraints for pinentry.

           --dkg


From Mento at gpgtools.org  Fri Nov 27 21:36:42 2015
From: Mento at gpgtools.org (Roman Zechmeister)
Date: Fri, 27 Nov 2015 21:36:42 +0100
Subject: Integrate pinentry-mac into pinentry
In-Reply-To: <87k2p3s572.fsf@vigenere.g10code.de>
References: <ADECD045-2809-4362-8D5A-43EBA9428C33@mykolab.com>
 <DD18C5EF-523B-4E99-9C84-55C2D8F862B8@gpgtools.org>
 <EB263EDB-EF9B-4702-98A7-212F0C1046EC@webkeks.org>
 <87sie3i7kb.fsf@vigenere.g10code.de>
 <AB173B31-D818-41A6-B7B7-5978C52211CE@webkeks.org>
 <873861d8eq.fsf@vigenere.g10code.de>
 <483FE4A0-C58E-44AB-AD78-EA5E1A80C8D1@gpgtools.org>
 <2786DC31-AEAC-4406-9143-94F32C74A644@webkeks.org>
 <EF669FD7-889C-49C4-AC86-728B6A94B94A@dressyvagabonds.com>
 <B8217C71-71D1-4134-AD58-A6B9E5FFEA08@webkeks.org>
 <A413BC4D-B3A3-4DF3-8134-80950BCAC798@gpgtools.org>
 <54E9F20F.9040506@enigmail.net> <87ioery4oe.fsf@vigenere.g10code.de>
 <54EDDBF9.3030108@guardianproject.info> <87bnkiuh37.fsf@vigenere.g10code.de>
 <C5DC1C67-2B50-4B96-A581-56DF85266D33@mento.at>
 <87h9u9t6hd.fsf@vigenere.g10code.de>
 <09F12993-5464-4156-8C7D-0D40435A3935@gpgtools.org>
 <87pozaw9g8.wl-neal@walfield.org> <87mvuew455.wl-neal@walfield.org>
 <514E159D-C26D-47BF-AB2F-E36ACA75DBC1@gpgtools.org>
 <87k2p3s572.fsf@vigenere.g10code.de>
Message-ID: <D859AE9B-CA81-4B46-9621-D4F6E9B0840E@gpgtools.org>


Am 27.11.2015 um 18:49 schrieb Werner Koch <wk at gnupg.org>:

> Pinentry must not have any strings.  All strings are provided by gnupg
> so that we have a consistent translation.  If you need a new string
> please ask for it.

I need the strings "Show typing" and "Save in keychain".




Regards, Mento
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20151127/f26bc825/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: strings.png
Type: image/png
Size: 2948 bytes
Desc: not available
URL: </pipermail/attachments/20151127/f26bc825/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </pipermail/attachments/20151127/f26bc825/attachment-0001.sig>

From neal at walfield.org  Sat Nov 28 13:58:32 2015
From: neal at walfield.org (Neal H. Walfield)
Date: Sat, 28 Nov 2015 13:58:32 +0100
Subject: Integrate pinentry-mac into pinentry
In-Reply-To: <D859AE9B-CA81-4B46-9621-D4F6E9B0840E@gpgtools.org>
References: <ADECD045-2809-4362-8D5A-43EBA9428C33@mykolab.com>
 <DD18C5EF-523B-4E99-9C84-55C2D8F862B8@gpgtools.org>
 <EB263EDB-EF9B-4702-98A7-212F0C1046EC@webkeks.org>
 <87sie3i7kb.fsf@vigenere.g10code.de>
 <AB173B31-D818-41A6-B7B7-5978C52211CE@webkeks.org>
 <873861d8eq.fsf@vigenere.g10code.de>
 <483FE4A0-C58E-44AB-AD78-EA5E1A80C8D1@gpgtools.org>
 <2786DC31-AEAC-4406-9143-94F32C74A644@webkeks.org>
 <EF669FD7-889C-49C4-AC86-728B6A94B94A@dressyvagabonds.com>
 <B8217C71-71D1-4134-AD58-A6B9E5FFEA08@webkeks.org>
 <A413BC4D-B3A3-4DF3-8134-80950BCAC798@gpgtools.org>
 <54E9F20F.9040506@enigmail.net>
 <87ioery4oe.fsf@vigenere.g10code.de>
 <54EDDBF9.3030108@guardianproject.info>
 <87bnkiuh37.fsf@vigenere.g10code.de>
 <C5DC1C67-2B50-4B96-A581-56DF85266D33@mento.at>
 <87h9u9t6hd.fsf@vigenere.g10code.de>
 <09F12993-5464-4156-8C7D-0D40435A3935@gpgtools.org>
 <87pozaw9g8.wl-neal@walfield.org> <87mvuew455.wl-neal@walfield.org>
 <514E159D-C26D-47BF-AB2F-E36ACA75DBC1@gpgtools.org>
 <87k2p3s572.fsf@vigenere.g10code.de>
 <D859AE9B-CA81-4B46-9621-D4F6E9B0840E@gpgtools.org>
Message-ID: <87610mwa9z.wl-neal@walfield.org>

At Fri, 27 Nov 2015 21:36:42 +0100,
Roman Zechmeister wrote:
> Am 27.11.2015 um 18:49 schrieb Werner Koch <wk at gnupg.org>:
> 
>     Pinentry must not have any strings. All strings are provided by
>     gnupg
>     so that we have a consistent translation. If you need a new string
>     please ask for it.
>     
> 
> I need the strings "Show typing" and "Save in keychain".

The show-passphrase option is coming to pinentry soon (tm):

  https://bugs.gnupg.org/gnupg/issue2139

We also have support for saving the passphrase in an external password
manager.  This should only be an option if "OPTION
allow-external-password-cache" was set.  The appropriate string is
saved in pinentry->default_pwmngr (which is set via "OPTION
default-pwmngr").

Thanks!

Neal


From wk at gnupg.org  Sat Nov 28 17:29:09 2015
From: wk at gnupg.org (Werner Koch)
Date: Sat, 28 Nov 2015 17:29:09 +0100
Subject: Integrate pinentry-mac into pinentry
In-Reply-To: <D859AE9B-CA81-4B46-9621-D4F6E9B0840E@gpgtools.org> (Roman
 Zechmeister's message of "Fri, 27 Nov 2015 21:36:42 +0100")
References: <ADECD045-2809-4362-8D5A-43EBA9428C33@mykolab.com>
 <87sie3i7kb.fsf@vigenere.g10code.de>
 <AB173B31-D818-41A6-B7B7-5978C52211CE@webkeks.org>
 <873861d8eq.fsf@vigenere.g10code.de>
 <483FE4A0-C58E-44AB-AD78-EA5E1A80C8D1@gpgtools.org>
 <2786DC31-AEAC-4406-9143-94F32C74A644@webkeks.org>
 <EF669FD7-889C-49C4-AC86-728B6A94B94A@dressyvagabonds.com>
 <B8217C71-71D1-4134-AD58-A6B9E5FFEA08@webkeks.org>
 <A413BC4D-B3A3-4DF3-8134-80950BCAC798@gpgtools.org>
 <54E9F20F.9040506@enigmail.net> <87ioery4oe.fsf@vigenere.g10code.de>
 <54EDDBF9.3030108@guardianproject.info>
 <87bnkiuh37.fsf@vigenere.g10code.de>
 <C5DC1C67-2B50-4B96-A581-56DF85266D33@mento.at>
 <87h9u9t6hd.fsf@vigenere.g10code.de>
 <09F12993-5464-4156-8C7D-0D40435A3935@gpgtools.org>
 <87pozaw9g8.wl-neal@walfield.org> <87mvuew455.wl-neal@walfield.org>
 <514E159D-C26D-47BF-AB2F-E36ACA75DBC1@gpgtools.org>
 <87k2p3s572.fsf@vigenere.g10code.de>
 <D859AE9B-CA81-4B46-9621-D4F6E9B0840E@gpgtools.org>
Message-ID: <87a8pyrstm.fsf@vigenere.g10code.de>

On Fri, 27 Nov 2015 21:36, Mento at gpgtools.org said:

> I need the strings "Show typing" and "Save in keychain".

This is the list of the fixed strings:

      /* TRANSLATORS: These are labels for buttons etc used in
         Pinentries.  An underscore indicates that the next letter
         should be used as an accelerator.  Double the underscore for
         a literal one.  The actual to be translated text starts after
         the second vertical bar.  Note that gpg-agent has been set to
         utf-8 so that the strings are in the expected encoding.  */
      { "ok",     N_("|pinentry-label|_OK") },
      { "cancel", N_("|pinentry-label|_Cancel") },
      { "yes",    N_("|pinentry-label|_Yes") },
      { "no",     N_("|pinentry-label|_No") },
      { "prompt", N_("|pinentry-label|PIN:") },
      { "pwmngr", N_("|pinentry-label|_Save in password manager"), 1 },
      { "cf-visi",N_("Do you really want to make your "
                     "passphrase visible on the screen?") },
      { "tt-visi",N_("|pinentry-tt|Make passphrase visible") },
      { "tt-hide",N_("|pinentry-tt|Hide passphrase") },
      { NULL, NULL}
    };

What about using only a tooltip and an icon for the "Show typing"?  For
the tooltip you may then use tt-visi and tt-hide.  Instead of an icon
the texts "..." and "abc" may also work in all languages.

For "Save in keychain" you should use pwmngr.  In you code you can use this:

      if (pinentry->default_pwmngr)
        {
          msg = pinentry_utf8_validate (pinentry->default_pwmngr);
          w = gtk_check_button_new_with_mnemonic (msg);
          g_free (msg);
        }
      else
        w = gtk_check_button_new_with_label ("Save passphrase using libsecret");

So that if the string is not available a fixed string is used.  We use
a different one here to be able to detect that something went wrong.
pinentry_utf8_validate() is useful to make sure that the provided string
is really utf-8 encoded.


Salam-Shalom,

   Werner

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



From kristian.fiskerstrand at sumptuouscapital.com  Mon Nov 30 17:43:54 2015
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Mon, 30 Nov 2015 17:43:54 +0100
Subject: Possible regression in 2.1.10-beta for --local-user
Message-ID: <565C7CCA.3030100@sumptuouscapital.com>

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

Dear all,

I haven't had time to bisect which commit introduce this behavior, but
somewhere after 2.1.9 there seems to be a regression to specifying a
specific signing subkey for --local-user using the ! operator. briefly
looking through log I suspect it might be related to [0]

$ gpg --version
gpg (GnuPG) 2.1.10-beta195
libgcrypt 1.7.0-beta284

$ echo "test" | gpg -u 0x250B7AFED6379D85! --clearsign
gpg: Invalid value ('0x250B7AFED6379D85!').
gpg: (check argument of option '--local-user')

Expected behavior
$ gpg --version
gpg (GnuPG) 2.1.9
libgcrypt 1.7.0-beta284

echo "test" | gpg -u 0x250B7AFED6379D85! --clearsign
results in good signature.

References:
[0]
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=f9983
0b72812395da5451152bdd2f2d90a7cb7fb;hp=e8c53fca954d33366e3494a6d4eecc386
8282bcc
- -- 
- ----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- ----------------------------
"When I was kidnapped, my parents snapped into action. They rented out
my room."
(Woody Allen)
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJWXHzGAAoJECULev7WN52FzkYIAMGWgoq7qEdvIm5YMUqu4XCc
zD4ck6BVHE9Qv8PIzS/fH+NN0O0DdMejXW7vGxN54XXP0FMV7EcBsydzPU4Yw/7Y
yStNU0enRJdjBRpWpNjYISFAe5q22nWO1UaDAHLI7SbbFCGfhwHUvkNqurHND77d
yhx7JJVpttafyRxipqe/YcygsR0H3APD0X7Tm9jT6eUbkLdXuN7/lx37zk1n5N8c
C/2pQ1gRpWk5WK0lFocLtMzVRqR3qof9hR+M3tdw19kX8WZJMwggiHp1YpsQzmsK
2qzeN9QIOmcAFkEvLwePQTyv+w4PaUhAYKOqNt8II246/fprY0mrb90BBFD7ijg=
=ahZj
-----END PGP SIGNATURE-----


From neal at walfield.org  Mon Nov 30 20:02:39 2015
From: neal at walfield.org (Neal H. Walfield)
Date: Mon, 30 Nov 2015 20:02:39 +0100
Subject: Possible regression in 2.1.10-beta for --local-user
In-Reply-To: <565C7CCA.3030100@sumptuouscapital.com>
References: <565C7CCA.3030100@sumptuouscapital.com>
Message-ID: <8737vnwbsg.wl-neal@walfield.org>

Hi Kristian,

At Mon, 30 Nov 2015 17:43:54 +0100,
Kristian Fiskerstrand wrote:
> I haven't had time to bisect which commit introduce this behavior, but
> somewhere after 2.1.9 there seems to be a regression to specifying a
> specific signing subkey for --local-user using the ! operator. briefly
> looking through log I suspect it might be related to [0]

I've found the bug and I'll try to come up with a fix tomorrow.

Thanks for the helpful bug report!

Neal