BZIP2 Plugin and Current libbzip2 Bug Fix

[karlchen]

Hello, Christian.

The BZIP2 Packer Plugin is v1.4 and was released in July this year.
So I tend to assume the latest libbzip2 fixes which e.g. Heise reported about (engl, german) only this month cannot be included yet.
Is the current TC plugin affected? And if so may we expect an updated version soon?

Kind regards,
Karl

[ghisler(Author)]

I will check it, thanks for your report. Do you know where I can find technical information about the bug they found?

[karlchen]

Hello, Christian.

Seems as if the details are currently not available to the public (yet). Please, cf. here, http://www.bzip.org/downloads.html, and here, http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0405.

Kind regards,
Karl

[ghisler(Author)]

I have updated the plugin now, see www.ghisler.com (plugins section). I made a code comparison myself, there was just one line added where the length of a specific data field was checked.

[karlchen]

Hello, Christian.

This was fast. Thank you very much.

Cheers,
Karl

[zeeko]

Hello,
I would like to announce modified source code of bzip2 plug in with support for very long paths (>260).
Modified source code can be downloaded from http://dl.dropbox.com/u/13501688/bzip2dll.tar.bz2.
Source has been successfully compiled with a compiler from Windows SDK 7.1.
Visual Studio Express 2005 and above, should be able to compile source too.
To enable very long paths, wcx needs to be compiled as Unicode.
This archive contains only bzip2dll.cpp, wcxhead.h and bzip2dll.rc, so Mr. Ghisler's bzipplug_src.zip is needed.

Cheers
zeeko

[infimum]

+1 for unicode support.

[ND]

I have updated the plugin now...

The plugins page displays version 1.4, although the download is indeed the new 1.5 version.

[ghisler(Author)]

2zeeko
Unfortunately your link gives me a 404 error. Can you send me your upated sources to support at ghisler dot com, please?

[karlchen]

The link erroneously included the dot character which just indicates the end of the sentence.

So the working URL is this one: http://dl.dropbox.com/u/13501688/bzip2dll.tar.bz2.

Note: there is no trailing dot in the link address.

Karl

[ghisler(Author)]

Got it, thanks! Unfortunately it's too different from my own code, so I cannot check (with compare by content) what was changed.

Also my own plugin version 1.4 already supports Unicode and long names, so where are the advantage of your changes?

[zeeko]

I'm sorry that my source can't be compared with original one. So, the major changes:
- ArchiveRec.ArchiveNameW increased from 260 to 1024 WCHARs since other Unicode file name arrays can store 1024 WCHARs
- if path is longer than 260 chars, it is prefixed with "\\.\". Without prefix, plug in can't open or create long path archives
- critical section is initialized and released in DllMain - OK this isn't some of improvement, but here it is
- all access to elements of static ArchiveRec array is guarded with critical section
- usage of "safe" CRT functions - cosmetics

About Unicode, you are right, your plug-in already supports Unicode file names.

wcx doesn't need to be compiled in Unicode configuration (in fact, with my modifications, it can't be compiled as Unicode configuration, but it does support Unicode file names).
In Configuration Properties, "Character set" option should be set to "Not Set" or "Use MultiByte Character Set"). My mistake.

To test long path support, I tried to pack file

e:\src\bzip2\bzip2dll\plugin\
1234567890123456789012345678901234567890123456789L1234567890123456789012345678901234567890123456789C
1234567890123456789012345678901234567890123456789L1234567890123456789012345678901234567890123456789C
12345678901234567890123456789012345678901234567.txt

and got "Cannot open file!" error.

Total path length is 280, file+ext length is 251. Four chars are spared for .bz2 extension, so that packed file+ext+.bz2 length is 255.

With my modifications, plug in can pack and unpack such files with long names.

[ghisler(Author)]

Thanks, I will check why long names do not work.

[zeeko]

I also found that StartMemPackW function is missing.
When I implemented StartMemPackW and put additional line to bzip2dll.def,
TC refused to use it. It always uses StartMemPack.
I checked with fileinfo plug in, newly created wcx exports StartMemPackW.

Updated source can be found at http://dl.dropbox.com/u/13501688/bzip2dll_20101025.tar.bz2
Changes:
- implemented StartMemPackW
- fixed Unicode compilation
- very long path in CanYouHandleThisFileW
- support for very long path for network paths
- fixed potential memory leak in StartMemPack

[ND]

I have updated the plugin now...

The plugins page displays version 1.4, although the download is indeed the new 1.5 version.

The ghisler.com plugins page still lists the plugin as version 1.4.
The page needs to be updated to state the correct version 1.5 (the download link is already set to plugin v1.5).