Re: lynx-dev Options, V.Links, random (was: patch 6 - UI Pages)

[Klaus Weide]

On Wed, 15 Dec 1999, T.E.Dickey wrote:

> ( well, _I_ don't listen, but it wastes time when re-convincing other people 
> ;-)

I haven't seen any complaints recently...

For anyone really concerned, there's always setting LYNX_TEMP_SPACE or
TMPDIR to a private direcory.  Still the best solution if you *really*
want to be sure, AFAIK.

> > If the first temp file is still around, you can get the second of its 
> > creation, therefore the value used for srand(), therefore reconstruct 
> 
> If the protection changes, ctime's not the same, and as long as it's
> being written to, both mtime/ctime are updated.

Ok, that limits it to some files.  If the first temp file that happens to
be one of the short internal pages, it should all be over in a fraction
of a second from open to close, on a reasonably fast machine.  If the
first temp file is a 'd'ownloaded file, things are different.

> > > > Using random numbers for temp filenames opens up a small chance, about  
> > > > one-in-10000, for name collisions.  Therefore a chance for very  

Btw., the filename space for the 'straight counter' implementation is *much*
bigger than the current 'pseudo-random pick out of 10000' implementation.
You have UINT_MAX possible different names before wraparound occurs.

Tested, again by manipulating 'counter' in gdb:  I get
L13496-4294967295TMP.html as the 'largest' filename, then wraparound
to L13496-0TMP.html (with 32-bit unsigned ints).  I.e. name reuse
becomes only a potential problem after 4G temp files...  If your Lynx
session generates one new temp file each second, it'll still take about
about 136 years to run into this...

> > > no - we already deal with name collisions (I did check that - it simply 
> > > tries the next one on a failure). 
> >  
> > I tested it, and find that you are wrong.  OpenHiddenFile removes the 
> 
> ugh (I'll look closer: I read the code but didn't go further, to see if
> the code works as designed: I was reading the do/while loop in LYOpenTemp).

Are you proposing to change the OpenHiddenFile behavior?  I think it's not
necessary, and some stuff may depend on it (although I don't know any
that does).  If reusing "our" files wasn't indended, why would there be
an IsOurFile test in OpenHiddenFile at all?

> > I don't think lenght is a serious abstacle, see the 4 points, at most 
> > an aesthetical matter.  But more importantly I still think filenames should 
> > be generated as before. 
> 
> well, there's more than one part:
> 
>       + more than one person has complained that the straightforward sequence
>         for next-filename is not secure (simply because it provides info).

Could you point to the last time?  (No, I don't count handwaving remarks
on bugtraq...)

No doubt a user who can see temp files created by another user can get
some information about what that user is doing.  That's just in the nature
of using a shared /tmp directory, and of multiuser systems.

>       + is the random sequence effective in making the next-filename not
>         obvious

Certainly less "obvious" to the casual observer, but still possible to
produce in at least some situations - as it is now, without using a good
randomness source at least.

>       + is the code that opens temp-filenames working properly when it finds
>         a collision.

I think the last one is the critical one.  If the answer is YES, the rest
hardly matters.

  Klaus