On Fri, Sep 18, 2015 at 1:18 PM, Niels Möller nisse@lysator.liu.se wrote:
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
I think the best approach is not to export such functions at all if they are not intended to be used.
I can understand that point of view, but it's not going to happen to Nettle any time soon.
Breaking the ABI it for a security fix is not that nice.
It's possible to do a "security fix-only" release which only enables crt hardening for rsa_pkcs1_sign_tr (basically, your patch from a few weeks ago). Do you think that is motivated? In that case, I agree that we shouldn't make any incompatible changes to internal but visible functions. My plan has been to *not* do any bug-fix-only relase, but do do a new regular release reasonably soon, including the crt-related improvements, the updated sha3, and possibly some other minor improvements.
That seems reasonable, but still it doesn't change the fact that this will be a bug fix release, as it will include bug fixes :)
As for _rsa_blind, my thinking is that it's a bit bad to change it's behaviour not because it will break applications that misuse internal functions, but because it might break such applications in unovious ways. So I'm now leaning towards simply removing those functions (making them static), which should offending applications fail obviously, with a link failure.
Why break them at all? The issue is that if you don't bump the so version some programs will stop working in a distribution if nettle is upgraded. Why not make a new symbol which is kept internal, and the old symbol remains exported and is simply a wrapper to the new symbol that keeps compatibility?
We made similar changes fairly recently (pkcs1_signature_prefix, dropped in the 2.5 release three years ago), and as far as I remember, there were no big problems with that.
I think the usage and visibility of nettle has changed much since then. However, it can be that there is no user of this function, or there may be a single user of which you'll break his already shipped program. There is no way you can tell how may programs rely on that. That's why I don't see a reason to break the ABI within a non major release. You may mark this function (and all the other internals) as deprecated [0], and plan for retiring them in the next so version bump. Doing it earlier you take a bet which may or may not affect some users of nettle.
regards, Nikos
[0]. Using __attribute__ ((__deprecated__))