From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id cHAAAWE+Q19sLAAA0tVLHw (envelope-from ) for ; Mon, 24 Aug 2020 04:13: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 mp1 with LMTPS id sLFROGA+Q19ZNQAAbx9fmQ (envelope-from ) for ; Mon, 24 Aug 2020 04:13:20 +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 5AB5D94062E for ; Mon, 24 Aug 2020 04:13:20 +0000 (UTC) Received: from localhost ([::1]:58512 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kA3rD-00062v-64 for larch@yhetil.org; Mon, 24 Aug 2020 00:13:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39514) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kA3r4-00062n-S7 for guix-devel@gnu.org; Mon, 24 Aug 2020 00:13:10 -0400 Received: from fsfla.org ([217.69.89.140]:48344) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kA3r2-00019q-MO for guix-devel@gnu.org; Mon, 24 Aug 2020 00:13:10 -0400 Received: from free.home (unknown [201.82.51.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by fsfla.org (Postfix) with ESMTPSA id 3AB051DEF53; Mon, 24 Aug 2020 04:13:05 +0000 (UTC) Received: from livre.home (livre.home [172.31.160.2]) by free.home (8.15.2/8.15.2) with ESMTPS id 07O4CnTV118019 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Aug 2020 01:12:49 -0300 From: Alexandre Oliva To: Mark H Weaver Subject: Re: Linux-libre 5.8 and beyond Organization: Free thinker, not speaking for FSF Latin America References: <87d03vv0nm.fsf@netris.org> <875z9kv41h.fsf@netris.org> Date: Mon, 24 Aug 2020 01:12:49 -0300 In-Reply-To: <875z9kv41h.fsf@netris.org> (Mark H. Weaver's message of "Sat, 15 Aug 2020 02:03:27 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.84 Received-SPF: none client-ip=217.69.89.140; envelope-from=lxoliva@fsfla.org; helo=fsfla.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/23 23:45:31 X-ACL-Warn: Detected OS = Linux 3.11 and newer 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_NONE=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, Jason Self Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Scanner: scn0 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-Spam-Score: -1.01 X-TUID: 5MPZhSyyDOpN On Aug 15, 2020, Mark H Weaver wrote: > I only checked your claims regarding 5.4, and found that you're mistaken > about them being updated in 5.4.44. There was a change to scripts at 5.4.44, just not one you cared about, because you didn't use the (discontinued) deblob-main script to prepare a cleaned-up source tarball. > Moreover, of the 4 deblob updates (.14, .18, .27, and .34) that have > *actually* been made so far during the 5.4.x series, IIUC only one of > them declared new blobs to remove, namely the update for 5.4.27. That's missing the point. Nearly all of these changes were motivated by changes reported as suspicious in our verification. Some turned out to be false positives, but they might as well have been new blobs. Any change has a potential to introduce new blobs, and the fact that our verification catches suspicious changes that you'd have quietly published as Free Software is the risk you're passing on to your users instead of living up to the expectation that you're doing your best to ensure they're not getting any non-Free Software from you. The value we provide, of checking that for every release, you're throwing on the floor. Yes, the releases that would *actually* introduce undesirable changes, vs merely suspicious ones that turn out to be false positives, are a smaller fraction of the total. But what you're doing right now is driving with blinders on because then you can go faster, because history has shown there's only a 5% or 2% chance of hitting a bus. > The 5.4.14 update only removed extraneous backslashes in existing > regexps, changing "\e" to "e" and "\@" to "@". That was in response to a change in python3.7 (?) regexp engine. Fortunately, all one got from the extraneous backslashes were warnings. But it could have been an actual change in output, or a failure to match a pattern that ought to have been cleaned up, and since you don't compare with our releases, you could have got non-Free results as much as from a newly-introduced bit from upstream. > I don't know whether these extraneous backslashes caused blobs to be > included in the linux-libre tarballs, but if so, that presumably > already happened in 5.4.13 and would have happened even if we had used > your official tarballs, no? No. If we'd hit it ourselves, our release engineering procedures would have caught the unexpected change. That's why treating our scripts (rather than our releases) as the ultimate truth, is error prone: the underlying tools are complex and subject to change and bugs. If you don't verify that their output isn't garbage (by comparing with our manually verified releases, or by performing equivalent automated and manual checks), you may end up shipping that garbage. Odds are that you already have. > The 5.4.18 and 5.4.34 updates only added new 'accept' directives. I > guess that means that temporarily omitting these additions wouldn't > cause new blobs to be included, is that right? You're probably right for these instances, but it does not necessarily follow that script changes that only add 'accept' patterns wouldn't get you in trouble without them. At times, we've had to add accept statements to match newly-added occurrences of '.firmware' in such constructs as: struct foo var = { .whatever = value, .firmware = "filename", ... }; These initializers are regarded as suspicious, so they need to be manually marked as accepted, whether or not the filename turns out to be a blob name that we clean up. Without arranging for a newly-introduced '.firmware' initializer to be accepted, this may end up cleaned up into: struct foo var = { .whatever = value, /*(DEBLOBBED)*/ "/*(DEBLOBBED)*/", ... }; which will get you a successful cleaning up session (say, if the firmware name was already known, in a file that we already cleaned up), and even a successful compilation, but, depending on the order of the fields in struct foo, the cleaned-up firmware name may end up used to initialize the wrong field. >>> I know this because I always check for updates to the deblob scripts >>> whenever I update linux-libre in Guix. In practice, the deblob scripts used by >>> Guix are never more than 1 or 2 micro versions behind the version of >>> Linux they are applied to. >> >> There have been 61 script updates for the 1274 4.*.*-gnu* and 5.*.*-gnu* >> stable releases, so Guix has shipped potentially non-FSDG code, that >> *would* have been flagged by deblob-check on the tarballs, at between 5% >> and 10% of these releases. Does that sound like a good standard for a >> freedom-first distro to aim for? > If it were true that we've been including blobs in 5-10% of our > linux-libre releases, I agree that would be a serious problem. Not what I meant, FWIW. What I meant was that in 5-10% of the times you might have *known* you had something wrong in your cleaned up tree if you'd just run deblob-check on it for one of the automated verifications. > I already wrote about 5.4 above. If we include only the deblob updates > that added checks for new blobs, it's only happened once in 58 upstream > updates, i.e. for 1.7% of the updates. The statistics you're using, counting only the suspicious changes that were not false positives, is analogous to saying that jaywalking, or driving across a red light, without even looking, are acceptable as long as you don't get hit or caught. Getting lucky 90%, 95% or even 98% of the time doesn't make up for disregarding the procedures that would have warned you of avoidable issues, whether or not they turn out to be actual freedom issues. The other reason you got much lower results than me was that I made room for your recipe's lagging for up to 2 releases (thus the 5% of stable releases requiring deblobbing changes turn to 10%), as you'd said, while you seem to have done yours assuming they'd lag for at most 1. -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer