On Mon, 2017-05-22 at 13:18 +0200, Niels Möller wrote: > Nikos Mavrogiannopoulos <[email protected]> writes: > > > > 1. 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.
A backwards compatible approach is to leave the nettle_hashes accessible and provide the function as well. That will not be any more broken than 3.3 is, and would allow 3.3 programs to be linked with 3.4 without recompilation. You can warn on use of nettle_hashes with the attached patch, most likely you can introduce a custom message as well with the replacement function. > > 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. I think we are moving to a setting where we have fewer and better studied/optimized options encryption/hashing in contrast with the pre- AES era on which we were including multiple ciphers in crypto libs, in the hope that few of them would be good. A new hash as such, I don't think has any use today as most of the use cases would be related to digital signatures or standard protocols, which have no reason to include a skein variant (for the majority of protocols sha3 isn't there yet either). regards, Nikos
From b9df33d888a5fa737342fdf42509538e95569367 Mon Sep 17 00:00:00 2001 From: Nikos Mavrogiannopoulos <[email protected]> Date: Mon, 22 May 2017 15:38:02 +0200 Subject: [PATCH] nettle-meta.h: warn on use of nettle_hashes variable Signed-off-by: Nikos Mavrogiannopoulos <[email protected]> --- nettle-meta.h | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/nettle-meta.h b/nettle-meta.h index 14b5e48..a95ae69 100644 --- a/nettle-meta.h +++ b/nettle-meta.h @@ -114,8 +114,15 @@ struct nettle_hash (nettle_hash_digest_func *) name##_digest \ } +#define _NETTLE_GCC_VERSION (__GNUC__ * 10000 + __GNUC_MINOR__ * 100 + __GNUC_PATCHLEVEL__) +#if _NETTLE_GCC_VERSION >= 30100 +# define _NETTLE_ATTR_DEPRECATED __attribute__ ((__deprecated__)) +#else +# define _NETTLE_ATTR_DEPRECATED +#endif + /* null-terminated list of digests implemented by this version of nettle */ -extern const struct nettle_hash * const nettle_hashes[]; +extern const struct nettle_hash * const nettle_hashes[] _NETTLE_ATTR_DEPRECATED; extern const struct nettle_hash nettle_md2; extern const struct nettle_hash nettle_md4; -- 2.9.4
_______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
