From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alexandre Garreau Newsgroups: gmane.emacs.devel Subject: Re: Contradictiory directions (Was: Re: master 3d38d1d: Add sqlite3 support to Emacs) Date: Wed, 15 Dec 2021 15:34:49 +0100 Message-ID: <4585375.Bg1kBCuomF@galex-713.eu> References: <20211211035614.15517.53830@vcs0.savannah.gnu.org> <87wnk6mjlm.fsf@gnus.org> <877dc6tjz0.fsf_-_@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31361"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 15 15:47:53 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mxVZR-00081h-B1 for ged-emacs-devel@m.gmane-mx.org; Wed, 15 Dec 2021 15:47:53 +0100 Original-Received: from localhost ([::1]:53224 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mxVZQ-0002fr-86 for ged-emacs-devel@m.gmane-mx.org; Wed, 15 Dec 2021 09:47:52 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:52652) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mxVMu-0000Av-6Y for emacs-devel@gnu.org; Wed, 15 Dec 2021 09:34:56 -0500 Original-Received: from [2a00:5884:8305::1] (port=36494 helo=galex-713.eu) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mxVMr-0003nS-Tx for emacs-devel@gnu.org; Wed, 15 Dec 2021 09:34:55 -0500 Original-Received: from gal by galex-713.eu with local (Exim 4.94.2) (envelope-from ) id 1mxVMn-0038Wr-KX for emacs-devel@gnu.org; Wed, 15 Dec 2021 15:34:49 +0100 In-Reply-To: <877dc6tjz0.fsf_-_@yahoo.com> X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a00:5884:8305::1 (failed) Received-SPF: pass client-ip=2a00:5884:8305::1; envelope-from=galex-713@galex-713.eu; helo=galex-713.eu X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:282049 Archived-At: Le merkredo, 15-a de decembro 2021, 8-a horo kaj 17:55 CET Po Lu a =C3=A9cr= it : > > There's an allowlist in place. Only the pcre and csvtable modules > > (both free modules) can be installed now via the current loading > > mechanism. > It's still based on looking at the names of modules: proprietary modules > could easily be renamed so that their filenames are the same as the > free ones, and vice versa: it is not concrete at all. I think it=E2=80=99s a little ridiculous to fear that. That=E2=80=99s obvi= ous malicious=20 intent, and distributions should refuse that anyway. If a user does a=20 such thing, it=E2=80=99s their intent, and their responsibility. They deci= ded to=20 choose oppression, and we won=E2=80=99t be able to stop them (and it=E2=80= =99s not=20 illegal, copyright is only about distribution, copying, not usage) > The PCRE and csvtable modules are also in the public domain. > Proprietary versions of them could be created ino the future. *That*=E2=80=99s worrying. Keeps me thinking the gpl-compatibility symbol = is the=20 only Right Way to go. We may completely disallow modules, with a call to=20 implementation/TODO about allowing them when they contain a such symbol,=20 and after that another one about hacking those libs to make them so, and=20 providing patches to distribution. But the first step is blocking them. > BTW, the term "allowlist" is confusing. It took me a while to guess its > meaning. Why not use the industry-standard term "whitelist" instead? I disagree, allowlist looks weird and esoteric to me but it perfectly=20 describes what it is. Maybe Lars just participated in this modern trend=20 of avoiding politically uncorrect/connotated words in technical jargon=20 (such as positivity for =E2=80=9Cwhite=E2=80=9D and negativity for =E2=80= =9Cblack=E2=80=9D, although I=E2=80=99m=20 still uncertain about it=E2=80=99s for sure historically related to racism;= actual=20 sociological/historical data welcome!); but still the side effect is those= =20 technical words becomes less like jargon and more understandable by laymen= =20 (or layperson? I don=E2=80=99t even understand the morphological nor etymol= ogical=20 construction of layman anyway=E2=80=A6) and newcomers (when they=E2=80=99re= chose wisely,=20 like here), I=E2=80=99m in favor of that, let me state my support of it.