In T6161#162306, @ikloecker wrote:

I'm not sure I understand. If you don't want pinentries depending on libX11, then simply disable those pinentries with --disable-pinentry-qt5, etc. For Wayland it may make sense to allow disabling it.

I'm not sure I understand. If you don't want pinentries depending on libX11, then simply disable those pinentries with --disable-pinentry-qt5, etc. For Wayland it may make sense to allow disabling it.

Let's turn this into a feature request.

I pushed the change with documentation.

The PKCS#12 import was a late add-on because I consider P#12 to be a nasty and insecure format. Unfortunately it survived and is now the mainly used interchange format. Eventually we need to improve things here. However, ppl should use smartcards for S/MIME.

Thank you for your work on the proposal. I have two comments:

• Do we have some test vector, which can be used in the testsute to test the new API?
• We need to mention the new API in the documentation.

I tested with a self-signed one.

Did you test with a self-signed cert? I ran into the problem that the selection only showed the root certificate, the signing works using the leaf cert, but the root cert was put into the signature. Changing Scute to only return the leaf certificate made it work but verification failed.

I can successfully sign with LibreOffice Writer (using Brainpool with Yubikey). I need to do:

• Tools
  • Optoins
    • LibreOffice - Security - Certificate Path
      • Select the profile of "firefox:default-esr" for NSS certificate directory

Probably, PIPE_REJECT_REMOTE_CLIENTS mode and lpSecurityAttributes=NULL is OK.

Experimental branches:
https://dev.gnupg.org/source/libgcrypt/history/t4873/
https://dev.gnupg.org/source/ntbtls/history/t4873/

Any progress on this?

While playing with your scripts I figured that it would be useful to enhance the KEYINFO command. With
rG989eae648c8f3d2196517e8fc9cce247b21f9629 we could now

The option to flag a user ID as the primary user ID is now available in the Certificate Details dialog as button below the user ID table and as context menu entry of the user ID table.

Firefox nicely shows the 3 NIST certificates from my Telesec card but not the important Brainpool certificate for eIDAS. It turns out that Firefox does not support Brainpool, despite that a patch has been provided 8 years ago. See https://bugzilla.mozilla.org/show_bug.cgi?id=943639 . Thus there is currently no way to use LibreOffice or Okular to signe PDFs because they rely on NSS.

Agreed

I think this was mostly covered with T5362: Kleopatra: Add warning in compliance mode if gnupg version is not compliant and T5653: de-vs and GnuPG 2.3.3 error.

Has this been implemented?

Probably, PIPE_REJECT_REMOTE_CLIENTS mode and lpSecurityAttributes=NULL is OK.

Here is the parser output:

$ python3 sd.py --type=pipe "D:P(A;;GA;;;SY)(A;;GA;;;BA)(A;;0x12019b;;;AU)"
D:P(A;;GA;;;SY)(A;;GA;;;BA)(A;;0x12019b;;;AU)
    Discretionary ACL: P(A;;GA;;;SY)(A;;GA;;;BA)(A;;0x12019b;;;AU)
        Flags: P: SE_DACL_PROTECTED (Blocks inheritance of parent's ACEs)

I think that the last argument of CreateNamedPipeA can limit the access to the named pipe.

Here is a patch to implement the functionality with --enable-win32-openssh-support.

This is related to T5950: Allow viewing expired certificates more easily where a user was wondering why some key wasn't offered as encryption key. It turned out that the encryption subkey was expired.

Backported for for 2.2.37

For documentation purposes: Werner suggested to use a TCP socket on Windows for logging (on the mailing list).

@ikloecker KWatchGnuPG does not work on Windows. And this also does not work with Kleopatra logging and GPGME logging, Kleopatra logging needs Dbgview on Windows, which can be spammed by other software and GPGME logging requires an enviornment variable. So having this in a logging view would be good for support.

In T4449#124252, @aheinecke wrote:

Or you can write it directly to the config in %APPDATA%/gpg-agent.conf

Reading through the report, the spec., and current implementation, I concluded that this is not a bug, thus, I'm closing this.

Please use the feature in 2.3.7 of T5099, instead.

It's in 2.3.7.

It's in 2.3.7.

It's in 2.3.7.

It's in 2.3.7.

It's in 2.3.7.

It's in 2.3.7.

We have KWatchGnuPG for watching the log files.

Due to vacation the review may take some time.

Any chance someone is able to review the posted patch?

Let me know how best to submit it

I tried to submit the below patch to gnupg-devel@lists.gnupg.org, but get an Unrouteable address error. Let me know how best to submit it

I'll prioritize this as Wishlist because the options in the "GnuPG System" tab come directly from gpgconf and they are meant to be used by experts (who read man gpg, etc.) and maybe for users who are instructed by an IT administrator to enter some value for some option (so that those users do not need to edit some configuration file).

Kleopatra uses SCD READCERT for reading certificates from the PIV app. This is used to import the certificates stored by the PIV app. I'm not sure whether this is really needed. Maybe we could/should use "learn card" for this instead.

Yes, only settings from the "GnuPG System" tab are involved

We could change how device keys are listed. Currently, Scute does KEYINFO --list, then asking gpgsm for each certificate.

The change requires "KEYINFO --list" command. This is not available through remote access of gpg-agent (extra socket).

The first ideas sounds best to me. Patches please to the mailing list.

Is this only about options shown on the "GnuPG System" tab?

FIPS 140-3 (https://csrc.nist.gov/Projects/cryptographic-module-validation-program/fips-140-3-standards) points to SP 800-140Dr1 (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-140Dr1.pdf) to list acceptable "Security Parameter Generation and Establishment Methods". From this document, RFC 5869 (i.e., HKDF with the counter at the end) can be reached via two paths:

We removed assuming "OPENPGP.3" means for ssh.

In T6040#159431, @Valodim wrote:

I suppose you're right, we might have crossed that bridge a while ago. Simple availability of certificate- or even signature-specific keyserver URIs just make the risks of honor-keyserver-url more obvious than before.

I suppose you're right, we might have crossed that bridge a while ago. Simple availability of certificate- or even signature-specific keyserver URIs just make the risks of honor-keyserver-url more obvious than before.

In T6040#159428, @Valodim wrote:

This is a reasonable feature, however it should be noted that this implies a fairly large metadata leak: You are essentially adding a URI to signatures that will be pinged on signature verification.

This is a reasonable feature, however it should be noted that this implies a fairly large metadata leak: You are essentially adding a URI to signatures that will be pinged on signature verification.

I don't see why this is a child task of T6020: the features are similar, but they don't actually impact each other in any way.

What about rejected changes to "Key:"?

What about rejected changes to "Key:"? Other this command would make it too easy to mess up the actual private key.