Bug when compiling elc code?

Bug when compiling elc code?

[Hadron]

I recently added this bit of lisp to my .emacs in order to automatically
byte compile any el files I saved

,----
| (add-hook 'emacs-lisp-mode-hook
|           '(lambda ()
|              (make-local-hook 'after-save-hook)
|              (add-hook 'after-save-hook
|                        '(lambda ()
|                           (byte-compile-file buffer-file-name))
|                        nil t)))
`----

I have my gnus specifics such as smtp server names and passwords in a
"personal.el" file which is obviously not readable by anyone but my own
login and root.

Unfortunately byte-compile-file produced the following:

-rw------- 1 hadron hadron 4961 2007-08-08 12:19 personal.el
-rw-r--r-- 1 hadron hadron 3795 2007-08-08 12:19 personal.elc

In other words a readable by anyone elc file.

I just checked - I can load up the elc file and see all my passwords.

Bug or feature? Seems like a nasty bug to me.

Which leads on to the next question, is there something I can put into a
file to stop it compiling into an elc using this hook?

Re: Bug when compiling elc code?

[Johan Bockgård]

Hadron <hadronquark@googlemail.com> writes:

> Which leads on to the next question, is there something I can put into
> a file to stop it compiling into an elc using this hook?

(info "(elisp)Byte Compilation")

   If you do not want a Lisp file to be compiled, ever, put a file-local
   variable binding for `no-byte-compile' into it, like this:

       ;; -*-no-byte-compile: t; -*-

-- 
Johan Bockgård

Re: Bug when compiling elc code?

[Sven Joachim]

Hadron <hadronquark@googlemail.com> writes:

> I recently added this bit of lisp to my .emacs in order to automatically
> byte compile any el files I saved
>
> ,----
> | (add-hook 'emacs-lisp-mode-hook
> |           '(lambda ()
> |              (make-local-hook 'after-save-hook)
> |              (add-hook 'after-save-hook
> |                        '(lambda ()
> |                           (byte-compile-file buffer-file-name))
> |                        nil t)))
> `----
>
> I have my gnus specifics such as smtp server names and passwords in a
> "personal.el" file which is obviously not readable by anyone but my own
> login and root.
>
> Unfortunately byte-compile-file produced the following:
>
> -rw------- 1 hadron hadron 4961 2007-08-08 12:19 personal.el
> -rw-r--r-- 1 hadron hadron 3795 2007-08-08 12:19 personal.elc
>
> In other words a readable by anyone elc file.
>
> I just checked - I can load up the elc file and see all my passwords.
>
> Bug or feature? Seems like a nasty bug to me.

No, not really.  If personal.elc does not exist, Emacs creates it
according to your current umask, like any other file.  You can change
this default with the function set-default-file-modes, please try the
following: 

(add-hook 'emacs-lisp-mode-hook
	  '(lambda ()
	     (make-local-hook 'after-save-hook)
	     (add-hook 'after-save-hook
		       '(lambda ()
			  (let ((old-mode (default-file-modes)))
			    (set-default-file-modes (file-modes buffer-file-name))
			    (byte-compile-file buffer-file-name)
			    (set-default-file-modes old-mode)))
		       nil t)))

Re: Bug when compiling elc code?

[Johan Bockgård]

Sven Joachim <svenjoac@gmx.de> writes:

>     (let ((old-mode (default-file-modes)))
>       (set-default-file-modes (file-modes buffer-file-name))
>       (byte-compile-file buffer-file-name)
>       (set-default-file-modes old-mode)))

You should use `unwind-protect' here.

-- 
Johan Bockgård

Re: Bug when compiling elc code?

[Sven Joachim]

bojohan+news@dd.chalmers.se (Johan Bockgård) writes:

