Simply sending "KILLSCD" is implemented.

There is also a confusing case: a subkey expiration date is set, but the associated primary key is expired.
Pushing a fix in master.

Actually I have a different approach to fix this bug(let). Please give me a few days.

Yes, very exactly indeed: It's GPgOL within gpg4win-3.1.1... ;) But you're right, the key itself is a legacy key, created back in 2001 with a commercial PGP Solution and later on the key was "spiced up" cipher-wise...Goal ist to get everybody (also the sender) to gpg4win-3.1.7, but how can I achive not having lots of eMails which one will never be able to decrypt?

@werner Thanks for merging the --dry-run patch in 110a4550179f !

Do you know which software the sender uses for encryption? That software may simply ignore the preferences or the sender also encrypts to a legacy key using a software which does not force the use of an MDC. Sometimes keys are generated with gpg but used with other software - without updating the preferences of the keys.

I don't see why the documentation needs to be fixed. gcry_sexp_canon_len returns 0 for certain and s-expressions, meaning tha the s-expression is not valid. After all the s-expression code in libgcrypt does not claim to be a general purpose parser for s-expression but is targeted towards Libgcrypt needs.

By marking this as "wontfix", you appear to be saying that you won't even fix the documentation to describe the constraints that gcrypt intends to enforce. This is surprising to me.

Thanks. Fixed in master and 2.2.

In master, I pushed a change, closing.

For future, it would make sense applying your patch, but I wonder if it works on macOS.
Let me check.

I spent a lot of time trying to figure out how to automate the interface between my preferred password store (gnome-keyring, via libsecret), but with the loopback pinentry mode changes in gpg 2.1, it is much harder (if not impossible) to do. Having passphrase caching is the only thing preventing me from choosing a weaker passphrase on my gpg keyring.

Disallowing passphrase caching is likely to have the unintended consequence of users choosing weaker passphrases that are more easily memorized and/or typed. Caching should be permitted, IMO. This puts more decisions about passphrase management into the control of the user.

And yet, that interface is already being used by the agent-transfer utility in monkeysphere. The interface exists, it is not marked in any way as unusable or deprecated or off-limits, so it is used.

Closing this as the moving problem was fixed.

That is on purpose. Exporting of a secret key should in theory not be possible at all via gpg. In practice we need a way to export a key, but that should be the exception and thus we do not want any caches for passphrases to have an effect.

trigger what command? i'm pretty sure gpgconf --reload gpg-agent does not trigger updatestartuptty. And it should not do so, afaict -- if you think it should, i'd be interested in hearing the rationale for it.

When having a backup media, I'd recommend completely different one (for example, on paper using paperkey to be stored in a locker in basement), which requires different method for recovering. Brains may be easily confused when same private key material exists in multiple similar devices.

Does gpgconf --reload gpg-agent trigger that command? that's the ExecReload setting in the systemd service unit I'm looking at.

Thanks for this @gniibe. I have long been frustrated by trying to save the correct "stubs" to have my keyring point at two different smartcards. It was common and even advocated in my former community to place one's master key on a separate smartcard (certify capability), with a different one designated for daily usage.

Thanks Gniibe San for explanation.

This doesn't sound systemd-specific to me, fwiw, though i don't understand how to reproduce the problem from the given description here.

Fix will go into 2.2.16 to be release this month.

There will be no full solution for this. However, the next release should in general work due to a 400ms delay we use after spawning the viewer. This is configurable; see rG7e5847da0f3d715cb59d05adcd9107b460b6411b.

I agree with @dkg here.

@blades: This feature will be available in GnuPG 2.3, which is planed to be released this year.
For Debian, Buster will come with GnuPG 2.2.12. After release of GnuPG 2.3, backport might be available (like GnuPG 2.2.x is available as backport for Stretch).

"requires too much changes" i can understand.

Actually the temp file is created but because the photo viewer is run as a detached process and gpg keeps on running, the temp file has been removed by gpg at the time the photo viewer tries to open it. Ooops. The correct behaviour would be to wait for the photo viewer to be finished. We use

The problem could be narrowed as follows: According to Mailvelope Add-on, GnuPG must be installed for smart card support. Screenshots show that GnuPG is not recognized by Mailvelope. Of course actual versions off all programs were installed. Therefore, e-mails sent out ecrypted with public key work fine, because the public key is stored in Mailvelope. Is the encrypted message arrives and should be decrypted. Mailvelope does not find GnuPG and therefore, no private key. I´ll send some screenshots to you.

Smartcard support is a big advantage of using the GnuPG backend and it should work of course.

