11–20 of 111 posts
Earlier quoted context omitted.
Why would you use this for anything else than a joke given that Certbot exists, and is even in most repositories? (asking seriously)
Certbot is a massive pile of dependencies that you need to care and feed and update. You should not need 100s of megs of nonsense for something that can be done with a shell script.
Earlier quoted context omitted.
Why would you use this for anything else than a joke given that Certbot exists, and is even in most repositories? (asking seriously)
The only joke here is Certbot, a tool intended for use on servers but distributed on a channel intended for consumer use - Snap. The only package manager that will update on its own, when it feels like it, without a killswitch, runs as a daemon intertwined with the system. Icing on the cake is that the Certbot team advertises alternative install methods, of which none work and all of the lengthy guides for them recom…
I've only been using it for a little while, but the pip + venv method seems to work decently well: https://certbot.eff.org/instructions?ws=other&os=pip
Earlier quoted context omitted.
Why would you use this for anything else than a joke given that Certbot exists, and is even in most repositories? (asking seriously)
The only joke here is Certbot, a tool intended for use on servers but distributed on a channel intended for consumer use - Snap. The only package manager that will update on its own, when it feels like it, without a killswitch, runs as a daemon intertwined with the system. Icing on the cake is that the Certbot team advertises alternative install methods, of which none work and all of the lengthy guides for them recom…
So ridiculous to have to install yet another package manager, snapd, to get certbot installed "the easy way".
The alternative to get around snapd works fine (IMHO, for my situation, a lightsail instance running amazon linux 2023 where installing snapd is a pain in the ass), but you still have to jump through some hoops.
Earlier quoted context omitted.
People are always talking like shell scripts are without dependencies. Shell scripting ist mostly piping program outputs to different programs, that have dependencies on libraries themselves. Each of them have to be kept up to date to stay secure. Just because they are mostly preinstalled on the system doesn't make them not a dependency. This, together with the fact that most shell scripting is bash based which is, i…
If it is just a few curl and openssl commands, why make a user install hundreds of megs of python deps just to ultimately call mostly openssl commands anyway One of the biggest risks today is supply chain attacks. The more dependencies you have, the more people you are giving the ability to tamper with your critical code paths.
As a bash script actually, not a (implied POSIX) shell script. Do not mix these two.
Earlier quoted context omitted.
If it is just a few curl and openssl commands, why make a user install hundreds of megs of python deps just to ultimately call mostly openssl commands anyway One of the biggest risks today is supply chain attacks. The more dependencies you have, the more people you are giving the ability to tamper with your critical code paths.
Wouldn't this bash script be just as susceptible to supply chain attacks? What dependencies does openssl, cURL, sed, grep, awk, mktemp pull in, and could it be vulnerable to attack like we saw with xz?
Earlier quoted context omitted.
Why would you use this for anything else than a joke given that Certbot exists, and is even in most repositories? (asking seriously)
The only joke here is Certbot, a tool intended for use on servers but distributed on a channel intended for consumer use - Snap. The only package manager that will update on its own, when it feels like it, without a killswitch, runs as a daemon intertwined with the system. Icing on the cake is that the Certbot team advertises alternative install methods, of which none work and all of the lengthy guides for them recom…
It's 2024. If you're still distributing snaps as the preferred method of install, you're alienating your users. AppImage, Flatpak, and regular containers are all far better deployment options.
Earlier quoted context omitted.
If it is just a few curl and openssl commands, why make a user install hundreds of megs of python deps just to ultimately call mostly openssl commands anyway One of the biggest risks today is supply chain attacks. The more dependencies you have, the more people you are giving the ability to tamper with your critical code paths.
Wouldn't this bash script be just as susceptible to supply chain attacks? What dependencies does openssl, cURL, sed, grep, awk, mktemp pull in, and could it be vulnerable to attack like we saw with xz?
Earlier quoted context omitted.
The only joke here is Certbot, a tool intended for use on servers but distributed on a channel intended for consumer use - Snap. The only package manager that will update on its own, when it feels like it, without a killswitch, runs as a daemon intertwined with the system. Icing on the cake is that the Certbot team advertises alternative install methods, of which none work and all of the lengthy guides for them recom…
> the Certbot team advertises alternative install methods, of which none work I've only been using it for a little while, but the pip + venv method seems to work decently well: https://certbot.eff.org/instructions?ws=other&os=pip
> Partial support > The Certbot team supports this installation method on a best effort basis. If you are on a more obscure or heavily customized system, these instructions may not work and the Certbot team may be unable to help you resolve the problem.
This is an instant no-go for any professional environment I ever worked in.