Cordial 0.13.2 — bwrap was chosen on hosts where it cannot run

One bug, and 0.13.1’s own release build is what found it.

Plugins silently did nothing on any host that refuses unprivileged user namespaces. Cordial decided whether to sandbox a plugin by running bwrap --help — which succeeds wherever the binary is installed and says nothing at all about whether the kernel will hand out the namespaces bwrap needs. Where it will not, bwrap was present, was chosen, started, and failed after the spawn had already returned success. The plugin produced nothing and reported nothing.

That is precisely the asynchronous silence 0.13.0’s interpreter check was written to eliminate, one layer up: the command is bwrap … deno …, so as far as Cordial could see, the process started.

Where this bites

Any host the kernel refuses the namespace on:

• Debian and derivatives with kernel.unprivileged_userns_clone=0
• hosts with user.max_user_namespaces=0
• an AppArmor or SELinux policy that denies it
• inside another container, which is how it was found

A Flatpak install was never affected — that case is decided separately and deliberately, for the reason ADR-018 gives, and it already resolved to no OS layer.

How it was found, and the evidence

0.13.1 made deno a hard dependency of the Arch package. That gave the archlinux:base-devel container an interpreter for the first time, so a test that had been skipping there for want of one finally ran — and failed. The container’s own log, verbatim, three times immediately before it:

bwrap: No permissions to create a new namespace, likely because the kernel does
not allow non-privileged user namespaces. On e.g. debian this can be enabled
with 'sysctl kernel.unprivileged_userns_clone=1'.

So the diagnosis is not an inference from reading the code. The machine said it.

The fix

The check is now a real sandbox over the same namespace and mount work the live command does, rather than --help. It is cached, because the answer cannot change under a running client and the probe costs a process.

Where it fails, the layer falls back to Deno’s zero permissions and the broker — which is what a Flatpak install has had all along, and what every install had before the bwrap layer existed. It is a downgrade and it is reported as one: the line printed at spawn now reads Deno permissions + broker (no OS sandbox available on this install) instead of claiming a bwrap that was not working.

Controls both ways. On this host, bwrap --help and the real probe both succeed and the workspace suite passes with the sandbox chosen. In the Arch container, --help succeeded and the probe is refused — which is the case that was being got wrong, on a real machine, with its message quoted above. A test pins the two answers agreeing in both directions, so it is a live assertion on a host with a working bwrap and on one without.

0.13.1 shipped as a Flatpak and nothing else

The test above runs inside the job that builds the Arch package, so that job failed, and the step that attaches every native package to the release is one step that waits for all four. The .deb, .rpm and AppImage all built correctly and were attached to nothing.

So the 0.13.1 release page carries a Flatpak alone. If you install by any other route, this release is the one to take — it is 0.13.1 plus the fix above, and its notes are worth reading, since 0.13.1 is where plugins became able to run at all.

What is still broken

Everything 0.13.1 listed, unchanged: the startup freeze when signed in, the black canvas inside an experience, text in a box disappearing when you click off it, the editor lagging a text box Roblox is animating, the web-view dialog’s clicks and cursor, and the TaskScheduler crash — diagnosed and instrumented in 0.13.1, not fixed.

gamepadType’s ordinals are still unestablished.

And 0.13.1’s three unobserved fixes are still unobserved: the / flash, the consent prompt, and the plugin Download row in Settings. Nothing here changed any of them.