Live data from Hacker News

Devs unknowingly use “malicious” modules snuck into official Python repository

arstechnica.com

71–80 of 119 posts

Re: Devs unknowingly use “malicious” modules snuck into official Python repository

#71

I think there is a value in upgrading the cheeseshop to use "verified maintainers" - it should be simple to do a first pass of "the person who signed the hash of this module has also verified they own the domain requests.kreitz.org by publishing that public key at that domains root" Even more useful might be domain/keys/kreitz/publickeylisting The key signing party is much harder to arrange but is easier to be confid…

> I think there is a value in upgrading the cheeseshop to use "verified maintainers" - it should be simple to do a first pass of "the person who signed the hash of this module has also verified they own the domain requests.kreitz.org by publishing that public key at that domains root"

That sounds useless. An attacker could verify that they own evilattacker.com & publish their malicious packages there.

I don't think a web of trust is the answer here, because it doesn't really matter if the attack is anonymous or not, and if only trusted people can publish packages, trust will be given more readily to encourage new programmers to contribute.

I think a reputation/review system is better, like docker search's star count, or metacpan's ++ rating.

Re: Devs unknowingly use “malicious” modules snuck into official Python repository

#72
post #36

Earlier quoted context omitted.

Debian has ~3000 packages, and every single package had an identified maintainer... As of yesterday npmjs had 516,132 packages, which was an increase of 373 since the day before. Debian's 3000 packages is a couple of weeks of npmjs activity. Even if you stripped out the unnecessary, abandoned, or duplicate packages you're still looking at a something significantly different to Debian. For what it's worth I think a we…

The culture around what should be in a package is vastly different. Node has left-pad. Debian has stuff like Apache. Sure, those are radical examples, but the barrier to entry for Debian is pretty high (as is the standard for quality) vs npm where anyone can put whatever out there. How do things like left-pad even come to be widespread dependencies? Does the node development process involve a lot of "gee I wonder if…

But the large number of packages available, even for seemingly trivial features, are what makes NPM popular and successful. You jest at left-pad, but there's real value in simple libraries they might only be "a few lines of code" because an app is made up of a large amount of "simple features" strung together.

Not to mention the code reuse factor.

If npm took the route of debian's verification/certification, you might end up with no libs at all!

Re: Devs unknowingly use “malicious” modules snuck into official Python repository

#73
post #66

Earlier quoted context omitted.

> Many have suffered and do not even bother with Ruby apps anymore. These sort of grandiose statements have of course existed on the Internet for decades, but with the rise of demagogues like Trump, we see that such statements can be readily believed en masse without a second thought. Could you provide data or numbers explaining that Ruby's package management system is a factor in new apps not being built in that lan…

Don't you think bringing Trump into this is an example of the same things you admonish GP for?

How so? My point is that stating something as a fact without proof can have serious consequences.

Re: Devs unknowingly use “malicious” modules snuck into official Python repository

#74
post #56

Earlier quoted context omitted.

You mean that every time you write a new project you write your own request parser, your own server, your own web framework, your own database access libraries, etc. from scratch? Packages taken over include misspelling of urllib. What exactly do you propose as an alternative here? I'm all for limiting bloat, but your rant here seems completely inappropriate for the issue bring described.

> You mean that every time you write a new project you write your own request parser, your own server, your own web framework, your own database access libraries, etc. from scratch? No, they mean that we need a better method than trusting some random popular GitHub / PyPy / npm whatever storage and delivery mechanism. Strong core language libraries ("batteries included"), that come with your distribution of the langu…

Java ecosystem has just as many libraries, and yet you don't see this problem. Why is that? Maven Central is just as available to add to (last i checked, all you need is a public GPG key registered to the MIT public gpg server).

Re: Devs unknowingly use “malicious” modules snuck into official Python repository

#75
post #17

The casual culture of pulling in hundred of dependencies, and mushrooming language specific package managers is ridiculously insecure and has to go. There is no way for anyone to know what all this code is doing, there is little way to verify updates and its simply untenable. If some developers like this sort of unsafe practice it should be strictly limited to their machines and in no way make it across in any form a…

> Users should simply boycott such user hostile developers and languages I await with interest your newsletter to "the internet" on how to boycott JavaScript.

Server side Javascript (which has the abovementioned dependency problems) can be boycotted just as easily as any other language, the JS monopoly effect applies only to the front end.

Re: Devs unknowingly use “malicious” modules snuck into official Python repository

#76
post #17

The casual culture of pulling in hundred of dependencies, and mushrooming language specific package managers is ridiculously insecure and has to go. There is no way for anyone to know what all this code is doing, there is little way to verify updates and its simply untenable. If some developers like this sort of unsafe practice it should be strictly limited to their machines and in no way make it across in any form a…

Bulshit. The benefits of this "casual culture of pulling in hundred of dependencies" vastly outweigh the harm. I'll be assembling another $6000 job that will take me maybe 12 hours to complete while you write your compiler, from scratch, in your own assembler, made for your own cpu, that you youre gonna cook up from a bucket of sand you collected yourself, from a sandpit you trust.

Re: Devs unknowingly use “malicious” modules snuck into official Python repository

#77
post #2

One nice thing about languages like C is that a lot of programmers just avoid dependencies because dealing with them kind of sucks. That's one solution to this problem.

The node.js community sees that very different and thats one aspect i dont understand, the blinded trust in dependencies. A midsize project will need quickly a 1000+ dependencies and we have to trust them all.

Re: Devs unknowingly use “malicious” modules snuck into official Python repository

#78

Earlier quoted context omitted.

> Users should simply boycott such user hostile developers and languages I await with interest your newsletter to "the internet" on how to boycott JavaScript.

Server side Javascript (which has the abovementioned dependency problems) can be boycotted just as easily as any other language, the JS monopoly effect applies only to the front end.

It's also worth noting that it's pretty easy to do JavaScript development and just not use NPM, so no-one needs to boycott JavaScript, just that particular installation approach.

Re: Devs unknowingly use “malicious” modules snuck into official Python repository

#79

This is a rehash of: https://hackernoon.com/building-a-botnet-on-pypi-be1ad280b8d... Interestingly, my fake system packages have been downloaded about 480 000 times so far this year

Ouch, and thanks for being proactive getting those names squatted

Re: Devs unknowingly use “malicious” modules snuck into official Python repository

#80
post #56

Earlier quoted context omitted.

You mean that every time you write a new project you write your own request parser, your own server, your own web framework, your own database access libraries, etc. from scratch? Packages taken over include misspelling of urllib. What exactly do you propose as an alternative here? I'm all for limiting bloat, but your rant here seems completely inappropriate for the issue bring described.

> You mean that every time you write a new project you write your own request parser, your own server, your own web framework, your own database access libraries, etc. from scratch? No, they mean that we need a better method than trusting some random popular GitHub / PyPy / npm whatever storage and delivery mechanism. Strong core language libraries ("batteries included"), that come with your distribution of the langu…

> Strong core language libraries ("batteries included"), that come with your distribution

There's a running joke in python that stdlib is where modules go to die. Stdlib by definition needs to be more dependable and stable than other places. But that reduces the innovation. There's a reason urllib is terrible to use and we're on urllib3 now, yet the nicest solution (requests) is not included.

See http://www.leancrew.com/all-this/2012/04/where-modules-go-to... This applies to some extent to all languages / runtimes.

Post reply on HN