This requires too much changes and does not reflect the reality. It actually makes debugging harder for us.

Helo and forgive me for the ignorance, Iam a new.
I subscribed to this topic because I need a fix like that, I have 2 yubikeys with same subkeys...
Now how is possible to install from master; It's about a debian based distro. Also, when this will be pushed for updates via apt-get;
Thank you.

I patched version 1.13.0 with that commit and installed the patched version on Monday. It appears to have fixed the problem.

It's complicated to have a good solution, because we need to change assumption (serial number identifies keys).

Right, that was missing. Fixed for master and 2.2. Noet that for kill and reload we added this already in 2016.

While I think that building with GCC 4 on Solaris 11/12 is minor issue, requirement of newer POSIX API (on GNU/Linux) would be a bit serious issue.
I pushed my change to fix this.

I think you are saying that dirmngr receives the query term as escaped data in the assuan connection from the dirmngr client (typically, gpg, which itself decides how to percent-escape what it feeds into libassuan).

Oh, ah. Ok. I do not read c't no more since about 2005. They are busy people and lead into the right direction.

There is actually a problem with --use-embedded-filename. Given that the option his highly dangerous to use we have not tested this for ages. We will see what you we can about it.

Good catch. Thanks for that work. I'll apply it to master and 2.2.

Yes, that term is overloaded. The reason in this case is that we once replaced "trusted key" by "valid key". That term "valid" now conflicts with another older use of valid. Using "self-signed" here seems to be more confusing that just removing the (first) "valid".

This is easy to explain: dirmngr receives already escaped data and that is what you see in the log. For proper parsing of the URI the escaping needs to be removed and only before sending the request the required escaping is applied. '@', '<', and '>' do not need to be escaped and thus you see them as they are.

I removed this specialized error message. Thanks for reporting.

While original npth-1.6 can be compiled with newer gcc (>= 5), we'd say please use CFLAGS+=-std=gnu99 with older gcc, as workaround.

I figured out:

• Removing -D_POSIX_C_SOURCE=200112L works both of gcc 4.9 and gcc 5.5 on Solaris 11.3 (even with -std=c99).
• Then, adding -D_XOPEN_SOURCE=500, gcc 4.9 works, but gcc 5.5 failed by another error (Compiler or options invalid for pre-UNIX 03 X/Open applications and pre-2001 POSIX applications)
  • I confirmed gcc 5.5 defaults to -std=gnu99

I think you'll be better off doing this with the simpler --quick-generate-key and --quick-add-key interfaces, rather than hacking on the domain-specific language used by --batch --generate-key.

Thanks for your offer. I have an account for GCC Compiler Farm. I'm trying with gcc211 machine. will back soon.

In case of gcc 4.8 on Solaris, could you please try this patch (instead of configure patch) to see if it works?

It looks like somewhat complicated more. It seems that specifying _POSIX_C_SOURCE=200112L is not good on Solaris with old GCC. Perhaps, it would have no problem with newer gcc (or -std=gnu99 option).

I think this patch should be backported to STABLE-BRANCH-2-2

I can confirm that this fix repairs the problem on debian's s390x.

I've just pushed e4a158faacd67e15e87183fb48e8bd0cc70f90a8 to branch dkg/fix-T4501 as a proposed fix for this specific problem (it doesn't introduce anything in the test suite, or try to deal with any of the other %b problems).

OK, i think the reason this is happening is that agent_public_key_from_file (in agent/findkey.c) is screwing up a %b format string in gcry_sexp_build_array.

IIUC, -std=c99 won't solve this issue. It is Solaris specific C99 issue.

Ok, the difference appears to be that on these 64-bit big-endian platforms, they're returning a zero-byte string for the associated comment. When this happens, gcry_sexp_canon_len returns 0 because of GPG_ERR_SEXP_ZERO_PREFIX. The same thing happens on x86_64 platforms when confronted with such an s-expression.

It looks to me like gcry_sexp_canon_len is returning 0 on these platforms from within a backtrace like this:

This is known and by design, basically it is a legacy X feature. For Wayland, the window manager determines if a window should be blocking, no grab or grab, not anything applications themselves have control over. This came up many times when I was first making the interfaces. You can reference these two comments, but there are many more in between them.

Validity values are also displayed for all user IDs.
[…]

show-uid-validity
       Display  the  calculated  validity of user IDs during key
       listings.  Defaults to yes.

[…]

Trust values are used to indicate ownertrust and validity of  keys  and
user IDs.  They are displayed with letters or strings:

[…]

revoked
       For validity only: the key or the user ID has been revoked.