[nixcraft]

Caddy cannot be found in the default repositories of Debian or RHEL. This raises the question of why one would use such a server. Personally, I am hesitant to download a random pre-built executable from Github, even if it is open source. I would much rather use the apt or dnf version, as anything else seems like just another toy server.

[francislavoie]

Debian's requirements for packaging of Go software is unreasonable. They expect every single dependency to be individually packaged. The total dependency chain of Caddy ends up being massive. We (the Caddy maintainers) don't have time necessary to allocate to a single distribution, to package and maintain every single dependency individually when all we want to do is ship a single static binary (plus some support files).

Instead, we ship with our own debian repo, hosting graciously provided by CloudSmith https://caddyserver.com/docs/install#debian-ubuntu-raspbian. This is packaged via CD with GitHub Actions, and you can verify the authenticity of the build since it's signed by Matt Holt's GPG key.

For RHEL, it's in COPR, and that's the best you'll ever get for similar reasons https://copr.fedorainfracloud.org/coprs/g/caddy/caddy/

[m_sahaf]

Adding to Francis input, the release artifacts (not the .deb packages, which are signed with Matt's key) published on GitHub are authenticated with Sigstore tooling[0]. You can verify the artifacts and the .deb packages were not tampered to the byte! The builds are reproducible and verifiable. FUD doesn't have any room to loiter.

You can also build it from source using the `buildable` source archive artifact that includes all the deps so it can be built in air-gapped machine. Like its sibling artifacts, the source archive is signed, the signature is published, the signing certificate is available, and the checksum is published and also signed. What's so concerning?

[Disclaimer: Affiliated with Caddy]

[0] https://www.sigstore.dev/how-it-works

[mardifoufs]

What's the reasoning behind that packaging requirement on Debian? Thanks for working on caddy by the way! I find it very neat.

[e12e]

> Debian's requirements for packaging of Go software is unreasonable. They expect every single dependency to be individually packaged.

Based on the sibling comment that points out a volunteer has packaged caddy for Debian 12 - that work has been done?

[xeeeeeeeeeeenu]

>Caddy cannot be found in the default repositories of Debian or RHEL.

Debian 12 (bookworm) will have it: https://packages.debian.org/bookworm/caddy

[francislavoie]

FWIW, that was created by someone not affiliated with the Caddy project, and looks to no longer be maintained (latest is v2.6.4, but it has v2.6.2). So as a maintainer of Caddy, I cannot recommend using that repo.

[cpuguy83]

While it is convenient to have software prebuilt in a trusted repo, these repos are more about providing toolchains. If something isn't in the repo (or the repo, as it often is, ie out of date) use the toolchain to build what you want.

[jakebasile]

Caddy provides their own yum repo and I'm pretty sure it's in EPEL too.

[garbagecoder]

Just build it from source?

[5e92cb50239222b]

And then watch it like a hawk for vulnerabilities and rebuild as needed. No thanks.