GNU bug report logs -
#36998
[PATCH] services: certbot: Add --manual-public-ip-logging-ok for manual challenges
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 36998 in the body.
You can then email your comments to 36998 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
guix-patches <at> gnu.org
:
bug#36998
; Package
guix-patches
.
(Sat, 10 Aug 2019 13:10:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Carlo Zancanaro <carlo <at> zancanaro.id.au>
:
New bug report received and forwarded. Copy sent to
guix-patches <at> gnu.org
.
(Sat, 10 Aug 2019 13:10:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I recently tried to configure the certbot-service with the dns
challenge type. It failed, because certbot tries to ask whether
you're okay with letsencrypt knowing (and potentially logging)
your IP address, but within an mcron task that just fails.
The solution is to add the --manual-public-ip-logging-ok flag, so
here's a patch to do that!
[0001-services-certbot-Add-manual-public-ip-logging-ok-for.patch (text/x-diff, inline)]
From 4a888155261caba0c4e11f8515a271ba33b92bc6 Mon Sep 17 00:00:00 2001
From: Carlo Zancanaro <carlo <at> zancanaro.id.au>
Date: Sat, 10 Aug 2019 22:52:50 +1000
Subject: [PATCH] services: certbot: Add --manual-public-ip-logging-ok for
manual challenges
* gnu/services/certbot.scm (certbot-command): Add
--manual-public-ip-logging-ok flag to the certbot command when doing a
manual challenge.
---
gnu/services/certbot.scm | 1 +
1 file changed, 1 insertion(+)
diff --git a/gnu/services/certbot.scm b/gnu/services/certbot.scm
index ae34ad17bb..0d3be03383 100644
--- a/gnu/services/certbot.scm
+++ b/gnu/services/certbot.scm
@@ -99,6 +99,7 @@
"--manual"
(string-append "--preferred-challenges=" challenge)
"--cert-name" name
+ "--manual-public-ip-logging-ok"
"-d" (string-join domains ","))
(if rsa-key-size `("--rsa-key-size" ,rsa-key-size) '())
(if authentication-hook
--
2.22.0
Information forwarded
to
guix-patches <at> gnu.org
:
bug#36998
; Package
guix-patches
.
(Tue, 10 Sep 2019 21:55:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 36998 <at> debbugs.gnu.org (full text, mbox):
Hi Carlo,
Time flies…
Carlo Zancanaro <carlo <at> zancanaro.id.au> skribis:
> I recently tried to configure the certbot-service with the dns
> challenge type. It failed, because certbot tries to ask whether you're
> okay with letsencrypt knowing (and potentially logging) your IP
> address, but within an mcron task that just fails.
>
> The solution is to add the --manual-public-ip-logging-ok flag, so
> here's a patch to do that!
[...]
> --- a/gnu/services/certbot.scm
> +++ b/gnu/services/certbot.scm
> @@ -99,6 +99,7 @@
> "--manual"
> (string-append "--preferred-challenges=" challenge)
> "--cert-name" name
> + "--manual-public-ip-logging-ok"
> "-d" (string-join domains ","))
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?
Thanks,
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org
:
bug#36998
; Package
guix-patches
.
(Thu, 12 Sep 2019 11:21:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 36998 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 (text/x-diff, attachment)]
Reply sent
to
Ludovic Courtès <ludo <at> gnu.org>
:
You have taken responsibility.
(Mon, 16 Sep 2019 08:24:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Carlo Zancanaro <carlo <at> zancanaro.id.au>
:
bug acknowledged by developer.
(Mon, 16 Sep 2019 08:24:04 GMT)
Full text and
rfc822 format available.
Message #16 received at 36998-done <at> debbugs.gnu.org (full text, mbox):
Hi Carlo,
Carlo Zancanaro <carlo <at> zancanaro.id.au> skribis:
> 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.
True. The only difference is that the Let’s Encrypt operators
explicitly state that they will log the IP address in this case, whereas
they may not do it otherwise.
> 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.
Yeah, there wasn’t any reaction, so it’s probably good enough. I’ve
applied it now, thank you!
Ludo’.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 14 Oct 2019 11:24:13 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 188 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.