Your message dated Sat, 13 May 2006 23:12:52 +0200
with message-id <[EMAIL PROTECTED]>
and subject line openssl: smime -encrypt mangles gzipped files
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
Package: openssl
Version: 0.9.7g-1
Severity: important
It seems that trying to 'smime -encrypt' a gzipped file doesn't work properly.
I noticed when encrypting a 600KB gzipped file left me with a 15KB encrypted
file. Gunzipping that file first and then encrypting it did seem to work
however.
Maybe I'm missing something competely obvious with the usage of openssl smime,
but it seems to me that openssl shouldn't be the one deciding on the kind of
data I'm allowed to encrypt.
Here are some steps to reproduce the problem:
# first we create a test certificate
$ openssl genrsa 1024 > test.key
$ openssl req -new -key test.key -x509 -days 5 -out test.crt
# next we create an original file to encrypt
$ echo "The original text" > original.txt
# we make an encrypted version, and a gzipped and encrypted version
$ openssl smime -encrypt -in original.txt -out original.txt.pkcs7 test.crt
$ gzip original.txt
$ openssl smime -encrypt -in original.txt.gz -out original.txt.gz.pkcs7 test.crt
# now we decrypt the encrypted version, and we check its contents
$ openssl smime -decrypt -in original.txt.pkcs7 -out result_without_gzip.txt
-recip test.crt -inkey test.key
$ cat result_without_gzip.txt
The original text
# ... no problem here
# now we decrypt the gzipped and encrypted version, try to gunzip it, to check
its contents.
$ openssl smime -decrypt -in original.txt.gz.pkcs7 -out result_with_gzip.txt.gz
-recip test.crt -inkey test.key
$ gunzip result_with_gzip.txt.gz
gunzip: result_with_gzip.txt.gz: unexpected end of file
# OK, there's a problem.
Comparing result_with_gzip.txt.gz with original.txt.gz shows that only the
first 8 bytes match, and the rest of the file has been truncated. When testing
with larger files, the first eight bytes always seem to match, but after that
the files are mangled and considerably smaller. For instance, when using 2MB
of urandom data in original.txt, and comparing result_with_gzip.txt.gz with
original.txt.gz, the first 8 bytes match again, but the filesizes are 6356 and
2097503 respectively.
Thanks for looking into this,
-- Mourad DC
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-1-k7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages openssl depends on:
ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an
ii libssl0.9.7 0.9.7g-1 SSL shared libraries
openssl recommends no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
Hi,
>From the manual page:
-binary
normally the input message is converted to "canonical" format
which is effectively using CR and LF as end of
line: as required by the S/MIME specification. When this
option is present no translation occurs. This is use-
ful when handling binary data which may not be in MIME
format.
Using that option seems to work for me, so I'm closing this bug.
Kurt
--- End Message ---
