>
> 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)
>
Jonathan,
Thanks for this page again !
I would like to add a paragraph about the release date (or "embargo
date"). It seems important to me that all packagers agree to synchronize
and distribute/deploy the security fix at the same date. For packager
who distribute the source code this is obvious. But that's also true for
DBaaS providers.
The Heroku announcement caused many confusions. The worst confusion is
that it sounds like Heroku gets a special treament and is allowed to
upgrade 3 days before full disclosure, while the rest of us have to wait
the official release date.
So basically the message we're sending is : Heroku Postgres is safer
than Vanilla PostgreSQL because in case of an high-exposure security
vulnerability, Heroku will upgrade before everyone else.
BTW you can replace Heroku by the DBaaS provider of your choice... I
have nothing against Heroku and I have great respect for the
contribution to our community.
I'm taking them as an exemple, because they've been very transparent
about all this (see
https://blog.heroku.com/archives/2013/4/4/heroku_postgres_databases_patched)
and that's a good thing because it helps us improving our Security
Release Policy.
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.
