From: Junio C Hamano Date: Sat, 13 Feb 2010 07:42:13 GMT Subject: Re: [PATCH v4 1/2] git-imap-send: Add CRAM-MD5 authenticate method support Message-ID: <7vsk95sht6.fsf@alter.siamese.dyndns.org> In-Reply-To: <4B764B67.1020402@dcl.info.waseda.ac.jp> Hitoshi Mitake 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.