Isn't the Sparc crypto instruction set only available in kernel mode?

That is not a functional feature request and I see no value in chnaging data structures just for being up to the latest RFC. Actually the ASN.1 is not from an RFC but from a specific X.509 profile. For CMS most parsing is anyway done with handcrafted code.

Argh, that Python specific stuff Ben used is weird and does not fit into the autotools model. Someone(tm) need to have a closer look at it.

The digest algorithm used is computed based on the preferences in the key if encryption is also used. Thus this should always work and any decent key has sha256 in its preferences. In case sha1 has a higher precedence, as seen on old keys, --personal-digest-preferences can be used to prefer sha256. However, it is way better to fix the key. The easisies way to do that is to change the expiration date - then the new standard preferences will be used.

The thing is that that I accidentally added the -Wno-* flags only in maintainer-mode as they were -Wmore-strict-warning-flags. One reason for using more strict warnings in maintainer mode is to allow building with older gcc versions without having to test for the availability of the warning flags.

Put

log-file /somewhere/scd.log
debug ipc,cardio
verbose

into ~/.gnupg/scdaemon.conf and kill scdaemon. Then look at the output. I would suggest to first stop the pcscd so that GnuPG's internal CCID driver will be used. Make also sure that there is no a permission problem with the usb port. In case of a CCID (card reader protocol) problem a

debug-ccid-driver

in scdaemon.conf will also be helpful.

If you have a patch please send it either by mail to gnupg-devel or attach it here. Thanks.

Please explain in more detail what the problem with Cygwin is.

Since 2.1 the standard use of gpg-agent is to have it started on demand by the components which require it. The use of
"gpg-agent --daemon /bin/sh " should be used for debugging only.

FWIW, with 4a130bbc2c2f4be6e8c6357512a943f435ade28f I fixed a similar report by @syscomet but lacking a test case this was a blind flight ("This patch is not tested but a good guess."). Thanks for tracking it down.

That might have been a regression since one of the Phrabricator updates (we need to apply out own patches each time).

Minor

We will do a new release in two or three weeks.

Can you please run claws like this:

Did you encrypt to a key of yours? You can only decrypt if you have the matching secret key for the public key you used for encryption. The error message: "No secret key" should be obvious.

Reolved since summer last year.

I don't anymore think this is a high priority request. BTW, A more real problem than several dirmngr instances is multi-user access to smartcards.

We do not support 64 bit Windows thus this problem on Cygwin is obvious. Funny that Cygwin falls back to native Windows object in this case.

And please do not use Gpg4win 3.16 but the bug fixed release 3.1.7.

Please explain in detail what you did to receive this error message.

@gniibe already wrote: “With gcc-9 in Debian experimental, everything goes well.”

• If the original key origin is a KEYSERVER or WKD it is fine to fetch an update of the key from a keyserver/wkd without user interaction.
• if the key origin is file it can be assumed that the key has bee received hand to hand and thus the existence of that key should not be made public.

I did lot of tests in the last weeks while working on gpg-card.

Well, it took long to fix. My original plan was to fix it while reworking getkey.c but that I have not yet come to work on that.

Conceptionally it is the same. You receive a key and start to use it, everything else is not a matter of gpg; in particular not the autocrypt protocol.

So this seems to be a gcc bug, right. Then we should close this bug.

autocrypt is not different from attaching a file to a (signed) message as it has always been done. We have no special treatment for that in gpg. Certain origins do have special treatment but in general the key origin is meta data for the frontend. For example it allows us to update a key received from WKD when it has expired.

Receiving a key by mail should in general be considered unknown and is not more trustworthy than receiving a key from a keyserver. I would suggest that you use "ks-pref" for this purpose. That origin value has no special meaning in gnupg but is numerical ordered between keyserver and and DANE; gpgme currently maps it to keyserver level anyway.

Please be so kind and point me to the specs stating that you should put the IP address into Host:

So in short you want:

1. Allow to specify a keyserver by IP without any DNS lookups.
2. When connecting via IP use the IP address for Host:.