> Trusting any single author is a single point of failure — eventually the author of one of the packages you depend on will get compromised and an attacker will publish a malicious package.
Thanks, this is exactly the sort of thing I had in mind when writing the "Making _ trustworthy"[0] section and exactly the sort of conversation I was hoping my post would prompt. One benefit I'm hoping to get from keeping the `_` sub-packages as simple/self-contained as possible is that that sort of supply-chain attack will be easier to spot (e.g., with a 0-dependency file, you couldn't use an attack like the event-stream incident, where a dependency was swapped out for a malicious copy – the malicious code would have to be in the repo itself).
Of course "easier to spot" ≠ "won't happen", which is where your other point comes in:
> To combat this, you need package validation by multiple independent identities. The classic ways to do this are to have multiple people sign a package using PGP
Someone else made a similar point in an r/programminglanguages comment[1] in response to part 1:
> One thing I'd like to see package managers adapt, though, is quorums for publishing. A simple majority quorum of amongst 3+ people would naturally make hacking much more difficult
Do you happen to know any details about how something like that could be put into practice? I agree that it seems like something that'd be worth investing in, as an ecosystem and would be interested in any info/thoughts other care to share.
The machinery for quorums could be built on top of PGP. Multiple people can sign a package, and the trustworthiness of their endorsements can be evaluated based on a web of trust — including by downstream users, so you don't actually have to rely on the robustness of the package manager's authentication at the moment of upload.
Because PGP is not universally loved, I think it's important to reiterate that the fundamental theory behind quorums is just multi-factor auth. But PGP does solve some of the hardest parts.
From there it's a matter of defining which authorities to trust, and then gating acceptance of a release once a quorum is reached (however that quorum is defined).
Finally, the idea needs buy-in and participation from package authors, which could be encouraged by privileging releases with multiple endorsers.
Thanks for sharing these ideas. Raku is actually in the process of migrating to a new package ecosystem, so this could be an ideal time to get something like this set up. I'm not sure how much work would be involved from a technical standpoint, but I've opened an issue[0] to ask the maintainer of our ecosystem package repository; hopefully we'll be able to implement a system somewhat along these lines.
The main thing the central package manager has to do is support uploading some significant number of .asc PGP signature files (max 10? max 100?) alongside a specific package. That's enough for third parties to start experimenting.
The package manager might also boost search rankings for packages with multiple sigs, but it's just one contributing measure of "kwalitee", like docs, a complete metadata file, etc.
Thanks, this is exactly the sort of thing I had in mind when writing the "Making _ trustworthy"[0] section and exactly the sort of conversation I was hoping my post would prompt. One benefit I'm hoping to get from keeping the `_` sub-packages as simple/self-contained as possible is that that sort of supply-chain attack will be easier to spot (e.g., with a 0-dependency file, you couldn't use an attack like the event-stream incident, where a dependency was swapped out for a malicious copy – the malicious code would have to be in the repo itself).
Of course "easier to spot" ≠ "won't happen", which is where your other point comes in:
> To combat this, you need package validation by multiple independent identities. The classic ways to do this are to have multiple people sign a package using PGP
Someone else made a similar point in an r/programminglanguages comment[1] in response to part 1:
> One thing I'd like to see package managers adapt, though, is quorums for publishing. A simple majority quorum of amongst 3+ people would naturally make hacking much more difficult
Do you happen to know any details about how something like that could be put into practice? I agree that it seems like something that'd be worth investing in, as an ecosystem and would be interested in any info/thoughts other care to share.
[0]: https://raku-advent.blog/2021/12/11/unix_philosophy_without_...
[1]: https://www.reddit.com/r/ProgrammingLanguages/comments/raau0...