Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
От | Neil Conway |
---|---|
Тема | Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in |
Дата | |
Msg-id | 87vg66je9q.fsf@mailbox.samurai.com обсуждение исходный текст |
Ответ на | Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in (Mark Pritchard <mark@tangent.net.au>) |
Ответы |
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
|
Список | pgsql-hackers |
Mark Pritchard <mark@tangent.net.au> writes: > I believe its been said before, in this forum no less, that > PostgreSQL should focus on its primary role as an RDBMS and not be > paranoid about security. I believe it was the thread on SSL > connections, and Tom suggested a simple ssh tunnel or vpn. I'd say the two issues are pretty different. IMHO, buffer overruns and similar security problems are just a special class of software bug (it's interesting to note that most of the buffer overruns have been found in the less-maintained parts of the system, like the cash type or contrib/). Therefore, the justification for fixing buffer overruns (and avoiding them in the first place) is the same as for fixing other kinds of bugs: it makes the system more reliable. On the other hand, adding something like SSL tends to make the system more complex (and therefore *less* reliable). There may or may not be a pay-off from a user's POV, but it's not the clear win that avoiding buffer overruns is, IMHO. > Of course, lets not leave the door wide open, but perhaps the > developer's time would be better spent on features such as schemas > and replication. It's probably worth noting that the "barrier to entry" for fixing buffer overruns or doing a code audit is much, much lower than for implementing advanced features like schemas or replication. The main thing that auditing code requires is time, rather than coding skill/knowledge. Cheers, Neil -- Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
В списке pgsql-hackers по дате отправления: