From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alex Dunn Newsgroups: gmane.emacs.devel Subject: Re: why is site-lisp placed before the default load path? Date: Mon, 1 Aug 2016 10:19:12 -0700 Message-ID: References: <83bn1co33l.fsf@gnu.org> NNTP-Posting-Host: blaine Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1135a88c90a00c053905cc8b X-Trace: blaine.gmane.org 1470072011 26810 195.159.176.226 (1 Aug 2016 17:20:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 1 Aug 2016 17:20:11 +0000 (UTC) Cc: emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 01 19:20:07 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bUGsn-0006ky-Py for ged-emacs-devel@m.gmane.org; Mon, 01 Aug 2016 19:20:06 +0200 Original-Received: from localhost ([::1]:51943 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUGsk-000277-Ca for ged-emacs-devel@m.gmane.org; Mon, 01 Aug 2016 13:20:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53226) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUGs2-00025m-Et for emacs-devel@gnu.org; Mon, 01 Aug 2016 13:19:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bUGs0-0007qw-Sm for emacs-devel@gnu.org; Mon, 01 Aug 2016 13:19:18 -0400 Original-Received: from mail-ua0-x22f.google.com ([2607:f8b0:400c:c08::22f]:33039) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUGrx-0007qB-Qn; Mon, 01 Aug 2016 13:19:13 -0400 Original-Received: by mail-ua0-x22f.google.com with SMTP id k90so111021213uak.0; Mon, 01 Aug 2016 10:19:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5CrCB01lNmq7dCyttKvX7tl2LdyRYEcEZhW4GVq+7rk=; b=Wy0gMj3Th0ih0lCqTFTmz59kHwKrtRM3O31/rHLbEaRfYzvOSV17ub2f2mjDWIPGwf 9tRAXwP3ZrbzFh7aefGD1U4qSSlNtzrruMRQWe3hotgOOg6hyBDHgwdPHhwUsTwy4AYO riFgHlToQMCq8o23JPvfNtS7Gub91eqX7LG6X72BL/mf4KuOaE7neq0mP55Bme6rorW9 mL6gJAsX2m3hSSTeQioDYG2TiUufjFS+eMVBQH9Gh9YDLREhZmIwu7/4E9ox78ivcoPr mhwxIbi8tPV15m8+oL/sjljpXEdR0iNB0i3vi+ymbADQh2sdi1tcEQDJpG31QmtFGJNg L80A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5CrCB01lNmq7dCyttKvX7tl2LdyRYEcEZhW4GVq+7rk=; b=W+HJYYGP4tjqy8gwx58XJ43hJQgHT0SMWMgRtr5DxloczPgS5vby5DOh4C0ZTnxXkk fCjaOcWSDd3vxmd+I35V4p0QTgXciok6Wbe9lhg8Cg04FSuZ0zLO+USvl/d9UBMqDZ14 ZvUVwI16MzAiHVa/mhvthGyCv+qgRjiQGNLhS/k7HJ9HOM5aAMb0koshU1get1IqHequ 61iITbUCA//Nf7icp60g1VnwZcCHQd29PgqYwMlrf9vmW10VEhkdwEnzTjXLRHaGqa6x LAi4U86nJvHTep1jT+7dkrWpkXtxepMRleSgYtHU/aX3DmT/501BsqIKZuBNhT9fPcVq 31GQ== X-Gm-Message-State: AEkoous2dLmj7KZR3Mi8rGdvPNNcM22crPJneKIMB33s0lfm4uVgsrZHTLA5fVpp6qPh+FP3FSyw5HFP1VB14Q== X-Received: by 10.159.33.248 with SMTP id 111mr22015564uac.99.1470071953199; Mon, 01 Aug 2016 10:19:13 -0700 (PDT) Original-Received: by 10.103.115.133 with HTTP; Mon, 1 Aug 2016 10:19:12 -0700 (PDT) In-Reply-To: <83bn1co33l.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400c:c08::22f X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:206321 Archived-At: --001a1135a88c90a00c053905cc8b Content-Type: text/plain; charset=UTF-8 > It's precisely so that users could have their local versions loaded in > preference to the bundled ones, I think. But there are plenty of other ways to do that. This makes it a little too easy to override important core libraries, IMO. realgud is just an example. It uses names like js.el and info.el because they are supposed to be loaded via `load-relative`, rather than required directly, but subdirs.el placing them at the front of the load path is what's causing trouble. Rocky could add 'realgud-' to the beginning of every elisp file in the application, but `load-relative` and the directory structure makes that unnecessary. You might argue that every elisp file in an application should be named to avoid conflicts with core libraries, but the only reason I see for that requirement is the current ordering of the load path. And beyond the inconvenience caused by programs using `load-relative`, or programs just accidentally using the same name as a core library, it seems possible that a malicious developer could tuck their own `url.el` into an otherwise innocuous package and cause some mayhem. On Mon, Aug 1, 2016 at 9:39 AM, Eli Zaretskii wrote: > > From: Alex Dunn > > Date: Mon, 1 Aug 2016 09:24:34 -0700 > > > > Right now, `init_lread` in lread.c creates the initial load path by > concatenating PATH_SITELOADSEARCH and > > PATH_LOADSEARCH, in that order. Since subdirs.el searches recursively > and adds everything to the > > load-path, if I install (for example), realgud into site-lisp, things > break because a number of Emacs' own > > libraries are shadowed by realgud's language and utility modules: > > - https://github.com/realgud/realgud/tree/master/realgud/common > > - https://github.com/realgud/realgud/tree/master/realgud/lang > > > > Looking through the code history, this order has been deliberately > maintained for well over a decade, but > > what's the reason for letting core libraries be overridden like this? > > It's precisely so that users could have their local versions loaded in > preference to the bundled ones, I think. > > If realgud somehow causes trouble due to this, the problem should be > solved there, IMO. > --001a1135a88c90a00c053905cc8b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>=C2=A0It's precis= ely so that users could have their local versions loaded in
> preference to t= he bundled ones, I think.

<= /span>
But there are plenty of o= ther ways to do that. =C2=A0 This makes it a little too easy to override im= portant core libraries, IMO. =C2=A0

realgud is just an example.=C2=A0 It uses names l= ike js.el and info.el because they are supposed to be loaded via `load-rela= tive`, rather than required directly, but subdirs.el placing them at the fr= ont of the load path is what's causing trouble.=C2=A0 Rocky could add &= #39;realgud-' to the beginning of every elisp file in the application, = but `load-relative` and the directory structure makes that unnecessary.

You might argue that every elisp file in an appl= ication should be named to avoid conflicts with core libraries, but the onl= y reason I see for that requirement is the current ordering of the load pat= h.

= And beyond the inconvenience caused by pro= grams using `load-relative`, or programs just accidentally using the same n= ame as a core library, it seems possible that a malicious developer could t= uck their own `url.el` into an otherwise innocuous package and cause some m= ayhem.

On Mon, Aug 1, 2016 at 9:39 AM, Eli Zaretskii <= ;eliz@gnu.org> wrote:
> From: Alex Dunn <dunn.alex@gmail.com>
> Date: Mon, 1 Aug 2016 09:24:34 -0700
>
> Right now, `init_lread` in lread.c creates the initial load path by co= ncatenating PATH_SITELOADSEARCH and
> PATH_LOADSEARCH, in that order. Since subdirs.el searches recursively = and adds everything to the
> load-path, if I install (for example), realgud into site-lisp, things = break because a number of Emacs' own
> libraries are shadowed by realgud's language and utility modules:<= br> > - https://github.com/realgud/realg= ud/tree/master/realgud/common
> - https://github.com/realgud/realgud= /tree/master/realgud/lang
>
> Looking through the code history, this order has been deliberately mai= ntained for well over a decade, but
> what's the reason for letting core libraries be overridden like th= is?

It's precisely so that users could have their local versions loa= ded in
preference to the bundled ones, I think.

If realgud somehow causes trouble due to this, the problem should be
solved there, IMO.

--001a1135a88c90a00c053905cc8b--