[openssl-users] MIME-canonicalization

etc at coderhacks.com etc at coderhacks.com
Wed Mar 14 16:43:10 UTC 2018


I have verified in comparing the orginal file that is going into 
SIME_read_CMS with
the content of the the 2nd argument (bcont) it get out of it.

I check manually. The file with a hex-editor.
bcont with BIO_read and then print it to the screen.

The file does have LFs, the bcont does have CRLFs.

The file is going directly into SMIME_read_CMS via BIO_read_filename.
So I use the filename to address the content-file - no string or 
something with a previous parsing.

I am running a debian buster.

Best regards,
Chris




On 2018-03-14 17:25, Michael Wojcik wrote:
>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
>> Of etc at coderhacks.com
>> Sent: Wednesday, March 14, 2018 02:33
>> To: openssl-users at openssl.org
>> Subject: Re: [openssl-users] MIME-canonicalization
>>
>> I think I found the reason for the problem.
>>
>> SMIME_read_CMS does convert any single LF to a CRLF.
> Have you verified that the file actually contains bare LFs, and not CRLFs?
>
> If you're running on Windows, beware the CRLF conversions done by the C library. For example, if you write a file using a file BIO that was created using a FILE* from a text-mode fopen, that file will have LFs converted to CRLF on output. You need to open the file in binary mode, or call _setmode on the FILE* before writing to it.
>
> SMIME_read_CMS just calls SMIME_read_ASN1, which ultimately does a bunch of BIO_gets, which calls the gets method on the BIO object. A file BIO's gets method just calls fgets. So if there's translation happening, it would appear to be in the C runtime.
>



More information about the openssl-users mailing list