Bug#976432: buster-pu: package python-certbot/0.31.0-1
On Sun, Jan 3, 2021 at 1:51 PM Adam D. Barratt wrote: > Thanks. Please feel free to upload. Uploaded! -- Harlan Lieberman-Berg ~hlieberman
Bug#976432: buster-pu: package python-certbot/0.31.0-1
Control: tags -1 + confirmed On Fri, 2021-01-01 at 17:05 -0500, Harlan Lieberman-Berg wrote: > On Fri, Jan 1, 2021 at 12:14 PM Adam D. Barratt > wrote: > > That version number is lower than the package currently in buster. > > You > > want 0.31.0-1+deb10u1. > > Indeed I do! New debdiff attached. Thanks. Please feel free to upload. [...] > > The next point release is likely to be in early February. Assuming > > the > > plan outlined at > > https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430 > > is still current, it sounds like there will be one brown-out for v1 > > before that point, possibly two if we're unlikely with timing. Are > > we anticipating that being enough of an issue to warrant pushing > > the update via stable-updates before the point release? > > It's not great, but I also don't think it's necessarily worth fixing > through s-u. I'll reach out to the ISRG folks and see what their > specific timing is like for doing the brownouts. I may be able to > encourage them to nudge it backwards into February. OK, thanks. Please let us know if the situation changes. Regards, Adam
Bug#976432: buster-pu: package python-certbot/0.31.0-1
On Fri, Jan 1, 2021 at 12:14 PM Adam D. Barratt
wrote:
> That version number is lower than the package currently in buster. You
> want 0.31.0-1+deb10u1.
Indeed I do! New debdiff attached.
> + * Switch to use of ACMEv2 API to prevent renewal failures. (Closes:
> #971045)
>
> The metadata for that bug implies that it affects the package in
> unstable. I'm assuming that's simply an oversight? If so, please add an
> appropriate fixed version. (I'm not entirely sure why it was cloned
> from #969126 either, but that's not directly relevant here.)
Correct. I cloned the bug so I could track the fix in oldstable and
the fix in stable separately, just to make sure I didn't miss one when
the autoclose happened. I've updated the version numbers to show the
fix in unstable (and to remove the reference to oldstable in the
stable issue).
> The next point release is likely to be in early February. Assuming the
> plan outlined at
> https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430
> is still current, it sounds like there will be one brown-out for v1 before
> that point, possibly two if we're unlikely with timing. Are we anticipating
> that being enough of an issue to warrant pushing the update via
> stable-updates before the point release?
It's not great, but I also don't think it's necessarily worth fixing
through s-u. I'll reach out to the ISRG folks and see what their
specific timing is like for doing the brownouts. I may be able to
encourage them to nudge it backwards into February.
Sincerely,
--
Harlan Lieberman-Berg
~hlieberman
diff -Nru python-certbot-0.31.0/debian/changelog python-certbot-0.31.0/debian/changelog
--- python-certbot-0.31.0/debian/changelog 2019-02-09 19:39:59.0 -0500
+++ python-certbot-0.31.0/debian/changelog 2020-12-04 21:33:11.0 -0500
@@ -1,3 +1,15 @@
+python-certbot (0.31.0-1+deb10u1) buster; urgency=high
+
+ * Switch to use of ACMEv2 API to prevent renewal failures. (Closes: #971045)
+
+Let's Encrypt's ACMEv1 API is deprecated and in the process of being
+shut down. Beginning with brownouts in January 2021, and ending with a
+total shutdown in June 2021, the Let's Encrypt APIs will become
+unavailable. To prevent users having disruptions to their certificate
+renewals, this update backports the switch over to the ACMEv2 API.
+
+ -- Harlan Lieberman-Berg Fri, 04 Dec 2020 21:33:11 -0500
+
python-certbot (0.31.0-1) unstable; urgency=medium
* New upstream version 0.31.0
diff -Nru python-certbot-0.31.0/debian/patches/0002-acmev2-api.patch python-certbot-0.31.0/debian/patches/0002-acmev2-api.patch
--- python-certbot-0.31.0/debian/patches/0002-acmev2-api.patch 1969-12-31 19:00:00.0 -0500
+++ python-certbot-0.31.0/debian/patches/0002-acmev2-api.patch 2020-12-04 21:33:11.0 -0500
@@ -0,0 +1,88 @@
+From 8a15bd7927e2b8956bb1f4d062423e471e473ccf Mon Sep 17 00:00:00 2001
+From: Alex Zorin
+Date: Thu, 21 May 2020 22:58:40 +1000
+Subject: [PATCH 1/2] renewal: disregard acme-v01 in renewal configs
+
+Fixes #7979
+---
+ certbot/_internal/constants.py | 2 ++
+ certbot/_internal/renewal.py | 17 +++--
+ certbot/tests/renewal_test.py | 8
+ 3 files changed, 25 insertions(+), 2 deletions(-)
+
+Index: python-certbot/certbot/constants.py
+===
+--- python-certbot.orig/certbot/constants.py
python-certbot/certbot/constants.py
+@@ -120,6 +120,8 @@ CLI_DEFAULTS = dict(
+ )
+ STAGING_URI = "https://acme-staging-v02.api.letsencrypt.org/directory;
+
++V1_URI = "https://acme-v01.api.letsencrypt.org/directory;
++
+ # The set of reasons for revoking a certificate is defined in RFC 5280 in
+ # section 5.3.1. The reasons that users are allowed to submit are restricted to
+ # those accepted by the ACME server implementation. They are listed in
+Index: python-certbot/certbot/renewal.py
+===
+--- python-certbot.orig/certbot/renewal.py
python-certbot/certbot/renewal.py
+@@ -17,6 +17,7 @@ import OpenSSL
+ from acme.magic_typing import List # pylint: disable=unused-import, no-name-in-module
+
+ from certbot import cli
++from certbot import constants
+ from certbot import crypto_util
+ from certbot import errors
+ from certbot import interfaces
+@@ -247,16 +248,28 @@ def _restore_int(name, value):
+ raise errors.Error("Expected a numeric value for {0}".format(name))
+
+
+-def _restore_str(unused_name, value):
++def _restore_str(name, value):
+ """Restores an string key-value pair from a renewal config file.
+
+-:param str unused_name: option name
++:param str name: option name
+ :param str value: option value
+
+ :returns: converted option value to be stored in the runtime config
+ :rtype: str or None
+
+ """
++# Previous to v0.5.0, Certbot always stored the `server` URL in the renewal config,
++# resulting in configs
Bug#976432: buster-pu: package python-certbot/0.31.0-1
On Fri, 2020-12-04 at 21:45 -0500, Harlan Lieberman-Berg wrote: > As part of the deprecation of the Let's Encrypt v1 endpoint beginning > in January, they are going to begin causing intermittant failures > increasing to a complete shutdown June 2021. > > To prevent users from being affected by this transition, I've > prepared a backport of the piece of code that switches renewals > automatically to v2. In this version of the code, new certificates > were already being issued through the v2 URL. +python-certbot (0.31.0-1~deb10u1) buster; urgency=high That version number is lower than the package currently in buster. You want 0.31.0-1+deb10u1. + * Switch to use of ACMEv2 API to prevent renewal failures. (Closes: #971045) The metadata for that bug implies that it affects the package in unstable. I'm assuming that's simply an oversight? If so, please add an appropriate fixed version. (I'm not entirely sure why it was cloned from #969126 either, but that's not directly relevant here.) The next point release is likely to be in early February. Assuming the plan outlined at https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430 is still current, it sounds like there will be one brown-out for v1 before that point, possibly two if we're unlikely with timing. Are we anticipating that being enough of an issue to warrant pushing the update via stable-updates before the point release? Regards, Adam
Bug#976432: buster-pu: package python-certbot/0.31.0-1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: hlieber...@debian.org, team+letsencr...@tracker.debian.org
Hello Release Team!
As part of the deprecation of the Let's Encrypt v1 endpoint beginning in
January, they are going to begin causing intermittant failures increasing to a
complete shutdown June 2021.
To prevent users from being affected by this transition, I've prepared a
backport of the piece of code that switches renewals automatically to v2. In
this version of the code, new certificates were already being issued through the
v2 URL.
A debdiff is attached.
Sincerely,
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru python-certbot-0.31.0/debian/changelog
python-certbot-0.31.0/debian/changelog
--- python-certbot-0.31.0/debian/changelog 2019-02-09 19:39:59.0
-0500
+++ python-certbot-0.31.0/debian/changelog 2020-12-04 21:33:11.0
-0500
@@ -1,3 +1,15 @@
+python-certbot (0.31.0-1~deb10u1) buster; urgency=high
+
+ * Switch to use of ACMEv2 API to prevent renewal failures. (Closes: #971045)
+
+Let's Encrypt's ACMEv1 API is deprecated and in the process of being
+shut down. Beginning with brownouts in January 2021, and ending with a
+total shutdown in June 2021, the Let's Encrypt APIs will become
+unavailable. To prevent users having disruptions to their certificate
+renewals, this update backports the switch over to the ACMEv2 API.
+
+ -- Harlan Lieberman-Berg Fri, 04 Dec 2020 21:33:11
-0500
+
python-certbot (0.31.0-1) unstable; urgency=medium
* New upstream version 0.31.0
diff -Nru python-certbot-0.31.0/debian/patches/0002-acmev2-api.patch
python-certbot-0.31.0/debian/patches/0002-acmev2-api.patch
--- python-certbot-0.31.0/debian/patches/0002-acmev2-api.patch 1969-12-31
19:00:00.0 -0500
+++ python-certbot-0.31.0/debian/patches/0002-acmev2-api.patch 2020-12-04
21:30:36.0 -0500
@@ -0,0 +1,88 @@
+From 8a15bd7927e2b8956bb1f4d062423e471e473ccf Mon Sep 17 00:00:00 2001
+From: Alex Zorin
+Date: Thu, 21 May 2020 22:58:40 +1000
+Subject: [PATCH 1/2] renewal: disregard acme-v01 in renewal configs
+
+Fixes #7979
+---
+ certbot/_internal/constants.py | 2 ++
+ certbot/_internal/renewal.py | 17 +++--
+ certbot/tests/renewal_test.py | 8
+ 3 files changed, 25 insertions(+), 2 deletions(-)
+
+Index: python-certbot/certbot/constants.py
+===
+--- python-certbot.orig/certbot/constants.py
python-certbot/certbot/constants.py
+@@ -120,6 +120,8 @@ CLI_DEFAULTS = dict(
+ )
+ STAGING_URI = "https://acme-staging-v02.api.letsencrypt.org/directory;
+
++V1_URI = "https://acme-v01.api.letsencrypt.org/directory;
++
+ # The set of reasons for revoking a certificate is defined in RFC 5280 in
+ # section 5.3.1. The reasons that users are allowed to submit are restricted
to
+ # those accepted by the ACME server implementation. They are listed in
+Index: python-certbot/certbot/renewal.py
+===
+--- python-certbot.orig/certbot/renewal.py
python-certbot/certbot/renewal.py
+@@ -17,6 +17,7 @@ import OpenSSL
+ from acme.magic_typing import List # pylint: disable=unused-import,
no-name-in-module
+
+ from certbot import cli
++from certbot import constants
+ from certbot import crypto_util
+ from certbot import errors
+ from certbot import interfaces
+@@ -247,16 +248,28 @@ def _restore_int(name, value):
+ raise errors.Error("Expected a numeric value for {0}".format(name))
+
+
+-def _restore_str(unused_name, value):
++def _restore_str(name, value):
+ """Restores an string key-value pair from a renewal config file.
+
+-:param str unused_name: option name
++:param str name: option name
+ :param str value: option value
+
+ :returns: converted option value to be stored in the runtime config
+ :rtype: str or None
+
+ """
++# Previous to v0.5.0, Certbot always stored the `server` URL in the
renewal config,
++# resulting in configs which explicitly use the deprecated ACMEv1 URL,
today
++# preventing an automatic transition to the default modern ACME URL.
++# (https://github.com/certbot/certbot/issues/7978#issuecomment-625442870)
++# As a mitigation, this function reinterprets the value of the `server`
parameter if
++# necessary, replacing the ACMEv1 URL with the default ACME URL. It is
still possible
++# to override this choice with the
