Maybe it's more like shift-left testing [1]? You're trying to move some checks to earlier in the process, if I understood you correctly, and get cheaper feedback loops.
FreeBSD has a "protect" command which does something similar to what this asks for – the man page [1] describes it:
"The protect command is used to mark processes as protected. The kernel does not kill protected processes when swap space is exhausted. [...] If you protect a runaway process that allocates all memory the system will deadlock."
Are those Google ads? That's the only ad-related script I can find on the page. One of the ads says it comes from "MediaGo", but the iframe seems to be served from googlesyndication.com.
If so, I'm glad we have such a trustworthy company keeping Android users safe from malware by preventing us from installing our own software, all for our own good.
The article compares LLMs to Stack Overflow and calls it "a continuation of the same trend", but I think there's a big difference.
With Stack Overflow, you got multiple answers from different people with different viewpoints and different approaches, each consistent within itself. You could figure out where the author of each answer was coming from and judge whether they seemed to know what they were talking about. You could weigh the trade-offs and merits of the different answers against each other.
With LLMs, you get a single mushy pile of slop, not grounded in any person's actual experience or judgement. It might pretend to offer different perspectives, but it can't really, so it's much harder to evaluate.
The Linux version is built with Free Pascal instead, and the Windows version will be based on that code in the future (says the README in the lazarus branch).
And the text appears to fade in on scroll, so you see literally nothing while scrolling down. Wonderful UX. It's like deliberately reintroducing a worse version of the checkerboard pattern the original iPhone used to display when the CPU couldn't handle the page rendering in time.
And it sounds like the proxy can be easily circumvented by the agent, since it only applies within the Node process and the agent can execute arbitrary external commands.
(The filesystem wrapper API sounds even more pointless. The risk it protects against seems insignificant compared to the other risks associated with their system.)
The proxy can be circumvented if the agent can execute arbitrary commands. This is where you’d start if you were planning to enable a world in which it’s more deliberately scoped.
Huawei fixed it in their Cangjie language. According to the docs [1][2], it throws an exception by default and you can use an annotation to get wrapping or saturation instead.
(Cangjie seems like a pretty nice language in other ways as well. Similar to Kotlin with some improvements and no Java. Bootstrapping the toolchain from source seems difficult though.)
It's probably a better idea to follow the process documented in PEP 541 [1] and contact the PyPI admins to request a transfer of the name. Taking over the domain to impersonate the original owner would look indistinguishable from a supply-chain attack.
Yeah, I noticed this library few years ago when checking pypi.org for supply chain attack vulnerability and scanned all libraries. There are a lot of such libraries which you can take over.
Is there a good alternative to Apache and Nginx that's written in a memory-safe language and not full of security holes? I briefly looked at Jetty (written in Java) and Caddy (written in Go) but they seem to have a history of vulnerabilities of other types (e.g. shell injection in Jetty) so I'm not sure they would be any better.
Memory safety is good, but does not protect from every threat. In this day and age infrastructure operators should familiarize themselves with proactive defenses, MAC: SElinux and AppArmor. It required much friction earlier, but there are more tools to ease the usage today.
Any software used at the scale of Apache and nginx will have a history of vulnerabilities. The fact they both survived with their market share for so long is a good sign
On the one hand Apache and Nginx are mature and proven but, being written in C, they will always suffer from memory-safety issues like this one and the recent Apache vulnerabilities.
On the other hand, the alternatives are perhaps not as mature and perhaps not implemented as securely as they could be, given that e.g. Caddy had multiple vulnerabilities in its request parsing this year and Jetty's shell injection vulnerability seems easily foreseeable and avoidable. Using a memory-safe language doesn't help much if you then (to take an unrelated but well-known example) implement arbitrary code execution as a feature in the logging library.
LDAP feature can be removed from log4j, but buffers can't be removed from nginx. Technically, bounds checking can be implemented, but presumably nginx has no plans for it, because it's anathema.
Caddy been a breeze to use, bit sucky model with "we have thousands of binaries depending on what combination of plugins you want" instead of a proper plugin system, but if you're building it from source, it's pretty nifty and simple anyways.
Recompiling with the features you want is a great model for a free software project. So much simpler to write and maintain compared to a plugin system that it really makes more sense in a lot of cases.
I've switched to using traefik from caddy. For simple use cases it's a little more verbose in the configuration, but for more involved things like multiple load balancing backends, rewriting paths and headers and so on I've found it really good.
That is a consequence of static linking, and an abandoned plugin package that hasn't yet been removed due to backwards compatibility.
People keep forgetting that with static linking they are back to 1980's IPC for application extensions, or building from scratch every time they need to reconfigure the application.
Apache and I think Nginx have a huge list of features and stuff. Most alternate http servers limit the scope a lot, so you'd need to specify what features you're interested in.
But I haven't seen a whole lot of discussion of http servers in memory safe languages. The big three C-based servers: Apache, Nginx, and lighttpd are all pretty solid... I don't think there's a lot of people interested in giving that up for a new project just because of the language.
I'll also add that when you pick up most memory safe languages, you're also picking up their sometimes extensive runtime / virtual machine and all the accoutrements. A Java webserver probably uses log4j because any random Java project probably does, etc.
[1] https://en.wikipedia.org/wiki/Shift-left_testing
reply