In theory it is safe. When a Nix package is built it isn’t “installed”. Unless root is running/installing random packages out of the Nix store there is no problem. As long as the user’s aren’t added to the trusted-users option they shouldn’t be able to cause any problems for other users.

However like any multi-user system you are sharing a Linux kernel. A kernel is a very complex piece of software with a huge attack surface. Privileged escalation vulnerabilities are commonly found. (This also applies to the nix-daemon, but it is a bit smaller attack surface but vulnerabilities are still occasionally found.) So you shouldn’t assume strong security isolation. I would say that a setup like this is acceptable for mostly-trusted people like coworkers or friends that are not expected to actively exploit vulnerabilities but definitely wouldn’t let random unknown users use the system.

So if you want strong isolation use a VM or separate hardware, but then you won’t be able to share the builds and packages defeating the point in this case.

This advice feels like “Have you moved to the surface of the sun? Make sure to drink lots of water.” It’s not wrong, but also not particularly helpful. The only solution is to stop buying these things. Ideally take them back and get a refund if it isn’t too late.

Please explain what you mean and how this could be abused. What does “real” mean in this context? They both have the same code. It would probably help if you can provide a specific attack that could actually cause harm rather than just stating facts that have unclear risk.

It doesn’t mutate history. It just creates a new branch of history in their own fork. Just like any new commit would do.

I don’t understand. Why does having two commit IDs with the exact same code cause problems.

A green “Verified” badge on GitHub is supposed to mean that a trusted author signed it

The author did sign it. It is the exact same code.

An attacker can reissue the same signed code under a fresh ID that’s still verified to slip past.

To split past what? At best it seems that they would be able to have a different ID for the exact same code, which seems harmless? Slightly confusing at worst.

Nix also doesn’t use PGP signatures, it requires a separate hash of the resulting commit (the files with the .git directory stripped by default).

I’m a little confused by what this is saying. It seems that you can create a basically identical commit with a different signature and thus a different (hashed) ID.

So basically you can take a Signature S1 and produce a valid Signature S2 over the same data that is not identical.

This doesn’t seem like a very useful exploit primitive to me. Not nothing, but doesn’t seem like a big deal. I feel like I am misunderstanding something.

Generally speaking it will be fine. SSH will also refuse keys with open permissions so you would notice if it was wide-open to other users of the device.

But you know if you are running random code or AI harnesses as that user it can be at risk. Or if you copy around the key all over the place it is more likely to leak. But generally speaking you are secure by default, just don’t do something dumb with the key and you’ll have no problems.

It sounds pretty reasonable. As long as you keep SSH patched and keep the key safe it should be quite locked down. Do double-check that password login isn’t allowed (or that all users have a very strong password).

One non-security note is be careful with rsync backup. Generally rsync isn’t considered a backup as any mistakes made in the source will be propagated to the “backup” on next sync. Although there are ways to use rsync to take good backups (like copying to a new directory for each backup).

I built Chibichange to have a way to conveniently deliver changelogs to Dawarich users

Have you considered just posting a changelog to your blog? That would be much more convenient than every app I run pinging me in its own way by phoning home to its server.

Because every three letter acronym means more than one thing. There are only 17 576 TLA so they are going to be heavily duplicated.

You should almost always spell out acronyms on the first use.

Oof, that is really not a good look. This should have been clearly disclosed and probably with a per-notification for the patch release.

I doubt Gaussian blur is an accurate model of real-world situations.

At the end of the day if you are worried about the codes being painted over print a few out and paint over them. Then scan with a variety of scanners.

If I had to come up with some more digital tests I would guess that a few of these are more representative of real-world situations:

1. Lower contrast. For example lighten or darken the whole code. This would simulate things like scanning in low light or with glare.
2. Block out sections of the code. This will test error correction levels and simulate partial damage or pockets of extreme glare.
3. Skew the code in various ways. This simulates the perspective shift of people scanning the code from an angle.

Ideally combine them in a bunch of scenarios then try to scan with a variety of scanner implementations.

No, the DRM wouldn’t work at higher levels so you would have the same requirements with regard to 4k.

You seem to be making this very complex. But it really isn’t. Yes, git doesn’t track renames. So you are working around it by splitting your operation into 2 commits.

1. A pure rename.
2. A file change.

This way 1 is always considered a rename and 2 is just a regular file change with the same path. You may also consider tweaking the default rename detection threshold with flags like --find-renames or options like diff.renameLimit.

Would it be nice if Git tracked renames? Probably. But that isn’t how the data model works so it is unlikely to happen soon. But maybe they could add some metadata.

I think it doesn’t really make sense. Because you can’t “squash” one commit. squash is taking multiple commits and making them one.

When you do a “squash merge” you are really saying “squash all the commits that are on this branch and not the target” then merge.

So you can’t “squash a merge commit” you need at least one additional commit to squash in.

No, but you can still choose to choose software that doesn’t steal and sell your data. You can also support laws that make doing this illegal.

The idea that putting this on your phone is bonkers is bonkers to me. Why would you want to carry around a journal or paper when you have everything on your phone? It can also be more easily backed up and synced.

It shouldn’t be normal that this data is stolen and sold. That is 100% the problem, not the fact that people track things on computers.

You have obviously never tried dereferencing a null pointer.

It’s also super locked down. You are only allowed to use it if Google or Apple says that your device is authorized. So no root, no custom ROMs. Unless your phone is owned by a corporation and that corporation is blessed by Apple or Google you are out of luck. (There are currently ways around this but the gaps are slowly being closed as older devices are phased out.)

IF no dependency tries to update too. Off course in that case I would stop. Without pacman -Sy, I never do that anyway, only -Syu.

That’s all you need to know. As long as you always use pacman -Syu you will be fine. pacman -Sy is the real problem. The wiki page is pretty clear about the sequences of commands that are problematic https://wiki.archlinux.org/title/System_maintenance#Partial_upgrades_are_unsupported.

Right? What i don’t understand is, when I uninstall with pacman -Rs firefox, delete the cached firefox package (only that file), then the system is in the same state as before I installed it. Then -S firefox should be okay, right? And it even looks up the new version.

This isn’t correct. It won’t look up the new version. Assuming that the system was in a consistent state it will download the exact same package that you deleted. The system only ever “updates” when you run pacman -Sy. Until you use -y all packages are effectively pinned at a specific version. If the version that gets installed is different than the one you removed it probably means that you were breaking the partial update rule previously.