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.

I have this use case: A card based encryption key is used as a subkey on one of my keys but also on another key of mine. The reason for this can be that I want to have separate keys (with different fingerprints) for two user ids but still use the same card for decryption. Sure it is possible to figure out that the user ids belong together but it is not obvious on first sight. Another use case is a role account with a shared subkey with only one administering the primary key.

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.

Maybe not on Linux but the environment is visible from other processes in the same way as the command line. So I don't see why we should add yet more clumsy passphrase workarounds to gpg. We already have PINENTRY_USER_DATA which can fulfill the same task.

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:

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

Patch 0001 applied to master.

BTW: For TSA keys an additional key (usage) flag ("This key may be used for time-stamping") in RFC 4880bis would be nice. What do you think?

According to RFC 3628 there are two additional conditions to consider:

A timestamp or a time mark (which is an audit record kept in a secure
audit trail from a trusted third party) applied to a digital
signature value proves that the digital signature was created before
the date included in the time-stamp or time mark.

The question is now to model the API for this. For 0x02 it seems to be pretty clear: We assume it is a detached signature on a zero length file and make sure that no signed file is given.

Attached is a timestamp signature created with the test key (alfa, alpha, alice) from tests/openpgp.

In master, commit from rGce2f71760155: g10: Change decryption key selection for public key encryption. until rG84cc55880a58: g10: Prefer to available card keys for decryption. fixed this.

I think it's good to close this as "resolved", since many fixes have been done, and I don't have remaining issue.
@wiz Please open another ticket for your next try.

Okay, can you please provide sample data for the test suite? Best using one of the existing keys but adding another one won't harm either.

DKGPG will contain programs to generate such signatures in its next release. Thus it would be nice, if those signatures can be verified by GnuPG as one of the most widespread OpenPGP implementations.

What are we going to do with this report? The last comment is 6 months old; can we change from testing to resolved or do we need to wait for a gpgme release?

What are your use cases?

Fixed for forthcoming 2.2.6. Because of T3781: ECC encryption key on-card generation broken.
rG820380335a20: g10: Add "key-attr" command for --card-edit.

Thanks for tracking this down. I'll fix.

Bissecting between gnupg-2.3-base and master pinpointed commit ecbbafb88d920e713439b6b1b8e1b41a6f8d0e38 as the origin of the bug. This commit changed MAX_FINGERPRINT_LEN from 20 to 32, but the get_user_id_byfpr function in g10/getkey.c still assumes the old value.

The error of testQuickUID is strange. In the test, it adds a UID and checks number of UIDs (3 + 1 = 4).
It is not reproducible for me (Debian with Qt 5.9.2, NetBSD 7.0.2 with Qt 5.5.1), gnupg 2.2.x from the repo.

(automake should flag non-portable Makefile features - after all it is there to avoid gmake features)

Thank you very much! This is working quite well now.

I believe that all BSD Makefile issues has been fixed (except python-tar-gz distribution thing for maintainer).
Please test again.

I located the problem. It's Makefile portability issue and it is fixed in: rMb5ec21b9baf0: tests: Makefile portability., rMba6e610baa13: tests: More Makefile portability., and rM3224d7f0ea83: tests: Fix previous commit
It was not your final invocation of "make check" (GNU or BSD), but the one before ("make all" by BSD make) which imported keys for tests.
The "export" directive doesn't work on BSD.