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.

I pushed the change needed for GnuPG to t5964 branch.
See: https://dev.gnupg.org/rGc281bd94349e4f7997a89927aaa2c2f45004b902

Added HKDF implementation to master.

I found this page:
https://firefox-source-docs.mozilla.org/security/nss/legacy/nss_tech_notes/nss_tech_note2/index.html

In the branch https://dev.gnupg.org/source/Scute/history/t6002/ , by the commit rS123d617ebefe: Less administration of devices by scute., things has been changed.

As Werner wrote, this is already possible. The next time please consult the extensive documentation of gpgme before opening a ticket.

Hmm, why not use:

gpgme_op_sign (ctx, in, out GPGME_SIG_MODE_CLEAR)

I realized that we need to invent a way to represent KEYGRIP (40-byte string) in the scheme of PKCS#11; PKCS#11 uses fixed-size string (space padded) for it's label (32) and serialno (16). Basically, it identifies the device by slot number.

Patch applied to master with small changes.

gpg-agent --supervised being deprecated is highly surprising, especially because it works so well with systemd.

The --supervised option of GnuPG is deprecated and thus it does not make sense to add this to keyboxd or even sdaemon (which is a helper to gpg-agent).

Now, it also supports a reader with pinpad.

A use case for this is to allow the use of S/MIME for de-vs mode and for standard mode while clearly indicating compliant certificates. As of now all certificates matching compliant algorithms are indicated as compliant. The new flag could be used to distinguish between them.

The suffix .kgrp has been added as default filter for the import with revision rKLEOPATRA5c4d3a80d5a9: Allow the export of certificate groups.

I can only find this one: https://github.com/patrickfav/singlestep-kdf/wiki/NIST-SP-800-56C-Rev1:-Non-Official-Test-Vectors

Updated (with T6012):

Thanks @jukivili , Here is the changelog,

Thanks for updated patch. I'm travelling next week and have time to check it closely only after I'm back. On quick glance, it looks good. What is also needed is the changelog for git commit log.

nice, that's great news! I'll have to try it out when I get a chance.

See https://github.com/google/xsecurelock/blob/master/helpers/authproto.h
for the interaction between xsecurelock and the helper.

I changed gpg-connect-agent (added --unbuffered option) so that we can write shell script interacting gpg-agent.

Wrote a shell script for xsecurelock's authproto (helper executable):