Package: release.debian.org Severity: normal User: release.debian.org@packages.debian.org Usertags: unblock X-Debbugs-Cc: lacme@packages.debian.org Control: affects -1 + src:lacme Please unblock package 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.1-1 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. [ 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 so trivial I uploaded 0.8.2-1 rather than backported the fix to 0.8.1-1. 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 testing unblock lacme/0.8.2-1 -- Guilhem.
diffstat for lacme-0.8.1 lacme-0.8.2
Changelog | 11 +++++++++++
client | 31 +++++++++++++++++--------------
debian/changelog | 12 ++++++++++++
lacme | 2 +-
lacme-accountd | 2 +-
tests/old-accountd | 2 +-
6 files changed, 43 insertions(+), 17 deletions(-)
diff -Nru lacme-0.8.1/Changelog lacme-0.8.2/Changelog
--- lacme-0.8.1/Changelog 2023-01-25 03:23:51.000000000 +0100
+++ lacme-0.8.2/Changelog 2023-04-25 20:06:22.000000000 +0200
@@ -1,3 +1,14 @@
+lacme (0.8.2) upstream;
+
+ + 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" state and
+ we need to account for that.
+ - Test suite: Point stretch's archive URL to archive.d.o.
+
+ -- Guilhem Moulin <guilhem@fripost.org> Tue, 25 Apr 2023 20:06:22 +0200
+
lacme (0.8.1) upstream;
+ lacme-accountd: improve log messages and refactor logging logic.
diff -Nru lacme-0.8.1/client lacme-0.8.2/client
--- lacme-0.8.1/client 2023-01-25 03:23:51.000000000 +0100
+++ lacme-0.8.2/client 2023-04-25 20:06:22.000000000 +0200
@@ -43,7 +43,7 @@
# instance own by another user and created with umask 0177) is not a
# problem since SOCKET_FD can be bound as root prior to the execve(2).
-our $VERSION = '0.8.1';
+our $VERSION = '0.8.2';
my $PROTOCOL_VERSION = 1;
my $NAME = 'lacme-client';
@@ -346,11 +346,12 @@
}
# 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};
@@ -361,19 +362,21 @@
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.1/debian/changelog lacme-0.8.2/debian/changelog
--- lacme-0.8.1/debian/changelog 2023-01-25 03:33:11.000000000 +0100
+++ lacme-0.8.2/debian/changelog 2023-04-25 20:08:21.000000000 +0200
@@ -1,3 +1,15 @@
+lacme (0.8.2-1) unstable; urgency=medium
+
+ * New upstream bugfix release.
+ + 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" state and we need
+ to account for that. Closes: #1034834.
+ + Test suite: Point stretch's archive URL to archive.d.o.
+
+ -- Guilhem Moulin <guilhem@debian.org> Tue, 25 Apr 2023 20:08:21 +0200
+
lacme (0.8.1-1) unstable; urgency=medium
[ Guilhem Moulin ]
diff -Nru lacme-0.8.1/lacme lacme-0.8.2/lacme
--- lacme-0.8.1/lacme 2023-01-25 03:23:51.000000000 +0100
+++ lacme-0.8.2/lacme 2023-04-25 20:06:22.000000000 +0200
@@ -22,7 +22,7 @@
use strict;
use warnings;
-our $VERSION = '0.8.1';
+our $VERSION = '0.8.2';
my $NAME = 'lacme';
use Errno 'EINTR';
diff -Nru lacme-0.8.1/lacme-accountd lacme-0.8.2/lacme-accountd
--- lacme-0.8.1/lacme-accountd 2023-01-25 03:23:51.000000000 +0100
+++ lacme-0.8.2/lacme-accountd 2023-04-25 20:06:22.000000000 +0200
@@ -23,7 +23,7 @@
use strict;
use warnings;
-our $VERSION = '0.8.1';
+our $VERSION = '0.8.2';
my $PROTOCOL_VERSION = 1;
my $NAME = 'lacme-accountd';
diff -Nru lacme-0.8.1/tests/old-accountd lacme-0.8.2/tests/old-accountd
--- lacme-0.8.1/tests/old-accountd 2023-01-25 03:23:51.000000000 +0100
+++ lacme-0.8.2/tests/old-accountd 2023-04-25 20:06:22.000000000 +0200
@@ -12,7 +12,7 @@
privkey = file:/etc/lacme/account.key
EOF
-echo "deb http://deb.debian.org/debian stretch main" >>/etc/apt/sources.list
+echo "deb http://archive.debian.org/debian stretch main" >>/etc/apt/sources.list
DEBIAN_FRONTEND="noninteractive" apt update
DEBIAN_FRONTEND="noninteractive" apt install -y --no-install-recommends \
--reinstall --allow-downgrades \
Attachment:
signature.asc
Description: PGP signature