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-boun...@openssl.org] On Behalf
Of e...@coderhacks.com
Sent: Wednesday, March 14, 2018 02:33
To: openssl-users@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.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
