From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id sIdSOZI9UWAhNAAA0tVLHw (envelope-from ) for ; Tue, 16 Mar 2021 23:21:54 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id 4IoANZI9UWBFHgAAbx9fmQ (envelope-from ) for ; Tue, 16 Mar 2021 23:21:54 +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 67C6A16936 for ; Wed, 17 Mar 2021 00:21:54 +0100 (CET) Received: from localhost ([::1]:33014 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lMJ0b-0004IZ-HT for larch@yhetil.org; Tue, 16 Mar 2021 19:21:53 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57830) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lMJ0N-0004HF-Ti for guix-devel@gnu.org; Tue, 16 Mar 2021 19:21:41 -0400 Received: from world.peace.net ([64.112.178.59]:33778) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lMJ0J-0002qG-Gb for guix-devel@gnu.org; Tue, 16 Mar 2021 19:21:39 -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 1lMJ0E-00076w-Vb; Tue, 16 Mar 2021 19:21:31 -0400 From: Mark H Weaver To: =?utf-8?Q?L=C3=A9o?= Le Bouter , guix-devel@gnu.org Subject: Re: [opinion] CVE-patching is not sufficient for package security patching In-Reply-To: <9b9a43a584e2dc70488482fce5931b46abd0e006.camel@zaclys.net> References: <9b9a43a584e2dc70488482fce5931b46abd0e006.camel@zaclys.net> Date: Tue, 16 Mar 2021 19:19:59 -0400 Message-ID: <87v99qit39.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-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-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: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1615936914; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=QgrP+uM0qNA1vWQF8sGm+Dk+cY2rp5E+qqsgJH44ANM=; b=HcONqdSYGTTTl51oIfN+YDC5aDWxLMgtppxk3KW9FYex2XU4dFcjAWly88zsZ3mQ5nYlSy 7WHgoN8JIAraKOqV2HPbBa86DRV0waml1oCNx6iUxvw6Jv28k/CVc5DUN2G2F2uN5ZW946 cZ9LRbUuTERZ57Bo92mhdY3FA2hZPWhxbWyiv4+Oj+BXetizwe1FcoJ6RUv1F/WkoZoyOk wZ7Wrvou7i6XBO3azWHhJiGGJN9rKJmNj/hVRODuzc9mBJWOTsgjHqHvnP9woGp6nZkVi6 3RxpE+AcoTknEeBSbrPVrayeuF79joBOdZwRMCabe5Zzs+ISddhDZg9P9wiZRQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1615936914; a=rsa-sha256; cv=none; b=etWeUxKgwtoUDUm0wjUZ1jgzbk4j9Tmhp//03td7fQJi8NVB9r9pAhlkaiatsfjOIyc0ND N24ifxq8ndQakySsiA97aUDOGhKmYmFkmBRKEDQMsgJl1dJzJ805cGcTsLhrqRIeEIXbk3 rQ6n+jqu9UeX1zW2hIuuJSEH/X8nNVEOcwnHoLk07frUxngCdVyr3jR+1HOKDqxYHn4+jU nEPRsHDA/NhW/wJpLUNWxBQbKp9cfDYbVcb79nCtXtVn9qvtfEpWczWoQJ2tyQse8IutmK Uq965Z75aqd5Z4aJPs0c9ioimHpf/1kV8ZLzBfzHR0AbaH4LCwBcGzomblzimQ== ARC-Authentication-Results: i=1; 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-Migadu-Spam-Score: -2.40 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-Migadu-Queue-Id: 67C6A16936 X-Spam-Score: -2.40 X-Migadu-Scanner: scn0.migadu.com X-TUID: WJCx6752PlUc Hi L=C3=A9o, L=C3=A9o Le Bouter writes: > I would like to share some opinion I have on CVE-patching for non- > rolling release GNU/Linux distributions and why we should strive to > always update to the latest available releases or always follow > upstream supported release series and never backport patches ourselves > in most cases (some upstreams may have really good practices but these > are rare). > > A lot of security issues are patched silently in upstream projects > without ever getting a CVE, security issues may not be labeled as such > by upstreams for various reasons (fear of shame, belief to patch > something with no security impact while it has, bizarre security > through obscurity policy, ..). ... and I'll add that it can be a lot of work to evaluate, for a given bug, whether or not that bug is exploitable. Anyway, I agree that bugs fixed upstream are sometimes exploitable, even when they have not been explicitly identified as security flaws, and that this is a valid argument in favor of keeping our packages updated to the latest release. That said, I strongly disagree that we should "never backport patches ourselves in most cases". The only way to do that, while addressing security flaws, would be to promptly update even our lowest-level libraries in response to CVEs, of which there is a steady stream. Anyone with experience working on the 'staging' or 'core-updates' branches in Guix, or in the release process of Debian, will immediately recognize this proposal to be unrealistic. In practice, updating low-level or even mid-level libraries tends to cause breakage. This kind of integration breakage happens quite frequently, even on x86_64-linux, the architecture that most developers work on. It's *much* worse on other architectures. New upstream releases quite regularly cause breakage on less popular architectures. It is often left to distros such as Debian to fix these problems. Since you're interested in security, I'll now remind you that *all* modern Intel systems include another little computer inside them called the Management Engine, which is always on when the machine is plugged in (even when the computer is "off"), has it's own memory that the main CPU cannot see, runs a proprietary OS that the user cannot replace, has full access to the RAM and disk of the machine, and can talk to the network without the main CPU even seeing those packets. Are you comfortable with this? If not, it would be good to work toward the goal of making Guix usable on non-Intel systems. I'm sorry to say that, in my opinion, your proposal would move us in the wrong direction to achieve that goal. In my experience, Guix is already moving far too fast to be usable on less popular architectures. I have some knowledge of this. Years ago, I made a serious effort to make Guix usable on non-Intel systems. When Guix was young, I initiated its first two ports to non-Intel architectures: mips64el-linux and armhf-linux, and I tried to actually use Guix on those systems in practice. I found that my system was very frequently broken by upstream updates, and that we didn't have nearly enough developer energy to keep up with fixing those problems. I've come to believe that having Guix work well on non-Intel systems is, in practice, incompatible with the rate at which we update our packages. I'm not sure that even Debian would have enough energy to keep less popular architecures working well, given our practices. I raised this issue on guix-devel a few times over the years, but it became clear that the desire in this community to keep packages aggressively updated far outweighs any interest in supporting non-Intel systems. Ultimately, I gave up. In my opinion, Guix has never achieved usability as a desktop system on non-Intel systems. Therefore, the Guix community is unable to attract many developers who want a distro that supports non-Intel systems well. Our community has thus become dominated by Intel users, and there's unsufficient political will to adopt policies that would enable us to provide a usable system for non-Intel users. What do you think? Regards, Mark