Help around writing security policies?

[HadrienG2]

So, I'm going through the exercise of writing down a security policy for a soon-to-be-released project of mine, and it's the first time I do this sort of thing so I feel very uneasy and was wondering if someone around here could give me some quick review of how good/bad/ridiculous these terms are.

Here's what I currently have in mind

# Security Policy ## Supported Versions This project aims for strict [SemVer](https://semver.org/) compliance. This means that upgrading to a new minor or patch version should be trivial, but upgrading to a new major version may incur some significant costs. With that in mind, if we denote major.minor.patch the SemVer version number, the policy for security updates support is that... - The latest major.minor.patch version published on crates.io is supported (obviously). - Each previously published major release remains supported, for users of the latest minor.patch version, during 6 months after the release of the next major release. ## Reporting a Vulnerability So you found a vulnerability in `hwlocality`, and want to report it in a responsible way. Thank you! Please start by assessing whether the vulnerability only affects users of the `hwlocality` Rust bindings, or would also affect direct users of the underlying `hwloc` C library. If the problem lies in `hwloc` itself, the preferred course of action is to [directly report the vulnerability to the `open-mpi/hwloc` project](https://github.com/open-mpi/hwloc/security), so that it can be fixed with the broadest user impact. To avoid effort duplication between the two projects, mitigation of such issues at the `hwlocality` level will only be considered if you have correctly followed the above procedure and can convincingly argue that the `hwloc` developers are not responding to your vulnerability report in an appropriate and timely manner. If the problem only affects `hwlocality` users, or if for some reason it is a much greater issue for `hwlocality` users than for `hwloc` users (e.g. some safe Rust API mistakenly exposes a pattern that is illegal at the C level like a dangling pointer or a null pointer dereference) then please [submit a security advisory](https://github.com/HadrienG2/hwlocality/security/advisories/new) that describes the vulnerability, assesses its impact, and provides instructions on how to replicate the issue locally. If you have a patch that adresses the issue, please also submit it there for discussion. As this project runs on volunteer effort, message replies within a week should be expected but cannot be guaranteed. If you do not get a reply within two weeks, please ping back in case the message fell through some mailbox crack. Absence of reply within a month is suspicious and should warrant another maintainer ping. After two months without a reply from our side, please feel free to consider the project abandoned and report the vulnerability publicly. In the normal case, after making sure we agree on the general mechanism and impact assessment, we will work on a fix, then a patch release will be published for all supported major versions (see above). From this point on, attackers closely following the `hwlocality` project's public releases will know that something is up, which amounts to some degree of vulnerability disclosure. At the same time, downstream clients of `hwlocality` may not have switched to the new patch release yet, so some embargo period before a high publicity announcement may be desirable on their side. As we are not directly in touch with downstream clients, we leave it up to you to work out this tradeoff with them. Also, in the event we would disagree with you on the fact that something is a vulnerability and you did your best to convince us otherwise to no avail, without witholding any information that could change our mind, it is obviously your call to proceed with an immediate public vulnerability disclosure. ---

In general, I think this is a task that could use some better templates than the very basic placeholder proposed by GitHub for SECURITY.md, so I would greatly appreciate it if you could highlight some great examples of pre-existing security policies you know about. Maybe provide links somewhere in the rustsec umbrella resources (website, this repo's README, etc)?

[tarcieri]

Here's the ones we use in the @RustCrypto project: https://github.com/RustCrypto/traits/blob/master/SECURITY.md

I think the most notable thing there is it uses GitHub's private vulnerability disclosure form.

[HadrienG2]

This is what I went for in the end: https://github.com/HadrienG2/hwlocality/blob/master/SECURITY.md . Please feel free to steal it if you end up following my suggestion of providing some security policy examples for Rust projects :)