On Wednesday, July 6, 2016 9:00:12 AM JST, Anthony G. Basile wrote:
On 7/4/16 11:26 PM, Aaron Bauman wrote:

Finally, that does not dissolve the developer of providing usable,
substantiated, and verifiable information regarding the
vulnerabilities.  The idea that a developer gets to choose whether or
not they do so should not be considered.  Anthony's verbiage on Freenode
was very frank, in that if he chose to do so he would.  We ask for all ...

1) In bug #473770 upstream gave sufficient information.  I stated so in
comments #1 and #2 with links.  You ignored this fact and proceeded to
p.mask in comment #3.  This CVE should never have been filed.  Its junk.

2) Bug #459274 is not a security bug.  A CVE request was filed by Ago
which, as far as I can tell, went no where.  The log file in question
does not disclose much more than one could obtain with just ps and
netstat.  I fixed a related issue with access.log in bug #459274.

That CVE request was not from Ago. It was from the respective OSS ML referenced in the URL field of the bug report. Not to mention, you as a maintainer were able to discover another issue with that package and fix it.


3) My point on IRC is that you are acting on junk CVEs and I question
your judgment.  You can't produce "substantiated and verifiable
information" on junk.  Your above paragraph eclipses that side of my
argument and strawmans me.


Why is this so difficult? All of the follow up information you gave, after the p.mask and inquiry from Alex, is exactly what we need from the maintainers. If the CVE is junk, which often happens, then the verifiable and substantiating information is perfectly acceptable from the maintainer. No one here is challenging your ability to provide such information, but given the multitude of security related bugs we need cooperation from the maintainers. We are not familiar with every package in the tree, but we do our best to ensure any potential vulnerability is mitigated. Again, you are the only developer who has had an issue with this. As previously mentioned, a p.mask is not the end of the road, it is just an obligation to ensure the user is warned of longstanding security issues. If they choose to unmask it then so be it.

I personally would like to see only QA oversee any forced p.maskings and
have the security team pass that task over to QA for review.  By forced
I mean without the cooperation of the maintainer.


Again, no one else has had an issue with this except you. The one who doesn't want to cooperate. I apologized for not pinging an active developer, but you cannot reciprocate the professionalism here and work with us. Why can't you just work the issue like you did following the p.mask and we can move on? Inevitably proving the point of why the p.mask is an option. Look at the myriad of security bugs and you will see such examples of developers working together in order to validate, mitigate, and close these bugs. Sometimes this process highlights the reality that CVE's are not perfect in their descriptions or assessments.
-Aaron

Reply via email to