Re: lynx-dev Some more security issues in Lynx...

[dickey]

> Tom Dickey wrote: 
>  
> > > What is snprintf?  
> > It is an 'sprintf' that allows you to specify a buffer limit.  There's 
> > a couple of flavors that it comes in (and they're incompatible).  I guess 
> > it's available on roughly half of the compilers people are using now. 
>  
> I would guess more like 80%. 

maybe in terms of number of users - but there's a lot of odd systems
around.  (it's in neither of VAX C nor DEC C, for instance).
  
> > (I don't believe it's either ANSI or POSIX - but it is present in Solaris). 
>  
> I could be mistaken, but I think snprintf() has made it into the latest 
> Unix standards (the Open Group's Unix98, and presumably the underlying 
> XPG4.2 standard). 
good. that means it'll percolate through to 'older' systems in a couple
of years.
  
> > For our purposes, it's not useful - I don't want to truncate strings 
> > just to avoid buffer overflow. 
>  
> That's true in some cases; there are others where snprintf() would 
> certainly be useful.  But in any case, it can be programmed around. 
>  
> Fixing these things one by one as they get slowly pointed out by bugtraq 
> isn't ever going to fix the real problem.  The entire Lynx code base 
> needs to be gone over with appropriate tools (software or human mind) 
> and fixed.  Then, when it's clean, we have to keep an eye on keeping it 
> that way. 

I agree with that - but now that we're going into the beginning of a
new development cycle, I think it's time to visit some of those and
bite off another chunk.  (There's also some display issues like the
text area that I know almost enough to do something about -- pruning
the code of some of the fixes such as buffer overflows and pathname
messes will let me read what's there more carefully).
  
But that's a short part of the cycle - once we get the initial bug
reports from 2.8.1 resolved and before getting bogged down in the
harder changes that we'll get into.

> I consider this all medium-distant-future stuff.  The code base is too 
> large for any one person to fully evaluate "in his spare time"... 
>  
> >Bela< 


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