[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20121024085501.GM13184@symphytum.spacehopper.org>
Date: Wed, 24 Oct 2012 09:55:01 +0100
From: Stuart Henderson <stu@...cehopper.org>
To: oss-security@...ts.openwall.com
Cc: Kurt Seifried <kseifried@...hat.com>,
Hanno Böck <hanno@...eck.de>
Subject: Re: CVE request: XSS in piwik before 1.9
On 2012/10/24 11:12, Matthieu Aubry wrote:
> We disagree that giving out exploits and more info about the hacks, will
> help security and our users : it will NOT.
Exploits, I agree. But more information will let people make a decision
as to whether they're vulnerable, and how much pain it's worth going
through to either upgrade to a fixed version or backport the fix.
> Supporting researchers to find security bugs in open source projects,
> however has helped us a lot: http://piwik.org/security/
So this page has a link, "You can see the previous Security issues in Piwik"
pointing at http://piwik.org/blog/category/security/. The last entry on here
referring to an issue with piwik itself is from June 2011, but 4 releases
since then have included security fixes, several of them rated "critical"
on the changelog page. I wonder if it might be better to just refer to
the changelog if the separate page can't be kept updated?
Unfortunately many of the releases with security fixes coincide with
warnings like "This new version contains database schema changes so
please be careful when running the Update script", anything more than
complicated than "update the installed files" is going to restrict
the number of users who keep up-to-date with security fixes.
In particular some OS distributions package piwik; if they would like
to fix the problems in a stable release (where it's not possible to
force schema changes etc), with the current process each different
OS packaging piwik would need to isolate the diff themselves and
hope they include all needed parts,
As a packager I don't necessarily think an upstream project needs to
continually maintain security fixes for old releases, but at least
posting information about the actual bugs fixed with a reference
to the commit/s would make life a lot easier for the people who
help many of your users stay on top of security fixes.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
