rfcs VS bubblewrap

Some people _do_ care about this (e.g. the proponents of this new RFC: https://github.com/rust-lang/rfcs/pull/3810). However, for some reason (culture, I guess?) there isn't much momentum yet to change the status quo.

Actually, a proposal for exactly this was published yesterday: https://github.com/rust-lang/rfcs/pull/3810

It's unfortunate that the response so far hasn't been very positive

> > no dynamic linking

> There is.

Eh, I'm a Rust fan, and I hate the dynamic linking situation too.

I genuinely cannot see how Rust would be able to scale to something usable for all system applications the way it is now. Is every graphical application supposed to duplicate and statically link the entire set of GNOME/GTK or KDE/Qt libraries it needs? The system would become ginormous.

The only shared library support we have now is either using the C ABI, which would make for a horrible way to use Rust dependencies, or by pinning an exact version of the Rust compiler, which makes developing for the system almost impossible.

Hopefully we'll get something with #[export] [1] and extern "crabi" [2], but until then Rust won't be able to replace many things C and C++ are used for.

[1] https://github.com/rust-lang/rfcs/pull/3435

[2] https://github.com/rust-lang/rfcs/pull/3470

As you can see, all trait methods are stored in sequence without any distinction between which method belongs to which trait. This is why upcasting is not possible. There's an ongoing RFC—RFC 2765—tracking this issue. Instead of discussing the solution proposed by the RFC here, we’ll introduce a more general workaround by adding an AsBase trait:

And for extra context the RFc lays out the current design and future options: https://github.com/rust-lang/rfcs/blob/master/text/3324-dyn-...

> so your claim is that rust compiler knows in advance which will be used by the target and adjusts its softfloat accordingly?

Rust performs FP operations using the precision of the underlying type. For compile time evaluation this is enforced by Miri, and for runtime evaluation this is enforced by carefully emitting the appropriate LLVM IR.

> IIRC there are cases for SIMD where there is only a 2 ULP guarantee and some tryhard silicon gives you 1 ULP for the same opcode.

Rust only permits operations in constant contexts when it's confident that it can make useful guarantees about their behavior. In particular, FP ops in const contexts are currently limited as follows:

"This RFC specifies the behavior of +, - (unary and binary), *, /, %, abs, copysign, mul_add, sqrt, as-casts that involve floating-point types, and all comparison operations on floating-point types."

https://github.com/rust-lang/rfcs/blob/master/text/3514-floa...

Rust doesn't support that, but there's an RFC trying to figure out how that could be done (hasn't gone anywhere after more than 10 years of discussions): https://github.com/rust-lang/rfcs/issues/294

But Rust supports macros, just like Lisp, so of course someone wrote a library that provides something similar:

https://docs.rs/some-error/latest/some_error/

Their post about how they came up with this crate is quite interesting:

https://jam1.re/blog/anonymous-sum-types-for-rust-errors

Ariadne Conill, Founder and Distinguished Engineer at Edera, highlighted the necessity for a new low-level container runtime in a recent blog post. Existing solutions like Bubblewrap and util-linux’s unshare rely heavily on complex command-line interfaces or lack the required programming control, making them error-prone. In contrast, high-level solutions like Kubernetes' Container Runtime Interface (CRI) abstract too much for low-level management, creating a gap that Styrolite aims to fill.

Another thing to look at is bubblewrap (https://github.com/containers/bubblewrap), which is what implements the sandboxing in Flatpak. It's handy on it's if you want to run a command from your host in a particular sandbox as kind of a one-off.

> Not requiring the cooperation of developers to opt-in, for starters.

True, meaningful in the general case, and completely irrelevant in this particular case, which started with specifically the question of OpenBSD applying the protection in question to its own base system. I actually agree that being able to externally impose a sandbox is super useful, but self-imposed restrictions are perfectly applicable in this usecase.

> You really think pledge and unveil are equivalent to sandboxing? Can you refer to any sandboxing solution or technologies that limit themselves to restricting syscalls and hiding file paths? Unveil is a lot more useful as a component in sandboxing, I'll give you that.

I think that pledge and unveil are a type of sandboxing, certainly. And... I'm struggling to think of any sandboxing tech that does anything but limit syscalls and filesystem access. After rereading https://github.com/containers/bubblewrap?tab=readme-ov-file#... a bit, I suppose there's a case for being able to change what a sandboxed process can see rather than only masking (ex. PID 1 is a different process inside and outside the sandbox), but that strikes me as a slight variation rather than a fundamental difference in what is or isn't a "sandbox" per se. Likewise, I could see an argument that OpenBSD's approach is coarser than it could be; ex. I think you could restrict a Linux process to keep your real user and be able to read files but not write them even though they're owned by your user and are 644, but that's more of a convenience thing than a true fundamental difference - an OpenBSD process could open files in read mode, keep the socket open, and then pledge away open() altogether which gives you the same outcome with more legwork.

As an example we will look at man 1 bwrap. Bubblewrap allows us to sandbox an application, not too dissimilar to docker. Flatpaks use bubblewrap as part of their sandbox. Bubblewrap can optionally take in a list of syscalls to filter. The filter is expressed as a BPF(Berkley Packet Filter program - remember when I said docker gives you a friendlier interface to seccomp?) program. Below is a short program that defines a BPF program that can be passed to an application using bwrap that lets us log all the sycalls the application makes to syslog.

Nothing nix specific but you may be interested in https://github.com/containers/bubblewrap

Recently, I came across Chainguard and wrote the article How to build Docker Images with Melange and Apko. As a fervent supporter of Kubernetes and GitLab CI, I was eager to experiment with building images using Melange in this particular setup. GitLab's shared Runners work seamlessly with Bubblewrap, eliminating the need for additional configurations. This post is intended for enthusiasts like myself, interested in hosting their own Kubernetes Runners and leveraging the Kubernetes Runner Type of Melange.