Siddhesh Poyarekar via Overseers <overse...@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