The problem itself is fixed (in T4495: UBsan finding "certdump.c:695:3: runtime error: null pointer passed as argument 2"). The variable buffer cannot be NULL at memcpy.

@sarman: Your question is actually a support question and not a bug report. Please read the documentation, use the public help channels (so that other can also learn from the issue), or get in touch with a commercial support provider.

I think that what you want is adding --batch option. In the gpg manual, we have:

--passphrase-file file
       Read  the passphrase from file file. Only the first line will be
       read from  file  file.  This  can  only  be  used  if  only  one
       passphrase is supplied. Obviously, a passphrase stored in a file
       is of questionable security if other users can read  this  file.
       Don't use this option if you can avoid it.

Hello Team,

For operations which require private key, it is needed to unlock private key.

I think that this chnage is useful enough to be backported to 2.2. Done that.

You can test it now out using GnuPG master: Just add --include-key-block and you can then verify using an empty keyring. Currently --auto-key-retrieve is not needed but we need to think on how we can enable or disable this during verification.

ftr, here is the thread I had in mind but couldn't recall above. @aheinecke is that your thinking, or a more pgp/mime bound mechanism as @dkg assumed?

"log" and "lock" are easy typo/confusions to make, @aheinecke was just trying to understand your report better, since there wasn't much information in it.

@wiktor-k, "just extend the spec" doesn't necessarily work with existing clients, which might be surprised to find unexpected packets in the signature section of an e-mail. It seems more likely to me that they'd be able to handle (meaning: ignore) an unknown subpacket (as long as it's well-formed) than to handle additional packets. But all of these surmises require testing with existing clients, of course. Has anyone done any of that testing?

At no point did I mention log files ? So not sure where that is coming from.

apologies but I do not understand this issue. Please clarify. Were you having issues with "log" files or "lock" files?
What was your issue?

This is a nice idea and although it overlaps with Autocrypt it has other uses too: for example verification of signed files that can be vastly simplified (just get the file and the signature, no key fetching needed, downside: the key attached to the signature could be stale).

Ah, thanks for pointing out the subpacket option (i guess it could be hashed or unhashed). i don't think any of the subpackets currently defined in RFC4880 supports this use case -- but i guess you could mint a new one, or use a notation.

Werner said that it's possible in OpenPGP to also put the pubkey into the signature. (...) The nice advantage is that this will also work for files.

I'm using enigmail 1.9.9 because I'm on a mail client that doesn't use WebExtensions, so it's using gnupg for keyserver stuff. In this case that means I've been able to verify it's a gnupg issue (both Kleopatra and enigmail displaying the same issue as CLI).

Hi @aheinecke, thanks for thinking about this, and thanks for tagging me here too. I'm definitely interested.

This is an important fix for a sensible S/MIME use case. Thanks for working on it!

@Moonchild wrote:

using enigmail with the new version

Just registered to report pretty much the same.
I've been using gpg 2 for a long while and it's been doing just fine, up to the point where people started using keys it didn't recognise that require a later version.

I t could print a warning for a non-existant homedir

Sure, I personally know that GnuPG requires a homedir to operate.

As you surely known GnuPG requires its home directory; in particular when using the gpgconf to manage the config options. Thus I can't see what to do other than error out. gpgconf needs to know the location of the config file; if it is containign diretcory is not existant it will fail anyway.

keyserver-URL needs to be replaced with with a keyserver URL, like

hkps://hkps.pool.sks-keyservers.net

In my particular case, I want to find out if an email address has a publickey associated to it that is publically available anywhere. I do not want to import the key automatically. I used to use this command:

--auto-key-retrieves tries to find a key when verifying a signature. --locate-key however does the same as what -r does and locates a key for further use. If you don't what that, don't include a key discovery mechanism in the the auto-key-locate like (wkd in this case, which is anyway the default).

Thanks for your info.

I will be using OpenPGP applet for the YubiKey NEO in a virtialized vanilla Debian environment. This emulated card can sign new keys just as correctly. PINs are the default 12345678 for admin and 123456 for user.

Or your card has the key to certify and its fingerprint is: CB522FE0379DDF40A93400D7E4BC91FACDA9A65B

Simply, we need the output of gpg --card-status to identify which key is on your card.

Nope, that's all I had. I'll try to get some debugging info in an hour.

Please show us your card information. Does it have unrelated signing key?

I'm pretty sure. That's the actual output above. Once again, if I remove the smart card, gpg --clearsign starts to just work, without a need to specify --default-key.

Are you sure that you have only one secret key? (run: gpg -K)

Wald certificate will be fixed very soon. But as it is not fixed yet, I provided an http link, not https for you.

Thomas, please provide a sample certificate. I can't access the intevation site to see whether one of the links has the cert. And pretty please fix the wald certificates!

Documentation for the regular expression of Jim Tcl: http://jim.tcl.tk/fossil/doc/trunk/Tcl_shipped.html#_jim_built_in_regular_expressions

Created gniibe/regexp branch.

RFC4880 (and older version of RFC2440) referes Henry Spenser's REGEXP. There are three implementations: https://garyhouston.github.io/regex/

Am I right as to this being due date?

That looks pretty much like another gawk regression. The easiest fix is to install another AWK version (e.g. mawk).

I think that this ticket and https://bugs.debian.org/346241 handle different things, although both do key selection.

This is also https://bugs.debian.org/346241

Implemented in master.

BTW, I just pushed some new features to maste for the gpg-card tool. You can now do

Yes that is fine with me.

Well that is due to "--debug packet" (aka --debug 1). We have this code

With new "KEYINFO" command of scdaemon, finally, we can move on to support better selection of signing key.
(Note: having a private key on multiple cards had already been solved in T4301: Handling multiple subkeys on two SmartCards.)

In master, it has been implemented.

The first "SCD SERIALNO" command let scdaemon re-scan smartcards/tokens.

With new "KEYINFO" command in scdaemon, a list of card keys can be retrieved by:

There is no use cases for $SIGNKEYID.

$ENCRKEYID use case have been removed.

$AUTHKEYID use cases have been removed.

I am wondering if there is any workaround or work in progress about this old ticket.
I understand this is kind of an edge case, but having the possibility to use signed ssh keys would be very useful to me.

FWIW, the second listed commit is the right one. You should only look at the STABLE-STABLE-2-2 branch. master and that branch differ; in particular we do not have a cut-off date in master (to be 2.3).

As a user I think that this capability would be a great addition to PGP and it might even make it a standard tool for key generation across cryptocurrencies.

The Name field in GnuPG needs to be at least 5 _bytes_ long. Given that UTF-8 is required for Hangul, a 3 _character_ name is at least 6 bytes long and thus passes gpg check. The Name field is also optional and the whole test can be skipped using --allow-freeform-uid.

Fixed in master and 2.2

Related task: About subkeys is T4028

Prio raised and assigned to werner as he asked for it.

Considering the concrete use case(s), it is more rational to support listing by capability.