| From: | shihao zhong <zhong950419(at)gmail(dot)com> |
|---|---|
| To: | imchifan(at)163(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #19702: decode() accepts Base64 payload after terminal padding |
| Date: | 2026-09-19 14:59:40 |
| Message-ID: | CAGRkXqQ1oavtxsq8y7Be63ig=iXic+ogTU2UoH9FQMBcqYi6iQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
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
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.
This rejects input that used to pass, so I am not sure about the back
branches. I would leave that to the committer.
Thanks,
Shihao
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0002-Add-tests-for-data-after-base64-padding.patch | application/octet-stream | 2.7 KB |
| v1-0001-Reject-data-after-padding-in-base64-decoding.patch | application/octet-stream | 1.8 KB |
| v1-0003-Reject-data-after-base64-padding-in-other-decoder.patch | application/octet-stream | 3.3 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2026-09-19 17:37:52 | BUG #19705: One NaN box makes a BRIN box_inclusion_ops index omit unrelated rows |
| Previous Message | PG Bug reporting form | 2026-09-19 13:51:31 | BUG #19704: ispell dictionary accepts trailing junk in numeric COMPOUNDFLAG |