From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:8:6d80::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id +OSRNqZcXmDTYAAAgWs5BA (envelope-from ) for ; Fri, 26 Mar 2021 23:13:58 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id +EdnMKZcXmDUSQAAB5/wlQ (envelope-from ) for ; Fri, 26 Mar 2021 22:13:58 +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 3717F1BC4A for ; Fri, 26 Mar 2021 23:13:58 +0100 (CET) Received: from localhost ([::1]:46246 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lPuiL-0002ZL-8G for larch@yhetil.org; Fri, 26 Mar 2021 18:13:57 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58622) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lPui4-0002Xd-G0 for guix-devel@gnu.org; Fri, 26 Mar 2021 18:13:40 -0400 Received: from mira.cbaines.net ([2a01:7e00:e000:2f8:fd4d:b5c7:13fb:3d27]:38697) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lPui0-0000Mk-Gs for guix-devel@gnu.org; Fri, 26 Mar 2021 18:13:40 -0400 Received: from localhost (unknown [IPv6:2a02:8010:68c1:0:8ac0:b4c7:f5c8:7caa]) by mira.cbaines.net (Postfix) with ESMTPSA id 870B427BC5C; Fri, 26 Mar 2021 22:13:32 +0000 (GMT) Received: from capella (localhost [127.0.0.1]) by localhost (OpenSMTPD) with ESMTP id 842e7fcd; Fri, 26 Mar 2021 22:13:32 +0000 (UTC) References: <12b4006a4a28c9678c523ab129945850b4adf37f.camel@zaclys.net> User-agent: mu4e 1.4.15; emacs 27.1 From: Christopher Baines To: =?utf-8?Q?L=C3=A9o?= Le Bouter Subject: Re: Security patching and the branching workflow: a new security-updates branch In-reply-to: <12b4006a4a28c9678c523ab129945850b4adf37f.camel@zaclys.net> Date: Fri, 26 Mar 2021 22:13:29 +0000 Message-ID: <87eeg1a7hy.fsf@cbaines.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=2a01:7e00:e000:2f8:fd4d:b5c7:13fb:3d27; envelope-from=mail@cbaines.net; helo=mira.cbaines.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_PASS=-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: , Cc: guix-devel@gnu.org 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=1616796838; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post; bh=3vRWFopi/1zONjX1hAUVQrHdua//PalPW5kNC4UEk4g=; b=oGW5P3l8Iu0H/5iZK63Kc6RI2NSIaHU+3GJO2yfDaRt1z9ak/jVGQGZam3W6GTCMI7Q2b7 WrKUeu3bhHRq4DZpy+Gb78I7z6h2QN/SNKaND0Pz0wxhucw/iX2uJ0z6hMk6ItCk5Nm2mr DrF+wLC1S0x9uTWQJhq3HbGJZr4IykfLsq2/w+Ta22XuLTk61VN56YU88JaGII9ucA5gpW rfMiK9r/ifqTwqJzRuepaENAObeoiMBqLssnAQAs1/i7u4dCOM7E3hfxooBY6PzQK7Vi8i UdWw2MdFbnOOMEYXsR0KaDzGxfyk9m5aSyHKGapwjD+IKsBBmKo2cwHUuCFAqQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1616796838; a=rsa-sha256; cv=none; b=Nis67Hq34LFGI3DqvUgZCyDmqyN0PUmhAweWdn8oj4POkxj7z8nMtvMqtK/CNLWBQOG2mn uYPnlVRD3YiAT6nNiRZBz+KwqIP5J+zI/Hs6IBtrcjxjN8xhWecq0B6UIz2+Vn/PbtLgNW CVnnffupd28WH4dpo1z/JU5567Q7hKPfnZ19jBXBxpsMJq+2R2B+thkiThqp7bAydLIkZt uOlGKvdQzzVVXi5oRT3ljmGESPLiZMCPlO4xjYVtVMQBTyankLWH8v/SRolsKYJAPMKYCt 9pRFX4F5iDdeEo2ZOGn7KqhegZ3YZbTErA/8pDCcuPuZuXRgEIFpVJjYKwu2Mg== 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: -4.52 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: 3717F1BC4A X-Spam-Score: -4.52 X-Migadu-Scanner: scn0.migadu.com X-TUID: BX5tXh2edyuJ --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable L=C3=A9o Le Bouter writes: > There is two ways to ship security fixes to packages: > > 1. Update to a patched version if upstream provides one > 2. Apply or backport individual patches to fix the issues in the > shipped version > > Grafts are most reliable for 2. but there's cases where using 2. is > lots of work and we can't afford that right now. An example is > ImageMagick where not all security issues get a CVE so essentially the > only way of getting security fixes is to fetch master or get the latest > release. > > There's also some types of packages where we are not sure whether we > can use grafting or not, such as Python ones. > > For these reasons, I would like to propose a new branch called > security-updates that would be based on master where we queue security > fixes that introduce any arbitrary number of rebuilds without using > grafts. > > We would merge the security-updates branch as soon as there is complete > substitute availability for the branch and it's future merged version > within master. > > The downsides of this approach are that: > > 1. Substitutes availability does not mean we can ship the updates > quickly because this might mean hundreds of megabytes if not gigabytes > of new substitutes to fetch to actually get the update. > 2. Users that don't use substitutes will suffer big rebuilds on each > security update shipped through this branch. > > For these reasons, grafting should still be preferred when possible, > but there are cases where it cannot be used for technical reasons or > lack of resources reasons but we still must provide a fix quickly. > > What do you think? Can you clarify what specific problem or problems you're proposing this security-updates branch to address? You mention applying and backporting patches is lots of work, and uncertainty around whether grafts work in particular situations. Personally I think staging and core-updates are quite a bit of work, and adding more complexity to the process involves more work in my mind. Additionally, this isn't going to provide more information about areas where grafts can't be used (if those exist). Now the software involved is getting better at rapidly building things for substitutes, personally I see a way forward through trying to measure and potentially increase the rate of change for outputs in general. Going faster also involves more work probably, but in terms of the process, that might just mean that updates to more packages can be merged to master directly, without sitting on a non-master branch. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmBeXIlfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh aW5lcy5uZXQACgkQXiijOwuE9Xde1w/+IqCRXWLp671dIA4Y1qY7GBYZnxXY8HYa XBizcjHJRrjZmC4OUu9Ez5NUHVXBZfaqXVZInpvSGrN8bdUlAMon+PMcPXbYA0GN q1G78m0SNZ9e6tPGTI4WPB7NsVrZ7fJagXr0WcfGi6M0gwuOD4cakBl91Yd/IWF/ WH7lDb0G/x68W2qNwnR8xi60bpeVFHRC+3bUE3oYO0SF9g1yWH5eXGeJAkpQ4fei ph0A2TAZ2CKO6EEz67foaTW1H1FoWoxegkOxod6ZKhTds2PGg3Jd95IiiQQqn1jG aRwOp8wgdMCYFSx+ACHKmvp4pWpMB+RrMs9Iv14DWcVp3wJpNqUp7Zgq2aylM1b/ ejTI8DftDUUVMsWENAWAVX3OzwpXG8DwOKDjlOkDPSYdtjOM6MusoOf4xuSN067w jyk2SwadM9+vr7zosaGUGFYfbPsw7u9taEuGnw4/zhWf8Bs0vK90JLfmvSfhGTh8 vYqdG78anBJnOpX3SOUPBbbhOGBdIpCUJfWoxa6VgSsYiM7Wu+uWI5oMJ6jLMQn+ LRxCkrQxPrpSixVG9sxacifPClRkAMG8q+Xkf+FIH0399dxVOwVs1nyk3g+QOP6+ rNR37MF5prRGSgCdVYBZ782CNmV3WGrlzLqiBvZzsL00OY6q6Eaap3+suGJ0dZz/ ZbmVOtRyYmg= =/C32 -----END PGP SIGNATURE----- --=-=-=--