base64 functions with SASL in INN

[Julien ÉLIE]

Hi Russ,

>> -          inbase64, outlen*2, (unsigned *) &inbase64len);
>> +          inbase64, outlen*2 + 1, (unsigned *) &inbase64len);
>>
>> But I believe it should be "outlen*2 + 10" (and thus, there was
>> already a bug).
>
> It should at most be +8, since we want to have the space to append the
> CRLF into the same buffer.

OK, that's fine with "+10" then, as that number is used elsewhere
in imap_connection.


> -#define BASE64_BUF_SIZE 21848  /* Per RFC 2222bis:  ((16K / 3) + 1) * 4. */
> +#define BASE64_BUF_SIZE 21848  /* Per RFC 4422:  (E(n/3) + 1) * 4
> +                                   where n = 16 kB = 16384 bytes. */

I will change E(n/3) to floor(n/3) -- it will be more understandable.
I think E() is a French notation for taking the int part (integer == "entier"
in French).


>> -           /* Encode the server challenge. */
>> +           /* Encode the server challenge.
>> +             * In sasl_encode64() calls, the fourth argument is the length
>> +             * of the third including the null terminator. */
>>             r1 = sasl_encode64(serverout, serveroutlen,
>> -                               base64, BASE64_BUF_SIZE, NULL);
>> +                               base64, BASE64_BUF_SIZE+1, NULL);
>>             if (r1 != SASL_OK)
>>                 r = r1;
>>        }
>
> This change looks wrong -- it looks like we're telling sasl_encode64
> that we have a larger buffer than we actually do.  That could lead it to
> writing beyond the end of the buffer.  I think that argument should be
> whatever the buffer size really is.

We have:

    char base64[BASE64_BUF_SIZE+1];

Isn't it enough for the size?

And then we use:

    Reply("%d %s\r\n", NNTP_CONT_SASL, serveroutlen != 0 ? base64 : "=");

so CRLF is not in base64.

-- 
Julien ÉLIE

« L'homme a imaginé le cercle avant de savoir que la terre était ronde.
  Ça prouve quand même une certaine faculté d'invention. » (Jacques Sternberg)