jutty

Average Debian system update experience:

All packages are up to date.
Summary:
  Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0

Mint is a glorious debloat of Ubuntu with several extras and are strategically wise in having LMDE ready and in production. They fill a very important role as an user-friendly not-DIY distro suitable for someone completely unfamiliar with Linux. I wouldn’t describe Fedora that way. It changes too fast for that use case and compared to Mint comes with not much preinstalled.

I wrote a small script that takes a query as its single argument and if it finds a matching filename in a given directory it shows that in a pager. If it doesn’t, it uses ripgrep to search inside that directory and returns the filenames in a picker. If I prepend the filename with e, it opens that file (either existing or new) in an editor. Then I track that directory with Git.

This way I have a quick way to store, find and retrieve notes from the terminal itself.

That’s already configurable in Settings > General > Share Links.

I’m focusing on the lock screen as having one single job to do well: protect the session from any access not granted exclusively through the password.

You posit this as if the attacker and the killing of the lock screen were connected: the attacker can only kill if they already have malware, so “it doesn’t matter”. But the point is, if the lock screen won’t relinquish access upon receiving the kill signal, even if the attacker had compromised this vector, or if there were some other cause behind the lock screen dying, crashing, whatever, access would not be granted in the first place. It stops at that layer.

Thinking in terms of “if they already can access the system, whatever” is different from thinking about security in depth/layers. So its not so much about the cause of the problem, but where you can contain it. This threat (a physical access attacker) is pretty extreme, but if we are going there, then yes, it’s not unfeasible to think that they could leverage this weakness to go from a possibly limited shell access to a fully unlocked physical session where you could have unrestricted access to e.g. a browser or unlocked password manager or other in-memory information.

But the two things don’t really need to be connected. The lock screen having a secondary way to allow access that does not require the password is a weakness in itself, that the attacker could exploit, but that should not have been there in the first place.

Not all processes that can send a kill signal to another process have the same degree of access as physical access. The fact they are already running inside the session doesn’t automatically imply they have unrestricted access. In fact, you could argue no access at all a process has can compare to physical access. So that’s quite an escalation.

If killing your lock screen unlocks the system, that signals there is actually little protection. Killing a lock screen should kill the session and log you out, or at least render the session unusable.

If you still want to go that route, you could wrap your hibernation process in a script or use a slightly more complex service setup to kill it once, by inspecting system/service state and enqueued systemctl operations, you determine hibernation is done (not pending)

Just fiddled with it to see how it works. And sorry, I’m not aware of any reviews to recommend.

https://radicle.xyz/ fits your description

Yes, Fossify came precisely as a continuation for the Simple apps. The https://github.com/FossifyOrg org and the website https://www.fossify.org/ are linked from the F-Droid metadata so they should be legit as well.

See also: https://f-droid.org/2024/01/04/twif.html

I think the ethos of open source flips this thinking. You should not trust. Microsoft may not be noting down your banking details, but you actually don’t and can’t know if it is. What it is doing is storing other personal data, because that is in its policies. Now, to what extent it takes advantage of this capability and permission, it is again unknown and unknowable.

Microsoft may be a big corp, but some distros are the backbone of highly critical systems, and collectively they run the vast majority of servers.

You don’t “trust” your distro. Or your laws. Everything being done is in the open, so you can see for yourself. If you lack the knowledge to do that, there are others who are doing it and many are sharing what they find. You will “trust” on some level, because of its reremovedtion, how established it is, but trust here means something very different from letting a huge blob of unknown code do whatever it does because I trust you.

That’s the best, safest way. By the way, you can do the same thing from a flash drive too, if it has enough space to hold the system. I don’t mean as a live temporary system, I mean you can just point the installer to a second flash drive as the install disk and it won’t care.

For Debian there’s Preseed, for Arch there’s archinstall, for a Fedora/RHEL there’s Kickstart, for Alpine there’s setup scripts, for distros with fully manual installs, you could just write a script?

Automating your install is something any sysadmin and mainly any distro developer will quickly reach towards, so it is something almost certain to exist.

Though, if I understand you, you’d want that to be “sourced” from an existing system, yes? I can see the use of that… NixOS is likely the closest to what you want, since you are always defining a full declaration of your system.

The PC itself as in hardware? Hardly… Your data is at risk. So ignoring updates for both Mint and Windows will put you in a more vulnerable position from a security standpoint.

If you are asking if not updating Windows will make your Mint system insecure, the answer is no. At least to me an exploit leveraging an unmounted Windows partition is unheard of. It will of course make your Windows system less secure for the 2% of the time you do use it. Another side effect of updating it is that it may break your dual booting.

While another comment covered the matter of security updates, another point that is safer about repositories is the security of the binary and the transaction. Meaning, the place you get your software from and how this transference is accomplished are also security sensitive.

When you get the software from a repository, you typically have some assurance that (a) the binary you are getting was compiled from the source that is published (b) the source from which you are downloading is known and trusted © the method through which you are transferring is somewhat secure (e.g. TLS) (d) the changes made were inspected by at least one more independent party (depends on the repository’s policies).

Repositories will also have criteria for inclusion, which can bar you from software you want, but still could also mean software with bad security practices never reached you to begin with. Being included in the repository might also mean it’s up to more scrutiny, as it may be removed depending on what security events happen in the future.

Say that instead we were to get the software directly from the original source. How will this source transfer the software to you? If they publish it on a website, that adds one more attack surface where, if an attacker tampers with files, hashes and/or links, you are now no longer getting it from the source. Say instead you get it from a Git forge such as e.g. GitHub. Is the binary being built form source in CI? Or is it uploaded manually? Does it provide a hash? How can we know the manually uploaded binary, even if it has a hash, was compiled from the publicly available source? There is no trusted, independent third party involved to confirm that.

I can think of a few other reasons unrelated to security, such as repositories, particularly distro/OS-specific repositories but not only them, will tailor the software to your OS, resolve dependencies for you and add niceties such as init system integration, shell completions, man pages and sample configuration that is specific to your OS.