> 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
