xml-security-c 2.0.2

Ferenc W√°gner wagner.ferenc at kifu.gov.hu
Wed Nov 7 20:21:56 GMT 2018

"Cantor, Scott" <cantor.2 at osu.edu> writes:

>> 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.

Yes, the security aspect stems from the application, not the library,
but we have to fix the library, so we have to run the security update
procedure for it.

> 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.

You made this clear last time and I'm fine with that.  The CVE ID helps
with cross-vendor referencing, so we prefer to have one for each issue,
but it's possible to do without.

> 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.

Speaking of the current issue: how is it possible to have only a private
key in a DSA structure?  OpenSSL 1.1 does not seem to allow this at all.
Is there some 1.0 code path which gives you this?  What do I miss here?
This would mean that verification is safe even without the patch...

>> 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).

OK, this is what I suspected.  You don't support 1.7 anymore, so you
didn't mention it.  But that doesn't mean we haven't got to backport the
fix for Debian stable.

> 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.

Fair enough.

> 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.

I don't mind unless you don't mind the occasion question, like now: I
didn't want to do meaningless work, so decided to ask first.

More information about the Pkg-shibboleth-devel mailing list