search

CSCfi / rems

Resource Entitlement Management System is a tool for managing access rights to resources, such as research datasets.
MIT License
51 stars 22 forks source link

Verifiable Releases #3178

Open hallundbaek opened 1 year ago

hallundbaek commented 1 year ago

Is your feature request related to a problem? Please describe. I would like to be able to verify that the released jar file that I download is the one that you intended to release, that there has been no man-in-the-middle attack.

Describe the solution you'd like The ideal solution, in my opinion, is the one described here. Which basically entails that the distributor downloads the file after release, verifies that it is indeed the one you intended to release, create a signature and upload that signature alongside the released jar file.

Describe alternatives you've considered The common solution is to add a hash of the released artifact, which definitely improves security, but in the case where an attacker has access to change the artifact, they might also have access to change the published hash, at which point the scheme fails. Which is why a signature based on a verifiable public key is preferable.

Macroz commented 1 year ago

Hi,

I think release signing is a possibility, but it is not currently on our plans. Release commits are signed by the developers, so you could alternatively build the JAR yourself. The complete release instructions are here. Note that many of our dependencies are not signed themselves, so us adding a rubber stamp may not add much.

Currently the files that are included in the GitHub release page are delivered fresh from the build servers by the developers, so the margin for MITM in this phase should be small.

The released JAR is built by our CI environment, so that would essentially have to be an environment that is trusted, even if it signs each JAR. The delivery to the GitHub release page is done by a developer that uploads the JAR to GitHub manually. This is another point where the JAR could be signed, but thorough testing of said JAR is not so simple. Each developer would have to maintain PGP signing, and the public keys would have to be distributed from a trusted location.

The organizations that you must trust in the current process are therefore CircleCI (building & signing the JAR), GitHub (project source code, release JAR), CSC (access rights to REMS project in the services and to developers who make the code and attach the JAR).

What do you think?

hallundbaek commented 1 year ago

I agree, PGP signing would be excessive, especially since release commits are signed by the developers, a point I had entirely missed.

It would be functionally equivalent as far as I can see, to go the simpler route of adding a digest to the release. Ideally in a place that is easily referenced from an automated CI system.

But that digest alone would be very nice, if not for protection against MITM attacks, then just to confirm that nothing has been corrupted during download.