I think the OP was expressing concern over Let's Encrypt being installed on servers and potentially doing malicious things. Of course, if you apply this logic to Let's Encrypt you could just as well apply it to your web server or your mail server, or even your OS itself. At some point you just have to trust that the people and organizations that you're getting your software from aren't malicious... or you could write everything from scratch yourself.
Bear in mind that this is all vaporware. The github repository for "AJAX" just has a spec, no code. They're selling a security "solution" no one has evaluated yet.
I'm bothered that this runs periodically. Will it auto-update code? How secure is the auto-update process? Who can run an auto-update? Does it run as root? If so, why?
If it was a one-time manual run, that wouldn't be so bad. You can snapshot a system, run it, and see what it changed. When it gets to run on its own, that's harder to test.
I think they have stated that they want to get official packages into distro repositories, so you'd get whatever security your distribution's package manager provides, and your distribution of choice would act as a kind of gatekeeper against malicious code/updates the same way it does for other packages.
That is exactly correct. And the client will be open source code written in Python.
It's not like "take this binary blob from us and run it as root on your machine", it's like "we have an open source project that would like to work with your upstream OS distributor on exactly the same terms as, and in exactly the same way as, the other tools that you're using on your server".
Edit: If you want to follow along with, audit, contribute to, help package, etc., our preview client, it is available at
We will also welcome people to create their own interoperable software, so if you don't want to run our client or any of its dependencies, or if it doesn't work well with your serving environment, you can create your own alternative. (Hosting providers or CDNs that want certs for sites they host, for example, could create their own tools to deploy them, instead of using our tools.)
Automate it. Make it part of your maintenance scripts. Put it in a cron job. I think it will be a huge step forward.