From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id EKuPIypnVWMpxQ8AWB0awg (envelope-from ) for ; Sun, 23 Oct 2022 12:09:14 -0400 Received: by simark.ca (Postfix, from userid 112) id 8D00F1E112; Sun, 23 Oct 2022 12:09:14 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=E9CiDPkf; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DATE_IN_PAST_03_06, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 1E5FF1E0D5 for ; Sun, 23 Oct 2022 12:09:14 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 88FA43857BB0 for ; Sun, 23 Oct 2022 16:09:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 88FA43857BB0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1666541353; bh=xeGQCtgfzkaWZ7FydKqM30V9Um35RYd3lzh4OkFVqhY=; h=References:To:Subject:Date:In-reply-to:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=E9CiDPkftPcqab6PIV2z66GzXw8tLtw3JG5SmASK2OsLUAF8Al3yuJnRqnW3Wromw q7+1eAZd0lSSm6JGb+jM45hE/h9zkcRdvqiT6rBr/vW1MRmIAKC+R0+KnQslRNGsvt I1juVbT7SQ/ET8508p4f0MRNt7Pyiy+JAYmIUCfc= 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 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 To: Overseers mailing list 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-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Ian Kelling via Gdb Reply-To: Ian Kelling Cc: gcc@gcc.gnu.org, libc-alpha@sourceware.org, Siddhesh Poyarekar , gdb@sourceware.org, Mark Wielaard , binutils@sourceware.org Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" 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