all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Alex Kosorukoff <alex@3form.com>
To: Glenn Morris <rgm@gnu.org>
Cc: 17467 <17467@debbugs.gnu.org>
Subject: bug#17467: 24.3; locate-library returning spurious path
Date: Sun, 11 May 2014 15:31:56 -0700	[thread overview]
Message-ID: <CAHD9_tQYOm2sJbzX6DkcZemepHmQ6nSFryeEqYwNFU2Xixg8eA@mail.gmail.com> (raw)
In-Reply-To: <3feh00ko79.fsf@fencepost.gnu.org>

[-- Attachment #1: Type: text/plain, Size: 1918 bytes --]

I think you are overlooking something. If I notice a random tramp.el in
some unusual place, I will investigate it right away because I know .el
files can be executed by emacs. I wouldn't do it for a random data file
without extension or a compressed .gz archive unless they have executable
permission for some unknown reason. Data files are created by many
applications and it is concerning me as long as no program I frequently use
will execute them randomly. You can say that data files should never be in
the load-path of emacs and I will agree with you. However, I can see
scenarios when this can happen unintentionally. It would be careless not to
try to add a simple safeguard to prevent this kind of execution.

I did fix the proximal cause already, worked around this function and
patched my emacs, so this bug doesn't affect me in any way now. Now I am
trying hard to fix the root cause. This is why I reported this bug, shared
my patches and addressed all valid concerns that were expressed here, even
those that aren't that important for me personally. The most difficult part
seems to be in persuading developers that this is an issue to be fixed. If
I fail at this, I simply will be less confident in using emacs.



On Sun, May 11, 2014 at 2:19 PM, Glenn Morris <rgm@gnu.org> wrote:

> Alex Kosorukoff wrote:
>
> > It can cause user inconvenience or pose a security/privacy issue
> > because a random file named "tramp" or "tramp.gz" placed in some
> > directory of the load-path can be loaded instead of the standard
> > library without user knowledge.
>
> This argument does not fly, because if someone can write a "tramp" file
> to a directory in your load-path, they can just as easily write
> "tramp.el". Random files should not be being written to your load-path,
> and you should not be adding inappropriate directories to that path.
> Your immediate problem was having ~/.emacs.d in load-path.
>

[-- Attachment #2: Type: text/html, Size: 2383 bytes --]

  reply	other threads:[~2014-05-11 22:31 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-11 16:06 bug#17467: 24.3; locate-library returning spurious path Alex Kosorukoff
2014-05-11 17:03 ` Eli Zaretskii
2014-05-11 17:38   ` Alex Kosorukoff
2014-05-11 17:46     ` Eli Zaretskii
2014-05-11 17:53       ` Alex Kosorukoff
2014-05-11 18:10         ` Eli Zaretskii
2014-05-11 18:55           ` Alex Kosorukoff
2014-05-11 22:55             ` Stefan Monnier
2014-05-12  0:41               ` Alex Kosorukoff
2014-05-11 17:37 ` Glenn Morris
2014-05-11 17:43   ` Alex Kosorukoff
2014-05-11 19:50 ` Stefan Monnier
2014-05-11 20:45   ` Alex Kosorukoff
2014-05-11 21:00     ` Alex Kosorukoff
2014-05-11 21:19     ` Glenn Morris
2014-05-11 22:31       ` Alex Kosorukoff [this message]
2014-05-11 21:56     ` Stefan Monnier
2014-05-12  0:20       ` Alex Kosorukoff
2014-05-12  0:32         ` Glenn Morris
2014-05-12  1:35           ` Alex Kosorukoff
2014-05-12  2:02             ` Alex Kosorukoff
2014-05-12  2:18         ` Stefan Monnier
2014-05-12  4:36           ` Alex Kosorukoff
2014-05-12  6:39             ` Stefan Monnier
2014-05-12 17:46               ` Alex Kosorukoff
2020-08-25 10:39           ` Lars Ingebrigtsen
2020-08-25 14:22             ` Stefan Monnier
2020-08-25 14:25               ` Lars Ingebrigtsen
2020-10-13  1:41             ` Lars Ingebrigtsen
2014-05-15 19:39 ` Stefan Monnier
2014-05-15 23:57   ` Alex Kosorukoff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAHD9_tQYOm2sJbzX6DkcZemepHmQ6nSFryeEqYwNFU2Xixg8eA@mail.gmail.com \
    --to=alex@3form.com \
    --cc=17467@debbugs.gnu.org \
    --cc=rgm@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.