6 ms·

> but that's like asking if something is "secure" no, that's asking if an enterprise grade project is fronted with Caddy. > People use it for "real" projects

• andmarios 9y ago
  Caddy uses go's standard libraries for most of its web serving parts, so you know at least that the http server code is used by google, cloudflare etc. Same goes for SSL and many other parts. However most companies out there aren't Facebook, Google, Oracle, Coca Cola or Nike anyway.
  • drdaeman 9y ago
    Using Go standard HTTP libraries doesn't guarantee things are stable. Here's an example how a missing option (that is Go 1.8+ - which is a recent release) can lead to a DoS: https://github.com/containous/traefik/issues/1322 https://github.com/containous/traefik/issues/1322
    • andmarios 9y ago
      Yeah, as it happens in software in general there aren't any guarantees. I could too give you a link to heartbleed. Caddy wasn't affected.
      • drdaeman 9y ago
        Well, yes, although security and stability are different matters. Every software has bugs, I just said that the fact something is using Go HTTP library doesn't automagically mean it's production quality. There are always many ways to accidentally shot oneself in the leg. (Caddy, in my experience is production quality. I've used it in a few projects and haven't had any serious issues. Maybe that's just my use cases, though.)
    • omginternets 9y ago
      Stability is relative. Knowing that it uses standard Go networking libs is an indication of how stable this thing is.
• omginternets 9y ago
  >no, that's asking if an enterprise grade project is fronted with Caddy. Just because you'll be the first to use something for some purpose doesn't make the tool unfit for said purpose. The parent post's point stands: "production-ready", like "secure", is a highly relative term.
  • drdaeman 9y ago
    I think I'd disagree. While Caddy doesn't do that, production readiness is something that can be objectively measured. Define some metric, like "how many % users encounter stability-related issues/error conditions", throw in telemetry and there will be solid numbers. Many do that with their own software deployments, using Sentry or similar solutions, deciding on whenever their beta deployments are "production ready" or "not yet". Of course, that only works with a large enough user base, otherwise the error margins are too high for the number to be any meaningful. It is relative only in regard whenever, say, "0.01% (just a random number) of users have encountered severe issues" is "way too many" or "oh, it's just a few". Security, on the other hand, is a different beast. Formal proofs aside - trying to define some similar metric "how many installations were hacked" or "how many security issues were found" isn't really meaningful. But I think it would be really off-topic. =/
    • omginternets 9y ago
      You're missing my point, I think. What you're describing is an epistemological problem, i.e.: "how do I know this thing is production ready?". This problem is (mostly) independent of whether or not the thing actually is production-ready. The point is that knowing about previous use in production is one way of knowing to what extent something is production-ready. There are other ways (e.g.: well-controlled tests). As for your point about security, I couldn't disagree more strongly. Comparing histories of compromises and mitigations across various projects is, in practice, a very useful metric. See OpenBSD for an example.