[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 23 Dec 2023 19:16:36 +0100
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: linux-distros membership application of openEuler
Hi,
First of all, thank you to everyone who contributed to this thread (I
include a summary at the end of this message, so please check that I got
it right), and I'm sorry I did not publicly comment on this application
for so long.
I did not ignore it - there were a few off-list messages between Aron
and me, and I've been thinking of how to approach the problem best.
I think the application (almost) meets our 9 criteria (once someone
vouches for Aron), and if we judge solely by those then we'd need to
accept openEuler. However, as several people said, there are legal
concerns, and even if the concerns are maybe unfounded, this would
likely reduce usage of the linux-distros list.
Overall, given these concerns and us having an isolated one application
like that so far, I think it's best if openEuler does not join
linux-distros now. However, I understand this might not work long-term,
as similar concerns could arise in context of another application later.
One approach is to wait and see, and revisit these concerns in a more
general manner if and when that issue does come up. Another approach is
to bite the bullet and proceed with accepting openEuler now, then
revisit and possibly generalize if related concerns arise in context of
another application.
Here are some things to (re)consider if and when we are about to accept
a controversial member like this:
1. As suggested by others, we could seek statements by lawyers and/or
relevant organizations such as the Linux Foundation. We actually have
much of this already, see below.
2. We could setup a sub-list with only non-controversial members, or a
super-list with extra members on it, technically in the same way we
currently have distros (which includes non-Linux) vs. linux-distros.
Given that existing separation, we'd end up with four lists/addresses,
which would unfortunately be complicated and could be distracting and
discouraging for issue reporters.
3. We could enforce delayed publication of the full private list
content, not just vulnerability disclosures, to more obviously meet
export regulations due to literally everything getting published. Per
other recent discussions, we already know this would discourage some
people/projects from contributing/participating, but would at the same
time be a welcome change for some others.
4. Alternatively to the above, we could state that it's the senders'
choice to publish everything they send to the list in case they're
concerned about (otherwise possibly not) meeting the regulations (in
their jurisdiction). Being extra burden, this would discourage some
people from contributing.
On Tue, Oct 17, 2023 at 12:15:30AM +0800, Aron Xu wrote:
> Not matter what would be the outcome, I'd like recommend an article
> from Linux Foundation which I think is a good read:
> https://www.linuxfoundation.org/resources/publications/understanding-us-export-controls-with-open-source-projects
Yes, it is, and specifically the "Be open and be public" section in it.
Even more specific is the statement Linux Foundation made on Huawei:
https://www.linuxfoundation.org/blog/blog/linux-foundation-statement-on-huawei-entity-list-ruling
> I'm not a lawyer though, but here are a few cents:
>
> 1) There is no general restrictions against Chinese organizations and nationals;
> 2) Open source software (which is publicly available) is not subject
> to EAR (Export Administration Regulation of the US);
> 3) According to ?? 734.7[1] of EAR, "knowledge with the intention that
> such information will be made publicly available if accepted" is
> treated as "Published" and is considered publicly available.
>
> If I understand correctly, distros list is targeted to open source
> software issues with a policy[2] of "Please only use these lists to
> report and discuss security issues that are not yet public (but that
> are to be made public very soon)", then everyone could retain their
> peace of mind.
I am also not a lawyer. As I'm aware, many countries, including the US,
Canada, EU countries, and even e.g. Russia and India and many others,
accepted the Wassenaar Arrangement. My understanding is that the
individual countries' export regulations are thus implementations of the
Wassenaar Arrangement, perhaps with some local tweaks. (Indeed, the
classification codes mentioned in the EAR section you reference above
match Wassenaar's.)
So the focus on US vs. China seen in this thread here looks unjustified
from a legal perspective. However, it may be justified from a practical
concern perspective.
Then there's the issue of "Huawei and its non-U.S. affiliates" being on
the US sanctions "Entity List". Reading the FAQ here:
https://www.bis.doc.gov/index.php/documents/pdfs/2447-huawei-entity-listing-faqs
I don't see relevance to what we're doing. Per my reading, this says
that for items already subject to EAR, a specific license for exporting
to Huawei is required and would likely be denied. We assume (and LF
agrees) that what we're doing is not subject to EAR (and if it were,
we'd have problems with most international communication like this, not
just with US vs. China or Huawei). So again, the legal concern looks
unjustified, but I understand that people are concerned in practice, and
that's a problem on its own.
Here are specific quotes from the two LF publications referenced above:
> Be open and be public
>
> First, communities should strive to keep their technical conversations open and public. If private technical conversations happen within communities, that's normal, but it is recommended to make the community decisions and outcomes publicly available. It is important for our projects to make information available transparently and publicly as the private exchange of technology or technical information may not meet the "publicly available" standard according to the EAR.
>
> One question that has come up has to do with exchanges of information related to security issues under a security disclosure process. As a best practice, projects may want to consider making exchanges like this public upon the availability of fixes, and not limit this information to only a confidential disclosure list.
> Security Vulnerability Pre-Disclosure Lists
>
> A few of the Linux Foundation's project communities use security vulnerability pre-disclosure lists to alert known implementers of the project's open source software about vulnerability fixes that will be disclosed by the developers and published publicly in the near future (typically within 2 weeks). In these situations, LF project communities are conveying knowledge, information and written software patches that will be made publicly available when accepted for publication by the committers on the project and such disclosures are permitted under 15 CFR 734.7(a)(5). [2]
>
> [2] https://www.ecfr.gov/cgi-bin/text-idx?SID=fcba36d2f267c2fdecc5694c1e754aa7&mc=true&node=se15.2.734_17&rgn=div8
Here's my summary of what was said in this thread so far:
Marcus Meissner brought up the US vs. China concern. Greg KH said
things were not that bad, but kept suggesting to talk to lawyers, which
Demi Marie Obenour found very discouraging.
Demi Marie Obenour and Igor Seletskiy are concerned about the legal
risks. Demi Marie wants that "a trusted entity (such as the Linux
Foundation) made a public, broadly applicable, and easily interpretable
(by non-lawyers) statement stating that it would be okay for me to make
such a post." I think we have that above. However, she also adds "And
maybe not even then." Igor brings up the Huawei concern. I think LF's
statement above addresses it.
This reads like 2 to 4 votes against accepting openEuler now.
Heiko Schlittermann and Steffen Nurpmeso are for us not considering
"anything else than technical/security restrictions here." In other
words, for accepting openEuler now if it meets our usual criteria.
Tianyu Chen brought up that there could already be subscribers from
other sanctioned countries.
W. Wadepohl expressed general unhappiness with linux-distros being
non-free and not addressing IoT device security.
This reads like 2 to 4 votes for accepting openEuler now.
Alan Coopersmith commented on who typically posts to the distros list,
and thus who would (not) be concerned about the legal risks.
Per the above, there doesn't appear to be an obvious majority or
obviously better reasoned opinion for or against accepting openEuler.
If any of the people who commented previously have something different
or more specific to say now (e.g., "my concerns are now sufficiently
addressed" and/or "my preference is such-and-such"), please do.
If anyone else has anything valuable to add, please do.
Sorry for the lengthy message, and thanks again.
Alexander
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
