Create a problem statement for JAR verification

[danielcompton]

There is a real concern that Clojars or other JAR hosts could be compromised in such a way that compromised JARs are distributed. It would be good to create a way to verify that the JARs we receive are the JARs that the creator intended to ship.

There are all sorts of technical solutions that could be devised, but before we go down that route, we need to define a problem statement of what we are and aren't trying to achieve, and outline the threat models we want to protect against.

Some of the things to consider:

• Development time downloads vs production time downloads
• Who/what is trusted/untrusted (there is currently trust in the CA ecosystem for SSL delivery of JARs, in the Clojars maintainers, in the developers that deploy the code)
• Maven will call out to multiple repos for an artifact and use the one that responds first (I think?)
• How (if) to handle uberjars which package multiple JARs
• How to integrate with the current Maven ecosystem (tooling and mirrors)
• Deletions need to be possible, at least for legal reasons
• Do we want to verify which packages are meant to be in a JAR? (to prevent one JAR providing classes/files in a package that shadows another JAR)

Prior art:
https://theupdateframework.github.io
https://lwn.net/Articles/629426/
https://github.com/docker/notary
https://github.com/theupdateframework/pep-on-pypi-with-tuf
https://github.com/theupdateframework/pep-maximum-security-model

[danielcompton]

See also https://malcolmsparks.com/posts/library-distribution.html