That is work in progress - please don't report bug for master to the tracker.

FWIW here's the trace (I pressed Ctrl-C when the passphrase was asked for)

tfoerste@n22 ~/workspace $ git tag -s 'test' -m ''
trace: built-in: git 'tag' '-s' 'test' '-m' ''
trace: run_command: 'gpg' '-bsau' 'Toralf Förster <toralf.foerster@gmx.de>'
gpg: enabled debug flags: memstat trust extprog assuan

You need a passphrase to unlock the secret key for
user: "Toralf Förster <toralf.foerster@gmx.de>"
1024-bit DSA key, ID 7DB69DA3, created 2004-08-14

gpg: DBG: connection to agent established
gpg: cancelled by user
gpg: skipped "Toralf Förster <toralf.foerster@gmx.de>": Operation cancelled
gpg: signing failed: Operation cancelled
random usage: poolsize=600 mixed=0 polls=0/0 added=0/0

outmix=0 getlvl1=0/0 getlvl2=0/0

secmem usage: 0/32768 bytes in 0 blocks
error: gpg failed to sign the data
error: unable to sign the tag

Even if that function is never called on Android, it will need to be #ifdefed out
in order for that code to build for Android. Right now, linking fails because it
can't find the symbol pthread_atfork.

Thanks for information (Note: I don't have experiences for Android).
I realized that fork/exec is basically not supported for applications on
Android.
If this were true, it makes sense to ifdef-out the calls to pthread_atfork for
Android.

The reason why we need to call pthread_atfork is to reset signal mask for
executable fork/exec-ed by the program. We had a bug which stoped killing
pinentry (which was fork/exec-ed by gpg-agent).

Its also not in any headers in the NDK:

$ grep atfork /opt/android-ndk/platforms/android-*/arch-arm/usr/include/*.h
$ grep atfork /opt/android-ndk/platforms/android-*/arch-arm/usr/include/*/*.h
$

Bad news, though that .c/.cpp file exists, it does not seem to get built into
Android. I have tried building against android-14, which is after that file was
introduces, and no luck. I also tried looking for it in the libs, and its not
in the .so or .a libs. Running this gives me nothing:

$ strings /opt/android-ndk/platforms/android-*/arch-arm/usr/lib/* | grep atfork

we've decided to suspend support for older versions on Android, so we can leave
this as is for now, any maybe forever. We want to support older versions, but
its more work than we can handle. Patches are welcome though, if anyone wants
to add back support for Android versions old than android-14/4.0/Ice Cream Sandwich.

It looks like pthread_atfork() was not added to bionic libc[1] until after
android-10/v2.3.6/Gingerbread. That excludes 1/4 of current Google Android
users, and probably more of unoffical Android users.[4] To target older
versions of Android, you either have to include pthread-atfork.c[2] or the newer
[pthread_atfork.cpp][3] in your project, or not use pthread_atfork() at all.
We might be able to manage including pthread-atfork.c, but it could be ugly.

[1]:

https://android.googlesource.com/platform/bionic.git/+/4f086aeb4aa06e13079b7fec71a8178ceeacf318

[2]:

https://android.googlesource.com/platform/bionic.git/+/android-4.0.1_r1/libc/bionic/pthread-atfork.c

[3]:

https://android.googlesource.com/platform/bionic.git/+/master/libc/bionic/pthread_atfork.cpp

[3]: https://developer.android.com/about/dashboards/index.html

I checked the source code of Bionic libc. There is the function defined:
https://github.com/android/platform_bionic/blob/master/libc/bionic/pthread_atfork.
cpp

Is it compile time option not including this function?

Still have this issue.

The patch against 2.0.19 applies to 2.0.22, bumping the version.

I will try again on both mailing lists, as well.

This has been discussed ad nauseam. Thus this will not be included.

D182: 410_0001-gpg-Compile-time-flag-for-RSA-key-sizes-4096.patch

Uploaded a new patch file - I missed a semicolon.

D184: 409_libksba-1.3.0-undef-true.patch

D183: 407_0001-gpg-Compile-time-flag-for-RSA-key-sizes-4096.patch

Hi Werner,

thanks! So, for GnuPG "Version:" we are ok.

I'm going to push forward the other application authors to disable the Comment:
field, at least removing the version information.

There is no comment header by default. Adding an extra option to disable it
does not make much sense - if application authors want them you need to convince
them. They are sometimes even used to convey meta information and thus a change
here would break some applications.

Would it possible also to provide a switch to prevent/filter out the adding of
"Comment:" header by default?

As i did notice that all software using GnuPG add a "Comment:" version with
additional "version leak" (such as EnigMail, MacGPG, etc).

I think that would be valuable if GnuPG would, by default, filter out the
"Comment:" header unless a specific command line switch is enabled.

A Default that does not allow "Comment:" by default.

A command line switch, like --enable-comment-header, to enable it.

That way, most of the software integrating GnuPG, when upgrading will need to
manage this condition and, by default, they will not leak additional information
in the "Comment:" header.

What do you think=

The new default is now

  Version: GnuPG v1

with --emit-version you can add more info and with --no-emit-version the version
line is removed as before. Pushed to all branches. A new 1.4 release is due
next month.

Yeah, that it is a very old discussion on whether versions numbers are good or
bade security wise. IIRC, we had such a discussion again on the GnuPG users
list a few month before the snow.

Distinguishing between GnuPG-1 and GnuPG-2 would still be useful so to see
whether 1 is still in use. Dropping the exact version number and the OS is fine
with me.

gpg can't do anything about permitting - the user may do what s/he wants. Using
sed is actually a fine way to insert whatever one likes and that is nothing
can't gpg can avoid.

Added GPGtools ticket
http://support.gpgtools.org/discussions/everything/13667-privacy-leak-in-version-and-comment-header

A discussion on this issue started on liberationtech mailing list on
https://mailman.stanford.edu/pipermail/liberationtech/2013-November/012239.html

This issue has been reported also on Enigmail
https://sourceforge.net/p/enigmail/bugs/215/

Mmmh when I run:

#include <stdio.h>
int _dowildcard = -1;
int main (int argc, char **argv)
{

int i = 0;
for ( i = 0; i< argc; i++) {
    printf("%s\n", argv[i]);
}
return 0;

}

With the command line *.* it just prints "*.*". Linking with CRT_glob.o directly
also leads to the same result.

Hi,
there is apparently a compile option "enable-wildcard" for the mingw-w64 c runtime.

But from:
http://mingw-w64.sourcearchive.com/documentation/0~20100125-3/wildcard_8c-source.html

I take it that you can also enable it in the program by defining int _dowildcard

-1;

I'll test it and let you know if this worked.

For the record. This is now optional in pinentry 0.8.4 you can pass
--enable-pinentry-qt4-clipboard to configure to enable clipboard and paste support.

No RSS at the moment. I disable the link until it works again.

I don't know what you are talking about.
ask_curve is a function in GnuPG master and thus *work in progress* - writing
bug reports make no sense. IF you want to discuss something, please do that at
gnupg-devel.

Fixed with commit 571bcd4. Thanks.

No, they are not. This is the specification of the algorithm.

On 2013-11-13 at 23:29 +0000, asdil12 via BTS wrote:

The fix for the login-data thing works fine.

The fix for the login-data thing works fine.

On 2013-11-12 at 21:29 +0000, asdil12 via BTS wrote:

asdil12 <dominik@heidler.eu> added the comment:

OK, I tested gnupg-2.0.22 with both patches applied, and it worked again.

I also noticed, that the pinpad won't be used - you would be asked via software

• (even if enable-pinpad-varlen was specified), if this

Login data .......: gpguser\n\x14P=6,8\n
thing was set on the card.

OK, I tested gnupg-2.0.22 with both patches applied, and it worked again.

I also noticed, that the pinpad won't be used - you would be asked via software

• (even if enable-pinpad-varlen was specified), if this

Login data .......: gpguser\n\x14P=6,8\n
thing was set on the card.

I tested on Archlinux (x86_64) applying my
patches on the current archlinux gnupg pkg.

On 2013-11-09 at 15:36 +0000, asdil12 via BTS wrote:

I just retried today using gnupg-2.0.22 with your patch, and it
failed again, if the enable-pinpad-varlen option was set:

the reiner reader also doesn't seem to work:

2013-11-09 17:00:48 scdaemon[7374] signatures created so far: 83
2013-11-09 17:00:48 scdaemon[7374] DBG: check_pcsc_pinpad: command=20, r=0
2013-11-09 17:00:48 scdaemon[7374] DBG: prompting for pinpad entry '||Please
enter the PIN%0A[sigs done: 83]'
2013-11-09 17:00:48 scdaemon[7374] DBG: send secure: c=00 i=20 p1=00 p2=81
len=24 pinmax=-1
2013-11-09 17:00:48 scdaemon[7374] DBG: response: sw=6B80 datalen=2
2013-11-09 17:00:48 scdaemon[7374] DBG: dismiss pinpad entry prompt
2013-11-09 17:00:48 scdaemon[7374] verify CHV1 failed: Card error
2013-11-09 17:00:48 scdaemon[7374] operation sign result: Card error
2013-11-09 17:00:48 scdaemon[7374] app_sign failed: Card error
2013-11-09 17:00:48 scdaemon[7374] updating slot 0 status: 0x0000->0x0007 (0->1)
2013-11-09 17:00:48 scdaemon[7374] sending signal 12 to client 4554

I just retried today using gnupg-2.0.22 with your patch, and it failed again, if
the enable-pinpad-varlen option was set:

one try:

2013-11-09 16:30:01 scdaemon[1536] DBG: send apdu: c=00 i=CA p1=00 p2=C4 lc=-1
le=256 em=0
2013-11-09 16:30:01 scdaemon[1536] DBG: PCSC_data: 00 CA 00 C4 00
2013-11-09 16:30:01 scdaemon[1536] DBG: response: sw=9000 datalen=7
2013-11-09 16:30:01 scdaemon[1536] DBG: dump: 01 20 20 20 03 00 03
2013-11-09 16:30:01 scdaemon[1536] 3 Admin PIN attempts remaining before card is
permanently locked
2013-11-09 16:30:01 scdaemon[1536] DBG: check_pcsc_pinpad: command=20, r=0
2013-11-09 16:30:01 scdaemon[1536] DBG: prompting for pinpad entry '|A|Please
enter the Admin PIN'
2013-11-09 16:30:01 scdaemon[1536] DBG: send secure: c=00 i=20 p1=00 p2=83
len=24 pinmax=-1
2013-11-09 16:30:01 scdaemon[1536] pcsc_control failed: not transacted (0x80100016)
2013-11-09 16:30:01 scdaemon[1536] control_pcsc failed: 65547
2013-11-09 16:30:01 scdaemon[1536] DBG: dismiss pinpad entry prompt
2013-11-09 16:30:01 scdaemon[1536] verify CHV3 failed: General error

for the other try (with user pin), see attached log.

Ok

No. The website,the manual, and the FAQ will soon be updated.