Re: BUG #19702: decode() accepts Base64 payload after terminal padding

On Mon, Nov 9, 2026 at 2:26 PM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>
> > On 19 Sep 2026, at 16:59, shihao zhong <zhong950419(at)gmail(dot)com> wrote:
> >
> > Hi Qifan,
> >
> > Thanks for reporting that issue.
> >
> > I can reproduce this on master. The decoder sets "end" at the first "="
> > and never looks at it again, so later data and later "=" all pass
>
> Sorry for missing this at the time of it being reported.
>
> > 0001 raises an error for anything but whitespace after the padding, the
> > same rule base32hex already has. 0002 adds tests. 0003 fixes the two
> > copies of this code, pg_b64_decode() in src/common and the armor decoder
> > in pgcrypto. dearmor() shows the same bug when the CRC matches.
>
> I had to stare the code for some time to convince myself there were no more
> bugs hiding in pgcrypto for this wrt RFC9580, but I think it's correct.
>
> > This rejects input that used to pass, so I am not sure about the back
> > branches. I would leave that to the committer.
>
> Thanks for the patches, the attached is a rebased squash of the three patches
> since I would prefer to apply them all at once. Given the lack of complaints I
> will err on the side of caution and keep this in master only. At least for now.

Thank you for taking care of it. I was also reviewing the patches and
was about to send LGTM.

While I agree that we don't backpatch it to v18 or older, I think it
(or at least the base64url part) should go into v19 as well. v19 is
still in RC and base64url is new in v19, so there are no existing
users relying on the current behavior, and it would be better to make
base64url and base32hex consistent before the release. IIUC the
base64url truncation fix 5f57f58179b was backpatched to v19 for the
same reason.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com