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 851743858D32 for ; Sun, 2 Oct 2022 14:55:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 851743858D32 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=ahI+NGx7qG4oXNYdvBnlUKVFxnmGDPrGnLZkYxnGZNQ=; b=BsSNs5bC+oKUKM7LPR9TSTWTFd jmP6sgSp714oeMoXzHPOsIc/m8TTKYLCypkke+w7SiMXDiHFEtOMgiv+8ZZmITpGcsdj1YigwgFLj S5bQrR81WEfqtui/CBMZ9H/mnw4DShfDHwJULzySkxUu8ngmSWjl3XQPvVd73T1R8NlrpZIYwls/Y AqNSZuVWhtgsN42g+cMQIBL+yFOKQcDZGeOxo0+hnP5FuSrFl6C9594xKe702/+QgX9S0eeuspZbT f+vaBo5xufYeMkTOqYYpGpCkIFimX2wlFhHVoiJLfAGpDjc+lsITSeSdc9vmoaKYa0MkKcaZi4CJ5 72QkaNYA==; 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 1of0Nq-00019X-0x; Sun, 02 Oct 2022 14:55:58 +0000 Received: from very.elastic.org ([192.168.1.1]) by elastic.org with esmtp (Exim 4.96) (envelope-from ) id 1of0Nq-000EKo-02; Sun, 02 Oct 2022 10:55:58 -0400 Received: from fche by very.elastic.org with local (Exim 4.96) (envelope-from ) id 1of0Np-008py3-3C; Sun, 02 Oct 2022 10:55:57 -0400 Date: Sun, 2 Oct 2022 10:55:57 -0400 From: "Frank Ch. Eigler" To: Carlos O'Donell Cc: Overseers mailing list , Mark Wielaard Subject: Re: Sourceware / GNU Toolchain at Cauldron Message-ID: References: <20220918162733.GB27812@gnu.wildebeest.org> <20220918213842.GC27812@gnu.wildebeest.org> <2db869b5-5724-18c0-e356-9e5df8f7cb4d@redhat.com> <940b60c6-54fe-d4d2-22d1-d93dcf2aaf79@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <940b60c6-54fe-d4d2-22d1-d93dcf2aaf79@redhat.com> 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 - > >> - Defense in depth > >> - Multiple servers, each with distinct services. > >> - Multiple servers for one service where possible. > > > > Depends on the threat model. Which one are you concerned about? > Consider an attacker simply looking to disrupt services (DoS, DDos) > using another service on the current system. The more services > present on the system the more the opportunity to do this kind of > attack. I don't quite see the "more opportunity". If someone wants to take out a particular source hosting site, they'll go after it, whether or not the target site is sharing resources with others. We are fortunate to use fully decentralized source control systems, where full clones at developers - and at other services like github etc. - are routine, and permit work to continue. I'd be surprised to hear of any organization hoping to hurt free software development by DoS'ing the sites - it'd be a futile gesture. > >> - If governments want to use FOSS tools directly, do we need to > >> comply with security standards like a contractor would? > >> - Does NIST SP 800 53r5 apply to Sourceware.org? > >> [...] > > If we don't have evidence that it does, what is the purpose of > > bringing it up? > Two downstream users of our sources have cited NIST SP 800-53 as > something they had to comply with Downstream corporations distributing products based on FOSS are irrelevant to this question. > and I want to dig more into two possible scenarios: > > (a) Is there an expectation that upstream source control > repositories need to meet this regulation as well as the > downstreams? (b) If we met the regulation would it improve FOSS > adoption and support downstream users? I can only assume that you already have evidence/argument in the affirmative for these questions, otherwise why are we discussing any of this? Can we hear that evidence/argument please? > >> It is two proposals. > >> > >> A fiscal sponsor for infrastructure in the OpenSSF via the GNU > >> Toolchain Infrastructure project at the Linux Foundation. > >> > >> A proposal to use managed services with the Linux Foundation IT for > >> projects currently at sourceware.org. > > > > Are they separable? > > They are, the fund is designed to support more than just managed services. That's not quite the same thing. Are the funds available for novel things that the various development communities may start requesting, **instead of** redirecting the vast majority to LF-IT for managed services? Or, are managed services an inseparable component of this proposal? - FChE