On Jan 17, 2008, at 2:37 AM, andrew morton wrote:
On Jan 16, 2008 9:08 PM, David Metzler <metzlerd@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