Protobuf Kotlin Core: Published artifact on Maven Central has the same SHA1 as a previous minor version

[dhladik]

What version of protobuf and what language are you using?
Version: v3.25.5 & 4.28.2
Language: Kotlin

What operating system (Linux, Windows, ...) and version?
MacOS 18

What runtime / compiler are you using (e.g., python version or gcc version)
Kotlin 2.0.20 & Java 21

What did you do?
Steps to reproduce the behavior:

1. Go to 'Maven 4.28.2 page'
2. Go to 'Maven 4.28.0 page'
3. Observe the same hash
4. Tools like Trivy that depend on correct properties and manifests compare hashes, these are the same, and a CVE is reported

What did you expect to see
A different hash

What did you see instead?
The same hash

Anything else we should know about your project / environment
We are using automated CVE scanning in our pipelines using Aquasecurity’s Trivy tool. This has uncovered an interesting case with the CVE-2024-7254. The artifact for the library Protobuf Kotlin is missing a pom.properties file and it’s manifest is also incomplete.

What’s worse, is that the computed SHA1 hash for both 3.25.0 and 3.25.5 are the same, which results in Trivy confusing the 3.25.5 version for 3.25.0 which has the vulnerability. This behaviour was observed in previous versions of your library, as well as newer ones, 4.28.0 and 4.28.2 respecitvely.

You can read more about this issue on Trivy’s GitHub: aquasecurity/trivy#7567

We’d like to ask you to fix this, as filtering CVEs is not really maintainable and will have to be done for potentially unlimited number of CVEs. We are also getting this reported with each build and will have to explain the situation to our customers.

Thank you very much.

[vijaykramesh]

We are experiencing the same with 4.27.5 having the same SHA1 hash as 4.27.1 (which is causing trivy to think we still have the vulnerability).

Furthermore running a diff on protobuf-kotlin-4.27.1.jar and protobuf-kotlin-4.27.5.jar shows the only difference is in .DS_Store files, which makes me think that 4.27.5 wasn't actually properly published and it is identical to 4.27.1 (i.e., the vulnerability still exists in the 4.27.5 package, and that's why the SHA1 is the same)

[deannagarcia]

Thanks for reporting this issue! I'm currently working on making our Kotlin manifest more OSGi-like to include more information including version numbers which should solve this issue.

[deannagarcia]

I believe this should be fixed with #18833 and corresponding cherrypicks so that the next version we release will be distinct. Please feel free to reopen if you see this issue resurface!