[Development] Backporting the Keccak change

[Lars Knoll]

On 3 Sep 2017, at 03:10, Thiago Macieira <thiago.macieira at intel.com<mailto:thiago.macieira at intel.com>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170904/df2c8362/attachment.html>