Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
От | ngpg@grymmjack.com |
---|---|
Тема | Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in |
Дата | |
Msg-id | Xns9270D553A54E49wn7t0983uom3iu23n@64.49.215.80 обсуждение исходный текст |
Ответ на | Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in (Greg Copeland <greg@CopelandConsulting.Net>) |
Ответы |
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
|
Список | pgsql-hackers |
greg@CopelandConsulting.Net (Greg Copeland) wrote > 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.=20 > That is, they are the ones that allowing people to do it in the first > place. In short, every time I see that response, I immediately think, > "...now that's the pot calling the kettle black." > > At some point in time, you have to stand and say, "the buck stops here." > I agree here, but at the same time you cannot put 100% of the responsibility on the developers. If you are the dba/sysadmin/whatever/etc then it is your responsibility. It is up to you to know about potential problems and have workarounds or whatever it is you need to do. I think that is one of the things that seperates a "good" admin from a "not-so- good" one. Afterall, when your boss calls you into his office monday morning and asks for a really good explanation for why the db was cracked, I dont think he is going to accept the excuse "this guy, you dont know him but his name is tom lane.. well anyway, he didnt fix this bug i knew about so i didnt do nothing about it because i shouldnt have to because that would be like the pot calling the kettle black" That being said, I do agree the developers should give things like this more priority. But, its open source... so you either live with it or write your own patch.
В списке pgsql-hackers по дате отправления: