Please explain in detail the bug. Note that subkeys.pgp.net is a round-robin
DNS entry, thus you get avrious keyseervers. For such tests. you should use a
one and only one server. For example: hkp://zimmermann.mayfirst.org .

(The second paragraph misses all details)

Issue also occurs in 1.6.1.

keys.gnupg.net. 86400 IN CNAME pool.sks-keyservers.net.

As you can see from the above zone entry this is just a CNAME for the standard
SKS pool. The members of the SKS poool are added and removed on the fly and
depending on your DNS resolve it may takle a while until unresponsive servers
have been removed. Sorry. I can't do anything about it.

Also applied to master.

The mostly used Python binding for GPGME seems to be pyme. However,
it does not yet support the edit interface thus for your task it is
probably not suitable either.

GPGME is actually available for all platforms and that is the reason
why I always suggest it. It even comes with a command line tool to
access gpg via gpgme. gpgme-tool is a debugging aid but useful on its
own for scripting purposes. It might make sense to add support for
some commonly used task to it.

I understand your concerns about GPA. The guardianproject has its own
tools based on GPGME but I have not yet looked at the key management.
Unfortunately I have no experience with MacOS and the folks providing
GnuPG for OS X seem to do their own thing. My main platforms are Unix
and well for the sake of most users Windows. Note that Python is not
a standard tool on Windows and due to different Python versions one
would need to distribute a separate copy. We don't have a useful
non-Microsoft packaging system for Windows which makes things hard.

The yes, yes, DWIM option has often been requested but it is not easy
given the complicated structure of OpenPGP and that some people want
to have full control over what and how they are signing. A
--sign-keys-as-most-users-would-do is of course be possible but it
needs to implement a policy into gpg which is not the best choice.
Putting this into a separate tools would be better.

Regarding --command-fd, the idea is that you can give it just a LF and
it would use the default. However, you need to detect certain prompts
and re-act on them. The most stable way to do this is of course a FSM
which can fail if a some GnuPG version changes things in way it does
not understand anymore. From a security point of view failing is
often better than continuing and possible introducing a security flaw.

The option --yes works only in certain cases, like "overwrite file".

If you send me a more detailed description of what you want to do with
your tool to wk@gnupg.org, we may be able to find a solution which
can also benefit GPA users (i.e. Windows).

Fixed with commit 23191d7.
This should be the same patch as used by Debian.

Thank you for the ideas.

Omnicard based readers do not work with Linux if you use keys >= ~2k. Actually
they have lot of problems. On Windows they work, though.

This is the wrong bug tracker.
You may want to report this to the authors of GPGMail.

Sorry for the delay, the passphrase is 512 characters long (now I should change
it after publishing that here ;-)) and just ascii characters.

Cards are openpgp cards from http://g10code.com/p-card.html
S/N:
V2.0 0005 00001E1B
V2.0 0005 00001FDF

My two cardreaders (omnikey 3021 and 4321 v2) seems not supported by scdaemon
directly (scdaemon logs ccid I/O errors for both bricked and live cards)

I've tried to send that apdu's to bricked card via gpg-connect-agent (througt
pcsc daemon) and got unknown scd errors.

After that I've tried to reset my second (worked) card:

/hex
scd serialno

S SERIALNO D276000124010200000500001FDF0000 0
OK

scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40

D[0000] 69 82 i.
OK

scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40

D[0000] 69 82 i.
OK

scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40

D[0000] 69 82 i.
OK

scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40

D[0000] 69 83 i.
OK

scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40

D[0000] 69 82 i.
OK

scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40

D[0000] 69 82 i.
OK

scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40

D[0000] 69 82 i.
OK

scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40

D[0000] 69 83 i.
OK

scd apdu 00 e6 00 00

D[0000] 90 00 ..
OK

scd reset

OK

/echo Disregard the error returned by the next command

Disregard the error returned by the next command

scd serialno undefined

ERR 100663356 Not supported <SCD>

scd apdu 00 44 00 00

ERR 100663351 Invalid value <SCD>

/echo Card has been reset to factory defaults

Card has been reset to factory defaults

