From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 44FD93858D37 for ; Mon, 26 Sep 2022 19:57:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 44FD93858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1664222240; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=oxJqPvTzuuubY9EZ3B0KCKxmQ8B6mYvQzgzJo5z8C/E=; b=OeTUJq2ozX2udVYu3zrJBgh8RTsAuNW4VearZaLbsWQkKXczVjQ0Eh9fSSf2lFQge9A3s4 xgdO1iNxTPwEMpn9puA7VKezNz/7lj4Zt/J5ovyiwO7Gw7u902WyDVd/XSsDhtSFBzNSQq PIYkNKHDOmWluYPEm+uw5iI7keFNggs= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-16-LzM2FL_YN5qup9-bMh6liw-1; Mon, 26 Sep 2022 15:57:18 -0400 X-MC-Unique: LzM2FL_YN5qup9-bMh6liw-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4E81A29AA3BE; Mon, 26 Sep 2022 19:57:18 +0000 (UTC) Received: from redhat.com (unknown [10.2.17.198]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5DDAC17583; Mon, 26 Sep 2022 19:57:17 +0000 (UTC) Received: from fche by redhat.com with local (Exim 4.94.2) (envelope-from ) id 1ocuE8-00081R-LF; Mon, 26 Sep 2022 15:57:16 -0400 Date: Mon, 26 Sep 2022 15:57:16 -0400 From: "Frank Ch. Eigler" To: overseers@sourceware.org Cc: ian@airs.com Subject: Re: Moving sourceware to the Linux Foundation? No thanks. Message-ID: <20220926195716.GD7916@redhat.com> References: <87ler4qcmo.fsf@gnu.org> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.12.0 (2019-05-25) X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-9.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi - > I see two important points that ought to be discussed on this topic. Thanks for joining the discussion. > The first is succession planning. Sourceware is essentially a community > project with a relatively small number of people keeping it going. It > needs trusted and capable people to step it to continue to maintain it. > Where are those people going to come from? We shouldn't simply hope > that it will keep carrying on as before. Fair, we need to attend to recruiting more helpers. (It was with this in mind that some folks got root on sourceware in the last few years.) With some moderate funding, the small amount of IT effort this place requires could be filled out with talented part-timers. OTOH, it's not an emergency, and the system is not complicated, running off-the-shelf basic RHEL8 for the core stuff (git, mail, mailing lists, http, ssh, authentication). > The second, mentioned in Mark's e-mail, is security. I hope that we > can all agree that there are highly intelligent, highly motivated > people seeking to break security on GNU/Linux and other free > operating systems. [...] sourceware be defended against these > kinds of attacks with mechanisms for prevention and detection and > restoration. [...] Luckily, sourceware is a pure upstream source repo, ships no binaries, and holds no secrets. As long as the integrity of the data is assured (for example by some mixture of crypto signed git-everything, broad backups of the git data, and project reviewers/maintainers doing their jobs), I don't think Thompson's hypothetical attack can be effective. Certainly, suggestions to improve infrastructure stability / resilience would be welcome, but it seems like projects can already self-serve code-repo security, if they choose to. - FChE