On Fri, 21 Jan 2005, Victor B. Wagner wrote: > > The ^@ sign is right above the second mime boundary. > > ^@ is an indication of the ASCII NUL (symbol with code zero),
Ahh, thanks... I was really wondering what it meant :) > So, anything wrong can happen if program, which treates in input as text > encounters this symbol. Then i better understand why openssl smime -verify can't find the next mime boundary. It simply thinks the message stops there! > Probably, in your code you write one char more than neccessary. Probably, but where? I have an idea. > May be you write as many char as you have allocated bytes for string, while > you should write as many as strlen() function returns. Thats exactly the fun part. I've only used BIO and PKCS7/SMIME API calls, and not a single std C function. Largely the way it is done in the openssl smime app, just a very big deal stripped down. It could actually fit for the demos/ directory, since there is no smime directory there :( After a second of thought, i found the flaw. I wasn't sure if BIO_read/write also copied the \0, so i inserted one myself with BIO_write( mem, "\0", 1 );. (How foolish :) And apparently SMIME_write_PKCS7( out, p7, mem, flags ); writes the /whole/ BIO *mem first, and /then/ the PKCS7 *p7. And since mem contained an extra \0, this was of course also written :( A many thanks to this list and Victor :) -- Regards, Michal Wodzinski ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
