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 ?

Given that we have reduced the number of operations to at most 2 (down from unlimited), and it is unclear if and how to proceed on this, I am closing here.

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

FWIW, OpenPGP's S2K and PKCS's PBKDF2 are very similar and don't make a difference except that we have calibration code for S2K in gpg-agent.

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

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

Thanks, fixed in 7b045f539e5f67c937c18157c26fb3a767c1c7e6

In T3243#99605, @jcross wrote:

Hi @420Dreamin - you just "fixed" the typo I was trying to demonstrate :/

Sorry man. I didn't realize wht I was doing.

Hi @420Dreamin - you just "fixed" the typo I was trying to demonstrate :/

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.

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

Digicert TERENAPersonalCA3 doesn't use issuingDistributionPoint anymore. It's hard to survey CRLs that are actually in use, so I don't know if there are other important users, but the fact that nobody else reported such problems is an indication that it is not widely used among dirmngr users. Supporting this is a lot of work, because it makes validating certificates much more complicated, so this is unlikely to happen without strong motivation, so I am closing this 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.

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.

Most people should use a graphical user interface, and the console gui for key generation doesn't ask too many questions, while the key editor allows to go "back". So I am closing this suggestion.

Seems to work fine on Solaris 11.3 and gcc 4.8.

Still no better message with gpg 2.1.21:

Maybe this can be done by Neal along with the book?

The change werner mentioned previously is eaba8d58acda66f428870794115cb22c2590ec5e, but this is based on Elgamal. RFC4880 since then specified S2K, and better approaches are available, too (at least PBKDF2 is in libgcrypt). These could be used with HKDF for RSA and other asymmetric key generation methods.

Fixed in 1209ea4e07b50d5cc4f9ffe6aef970ed3572fff0

gnupg 1.4 is phased out and only receives important updates.

Oh, my bad. Someone on IRC said it was a bug and I didn't look at any further details.

No, that is the convention used by gpgconf. See https://gnupg.org/documentation/manuals/gnupg/Format-conventions.html#Format-conventions:

Fixed. Thanks.

I'm going to close this task now. If we need more options to be configurable, it is easy to open another task for them.

It fails the very same way:

I agree with @dkg, and something should be done to address this one way or another. It is pretty misleading.

fwiw, i also find this password quality indicator rather dubious.

Fixed in 273964798592cd479c111f47e8ce46d5b1999d6a.

I can't remember either. We should swicth back to mailing lists for such things.

Any updates / thoughts on how this might be fixed?

ping

Well, can you then please fix it?

Any update on this?

We now have a GPGME feature to list packets:

Solution has been given: Use "gpg.conf-1" for gpg 1.4

I don't know if this ever landed. If not, please reopen. We now have a bug tracker that can do nice patch management, too :)

@werner Can we close this here?

Thanks for the fast response!

we don't use GPG4Win anymore ... so, honestly I don't know - if you want I can verify that. Or you simply close the topic ...

• marcus (Marcus Brinkmann) <noreply@dev.gnupg.org> [20170622 16:41]:

So, the default change 7y ago and the world didn't end. Closing this.

@werner What's the status here?

Is this still an issue?

So, the default change 7y ago and the world didn't end. Closing this.

@werner do you have any updates on this?

By the way, when terminating pinentry with "kill -TERM ...", it shuts down correctly, while CTRL-C show "gpg: signal Interrupt caught ... exiting" and a corrupt screen layout that is reset when pressing RETURN, further confirming the above diagnosis.

The problem seems to be that the CTRL-C is sent to gpg, terminating it, but pinentry keeps running and interfers with the terminal. With "ps -j" we can verify that pinentry runs in the process group and session of gpg-agent, while gpg runs in its own process group within the shell session. So, the signal rightly goes to gpg.

We can do this with estream now.

Hello. Please note that this is a bug tracker and not a support forum. Nevertheless, let's investigate.

GnuPG needs to report compliance when decrypting symmetrically encrypted packet.

I released libgcrypt 1.7.7
and nPth 1.6

libgcrypt secmem fix is not that in hurry, I think. nPTh bug for macOS sounds more severe.

So, should we do a new libgcrypt release RSN?
There is another bug with solution also pending and it might not be too late for Squeeze if we hurry.

Implemented in gpg, gpgsm, and gpgme with all bindings.

I managed to replicate this issue by preparing artificial nPth on x86 GNU/Linux.

@gniibe , I was happily running scdaemon 2.1.21-beta73 for more than a month and it properly relinquished the card every time. However, a few days ago it got hold of the card and would not let go (or at least, other users of the card got "sharing violation" error from pcscd). I collected some debugging information: