inn-2.2 / storageapi + wireformat == corruption

Russ Allbery rra at stanford.edu
Sat Sep 25 23:21:22 UTC 1999


David W Hankins <dhankins at mercenary.net> writes:

> Two inn-2.2 systems, one feeding the other via innxmit.  The result is
> something on the order of 5k md5 log blips a day...but that's from
> memory, network screwiness is keeping me from calculating that number
> anew.  All of the articles I've caught on both systems disks have been
> cases where lonely \n's had been matched up to \r\n pairs, and other
> assorted line termination weirdness

Yup.  I finally had a chance to go and look at this, and QIOread() has:

        /* Find the newline. */
        p = memchr((POINTER)qp->Start, '\n', (SIZE_T)(qp->End - qp->Start));
        if (p != NULL) {
            if ((qp->WireFormat == 1) && (*(p-1) == '\r')) {
                *(p-1) = '\0';
                qp->Length = p - qp->Start - 1;
            } else {
                *p = '\0';
                qp->Length = p - qp->Start;
            }

which will mangle any article that's in wire format and contains an
embedded bare newline.  Not good.  It needs to be rewritten into a loop
that searches specifically for \r\n when WireFormat is set.

The wire format guessing code is still going to need to use the first line
termination found to determine whether an article is in wire format so
that we can support older spools, but that should be safely in the headers
where I'm pretty sure bare newlines are outlawed by the standards.

I'll go look at fixing this.

-- 
Russ Allbery (rra at stanford.edu)         <URL:http://www.eyrie.org/~eagle/>


More information about the inn-workers mailing list