We use "error ..." and "failed to ..." interchangable. The German translation even uses the same term for both.
Thus I think it would be better to keep the old diagnostic but show it only in --verbose mode.

I did not want to move the fingerprint verification process more prominent with an entry field or something like that.

With the new version we get an even more extensive rework of the certify dialog. We now also have support for search tags.

It's probably a wrong encoding in the italian translation. Will be fixed with updating our build system to buster and NSIS-3

Is this resolved?

I tuned down the error message. I don't think there is a problem here anymore.

See also D475.

BTW, since I start my X session with startx, these are the relevant parts I have in my .xinitrc:

So my gpg-agent.conf file looks like this now:

Please add

In T4726#130609, @werner wrote:

-r  STRING

does a remote key lookup only if STRING is a valid addr-spec. No extraction of the addr-spec from STRING is done and thus angle brackets inhibit the use of a remote lookup.

does a remote key lookup only if STRING is a valid addr-spec. No extraction of the addr-spec from STRING is done and thus angle brackets inhibit the use of a remote lookup. This was implemented in this way to be as much as possible backward compatible.

DETAILS says:

*** PLAINTEXT_LENGTH <length>
    This indicates the length of the plaintext that is about to be
    written.  Note that if the plaintext packet has partial length
    encoding it is not possible to know the length ahead of time.  In
    that case, this status tag does not appear.

Sorry, we can't replicate this with the current pinentry version.

I always select both files and click to verify, I thought that was the way
it was supposed to be done, that I should provide the file and the
signature to the program.

Just downloaded the file and signature and there is only one signature. Just verifying the signature also does not result in duplicated results.

"PLAINTEXT 75 ..." means UTF-8 encoding (u) which is not not binary (b) or MIME ('m') and thus on Unix the line endings are converted from CR,LF to LF. On Windows you should see a different length. See plaintext.c#handle_plaintext()

Thanks for the report. I'm only giving it low priority because while it is ugly it is no loss of functionality.

Thanks for the report. I fixed this for the next 2.2 release and put a not in the source file to not translate the keyword.

Thanks for the follow-up Werner.

Dehydrated problem after the last server update: https://github.com/FlorentCoppint/dehydrated/commit/aed6f4ba06858c926042b95f1cef4a7a681ddf88

Then better do not use a curses pinentry. It can't guarantee that another process changes the tty properties. For security reasons it is better to run the pinentry in a different window (ie. a GUI based pinentry).

Sorry, it was simply my confusion (between GEMPC_PINPAD and GEMPC_EZIO).
Fixed now.

Please test. When I can confirm that it is stable, I'll backport it to 2.2.

Please no reports for non-released devel versions.

Ping.

@werner, are you saying that gpgme is not fully supported for use with gpg 1.4?

@werner, you seem to be saying that -r does not imply "key lookups on remote services". Is that correct?

In T4726#130341, @werner wrote:

This is a misunderstanding. The extraction of mail addresses is only doe for key lookups on remote services. Thus the -r case is as intended.

This is a misunderstanding. The extraction of mail addresses is only doe for key lookups on remote services. Thus the -r case is as intended.

That seems to be gpg 1.4 which we do not fully support.

Sure: https://gitlab.com/sequoia-pgp/openpgp-interoperability-test-suite/blob/master/src/gnupg.rs#L70

Is this task maybe related to T1927?

Thank you @dkg for creating the bug report! I would like to glean the following information from the above mentioned discussion.

@justus can you provide an example of the gpgme code you're using that generates this weirdness?

https://twitter.com/charleslewisni4/status/1051021429637025792?s=20

Still unresolved...

GnuPG ships a non-PKI certificate, specifically to authenticate hkps.pool.sks-keyservers.net. Now due to an implementation detail, this has been shown to potentially lead to authentication of other domains by this certificate, if a maintainer changes the default keyserver via the DIRMNGR_DEFAULT_KEYSERVER variable in configure.ac. Now arguably, this variable isn't exposed via ./configure, so it's not "officially" configurable - but evidently maintainers do want to change it. A trivial one-line patch was supplied to change the unintended and potentially security-problematic behavior into the (I believe) obviously intended one.

@gniibe oh, I see thanks for pointing out precisely main the problem. I will check the hardware supply chain RoHS 2002/95/EC

@pow, thanks for a reference. But problem here is that there are multiple products with same name.

I've also noticed this issue on windows when trying to symlink %APPDATA%\gnupg to $HOME/.gnupg under msys32.

Dear Martin,

Not sure what I did wrong this time, but it's broken again - GPG will again prompt for the PIN on my computer instead of on the Gemalto Ezio Shield reader :(

I'm using GnuPG 2.2.4-1ubuntu1.2 with your patch applied:

I have the same effect if I send a signed text-only or HTML email using Outlook 365 and our Exchange 365 and if I view the mail on Outlook on Android. The mail shows no contents only the file. If I view the mail using Outlook 365 on my PC or Windows 10 Mail it looks fine.
If I address it also to my Microsoft account and my Gmail account (using all adresses in the TO: field of the same mail) the email looks normal in the Gmail Android app and (!) in Outlook for Android.
So the same mail - both in the same Outlook for Android app - looks correct in my Microsoft account inbox but only shows the file in my Exchange inbox - in the same Outlook App. Weird… Nokia 7 plus, Android 9, newest patch level (September 2019) and no updates in Google Play Store.
BTW: In Exchange 365 I configured the message flow, default remote domain (there is no other) to never to use Rich Text, always and only HTML.

Thanks for the feedback! Right now it hangs only for a few seconds, then works as usual. No idea how this come, but I'll close the issue and contact the ML if it appears again.

Please try with the latest GnuPG version (2.2.17) - it is unlikely that we can give support for an old version with Ubuntu's own set of patches. It is also advisable to post to the gnupg-users ML because over there you have hundreds of Ubuntu users.

I agree with @werner that when presented with a User ID with self-sig with preference, the preferences subpackets from the self-sig should take precedence.

I modified _gcry_ecc_fill_in_curve so that g_y has new value in eid4730.

I believe the issue is as follows. When given the option ttyname=... pinentry will open() the given tty and that fails since it is owned by the regular user and not root; strace reports:

openat(AT_FDCWD, "/dev/pts/1", O_RDONLY) = -1 EACCES (Permission denied)

However, when not given this option, pinentry will simply write() to stdout which causes no permission problem; through sudo and the terminal this goes to /dev/pts/1.

I found a way to replicate that error with just pinentry by doing (as root):

# tty
/dev/pts/1
# pinentry
OK Pleased to meet you
OPTION ttyname=/dev/pts/1
OK
GETPIN
S ERROR gtk2.open_tty_for_read 83918849
ERR 83918849 Permission denied <Pinentry>

When I remove OPTION ttyname=... there is no error.

My other terminals (xterm) are /dev/pts/1, /dev/pts/2, etc. and I can reproduce the bug in them too.

Also in another terminal?

I did not (neither in my root shell nor in my user shell) but setting and exporting this environment variable does not make any difference: gpg --gen-key still fails as above. (Note that tty indeed returns /dev/pts/0 .)

Do you have

GPG_TTY=$(tty)
export GPG_TTY

That's my badness. I think that I haven't seen this problem, because I mainly use tokens (where keygrip difference doesn't matter, after --card-status).

Hi
FYI here is what I did to resolve:
running gpg.exe and gpg-agent.exe as Administrator and XP mode....
gp-agent:
set service Priority to REALTIME
Disabled Windows UAC virtualization.

Thanks for your help investigating this.