[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