If you are using a browser with password sync, you have the same possible data leakage problem as with a password manager.
If you aren't using a browser with sync, then you... have no sync.
So you get five options, all with some downsides
Browser:
Browser (with sync):
Password manager (in cloud):
Password manager (KeePassXC with no sync):
Selfhosted password manager:
Simple solution for password manager leakage - KeepassXC or selfhosted bitwarden. All blame is on you then.
KBin instance getting a 500 while loading a community from a Lemmy instance, so you opened it up on Mastodon. This sounds crazy but it's real...
You were right :) look at my username!
Installation was very interesting - using kexec to swap the current loaded kernel to a NixOS live image, and installing it right over the current system surprisingly worked flawlessly. One reboot for an entire install (I might end up writing a post in !NixOS@infosec.pub about it).
Setting up lemmy was a bit more difficult though, as the lemmy module is currently in the middle of a pull request to improve it, so I had to do some hacky trickery.
Huh, really?? I must be lucky then, because I just checked, and my server has been running since Mar 11, 2022!!
I'm aware, thanks
Ended up creating an instance just for me, my main reasons were:
I probably forgot about something too...
The hash isn't there for security, it's to make sure the code you're building against doesn't randomly change which could make the derivation fail to compile. For example, for the source, you can specify a literal HTTP download from a URL, and that file could be changed by the host at any given time, so it's there as a safeguard.
In the end, the lag is just caused by the fact that it has to work. You never want to get some broken version that you want to avoid, so nix packages are always tested with the new versions, because it may turn out they may need some patching for that version, or they have some new dependencies.
While we were talking I updated lemmy-server using overrideAttrs for my own use. It's honestly not that hard. You change the commit, specify some random incorrect hashes, build it, nix screams at you that the hash is incorrect (and generously provides the correct one), put the correct hash, and build again. Done.
Nixpkgs is by nature fully reproducible and declarative - that means you can't write a nix package to just build from master branch. You also have to specify the sha256 hash to absolutely make sure the source is the same for everyone.
With flakes, it's a bit easier, because if the package you're trying to build has a flake, you can just update it in your own lockfile and it will be rebuilt from the latest version.
If using something from nixpkgs, you have to wait (or PR yourself) for someone to PR the update, or you can also use overrideAttrs to do a "private" fix.
For example, I'm using the wlsunset program, but wanted to build from a different branch, so I did this:
(wlsunset.overrideAttrs (old: {
src = fetchFromSourcehut {
owner = "~kennylevinsen";
repo = old.pname;
rev = "81cfb0b4f8e44db9e5ecb36222a24d53a953e6aa";
sha256 = "sha256-Lxuhsk4/5EHuKPkBbaRtCCQ/LFvIxyc+VQYEoaVT484=";
};
}))
This just changes the source attribute to another commit and another sha hash, and it works fine.
Note that the PR got merged into nixpkgs now, but hasn't made it's way forward (see https://nixpk.gs/pr-tracker.html?pr=236295), so that's why you need to do the override for now Also, a fix for the issue with the migrations (if still occuring) has been merged yesterday, but it's not in any release yet, and especially not in nixpkgs. You could most likely get around it by using overrideAttrs to change the source to make it build from a newer commit.
No, it's catppuccin