The current thing I was working on was figuring out if I can do this: https://github.com/NilsIrl/dockerc . This project, compiles a docker image, and runtime to a single container. The interesting thing I find about it, is that it brings the docker container runtime and sandbox along. If I replace a user’s login shell with it, the user is now placed inside a sandboxed environment and can’t do anything.

My usecase is I want to replace people’s login shells with a container in a defensive cybersecurity competition. But, containers are not a sandbox, and full network access, and so on.

So my improvement, was to:

• Use the gvisor/runsc runtime instead of a normal container. Gvisor is a reimplementation of the Linux kernel in Go, and it is as secure as a virtual machine, way more secure than a normal container, BUT I can’t guarantee nested virtaulization is enabled
• Rip out dependencies on user namespaces or fuse for sandboxing or the container runtime, and entirely rely on Gvisor for isolation, just in case machines are old/misconfigured and those components don’t work
• Use Nix to build images and all in one executables instead: Nix has ways to package static programs that avoid pitfalls of above

I am having trouble meeting all of these requirements, so I suspect one or a few will go, or I will have multiple versions of the project with tradeoffs.

All of my projects, often involve doing something standard, but with extra constraints, or some kind of “twist”. Like a very common thing I find myself doing, is to do something normal, but then rip out one of the underlying components of the system, replacing it with something else.

I’ve found that I’ve learned a lot about how these systems work, without having to spend time building them entirely from scratch. You learn way more about Linux by reconfiguring your init system to enable encryption, than copy pasting from the Arch Linux Installation Guide the whole time, doing the standard setup. And then ignoring the partition layout so that my kernels are restored by BTRFS snapshots, which is not the default configuration.

That’s the way to break out of tutorial hell. You have to not follow the tutorial. You can still follow them most of the way, but you have to pick a few steps, and do something different. I pick something that I think will benefit or make my setup better in some way.

It is kind of difficult, since I feel like Linux has gotten more popular, and people know write more blog posts, and something that was previously a cool twist, is now something I can find a tutorial for. But with some care, you can ensure you still are learning, and it’s made easier by picking projects with twists.

Skill issue. I have to constantly convince the models that what I want to do is in fact possible, and that the “alternate paths” they give are things I already considered but discarded because of various reasons.

It’s gotten to the point where I would ask them to search for blogs directly, but they still try to give me hallucinated slop that isn’t actually what I want instead of following my instructions of being a search engine that filters out all the SEO slopspam that’s so prevalent nowadays.

I currently am doing:

https://blogsearch.io/

https://marginalia-search.com/

To find blogs directly.

Although I do almost exclusively Linux/Kubernetes stuff, and very little programming atm, that might be why I have a different experience.

Back when chatgpt wasn’t as broad (and people hadn’t posted blogs on as many things) I used to assign students things that chatgpt would find impossible do solve, and I got great glee from watching them spend a day trying to get chatgpt to do it entirely for them, before they gave up and had to actually learn. They can learn from chatgpt ofc, idrc, but it wouldn’t be able to do ut for them.

Nowadays, things like “set up nextcloud with caddy instead of apache” have 10 thousand (real, non hallucinated) blogposts about them, which have been fed into chatgpt so it can do that without much difficulty.

It is getting harder to find things that beginners can do that chatgpt can’t, but as soon as you move beyond the level of advanced beginner (also called being stuck in tutorial hell) in linux, you quickly find the LLM can’t do everything for you.

Account with no comments = suspicious af

Tailscale works great, but their free tier is limited to a total of 8 users, which is enough for a tiny minecraft server, but doesn’t seem to be enough for your usecase.

For 10-15+ users, you probably want to self host a VPN on your own VPS. Like, you can self host headscale, which is tailscale but self hosted. : https://github.com/juanfont/headscale [1]

I wouldn’t port forward game servers, because they often lack authentication (login and stuff), and then they also have security issues due to not receiving updates. If your game server isn’t truly public, then it’s easier to just have people use the tailscale client to connect to your VPN.

[1] Although I would recommend headscale to OP for it’s simplicity, it is very barebones, and software like netbird or netmaker is more close to a truly self hosted tailscale, with things like more advanced accounts, OIDC integration, authorization, and so on. But they are more annoying to host and set up.

OP is definitely a bot,

But both choco and winget use the upstream windows installers to download the program already, they just wrap/script it.

They might pull related programs, but they don’t really manage dependencies the same way Linux package managers do.

No, firefox doesn’t implement the webusb standard which they probably want.

https://developer.mozilla.org/en-US/docs/Web/API/WebUSB_API

The problem here is not browser support, but them not shipping a native application or library (which I would want to be open source).

Do nix and then use nix2appimage, or nix bundle to package the app compressed as an arx archive without the startup times they complain about.

You can also use https://github.com/DavHau/nix-portable to bundle it a bit better, without needing nix on the host.

And then, based off a quick search:

https://github.com/neobrain/nix2flatpak

https://github.com/barstoolbluz/nix2deb

I couldn’t find nix2rpm or nix2pacman, but there exist tools to convert between formats (alien, debtap, rpmtap, and one more who’s name I can’t remember but I remeber as being the most versatile).

What I’m trying to say, is that when people said “just use nix”, they probably really mean to use nix as a platform to build other packages withouth doing extra work.

On the other hand,

You can also use one of the newfangled appimage like formats: https://docs.pkgforge.dev/formats/packages

This one is linked in there and creates a static executable from any binary: https://github.com/VHSgunzo/sharun

Now they would still have to build for macos and windows, but they are already doing that anyways.

As a sidenote, there is also this: https://github.com/pacur/pacur , which is an aur like repo that buids debs, rpm’s, and pacman packages. So there’s semi-automatic updates, via a publuc repo you can out stuff on.

The real elite solution, imo, is to host forgejo, or use codeberg, which insanely has a package registry for every possible format of packages. So you can directly just push there, after building however you want.

But if developer’s were good at packaging, I wouldn’t be so mad when they try to do it.

Because this:

The next version will include a new built-in self-updating mechanism

Downloading unsigned, unverified binaries directly from the latest versioned github release?

Makes it so that all that’s needed for getting malware on the system is pwning the developers account via some supply chain malware, that hooks into there browser and pushes a release.

And every additional developer who can release, or every github actions that is potentially vulnerable but can be made to release, or claude (since the author is letting it commit, which requires it to run without sandboxing afaik) becomes more attack surface.

There are ways to fix this. Conventional distros use multi party signing of commits and releases, where developers continously verify eachother and look over changes.

More newfangled flows involve using github actions to build immutable releases, directly from tagged versions of the code.

But random developer #3989 isn’t doing this. They are distributing their software in a way that malware distributors will be ery happy to see after pwning their account.

I want devs to use nix, because then I can build or run their program directly from the source code. It sidesteps so many issues with visibility of the supply chain, or being unable to inspect what I am running.

I like nix becuase I can make developers like the above satisfied by giving them a way to easily build static binaries, or other formats.

Nix is also packaged in debian as nix-bin.

Anyway I was gonna write a rant about it but I’m too tired. But basically the docker ecosystem is kinda fucked in this regard, and trades security in many aspects for convenience of development and distribution. This is one of the most notable examples of this.

It’s popular because it’s convinient and easy to use in many ways. If these pitfalls are a dealbreaker for you, then there is no trivial way to add the security requirements you are asking for.

You can pay for signed images from someone else, which is a little better, but there are still disadvantages.

Also what are you building? You might be able to replace docker with nix for example.

I think the most popular solution is locally building and registry.

The version you get from Debian does respect all four freedoms.

The version that is installable from the repositories of Linux distros is all open source. Docker itself, the container engine and runtime are all open source. Nobody cares about stuff like docker desktop or docker sbx, not only are they not critical to the software itself, they aren’t that useful or valuable.

Lichess

Docker is foss. Docker desktop and docker sbx are not.

What do you use for notes and file/note syncing?

Also backups?

Is your comment supposed to say “native pf or nftables”?

See also: https://strudel.cc/workshop/getting-started/

the whole concept of stable distributions is that the software was used for an extended period of time before tha

Not quite, the whole concept of these ultra stable distros is that they take a version of the software, and essentially pin, it, cherrypicking mostly, or only security changes as updates. The version of the software that is selected, can be, and usually is from a much newer version of the software overall.

Because of this, Debian and Ubuntu have an interesting pattern, where each one doesn’t universally have older packages than the other. Instead, a new Debian release comes out, it has newer packages, then a new Ubuntu release comes out, and they alternate.

Anyway, during the process of releasing a new stable distro, the programs are libraries are assessed, and then tested a bit before being included. In theory, if you had enough manpower, and you were fast enough, you could probably pin close to the current latest version of things, and then have those in your stable distro, even if they have only been out for a short period of time.

The idea of “program version has been released for 2 years, now let’s include them into a stable distro”, is not how they actually work. Instead, the pinning and then security updates model, deduplicates a lot of work, because now you only assess the security and quality of the programs to be packaged once, instead of continuously every single update.

It’s not about eliminating bugs by using well tested programs. Stable distros are about ensuring the stability of the behavior of the system. The same set of, of predictable bugs, rather than a constantly changing set of them.

If you use a stable distro as your programming language supply chain, you essentially don’t have to deal with security updates in dependent libraries, or worry about supply chain security. Any dynamically linked language is able to do this, but my frustration with Rust is that this is not an option, which is something I really hope changes in the future.

The model of stable Linux distros, particularly Red Hat, Debian, and Ubuntu is impressive in that they only ship cherry picked security updates, and don’t ship general updates overall, often even forgoing bugfixes. They are extremely resilient against supply chain attacks.

The XZ utils backdoor, for example, did not make it into either of those three distros. That’s why I hate when it’s compared to programming langauge specific supply chain attacks, because there is a big different. With Debian/RHEL, you have 4+ years to catch a supply chain issue, rather than whatever your dependency cooldown is.

And then, the lack of any non-security changes means that the system behavior is stable enough to base software on it that automatically receives security updates to libraries it is using.

This is why enterprises like RHEL so much. For so many institutions, manually managing updates is a cost they are unwilling to, or straight up unable to handle. The idea of manually doing updates, or bypassing cooldowns in order to get a fix for some critical CVE, is way more expensive than it’s worth at scale, especially for institutions that aren’t going to actively take advantage of new features, like so many slow moving government entities or so many non tech focused corporations.

I like the model of Rust, and believe it is the future of systems programming, but I am intensely frustrated with the way it is tied to an ecosystem that is extremely sloppy about supply chain security. The Linux kernel and Firefox may use Rust, but they don’t actually use the Rust ecosystem, they copy all crates they use into their own tree, and then cherry pick and review changes, or maintain the software themselves entirely. All Rust code Linux/Firefox use is owned by themselves, although I think that such a model is only possible due to the development resources they have.