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.

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.