From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.fsf.org (mail.fsf.org [IPv6:2001:470:142::13]) by sourceware.org (Postfix) with ESMTPS id 3EDA33858D1E; Sun, 23 Oct 2022 16:07:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3EDA33858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=fsf.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=fsf.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=fsf.org; s=mail-fsf-org; h=MIME-Version:In-reply-to:Date:Subject:To:From:References; bh=xeGQCtgfzkaWZ7FydKqM30V9Um35RYd3lzh4OkFVqhY=; b=1oBPJHYcz9G4ujWxt7nuuEO2T wjfW5JJ03ehcJe1FbJO++XWkwMbKKVGVx/GEGE4DYpIyhT0YNOpjsSYPkS+QQHC9zey4d8ucJwTaC zt9H3Zf+aQOJw0b4GhHqaTFPGfkiuaOJQv1jbVR6PqwAx4nSTN7AN2gWepfC6Fa2JsFYqhZFUHQ6p pTddcD0FuSItdiSEW15YJ/ZL8uso9bKQPm+3ryOu8GYyeTVSCbo0HHrImsSK48zUMolsiQfXAdvM7 mXhKxHjqW+U7Ch4Hoav6GvoMx6ITBKwGkbUxVf1B6U/FA4S1dOagd0ubSjY8yu5TU4q2blV3t/YoD mxMpE0geA==; References: <2513b668-9ebd-9e78-7263-dc24f4a9558a@redhat.com> <20221013182529.sm76fysq37sv754x@cgf.cx> <9c0a9111-07b1-3617-c5c8-4b12e616f985@gotplt.org> User-agent: mu4e 1.9.0; emacs 29.0.50 From: Ian Kelling To: Overseers mailing list Cc: Siddhesh Poyarekar , gdb@sourceware.org, Mark Wielaard , libc-alpha@sourceware.org, binutils@sourceware.org, gcc@gcc.gnu.org Subject: Re: Toolchain Infrastructure project statement of support Date: Sun, 23 Oct 2022 07:33:06 -0400 In-reply-to: <9c0a9111-07b1-3617-c5c8-4b12e616f985@gotplt.org> Message-ID: <874jvufrqy.fsf@fsf.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,DATE_IN_PAST_03_06,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Siddhesh Poyarekar via Overseers 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