Thanks for reporting. Fixed for 2.2.22. repeat==0 works like before and repeat>1 also (that is several passphrase pinentries will pop up).

I's say we should not do anything but solve that along with the move of all fd/fp/sock/HANDLE stuff to gpgrt to solve this at one place. We need that anyway to properly support Windows64. We won't be abale to do this for 2.3, though.

If you use

It is indeed a limitation. We added these options to support the Kleopatra GUI. To avoid problems with filenames with embedded newlines etc. Kleoptra uses a binary nuls to delimit filenames. And that is what we only support.

Thanks

No, c99 was never required. Meanwhile we use a few c99 features but those are supported without any compiler option.

Please try with out supplied CFLAGS or change them from

@JW: @gniibe explained you the problem and provided a fix (i.e. use correct specifiction of the directory names). Changes to Makefile.in are a no-go because that is a built file and a real fix would need to go into libtool. However, for a couple of reasons we do not want to update libtool (e.g. too many breakages in the past, we have out own fixes in for Windows). Thus we consider this bug closed.

We won't do such a interface now.

Mitigations are in place for quite some time now; see T4755.

Fix will be in 2.2.22. Thanks for the report.

It was actually moved to noninstall in 2006. The reason or this is a conflict between the version of gpgsplit in GnuPG 1.4 and 2.0. Back then it seemed easier to keep on using the gpgpslit from 1.4 because that version was installed anyway. At that time gpg was called gpg2 we changed this much later and probably forgot to switch also to the gpgsplit from GnuPG 2.

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.