On 3 Sep 2017, at 03:10, Thiago Macieira <[email protected]<mailto:[email protected]>> wrote:
On Saturday, 2 September 2017 12:03:13 PDT Oswald Buddenhagen wrote: On Wed, Aug 30, 2017 at 12:45:44PM -0700, Thiago Macieira wrote: a) revert the 5.6 backport of 88a8feeacb9bdaff9ee06164424e407eb904cd10 so that 5.6.x will forever calculate Keccak, not SHA3; b) additionally backport 12c5264d9add1826d543c36d893db77262195fc6 to both 5.6> and 5.9, with the proper binary compatibility notices, so that people who need to can adapt their code to calculate Keccak. It won't be pretty, but it will work. I'm actually leaning towards (a) for 5.6 and (b) for 5.9. b) isn't legitimate for 5.9, either, as we can't add new api in a patch release (forward compat promise). so it would be a) for 5.9, too. the unfortunate effect is that this is a behavior change against 5.9.0, but 5.9.2+ will certainly have a longer lifetime than 5.9.x so far. While technically correct, I think this one is worth breaking the promise. Please note that we will break the promise anyway by adding QOperatingSystemVersion::AndroidOreo and we did it already for 5.9.1 for QOperatingSystemVersion::MacOSHighSierra. You can blame MSVC 2013 for this need. Adding a new enum value is acceptable for me in the 5.9 series. It's not strictly conformant with full forward compatibility, but any bug in 5.9.1 that is fixed in 5.9.2 could break that promise as well :) Reverting the SHA3 calculation might not be such a bad idea, though. if we wanted to be really conservative, we'd leave the old meaning of the sha3 constants and introduce realSha3 (or something to that effect) instead, in 5.10+. keccak aliases would be also provided for a smooth migration. Yeah, we can do that and we can also provide a #define to opt-in or out-opt of the real SHA3. Having people add a #define to their code if they need to keep compatibility is much easier than using an enumerator that isn't yet present in any released version. So I agree with Ossi here. I suggest we do: a) revert the previous enumeration values to calculate Keccak b) accept a forwards BC break by adding new values for SHA3 c) introduce a macro so people who need algorithm compatibility across versions can opt-in without introducing ugly #if in their code I think we should in any case also introduce the keccak enum values. I'm ok, if one of them aliases Sha3_512 (which we should then deprecate) and you add a new enum value for the correct Sha3 algorithm. Cheers, Lars
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
