[development] Think there's a security problem in your module? Here's what to do.

[David Metzler]

On Jan 17, 2008, at 2:37 AM, andrew morton wrote:

> On Jan 16, 2008 9:08 PM, David Metzler <metzlerd at metzlerd.com> wrote:
>> 2.  It seems to take the RTBC decision out of the contrib module...
>>
>
> Not at all, they don't write the patch for you, you and your
> co-maintainers come up with the fix. You RTBC it... As for any
> secondary reviews by the security team extending the vulnerability
> window, they've been very prompt when I've dealt with them and I
> appreciated the second set of eyes. I'd feel really dumb posting a
> security fix that didn't actually fix the bug but brought it to
> everyone's attention.

I'm not doubting the intentions of the security team, nor the need  
for quality code review, just the assumption that the fastest way to  
get a release into the hands of the users is always done by single  
threading this through the security team.

FYI:  I also got a quick answer when I asked them the best way to  
patch my bug (I did consult with them after all), and I was  
appreciative of the info. but they didn't offer to review my code,  
and they didn't try to manage my patch process at the time.  Maybe  
the next time it will be different....

>
>> When I discovered a vulnerability in my CAS module,....
>>
> You seem concerned about loosing control of your module to the
> security team. I can tell you that this fear is unfounded. The
> security team is here to help, not tie your hands. And as for more
> productive tasks... this is exactly what they're here for.
>
> I don't have the energy to get into a discussion on mixing security
> and bug fixes in a release so I'll just say that I think it's a bad
> idea. The best practice would be to get the minimum patch out to fix
> the security hole and then then follow it up with additional fixes in
> a later release.

I don't either, so lets just agree that I don't run releases the way  
the security team wants me to.  Oh well.  I'd love to debate that  
over a beer sometime :)

I'm not worried that the security team will take over my module.  But  
I am concerned that if I am authoring a module that deals with a  
single sign-on protocol that the security team is not versed in and  
isn't really used by that many of the drupal users (which I am), that  
when it comes down to it, my modules "audit" as derek describes it,  
will not (and I believe rightly so) be at the top of the priority  
list of the security team. Meanwhile, I'm instructed to not commit or  
release the fix.  This is again predicated on the fact that someone  
might be able to recognize the vulnerability based on the source code  
that expresses the fix. I can't verify the patch/commit process, or  
independently install and verify the vulnerability is fixed in  a dev  
or beta release until the security team puts out an announcement  
saying the patch is ready for download.  Doing testing of committed  
code is my practice regardless of whether its a security related  
patch or not.

Given our distro system, if we're really worried about hackers  
sniffing commit logs, I would rather remove anonymous CVS access.  
That way you stop the vulnerability sniffing all together.  Like I  
said I know I'm in the minority here and don't really expect to  
change your mind on this one.

I been involved with enough volunteer organizations to know that it's  
always an uphill battle to manage workload.  I don't begrudge that,  
but I try and keep my expectations tempered.

I really hope no-one on the security team is offended.  I mean no  
such offense. I really do respect and appreciate the service that  
they provide and yes, I do consult with them when I do my security  
related fixes.
>
> andrew
>
> andrew