dkg (Daniel Kahn Gillmor)
User

Projects

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Friday

  • Clear sailing ahead.

User Details

User Since
Mar 27 2017, 4:49 PM (86 w, 1 d)
Availability
Available

Recent Activity

Sun, Nov 18

dkg added a comment to T4251: gpg-zip embeds the build-time path for tar instead of finding it at runtime..

hm, adding: --with-tar=tar to my invocation of ./configure appears to leave gpg-zip with:

Sun, Nov 18, 7:52 PM · gnupg (gpg22), Bug Report

Wed, Nov 14

dkg created T4254: broken link to gpgrelay in website.
Wed, Nov 14, 7:02 PM · Bug Report
dkg added a comment to T4251: gpg-zip embeds the build-time path for tar instead of finding it at runtime..

i don't see any active use of it in all of debian: https://codesearch.debian.net/search?q=gpg-zip

Wed, Nov 14, 6:48 PM · gnupg (gpg22), Bug Report
dkg created T4251: gpg-zip embeds the build-time path for tar instead of finding it at runtime..
Wed, Nov 14, 7:23 AM · gnupg (gpg22), Bug Report

Thu, Nov 8

dkg added a comment to T3464: successful decryption with session key reports failure if public key is unknown.

I don't think this answered my question -- i'm asking how adding --no-keyring affects gpgme_op_decrypt_verify -- it seems like verification would fail if no keyring is used, no?

Thu, Nov 8, 8:59 AM · gnupg (gpg22), gpgme, Bug Report
dkg added a comment to T3464: successful decryption with session key reports failure if public key is unknown.

I'm fine with this change, but i do note that some people expect --decrypt to mean "decrypt and verify, if possible". In particular, gpg(1) says about --decrypt:

Thu, Nov 8, 6:44 AM · gnupg (gpg22), gpgme, Bug Report
dkg committed rM2557d0ae6ff0: spelling: fix misspellings (authored by dkg).
spelling: fix misspellings
Thu, Nov 8, 6:37 AM

Mon, Oct 29

dkg added a comment to T4235: GnuPG doesn't respect key flags when decrypting.

