XPost: linux.debian.devel.release

This is a multi-part MIME message sent by reportbug.


Package: release.debian.org
Severity: normal
X-Debbugs-Cc: python-certbot@packages.debian.org, hlieberman@debian.org Control: affects -1 + src:python-certbot
User: release.debian.org@packages.debian.org
Usertags: unblock
User: hlieberman@debian.org
Usertags: trixie-certbot

Please unblock package python-certbot

[ Reason ]

The certbot 2.x series is end of life and will not receive further updates or backports of changes. (https://github.com/certbot/certbot/wiki/Architectural-Decision-Records-2025#-update-to-certbots-version-policy-and-end-of-life-support-on-previous-major-versions)
By far and away, the primary purpose of certbot is to receive certificates from Let's Encrypt, and the Let's Encrypt team are planning API changes in 2025 which
will break the issuance of TLS certificates for people using the Certbot 2.x series.

[ Impact ]

If the unblock is not granted, certbot will suddenly stop working at
some point in the future and users' TLS certificates will expire. Because certbot tends to be used as a set-it-and-forget-it system, and Let's Encrypt has
recently disabled their email notifications, users' websites and applications may suddenly be unavailable to users and/or vulnerable to MitM.

[ Tests ]

Certbot's two primary plugins (python-certbot-apache, python-certbot-nginx) and the main utility (python-certbot) have a test harness which exercises the entire
process of getting a certificate against a test environment. This provides very high confidence that those packages are still working, and that the libraries which they depend on (python-josepy, python-acme) are in good health. These tests pass cleanly on ci.d.n for all three invocations.

The dns plugin packages (python-certbot-dns-*) are substantially less complicated than the other certbot packages and primarily handle communication with various companies' API layers. Those are unlikely to have broken because of
the changes to certbot's internals; the primary way in which those packages break are due to API changes on the providers' ends.

[ Risks ]

Upgrading the packages across major versions comes with risks, certainly, but there is little in the way of alternative. The changes are too complex for me to
be willing to attempt to backport, and in a security critical application, I am even more reticent than I normally would be. I recognize the late application introduces even more risk --- and rightfully, I'm sure no small amount of annoyance --- but it is where we've ended up.

[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing

[ Other info ]

This is one of a series of identical unblock requests with only
package names and debdiffs differing.

unblock python-certbot/4.0.0-2

diff -Nru python-certbot-2.11.0/certbot/achallenges.py python-certbot-4.0.0/certbot/achallenges.py
--- python-certbot-2.11.0/certbot/achallenges.py 2024-06-05 17:34:02.000000000 -0400
+++ python-certbot-4.0.0/certbot/achallenges.py 2025-04-07 18:03:33.000000000 -0400
@@ -19,6 +19,7 @@
"""
import logging
from typing import Any
+from typing import Tuple
from typing import Type

import josepy as jose
@@ -49,7 +50,8 @@
"""Client annotated `KeyAuthorizationChallenge` challenge."""
__slots__ = ('challb', 'domain', 'account_key') # pylint: disable=redefined-slots-in-subclass

- def response_and_validation(self, *args: Any, **kwargs: Any) -> Any:
+ def response_and_validation(self, *args: Any, **kwargs: Any
+ ) -> Tuple['challenges.KeyAuthorizationChallengeResponse', Any]:
"""Generate response and validation."""
return self.challb.chall.response_and_validation(
self.account_key, *args, **kwargs)
diff -Nru python-certbot-2.11.0/certbot/compat/filesystem.py python-certbot-4.0.0/certbot/compat/filesystem.py
--- python-certbot-2.11.0/certb