Packaging Caddy

(Erick Calder) #82

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

(Matt Holt) #83

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.

That’s good to know. We can look into that.

(Erick Calder) #84

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

by way of introduction, I wrote and maintain which pulls perl modules from CPAN and packages them in RPM format (for Redhat systems). so I’m not entirely unfamiliar with packaging systems

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

(Matt Holt) #85

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.

(SP) #86

I really like Caddy. Thanks for creating this beautiful server.

Regarding the packaging, what do you think about this?

  1. Install only the basic caddy file from the package manager (i.e. without any plug-in)

  2. If user wants to add plug-in, he can run command like:

     caddy plugin install plugin-a plugin-b plugin-c ...

    This will write the plugin list to a config file

  3. 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.

(Erick Calder) #87

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

(Matt Holt) #88

I think this causes direct conflict with what a package manager does, but whatever, we’ll see when we get closer to it.

(Erick Calder) #89

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.

(Johan Dorland) #90

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. 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.

(Mark Hanford) #91

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… :frowning:

(Matt Holt) #92

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.

(Mark Hanford) #93

Fair enough, thanks for clarifying. I wasn’t having a poke, just trying to work out the lay of the land :wink:

I actually use Chef to deploy everything, so in many ways a single binary I can push out is easier.

(Matt Holt) #94

It’s fine, I was just imagining something like how Chrome auto-updates.

(Mark Hanford) #95

That could work. You just have to be really sure you don’t mess it up :slight_smile:

(Johan Dorland) #96

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 :confounded:)

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.

(Alfie Pates) #97

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. 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.

(Matt Holt) #98

So we ship a Caddy package manager with OS package managers, instead of Caddy itself with OS package managers?

I actually kinda don’t hate that idea.

Except for the part about me having to write a Caddy package manager.

(Alfie Pates) #99

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 :wink:

(Anish V ) #100

If 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.

(Matthew Fay) #101

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, 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 to pwn your system? That’s your fault! Shoulda downloaded it and read it before piping to sudo. :stuck_out_tongue:

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.