Nikos Mavrogiannopoulos nmav@gnutls.org writes:
- Fix the ABI problem (which unfortunately implies an abi break). Some progress, but I don't think I've published my wip branch.
I'd recommend against breaking the ABI. It would mean that any new additions would take significant time to be propagated into distributions. Is there a way to fix the issue by introducing new safe APIs?
Problem is described at https://trofi.github.io/posts/195-dynamic-linking-ABI-is-hard.html. As I understand it, when I added SHA3 hashes to the nettle_hashes list in the nettle-3.3 release, that was intended to be binary compatible with earlier releases. But it wasn't, for traditional non-PIE executables linking dynamically with nettle, due to the way R_X86_64_COPY relocations work.
As far as I'm aware, the only fix which is going to be binary compatible with executables linked with all of nettle-3.1, -3.2 and -3.3 would be to drop sha3 from nettle_hashes. And that would clearly break compatibility with nettle-3.3 in a different way.
But my plan was to rename the symbol nettle_hashes to _nettle_hashes, add a function get_nettle_hashes to return its address, and define nettle_hashes as a macro expanding to get_nettle_hashes(). Which would be a compatible change to the API, but a break of the ABI.
Maybe it's possible to leave the old halfway broken symbols in place in some way. One could define the nettle_hashes symbol as an alias for _nettle_hashes, which would be left around in the .so file but unused when using updated header files.
Advice appreciated.
And this affects all global data where a symbol referring to the address was intended to be part of the ABI, while the size of the data was intended to be an implementation detail. In libnettle.so, the lists declared in nettle_meta.h are of this type, and in libhogweed.so, we have the ecc_curve structs.
- Get skein256 in (see skein branch), and possible skein512 too.
While interesting to have, is there any practical use of it?
Unclear. May be of more interest if it turns out to be significantly faster than sha3.
Regards, /Niels