Re: Toolchain Infrastructure project statement of support

On 2022-10-23 07:33, Ian Kelling wrote:
> Siddhesh Poyarekar via Overseers <[email protected]> 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.

+Konstantin from LF IT since he's better equipped to speak to this, 
although ISTM that they started migrating off vger last year[1].

Sid

[1] https://www.kernel.org/lists-linux-dev.html

Sid