From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id EKl9LR/fE2XV3wAAG6o9tA:P1 (envelope-from ) for ; Wed, 27 Sep 2023 09:51:59 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id EKl9LR/fE2XV3wAAG6o9tA (envelope-from ) for ; Wed, 27 Sep 2023 09:51:59 +0200 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 1841A5A11D for ; Wed, 27 Sep 2023 09:51:58 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=loang.net header.s=default header.b=Xrc3J9a1; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gnu.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1695801119; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:content-type:content-type: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=rauPq94fg6YlRxzoYO98+eZRft5aFvL5t2TZsmuoRzM=; b=A3pOeyVTwFINPjZQrBVZguAXfvNulDZuU4PbbBzh1FGB7iZiVseGAgiwXkndiYu43ZQFVK Nv184zz+1KeSNZomtLUo5Jj7SsJg14K5QfQ5RrT6rVJXrFo6ieB6C2YEgn0nnxhhvSZUCB sBCfEcXxtQ6mQk20tzI3E5dVeC+7t1EZ/qeHKz7tXJAGMjrSc9rg93jm4upJBCyWNFDd30 kzjWtYPNYHROPS67KsLLvon/RIZGqH3fbh0l5GahX+5gMM/dYkDi38xT+3+xArzVCMcz+K VhX92fyD9akjNX3EPVm2kplurizAfvd2jg3Mucc8AtE/s9dm8nVHYr8OYdGuhA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1695801119; a=rsa-sha256; cv=none; b=m81pSi87YHNsxZZltE/rBSC33KI8xncJlnjqjnRvHAqrn5z4ic2ic0QM25tOE3fGb+TGBl VDz8nntniWj/vLEgKfxGxc4/oCuwTnwvXUeybSlWNU5fHXUfvFBaqovpf85C8BRu0H5bPu kFnplddRSjfDrzP5gsDFlqA5M7IVjt2oGs0NR5R+b4OTa9OJAIh4IXV6Dp/UH+127xQn42 DB1N9RxhsLTXwpFCY1pqC8mgHJtanYuZts4DzsBNoC045iqqA5jG+FBYomvq9+IMbyrZxg N0Z3kHvlax+epS5T4y8aR/wgT/ZuyLO8DwkPiLpx8bZy3SQ0xh6bilrT/5wWAg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=loang.net header.s=default header.b=Xrc3J9a1; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gnu.org Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qlPKT-0008Uf-Ml; Wed, 27 Sep 2023 03:51:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qlPKR-0008Su-He for guix-devel@gnu.org; Wed, 27 Sep 2023 03:51:27 -0400 Received: from tem.loang.net ([2a03:3b40:100::1:2]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qlPKP-0002AV-Pv for guix-devel@gnu.org; Wed, 27 Sep 2023 03:51:27 -0400 DKIM-Signature: a=rsa-sha256; bh=rauPq94fg6YlRxzoYO98+eZRft5aFvL5t2TZsmuoRzM=; c=relaxed/relaxed; d=loang.net; h=Subject:Subject:Sender:To:To:Cc:From:From:Date:Date:MIME-Version:Content-Type:Content-Type:Content-Transfer-Encoding:Reply-To:In-Reply-To:In-Reply-To:Message-Id:Message-Id:References:References:Autocrypt:Openpgp; i=@loang.net; s=default; t=1695801071; v=1; x=1696233071; b=Xrc3J9a1cy+5OTZP1XAm1Tnp6B9685rC5fly2WkgQFqXKdEVw/iNeCZ8ZJApCYXNzcQQ3Hr1 hjqaXK5jSySlGEPEuEpbOrbgJcNIGpUKDrODlF4EFVaGyB0DwOOZESfVJ287qHN1xtpcHoSUrdK +SfO75KgM1PX/kpl+ubbZdoZYV8jeu3zJpsxUw5dHboS1nSroBOT7Cg3ZtOAjGmv99ogbQyy6k1 eZGiiqLusxYANM4ZaEpcBNlnwA5Rep52jFFgB4Pv8UT4eT9vICFA6bzqbZALB/a8E7XGeDzIgJg RgMZP3wITdg0zVL+wn+DphuUP5BJnHWybMgq6KOW33x6A== Received: by tem.loang.net (envelope-sender ) with ESMTPS id 24d15443; Wed, 27 Sep 2023 07:51:11 +0000 Content-Type: multipart/signed; boundary=dcd0703fe5f5cefb70c8712233f27bd55b13114550d2f96e8eb3e8b4986c; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Wed, 27 Sep 2023 16:51:04 +0900 To: "Distopico" , Subject: Re: Pinned/fixed versions should be a requirement Message-Id: References: <87h6o9pbbv.fsf@riseup.net> In-Reply-To: <87h6o9pbbv.fsf@riseup.net> Received-SPF: pass client-ip=2a03:3b40:100::1:2; envelope-from=cnx@loang.net; helo=tem.loang.net X-Spam_score_int: -12 X-Spam_score: -1.3 X-Spam_bar: - X-Spam_report: (-1.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MIME_HEADER_CTYPE_ONLY=0.1, SPF_HELO_SOFTFAIL=0.732, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-to: =?utf-8?q?Nguy=E1=BB=85n_Gia_Phong?= From: =?utf-8?q?Nguy=E1=BB=85n_Gia_Phong?= via "Development of GNU Guix and the GNU System distribution." Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Spam-Score: -6.37 X-Migadu-Spam-Score: -6.37 X-Migadu-Scanner: mx1.migadu.com X-Migadu-Queue-Id: 1841A5A11D X-TUID: ZbmpLDt9wzJb --dcd0703fe5f5cefb70c8712233f27bd55b13114550d2f96e8eb3e8b4986c Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 The dependency graph visualization has been discussed by others more knowledgable of the Guix ecosystem than me, so I'll focus on titled topic. On 2023-09-04 at 21:59-05:00, Distopico wrote: > `rust-my-lib-1`, where "1" refers to the semver "1.x" of the package, > e.g., "1.0.32", and `rust-foo` depends on `rust-my-lib =3D=3D 1.0.32`. > However, in some other package got updated to "1.0.34" so `rust-foo` > will break. > > [...] It makes it more likely that if a dependency changes, > many packages will need to be updated/rebuilt due to that change. This is not a bug but a feature, so that a fix can be rolled out simutaneously to many if not all programs. Recall the OpenSSL incidents, and more recently, libwebp. IMHO as software integrator, distribution maintainers should provide feedback to upstream to relax version pinning, preferably with patches. I know first-hand this is not easy, but otherwise we might as well just tell users to directly invoke e.g. Cargo, since packaging without system-wide integration is just extra hassle without any of the security benefits. In the alternative world where dependencies are pinned, distros can also patch each vulnerable version, but delaying efforts until emergency is hardly wise. On 2023-09-04 at 21:59-05:00, Distopico wrote: > Over time, it becomes more vulnerable to libraries/packages breaking. I'd like to add that this is not wall clock time, but labor time. This would not be an issue if Guix has enough contributors (and maintainers to actually apply to patches) to perform integration, as discussed in the parallel thread. On 2023-09-04 at 21:59-05:00, Distopico wrote: > It makes reproducible software more challenging, > as "1.x" can encompass many versions. FMIIW, but the Guix way of reproducibility expects both channel version and derivation name[, version]. With free software philosophy in mind, reproducibility is not so beneficial without the ease of modification, which in this context includes changing dependency[ version]. I'm speaking as someone primarily using Nix and seek Guix for correctness, e.g. not making it impossible to patch a Go library system-wide. On 2023-09-04 at 21:59-05:00, Distopico wrote: > For these reasons, I believe that pinned versions should be a > requirement in libraries, always specifying the exact dependency, for > example, `rust-serde-json-1.0.98`. > > This brings the following benefits: > > - Fewer packages will be prone to rebuilding > when changing the definition of a library. > - Reduced likelihood of libraries/packages breaking. > - Easier maintenance of packages and libraries > without fear of breaking others or having to update many. I'd like to point out these exact benefits could be achieved by distributing binary built by upstream. --dcd0703fe5f5cefb70c8712233f27bd55b13114550d2f96e8eb3e8b4986c Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iIQEABYIACwWIQSDiv4NVdwHTjYPlDqEtpzm8/a3ZwUCZRPe6w4cY254QGxvYW5n Lm5ldAAKCRCEtpzm8/a3Z6oaAP95WQsc2mR144idsG8FIHE1nmXO1sJ4I0GJz23D E1NH9AD+KyMTii3iVoYu/vUYgsqFpwCbA1dBYg1aNvaGHzJqjQg= =OWo8 -----END PGP SIGNATURE----- --dcd0703fe5f5cefb70c8712233f27bd55b13114550d2f96e8eb3e8b4986c--