Problem/Bug still persists in current version (gpg4win 3.1.16) --> reopen

GnuPG 2.0 reached end-of-life nearly 4 years ago. See https://gnupg.org/download/index.html#end-of-life . Same for Gpg4win. They are not maintained and its use is very risky due to unfixed bugs. Please update to a recent version.

Please use shorter password.
For gpgsm, maximum is 31 chars.

Thanks. Added to 2.2.

This was actually reported against 2.0.31 which reached EOL 8 months ago.

Sorry, the patch above is completely wrong, since pk->pubkey_usage is not the right key to check.

If someone claims this is a kind of vulnerability, I think that what we need to fix is signature checking side:

The bug is specific to 2.2, which may select available key on card. When such a selection, checking the PK->REQ_USAGE was missed.

Shouldn't this also be applied to STABLE-BRANCH-1-4?

I think that I located the bug and fixed. I wonder why Werner put gpg20 tag.

Same issue exists in 2.2:

A backport to 2.0 does not make anymore sense given EOF in 2 months.

No info received, similar to another fixed bug, and for 2.0 which will soon reach EOL.

2.0 will reach EOL soon and we have received no response. Thus closing. If the problem persists with 2.2 (e.g. from gpg4win 3.0) please re-open this bug.

Won't be fixed for 1.4.

@perske, may I ask you to send a DCO and an possible updated patch against 2.2 to gnupg-devel@ ? I would like to add it to 2.2.2. Sorry for the delays.

This looks suspiciously like T1547: gnupg >= 2.0.21 won't build on OSX 10.8.5 with XCode5.

gpgtools will have to update.

I just verified that this is indeed fixed.

I tried to find evidence that such a change ever landed in 2.0. I now believe the mistake is in the NEWS file. As 2.0 is nearing EOL, we won't backport this.

gnupg uses LC_ALL, LC_MESSAGES, LANG and the system default determined with GetThreadLocale() on Windows. Can you please check if you have set any of these environment variables?

Landed in 67cd81ed90ad88cbe607b7f7d1a0b1e08b8ac1f1.

The sqlite backend was a little experiement that I did and it will not be merged.

As the @neal branch has not been updated anymore, I wonder what the status of this report is. Do we have a canonical test case and a performance goal, or anything else that let's us evaluate this? @werner ?

No I don't recall any such problems, sorry.

For information, this issue was also discussed on both gnupg-user and gnupg-devel back in january 2017. I mention it here for reference.

@werner The backport to 2.0 didn't happen, I think. Is this still relevant. @justus Do you recall any more problems in the tests?

Any updates / thoughts on how this might be fixed?

Libgcrypt 1.6 reaches EOL in 7 days, so we won't fix it.

What is your operating system?

Hello Werner,

The problem is, that some projects liek gpgtools for MacOS are reluctantly sticking to
gnupg-2.0 :-/

So, I'd love to have this patch committed in order to ease the transition phase from

2.0 to 2.1 for them.

Regards, Wolfgang

This was included in 2.0.30, but somehow was missing from the 2.1.x branch.
I've included it in master as of 8a9d4b55b09d04482b46055f0a60f01b86738df3

Attached example output after patch is applied. Now User4 has full validity like
expected, and the debug output shows a match for User4's email address (NOTE:
the debug output has 'YES' for no match and 'NO' for successful match)

D406: 944_example.patch

Attached example patch prevents escaping normal lowercase letters.

Note that this isn't a general solution, though it does solve the issue for me.
For example, some email addresses have numbers (I don't know if having backslash
before numbers is an issue like it is for letters)

Attached example are the following setup:

user1 tsign user2 with full trust, depth 1, domain="customer.com". User2 signs
user3 through user5 (regular signatures). User4 is at customer.com, users 3 and
5 are at example.com.

Fixed in 2.1.11 and 2.0.30.

I run in the same issue as PRab whenever I suspend or hibernate my machine. The
machine as Broadcom BCM5880 with a smart-card reader, so I cannot unplug it.
Quickest workaround is to kill/restart scdaemon.

Is there/could there be a command that could be sent to scdaemon via the agent
so a reset could be triggered? It should be easy enough to line that up as part
of the resume scripts.

Indeed, this is unfortunate, but not as bad as you make it sound (unless the
user uses always trust).

