From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id CGKGBSmMNF9xEgAA0tVLHw (envelope-from ) for ; Thu, 13 Aug 2020 00:41:13 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id 0k1YASmMNF9vRAAAB5/wlQ (envelope-from ) for ; Thu, 13 Aug 2020 00:41:13 +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 84809940719 for ; Thu, 13 Aug 2020 00:41:12 +0000 (UTC) Received: from localhost ([::1]:52588 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k61It-0006uN-4O for larch@yhetil.org; Wed, 12 Aug 2020 20:41:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59114) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k61If-0006uE-2S for guix-devel@gnu.org; Wed, 12 Aug 2020 20:40:57 -0400 Received: from world.peace.net ([64.112.178.59]:53080) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k61Ic-0001ZS-T8 for guix-devel@gnu.org; Wed, 12 Aug 2020 20:40:56 -0400 Received: from mhw by world.peace.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k61IP-000466-61; Wed, 12 Aug 2020 20:40:41 -0400 From: Mark H Weaver To: Jason Self Subject: Re: Linux-libre 5.8 and beyond In-Reply-To: <20200809131541.2f6706cc@pc> Date: Wed, 12 Aug 2020 20:39:46 -0400 Message-ID: <87d03vv0nm.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=64.112.178.59; envelope-from=mhw@netris.org; helo=world.peace.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/12 20:40:42 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] 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_PASS=-0.001, URIBL_BLOCKED=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 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: UxloEYR7gAwG Hi Jason, I didn't see your email until just now. I read this list only sporadically, so it's best to keep me in the CC list for messages that you'd like me to see, or that are responses to me. Mark H Weaver wrote: >> the linux-libre project periodically deletes most of its older >> tarballs, even if there are no accidents. Jason Self responded: > Just FYI that git://linux-libre.fsfla.org/releases.git was created > mainly to solve that problem. Versions are now pretty much permanent. That's helpful, thanks. I didn't know about this. Out of curiosity, is this git repository advertised anywhere? I wasn't able to easily find it on , but I didn't look carefully, perhaps I missed it. One question: Would it solve the problem that I mentioned in my earlier email, namely the problem of how to determine which precise commit introduced a regression between two stable kernel releases? If not, I think that justifies the machinery that Guix includes to do the deblobbing itself. >> It may be useful for users with newer hardware devices, which are >> not yet well supported by the latest stable release, to use an >> arbitrary commit from either Linus' mainline git repository or some >> other subsystem tree. > > The cleaning up scripts are version-specific and won't work on an > "arbitrary commit from Linus's mainline git repository" (i.e., someone > wanting to get today's most recent commit going into 5.9.) The scripts > would fall over and die in such a scenario, Okay, perhaps this was wishful thinking on my part. I had hoped that the deblob scripts would typically mostly work, even if they weren't able to do a comprehensive cleaning. I would oppose adding such a partly-cleaned kernel to Guix itself, but I wanted to enable users who need to use some other branch of Linux on their own systems to make a best-effort cleaning. >> It allows us to update to a new point version (which usually >> includes security fixes) more quickly, before the linux-libre >> project reacts. > > Any attempt outrun the Linux-libre project and get updates out sooner > is unwise. While major new kernel releases will definitely require > updates to the cleanup scripts, even minor patched versions > occasionally require changes too. Updating to a new version prior to > the Linux-libre project having had time to review that new version and > determine if any updates are needed to the scripts risks introducing > freedom problems in the corresponding Guix version. In my experience, the deblob scripts are very rarely changed after the first few point releases of a stable release series. I know this because I always check for updates to the deblob scripts whenever I update linux-libre in Guix. In practice, the deblob scripts used by Guix are never more than 1 or 2 micro versions behind the version of Linux they are applied to. > The moment that the Linux-libre project determines that scripts are > suitable is the moment that the new cleaned-up release is ready to > publish in git and the appropriate tags will then appear in git. The > compressed tarballs come some time later. I prefer to avoid unnecessary delays when applying micro kernel updates, because I assume that many of the fixes are potentially security fixes (although they are rarely marked as such because upstream does not attempt to determine the security relevance of most fixes, which is reasonable). 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. It's not that I doubt the competence of those people who maintain or administer those systems; it's that I think it's unwise to trust *any* computer system that we can easily avoid trusting. Personally, I don't consider any modern civilian computer system to be trustworthy, and especially not one that paints a target on its back by being a potential vector for compromising the machines of large numbers of users. Enabling users to run the Linux-libre deblob scripts on their own computers (as I do; I *never* use substitutes) enables them to remove one computer system from the set of systems that they must trust. I think that's a good thing. Regards, Mark