From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Joe Conway <mail(at)joeconway(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: can we mark upper/lower/textlike functions leakproof? |
Date: | 2024-07-31 18:03:46 |
Message-ID: | 3416373.1722449026@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> If there are some inputs that cause upper() and lower() to fail and
> others that do not, the functions aren't leakproof, because an
> attacker can extract information about values that they can't see by
> feeding those values into these functions and seeing whether they get
> a failure or not.
> [ rather exhaustive analysis redacted ]
> So in summary, I think upper() is ... pretty close to leakproof. But
> if ICU sometimes fails on certain strings, then it isn't. And if the
> multi-byte libc path can be made to fail reliably either with really
> long strings or with certain choices of the LC_CTYPE locale, then it
> isn't.
The problem here is that marking these functions leakproof is a
promise about a *whole bunch* of code, much of it not under our
control; worse, there's no reason to think all that code is stable.
A large fraction of it didn't even exist a few versions ago.
Even if we could convince ourselves that the possible issues Robert
mentions aren't real at the moment, I think marking these leakproof
is mighty risky. It's unlikely we'd remember to revisit the marking
the next time someone drops a bunch of new code in here.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Christophe Pettus | 2024-07-31 18:07:39 | Re: CI, macports, darwin version problems |
Previous Message | Christophe Pettus | 2024-07-31 17:55:33 | Re: CI, macports, darwin version problems |