T4702 is our release info task for 2.3.0

Sorry, we won't apply such changes. A couple of years we did this and all we earned were a few extra bugs aqnd useless diffs. Further many of those changes are in files which will be updated from upstream time to time and your chnages would be lost.

Thanks. However, we need to go over the list one by one to decide this. For example
"http://gnupg.org/.well-known/openpgpkey/hu/12345678" is actually expected to return a 404 and test code may very well use http:

Last week:

• Released Libgcrypt 1.9.0
• Looked at CardOS support for scd
• Hacked OpenSSH to get rid of the need for updatestartuptty.

• Please see T5262 if you want to build with Qt4.

Should we add this to the hints in the README? After all this does not seem to be the standard system compiler or it has not been properly setup as replacement.

Do you mean self-signed certs or what kind of certs do not work?

Sure. Thanks for testing. The problem with new versions is that ppl don't like to test release candidates and thus we need do real releases and wait for the outfall. ;-)

Thanks for the reports. IIRC, we had similar reports in the past either here or on a ML.

• For build problems on Raspberry PI see T5251 for a patch

FWIW, after the release I had some time and after some trouble with my Pi4B I ran into the same problem.

So is this about 1.8.7 or 1.9.0 (as shown in the Version field)?

Reading the bugzilla report it seems that TB is loading gpgme at runtime. In particular the hints on using externally build stuff (Homebrew) is worrying. Someone(tm) needs to check how gpgme is used by TB and that it is properly initialized. GPGME is actually not designed to be loaded at runtime but should be used as standard shared object or static library.

Dependency hell - ask your favorite distribution

Sure that TB uses GPGME - they claimed they won't use it due to license incompatibility (LGPL). I assumed they use gpgme-json via naticve messaging. Regarding the error - I have no idea.

We plan this for 1.10 but it may also go into one of the next 1.9.x releases

Docs done.

Typo, sorry. I have no access to pypi and won't apply for an account due to general concerns about those platforms. Thus I can't change that page. Let me assign you this issue ;-)

No, this is a fork and we consider the use of a PyPy for GPGME a Bad Thing because it does not guarantee a stable ABI and we accept bugs files against this version.

Please let us know your gpg4win version.

I am not sure. MD5 is still important for some applications, say CRAM-MD5. IIRC, back in 2008 we dis-allowed RMD160 and added separate RMD160 code directly to gpg to fulfill FIPS requirements.

Okay for 1.9.

Note: The commit in master (1.9) is rCe0898d0628789414

The commit which fixes this is rC761a1a0d30

Lowered priority because in reality it is not possible to get a certificate for an arbitrary SigG key on the card. Only accredited CAs may issue certs and they want to keep full control over the key generation.