Note that this is not about signing (which uses the private key), but about
encryption. I've changed the bug title accordingly.

This happens also with master, and it seems the order of keys in the public
keyring is important:

teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % export GNUPGHOME=$(mktemp -d)
teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % gpg2 --import test.user.asc
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: keybox '/tmp/tmp.TR2cSoWHMb/pubring.kbx' created
gpg: /tmp/tmp.TR2cSoWHMb/trustdb.gpg: trustdb created
gpg: key 8D62594F1FE90C7B: public key "test.user@example.org" imported
gpg: Total number processed: 1
gpg: imported: 1
teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % gpg2 --import user.asc
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: key 00988FEC00B5CA77: public key "user@example.org" imported
gpg: Total number processed: 1
gpg: imported: 1
teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % echo huhu|gpg2 -e -r
"user@example.org" -a|gpg2

gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: 1A7265CF27F9E78E: There is no assurance this key belongs to the named user
sub rsa2048/1A7265CF27F9E78E 2016-09-14 test.user@example.org
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
Primary key fingerprint: CA77 8656 2AAC BBB2 6A50 3A50 8D62 594F 1FE9 0C7B

      Subkey fingerprint: 52CB E9DC 1812 9F78 3054  6569 1A72 65CF 27F9 E78E

It is NOT certain that the key belongs to the person named
in the user ID. If you *really* know what you are doing,
you may answer the next question with yes.

Use this key anyway? (y/N)

gpg: signal gpgInterrupt: signal caught ... exiting
Interrupt caught ... exiting
130 teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % export
GNUPGHOME=$(mktemp -d)
teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % gpg2 --import user.asc
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: keybox '/tmp/tmp.Hfjbb2jvji/pubring.kbx' created
gpg: /tmp/tmp.Hfjbb2jvji/trustdb.gpg: trustdb created
gpg: key 00988FEC00B5CA77: public key "user@example.org" imported
gpg: Total number processed: 1
gpg: imported: 1
teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % gpg2 --import test.user.asc
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: key 8D62594F1FE90C7B: public key "test.user@example.org" imported
gpg: Total number processed: 1
gpg: imported: 1
teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % echo huhu|gpg2 -e -r
"user@example.org" -a|gpg2
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: DAB278A8736B0D2C: There is no assurance this key belongs to the named user
sub rsa2048/DAB278A8736B0D2C 2016-09-14 user@example.org
Primary key fingerprint: 6680 B181 D853 CEB5 6671 ECC7 0098 8FEC 00B5 CA77

      Subkey fingerprint: 3909 7C31 399C A746 87B3  5D74 DAB2 78A8 736B 0D2C

It is NOT certain that the key belongs to the person named
in the user ID. If you *really* know what you are doing,
you may answer the next question with yes.

Use this key anyway? (y/N)

gpg: signal gpgInterrupt: signal caught ... exiting
Interrupt caught ... exiting

D198: 866_gnupg-2.1.14.diff

With T1590 irrelevant, issues 1862, 1970, and 2336 resolved (very special
thanks to everyone who helped in fixing them!), this is the only problem left in
version 2.1.14 that forces me to use a patched version of gpgsm for my webmailer.

My patch from 2014-04-30 works, but by mistake ("if (cmp < 0)" in place of "if
(cmp > 0)" it selects not the newest but the oldest one of the ambiguous
certificates what is bad in the DFN PKI because an older one of the certificates
is revoked, so I attach a new patch against 2.1.14.

For the T2238, it was backported in effect (not intentional, though).

1.4: ca1fc59
2.0: 1c15136

Removed from doc with commit d877528

With GnuPG 2.1 and a recent ssh versions you can keep the private key on the
local machine but use it on the remote machine for decrytpion or signing.
Checkout --extra-socket in the gpg-agent man page. This is not possible with 2.0.

Hi Justus,
my report describing the problem, not proposing a solution.
(I think that most report should describe the issue,
so that good solution ideas can be measursed against how could they
solve this and other problems.)

If there is no technical reason to have --faked-system-time
in 2.0.x, I guess that fixing the documentation is the easier solution.

gpg-agent does disable core dumps both in the stable and modern version.
Furthermore I have to agree with Werner here, if there is a process that can
ptrace your gpg-agent, then you have already lost anyway.

I don't understand the bug report. Do you want the feature backported or the
documentation fixed?