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.