bug#24478: 25.1; Regression in 25.1: .tramp_history files are littered in non-$HOME working directories

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Mon, Oct 10, 2016 at 12:38 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Michael Albinus <michael.albinus@gmx.de>
>> Date: Thu, 22 Sep 2016 20:02:59 +0200
>> Cc: Ævar Arnfjörð Bjarmason <avarab@gmail.com>,
>>  24478@debbugs.gnu.org
>>
>> Ævar Arnfjörð Bjarmason <avar@booking.com> writes:
>>
>> Hi,
>>
>> > There's a regression in 25.1 introduced by 1e04ea9 (although that seems
>> > to also have fixed an issue): Now tramp-histfile-override is set to
>> > ".tramp_history", which is good, but I would expect it to be created in
>> > $HOME on remote hosts.
>> >
>> > Instead when I e.g.:
>> >
>> >  1. C-x C-f //ssh:<hostname>:/usr/local/git_tree/sysadmin/
>> >  2. Run e.g. magit to make a commit
>> >  3. I end up with:
>> >
>> >     $ echo $PWD/.tramp_history
>> >     /usr/local/git_tree/sysadmin/.tramp_history
>> >     $ wc -l !$
>> >     wc -l $PWD/.tramp_history
>> >     34 /usr/local/git_tree/sysadmin/.tramp_history
>>
>> Most of the shells I know off use the home directory, when you specify
>> just the relative file name ".tramp_history".
>>
>> > From reading https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20446 and
>> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19731#56 this seems like
>> > an unintended bug.
>> >
>> > Just setting:
>> >
>> >     (setq tramp-histfile-override "~/.tramp_history")
>> >
>> > Works for me. Now it's always created in ~.
>>
>> I have thought about this, when I was fixing bug#19731. Unfortunately,
>> there exist shells which cannot expand "~/". Other shells cannot expand
>> "$HOME/". So I really don't know a robust default we could offer.
>>
>> Maybe one should give this problem more emphasis in the Tramp
>> manual. But who reads manuals?
>
> Michael, does the above mean this bug should be closed as wontfix?  It
> currently blocks a release, so I'd like to resolve this some way soon.

I'm the reporter, so I obviously have a dog in this fight, but I don't
think that makes sense. This whole facility introduced in the emacs-25
series still seems really broken since its introduction, and the
various regressions reported have just resulted in other regressions
taking their place, the latest one being discussed in this ticket.

Here's a Git history showing the back & forth this has gone through:

    git log --reverse -p -Gtramp-histfile-override -- 'lisp/net/*tramp*.el'

I might have read those commits incorrectly, but it seems to me that:

 * In emacs-24 there was no way to have a Tramp history file, we'd
just specify a HISTFILE=/dev/null environment variable.

 * 9be1538 added an option to change that, so you could have a history
file as a file, defaulting to /dev/null, but they way it was
implemented caused it to unlink /dev/null, as reported in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19731

 * So Michael patched it to make 'unset an option, which was
implemented in 6f8372d, as far as I can tell at this point the
facility worked the way it did in emacs-24 again. I.e. no history by
default, but no regression with unlinking /dev/null

 * 'unset was made the default by Michael in 954ca0f, but just a few
hours later this was set to t instead in c10828b, which does the same
thing as 'unset according to the commit message. I.e. just an internal
refactoring. This was followed-up by 24fa4ff to refactor it some more.

* It was then changed from t to ".tramp_history" in 1e04ea9. The
commit message says to fix
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20446 but I don't see
how it could eat the bash history if it's set to not have any history
file by default.

* Now because it's ".tramp_history" and not "~/.tramp_history" it gets
created in random non-~ directories you open with tramp, but more
importantly, and I didn't realize this in my initial report, the shell
history *might be shared between multiple users*, which seems like a
bad security issue.

It seems to me that the best solution to this whole problem is to set
it to "t" again which would return to the non-history days of
emacs-24, since apparently using ~ can't be counted on.

In addition, depending on the bug with history potentially being
shared between users now that it's being dumped in random potentially
shared FS directories they open with tramp, changing this to
".tramp_history" might have caused a security issue worth of a CVE,
but I haven't investigated that, but we *certainly* went from no
history by default in emacs-24 to history littered in potentially
world readable directories in emacs-25.

The permissions on the file itself might have mitigated data leakage
in some cases, but in those cases it would have blocked other Emacs
users from recording their shell history. In addition not all remote
FSs tramp supports working with can be relied upon to obey HISTFILE
permissions.