Do we need to be afraid of something like malicious packages?
Yes, this is a real concern. We need some kind of trust infrastructure that allows users to use code that has been written by authors they trust easily and warns them about code that is not written by someone they trust. That’s very hard to do in a way that isn’t just security theater, however, and remains as future work.
3 Likes
Not sure if this has been suggested before, but wouldn’t blockchain technology be ideal for this? A signed hash for each release could be placed onto the blockchain, at which point no attacker can change it anymore (the absolute guarantee of a blockchain being that its history is immutable). If a malicious release is placed onto the blockchain, it can be invalidated by revoking the key for the signatures. I don’t know the details, but I think this kind of application is possible using Ethereum contracts. The downside is that doing a release will have a transaction fee.
I’m not clear how blockchain buys you anything that cryptographically secure hashes and signatures don’t.
4 Likes
I’m wondering if it could help protecting against attacks like this:
The advantage of storing the signature or hash in the blockchain is that an existing version can never be replaced with a compromised version, regardless of the validity of the signature: once a release is signed, it can’t be changed and signed again even if the attacker has the key. Of course the above attack could still be used to release a new compromised version, but that could be quickly detected by automatically notifying developers when a new release happens and maybe requiring multiple developers to sign off on a release, checking on multiple systems that they get the same hash.
Having a centralized registry protects against that already. Block chain is only useful here for as far as I can tell because it provides a distributed consensus on that the “official” registry is.
I am a newbie, and although I am very enthusiast about the power and productivity that Julia offers and more more confident about it’s potential for my activity, I wonder about where and when it is safe to use. For my research activities it is already OK (and adopted !). Since V1.0 is near, the question arises about using Julia in more industrial contexts.
The question addressed in The Node.js Ecosystem Is Chaotic and Insecure | by Casper Beyer | Commit Log | Medium leads to consider a trusted collection of packages.
The set-up of a “trusted” flag for packages, where you would have an independent, redundant, and trusted code review seems to be a difficult but necessary task.
I imagine that a kind of balance between the number of “trusted packages” and the strength/size of the community in charge of the review has to be considered.
What is your opinion on that matter ?
Thank you for the ref.
So I understand that a trusted package zone (with independent reviews) is not considered (or considered out of reach).
The idea is to trust authors and to provide signature checks to ensure that a given package update comes from a given trusted author (BTW what is the initial authentication process for package author ?)
I am not a security expert at all, so my insecure feelings about this are probably irrelevant. How do Debian distribution deals with this issue ?
Unfortunately, I feel the current system with METADATA.jl is too centralized.
(That it can take ages to get a new set of dependent packages or a new version of them registered is a large pain point currently)
I’m hoping that for Pkg3, a more decentralized trust system based on trusted organizations can be set up.
I’m not sure, but if a blockchain approach could be used for registering the trusted organizations, so that if one is later deemed untrustworthy, that can be revoked, might be a useful approach.
What about peer review?
If you want your package to be placed in the trusted area: you have to accept to review/read the code (and updates) of 3 other trusted packages (of equivalent size).
(My apologies if I push at open doors)