• Users will stop referring to non-containerized applications as “running on bare metal”

What “other technology” is going to make sure your API doesn’t have SQL injection and bad authentication vulnerabilities?

You know what? Rather than over-complicate things you can probably just check that filenames only contain a small set of white-listed chars. [a-zA-z-._] (and != ‘…’ or ‘.’) or something.

And one other nit-pick if you’re up for more code-review - your authentication logic should probably be inverted:

if !ok || user != session.config.username ||
				pass != session.config.password

I’d change that to be something like

if ok && user == session.config.username && pass == session.config.password {
   // do login
} else {
   // not auth
}

There’s a whole category of security errors where an exception in logic like that causes the code to skip the “you’re not allowed” logic and go right to the “you’re allowed!” block. It’s more of an issue with languages that support exceptions but it’s still considered a best practice generally (it’s also typically easier to read).

“Security” is not just “ssl”…

Ah - I missed that other parms were keys. Still - best practice is to sanitize all user inputs. Try throwing lots of file-path-like args at it to see what it does. it’s a historically tricky problem so there should be some libraries that help with it.

Happy 2026! And happy hacking!

You try using “…/…/…/…/…/etc/passwd” as the filename in your requests? I don’t see anywhere where ‘…’ is escaped or removed from file strings. Sending untrusted filenames directly to file operations without scrubbing and sanity checking is very dangerous and potentially allows a malicious user to read and overwrite any files the application has permissions for.

I think you should make it more clear in your docs that this is wildly insecure and should be restricted to “tinkering” usage only.

That said it seems like a fun project to write.

It’s not a pain, it’s just a different process than what you’re used to

That’s exactly how people defend something that is a pain.

There is no such thing.

Containers are just separated from the rest of your system by cgroups. You can even see the executable running in containers with ps and top. They’re native binaries running on the same kernel as the rest of your system.

It “shines”? It’s the same thing.

Neat

Distrobox is not a feature of immutable distros. It runs just fine on Debian. As does flatpak.

Read again. You completely misunderstood.

Yeah, this is the “fun” of bazite. If you want to do the things it does well (desktopy things) it works well. But then things that are trivial in other distros are a pain. And the “solution” is to actually run one of those other distros in a container. It’s ridiculous.

Bazite is for people who want a computer to be like an iPhone near as I can tell.

Flatpak is simply a sandboxed application, similar to a Docker container. Its better to have natively installed applications over sandboxed if you are seeking the highest level of performance.

This is bullshit. Containers run natively on your system just like “native” [sic] applications.

I wouldn’t use arch for anything.

But even without , the arch way isn’t insane either: when something kernel-related breaks, boot with a live system on USB and fix it.

That is not a replacement for “arrow-key down during boot to select an older kernel”.

I have a server with a RAID card and the kernel at some point introduced a bug with the driver that prevented that server from booting. So I select the older kernel at boot, get the system up and running, mark that kernel as the default until the bug is fixed.

It’s not crazy, it doesn’t take long, you just need to know how the system works.

I know how the system works very well thankyouverymuch. But that’s an insane option when having multiple older kernels is so easy to do and common.

That’s… Insanity. Keeping at least one old kernel is amazingly useful if you run into issues with an update.

Don’t feel silly! It’s a common mistake, easy to fix, and easy to make. I’ve seen experienced developers do something similar.

It seems you’ve resolved the issue at this point but remember you can always run commands by specifying their full path as well (should you end up in a similar situation). All the PATH variable does is set the default locations to search when you don’t provide a full path to a binary.

e.g. /bin/ls or /usr/bin/vi

Ssh port forwarding and socks proxying. Unless they block port 22.

Edit: If they do block port 22 run ssh on port 443.