www.ruby-lang.org
www.ruby-lang.org copied to clipboard
security disclosure policy
ref. http://bugs.ruby-lang.org/issues/5821
In short, I think:
http://www.ruby-lang.org/en/security/
should do more to emulate:
http://jruby.org/security
Namely, we don't have a "Disclosure Procedure" section:
> Disclosure Procedure
>
> The JRuby team will endeavor to follow these steps when handling reported vulnerabilities:
>
> 1. Work with the reporter to determine the appropriate fix within 24-72 hours of the initial email report.
> 2. Once the fix has been found, wait for an embargo period of 48 hours.
> 3. After the embargo has passed, push out a new software release containing the fix.
> 4. Send email announcement on jruby-user mailing list containing source patch for most recent release.
> 5. Post an announcement on jruby.org and list below.
Can we get something like this added?
It is https://bugs.ruby-lang.org/projects/ruby/wiki/SecurityFixProcess
We don't have time schedule.
I would strike the embargo period. Once the patch has been tested against the exploit and passed regular testing, it should be announced ASAP.
I don't think that an embargo period like that is a standard practice, at least I haven't seen it before. Neither is a deadline for when a fix will be available. Some issues are more complicated than simple one-line patches and may require research and re-engineering to handle properly. I don't think the JRuby statement is one that you want to copy.
I think the most important thing you can state is what kind of communication that a vuln reporter can expect after they've reported a flaw. The number one cause of someone going rogue and dropping their 0day before you fix it is because they feel lost and don't understand current remediation efforts.
To that end, I think you should describe your process in the simplest terms possible to prevent any confusion: Step 1: You report the bug to us Step 2: We triage it and work privately with you to fix it Step 3: We prepare a new software release with the fix and prepare an announcement Step 4: We release our announcements and the fixed software
If you really want to include some kind of time schedule, the schedule should refer to the communication between your group and the reporter. Ie, we will respond to your email and triage the issue (determine if it is a real issue) within 48 hours, we will send you an update on the status of the fix biweekly until the issue has been fixed, we will information you of the scheduled date that the software will be released, etc.
For reference, here is the current best practice for "coordinated vulnerability disclosure" from Microsoft: http://go.microsoft.com/?linkid=9770197
This is not written in a documentation for users, before announcement we must inform distributors that we are releasing security fix. Distributors means debian, RedHat, and so on.
Actual process inside security@ is
- receive a mail
- reply the initial response
- discussing the issue
- making a patch
- reviewing the patch
- fixing a patch
- reviewing the patch
- fixing a patch
- pass the review
- decide and inform the release datetime distributors, other implementers, and platformers
- announce the vulnerability and release the security fix
Ah, I didn't think of that. Yes, you definitely want to inform your distributors before releasing a security fix and give them time to re-package the affected software. However, I'm leaning towards thinking that the head start you give your distributors is an internal policy that informs how you schedule your release dates and doesn't need to be listed on the public website. I'm not certain information about how you decide on a release date needs to be set in stone and described on the website.
Besides JRuby, are there any open-source organizations that have a reputation for excellence in handling security vulnerabilities and communicating them to distributors?
Rails Security Policy. They also have an Embargo, but I'm not sure if Rails copied that from JRuby?
I think "embargo" corresponds reviewing in my process list. They would fix patch if someone found an issue in embargo.
What's the status with this issue? Maybe we should close it considering we now have a "Reporting Security Vulnerabilities" section? @hsbt