the cipher suites (whatever those are) are a run-time matter, yes? so that wouldn’t affect how Caddy is packaged and delivered. if they are a compile-time matter, that still wouldn’t affect the packaging and delivery since the install scripts in the packager can do the compilation under whatever conditions
nothing crippling about a packaging manager’s policies. all the packagers do is give you tools to do what you’d otherwise do manually. as for timelines, I presume you refer to the time it takes to get the software into their main repos, which is easily solved by having a private repo. we all add private repositories to our lists
I don’t have this all figured out yet, but an instance of Caddy will need to securely negotiate a new build configuration when a cipher suite is broken, for example. I’m not sure package managers can facilitate that. A Caddy instance deployed today and not touched should still be secure 5 or 10 years from now, ideally.
and I presume that a cipher suite breaking is a run-time event i.e. something that may happen after the product has been installed? if so, then it has nothing to do with the package manager whose job is merely to install the product
I like Caddy very much and would like to see it widely distributed. if you guys can figure out the issues I’ll be happy to write the RPM spec file for it and to maintain it
Yes, and remedying this will likely require installing a new binary. Hence the question about whether a traditional package manager is a good fix…
I would be very glad to have your experience in helping to distribute Caddy! I’m trying to finish up the new website and stuff first which will greatly affect how we do releases, and as we get close to 1.0, distribution will be more of a priority.
When caddy starts, it will check for change and download/update itself with the correct executable file. Changes include caddy itself has been updated (eg. by a package manager) or plugin config has changed.
I’m not sure about security implication of this method, but I think it will make caddy very easy to use and maintain.
but that is no longer within the province of the package manager. the PM handles the installation and upgrades but what you’re describing is some runtime event that Caddy already handles in some fashion and can simply continue to do so
well… a package manager’s job is to take care of the install and upgrades. the install is straightforward. the issue is that the installation may have changed since the PM did its thing so upgrades will trash the state. that’s something the particular software needs to figure out. I don’t know enough about Caddy to understand what the issues are but I can guarantee you they’re not unique. we’ve been down all roads.
So I have some experience with the Centos/RHEL/Fedora ecosystem and was looking into creating an rpm repo with Caddy. It turns out there are already a few on COPR. There is a major problem however if we want Caddy included into the official repositories and that is that packages have to be built from source on the target platform. Since Caddy is quite aggressive with requiring newer Go versions this will be a problem as Centos/RHEL ship with older versions of Go. Fedora Packaging Guidelines - Fedora Project Wiki. Although I couldn’t find a similar for guide for Debian I can imagine they have a similar policy.
Packager looks interesting, but I’m not sure whether it is customizable/powerful enough to setup a clean systemd service.
The alternative is to provide our own aptitude and rpm repositories with custom built packages for both, we’d only have to find people willing to maintain them.
How do you envision this working, without automatic security updates via a package manager? It can’t see the future and turn off protocolX when it turns out to be insecure. It’ll need a binary update, which is traditionally done by my “install security patches” process.
It seems all the problems being mentioned here stem from the fact that all plugins need to be baked into the binary. Imagine if Apache or Nginx did that…
A Caddy instance can receive an authenticated notification by a trusted origin when a protocol or cipher suite needs to be deprecated.
That’s not the problem; getting any custom build of Caddy that you want is as easy as a GET request. I’m just inexperienced with package managers and don’t know how to make that happen with them.
On Windows auto-updates is the lesser evil because there is no package management, but on Linux Google just provides repositories for RPM and DEB packages. Also most sysadmins would be horrified of running an auto updating binary in production (which would require root priveleges )
The way most open source projects handle security updates is by using a security mailing list. If you’re a sysadmin and Caddy is important enough to your business you should be subscribed to this mailing list.
In case you’re just a developer and you don’t care much about updates you can just enable automatic installation of updates in your package manager, which would work the same as having chrome-like auto-updates, but then system-wide (if Caddy supplies an up-to-date repository).
I’d recommend not to reinvent the wheel by creating a custom package management/update mechanism and just use the existing package managers that already exist on Linux.
I guess I am responsible for this thread, so I am going to chime in again with the following:
I’ve been investigating this issue for a while, trying to figure out the best way to solve this issue, and my conclusion is thus:
All OS package managers suck. Docker/Containers suck. Manual deployment sucks. getcaddy.com is a bit of a hack. There is no way to solve this problem which will make everyone happy. Build a Caddy version/plugin manager that is installed by and doesn’t step on the toes of the OS package manager but also, y’know, works.
That’s the best I can come up with given the limitations of Go. Here’s how I’d do it:
Have a background daemon (let’s call it caddymand because I’m so original) that’s installed and managed by the OS package manager which is responsible for fetching, updating, and keeping the Caddy server binary running.
It’s an ugly abstraction layer, but it’s the only way I can think to give Caddy a robust hands-off automatic update system, make plugins work like plugins, and also handle making Caddy a “service”.
Except for the part about me having to write a Caddy package manager.
Careful there, I’ll make you rewrite Caddy in a whole different language that actually does runtime plugins
If caddyserver.com is compromised how would you verify the server you run isn’t faulty? Would a package manager mitigate these security issues? Of course there’s a component of trust for everything, but still something I was wondering about.
It kinda depends on what kind of compromise we’re talking about, doesn’t it?
I mean, say the build server has malicious code inserted - not much you can do about that, I think? You trust caddyserver.com, it gives you bad code mixed in with the binary, game over.
What if the domain gets hijacked and pointed somewhere else? Well, it’d be pretty difficult to accurately replicate the content and behaviour of the real servers, right?
Maybe a package manager could come with a trusted certificate of some kind. But that wouldn’t do much if someone pwns the build server, I think.
Someone rewrites https://getcaddy.com/ to pwn your system? That’s your fault! Shoulda downloaded it and read it before piping to sudo.
I suppose compiling from git source is always gonna be fairly trustworthy. You know when code changes. And if someone pwns git, you’ll get a warning. Might be the way to go for someone very cautious.
)
