Your message dated Sun, 30 Apr 2023 12:05:55 +0200
with message-id
<cam8zjqtz5-z0emdypnsh7spbktbeikqgcudiez3jxmhpuh7...@mail.gmail.com>
and subject line Re: Bug#1034879: unblock: lacme/0.8.2-1
has caused the Debian Bug report #1034879,
regarding unblock: lacme/0.8.2-1
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 [email protected]
immediately.)
--
1034879: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034879
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: [email protected]
Usertags: unblock
X-Debbugs-Cc: [email protected]
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 <[email protected]> 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 <[email protected]> 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 \
signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
On Wed, 26 Apr 2023 at 17:21, Guilhem Moulin <[email protected]> wrote:
> Please unblock package lacme
Unblocked, thanks.
--- End Message ---
