On Fri, Sep 18, 2015 at 1:18 PM, Niels Möller <[email protected]> wrote: > Nikos Mavrogiannopoulos <[email protected]> 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__)) _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
