[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [oniro-dev] Security tooling meeting minutes June 29th, 2022
|
Hello Luca and Marta,
On Monday, 25 July 2022 07:34:24 CEST Marta Rybczynska wrote:
> -----Original Message-----
> From: Agustín Benito Bethencourt
> [mailto:agustin.benito@xxxxxxxxxxxxxxxxxxxxxx] Sent: 21 July, 2022 09:28
> To: oniro-dev@xxxxxxxxxxx
> Cc: Marta Rybczynska <marta.rybczynska@xxxxxxxxxx>
> Subject: Re: [oniro-dev] Security tooling meeting minutes June 29th, 2022
>
> Hello,
>
> On Friday, 15 July 2022 14:58:24 CEST Marta Rybczynska wrote:
<snip>
I went over the text sent by you two. Thank you.
I added some text and context to it. Please review. Feel free to amend what I
did, obviously.
Given that this request come from two different Oniro projects (oniro core and
oniro-compliance-toolchain), I think it would send a strong message if the
request comes from the Oniro PMC. This is the forum to coordinate the
different projects so it make sense to me that they are the ones bringing this
request. I see it as more than a simple formalism.
The PMC has a meeting this Thursday. Amit K. is the Chair. I suggest you two
request the inclusion of this topic in the agenda of such meeting if you think
the proposal is sound. I can do it too, if you like.
Otherwise, feel free to submit the ticket to help desk yourself. Please put me
in cc. As soon as I get notified, I will let the corresponding EF teams know
about the use cases being already described in the ticket.
Please also refer to this new ticket in this ticket: https://
gitlab.eclipse.org/eclipsefdn/emo-team/emo/-/issues/293 that tracks the
evolution of the oniro-compliance-toolchain project proposal.
Best Regards
--
Agustin Benito Bethencourt
Oniro Program Manager | Eclipse Foundation
Eclipse Foundation: The Community for Open Innovation and Collaboration
## Request
Availability of private repositories and communication channels for:
* Handling (complex) security fixes/issues under embargo.
* Handling potential IP violation.
... managed by a reduced group of security and IP compliance team members.
In addition, it is requested to allow and/or provide the implementation of private infrastructure and services for the debugging, fixing, integrating, testing and deploying the fixes corresponding to vulnerabilities under embargo at Oniro and/or upstream.
## Handling of pending (complex) security fixes
### Problem statement
When developers have a complicated security issues which is not public yet, we may need to exchange the state of development of the fix in a confidential manner. Their commits in a development branch may contain exploits used as test cases, references to the not-yet-public CVE and similar materials.
As the fix is not yet available publicly, this info could be exploited by malicious parties. This might be a **risk for commercially available devices**.
Sometimes testing of such a fix can take time. Examples of such cases could be: Meltdown/Spectre; a core library change with different fixes for different versions and possible regressions; need to test on multiple platforms; a security fix that causes a performance regression.
In typical cases, developers we expect people to work on their private copy of the repository and test on their machines and platforms. This becomes more problematic when they need to share the development branch with others for testing on different platforms, request an opinion from a domain expert, share with the upstream project affected... Typically the code will be shared only with need-to-know people.
### Which kind of projects have this need
This issue happens in distributions (like Oniro) when we are working on a fix in a 3rd party, upstream project, code base. It could potentially happen on code/configuration maintained directly by Oniro, but much less frequently.
### How frequent it would be
We expect a limited number of cases, only a few per month. A few per year at the beginning. This shared source tree will be only a temporary one, removed when the public fix is ready.
### What will happen with the confidential code later
The code will be cleaned up to fit the more detailed security policy of the project and/or the upstream project. Typically it means including limited information only in the commit message, likely remove the CVE reference. The cleaned up version will be then pushed to the public repository. And the security advisory is release
### Who requires access to this information?
* security team of the project affected
* maintenance/release team to prepare for an upcoming release
* domain experts (as needed)
* other 3rd parties when necessary (security experts, upstream project security team, vendors security teams...)
### Communication channels and tools affected and how
Tools affected:
* repo(s): need a repo that is seen only by the people who need to work on it. It should not be visible to anyone else (even committers)
* Mailing list: need a way to exchange in the restricted group. I'm not sure if dedicated mailing lists are useful here, probably a smaller exchange loop would do. Could use a private mailing list for the project's security team to keep the info in one place and include all security team members.
* Tickets: need a ticket per-issue. Nobody from the outside of the group working on the issue should be able to access it. A security bugtracker would do here.
* Pipeline: it would be good to have private (unseen from outside, esp. artifacts and commits) pipelines so that the team can test the change on all hardware/configurations.
* Testing on HW: The team working on the issue will need the complete hardware set to verify for regressions.
## Handling of IP compliance issues
### Problem statement
During the IP compliance auditing process sometimes issues related to possible IP violation need to be discussed in a confidential way.
This is needed because they have legal implications and the IP team may be discussing situations that are possibly problematic (in Eclipse-hosted projects or any other 3rd party projects). This discussion process should not exposed publicly before those eventual IP violation issues are definitely solved.
This discussion often implies the necessity to go back to the development team and ask for modification of removal of part of the source code. This of course takes some time and further discussion to solve the issue.
Moreover, the discussion with qualified lawyers needs to be privileged and the lawyers can be in an awkward position discussing matters which could lead to potential legal liability in the open; in order to maintain legal privilege and avoid ethical issues, the discussion must be made with an expectation of secrecy.
### Which kind of projects have this need
This issue happens when an IP compliance auditing process is applied to any type of software.
### How frequent it would be
In general, all IP compliance issues that need discussion among the IP team need this level of confidentiality during the clearing process.
### What will happen with the confidential code later
As soon as any possible violations are cleared, the information regarding the audit process related to the issue is publicly documented. The related code is any case already available on external resources, under Open Source licenses.
### Who requires access to this information?
* Oniro IP and license compliance team
* EF IP team
* domain experts (as needed)
### Communication channels and tools affected and how
* repo(s): need a repo that is seen only by the people who need to work on it. It should not be visible to anyone else (even committers)
* Mailing list: need a way to exchange in the restricted group.
* Tickets: need a ticket per-issue. Nobody from the outside of the group working on the issue should be able to access it. An IP/license compliance bugtracker would do here.
## Summary
An operating system is an integration and distribution project, so is Oniro. We mostly deal with third party code so we inherits risks that we need to manage carefully in order to avoid passing them downstream. Given that our downstream is intended to be commercial adopters, some the risks we need to manage might have a high impact for them.
In order to manage security and IP/license compliance risks, the availability of private repositories, communication forums and tooling is unavoidable, from our point of view. This is the case for any distributions that take these topics seriously, especially when they are down in the software supply chain, as Oniro is.
We request EF to consider the above two use cases and provide a solution that meet our needs, as well as EF needs (other projects too).
