| 1 |
On Wednesday, July 6, 2016 9:00:12 AM JST, Anthony G. Basile wrote: |
| 2 |
> On 7/4/16 11:26 PM, Aaron Bauman wrote: |
| 3 |
> |
| 4 |
>> Finally, that does not dissolve the developer of providing usable, |
| 5 |
>> substantiated, and verifiable information regarding the |
| 6 |
>> vulnerabilities. The idea that a developer gets to choose whether or |
| 7 |
>> not they do so should not be considered. Anthony's verbiage on Freenode |
| 8 |
>> was very frank, in that if he chose to do so he would. We ask for all ... |
| 9 |
> |
| 10 |
> 1) In bug #473770 upstream gave sufficient information. I stated so in |
| 11 |
> comments #1 and #2 with links. You ignored this fact and proceeded to |
| 12 |
> p.mask in comment #3. This CVE should never have been filed. Its junk. |
| 13 |
> |
| 14 |
> 2) Bug #459274 is not a security bug. A CVE request was filed by Ago |
| 15 |
> which, as far as I can tell, went no where. The log file in question |
| 16 |
> does not disclose much more than one could obtain with just ps and |
| 17 |
> netstat. I fixed a related issue with access.log in bug #459274. |
| 18 |
|
| 19 |
That CVE request was not from Ago. It was from the respective OSS ML |
| 20 |
referenced in the URL field of the bug report. Not to mention, you as a |
| 21 |
maintainer were able to discover another issue with that package and fix |
| 22 |
it. |
| 23 |
|
| 24 |
> |
| 25 |
> 3) My point on IRC is that you are acting on junk CVEs and I question |
| 26 |
> your judgment. You can't produce "substantiated and verifiable |
| 27 |
> information" on junk. Your above paragraph eclipses that side of my |
| 28 |
> argument and strawmans me. |
| 29 |
> |
| 30 |
|
| 31 |
Why is this so difficult? All of the follow up information you gave, after |
| 32 |
the p.mask and inquiry from Alex, is exactly what we need from the |
| 33 |
maintainers. If the CVE is junk, which often happens, then the verifiable |
| 34 |
and substantiating information is perfectly acceptable from the maintainer. |
| 35 |
No one here is challenging your ability to provide such information, but |
| 36 |
given the multitude of security related bugs we need cooperation from the |
| 37 |
maintainers. We are not familiar with every package in the tree, but we do |
| 38 |
our best to ensure any potential vulnerability is mitigated. Again, you |
| 39 |
are the only developer who has had an issue with this. As previously |
| 40 |
mentioned, a p.mask is not the end of the road, it is just an obligation to |
| 41 |
ensure the user is warned of longstanding security issues. If they choose |
| 42 |
to unmask it then so be it. |
| 43 |
|
| 44 |
> I personally would like to see only QA oversee any forced p.maskings and |
| 45 |
> have the security team pass that task over to QA for review. By forced |
| 46 |
> I mean without the cooperation of the maintainer. |
| 47 |
> |
| 48 |
|
| 49 |
Again, no one else has had an issue with this except you. The one who |
| 50 |
doesn't want to cooperate. I apologized for not pinging an active |
| 51 |
developer, but you cannot reciprocate the professionalism here and work |
| 52 |
with us. Why can't you just work the issue like you did following the |
| 53 |
p.mask and we can move on? Inevitably proving the point of why the p.mask |
| 54 |
is an option. Look at the myriad of security bugs and you will see such |
| 55 |
examples of developers working together in order to validate, mitigate, and |
| 56 |
close these bugs. Sometimes this process highlights the reality that CVE's |
| 57 |
are not perfect in their descriptions or assessments. |
| 58 |
|
| 59 |
-Aaron |
Archives