os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Partially restructure the core team report

Browse source 
Split out the two major issues into enumerated portions for greater
clarity.  Reorder content within the security team reorganization portion
of the entry in order to make more prominent the actual nature of the
restructuring, and improve clarity on the motivation and ramifications
of the changes.

Discussed with: koobs
This commit is contained in:
Benjamin Kaduk 2016-01-19 03:16:56 +00:00
parent b18f6313e0
commit aacfdead69
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=48066
1 changed files with 66 additions and 53 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

119
en_US.ISO8859-1/htdocs/news/status/report-2015-10-2015-12.xml
View file

@ -2483,68 +2483,81 @@
</contact>
<body>
<p>Two major concerns have occupied much of core's attention
<p>Two major issues have occupied much of core's attention
during the last quarter: the reorganisation of the Security
Team and the question of whether to import GPLv3 licensed code
into the source repository.</p>
<p>The Security Team reorganisation, first proposed to Core
during a meeting at BSDCan this year by Gleb Smirnoff &mdash; core
member and newly-appointed deputy Security Officer (SO) &mdash; has now
been accomplished. In order to improve the project's
responsiveness to security alerts, to maintain security on
privileged information received in confidence before general
publication and, not least, to reduce the work load on the
security officer, the role of the SO team has been redefined as
the controller of the distribution of security sensitive
information within the project; they are responsible for
interfacing with external bodies and individuals reporting
security problems, and connecting them with appropriate
individuals within the project with the technical expertise to
address the identified concerns. The SO team was cut down to just
the Security Officer and their deputy, assisted by a secretary, and
with input and help in drafting security advisories from former
and any potential future Security Officers plus liasons with Core,
Cluster Administration and Release Engineering.</p>
<ol>
<li>
<p>The idea of reorganizing the Security team was first
proposed to Core during a meeting at BSDCan this year by
Gleb Smirnoff &mdash; core member and newly-appointed deputy
Security Officer (SO). The &quot;Security Team&quot;, which
previously could contain several people (a varying number
over time, but more than two) has been refashioned into just
two roles: Security Officer and Deputy Security Officer.
Accordingly, the role of the SO team has been redefined to
be the controller of the distribution of security sensitive
information into and within the project; they are
responsible for interfacing with external bodies and
individuals reporting security problems to the project, and
connecting those reports to the appropriate individuals
within the project with the technical expertise to address
the identified concerns. These changes will improve the
project's responsiveness to security alerts, help maintain
security on privileged information received in confidence
before general publication and, not least, reduce the work
load on the security officer. The SO team will continue to
benefit from liasons with the Core, Cluster Administration,
and Release Engineering teams, and will be assisted by a
secretary; they will also be able to obtain input and
assistance in drafting security advisories from former and
potential future (Deputy) Security Officers.</p>
<p>Core would particularly like to thank the former members of
the Security Team group for their past contributions, now that
the Security Team role has been merged into the Security
Officer's responsibilities.</p>
<p>Core would particularly like to thank the
former members of the Security Team group for their past
contributions, now that the Security Team role has been
merged into the Security Officer's responsibilities.</p>
</li>
<p>The other large question concerning Core is how to provide a
modern toolchain for all supported achitectures. Tier 1
architectures are required to ship with a toolchain
unencumbered by onerous license terms. This is currently
provided for i386 and arm64 by the LLVM suite, including the
Clang compiler, LLD and LLDB. However LLVM support for other
(Tier 2 or below) architectures is not yet of sufficient quality
to be viable, and the older but pre-existing GPLv2 toolchain
cannot support some of the interesting new architectures such
as arm64 and RISC V. Pragmatically, in order for the project
to support these, until LLVM support arrives we must turn to the
GNU project's GPLv3 licenced toolchain.</p>
<li>
<p>The other large question concerning Core is how to provide a
modern toolchain for all supported achitectures. Tier 1
architectures are required to ship with a toolchain
unencumbered by onerous license terms. This is currently
provided for i386 and arm64 by the LLVM suite, including the
Clang compiler, LLD and LLDB. However LLVM support for
other (Tier 2 or below) architectures is not yet of
sufficient quality to be viable, and the older but
pre-existing GPLv2 toolchain cannot support some of the
interesting new architectures such as arm64 and RISC V.
Pragmatically, in order for the project to support these,
until LLVM support arrives we must turn to the GNU project's
GPLv3 licenced toolchain.</p>
<p>The argument here is whether to import GPLv3 licensed code
into the &os; src repository with all of the obligations on
patent terms and source code redistribution that would entail,
not only for the &os; project itself but for numerous
downstream consumers of &os; code. Not having a toolchain
readily available is a big impediment to working on a new
architecture.</p>
<p>The argument here is whether to import GPLv3 licensed code
into the &os; src repository with all of the obligations on
patent terms and source code redistribution that would entail,
not only for the &os; project itself but for numerous
downstream consumers of &os; code. Not having a toolchain
readily available is a big impediment to working on a new
architecture.</p>
<p>One potential solution is to create a range of &quot;GPLv3
toolchain&quot; base-system packages out of a completely separate
source code repository, for instance within the &os; area on
Github. These would be distributed equivalently to the other
base system binary packages when that mechanism is
introduced.</p>
<p>One potential solution is to create a range of &quot;GPLv3
toolchain&quot; base-system packages out of a completely separate
source code repository, for instance within the &os; area on
Github. These would be distributed equivalently to the other
base system binary packages when that mechanism is
introduced.</p>
<p>Core recognises that this is a decision with wide-ranging
consequences and will be producing a position paper for
circulation amongst all interested parties in order to judge
community opinion on the matter. Core welcomes feedback from
all interested parties on the subject.</p>
<p>Core recognises that this is a decision with wide-ranging
consequences and will be producing a position paper for
circulation amongst all interested parties in order to judge
community opinion on the matter. Core welcomes feedback from
all interested parties on the subject.</p>
</li>
</ol>
<p>Beyond these two big questions, Core has handled a number of
lesser items:</p>