On Tue, 20 Aug 2002 15:22, Neil Conway wrote:
> 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.
Agreed - different issues, similar argument. They should be fixed, I just
don't think its a sky is falling type problem. Not saying you said I was
(*grin*), just that a competent network administrator has taken steps to
secure the database over and above that expected of the developers.
> 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.
Definitely, and I wish I had some to spend on Postgres! Time that is :)
As you noted, most of the issues are in contrib - obviously due to the
skills/knowledge of the core team and the strength of the development model.
However, if the quality of programmers in the market is anything to go by, I
don't hold out for the future unless Postgres is rewritten in something that
holds hands as well as Java :)
Cheers
Mark