I renamed the task accoringly.

Oh These are good points

This is not the first time I saw that users are confused by this. My wish would be to change the label of the Group at least to "S/MIME (X509) Directory Services"

@ebo Is this fixed now?

Is the lack of display of entries in the listbox proper functionality?

In T6946#181608, @werner wrote:

The min-rsa option was introduced due because the de-vs compliance allowed 2048 bit until the end of 2023 and we used a trick in our configuration file to switch that relaxed handling off with this year. I don't think that the --ciompliance option is really useful becuase it would also disallow ed25519.

A better option would be an --assert-algo option similar to the --assert-signer which we already have in gpg.

But thanks for reporting! I really like feature requests so please do not feel discouraged to request more features.

Sorry, but this is a "Wontfix" we do not support this by choice. We think that adding photos to certificates both gives a wrong sense like "I know that picture, iit must be this person" and also increases the sizes of the certificates a lot. It is in our opinion a misfeature in the OpnePGP specificationl.

Under "X.509 Directory Services" you can add "key servers" for X.509 certificates (aka CMS certificates, vulgo S/MIME certificates). For OpenPGP only a single OpenPGP server can be entered. The suggestion is the Ubuntu key server because it is/was one of very few reliable key servers.

I noticed the Debian bug and was about to answer but a feature request is also a good thing.

I'm putting this back to triage because I cannot act on this ticket. There's way too much text and the outcome what should be done is unclear. Either rewrite the description so that it tells the reader concisely what should be changed and how it should be changed. Or, maybe better, create a new ticket referring to the discussion in this ticket and close this ticket.

I don't understand what your comments about the (missing) success window mean. The screenshot that you added to this task is the success window reporting "The key was copied to the card.". It even has the title "Success". As far as I can tell this window is exactly what you describe with

Would it be possible to move the success window to the start? Ideally combine it with the window asking what should be done with the key on disk. Then "copied" would be correct, as the original still exists and we do not need additional code paths for the other combinations.

In T6708#181592, @werner wrote:

I would also suggest that we show the git last git commit in Kleo's About dialog. That makes it far easier to see what we are testing. The Kleo version numbers are a bit arbitrary.

The problem mentioned in T6095#173465 no longer occurs with the changes made for T6662: Kleopatra: improve useability of group configuration , neither if the Help button is shown nor if the Help button isn't shown.

Regarding T6662#174484, this was already implemented this way. Of course, it still works this way.

I would also suggest that we show the git last git commit in Kleo's About dialog. That makes it far easier to see what we are testing. The Kleo version numbers are a bit arbitrary.

Sorry, it was my fault building the test installer.

To be clear: This ticket is only about GnuPG (more precisely dirmngr) and the changes are included in VSD and Gpg4win.

Hi, ebo I would still think this is resolved. Because it was never meant that the user manually enters the value of "none" because there is no hint for the user that "none" is a reserved word. It should either be administratively configured which does not make much sense for Gpg4win or provided by the distribution. If left empty the default of GnuPG should be used. If we really want users to deactivate keyserver access by using "none" in the dirmngr.conf a much better solution would be a checkbox for this. In that case I would open a new issue.

The fix was not included in the Testbuid...

Does not work in Gpg4win-4.2.1-beta178

works in Gpg4win-4.2.1-beta178
Note to self: need to check with "to the second" expiry time, in case this only occurs with summertime

works in Gpg4win-4.2.1-beta178

For what it's worth when I filed the Debian bug I mistakenly believed min-rsa-key-length in gpg would do that but it only applies to de-vs compliance profile and is *silently* ignored otherwise.

We tested with Kleopatra:

• Only gpg4win 4.2 is affected (the current version) but 4.1 is not affected.
• No vsd version is affected.

FWIW, I am already working on this.

Currently, there is no support for gpg-agent to keep private key not on disk, but only on memory of gpg-agent. Given the situation,
I think that it is good to:

Regading Kyber in GnuPG, there are a couple of open questions. For example whether the implicit lengths used for the key parameters match well with the overall protocol structure. Thus, as soon as we have finished the Libgcrypt part we will address this and implement it in some way. Before we do this we have to do a couple of changes to GnuPG required for FIPS compliance.

Example output:

I just saw that Niibe is already working on the integration of the ML-KEM code into the master branch of libgcrypt. Apparently, this is an entirely new code base. Currently we are working on the integration of our ML-KEM implementation in libgcrypt into GnuPG. But based on what I see now it seems that apparently another approach is planned and already underway for libgcrypt and probably later also for GnuPG. It would be helpful if you could give us a pointer what your exact plans are, this makes it easier for us to direct our efforts in the optimal way.

Fall back to distutils for old Pythons: setuptools for Python 2.7 does not have setuptools.command.build.build

In D545#6037, @ikloecker wrote:

But there *is* a setup.py in lang/python, The .in file is even part of the patch

No, there isn't. There is a setup.py in the build folder, but not in the src folder. I suppose the problem doesn't show on build.opensuse.org because they do in-source builds.

Remove the changes for m4/ax_python_devel.m4 serial 36 commit to master in the meantime.

The patch didn't make the necessary change to configure.ac which makes a missing Python a non-fatal warning instead of an error.