811–820 of 1001 posts
>This trains people not to update, 'coz stuff might break.
He says this as if it's a bad thing? Clearly depending on 300 libraries and auto-updating everything is a massive security risk.
Also very concerning that the dev's account has been suspended.
Earlier quoted context omitted.
What's actually malicious about the code? It's an infinite loop that logs to stdout. Sure, it's not what the library is supposed to do, but is it malicious code?
I think the intention is to cause downstream users to spinlock.
Earlier quoted context omitted.
If we are willing to admit that repositories like npm are useful, what can be done to mitigate these issues? Is there some tooling we can build?
A meta repository that lists versions reviewed by a trusted group of people? It would ad latency to bug fixes and limit the amount of available libraries, but would prevent single developers from taking down the ecosystem on a whim.
Earlier quoted context omitted.
Here's the proof: https://abc7ny.com/suspicious-package-queens-astoria-fire/64... Another article: https://www.njhomelandsecurity.gov/at-a-glance/9-21-20
All that proves is he’s got an interest in explosives. Believe it or not, explosives are a legitimate hobby for some folks. Unless there is other evidence, you’re just blindly speculating as to his intent.
Earlier quoted context omitted.
> it is recommended prominently in multiple places that they not blindly trust the code and actually inspect it before using it. The friction in this process is intended. There is nothing inherent in using packages that means you have to blindly trust the code, neither does providing a package mean you have to accept any more responsibility over providing a .php file (packages are just .php files with a few metadata…
> There is nothing inherent in using packages that means you have to blindly trust the code Agreed, but packages are an additional layer of abstraction, and you and I both know that the vast, vast majority of devs will not "look under the hood". Packages are often seen as a one-step plug-and-play solution. I don't want people to see my code that way. They should dive in and inspect it before using it (it is always wr…
> IMO, the advantage of my method is that (at least a few) more people will test/audit my code as opposed to if it was available as a package. Which increases the likelihood of any possible bugs in the code getting caught.
The person who unthinkingly installs a package will also unthinkingly include your script using 'require'.
The only thing that happens is anyone who is interested in auditing your code and uses composer is inconvenienced with busywork, that would otherwise be handled by composer, e.g. autoloading the library.
> Honestly, this is a personal thing for me. If people are using my code, I will feel responsible to some extent.
The point you made was that you would feel more responsibility for a package rather than a PHP file. There's no reason why this should be the case. Both methods result in your code being run by 3rd parties.
Here's my $.02: Packages are literally remote code exec vulns in the hands of package authors. At the very least, it takes them under a minute to break your app, simply by deleting their package. Read the article. This is not the first time it's happened, and it's not going to be the last. [0] I write backends (mostly in PHP, although not exclusively), and I release a lot of my code under libre licenses. But I don't…
I’m a self taught Python programmer. I haven’t don’t much front end. Why do some JS devs import tiny packages to do simple things? I don’t feel like I’ve seen this behavior in Python. Is it because browsers are an awful environment?
I got tired of copying and pasting the same classes between projects. The worse part was I'd add new features to the newer projects and when I would have to go back to work on something from a year or two ago I'd have to spend time backporting all the new code. I also don't like how bloated a bunch of the "popular" packages are. Why do something in 40kB of JS when you can do it in 3kB. Smaller is faster which is important to me because one of my main selling points is that I build modern-looking marketing websites that load and render under 5 seconds on a slow 3G connection.
Earlier quoted context omitted.
> There is nothing inherent in using packages that means you have to blindly trust the code Agreed, but packages are an additional layer of abstraction, and you and I both know that the vast, vast majority of devs will not "look under the hood". Packages are often seen as a one-step plug-and-play solution. I don't want people to see my code that way. They should dive in and inspect it before using it (it is always wr…
> Packages are often seen as a one-step plug-and-play solution. I don't want people to see my code that way. They should dive in and inspect it before using it (it is always written with this in mind - with extensive commenting and documentation). > IMO, the advantage of my method is that (at least a few) more people will test/audit my code as opposed to if it was available as a package. Which increases the likelihoo…
Yeah, everything I'm talking about is to make the latter a less likely occurance.
Here's my $.02: Packages are literally remote code exec vulns in the hands of package authors. At the very least, it takes them under a minute to break your app, simply by deleting their package. Read the article. This is not the first time it's happened, and it's not going to be the last. [0] I write backends (mostly in PHP, although not exclusively), and I release a lot of my code under libre licenses. But I don't…
You should still look over it and make sure it's not obviously malicious, but simply using forks or local repos of open source packages would probably save 98% of these kinds of headaches (with a 2% allowance for insecure/malicious open source code).
Earlier quoted context omitted.
The tool should take some blame here. I agree that it’s ultimately the developers fault for allowing code to be automatically injected from not fully trusted sources on minor updates, but the package manager makes it way too easy to do. For example, when I npm install a package, it defaults to specifying a semver compatible version in package.json, rather than doing the secure thing and pinning a version. But whether…
> I agree that it’s ultimately the developers fault for allowing code to be automatically injected Let's not do victim blaming here. This is ultimately the fault of the person deliberately updating their package to break other people's software.
Do your job and make sure the code that's running is what you expect. There's no valid excuse not to.
Earlier quoted context omitted.
Nah, open source software is "use at your own risk" and there's 0 guarantee for anything. All responsibility lies with the user. If you don't like that responsibility, don't use open source software without reviewing it first.
It’s one side of the coin. The other is, to do anything at all of practical use in 98% of jobs, day 1 is installing a tonne of OS stuff. It’s not practical to expect pretty much every dev to inspect 100% of that, even if that’s what they implicitly agree to do in the license.
If you have your package manager set up in a way that allows it to automatically upgrade/break your code, that's 100% on you.