Re: hypermail core dump - buffer overflow

On Mon, 25 Jan 1999, Ron Stanonik wrote:

> We ran into a problem with hypermail core dumping when parsing messages
> with long lines, QP encoded with soft line breaks. The problem was a
> buffer overflow, which the appended diff seems to have fixed.

Hypermail is filled with buffer overflows. The most recent version in the main thread has no protection against them and my ambitions to fix them has been paused (although my 2b12 version should not be subject to buffer overflows, even if other bugs exist).

> The messages were coming from Outlook Express, multipart/alternative, the
> alternatives being text and html. It appears the messages were composed
> as html, then Outlook Express generated the text alternative by turning
> each paragraph into one line, QP encoded with soft line breaks (= at the
> end of the maximum 76 character lines to satisfy mime's maximum line
> length requirement). When the decoded line exceeded the size of
> tempbuff, then hypermail would core dump.

Many mailers work that way and hypermail makes a lot of silly assumptions about maximum line lenths all over. It is not a trivial task to change all them into dynamic versions.

I still wait for Kent's promised beta 4, as he stopped all my development well over a month ago now and still there is no sound from him.

I don't mean to be rude, but if there ever is gonna be any hypermail 2 development, isn't it time for some development? I may have to reconsider my previous statement about me not going to fork this project. If things don't change within the nearest months, I'm gonna take off in a direction where things actually move.

Yes, all opinions in the matter are welcome!

--
             Daniel Stenberg - http://www.fts.frontec.se/~dast
   ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol