xml-security-c 2.0.2

Cantor, Scott cantor.2 at osu.edu
Wed Nov 7 14:25:02 GMT 2018


> Yeah, two problems with that: 1. according to the Debian Security Team, CVE
> policies disallow merging of issues with significantly different discovery times;
> 2. Mitre declined allocating a CVE even for the first one, saying that the Apache
> Foundation should assign these for its own products, or even more, it should
> have allocated one already during the patching process.  Now, the Apache
> Security Team webpage emphasises that they only handle undisclosed issues,
> so I'm uncertain what to do.  Are you okay with me asking them nevertheless?

I simply chose not to treat this as a Santuario security issue, so if you want to be consistent in Debian, that's really the best answer, it's a bug fix. I didn't ask for a CVE from Apache deliberately.  The two Apache libraries have literally dozens or hundreds of unpatched NULL crashes (that's an optimistic guess, it's probably more) and I'm just not going down that road, I'd be on the hook for security releases all the time.

I did an advisory for Shibboleth because I'm specifically paid to do that and because it's something that happens to be exploitable in a specifically problematic way that I can explain in context there. With the library alone it's really anybody's guess.

> Also, SANTUARIO-496 affects 2.0.0+ only, but the same code is present in
> earlier versions as well.  Is there really an excuse for not backporting the fix to
> 1.7 as shipped (and patched for SANTUARIO-491) in Debian stable, or you
> simply didn't care to enumerate such ancient versions?

I could set the affected versions on those bugs since it's pretty obvious in this case but the concern is the precedent there because future bugs may not be easy to answer that question for without spending the time to test them, and I didn't want the absence of an affected version to be an implication for anybody. It's similar to whether I go back and check if 1.4 is affected, I'm just not going to do that. Since anything before the latest one is unsupported, they're not tested for impact (again, in this case obviously it's known without testing).

That's been my thinking anyway. I probably have not been as consistent with that on my projects and bug tracking, but I have more insight into the code there, so usually I know without checking how far back something goes.

The alternative I suppose would be to just assume most anything does affect 1.x and attach those versions. I could do that if it's preferable, I don't feel strongly about it. Whatever is clearest.

-- Scott




More information about the Pkg-shibboleth-devel mailing list