From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Selena Deckelmann <selena(at)chesnok(dot)com> |
Cc: | "Jonathan S(dot) Katz" <jonathan(dot)katz(at)excoventures(dot)com>, 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-09 17:54:08 |
Message-ID: | 20130409175408.GT4361@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-advocacy |
All,
* Selena Deckelmann (selena(at)chesnok(dot)com) wrote:
> On Tue, Apr 2, 2013 at 4:42 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > Having some kind of documentation / policy regarding who can get access,
> > or what they have to do to get access, would certainly help address
> > these concerns.
>
> This is a key point.
Here's what I've been kicking around for a general plan (though -advocacy
still seems like an odd place to discuss this, but whatever):
Tiered release-
First to people who can FIX the problem, eg: -security
Second to people who maintain things downstream:
This would include both packagers for major distros and large-scale
DBaaS environments; approved by -core or a similar committee.
Public notification of a general release to be forthcoming.
Third to the general public as binaries/packages
Lastly, full disclosure, sources, etc.
This would only apply in cases where there is no known exploit and the
bug is not generally known, and perhaps only for major bugs.
Ideally, we would be able to minimize impact from this process on the
developers, perhaps through an independent/security repo or similar.
Anyway, that's my 2c.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2013-04-09 17:59:29 | Re: Heroku early upgrade is raising serious questions |
Previous Message | Andres Freund | 2013-04-09 17:50:24 | Re: Heroku early upgrade is raising serious questions |