Fixed in 2.1.3.

Fixed in 2.0.28 (and in 2.1.x).

Fixed in master which was released as 2.1.5.
Fixed in the repo of 1.4 and 2.0.

This feature has landed in the latest 2.0 and 2.1 branches and support has been
added in pinentry. I'm closing this now.

Thank you, patch applied to master and 1.6 branch.

Fixed with commit 255dadd.

1.5.5 has been released.

1.5.5 has been released. Closing.

Oops. Long standing bug.

Fix in commit
0d28a696163677d6b34a802b6beddecd805d0fc7

The change is in gnupg 2.1.4.

It was fixed in 2.1.4.

Yes, this is fixed. Sorry for forgetting to update this bug. Already noticed your
commits are signed - unfortunately, your commit signing key isn't signed by any other
of your keys, though.

May I assume this problem has been fixed?

(BTW, I sign my commits now)

That's it! Setting

+ export LDFLAGS=-lrt

and then running the build process as described in my original report and in
msg6216, compilation is successful.

Thank you very, very much!

Thanks. No, you don't need to create another issue, since it's known simple issue.

Old system has clock_gettime function in librt. Please link with -lrt.
It would be good for npth's configure script to detect this for its build time.
I'll consider about that.

A big step forward :-)

With the command sequence

+ [... for building prerequisites see original bug report ...]
+ tar jvxf ../gnupg-2.1.2.tar.bz2
+ cd gnupg-2.1.2
+ /bin/cp -i common/Makefile.am common/Makefile.am.orig </dev/null || true
+ /bin/cp -i common/Makefile.in common/Makefile.in.orig </dev/null || true
+ s1='s|^t_jnlib_src = t-support\.c t-support\.h$|t_jnlib_src = t-support.h|'
+ s2='s|^amobjects_18 = t-support\.\$(OBJEXT)$|amobjects_18 =|'
+ /bin/sed "$s1" <common/Makefile.am.orig >common/Makefile.am
+ /bin/sed "$s1;$s2" <common/Makefile.in.orig >common/Makefile.in
+ ./configure --prefix=/PREFIX --with-gpg-error-prefix=/PREFIX
--with-npth-prefix=/PREFIX --with-libassuan-prefix=/PREFIX
--with-libgcrypt-prefix=/PREFIX --with-ksba-prefix=/PREFIX
--with-pinentry-pgm=/PREFIX/bin/pinentrywrapper
+ make

the build process fails later:

[...]
make[2]: Leaving directory `/root/devel/rpgpg/work/gnupg-2.1.2/sm'
Making all in agent
make[2]: Entering directory `/root/devel/rpgpg/work/gnupg-2.1.2/agent'
[...]
gcc -I/PREFIX/include -I/PREFIX/include -I/PREFIX/include -I/PREFIX/include -g
-O2 -Wall -Wno-pointer-sign -Wpointer-arith -o gpg-agent gpg_agent-gpg-agent.o
gpg_agent-command.o gpg_agent-command-ssh.o gpg_agent-call-pinentry.o
gpg_agent-cache.o gpg_agent-trans.o gpg_agent-findkey.o gpg_agent-pksign.o
gpg_agent-pkdecrypt.o gpg_agent-genkey.o gpg_agent-protect.o
gpg_agent-trustlist.o gpg_agent-divert-scd.o gpg_agent-cvt-openpgp.o
gpg_agent-call-scd.o gpg_agent-learncard.o ../common/libcommonpth.a
-L/PREFIX/lib -lgcrypt -lgpg-error -lassuan -L/PREFIX/lib -lgpg-error
-L/PREFIX/lib -lnpth -lpthread -L/PREFIX/lib -lgpg-error
/PREFIX/lib/libnpth.a(npth.o): In function `npth_clock_gettime':
/root/devel/rpgpg/work/npth-1.1/src/npth.c:699: undefined reference to
`clock_gettime'
collect2: ld returned 1 exit status
make[2]: * [gpg-agent] Error 1
make[2]: Leaving directory `/root/devel/rpgpg/work/gnupg-2.1.2/agent'
make[1]: * [all-recursive] Error 1
make[1]: Leaving directory `/root/devel/rpgpg/work/gnupg-2.1.2'
make: *** [all] Error 2

Shall we keep in this issue or open a new one?

I mean, when you manually edit common/Makefile.in, you need to edit the variable
am__objects_18, so that it won't include the object generated by t-support.c.

See the description of my build steps in my original report: After

+ tar jvxf ../gnupg-2.1.2.tar.bz2
+ cd gnupg-2.1.2

I manually changed both common/Makefile.am and common/Makefile.in and then
continued with

