333311 - Automatic decoding of binhex attachments is not performed on the Mac and can lead to a mismatch between content and file extension

Status: RESOLVED WONTFIX

(Thunderbird :: General, defect)

Description

[jwq]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727

Thunderbird version 1.5 (20051201); Mac OS X 10.3.9

 I occasionally receive binhex encoded files which have MIME headers similar to the following:

   Content-Type: application/mac-binhex40; name="Filename.zip"
   Content-Disposition: attachment; filename="Filename.zip"

Thunderbird saves the attachment as "Filename.zip" without Type or Creator codes and without binhex decoding the file. The mismatch between the file contents (binhex) and the file extension (zip) causes BOMArchiveHelper 1.0.1 to lock and Stuffit Expander 7.0.3 to crash the Finder.

 I most recently received such an attachment from a user of Microsoft Outlook Express for the Mac version 5.0.4.


Reproducible: Always

Steps to Reproduce:
1. Receive binhex encoded attachment with declared filename "Filename.zip".
2. Save attachment to disk (attachment will be saved as "Filename.zip" with no Type or Creator).
3. Double click on the attachment.

Actual Results:  
The assigned zip-file expander app will launch, but the saved attachment will not be expanded due to mismatch of content and file extension.

Expected Results:  
Thunderbird should automatically binhex decode the attachment at the time it is saved to disk.

 This problem was reported for all platforms in Bug 220167, but the fix apparently didn't include the Mac. Bug 163142 concerns browser downloads and in the case of the Mac it was decided to hand binhex decoding off to the appropriate helper app. So I'm told. This is the wrong behaviour for Thunderbird because it leads to a problematic mismatch between content and file extension under some circumstances.

See also: Bug 217104.

Comment 1

[jwq]

 The attachment to Bug 217104 "mozilla.eml" may be used to demonstrate this problem. Open "mozilla.eml" in Thunderbird (File -> Open Saved Message...) and save the attachment to disk. The attachment is saved as "mozilla.zip" but the content is the same as was in the body of "mozilla.eml":

   (This file must be converted with BinHex 4.0)

   :#fe[HQPXE'%ZHQP`!&T*8#"D59!J!3!!!#J1!!!!!+pC8%X$""3!!!!)!&Zd&Lr
   ...

"mozilla.zip" causes BOMArchiveHelper 1.0.1 (Apple's zip archive app which comes with Mac OS 10.3.9) to report an error and Stuffit Expander 7.0.3 to crash the Finder.

 If the file is renamed "mozilla.hqx" and/or is binhex decoded, the resulting zip file can be unzipped by either BOMArchiveHelper or Stuffit.

Comment 2

[Katsuhiro MIHARA]

Reproduced with Nightly-trunk TB version 3 alpha 1 (20060706).
Mac OS X 10.4.7 (PowerPC)

Comment 3

[Katsuhiro MIHARA]

Reproduced with Seamonkey {Build ID: 2006080106}.
Mac OS X 10.4.7 (PowerPC)

Comment 4

[Katsuhiro MIHARA]

I want to change Product to "Core" because this bug can be reproduced with Thunderbird and Seamonkey.

Comment 5

[HARUNAGA Hirotoshi]

dup of Bug 163142 or Bug 202353.

Comment 6

[jwq]

(In reply to comment #5)
> dup of Bug 163142 or Bug 202353.

 Neither, actually. Bug 163142 is for browser downloads and Bug 202353 was filed due to older versions of Stuffit having issues with end of line characters (and is thus probably invalid).

Marking confirmed (thanks, Katsuhiro).

Comment 7

[Katsuhiro MIHARA]

Gecko on each platforms has either BinHex decoder or AppleFile decoder.

> 64 #if defined(XP_MAC) || defined(XP_MACOSX)
> 65 // Mac OS
> 66 #define BUILD_APPLEFILE_DECODER 1
> 67 #else
> 68 // other platforms
> 69 #define BUILD_BINHEX_DECODER 1
> 70 #endif
http://lxr.mozilla.org/seamonkey/source/netwerk/build/nsNetModule.cpp#64

This specification is inconvinient for users.

Comment 8

[Michael Soliman.]

Moin Moin.
This Bug seems to be valid on XPSP2 Systems as well.
How about a workaroung:
We could handle it like the cookies and issue "Allow", "Allow for Session", "Deny", buttons with a remember answer checkbox (and of course the logic of ignoring this specific error).
It would still be ok to reanswer the question for every session.
By the way, is there a simple method to download and compile Thundie on a windows system (I mean including a working compilation environment: I have MSVC 8, Intel C++ 9.1 and do not even see, where to download a configure compatible shell that can be compiled without configure.).
_Tschuess,
__Michael.

Comment 9

[rb]

Reproduced with Nightly-version 2.0.0.6pre (20070724)
Mac OS X 10.4.10 (PowerPC)

perchance, any progress elsewhere on this since Dec '06?

Comment 10

[gumpish]

Why is it that Tb/Linux handles this correctly but Tb/Mac doesn't? I thought this project was high-level enough to be fairly platform generic and that this functionality would be part of the shared codebase.

Also it's a bit ironic since BinHex was created specifically to handle the resource fork in Mac files...

Comment 11

[Wayne Mery (:wsmwk)]

Is this really still an issue?

Comment 12

[Eckard Berberich]

I can't reproduce this issue in TB 60.3.3 (running macOS 10.13.6 on an iMac).

Comment 13

[jwq]

The passage of time has seen the BinHex encoding system become as obsolete as the classic Mac OS from which it originated. This bug's resolution is, de facto, WONTFIX.