Package: release.debian.org Severity: normal Tags: bullseye User: release.debian....@packages.debian.org Usertags: pu X-Debbugs-Cc: la...@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 <guil...@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 <guil...@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
signature.asc
Description: PGP signature
