At a meta level, I really think that writing more conservative code that enables compilers to do a better job checking for safety is a good idea. The tricks we do with structs are premature optimization from a time when compilers were dumb as a doornail.

Maybe casting to a void* helps to disable the check in the compiler.

It's unclear from the discussion if this issue has been resolved. @werner can you please comment on this?

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 ?

Thanks. Will go into the next release.

I just fixed that in master. The limit is now 255 also for the loopback.

See also T2038 where the limit was raised from 100 to 255. It has not been raised for the loopback mode though.

I can confirm this behavior with the latest pinentry-gtk-2 under the Awesome window manager.

I can replicate the issue on my system.
It is not the line 681, actually.

Should be fixed in 782f804765b6f4226fd77843e59f57dcca61b6fb, can you verify that? Thanks!

Fine by me, unless someone else is still running into this.

To be clear: the dialogue should be a floating window, and it is when actually promoting for a pin entry, but not when alerting to the absence of a PGP card.

I am not sure I understand your question. In any case you need to tell us whcih pinentry flavour you ar using (gpt, qt, curses, gnome, etc...

We have fixed a couple of bugs related to keyservers between 2.1.17 and the current .21.

I think that the problem is in your usage with your tool. Please have a look at md_open function in cipher/md.c.
This bug is not the one in libgcrypt, but in the compiler.

Same argument can apply to MD5. See T3249: sha256.c:265:3: runtime error: unsigned integer overflow: 4084723048 + 1633837952 cannot be represented in type 'unsigned int' of SHA2.

See T3245: cipher-gcm-intel-pclmul.c:418:17: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'size_t' (aka 'unsigned long').

See T3248: mpiutil.c:501:37: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'unsigned long' for unsigned integer overflow.

It is intentionally used.
And in the C programming language, it is defined that unsigned integer never overflows (it is computed as modulo 2).

See T3249: sha256.c:265:3: runtime error: unsigned integer overflow: 4084723048 + 1633837952 cannot be represented in type 'unsigned int'.

In the SHA2 computation, it is defined that addition is calculated modulo 2^32.
And in the C programming language, "unsigned integer" operation never overflows (it is defined as modulo).

OK, closed.

In T3239#99523, @gniibe wrote:

"gpg: selecting openpgp failed: Operation not supported by device" means that gpg tried to access smartcard (expecting OpenPGP card), but it failed.

Did you insert some smartcard?

What's the output of 'gpg --card-status'?

In T3239#99523, @gniibe wrote:

"gpg: selecting openpgp failed: Operation not supported by device" means that gpg tried to access smartcard (expecting OpenPGP card), but it failed.

Did you insert some smartcard?

What's the output of 'gpg --card-status'?

Addition 2 [Workaround]:

when I run tail -f agent,log while executing the echo command these are the last lines that are printed to the file before the wait:

The cause of the regression may actually not be in GnuPG's code.

What version of GnuPG are you using? Standard upstream or from a distribution?

We need to find out when this regression happened. Back when David implemented trust signatures he ran tests with the PGP folks to make sure our implementation are compatible. This is why I call this a regression.

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

Can you please provide more information about the versions you are using?

I just tried with Windows 7 DE SP1 and GPG4Win 2.3.3 and it just worked fine.

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

Well, I closed it as invalid because werner asked for more info a year ago and there was no response (at least none that made it into the bug tracker). If there is still an issue, maybe you can describe it in more detail and reopen the ticket. Thanks!

Oh, this has been fixed? Sorry, i don't think i got any message from this, i have changed my e-mail address now.

Thanks for reporting this, but there isn't really anything we can do about it for several reasons, one is that we don't have Symantec Enterprise Vault to try to reproduce it.

@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?

Is this still an issue?

The passage has been removed from the dirmngr man page, and I marked the gpgsm option as obsolete.

This works now, there have been many changes in how homedir is handled since then. For example 70a8584ec4389209762eb65bb77f20f7881577be and aab8a0b05292b0d06e3001a0b289224cb7156dbd, among many others.

Thanks for letting us know, but there is nothing we can do about it, so I am closing it here.

That's fine. The 2.0 branch will reach EOL in 6 months and we will
probably only do a last maintenance release. No need to backport this
fix, though.

"gpg: selecting openpgp failed: Operation not supported by device" means that gpg tried to access smartcard (expecting OpenPGP card), but it failed.

Btw, if you want to use the test script, you have to use "gpg2 --keyid-format short".

I have verified that it works fine in 2.1.21. I did not test 2.0.30, but that's very old, just use the latest 2.1.x version. gpg 1.4 also only receives critical fixes.

You should really use GPGME.

I don't think we want any behavioral changes to gpg 1.4 anymore. And in gpg2 all of this is different (use-agent is mandatory, passphrase-fd only used with batch).

No feedback for 2 years.

Still an issue in gpg 2.1.21.

I could not reproduce this on Solaris 11.3 amd64 and gcc 4.8, using CFLAGS="-m64 -O2". If you have more information how to reproduce this, please reopen.

Seems to work fine on Solaris 11.3 and gcc 4.8.

I added a new task status "Testing".

On Wed, 28 Jun 2017 15:47, noreply@dev.gnupg.org said:

What tests do you want to be done?

Fixed the PUBLIC_ARCHIVE_URL setting in mm_cfg.py. I have no idea why the other archive links worked.

According to the linked discussion forum, this was a misconfiguration.

No response.

No response for years.

Fixed in b00cf0913243ad5432e4cb859146d88b6691f9a3.

Please reopen if this is still an issue with the latest version of gpg4win.

Please reopen if it can be reproduced with a recent version of gpg4win.

What tests do you want to be done?

Which tool did you use: gpg or gpgsm? <== In-house developed Web Service that call gnupg to decrypt or encrypt