Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

arstechnica.com

Post reply on HN
Print view View original

31–40 of 119 posts

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

#31

Post by lifeisstillgood »

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 confident about

Personally I am surprised the Post Office does not do key signing

Edit: I thought pip did do cryptographic checks?!

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

#32

Post by julianhouston12 »

Hi My name is Julian Houston, am from upper island cove , Canada.. I want to Use this opportunity to thank God for using this Great prophet to solve my Marriage problem. This Great Prophet of God brought my husband back to me. 3 years ago, i and my husband has been into one quarrel or the other until he finally left me for one lady. I felt my life was over and my kids thought they would never see their father again. I tried to be strong just for the kids but i could not control the pains that was tormenting my heart. My heart was filled with sorrows and pains, because i was really in love with my husband. Every day and night i think of him and always wish he would come back to me. Until one day i melt a good friend of mine that was once in my situation, but her problem was different a little bite, her ex-boyfriend who she had an unwanted pregnancy for refused to take responsibility and dumped her. She told me that mine issue was a minor case and that i shouldn't worry about it at all. So, i asked her what was the solution to my problems and she gave me this Great Prophet of God phone number and his email address. I was doubting if this Great Prophet of God could actually solve my problem. So, I contacted this Great Prophet of God and he told me what to do and i did it. He told me to wait for just four days and that my husband will come crawling on his kneels just for forgiveness. So, I faithfully did what this Great Prophet of God asked me to do and for sure after four days i heard a knock on the door, in a great Surprise i saw him on his knees and i was speechless, when he saw me, all he did was crying and asking me for forgiveness, from that day, all the pains and sorrows in my heart flew away, since then i and my husband and our lovely kids are happy. That why i want to say thank you to God for using Prophet Ikehedu .to solve my marriage problem. This Great Prophet of God made me to understand that there’s no problem on earth that does not Have solution. So, if you are having same problem, any problem that is Similar, i will advise you to a contact This Great Prophet of God straight At prophetikehedu@gmail.com

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

#34

Post by yeukhon »

zizek23 wrote: 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…

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 the code because the number of eyes? Probably, but not always.

Why? We can overlook and pretend the code is legitmate. Take Linux kernel or some of the crypto projects out there. A lot of unreadable old tricks made backdoor really easy. [1] is interesting because someone apparently made an authorized changeset to BitKeeper. Are you going to read JRE code to make sure no backdoor? Nah.

Is there a solution? Nope and will never have a solution. The best one can do is using a DVCS to prevent unathorized changeset (provided every contributor does a sanity check for pulling in changeset) and trust the community. No machine can distinugish a good code from a bad code. Humans can't even tell unless raising a red flag.

Sometimes change of project ownership can also introduce some uncertainty, but that is a rare case for major projects.

I am pretty confident there are code in the Linux kernel no one has ever touched or ever read for years.

[1]: https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-...

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

#35

Post by ubernostrum »

lifeisstillgood wrote: post #31

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…

pip allows you to specify, along with package name and version, the expected hash of the downloaded package. If you do that, then pip will download the package, calculate the hash, and check against what you specified. In case of mismatch, pip will refuse to install the package.

PyPI also supports adding GPG signatures alongside packages, but with no trust/verification process to assert "this key really is the key of the person who should be releasing this package", the signature is literally worthless; anyone who could put up a fake package could also generate a signature for it, and you'd have no way of knowing that the key which signed that package shouldn't be trusted for that package.

It is a very very hard problem, and people need to appreciate that.

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

#36

Post by onion2k »

xroche wrote: post #26
viraptor wrote: post #22

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, but downloading random code is just insane. As a comparison, Debian has ~3000 packages, and every single package had an identified maintainer, with its own GPG key, validated in face-to-face meeting with an ID card by three people, an…

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 well-maintained, verified, and known secure subset of npmjs would be a great idea, but the logistics of providing that would be effectively impossible without some serious cash behind it.

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

#37

Post by sametmax »

userbinator wrote: post #18

The IP address it phones home to, 121.42.217.44, is located in China and visiting it with HTTP just displays this interesting message: Hi bro :) Welcome Here! Leave Messages via HTTP Log Please :) On 2017-09-16: Happy to see somebody find it ! :) Just curious about how long it would take for people to find those 'bad' packages As you see, that's just a toy script, no harm, hope you enjoy it ! It looks like someone (s…

It may be https://pytosquatting.org/. In that case it was indeed a harmless and quite useful PoC.

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

#38

Post by sametmax »

swiley wrote: 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.

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.

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

#39

Post by sametmax »

zizek23 wrote: 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…

Sooo, you read the OpenSSL source code and avoided heart bleed ?

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

#40

Post by jacalata »

cassowary wrote: post #30
mrmondo wrote: post #29

Earlier quoted context omitted.

Debian security are very good at their job indeed, however so many of the packages are so old they’re not usable, furthermore Debian doesn’t enable SELinux by default and has a number of policies missing which significantly weakens the average deployment.

Those comments are all irrelevant to the OP's point. Debian software is "old" by intention; it is part of the spec that it shouldn't be a moving target. As for Debian making some policy decisions that you disagree with, it's very different for Debian to make decisions than for NPM to make decisions. There's just no comparison.

I agree that Debian is so different to npm as to make any comparison irrelevant, but you should direct that at the comment which introduced the comparisons, not one that pointed out ways it doesn't work to compare them.
Post reply on HN