Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 646298 - app-crypt/certbot-dns-route53 - Amazon Route53 plugin for app-crypt/certbot
Summary: app-crypt/certbot-dns-route53 - Amazon Route53 plugin for app-crypt/certbot
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Default Assignee for New Packages
Keywords: EBUILD, PullRequest
Depends on:
Reported: 2018-02-01 13:25 UTC by Austin S. Hemmelgarn
Modified: 2023-07-30 17:48 UTC (History)
7 users (show)

See Also:
Package list:
Runtime testing required: ---

Current version ebuild for app-crypt/certbot-dns-route53 (certbot-dns-route53-0.21.1.ebuild,994 bytes, text/plain)
2018-02-01 13:25 UTC, Austin S. Hemmelgarn
Live ebuild for app-crypt/certbot-dns-route53 (certbot-dns-route53-9999.ebuild,994 bytes, text/plain)
2018-02-01 13:26 UTC, Austin S. Hemmelgarn
app-crypt/certbot-dns-rfc2136 (certbot-dns-rfc2136-0.22.0.ebuild,995 bytes, text/plain)
2018-03-18 11:07 UTC, Nico Baggus
RFC2136 ebuild (certbot-dns-rfc2136-1.0.0.ebuild,1023 bytes, text/plain)
2019-12-06 20:56 UTC, Nico Baggus
Ebuild for standalone DNS (generic) authenticator. (certbot-dns-standalone-9999.ebuild,1.06 KB, text/plain)
2019-12-06 20:58 UTC, Nico Baggus

Note You need to log in before you can comment on or make changes to this bug.
Description Austin S. Hemmelgarn 2018-02-01 13:25:46 UTC
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.
Comment 1 Austin S. Hemmelgarn 2018-02-01 13:26:31 UTC
Created attachment 517370 [details]
Live ebuild for app-crypt/certbot-dns-route53
Comment 2 Nico Baggus 2018-03-15 22:47:17 UTC
please also consider the other DNS plugins.

I personaly prefer the rfc2136 plugin as that can interact with updateable DNS records. (Bind f.e.)
Comment 3 Nico Baggus 2018-03-15 22:48:50 UTC

the dns plugins are available through pip but gentoo forces pip install --user which is not exactly preferable.
Comment 4 Nico Baggus 2018-03-18 11:07:50 UTC
Created attachment 524252 [details]

ebuild for certbot-dns-rfc2136
Comment 5 Scott Tester 2018-03-28 00:47:57 UTC
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.
Comment 6 Austin S. Hemmelgarn 2018-03-28 11:30:23 UTC
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.
Comment 7 Nico Baggus 2018-03-28 12:57:43 UTC
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).
Comment 8 Robert Förster 2018-05-19 12:33:46 UTC
(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.
Comment 9 Matthew Thode ( prometheanfire ) archtester Gentoo Infrastructure gentoo-dev Security 2018-05-19 17:52:59 UTC
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.

I have considered adding certbot-dns-rfc2136 as I do run bind though.
Comment 10 Austin S. Hemmelgarn 2018-05-21 12:32:22 UTC
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).
Comment 11 Matthew Thode ( prometheanfire ) archtester Gentoo Infrastructure gentoo-dev Security 2018-05-21 13:27:31 UTC shows that it can/should be standalone.
Comment 12 Nico Baggus 2018-05-21 21:24:27 UTC

The certbot-dns-rfc2136 is already here.
see attachments.... 

AFAICT 0.24 can still use the ebuild provided here.
Comment 13 Nico Baggus 2019-12-06 20:54:06 UTC
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
Comment 14 Nico Baggus 2019-12-06 20:56:42 UTC
Created attachment 598652 [details]
RFC2136 ebuild
Comment 15 Nico Baggus 2019-12-06 20:58:32 UTC
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.
Comment 16 Nico Baggus 2019-12-13 21:48:34 UTC
Created separate issues for certbot-dns-standalone & certbot-dns-rfc2136