echo "deb [trusted=yes] https://apt.fury.io/caddy/ /" | sudo tee -a /etc/apt/sources.list.d/caddy-fury.list
apt update && apt install caddy echo "deb [trusted=yes] https://apt.fury.io/caddy/ /" | sudo tee -a /etc/apt/sources.list.d/caddy-fury.list
apt update && apt install caddyUnless I'm mistaken, a malicious package with the same name as a critical system package could be added to that untrusted repository by an attacker who had compromised it, and if the version number is higher than that of the 'official' package and your Apt priority config prioritises it, your system would download and install it without any verification.
This is a fairly niche attack vector that may not be considered a significant risk in some environments, but it's one to consider when establishing your threat model and risk appetite.
As a side note, it's worth noting that GPG signing packages is not a silver bullet either, especially if the signing keys and administrative access to the repository fall within the same security boundary (e.g. developer doing both from their PC without any segregation/sandboxing). However, it has proven to be a robust method so far, and definitely beats explicit [trusted=yes].
That was my pet project for the past couple weeks, I'm so glad to see people appreciate it!
There's ongoing effort to package Caddy into Debian. Until then, this is the alternative as stopgap.
Thanks for pointing out
In case it's of interest, as a new visitor, I started browsing from your main v2 landing page, scanning down most of that information. Then I followed the prominent download and get started links near the top. I think I next went to the documentation area, and started browsing the links on the left, though I totally missed the "Install" link just under "Welcome" because my eye was drawn first to the Tutorials section and its getting started link, and then I went exploring from there on down.
I suppose that was an unfortunate combination of two things to miss. :-)
We'd love to get some help from people who are more comfortable with the debian ecosystem though! It's definitely something we want to achieve, but for the short term we had to make the decision to simply release the .deb via https://gemfury.com which provides us with free APT repo hosting for open source projects.
I understand why, but it’s indeed quite a pain.
Of course, that isn't helpful if you need to compile with extra plugins, but in that case you are probably using standard go tools and not apt packages anyway.
We were specifically told that we would need to have all our dependencies packaged. Debian needs to be able to validate that it was built entirely from source code from library packages, not from a binary built externally.