bug#20330: Do not capture build-time $PATH in 'emacs' binary

bug#20330: Do not capture build-time $PATH in 'emacs' binary

[Ludovic Courtès]

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

The attached patch makes sure that the ‘emacs’ executable does not
capture the value of the build-time $PATH (which notably includes the
build directory, which may or may not exist afterwards.)

(FWIW, the added motivation in the context of Guix and Nix is that the
garbage collector would see those references and assume that Emacs needs
all these items at run time.  See
<http://git.savannah.gnu.org/cgit/guix.git/commit/?id=1bef37ee2e0a6ba9048eb8087651c8dbd2c6c796>.)

Ludo’.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 489 bytes --]

--- a/lisp/loadup.el
+++ b/lisp/loadup.el
@@ -64,6 +64,11 @@
                           (expand-file-name "textmodes" dir)
                           (expand-file-name "vc" dir)))))
 
+;; Reset 'exec-path' so we don't capture the build-time $PATH in the
+;; 'emacs' executable.
+(setq-default exec-path nil)
+(setq exec-path nil)
+
 (if (eq t purify-flag)
     ;; Hash consing saved around 11% of pure space in my tests.
     (setq purify-flag (make-hash-table :test 'equal :size 70000)))

bug#20330: Do not capture build-time $PATH in 'emacs' binary

[Eli Zaretskii]

> From: ludo@gnu.org (Ludovic Courtès)
> Date: Tue, 14 Apr 2015 13:51:35 +0200
> 
> The attached patch makes sure that the ‘emacs’ executable does not
> capture the value of the build-time $PATH (which notably includes the
> build directory, which may or may not exist afterwards.)

Why only exec-path?

bug#20330: Do not capture build-time $PATH in 'emacs' binary

[Ludovic Courtès]

Eli Zaretskii <eliz@gnu.org> skribis:

>> From: ludo@gnu.org (Ludovic Courtès)
>> Date: Tue, 14 Apr 2015 13:51:35 +0200
>> 
>> The attached patch makes sure that the ‘emacs’ executable does not
>> capture the value of the build-time $PATH (which notably includes the
>> build directory, which may or may not exist afterwards.)
>
> Why only exec-path?

AFAICS this is the only thing that captures the build-time $PATH in the
installed binary.

Ludo’.

bug#20330: Do not capture build-time $PATH in 'emacs' binary

[Eli Zaretskii]

> From: ludo@gnu.org (Ludovic Courtès)
> Cc: 20330@debbugs.gnu.org
> Date: Tue, 14 Apr 2015 18:10:27 +0200
> 
> Eli Zaretskii <eliz@gnu.org> skribis:
> 
> >> From: ludo@gnu.org (Ludovic Courtès)
> >> Date: Tue, 14 Apr 2015 13:51:35 +0200
> >> 
> >> The attached patch makes sure that the ‘emacs’ executable does not
> >> capture the value of the build-time $PATH (which notably includes the
> >> build directory, which may or may not exist afterwards.)
> >
> > Why only exec-path?
> 
> AFAICS this is the only thing that captures the build-time $PATH in the
> installed binary.

What makes PATH special?  Don't you want to prevent any build-time
directories (except source-directory) from leaking into the binary?

bug#20330: Do not capture build-time $PATH in 'emacs' binary

[Ludovic Courtès]

Eli Zaretskii <eliz@gnu.org> skribis:

>> From: ludo@gnu.org (Ludovic Courtès)
>> Cc: 20330@debbugs.gnu.org
>> Date: Tue, 14 Apr 2015 18:10:27 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> skribis:
>> 
>> >> From: ludo@gnu.org (Ludovic Courtès)
>> >> Date: Tue, 14 Apr 2015 13:51:35 +0200
>> >> 
>> >> The attached patch makes sure that the ‘emacs’ executable does not
>> >> capture the value of the build-time $PATH (which notably includes the
>> >> build directory, which may or may not exist afterwards.)
>> >
>> > Why only exec-path?
>> 
>> AFAICS this is the only thing that captures the build-time $PATH in the
>> installed binary.
>
> What makes PATH special?  Don't you want to prevent any build-time
> directories (except source-directory) from leaking into the binary?

I do, but I haven’t noticed any other leaks.  Do you think there are
others?

Thanks,
Ludo’.

bug#20330: Do not capture build-time $PATH in 'emacs' binary

[Eli Zaretskii]

> From: ludo@gnu.org (Ludovic Courtès)
> Cc: 20330@debbugs.gnu.org
> Date: Wed, 15 Apr 2015 09:45:38 +0200
> 
> >> >> The attached patch makes sure that the ‘emacs’ executable does not
> >> >> capture the value of the build-time $PATH (which notably includes the
> >> >> build directory, which may or may not exist afterwards.)
> >> >
> >> > Why only exec-path?
> >> 
> >> AFAICS this is the only thing that captures the build-time $PATH in the
> >> installed binary.
> >
> > What makes PATH special?  Don't you want to prevent any build-time
> > directories (except source-directory) from leaking into the binary?
> 
> I do, but I haven’t noticed any other leaks.  Do you think there are
> others?

load-path comes to mind, it can include PATH_DUMPLOADSEARCH, AFAIR.

bug#20330: Do not capture build-time $PATH in 'emacs' binary

[Ludovic Courtès]

Eli Zaretskii <eliz@gnu.org> skribis:

>> From: ludo@gnu.org (Ludovic Courtès)
>> Cc: 20330@debbugs.gnu.org
>> Date: Wed, 15 Apr 2015 09:45:38 +0200
>> 
>> >> >> The attached patch makes sure that the ‘emacs’ executable does not
>> >> >> capture the value of the build-time $PATH (which notably includes the
>> >> >> build directory, which may or may not exist afterwards.)
>> >> >
>> >> > Why only exec-path?
>> >> 
>> >> AFAICS this is the only thing that captures the build-time $PATH in the
>> >> installed binary.
>> >
>> > What makes PATH special?  Don't you want to prevent any build-time
>> > directories (except source-directory) from leaking into the binary?
>> 
>> I do, but I haven’t noticed any other leaks.  Do you think there are
>> others?
>
> load-path comes to mind, it can include PATH_DUMPLOADSEARCH, AFAIR.

Maybe you’re right, but I haven’t noticed any such thing with Guix’s
conservative GC scanner.

Ludo’.

bug#20330: Do not capture build-time $PATH in 'emacs' binary

[Eli Zaretskii]

> From: ludo@gnu.org (Ludovic Courtès)
> Cc: 20330@debbugs.gnu.org
> Date: Wed, 15 Apr 2015 18:37:00 +0200
> 
> >> > What makes PATH special?  Don't you want to prevent any build-time
> >> > directories (except source-directory) from leaking into the binary?
> >> 
> >> I do, but I haven’t noticed any other leaks.  Do you think there are
> >> others?
> >
> > load-path comes to mind, it can include PATH_DUMPLOADSEARCH, AFAIR.
> 
> Maybe you’re right, but I haven’t noticed any such thing with Guix’s
> conservative GC scanner.

I clearly see it in my build of Emacs.  Try grepping through output of
"strings ./emacs".

bug#20330: Do not capture build-time $PATH in 'emacs' binary

[Glenn Morris]

Ludovic Courtès wrote:

> +;; Reset 'exec-path' so we don't capture the build-time $PATH in the
> +;; 'emacs' executable.
> +(setq-default exec-path nil)
> +(setq exec-path nil)

I'm not sure this is a good way to solve your issue.
Eg it will cause "Erase Customizations" on exec-path to set it to nil.

bug#20330: Do not capture build-time $PATH in 'emacs' binary

[Ludovic Courtès]

Glenn Morris <rgm@gnu.org> skribis:

> Ludovic Courtès wrote:
>
>> +;; Reset 'exec-path' so we don't capture the build-time $PATH in the
>> +;; 'emacs' executable.
>> +(setq-default exec-path nil)
>> +(setq exec-path nil)
>
> I'm not sure this is a good way to solve your issue.
> Eg it will cause "Erase Customizations" on exec-path to set it to nil.

OTOH, at startup, ‘init_callproc_1’ does:

  Vexec_path = nconc2 (decode_env_path ("PATH", ""), Vexec_path);

So it looks rather safe.  WDYT?

Ludo’.

bug#20330: Do not capture build-time $PATH in 'emacs' binary

[Glenn Morris]

Ludovic Courtès wrote:

>>> +(setq exec-path nil)
>>
>> I'm not sure this is a good way to solve your issue.
>> Eg it will cause "Erase Customizations" on exec-path to set it to nil.
>
> OTOH, at startup, 'init_callproc_1' does:
>
>   Vexec_path = nconc2 (decode_env_path ("PATH", ""), Vexec_path);

I don't think that's relevant, is it?

It may make no real difference in practice, but I think I'd prefer to
see it set to a valid value. Eg whatever the bash shell's hard-coded
default is for PATH (/usr/local/bin:/bin:/usr/bin?) plus exec-directory.

(Also the setq-default seems superfluous, since exec-path is not buffer-local.)

bug#20330: Do not capture build-time $PATH in 'emacs' binary

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Thu, 16 Apr 2015 11:37:50 -0400
> Cc: 20330@debbugs.gnu.org
> 
> It may make no real difference in practice, but I think I'd prefer to
> see it set to a valid value. Eg whatever the bash shell's hard-coded
> default is for PATH (/usr/local/bin:/bin:/usr/bin?) plus exec-directory.

That'd need to be platform-dependent.

bug#20330: Do not capture build-time $PATH in 'emacs' binary

[Glenn Morris]

Eli Zaretskii wrote:

> That'd need to be platform-dependent.

No, it wouldn't. I'm only concerned with providing a syntactically valid
value, rather than nil. It doesn't actually do anything.

But, it has long bugged me that exec-path always shows up in
customize-rogue output. The following patch takes care of that, and
means I have no problem with setting exec-path to nil in loadup, since
it really does become about nothing more than keeping the build-time
value out of the binary.

(The callproc part is because I noticed that running uninstalled puts the
eventual installation directory's libexec into exec-path, which is wrong.)


--- a/lisp/cus-start.el
+++ b/lisp/cus-start.el
@@ -169,7 +169,12 @@ Leaving \"Default\" unchecked is equivalent with specifying a default of
 	     (shell-file-name execute file)
 	     (exec-path execute
 			(repeat (choice (const :tag "default directory" nil)
-					(directory :format "%v"))))
+					(directory :format "%v")))
+                        nil
+                        :standard
+                        (mapcar 'directory-file-name
+                                (append (parse-colon-path (getenv "PATH"))
+                                        (list exec-directory))))
 	     (exec-suffixes execute (repeat string))
 	     ;; charset.c
 	     (charset-map-path installation
diff --git a/src/callproc.c b/src/callproc.c
index e1fe8ed..8c1f910 100644
--- a/src/callproc.c
+++ b/src/callproc.c
@@ -1595,12 +1595,12 @@ init_callproc (void)
 #ifdef HAVE_NS
 	  const char *path_exec = ns_exec_path ();
 #endif
+          /* Running uninstalled, so default to tem rather than PATH_EXEC.  */
 	  Vexec_path = decode_env_path ("EMACSPATH",
 #ifdef HAVE_NS
 					path_exec ? path_exec :
 #endif
-					PATH_EXEC, 0);
-	  Vexec_path = Fcons (tem, Vexec_path);
+					SSDATA (tem), 0);
 	  Vexec_path = nconc2 (decode_env_path ("PATH", "", 0), Vexec_path);
 	}
 

bug#20330: Do not capture build-time $PATH in 'emacs' binary

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: ludo@gnu.org,  20330@debbugs.gnu.org
> Date: Thu, 16 Apr 2015 15:25:10 -0400
> 
> Eli Zaretskii wrote:
> 
> > That'd need to be platform-dependent.
> 
> No, it wouldn't. I'm only concerned with providing a syntactically valid
> value, rather than nil. It doesn't actually do anything.

But even the syntax is platform-dependent.

bug#20330: Do not capture build-time $PATH in 'emacs' binary

[Glenn Morris]

Version: 25.1

Applied.