Yes, we read up to the first LF. This has been the traditional way of PGP2 and is still used by mail programs like Mutt.

I'm guessing gpg in Unix has stripped the \n if present? I don't have access to a real Unix system at the moment.

I see that problem but gpg has traditionally not interpreted the passphrase in any way. Right, for Windows we could strip the CR but I fear that this might break other users scripts/passphrases. However there should be a warning in the manual.

gpg verifies the content of the file and not its meta data (file name). Thus an empty file is identical to a non-existing file. The OpenPGP protocol does not allow to distinguish between a detached signature and an embedded signature if you sign an empty file.

Nah, I think I laid out all my arguments by now. I don't have more to add, so I'll just let it be.

Thanks for helping out @werner.

Not at all. But 2.1 was such a large change that users really should have read the announcement and think about their use case. We have exensivly communicated the changes and can expect that users test their new installation. IF you have further comments, please use the mailing list.

You can write your own pinentry script instead of the loopback thing. The use the envvar PINENTRY-USER_DATA to communicate with the pinentry.

I'm still sad that you don't acknowledge the problem I am describing. It seems that you are writing your software for the kind of user who reads all your documentation first. That kind of user does not exist.

The option has been removed form the repo more than 11 years ago and the gnupg with this changes (2.1.0) was released 7 years ago including an extensive writeup on all the major changes including notices that the secret keys will be converted and moved.

Okay, I close this as a keyserver infrastructure problem. Feel free tore-open if you get other infos.

Fixed in 2.3.2.

At first I've had simply tried to give multiple --symmetric options (which of course didn't work).

I have no clear idea on how to style the UI for this feature. Technically it is simple but we need top query several passphrases. loopback mode with a list of passphrases might be easiest way to do that.

Yeah, that sounds good to me.

In T5551#148510, @werner wrote:

I would prefer to see a fix/hack in pinentry-qt instead.

I see. Thanks!

To minimize the risk of regressions.

Not to be bothersome, but why? DISPLAY seems like the universal method of selecting a display to put things on, where a lot of applications don't support --display or equivalent, especially now there's no equivalent for wayland. It's especially confusing to me when the keep-display option will pass DISPLAY instead of --display. This would also prevent other such scenarios with 3rd party qt/gtk plugins or alternative pinentry implementations.

I would prefer to see a fix/hack in pinentry-qt instead.

Proposed patch:

--- gnupg-2.2.27.orig/agent/call-pinentry.c
+++ gnupg-2.2.27/agent/call-pinentry.c
@@ -202,13 +202,14 @@

I propose the following patch to inform the user about the obsolete --secret-keyring option. The same is done for many other obsolete options.

This is very saddening and alarming from a respected member of the community whose opinion matters.

You should have read the release notes of 2.1 (first point). We can't keep a bug open because you had a wrong understanding of GnuPG properties. Sorry.

Sorry, I don't understand what you are trying to say, so let me give you some more detail.

Everything in ~/.gnupg is and has always been private to gnupg unless explicitly stated otherwise.

For many years I was convinced that my secret keys are stored in an encrypted folder. The .keyring file was there, everything looked correct...

Forgot to mention one thing: after changing my user folder directory I lost all my Outlook contacts. I was able to recover them... make sure you have a backup before attempting this!

I just had the same issue as hurui200320. My user name contains a "ç" and Kleopatra did not start. The Windows event logger reported a crash in libstdc++-6.dll. This was with gpg4win-3.1.16. Installing gnupg 2.3.1 did not change anything.

In agent_write_private_key of agent/findkey.c, when file is available, it returns GPG_ERR_EEXIST error. Thus, private (stub) key will be kept.

Do I correctly understand that issue will be resolved on GnuPG side by tweaking key bits before private-key import/and/or/operations?

We should not support a different OID or representation of 22519 which will only lead to incompatibilities and trouble existing users. 25519 is in too widespread use than to allow for any changes.

Thanks werner. That helps us to know that such test failure is not a deep issue that would push us to not deliver this version of gnupg on AIX.

With the next release you will get only a warning:

gnupg-2.2/common/t-sexputil.c:467: test 0 failed: Unknown elliptic curve - ignored
This is likely due to a patched version of Libgcrypt with removed support for Brainpool curves

The sks pool is now officially gone.

Sorry for the expired certificate.

Fix: "I Know so few about gnupg, thus I'm not sure I COULD add test cases, probably not. "

