Thread: Purge obsolete security updates?
WWW, http://www.postgresql.org/support/security ... currently has security patch information going back to 2004. I'd like to cut everything which only applies through version 8.0 as obsolete. This would mean cutting all notices starting with CVE-2006-0678. Further, I'd like to make a general policy that we cut security information from this page a year after the last referenced version goes EOL (e.g. we'd delete CVE-2006-5542 this November). -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com
On Mon, Jan 31, 2011 at 6:11 PM, Josh Berkus <josh@agliodbs.com> wrote: > WWW, > > http://www.postgresql.org/support/security > > ... currently has security patch information going back to 2004. I'd > like to cut everything which only applies through version 8.0 as > obsolete. This would mean cutting all notices starting with > CVE-2006-0678. Well there are two notices prior to that that apply to 8.1. > Further, I'd like to make a general policy that we cut security > information from this page a year after the last referenced version goes > EOL (e.g. we'd delete CVE-2006-5542 this November). Will the information still be archived someplace if someone needs it? I might be more inclined to move it to a separate page than to nuke it completely. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
>> ... currently has security patch information going back to 2004. I'd
>> like to cut everything which only applies through version 8.0 as
>> obsolete. This would mean cutting all notices starting with
>> CVE-2006-0678.
>
> Well there are two notices prior to that that apply to 8.1.
Oh, yeah, well spotted. Those two would be untouched.
> Will the information still be archived someplace if someone needs it?
The release notes will still be available.
> I might be more inclined to move it to a separate page than to nuke it
> completely.
Why? What's the point in keeping it around?
-- -- Josh Berkus PostgreSQL Experts Inc.
http://www.pgexperts.com
Josh Berkus <josh@agliodbs.com> writes:
> ... currently has security patch information going back to 2004. I'd
> like to cut everything which only applies through version 8.0 as
> obsolete. This would mean cutting all notices starting with
> CVE-2006-0678.
> Further, I'd like to make a general policy that we cut security
> information from this page a year after the last referenced version goes
> EOL (e.g. we'd delete CVE-2006-5542 this November).
-1 on both. The fact that we're not releasing new updates for old
versions is miles away from suppressing information about them.
Furthermore, having those notices up there might help to spur people to
update off those versions, which is what we really want. If we remove
all the old notices it is likely to leave the impression "hey, 7.4 is
much more bug-free than the newer versions, so I should stay on it".
If anything, I'd like to see us *add* the older versions to the newer
notices when relevant. We want people to realize that these holes exist
and are unfixed in old branches, not think they're secure.
regards, tom lane
On Tue, Feb 1, 2011 at 01:08, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Josh Berkus <josh@agliodbs.com> writes: >> ... currently has security patch information going back to 2004. I'd >> like to cut everything which only applies through version 8.0 as >> obsolete. This would mean cutting all notices starting with >> CVE-2006-0678. > >> Further, I'd like to make a general policy that we cut security >> information from this page a year after the last referenced version goes >> EOL (e.g. we'd delete CVE-2006-5542 this November). > > -1 on both. The fact that we're not releasing new updates for old > versions is miles away from suppressing information about them. > Furthermore, having those notices up there might help to spur people to > update off those versions, which is what we really want. If we remove > all the old notices it is likely to leave the impression "hey, 7.4 is > much more bug-free than the newer versions, so I should stay on it". > > If anything, I'd like to see us *add* the older versions to the newer > notices when relevant. We want people to realize that these holes exist > and are unfixed in old branches, not think they're secure. Agreed. However, moving them to a separate page and put a prominent note saying "security advisories for no-longer supported releases are archived here" or something like that seems like a reasonable compromise. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Mon, Jan 31, 2011 at 7:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Josh Berkus <josh@agliodbs.com> writes: >> ... currently has security patch information going back to 2004. I'd >> like to cut everything which only applies through version 8.0 as >> obsolete. This would mean cutting all notices starting with >> CVE-2006-0678. > >> Further, I'd like to make a general policy that we cut security >> information from this page a year after the last referenced version goes >> EOL (e.g. we'd delete CVE-2006-5542 this November). > > -1 on both. The fact that we're not releasing new updates for old > versions is miles away from suppressing information about them. > Furthermore, having those notices up there might help to spur people to > update off those versions, which is what we really want. If we remove > all the old notices it is likely to leave the impression "hey, 7.4 is > much more bug-free than the newer versions, so I should stay on it". This was actually my first reaction, too. But I got shouted down the last time I argued for keeping something around for longer, so I softened it before sending. I don't really see the benefit of removing information from this page. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Magnus Hagander <magnus@hagander.net> writes:
> On Tue, Feb 1, 2011 at 01:08, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> If anything, I'd like to see us *add* the older versions to the newer
>> notices when relevant. �We want people to realize that these holes exist
>> and are unfixed in old branches, not think they're secure.
> Agreed. However, moving them to a separate page and put a prominent
> note saying "security advisories for no-longer supported releases are
> archived here" or something like that seems like a reasonable
> compromise.
Sure, that'd be fine.
regards, tom lane
On Mon, Jan 31, 2011 at 03:52:03PM -0800, Josh Berkus wrote: > > >> ... currently has security patch information going back to 2004. > >> I'd like to cut everything which only applies through version 8.0 > >> as obsolete. This would mean cutting all notices starting with > >> CVE-2006-0678. > > > > Well there are two notices prior to that that apply to 8.1. > > Oh, yeah, well spotted. Those two would be untouched. > > > Will the information still be archived someplace if someone needs > > it? > > The release notes will still be available. > > > I might be more inclined to move it to a separate page than to > > nuke it completely. > > Why? What's the point in keeping it around? The *act* of removing it is the one we want to avoid even the appearance of doing. It's an affirmative act, and one that could make us look very bad. Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
>> Agreed. However, moving them to a separate page and put a prominent
>> note saying "security advisories for no-longer supported releases are
>> archived here" or something like that seems like a reasonable
>> compromise.
>
> Sure, that'd be fine.
Suggested text:
"Security advisories below cover only currently supported versions. For
security advisories which specifically affect versions no longer
supported by the community, see the list here<link>. Please note that
obsolete versions are certainly affected by some of the security issues
below but there are no updates available for them. For more information
about the community support term, see <link>"
And on the archive page itself (support/security_archive.html?)
"Below are security advisories which only affect older versions of
PostgreSQL which are no longer supported by the community. Note that
these releases are also affected by some of the security advisories on
the current security advisories page<link> but are not patched. For
more information about the community support term, see <link>"
-- -- Josh Berkus PostgreSQL Experts Inc.
http://www.pgexperts.com