Make the variable name more expressive.

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.

Fixed in rD1143a81c4691.

Should be fixed in 782f804765b6f4226fd77843e59f57dcca61b6fb, can you verify that? Thanks!

Thanks, fixed in 7b045f539e5f67c937c18157c26fb3a767c1c7e6

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.

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!

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.

The TOFU trust model gives some more information about certificate usage. Beyond that I don't think this is well defined to be actionable in the backend.

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

Thanks for letting us know, but there is nothing we can do about it, so I am closing it here.

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.

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.

I removed the man page and the link for now. Currently there doesn't seem to be an easy way to update it automatically.

PGP/MIME is supported since Gpg4win 2.3.

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.

I could not reproduce this on Solaris 11.3 amd64 and gcc 4.8, using CFLAGS="-m64 -O2". If you have more information how to reproduce this, please reopen.

Seems to work fine on Solaris 11.3 and gcc 4.8.

I added a new task status "Testing".

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 the PUBLIC_ARCHIVE_URL setting in mm_cfg.py. I have no idea why the other archive links worked.

Fixed in 1209ea4e07b50d5cc4f9ffe6aef970ed3572fff0

According to the linked discussion forum, this was a misconfiguration.

No response.

No response for years.

gnupg 1.4 is phased out and only receives important updates.

Fixed in b00cf0913243ad5432e4cb859146d88b6691f9a3.

Please reopen if this is still an issue with the latest version of gpg4win.

Please reopen if it can be reproduced with a recent version of gpg4win.

What tests do you want to be done?

Should be done now.

@werner An open ticket should mean there is something that can be acted upon. Unless you are saying that we should actively look for regressions or should actively do more testing, this ticket should be closed now. There is plenty of peripheral information that will remind us of this ticket in case more issues resurface related to this change.