Re: Sourceware / GNU Toolchain at Cauldron

[Carlos O'Donell <carlos@redhat.com>]

On 9/18/22 17:38, Mark Wielaard via Overseers wrote:
> - There were several different kind of "security concerns" which would
>   be good to untangle:
>   
>   - There is the concern of he security of the sourceware server
>     itself. We discussed that in one of the public chats with the SFC
>     and the recommendation was to see if we could maybe hire a
>     penetration testing firm to see if we missed anything.

Discussed in the BoF were a few additional items:

- Defense in depth
  - Multiple servers, each with distinct services.
  - Multiple servers for one service where possible.

- If governments want to use FOSS tools directly, do we need to comply with security
  standards like a contractor would?
  - Does NIST SP 800 53r5 apply to Sourceware.org?
    - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf

 
>   - There is the "hardening" concern of separating unix user accounts
>     for separate services like running git hooks. This is one of the
>     things that the buildbot service offers. We could also adopt
>     something like gitolite.

... and run them on a distinct machine (which requires machine resources, and admin
time, etc).

Adopting gitolite is also a great step in the direction of not having real accounts
for users of a services.
 
>   - There is the secure software supply chain idea. This is one of the
>     things I wanted to discuss now that we have services like
>     public-inbox and tools like b4 for patch attestation. Sourceware
>     offers the services for that, but it really is a policy question
>     for the guest projects whether they use that (and for example
>     whether to use signed git commits).

I agree these are going to be policy questions for each project to discuss.

Though the proposal to use managed services with the LF IT would align us with
exactly the groups doing public-inbox, b4, patatt, and other work for the Kernel.

We would be leveraging everything they've been doing, which we could also do,
but the proposal is about having them support us instead.

> - Although it is true that there is a GNU Toolchain with the FSF as
>   fiscal sponsor and that the separate GNU projects work together
>   using that name, it wasn't clear to me when in this discussion we
>   were talking about the gdb, binutils, glibc and gcc projects
>   collectively. From other discussions during Cauldron it was very
>   clear that although each project is hosted on sourceware and using
>   some of the same services, each one has its own policies which make
>   sense for their separate communities.

Correct.

The core GNU Toolchain projects in this case are gcc, binutils, glibc and gdb.

We work to try and support each other as the "GNU Toolchain."

We adopt best practices from each other, attend BoFs together, and discuss solutions
to common problems using FOSS tooling that we could all adopt.

> - I wasn't really sure what to make of this LF/GTI proposal. It seemed
>   to conflate separate concerns that we were explicitly trying to
>   avoid with our Sourceware as Conservancy member proposal. It seemed
>   to mix explicit fundraising with advocating for a certain "managed
>   services at the LF/IT" technical proposal for using those funds. And
>   setting up yet another fiscal sponsor?

It is two proposals.

A fiscal sponsor for infrastructure in the OpenSSF via the GNU Toolchain Infrastructure
project at the Linux Foundation.

A proposal to use managed services with the Linux Foundation IT for projects currently
at sourceware.org.

Technically speaking, I think the Linux Foundation IT, with their existing work with
public-inbox (ahead of its time), b4, patatt, and more, means they are globally the
best positioned to keep solving these problems and supporting the development of
these FOSS tools for the linux kernel and others. Even more so for a distributed
development model that we use for the GNU Toolchain.

-- 
Cheers,
Carlos.