Re: [gentoo-dev] why is the security team running around p.masking packages

[NP-Hardass]

On 07/05/2016 10:43 PM, Aaron Bauman wrote:
> 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
>

I think it is a little bit of a stretch to say that he's the only one to
have an issue.  Now, I've spoken with the parties involved, so my issue
is resolved, but I had a package of mine bumped in the name of security
without being pinged/consulted at all.  I'm not attempting to point
blame at anyone, but merely show that there are others who have been
affected by security workflow sometimes going around the maintainer.  I
don't think there should be any harm in acknowledging that, and striving
to make sure it doesn't happen in the future, where possible.

-- 
NP-Hardass