i agree with @Valodim that it would be better to not have a warning at all for an attempt to decrypt from secret key whose public key has never been marked as valid for encryption. A strict failure there (as with a strict failure for lack of mdc) is a better scenario than a warning. If the user controls the secret key and they decide they want to be able to decrypt with it, they should be able to mark it as decryption-capable (if that's really what they want) and retry. But this is an action only for experts.

Mon, Oct 29, 8:04 PM · Not A Bug, OpenPGP, gnupg
dkg added a comment to T4235: GnuPG doesn't respect key flags when decrypting.

I understand the real world requirement for decrypting messages that have been encrypted to a revoked or expired key.

Mon, Oct 29, 7:43 PM · Not A Bug, OpenPGP, gnupg

Thu, Oct 25

dkg committed rGa7c5d65eb503: all: fix more spelling errors (authored by dkg).
all: fix more spelling errors
Thu, Oct 25, 10:53 PM
dkg committed rGb39ece7d3540: headers: fix spelling (authored by dkg).
headers: fix spelling
Thu, Oct 25, 10:53 PM

Wed, Oct 24

dkg committed rG54eb375ff14e: all: fix spelling and typos (authored by dkg).
all: fix spelling and typos
Wed, Oct 24, 9:57 PM
dkg committed rGef540d1af064: doc: fix spelling mistakes (authored by dkg).
doc: fix spelling mistakes
Wed, Oct 24, 8:40 PM

Oct 19 2018

dkg added a comment to T3354: gpgme only builds against two versions of python at once.

@werner, thanks for rMff6ff616aea6 -- i've backported it to debian's packaging and it lets us cleanly build against all installed versions of python.

Oct 19 2018, 11:47 PM · Python, gpgme, Bug Report
dkg committed rEe99480affa59: build-aux: use https instead of http (authored by dkg).
build-aux: use https instead of http
Oct 19 2018, 3:12 PM

Oct 18 2018

dkg created T4196: gpgme-json is confused about malformed input.
Oct 18 2018, 6:33 PM · gpgme
dkg added a comment to T4195: Fix time API in gpgme.

what does "not only on Jan 19, 2038" mean here?

Oct 18 2018, 6:21 PM · gpgme, Feature Request
dkg added a comment to T4191: gpgme python bindings test t-callbacks.py fails on 32-bit platforms.

the error i'd seen earlier after reverting the change was an error due to running t-callbacks.py on its own, without the rest of the test suite framework. running it within the test suite framework (with the change reverted), it passes without a problem. I've uploaded 1.12.0-4 to debian with a patch to t-callbacks.py. I can apply it upstream, if you want me to.

Oct 18 2018, 6:20 PM · Python, gpgme, Bug Report
dkg added a comment to T4191: gpgme python bindings test t-callbacks.py fails on 32-bit platforms.

The error might have to do with rM46da79e3de99a7b65748994921d6aab73b9974e7 which looks like it might run afoul of 32-bit time_t (Y2K38 problem?).

Oct 18 2018, 5:33 PM · Python, gpgme, Bug Report
dkg added a comment to T4191: gpgme python bindings test t-callbacks.py fails on 32-bit platforms.

here's me running just the specific test:

Oct 18 2018, 5:20 PM · Python, gpgme, Bug Report
dkg added a comment to T4192: python gpg segfaults when first parameter to gpg.Context().op_genkey() is None or otherwise malformed.

If the swig interface isn't robust, can we replace it with something that will be more robust? Or do we need to wrap it with hand-crafted error checks that describe the API's constraints? It's pretty bad form to segfault python.

Oct 18 2018, 5:01 PM · Python, gpgme
dkg added a comment to T4192: python gpg segfaults when first parameter to gpg.Context().op_genkey() is None or otherwise malformed.

When parms is malformed but not NULL, then the error appears to be a bug in the python bindings in _wrap_gpgme_release. maybe something is going wrong because of the "cannot allocate memory" error? in particular:

Oct 18 2018, 4:52 PM · Python, gpgme
dkg added a comment to T4192: python gpg segfaults when first parameter to gpg.Context().op_genkey() is None or otherwise malformed.

To deal with passing None correctly, it looks to me like the problem is inside get_parameter() in src/genkey.c -- there ought to be a check for parms being NULL, and then returning either GPG_ERR_INV_VALUE or something else. otherwise, the segfault happens inside strstr.

Oct 18 2018, 4:06 PM · Python, gpgme
dkg added a comment to T4192: python gpg segfaults when first parameter to gpg.Context().op_genkey() is None or otherwise malformed.

It the first error (first param = None) is a segfault in versions 1.11.1-2 (debian unstable i386) and 1.8.0-3+b2 (debian stretch amd64).

Oct 18 2018, 1:15 PM · Python, gpgme
dkg renamed T4192: python gpg segfaults when first parameter to gpg.Context().op_genkey() is None or otherwise malformed from python gpg segfaults when first parameter to gpg.Context().op_genkey() is None to python gpg segfaults when first parameter to gpg.Context().op_genkey() is None or otherwise malformed.
Oct 18 2018, 8:14 AM · Python, gpgme
dkg created T4192: python gpg segfaults when first parameter to gpg.Context().op_genkey() is None or otherwise malformed.
Oct 18 2018, 8:05 AM · Python, gpgme
dkg updated the task description for T4191: gpgme python bindings test t-callbacks.py fails on 32-bit platforms.
Oct 18 2018, 6:38 AM · Python, gpgme, Bug Report
dkg created T4191: gpgme python bindings test t-callbacks.py fails on 32-bit platforms.
Oct 18 2018, 6:38 AM · Python, gpgme, Bug Report
dkg committed rM9de1c96ac3cf: python: do not export HAVE_CXX11 definition (authored by dkg).
python: do not export HAVE_CXX11 definition
Oct 18 2018, 6:31 AM
dkg committed rM12b0b5c8941b: doc: convert more links to equivalent https:// URLs (authored by dkg).
doc: convert more links to equivalent https:// URLs
Oct 18 2018, 6:29 AM
dkg committed rMa81534fed8ff: doc: convert more http:// links to https:// (authored by dkg).
doc: convert more http:// links to https://
Oct 18 2018, 6:29 AM
dkg committed rM2f12427e416a: doc: use https:// for www.gnu.org (authored by dkg).
doc: use https:// for www.gnu.org
Oct 18 2018, 6:29 AM
dkg created T4190: https://git.gnupg.org/ is out of date.
Oct 18 2018, 6:15 AM · gpgweb, Bug Report

Oct 17 2018

dkg added a comment to T3354: gpgme only builds against two versions of python at once.

what's the status on this? i'd love to be able to build binaries for both python3.6 and 3.7 for debian. as it stands right now, the python3.7 continuous integration test for debian is failing.

Oct 17 2018, 12:53 AM · Python, gpgme, Bug Report

Oct 12 2018

dkg committed rEa3f4e8838036: syscfg: Add support for arm64ilp32 (authored by Wookey <wookey@debian.org>).
syscfg: Add support for arm64ilp32
Oct 12 2018, 4:49 PM

Oct 9 2018

dkg added a comment to T3894: re-evaluate default randomness choices during key generation on GNU/Linux platforms.

What are the next steps here? i confess i'm a little tired of doing regular checkins on this issue, and i'm sure other people are tired of me nagging. What can we do to move this along?

Oct 9 2018, 6:39 PM · libgcrypt, gnupg

Oct 8 2018

dkg added a comment to T4014: when verifying signatures, gpg and gpgv should ensure signing capabilities.

what does "back signature's usage tool" mean? can we make an addition to the test suite that ensures that bad signatures will be rejected?

Oct 8 2018, 5:07 PM · gpgv, gnupg, Bug Report

Oct 7 2018

dkg added a comment to T4154: allow setting passphrase from an environment variable.

ok, feel free to close this ticket then. It's disappointing that there
seems to be no sane, simple, private multi-channel communication
mechanism avaiable cross-platform that GnuPG can rely on.

Oct 7 2018, 6:45 AM · Feature Request, gnupg (gpg23)

Sep 28 2018

dkg added a comment to T3398: fingerprint-based import screener is no defense against malice.

This was additionally reported as https://bugs.debian.org/909755 -- it would be great to get a clear statement from the GnuPG project about handling the curated keyring use case.

Sep 28 2018, 5:45 PM · gnupg (gpg23), Feature Request

Sep 23 2018

dkg added a comment to T4154: allow setting passphrase from an environment variable.

i note that my patch doesn't include an addition to the test suite, which it probably should, though i'm not fluent in gpgscm. if someone could update it to include a test, i'd appreciate that, and would probably learn from the commit. I imagine the test would do something like:

Sep 23 2018, 9:31 PM · Feature Request, gnupg (gpg23)
dkg committed rG07c19981da06: gpg: add --passphrase-env VARNAME to read passphrase from environment (authored by dkg).
gpg: add --passphrase-env VARNAME to read passphrase from environment
Sep 23 2018, 8:58 PM
dkg added a comment to T4154: allow setting passphrase from an environment variable.

I tried to push commit 07c19981da0607dc442fadc4079b1d71fbef8f83 to branch dkg/passphrase-env on playfair, but i got this complaint:

Sep 23 2018, 8:36 PM · Feature Request, gnupg (gpg23)
dkg created T4154: allow setting passphrase from an environment variable in the S1 Public space.
Sep 23 2018, 8:32 PM · Feature Request, gnupg (gpg23)

Sep 12 2018

dkg added a comment to T3464: successful decryption with session key reports failure if public key is unknown.

sorry, i haven't had time to test gpgme with those changes myself. i hope someone can do so.

Sep 12 2018, 4:53 PM · gnupg (gpg22), gpgme, Bug Report
dkg added a comment to T3464: successful decryption with session key reports failure if public key is unknown.

if gpgme doesn't rely on the return value, but instead on parsing the --status-fd for errors, then there will still be an ERROR printed:

Sep 12 2018, 4:12 PM · gnupg (gpg22), gpgme, Bug Report
dkg removed a project from T3464: successful decryption with session key reports failure if public key is unknown: Info Needed.

yes, it looks like using --no-keyring does change the return code from 2 to 0 for me.

Sep 12 2018, 6:13 AM · gnupg (gpg22), gpgme, Bug Report

Sep 7 2018

dkg added a comment to T3894: re-evaluate default randomness choices during key generation on GNU/Linux platforms.

@aheinecke -- @smueller_chronox.de (author of the comment above) is Stephan Müller from atsec. Glad to see he seems ok with the proposal :)

