Re: Heroku early upgrade is raising serious questions

Поиск
Список
Период
Сортировка
От Jonathan S. Katz
Тема Re: Heroku early upgrade is raising serious questions
Дата
Msg-id 6A89CDBE-20D4-4312-BD59-8389308157C2@excoventures.com
обсуждение исходный текст
Ответ на Re: Heroku early upgrade is raising serious questions  (damien clochard <damien@dalibo.info>)
Ответы Re: Heroku early upgrade is raising serious questions  (Bruce Momjian <bruce@momjian.us>)
Re: Heroku early upgrade is raising serious questions  (Michael Meskes <meskes@postgresql.org>)
Список pgsql-advocacy
On Apr 8, 2013, at 5:27 PM, damien clochard wrote:

>> Now that a few days have passed, I'd like to revisit this before too
>> much time lapses.
>>
>> (The link again for the security policy
>> draft: https://wiki.postgresql.org/wiki/PostgreSQL_Security_Release_Policy_Draft)
>>
>
> Now I understand that Heroku (and other DBaaS providers) may host
> hundreds of thousand PostgreSQL servers and I understand that upgrading
> so many servers in a few hours is something very hard to acheive. But
> the responsability of building a security maintenance process like that
> is on Heroku (and other DBaaS providers). The PostgreSQL community
> should keep some neutrality and should not compensate the lack of
> upgrade machinery of a private company. Even if that means thousand of
> their customers will be exposed for a while.

I do not entirely agree with this.  Applications that run as critical infrastructure (examples again: hospitals,
utilities,etc.) should be permitted early access to releases - as a community, we would not want to expose critical
infrastructureto unnecessary risk while there is a fix available prior to public disclosure of a bug.  I think most
peoplehave good judgment and understanding that certain groups should have early access to a potentially dangerous
softwareissue as it could end up causing much larger issues should the software be exploited.  I think if we as a
communitycommunicate this message well, the people who have issues with some groups having early access would be
minimal.

In this specific case, DBaaS providers were exposed to a bug that is relatively easy to exploit with potentially dire
consequencesthat could potentially ruin many, many businesses (I do not want to give a bad estimate, so I won't provide
anumber).  Let's say this horrible scenario happened: sure, people could say that a DBaaS provider did not adequately
securetheir system, but fingers could also be pointed at the community for a) having a security hole in the first place
(asludicrous as that sounds to us as we know that software is flawed AND Postgres has an *excellent* track record for
security)and b) not recognizing the damage that could be caused by not permitting systems considered to be "critical
infrastructure"early access to a fix. 

In an ideal world - yes - everyone should have access to critical security bugfixes at identical times.  However, due
tothe sensitivity of certain systems (I do not think any of us would want to see a hospital's system go down due to a
securityexploit), there does need to be an early access list.  The way keep it fair for that is to have a committee of
variousPGDG members with different backgrounds to review applications and vote to decide who should have early access
(whereaccess is not even necessarily the source - access could even be just to the binaries).  I know one of the goals
isto keep that list small, and I do agree with that, but more importantly, there should be guidelines on how to
maintainmembership to that list. 

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

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Re: Heroku early upgrade is raising serious questions
Следующее
От: Matteo Beccati
Дата:
Сообщение: Re: elephant logo in OFM format?