Discussion: Package Signing & Security

[yorgos]

@cloudhead

• The natural place for the checksum to live is in the radicle repository of the project/package/binary; reason being that the rules and security model around a certain project are self-contained, within that repo.

+1

@cloudhead

• Since everything published is always signed, the question becomes: by who?
• You may consider a release/pkg trustworthy if it is signed by a certain key. Usually the trusted keys are the ones controlled by maintainers/authors of the project. These are modeled as “delegates” in radicle.

I think that is what the entries valid_when and signed_off_by try to capture in the data structure proposed here .

@cloudhead

• There isn’t much sense in separating checksum from package; since radicle repositories are the ideal storage for both, and one without the other is useless anyway.

hmmm… what if the binary is a few hundred MB ? what if it is a container image of a few GB ? would we still want to store these in Git (or did I misunderstand what you mean here)?

I was thinking that while the checksum (and probably a descriptor / reference to the binary package) should live inside the radicle repository, we could decouple storage/location of that binary, so that it could live… anywhere. All we need on our side is to be able to reliably point to that location and leave the actual storage / content delivery to existing, well-established 3rd party services.

@cloudhead

• Collaborative objects can add functionality, but the essentials needed here are really just storing a file in the repo and creating a git ref, that’s all. CRDTs (which is what collaborative objects offer) are probably overkill for now.

for the above 2 reasons, I would like to see us start with a Conflict-Free Replicated Data Type (CRDT) that we can build upon, rather than some other more basic structure that will soon limit what is possible with Radicle Releases.

Looking forward to your thoughts (whenever you have some time).

(disclaimer: I am perhaps a little sensitive / overly focused in this area as my day job is largely around release engineering).