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.

We can later decide whether to backport this to 2.2

For workaround (master branch with rG0a7661129499), moving the private key file to *.key.bak can do that.

But not for 2.2

I've changed the text of this report from "filter" to "screener" to match the preferred terminology. thanks for the clarification.

I still consider the import screener (the term filter is used in a different way now) a big mess. Using the import feature to maintain the idea of a curated keyring is a bad idea because gpg has not been designed with this in mind. We spent so much time on this screener already and problems pop up again and again.

I am not proposing changing the order of the *hashed* subpackets in a signature. I'm proposing removing/changing/canonicalizing the *unhashed* subpackets in a signature. Sorry if i didn't make that clear enough in the initial message.

But wait. Does my idea really help with comparing? I doubt it because a signature also includes a date and other variable stuff and thus they are already binary identical or it is a different signature.

Right we can't change the order of signature subpackets after they have been created. Given that we create subpackets by directly appending them to a memory buffer instead of keeping a list of subpackets to create, the least invasive method would be a function to shuffle that memory buffer right before the signature is computed.

I thoroughly agree that this is not required by the specs.

That is not required by the specs. Another way is to provide a tool to compare keys. That seems to be easier to me. Also consider the cases that there are new new packets or signature subpackets with unknown properties to the current implementations. What about different encodings in signed key material?

This would emit the "content-encryption key", as specified in
https://tools.ietf.org/html/rfc5652#section-6.3