Revisiting the original issue. On 1/16/08, Derek Wright <drupal@dwwright.net> wrote:
Perhaps the docs are too detailed, confusing, hard to find, or obscure. I'd like to try in short, plain english to explain what to do when you think you've found a security problem in your module:
It is apparent through Derek's plea here that module developers are not following the security teams protocol. I see 2 main reasons why: 1. Education. This will always be a challenge but helps if you have a marketable version of the information you are trying to get out to everyone. 2. Getting module developers on board with the process. As it has been pointed out several times, the point of the process is to get out important updates and announcements to Site Admins in the best and safest way possible. Well let me point out that if you make the process difficult, that will be a deterrent for developers to follow the process. While security is very important, you have to be willing to see the end value and not just the perceived value of the process. If you have an super secure process but developers don't follow it, where does that leave the Site Admins? In a much worse position than if the process was simpler and provided slightly less security proccess. It is much better to have a 90% secure process that is followed than a 100% secure process that is NOT followed. With that in mind I would like to revisit the process:
a) Either you think you find a potential security problem in your module or a user reports a vulnerability to you.
This is a description and doesn't help the marketability of the process.
b) You *immediately* send email to security@drupal.org about it to let us know.
Agreed. This easy to understand, perform and educate. Maybe also have other ways for developers & users alike to the security team that doesn't make them have to remember the email address. The more ways to contact them with important information the better.
c) You try to analyze the vulnerability to the best of your abilities, and if possible produce a patch that fixes it.
More added descriptions that doesn't help the marketability.
d) DO NOT COMMIT YOUR PATCH YET.
This stops all development and is not friendly to the developer. We have shown this step provides little to no benefit or possible harm. I think that no matter what your position on the subject is, this is an easy step to remove to make the process better.
e) DO NOT MAKE A RELEASE YET.
This too I think is going over board. I will describe more about what I propose below.
f) DO NOT MARK YOUR RELEASE AS A "SECURITY UPDATE" YET.
I think that marking something as a security release should be taken out of the hands of the developers. Only the security team should be able to do this. More info below.
g) Send your patch to security@drupal.org.
This is more work for the developer that can easily be removed by having the security team use our version control system.
h) Wait for the security team to reply.
More description.
i) Do what the security team advises you to do.
More description and slightly unfriendly in the fact is makes you feel like the security team is your boss. While I know that the security team is a great bunch of people and this is not true about the process or how they work with people, this step gives the wrong impression to those that do not know that.
j) If/when the security team thinks your vulnerability is real, the fix is complete, and a security announcement (SA) is ready to go out, we'll tell you.
This is a security team process not needed for the developer process.
k) Only once an SA is ready for your vulnerability and the security team is ready to coordinate a release, THEN (and only then) do you commit your patch to all relevant branches, tag new releases, create release nodes, and mark them as "Security update" releases.
Again, I think that this should be a security team step not a developer. See below.
l) The security team can then publish your release nodes (which doesn't happen automatically if they're flagged as a "Security update") and send out the SA, at which point your users will know they need to upgrade (both via the security announcement email lists and RSS feeds, and via the update_status module).
Agreed. Now let me propose a modified process: Developers Process: 1. Contact the security team with information about security holes. 2. Do NOT post security vulnerabilities. The Security team will take care of that. That is a very marketable process. In the handbooks and other places we can elaborate with more information if needed. Security Team Process: 1. Coordinate with the developer to evaluate the hole and fix. 2. Coordinate with the developer on which revision # is safe to publish as an Official security release. 3. Publish or mark a release as security update and send out the announcements. Let me explain these proposed processes a little. Getting knowledge into the security teams hands is the first and most important thing. Once the security team has that knowledge they can communicate with the developer on the problem and fix. The developer should go about his normal work flow except we need to educate them that only the security team should announce security holes or updates. This is to help the security race. The security team should then coordinate with the developer on what revision # is safe to mark as a security release. This could be an already published release or a revision # of one of the branches. The security team would then, at their discretion, mark or publish a release as a security release and send out announcements. I realize that many people may find that this approach is lacking in certain areas but I honestly believe the final result would be much more secure even if the the process is not as secure. We would then educate developers and users by creating a security report form and linking to it from all appropriate places. On this form page make it clear to not advertise the security hole or the fix because the security team will do a coordinated security release and announcement. It is also very easy to educate developers by just saying: "Contact the security team". Which is much easier than having grok man pages and long processes. This also makes it very easy for the security team to change their policies or procedures without having to re-educate all developers. Just my 2 cents. Thoughts? -- Alan Doucette Koi Technology, LLC www.KoiTech.net