Sep 7 2018, 9:49 PM · libgcrypt, gnupg

Sep 5 2018

dkg committed rC842ff5f60cfa: random: use getrandom() on Linux where available (authored by dkg).
random: use getrandom() on Linux where available
Sep 5 2018, 9:19 PM
dkg added a comment to T3894: re-evaluate default randomness choices during key generation on GNU/Linux platforms.

well, i tried to push, anyway, but it looks like playfair is rejecting my pushes:

Sep 5 2018, 4:54 PM · libgcrypt, gnupg
dkg added a comment to T3894: re-evaluate default randomness choices during key generation on GNU/Linux platforms.

@werner -- yes, i am asking for a change that is specific to the way that gcrypt interacts with the Linux kernel. The minor patch i've proposed only affects a codeblock within #if defined(__linux__), so i don't believe it would have an effect on other Unices. I hope that people working with other kernels will propose any necessary fixes for them.

Sep 5 2018, 4:46 PM · libgcrypt, gnupg

Aug 23 2018

dkg added a comment to T3894: re-evaluate default randomness choices during key generation on GNU/Linux platforms.

@aheinecke thanks for the followup!

Aug 23 2018, 5:59 PM · libgcrypt, gnupg

Aug 2 2018

dkg added a comment to T3894: re-evaluate default randomness choices during key generation on GNU/Linux platforms.

