Proposal for SECURITY.md

[hexsecs]

I took a crack at creating a SECURITY.md file. Fixes #227

[pattivacek]

The general idea seems fine. I generally prefer being as open as possible about vulnerabilities, but it makes sense to ask for some time to find solutions or mitigations first. However, this is just a standard, not an implementation, so even if we provide a solution to a newly announced vulnerability, that says nothing about whether a given implementation is actually vulnerable, nor whether our proposed solution is viable for it.

[tkfu]

I think there's one really challenging thing going on here: Uptane has a number of implementations, but most of them are private and proprietary. So while it's useful to have a responsible disclosure process for potentially-exploitable issues in the standard itself, the people who need to act on it are the authors/maintainers of those various implementations.

The problem with that is the automotive industry's proclivity for secrecy. We just don't have a comprehensive list of all the implementations out there (or at least I don't). If the issue has the potential to be exploited in the wild, a good responsible disclosure policy is a lot more complicated than it would be for a typical software project. For example, a serious enough issue could necessitate a recall, and regulatory issues surrounding recalls are complicated and different in different jurisdictions around the world.

@jhdalek55 , I think maybe we ought to put this on the agenda for the next standard meeting: what should a responsible-disclosure policy and process for Uptane look like?

[jhdalek55]

@tkfu I made a note and will include this as an agenda item for our next meeting.

[jhdalek55]

This PR provoked quite a bit of discussion at the 3/29 meeting. A side issue that emerged is that we continue to refer to the Reference Implementation even though this was archived sometime ago and has not been updated for years. PR #47 on the website repository is a first attempt at removing these references.

[jhdalek55]

My notes from the last Uptane meeting do not make it clear if we reached a decision on this. Do we wish to stipulate anything about responsible disclosure on the website? Or is this an issue better addressed as a PURE since the central issue of how we identify, notify, and/or correct problems is such a complicated and potentially serious one?

[iramcdonald]

Hi Lois, My two cents: (1) Describe/define responsible disclosure and all of its shirt-tail relatives in a PURE (2) Put only a link to that PURE in the Security.md. It would be dangerous (legally and ethically) to put the body of responsible disclosure in the Security.md page. Cheers, - Ira *Ira McDonald (Musician / Software Architect)* *Chair - SAE Trust Anchors and Authentication TF* *Co-Chair - TCG Trusted Mobility Solutions WG* *Co-Chair - TCG Metadata Access Protocol SG* *Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF Designated Expert - IPP & Printer MIBBlue Roof Music / High North Inchttp://sites.google.com/site/blueroofmusic <http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/highnorthinc <http://sites.google.com/site/highnorthinc>mailto: ***@***.*** ***@***.***>(permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434*

…

On Mon, Apr 11, 2022 at 2:13 PM Lois Anne DeLong ***@***.***> wrote: My notes from the last Uptane meeting do not make it clear if we reached a decision on this. Do we wish to stipulate anything about responsible disclosure on the website? Or is this an issue better addressed as a PURE since the central issue of how we identify, notify, and/or correct problems is such a complicated and potentially serious one? — Reply to this email directly, view it on GitHub <#231 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE33UOYKIFX76RQGXTOR2BLVERTUZANCNFSM5LH66S5A> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[jhdalek55]

Perhaps we can discuss the proposed solution from @iramcdonald above at our next meeting?

[jhdalek55]

I am proposing we move this issue to a PURE. As @iramcdonald noted, there could be consequences if we frame this incorrectly in the Standard or even the Deployment pages.

[trishankatdatadog]

Should we then close this issue, and open a PURE instead?

[jhdalek55]

I think it would make sense to move this to the PURES repo. @hexsecs any objection to doing so?

[hexsecs]

I think it would make sense to move this to the PURES repo. @hexsecs any objection to doing so?

No objection to moving it to a PURE

[jhdalek55]

Thanks. I'll take care of moving it over.

[jhdalek55]

I have opened a pull request for PURE 3 (uptane/pures#8) that converts this request into the PURE format. It is incomplete and requires additional text as well as suggested revisions. @hexsecs @pattivacek and others, please give us your input.

[jhdalek55]

@hexsecs I corrected a typo and a few other things. I think if the last few corrections are made, we can merge this.

[jhdalek55]

@hexsecs I know we are all busy, but if you can just correct the last few tiny typos, we can merge this.

[trishankatdatadog]

@hexsecs I know we are all busy, but if you can just correct the last few tiny typos, we can merge this.

I committed your changes. Please let us know if this works for you.

[trishankatdatadog]

WDYT @jhdalek55 ?

[jhdalek55]

Thanks @trishankatdatadog