Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in - Mailing list pgsql-hackers

From Greg Copeland
Subject Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Date
Msg-id 1029942047.10063.35.camel@mouse.copelandconsulting.net
Whole thread Raw
In response to Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in  (Mark Pritchard <mark@tangent.net.au>)
List pgsql-hackers
On Tue, 2002-08-20 at 18:40, Mark Pritchard wrote:
> On Tue, 20 Aug 2002 23:48, Greg Copeland wrote:
> > On Tue, 2002-08-20 at 00:35, Dann Corbit wrote:
> > > Most computer virus problems are caused by buffer overrun.  Someone
> > > decided it wasn't very important.
> >
> > This is true.  IMO, it is extremely arrogant to ignore a buffer overrun
> > and announce it can't be exploited.  There is many cases where this
> > assertion has been proved to be false.  The real risk of overrun is not
>
> I would certainly hope you are not misquoting me here. I have never stated we
> should ignore the bug. I suggested that with proper network level protection,
> the bug should not be exploitable.

Don't think I quoted you at all.  I don't see quotation marks and am
including Dan's remark.  Perhaps everyone isn't talking about you after
all.  Continue with the green pills.  ;)

> do disagree with is the "panic" mentality that seems so evident in this type
> of post.

Hmmm.  Interesting.  I didn't see panic or anything alarmist in my post.

>
>
> > IMO, if you don't embrace that rule of thumb, a developer shouldn't be
> > working on a project where stability and reliability are key components
> > of the end product.
>
> I wasn't aware that PostgreSQL as an open source collaborative project had any
> specific requirements of upon it at all. While stability and reliability are
> obvious goals, if you feel the project does not meet your needs you are more
> than welcome to try one of the alternatives. MySQL for example :)

In other words, if someone if verbal about development goals or
objectives they should go elsewhere.

As for specific requirements, I've said nothing which are not inherently
obvious.  Without a stable and reliable product, no one is going to use
it for serious work.  As such, it's certainly not a leap of faith to
assume that developers without such ideals in mind should be shunned or
properly guided.  Why?  Obviously (amazed I have to spell this out),
said developer efforts would be counter to the project's objectives
(stated or otherwise implicitly obvious).

You also seem to imply that "open source collaborative project[s]"
should not aim for high goals.  I think it's safe to say, we disagree.

> I'm not going to restate my previous response to this view, but I will ask,
> who is affected by the "horribly irresponsible" approach? If it is you, then
> why hasn't your due dilligence process audited the code? Perhaps you would
> feel more comfortable with one of the closed source/closed development model
> organisations? But what bugs lie within the depths of DBs such as SQL Server?
> How will you audit those? Or will you just trust the sales guy?

Hmm.  Keep a blind and pretend it doesn't exist.  Not a good response.
Since this thread came out of someone's dilligence (coders or
otherwise), I fail to see the significance of your comments.  After all,
mucho-peer review is supposed to be one of the perks of using OSS
software.  Considering I'm not asserted I'm performance a code audit,
this seems completely unrelated to the topic at hand.

> Where is an expectation at all? If you want to use PostgreSQL, then use it. If
> it doesn't meet your needs, don't use it, or start fixing the issues
> yourself. If you can't do it, buy Oracle, or DB2, or whatever else.

In other words, if someone if verbal about development goals they should
go elsewhere.  Furthermore, you seem to assert that only the core
developers should be using this database.  Wow, I'm amazed.  Just
because someone does or does not contributes code doesn't suddenly
invalidate observations.  That, of course, doesn't mean the observations
have to be valid.

Simply stated, if it meets my needs, shut-up and use it.  If it doesn't,
go elsewhere.  Bad attitude.

> I'm not sure how you make the jump from knowing that an issue exists and
> allowing people to exploit it, to the inference that core developers are
> turning a blind eye to it. Forgive me if I misquote you Tom, but I don't
> think he has ever said "we should not fix this bug", simply that the effort
> is significant, and there are other factors to consider.

Because it was stated that these are known issues.  Because it was
stated these have been known issues for a very long time.  Because it
was stated that, more or less, no one is excited about doing the lots of
effort which is seemingly required to put some of these issues to bed.

The expression, "turning a blind eye", means that something is being
ignored.  It means it won't be focused on for now.  That does not have
to mean forever.  The statement is valid and supported by pretty much
every posting on this list on the topic at hand.  I stand by my
statement.

Stop with the misquoting comments already.  The quotes I used were
properly attributed.   Believe it or not, everyone is not talking about
you or trying to place words in your mouth.  Believe it or not, the
quotes are correct.  I have no idea what you're talking about.

> Perhaps we need a pgsql-hackers-heated_discussions list so we can take these
> discussions offline? :)
>

I'm concerned that you feel comments on corporate culture should be
considered a heated discussion.  I in no way, shape or form, asserted
anything other then perhaps there is a cultural emphasis behind the
marketing ploy.  You can say no and I can say maybe all day long.
Either way, that's hardly heated.

Somewhere around here, we've wondered from the road.

Regards,
Greg Copeland


pgsql-hackers by date:

Previous
From: Sir Mordred The Traitor
Date:
Subject: @(#)Mordred Labs advisory 0x0002: Buffer overflow in PostgreSQL
Next
From: Lamar Owen
Date:
Subject: Re: i'll promise, i'll be polite :-)