+ ./configure --prefix=/PREFIX --with-gpg-error-prefix=/PREFIX
--with-npth-prefix=/PREFIX --with-libassuan-prefix=/PREFIX
--with-libgcrypt-prefix=/PREFIX --with-ksba-prefix=/PREFIX
--with-pinentry-pgm=/PREFIX/bin/pinentrywrapper
+ make

On 04/23/2015 05:20 PM, Rainer Perske via BTS wrote:

no change: I had already tried installing from scratch working in an empty
directory.

no change: I had already tried installing from scratch working in an empty
directory.

Umm... Could you try 'make distclean', then 'configure && make'? t-support.o is
not the target to build any more by the patch,
so, it should not be linked to t-stringhelp.
When you change common/Makefile.am and common/Makefile.in, common/Makefile
should be generated again,
but it would not be generated, perhaps.

Thank you, but I regret, the patch does not change anything.
(I have made the corresponding change in common/Makefile.in, too,
with same result.)

D291: 599_gpg2-scd-issue-1930-patch.diff

I can confirm that this is resolved in 2.1.3 with .kbx files. Thanks for the fix!

This should be fixed in 5cde5bf. I tested building with LDAP and without. I
also ran some basic queries in the LDAP case and everything seemed ok. If I
don't hear about any further issues, I'll close this in the next few days.

It is fixed by the commit: f82c4a6d0d76e716b6a7b22ca964fa2da1f962a0
This is not a perfect solution (it updates key storage by "learn --force" command
of gpg-agent), but it works fine usually.

Never mind. Just pushed the changes for the 2.0 branch.

Thanks!

Is there a need to backport it to 2.0 ?

No

Patch still needs to be applied upstream but this is tracked in another issue.
-> Resolved

I have verified that the bug have been solved in version 2.2.3. Thank you very much.

All release tags are signed.

Signed commits are a bit cumbersome becuase I would have to insert the smartcard
for all commits. Signing with my on-disk standard key would be possible, though.

Ok, I'll give it a try with 09e8f35d3808d6e49f891360c341aae3869e8650 this weekend.

Regarding https: Yes, this is more security, even though only slightly as you will have
to trust CAs. Without it, an attacker could just give you a different repo and you'd
never notice if you don't compare commit checksums with someone else. Then again, that
someone else could also get the wrong repo, because your government decided that
everybody should get a backdoor'd GPG. With https, you also need to get a valid
certificate that's in the CAs. That's not helping against a government wanting to
backdoor GPG, but it at least helps against script kiddies and the like.

Speaking about signed commits and tags: Why not do that? I tried it with git and it
works great.

s/GPG-2/PGP-2/ of course

Tt is not really corrupted. There are just GPG-2 keys at the wrong place.

Well, some keys are duplicated but I do not think that this created the test case.
The reason for the duplication might be 1.4.12 which may not include the latest
locking code.

Regarding git: An https:// access is not in any way safer - it only hides what
you are doing on the remote repo. The security from git is due to the chain of
hashes. Thus if you see a full commit id you can be sure that we are talking
about the very same code.

Right, I could have given the full commit id, but that won't help either because
you should not trust this bug tracker. The only reliabale task is by starting
from a signed commit or tag and review all code up to there.
Fortunately any tmapering with git.gnupg.org would soon trigger a lot of
complains from people pulling updates and checking commit ids.

Okay, I was able to replicate your test case with an older gpg version. I am not
sure which version that was, though. I would need to bisect to find it.

However, with the latest version (commit 09e8f35d3808d6e49f891360c341aae3869e8650)
the problem has gone.

Thanks!
I'll test it. Any idea what could have caused this corruption in the first place?

Here's how to reproduce it:

$ mkdir 1 2
$ chmod 700 1 2
$ cp ~/.gnupg/gpg-agent.conf 1
$ cp ~/.gnupg/gpg-agent.conf 2
$ gpg2 --homedir 1 --yes --quick-gen-key "Test User 1"
gpg: keybox '1/pubring.kbx' created
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: 1/trustdb.gpg: trustdb created
gpg: key E2D6B58A marked as ultimately trusted
gpg: directory '1/openpgp-revocs.d' created
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
pub rsa2048/E2D6B58A 2015-01-22

Key fingerprint = E618 DF9C A599 A3A5 D5B2  B8FE 57C0 450E E2D6 B58A

uid [ultimate] Test User 1
sub rsa2048/C3D1C503 2015-01-22

$ gpg2 --homedir 2 --yes --quick-gen-key "Test User 2"
gpg: keybox '2/pubring.kbx' created
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: 2/trustdb.gpg: trustdb created
gpg: key C767617A marked as ultimately trusted
gpg: directory '2/openpgp-revocs.d' created
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
pub rsa2048/C767617A 2015-01-22

Key fingerprint = 4741 1B55 ADF9 4000 DFE9  60CF DDF2 7707 C767 617A

uid [ultimate] Test User 2
sub rsa2048/BFC45B68 2015-01-22

$ gpg2 --homedir 1 --export | gpg2 --homedir 2 --import
gpg: key E2D6B58A: public key "Test User 1" imported
gpg: Total number processed: 1
gpg: imported: 1
$ gpg2 --homedir 2 --sign-key E2D6B58A

pub rsa2048/E2D6B58A

created: 2015-01-22  expires: never       usage: SC  
trust: unknown       validity: unknown

sub rsa2048/C3D1C503

created: 2015-01-22  expires: never       usage: E

[ unknown] (1). Test User 1

pub rsa2048/E2D6B58A

created: 2015-01-22  expires: never       usage: SC  
trust: unknown       validity: unknown

Primary key fingerprint: E618 DF9C A599 A3A5 D5B2 B8FE 57C0 450E E2D6 B58A

     Test User 1

Are you sure that you want to sign this key with your
key "Test User 2" (C767617A)

Really sign? (y/N) y

$ gpg2 --homedir 2 --export | gpg2 --homedir 1 --import
gpg: key C767617A: public key "Test User 2" imported
gpg: key E2D6B58A: "Test User 1" 1 new signature
gpg: Total number processed: 2
gpg: imported: 1
gpg: new signatures: 1
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
$ gpg2 --homedir 1 --list-keys

1/pubring.kbx

pub rsa2048/E2D6B58A 2015-01-22
uid [ultimate] Test User 1
sub rsa2048/C3D1C503 2015-01-22

pub rsa2048/C767617A 2015-01-22
uid [ unknown] Test User 2
sub rsa2048/BFC45B68 2015-01-22

$ # Still ok!
$ gpg2 --homedir 1 --sign-key C767617A

pub rsa2048/C767617A

created: 2015-01-22  expires: never       usage: SC  
trust: unknown       validity: unknown

sub rsa2048/BFC45B68

created: 2015-01-22  expires: never       usage: E

[ unknown] (1). Test User 2

pub rsa2048/C767617A

created: 2015-01-22  expires: never       usage: SC  
trust: unknown       validity: unknown

Primary key fingerprint: 4741 1B55 ADF9 4000 DFE9 60CF DDF2 7707 C767 617A

     Test User 2

Are you sure that you want to sign this key with your
key "Test User 1" (E2D6B58A)

Really sign? (y/N) y

$ gpg2 --homedir 1 --list-keys
gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 1 trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1 valid: 1 signed: 1 trust: 1-, 0q, 0n, 0m, 0f, 0u

1/pubring.kbx

pub rsa2048/E2D6B58A 2015-01-22
uid [ undef ] Test User 1
sub rsa2048/C3D1C503 2015-01-22

pub rsa2048/C767617A 2015-01-22
uid [ full ] Test User 2
sub rsa2048/BFC45B68 2015-01-22

$ # Broken!

I applied c595659 manually to 2.1.1, this doesn't change anything.

I'd try it with the latest git master, however I don't see any way to securely check it
out as it is only offered via the insecure git:// protocol.

I am not able to repeat that with the latest git version.
This is probably due to the fix by commit c595659.

A patch has been submitted, which should fix the problem. commit c595659

Jonny, can you confirm that the problem is gone with 2.2.3?

Sorry for the long delay. Fixed with commit 8c5eee5 for 1.7.

I won't backport it to 1.6 because the leak is only triggered by wrong usage of
the functions.

Windows does not allow file names with a '*'. I'm not sure on what level but Its
ok not to handle this case.
I don't expect any problems for internal usage. Keep in mind that this is a
regression, we had wildcard expansion before we made the switch to mingw-w64.

We also don't need this in gpgwrap as gpgwrap just passes the argument on and it
will be expanded in the process itself.

But I actually like the idea to do the wildcard expansion in kleowrap / gpgwrap.
This way it would be contained in Gpg4win and we catch all our "user exposed"
processes. Ok?

I won't do that just for gpg - this would be inconsistent. The wrapper we put
into the PATH directory needs this as well. What about gtk and qt libraries -
they run exe files internally - will the quoting continue to work? A single '*'
in a file name would likely break Enigmail.

Well just gpg would be enough imho as this is by far the most prominent command
line tool.

On the other hand it might be more prudent for us to hack / patch it just in the
gpg4win build to have it enabled globally for all tools we ship so that it is
more consistent. This would mean patching the compiler tough which we tried to
avoid so far.

I would be fine with moving this patch to the version independet gnupg2 patches
in gpg4win as it is kind of a "distribution" option forced upon gpg4win by the
compiler we are currently using.

Werner: If you agree please give a short ping here and I'll move the patch /
close the issue.

Now, shall I add this to gnupg 2.1? To which tools? All or just gpg?

Does the patch work for you?

1.6.2 with the fix was released in August