www.ruby-lang.org icon indicating copy to clipboard operation
www.ruby-lang.org copied to clipboard

security disclosure policy

Open hsbt opened this issue 12 years ago • 7 comments

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.

hsbt avatar Apr 18 '13 08:04 hsbt

I would strike the embargo period. Once the patch has been tested against the exploit and passed regular testing, it should be announced ASAP.

postmodern avatar Apr 18 '13 08:04 postmodern

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

dguido avatar Apr 18 '13 19:04 dguido

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

nurse avatar Apr 18 '13 19:04 nurse

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?

dguido avatar Apr 18 '13 23:04 dguido

Rails Security Policy. They also have an Embargo, but I'm not sure if Rails copied that from JRuby?

postmodern avatar Apr 19 '13 00:04 postmodern

I think "embargo" corresponds reviewing in my process list. They would fix patch if someone found an issue in embargo.

nurse avatar Apr 19 '13 07:04 nurse

What's the status with this issue? Maybe we should close it considering we now have a "Reporting Security Vulnerabilities" section? @hsbt

siaw23 avatar May 29 '22 16:05 siaw23