Add SECURITY.md

[icyphox]

Fixes #584

This PR is up for debate/discussion. What else needs to be added to this?
Also, we need an email to receive reports.

[coveralls]

Coverage remained the same at 67.23% when pulling 20dc77e on icyphox:security-policy into d3744d4 on pythonindia:master.

[pradyunsg]

This should live in the documentation as the "security policy" page.

You'll probably want to note that security issues should not be filed publicly and sent via email to the developers/maintainers (ideally by providing an email here).

The language of the "reporting a bug" seems to be more in line with something for the contributing guide.

Further, it references the use of email and a security team, which haven't been mentioned in the rest of the document.

[icyphox]

This should live in the documentation as the "security policy" page.

I'm not sure I agree. The security policy for the project should be easily noticeable and not some page hidden away in the docs.

You'll probably want to note that security issues should not be filed publicly and sent via email to the developers/maintainers (ideally by providing an email here).

Agreed, I'll add this in. I've also mentioned the need for an email to receive reports in the first comment.

The language of the "reporting a bug" seems to be more in line with something for the contributing guide.

Well, it's the standard format followed by platforms like HackerOne, for reports. I figured it'd fit in here as well. What do you suggest?

Further, it references the use of email and a security team, which haven't been mentioned in the rest of the document.

Yeah, again, we'll need an email from Junction's maintainers. /cc @zerothabhishek

[pradyunsg]

The security policy for the project should be easily noticeable and not some page hidden away in the docs.

Would the way Django handles their security policy serve as enough prior art to justify my position? PyPI also has a section in their documentation, that links to a page that's rendered at https://pypi.org/security.

Neither project stores it the root of the project's repository.

What do you suggest?

Something like what Django does, should be good enough for us:

Short version: please report security issues by emailing security@.com.

Most normal bugs in Junction are reported to our public GitHub issue tracker, but due to the sensitive nature of security issues, we ask that they not be publicly reported in this fashion.

Instead, if you believe you’ve found something in Junction which has security implications, please send a description of the issue via email to security@.com. Mail sent to that address reach a security team.

I think it is also important to note that given that this project does not have any active maintainers, it's probably better to not promise a timeline for a response to the reporter.

[icyphox]

Would the way Django and PyPI handle their security policy serve as enough prior art to justify my position? Neither store it the root of the project's repository.

Fair enough. In that case, I'll close this PR and you can proceed to add the security policy over at #577.

Something like what Django does, should be good enough for us:
...

LGTM.

I think it is also important to note that given that this project does not have any active maintainers, it's probably better to not promise a timeline for a response to the reporter.

Let's wait on @zerothabhishek for a final take.

[pradyunsg]

Fair enough. In that case, I'll close this PR and you can proceed to add the security policy over at #577.

Yea, either of us can add it in a follow up PR to #577. I don't want that to be held up due to a discussion on the exact security policy we end up with.

[ananyo2012]

@palnabarun We should create a email alias via magudi for reporting security issues. Then we can proceed with the documentation. Can you keep it as an action item when you update the PyCon 2020 email aliases in magudi ?

[palnabarun]

Sure. 👍

[ananyo2012]

Let's go ahead with webmaster@in.pycon.org which I believe exists already. @pradyunsg You may want to add a SECURITY.rst when you update the documentation.

[pradyunsg]

Closing since #584 is the tracking issue and we're going to be taking a different approach for documenting our security policy (in the built documentation vs as a security.md file).