i’m lizard

  • 0 Posts
  • 37 Comments
Joined 1 year ago
cake
Cake day: June 21st, 2024

help-circle

  • Then it can’t be booted with new media. Microsoft has been very, very slow with the automatic rollout of their own key updates, and made just about no progress over the past two years. It’s been manual updates + newly produced systems only.

    The trick here is that they have a key-exchange-key that can be used to update the other keys. That doesn’t expire (or rather, not in a meaningful way). But, a Windows image is still only going to boot on a system that trusts the key that was used for it. If you make a Windows image on a 2011 system now, it’s going to be signed with the 2011 key, and it won’t boot on a system that distrusts that key. The same is true in reverse.

    Their key update documentation is all available and some enterprises have been on the new key for a while, but it’s a lot of manual work and a lot of problems have popped up, most documented in there. How they’re going to roll this out automatically to normal users isn’t obvious to me. There’s technically nothing stopping a system from trusting both the 2011 and 2023 keys, and I wouldn’t be entirely surprised if they end up never pushing the 2011 revocation.

    The keys they use for their own OS don’t truly expire until late 2026, and I expect they’ll do their best to delay it until then, but the next time they have to update their boot manager is going to be painful and introduce all kinds of new problems.






  • PUID is indeed handled inside the container itself, it’ll run a container-provided script as whatever the container’s UID 0 happens to be first which then drops to whatever $PUID happens to be inside the container. user= is enforced by Podman itself before the container starts, but Podman will still run as root in that setup. That means Podman is running “rootful”, while if you started the container manually as $uid using the regular Podman CLI, it would be “rootless”. That is a major difference in a lot of respects, including security, and you can find quite a bit of documentation on the differences between those operating modes online; it wouldn’t fit in a comment. Rootless is generally considered the better mode, though there are some things that still require a rootful container.

    In the upcoming NixOS 25.05 or current unstable, there are some tools you can use to run containers rootless as another user more easily using a new $name.podman.user = ""; setting. From what I understand they’ll still be root-managed systemd system services that require sudo to operate, but that means privileges get dropped by systemd before running Podman, instead of dropped by Podman before running the container. This stuff is recent and I haven’t used it, I just happen to know it exists, relevant nixpkgs commit if you wanna dig into it yourself: https://github.com/NixOS/nixpkgs/commit/7d443d378b07ad55686e9ba68faf16802c030025






  • Windows prefers to deactivate or minimize the write cache on removable devices, most of the common Linux distros generally don’t make such changes. Microsoft has a very good reason for that default: not a lot of people actually use the “safely remove hardware” option and if the cache is enabled, using and waiting for that is a hard requirement for the data to have actually made its way onto the drive.




  • Borg or the like with ‘hardcoded’ plaintext/regularly full-disk-encrypted key is acceptable. Someone that has your unencrypted private key sitting on your server has almost certainly already obtained access to the entire set of data you’re backing up, with the backup key itself only meaningfully guarding access to older backups.

    The more important thing is to securely keep extra copies in case the server fails. I keep mine in a group in my password manager, one per repo.



  • There’s no 100% indicator, but presence/non-presence of a contributor license agreement that gives them the rights to distribute under any license is the best one I’ve found. Corporate backed FOSS where they want the option to turn into non-FOSS “just in case” means that will inevitably happen after people are locked in. Best place to look for one is the project’s documentation on how to contribute/how to send pull requests.

    Stuff licensed under BSD/MIT style permissive licenses don’t need a CLA to go proprietary, but the ones that do tend to have a CLA anyway.

    “CLAs” that are just an sign-off (developer certificate of origin like used by the kernel) are fine and are also treated as a CLA every so often, but the moment you see anything about giving one specific company a “perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license” or the like, run for the hills.


  • (It’s a joke/reference, I guess it’s not 100% known though. My bad.)

    I really do hate “I know what I have so you are going to pay whatever number I set” capitalism though, which is what they do here. These registrars figured out a loophole around the redemption grace period and are, from the start, set up to make you lose the domain and then spend significant money on a completely unfair auction where they have the power to plant fake bids, rather than paying the usual static redemption fees that aren’t that excessive.