861–870 of 894 posts
Earlier quoted context omitted.
Irony is that Node has no need for Axios, native fetch support has been there for years, so in terms of network requests it is batteries included.
It doesn't matter. We pulled axios out of our codebase, but it still ends up in there as a child or peer from 40 other dependencies. Many from major vendors like datadog, slack, twilio, nx (in the gcs-cache extension), etc...
"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…
I'm guessing it's similar to the tragedy of the commons phenomenon. When things are freely available people tend to overuse or carelessly use them. NPM is just too easy to use. If a package offers a 1% ergonomics increase over a builtin function, many folks will just go for it because it costs them nothing (well, it seems to cost them nothing).
Earlier quoted context omitted.
To the extend that Python is indeed "batteries included," that seems true. But just how "batteries included" is it? I'd argue that its batteries are pretty limited. Exhibit A: everybody uses the third-party requests instead of the stdlib urllib . Exhibit B: http.server isn't a production-ready webserver, so people use Flask or something beefier. I'd contrast Python with Go, which has an amazing stdlib for the domains…
> http.server isn't a production-ready webserver, so people use Flask [...] Nit, but relevant nit: Flask is also not a production-grade webserver. You could say it is also missing batteries ... and those batteries are often missing batteries too. Which is why you don't deploy flask, you deploy flask on top of gunicorn on top of nginx. It's missing batteries all the way down (or at least 3 levels down).
I really don't miss this part of the Python world. When I started on backend stuff ~10 years ago, the morass of runtime stuff for Python webservers felt bewildering. uWSGI? FastCGI? Gunicorn? Twisted? Like you say, missing batteries all the way down, presumably due to async/GIL related pains.
Then you step into the Go world and it's just the stdlib http package.
Anyway, ranting aside, batteries included is a real thing, and it's great. Python just doesn't have it.
Earlier quoted context omitted.
> tried to test the LiteLLM hack but the affected packages had been pulled Hey, I have been part of the archival effect/Litellm issue thread. I think I have stored them in archive.org for preservation purposes https://web.archive.org/web/20260325073027/https://files.pyt... (I have also made an archive of the github issue with all the comments manually till a certain point at https://web.archive.org/web/20260325054202…
thanks for highlighting that i will take a look and see if there's similar archive for the other vulnerabilities as well . If i can make it work with clamscan & MS Defender i'll run a scan and try to report back
"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…
Irony is that Node has no need for Axios, native fetch support has been there for years, so in terms of network requests it is batteries included.
Earlier quoted context omitted.
This looks like an ad for batteries included to me. Libraries also don't get it right the first time so they increment minor and major versions. Then why is it not okay for built-in standard libraries to version their functionality also? Just like Go did with JSON? The benefits are worth it judging by how ubiquitous Go, Java and .NET are. I'd rather leverage billions of support paid by the likes of Google, Oracle and…
Third party libraries have been avoiding those json footguns (and significantly improving performance) for well over a decade before stdlib got it. Same with logging. And it's looking like it will be over two decades for an even slightly reasonable http client. Stuff outside stdlib can, and almost always does, improve at an incomparably faster rate.
Their JSON even does cross-platform SIMD and their Kestrel stack was top 10/20 on techempower benchmarks for a while without the ugly hacks other frameworks/libs use to get there.
stdlib is the science of good enough and sometimes it's far above good enough.
Earlier quoted context omitted.
thanks for highlighting that i will take a look and see if there's similar archive for the other vulnerabilities as well . If i can make it work with clamscan & MS Defender i'll run a scan and try to report back
Glad to see that Clamscan experiment worked. Keep me updated on the continued testing and I am glad that my archival efforts are appreciated :)
Earlier quoted context omitted.
I'm confused. All an attacker has to do is phish you to get your password and TOTP. TOTP would cover cases like a compromised password manager or a reused password. That's it, right?
My password manager, as is standard for most of them, will not fill or show a password if the URL bring visited doesn't match the credential. Thus, a credential not showing is a huge red flag. The workflow is pretty standardized so any deviation is a big red flag. Maybe you can be more specific about the attack flow you are imagining and how it will work technically to bypass my controls. To answer your question, no…
I agree.
> Maybe you can be more specific about the attack flow you are imagining and how it will work technically to bypass my controls.
Can you be more specific about the attack that your password manager doesn't solve that your TOTP does? The attack I'm suggesting is already solved by your password manager.
Earlier quoted context omitted.
My password manager, as is standard for most of them, will not fill or show a password if the URL bring visited doesn't match the credential. Thus, a credential not showing is a huge red flag. The workflow is pretty standardized so any deviation is a big red flag. Maybe you can be more specific about the attack flow you are imagining and how it will work technically to bypass my controls. To answer your question, no…
> My password manager, as is standard for most of them, will not fill or show a password if the URL bring visited doesn't match the credential. Thus, a credential not showing is a huge red flag. The workflow is pretty standardized so any deviation is a big red flag. I agree. > Maybe you can be more specific about the attack flow you are imagining and how it will work technically to bypass my controls. Can you be more…
Earlier quoted context omitted.
These are definitely some good thoughts, thanks! Do you worry at all about the future of F#? I've been told it's feeling more and more like a second-class citizen on .NET, but I don't have much personal experience.
I used to, but the knowledge of .NET seems mostly transferrable to C#. It's super useful to do `dotnet fsi` and then work out the appropriate .NET calls in the F# repl.
As someone with all the memory of a fruit fly, I love a good REPL when I'm trying to recall the various magic incantations that make the computer go.