Git repos are development only and developers need to find a way to establish some trust in the source before building it. All kind of mischief can happen with arbitrary sources. https does not help at all. You need to find a way to establish trust - how you do that is up to you. For example looking at signed commits and try to figure out whether you can trust this key.

A public keyblock without a user id packet is non-compliant. I see no reason to provide a feature to created crippled data. We had all this discussions back in the early 90s regarding to self-signatures. OpenPGP spoke a final word on this in 1998 by making user ids and corresponding self-signatures mandatory.

Oops, that was an experimental feature never intended for a released version. Will be removed in a way that it does not leas to compile problems - just to be extra cautiousness.

I think that a backport to 1.8. also makes sense

Stick to your channels and get back after you have learned basic some basic developer workflows.

@hanno, this is a bug tracker and not yet another media for your rants.

Fix has been released. Keeping this in testing state for easier visibility of this task.

Release done.

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:

BTW, we should better get back to the classic/GNU-coding-style pattern:

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

Do not use -fno-common

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
• If you run into "selftest" error see T5254 for a patch (which should be applied in any case)