From: Thomas Ellmenreich <t.ellmenreich@proxmox.com>
To: pve-devel@lists.proxmox.com
Cc: Thomas Ellmenreich <t.ellmenreich@proxmox.com>,
Elias Huhsovitz <e.huhsovitz@proxmox.com>
Subject: [PATCH proxmox-acme v2] fix #7749: always serialize in same order
Date: Mon, 27 Jul 2026 09:29:58 +0200 [thread overview]
Message-ID: <20260727072958.37999-1-t.ellmenreich@proxmox.com> (raw)
All objects are now serialized with "canonical => 1" so that the
resulting bytes are directly comparable. Perls randomized hash key
orders lead to different serialization outputs even with the same input.
The 'tojs' function also now explicitly overrides the utf8 and canonical
options to make sure that they are always set.
Signed-off-by: Thomas Ellmenreich <t.ellmenreich@proxmox.com>
Reviewed-by: Elias Huhsovitz <e.huhsovitz@proxmox.com>
---
Serializing acme responses to json, because of perls randomized hash key order,
would lead to unequal serialized responses if they were compared as bytes. By
setting "canonical => 1" the serializations now always have the same order and
can thus be compared bytewise.
I have tested the patch against a local instance of HashiCorp Vault PKI and the
EAB registration works.
It seems that "canonical" can have performance implications when serialising
larger objects, but since the objects produced in our acme client are
relatively small, I consider this acceptable.
src/PVE/ACME.pm | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/src/PVE/ACME.pm b/src/PVE/ACME.pm
index e6fb9c2..fb93eca 100644
--- a/src/PVE/ACME.pm
+++ b/src/PVE/ACME.pm
@@ -64,9 +64,13 @@ sub encode($) { # acme requires 'base64url' encoding
return encode_base64url($_[0]);
}
-sub tojs($;%) { # shortcut for to_json with utf8=>1
- my ($data, %data) = @_;
- return to_json($data, { utf8 => 1, %data });
+sub tojs($;%) { # shortcut for to_json with utf8=>1 and canonical=>1
+ my ($data, %opts) = @_;
+
+ $opts{utf8} = 1;
+ $opts{canonical} = 1;
+
+ return to_json($data, %opts);
}
sub fromjs($) {
@@ -155,7 +159,7 @@ sub save {
}
# pretty => 1 for readability
# canonical => 1 to reduce churn
- file_set_contents($self->{path}, tojs($o, pretty => 1, canonical => 1));
+ file_set_contents($self->{path}, tojs($o, pretty => 1));
}
# Load serialized account JSON file into $self
@@ -196,7 +200,7 @@ sub jwk {
sub jwk_thumbprint {
my ($self) = @_;
my $jwk = $self->jwk(1); # $pure = 1
- return encode(sha256(tojs($jwk, canonical => 1))); # canonical sorts
+ return encode(sha256(tojs($jwk)));
}
# A key authorization string in acme is a challenge token dot-connected with
--
2.47.3
reply other threads:[~2026-07-27 7:30 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260727072958.37999-1-t.ellmenreich@proxmox.com \
--to=t.ellmenreich@proxmox.com \
--cc=e.huhsovitz@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.