Thanks. Added to 2.2.

You used --personal-digest-preferences to force the use of SHA-512, right?

OpenPGP (RFC-4880) requires support for 3DES and SHA-1 thus you can't disable them. However, they are not used in practice because the key preference guarantee the use of more modern algorithms,

Do you mean you want to copy a backup key created while generating the keys for the card onto a new card?

We won't do that for 2.2.

Solved in master (1.9). We won't do it in 1.8.

Use

gpgconf --kill dirmngr

to stop it.

No more info was provided.

Download the corresponding tor signature file. Then enter that file name.

There are no log file but you can run the test by hand:

Iyou look at the key on the command line (or with Kleopatra's certificate manager), for example by using "gpg --list-key foo@bar.com" or by applying the command "gpg --show-keys" on the pasted keyblock you get this:

Patch backported to 2.2

We have had this in the past but it led to subtle build and, worse, runtime problems. Thus the decision to provide architecture dependent files and have configure complain for wrong files. Right, you sometimes get false warnings for non-matching cpu-vendor-os strings but I consider this less severe than the old problem.

Well, it is now defined. We use a CMS object containing an OpenPGP keyblock container. Right, there is no open standard for it but with OIDs you don't really need them. it is a bit of a hack but it works with the majority of deployed cards and the overhead is quite small.

Item 2 and 3 have already been solved by allowing to store a minimal key.

I deferred this thing because I hoped to implement this in the keyboxd. Another option is to use a truncated fingerprint - for displaying purposes we anyway truncate to 25 byte and 20 byte should also be okay until we can move this to keyboxd. But okay, if you want to add support please go ahead but make sure that there are no fatal conditions if a gpg 2.2 accesses the v5 enabled trustdb.

That could also be the reason for some strange behaviour I have sometimes with my bunch or readers. I have not had the time to look into this and thus opted for a gpgconf --kill scdaemon which fixes things quickly but of course this is a bad workaround.

C++ interface is also availabale in 1.14.0 (see rM690d967196d9).

iirc, you need to start gpg-agent before you use putty; thus do a "gpg -K" or "gpgconf --launch gpg-agent".

Thanks for looking into this. However, I do not understand the problem behind it. Is it the need to link against the socket lib? 10 or 15 years ago things were more complicated because two TCP stacks were in use and you could use the modern one only if a certain service pack or Explorer version was installed. That might be the reasons for some of the peculiarities we have in the code.

Right 2.2.21 fixes a long standing bug in symmetric encryption in that the configured passphrase constraints were not checked. Eventually we will add a second sec of constraints here but for now the same constrains as for private key protection are used.

No info received

I am not any longer interested to see the real cause; eventually we will replace it anyway with a modern CreateProcess.

Reconsidering this: Running the test suite with gpg1 is not a proper use case. gpg1 may be installed in addition to gpg but it should never be used on a build machine solely.

I don't see any error here. There is a trailing LF on the binary data which gpg rightfully complains about.

As of today we don't want to maintain another binding; see T3395

The Python bindings are troublesome enough; as of today we don't want to maintain a Perl module.

No info received in3 years.

Has already been fixed with T4061.

C part done; C++ interface is not yet done.

Well, it changes the behaviour on error and thus it should not be backported to 2.2 so that existsing error reports about corrupted data don't change. Fine for master.