This bug report has been around for several months now. it has a simple patch, a clear explanation, a report of running code, and examples of problems it solves.

Aug 2 2018, 7:34 PM · libgcrypt, gnupg

Jul 22 2018

dkg added a comment to T3894: re-evaluate default randomness choices during key generation on GNU/Linux platforms.

I've now run the proposed patch on a GNU/Linux system where the kernel's RNG is initialized but /proc/sys/kernel/random/entropy_avail shows numbers below 100, and i can confirm that 3072-bit RSA key generation takes roughly 0.8 seconds: 20 sequential default --quick-keygen operations (each creating two secret keys) took ~32s.

Jul 22 2018, 7:54 AM · libgcrypt, gnupg
dkg added a comment to T3894: re-evaluate default randomness choices during key generation on GNU/Linux platforms.

Here is another example of users doing sketchy things to try to "fix" this process:

Jul 22 2018, 5:28 AM · libgcrypt, gnupg
dkg added a comment to T3894: re-evaluate default randomness choices during key generation on GNU/Linux platforms.

Here is an example of the kinds of UI/UX mystery that users face while this decision is unresolved:

Jul 22 2018, 5:22 AM · libgcrypt, gnupg

Jul 14 2018

dkg added a comment to T4072: fix inconsistent CLI.

We do have a history of extending the API, no?

Jul 14 2018, 5:11 AM · Feature Request, gnupg

Jul 12 2018

dkg added a comment to T1800: Allow s2k options for gpg --export-secret-key.

About how the keys are actually stored on disk:

Jul 12 2018, 6:31 PM · Feature Request, gnupg

Jul 2 2018

dkg added a comment to T3894: re-evaluate default randomness choices during key generation on GNU/Linux platforms.

ping again…

Jul 2 2018, 4:47 PM · libgcrypt, gnupg

Jun 19 2018

dkg added a comment to T3894: re-evaluate default randomness choices during key generation on GNU/Linux platforms.

could i get feedback on this ticket? a simple, clean patch is available, and i don't understand what is blocking it.

Jun 19 2018, 4:32 PM · libgcrypt, gnupg

Jun 18 2018

dkg created T4031: gpg-check-pattern.1 in Debian generates warnings from test-groff .
Jun 18 2018, 6:01 PM · Debian, gnupg, Bug Report

Jun 14 2018

dkg created T4025: `gpg --with-sig-list --show-keys` does not show all the signature packets from stdin in the S1 Public space.
Jun 14 2018, 5:23 PM
dkg added a comment to T4024: "Clean" does not remove superseded subkey signatures.

i'm having trouble just assembling the two signatures over the subkey with 2.2.8 in a single homedir. in particular, when i try to do the following with a new, clean test GNUPGHOME, then i see only one signature on the subkeys afterward:

Jun 14 2018, 4:56 PM · gnupg
dkg added a comment to T4018: gpg --with-colons --show-keys does not show revocation certificates.

thanks, that works for me. I look forward to seeing the patches :)

Jun 14 2018, 4:11 PM · gnupg, Bug Report
dkg added a comment to T4018: gpg --with-colons --show-keys does not show revocation certificates.

can you let me know what you're planning so i can plan my work on enigmail?

