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

From Greg Stark
Subject Re: [pgsql-advocacy] MySQL worm attacks Windows servers
Date
Msg-id 87brb6seke.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: [pgsql-advocacy] MySQL worm attacks Windows servers  (Dawid Kuroczko <qnex42@gmail.com>)
Responses Re: [pgsql-advocacy] MySQL worm attacks Windows servers
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: example for read committed/volitile functions
Next
From: elein@varlena.com (elein)
Date:
Subject: Re: example for read committed/volitile functions