From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:1008:1e59::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms1.migadu.com with LMTPS id gCHMBaR3WGaFnQAAA41jLg (envelope-from ) for ; Thu, 30 May 2024 14:57:08 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id ENSQOqN3WGY55QAA62LTzQ (envelope-from ) for ; Thu, 30 May 2024 14:57:08 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20230601 header.b=i+LFvEX8; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1717073827; 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: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=gT7qA/kFBTS7vBXgv0XsSVZkxfRk78wjBkruN2+rY2g=; b=VxnwgAjTDxVcEEkQzixRJSsd+Pf2mi6pCj1ywgF6q+w32lwYP+46AiDROpkO+9zc1bGSS1 FaDECSXQSnPUcthbEgeF6qLKIxduZNi+MVRCrbljMqHQ1PU9VRDcq+3FFbQkfY9rB1MPXi c4Bqnw+sg9hdriyuVtcH5ezk7mT4ppDRd9tlra0MV76ePqTXSiXWN7YbU9wOMxccwfZ6iC 3bOkLJeI7AZUto5bIS9MaW3ZkIqPFaar4AQ5bKv6r0q2hWrW806bNUjyc0wKfs/8TeK6fw +9HePH7rGmjMl6Uck7rQGp0OKnzYXMbRZeE5Mvaq/bRwhwA4Unr4rDJkjHaRYw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1717073827; a=rsa-sha256; cv=none; b=HvYNeJ42n+Nv2j8YtY0Cq5oOziPD2hBSOeB4VrA3IGmuO5dmcu3UnEmHb7fObBNci+DYfo WkxktkeDx228vIfa0E6JC4iLS/F+5w1GNi8reO6Gg2Y9qYJYt5l/5sKbskmNcJDuX03ZmO wr89m1/tc94xDhcpewr3aw+ofBvGC2xKZSuf9s4D0sQVbJZIxMgFvKQmkfcdrH//T1j8RN WnZh9ep94kx5faujsFCprgQORlV2n7iWkTg0lSBdmMTxzaMzGPur78YXbfS0jUkmMF1uuP tjllvFqJjJyAi8ym3ipGaMmv54byvEjhKYdgKEpyGJSw3GV9h3KPN5G2XvXSZA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20230601 header.b=i+LFvEX8; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" 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 77DCEC218 for ; Thu, 30 May 2024 14:57:07 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sCfKw-0007kY-71; Thu, 30 May 2024 08:56:54 -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 1sCfKu-0007kC-KQ for guix-patches@gnu.org; Thu, 30 May 2024 08:56:52 -0400 Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sCfKu-0003cP-Ce for guix-patches@gnu.org; Thu, 30 May 2024 08:56:52 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sCfL4-0007t1-KZ for guix-patches@gnu.org; Thu, 30 May 2024 08:57:02 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#71121] [PATCH 2/3] gnu: librewolf: Rebuild source tarball Resent-From: Maxim Cournoyer Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Thu, 30 May 2024 12:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71121 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Ian Eure Cc: 71121@debbugs.gnu.org Received: via spool by 71121-submit@debbugs.gnu.org id=B71121.171707377130226 (code B ref 71121); Thu, 30 May 2024 12:57:02 +0000 Received: (at 71121) by debbugs.gnu.org; 30 May 2024 12:56:11 +0000 Received: from localhost ([127.0.0.1]:34214 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sCfKE-0007rR-8z for submit@debbugs.gnu.org; Thu, 30 May 2024 08:56:11 -0400 Received: from mail-qk1-f170.google.com ([209.85.222.170]:53611) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sCfKB-0007r1-FD for 71121@debbugs.gnu.org; Thu, 30 May 2024 08:56:08 -0400 Received: by mail-qk1-f170.google.com with SMTP id af79cd13be357-7930504b2e2so43277385a.3 for <71121@debbugs.gnu.org>; Thu, 30 May 2024 05:55:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717073690; x=1717678490; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=gT7qA/kFBTS7vBXgv0XsSVZkxfRk78wjBkruN2+rY2g=; b=i+LFvEX8ZpXIVvXgRM1H+P+U+eAoe87JNGzqRQZM/JJHwo+z3FduFXst9Rz4uHXiRZ PtqPt9dgJcCLnf/rYptoqhSCrSIp7tg2AZsux6+SwFoe9Ezk9Vb8qB+B/eH7vw2mN6+K 2QFJ+5EVHoC0YoCDTLAw3OY5WvkFkIx747WH93NWcgUduO42OMdwKb15tvy8Vv3Q8hsA tfeIeC84aNI6/ff01mqsf+iMPtP+2IwUnka6ss4xiVfV+iFcUdsKJL4e4S88/vb9YbQj 3eDvZ6T+uYWgSn6akOV9Adu5lbmPHK5zRjCHEOR9UWnCyJaRjPZXiK83HBzC/hUua2Gq SMmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717073690; x=1717678490; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=gT7qA/kFBTS7vBXgv0XsSVZkxfRk78wjBkruN2+rY2g=; b=kiIz3UOauE2V+R9E+ZdhQSELzJVmTcHSvi36XPzSxgCt5JOaYU/qzCnTcMqPYdrbCA 5GyJlO3A9nBgvESvM/VZqLNrE6CxgYTZcpCU8yv+X+Jz0WfYabZ0G0VgmcUC2OUNyIV8 P33qMlROmXszq+Rn9rAkG9pspKiWNn646Yso1ISOzXhWOUA3q8cNZBb/YRLxX2y7dqt/ qaHaLZW0gx3isJ4eKBJ6Jt0lC19CBDsEzhdIND3Z+w5KkMk4nGaYLY11Ck9A0zi1X09B SmaO63hACMSAC0mxQv44wtiSuSbLPcLICQbWS/j2JLAazJP4e4/3EX0gedMaNORj5IBB etWQ== X-Gm-Message-State: AOJu0Yxh/xHI78iPT2wd9HcPDUhYI44iFUmkcyWZt+xIkBc1T5EnzAT9 bkUyiDCzR6u4M4k3KBIrIoMXG8SIWWKBttMovwyrvxcaSbjm+lU/6a+hmQ== X-Google-Smtp-Source: AGHT+IE+PEMtDRIVgmWyolutL9jqar7h/BMrLMwPtDpTvB0UVjEJ6ivSjHhXn7Fd6pVqNAk5t5/h/w== X-Received: by 2002:a05:620a:25d4:b0:794:70cb:8 with SMTP id af79cd13be357-794e9dc039amr252026685a.40.1717073689984; Thu, 30 May 2024 05:54:49 -0700 (PDT) Received: from hurd (dsl-205-233-124-92.b2b2c.ca. [205.233.124.92]) by smtp.gmail.com with ESMTPSA id af79cd13be357-794abd063f1sm553013585a.72.2024.05.30.05.54.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 May 2024 05:54:49 -0700 (PDT) From: Maxim Cournoyer In-Reply-To: <87a5k8uh9f.fsf@meson> (Ian Eure's message of "Wed, 29 May 2024 18:48:11 -0700") References: <20240522145956.31218-1-ian@retrospec.tv> <20240522145956.31218-2-ian@retrospec.tv> <87jzjcf5nk.fsf@gmail.com> <87a5k8uh9f.fsf@meson> Date: Thu, 30 May 2024 08:54:48 -0400 Message-ID: <87plt3e9yf.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -2.25 X-Spam-Score: -2.25 X-Migadu-Queue-Id: 77DCEC218 X-Migadu-Scanner: mx11.migadu.com X-TUID: xDf9yyBGramW Hi Ian, Ian Eure writes: > Hi Maxim, > > Maxim Cournoyer writes: > >> Hi Ian, >> >> Ian Eure writes: >> >>> * gnu/packages/librewolf.scm (librewolf): This patch removes an >>> intermediate >>> step in the build chain. The upstream source tarball is created >>> with an >>> automated build process, where Firefox sources are fetched, >>> patched, and >>> repacked. Rather than download the output of that process, as the >>> package has >>> been, it=E2=80=99s now replicated within the build process, similar to = how >>> IceCat >>> works. >> >> I think I'd rather keep using a human-prepared and vetted tarball, >> to >> avoid anything going stale in our local recipe of how it's meant to >> be >> prepared. >> > > The upstream tarball is built by scripts run under a CI system which > triggers when changes are pushed[1], and aren=E2=80=99t human-prepared or > vetted in the same way that many release tarballs have tradionally > been. This patchset uses the same script as upstream, with > modifications to make it reproduceable, as the upstream process isn=E2=80= =99t. Perhaps the modifications to make it reproducible could be shared to upstream? We'd benefit all thee users of librewolf this way, not only Guix ones. > As noted in the commit messages, IceCat also builds this way[2], > including patching the upstream build script[3][4], so this seems like > a reasonable & accepted way to build. Though perhaps there=E2=80=99s > dissatisfaction with the IceCat build which I wasn=E2=80=99t aware of, be= ing a > fairly new contributor. The "dissatisfaction", if we can call it that, was about Linux-libre, and voiced by some a few years ago, including the project maintainers, if I recall correctly. The idea of linux-libre is to shield users from blobs. In this sense it is valuable that they don't even have to touch the pristine blobbed (there are a few array-defined firmwares in the tree still, at least one old Apple one IIRC) Linux source, which is considered problematic for some from a GNU FSDG perspective. >> It's also simpler and less maintenance, and arguably shields >> the users better against non-free source code (although I don't >> think >> there's anything non-free in the Firefox tree, so that point is more >> moot than say, for linux) to use a tarball. >> >> What do you or others think? >> > > It=E2=80=99s definitely simpler to use the upstream tarball in most cases, > which is why I went that direction when I initially packaged > LibreWolf. But, since IceCat builds this way, and the xz backdoor was > discovered hiding in the non-reproduceable build process, I=E2=80=99ve be= en > intending to update the package to control the full build, rather than > trusting an unreproducable external process. I understand that if the > build scripts are backdoored, it doesn=E2=80=99t matter whether upstream = runs > them or Guix does, but I believe that aligning with IceCat and having > a reproduceable build directly from the upstream source repo are > worthwhile. Right. > In the specific case of the 126.0-1 release, owning the whole build > process made things easier. Upstream backported a very large Firefox > change[5] which updates a bundled dependency to a new version; that > dependency doesn=E2=80=99t work with Rust 1.75, which is what=E2=80=99s i= n Guix. With > the Guix build process controlling what patches get applied, I was > able to solve the problem by removing one line from the manifest of > patches to apply to the Firefox source. If the package builds from > the 126.0-1 tarball, it=E2=80=99ll need to ship a 22,000-line patch(!) to= back > out that change. That may still be necessary, depending on the timing > of the rust-team branch merging and the next Firefox release, but at > least for now, things are simpler. Ideally, this wolud be solved by > unbundling that (and the other) vendored Rust libraries (and that=E2=80= =99s > something I intend to look into), but I didn=E2=80=99t want to block secu= rity > fixes on work with unknown-but-probably-large scope -- there will > almost definitely be Rust libraries currently not packaged in Guix > which need to be addressed. OK, this flexibility seems indeed useful here. > As far as maintenance burden or things getting stale, the risk is that > upstream alters their scripts, which requires updates to the Guix > patches for them. This doesn=E2=80=99t seem like a major drawback to me,= and > I=E2=80=99m the one doing the maintenance. :) Overall, I think it=E2=80= =99s a > reasonable tradeoff for the reproducability we gain. If this approach > to building LibreWolf in this patchset is acepted, I=E2=80=99d like to wo= rk > with upstream to make their build process more flexible, ideally > running it unmodified in the Guix build, which would eliminate the > risk. Yes, you are the one doing it (thank you!) until you won't :-) (life...). Then someone else would have to pick it up and understand it. The simpler the better. > Lastly: I noticed that I neglected to update %librewolf-build-id when > I sent this patchset in. If my arguments are compelling enough for > you, I think it=E2=80=99d make sense to update that when the changes are > pushed (it=E2=80=99s a one-line change & the command to print an ID are i= n the > comment above the variable). But, if you=E2=80=99d like a v2 patchset, e= ither > just to update that, or to back out the build process change and > replace it with a 22kloc patch, I=E2=80=99d be happy to handle it instead. The 22kloc patch doesn't sound too good... I guess we can stick with the self-made tarball for now. > Thank you very much for your thoughts and the time you took to > respond. Sorry for the delay handling this security-sensitive issue (still better than our ungoogled-chromium package which appears untouched for a full year, though! We should probably open a security issue about that). If you could send v2 with the build id thing, I'll try to apply it quickly. --=20 Thanks, Maxim