Security Policy Discussion

[kinggoesgaming]

Before we do release 1.0,0, we need to determine how we deal with any vunerablilities that show up in the crate or any deps that we have.

Also setup the Security Policy file.

[KodrAus]

This sounds like a great idea!

[KodrAus]

Did you have any thoughts on what should go in there @kinggoesgaming?

[kinggoesgaming]

Will brainstorm on this on my commute to work tomorrow

[kinggoesgaming]

So after sleeping over the matter, I think these these questions need to be addressed:

Who/ How to contact?

• needs to be a private means

Time to contact the reporting party?

• First action
• Affected versions
• Further steps
• etc

Security support lifetime?

What to do when we cannot resolve a vulnerability in a version due to MSRV?

What uuid versions are considered LTS?

What about 0.8.x?

How to publicly report the vulnerability?

• Disclosure policy?
• Timeframe
• Resolution steps
• Where to publish?

What versions are just to be yanked vs get a update version?

Update policy?

• how to handle deps according to Semver versioning (should help with determining which versions are likely affected)

---

@KodrAus if you think you have any other questions/ issues to be raised, add to the list.

For the matter of clarity it's best to either do each point as a separate comment; or move this to Discussions.

[kinggoesgaming]

I will start adding my 2 cents tonight after work

[kinggoesgaming]

What about 0.8.x?

[kinggoesgaming]

Provided that most crates are still on 0.8.x, we will continue to provide security only updates until 6 months after full 1.0.

After that 0.8.x will be considered End of Life and update will be provided. However, if need be, version(s) affected can be yanked.

[KodrAus]

we will continue to provide security only updates until 6 months after full 1.0.

I'm not sure we even need to go that far. Since it's pre 1.0 I don't think it's reasonable to expect us to manage backports to that branch. It seems fair to commit to providing security patches just for the current minor release, and avoid bumping anything unless it's necessary for patching.

[kinggoesgaming]

Who/ How to contact?

• needs to be a private means

[KodrAus]

A private means is a bit tricky here... We don't have any infrastructure to host a private mail address and I don't think it's necessarily a good idea to acquire one. I think it's fair to say that if there's a security vulnerability that needs to be privately disclosed then it can be directed to one of the library maintainers. We'll then use GitHub's security advisories to coordinate fixes and disclosures.

What do you think?

[kinggoesgaming]

one means we can do is list our urlo usernames where they can contact us. Then we can create Github Security Advisory draft (which are private till published) and invite them to participate, if they have a Github account.

[KodrAus]

I’ve also got contact details in my GitHub profile so people can reach me privately, which I’d be ok with using.

[kinggoesgaming]

So been working locally on getting the policy written, and I have come up with the following for contact:

• Contact the maintainers on urlo
• Contact on the contact details given on Github profile
• Create an issue mentioning that a person has found a vunerablility. (We create a private repo in uuid-rs and invite them to it to discuss.)

There is a major emphasis that the actual details of the vunerability should not be discussed in the public issue tracker.

@KodrAus Does that seem fair?

[KodrAus]

Some prior art here: https://github.com/tokio-rs/tokio/blob/master/SECURITY.md

One difference is that tokio is a commercially backed project, so they probably have better means to share infrastructure.

[kinggoesgaming]

What uuid versions are considered LTS?

[KodrAus]

If you think it's worth maintaining a LTS maybe we can pick 1.0.x? How long would you want to support a LTS for?

[KodrAus]

I haven’t actually found any Rust libraries that offer LTS releases specifically. tokio is another notable exception as it’s a framework 🤔

If we don’t have a compelling reason to do it I’m not sure if it’s going to be worth the effort to support and communicate.

[kinggoesgaming]

I think one of the big issues we can get is if a dependency has an issue but the only solution is bumping the version to something that also raises the MSRV

[KodrAus]

Hmm, pinning is problematic with Cargo already. You can end up in situations like this where Cargo refuses to resolve multiple versions of a crate if they’re semver compatible. So we can’t use any time-based scheme for LTSs where a minor version is LTS for a period of time or we’re inviting this kind of resolution failure. It also doesn’t seem good to commit to maintaining a single MSRV indefinitely so I think we don’t have any good tools for doing LTSs, and maybe should just punt it.

[KodrAus]

We can try avoid bumping our MSRV unless it’s actually necessary so they’re not bundled with patches.