Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian.org@packages.debian.org
Usertags: pu
X-Debbugs-Cc: lacme@packages.debian.org
Control: affects -1 + src:lacme
[ Reason ]
The ACME specification (RFC 8555 sec. 7.1.6) clearly reads that state
transition for Order Objects follows (‘pending’ →) ‘ready’ →
‘processing’ → ‘valid’, but lacme 0.8.0-2 fails to handle the transition
via ‘processing’ state.
https://www.rfc-editor.org/rfc/rfc8555#section-7.1.6
[ Impact ]
As of today Order Requests still work on the production Let's Encrypt
environment, but now fails on the staging one. It's unclear whether the
production server has different timing conditions (faster machine, so
the client doesn't have time to issue follow-up request while the server
is in ‘processing’ state), or if there was some code change deployed to
the staging server which is not in production (yet).
In the former case, the lacme client suffers from a race condition that
needs to be fixed anyway. In the latter case, lacme will fail to handle
Order Requests (incl. certificate renewals) if/when the production ACME
server is upgraded.
The issue is fixed in unstable (0.8.2-1) and the unblock request for
bookworm was filed at #1034879.
[ Tests ]
Manual tests: I successfully ran the upstream test suite (which includes
multiple Order Requests) on the staging server. (There is unfortunately
no autopkgtest running the test suite, because it requires inbound
80/tcp and a stable (wildcard) domain name.)
I also successfully issued Order Requests to Let's Encrypt's production
server.
[ Risks ]
src:lacme is a leaf package and the diff is rather trivial: AFAICT the
only change is a more lax handling of Order Object responses, so there
shouldn't be any risk associated with the upgrade.
[ 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 bullseye
[x] the issue is verified as fixed in unstable
[ Changes ]
* Point debian-branch to debian/bullseye in debian/gbp.conf.
* lacme client: Handle "ready" → "processing" → "valid" status change
during newOrder, instead of just "ready" → "valid". The latter may
be what we observe when the server is fast enough, but according to
RFC 8555 sec. 7.1.6 the state actually transitions via "processing"
and the client needs to account for that.
It appears Let's Encrypt staging environment now has different
timing conditions and lacme is unable to request certificates due to
this issue.
(Closes: #1034834)
--
Guilhem.
diffstat for lacme-0.8.0 lacme-0.8.0
changelog | 11 +
gbp.conf | 2
patches/client-Handle-ready-processing-valid-status-change-during.patch | 76 ++++++++++
patches/series | 1
4 files changed, 89 insertions(+), 1 deletion(-)
diff -Nru lacme-0.8.0/debian/changelog lacme-0.8.0/debian/changelog
--- lacme-0.8.0/debian/changelog 2021-05-04 01:37:13.000000000 +0200
+++ lacme-0.8.0/debian/changelog 2023-04-28 10:25:54.000000000 +0200
@@ -1,3 +1,14 @@
+lacme (0.8.0-2+deb11u1) bullseye; urgency=medium
+
+ * client: Handle "ready" → "processing" → "valid" status change during
+ newOrder, instead of just "ready" → "valid". The latter may be what we
+ observe when the server is fast enough, but according to RFC 8555 sec.
+ 7.1.6 the state actually transitions via "processing" and we need to
+ account for that (closes: #1034834).
+ * d/gbp.conf: Set 'debian-branch = debian/bullseye'.
+
+ -- Guilhem Moulin <guilhem@debian.org> Fri, 28 Apr 2023 10:25:54 +0200
+
lacme (0.8.0-2) unstable; urgency=medium
* d/lacme.postrm: Don't delete system users on purge. There might be files
diff -Nru lacme-0.8.0/debian/gbp.conf lacme-0.8.0/debian/gbp.conf
--- lacme-0.8.0/debian/gbp.conf 2021-05-04 01:37:13.000000000 +0200
+++ lacme-0.8.0/debian/gbp.conf 2023-04-28 10:25:54.000000000 +0200
@@ -1,6 +1,6 @@
[DEFAULT]
upstream-branch = upstream
-debian-branch = debian/latest
+debian-branch = debian/bullseye
upstream-tag = v%(version)s
debian-tag = debian/%(version)s
pristine-tar = False
diff -Nru lacme-0.8.0/debian/patches/client-Handle-ready-processing-valid-status-change-during.patch lacme-0.8.0/debian/patches/client-Handle-ready-processing-valid-status-change-during.patch
--- lacme-0.8.0/debian/patches/client-Handle-ready-processing-valid-status-change-during.patch 1970-01-01 01:00:00.000000000 +0100
+++ lacme-0.8.0/debian/patches/client-Handle-ready-processing-valid-status-change-during.patch 2023-04-28 10:25:54.000000000 +0200
@@ -0,0 +1,76 @@
+From: Guilhem Moulin <guilhem@fripost.org>
+Date: Tue, 25 Apr 2023 10:51:36 +0200
+Subject: =?utf-8?q?client=3A_Handle_=22ready=22_=E2=86=92_=22processing=22_?=
+ =?utf-8?q?=E2=86=92_=22valid=22_status_change_during_newOrder=2E?=
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+
+Instead of just "ready" → "valid", which may be what we observe when the
+server is fast enough, but according to RFC 8555 sec. 7.1.6 the state
+actually transitions via "processing" state and we need to account for
+that.
+
+It appears Let's Encrypt staging environment now has different timing
+conditions and lacme is unable to request certificates due to this
+issue.
+
+Thanks to Alexander Borkowski for the report!
+
+Bug-Debian: https://bugs.debian.org/1034834
+---
+ client | 29 ++++++++++++++++-------------
+ 1 file changed, 16 insertions(+), 13 deletions(-)
+
+diff --git a/client b/client
+index fdef865..4d4d129 100755
+--- a/client
++++ b/client
+@@ -351,11 +351,12 @@ elsif ($COMMAND eq 'newOrder') {
+ }
+
+ # poll the order URL (to get the status of all challenges at once)
+- # until the status become 'valid'
++ # until the status become 'valid'; see RFC 8555 sec. 7.1.6 for the
++ # the status change flow
+ my $orderstr = join(', ', map {uc($_->{type}) .":". $_->{value}} @identifiers);
+ my $certuri;
+- for (my $i = 0;;) {
+- my $r = acme($orderurl);
++ for (my $i = 0, my $url = $orderurl, my $payload;;) {
++ my $r = acme($url => $payload);
+ my $resp = request_json_decode($r);
+ if (defined (my $problem = $resp->{error})) { # problem document (RFC 7807)
+ my $msg = $problem->{status};
+@@ -366,19 +367,21 @@ elsif ($COMMAND eq 'newOrder') {
+ my $status = $resp->{status};
+ if (!defined $status or $status eq "invalid") {
+ die "Error: Invalid order $orderstr\n";
+- }
+- elsif ($status eq "ready") {
+- my $r = acme($order->{finalize}, {csr => encode_base64url($csr)});
+- my $resp = request_json_decode($r);
+- $certuri = $resp->{certificate};
+- last;
+- }
+- elsif ($status eq "valid") {
++ } elsif ($status eq "pending") {
++ # keep retrying
++ } elsif ($status eq "ready") {
++ $url = $order->{finalize};
++ $payload = {csr => encode_base64url($csr)};
++ # retry after moving to "processing" or "valid" state
++ next;
++ } elsif ($status eq "processing") {
++ $url = $orderurl;
++ undef $payload;
++ } elsif ($status eq "valid") {
+ $certuri = $resp->{certificate} //
+ die "Error: Missing \"certificate\" field in \"valid\" order\n";
+ last;
+- }
+- elsif ($status ne "pending" and $status ne "processing") {
++ } else {
+ warn "Unknown order status: $status\n";
+ }
+
diff -Nru lacme-0.8.0/debian/patches/series lacme-0.8.0/debian/patches/series
--- lacme-0.8.0/debian/patches/series 2021-05-04 01:37:13.000000000 +0200
+++ lacme-0.8.0/debian/patches/series 2023-04-28 10:25:54.000000000 +0200
@@ -1 +1,2 @@
Mention-the-Debian-BTS-in-the-manpages.patch
+client-Handle-ready-processing-valid-status-change-during.patch
Attachment:
signature.asc
Description: PGP signature