Potential risks in Boost testing and release workflow
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.
On September 14, 2025 12:08:49 PM Mohammad Nejati via Boost <boost@lists.boost.org> wrote:
For example, the final machine that publishes shared libraries or Boost archives should not run tests.
I may be mistaken, but I don't think running tests is part of the release process. Building documentation is, though, and that may involve some scripts and XSLTs provided by libraries. I'm not sure about high security concern about compromising Boost distribution as a whole. Hacking individual libraries seems more likely. But it is possible to break entire Boost build by an erroneous change in a single library, and it would be nice if this was mitigated.
On Sun, Sep 14, 2025 at 1:52 PM Andrey Semashev via Boost <boost@lists.boost.org> wrote:
I may be mistaken, but I don't think running tests is part of the release process. Building documentation is, though, and that may involve some scripts and XSLTs provided by libraries.
I'm not sure about high security concern about compromising Boost distribution as a whole. Hacking individual libraries seems more likely. But it is possible to break entire Boost build by an erroneous change in a single library, and it would be nice if this was mitigated.
On Sun, Sep 14, 2025 at 1:52 PM Andrey Semashev via Boost <boost@lists.boost.org> wrote:
I may be mistaken, but I don't think running tests is part of the release process. Building documentation is, though, and that may involve some scripts and XSLTs provided by libraries.
I'm not sure about high security concern about compromising Boost distribution as a whole. Hacking individual libraries seems more likely. But it is possible to break entire Boost build by an erroneous change in a single library, and it would be nice if this was mitigated.
Yes, I mean the release should be done on a fresh machine that has not been used for running unit tests. The concern is that even without building anything from a library, their Jmafiles can execute code on a machine. Therefore, it might be advisable for developers to clone only what they need and not every library in the superproject.
Fwiw, I think it's incredibly important to care about supply chain attacks in Boost. We've never had any issues so far, which is good. One thing we could do is look into sandboxing the test running and looking to see if there are malicious actions, for some definition of malicious that we can actually track. It also might be useful to start encouraging library authors whose libraries touch networking components to fuzz and fuzz heavily. While supply chain attacks are a valid thing to look out for, in the wild fuzzing is more likely to catch bugs and potential issues. From what I can tell, libraries like URL and MySQL are fuzzed by libraries like Mqtt and Redis are not. Getting serious about security is a good move and we should at least think about what kind of infrastructure and common abstractions we can apply to help authors reach the bar of quality we want. Google's oss-fuzz project already fuzzes a good number of Boost libraries for us but it'd be nice to rely on ourselves. Actually, Hash2 probably could use some fuzzing... - Christian
It also might be useful to start encouraging library authors whose libraries touch networking components to fuzz and fuzz heavily.
While supply chain attacks are a valid thing to look out for, in the wild fuzzing is more likely to catch bugs and potential issues.
From what I can tell, libraries like URL and MySQL are fuzzed by libraries like Mqtt and Redis are not.
This is something I have in mind to add to Boost.Redis in the near future, since I do share your view. JSON is also fuzzed, BTW.
Getting serious about security is a good move and we should at least think about what kind of infrastructure and common abstractions we can apply to help authors reach the bar of quality we want.
Google's oss-fuzz project already fuzzes a good number of Boost libraries for us but it'd be nice to rely on ourselves. Actually, Hash2 probably could use some fuzzing...
- Christian _______________________________________________ Boost mailing list -- boost@lists.boost.org To unsubscribe send an email to boost-leave@lists.boost.org https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/boost@lists.boost.org/message/BOQUDXWE...
On Fri, Sep 19, 2025 at 11:11 AM Ruben Perez <rubenperez038@gmail.com> wrote:
This is something I have in mind to add to Boost.Redis in the near future, since I do share your view. JSON is also fuzzed, BTW.
This is fantastic to hear! Maybe we should start compiling a list of libraries in Boost that, RFC-style, SHOULD be fuzzed. - Christian
On Fri, 19 Sep 2025 at 22:51, Christian Mazakas via Boost < boost@lists.boost.org> wrote:
On Fri, Sep 19, 2025 at 11:11 AM Ruben Perez <rubenperez038@gmail.com> wrote:
This is something I have in mind to add to Boost.Redis in the near future, since I do share your view. JSON is also fuzzed, BTW.
This is fantastic to hear!
Maybe we should start compiling a list of libraries in Boost that, RFC-style, SHOULD be fuzzed.
Maybe we could add some kind of badge in the website saying that a library does fuzz testing, too?
- Christian _______________________________________________ Boost mailing list -- boost@lists.boost.org To unsubscribe send an email to boost-leave@lists.boost.org https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/boost@lists.boost.org/message/AXW4OIMQ...
No dia 19 de set. de 2025, às 23:56, Ruben Perez via Boost <boost@lists.boost.org> escreveu:
On Fri, 19 Sep 2025 at 22:51, Christian Mazakas via Boost < boost@lists.boost.org> wrote:
On Fri, Sep 19, 2025 at 11:11 AM Ruben Perez <rubenperez038@gmail.com> wrote:
This is something I have in mind to add to Boost.Redis in the near future, since I do share your view. JSON is also fuzzed, BTW.
This is fantastic to hear!
Maybe we should start compiling a list of libraries in Boost that, RFC-style, SHOULD be fuzzed.
Maybe we could add some kind of badge in the website saying that a library does fuzz testing, too?
I’d be so grateful if someone could help me get Boost.Unordered fuzzed. Joaquín M López Muñoz
On Fri, Sep 19, 2025 at 5:42 PM Joaquín M López Muñoz via Boost < boost@lists.boost.org> wrote:
No dia 19 de set. de 2025, às 23:56, Ruben Perez via Boost < boost@lists.boost.org> escreveu:
On Fri, 19 Sep 2025 at 22:51, Christian Mazakas via Boost < boost@lists.boost.org> wrote:
On Fri, Sep 19, 2025 at 11:11 AM Ruben Perez <rubenperez038@gmail.com> wrote:
This is something I have in mind to add to Boost.Redis in the near future, since I do share your view. JSON is also fuzzed, BTW.
This is fantastic to hear!
Maybe we should start compiling a list of libraries in Boost that, RFC-style, SHOULD be fuzzed.
Maybe we could add some kind of badge in the website saying that a library does fuzz testing, too?
I’d be so grateful if someone could help me get Boost.Unordered fuzzed.
I was wondering about adding fuzzing to things because of this discussion a few hours ago. And eventually found this to be helpful.. < https://www.boost.org/doc/contributor-guide/testing/fuzzing.html> -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supongas Nada -- Robot Dreams - http://robot-dreams.net
I’d be so grateful if someone could help me get Boost.Unordered fuzzed.
I was wondering about adding fuzzing to things because of this discussion a few hours ago. And eventually found this to be helpful.. < https://www.boost.org/doc/contributor-guide/testing/fuzzing.html>
I wrote that page based on what I discovered fuzzing MySQL. If you find that something's missing or not clear, please do report it to make the page better.
-- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supongas Nada -- Robot Dreams - http://robot-dreams.net _______________________________________________ Boost mailing list -- boost@lists.boost.org To unsubscribe send an email to boost-leave@lists.boost.org https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/boost@lists.boost.org/message/3I66NH65...
participants (6)
-
Andrey Semashev -
Christian Mazakas -
Joaquín M López Muñoz -
Mohammad Nejati -
René Ferdinand Rivera Morell -
Ruben Perez