Live data from Hacker News

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

arstechnica.com

91–100 of 119 posts

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

#91

Earlier quoted context omitted.

I love Python for this. Big standard library. I hate JavaScript for this... So many weird legacy issues that generally get resolved with libraries. Though ES6 went a long long way.

ES6 does not fix the left-pad issue; there is a propensity to use a package to get one small function vs using a library of common helper functions (which is somewhat what e.g. ES6 helps with...less need for underscore or similar). You pretty much don't need jquery now, but so many things depend on it for convenience / backward compatibility / because it's so insanely battle-tested that you know that it will work or…

> ES6 does not fix the left-pad issue

Actually, for that particular problem... https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

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

#92

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.

Sure, and I actually like java, but you know, blanket "don't use javascript" because it happens to have package manager is dumb. I mean, java has maven. It just so happen to be that package managers are useful things and helps to avoid massive mess in anything larger then hello world. Especially if we are speaking about open source projects.

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

#93
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.

Damn straight. While you're assembling that $6k job, I'm selling your client's data from out from under them. Everyone gets paid.

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

#95
post #74

Earlier quoted context omitted.

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).

It's not just as available to add to; you can only add to Central through one of three approved hosts unless your project has a special exception. And those hosts all involve an actual review of your artifact, its signature, and your POM. I've never done it, but it at least sounds like there's a process where you need to convince 3 or more people that adding your package is a good idea and will not hurt security. Tha…

you don't need to convince anyone other than the central hoster - provide an issue in the tracker with the information required (see the myriad of existing projects https://issues.sonatype.org/projects/OSSRH/issues/OSSRH-3462...).

It's not a free-for-all like npm, but may be npm can learn a thing or two.

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

#96
post #63
post #34

Earlier quoted context omitted.

Everything we do in life relies on a trust system more or less. Reproducible build only guarantees integrity, not the trustworthiness of the code. > 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. Because few people have time to read source code. Take Django as an example. Big community, lots of contributors. Can we say we should trust th…

> someone apparently made an authorized changeset to BitKeeper I suggest you read the link you mentioned. It was not an authorized change in BK, it was not an authorized change at all. It was only in a third-party CVS mirror, and it was found exactly when someone asked why there was a changeset in the CVS mirror that wasn't in BK. And while I don't doubt that there are enough unreadable code to hide a backdoor in, ce…

I was intended to say unauthorized change but spell check fucked me up, although you could probably tell my actual intention from the rest of my comment. Thanks for pointing out.

I ack when it comes to size my comparison is not fair, but I am trying to say just because there is a large community, we sometimes still overlook. Usually big projects would have some "module owners" to approve merge. This limits to a number of people. If the project is active enough, there will be dozens of commits or more per day. Sometimes people really do overlook and let things pass. Until someone spots something wrong, the code could have been in the wild for days or years.

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

#97
post #44
post #34

Earlier quoted context omitted.

Everything we do in life relies on a trust system more or less. Reproducible build only guarantees integrity, not the trustworthiness of the code. > 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. Because few people have time to read source code. Take Django as an example. Big community, lots of contributors. Can we say we should trust th…

Distributions - let's take Debian as a concrete example - provide an audit trail to individual identified developers as a mitigation for users relying on trust. Just because we must necessarily rely on some level of trust does not mean that we must blindly trust, which is what happens when anyone can upload to a repository such as PyPI.

As far as I know, once the project name is taken, that ownership belongs to the account first created this package in PyPI.

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

#98
post #52

Earlier quoted context omitted.

Yeah this way you reinvent a less unit tested, battle field tested and documented wheel. It's like saying the good thing with not having a cellphone is that you avoid a lot of fight with your girlfriend cause you can't talk as much.

> It's like saying the good thing with not having a cellphone is that you avoid a lot of fight with your girlfriend cause you can't talk as much. I can't quite see what's wrong with that...

Do you have a cellphone? If so, throw it into the trash right now.

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

#99
The other day, I was using rmarkdown and noticed that every time it ran it tried to source this:

https://mathjax.rstudio.com/2.7.2/MathJax.js?config=TeX-AMS-...

This was really disconcerting since I did not expect to be downloading anything, let alone running javascript from there just to make a chart.

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

#100
post #88
post #68

Earlier quoted context omitted.

How does npm solve the transitive dependencies problem?

If by "transitive dependencies problem" you mean a case where package A depends on package B which depends on package C and you want to use A in your project, then it solves that by simply pulling in all three of those packages. Or did you mean the case where you want package D as well, and it depends on a conflicting version of package C? In that case, it solves the problem by pulling in both versions of package C a…

I do mean the latter - A and D both using different versions of C.

Running both C side-by-side cannot work if C is incompatible (that is, even if both versions are api compatible, but each assumes it's the sole C being loaded - and therefore, do some static/singleton crap that might get clobbered when loaded again).

Post reply on HN