Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
От | Tom Lane |
---|---|
Тема | Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in |
Дата | |
Msg-id | 13493.1029860138@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in (Lamar Owen <lamar.owen@wgcr.org>) |
Ответы |
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in |
Список | pgsql-hackers |
Lamar Owen <lamar.owen@wgcr.org> writes: > Umm, but what about the reply buffer overrun advisory? I've read this whole > thread, and the reply advisory (AFAICT, unless I've just hit delete too > quickly) has NOT been addressed. Yes it has. CVS logs show 2002-08-04 02:44 thomas * src/backend/utils/adt/: date.c, datetime.c, format_type.c,nabstime.c, timestamp.c, varlena.c: Add guard code to protectfrombuffer overruns on long date/time input strings. [othercomments pruned, but note this commit did a lot of otherstuff too] The original argument was about whether we should push out a 7.2.2 release just because of this fix. AFAIK no one has even troubled to look at the patch and see whether it applies directly to the 7.2 branch; Thomas has revised the date/time code quite a bit since 7.2, so I'd expect that it's not going to apply exactly. I'd put more stock in the concern level of the people making complaints if anyone had bothered to do even that much legwork. Without an offered patch against 7.2 branch, I don't think the folks who push out releases (which is not me, but Marc, Bruce, you, Trond, etc) should bother to take notice of the complaints at all. regards, tom lane
В списке pgsql-hackers по дате отправления: