On Thu, Jun 11, 2026 at 04:26:06AM -0600, Anthony J. Bentley wrote:
> Jonathan Matthew writes:
> > Sadly this adds yet another base64 decoder implementation, because there
> > wasn't one using the base64url encoding that acme-client could get to.
> > This one is based on the libc bcrypt implementation, because it's short and
> > uncomplicated and doesn't care about padding.
> 
> It seems that padding matters here. Actalis gave me a key ending in =
> which acme-client doesn't understand:
> 
> $ acme-client -e XXXXXXXXXXXXXXXXXXXXXXXXXX:YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYABC= mydomain
> acme-client: unable to decode EAB key

Interesting.  Most of the code I've looked at for dealing with EAB keys
will fail if the base64url encoded string is padded with '='s, so I assumed
we weren't going to see that in the wild.  Can you try this diff?

Index: base64.c
===================================================================
RCS file: /cvs/src/usr.sbin/acme-client/base64.c,v
diff -u -p -r1.10 base64.c
--- base64.c	22 May 2026 01:53:10 -0000	1.10
+++ base64.c	22 Jun 2026 05:08:17 -0000
@@ -113,6 +113,8 @@ unbase64buf_url(const unsigned char *dat
                 if ((p + 2) >= data + len)
                         break;
 
+                if (*(p + 2) == '=')
+                        break;
                 c3 = CHAR64(*(p + 2));
                 if (c3 == 255)
                         return -1;
@@ -121,6 +123,8 @@ unbase64buf_url(const unsigned char *dat
                 if ((p + 3) >= data + len)
                         break;
 
+                if (*(p + 3) == '=')
+                        break;
                 c4 = CHAR64(*(p + 3));
                 if (c4 == 255)
                         return -1;