Boost logo

Boost :

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: >>  >> Locale:  >>     * 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 much harder. 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.   Artyom Beilis -------------- CppCMS - C++ Web Framework: CppDB - C++ SQL Connectivity:

Boost list run by bdawes at, gregod at, cpdaniel at, john at