tramp-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Crazy idea: generate a pseudo-random value for tramp-end-of-output


From: Kai Großjohann
Subject: Re: Crazy idea: generate a pseudo-random value for tramp-end-of-output
Date: Fri, 11 Oct 2002 17:14:23 +0200
User-agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.3.50 (i686-pc-linux-gnu)

Francis Litterio <address@hidden> writes:

> address@hidden (Kai Großjohann) writes:
>
>> The second reason for not incorporating the change is that people
>> might see strange behavior which cannot be reproduced.  I don't like
>> bugs that go away if you look at them.  Therefore I wanted to have a
>> fixed prompt so that people who complain about a misbehavior can at
>> least reproduce the problem when I ask them.
>
> I hadn't thought of that.  My change makes TRAMP non-deterministic in
> some small way.  This is often not desirable in software.

But I take it that you and Daniel would like this change anyway?

>> But I can see that the issue is different for
>> tramp-handle-shell-command, where the string "/////" might indeed
>> occur.
>>
>> Your (and Daniel's) suggestion could easily be extended to deal with
>> the first problem I'm mentioning above, by including "///" in the
>> prompt.  But I don't know how to deal with the second issue.
>>
>> Ideas?
>
> Well, the output of a user-supplied shell command could contain just
> about any byte sequence (even binary data).  This was what motivated me
> to use the MD5 hash of some unpredictable data.  It's a bit pattern
> known only to TRAMP, and it's _astronomically_ unlikely to occur in the
> output of remote commands.  I'm more likely to be killed by a meteor
> within the next 10 seconds than to experience an accidental collision
> between tramp-end-of-output and remote command output.
>
> [Pause for 10 seconds.]
>
> See. :-)  I'm only half kidding.  A hash function like MD5 is
> "cryptographically secure" because it exhibits the feature that if you
> change just one bit in the input data, then, on average, half of the
> bits in the hash change.  This is what makes collisions so unlikely.

Note that you are comparing apples and oranges.  MD5 has the property
that md5(x) and md5(y) will be very different even if x and y are
similar.  It does not say anything about md5(x) and some other value
z which is not the result of an MD5 operation.

You could also take any 128 random bits (if MD5 indeed produces 128
bits).

How about using (concat "///" your-value)?

Michael has submitted some rather large changes which he wants me to
look at.  Could you please remind me to add this after his changes are
in CVS?  I might forget otherwise, and I'm pretty busy at the moment.

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]