- Boost - lists.boost.org

Potential risks in Boost testing and release workflow
by Mohammad Nejati 20 Sep '25

20 Sep '25

Hi everyone, There is a potential security concern regarding how Boost libraries are built and tested that might deserve some attention. Currently, it is common for the release manager or developers to build the superproject with all libraries and run all tests. This creates a risk that it only takes one malicious test to compromise the developer's or release manager's machine. Given the size of Boost and the number of libraries it contains, the chance that one library could include harmful code (especially in unit tests) is not negligible. The risk depends on the quality of maintenance for each individual library, which Boost has very little control over. I think the current process dates back to when Boost was a smaller set of libraries authored by trusted contributors. Today the situation is different, and there are more potential attack vectors. For example: Maintainer or contributor-related risks: While the risk is low for long-time trusted contributors, maintainers can change over time, especially for libraries that are under-maintained or abandoned and later picked up by volunteers. There is also a possibility that a contributor's credentials could be compromised and used against the Boost project in a targeted attack. Malicious pull requests: This may be the easiest way for an attacker to inject harmful code. Test-related PRs are especially risky, since they often involve large datasets or third-party code. CVE-2024-3094 shows how subtle such attacks can be. I believe it may no longer be safe to fully trust every individual library in the Boost collection. Changes to the release process might be necessary to reduce the chance of compromise. For example, the final machine that publishes shared libraries or Boost archives should not run tests. We might also recommend that developers clone only the libraries they actually depend on, rather than the full superproject. Given how B2 works, a library can execute an executable even if it is not part of a dependency chain. Thanks, Mohammad.

6 10

Looks like our CMake misses some of the b2 features
by Antony Polukhin 16 Sep '25

16 Sep '25

Hi, Looks like b2 was doing many things behind the scene and I've get used to it. Now I'm getting instantly hit by bugs because CMake misses the functionality. Below are some of the missing features ## Installation testing With b2 there is no need to test installation. It just works. CMake is different in that place, without CI scripts to test installation things break ( https://github.com/boostorg/dll/issues/102, https://github.com/boostorg/pfr/issues/217 ) ## CLI convenience cd libs/pfr/tests; ../../../b2 toolset=gcc14,gcc-15,clang-21 cxxstd=11,14,17,20,23,26 variant=debug, release and the library is tested in 36 configurations. CMake miss that functionality, and it also can not be run from libs/pfr/tests. Instead of that a list of libraries should be provided via CMake variable. Workarounds via CI matrix or shell scripts are clumsy and require copy pasting between Boost libraries. The same story with C++20 modules. If b2 was able to build modules, the syntax would be like modules=on. With CMake it is -DBOOST_USE_MODULES=1 -DCMAKE_EXPERIMENTAL_CXX_IMPORT_STD=0e5b6991-d74f-4b3d-a41c-cf096e0b2508 -G Ninja. ## Non-run tests CMake miss the compile, compile-fail, link, link-fail testing rules of b2 https://www.boost.org/doc/libs/1_76_0/tools/build/doc/html/index.html#bbv2.… ## Double efforts for build scripts Manual rewriting of Jamfiles to CMakeLists is boring and tiring. Keeping those two in sync is pain. ## Regression tests matrix The regression tests https://regression.boost.io/develop/developer/summary.html use b2. As a result cmake tests are limited to github CI only. # How to make things better In my naiive opinion many of the above issues could be bypassed by the following steps: 1) How about adjusting b2 to be able to run cmake? I mean it should under the hood convert b2 arguments into CMake arguments and run the cmake and tests. It can check for particular tests compile/link failures to emulate the missing cmake functionality. It could also run the the installation tests (test against an installed Boost library) 2) Can b2 fallback to CMake if there's no Jamfile? In that way the developers could transparently move from Jamfiles to CMake As a bonus, the following step could simplify the migration: 3) Can b2 be adjusted to generate CMakeLists from Jamfiles? Not necessary fully functional, but at least something to simplify the migration.

7 9

[sqlite] Review Result
by Mohammad Nejati 14 Sep '25

14 Sep '25

