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 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, 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 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 :)