[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#36998] [PATCH] services: certbot: Add --manual-public-ip-logging-ok
From: |
Carlo Zancanaro |
Subject: |
[bug#36998] [PATCH] services: certbot: Add --manual-public-ip-logging-ok for manual challenges |
Date: |
Thu, 12 Sep 2019 21:20:23 +1000 |
User-agent: |
mu4e 1.2.0; emacs 26.3 |
Hey Ludo’,
On Wed, Sep 11 2019, Ludovic Courtès wrote:
Perhaps we should pass --manual-public-ip-logging-ok only when
‘challenge’ has the expected value (DNS challenge type; what’s
the value for that?), and also document that prominently in the
manual?
My understanding is that this flag is necessary for any manual
challenge type, it's just that our default HTTP challenge doesn't
use a "manual" challenge type. For a DNS challenge the value for
challenge should be "dns".
I was a little torn about documenting it in the manual, because
using the manual IP logging doesn't leak any more information than
the standard HTTP challenge type. There is a certbot issue
discussing the problem for manual challenges[1], and the problem
is when one requests the certificate from a different machine to
the one that will use the certificate. This doesn't seem to be the
natural use case for the Guix certbot-service-type, so I didn't
feel it was necessary to add it to the manual. I'm also fairly
sure that the logged IPs are not publicly available at the moment,
based on this[2] and this[3].
Given all of that, I have attached a patch with a small update to
the manual. I don't think I'd describe it as "prominent", but it
does mention it in an appropriate place.
Carlo
[1]: https://github.com/certbot/certbot/issues/991
[2]:
https://community.letsencrypt.org/t/public-logging-of-requesting-ip-addresses/64077
[3]: https://community.letsencrypt.org/t/public-ip-logging/89712
0001-services-certbot-Add-manual-public-ip-logging-ok-for.patch
Description: Text Data