First of all, I would like to thank everyone who participated in the review process, and Klemens for submitting the library. In total, we received 9 reviews: 3 ACCEPT, 3 CONDITIONALLY ACCEPT, and 3 REJECT. The individual reviews are as follows: Barend Gehrels: ACCEPT [1] Ruben Perez: REJECT [2] Scott Bailey: ACCEPT [3] Mungo Gill: CONDITIONALLY ACCEPT [4] Amlal El Mahrouss: ACCEPT [5] Harold Bott: CONDITIONALLY ACCEPT [6] Darryl Green: CONDITIONALLY ACCEPT [7] Andrzej Krzemienski: REJECT [8] Maximilian Riemensberger: REJECT [9] After carefully examining all reviews, going through the mailing list discussions, and consulting with Ruben Perez (author of Boost.MySQL) and Klemens, I have decided to REJECT the library due to critical flaws in the API and insufficient documentation. I strongly encourage the author to make another submission after addressing the issues listed below: - connection ownership ambiguity: A connection object can currently be constructed in two forms, owning and non-owning, which makes reasoning about it difficult. It was suggested on the mailing list to introduce a connection_ref type, which not only resolves this problem but also makes it easier for a user to wrap an existing sqlite3* (acquired from another library or C API) and benefit from the type safety provided by this library. - resultset ownership ambiguity: A resultset can either own an sqlite3_stmt or act as a non-owning reference to an existing sqlite3_stmt, providing only an access interface. This dual behavior makes reasoning about ownership difficult and allows multiple resultset objects to reference the same sqlite3_stmt, giving the false impression that they exist independently of the main statement object. Further exploration is needed to determine the right API. One suggestion from the mailing list is to remove the resultset type entirely and merge its functionality into the statement type, with a non-owning view/range type that can be used for iterating without having to pass the statement object around. - Wrong usage of cstring_ref (minor): As noted in the reviews, field::get_text could return a core::string_view instead of a cstring_ref, since SQLite already provides an API for determining the length of a column. - CI and test coverage: Currently, the CI supports only a limited set of platforms. It should, at a minimum, build and test the project on Linux, Windows, and macOS using Clang, GCC, and MSVC, with a matrix of configurations (RTTI on/off, exceptions on/off, shared/static). It should also include sanitizer builds and coverage reports. I would recommend that the author use the coverage report results to improve the tests, as the current tests do not appear to cover all interfaces. - Build scripts: The Jamfile should allow using libsqlite3 even when it is not installed system-wide and exists only in package manager paths, such as vcpkg. The necessary Jamfile for locating libsqlite3 should likely be added to the Boost.Build repository. - Examples: The existing examples cover advanced usage, such as SQLite virtual tables, but lack clear and simple use cases. I would recommend that the author focus on the most frequently used APIs and provide examples that quickly convey the knowledge needed to use the library for simple tasks. - Documentation: Currently, there is very little documentation around important types such as connection, statement, resultset, row, field, and value. I would recommend that the author provide proper documentation and usage examples for each type, and place extra emphasis on the quick-start section, as it is likely the part most users will read. - Real-world users: Considering the nature of this library, I would recommend that the author seek feedback from real-world users before submitting it again, as many design flaws in the libraries of this kind only become apparent through practical use. Without such feedback, it is difficult to anticipate usage patterns and design interfaces accordingly. Additionally, receiving reviews from users who have successfully used the library in their applications provides extra confidence to the release manager regarding the library's future success. [1] https://lists.boost.org/archives/list/boost@lists.boost.org/message/MGOXOV6… [2] https://lists.boost.org/archives/list/boost@lists.boost.org/message/57ZZ7II… [3] https://lists.boost.org/archives/list/boost@lists.boost.org/message/BD3OQOW… [4] https://lists.boost.org/archives/list/boost@lists.boost.org/message/O477WE5… [5] https://lists.boost.org/archives/list/boost@lists.boost.org/message/BUL75BO… [6] https://lists.boost.org/archives/list/boost@lists.boost.org/message/CS3FT3E… [7] https://lists.boost.org/archives/list/boost@lists.boost.org/message/VKZMFA6… [8] https://lists.boost.org/archives/list/boost@lists.boost.org/message/DIP5GYY… [9] https://lists.boost.org/archives/list/boost@lists.boost.org/message/TVXSK4D… Best regards, Mohammad Nejati Review Manager for the proposed Boost.SQLite

