Re: [oniro-dev] [REQUIREMENTS v2] Requirements for resources for discuss

[Amit Kucheria <amit.kucheria.ext@xxxxxxxxxx>]

Hi Oniro-PMC,

Forwarding a discussion topic for tomorrow's meeting.

Thanks for driving this Marta/Luca. Talk to everyone tomorrow.

Regards, 
Amit

> -----Original Message-----
> From: Marta Rybczynska
> Sent: 27 July 2022 10:38
> To: oniro-dev@xxxxxxxxxxx; Amit Kucheria <amit.kucheria.ext@xxxxxxxxxx>;
> agustin.benito@xxxxxxxxxxxxxxxxxxxxxx
> Subject: [REQUIREMENTS v2] Requirements for resources for discussing
> security issues/potential IP violations
> 
> Dear all,
> 
> Following the discussion on the ML on the use-cases for confidential
> repositories and issue trackers, here's the summary of requirements for the
> PMC meeting. This version includes re-wording after comments from the IP
> compliance team.
> 
> Requirements (for each of the groups)
> * 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.
> 
> Kind regards,
> Marta
> 
> 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.
> 
> ## 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).