*: clarify how security issues are handled

[cyphar]

This PR is in response to the discussions on the ML about the new
security mailing list and how these documents don't match what
the security@opencontainers.org mailing list should be for.

The security@opencontainers.org mailing list is for maintainers only,
and is to be used for technical discussion about potential security
issues. It is not a place for the TOB to have votes about
specification-related business, simply because it is not sane to include
people who are not maintainers of projects in critical security
discussions of said projects.

If in the future we discover that we need to have a place to vote on
security issues, the TOB can do that on their own private mailing list.
For now, we should focus on making sure that security disclosures on
actual shipping code is actually done properly.

Signed-off-by: Aleksa Sarai asarai@suse.de

[jonboulle]

If are

[cyphar]

fix'd

[vbatts]

LGTM

[crosbymichael]

LGTM

[philips]

LGTM

[wking]

On Wed, Nov 30, 2016 at 01:26:29AM -0800, Aleksa Sarai wrote: The ***@***.*** mailing list is for *maintainers only*, and is to be used for technical discussion about potential security issues. It is not a place for the TOB to have votes about specification-related business…

GOVERNANCE.md is about maintainers voting on project direction, not about the TOB (which is why I pushed back against involving the TOB here at all [1]). You still need *maintainer* votes about handling the security issue, because the actions will be things like: * This is not actually a security issue, it can go in a public issue/PR. * This is a security issue, and we're accepting this patch for a new 1.0.1 patch release. We're pushing that release out to trusted consumers privately and will make the patch and release public once they've had time to deploy it. Both of those are important enough decisions that I think the usual formal governance process applies. You just want the motions and votes to happen in secret (to be published later). [1]: opencontainers/tob#15 (comment)

[cyphar]

@wking Read the patch -- you're in violent agreement with the main change (that it's for maintainers not the TOB). I disagree that we need to go through motions and counter-motions to fix a security issue -- that's just adding friction to maintenance of a project which is just insanity and process for process's sake.

[wking]

On Wed, Nov 30, 2016 at 11:02:51PM -0800, Aleksa Sarai wrote: … you're in violent agreement with the main change (that it's for maintainers not the TOB).

Yes. But you cited “not a place for the TOB to have votes” in your motivation, so I wanted to point out that the old language was not about the TOB having votes. The TOB was providing a channel for the maintainers to reach a consensus and helping to notify “affected parties” (although who that is is still not clear).

I disagree that we need to go through motions and counter-motions to fix a security issue -- that's just adding friction to maintenance of a project which is just **insanity** and **process for process's sake**.

Saying “here's what I think we should do: $MOTION” followed by a string of LGTMs doesn't seem like overly much process to me. With active maintainers, that sort of thing should go quickly and smoothly in most cases. When it doesn't go quickly and smoothly, it will be because there isn't a landslide consensus yet, and that's exactly the case where you want a formal procedure for determining a consensus. One of the hiccups with the current governance approach is that often several maintainers don't vote at all. I expect they'd be more attentive to security notices though. And where the security issue impacts a non-spec repo's release you only need the lesser of three LGTMs or ⅔ of maintainers [1]. So I really doubt collecting that many LGTMs for a security release would be a serious hurdle. [1]: https://github.com/opencontainers/project-template/blob/3eec2a6382c7264073542b4a95024678ee41f0bc/GOVERNANCE.md#quorum

[wking]

To put something concrete behind my desire to remove the TOB but keep this section, I'd like something like:

Motions with sensitive security implications MUST be proposed on the security@opencontainers.org mailing list instead of dev@opencontainers.org, but should otherwise follow the standard proposal process. The security@opencontainers.org mailing list includes maintainers of all OCI projects. Project maintainers SHOULD notify affected parties before making an adopted motion public.

Although I'd be even happier with {project}+security@ lists (in addition to an all-maintainer security@ for folks who can't figure out which project their bug belongs to?) and clarity around “affected parties”.

[crosbymichael]

@caniszczyk please take a look.

[caniszczyk]

LGTM

[wking]

On Thu, Dec 01, 2016 at 11:56:15AM -0800, Chris Aniszczyk wrote: Merged #22.

My impression was that GOVERNANCE.md amendments were supposed to follow the usual voting procedures [1]. Ignoring the mailing list recommendation (only a SHOULD) [2] and counting @cyphar as a LGTM (although #18 is still in flight and it doesn't look like he explicitly LGTMed this PR) this motion is still: * +4 -0 #18 for the OCI as a whole. * +3 -0 #6 for runtime-spec. * +2 -0 #5 for image-spec. * +3 -0 #8 for runtime-tools. * +2 -0 #7 for image-tools and runC. Perhaps we should revise the amendment procedure to reflect our desired approach? Or is the goal to merge things with a few LGTMs here and then have more formal acceptance votes on a per-project basis? If the latter, that seems like it might make consistency difficult, since there's less incentive for projects to agree on changes at the OCI level. [1]: https://github.com/opencontainers/project-template/blob/3eec2a6382c7264073542b4a95024678ee41f0bc/GOVERNANCE.md#amendments [2]: https://github.com/opencontainers/project-template/blob/3eec2a6382c7264073542b4a95024678ee41f0bc/GOVERNANCE.md#proposing-a-motion