sourceware.org
 25 Roadmap
Our Mission
 Organization
 Services
 Sponsors
Donate
Mirrors
News
Projects
 Binutils
 Cygwin
 dwarfstd
 elfutils
 GCC
 GDB
 GLIBC
 Libabigail
 Newlib
 SystemTap
 Valgrind
 More projects...
Mailing Lists
Suggestions

Sourceware infrastructure security

Worry-free, friendly, secure, independent infrastructure for core toolchain and developer tool communities.

What is Sourceware?

Sourceware is a Free Software hosting project for core toolchain and developer tools.

Projects like Cygwin, a UNIX API for Win32 systems, the GNU Toolchain, including GCC, the GNU Compiler Collection, two C libraries, glibc and newlib, binary tools, binutils and elfutils, debuggers and profilers, GDB, systemtap and valgrind. Sourceware also hosts standards groups like the gnu-gabi and the DWARF Debugging Standard committee.

The 25+ hosted projects (with 350+ active developers and more than 1000 contributors) are at the heart of the Free Software supply chain, providing the core toolchain and developer tools of all GNU/Linux distributions.

Free Software needs Free Infrastructure. Standard services Sourceware provides hosted projects include websites, mailing lists, git hosting, job automation, bug tracking, patch tracking, continuous integration testing, snapshots, wikis, release hosting and mirroring.

https://sourceware.org/projects.html

Sourceware organization and mission

Sourceware's goal is to offer a worry-free, friendly, secure, independent home for Free Software projects at community scale.

The purpose of Sourceware is Free Software hosting of projects that produce, distribute, document, and improve software and/or documentation that can be freely copied, modified and redistributed and for which modified versions can also be redistributed (“Free Software”), and to facilitate and organize its production, improvement and ease of use. Sourceware provides the infrastructure for many widely used and essential software projects that are relied on by the software industry at large.

Sourceware is a Software Freedom Conservancy member project.

The Sourceware Project Leadership Committee, eight representatives from the various hosted projects and (former) Overseers, coordinate with SFC staff, all stakeholders and the developer community to make decisions on how to allocate budget for infrastructure and services support. The daily support is in the hands of the Overseers volunteers, helped by payed staff of the organizations providing hardware resources, and various project admins, maintainers and release managers. Every month there is a public office hour for all stakeholders and every quarter Sourceware publishes infrastructure community updates.

Current funding is provided through hardware partners, in particular Red Hat and the Oregon State University Open Source Lab (OSUOSL), providing hardware services that are maintained by volunteers. There is also a (hardware replacement) fund which comes from individual sponsors and grants. This provides a stable base for the continued operation of the basic infrastructure.

https://sourceware.org/mission.html

Secure Sourceware Project Goals

Reflections on Trusting Trust. 40 years ago Ken Thompson laid out the roadmap for attacking an operating system via the compiler and other code generation tools. These days these are known as supply chain attacks. The Free Software community should reasonably insist that they be defended against these kinds of attacks with mechanisms for prevention, detection and restoration.

There are three "layers" to security for projects hosted by Sourceware with different, but overlapping, stakeholders. First there are the infrastructure services (wikis, websites, source repositories, bug and patch trackers, CI builders, snapshots, mailing lists, etc.). Second is the secure software development framework setup by the hosted projects themselves (policies about patch submission, review, testing, integration, etc.). Finally there is the publication of software artifacts, like release tarballs, that end users (and the rest of the Free Software supply chain) can use, mirror, fork, adapt. The end user should be able to verify that the release is what the project release manager intended to publish.

For the first layer, the infrastructure services, the main security goal is making sure the provided services can only be manipulated by authenticated users and that one service cannot interfere with any other (for which a user isn't authorized). We do not want to lock in the community in using our services exclusively or create a locked centralized controlled community. Sourceware specifically wants the infrastructure services it offers to be "forkable". Therefore, the infrastructure services it offers show best practices and encourage (other) communities to replicate them.

The goal of the secure software development framework is making sure that changes to the software (repository) are properly audited, reviewed, discussed and tested. Sourceware provides the technical infrastructure for this, but hosted projects set their own rules, which are in a large part social constructs making sure that for each source code change an audit trail exists, which is facilitated by technical services creating the necessary records. The framework and infrastructure should support integrating bug fixes and new features from both established, trusted, developers on the project and new contributors.

Finally the publication of the final software artifacts (releases) must be done in a way that end users can make sure they are as the project (release managers) intended, without any changes not audited by the project secure software development framework. This includes making sure the artifacts, including signatures and the audit records, can be mirrored. The stakeholders here are the end users, distributions and companies wanting to integrate the software and make sure it reaches the public at large.

https://sourceware.org/sourceware-wiki/sourceware_security_posture/

Plans

Sourceware would like to implement the following programs related to improving the security of various processes and services.

  • More isolation of existing services. Moving some services that currently use traditional unix isolation into their own container or (virtual) machine. This will help scaling by making it easy to move services between separate physical machines. It will also provide security in depth. The goal is to deliver an Ansible playbook for each service plus a (public) git repository for those services for which we have any local modifications.

  • Modernizing account processes. Our account creation process is a custom made script/web-app that allows appointed maintainers of the hosted projects to approve new developer accounts. One of the Sourceware overseers then double checks all details and creates the account. But part of this is still a manual process, which needs a better process. We also started an aging inactive users policy, which needs process documentation. All steps need a security audit.

  • Release upload process improvements. Specifically to ensure release managers for all the hosted projects have their keys registered and software enforces all release tar balls are signed. The most likely candidate for this upload process is the FSF "gatekeeper" project since that is already familiar to the GNU projects hosted on Sourceware. And the gatekeeper project has already seen a security audit. This includes migrating existing projects to the new process.

  • Hardware keys for administrators, release managers and developers. This reduces the risk and scope of security breaches involving private keys. We first like to provide all Sourceware oversees and project admins with hardware keys, then all release managers for the hosted projects and eventually every active developer with commit access.

  • Pull-request server. A lower-privileged git server for contributors which don't have commit access, as an alternative/complementary mechanism to email based submission and tracking of contributions, to support the projects secure software development framework. A good minimum capacity for our current projects would be support for up to ~1000 contributors/forks/branches. And should ideally integrate with (automatic) email/patchwork/builder CI review/testing.

  • Hire a part time junior system administrator (possibly connected to one of our hardware partners OSUOSL). The goal would be to help us coordinate these updates and create updated and new standard operating procedures (SOPs) for Sourceware overseers and project admins. They would assist the overseers in integrating the updated services, handle some of the daily administrative tasks and document them. They will also provide blueprints for setting up and running the services for users or organizations who want to provide their own Free Software Infrastructure environment.