> Sven Joachim <svenjoac@gmx.de> writes:
>
>>     (let ((old-mode (default-file-modes)))
>>       (set-default-file-modes (file-modes buffer-file-name))
>>       (byte-compile-file buffer-file-name)
>>       (set-default-file-modes old-mode)))
>
> You should use `unwind-protect' here.

Right, thanks.  Is the following okay?

(add-hook 'emacs-lisp-mode-hook
	  '(lambda ()
	     (make-local-hook 'after-save-hook)
	     (add-hook 'after-save-hook
		       '(lambda ()
			  (let ((old-mode (default-file-modes)))
			    (unwind-protect
				(progn
				  (set-default-file-modes (file-modes buffer-file-name))
				  (byte-compile-file buffer-file-name))
			      (set-default-file-modes old-mode))))
		       nil t)))

Re: Bug when compiling elc code?

[weber]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 1212 bytes --]

On 8 ago, 11:59, Sven Joachim <svenj...@gmx.de> wrote:
> bojohan+n...@dd.chalmers.se (Johan Bockgård) writes:
> > Sven Joachim <svenj...@gmx.de> writes:
>
> >>     (let ((old-mode (default-file-modes)))
> >>       (set-default-file-modes (file-modes buffer-file-name))
> >>       (byte-compile-file buffer-file-name)
> >>       (set-default-file-modes old-mode)))
>
> > You should use `unwind-protect' here.
>
> Right, thanks.  Is the following okay?
>
> (add-hook 'emacs-lisp-mode-hook
>           '(lambda ()
>              (make-local-hook 'after-save-hook)
>              (add-hook 'after-save-hook
>                        '(lambda ()
>                           (let ((old-mode (default-file-modes)))
>                             (unwind-protect
>                                 (progn
>                                   (set-default-file-modes (file-modes buffer-file-name))
>                                   (byte-compile-file buffer-file-name))
>                               (set-default-file-modes old-mode))))
>                        nil t)))

Btw, is keeping a password inside a .elc file and deleting the
original .el a semi-safe way to hide your personal info ?

Re: Bug when compiling elc code?

[Sven Joachim]

[Please keep this topic on-list. Thanks.]

Hadron <hadronquark@googlemail.com> writes:

> The problem is that even if personal.elc exists in 600 mode, then a
> recompile puts it back to 644. This is surely a bug?

Maybe, but other compilers (gcc, for instant) behave similarly: they
remove the target before they write to it.  And Emacs has a good
reason to do this, as can be seen from this comment in the
byte-compile-file function in bytecomp.el:

,----
| 		  (when (file-exists-p target-file)
| 		    ;; Remove the target before writing it, so that any
| 		    ;; hard-links continue to point to the old file (this makes
| 		    ;; it possible for installed files to share disk space with
| 		    ;; the build tree, without causing problems when emacs-lisp
| 		    ;; files in the build tree are recompiled).
| 		    (delete-file target-file))
| 		  (write-region (point-min) (point-max) target-file))
`----

Regards,
        Sven

Re: Bug when compiling elc code?

[Sven Joachim]

weber <hugows@gmail.com> writes:

> Btw, is keeping a password inside a .elc file and deleting the
> original .el a semi-safe way to hide your personal info ?

No, the password is still stored as clear text and the .elc file can
be disassembled:

  (info "(elisp)Disassembly")

Cheers,
       Sven

Re: Bug when compiling elc code?

[Hadron]

Sven Joachim <svenjoac@gmx.de> writes:

> [Please keep this topic on-list. Thanks.]

Better not to copy on email then - I thought I had replied to the
group. Sorry, about that.

>
> Hadron <hadronquark@googlemail.com> writes:
>
>> The problem is that even if personal.elc exists in 600 mode, then a
>> recompile puts it back to 644. This is surely a bug?
>
> Maybe, but other compilers (gcc, for instant) behave similarly: they
> remove the target before they write to it.  And Emacs has a good
> reason to do this, as can be seen from this comment in the
> byte-compile-file function in bytecomp.el:

As I said in private email, this is not the same thing. passwords etc
tend not to be hard coded into C/C++ files - they are in external
resource/config files which can be cleartext but are hidden by the linux file
permissions in many cases (or even gnupg encrypted).

At the very least I would think that the compile should maintain the
read/access modes of the original .el file.

Either that or something as happened to me might well happen to others
without them realising it. I can see no drawback to keeping the mode of
the elc file as the same as that of the source. Or?

>
> ,----
> | 		  (when (file-exists-p target-file)
> | 		    ;; Remove the target before writing it, so that any
> | 		    ;; hard-links continue to point to the old file (this makes
> | 		    ;; it possible for installed files to share disk space with
> | 		    ;; the build tree, without causing problems when emacs-lisp
> | 		    ;; files in the build tree are recompiled).
> | 		    (delete-file target-file))
> | 		  (write-region (point-min) (point-max) target-file))
> `----
>
> Regards,
>         Sven
>
>

--