Problem with .ghci (fwd)

[Tom Moertel]

Simon Peyton-Jones wrote:
> 
> | explicitly tell ghci that they're okay! Hand-holding w.r.t.
> | 'insecure' file permissions has a nasty habit of becoming a
> | nuisance in unusual cases the original authors hadn't thought of. :-(
> 
> Constructive suggestions for how to improve are welcome.
> What we are trying to avoid is obvious trojan horses, where
> X can persuade Y's ghci to do rm *.*.   This is bad.

How about verifying an untrusted .ghci file by looking up its MD5 hash
in a list of "approved" hashes?  The verification would occur only if
the user provides an approval list (or lists?) in $HOME/.ghci (which
should be writable only by that user):

    :add_auto_ghci_list $HOME/.ghci-approval

Then, when the user should happen to encounter the dreaded

    *** WARNING: ./.ghci is writable by someone else, IGNORING!

he could inspect the suspect .ghci file, and (if it meets approval) tack
its md5sum unto his approval list to tell ghci that autoloading this
particular file is okay:

    md5sum .ghci >> $HOME/.ghci-approval

Thoughts:

* Fairly simple to use.
* Imposes no overhead if you don't use it.
* Eliminates the possibility of running an untrusted .ghci file
  that is writable by someone else.  (Unless *you* approve it,
  it won't run.  If the file changes, you must re-approve it.)
BUT
* Seems a bit roundabout.

How does that sound?

Cheers,
Tom