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 | 54BB6DF7-22F2-406D-B092-253D9716E50C@excoventures.com Whole thread Raw |
In response to | Re: Heroku early upgrade is raising serious questions (Josh Berkus <josh@agliodbs.com>) |
Responses |
Re: Heroku early upgrade is raising serious questions
Re: Heroku early upgrade is raising serious questions |
List | pgsql-advocacy |
On Apr 3, 2013, at 1:46 PM, Josh Berkus wrote:
My one question regarding policy is related to distribution. I doagree with the evaluation criteria for choosing distributors, but myquestion pertains to entities that could be classified as "criticalinfrastructure" that use Postgres, e.g. utilities, hospitals, etc.Though it is still up to the management of those entities to handlethe upgrades, I think it would be in their best interests to have acritical security fix available to them so they have that opportunitybefore it goes live.I also presume that these organizations receive their releases fromdistributors - so if we were to enable such organizations to alsoreceive an early release, what would the policy be?
There's a whole set of questions regarding early access to security
updates which we're not yet ready to tackle, and may never be ready to
tackle. This includes:
- large commercial support vendors (e.g. SRA)
- distributors of embedded Postgres (on devices) (e.g. Apple)
- critical infrastructure users (e.g. the FAA)
- large-scale end users with high security profiles (e.g. Enova)
All of the above have legitimate, and sometimes compelling, reasons to
need to be able to apply security updates in advance of them becoming
public. Deciding who gets to be on an early notification list and who
doesn't, while keeping the list small enough to not effectively make
things public, will be very hard and potentially impossible. And
ultimately we are a non-profit, volunteer project and can't devote 100
full time staff to managing security disclosure the way Microsoft can.
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)
Josh - I think your points are valid concerning the vetting of who would be included in early releases. I believe the best way to address who would be on that list is having a committee to vet those applications - I believe that is similar to how other OSS communities handle it. I do not think the amount of submissions for requesting early access would be so great that we would need a full-time team to maintain it, and I think most of us have a good idea already about which types of organizations truly would need an early access release.
With that said, if there are no overwhelming objections over the next 36 hours, I can submit a patch to our security policy on the website using the language that is in the wiki above.
Jonathan
pgsql-advocacy by date: