From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 4EIOC3lDQ18vbwAA0tVLHw (envelope-from ) for ; Mon, 24 Aug 2020 04:35:05 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id mEe/BnlDQ1+URAAAbx9fmQ (envelope-from ) for ; Mon, 24 Aug 2020 04:35:05 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id A52B9940367 for ; Mon, 24 Aug 2020 04:35:04 +0000 (UTC) Received: from localhost ([::1]:39826 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kA4CF-0002xU-M5 for larch@yhetil.org; Mon, 24 Aug 2020 00:35:03 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42484) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kA4C7-0002xF-I1 for guix-devel@gnu.org; Mon, 24 Aug 2020 00:34:55 -0400 Received: from fsfla.org ([217.69.89.140]:48458) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kA4C5-0003Ee-8v for guix-devel@gnu.org; Mon, 24 Aug 2020 00:34:55 -0400 Received: from free.home (unknown [201.82.51.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by fsfla.org (Postfix) with ESMTPSA id BD16A1DEF91; Mon, 24 Aug 2020 04:34:50 +0000 (UTC) Received: from livre.home (livre.home [172.31.160.2]) by free.home (8.15.2/8.15.2) with ESMTPS id 07O4Yf4q118503 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Aug 2020 01:34:41 -0300 From: Alexandre Oliva To: Mark H Weaver Subject: Re: Linux-libre 5.8 and beyond Organization: Free thinker, not speaking for FSF Latin America References: <87d03vv0nm.fsf@netris.org> <875z9kv41h.fsf@netris.org> Date: Mon, 24 Aug 2020 01:34:41 -0300 In-Reply-To: <875z9kv41h.fsf@netris.org> (Mark H. Weaver's message of "Sat, 15 Aug 2020 02:03:27 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.84 Received-SPF: none client-ip=217.69.89.140; envelope-from=lxoliva@fsfla.org; helo=fsfla.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/23 23:45:31 X-ACL-Warn: Detected OS = Linux 3.11 and newer X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel@gnu.org, Jason Self Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Spam-Score: -1.01 X-TUID: 77/GeykzVtPV On Aug 15, 2020, Mark H Weaver wrote: > Alexandre Oliva wrote: >> On Aug 12, 2020, Mark H Weaver wrote: >>> I also consider it unwise for all of us, as a matter of habit or policy, >>> to trust the integrity of the computer systems used by the Linux-libre >>> project to perform the deblobbing. >> >> I welcome double-checking of our cleaning up at all levels, but why are >> you setting a higher trust standard for us than for a project known to >> be at odds with our shared goals, such as Linux? > I don't understand how you reached the conclusion that I'm setting a > higher trust standard for Linux-libre than for Linux. You blindly trust Linux release tags, but not ours. OTOH, you're right that it's not a strictly higher standard. You also trust our cleanup scripts, even when we tell you they're not fit for the use cases you put them through. > The principle I'm following here is simply to avoid relying on the > integrity of any system if I can easily avoid it. You could avoid relying on the integrity of Linux release tags, and trust ours instead. That's what tells me you don't trust Linux-libre as much as you do Linux. You could use our tags, at the very least to check that you got something sensible out of your own deblobbing run, but you don't even look at them. You're not checking anything, so what you put builders through is at best busy, redundant work, and at worst, a waste of cpu cycles that doesn't even get them what they hope for. > However, I reject the argument that because we must > trust X and Y, we might as well trust Z as well. That doesn't follow indeed. What I'm saying was that, instead of trusting both X and Y, you might trust just X instead, while you insisted on trusting mostly just Y instead (but also X and a bunch of other tools used underneath). >> But the point stands that, for someone who'd rather trust no one, you're >> blindly trusting both Linux and Linux-libre. The former when it comes >> to base releases you don't check; the latter when it comes to scripts >> whose results you hardly even look at. Why not reduce your trust base >> to just Linux-libre, > That's not possible. Clearly, you do not have the capacity to audit all > of the code that Linux produces. Therefore, by trusting Linux-libre, we > must implicitly also trust the Linux project. That much we cannot > avoid. We also cannot avoid trusting your deblob scripts. True, we don't even attempt to audit Linux sources in this sense. This seems to imply that taking our cleaned-up sources, and taking Linux' sources and cleaning them up, carries exactly the same amount of trust on each project involved. And yet you prefer to trust the one that sneaks non-FSDG bits in every now and again, instead of the one that hunts them down and removes them. > However, we *can* easily avoid trusting the integrity of the systems > that you use to run the deblob scripts. You *could* avoid that, and also some blind trust on the underlying tools and systems used for cleaning up by us and by you, by at least *comparing* the cleaned-up tree you get with the one we provide. But that's not what you do. You distrust us enough to shed doubts on our processes, but you (and guix builders, trusting you) trust us enough to run our scripts for purposes they aren't fit, and trust a very complex and fragile combination of tools and systems to carry out its difficult job without giving their output a second look. > In fact, I strongly support reducing Guix's reliance on pre-generated > outputs produced by *any* project. I'm not singling out the Linux-libre > project here. You really are. You take most other projects' releases without anything even close to the amount of scrutiny and disregard that you place on the results of our release engineering processes and resulting release tarballs and tags. You might not think so if you consider the deblobbing scripts we publish for transparency and verification as our releases, but since they (very) occasionally remain unchanged even when new changes need to be made (*), say because they by chance already contain the code that makes the newly-needed changes, that supposed equivalence is a mistake. (*) just as I write this, I manually check 5.8.3-gnu and find a fresh example of this, also applicable to 5.7.17-gnu and 5.4.60-gnu. -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer