Add JAR fingerprinting #3
Conversation
This reverts commit c98e688. This is actually a dual-license, and we're allowed to select BSD.
|
|
||
| #[tracing::instrument(level = tracing::Level::DEBUG, fields(entry = ?entry.name()), ret)] | ||
| fn is_class_file(entry: &ZipFile<'_>) -> bool { | ||
| entry.name().ends_with(".class") |
There was a problem hiding this comment.
I'm not sure when a class file wouldn't have this extension, but technically there is a magic-number you can read out as well: https://en.wikipedia.org/wiki/Java_class_file#Magic_Number
There was a problem hiding this comment.
There was a problem hiding this comment.
Good idea though, i'll use that, seems better
There was a problem hiding this comment.
Hmm, actually, to do that requires refactoring how to do the overall filter operation (since there's no way to "unread" those header bytes from the file).
I think I'm going to leave it as is for v1 of these fingerprints but we can always make a v2 that uses the magic number if we want later.
There was a problem hiding this comment.
That sounds fine to me. I was pointing it out more as a random bit of information that could be useful later but isn't really important now.
Overview
Note
This diff isn't quite as insane as it seems; the files under
tests/it/jar/expect/*.jarjust consist of the expected results from the tests intests/it/jar.rs.JARs are fingerprinted in two ways:
.classfiles. Each file inside is extracted and hashed; then sorted by their file names. Each hash is then hashed in order to derive a final hash for the overall JAR. Files that do not end with.classare ignored.Acceptance criteria
We can fingerprint JARs by their contents in a platform independent mannter.
Testing plan
Relying on automated tests.
Automated tests were constructed based on https://fossa.atlassian.net/browse/ANE-1701, which features JARs provided by users that we want to be certain we can work with.
Risks
None in particular.
References
https://fossa.atlassian.net/browse/ANE-1709
Checklist