Thanks, LD_LIBRARY_PATH solved the problem

This is a bug tracker, not a support forum.

That is a matter of taste. A line requires a LF - many tools even ignore the last line or print a warning for a missing final LF. Not having a final LF is a bad idea.

We have to check what happens here, because list-sigs should be fast.

Yes, please please raise the priority on this. I just spent 15-30 minutes looking through tons of emails on lists saying to use --with-fingerprints and wondering what the heck was wrong with the people posting that until I saw this bug. Please raise priority, please fix.

I fixed the typo. The actual process is the same as described in https://www.gnupg.org/documentation/bts.html, see also T3074.

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

I did some experimenting and clang SIGILL does not trigger with commonly used, but non-conforming, variable-length object with "struct hack", as below:

applied the following patch and the package built successfully. thank you!

Oh well, the usual IBM enum/int problems. It bugs me since the OS/2 days. I am not sure why you experienced it only now. One of the wrong return types is there for ages. I pushed fixes for master and 1.7.

Hi, I found a workaround for neomutt (see https://github.com/neomutt/neomutt/pull/662).

In T1938#99890, @marcus wrote:

It's unclear from the discussion if this issue has been resolved.

With an integer overflow.

This is a standard dynamic sized array:

Sorry, this is a standard C feature and the only way to have dynamic sized arrays. CLANG simply does not get this pattern right. Grep for pgut001's very comments on such ill behaving compilers (including gcc).

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?