JLLeitschuh commented on PR #5: URL: https://github.com/apache/maven-project-utils/pull/5#issuecomment-1321480137
> Would automated emails with patch files attached be preferred? I reiterate this question. Is this what the ASF process would prefer? > This is not Apache commons, this is part of the Apache maven project. I agree. But the comment I was responding to was from @garydgregory who stated he had personally placed these files in all of the Apache Commons files. I presume this was done with the blessing of the ASF PMC, and I would of course respect it if that were the case. > you are already ignoring the request to not report security issues publicly How do you propose I do this at scale? When reporting hundreds or thousands of security vulnerabilities across OSS, I am only one person. How do you propose I attempt to follow the policies of every org I report to? How would you solve this problem? The problem is, there are a lot of common ways that vulnerabilities appear in open source. I've opened 165 pull requests to fix Zip-Slip across the java OSS ecosystem. Zip-slip is well recognized as a fairly critical security vulnerability when that code is reachable by an external actor. Other similar vulnerabilities impact our industry writ-large. My knowledge of security vulnerabilities doesn't scale well if I'm expected to triage and report each vulnerability 1 at a time. In an ideal world, I completely agree this would be how we'd want to solve this problem. But it's impractical. According to GitHub, there is 1 security researcher to every 500 developers. We are heaviy outnumbered. I believe, although there will be false positives, that providing an easily mergeable fix is the best way to actually see these widespread common security vulnerabilities eliminated in the most efficient manner from the industry. The goal of all of these fixes is to have them either be valid security fixes, or at worse, valid security hardening worth merging regardless. The feedback regarding pure-test security PRs has forced me to reasess a bit, and I'll be improving the recipe logic to prevent pure-test fixes from being created with FUD language. Anyone in this thread is more than welcome to grab some time on my calendar to discuss this in person. I welcome the feedback and the ability to discuss this with you all more moving forward. https://calendly.com/jonathan-leitschuh-at-dan-kaminsky-fellowship/30min -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
