So you mean the bug that you see a second set of passphrase dialogs iff you told the first one that you don't want a passphrase? That is not trivial to fix because we use the passphrase cache to avoid the double passpharse questions. Without passphrase cache we need a separate code path.

No! That is not what I want with this issue. We should ask once for a passphrase and then shut up.

Yeah, it is annoying. Maybe it is indeed better not to ask for a passphrase at all.

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.

OK. Then, it may be some bashi-ism in Makefile. I'll investigate with no bash installed.

No, I don't have a smartcard. Perhaps it misdetects one?

For other failures, I guess that you are connecting your card, aren't you?
Last year, I introduced a change for key selection to prefer existing card key. That may affect tests. Well, tests should have configure not to try to access card.

For scdaemon process(es), I created a ticket T3778: NetBSD: scdaemon should be killed when its parent (gpg-agent) is going to shutdown.

I'm confused. I've just now retested, and I get further with BSD make (there is another problem when importing the keys into the test keyring, where it the error is ignored with GNU make but the build fails with BSD make) but that is not what I want to focus on.

Thanks for your additional suggestion. I pushed the change.

For qt: adding /usr/pkg/qt5/bin to the path makes the build succeed. I think you should take a look at the build rules though, since it seems that it wants to execute the header file if "moc" is not found.

For BSD Make issue, please try:

For the latter, I think it requires path to moc, which may be like /usr/pkg/qt5. Please add it to your PATH. Then, retry from configure

Using BSD make on git head of gpgme, I see

Other problems are fixed. Please test. It works for me on NetBSD 7.0.2.

Checked - it builds fine now. Thanks!

I push my change to master.
Please test.

Thanks for testing master.
No, it's not typo, in my opinion.
The line was added as if it's LOCAL_PEERUID, but there is no such a thing in XNU, but there is LOCAL_PEERUUID which is for UUID.

Using an external process as an option is fine. However adding more dependencies to gnupg should be avoided.

So… Is there any interest in the approach I drafted in D442?

In T3056#95172, @wiz wrote:

Oh, to make it clear - I was testing the pkgsrc version with the additional patches used by pkgsrc, see http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/security/gpgme/patches/

Testing it without patches does not work because:

get-env.c:57:2: error: #error Use of getenv_r not implemented.
 #error Use of getenv_r not implemented.

There are multiple problems. I fixed one Makefile portability issue today.

To compute the key validity (trust) more information may be needed and we can only do that after the changes have been saved. Further, no-auto-chec-trustdb will anyway delay that computation until "gpg --check-trustdb" is run (e.g. by a cron job).

It might be easier to include a regexp implementation in GnUPG proper. This way we have a well defined behaviour and it will work also on Windows. The gpg-check-pattern tool might slightly change its behaviour, though.

No, I was not accurate. EXAMPLE.COM works, while example.com doesn't work.

Henry Spencer wrote three implementations (old, BSD, and Tcl): https://garyhouston.github.io/regex/
Indeed, for the one in old library and BSD library, \ + CHAR means that single CHAR.
For one in Tcl library, \s, \S, \w, \W is supported (just like GNU), and \d, \D (digit) is also supported.

For what is worth I think sanitize_regexp was programmed while reading 4880 because the RFC allows backslash + any character (section 8: Regular Expressions):

It might be not a regression. The possibilities are: (1) it was tested by using non-GNU operating system. (2) Tests didn't cover characters (b, B, w, W, s, and S).

For the reference sanitize_regexp was introduced in this commit from 2007 to "Protect against malloc bombs.": and I see no changes to it (except typo correction) in git blame in trustdb.c.

I built gnupg 2.2.1 with the patch from D450, but that didn't help.
I even got an additional error:

I believe this is due to the bug of gpg-agent. So, I put this report as a sub task under T3276: the calibrate_get_time() function depends on a system that has a non-tickless kernel.

We could signal an error. However, that would break existing behaviour and can only be done for 2.3.

Let's move that to master.