Done for master

Seems like this is applicable to other binaries as well:

On further thought, it's possible that something closer to what
Bernhard wants (and incidentally more along the lines of what I was
thinking of in some of our discussions just after the initial port)
might be achievable with Cython.

FWIW, GPGME is basically C90 and we only recently started to use C99 variadic macros - they are a cpp feature, though.

CFFI has no real means of generating the needed bindings on the fly
like SWIG does, except via its ABI methods, but those are inferior to
what SWIG does. It also can't handle all the ifdefs (or really any of
the ifdefs) in gpgme.h.

I am working on the Telesec Signature Card v2. I will add encryption support to gpgsm.

Nope, I was wrong.

Hi @slandden.
Do you have any updates?

It runs like:

$ gpg-connect-agent "scd devinfo --watch" /bye
S DEVINFO_START
S DEVINFO_END
S DEVINFO_STATUS new
S DEVINFO_START
S DEVICE generic D276000124010200F517000000010000 openpgp
S DEVINFO_END
S DEVINFO_STATUS removal
S DEVINFO_START
S DEVINFO_END
OK
$ 

Push the change to master.

genkey for Ed25519 works now with libksba in master.

For public key, it's done.

Thanks for following up!

No, we always stated that the user id is a mandatory part of OpenPGP keyblocks and that non-compliant keyblocks are rejected. The only exception we made are for revocation signatures where we allow a standalone packet. That exception is done to allow typing in a printed out revocation signature.

To be clear: marking this ticket wontfix means (among other things) that it is the GnuPG project's upstream position that:

With OpenPGP we made user ids mandatory to avoid problems we had with PGP2. I see no reason to revert this.

Nine months have passed since the patches for this problem have been available.

I recall that I talked with Stephan about it but things got lost.

NIST P-256 key generation looks good.

There are two code paths to generate key: gpgsm_genkey and gpgsm_gencertreq_tty. Latter is partially supported with card key.
Firstly, I'm going to work for T4888.

This should work well with libksba master and gnupg/sm master.

The commits in 2019 (for libksba and gnupg/sm) handles the problem (of key generation using card).

Created https://dev.gnupg.org/source/gnupg/history/gniibe%252Fscd-watch/

Given that we may move to yet another format in 2.3 I now doubt that we should add such a feature to 2.2.

Thanks. I applied your patch to 2.2 and master. I had to do a minor fix because the function does not return anything. Also extended on master with another patch for v5 keys.

It is my confusion. The API is available. I only looked for symbols in the library.
It is #define-d macro to pthread_cond_*.

For Windows, it is available. I don't know the reason why it has not been available for POSIX.

I think that this chnage is useful enough to be backported to 2.2. Done that.

You can test it now out using GnuPG master: Just add --include-key-block and you can then verify using an empty keyring. Currently --auto-key-retrieve is not needed but we need to think on how we can enable or disable this during verification.

I am not sure whether this is related but when using Libgcrypt master and verifying a signature created with an ed25519 key, I get the error below with valgrind. Both with 2.2. current and 2.3. It does not happen with the current Libgcrypt 1.8.

For reference, here's an error message from openssl smime when it is trying to verify an e-mail message with no embedded certificate at all (despite it knowing about the relevant certificate):

There are likely some bugs in the new code and I also want to do some improvements; see rGb4f1159a5bd7. But things should basically work as before and thus I set this again to testing

Fixed in master.

A program like tests/t-mpi-point assumes gcry_mpi_print can do that.
We have a sort of regression with --debug option with t-mpi-point, the point q is not printed out correctly.

This requires re-evaluation of Libgcrypt to match the current FIPS specs.

Okay, I recall that I have seen these Yubikeys. Can you tell me which GPG app you intended to use? I am not aware of any GnuPG ports to the iPhone.

The new Yubikey 5Ci does NOT work with NFC, this is wrong. This Yubikey is delivered with two connectors: A lightning and an USB-C, see: https://www.mtrix.de/shop/yubikey-5ci/. The key can be connected to a laptop and an iPhone by plug-in. So the new Yubikey 5Ci does not require NFC at all. You refer to the Yubikey 5 NFC. This technology is not supported by developers because they do not have experiences there. With the plug and play functionality of a lightning connector it is easier and few application already exist (e.g. Yubico authenticator and several password manager in the professional edition). Hope this information will be useful for you.

Supporting NFC tokens requires implementing secure messaging for cards. This is on our todo list anyway but has had no priority. I have a couple of Yubikeys but not done any work on NFC.

i'd be unlikely to ship anything as /etc/gnupg/gpg.conf or /etc/gnupg/dirmngr.conf just because of the mess that admins have to deal with when shipped config files change.

Arggh, gpgconf uses its own option parser so adding the global config file there will require some extra work.

@dkg You might find this interesting. Debian could do stuff in /etc/gnupg/gpg.conf or /etc/gnupg/dirmngr.conf without patching GnuPG to change some defaults.

All done in master with the latest libgpg-error (see T4859). There is always a global configure file in /etc/gnupg (or whatever "gpgconf --list-dirs sysconfdir" prints). The name of the configure file is the same as the user config file (gpg.conf, gpgsm.conf, gpg-agent.conf, ...) but for gpg.conf no versioned config names are used.

Internally only the long key id is is used thus the fingerprint might give a wrong impression. OTOH, to allow easy migration to future versions, extracting the keyid from the fingerprint is a good idea.

In T4513#132777, @Valodim wrote:

But searching on Keyservers is also in my opinion not a common use case for Kleopatra users.

Thanks for engaging constructively.

Okay, we now have global conf files in master. The extra flags to ignore or force certain options will be added to libgpg-error.

In T4513#132770, @aheinecke wrote:

Werner could you maybe at least check for an internet connection, I don't know how to do it on Linux but on Windows it's easy because windows has API for that.

But searching on Keyservers is also in my opinion not a common use case for Kleopatra users.

and by that bypassing all key source tracking as done by gpg. In any case searching by name or mail address on a keyserver should not be done - at least not by a GUI tool as used by non experienced users.

I agree that this is a tricky problem, but it should really be improved.

The problem is not to check whether there is a connection but on how to decide whether something is a pool or an explictly added single keyserver and how often should we try to connect or read from it. Without marking hosts as dead the auto search features won't work well.

@Valodim probably not so much as dirmngr might behave differently and not mark hosts as dead.

The proper solution is of course to use pkill instead of killall. SCNR.

I can attest to the "growing bit of popular lore": Roughly half the support requests I get to support@keys.openpgp.org boil down to an exchange of "it just doesn't work with a 'general error' message" -> "try killall dirmngr" -> "that did it". I have heard similar stories from @patrick from Enigmail users, and more than once heard people applying poweruser trickery like "I just have killall dirmngr in my resume.d".

Hi Andre, did you already get anywhere with this task? Thanks a lot in advance, Joachim

Yes, I need to optimize it.

Hi @slandden. Have you made any progress since the last time I asked?

It can force it on the outbound. https://support.symantec.com/us/en/article.tech164655.html
It also allow SIMME pass-through. https://support.symantec.com/us/en/article.tech166867.html

Implemented in master.