The original pass is just a single shell script. It's short, pretty easy to read and likely in part because it's so simple, it's also very stable. The only real dependencies are bash, gnupg and optionally git (history/replication). These are most likely already on your machine and whatever channel you're getting them from (ex: distribution package manager) should be much more resilient to supply chain vulnerabilities.
It can also be used with a pgp smartcard (in my case a Yubikey) so all encryption/decryption happens on the smartcard. Every attempt to decrypt a credential requires a physical button press of the yubikey, making it pretty obvious if some malware is trying to dump the contents of the password store.
Most of the popular touring bikes fit your budget. Really you're just looking for durable, a wide gear range and the capacity to mount gear. Surly disc trucker has historically been one of the most popular as an example, but there are a lot of others.
Also, it can absolutely be done with cheaper. My partner and I finished a 4800 mile trip last year. I used a second hand cyclocross bike that I got off craiglist for ~500 a few years ago. She had a road bike that she bought for 200 from the local bike project.
It looks like at least some of the individuals claiming production issues are pulling the latest version of Axios from a CDN. It doesn't seem like they actively pushed a release to production without adequate testing. Not that I disagree with your overall point, but it's at least a little bit less damning.
The parent comment is still talking about rootless podman (and really just user namespaces). Root in the container is absolutely mapped to the user executing podman outside the container.
If it mapped to root outside the container, you could just use podman to create setuid scripts owned by root for very trivial privelege escalation.
I've happily used systemd-boot in the past, but it's definitely less featureful than grub. Notably, it doesn't support the use of a (LUKS) encrypted boot partition. I'm not even sure it supports /boot on btrfs? Both are necessary if you want to have an encrypted root AND include the matching kernel / initramfs in any snapshots of root.
Systemd-homed isn't inventing the idea of encrypted home partitions and fundamentally, what you're saying is that cron is incompatible with encrypted home partitions (or any other auto mounted home partition, ex: network mounted). The same is true for the concerns about ssh.
If you listened to the original talk from Lennart, you're really just giving examples of one of his major points. Because /etc/passwd wasnt flexible enough to accomodate arbitrary user properties, user configuration has organically spread out over time into all these "side car" configuration files. Some are scattered around /etc so not easily portable while others are in the user's home directory and suffer from exactly the scenario you've mentioned. One of the goals of systemd-homed is to add a portable, extensible format for a user record external to the home directory which would mean that systemd-homed rather than causing, could actually lead to a solution for the issue you've highlighted.
One of the supposed benefits I remember from his original talk on systemd-homed is better handling of encrypted home directories even for a single user workstation.
Even on a single user workstation, having an encrypted root filesystem doesn't do as much good if your laptop is left booted up with the root filesystem unlocked most of the time. Systemd-homed in that scenario is supposed to make it easier to automatically unmount/mount on locking/unlocking the workstation.
I have to admit, the biggest selling point to me for podman is the removal of the central docker daemon. For my use case (personal workstation and home lab), it seems strange to me that I need essentially another service manager for these processes just because I want to slap them in a container. It definitely makes sense that there would still be some gaps though as it's a less mature product.
You've definitely convinced me to take a good look at LXC/LXD though. Thanks for the thorough response!
Have you taken a look at podman / buildah? My understanding is that podman resolves all of the security concerns you highlight above while mostly maintaining compatability with the docker cli and existing docker images. It gets rid of the docker daemon so your containers (and restart policy) can just be managed by your existing service manager.
I only just recently discovered podman and I've been pretty excited. Having never used LXD and only understanding the high level differences between the two, I'm curious how it compares with regards to security and usability.
Regarding apparmor/selinux, who creates/audits those profiles to make sure each application only has access to exactly the libraries it needs? It probably defeats the purpose if it's the app authors. Similarly, who validates that these profiles don't break functionality for any device/os version? I could see this being an option for power users who are willing to collaborate on creating the profiles and deal with fixing the occasional incomplete profile. I'm not sure how feasible it'd be as a solution for your typical user though.
JSON Schema and Swagger/OpenAPI provide some of the missing functionality described above (type definitions, enumeration, validation). It's not quite the same and in particular I'm not sure I've seen a reference to the schema passed with the json itself (although that could easily be ignorance on my part).
I'll admit to being ignorant of apt as my primary distributions aren't debian based, but aren't packages cryptographically signed? If package signatures are validated after download, then it shouldn't matter right?
Edit: Skimming and I shamefully didn't the read grandparent post. The link addresses exactly this point.
YubiKey is at least supported, but only because it also functions as a pgp smartcard. You can load you pgp private keys on the yubikey and then all decryption will only be done on the Yubikey itself.
I'm surprised there's not more discussion of passwordstore in this thread. In light of the parent article, I want to point out one of it's killer features (from my perspective). As it's built on top of PGP, you can move your private key to a PGP smart card and then decryption operations are done entirely on the smart card. Your private key never leaves the card. If you're using a Yubikey as the smart card, there's also a feature where you have to touch the card to approve of any operation (even when already unlocked by entering the smart card's password).
If you want to buy my house, sure. You're free to look at anything you want once you own it. It's yours.
What's not okay is for me to build a house and add recording devices all around and then sell it to you without informing you. Using your house example, that's the most direct comparison and would 100% be illegal.
There's obviously a trade off most users are willing to make between privacy and functionality, but I do believe the exchange should be 100% in the open and a conscious decision made by the user.
The original pass is just a single shell script. It's short, pretty easy to read and likely in part because it's so simple, it's also very stable. The only real dependencies are bash, gnupg and optionally git (history/replication). These are most likely already on your machine and whatever channel you're getting them from (ex: distribution package manager) should be much more resilient to supply chain vulnerabilities.
It can also be used with a pgp smartcard (in my case a Yubikey) so all encryption/decryption happens on the smartcard. Every attempt to decrypt a credential requires a physical button press of the yubikey, making it pretty obvious if some malware is trying to dump the contents of the password store.