Two major concerns have occupied much of core's attention +
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.
-The Security Team reorganisation, first proposed to Core - during a meeting at BSDCan this year by Gleb Smirnoff — core - member and newly-appointed deputy Security Officer (SO) — 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.
+The idea of reorganizing the Security team was first + proposed to Core during a meeting at BSDCan this year by + Gleb Smirnoff — core member and newly-appointed deputy + Security Officer (SO). The "Security Team", 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.
-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.
+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.
+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.
+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.
-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.
+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.
-One potential solution is to create a range of "GPLv3 - toolchain" 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.
+One potential solution is to create a range of "GPLv3 + toolchain" 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.
-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.
+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.
+Beyond these two big questions, Core has handled a number of lesser items: