From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from elastic.org (elastic.org [96.126.110.187]) by sourceware.org (Postfix) with ESMTPS id 176FD3857B8D for ; Fri, 23 Sep 2022 15:06:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 176FD3857B8D Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=elastic.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=elastic.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=elastic.org ; s=default2; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=2ECNErXg/Xx4bBqLjSVOxlSRwIloenEwV3YZOTi+jCs=; b=TLosj1P8cHMXpdZhUCpW0tWxFy 5Oq55TkdEb0KRy3sdPdGTJ/9UhuRsECy1zDhcYYHnpS1WiNN5ULaPlG32soPqm+9k36FdLseIYu4r zJZ4C2OtIJUd2Ui8O08ANB7i4UWEy3LL/dqnKqYlu57g67X9kTFTsMQojHz64ngkVJ4IswiRtHEqM rdtdpXLGu65l6EWPzSeZdZXtoC3c1+9MHdqooqCtA+reYiJwBSaEa+FhEHNB06V61IQL9YsMkPCHR b94XBLAdKvOBfByHsRsqpMmn2tNc8IGGZfmXnTdn/1sJkUnXeSPl2RS7FttWbFbRXkrm4V5xMohjo pqR+5kAA==; Received: from vpn-home.elastic.org ([10.0.0.2] helo=elastic.org) by elastic.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1obkGC-0001ID-1B; Fri, 23 Sep 2022 15:06:36 +0000 Received: from very.elastic.org ([192.168.1.1]) by elastic.org with esmtp (Exim 4.96) (envelope-from ) id 1obkGC-000CAq-00; Fri, 23 Sep 2022 11:06:36 -0400 Received: from fche by very.elastic.org with local (Exim 4.96) (envelope-from ) id 1obkGB-00H7MO-32; Fri, 23 Sep 2022 11:06:35 -0400 Date: Fri, 23 Sep 2022 11:06:35 -0400 From: "Frank Ch. Eigler" To: Overseers mailing list Cc: Paolo Bonzini Subject: Re: Role of sourceware for hosted projects Message-ID: References: <58991505-d402-bc5f-5ee8-fff48dcde6cd@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <58991505-d402-bc5f-5ee8-fff48dcde6cd@gnu.org> X-Sender-Verification: "" X-Spam-Status: No, score=-101.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS,TXREP,USER_IN_WELCOMELIST,USER_IN_WHITELIST 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, Paolo - Thank you for your comments. I'll address a couple of things. > [...] > The obvious observation from the outside is that the two "opposing sides" > (for lack of a better word) have different priorities on what Sourceware > needs to provide for them. [...] Indeed. And the only way we can contemplate making improvements or fixing shortcomings is by discussing them openly. In addition, we have been super consistent in saying that projects are welcome to come, stay, and leave for whatever reason if they like. This is one reason I don't see any necessary conflict between the SFC and LF/GTI proposals. > The first part of the assessment in my opinion should be that most > projects on sourceware.org are dead. Some of them (e.g. GSL) have > already migrated out of Sourceware in fact, but the others should be > archived ASAP. Archival means [...] Most of your suggestions can be dealt with gradually, on a per-project basis. I believe that passive presence on the server is harmless, so extraordinary attempts to transport & forward stuff is not necessary. We have hardly any cgi stuff, especially in small projects, so access control withdrawals for long-inactive users should be sufficient to freeze things safely --- and quickly unfreeze if new activity appears. > [...] A prime target for this simplification, based mostly on my > experience with QEMU, is source control and CI. [...] For this > reason, source control is the main concern of the people behind the > GTI proposal. [...] I have heard this as a general concern, but it's hard to match this to a random drastic change and believe that it would or would not help. So instead of generalities, I believe one particular threat model that has been uttered here and there is ... "what if someone breaks into sourceware and alters the code repositories?". That is a reasonable and specific concern. Fortunately, all the active projects already / finally use git. (gcc was one of the last to switch). As you know, git already has excellent damage resiliency with every developer having full clones, hash based content verification, etc. Signed tags are common. AIUI, git is just not that vulnerable. In addition, any git project on sourceware has the option to go further into security territory with gpg-signed git commit/merge/push ops. AIUI, this practically eliminates the possibility of malicious code-repository damage, even with a full penetration of the server. Sourceware's git server has supported this stuff for years. I'm a little bit surprised that hardly any project has taken advantage. > [...] > The remaining common needs of large and small projects alike [...] > While other services such as patchwork can be included [...] Those are reasonable suggestions, OTOH for small/medium projects, the current set of colocated services are convenient, fully open-sourcy, community maintained. Attack surface, yes, I suppose, but that's balanced against a happy developing experience. - FChE