Re: char 0x00
От | Dave Cramer |
---|---|
Тема | Re: char 0x00 |
Дата | |
Msg-id | CADK3HHLT4mAq_09asP1r0E66+3cf8q-+V2X27Le0NPmWbC-hrg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: char 0x00 (Brett Okken <brett.okken.os@gmail.com>) |
Список | pgsql-docs |
We don't have to make it consumable. If we can use his code and reproduce it in the JDBC driver that is enough.
Dave Cramer
On Sat, 28 Mar 2020 at 11:31, Brett Okken <brett.okken.os@gmail.com> wrote:
Dave, any thoughts on best way to reproduce Vladimir’s described workflow in a way that is consumable by the postgresql team?On Thu, Mar 26, 2020 at 10:21 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:Brett Okken <brett.okken.os@gmail.com> writes:
> Using a client and server encoding of SQL_ASCII makes it possible to get
> 0x00 into a text value column when using a bind variable.
Having looked at the code again, I flat out don't believe you.
textin is certainly not going to read past a nul character,
and textrecv goes through pg_client_to_server (via pq_getmsgtext),
which AFAICS is careful in all code paths to reject nuls.
If I'm missing something, I'd really like to see a concrete example,
because this would be a bug, and it'd suggest that somebody's managed
to reopen CVE-2006-2313. If we're missing nul rejection in some code
path, then we're probably not doing encoding validation at all.
regards, tom lane
В списке pgsql-docs по дате отправления: