Re: lynx-dev Lynx buffer mismanagement

[Bela Lubkin]

Theo de Raadt wrote:

> > 980508 Laura Eaves wrote: 
> > > 980508 Thomas Dickey wrote:
> > >> 980508 Theo de Raadt wrote:
> > >>> Lynx source code is rife with really really bad buffer mismanagement. 
> > >>> Any plans to fix any of this soon? 
> > >> are you volunteering to help?
> 
> > > It would help if you pointed out the specific places
> > > where the buffer is mismanaged.
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> Sigh.  Obviously, the point has been completely missed.

Not completely.  It would still be helpful to provide some examples you
noted, because the people you're talking to are less expert at buffer
management issues than you.  Even if they would like to carry out your
wishes, doing so would be easier with a starting point.

> I certainly do not have time to do the job that the lynx people should
> be doing themselves.  Go through your code, fix all the buffer overflows.
> It's obvious.  Every strcpy, strcat, sprintf, and every place where *p++
> goes beyond the end of the buffer.
> 
> Just read the code, understand it, and fix it.

Lynx has a lot of other problems to tackle, such as keeping up with
evolving WWW standards.  I don't disagree, and I think hardly anyone
would disagree, once they understood what you're getting at, that these
things should be fixed.  But they'll only get fixed when someone has
time and energy to do it, and feels it's higher priority than other
current issues.

> > do let everyone know exactly where you see room for improvement
> 
> ALL OVER THE CODE.  It's horrible; there's probably 400 buffer
> overflows in lynx of some sort or another, and it's shameful that
> noone has sat down and tried to improve the code quality before.

So do you have a list of 400 instances, to give someone a starting
place?

Before starting to reply I did a quick search and found about 1200 calls
to sprintf, strcat, and strcpy.  None to gets(), at least.  ;-}  Lynx
also has its own internal functions which might be susceptible to the
same problems, so it might be even worse than that.  On the other hand I
could see right away that a good fraction of them were using internally
generated data that could be "proven" safe.

I'm willing to do the line-by-line evaluation (I've done this for other
areas of Lynx).  So I'm one of the 3 or 4 most likely people to actually
tackle the problem.  My request for a starting place applies most of all
to my own probability of tackling it.

> > & do feel very welcome to contribute patches of your own.
> > the latest 2-8 is at  www.slcc.edu/lynx/release/
> > & the latest development version is at  -/-/current/  (i believe);
> > TD is the current volunteer co-ordinator.
> 
> Sorry, but it's the lynx' team's responsibility to improve their own
> code.  I've got my own to work on.  I'm simply pointing out that lynx
> is in very bad need of a code review.

I agree.  It will happen, eventually.  Maybe soon, maybe not.

>Bela<