Jun 14 2018, 2:26 PM · gnupg, Bug Report
dkg created T4022: too-large User ID packets result in dropping an entire certificate.
Jun 14 2018, 6:28 AM · gnupg, Bug Report

Jun 13 2018

dkg added a comment to T4018: gpg --with-colons --show-keys does not show revocation certificates.

thus far every packet type has been a three-letter string, right? I'm looking at "Field 1" in doc/DETAILS. adding a 4-letter packet type seems like it could be trouble if someone has done the dumb thing of assuming the field is fixed-length.

Jun 13 2018, 2:49 PM · gnupg, Bug Report
dkg added a comment to T4018: gpg --with-colons --show-keys does not show revocation certificates.

can i get a confirmation that the options you're considering for --with-colons --show-keys when confronted with a revocation certificate will be either:

Jun 13 2018, 12:16 AM · gnupg, Bug Report

Jun 12 2018

dkg added a comment to T4018: gpg --with-colons --show-keys does not show revocation certificates.

By "dummy pub line" I think you're proposing output that looks something like this instead of just the rev: line.:

Jun 12 2018, 3:47 PM · gnupg, Bug Report
dkg added a comment to T4018: gpg --with-colons --show-keys does not show revocation certificates.

Revocation certificates consist of *only* the revocation packet, right? Claiming that the revocation cert contains more than the revocation packet (when it doesn't) seems more troubling from an API perspective than just telling people to expect a single rev: line if they are looking at a revocation certificate.

Jun 12 2018, 9:12 AM · gnupg, Bug Report
dkg added a comment to T4017: `gpg --show-keys` can modify the keyring (it is not actually the same as `--dry-run --import-options import-show --import`).

thanks for looking into this so quickly. where is your patch? i don't see it on the master branch yet.

Jun 12 2018, 9:05 AM · gnupg, Bug Report
dkg added a task to rGee1fc420fb97: gpg: Print revocation certificate details when showing with-colons.: T4018: gpg --with-colons --show-keys does not show revocation certificates.
Jun 12 2018, 8:50 AM
dkg added a commit to T4018: gpg --with-colons --show-keys does not show revocation certificates: rGee1fc420fb97: gpg: Print revocation certificate details when showing with-colons..
Jun 12 2018, 8:50 AM · gnupg, Bug Report
dkg added a comment to T4018: gpg --with-colons --show-keys does not show revocation certificates.

ee1fc420fb9741b2cfaea6fa820a00be2923f514 contains a proposed fix for this.

Jun 12 2018, 8:50 AM · gnupg, Bug Report
dkg committed rGee1fc420fb97: gpg: Print revocation certificate details when showing with-colons. (authored by dkg).
gpg: Print revocation certificate details when showing with-colons.
Jun 12 2018, 8:48 AM
dkg added a commit to T4019: --export-filter drop-subkey filter type should have usage option property: rGe037657edaf0: gpg: Add new usage option for drop-subkey filters..
Jun 12 2018, 6:49 AM · gnupg, Feature Request
dkg added a task to rGe037657edaf0: gpg: Add new usage option for drop-subkey filters.: T4019: --export-filter drop-subkey filter type should have usage option property.
Jun 12 2018, 6:49 AM
dkg added a comment to T4019: --export-filter drop-subkey filter type should have usage option property.

I've just pushed e037657edaf0b3ee9d2e30f6fe3edf6879976472 on the fix-T4019 branch

Jun 12 2018, 6:49 AM · gnupg, Feature Request
dkg committed rGe037657edaf0: gpg: Add new usage option for drop-subkey filters. (authored by dkg).
gpg: Add new usage option for drop-subkey filters.
Jun 12 2018, 6:49 AM
dkg renamed T4019: --export-filter drop-subkey filter type should have usage option property from --export-filter drop-subkey filter type should have usage_flag option property to --export-filter drop-subkey filter type should have usage option property.
Jun 12 2018, 6:43 AM · gnupg, Feature Request
dkg created T4019: --export-filter drop-subkey filter type should have usage option property.
Jun 12 2018, 3:41 AM · gnupg, Feature Request
dkg updated the task description for T4018: gpg --with-colons --show-keys does not show revocation certificates.
Jun 12 2018, 1:11 AM · gnupg, Bug Report
dkg added a comment to T4017: `gpg --show-keys` can modify the keyring (it is not actually the same as `--dry-run --import-options import-show --import`).

see e051c279216ecd4ec9a48e13ccc695f5ab667b2a

Jun 12 2018, 1:02 AM · gnupg, Bug Report
dkg committed rGe051c279216e: gpg: set full --dry-run when used with --show-keys (authored by dkg).
gpg: set full --dry-run when used with --show-keys
Jun 12 2018, 1:02 AM
dkg added a comment to T4017: `gpg --show-keys` can modify the keyring (it is not actually the same as `--dry-run --import-options import-show --import`).

I note that --import-options show-only --import has the same effect as --show-keys -- that is, the revocation cert is imported. so the error is in the import-options code itself. I'll push a fix-T4017 branch shortly with a proposed correction.

Jun 12 2018, 1:00 AM · gnupg, Bug Report

Jun 11 2018

dkg created T4018: gpg --with-colons --show-keys does not show revocation certificates in the S1 Public space.
Jun 11 2018, 11:34 PM · gnupg, Bug Report
dkg created T4017: `gpg --show-keys` can modify the keyring (it is not actually the same as `--dry-run --import-options import-show --import`).
Jun 11 2018, 11:10 PM · gnupg, Bug Report

Jun 9 2018

dkg created T4014: when verifying signatures, gpg and gpgv should ensure signing capabilities.
Jun 9 2018, 12:33 AM · gpgv, gnupg, Bug Report
dkg added a comment to T3894: re-evaluate default randomness choices during key generation on GNU/Linux platforms.

I've heard no critique of the logic above. could we get this fix landed? it is concretely useful for doing key generation on modern GNU/Linux systems.

Jun 9 2018, 12:03 AM · libgcrypt, gnupg

Jun 8 2018

dkg added a comment to T3844: Able to certify public keys without a certify key present when using smartcard..

fwiw, i agree that if there's any security vulnerability here, it is in the verification side, not the creation side.

Jun 8 2018, 11:58 PM · gnupg (gpg22), Bug Report

May 29 2018

dkg added a comment to T3277: decrypting data symmetrically doesn't reliably convey confidentiality property.

@werner, what protocol design rule do you think is not being followed specifically?

May 29 2018, 11:31 PM · Feature Request, gnupg (gpg22)
dkg committed rE619abb6211e8: po: More Spanish translations. (authored by emma peel <emmapeel@aktivix.org>).
po: More Spanish translations.
May 29 2018, 5:12 PM

May 25 2018

dkg committed rG3308d5e3f4e2: g10: Make force-mdc the default. (authored by dkg).
g10: Make force-mdc the default.
May 25 2018, 7:21 PM
dkg committed rG49e4908652c4: po: Update Spanish translation. (authored by emma peel <emmapeel@aktivix.org>).
po: Update Spanish translation.
May 25 2018, 7:21 PM
dkg committed rG64597e1bd9ff: po: Update Spanish translation. (authored by emma peel <emmapeel@aktivix.org>).
po: Update Spanish translation.
May 25 2018, 7:21 PM
dkg added a comment to T3995: make --force-mdc the default.

please see the branch dkg/fix-T3995 with rG3308d5e3f4e25dce5168c4a7cb2f545424c6d185

May 25 2018, 6:34 PM · gnupg, Bug Report
dkg created T3995: make --force-mdc the default.
May 25 2018, 3:48 PM · gnupg, Bug Report

May 1 2018

dkg committed rE7e2517a29619: po: new Spanish translation (authored by emma peel <emma.peel@riseup.net>).
po: new Spanish translation
May 1 2018, 4:19 PM

Apr 28 2018

dkg committed rEa498adfc84c9: po: new Spanish translation (authored by emma peel <emma.peel@riseup.net>).
po: new Spanish translation
Apr 28 2018, 10:26 PM

Apr 26 2018

dkg added a comment to T3942: Can't unregister a non-existent private key.

I note that this problem could also affect a user with multiple identities, one of which has their decryption keys on a smartcard. If a message arrives encrypted to both identities, but the user does not have their smartcard available, they will hit the same issue.

Apr 26 2018, 5:31 PM · gnupg (gpg22), Bug Report

Apr 19 2018

dkg added a comment to T3775: enable mixed hidden/non-hidden recipients during encryption.

I think i can understand why this decision was made, but i'm not convinced it's a great solution. In particular, string-based arguments for C libraries are asking for trouble, and compound string arguments of the type described above are even more risky.

Apr 19 2018, 9:01 PM · gpgme, Feature Request