[oniro] Request for resources for discussing security issues/potential IP violations

Summary

The Oniro Core team and Compliance Toolchain team need ways to discuss security issues and potential IP violations. The request below has been discussed at Oniro PMC meeting on July 28th and is a summary of multiple earlier discussions.

Contact people for Oniro Core security aspect: @mrybczyn, for the Eclipse Oniro Compliance Toolchain @lucamiotto

Requirements (for each group):

a private issue tracker to which only a restricted number of persons has access; those groups might include some of the committers (see detailed setup in the document below)
a private mailing list with the same restrictions.
private repos to handle development of fixes for security issues/development of fixes for possible IP violations

Specific requirements:

everyone should be able to create issue in the private issue tracker, they should be visible to the creator and the team handling the issue tracker only (not visible to other committers or guests)
it should be possible to add any committer or any project member to a specific ticket, but without giving them visibility to all other tickets (the way to include domain experts); only the private issue tracker team should be able to add people to tickets
the private mailing list does not have an archive
it is impossible to self-subscribe to the private ML
private repos do not use pubic pipelines and other resources that would make their output or intermediate state public

Differences security/IP compliance:

security needs ad-hoc repos with different set of people having access to them (not one repo for all issues - such a repo would be a security thread) while IP compliance seems prefers one repo for all development
the security mailing list can accept messages from everyone, but do not accept subscription (this was it can be used for reporting issues). On the IP compliance team the list is for internal discussion only and should not accept messages from non-members.

Background/more information

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 if lawyers' privilege can be safely waived without risk for possible IP violators. 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.

Conclusions

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).

Edited Aug 31, 2022 by Frederic Gurr