From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: chad Newsgroups: gmane.emacs.devel Subject: Re: Suppressing native compilation (short and long term) Date: Sun, 2 Oct 2022 12:23:43 -0400 Message-ID: References: <87bkqxf1ij.fsf@tethera.net> <8335c9dkyf.fsf@gnu.org> <83edvqafr7.fsf@gnu.org> <83h70m19yv.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000039de9105ea0fa7c8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35692"; mail-complaints-to="usenet@ciao.gmane.io" Cc: tomas@tuxteam.de, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Oct 02 18:24:46 2022 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 1of1ll-000957-Os for ged-emacs-devel@m.gmane-mx.org; Sun, 02 Oct 2022 18:24:45 +0200 Original-Received: from localhost ([::1]:39420 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1of1lk-0000M8-JT for ged-emacs-devel@m.gmane-mx.org; Sun, 02 Oct 2022 12:24:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59714) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1of1l4-0007eI-Nl for emacs-devel@gnu.org; Sun, 02 Oct 2022 12:24:02 -0400 Original-Received: from mail-ej1-x62b.google.com ([2a00:1450:4864:20::62b]:44711) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1of1kz-0004oD-Kp; Sun, 02 Oct 2022 12:24:02 -0400 Original-Received: by mail-ej1-x62b.google.com with SMTP id r18so17901664eja.11; Sun, 02 Oct 2022 09:23:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=eyPddt7Yj1H/7wcBKsuJi/mDJeETon0pXlhBw5QtMgk=; b=FIdgfi3CkeErhXKgxY8vDbWLUt2AsT3YhvH8F/4cYcn2ofwh1XpOoAcSUTqQUf6b/E teyFouaer1p7NrUWSQsysp2qI4e4CXoN00n+auFyGfq5Qc3HsFAxp+SWXpV+MRKUBgeV 0AIA9XThvmeYiYalFOBjFfR3ryEVG2qkblrBi9h5YGitWwAHzpEy5loYUQm0Zntc+HbT HVasSSiGCtrc7ZIo3FWijTN3xyv+q4qIfRIJdq+86HANnVKI7i2VkMm6kjyLrgJ/n+wM InbRuVHCexNXSK9TIu7Y/xijYjpR0y+JQK4zO3IVkmcSg5MNqV3S3/zoh7rXWJKNch/j xfgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=eyPddt7Yj1H/7wcBKsuJi/mDJeETon0pXlhBw5QtMgk=; b=R9sTUbVlhoLzB/MGqZCVqS/qvRkPZNZl24vpr1RRTuNoPwAHatxAVEJcw+ZGUyBkt+ jrPSwiA/OLbR8DqqammInE2zJdDZCNg9iomYO9L32T3Xz5r/JvaEduUPYIqmFTVUx69C sot/gjYh2wQgn9AfMkS5w49cKgFA9wFKARYBicAmaUoJrxwRrpQ18S1uG1r5TaxeHsvM kHtfnLDxbZaYLsH7xWCcGCAfOxgeXX6MvETf3+gs5JMudmNYXXGG55yzvpQax9wFNjjw 53ESc4kOdf/B0r5bj/mWUo8zRlYlkIyDyksuEOcOv6Vo2dQb2Q+kgB09jYpaVf/0s1HT OyDg== X-Gm-Message-State: ACrzQf3IOSQVIvt3l4LoSEl5ikyWAYSW7oIZUE3zXAlF9wMl28SgVZ2Z fY/61xdBH8s5zc9+k03PUM4BedR/rs+xmAR8ndF3Vmg8Wt0= X-Google-Smtp-Source: AMsMyM7MqEs1/EjatCheQxqB2pnY8bFJRJgK05fx+rGupZvfa/D/Py9c+Dps6vOlEPnu04Fl5ymTndP328LamLvpBNo= X-Received: by 2002:a17:906:7007:b0:6ff:8028:42e with SMTP id n7-20020a170906700700b006ff8028042emr12641982ejj.278.1664727834548; Sun, 02 Oct 2022 09:23:54 -0700 (PDT) In-Reply-To: <83h70m19yv.fsf@gnu.org> Received-SPF: pass client-ip=2a00:1450:4864:20::62b; envelope-from=yandros@gmail.com; helo=mail-ej1-x62b.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01 autolearn=ham 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:296636 Archived-At: --00000000000039de9105ea0fa7c8 Content-Type: text/plain; charset="UTF-8" On Sun, Oct 2, 2022 at 12:13 PM Eli Zaretskii wrote: > > User separation goes out of the window, and this is one important > > service the OS provides. To illustrate, one user could put malicious > > .eln files all other users would execute. > > This is about installation writing files into a shared space on disk, > right? If so, this is something for the Debian packagers to figure > out, because doing that is their request. And anyway, I don't > understand how do *.eln files are different from *.elc files, which > are already written to shared disk space upon installation. What am I > missing? > At the risk of over-explaining due to message crossing mid-flight: the thing you might be missing is that Debian provides a mechanism for people to install *.elc files in a space shared by all users that is not writable by those users, and there are people that use this provision. Since these are used for *.elc files, it seems highly likely that they will be desired for *.eln files. Even in the face of a theoretical issue like "potential package combinations make it unworkable to pre-build a single set of emacs+emacs-packages", the practical situation is that such combinations exist and are used by Debian users to build a stable base of emacs+emacs-packages that is shared across users who cannot change that shared base (but can, of course, supplement it with their own packages, via site-lisp, user packages, etc.) As a practical goal, there is at least *some* impetus for Debian to provide such a stable base, and to make it as wide as reasonable. The basic mechanism for determining the size of that base is "which emacs-packages are made into debian-packages", (iff I understand correctly; I'm not a Debian expert). ~Chad --00000000000039de9105ea0fa7c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Oct 2, 2022 at 12:13 PM Eli Z= aretskii <eliz@gnu.org> wrote:
> User separation goes out of the window, and this is one important
> service the OS provides. To illustrate, one user could put malicious > .eln files all other users would execute.

This is about installation writing files into a shared space on disk,
right?=C2=A0 If so, this is something for the Debian packagers to figure out, because doing that is their request.=C2=A0 And anyway, I don't
understand how do *.eln files are different from *.elc files, which
are already written to shared disk space upon installation.=C2=A0 What am I=
missing?

At the risk of over-explaining= due to message crossing mid-flight: the thing you might be missing is that= Debian provides a mechanism for people to install *.elc files in a space s= hared by all users that is not writable=C2=A0by those users, and there are = people that use this provision. Since these are used for *.elc files, it se= ems highly likely that they will be desired for *.eln files.

=
Even in the face of a theoretical issue like "potential pac= kage combinations make it unworkable to pre-build a single set of emacs+ema= cs-packages", the practical situation is that such combinations exist = and are used by Debian users to build a stable base of=C2=A0 emacs+emacs-pa= ckages that is shared across users who cannot change that shared base (but = can, of course, supplement it with their own packages, via site-lisp, user = packages, etc.) As a practical goal, there is at least *some* impetus for D= ebian to provide such a stable base, and to make it as wide as reasonable. = The basic mechanism for determining the size of that base is "which em= acs-packages are made into debian-packages", (iff I understand correct= ly; I'm not a Debian expert).

~Chad
=
--00000000000039de9105ea0fa7c8--