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: