> > I don't see any with priviledge seperation, nor any which could > > plausibly be pledged. > > For months there wasn't anything other than the official client. After > the service started operating and showed itself to not be vapourware > people started writing their own, but obviously the ones that were > ready to share early were mostly quick hacks. > > It's not priviledge-separated (though like most of them can be run as an > unpriviledged user given a little thought),
"as an unpriviledged user" is terribly low bar. Can it be run with parts chrooted? If not, then where is the actual filesystem safety? Many people not capable of setting up what you propose. Hence, they won't. There will be little or no thought. Many people are running these clients as root, connecting to a server on the internet that probably has the same code quality. > but there's one written in go (acmetool) which seems cleaner than > most. (Pity it's in a language with an annoying-to-build/package > ecosystem but at least it's not another one in unportable bash...) And where is the filesystem safety? The system administrator must structure safe use themselves? And surely the documentation advises that, and the program won't work if you use it unsafely? I am very sceptical. If the domain knowledge required to use a subsystem is too high, it will be misused by many. There is a fan club pushing for letsencrypt without recognizing the unsafe practices everyone is now following on their systems, as a result of this push using crap prototypes. > I'd be happy to be proved wrong but I don't think we're very likely to > see privsep unless it comes from someone familiar with OpenBSD. I don't > know why but very few seem to use these techniques. Of course. But until that happens, most of the people using the existing let encrypt clients are Sheep.
