> I think OpenBSD actually does support static libc though.
How does that work, with syscalls being unable to be called except from the system’s libc? I’d be a bit surprised if any binary’s embedded libc would support this model.
For static executables, “the system’s libc” is of course not a thing. To support those, OpenBSD requires them to include an exhaustive list of all addresses of syscall instructions in a predefined place[1].
(With that said, OpenBSD promises no stability if you choose to bypass libc. What it promises instead is that it will change things in incompatible ways that will hurt. It’s up to you whether the pain that thus results from supporting OpenBSD is worth it.)
> How does that work, with syscalls being unable to be called except from the system’s libc?
OpenBSD allows system calls being made from shared libraries whose names start with `libc.so.' and all static binaries, as long as they include an `openbsd.syscalls' section listing call sites.
You can. There is a thread-unsafe implementation here <https://gist.github.com/oguz-ismail/72e34550af13e3841ed58e29...>. But the listing needs to be per system call number, so this one only supports system calls 1 (_exit) and 4 (write). It should be fairly easy to automatically generate the complete list but I didn't try it.
Good point. C's "freestanding" mode, analogous to Rust's nostd, does not provide any functions at all, just some type definitions and constants which obviously evaporate when compiled. Rust's nostd not only can compute how long a string is, it can unstably sort a slice, do atomic operations if they exist on your hardware, lots of fancy stuff but as a consequence even nostd has an actual library of code, a similar but maybe less organized situation occurs in C++. Most of the time this is simply better, why hand write your own crap sort when your compiler vendor can just provide an optimised sort for your platform? But on very, very tiny systems this might be unaffordable.
Anyway, C doesn't have Rust's core versus std distinction and so libc is a muddle of both the "Just useful library stuff" like strlen or qsort and features like open which are bound to the operating system specifics.
Won’t IDEA automatically index/execute some Gradle code when possible? As soon as you execute an arbitrary binary/script from the project directory, the isolation of the JVM doesn’t matter.
This particular vulnerability relied upon passing the require function to a scope to allow the loading and running of arbitrary code. This is what I tend to call a blacklist approach. You're saying in this sandbox certain features can't be used because they will allow escape.
The alternative is a whitelist approach. Instead of disallowing dangerous features you're enabling only the features you need.
So a build system like Gradle or Maven (same thing really) has a limited set of primitives it is allowing access to. It's not loading, say, the entire JVM and all the Java core libraries and then listing all those you can't use.
You see the difference? If nothing else, the blacklist approach is going to fail when the virtual machine (or whatever) adds a new API call upstream and it's added without intent to the sandbox by simply doing an update where nobody has thought to disable it.
Another way of looking at this is Gradle isn't being compiled into Java bytecode and run in the same environment as the IDE (sandboxed or otherwise). That is inherently riskier.
Not really. The drivers are not upstream, so it only works well on specially made Ubuntu spins that carry out of tree patches and random binary blobs. It is really still quite a mess at the moment.
Integration, testing, and support are all expensive. Right or wrong, that's a reason why if a laptop "just works" (like a Mac, Windows Thinkpad, or a Chromebook), it probably has proprietary binaries.
Also, if you aren't paying for the OS (via the hardware it's coupled with), you can't expect the OS to have the benefits of tight hardware integration.
Even Framework laptops use proprietary boot firmware, and they've been pretty clear that they only provide support for Ubuntu and Fedora, not the alphabet soup of other Linux desktop distros.
rubygems.org will still be operated by Ruby Central, though, so you still have to trust them. Given the state of affairs, this is less than ideal, but it’s probably a better outcome than nothing changing.
Thank you for the swift and candid response, this has to suck. :/
> The author appears to have deleted most of the compromised package before losing access to his account. At the time of writing, the package simple-swizzle is still compromised.
Is this quote from TFA incorrect, since npm hasn’t yanked anything yet?
This isn’t the same website as https://news.ycombinator.com/item?id=44560662 — clearly a different product with the same name, though it seems the signup button doesn’t even do anything?
