Re: [pgsql-advocacy] MySQL worm attacks Windows servers

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: [pgsql-advocacy] MySQL worm attacks Windows servers
Дата
Msg-id 87brb6seke.fsf@stark.xeocode.com
обсуждение исходный текст
Ответ на Re: [pgsql-advocacy] MySQL worm attacks Windows servers  (Dawid Kuroczko <qnex42@gmail.com>)
Ответы Re: [pgsql-advocacy] MySQL worm attacks Windows servers
Список pgsql-general
Dawid Kuroczko <qnex42@gmail.com> writes:

> > Why only -core?
>
> I think it is in good taste that when you find a bug/vulnerability/etc
> first you contact the author (in this case: core), leave them some
> time to fix the problem and then go on announcing it to the
> world.
>
> I think it is perfectly reasonable!

In case there are some that are not aware, this is a matter of some
controversy. Many people believe it better to disclose vulnerabilities
publicly.

There are always ways for a sysadmin to close the vulnerability, even if it
means temporarily limiting access until the fix is available. How would you
like to be a sysadmin that finds his system exploited only to discover that
the vulnerability was known and he could have worked around it had he been
informed but those in the know kept it secret until a patch was published.

The only way keeping it secret is really justified is if a) You know no
malicious persons are aware of the vulnerability (which of course one never
really knows for certain) b) it's more reasonable for a sysadmin to run with
the vulnerability than to work around it using whatever means necessary (and
you feel comfortable making that decision for every sysadmin everywhere).

There are certainly others that disagree but I think history shows that when
vulnerabilities are disclosed in full sysadmins can react more effectively and
vendors release fixes faster and the net result is fewer compromises and
better software.

Of course in this case the argument that Postgres would have responded quicker
had the vulnerability been known is almost certainly baseless. And it may turn
out to be the case that there were no compromises because not a single
malicious user knew about the hole. It doesn't always work out that way
though.

--
greg

В списке pgsql-general по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: example for read committed/volitile functions
Следующее
От: elein@varlena.com (elein)
Дата:
Сообщение: Re: example for read committed/volitile functions