7 12

Spirit requires C++23 for questionable reasons
by Vinnie Falco 13 Sep '25

13 Sep '25

This new maintainer of Spirit has bumped up the language requirements to C++23, for what is in my opinion a gratuitous reason. To serve the widest audience I think it is best when libraries use the lowest version of C++ which is practical, and only adopt new language features when doing so improves the public API or offers a significant benefit to the user experience. While it is true that newer language features can make it easier for the maintainer to express the implementation, we make sacrifices (like writing `typename...type` instead of using the newer type trait aliases) for the convenience of users. This bump to C++23, which came without warning, has affected Boost.MQTT5 which must now scramble to fix itself before the next release. There should have been a warning for a version first. The Spirit author's rationale can be seen in this GitHub issue: https://github.com/boostorg/mqtt5/issues/36 Quoted here for convenience: > There's one political reason that I didn't mention: young people. > Why would a high school student who likes to experiment with C++ consider some obsolete > (C++17) library as attractive? Boost is dying and we're doomed if we don't use bleeding > edge features to attract young people. > You might think this is some kind of joke but I believe this is the right way to proceed. > > Young people will avoid contribution to the existing library if it sticks to the C++ standard that is > now obsolete for 2 versions. That was my feeling when I saw a C++03 library when I was a high > school student. I'm 30 years old now and still think the same. > > My goal is to revitalize C++. It is impossible without gathering contributions from the young people. > Some people write C++ for business, while some people write C++ because it's genuinely fun to hack. That's the difference. > It's the same reason that Rust is getting wider audience than C++. > > Many Japanese University students think otherwise. I have active connections to the > young community and they actually empathize with me. Thanks for the video anyways, > that is a good evidence that western, agitated-by-businessman young people are very > different than my colleagues. Thanks

14 41

[sqlite] Formal review of Boost.SQLite begins
by Mohammad Nejati [ashtum] 12 Sep '25

12 Sep '25

Dear Boost community, The review of Boost.SQLite by Klemens Morgenstern begins today, Monday, August 25, and runs through Wednesday, September 3, 2025. Boost.SQLite provides a safer and more expressive C++ interface to the SQLite3 C-API to simplify usage and reduce errors. You can read the documentation at: https://klemens.dev/sqlite and study or try out the code at: https://github.com/klemens-morgenstern/sqlite This is the second review attempt. The first concluded without a result due to too few submitted reviews. Anyone with experience in C++ or SQLite, at any level, is encouraged to contribute. In your review, please indicate how much time you spent on the evaluation. Here are some questions you might find helpful when writing your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? Do you already use it in industry? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? At the end of your review, please state clearly whether you ACCEPT, REJECT, or CONDITIONALLY ACCEPT (with explicit conditions) the proposed Boost.SQLite library. Your feedback is critical to the success of this review. Thank you in advance for your time, expertise, and contributions. Best regards, Mohammad Nejati Review Manager for the proposed Boost.SQLite

17 56

Are BOOST_STATIC_ASSERT() and BOOST_STATIC_CONSTANT() still necessary?
by Gennaro Prota 12 Sep '25

12 Sep '25

Hi everyone, I was wondering if there's still any compiler among those generally supported by Boost which requires either BOOST_STATIC_ASSERT() or BOOST_STATIC_CONSTANT(). I'd like to get rid of them for DynamicBitset. Thanks. -- Gennaro Prota <https://prota.dev>

5 15

Guidelines to support Boost components and their std alternatives
by Samuel Debionne 11 Sep '25

11 Sep '25

Dear all, Some libraries have APIs that rely on type from Boost libraries that have std alternative in C++17 (think filesystem, variant, optional). I wonder if there are some guidelines available for library maintainers to support both alternatives (or concerns if it is not a good idea)? For example, in Boost.MPI, the foreseen solution is to introduce an alias for optional in the boost::mpi namespace that will conditionally refer to std::optional or boost::optional depending on BOOST_NO_CXX17_HDR_OPTIONAL and a new BOOST_MPI_FORCE_BOOST_OPTIONAL macro. See https://github.com/boostorg/mpi/issues/168 Thank you, Samuel

