• 1 Post
  • 418 Comments
Joined 2 years ago
cake
Cake day: July 6th, 2024

help-circle

  • If you use the shortlived profile and your key is compromised, you benefit from the short lifetime.

    Maybe I’m just too stupid to understand how those certificates work.

    But in what scenario is my key compromised but not my server? Because someone getting control of my server can just get an new long-term certificate. That was my actual point in the comment above. I understand the argument of added security if they only issue short-term certificates. But where is the benefit of my short-term certificate when someone compromising my server can just get a new long-term one in seconds?

    Also we are talking about self hosting. I understand the issue of revoking certificates when you have a massive userbase where some might miss the revocation for quite some time. Not so much with the dozen max family and friends.


  • As of the manpages systemd-sleep looks for:

    The main configuration file is loaded from one of the listed directories in order of priority, only the first file found is used: /etc/systemd/, /run/systemd/, /usr/local/lib/systemd/, /usr/lib/systemd/.

    Also

    The default configuration is set during compilation, so configuration is only needed when it is necessary to deviate from those defaults.

    So yes, you can use any existing file from another computer as your template (root:root 644 would be the default owner/permissions for it).

    PS: I tried on my PC and setting AllowHibernation=no in the config file produced a different “hibernate is disabled by config” error. Only if I remove the resume=<swap location> kernel parameter do I get the “not set up” error you mentioned but I’m not at home and only have my old (encrypted and able to hibernate) bios laptop with me. So I can’t check this for modern UEFI where systemd-sleep should automatically pick a suitable swap space and save the location in an EFI variable without any additional configuration.

    You can however set the resume=UUID=<your swap's UUID> kernel parameter anyway. Even the automatic systemd/uefi setup accepts this as a way to manually select a location. So maybe you try that. If your problem is decryption of the swap at startup you should not get an error when initiating the hibernation as you do now but instead get problems when you try to restart from swap.




  • I know that I could easily change my config. My point is that a) they are failing to advertise this and b) I don’t see any reason to do it. I understand the arguments about security benefits of shorter certificates on their side and iirc they are already planning to change it from 3 months to 1.5 months in the future. But in what scenario do I benefit from a short-term certificate as long as the regular ones are still available anyway?




  • Certbot came with a systemd timer running twice a day (0, 12 +12h random) that only renews –iirc– when the certificate has 30 days or less to live. Also I looked it up and my (version 6.7) Certbot neither mentions the option with the --help option, nor in the manual (where there is just one instance of “profiles exist, no other details given”).

    So they probably need another way than a random blog post when they want users to use (or even just know about) that option…

    It’s been pretty much a set-and-forget experience

    Yeah, that’s what it always has been. So no need to change anything unless they make it the new standard on their side with an update…