Hello Roumen,
On Sunday, October 22, 2006 at 14:20:49 +0200, Roumen Petrov via RT wrote:
> Proposed patches:
> a.) apps-smime.patch : proper eol for To,From and Subject headers in
> case of -crlfeol command line option.
Very good, thank you. Only the smime.p7s base64 lines remain ending
in LF with -crlfeol.
> b.) crypto-pkcs7-pk7_mime.patch :
> - add header in case of binary procesing
I'm not familiar with the -binary option, but generating a fixed
"Content-Type: application/octet-stream" header would disallow insertion
of user's own custom headers.
> - add empty line (mandatory) if procesing type is not specified (case
> without -text and without -binary)
Unfortunately this seems a bad idea. Without -text nor -binary, we
sign (or encrypt) a MIME entity, and the user must provide us the
mini-header. If we insert an empty line there, it breaks this
mini-header.
Example: I want to sign a Latin-1 text with accented letters.
OpenSSL -text option doesn't support charsets at all, outside of the
default us-ascii. So I must prepare myself the appropriate header
together with the said accented text properly encoded:
| Content-Type: text/plain; charset=iso-8859-1
| Content-Transfer-Encoding: quoted-printable
|
| Un texte accentu=E9.
I must give those 4 lines to OpenSSL's input, and use no -text
option (nor -binary option, otherwise I'd have to do the CRLF
canonicalization myself). Today, the result is OK "Un texte accentué.".
With your patch, the result is a 7bit Ascii text showing those 4 raw
lines.
Bye! Bruno.
--
/* Bruno Kozlowski <[EMAIL PROTECTED]> */
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
