Why can't we hide internal symbols in c++ as we are doing in other libs for ages? Were the internal symbols only accidentally exposed?

I pushed the change: rCa340e9803882: fips: More portable integrity check.
It uses .note.fdo.integrity section, not loaded onto memory.
It simplifies the logic, and switches to dladdr (from dladdr1).

Pushed the change which fixes the build with ld.gold.
rC9dcf9305962b: fips: Integrity check improvement, with only loadable segments.

Thank you for your suggestions, @werner.
I agree that we should not put much effort to develop our own methodology here; Too much effort may introduce possibility of unmaintainable code, which should be avoided for the particular purpose of "integrity".

Sure. We'll bump the SONAME.

In T5834#154975, @ikloecker wrote:

I assumed that changes to internal classes wouldn't break the ABI, but apparently the symbols were still exported. I'll keep this in mind for the next release.

FWIW, the internal class in question was completely rewritten. Since the damage has been done already, I'll close this report. We won't readd symbols to dead code. Sorry, for the inconvenience.

Folks, you are opening a can of worms. The only secure why to sign a file is to have a detached signature. That is often non-practical and thus putting the signature/MAC at one certain position and exempt just this one position from hashing is the next best alternative. Any more complicated rules will inevitably introduce security flaws. If a binary is stripped, it is a different binary than a non-stripped one, if it is linked with another linker, it is a different one. And that binary will even be able to figure this out and change behavior. Please keep it simple.

Thanks! Maybe it would be simpler to use dl_iterate_phdr(3) for this. I wasn't aware of the function, but a colleague just implemented a proof-of-concept of what you're proposing in https://gitlab.com/dueno/integrity-notes.

I assumed that changes to internal classes wouldn't break the ABI, but apparently the symbols were still exported. I'll keep this in mind for the next release.

I am going to apply https://gitlab.com/redhat-crypto/libgcrypt/libgcrypt-mirror/-/commit/64ccc25c4b4a2c8c4e13e7e37ff1c8c60a3d8401
And consider adding the code to limit hashing content (from start of the file to end of data section).

Guess why GnuPG has its own Tor aware resolver ;-) To debug this kind of stuff you need to debug dirmngr, by adding for example

Found it: I did not initialize gpgme_op_interact's last parameter out with gpgme_data_new. The error is now gone.

As well as GnuPG VS-Desktop. 3.1.21. We should also do a new gpg4win release.

Instead of extending the context menu I have simply added a button next to the fingerprint which always copies the fingerprint without whitespace to the clipboard. Should also be better for accessibility.

Good to hear the cause.

I have added tooltips to the + ECDH and the + Elgamal checkboxes. Hope this helps.

If the user unselects + ECDH, then the checkmark before Encryption under Certificate Usage is removed. I'm not sure whether adding a tooltip would help if they don't notice this.

Since you are using C++, I suggest that you have a look at GpgSetOwnerTrustEditInteractor in the C++ bindings of gpgme. Have a look at QGpgMEChangeOwnerTrustJob in the Qt bindings of gpgme to see how it's used even if you do not want to use Qt.

Hi,
(Exec format error), read 0 bytes

Commented out the problematic code and added notes.