131–140 of 254 posts
Would it be possible to have a general package manager (like apt) as reusable base for the individual language specific package managers? I know that npm and pip and gem etc all do some additional stuff, but at the core they all do the same (pull packages from repo, do some postinstall, resolve dependencies, maybe in some cases even check if the package is legit). So we could implement and check that once and then ju…
Whoa urlib & urllib3. Those are pretty popular packages, especially to newbies. Hundreds of websites that teach web-scraping use those libraries. Wonder what is an effective form of protection against such attack vectors? Do digitally signed certificates fit into this usage scenario??
> Do digitally signed certificates fit into this usage scenario?? No, because either the package author would have to sign them, in which case you have to choose to trust each package author, or the repository would sign them, in which case there would be no improvement for this current issue, since the repo would sign the fake packages as well.
Earlier quoted context omitted.
You are cherry-picking one example involving a library that had a plethora of vulnerabilities from upstream. Contrast it with reviewing and maintaining 50k+ packages, managing thousands of CVEs every year, sometimes even writing security patches before upstream. Also the project pioneered reproducible builds and implemented build hardening for most packages.
None of that, nor the good that they have done, negates the fact that distributions can fuck up too. And regardless of whether OpenSSL had a plethora of bugs from upstream, this one wasn't one of them. It was only in Debian, because of changes the project had made. Just because it's packaged in Debian by Debian maintainers doesn't mean you're immune to these kind of issues. They're arguably less likely but you'd need…
Unless your package manager enforces signatures and you trust the person that signed the package. Then this is an attack vector for you. That includes Java (Maven), Ruby (Gems, Bundler), Node (npm), Haskel (stack) etc etc. Installing code via package managers is the coders equivelant of opening up an exe sent to you in an email. Code downloaded from the internet is not to be trusted.
Unless your package manager enforces signatures and you trust the person that signed the package. Then this is an attack vector for you. That includes Java (Maven), Ruby (Gems, Bundler), Node (npm), Haskel (stack) etc etc. Installing code via package managers is the coders equivelant of opening up an exe sent to you in an email. Code downloaded from the internet is not to be trusted.
Signing packages helps against typosquatting about as much as SSL certificates help against phishing. Or in other words, not at all, especially if we don't have the certificates rooted in real world identities (like EV SSL certs).
"Success of the attack relies on negligence of the developer" How about package manager managers accept their enourmous responsabilty? urllib vs urllib2, one is a virus? Sorry but that is not "negligence of the developer"
There are over 100,000 packages and PyPI is run by volunteers. This is not practical. PyPI is not a curated distribution.
Earlier quoted context omitted.
None of that, nor the good that they have done, negates the fact that distributions can fuck up too. And regardless of whether OpenSSL had a plethora of bugs from upstream, this one wasn't one of them. It was only in Debian, because of changes the project had made. Just because it's packaged in Debian by Debian maintainers doesn't mean you're immune to these kind of issues. They're arguably less likely but you'd need…
So the PyPi issue isn't a bug. It is an attack by hostiles. There are always bugs but this is a person packaging malware probably as a practice to package worse stuff that runs at build time. If package maintainers have time to respond to valgrind reports on their package they have time to check strace on the installer. Edited: longer rant.
Arguably. The issue with typosquatting on PyPi has been known and demonstrated for a long time, but nothing has been done about it. Considering there are ways of closing this attack vector, even though it would require some serious work, I'd consider this a bug. It's just a bug that's being exploited now.
Earlier quoted context omitted.
> npm alone has over 500,000 packages ( http://www.modulecounts.com/ ) so even a one time review isn't going to happen. But at least the modules with the most downloads (webpack, react, or stuff like left-pad) could be vetted, and especially npm could implement a 2-or-more person model - basically, everyone with publish access can upload a new artifact, but to actually have it distributed to endusers, a second person…
Indeed it's not impossible to do (although full code review would be expensive/tricky/slow). The fact it hasn't been done despite the obvious risks indicates how much demand there is for this feature...
People who upload packages often leave organizations, who are then stuck with a package they can't update because the password went with the person, and the email reset link points to a now-defunct email address.
Petitioning the package management team is sometimes fruitless, forcing a needless new instance of typosquatting.