Ensure that MurmurHash3_64.update handles ArrayBuffer input correctly, to avoid hash-collisions (issue 12533)
#12534
Conversation
…ctly, to avoid hash-collisions (issue 12533) Different fonts incorrectly end up with *identical* hashes, despite having different /ToUnicode data. The issue, and it's very interesting that we've apparently not seen it before, appears to be caused by the fact that different /ToUnicode entries share the *same* underlying `ArrayBuffer`, which thus becomes problematic at the `const dataUint32 = new Uint32Array(data.buffer, 0, blockCounts);` line. The simplest solution thus seem to be to just *copy* the input, when it's an `ArrayBuffer`, rather than using it as-is. (Note that if we'd stringified the input, when calling `MurmurHash3_64.update`, the issue would also have been fixed. In this case, we're already creating an unique TypedArray.)
|
/botio-linux preview |
From: Bot.io (Linux m4)ReceivedCommand cmd_preview from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.67.70.0:8877/4ff5106137b8d70/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/4ff5106137b8d70/output.txt Total script time: 3.91 mins Published |
|
/botio test |
From: Bot.io (Linux m4)ReceivedCommand cmd_test from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.67.70.0:8877/5ff6ae427aa90dd/output.txt |
From: Bot.io (Linux m4)FailedFull output at http://54.67.70.0:8877/5ff6ae427aa90dd/output.txt Total script time: 25.87 mins
Image differences available at: http://54.67.70.0:8877/5ff6ae427aa90dd/reftest-analyzer.html#web=eq.log |
|
Nice find; that's a really interesting one! /botio-linux makeref |
From: Bot.io (Linux m4)ReceivedCommand cmd_makeref from @timvandermeij received. Current queue size: 0 Live output at: http://54.67.70.0:8877/1fc654d81162cb8/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/1fc654d81162cb8/output.txt Total script time: 23.83 mins
|
Different fonts incorrectly end up with identical hashes, despite having different /ToUnicode data.
The issue, and it's very interesting that we've apparently not seen it before, appears to be caused by the fact that different /ToUnicode entries share the same underlying
ArrayBuffer, which thus becomes problematic at theconst dataUint32 = new Uint32Array(data.buffer, 0, blockCounts);line. The simplest solution thus seem to be to just copy the input, when it's anArrayBuffer, rather than using it as-is. (Note that if we'd stringified the input, when callingMurmurHash3_64.update, the issue would also have been fixed. In this case, we're already creating an unique TypedArray.)Fixes #12533