Subject: [boost] [Security] Policy about security issues (was [locale] security bug announcement ...)
From: Artyom Beilis (artyomtnk_at_[hidden])
Date: 2013-01-04 15:51:51
----- Original Message -----
> From: Eric Niebler <eric_at_[hidden]>
>> It is in release notes quoting:
>> * Security related bug fix, some invalid UTF-8 sequences where accepted
> as valid #7743 Also maybe it need to be more
>> Release managers, maybe we need to make it bolder?
> Yes, I think this warrants a bolder announcement, like the one we did
> last release for the potentially breaking result_of change. Here I'm
> thinking of the red warning on the front page, not necessarily a
> separate page describing the issue. The red warning could simply link
> directly to the 1.53 release notes.
> Daniel, thoughts?
> Eric Niebler
> BoostPro Computing
What is more disturbing me that we do not have **standard and ready**
to go way of handling such situation.
I think we need a general policy what to do if some bug that
may affect application security or introduce a potential
vulnerability to an application is discovered.
It is not the first time (and of course it would not be the last time)
that such a situation happens.
For example, there is a bug in UUID that was fixed
in 1.43 should get much more serious attention:
It is uncommon case when generation on unpredictable UUID is used
ad application relay on that (for example session key).
Also, I'm not sure if the author was aware how critical
this bug was, but such a bug should be treated much more
seriously that small line in Boost 1.43 UUID notes.
Probably potential vulnerabilities should be:
1. Published in a central place, including the information
about which Boost versions are affected.
2. Exact security risk should be described.
3. A patch that can fix them should be given.
You should remember, that for example many Linux distributions
deliver older Boost version and support of for a long time.
End even distributions with a short release cycle need to
provide security updates for their packages for at least
for about year or two, but sometimes for much longer period
as like RHEL, Debian or Ubuntu LTS.
The fact that Boost does release bug fixes for older versions
makes the work of package maintainers for Linux distributions
Such central documentation and page should be available
and keep a track of all potential vulnerabilities, and of course
it should not be tied to release cycle.
CppCMS - C++ Web Framework: http://cppcms.com/
CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk