Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in

Поиск
Список
Период
Сортировка
От Nigel J. Andrews
Тема Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Дата
Msg-id Pine.LNX.4.21.0208201539200.1042-100000@ponder.fairway2k.co.uk
обсуждение исходный текст
Ответ на Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Список pgsql-hackers
On Tue, 20 Aug 2002, Tom Lane wrote:

> "Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:
> >> I'd like to see something done about this fairly soon, but it's not
> >> happening for 7.3 ...
> 
> > Does anyone have an idea about what other functions are affected by this?
> 
> As a first approximation, every output function for a built-in
> pass-by-reference datatype will show this same behavior.  cash_out is
> just getting picked on because it was the one mentioned in the first
> complaint.  For that matter, every input function for any datatype
> has the same problem:
>     regression=# select cash_in(2);
>     server closed the connection unexpectedly
>
> ...

But going back to the idea that it seems that the only problem being publicised
in the 'outside world' is the cash_out(2) version can we not do the restriction
on acceptable input type in order to claim that the fix?

Obviously this is only a marketing ploy but on the basis that a real fix seems
unlikely before beta in 11 days time (I'm still trying to work out what Tom's
suggestion is) perhaps one worth implementing.

-- 
Nigel J. Andrews
Director

---
Logictree Systems Limited
Computer Consultants



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Следующее
От: Michael Meskes
Дата:
Сообщение: Re: bison news