Great feedback, @yorgos. Thank you.
I think it is important to clarify what we want to focus on, so I would recommend we consider the case of a compiled language (java, golang, rust, etc. etc.) which will help clarify that point further. For example, in one of these languages, a specific release of the library might have several different packages attached to it (i.e. different binary files - e.g. for different platforms).
I think we could define a package as “one or more binary files”. That definition nicely spans both the npm use-case as well as the compiled language use-cases. Even in the broadest sense of the term, where it indicates the source code, that source code would probably be distributed as a binary file (like zip or tgz).
Collaborative Objects on the other hand will be the basis of other entities like e.g. Issues and Patch Proposals, and Releases (which would be linked to a set of (signed) binary packages) seem to be a good fit.
I need to understand the Collaborative Object in more detail. The concepts in the referenced thread do not give a clear picture to me as to how it solves the issues of signed packages and avoiding supply chain attacks. From reading that previous thread, I don’t understand:
- How does a package consumer verify the signature? (or verify that the package has not been tampered with)
- How would the package signing be integrated into a Radicle workflow?
Is the Collaborative Object an idea that has been worked on, but there just isn’t any documentation for it yet? How can I learn more about this idea? How much of it has already been implemented?
As a new data point for this discussion, @cloudhead dropped this link in the heartwood Discord channel. This appears to be a very handy TypeScript library for signing and verifying npm packages. It also seems to leverage the Ed25519 signature that Radicle uses:
The problem remains: where does the checksum live? But this library would be a handy tool for generating the checksums.