Re: Heroku early upgrade is raising serious questions

From: "Jonathan S(dot) Katz" <jonathan(dot)katz(at)excoventures(dot)com>
To: damien clochard <damien(at)dalibo(dot)info>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL Advocacy <pgsql-advocacy(at)postgresql(dot)org>
Subject: Re: Heroku early upgrade is raising serious questions
Date: 2013-04-08 22:58:57
Message-ID: 6A89CDBE-20D4-4312-BD59-8389308157C2@excoventures.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 infrastructure to unnecessary risk while there is a fix available prior to public disclosure of a bug. I think most people have good judgment and understanding that certain groups should have early access to a potentially dangerous software issue as it could end up causing much larger issues should the software be exploited. I think if we as a community communicate 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 consequences that could potentially ruin many, many businesses (I do not want to give a bad estimate, so I won't provide a number). Let's say this horrible scenario happened: sure, people could say that a DBaaS provider did not adequately secure their system, but fingers could also be pointed at the community for a) having a security hole in the first place (as ludicrous 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 to the sensitivity of certain systems (I do not think any of us would want to see a hospital's system go down due to a security exploit), there does need to be an early access list. The way keep it fair for that is to have a committee of various PGDG members with different backgrounds to review applications and vote to decide who should have early access (where access is not even necessarily the source - access could even be just to the binaries). I know one of the goals is to keep that list small, and I do agree with that, but more importantly, there should be guidelines on how to maintain membership to that list.

In response to

Responses

Browse pgsql-advocacy by date

  From Date Subject
Next Message Matteo Beccati 2013-04-08 22:59:12 Re: elephant logo in OFM format?
Previous Message Tatsuo Ishii 2013-04-08 22:39:01 Re: Heroku early upgrade is raising serious questions