Hello, I would like to know if there is any policy about security bug fixes, updates or releases. What I'm talking about. Consider a security related bug discovered in boost library. For example: For example recently reported bug in Boost.Locale that will be fixed in 1.53 https://svn.boost.org/trac/boost/ticket/7743 I consider it security bug as an application that validates the input (checks if it is UTF-8) may accept an invalid sequence. Or very critical bug in UUID (fixed in 1.43): https://svn.boost.org/trac/boost/ticket/3971 That any application that used them may be target to UUID guessing. These kind of bugs in general should be considered critical and somehow published, it may be also important to backport the fixes to stable releases, because not everybody can move forward and they may need to stick with older releases (as Boost is neither ABI nor API backward compatible even between minor releases). Annoucements of such bugs may be critical for example for stable Linux distributions that ship some older Boost versions and likely need to backport such bug fixes to their own boost tree because Boost doesn't do it. Questions: - Do we have any policy about it? - If not we probably need one including backporting of security bug fixes to stable releases. What brings me to other issues... Should Boost support older releases with critical bug fixes/security bug fixes? For how long time? Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.com/ CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/
On Sat, Dec 22, 2012 at 01:15:12PM -0800, Artyom Beilis wrote:
Hello,
I would like to know if there is any policy about security bug fixes, updates or releases.
Nope. There's no distinction at all between security fixes, bug fixes and new features.
Questions:
- Do we have any policy about it?
Current development has only one development direction, and it's: * releases are made by pulling in stuff from the wild west trunk; * point releases (1.NN.1+) are only made when there's something very important that needs to be fixed immediately but is found after the release window is closed, and someone can convince the release wranglers that it indeed is important enough to roll a point release for instead of waiting for the next proper release.
- If not we probably need one including backporting of security bug fixes to stable releases.
There is no such policy, and I've lifted this issue in the past on the lists with very little response.
What brings me to other issues...
Should Boost support older releases with critical bug fixes/security bug fixes? For how long time?
In the current approach, I don't really see how this could easily be adopted. It's definitely something that should be strongly considered for the new modularised fancy-pants Ryppl-filled future. Many other projects have a policy along the lines of: * point releases get all applicable bugfixes, * proper releases get features, * releases have a lifespan of N months. It's more work if you're not careful about separating bugfixes and features, but in the long run, it does wonders for end user trust. As for distros backporting unofficial fixes, all that'll do is fragment the userbase, as they can't really rely on or determine what shenanigans have been inflicted on a legacy version. If there is to be changes made to older versions, it needs central coordination and a proper testable version bump. -- Lars Viklund | zao@acc.umu.se
participants (2)
-
Artyom Beilis -
Lars Viklund