[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1035046: marked as done (bullseye-pu: package lacme/0.8.0-2+deb11u1)

Your message dated Sat, 07 Oct 2023 12:41:28 +0100
with message-id <84bb5ff8312f749ebe536897993782bf35aa1977.camel@adam-barratt.org.uk>
and subject line Closing opu requests for updates included in 11.8
has caused the Debian Bug report #1035046,
regarding bullseye-pu: package lacme/0.8.0-2+deb11u1
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1035046: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035046
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
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


--- End Message ---
--- Begin Message --- 
Package: release.debian.org
Version: 11.8

Hi,

The updates referred to by each of these requests were included in
today's 11.8 bullseye point release.

Regards,

Adam

--- End Message ---
Reply to: