Re: Toolchain Infrastructure project statement of support

[Ian Kelling <iank@fsf.org>]

Siddhesh Poyarekar via Overseers <overseers@sourceware.org> writes:

> I personally do not think the current sourceware infrastructure, even
> with the roadmap it promises is a viable alternative to what LF IT can
> provide.  There is a significant resource gap (e.g.
....
> established security and administration practices,
...
> that we seem to disagree about.


Let's consider some "established security and administration practices"

curl -v http://vger.kernel.org | head
...
< Server: Apache/2.0.52 (Red Hat)
< X-Powered-By: PHP/4.3.9

This is RHEL 3, released in 2003, according to
https://people.redhat.com/crunge/RHEL3-package-lists.pdf,

The final end of support for this distro was on 2014-01-30.

There are CVE's for that version of Apache. I assume their apache is not
running in a configuration that makes them actually exploitable, but it
is still better security practice upgrade.

The kernel is likely from RHEL 3 too. I'm reminded of Greg KH beating the
drum that old kernels need upgrades for security, especially because the
kernel devs don't always check if a bug is a security issue and
especially not for really old kernels (
https://thenewstack.io/design-system-can-update-greg-kroah-hartman-linux-security/
)

Notice that link is http because https is not supported by the apache
from 2003. Linux kernel development works through patches on mailing
lists, and how do you find the patches if you aren't already subscribed
to a list? You'd naturally go to the lists main webpage,
http://vger.kernel.org, and click "LIST INFO",
http://vger.kernel.org/vger-lists.html, and then click one of the list
archive links, or maybe the subscribe link. So, those vger.kerne.org
pages are an essential part of retrieving upstream kernel patches and
security information for some people. And being http only, my isp or
anyone in my network path could alter them to be malicious urls that
that appear to give the correct result, but actually give malicious
kernel patches, or hides away a security relevant patch. Obviously,
https for security sensitive pages like these is a basic 101 security
practice in 2022.

You might think when kernel.org had a major compromise in 2011, 11 years
later, they would have managed this basic upgrade. The fact is that the
Linux Foundation struggles with getting stuff to current versions and
following good security practices like everyone else does. This
narrative that there is a huge resource gap in security practices
between LF and sourceware is not true, and I don't think the kernel.org
IT team would claim that either. They certainly made no such claims in
their slide deck about the GTI proposal.

If LF IT were to get involved in services for GNU toolchain packages, it
should be more of a collaboration with sourceware instead of taking over
what sourceware is doing.

Competent sysadmin volunteers are rare and valuable to GNU. They help
build community, they help GNU stay independent, and they help GNU
practice what it preaches.

-- 
Ian Kelling | Senior Systems Administrator, Free Software Foundation
GPG Key: B125 F60B 7B28 7FF6 A2B7  DF8F 170A F0E2 9542 95DF
https://fsf.org | https://gnu.org