Hello all,

I found the problem in camel-smime-context.c and fixed it. Please see bug 608620.


The bug report includes a patch suitable for applying on the evolution-data-server trunk. If someone can commit it to the trunk (and to any other "prior supported releases" too if there are any--I don't know the release schedule) that would be great.

The fix is pretty much a one-liner. I tested it against the trunk and against Evolution 2.26.1, which is what I apparently got from <http://mad-scientist.us/evolution.html>.



dev+gn...@seantek.com wrote:
Hi there,

I have found a bug in the S/MIME feature of Evolution (2.28.1 and trunk). Hopefully this should be pretty easy to fix. I tried to file this as a bug on Bugzilla, but I cannot create an account on bugzilla.gnome.org--no ping e-mail is received in any of my inboxes, and I have tried several e-mail addresses with different providers.

When a signed and encrypted message is composed in Evolution, the MIME content of the EnvelopedData object is formatted with bare linefeeds (LFs). This is not valid MIME--all MIME messages (and e-mail in general) is required to use CRLFs as line endings. The outer message, where the EnvelopedData is base64 encoded, and the inner message inside the SignedData part, are properly CRLF encoded. It's just the layer in between.

When an EnvelopedData (encrypted)-only message is composed, and when a SignedData (signed)-only message is composed, this is not a problem.

How can this be fixed? I have started to look through Evolution to see if it is easy enough to develop a patch, but the process is taking awhile.

Evolution-hackers mailing list

Reply via email to