On Wed, Aug 19, 2015 at 1:14 PM, Niels Möller <[email protected]> wrote: > Nikos Mavrogiannopoulos <[email protected]> writes: > >> Not for my use cases. What I worry most is how would applications detect the >> correct sha3 being in place? > I'm not sure how it should be handled. If we think of it as a bugfix, > the soname would be the same, and some applications using sha3 might want > some runtime check. For the serpent byteorder fix (nettle-2.2), we > didn't bump the soname.
No I also don't think we need to bump the soname. nettle_version_major() and nettle_version_minor() could be used for runtime checks. > The important question is, what applications are using Nettle's current > sha3 code? https://codesearch.debian.net/search?q=sha3_[0-9]*_update > finds only the Haskell bindings. Are there any Haskell people on this > list who can comment on any need for bug-compatibility? >> Would there be a new definition in the header >> or should applications check the nettle version number? > For compile-time check, we could add an > #define NETTLE_SHA3_NIST 1 That would be best. > in sha3.h. Would that be of any help for applications? For runtime > checks, I think the simple (but not very beautiful) way is to hash the > empty string and look at the output. I wouldn't really want applications to do that. The best would be to depend on nettle 3.2 and if they really want compatibility with 3.1 then they should use the nettle_version_xxx() functions. > I'm afraid it will cause confusion to fix this without increasing > the version number in some way. Do you think that a nettle-3.2 release > (with fixed sha3, and a couple of other smaller changes) is needed soon? That would be really helpful. regards, Nikos _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
