Just somw thoughts.. - Everyone "watching/monitoring" cvs for security holes doesn't wait for a "security" release to be published. It happends in a coordinated release as the SA flow, or in not really coordinated releases. - Doing a coordinate release will close the time window for those monitoring only drupal security releases, what is good in any case. The people doing extensive monitoring will not be stopped even in a coordinated release, as not every people can update their sites, nor even know about the security release tags. - Note: despite about hackers looking for site ownage.. there's already paying services to simply get as stealthly as possible a list of real live email addresses. This is a more real worry than a "hacker" trying to do a php worm to deface any drupal site. It happends also in joomla, wordpress and any other web application, where the more close to a community is the application, bigger is the fee.. Some email addresses can be sold for $1 each if they deserve. Drupal users/administrators should be encouraged to know about the security relevant information of drupal, I don't know, maybe while they wait the download process to finish. I know a few people hearing how good drupal is, downloading, testing, and using their site.. after a year they realized they did nothing about site security, or module updates. Some of this sites are still published as they were installed.
I think Greg's email best summed it up. We're worried about potential hackers finding out about security vulnerabilities before Drupal site maintainers have a way to plug the holes. It's one of the few downsides of a fully open source project -- everyone, friend or foe, can see what's happening with the source all the time.
For sure I can tell you this is happening outsite of drupal scope.
We have no way to know this for sure, only speculation (on all sides). Given that we're operating completely in the dark on this, in the interest of caution/safety, we should probably assume that hackers are paying more attention here, not less. Certainly, they're going to be sad hackers if all they do is wait around for commits that are patching vulnerabilities.
These hackers do not have to be sad people.. everybody is free to have it's own hobby.. IT's true also, that some scripts can do almost 90% of the job in automated vulnerabilities finding, and more than 90% if the scope of code is well defined: for example, drupal scope including drupal API.
Presumably, they're doing other things: their own audits, automated tests/tools, whatever. However, for the sake of argument, let's assume they're *also* watching the commits at some level. Agreed?
The cvs is already being monitored, I know (I'm not saying they are friends in any case) some people doing it, not only in drupal, but in many many cvs svn or even websites. I myself have spent sometime monitoring www.debian.org website. In the front page of that site, new security updates about debian packages are being published. It's one of many resources being used to track and pick vulns. Also, the tools they use to program, these named "automated test/tools" are of course, tools to better find vulns in cvs diffs, between others..
3) Disagreement about how much it helps to obfuscate the commit message regarding security patches. DragonWize, you're not being consistent here:
Tagging a release only "security", and including only the security patch code makes finding the vuln very very easy. Here DragonWize has some kind of reason.. Even if you tag the update as security, just to keep update_status tracking the new release, the diff of the two versions can make a little difficult to really find the security code before many sites could be patched.
Really, your claims about "not putting a line number for the exploit in the SA" boil down to security through obscurity. The problem is that if the fix goes into CVS days or weeks before an official release goes out and a security announcement is published, that interested readers (hackers) will (potentially) know about the problem long before users can defend themselves against it.
I agree with Derek here. If fix a security bug, you probably comment the code with the security information, or update an issue post. This may advise a group of "monitoring" people about the flaw, even if others may have found it time ago. The security tag should go close to the release of the SA from drupal.
Really, once the SA happens, it's just a race to try to get everyone to upgrade before hackers have much of a chance to exploit it. All we can do to help that race is try to make sure everyone's on the security announcement list, everyone's running update_status.module, everyone's subscribed to the security RSS feed, and make it easier and easier for people to upgrade their site. The point is when does the clock start ticking for both parties in the race? We'd rather start everyone at the same time and give them a fair chance, than ever give the hackers a head start in any way.
The only way to get this working is doing a coordinated release.
p.s. Note: no one on the security team has any illusions that this process, alone, leads to complete security for all of Drupal. Of course there are many vulnerabilities in contrib, and probably still some in core, and it's entirely likely that hackers know about these and we don't. That's a completely separate question from the situation of how we handle it when we *do* find out about a vulnerability. The solutions to the former problem are getting more security experts involved on the security team, better automated tools/tests for our side, more general awareness and concern about security in the Drupal community (both users and developers), etc, etc. All of that is worthy, and on-going, and we always need more help. But, that's off topic from the point of this particular thread.
The cvs server is a powerfull tool, and can help to automate many process on commit, as check some security basic tests on each file, or even launch audit processes.. I agree again here. If drupal sec team is (or feels) in somehow resposible of the contribs module's security status, should start monitoring them as others do. Sorry if I bother you, it's just an oppinion :)