TL;DR, This is not a vulnerability, it's a default that people don't like that required a minor update to change, and that wasn't going to happen. The code has been formally retired at Apache and forked for the Shibboleth Project's use, and there will be some form of official indication of that at some point later this summer.
> The following vulnerability was published for xml-security-c. It is not a vulnerability, and should never have been published as one. It's a default that people don't like. I don't like a lot of defaults in lots of software but that doesn't make them vulnerabilities. > NOTE: the supplier disputes this CVE Record on the grounds > that they are | implementing the specification "correctly" > and are not "at fault." Yes, because those are the facts. The scare quotes are unnecessary, as is the entire CVE. > Not sure what to make out of this? It seems the use of xml >-security-sec within Shibboleth continues to be supported, > but otherwise the library is deemed deprecated, so maybe > this should at least be made explicit in the package > description? The mess around this invalid CVE led to my finally putting my foot down and demanding that we either retire the code or somebody else show up to help maintain it. Nobody did, so the Apache project retired that version of the library. The Shbboleth Project has forked the codebase for its own use since we were the only maintainers. It is effectively in the same state in terms of support as the xmltooling and opensaml libraries: they're for the Shibboleth SP's use and any other uses are not relevant to the maintainers of the code and bugs or requests that do not impact the SP will not be prioritized. Our needs are far less general than the original library's, so taking it over allows us to potentially do new releases that strip out a lot of code and attack surface, and to make different decisions in regard to API compatibility than could be made when it was a general-purpose tool. The code was only recently converted to git and we are still in the process of getting it in place and deciding what to do with it. I have no idea how the retirement is going to be managed from the Apache side. Something needs to be done with the wiki, etc., but none of that has been determined. Once the code is fully in place, I was planning to drop a note to the Debian packaging list for Shibboleth to note the change, as if the packaging continues, it should likely pull from our copy rather than the old one. I don't have an opinion really about what to do with the package. I'm not about to rename it because that's more work for me, not less. I could understand the feeling on the Debian side being different about the need to delineate the transition and retire the original package since it's unmaintained. -- Scott
