[dead]
Axios compromised on NPM – Malicious versions drop remote access trojan
651–660 of 894 posts
Re: Axios compromised on NPM – Malicious versions drop remote access trojan
#652Earlier quoted context omitted.
And when you actually need a super hot fix for a 0-day, you will need to revert this and keep it that way for some time to then go back to minimum age. While this works, we stillneed a permanent solution which requires a sort of vetting process, rather than blindly letting everything through.
Who will do the vetting process?
Jia Tan
Re: Axios compromised on NPM – Malicious versions drop remote access trojan
#653Earlier quoted context omitted.
I think you can do copy paste in most languages. But it will be a pain to update when there are improvements / security fixes. You got a project with 1-2 depencies? Sure. But if you need to bring in 100 different libs (because you bring in 10 libs which in turn brings in 10 libs) good luck.
> But if you need to bring in 100 different libs (because you bring in 10 libs which in turn brings in 10 libs So don’t? With manual deps management, everyone soon gravitates to a core set of deps. And libraries developer tends to reduce their deps needs, That’s why you see most C libraries deals with file formats, protocols, and broad concerns. Smaller algorithms can be shared with gists and blog articles.
> Smaller algorithms can be shared with gists and blog articles
You just invented a worse Stack Overflow.
Using libraries is good, actually.
Re: Axios compromised on NPM – Malicious versions drop remote access trojan
#654Earlier quoted context omitted.
Bit ridiculous to dismiss the most popular programming languages packaging repo as silly toys.
I don't deny that node/npm is useful for building servers, devtools for JS development itself, etc. but as an end user I haven't encountered anything useful which requires having it on my machine.
Ok? So you don't code in that language?
You still have multiple programming languages preinstalled on your OS, no matter which one it is.
Re: Axios compromised on NPM – Malicious versions drop remote access trojan
#655Package managers are a failed experiment. We have libraries like SQLite, which is a single .c file that you drag into your project and it immediately does a ton of incredibly useful, non-trivial work for you, while barely increasing your executable's size. The issue is not dependencies themselves, it's transitive ones. Nobody installs left-pad or is-even-number directly, and "libraries" like these are the vast majori…
They're not a failed experiment. No one has ever "experimented" by making a safe package manager for their new language. And it is not that insane to do so. Very basic things will get you very far: 1. Packages should carry a manifest that declares what they do at build time, just like Chrome extensions do. This manifest would then be used to configure its build environment. 2. Publishers to official registries should…
For those who didn't know what TUF means (like me), I think they're referring to The Update Framework (https://theupdateframework.io).
Re: Axios compromised on NPM – Malicious versions drop remote access trojan
#656"Batteries included" ecosystems are the only persistent solution to the package manager problem. If your first party tooling contains all the functionality you typically need, it's possible you can be productive with zero 3rd party dependencies. In practice you will tend to have a few, but you won't be vendoring out critical things like HTTP, TCP, JSON, string sanitation, cryptography. These are beacons for attackers…
> In practice you will tend to have a few, but you won't be vendoring out critical things like HTTP, TCP, JSON, string sanitation, cryptography Unless you are Python, where the standard library includes multiple HTTP libraries and everyone installs the requests package anyways. Few languages have good models for evolving their standard library, so you end up with lots of bad designs sticking around forever. Libraries…
> Few languages have good models for evolving their standard library
Re: Axios compromised on NPM – Malicious versions drop remote access trojan
#657Earlier quoted context omitted.
Or find the best third party library and copy the code from a widely used version that has been out long enough to have been well tested into your source tree. The problem is not third party libraries. It is updating third party libraries when the version you have still works fine for your needs.
Don't do this. Use a package manager that let's you specify a specific version to pin against. Vendoring side steps most automated tooling that can warn you about vulnerabilities. Vendoring is a signal that your tooling is insufficient, 99% of the time.
Vendoring means you don't have to fetch the internet for every build, that you can work offline, that you're not at the mercy of the oh-so-close-99.999 availability, that it will keep on working in 10 years, and probably other advantages.
If your tooling can pull a dependency from the internet, it could certainly check if more recent version from a vendored one is available.
Re: Axios compromised on NPM – Malicious versions drop remote access trojan
#658Earlier quoted context omitted.
Could you explain what you mean re: ambiguity? I understand why “calendar units” like months are ambiguous, but minutes, hours, days, and weeks all have fixed durations (which is why APIs like Python’s `timedelta` allows them).
In the UK last Sunday was 23 hours long because we switched to BST, and occasionally leap seconds will result in a minute being something other 60 seconds.
No it wasn't. The country instantaneously changed timezones from UTC+0 to UTC+1 (called something else locally), it was no different to any other timezone change from e.g. physically moving into another timezone.
Re: Axios compromised on NPM – Malicious versions drop remote access trojan
#659Uh Axios. Even after being years out of NPM dev I remember that as the XHR thing for node. Whichs rings a big hit even to out of the loop people...
Re: Axios compromised on NPM – Malicious versions drop remote access trojan
#660Earlier quoted context omitted.
Number 1 would only be a win for zero-installs if it happened that registry was up when you made the security hotfix, since you'd need to install the depdencency the first time to get it in VC, but then suddenly down when doing a deploy. Seems like a highly unlikely scenario to me. Also, cases where npm CVEs must be patched with such urgency or bad things will happen are luckily very rare, in my experience. Most npm…
> you'd need to install the depdencency the first time to get it in VC, but then suddenly down when doing a deploy. Which dependency? It sounds like you are assuming some specific scenario, whereas the fix can take many forms. In immediate term, the quickest step could be to simply disable some feature. A later step may be vendoring in a safe implementation. The registry doesn’t need to be actually down for you , eit…
This is why Artifactory and similar exist and they do this better. You ~never want to vendor libraries.