personally disagree all of this is will be manageable - we are just not used to it yet not saying avoidable but the impact is imho manageable eg codelinting or dependency-linting in all steps of the tool chain time delay until it's available to 100% etc
We really need to rethink how open source works. Systems built on trust work when n=small, but they don't scale.https://twitter.com/KrauseFx/status/1067124100332744704 …
Step 
Go through the most popular inactive open source libraries
Step 
Reach out to author and ask to help out
Step 
Get push access and release a compromised version
Step 
Reach 2 million applications within a week
https://github.com/dominictarr/event-stream/issues/116 … pic.twitter.com/OZRWpMJCQ6
Go through the most popular inactive open source libraries
Step Reach out to author and ask to help out
Step Get push access and release a compromised version
Step Reach 2 million applications within a week
https://github.com/dominictarr/event-stream/issues/116 … pic.twitter.com/OZRWpMJCQ6
Show this thread
-
-
-
Agreed, I think automation will help make the transition to a scalable system. But trusting random strangers doesn't work without those adjustments
-
agree i think it will come down to "automation" plus a "standard" that can be automatically checked (whatever that one will be and is actually useful)
-
Makes me think of pilot checklists, which massively reduced accidents!
End of conversation
New conversation -
-
-
I don't know that I agree with that. The issue I see isn't that trust can't be used, it's that it's all done manually now which absolutely doesn't scale.
-
Yep, that's more along the lines of what I intended to say! If we want to rely on manual trust then we need to put up guardrails elsewhere
End of conversation
New conversation -
-
-
More proof, less trust.
-
Agreed!
End of conversation
New conversation -
-
-
I'm curious whether your conclusion from this starting point (which I agree with) is that we should make many small systems, or figure out a way to allow communities to scale using something other than trust as currency.
-
Too many thoughts to fit into a tweet, but mostly the latter!
-
as far as i can see the system worked. Issue discovered because it was open and those who uses and update dependencies blindly got burned and lesson learned ? I have a hard time seeing it perform better ;)
-
The issue with NPM is that the attack surface of a dependency-of-a-dependency is completely opaque. Also popularity != risk mitigation in the way it is with some other projects.
-
Npm for sure overdone it with the fine grained modularity. there are basic stuff you can do today to make your life better in npm land. Like use ‘npm ci’ instead of ‘npm install’ which not only means your build stays on exact transitive dependencies but also faster
End of conversation
New conversation -
-
-
I think systems which security is differently designed can be both secure and scale See https://youtu.be/vrbmMPlCp3U?t=3308 … (from 55'00'' to 56'30''... then the whole talk if you're interested) This could be retrofitted to npm fairly easily IMO
-
(the patronizing tone is unfortunate :-/)
End of conversation
New conversation -
-
-
I disagree that this problem is endemic in OSS. Distros like Debian and Red Hat have existed for 20+ years with systems in place to protect against this.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
@KrauseFx are you pushing permission-restricted platforms like Android?Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.