Seconding what Matthew said, and emphasizing that there are multiple dimensions to “compromising” the Caddy website. It’s comprised of several components across different machines. Which machine is compromised? Or maybe it’s just a localized attack like DNS cache poisoning? So, what exactly is compromised? If you’re talking about the binaries being changed, you should be able to detect that because the new site (in 7 days…) signs builds with a PGP key.
Building from source yourself is always going to be the “safest” way to do it assuming you know what you’re doing and you assume your system, etc, is safe. But if you don’t trust Caddy infrastructure whatsoever, don’t use it. Just build it yourself. I imagine this same logic would go for any software you install on your system.
Package managers never really settled well with me. NPM has (had?) this problem where someone could use a package name after the old package was removed and thus gain the trust of thousands of dependent projects instantly, and run bad code.
Just sayin’, the more surfaces we introduce for distributing Caddy (such as package managers for your distro), the more ways there are to mount attacks.
I’m checking out of responding to this thread, I’m not particularly happy with the direction it’s going and I don’t see it coming to any kind of conclusion.
My final input is this; Stop bikeshedding and engineer a solution.
Now, for an incredibly late Chime in:
I no longer work at canonical and therefore lack the time that I used to have to update this package and its snap.
A Few issues about caddy and PPAs.
Caddy is was not, at the time of my last packaging, a reproducible build, just pulling a tag would not guarantee you get it even compiling or at any rate a similar version than the offered on the site, hence my github fork that basically just had the dependencies.tsv file necessary to pin the older versions of packages, usually untagged, that it depended on.
The debian rules are a PITA to use with go, if you where to follow them, there should be a package (like, a deb package) for each dependency, even though your binary would not use the, because you must be able to find all dependencies if you where to modify yada yada yada. Hence the PPA just vendoring all of the necessary deps (for this reason it will never be an “official” package.
Launchpad, the server and builder of caddy for most odd architectures is both difficult to understand and easy to upset so each mistake will set you back a couple of hours.
building debian packages locally is far from fun, it includes iirc something like bootstraping either a qemu or a chroot or sth like that from scratch each time. It makes me wonder if its even possible to cross build the other architectures (I guess that if its qemu it is)
At any rate, these pain points don’t seem to be near ironing, I had an approach with snaps but these where also built by launchpad and caused me the same pains (I did not feel like setting a builder myself) and I am not sure snaps is something that is going to have success in the market to be worth the effort.
tl;dr: Handbrake’s download mirror was compromised, the DMG of 1.0.7 replaced with a malware installer. It was compromised for about 4 days. Meanwhile, Homebrew accepted a PR that changed the hash of version 1.0.7 to the hash of the malware installer without changing the version number!
In other words, software gets infected with malware, alarm goes off because hash mismatches, then package manager assumes false alarm and distributes malware.
I think this highlights what could be a much wider problem in the package management ecosystem.
I expect the maintainer(s) to get some blowback for that one. That was a serious blunder that probably could have been avoided with just a few cursory checks (the kind of checking we trust maintainers to do in the first place). The same kind of problem (accepting PRs without investigating) is just as dangerous for the Caddy repo itself, I don’t really think it’s a problem inherent to packaging.
The main weakness with Homebrew, IMO, was that the packaging is done via PR, with no technical restraints to prevent an inconsistent or suspicious change like that one. The PR system is not a good match for active package management IMO. A check with the upstream authors would have been good but Homebrew can’t do that at scale with PRs.
Vendoring is a little different. It’s easy to hide a malicious change behind a hash, it’s much harder to hide a change to the actual source code in that diff.
But it’s something I’m aware of and researching and thinking about as the project gains popularity. For now, a good way to reduce vulnerability is to reduce attack surface.
I’d like to help get Caddy packaged for Fedora and RHEL/CentOS (via the EPEL repo). The main thing stopping me at the moment is the Go 1.8 requirement. That Go version should be available in:
Fedora 26, expected in June this year
RHEL 7.4, expected in ~Q3 this year
For now, I have packaged it in a COPR repo (similar to a PPA) for Fedora 26 (alpha) and Fedora Rawhide. Once I get all the dependencies added to Fedora/EPEL, I should be able to submit the spec file to Fedora/EPEL proper.
a default Caddyfile that listens on port 80 for all interfaces, with a default “hey it works” page with a link to the upstream docs for further configuration (similar to other packaged webservers)
CADDYPATH set to /var/lib/caddy (traditional Fedora/RHEL location for this type of data)
I added another COPR repo today with a caddy-bin package. It’s the same as the other COPR except that it’s using a pre-compiled binary rather than compiling it during the RPM build. It’s available for Fedora 24, Fedora 25, and EPEL 7.
bit late to the discussion but i agree having to rely on distro packaging policies and timelines isn’t idea so i prefer source install for common and frequently updated packages i.e. nginx, php-fpm, memcached etc. What caddy can do is offer up the normal non-packaged method but have a rpm build script made, so folks can run the rpm build script to build their own rpms against the source package. This way rpm repo creators and maintainers have an easier way of building the rpm packages and you still have some control as to how those rpms and thus how caddy is built via the rpm built script you provide.
This way folks who want rpm method of install can do it via yum repos or build their own rpms from the provided rpm built script or create their own private yum repos for themselves. Best of both worlds with some form of control and say as to how it’s build via the caddy officially provided rpm build script.
I haven’t followed caddy much since 0.9 so if this has already been done - sorry for repeating it
I understand the concerns about distro packaging, but please keep in mind that every distro is different and has different policies, and those policies evolve over time. I can’t speak to this matter outside the Red Hat ecosystem, but I can comment several things in that ecosystem that are notable.
Go is part of the RHEL “optional” channel, which has no ABI guarantees (read: can be updated easier than packages in the “base” channel). This is why Red Hat is going to be able to update it from 1.6.3 to 1.8.x in the next update. More than likely, this also means Go will get more updates in the future (although there is no way to know for sure).
EPEL (the repository I want to submit caddy to) is a third party repository and not part of RHEL/CentOS. It is a sub-project of Fedora, and most EPEL maintainers will keep their packages up to date in both Fedora and EPEL whenever possible.
EPEL policy is that packages can be updated regularly, so long as the update doesn’t “require manual intervention to keep the package functioning after update”. The policy also states that “major updates with changes to user experience are to be avoided”. EPEL also has a process for handling incompatible packages upgrades when they are deemed necessary.
Side note, I updated those COPR repos to the 0.10.3 version of caddy the same day it was tagged in GitHub.
Also, it’s now just a single repo for RHEL 7 and Fedora 26/27/rawhide. I won’t be doing any more updates for the caddy-bin repo now that RHEL 7 and Fedora 26 have been released with go 1.8.
I’ve been using this repo to make continuous improvements to the packaging in preparation of submitting this to Fedora and EPEL proper. I’ve been toiling on getting a working selinux policy, but I found out recently that isn’t a blocker for the package review, so I can handle that later.
I just updated it to the latest 0.10.8 version that was tagged today, enjoy!
@carlwgeorge Nice catch. Full announcement coming tomorrow morning about that. Basically, the source code is still Apache licensed, so if you build from source, the EULA doesn’t apply (the EULA itself says this near the top).
We’ve started looking into building a robust, automated packaging system that can be customized by our customers to deploy their own configuration to their servers. Main limitation here is what package managers are capable of. But stay tuned! @yroc92 will have more on that later.
Guys, I’m writing a cross platform (windows and linux atm) CLI application. The CLI tool can download or build Caddy, more feature will be added later. I’ll announce to the forum once I’d release it. The tool might not be open source, however I’d appreciate everyone support.
for those using docker, you can use my base-images like this to build caddy from source with pluings.
FROM ulrichschreiner/caddy-builder:0.10.9 as builder
FROM ulrichschreiner/caddy-runtime:latest
USER caddy
and simply put a plugins.go (with your import-paths for the plugins) to your directory. you can then run “docker build” and the result will be a container with caddy and your desired plugins inside.
Full announcement coming tomorrow morning about that. Basically, the source code is still Apache licensed, so if you build from source, the EULA doesn’t apply (the EULA itself says this near the top).