On Wed, Aug 19, 2015 at 1:14 PM, Niels Möller nisse@lysator.liu.se wrote:
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com 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_%5B0-9%5D*_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