6 7

[dynamic_bitset] Boost.DynamicBitset is back in business
by Gennaro Prota 10 Sep '25

10 Sep '25

Hi everyone, I'm happy to share that Boost.DynamicBitset is officially back in business! After some years of relative quiet, I'm resuming active maintenance of the library. My goal is to ensure dynamic_bitset continues to be a reliable and efficient tool for bit manipulation in C++ projects. I'll be reviewing open issues and pull requests, modernizing parts of the codebase where appropriate, and welcoming contributions and feedback from the community. If you've been using dynamic_bitset, have ideas for improvements, or just want to help shape its future, now's a great time to get involved. Feel free to reach out, open issues, or start discussions. Looking forward to collaborating with you all. Best, Gennaro

9 31

[sqlite] End of Boost.SQLite review
by Mohammad Nejati 08 Sep '25

08 Sep '25

The review of the proposed Boost.SQLite library has now ended. We received 7 reviews, along with a constructive discussion on potential API, documentation, and implementation issues. I want to thank everyone who participated in the process, and Klemens for submitting the library. Including the 3 reviews from the previous attempt, which are still relevant, I believe there is now enough feedback to reach a consensus. I will take a few days to weigh all the feedback and discussions before providing a conclusion. Best regards, Mohammad Nejati Review Manager for the proposed Boost.SQLite

1 0

[boost][sqlite] Review
by Andrzej Krzemienski 06 Sep '25

06 Sep '25

Hi Everyone, Again, I wanted to thank Klemens for his determination in developing, improving and submitting for review the Boost.Sqlite library. I also want to thank Mohammad for managing the review. My recommendation is to REJECT the library in its current shape, and encourage the author to resubmit the library in the future, when the issue listed below is addressed. I am *not* well familiar with SQLite, and my review is based on studying the documentation. I haven't played with the library. I see a great value in offering a wrapper over the native SQLite C API that offers clean, automatic, C++-style resource management. However, the way I see it, the library, in its current shape, does not offer this, or at least fails to communicate it in the documentation. This is my motivation for recommending rejection. As a C++ programmer I have two viable options. Either accept that I am dealing with the C interface, and write a resource-managing wrapper myself, or *trust* that a library performs a clean, correct resource management. I do not see a clear indication that class `connection` does the resource management right: 1. It is not documented 2. Constructor parameter take_ownership implies (but this is never documented) that a connection may have and use a connection handle and yet not manage its lifetime. How do I even tell if the connection object I have received does or does not manage the lifetime of the corresponding handle? 3. There are two functions for which it is not clear how they differ: release() ("Release the owned handle.") and close() ("Close the database connection."). What does function valid() check? having called close() or having called release() or having used `take_ownership`? I do not see a clear resource management in the class `statement`. Is `statement` associated with a resource that needs to be managed? The class has a comment "This transfers ownership to the resultset". Ownership of what? What is the full lifetime of this implied resource? Can execute() be called multiple times? If so, do you transfer the same ownership of something to multiple places? I do not see a clear resource management scheme in class `resultset`. I intuitively feel that some life-time-related thing happens each time I call read_next(). But I do not know when and what actually happens. I also do not know in the iterator interface whether it is operator++ or operator* that corresponds to read_next(). Or if the call to begin() also involves calling read_next(). THe documentation is silent about this important aspect. I fail to see how the example provided could be correct: sqlite::resultset rs = conn.query("select * from users;"); do { handle_row(r.current()); } while (rs.read_next()); // read it line by line The first call to `r.current()` is performed unguarded, without any check. How does this work given that the query can potentially return zero results? These things lead me to the conclusion that I would not be able to correctly manage resources if I used this library interface in its current shape. It is possible that the implementation is fine, and this is just the issue with the documentation. But in my opinion this aspect (resource management) is so important that it cannot be left undocumented, and having left it undocumented in the first place may be an indication that not enough thought has been given to the correct design of the resource management. I hope that the next incarnation of the library will address this aspect. Best regards, &rzej;

6 12