…that proved that the algorithms/protocols work.

You can use a perfect algorithm and still be insecure because the implementation was bad. You are trusting the SimpleX Chat devs to a degree.

I wouldn’t trust encryption made by anti-vaxer more than…

Important to note: SimpleX Chat has gone through two security audits.

The SimpleX Chat is AGPL. If the founder is problematic, one can fork it and avoid reinventing what has already been made.

It is forkable if necessary. I do think SimpleX is a great piece of software that shouldn’t be reinvented because of the founder.

There’s some time limit before having to re input it.

Inputting a password multiple times into sudo has downsides too. Larger window for attackers to do something like: add a directory to your path, which has a fake sudo in it, and capture your password.

Yes. Memory allocated, but not written to, still counts toward your limit, unlike in overcommit modes 0 or 1.

The default is to hope that not enough applications on the system cash out on their memory and force the system OOM. You get more efficient use of memory, but I don’t like this approach.

And as a bonus, if you use overcommit 2, you get access to vm.admin_reserve_kbytes which allows you to reserve memory only for admin users. Quite nice.

If by “unused” you mean not actively storing data, then the Linux kernel docs disagree.

vm.min_free_kbytes

Unless you have the vm.overcommit_memory sysctl set to 2, and your overcommit is set to less than your system memory.

Then, when an application requests more memory than you have available, it will just get an error instead of needing to be killed by OOM when it attempts to use the memory at a later time.

If such a project were to become compromised (the way XZ-Utils was), it would eventually spread to Ventoy.

What a lot of people don’t know is that the XZ attack entirely relied on binary blobs: Partially in the repo as binary test files, and partially in only the github release (binary).

If someone actually built it from source, they weren’t vulnerable. So contrary to some, it wasn’t a vulnerability that was in plain view that somehow passed volunteer review.

This is why allowing binary data in open-source repos should be heavily frowned upon.

You can modify the keybinds in software too. You would need to change your console keymap (TTY) and your desktop environment keybindings. Programmable keyboard is most likely easier though.

I played around with it and changed both to just use F1 = tty1 and so on, without requiring CTRL+ALT.

Your needs must be different than mine.

I press one button combination and have root without ever entering a password. I press a similar combination and go back. Not sure how this is a pain in the ass.

All I do is have agetty --autologin root tty2 linux run as a service. It launches on startup, and I just hit CTRL + ALT + F2 if I ever need a root shell.

All its doing is just auto logging-in as root on TTY2.

From what I’ve read, no. Though it doesn’t solve the fundamental problem of a root process handling untrusted input from a regular user.

The TTY method is IMO better as it ties privileges to a piece of physical hardware, bypassing the complexities of userspace elevation of privileges.

The nosuid mount option disables this behavior per mount. Just be sure you don’t use suid binaries.

Example: sudo or doas. I replaced those with switching to a tty with an already open root account on startup. Generally faster and (for me) more secure (you need physical access to get to the tty).

My biggest gripe with flatpak is the fact it isn’t sandboxed properly by default.

I’m not referring to vendor-given privileges. Every flatpak, unless explicitly ran with the –sandbox option, has a hole in the sandbox to communicate with the portal. Even if you try to use flatseal to disallow it, it will still be silently allowed.

This leads to a false sense of security. A notable issue I found is if you disallow network access to a flatpak, it can still talk to the portal and tell it to open a link in your browser. This allows it to communicate back to a server through your browser even though you disallowed it. Very terrible.

Security should to be dead easy and difficult to mess up. The countless threads I’ve read on flatpak tell me the communication about flatpak’s actual security has been quite terrible, and so it doesn’t fit this category.

Ignore the downer replying to you. If you found something that works well for you, then great!

… Alpine is designed to be friendly to corporations who want to lock down their devices and prevent you from modifying them.

“Designed to” assumes intent. Alpine is absolutely designed to be Small, Simple, and Secure. Using busybox instead of the GNU coreutils is a means to this end. Using musl instead of glibc is a means to this end.

On the about page they list why they use these tools. The licensing is not listed at all.

If they don’t have the training data available, then I wouldn’t consider them open source.

The difference would be that RMS is extremely well-versed in computer technology. He understands the problems with non-free software.

Someone with his knowledge could choose to disregard those issues for convenience, but Stallman is willing to make great sacrifices.

But now it’s too long for a power user.

Short and Long options are a thing.

Ex: GNU rm can use

--recursive

-r

or

--force

-f