So, we found the error, good!
I could not find the buffer with the raw encrypted content.
As far as I understand, it is stored in the buffer-local variable called "mime-view-temp-message-buffer”.
C-h v mime-view-temp-message-buffer
tells me:
mime-view-temp-message-buffer is a variable defined in `mime-play.el'.
Its value is #<buffer *WL:Message*-nil>
Local in buffer *Preview- *WL:Message**; global value is nil
Documentation:
Not documented as a variable.
That means the buffer with the raw decrypted content has the name: *WL:Message*-nil
But I do not know how to display this buffer. M-x b does not show this buffer because it is not global, I guess.
How can I display this buffer?
As a workaround, I used the override function for "mime-view-application/pkcs7-mime" you sent me before in order to get hold of the raw data.
I attached you the contents of the buffer *WL:Message*-nil in my last mail to you.
Then I went into hexl-mode as you asked me to do. The result (only the beginning) is visible in screenshot attached below.
Finally I stored the direct output of gpgsm in a file attached below as well. The command I used was:
gpgsm -d smime.p7m > raw_decryped_on_command_line_from_gpgsm
I hope this is all the information you need to simulate my case and to compare the outputs.
All best
mc
Attachment:
raw_decryped_on_command_line_from_gpgsm
Description: Binary data
On 03.02.2014, at 15:11, Kazuhiro Ito <kzhr@d1.dion.ne.jp> wrote: >> 3. showing "mime-view-entity" >> or >> showing "mime-view-entity-header” >> in new buffer >> ========================== >> >> [mime-buffer-entity >> [0 0 0 0 0 0 0] >> #<buffer *WL:Message*-nil> >> ((type . message) >> (subtype . x-broken)) >> nil nil nil >> ((type . attachment)) >> "7bit" >> ((Content-Transfer-Encoding . "7bit >> ") >> (Content-Disposition . "attachment; >> \n filename=smime.p7s >> ")) >> nil #<buffer *WL:Message*-nil> 1 4215 4215 4215] > > mime-view-entity's property shows how the raw content is parsed, and > this result seems broken. > > 1. Last 4 numbers indicate positions of the beginning of headers, the > end of headers, the beginning of body, the end of body respectively. > The fact that last 3 numbers are equal means delimiter between headers > and body are found at the end of the raw content, i.e. actual > delimiter is ignored. > > 2. Moreover, last 3 numbers are too big. The buffer which has 4214 > characters returns 4215 as point-max function's result. The decrypted > raw content actually has 4214byte. But CRs in EOL are truncated in > raw content's buffer. As a result, point-max's result is more smaller > than 4215. > > > Your broken mime-view-entity's property is similar to the case that > gpgsm append extra CR in its output. I guess gpgsm outputs extra > character before LF. Please visit the decrypted raw content buffer > according to [wl-en: 05587] and run hexl-mode to check whether there > is garbage especially before LF. > > > -- > Kazuhiro Ito >
Attachment:
smime.p7s
Description: S/MIME cryptographic signature