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

[T.E.Dickey]

> > > If they are wrong and we are right, we shouldn't listen to them.  
> >  
> > easy in principal, hard in practice. 
>  
> Hard not to listen to people who are wrong?  I don't find that, and you 
> seem to do a good job of it yourself. :) 

( well, _I_ don't listen, but it wastes time when re-convincing other people ;-)
  
> [I don't know why he talks about utime() - stat() should be all that's 

nor I - utime/utimes set times (and iirc lynx doesn't)

> needed.  That text talks about the "secure" value, which doesn't 
> matter any more, but the same applies for getting the seed value used 
> now.] 
>  
> 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.

I considered adding a pointer-value (just to make it less predictable),
but left it with time.  There's not a lot of good "random" variables we
could use.

> the whole sequence of random numbers.  Basically a no-brainer for 
> anyone serious, and the "advantage" of random numbers has evaporated. 
> Or am I completely missing something? 
>  
> Now, we could try to improve this by using a more sophisticated seed 
> value.  Hmm, so what sources of randomness are there that can be 
> used portably?  Do we really want to get into this kind of race, and/or 
> leave some systems more vulnerable than others? 
>  
> > > Using random numbers for temp filenames opens up a small chance, about  
> > > one-in-10000, for name collisions.  Therefore a chance for very  
> >  
> > 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).

> You mean someone using the same pid?  I don't see how *that* creates a 

no - it could wrap around in only a few days on a busy ISP, and since temp
files are not necessarily cleaned up they could still be there.

> problem.  The other process would have to be dead of course.  If it 
> belonged to the same user, no problem - obsolete file instance will be 
> overwritten, nobody needs it any more.  If it belonged to a different 
> user, no problem - the code should detect IsOurFile()==FALSE and iterate 
> until a free name is reached. 

agreed
  
> 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).

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

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


-- 
Thomas E. Dickey
address@hidden
http://www.clark.net/pub/dickey