8 ms·

They haven't released the source, and the compiled versions are non-trivial to diff (e.g. there are nondeterministic numbers from the clojure compiler that seem

They haven't released the source, and the compiled versions are non-trivial to diff (e.g. there are nondeterministic numbers from the clojure compiler that seem to have changed from one to the other, and .clj files have been removed from the jar). The old version has `hash=1bb88f5`, which is a public commit: https://github.com/metabase/metabase/commit/1bb88f5 https://github.com/metabase/metabase/commit/1bb88f5 Whereas the new version has `hash=c8912af`, which is not: https://github.com/metabase/metabase/commit/c8912af https://github.com/metabase/metabase/commit/c8912af

MuffinFlavored 3y ago
I didn't even know you could have a "private" commit on GitHub/an open source repo like that.
- JJJollyjim 3y ago
  Oh, I didn't mean to imply you can, just that it's 404... presumably it exists in a repo checked out on someone's machine, and maybe in a separate private Github repo.
  - MuffinFlavored 3y ago
    This is silly on my end (I woke up early and have time to kill)... Also like, note: I would never publicly disclose whatever I find, I'm just curious I observed exactly what you said about the Clojure filenames not matching up, etc. etc. #!/bin/bash # Variables DIR1=~/metabase-v0.46.6.jar.src # decompiled with jd-cli / jd-gui (java decompiler) DIR2=~/metabase-v0.46.6.1.jar.src # decompiled with jd-cli / jd-gui (java decompiler) # Function to create fuzzy hash for each file in a directory create_fuzzy_hashes() { dir=$1 for file in $(find $dir -type f) do ssdeep -b $file >> ${dir}/hashes.txt done } # Create fuzzy hashes for each file in the directories create_fuzzy_hashes $DIR1 create_fuzzy_hashes $DIR2 # Compare the hashes ssdeep -k $DIR1/hashes.txt $DIR2/hashes.txt How far do you think this gets us (fuzzy hashing)? I was thinking this, or binary diffing the .class (instead of the "decompiled" .java)?
    - JJJollyjim 3y ago
      I found something which is clearly a security fix, using the same idea but more naive: just diffing at the lengths of the decompiled files. It's not at all clear how the issue I found would be triggered by an unauthenticated user though.
batch12 3y ago
I could be wrong (and often am), but I am seeing updates related druid client authentication.

MuffinFlavored 3y ago

I didn't even know you could have a "private" commit on GitHub/an open source repo like that.

JJJollyjim 3y ago
Oh, I didn't mean to imply you can, just that it's 404... presumably it exists in a repo checked out on someone's machine, and maybe in a separate private Github repo.
- MuffinFlavored 3y ago
  This is silly on my end (I woke up early and have time to kill)... Also like, note: I would never publicly disclose whatever I find, I'm just curious I observed exactly what you said about the Clojure filenames not matching up, etc. etc. #!/bin/bash # Variables DIR1=~/metabase-v0.46.6.jar.src # decompiled with jd-cli / jd-gui (java decompiler) DIR2=~/metabase-v0.46.6.1.jar.src # decompiled with jd-cli / jd-gui (java decompiler) # Function to create fuzzy hash for each file in a directory create_fuzzy_hashes() { dir=$1 for file in $(find $dir -type f) do ssdeep -b $file >> ${dir}/hashes.txt done } # Create fuzzy hashes for each file in the directories create_fuzzy_hashes $DIR1 create_fuzzy_hashes $DIR2 # Compare the hashes ssdeep -k $DIR1/hashes.txt $DIR2/hashes.txt How far do you think this gets us (fuzzy hashing)? I was thinking this, or binary diffing the .class (instead of the "decompiled" .java)?
  - JJJollyjim 3y ago
    I found something which is clearly a security fix, using the same idea but more naive: just diffing at the lengths of the decompiled files. It's not at all clear how the issue I found would be triggered by an unauthenticated user though.

batch12 3y ago

I could be wrong (and often am), but I am seeing updates related druid client authentication.