Apache XML Security for C++

After discussion with the Santuario PMC, it has been decided to address the long term lack of support for the C++ library by formally retiring the code here at Apache. The Java code of course remains well supported and will continue to be developed.

As of now, the C++ code is frozen here. The current sole maintainer will be transferring the source code to the Shibboleth Project and it will be maintained by that team for some period of time because it is a dependency of that software, but it will not be supported for any third-party use. It is estimated that the code will be fully retired some time before 2030. The code will be publically hosted and accessible after the transition, and the license is not changing.

Once the code transition occurs, which may not be for some time yet, we will update more of the site as is appropriate to reflect the transition. In the event a significant issue arises with the library prior to the transition, we will endeavor to address it here.

The XML Signature and Encryption specifications are complex and difficult (some would say virtually impossible) to implement securely. Moreover, this library is extremely generic in nature and was designed to support a wide array of use cases with different characteristics and threat models, and out of the box it does not (and cannot) provide the safeguards needed to ensure that any given use case is implemented safely. Applications or libraries using this library have to be carefully designed with their own needs in mind and generally would need to include a large amount of additional code to limit the kinds of signature or encryption syntaxes permitted.

This library in particular is not modular in nature to the extent that specific features can easily be turned on and off, and so the potential for vulnerabilities is very large and very hard to avoid, especially for developers not extremely well versed in the specifications. Notably, the support for XPath and XSLT, while extensive when Xalan is included, is an extremely large source of risk and should be avoided in virtually all cases.

Thus, we strongly urge that developers consider whether they are prepared to take on such a responsibility and in most cases should seek better options that may already exist to address their needs rather than attempting (and likely failing) to produce a secure solution on their own.

Furthermore, this library has very limited support in the form of active maintainers and should be viewed as a poor option for new applications in general.