I am using Debian 9 with the packaged versions. For gnupg this is 2.1.18.

@aheinlein we need to know the gnupg version you are using with GPGME.

There are no team encryption keys, that's the problem. So there is at least a dependency between the tasks, as we can't document what we don't have.

I don't see how this duplicates T3074. If the web form is going to encourage people to ask for the team's encryption keys, it should just provide the encryption keys directly.

Agreed, i think the OP is asking for X when he wants Y, so that makes this request a little bit strange.

Fixed in 6053cb4f. The third patch was obsolete due to use of FIND_QT macro.

I've since tried neomutt-20170707 which includes stbuehler's patch, but I see the same error cases as before.

Note that the documentation clearly says that --nameserver expects an ip address. Now we could make it accept a port too, but that would not make the OP happy, as he wants to talk to localhost, but in tor mode, all dns requests are routed through tor (this is actually one of the main motivations for using a custom DNS resolver).

In T3240#99654, @im0nde wrote:

Neverthenless, I would be interested in other solutions that allow me to keep gnome-keyring installed alongside, as I would like to use it for other applications.

This is not specific to Python, and it may not even be a bug in GPGME, but in gpg. Needs some more investigation.

Fixed in 1e68f93dc547ae75b921e43db35e3599de92e2cb.

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.