Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A guide to security vulnerabilities and best practices #62

Closed
mocoso opened this issue Oct 5, 2013 · 7 comments
Closed

A guide to security vulnerabilities and best practices #62

mocoso opened this issue Oct 5, 2013 · 7 comments

Comments

@mocoso
Copy link
Contributor

mocoso commented Oct 5, 2013

It would be really useful to have a guide to indicate best practices for

a) Users of gems who spot security vulnerabilities on how to report issues and...

b) ...gem maintainers on how to distribute information about new releases they have made to their gems to fix security vulnerabilities.

@bf4
Copy link
Contributor

bf4 commented Nov 22, 2013

Do you have any thoughts on the matter? There is now a security page where this information may fit http:https://guides.rubygems.org/security

@bf4
Copy link
Contributor

bf4 commented Dec 12, 2013

This issue should be moved to a mailing list, no? Or to rubysec/ruby-advisory-db#64

@drbrain
Copy link
Member

drbrain commented Dec 12, 2013

I think these best practices should be included on guides.rubygems.org with pointers to rubysec/ruby-advisory-db for a place for authors to report vulnerabilities in their published gems.

@bf4
Copy link
Contributor

bf4 commented Dec 12, 2013

@drbrain But someone has to make up the guidelines and a how-to-post and distribute advisories :)

  1. How does one report gem security issues to an author/rubygems.org/rubysec and
  2. How should a gem author should publicize the gem security release. (very few seem to [ANN] on ruby-lang or check it)

@mocoso
Copy link
Contributor Author

mocoso commented Dec 12, 2013

@bf4 the reason I originally raised this issue was was that I was trying to find out what best practice in this area was and could not find good guidance. When I asked on the London Ruby User Group (my local group) mailing list no one else seemed to know either.

It seems to me that the easier we can make this i.e. here is a clear guide to follow which tells you who to contact and what to tell them the more likely it is that people will report issues.

Even writing something as brief as:

  1. To report a security issue with someone else's gem

    Contact the author(s) privately (i.e. not via a pull request or issue on public project) explaining the issue, how it can be exploited and ideally offering an indication of how it might be fixed.

  2. To report a security issue with your own gem

    2.1 OSVDB: email [email protected] and/or message @osvdb on GitHub or Twitter.
    2.1 Request a CVE from oss-sec mailing list or reserve a CVE from MITRE.

  3. To tell people about a patched version of your gem

    [ANN] on ruby-lang

Would be an improvement on where we are now. Over time each of these sections could be expanded and clarified or link off to guides to these particular actions elsewhere.

@bf4
Copy link
Contributor

bf4 commented Jun 13, 2014

@mocoso why don't you add the some of your previous comment in a PR?

mocoso added a commit to mocoso/guides that referenced this issue Jun 29, 2014
…to the security page.

The information about requesting a CVE is taken from
https://cve.mitre.org/cve/request_id.html

It seems much less clear how to tell the world about your
issue and with no well recognised route, as far as I can tell.
In the absence of any well trodden route I have suggested the
ruby-talk mailing list since people already use this to
announce new versions of gems.

Further discussion can be found in issue rubygems#62
@drbrain
Copy link
Member

drbrain commented Sep 25, 2014

Closing this due to the security page added in #89

@drbrain drbrain closed this as completed Sep 25, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants