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. If you did indeed misquote me, perhaps extreme arrogance in this case is the attribution of comments to people without basis? > I agree with that too. When setting priorities, using a scale of 1-10, > 10 being highest priority, anything that effects stability or > reliability should always be a 10. As such, they should always be > repaired even above new wiz-bang features. So, cutting through the self-supporting hyperbole, you believe that stability or reliability is more important than new features. I don't disagree. What I do disagree with is the "panic" mentality that seems so evident in this type of post. If you have set up your production infrastructure in a sensible manner (of course sensible is open for interpretation), this bug does not affect you. This does highlight the root cause of our difference in opinions - I don't feel this is an issue because it doesn't affect me. You may be concerned by these issues because your infrastructure allows the general 'net using public to directly access your database. While I disagree with this configuration...it doesn't make you fundamentely wrong, simply different in our respective approaches. > 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 :) Seriously though, its similar to the people who run Linus' kernels. Oh my god they say, the stable 2.4.x series has VM issues. We can't trust it anymore! Why are you using that kernel in the first place? Where has Linus said that this is suitable for production use? Stable does not mean "production ready". > > potential overruns should be identified. A grep for memcpy, strcpy, > > gets, etc. should hunt down most of them. A known buffer overrun should > > fill the designer of a product with abject terror. And I really mean > > Agreed. It is horribly irresponsible to thumb a nose at such things in > this day and age. 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? > > programmers, but I am thinking of the damage that can be inflicted upon > > potential clients using the database. > > Not a question of it sounding negligent. It is negligent. > > If quality and stability is not the core developers #1 goal then > expecting people to trust the resulting product is laughable. Please 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. > Time and time again I've read what basically amounts to, "...if someone > can crash it it's because someone is stupid enough to allow someone to > be able to do it in the first place..." Maybe you're right. After all, > if core developers continue to turn a blind eye to such issues, they are > in fact, the facilitators of allowing people to do it to begin with. 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. > You know, I've seen many people trash Oracle's "unbreakable" mantra. > I'm sure no one is confused at the fact that it is nothing but a > marketing ploy, however, perhaps there is a culture behind it. Perhaps > this is their way of saying stability and reliability is very important > to them. Perhaps their mantra is the rule of thumb outlined above. Perhaps we need a pgsql-hackers-heated_discussions list so we can take these discussions offline? :) Cheers Mark ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
