This is why I use packages from a Linux distribution - specifically Debian.
Malicious PyPI packages stealing credit cards and injecting code
91–100 of 230 posts
Re: Malicious PyPI packages stealing credit cards and injecting code
#92This is why our build systems don’t use public repositories directly, and why we always pin to an exact version. Any third party dependencies (js/python/java/c/you-name-it) are manually uploaded to our Artifactory server- which itself has no internet access. All third party libraries are periodically checked for new versions, any security announcements etc, and only if we are happy do we update the internal repo. It…
I did a bunch of nodejs stuff at my last gig. These teams had the of practice keeping packages up to date. Drove me frikkin nuts. So much churn, chaos. Is this a JavaScript thing? Carried over from frontend development? Exasperated, I finally stopped advocating for locking everything down. Everyone treated me like I was crazy. (Reproducible builds?? Pfft!!) Happens with enterprisey Java, Sprint, Maven projects too. (…
They have no concept of ever needing to reproduce a build. And they are probably right if you do continuous development of some SaaS stuff.
Re: Malicious PyPI packages stealing credit cards and injecting code
#93This is why our build systems don’t use public repositories directly, and why we always pin to an exact version. Any third party dependencies (js/python/java/c/you-name-it) are manually uploaded to our Artifactory server- which itself has no internet access. All third party libraries are periodically checked for new versions, any security announcements etc, and only if we are happy do we update the internal repo. It…
This is how it always used to be, back in the before[1] times. Libraries would be selected carefully and dependencies would be kept locally so that you could always reproduce a build. The world is different now, and just being able to select a package and integrate it like that is a massive effectiveness multiplier, but I think the industry at large lost something in the transition. ([1] before internet package manag…
> I think the industry at large lost something in the transition.
Lost a lot of trust and security with the advent of language-specific installers that pull libraries and their dependencies from random URLs without any 3rd party vetting.
Re: Malicious PyPI packages stealing credit cards and injecting code
#94This is why our build systems don’t use public repositories directly, and why we always pin to an exact version. Any third party dependencies (js/python/java/c/you-name-it) are manually uploaded to our Artifactory server- which itself has no internet access. All third party libraries are periodically checked for new versions, any security announcements etc, and only if we are happy do we update the internal repo. It…
This is how it always used to be, back in the before[1] times. Libraries would be selected carefully and dependencies would be kept locally so that you could always reproduce a build. The world is different now, and just being able to select a package and integrate it like that is a massive effectiveness multiplier, but I think the industry at large lost something in the transition. ([1] before internet package manag…
The problem is that it also is a vulnerability multiplier.
People used to understand every package the installed. Now, they install dependencies of dependencies of dependencies, to the point that they have not even SEEN the name of most of their dependencies.
Install anything with maven and count the number of packages installed. It is appalling.
Re: Malicious PyPI packages stealing credit cards and injecting code
#95This is why our build systems don’t use public repositories directly, and why we always pin to an exact version. Any third party dependencies (js/python/java/c/you-name-it) are manually uploaded to our Artifactory server- which itself has no internet access. All third party libraries are periodically checked for new versions, any security announcements etc, and only if we are happy do we update the internal repo. It…
I did a bunch of nodejs stuff at my last gig. These teams had the of practice keeping packages up to date. Drove me frikkin nuts. So much churn, chaos. Is this a JavaScript thing? Carried over from frontend development? Exasperated, I finally stopped advocating for locking everything down. Everyone treated me like I was crazy. (Reproducible builds?? Pfft!!) Happens with enterprisey Java, Sprint, Maven projects too. (…
I get notifications every other week about my NodeJS packages having security vulnerabilities, and so I upgrade.
I'm not sure why NodeJS devs are so bad at security compared to say C++ devs. It's not like I'm getting asked to upgrade libstdc++ and eigen all the time ...
Re: Malicious PyPI packages stealing credit cards and injecting code
#96Earlier quoted context omitted.
Everyone I know uses some form of lock file, and most of the modern programming languages support it. As for upgrading only when absolutely necessary, let's be honest, nothing is absolutely necessary. If the software is old, or slow, or buggy, well dear users you'll just have to deal with it. In my experience however, it's easier to keep dependencies relatively up to date all the time, and do the occasional change th…
Both extremes are bad. If you never change anything, you are left behind on a lot of security updates and bug fixes. The longer you wait the harder it is to move. The “stay current” model comes with risks too. It’s just a matter of figuring out which manner has the better value to risk trade off, and how to mitigate the risks.
> It’s just a matter of figuring out which manner has the better value to risk trade off
This is also bad.
If you want to have both stability/reliability and also receive security updates you need somebody to track security issues and selectively backport patches.
This is what some Linux distribution do. Mainly Debian, Ubuntu, paid versions of SuSE and Red Had and so on
Re: Malicious PyPI packages stealing credit cards and injecting code
#97Earlier quoted context omitted.
I did a bunch of nodejs stuff at my last gig. These teams had the of practice keeping packages up to date. Drove me frikkin nuts. So much churn, chaos. Is this a JavaScript thing? Carried over from frontend development? Exasperated, I finally stopped advocating for locking everything down. Everyone treated me like I was crazy. (Reproducible builds?? Pfft!!) Happens with enterprisey Java, Sprint, Maven projects too. (…
Feels like this is a business opportunity for someone. Use case: 1. Upload a pre-reviewed package.json file. 2. The service monitors changes, and recommends updates. Recommendations might include security, bug, features, etc. It would check downstream dependencies, too. For production systems, the team might only care about security features. 3. Developer team can review recommendations, and download the new package.…
> Feels like this is a business opportunity for someone.
This is what some Linux distributions do. Quality review, legal review, security backports.
Re: Malicious PyPI packages stealing credit cards and injecting code
#98Re: Malicious PyPI packages stealing credit cards and injecting code
#99Earlier quoted context omitted.
In the US, CC has, by law, almost no liability for fraud - it's capped at 50 bucks, and is 0 bucks if you report it before it gets used. They are also easily replaced, so i think many wouldn't go as far as you are. Debit cards are weirder in their liability (and are extracting money from your bank account, which is harder to get back). If you report them lost/stolen before someone uses them, it's 0 bucks Within 2 day…
Hmm. I understood this to be different, but realizing now I don’t have sources for where I learned this: * Bank accounts, savings accounts, brokerage accounts, etc. are all unlimited liability * Lines of credit are all zero liability I’ve used this as a rule of thumb for many years, and was the initial reason for me switching to 100% credit cards for transactions.
Yeah, i'm telling you based on what the statutes say (the FCBA covers credit cards, the EFTA covers debit)
A short version of it is here: https://www.consumer.ftc.gov/articles/0213-lost-or-stolen-cr...
Re: Malicious PyPI packages stealing credit cards and injecting code
#100Interesting that all the noted examples assume a Windows host. I like that, people that use Windows deserve the drama the get ;-)
Sometimes they don't get a choice. Specially in a corporate environment.