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 11:15:49 -0700 Message-ID: References: <83bn1co33l.fsf@gnu.org> NNTP-Posting-Host: blaine Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114ccd3208c3d405390697ee X-Trace: blaine.gmane.org 1470075524 17805 195.159.176.226 (1 Aug 2016 18:18:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 1 Aug 2016 18:18:44 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel To: Robert Weiner Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 01 20:18:40 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 1bUHnT-0004M0-Mo for ged-emacs-devel@m.gmane.org; Mon, 01 Aug 2016 20:18:39 +0200 Original-Received: from localhost ([::1]:52231 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUHnQ-00040Y-6l for ged-emacs-devel@m.gmane.org; Mon, 01 Aug 2016 14:18:36 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38108) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUHko-0001jG-17 for emacs-devel@gnu.org; Mon, 01 Aug 2016 14:15:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bUHkm-00025B-Lq for emacs-devel@gnu.org; Mon, 01 Aug 2016 14:15:53 -0400 Original-Received: from mail-ua0-x22d.google.com ([2607:f8b0:400c:c08::22d]:32769) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUHkk-00023k-Gu; Mon, 01 Aug 2016 14:15:50 -0400 Original-Received: by mail-ua0-x22d.google.com with SMTP id k90so112131012uak.0; Mon, 01 Aug 2016 11:15:50 -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=VgxqivEHSgk7wBZO7w28AHfMfLZeo5fnlRKnP4YfsDY=; b=Nu7pigmY6/H01phJvJK1kUEDWbA0yD6S6Hyl6GKBBz+t37+1LCu1jTygsETaDfiJGt f2N5NZX0bBFvUZCYzEVuMTbQqcaVIkmZtJWixTC2AMjDZiOoK9uvTZ9wnMIcynG5EGiL ApijLckor+dQSHW31I8rA+xZ2wz6QnY8gGWku7oT3b0nHUZ0de2OgcYNwo6zecIAkRjY fdP+sK5tUBdHLr6OGH/F+cLbYiFwTwqO10/LKPY5Ik+EJv5jm6kHoCWETWfOBWqEuGxm qPAsHlO+nlfprhDghm5LxSYMPSccomxHuA0PtTpyH5yizbnaKdAKNSBiexBqEcVS0daU CnnA== 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=VgxqivEHSgk7wBZO7w28AHfMfLZeo5fnlRKnP4YfsDY=; b=D/35kmjqXNxl+V4EredmVQ97deKaOxG7kflgjwE1KfaZGIq9SGjhF1HWv5a/M7HWHx HEmVJEyKyEUAOFOsx3DQd6OB2XaSpHVPv4gtD6qkvtwAg9/IHULMF7DNPsH5TCYp8+gh FNvcaj2Ija1vyW4NWAaYhpx2U4wDzEaMGFbVbg1e2fIVejt22A2RXQlIFI83r6LUerFz LJ2Lh+zBxc4aQ2cXKqlbaNYYMzEs2rZl2Q6vA+zeSjaqNBx2eK6I/HsZuNS1fA28grHC nANa8DXueNHoJ7zIoMwaPBoF65mMDIblrLvjH1kEu4ltQ9GFYGDt9c2LVlQbfN/cyRIC OkDw== X-Gm-Message-State: AEkooutwNeLm1qiJRNOj6LOgq3CbpRUi8HqEjyTdgxPLT1u3i2x52p0RxoBEzZg5JcUjlyKyyQ0qEnGZ8ZEGaA== X-Received: by 10.176.68.102 with SMTP id m93mr26975834uam.111.1470075350072; Mon, 01 Aug 2016 11:15:50 -0700 (PDT) Original-Received: by 10.103.115.133 with HTTP; Mon, 1 Aug 2016 11:15:49 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400c:c08::22d 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:206324 Archived-At: --001a114ccd3208c3d405390697ee Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable OK. I'm still not convinced this is good default behavior, but I'll defer to y'all. Realgud solved the issue in their case by adding .nosearch files in the subdirectories, which I didn't realize was an available tool. On Mon, Aug 1, 2016 at 10:54 AM, Robert Weiner wrote: > > On Mon, Aug 1, 2016 at 1:19 PM, Alex Dunn wrote: > >> But there are plenty of other ways to do that. This makes it a little >> too easy to override important core libraries, IMO. >> > > =E2=80=8BIt should be easy for a site or a user to override default behav= ior in > Emacs. Sometimes this means having modifications loaded prior to > particular local initialization files running and changing load-path. > =E2=80=8B > > >> >> realgud is just an example. It uses names like js.el and info.el becaus= e >> 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. >> > > =E2=80=8BGiven all the existing tools that look for Elisp files by filena= me, > find-library being just one, it is not a good assumption that the filenam= e > will always be uniquely identified by adding a directory name. > > Rocky could add 'realgud-' to the beginning of every elisp file in the >> application, >> > > =E2=80=8BThat would be much better and safer and more generally useful. > =E2=80=8B > > >> 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 th= at >> requirement is the current ordering of the load path. >> > > =E2=80=8BThere are others. > =E2=80=8B > > >> >> And beyond the inconvenience caused by programs using `load-relative`, o= r >> programs just accidentally using the same name as a core library, it see= ms >> possible that a malicious developer could tuck their own `url.el` into a= n >> otherwise innocuous package and cause some mayhem. >> > > =E2=80=8BYes, Emacs is a pretty open environment that relies on a lot of = trust > among users and developers. The community helps keep bad actors from > acting badly. Emacs has existed for decades without a major issue like y= ou > describe and there are very likely good reasons for that. > > =E2=80=8BBob > =E2=80=8B > =E2=80=8B > > --001a114ccd3208c3d405390697ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK.=C2=A0 I'm still not convinced this is good default= behavior, but I'll defer to y'all.=C2=A0 Realgud solved the issue = in their case by adding .nosearch files in the subdirectories, which I didn= 't realize was an available tool.

<= div class=3D"gmail_quote">On Mon, Aug 1, 2016 at 10:54 AM, Robert Weiner <rsw@gn= u.org> wrote:

On Mon, Aug 1, 2016 at 1:19 PM, Alex Dunn <dunn.alex@gmail.com= > wrote:
= But there are plenty of other ways to do t= hat. =C2=A0 This makes it a little too easy to override important core libr= aries, IMO. =C2=A0

=E2=80=8BIt should be easy for a site or a user to override de= fault behavior in Emacs.=C2=A0 Sometimes this means having modifications lo= aded prior to particular local initialization files running and changing lo= ad-path.
=E2=80=8B
=C2=A0<= /div>

realgud is just an example.=C2=A0 It uses na= mes 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 t= he front of the load path is what's causing trouble.
=

=E2=80=8BGiven all the = existing tools that look for Elisp files by filename, find-library being ju= st one, it is not a good assumption that the filename will always be unique= ly identified by adding a directory name.
=

=
=C2=A0 Rocky could add 'realgud-&= #39; to the beginning of every elisp file in the application,
=

=E2=80=8BThat woul= d be much better and safer and more generally useful.
=E2=80=8B
=C2=A0
but `load-rela= tive` 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.

=E2=80=8BThere ar= e others.
=E2=80=8B
=C2=A0=

And= beyond the inconvenience caused by programs using `load-relative`, or prog= rams just accidentally using the same name as a core library, it seems poss= ible that a malicious developer could tuck their own `url.el` into an other= wise innocuous package and cause some mayhem.

=E2=80=8BYes, Emacs is a pretty ope= n environment that relies on a lot of trust among users and developers.=C2= =A0 The community helps keep bad actors from acting badly.=C2=A0 Emacs has = existed for decades without a major issue like you describe and there are v= ery likely good reasons for that.

=E2=80=8BBob
=E2=80=8B
=E2=80=8B


--001a114ccd3208c3d405390697ee--