-
Notifications
You must be signed in to change notification settings - Fork 189
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
Comments
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 |
This issue should be moved to a mailing list, no? Or to rubysec/ruby-advisory-db#64 |
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. |
@drbrain But someone has to make up the guidelines and a how-to-post and distribute advisories :)
|
@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:
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. |
@mocoso why don't you add the some of your previous comment in a PR? |
…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
Closing this due to the security page added in #89 |
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.
The text was updated successfully, but these errors were encountered: