On Tue, 2006-12-05 at 10:02 +0100, Michele Baldessari wrote:
> The previous version had "inlen != 2" test which doesn't really make
> much sense since we are checking the two next characters, so we need to
> guarantee their presence.
Correct, I made a typo there.
> I also added a second check for
* Fabian Fagerholm ([EMAIL PROTECTED]) wrote:
> On Tue, 2006-12-05 at 09:59 +0200, Fabian Fagerholm wrote:
> > Thanks for the report Michele, I'm marking this as found and I'm
> > starting to investigate. (I was able to reproduce the bug as you
> > showed.)
>
> Apparently the input string can be t
I took a better look at this, and here's an updated
0015_saslutil_decode64_fix:
if (inlen > 0) {
/* check for trailing CRLF */
if (inlen == 2 && in[0] != '\r' && in[1] != '\n') {
if (saw_equal) {
return SASL_BADPROT;
On Tue, 2006-12-05 at 09:59 +0200, Fabian Fagerholm wrote:
> Thanks for the report Michele, I'm marking this as found and I'm
> starting to investigate. (I was able to reproduce the bug as you
> showed.)
Apparently the input string can be terminated by just a single LF. I
presume that in some circ
Processing commands for [EMAIL PROTECTED]:
> found 400955 2.1.22.dfsg1-5
Bug#400955: base64 problems authenticating using gssapi
Bug marked as found in version 2.1.22.dfsg1-5.
> thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking system administrator
(
found 400955 2.1.22.dfsg1-5
thanks
On Tue, 2006-12-05 at 00:25 +0100, Michele Baldessari wrote:
> The bug (or a related base64 bug) is unfortunately still present. To
> reproduce:
[...]
Thanks for the report Michele, I'm marking this as found and I'm
starting to investigate. (I was able to reprod
The bug (or a related base64 bug) is unfortunately still present. To
reproduce:
$ sasl-sample-client
Waiting for mechanism list from server...
S:
TlRMTSBMT0dJTiBQTEFJTiBBTk9OWU1PVVMgRElHRVNULU1ENSBHU1NBUEkgQ1JBTS1NRDU=
sasl-sample-client: Decoding data from base64: bad protocol / cancel
The above
7 matches
Mail list logo
