From: Marc Balmer (marcmsys.ch)
Date: Mon Jan 01 2007 - 09:21:41 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Marc Espie wrote:
> Well, I was probably a bit harsh on my first comments wrt hiawatha.
> One actually nice feature of this program is that it is reasonably
> small. Someone with incentive could probably audit it.
>
> Since it is under the GPL, the OpenBSD project has little incentive
> in looking at it very closely...

You might want to a closer look a www/nostromo, a secure and small
webserver written by mglocker.

>
> Antoine fixed hiawatha so that it does not abuse user nobody, so that one
> issue doesn't exist on OpenBSD.
>
> Just looking shows me there is probably a race condition on signals.
> Using the same variable for TERM/USR1/USR2 is asking for trouble...
> and the variable is an int, not a sigatomic_t (whch is innocuous on
> most arches, but still).
>
> Some printf's are not portable... like printing getpid with %d (okay,
> this is a stretch).
>
> the str2int function has absolutely no overflow handling.... and uses 48
> directly, which is totally icky. This means that a few functions have no
> protection against user error, which is probably not too bad.
>
> Like I already noticed, there is no handler for seg faults, not even
> something to log an error message (which is about all that should happen,
> but this SHOULD happen).
>
> I've looked a bit more, but the coding layout is a bit bizarre. I'm not
> a big fan of code that indents out to column 160 or so...
>
> There are LOTS of hand-coded length computations based on strings, and use
> of unsafe string functions, or error-prone stuff (between atoi, str2int,
> strncpy, and friends...). I don't think it's incredibly bad, but it doesn't
> look incredibly good either...
>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]