3 ms·

> Basically, if you're not using it (and you shouldn't be using such functionality on a production machine), then you don't need it and should disable it Actua

> Basically, if you're not using it (and you shouldn't be using such functionality on a production machine), then you don't need it and should disable it Actually, most everyone wants zero-downtime config reloads. The API is necessary to perform config reloads. As others have said, you may use a unix socket instead for the admin endpoint. And see https://news.ycombinator.com/item?id=37482096 https://news.ycombinator.com/item?id=37482096, we plan to make that the default in certain distributions.

yencabulator 3y ago
> The API is necessary to perform config reloads. Of course it isn't. It could reload the config from the same path it loaded the config from in the first place. Like practically all other software has done for decades.
- francislavoie 3y ago
  The source of a config doesn't necessarily need to be from a config file. Config loading is abstracted. So it requires input, and signals provide no way to pass arguments, so it's not workable. See https://github.com/caddyserver/caddy/issues/3967 https://github.com/caddyserver/caddy/issues/3967
  - yencabulator 3y ago
    This sounds like a design decision you've made, not an inherent limitation. You can read config from files, like practically all other software has done for decades.
rekoil 3y ago
I get the thing about config reloads, I don't think it's worth it due to the security risks of the current default, but I get it. Happy to hear you're moving to sockets by default on *nix! However, I'd like to point out that the default should be in the binary, not in the distros default environment variables, otherwise it won't reach people who build their own binary, and depending on how you start your Caddy server you may clear environment variables for that process, and end up with the insecure HTTP-based admin endpoint enabled by accident.
- francislavoie 3y ago
  The only default that works on all platforms is a TCP socket. We can't write to unix socket file by default because the path to the socket needs to be writable, and there's no single default that has any guarantee to work. So it needs to be dictated by config in some way or another. It's better for it to actually work by default than possibly not work because of a bad default.
  - rekoil 3y ago
    So detect the OS and choose the more secure default where possible? I know it's less elegant, but having a much more secure model is worth some sacrifices.
    - francislavoie 3y ago
      It's not only the OS, it's the environment. File permissions are not a guarantee, no matter the OS.
      - rekoil 3y ago
        Then you throw an error in the log, you have to leave something for the admin to do to set their system up correctly. It's better that Caddy fails to enable the admin endpoint than that it enables it in an insecure manner.
        francislavoie 3y ago
        You're overestimating the users; a large % of them would not understand how to resolve that on their own and would complain to us that they can't start Caddy without errors. And I fundamentally disagree that the TCP socket is so insecure that it must never be used as a default, it's only insecure if your server is otherwise compromised. It's a sufficient default for 99.99% of users.
        rekoil 3y ago

yencabulator 3y ago

> The API is necessary to perform config reloads. Of course it isn't. It could reload the config from the same path it loaded the config from in the first place. Like practically all other software has done for decades.

francislavoie 3y ago
The source of a config doesn't necessarily need to be from a config file. Config loading is abstracted. So it requires input, and signals provide no way to pass arguments, so it's not workable. See https://github.com/caddyserver/caddy/issues/3967 https://github.com/caddyserver/caddy/issues/3967
- yencabulator 3y ago
  This sounds like a design decision you've made, not an inherent limitation. You can read config from files, like practically all other software has done for decades.

rekoil 3y ago

I get the thing about config reloads, I don't think it's worth it due to the security risks of the current default, but I get it. Happy to hear you're moving to sockets by default on *nix! However, I'd like to point out that the default should be in the binary, not in the distros default environment variables, otherwise it won't reach people who build their own binary, and depending on how you start your Caddy server you may clear environment variables for that process, and end up with the insecure HTTP-based admin endpoint enabled by accident.

francislavoie 3y ago
The only default that works on all platforms is a TCP socket. We can't write to unix socket file by default because the path to the socket needs to be writable, and there's no single default that has any guarantee to work. So it needs to be dictated by config in some way or another. It's better for it to actually work by default than possibly not work because of a bad default.
- rekoil 3y ago
  So detect the OS and choose the more secure default where possible? I know it's less elegant, but having a much more secure model is worth some sacrifices.
  - francislavoie 3y ago
    It's not only the OS, it's the environment. File permissions are not a guarantee, no matter the OS.
    - rekoil 3y ago
      Then you throw an error in the log, you have to leave something for the admin to do to set their system up correctly. It's better that Caddy fails to enable the admin endpoint than that it enables it in an insecure manner.
      - francislavoie 3y ago
        You're overestimating the users; a large % of them would not understand how to resolve that on their own and would complain to us that they can't start Caddy without errors. And I fundamentally disagree that the TCP socket is so insecure that it must never be used as a default, it's only insecure if your server is otherwise compromised. It's a sufficient default for 99.99% of users.
        rekoil 3y ago