Add SECURITY.md

[jpkrohling]

This pull request creates a SECURITY.md file, which has a special meaning on GitHub repositories.

The initial version is based on Jaeger's, adapted in a few places to the OpenTelemetry reality. During the review, please pay special attention to the "Ways to report": every channel should have enough people watching, in order to allow for a quick response to the reporter.

It might also be a good idea to have this prominently on the website, perhaps as a footer link named "Report a security issue". If agreed, I can open a PR for the website to include this. The question will then be which would be the source of truth in case of conflicts: this SECURITY.md, or the website. For Jaeger, we assume the website is the source of truth, but a different decision might be made for OpenTelemetry.

Once the security procedure is established, it should be communicated with all project leads: all sub-projects should contain a similar file, pointing to this one.

Signed-off-by: Juraci Paixão Kröhling juraci@kroehling.de

[jpkrohling]

cc @yurishkuro

[arminru]

Thanks for taking care of this!

Shouldn't we put this file into the community repo and have all SIGs point there? We could also use the website repo as a source of truth and have the SECURITY.md files link to it.

Also, whose key is this and who has access to the private key? I am not aware that we already have a common PGP key for the org, GC or TC. It's also not in our list of org assets (https://github.com/open-telemetry/community/blob/master/assets.md).

[jpkrohling]

Shouldn't we put this file into the community repo and have all SIGs point there?

If that repository makes more sense, I'll be glad to open a PR to add this file there.

We could also use the website repo as a source of truth and have the SECURITY.md files link to it.

The approach we have for Jaeger is to duplicate the info, so that people looking for this don't have to do an extra hop. We do link to the website, stating that in case of divergences, the website takes precedence:

https://github.com/jaegertracing/jaeger/blob/master/SECURITY.md#reporting-a-vulnerability

Also, whose key is this and who has access to the private key?

As far as I know, @yurishkuro is taking care of it and can confirm who has the keys already.

[arminru]

Suggested change

The OpenTelemetry project provides community support only for last minor version: bug fixes are released either as part of the next minor version or as an on-demand patch version. Independent of which version is next, all patch versions are cumulative, meaning that they represent the state of our `master` branch at the moment of the release. For instance, if the latest version is 0.10.0, bug fixes are released either as part of 0.11.0 or 0.10.1.

The OpenTelemetry project provides community support only for the last minor version: bug fixes are released either as part of the next minor version or as an on-demand patch version. Independent of which version is next, all patch versions are cumulative, meaning that they represent the state of our `master` branch at the moment of the release. For instance, if the latest version is 0.10.0, bug fixes are released either as part of 0.11.0 or 0.10.1.

I'm not sure if this statements work for all SIGs and if we even have to mention this here but it sounds reasonable to me.

[jpkrohling]

This doc needs to have a very clear statement of what's supported and what people should expect when they use an OpenTelemetry project.

The text from this paragraph is almost verbatim from Jaeger, and reflects our reality there. For comparison, Kubernetes is a different example where they support the last two minor versions (IIRC), so, security problems are backported to them.

In this "root" document, we could say that "individual projects might define broader support", but there has to be a minimum standard across the projects.

[arminru]

The approach we have for Jaeger is to duplicate the info, so that people looking for this don't have to do an extra hop. We do link to the website, stating that in case of divergences, the website takes precedence:

@jpkrohling I don't have any strong opinion here. It looks rather straight forward and I wouldn't expect it to be updated frequently, so keeping it duplicated should be fine as long as we take care to reflect the changes.

[yurishkuro]

Shouldn't we put this file into the community repo and have all SIGs point there?

I recommended the Spec repo for the main security document, since it is more code related than the community repo. But then, since it's about communicating, I'm fine with the community repo as well. The key thing is for all other repos to have similar files that all point to the main file.

[andrewhsu]

from the issue triage mtg today, labelling this as allowed-for-ga since this is not related to the spec but admin updates for the repo

[arminru]

@open-telemetry/technical-committee please review

[tigrannajaryan]

What does "on-demand patch version" mean?

[arminru]

I think it's meant to say "rather than waiting on the next minor version being due as per our (hypothetical) release schedule, we'll publish a patch version fixing the issue as soon as possible". Right, @jpkrohling?

[tigrannajaryan]

Makes sense. It would be nice to make the text clearer.

[jpkrohling]

That's absolutely correct.

[arminru]

@open-telemetry/governance-committee Please review.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[arminru]

@open-telemetry/governance-committee @open-telemetry/technical-committee Please review.

[jpkrohling]

This is still missing a review from @open-telemetry/governance-committee.

[tedsuo]

The OpenTelemetry project provides community support only for the last minor version

Since we haven't finished defining versioning for OpenTelemetry, let's make sure we don't end up with conflicting definitions. cc @andrewhsu

[andrewhsu]

Since we don't have a GA release yet and the specifics of release branch has not been formalized yet on all the SIGs, I suggest we punt on the wording related to the branch name.

i.e. i suggest change:

Independent of which version is next, all patch versions are cumulative, meaning that they represent the state of our master branch at the moment of the release.

to

Independent of which version is next, all patch versions are cumulative.

[tedsuo]

Shouldn't we put this file into the community repo and have all SIGs point there?

Based on the content of this file, and the audience, I agree with the above statement. Security and reporting procedures should live in the community repo, next to COMMUNICATION.md, code-of-conduct.md, etc.

Other than that, I approve the content. Thank you for putting this together @jpkrohling!

[andrewhsu]

LGTM w.r.t. getting a procedure in place to receiving security bug fixes

my suggested changes are optional in my mind

[jpkrohling]

Security and reporting procedures should live in the community repo, next to COMMUNICATION.md, code-of-conduct.md, etc.

Should I move this file elsewhere then?

[arminru]

@tedsuo I think we can assume the content of the policy here approved as-is since everyone seems to be fine with that and should publish it in a "default community health file repo" as @andrewhsu suggested on open-telemetry/community#544.

[jpkrohling]

Closing in favor of open-telemetry/.github#1

[yurishkuro]

How would people discover .github repo?

[jpkrohling]

From what I understood, .github is a special repository: files in this repository will show up in all repositories from the organization, unless they explicitly exist. We should consider doing that for Jaeger as well :-)