How about new xml-security-c bugreports?

[Yuri <0x...@gmail.com>]

Hello everyone.

From time to time I get XAdES files that xsec fail to validate. I try to
patch sometimes our software, sometimes xml-security-c sources. The problem
I'm not so familiar with internals and my fixes *could* bring more problems
than benefits.

For example, attached patch fixes two problems. 1) XPath-transformation
followed by enveloped-signature transformation was not expected by xsec; 2)
particular raw signature has omitted NULL parameter in RSA padding. (I hope
I can provide broken xml documents too).

Is it worth the effort to report that kind of issues and work on better
quality patches?

Re: How about new xml-security-c bugreports?

["Cantor, Scott" <ca...@osu.edu>]

As you'll have seen, I do have to spin another release next week so if you want something reviewed, now's the time. But as I noted, the chances I'd patch anything aroung RSA signatures is about nil without a really serious bug unless it was just fixing a crash with a controlled error path.

-- Scott

Re: How about new xml-security-c bugreports?

["Cantor, Scott" <ca...@osu.edu>]

>    Is it worth the effort to report that kind of issues and work on better quality patches?

That's not a simple yes/no answer. Generally speaking, I'm only going to do releases when the Shibboleth Project has a need for them. There is no other reason I can spend time on this code. That need is likely to end sometime in 2023-2024 when I replace the dependency on this code with Java so that I can officially end my involvement with this code and Xerces. Xerces itself is a project that is dead in all but name, with open, unfixed vulnerabilities. Since this code depends on Xerces...you can do the math.

I just did a release because I needed one. I won't do another one until I need something again.

In terms of "risk", any patches that could impact basic correctness are probably off-limits unless they address a bug I'm affected by.

Patches that don't impact my project are more likely to be "accepted" if and when I do a release, and anything in the XPath or XKMS areas are in that category. I wouldn't be able to review them for correctness but if they look ok I would usually apply them.

One type pf patch I will *not* accept is anything that works around somebody else's bug. I don't know for certain, but it seemed like your "RSA padding" issue might be in that category if you're trying to deal with something being missing from the message that is required by the standard. That's not going to happen. Coding defensively if it's crashing is fine, I would do that, but I would never support non-compliant inputs. That is just madness. But if it's a real bug not handling something we need to handle, that's a different matter.

I would close with: this is just me. If somebody else steps up as a committer, they're welcome to adopt a different standard or do more frequent releases, but I would wield my PMC vote against that last category of patches. I simply believe that's wrong, and a bad idea.

-- Scott