Hacker News new | past | comments | ask | show | jobs | submit login

Some people have argued that we should work inside expendable and tightly restricted VMs when doing anything that involves fetching packages from a repository using a package manager. I used to feel that was quite an extreme position but it does make sense because the risk we're discussing is really a consequence of two systemic vulnerabilities. Mainstream desktop operating systems have weak security models that aren't fit for purpose in our modern online-first world. And software development has evolved this strange philosophy that fetching someone else's code for every tiny thing is a good idea and code in someone else's repo is better than anything we could write ourselves. Those are both terrible ideas but neither is going to change quickly so maybe the sandbox advocates aren't so extreme after all?

Also did anyone else notice the timeline at the end of the article where it took 10 days to remove these packages from the repo? I could understand some hesitation if a package has something like debatable telemetry but surely behaviour like obfuscated code should result in an immediate block by default?




>Mainstream desktop operating systems have weak security models that aren't fit for purpose in our modern online-first world

Stop using propietary software first, then we will discuss your "security" rants. Perl users have been using CPAN since forever, so did LaTeX users with CTAN. Ditto with Emacs users with ELPA and NonGNU. No issues with addons.


This has little to do with being open or proprietary. CPAN is analogous to repositories we use with pip or npm today and most of what is involved is not proprietary on any of those platforms. The relevant differences are cultural and technical.

I don't think invoking CTAN as an example is very convincing. It's well known that there are only seven people in the universe who can actually program TeX and they probably have little interest in trying to infect each other with malware.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: