3 ms·

i know of one example, which was admittedly beyond silly (caddy wouldn't start when lets encrypt had an outage), and they back paddled very quickly after it ble

by y4mi 8y ago

i know of one example, which was admittedly beyond silly (caddy wouldn't start when lets encrypt had an outage), and they back paddled very quickly after it blew up, and provided a fix within hours iirc. your comment however paints a different picture... if you know other examples, please enlighten us.

stephenr 8y ago
The issue you're aware of is when I became aware of the project (because of the outages and ensuing coverage here on HN). My issues are: - that problem was caused not by a 'bug' but by a deliberate decision that the author made, and defended. I wouldn't use the term 'back peddled' so much though: Even after relenting and changing the allowed expiry window, the behaviour was essentially the same, albeit with a smaller failure window. AFAIK Caddy to this day won't start with a valid certificate if it can't renew it, if the expiry is within 7 days. - before the TLS-SNI-01 challenge was disabled on the LE side, Caddy's behaviour was to randomly select a challenge to use. When I questioned the author about this his response was "oh well that would be too much load for LE". The problem there is that the ACME protocol handles this exact scenario - you query the ACME server to find out which of the challenges you want to use, it will allow you to continue with. As I pointed out at the time, I personally wasn't aware of this before the TLS-SNI issue, but as demonstrated by his response, neither was he. If his project's entire reason for being is registering certs via ACME, wouldn't you expect him to know the basic information/control flow when requesting a cert? - the author has no apparent concept or understanding of 'separation of concerns' - apparently anything that isn't a single file go binary is all too much for the world to bare, regardless of the disastrous results his approach has given the world. I'm all for competing approaches to solving a problem, but when someone essentially ignores any competing approach that doesn't fit their existing narrative of "I have the sole solution to this problem", it's not a sign of someone who is really interested in solving the problem, it's someone interested in pushing their solution. That's fine for a salesman, I guess. Not so much for an 'engineer'. Edit: - the 'ads via headers' stunt was just plain weird and creepy, and shows that the author and his partners have no real sense for business. This is demonstrated in their 'Basic' paid support, which states: "We usually respond within 1-2 business days.". USUALLY!? You're paying $25 a month per instance, so you.. I dunno, don't have to install certbot once, and your support response timeframe includes the term "usually". Sweet fucking Jesus.
- andmarios 8y ago
  I'd say that $25/month in order to get support from the core development team within a couple business days is an excellent deal, especially for an open source software.
aurieh_ 8y ago
Not OP, but opt-out telemetry (https://github.com/mholt/caddy/pull/2079 https://github.com/mholt/caddy/pull/2079) phoning home to a non-libre, non-open source server for one. Not to mention the fact you couldn't opt-out without changing the build up until someone else (not the author!) made it a CLI flag (https://github.com/mholt/caddy/pull/2191 https://github.com/mholt/caddy/pull/2191)

by y4mi 8y ago

stephenr 8y ago

The issue you're aware of is when I became aware of the project (because of the outages and ensuing coverage here on HN). My issues are: - that problem was caused not by a 'bug' but by a deliberate decision that the author made, and defended. I wouldn't use the term 'back peddled' so much though: Even after relenting and changing the allowed expiry window, the behaviour was essentially the same, albeit with a smaller failure window. AFAIK Caddy to this day won't start with a valid certificate if it can't renew it, if the expiry is within 7 days. - before the TLS-SNI-01 challenge was disabled on the LE side, Caddy's behaviour was to randomly select a challenge to use. When I questioned the author about this his response was "oh well that would be too much load for LE". The problem there is that the ACME protocol handles this exact scenario - you query the ACME server to find out which of the challenges you want to use, it will allow you to continue with. As I pointed out at the time, I personally wasn't aware of this before the TLS-SNI issue, but as demonstrated by his response, neither was he. If his project's entire reason for being is registering certs via ACME, wouldn't you expect him to know the basic information/control flow when requesting a cert? - the author has no apparent concept or understanding of 'separation of concerns' - apparently anything that isn't a single file go binary is all too much for the world to bare, regardless of the disastrous results his approach has given the world. I'm all for competing approaches to solving a problem, but when someone essentially ignores any competing approach that doesn't fit their existing narrative of "I have the sole solution to this problem", it's not a sign of someone who is really interested in solving the problem, it's someone interested in pushing their solution. That's fine for a salesman, I guess. Not so much for an 'engineer'. Edit: - the 'ads via headers' stunt was just plain weird and creepy, and shows that the author and his partners have no real sense for business. This is demonstrated in their 'Basic' paid support, which states: "We usually respond within 1-2 business days.". USUALLY!? You're paying $25 a month per instance, so you.. I dunno, don't have to install certbot once, and your support response timeframe includes the term "usually". Sweet fucking Jesus.

andmarios 8y ago
I'd say that $25/month in order to get support from the core development team within a couple business days is an excellent deal, especially for an open source software.

aurieh_ 8y ago

Not OP, but opt-out telemetry (https://github.com/mholt/caddy/pull/2079 https://github.com/mholt/caddy/pull/2079) phoning home to a non-libre, non-open source server for one. Not to mention the fact you couldn't opt-out without changing the build up until someone else (not the author!) made it a CLI flag (https://github.com/mholt/caddy/pull/2191 https://github.com/mholt/caddy/pull/2191)