after that it became bricked too :-(

scdaemon via pcscd:

scdaemon[16985]: chan_7 <- serialno
2014-02-13 12:37:47 scdaemon[16985] DBG: send apdu: c=00 i=A4 p1=00 p2=0C lc=2
le=-1 em=0
2014-02-13 12:37:47 scdaemon[16985] DBG: PCSC_data: 00 A4 00 0C 02 3F 00
2014-02-13 12:37:47 scdaemon[16985] DBG: response: sw=6B00 datalen=0
2014-02-13 12:37:47 scdaemon[16985] DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=6
le=-1 em=0
2014-02-13 12:37:47 scdaemon[16985] DBG: PCSC_data: 00 A4 04 00 06 D2 76 00 01
24 01
2014-02-13 12:37:47 scdaemon[16985] DBG: response: sw=6285 datalen=0
2014-02-13 12:37:47 scdaemon[16985] DBG: send apdu: c=00 i=A4 p1=04 p2=0C lc=7
le=-1 em=0
2014-02-13 12:37:47 scdaemon[16985] DBG: PCSC_data: 00 A4 04 0C 07 D2 76 00 00
03 01 02
2014-02-13 12:37:47 scdaemon[16985] DBG: response: sw=6B00 datalen=0
2014-02-13 12:37:47 scdaemon[16985] DBG: send apdu: c=00 i=A4 p1=04 p2=0C lc=12
le=-1 em=0
2014-02-13 12:37:47 scdaemon[16985] DBG: PCSC_data: 00 A4 04 0C 0C A0 00 00 00
63 50 4B 43 53 2D 31 35
2014-02-13 12:37:47 scdaemon[16985] DBG: response: sw=6B00 datalen=0
2014-02-13 12:37:47 scdaemon[16985] DBG: send apdu: c=00 i=A4 p1=08 p2=0C lc=2
le=-1 em=0
2014-02-13 12:37:47 scdaemon[16985] DBG: PCSC_data: 00 A4 08 0C 02 2F 00
2014-02-13 12:37:47 scdaemon[16985] DBG: response: sw=6B00 datalen=0
2014-02-13 12:37:47 scdaemon[16985] DBG: send apdu: c=00 i=A4 p1=01 p2=0C lc=2
le=-1 em=0
2014-02-13 12:37:47 scdaemon[16985] DBG: PCSC_data: 00 A4 01 0C 02 50 15
2014-02-13 12:37:47 scdaemon[16985] DBG: response: sw=6B00 datalen=0
2014-02-13 12:37:47 scdaemon[16985] DBG: send apdu: c=00 i=A4 p1=04 p2=0C lc=9
le=-1 em=0
2014-02-13 12:37:47 scdaemon[16985] DBG: PCSC_data: 00 A4 04 0C 09 D2 76 00 00
25 45 50 02 00
2014-02-13 12:37:47 scdaemon[16985] DBG: response: sw=6B00 datalen=0
2014-02-13 12:37:47 scdaemon[16985] DBG: send apdu: c=00 i=A4 p1=04 p2=0C lc=6
le=-1 em=0
2014-02-13 12:37:47 scdaemon[16985] DBG: PCSC_data: 00 A4 04 0C 06 D2 76 00 00
66 01
2014-02-13 12:37:47 scdaemon[16985] DBG: response: sw=6B00 datalen=0
2014-02-13 12:37:47 scdaemon[16985] no supported card application found: Invalid
value
scdaemon[16985]: chan_7 -> ERR 100663351 Invalid value <SCD>
scdaemon[16985]: chan_7 <- RESTART
scdaemon[16985]: chan_7 -> OK

---------

scdaemon directly:

----------

scdaemon[17272]: chan_7 <- serialno
2014-02-13 12:44:41 scdaemon[17272] reader slot 0: using ccid driver
2014-02-13 12:44:41 scdaemon[17272] slot 0: ATR=3B DA 18 FF 81 B1 FE 75 1F 03 00
31 C5 73 C0 01 40 00 90 00 0C
2014-02-13 12:44:41 scdaemon[17272] DBG: send apdu: c=00 i=A4 p1=00 p2=0C lc=2
le=-1 em=0
2014-02-13 12:44:41 scdaemon[17272] DBG: raw apdu: 00 A4 00 0C 02 3F 00
2014-02-13 12:44:46 scdaemon[17272] ccid_transceive failed: (0x1000a)
2014-02-13 12:44:46 scdaemon[17272] apdu_send_simple(0) failed: card I/O error
2014-02-13 12:44:46 scdaemon[17272] DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=6
le=-1 em=0
2014-02-13 12:44:46 scdaemon[17272] DBG: raw apdu: 00 A4 04 00 06 D2 76 00 01 24 01
2014-02-13 12:44:51 scdaemon[17272] ccid_transceive failed: (0x1000a)
2014-02-13 12:44:51 scdaemon[17272] apdu_send_simple(0) failed: card I/O error
2014-02-13 12:44:51 scdaemon[17272] DBG: send apdu: c=00 i=A4 p1=04 p2=0C lc=7
le=-1 em=0
2014-02-13 12:44:51 scdaemon[17272] DBG: raw apdu: 00 A4 04 0C 07 D2 76 00 00
03 01 02
2014-02-13 12:44:56 scdaemon[17272] ccid_transceive failed: (0x1000a)
2014-02-13 12:44:56 scdaemon[17272] apdu_send_simple(0) failed: card I/O error
2014-02-13 12:44:56 scdaemon[17272] DBG: send apdu: c=00 i=A4 p1=04 p2=0C lc=12
le=-1 em=0
2014-02-13 12:44:56 scdaemon[17272] DBG: raw apdu: 00 A4 04 0C 0C A0 00 00 00
63 50 4B 43 53 2D 31 35
2014-02-13 12:45:01 scdaemon[17272] ccid_transceive failed: (0x1000a)
2014-02-13 12:45:01 scdaemon[17272] apdu_send_simple(0) failed: card I/O error
2014-02-13 12:45:01 scdaemon[17272] DBG: send apdu: c=00 i=A4 p1=08 p2=0C lc=2
le=-1 em=0
2014-02-13 12:45:01 scdaemon[17272] DBG: raw apdu: 00 A4 08 0C 02 2F 00
2014-02-13 12:45:06 scdaemon[17272] ccid_transceive failed: (0x1000a)
2014-02-13 12:45:06 scdaemon[17272] apdu_send_simple(0) failed: card I/O error
2014-02-13 12:45:06 scdaemon[17272] DBG: send apdu: c=00 i=A4 p1=01 p2=0C lc=2
le=-1 em=0
2014-02-13 12:45:06 scdaemon[17272] DBG: raw apdu: 00 A4 01 0C 02 50 15
2014-02-13 12:45:11 scdaemon[17272] ccid_transceive failed: (0x1000a)
2014-02-13 12:45:11 scdaemon[17272] apdu_send_simple(0) failed: card I/O error
2014-02-13 12:45:11 scdaemon[17272] DBG: send apdu: c=00 i=A4 p1=04 p2=0C lc=9
le=-1 em=0
2014-02-13 12:45:11 scdaemon[17272] DBG: raw apdu: 00 A4 04 0C 09 D2 76 00 00
25 45 50 02 00
2014-02-13 12:45:16 scdaemon[17272] ccid_transceive failed: (0x1000a)
2014-02-13 12:45:16 scdaemon[17272] apdu_send_simple(0) failed: card I/O error
2014-02-13 12:45:16 scdaemon[17272] DBG: send apdu: c=00 i=A4 p1=04 p2=0C lc=6
le=-1 em=0
2014-02-13 12:45:16 scdaemon[17272] DBG: raw apdu: 00 A4 04 0C 06 D2 76 00 00 66 01
2014-02-13 12:45:21 scdaemon[17272] ccid_transceive failed: (0x1000a)
2014-02-13 12:45:21 scdaemon[17272] apdu_send_simple(0) failed: card I/O error
2014-02-13 12:45:21 scdaemon[17272] no supported card application found: Ошибка
ввода/вывода
scdaemon[17272]: chan_7 -> ERR 100696113 Ошибка ввода/вывода <SCD>
scdaemon[17272]: chan_7 <- RESTART
scdaemon[17272]: chan_7 -> OK

Fixed with commit f916ab7 to be released with 1.5.0 (hopefully this month)
Workaround is obvious.

Thanks.

For 2.1 use --with-keygrip.
2.0 does not use the agent for secret key operations but merely as a passphrtase
cache.

And well, using opensc or pcscd stuff might not work. Better use the internal
driver. It is also possible that omnicard readers don't work (for example they
do not work with 2k keys).

