121–130 of 254 posts
I'm glad Go completely sidestepped the name-rush induced by this type of package managers (composer, cpan, rvm, pypi, npm…). Just provide an URL. Done.
...which is even less secure.
Yes, it might put a higher burden on the publisher if they don't host on github/gitlab, etc.
But it strips the "magic" part and makes sure the dev knows where the code is coming from.
Earlier quoted context omitted.
If there was a business/enterprise offering with extra security I'm sure they'd have a long list of people who would sign up and happily pay for it.
The conda package manager is free and generally feels like a professional package manager like yum or apt-get.
In general, Conda does more package verification than pip, and the packages in the Anaconda distribution are more thoroughly vetted than PyPi. Conda-Forge [2] provides an escape hatch for less-vetted community code.
[0] https://conda.io/docs/index.html [1] https://www.anaconda.com/distribution/ [2] https://conda-forge.org/
Earlier quoted context omitted.
I appreciate the proactive approach. Is your project the author of the packages identified by NBU? If so: (1) Why is the tracking pingback obfuscated? (2) Why does the code include a cheeky hello instead of a link to https://www.pytosquatting.org/ ? (3) Why is there not a visible warning when installing one of these packages? ================= edit: Reading through the linked blog post [0], it appears these researche…
We're not the authors of those packages. But we own many others. 1. We're not obfuscating pingbacks. 2./3. We're raising an exception with an explanation and a link. Just look at the code of one of our packages: https://pypi.python.org/pypi/codecs The research in 2016 was done by someone else. The kinda crazy thing is: Some of the package names he used were made available again after that instead of being blocked...…
Earlier quoted context omitted.
A review system unfortunately isn't likely to be practicable with current development models. npm alone has over 500,000 packages ( http://www.modulecounts.com/ ) so even a one time review isn't going to happen. If people want a more trusted solution the likely outcome is that they'll need to use a smaller more static set of libraries and then either do the audits themselves, or outsource that to a 3rd party. Ofc wit…
> they'll need to use a smaller more static set of libraries That's what stable Linux distributions do.
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.
I bet there are quite a few malicious NPM packages that we do not know about. Is Node is used in government and military solutions? If so then the NPM ecosystem is likely targeted by state actors, and it is a sitting duck.
Earlier quoted context omitted.
They do a lot that could be and sometimes even is automated, but that doesn't help with security, only weakens it. Which is my point. It's better to automate package generation and trust fewer people, mainly the authors, not introduce maintainers into it.
Authors don't generate distro packages because there's too many distros and each distro needs to make changes that have nothing to do with code. Maintainers are necessary and a package signed by the author is a non-starter. However, source code can be signed and then used to make a package signed by a distro.
Anyone know if this is also an issue for Java? I've used Maven repository for ages, and I know many big cos depend on it.
Deployed Maven artifiacts from Central are to required to be signed with a PGP key and are only supposed to come from approved hosts. I don't know how strictly that is enforced and how hard it is to become a host, but at least there is some kind of process.
Maven Central also doesn’t allow the removal of artifacts after they've been published, and every artifact requires a unique version and name. And the names are namespaced. So you don't have the issues that you see with npm, where someone can pull a package and break everything people are using, and then some third party can come in and publish anything under the exact same name.
Is this model perfectly secure? No, you still have to trust that the artifact was signed by a non-malicious person from a host that was not compromised.
The regex they have for identifying fake/harmful packages is wrong. `pip list –format=legacy | egrep '^(acqusition|apidev-coop|bzip|crypt|django-server|pwd|setup-tools|telnet|urlib3|urllib) '` This incorrectly lists `urllib3` or the `cryptography` package for example, which are perfectly valid packages. [UPDATE] Read "tobltobs" comment below. I incorrectly removed a trailing space from the regex.
https://gist.github.com/osteele/198b50a2a208e5bc7e5fb8d010cf...