Define security policy

[iinuwa]

Closes #86

[msirringhaus]

lgtm, but I'd recommend waiting for feedback from @AlfioEmanueleFresta, as I'm not well versed in these kind of statements

[msirringhaus]

nit: word order "but we may decide not to address"?

[iinuwa]

Yeah, you're right, that's not what I intended to convey. I think it's even more clear to say:

Suggested change

	the issue privately, but we may not decide to address it within the response
	the issue privately, but we may decide to address it beyond the response

[kalvdans]

Great document to have, but please define all users of "we" a bit closer. I take it that potential vulnerabilities reports go to the github project maintainers, which individuals I believe is not open information. But since this in an open-source project, it is a broader group of collaborators that decides about features and scope of the project.

I've suggested some concrete changes, but I'm not a good text writer myself.

[kalvdans]

Suggested change

	We only support the latest published release. We may backport patches when
	possible to help users running on distributions that package older versions of
	our software.
	The security team only respond to reports about the latest published release.
	Collaborators may backport patches when possible to help users running on distributions that package older versions of the software.

[kalvdans]

Suggested change

	## Security Team
	The security team consist of the github project maintainers, which list of indivuduals are kept closed and
	might change over time.

[kalvdans]

Suggested change

	In the future we may offer stricter configuration where privileged clients
	In the future the service may offer stricter configuration where privileged clients

[iinuwa]

Great document to have, but please define all users of "we" a bit closer. I take it that potential vulnerabilities reports go to the github project maintainers, which individuals I believe is not open information. But since this in an open-source project, it is a broader group of collaborators that decides about features and scope of the project.

I've suggested some concrete changes, but I'm not a good text writer myself.

Thanks for the feedback, @kalvdans! I've clarified in the opening sentence that "we" refers to the project maintainers. While we accept contributions from the community, I think putting security responsibility on contributors wouldn't be fair since they don't have control over the code. I think it's important for the responsibility for features to be kept by those who have permission to merge and release the code, so I've kept the "we" language throughout. We'll take backports on a case-by-case basis.

[AlfioEmanueleFresta]

Looks good to me! Added a few comments, feel free to choose which, if any, to address.