moonpiedumplings

Although google happily lets you log into more than one account from the same browser, microsoft doesn't let you.

I used to, and still do use profiles, which are basically entirely seperate instances of firefox for each main account.

Back when I tried containers, they were really frustrating, because they would always ask which container I wanted a tab in. But that was a while ago, and they've probably fixed my annoyances so I will try them again sometime.

Straying away from utilities, games are always fun to host. I got started with self hosting by hosting a minecraft server, but there are plenty of options.

So instead you decided to go with Canonical's snap and it's proprietary backend, a non standard deployment tool that was forced on the community.

Do you avoid all containers because they weren't the standard way of deploying software for "decades" as well? (I know people that actually do do that though). And many of my issues about developers and vendoring, which I have mentioned in the other thread I linked earlier, apply to containers as well.

In fact, they also apply to snap as well, or even custom packages distributed by the developer. Arch packages are little more than shell scripts, Deb packages have pre/post hooks which run arbitrary bash or python code, rpm is similar. These "hooks" are almost always used for things like installing. It's hypocritical to be against curl | bash but be for solutions like any form of packages distributed by the developers themselves, because all of the issues and problems with curl | bash apply to any form of non-distro distributed packages — including snaps.

You are are willing to criticize bash for not immediately knowing what it does to your machine, and I recognize those problems, but guess what snap is doing under the hood to install software: A bash script. Did you read that bash script before installing the microk8s snap? Did you read the 10s of others in the repo's used for doing tertiary tasks that the snap installer also calls?

# Try to symlink /var/lib/calico so that the Calico CNI plugin picks up the mtu configuration.

The bash script used for installation doesn't seem to be sandboxed, either, and it runs as root. I struggle to see any difference between this and a generic bash script used to install software.

Although, almost all package managers have commonly used pre/during/post install hooks, except for Nix/Guix, so it's not really a valid criticism to put say, Deb on a pedestal, while dogging on other package managers for using arbitrary bash (also python gets used) hooks.

But back on topic, in addition to this, you can't even verify that the bash script in the repo is the one you're getting. Because the snap backend is proprietary. Snap is literally a bash installer, but worse in every way.

Except k3s does not provide a deb, a flatpak, or a rpm.

I consider it a lesser evil to use curl | bash once to install Nix and then get the latest version of packages like rustup and deno than to use curl | bash twice or more to install software on their own (in addition to my opposition to developers installing software on users machines).

And again, cycling all the way back around to what I said in the earlier comments, you still have not provided an example of bash scripts you would like packaged that do stuff other than installing software. You talk about wanting a general repo of scripts, and I have also expressed my concerns about that, and the problems with losing it's portability when you need an extra tool instead of bash and curl/wget.

We are just rehashing the same points.

Canonical's snap use a proprietary backend, and comes at a risk of vendor lock in to their ecosystem.

The bash installer is fully open source.

You can make the bad decision of locking yourself into a closed ecosystem, but many sensible people recognize that snap is "of the devil" for a good reason.

I've tried snap, juju, and Canonical's suite. They were uniquely frustrating and I'm not interested in interacting with them again.

The future of installing system components like k3s on generic distros is probably systemd sysexts, which are extension images that can be overlayed onto a base system. It's designed for immutable distros, but it can be used on any standard enough distro.

There is a k3s sysext, but it's still in the "bakery". Plus sysext isn't in stable release distros anyways.

Until it's out and stable, I'll stick to the one time bash script to install Suse k3s.

I find this comparison unfair becuase k3s is a much more batteries included distro than the others, coming with an ingress controller (traefik) and a few other services not in talos or k0s.

But I do think Talos will end up the lighest overall because Talos is not just a k8s distro, but also a extremely stripped down linux distro. They don't use systemd to start k8s, they have their own tiny init system.

It should be noted that Sidero Labs is the creator of Talos Linux.

Apologies for the second comment, but I do want to clarify that I find curl | bash okay when they are used to install a package manager or platform that can install more software. (in more than one programming language, though).

I find that acceptable because:

1. Such installation methods are made by the package maintainers who maintain the "distro" of Nix, rather than developers.
2. The package managers (nix, brew, etc) can be used to install software that would otherwise be obtained with curl | bash.

There are very few software of these exceptions, however.

If the answers aren’t “yes” and “no”, respectively, your app belongs in the garbage. Do not pass Go.

Please see my comment about this issue. Signal does not pass this test due to not having (working) reproducible builds.

So Soatok advocates for signal as pretty much the "gold standard" of e2ee apps, but it has a pretty big problem.

1. Having signal be the distributor of the app, sorta breaks the threat model where you trust the app to encrypt data and hide it from the sever

2. Signal is hostile to third parties packaging and distributing signal

The combination of these problems is suppose to be fixed with reproducible builds, where you can ensure that any user who builds the code will get the same binaries and outputs. Soatok mentions reproducible builds and the problems they solve on another blogpost

But signal's reproducible builds are broken.

The problem is that the answer to Soatok's second question "Can you accidentally/maliciously turn it off" is YES if you are using packages directly from the developer without signing to verify their identity and reproducible builds. They could put a backdoor in there, and you would have no way to tell. It's not fair to pretend that signal doesn't have that flaw, while dissing OMEMO

To understand why this is true, you only need check whether OMEMO is on by default (it isn’t), or whether OMEMO can be turned off even if your client supports it (it can)

(Although there is an argument to be made that having e2ee always on by default would minimize user error in improperly configuring it).

Now, I still think signal is a great software choice for many things. It's basically the best choice as a replacement to text messaging, universally.

But some people need something more secure than that, if you're seriously concerned about certain entities compromising the signal project, than you must have the ability to install clients from third party distributors and developers, even though they can have security issues, which Soatok notes in a post about Matrix (see the heading "Wasn’t libolm deprecated in May 2022?").

I thought the whole point of choosing Matrix over something like Signal is to be federated, and run your own third-party clients?

Yes Soatok. Depending on your threat model you may need to be able to choose from more than client implementation, even if all of them are trash except for 3. (Although I wouldn't recommend Matrix as a private messeger due to metadata like users/groups being public, but it's shaping up to be a great discord clone with PM feature. Is the crytography as secure as signals? No. But it checks the box of "Discord but doesn't sell my data" (yet ofc, Matrix is VC funded).).

Anyway, it's frustrating how he seems to have become more of a hardliner about this. It used to be that these were the bar to clear to become a signal competitor. Now these standards are the bar to clear to be recommended entirely (see the main section about "How do experts recommend secure messaging apps"), even though Signal itself doesn't clear them.

dev can keep using bash

I don't want "devs to keep using bash". My security problems are with the developer distributions of these softwares themselves, rather than bash. Even if developers offered a rust binary as an installer (or a setup.exe), I would still be miffed and disappointed with them for doing things like vendoring CVE's into their software!

Simply having this discussion brings attention to the issue, and to alternatives for getting packages onto the users machine, thereby increasing their security. There's a reason why it's a hot topic whenever it's brought up.