Le 03/04/2013 02:43, Jonathan S. Katz a écrit :
> On Apr 2, 2013, at 8:14 PM, Jonathan S. Katz wrote:
>
>> On Apr 2, 2013, at 8:03 PM, Selena Deckelmann wrote:
>>
>>> I agree that we should have a well-documented security release
>>> process. There are existing processes documented that we might use as
>>> a starting point, and I personally think largely match what we
>>> currently do, like:
>>> https://docs.djangoproject.com/en/1.5/internals/security/
>>
>> The Django security release guide is good - I think we could almost
>> copy & paste it. I could throw something up on our wiki where we can
>> fill in the blanks on what we want the actually policy to be and allow
>> people to comment + add modifications.
>
> Here is a wiki I through together combining elements of both our current
> security page and thoughts from the Django one:
>
> https://wiki.postgresql.org/wiki/PostgreSQL_Security_Release_Policy_Draft
>
> I separated between our current policy and the draft. The draft really
> needs some blanks to be filled in.
>
Thanks for this draft, it's an improvement !
Here's a few comments :
A/ I think the names of "The Packagers List" should be public. I think
it's an important infomation when you choose a distibution system or a
service provider. One should be able to check if a package/service
provider is connected to the Security Team or not.
B/ I feel that all "Packagers" should respect the "embargo date". They
should not produce the packages prior to the official realease. This is
what RPM and DEB packagers do and it's a good thing. Once again the
problem is not that Heroku had early access to the security fix. The
problem is that they "released" it 3 days before others packagers. I
don't know if they did that on purpose but the message they are sending
is "Heroku Postgres is more secure than vanilla PostgreSQL, because you
get upgrades before full disclosure"
C/ The Packagers list could be extended to companies providing
PostgreSQL support. If the term "Packagers" include not only
organizations that distribute the code but also organizations that
provide PostgreSQL as a services, then PostgreSQL Support services
should be included too.
If you produce binaries you're not supposed to make them accessible
prior to the embargo date.