I don't know about the crypto-stick. For the other cards feed

/hex
scd serialno
scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40
scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40
scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40
scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40
scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40
scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40
scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40
scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40
scd apdu 00 e6 00 00
scd reset
/echo Disregard the error returned by the next command
scd serialno undefined
scd apdu 00 44 00 00
/echo Card has been reset to factory defaults

this into gpg-connect-agent. You may need to do it a second time after
reinserting the card.

That ain't no bug. gpg is waiting for input data. Enter it on the terminal,
provide a file or feed it from stdin.

D191: 426_darwin_ppc.diff

D190: 425_no-expiry.patch

This happens because AM_PATH_GPG_ERROR uses AC_ARG_WITH
in a bad way. First it parses the official name, which
is --with-libgpg-error-prefix. But then it tries to implement
a fallback to the old undocumented option name
--with-gpg-error-prefix. Unfortunately, that fallback
unconditionally overwrites the result of the first
AC_ARG_WITH.

The enclosed patch fixes this issue.

This patch needs to be installed in both the libksba
and the gnupg repositories.

The same issue was however fixed in the libassuan repo
in 97ce28a430129ce997783c6196ccfe737f5b3007. Applying
that solution in the libksba and gnupg repos would work
just as fine as my patch (and reduce the proliferation
of differing versions).

I think T1526 is a duplicate of this bug.

I think T1561 is the same bug, but in the gnupg
repository.

D166: 424_0001-configure-fix-with-libgpg-error-prefix.patch

I was not aware that the subkey can have a different passphrase. That
does indeed complicate things.

I like your idea to tell gpg-agent about related keys. I think that would
solve the problem. (I did look at the existing feature requests but did
not find a duplicate.)

gpg-agent does not known about OpenPGP. Thus the concept of primary and and
secondary (sub) keys is also unknown to it. The second reason why this can't be
done is because each key part may have a different passphrase. GPG tries to
make them all the same but it is possible for a user to change that or import
subkey with different passphrases.

Now, what could be done is to tell gpg-agent to try the passphrase of a
different key before asking the user. This requires a hint mechanism so that
gpg can tell gpg-agent about related keys. We have something similar in the key
creation code. If you would like this, please change the priority to "feature
request". It is possible that such a feature request has already been entered.

[role changed to User]

I attach a small shellscript that demonstrates the problem. It must be run in an
environment where no agent is running. This has been tested under Ubuntu Linux.
If prompted for a passphrase, use "abc". Please read the script before running it.

Thanks, it's no problem to wait until 1.6.2. I just tested the patch and it's
working as intended.

Oh no!

I recall that I looked up the commit id this morning but obviously was disturbed
and thus didn't actually complete the cherry-pick. Sorry. I just pushed the
change. We need to wait some time before we can do a 1.6.2.

I attach a patch for 1.6.1.

D187: 422_0001-cipher-Take-care-of-ENABLE_NEON_SUPPORT.patch

A user shall not use automake to build libgrypt.

I am very well aware of all the problems with newer automake versions. I try to
eventually mitigate the problems and the extra rules we have in some projects
might be helpful but a proper solution for automake would be to reverse the
default tests method to serial-tests. There are only a few projects with lots
of regression tests which benefit from the new default - those could easily
switch on parallel-tests. But I have seen no signs that they will revert it.

Eventually we need to add our own test driver - IIRC, recent automakes allow to
enable a custom test driver while still having build support by automake.

Did you intend to include the changes in 1.6.1? It doesn't appear that they made
it into the release.

the tarball is OK, however, we must patch the autoconf[1], so we also use the
automake installed at user site which may be newer than 1.13.

it seems that this expression has no effect to 1.13 and damage the 1.14...

bench-slope.log: benchmark.log
hashtest-256g.log: bench-slope.log

you can close this issue, but know that it does exist in newer versions of
automake. if there is no real need for the above statements then removing them
resolves the issue.

[1]
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/libgcrypt/files/libgcrypt-1.5.0-uscore.patch?revision=1.1&view=markup

I am confused:

Do you say that you have problems to build the tarball release? In that case I
can replicate the problem. FWIW, the 1.6.1 release has been build with automake
1.11 and I am pretty sure that this was also the case for 1.6.0.
From the top Makefile.in:

Makefile.in generated by automake 1.11.6 from Makefile.am.

So, why do you need autoreconf to fix a problem with parallel tests? automake
1.11 does not generate such test rules.

Done and 1.6.1 released

That was added because we have it in master.

Have 'it'? I see it in the tarball of 1.6.

Again: If you do not use the tarball release do not expect that pacthes will

be included. You should never do autoreconf.

We do use the tarball release, and we must patch it to resolve issues you do not
handle as I presented in previous comment.

That was added because we have it in master.

Again: If you do not use the tarball release do not expect that pacthes will be
included. You should never do autoreconf.