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.

A common distribution method involves multi-party signing, that is, multiple developers use keys to sign off on reviewed changes.

Multiple developers review the changes, before signing the git commit after review. Then they build the package, either locally or on CI servers, but again, multiple parties/servers sign and review, doing a reproducible build to verify across machines.

In an ideal architecture, there is never a single point of failure. You would have to compromise the computers of multiple devs, or multiple build servers that are building signed reproducible builds, in order to do it.

Although in theory, you could compromise all of them. But it’s extremely difficult.

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.

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

Guix does not have that same churn by any stretch, but, would still offer all the wonderful features of NixOS if you are willing to do the work of setting up any packages yourself, that do not already exist, and that is not at all removed from my to do list

One of Guix’s strengths, and one of the things that appeals to me over Nix, is importers:

https://guix.gnu.org/manual/1.5.0/en/html_node/Invoking-guix-import.html

You can import packages from go, ruby, python, rust, or a few other languages really easily. Just guix import packagerepo and boom you have a package. This makes it significantly easier to get packages from those ecosystems.

Now, Nix has unofficial equivalent functionality… but it’s a mess and spread over 30 different projects, many of which would frustratingly only work with flakes (which are “experimental” and “not officiallly supported” despite the fact their extreme popularity), or only work with channels.

I remember this pain point when trying to import a python package with nix. The only “just works” way of doing it that only worked via channels… and was deprecated, with the repo being archived. There was this new, non deprecated way by the same group of people… that didn’t support a specific feature I needed to get the python package to work. And to the best of my understanding, still doesn’t.

Guix may not move as fast as Nix when it comes to packaging or innovation, but they have a certain “coherency”, where everything is together, integrated, well documented, and guaranteed to work.

Yes, although there have been a few CVE’s related to escalating privileges or breaking out of the sandbox. You’re going to want to keep those updating and keep on top of those.

There is one concern, in that the nix store (/nix/store) is world readable. It is not world writable, which is good, but there is a problem in that secrets can potentially be copied into the nix store. If you copy a file containing environment variables or the like into the nix store, it could theoretically be found it. This one is on the users of nix to be careful of.

With Nix flakes, the entire git repo that the flake originates from is copied into the nix store. Meaning if you have a nix flake in something that is supposed to be a private repo, or contains tracked sensitive data (untracked files are not copied into the nix store), then it could be found and inspected by other users.

My big concern with multi user in this case is not merely the Nix daemon though, but also Linux itself. Linux has been hit with a LOT of privilege escalation and container escape issues over the past few years, and many of them have been zero day’s. Given this, I no longer really have the same level of trust for Linux with regards to multi user isolation, for in cases like these.

Of course, in academic computing, I would probably just do multi user anyways, for simplicity. If you install tracking and monitoring, then you can attach malicious actions to identities. Because every user is registered and operates within the institution, if they break the terms of use for computing equipment, then you can punish them within the institution, or pursue greater legal action.

And then, you also would want to enforce 2FA to help minimize stolen accounts. While that can still be phished via fake login pages that ask for 2FA, it handles most of the things. Isolate the server via firewalls, and then it becomes a small enough target that doesn’t have enough value (assuming of course, your research isn’t too valuable and worth targeting), and you mostly don’t have to worry about it.

Sure, people will root it. But then they’ll send you a nicely worded email explaining how they rooted it and how to fix it. Which is what my friend did at my school, on our shared ssh server. Just keep it updated to handle the low hanging fruit.

However, if you are going to give it to untrusted users with unknown or temporary (not within the institution) identities, then things change, and you have to take it a lot more seriously. I no longer have confidence in just Linux’s user based isolation.

The first line solution I would go to, is to put users in containers and mount the nix store (and nix daemon) in and out. Something like a docker/podman container or Incus container. Of course, container escapes are still possible. If you are even more concerned about those, then you would want virtual machines. It is still possible to share the nix store between virtual machines, but it is more complicated.

In addition to that, virtual machines have a performance tradeoff (usually 95% or more of the host’s performance though), but there might be issues with sharing GPU compute resources among virtual machines, depending on the hardware you are using. Enterprise GPU’s usually support it though.

Debian has a policy of only cherry picking security updates, or critical bugfixes, in order to ensure maximum system stability. In general, they don’t do entire program updates or additional features. For the 4 year lifecycle of a Debian release, it will behave the same as it did yesterday.

As of today, current version of rsync in Debian’s stable’s packages is 3.4.1: https://packages.debian.org/stable/rsync (archive).

The versions with significant LLM assistance are 3.4.3 and later.

the physical display output is claimed by something else totally separate.

Yes, and the above solution I laid out is a way to get around that, that potentially dodges the complexity of configuring a truly headless session. It’s possible to run two KDE sessions at once, next to eachother, and then simply put one on the main display, with the second being “headless”, and not shown.

I started fiddling with the above setup I described, actually installing and testing sunshine. Unfortunately I hit some hiccups. I got sunshine to run, but with no input, and then then it attached to the wrong KDE, even though it was streaming the correct one initially. Now I’m running the same KDE session as a different user (since I was on the same user before), but having pairing issues, but I suspect these are because moonlight is seeing the wrong SSL cert, since the sunshine as a new user generated a new cert.

Do you actually need the headless backend? Or do you need a background session that doesn’t interfere with the main session?

Second comment:

https://docs.lizardbyte.dev/projects/sunshine/v0.21.0/about/guides/linux/headless_ssh.html

There is also this guide, but it is specific for Xorg and Nvidia gpus. But I suspect that if you replace the startx here with startplasma-wayland or dbus-run-session startplasma-wayland, then it will work. It would still be nvidia gpu specific though.

If you log in (preferably as another user) to another tty (Cntrl + Alt + F2/3/4/5), and then run dbus-run-session startplasma-wayland, does that work?

Sometimes just startplasma-wayland works, which used to work for me but didn’t work for me this time.

Then, you should be able to switch back to the original KDE session, which continues to work normally, at least it does for me. Both sessions should have shared access to the GPU, as well. You can then probably run sunshine in that second instance of KDE, while the monitor can be attached to tty1 or tty2, whichever one is the default where KDE is put.

Then, you would probably want to configure sunshine to work even when the screen is locked, that way you can lock the second session with Win + L, but it can still be interacted with remotely via sunshine.

Certbot?

It can automate provisioning of certificates using DNS-01 challenges, which have wildcard certificates.

https://eff-certbot.readthedocs.io/en/stable/using.html#dns-plugins

Example tutorial: https://www.digitalocean.com/community/tutorials/how-to-create-let-s-encrypt-wildcard-certificates-with-certbot

Once you do that it puts the cert in /etc/letsencrypt/live/ so you can then do whatever you want with it. You would have to handle distribution manually.

If you want to automate stuff across of a bunch of machines at once, I recommend Ansible: https://docs.ansible.com/projects/ansible/latest/index.html