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 wAU9Gz0KUF9EAgAA0tVLHw (envelope-from ) for ; Wed, 02 Sep 2020 21:10:21 +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 4MwsFz0KUF9DVwAAB5/wlQ (envelope-from ) for ; Wed, 02 Sep 2020 21:10:21 +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 DB3849401CD for ; Wed, 2 Sep 2020 21:10:20 +0000 (UTC) Received: from localhost ([::1]:51312 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kDa1K-0007fJ-8s for larch@yhetil.org; Wed, 02 Sep 2020 17:10:18 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45400) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kDa14-0007dV-98 for guix-patches@gnu.org; Wed, 02 Sep 2020 17:10:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:49331) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kDa13-0005vC-V1 for guix-patches@gnu.org; Wed, 02 Sep 2020 17:10:01 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kDa13-0003d6-PS for guix-patches@gnu.org; Wed, 02 Sep 2020 17:10:01 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#43173] Ensure that the correct linux-libre deblobbing scripts are used Resent-From: Mark H Weaver Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Wed, 02 Sep 2020 21:10:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43173 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: To: leo@famulari.name, 43173@debbugs.gnu.org Cc: Maxim Cournoyer X-Debbugs-Original-To: Leo Famulari , guix-patches@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.159908095213891 (code B ref -1); Wed, 02 Sep 2020 21:10:01 +0000 Received: (at submit) by debbugs.gnu.org; 2 Sep 2020 21:09:12 +0000 Received: from localhost ([127.0.0.1]:60877 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kDa0F-0003bz-PG for submit@debbugs.gnu.org; Wed, 02 Sep 2020 17:09:12 -0400 Received: from lists.gnu.org ([209.51.188.17]:58720) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kDa0D-0003br-RE for submit@debbugs.gnu.org; Wed, 02 Sep 2020 17:09:10 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45222) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kDa0D-0007Qw-N1 for guix-patches@gnu.org; Wed, 02 Sep 2020 17:09:09 -0400 Received: from world.peace.net ([64.112.178.59]:39134) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kDa0B-0005l5-Ia for guix-patches@gnu.org; Wed, 02 Sep 2020 17:09:09 -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 1kDa09-0005eB-7t; Wed, 02 Sep 2020 17:09:05 -0400 From: Mark H Weaver In-Reply-To: <20200902182922.GA26301@jasmine.lan> References: <20200902182922.GA26301@jasmine.lan> Date: Wed, 02 Sep 2020 17:07:56 -0400 Message-ID: <87363z28fs.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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/09/02 17:09:05 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 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-Spam-Score: -2.3 (--) X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Spam-Score: -1.01 X-TUID: fDZvCVLsB/9C Leo Famulari writes: > In recent discussions [0], people raised the possibility that we might > accidentally leave non-free firmware blobs in our linux-libre packages. > > If I understand correctly, the root of the issue is that, currently, we > manually specify the versions of the deblobbing scripts. They are not > changed with every linux-libre release, so it is usually okay to use an > older version number =E2=80=94 the scripts themselves will be identical. > However, sometimes the scripts do change, and we might not notice, and > thus we would fail to remove every blob from the kernel sources. > > These two patches should make that failure mode impossible, by 1) making > sure that the file names of the deblobbing scripts' store items include > the full version number of the kernel and 2) only defining the version > in one place. The hashes of the deblob scripts will be checked > automatically when Guix downloads them for each new kernel release. [...] > [0] https://lists.gnu.org/archive/html/guix-devel/2020-08/msg00040.html In the aforementioned discussion, I agreed to either: (1) Wait until the linux-libre project publishes a new release, or (2) Check for new blobs myself in the upstream release. Since then, I've actually chosen option (2) a couple of times. I did so by reviewing each of the upstream commits looking for new blobs. I found that it took on the order of 10-15 minutes per release. With this proposed change, we will lose an easy way to exercise option (2), and will effectively be constrained to always wait until linux-libre produces a new release. I'll leave it to the maintainers to decide what to do here, but I wanted to make it clear what's at stake. Personally, I do not find Jason and Alexandre's arguments compelling, and would be in favor of retaining the option to push these security updates more quickly by checking for new blobs manually. Thanks, Mark