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

Hitoshi Mitake [off-list ref] 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.