Created attachment 517368 [details] Current version ebuild for app-crypt/certbot-dns-route53 In addition to the Nginx and Apache plugins that are already packaged in Portage, app-crypt/certbot also has a number of official plugins for interacting with DNS providers to verify ownership of a domain. DNS-based verification has two big advantages over the web-based verification that certbot uses by default: 1. The hostname you are generating the certificate for does not need to resolve to an internet routable address with a web server. 2. When LetsEncrypt enables their production ACMEv2 endpoints at the end of the month, DNS verification will be the only method permitted for obtaining wildcard certificates. The attached ebuilds are for the Amazon Route53 DNS verification plugin for certbot. They are adapted from the app-crypt/certbot-nginx ebuilds by simple substitution of the plugin name throughout the ebuild and modification of the dependencies to match those for the Route53 plugin. Tested on amd64, installs and runs correctly.
Created attachment 517370 [details] Live ebuild for app-crypt/certbot-dns-route53
please also consider the other DNS plugins. I personaly prefer the rfc2136 plugin as that can interact with updateable DNS records. (Bind f.e.)
Additional: the dns plugins are available through pip but gentoo forces pip install --user which is not exactly preferable.
Created attachment 524252 [details] app-crypt/certbot-dns-rfc2136 ebuild for certbot-dns-rfc2136
Nico, That ebuild (app-crypt/certbot-dns-rfc2136) works for me. Thanks. I'm just wondering if official plugins should actually be a part of the app-crypt/certbot ebuild and pulled in via USE flags. Not sure of the pros and cons of this though.
FWIW, I'm not 100% certain whether or not the official plugins are part of the main development or not. They share a Git repository with the main program, but each one is entirely contained in it's own directory with it's own README and setup/install script. I think it's probably better right now to keep them as separate packages just like the nginx and Apache plugins (which are both handled the same way as the DNS plugins upstream), but I would love to have USE flags for app-crypt/certbot to pull them in automatically.
Use flags to pull them in would probably the best option. That prevents the download fromt he whole shebang (esp. the AWS updater has a lot of dependencies..., in certbot development this was a previous discussion as well).
(ccing current certbot maintainer, if it lets me.) at the end of the day, all certbot plugins which are part of the official distribution should be added - the question is how should it be done. 1. one package per plugin would mean 10 packages, that would be the easiest one to do but the hardest one to maintain, the advantage of doing it that way would be that if upstream ever decides to release a plugin update separately, it can be better handled by single-plugin packages rather then a monolithic one 2. a certbot-dns-plugins package - so a new USE_EXPAND var for these; some of these plugins have varying deps so that would have to be need to be taken care of maybe we do app-certbot or something at some point but while that one would house ~15 packages i don't really think its a good idea, but it wouldn't be polluting app-crypt so much; if that is even a problem, i don't really know.
I don't feel comfortable maintaining a plugin I don't use. I don't even use the other certbot plugins (nginx and apache). I'd suggest this go through proxy-maintainers. It's a small package that should match the other plugins prety closely. https://github.com/certbot/certbot/blob/master/certbot-dns-route53/setup.py#L10-L17 https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers I have considered adding certbot-dns-rfc2136 as I do run bind though.
Looking at things further, I'm starting to think it may make more sense to just have one certbot package, and have a new USE_EXPAND for the plugins. That would be consistent with how upstream seems to intend for it to be distributed, even though their development arrangement is somewhat ambiguous. The main reason I did this up as an independent ebuild is that that's how the existing plugins were done, and it was trivial to do so (literally just copy one of the existing plugins and update the dependencies and name).
https://pypi.org/project/certbot-dns-route53/ shows that it can/should be standalone.
@prometheanfire: The certbot-dns-rfc2136 is already here. see attachments.... AFAICT 0.24 can still use the ebuild provided here.
Well certbot v1.0.0 is out so i decided to update the certbot-dns-rfc2136 ebuild and throw in the certbot-dns-standalone for free.... Oh the rfc2136 ebuild is a straight copy from 0.24... upto to 0.40.1 and now 1.0.0
Created attachment 598652 [details] RFC2136 ebuild
Created attachment 598654 [details] Ebuild for standalone DNS (generic) authenticator. This authenticator is handy for people that cannot easily or fast update DNS from remote. It mostly depends on static DS setup.
Created separate issues for certbot-dns-standalone & certbot-dns-rfc2136
