For your home network, you might like Mozilla SOPS for secrets storage. You can keep your secrets in an encrypted file and have a container that loads those secrets and puts it into each service's environment variables. At least that way you aren't committing plaintext secrets to source or having them laying around in the clear, plus it's a breeze to manage and edit them.
Ugh, that this psyops sockpuppetry may have started or contributed to the maintainer's mental health issues seems like the most depressing part of all this. Maintaining OSS is hard enough.
I hope that one takeaway from this entire situation is that if you're a maintainer and your users are pushing you outside your levels of comfort, that's a reflection on them, not on you - and that it could be reflective of something far, far worse than just their impatience.
If you, as a maintainer, value stability of not only your software but also your own mental health, it is entirely something you can be proud of to resist calls for new features, scope increases, and rapid team additions.
Yeah, that was a hard read. I think it highlights the importance of emotionally distancing yourself from your projects.
It's also interesting because it exploits the current zeitgeist when it comes to maintainers' responsibilities to their users and communities. Personally, I think it puts too much expectation on maintainers' shoulders, especially when they're working for free.
Personally, I think maintainers are doing favors for users, and if they don't like how the project is progressing or not, then too bad. That's not a popular sentiment, though.
Probably didn't start them, considering that he already mentioned (long-term) mental health issues in the mailing list discussion in which the (likely) sock puppets started making demands.
But it's hard to see the whole thing helping, and it is some combination of depressing and infuriating. I hope he's doing ok.
NIST dropped the password change recommendation a while back [1] but it still lingers on. The staying power and long tail of this deprecated advice is unfortunate, to say the least.
I don't personally agree that short sessions is bad advice, but Phil Venables has an article that you might enjoy, "Ceremonial Security and Cargo Cults" [2]
My experience with security auditors from big firms is that they have a checklist including recommendations like 90-day password changes, composition rules, and so on, and will probably never get rid of those.
You may be able to explain to the assessor that "we don't force password changes because NIST no longer recommends it", and they may be sympathetic, but they are still ultimately going to deliver a report that you got dinged on two items because you answered those parts of their questionnaire "wrong".
I have had issues raised for a site having a robots.txt file. NOT that there was a sensitive URL listed in the robots.txt file, or that we were using it to try to hide stuff that wasn't locked behind authentication. Just that we had one at all.
It ends up being way easier to just get rid of it and comply, than try to explain to multiple people at different levels of management how robots.txt works and how it could be associated with vulnerabilities due to misguided usage while also having NOTHING to do with security when used properly.
Reminds me of the anti virus software at work many years ago that did not allow me to download a password encoding library, because the filename contained the word "password"
I've also experienced automatic security reports that complain that the configuration file contains the word "password" (as in "database.password="). I had to argue with them that we did not actually store passwords in Git as they could clearly see, but that it was set using a environment variable by a secrets manager when actually running in a container. Next time we had a similar use case we would just give it a different name to avoid this complication
I usually have more plans to write things than actual time, but I do keep some articles/lists "evergreen" and they come up in conversations quite a bit:
This is a great way to test for backwards-incompatible changes if your fleet is running canaries or instances on different versions backed by a singleton database. You apply the migrations, checkout the app from the old version, and then re-run your test suite. Any failures are a reasonably high signal that some backwards-incompatible migration was introduced.
Have you tried Nix[1]? The learning curve was a bit steep for me, but I think I finally started "getting" it and it absolutely solves this problem for me. Now I'm at the point where if I install Nix on any computer, VM, whatever, I can just pull in my configs via home manager[2] and everything Just Works. It's seriously one of the best package managers I've ever used, and I can't imagine going back to anything else. Windows support is only via WSL, so this might be a non-starter for you.
The secure copy and paste feature always seemed to address the wrong threat model or use case for me. Sure, it's great that it keeps things isolated and compartmentalized across VMs, but it doesn't help much if you accidentally paste it into a phishing site. I wish there was just better browser integration for it, so you could have a password manager that could only access secrets on-demand + also automatically verify the domain or site you're trying to enter credentials into.
Anyway, still very cool stuff. I used Qubes for a few years before I made the mistake of purchasing a laptop that wasn't fully supported, but I often think about picking it back up or trying to install it again.
In practice, the Qubes C/P thing isn't unpleasant. There's also no reason browser integration can't be done right now; I use it with Qubes.
I have a primary 'vault' qube that holds all the credentials for all qubes, and then use Firefox's built-in password management on a per-qube basis. There is an initial 'config' step where I'll need to pass credentials from the Vault qube to an App qube, but after that it's smooth+automated.
Alternatively, you could use a vault-per-qube model.
You can do remote play on a Chromebook right now with Moonlight! Works great (for me). Some other alternatives include Parsec and Rainway, and probably a few others I'm missing.
I'm not advocating that this is generally a good or bad idea, or even economical, but it's possible.