If it's a conspiracy, it would be one where the Minimum Viable Conspirator Count is 1 (inclusive of one's own self).
In that case, by that rubric literally anything that you conspire with yourself to accomplish (buying next week's groceries, making a turkey sandwich...) would also be a conspiracy.
Hey HN! Inspired by platforms like pico.sh and exe.dev, we launched a service where you can instantly create GPU instances over SSH. The disk is persistent and the commonly used tools are installed by default so you don't waste time (and money) setting everything up.
At the moment, free users get 30 credits (about 10 hours of compute with an RTX 3090 or 6 hours with an RTX 4090).
Wine is not a Sandbox but come on. Everyone has been using it as if it was.
Even Bottles was only a prefix-manager until a couple months ago.
I think it should be and also disallow Linux syscalls and Z: drive accesses by default from within the "sandbox" on top of that in order to reduce the attack surface.
> I think it should be and also disallow Linux syscalls and Z: drive accesses by default from within the "sandbox" on top of that in order to reduce the attack surface.
This is not even remotely sufficient. A malicious application could modify the memory pages of WINE code and execute direct syscalls anyway.
If you want sandboxing, use a Linux sandboxing solution on WINE. It's far too late to try to bolt on sandboxing now.
For these kinds of services, I think the main value would be UX improvements, such as offering an environment preconfigured with a certain set of tools (e.g. nmap, tmux, curl, etc.) and other defaults. SSH in, and don't deal with a web panel. They may also be valuable in a learning environment where you don't want student servers running 24/7.
Other than those points, offering access to more powerful hardware is probably the best use-case.
It should be noted that iOS/macOS is likely to be not vulnerable because for them the Dolby decoder has been compiled as any C/C++ program should be compiled by default everywhere, i.e. with bounds checking enabled.
Unfortunately, all C/C++ compilers have as the default option to omit bounds checking, but any decent compiler has options for enabling bounds checking and other run-time checks suitable for catching all the undesirable behaviors that are undefined in the C/C++ standards. The default should be to enable such options globally for any program and to disable them selectively only for the code parts where benchmarks have demonstrated that they prevent the program to reach the target performance and code analysis has concluded that the erroneous behavior cannot happen.
The claim that C/C++ are unsafe programming languages is only in small part true, because most of the unsafety is caused by the compiler options that are chosen to be default by tradition, and not intrinsically by the language. The C/C++ standards fail to define a safe behavior for many situations, but they also do not prevent a compiler to implement the safe behavior, e.g. the fact that the standard does not require mandatory bounds checking for accessing arrays and structures does not mean that a compiler should not implement such checking.
When a C/C++ program is compiled with safe compilation options, instead of the default options, then it becomes quite safe, as most errors that would be caught by a "safer" language would also be caught when running the C/C++ program.
> When a C/C++ program is compiled with safe compilation options, instead of the default options, then it becomes quite safe, as most errors that would be caught by a "safer" language would also be caught when running the C/C++ program.
Sean Baxter has been providing quite a number of crazy examples that even if they wanted to which there is no sign they do, C++ couldn't attempt to fix without major language changes.
Bounds checking in more places by default, catching some types of initialization screw up, these are all nice enough in some sense - indeed in this particular case maybe they close the vulnerability - but they're band aids, the pig is gone dad. https://www.youtube.com/watch?v=1XIcS63jA3w
That's a lot of words, but how is that even possible?
Pointers and arrays are basically interchangeable in C, and you have to do that constantly in any large program. Even the blog post has a malloc in it.
Once you start passing around a pointer to the middle of the array all size info is lost.
Are you talking about -fsanitize=address? It's too slow to be used in production
I believe GP is talking about -fbounds-safety [0, 1]. From my understanding this will cause the compiler to emit an error if it can't figure out how to bounds check a pointer access at either compile time or run time. You then need to either add appropriate annotations to provide the missing information or otherwise restructure the code to satisfy the compiler.
As implemented in the most popular compilers "-fsanitize=address" is indeed slow.
However, for the majority of the code of a program, enabling this and all the other sanitize options will have a negligible effect on the useful performance.
Like I have said, sanitize options should be disabled in performance-critical sections, which have been identified as such by profiling, not by guessing, but only after examining those sections thoroughly, to be certain that the undefined behavior cannot be triggered.
Currently, the sanitize options are significantly slower than they should be in an optimized implementation, because there is a vicious circle. The application developers do not enable such options for production because they believe that they are slow and the compiler developers do not make the effort to improve their speed, because they believe that the application developers will not enable them in production code anyway.
However, these problems are not inherent to the language or compiler, they are caused by a bad historical tradition of neglecting the correctness of a program whenever cheating can improve the performance in the best case (which will be the only one demonstrated to potential customers), even if that makes the worst case catastrophic.
Even Rust is not immune to bad traditions, e.g. by disabling overflow checking in release builds, as opposed to debug builds.
I've done this before. There are valid reasons to do this, especially if you're too lazy to do a full Linux port of an application but are still willing to implement some workarounds.
The project dates to the 2016 election campaign and was archived in 2020. I don't think Trump had that particular speech affect that time around, or at least I can't recall it being memed upon the way it is now.
They do, on paper, but many countries hardly enforce them. For example, the EU has more caveats to its section-1201-style insanity; China simply doesn't care at all. These copyright treaties are useless in practice and harmful because they ossify a bad system.
reply