Re: Heroku early upgrade is raising serious questions - Mailing list pgsql-advocacy
From | Jonathan S. Katz |
---|---|
Subject | Re: Heroku early upgrade is raising serious questions |
Date | |
Msg-id | 6A89CDBE-20D4-4312-BD59-8389308157C2@excoventures.com Whole thread Raw |
In response to | Re: Heroku early upgrade is raising serious questions (damien clochard <damien@dalibo.info>) |
Responses |
Re: Heroku early upgrade is raising serious
questions
Re: Heroku early upgrade is raising serious questions |
List | 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 by date: