Add a `.well-known/security.txt` that links to https://www.rust-lang.org/policies/security

[carols10cents]

Summary

Add a plain text file accessible at https://www.rust-lang.org/.well-known/security.txt that contains this text:

Contact: https://www.rust-lang.org/policies/security
Expires: 2025-05-15T00:00:00.000Z

Motivation

RFC 9116 proposes a machine-readable standard for websites to convey their security information. As a security-conscious project, we should participate. https://securitytxt.org/ contains more info on this idea.

Because our security information is already on https://www.rust-lang.org/policies/security, rather than duplicating that information, the spec of the security.txt file allows us to put a URL as the contact and direct people there.

Setting an "expires" date that is not "forever" is recommended to encourage periodic review; I chose Rust's birthday in about a year as the expiration date but that was rather arbitrary and I'm open to alternatives.

Drawbacks

• Periodic review and date updating will be needed.
• This may increase the automated reports the security team gets.

Rationale and alternatives

• We could serve this file from /security.txt as well as .well-known/security.txt.
• Someone with access to the PGP key could sign it.

Maintenance

The maintenance of this will likely be:

• Notice that the expiration date in the file is in the past
• Verify that https://www.rust-lang.org/policies/security is still the canonical resource for security information
• Send a PR updating the expiration date to be in the future

and would be a great task for a new contributor.

If we decide to sign it with the PGP key, someone with access to the key will need to re-sign it at whatever cadence we choose. This could also be a good low-stakes test that people who are supposed to have access to the key still have that access.

Ultimately, this will be the responsibility of the @rust-lang/security team, so they should approve this idea. I'm happy to send in an initial PR with whatever content they would like.

Unresolved Questions

Should any of the other optional fields be filled in? See https://securitytxt.org/ for a handy generator.

[Manishearth]

In favor from the website team side.

[senekor]

Should be easy to implement, just one question: What is the mechanism by which we "Notice that the expiration date in the file is in the past"?

Maybe I could add a test that fails if the date is in the past? It won't be immediate, but we'd notice at the next PR. It could include an error message with instructions to check if /policies/security is still the source of truth.

I suppose this still needs the green light from the security team?

[carols10cents]

The mechanism I had in mind as "the simplest possible thing that could possibly work" is that someone using a tool that scans .well-known/security.txt or looks at it notices the date is in the past and emails us. I'm open to whatever though!

[senekor]

Here's a PoC where an expired date fails CI: #2016

[Manishearth]

cc @pietroalbini @cuviper for the security team perspective

[cuviper]

Seems reasonable to me.

I think I'll probably forget about the expiration unless there's something to remind us, but maybe nobody noticing will also be a sign that nobody cares...

[Manishearth]

I think having the CI may be enough, along with a Google Calendar reminder.

I'd say the CI should start failing a month or two before expiry, and website team members are free to bump the date whenever they feel like it provided they verify that that page still works, and that they cc the security team when doing so.

[pietroalbini]

Happy with it, the only concern is I'll forget to update it.