Hi,
The site now shows: "NET::ERR_CERT_DATE_INVALID" and I have a limited access to the web page.
Thanks for you explanation. However, I now so few about gnupg, thus I'm not sure I cannot add test cases, probably not. I'll see later if we have to provide on AIX a behavior different than the one of RedHat. Meanwhile, about your last proposal, yes it would be very useful to detect the case, print a warning, and skip the test. That would be helpful. Moreover, if the test deals with smartcards, we do not have on AIX, thus this test is very probably not useful in our environment.

The thing is that I added a test for a new function which uses standard curves of Libgcrypt. But here we are again at the RedHat mess: They support the NIST curves but they removed support for Brainpool curves. Both are very similiar curves just different parameters. Brainpool is just in Europe out of fear that the NIST curves are rigged by the the NSA. Now, why RedHat removed Brainpool is probably just a legal dept thing who didn't have a clue. The tin foil hats probably see a different reason.

• a patch change within scd/apdu.c dealing with a call of: pcsc_connect() since code has changed between the 2 versions: may this be the cause of the failure? (Edited: hummm this patch seems no more required. And I have the same failure without it).

Hi Werner,

Supported curves should be listed by

gpg --list-config --with-colons curve

I am not sure about Fedora, but RedHat used to remove ECC support from Libgcrypt; GnuPG requires these curves. As long as you don't use ECC you things will work despite of this failed test. The test is new to check and does not anticipate a broken Libgcrypt.

Thank you.

Hi, I updated the whole file, PLZ review. https://dev.gnupg.org/D533

Thank you for your suggestion and making a patch.

Sorry, I think, it is more official to update from 把密钥导出到一个公钥服务器上 to 将密钥导出到一个公钥服务器上 in the Chinese doc scenario. 😄😄😄😄

Thank you Werner for fixing this! We just came across the group permission issue in a multi-user environment and all we had to do was to upgrade to gnupg >=2.2.24.

Pushed the change.

Considering the history of the translation, I concluded that it should be:
把密钥导出到一个公钥服务器上
(the typo was G-A where B-A was expected.)

@guzhongren
This is not GitHub, so, if you want, you need to learn how to submit your change in the form of patch, by using git.

Clone and checkout the branch as usual with Git. There is no web editor etc like you might know from github. For your request we need to wait for someone to check your request.

Now also fixed for 2.2.28

Better don't backport this.

Fixed.
I'm not sure if it's worth backporting this to 2.2.

I encountered this bug last year, but I realized that it's hard to make a reproducible case.

In your log, it says:

usb_claim_interface failed: -3

Sorry, I was wrong.

I need to see how we can pass the check permission notice up to gpg. This is a too common problem and thus serves some special treatment.

GPG Version :

In T5442#146871, @gniibe wrote:

I see your situation

Could you please help me to analyze what's going on?
Please add following lines to your scdaemon.conf to see CCID driver's debug output:

debug-ccid-driver
verbose
verbose
verbose

And share the debug output.

Ah, I think that your problem was fixed in rG53bdc6288f9b: scd: Recover the partial match for PORTSTR for PC/SC. (to be 2.3.2).

I see your situation

In T5442#146869, @gniibe wrote:

If possible, please let us know how you configure the permission to access CCID device with 2.2 (and with 2.3)?

If possible, please let us know how you configure the permission to access CCID device with 2.2 (and with 2.3)?

Hi Werner, I need this for a potentional customer. And generally I need this in config, too. because in support we have to send customers configuration files which they do not need to edit and variables are important because of file system permissions. But most immedialtely I need this for homedir registry.

jitterentropy is also used in Linux kernel, and some people use clang to build it these days. So, I checked the kernel's one. It is simply compiled -O0 by Makefile, and there's no pragma line now (as of v5.13).

I don't think that it is a good idea to silence this warning. The pragma is esssential for proper random numbers and if clang hijacks a GCC's name space but implements something different it is better to have a warning than to fall into the pit full of dragons.

In T5369#144864, @jukivili wrote:

That warning could be silenced by surrounding pragma with #ifdef __OPTIMIZE__ (with should be supported by GCC and Clang).

I test on ppc64 machine (POWER9, big endian).

Could make --multifile work on windows 10, documenting the workaround here.

This is another test case for GNU C library's strncmp:

This is the minimized test case.

Thanks for the well written report. We had another already, and thus I merged it into T5415.