Request: Integrity verification of dependencies

[hrj]

I would like the ability to verify that any artifact downloaded by sbt is as I expect it to be, before it gets used. This prevents man-in-the-middle attacks as well as malicious payloads from a compromised server.

Specifying a checksum for each dependency is one way to enable this.

Gradle has a plugin for this: checksum-dependency-plugin. That README describes the use-case very eloquently, so I won't repeat it here.

NPM also has support for this. The integrity properties are defined in package-lock.json.

There appears to be a sbt-plugin that does this https://github.com/josephearl/sbt-verify. However, it is not updated frequently. In any case, it would be nice to have this support in sbt itself. A plugin that gets downloaded could be compromised and would defeat its own purpose.

---

PS. I am sorry for not using discourse.lightbend. The website is not working for me.

[eed3si9n]

Doesn't Coursier already do checksum validation?
There's also sbt-pgp that checks for PGP signatures.

[hrj]

Doesn't Coursier already do checksum validation?

If the checksum is downloaded from the server then it doesn't count as "integrity" check, since a man-in-the-middle or compromised server can send a checksum that matches the compromise.

There's also sbt-pgp that checks for PGP signatures.

Signatures are better, because only the publisher can change them. So, it eliminates server and man-in-the-middle attacks. However, the publisher itself could become compromised over time.

What I am proposing (and it's not an original idea by any means), is to let the sbt user specify the checksum in their project. This eliminates all three vectors: MITM, server compromise and publisher compromise.

There is still a one-time-risk involved in calculating the checksum the first time. This can be mitigated in various ways like manual or automated functional verification. But after the checksum is committed to a repo, it protects against all future attacks.

[eed3si9n]

What I am proposing (and it's not an original idea by any means), is to let the sbt user specify the checksum in their project. This eliminates all three vectors: MITM, server compromise and publisher compromise.

ok. Before we go too deep into the solution space, maybe we should clarify the attack vectors that this intends to protect against.

• MITM could be a.) Maven Central is ok, but b.) attacker redirects the traffic to Maven Central to a compromised clone serving bad JAR?
• Is server compromise the local machine getting hacked?
• Is publisher compromise Maven Central getting compromised, or the library author getting compromised?

[hrj]

• MITM, yes exactly as you typed
• Server compromise is when the repository (eg. maven central) is serving malicious artifacts including any checksum files. Note: there are subtle variations of this such as shadowing.
• Publisher compromise is when the library author is compromised. This vector can't be protected against with signatures, because the attacker can create a new signature for the malicious artifact. (You could pin the signature, but that's equivalent to pinning the checksum)