Re: [PATCH v4 1/2] git-imap-send: Add CRAM-MD5 authenticate method support

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 13, 2010, 07:42 UTC
Message-ID: <7vsk95sht6.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4B764B67.1020402@dcl.info.waseda.ac.jp>

Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp> writes:

> Because strlen(challenge_64) is the upper limit of length of challenge.
> So tail part of challenge may not be filled by EVP_DecodeBlock(),
> non-zero filled buffer produces not NULL terminated string.
> I've confused once by this problem before.

If you know the length of the decoded thing, then you would just know how much to hash. Doesn't the EVP_DecodeBlock() give you that number? Why do you need a NUL termination to begin with?

Because you pretend as if you do not have the actual length, you run strlen() instead. I am not that familiar with the API to EVP_* functions, but I'd be surprised if it were designed in such a stupid way to force you to write into a pre-zeroed buffer.

By the way, if you use strlen() on a pre-cleared and overallocated buffer, doesn't your ENCODED_SIZE(n) have to be one byte longer than what you are computing?

Looking for EVP_DecodeBlock in http://www.google.com/codesearch seems to find usage examples of varying quality. Your favorite isync-0.5 stores the result in "len", but it entirely ignores it and does the same silly calloc() and strlen(). Usage example in OpenSSL's own x509spki stores the return value in spki_len and uses that as the length of the stuff to call another function, which looks much more reasonable. From this observation and a bit of reading of the manual, my understanding is that the function gives you the number of bytes written in the buffer.

So does EncodeBlock(), I would think.