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

Already on GitHub? Sign in to your account

Improve Process & Documentation for Security Issues #7143

Closed
evilpacket opened this Issue Feb 18, 2014 · 6 comments

Comments

Projects
None yet
3 participants

While I know that a security mailing list has been established to announce security issues related to node. As well as a email security@nodejs.org

I don't believe the process as it exists is documented well enough and located at a convenient enough location to be as accessible as it should be.

We should establish the page at nodejs.org/security and recommend documenting it and structuring it in a similar way to the ember security page. I also believe this process should be described in a SECURITY.md file.

It also makes it clear how the process should work, communications expectations, and makes it easier to find for "researchers" who might get frustrated and just pop a public issue or go full disclosure. It also makes it clear for users that want to report or find out about security issues as patches become available.

These are good ideas and I'm fine with them, but there are a couple things
that we don't control and screw this up.

First are those who report an issue that don't realize it's security
related. Instead they see it as just a bug.

Second are those who might find what they think is a security issue, but
not having much background in security related things, go ahead and just
post it to the issue tracker. Possibly even under the title "[security]
blah blah" or some such. I used to be in this group before getting serious
into open source programming. Finding things like, "Hey, this is funny. I
found a way to DOS the server" or some such. Don't underestimate those who
know nothing about the program to mess with it in ways none of us thought.
:P

Both of these are problematic because GitHub doesn't have the ability to
select that an issue is security related when posting. Or if afterwards the
issue is found to be security related there's no way to hide it from the
public. This makes tracking any security issues a bit of a pain in the ass.
Also add that of not easily being able to include those in the loop we know
are affected by the security issue.

So, honestly, the best solution would be to migrate away from GitHub's
issue tracker. Unless they pull their heads out and add this functionality.

Certainly there are always mistakes and screw-ups along the way that
disclose security issues, in any number of ways, including pure negligence.

As for issue tracking...we have pushed for this functionality from
github in the past and from my discussions with them it's not a trivial
change to make happen. However the process and documentation and
publication of those things can be done even without a proper issue
tracker in place. I know it's not ideal, but we certainly could make a
few strides to improve in this area, even if it can't be 100% ideal
right away.

Trevor Norris mailto:notifications@github.com
February 17, 2014 at 10:52 PM
These are good ideas and I'm fine with them, but there are a couple things
that we don't control and screw this up.

First are those who report an issue that don't realize it's security
related. Instead they see it as just a bug.

Second are those who might find what they think is a security issue, but
not having much background in security related things, go ahead and just
post it to the issue tracker. Possibly even under the title "[security]
blah blah" or some such. I used to be in this group before getting serious
into open source programming. Finding things like, "Hey, this is funny. I
found a way to DOS the server" or some such. Don't underestimate those who
know nothing about the program to mess with it in ways none of us thought.
:P

Both of these are problematic because GitHub doesn't have the ability to
select that an issue is security related when posting. Or if
afterwards the
issue is found to be security related there's no way to hide it from the
public. This makes tracking any security issues a bit of a pain in the
ass.
Also add that of not easily being able to include those in the loop we
know
are affected by the security issue.

So, honestly, the best solution would be to migrate away from GitHub's
issue tracker. Unless they pull their heads out and add this
functionality.


Reply to this email directly or view it on GitHub
joyent#7143 (comment).

Totally agree with you. Just makes me wonder when the line will be drawn and Node decides to move beyond this.

Looks like joyent#6449 at least starts the process by adding a link to the community page... been sitting around a while. What's the process to move these things forward?

Owner

jasnell commented May 28, 2015

@evilpacket @trevnorris ... is there reason to keep this open here?

not from me.

@jasnell jasnell closed this Jun 1, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment