Can certbot fork acme.sh and launch their own certbot.sh script which does not need any dependencies?
3 Likes
If it is public source code, then anyone can do that.
3 Likes
I'm honestly thinking of constructing a project to redevise the process entirely. IMO, cracking the problem into acquisition and installation then further cracking acquisition into webroot and dns approaches is straightforward. Basically, as I see it, if "universal" dns update scripts were created per dns api and installation scripts were created per webserver/application, there wouldn't be a need for all the wasted/duplicate/incompatible development occurring in so many places. Divide and conquer.
Of course, using relatively-ubiquitous technologies helps. PHP, Java, native script, whatever gets the best mileage. With a split solution and an established api, the delegation of tasks would certainly be easier.
3 Likes
What would be the benefit of doing that, compared to just using acme.sh?
4 Likes
Not being beholden is one that comes to mind.
He who controls the valve controls the well...
3 Likes
This is true, which is why browser engines (for instance) have forked multiple times as groups with their own priorities have wrestled for control over their own development directions.
Regarding DNS libraries, there have a been a few efforts such as libdns · GitHub [Go], Apache Libcloud DNS — Apache Libcloud 3.8.0 documentation [Python], Posh-ACME https://github.com/rmbolger/Posh-ACME/tree/main/Posh-ACME/Plugins [Powershell]
Really though I don't think it's sustainable to support lots of DNS providers (there are thousands), instead we need better common implementations of DNS APIs by the providers themselves. An acme specific TXT challenge API implementation that DNS providers could opt into would be good. Or, we just all try to use acme-dns (which is why I built Certify DNS). Over the long term I expect most small DNS providers to be replaced by the large cloud providers. I did briefly consider providing a hosted DNS API service that could update a large range of DNS providers, but I didn't like the idea of people have to provide their DNS API/control credentials (and neither would they). It's still possible to do as a self-hosted thing.
Regarding acme client implementations, Bash based solutions are sometimes a little clunky (acme.sh is a single 7K .sh file not counting DNS providers) and not as cross platform as they might appear, they're just low dependency on linux (and possibly mac os).
The python approach for certbot has proven to be reasonably cross platform (with a few differences). Go would be the most obvious cross platform language given it's prevalence for other acme tools (but requires per platform binaries in the end). Node or Python would be well supported runtimes that don't necessarily require the output to be compiled natively. Certify The Web is (already) targeting .net 6, which is cross platform and can be a single file/single bundle but is limited to mac OS, Windows, and common linux distributions and their offshoots. For other projects though I doubt .net would be a natural choice.
Honestly, Python seems like the best compromise so far for this sort of command line tool/service.
3 Likes
Apparently the curse of Babel extends unto digital languages as well.
2 Likes
And it's quite Biblical indeed in that sense. I'm a big believer of Python and I reaaaallllyy hate Go on a religious level 
3 Likes
...and *BSD. IOW, on essentially everything but Windows. And Windows works as well using Cygwin, but admittedly that's a bigger set of dependencies.
Meanwhile, certbot requires a compiled binary installer for Windows, so Windows is apparently a place where the devs will make an exception to "snap only".
Eh, not really in this case. It's a public project on GitHub. If he decides to close it, or make harmful changes (and, IMO, defaulting to a different CA isn't a harmful change), anyone can fork and roll back at that time.
4 Likes
I'm more worried about decadence.
If many people simply rely on a product owned/maintained by some entity, this can lead to reduction in development and eventually loss of knowledge amongst the people. As the market share of the product grows, the proclivities of the owner/maintainer become more dominant. If/when people decide that they want something different, options may be quite limited and the bar quite high to produce an alternative.
3 Likes
Absolutely! Acme.sh is a free and open source project, under the GPL, so EFF/Certbot could fork it. ISRG/LetsEncrypt could fork it too.
The question is "Why?"
Forking a project like that is a large undertaking, and would effectively double the amount of work for ISRG or EFF. It's not simply forking the code and releasing it, but taking on the responsibility of constant maintenance and testing.
There would also still be a problem with how to keep the script properly updated. Acme.sh is only 1 file, which simplifies things a lot, but that's still going to create both an initial workload and a continuous testing system.
5 Likes
Not just EFF/ISRG could fork it, anyone can. To be precise, I've forked the code too! I just didn't rename it to my own version or something like that. And for the why: no commercial "smudge" and restore Let's Encrypt as the default ACME API could be reasons.
But to be frankly, any discussion about acme.sh including forking it is offtopic in this thread about certbot & snap IMHO 
6 Likes
I feel like there is an underlying spirit of hope here (and in several other topics in the community) for the "reimagining?" of a more lean, nimble, streamlined certbot.
In my view, it's a kind of reflection on the "universally-compatible" server-side of ACME (Boulder) versus the "fragmentedly-compatible" client-side. In a way this echoes the whole server-side production versus client-side consumption of web content in general with web browsers (and the associated content standards and expected behaviors) being the attempt at universalization on the client-side.
Boulder is to the web server as the ACME client is to the web browser.
3 Likes
Well, certbot is open source too! With its Apache 2.0 license, it's quite permissive.
Although IMO this thread was more about the packaging of certbot than the client itself.
Gentoo and certbot would be best friends in that regard: with Gentoo you're building the applications from source and Gentoo has a rolling release model, so always bleeding egde versions! Even today, certbot 1.18.0 is available, added within 24 hours of the release!
4 Likes
I feel like ideally the OS should not matter one iota to the availability or operation of the ACME client.
3 Likes
Well, @griffin, the certbot team agreed! So they decided they wanted a method that transcended those pesky different distribution package repositories like Debian and Ubuntu. So they choose snap 
And we're back again to the beginning of this thread!
4 Likes
I would have happily used a snap install if it worked. But, Amazon Linux 2 does not yet support it. Luckily, Certbot 1.11.0 is part of EPEL which can be installed with amazon-linux-extras to run without snap. It has taken me hours to understand the install variations and research alternate clients.
I wanted Certbot and LE to simplify my job of getting fresh certs. Given how much time I have spent on it, it will take years to recover the time spent compared to doing the certs manually.
I am not ungrateful - I am glad for Certbot and LE. But, the docs focus on snap resulted in a huge time loss even though I use a common systemd distro. Like @cazort in the other thread, I had to stumble across a solution.
5 Likes
...which isn't OS-independent, nor even disto-independent.
5 Likes
And it will also include uacme: Debian -- Package Search Results -- uacme
Several other distributions also include it:
https://packages.ubuntu.com/uacme
https://software.opensuse.org/package/uacme
https://pkgs.alpinelinux.org/packages?name=uacme
https://aur.archlinux.org/packages/uacme
4 Likes
I can understand a software developer's desire that everyone should use the latest and greatest version of their software all the time, especially after all the effort that went into it. But please understand that it's not all about your software. There's other people's software too. And other people's time managing systems. And things get complicated. And people get busy.
Some of us find great value in the huge amount of effort that goes into creating debian stable. I don't mind if the packages are old. It means that there are fewer surprises. That has great value. You might think that there are bug fixes missing, but not every bug affects every user, and every bug starts out in one particular version before it gets fixed in another particular version. Waiting until a version has been around for a while can mean that you also miss out entirely on some bugs. And security fixes get backported.
I like the fact that any upcoming breaking changes across an entire system will have been noticed, analysed, documented, and brought to my attention in one place as I prepare for major debian stable upgrades every two years. Using snap would mean accepting the fact that, if a new version of some software requires config changes, then I have to be ready to make those changes when they come, not when I'm ready and have the time to look into it. Perhaps you have committed to never ever breaking backwards compatibility, but I'm not aware of that. And even if you have committed to it, you might be forced to change your mind one day.
So I'll be using debian stable's certbot package, whatever version it is. The administrative benefits of using a system's package management system outweigh, for me, the absence of any new certbot features that I'm presumably missing out on. Sure, there are things I'd like certbot to do (like working better for DANE usage), but that'll come when it comes, and I'll just reuse keys for each new certificate, and roll the keys themselves manually (on a schedule that suits me), until certbot and debian stable do what I want.
Having said all that, I wouldn't "not recommend certbot because of a reliance on snap". It doesn't rely on snap. It might seem to, but really, it only strongly recommends it, and only if you feel that you always need the latest version. Certbot works fine without snap (as far as I can tell). It's just older on some systems.
Perhaps the documentation that currently only mentions snap could mention that many operating systems have their own certbot packages, some possibly quite old but stable, and that the documentation for those systems should be consulted for more information. Just a thought.
P.S. Thanks for the huge amount of effort that goes into certbot! It's much appreciated.
9 Likes