Greetings,
Yesterday during the informal security working group meeting, we had a lighter and somewhat of a different attendance due to just the nature of schedules.
We didn't end up diving into the high level requirement extraction which is where our first meeting started approaching, and in this meeting we started heading into the question of the principals and high level requirements as a starting point to building consensus.
While we have some core themes we collected in the etherpad[0], what is likely needed is a stated principal or set of principles, much like the four opens. Something to set a tone is what is needed. It was noted in discussion that a principal could be as simple as an item in the project confirmation guidelines, but that might not set the overall tone required. I'm sure future discussion amongst the board will help bring consensus as time moves forward. One interesting aspect we need to keep in mind as we move forward, we're not just talking about aspects which relate to the foundation, but the expectations to have of our communities as well as expectations as it relates to how packagers/distributors engage.
To cover some of the core themes, it was noted: - Open Infrastructure means a long-term investment in both trust and security. - No new release of software from a project should ever take place with a known vulnerability. This means guidelines and project level processes would be necessary as well, and highlights a need for an upper level principal statement to drive consensus. - Users should have a forward path they can take, i.e. to upgrade.
One challenge I've encountered writing this email is we can be vague with a principal to set a tone, except any attempt to be specific begins to take us down the path of expectation setting. Setting a requirement is also easy, but expectation setting requires specific dialog in that specific context. As a result, I think the best path to a principal statement is reaching consensus along the lines of "Security is a primary concern for all OpenInfra projects, second only to the project's specific problem it seeks to solve."
With an established principle, we can then begin to set requirements at the foundation level, and then engage projects to ensure requirements are clear, communicated, and are appropriately documented. Documentation is also critical as packagers/distributors and regulatory/market surveillance authorities will need a clear understanding of relationships and how to engage specific projects should issues arise.
Thoughts?
-Julia
[0]: https://etherpad.opendev.org/p/board-informal-security#L107