OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office] RE: Directories in Zip packages


Hi all

I've just been working through the helloworld.odt file with emacs (in
hexl-mode) with the appnote alongside.  Primitive I know, but anyway
..

My take on what I am seeing is that it *should* be obvious what to
sign and what not to sign by looking at the "uncompressed size" field
of each local file header - one hopes if uncompressed size=0 then
compressed size will also equal zero.  This at least is the case of
the file I am looking at.  And I believe the signature references are
references to the content of streams.

So one (fairly low level algorithm) would be to iterate through all
the local file headers and provide a signature reference to all those
with uncompressed size>0 ie. which actually have file data sections to
sign.

The implication of this would be that empty files and directory
entries could be removed from (or added to) the zip archive without
breaking the signature.  I would have to think some more on how bad
this might be but I suspect that its not altogether good (I'm having
visions of injecting 1000's of circular directory references).  ODF
producers do not use winzip, pkzip or 7zip to create the packages so
in general there should be fine grained control over which entries go
into the zip.  Is it too much to recommend that ODF producers *should
not* add entries for empty directories and empty files.  I might be
wrong, but I suspect an odf consumer does not use such entries for any
purpose whatsoever in which case they are better not to be there.  I
am fairly confident this is the case for directory entries - not 100%
sure about 0 length files.

Regards
Bob

On 27 September 2010 01:30, Dennis E. Hamilton <dennis.hamilton@acm.org> wrote:
> The problem of course is that the directory case is not defined in the APPNOTE at all, and presumably having file directories is a version 2.0 feature, and that is not specified in the version needed to extract, unless we can presume that is latent in the defaulting to MS-DOS/OS-2 whatnot.  Why would we require knowledge of a specific platform file-system convention in order to make cross-platform, interoperable ODF packages.  Does that mean we are limited to valid path and file names from the MS-DOS/OS-2 systems?
>
> I find this ridiculous.
>
> One more thing:
>
> I did also take a look using another machine that did not (and never will) have PKZip installed.
>
> You'll recall that WinZip did not display anything that was not actually a file, but it did say that "Configurations2\images\Bitmaps\" was OK when I tested the .odt as a Zip.  Also, 7-zip recognized it as a directory and PKZip showed Bitmaps as a folder.
>
> Well, when I rename helloworld-signature.odt to helloworld-signature.zip, and then I drill down into it using Windows Explorer (not WinZip and on a machine where PKZip has not been installed), I get Bitmaps as an 0-length file of unknown association.  (See the attached PNG image.)
>
> Here's that puppy in the main sequence of Zip entries:
>
> 0000 1520                             50 4b 03 04 0a 00 00            PK♥♦...
> 0000 1530 00 00 00 35 86 38 3d 00  00 00 00 00 00 00 00 00   ...5å8=.........
> 0000 1540 00 00 00 1f 00 00 00 43  6f 6e 66 69 67 75 72 61   ...▼...Configura
> 0000 1550 74 69 6f 6e 73 32 2f 69  6d 61 67 65 73 2f 42 69   tions2/images/Bi
> 0000 1560 74 6d 61 70 73 2f                                  tmaps/
>
> which does not seem any different than anything else, and here is the central directory entry:
>
> 0000 56a0             50 4b 01 02  0a 00 0a 00 00 00 00 00       PK☺☻........
> 0000 56b0 35 86 38 3d 00 00 00 00  00 00 00 00 00 00 00 00   5å8=............
> 0000 56c0 1f 00 00 00 00 00 00 00  00 00 00 00 00 00 29 15   ▼.............)§
> 0000 56d0 00 00 43 6f 6e 66 69 67  75 72 61 74 69 6f 6e 73   ..Configurations
> 0000 56e0 32 2f 69 6d 61 67 65 73  2f 42 69 74 6d 61 70 73   2/images/Bitmaps
> 0000 56f0 2f                                                 /
>
> I see nothing here that would account for that except for a bug in how the shell decides not to make folders when there are no contents (notice in the image that Windows does not recognize the other empty folder entries, but this one seems to have confused things, maybe by being one "/" too far).
>
>
>  - Dennis
>
> I am really annoyed that PKZip stole the Zip association from Windows and the uninstall simply left there being no Zip association at all.  I will have to do a blankety-blank system restore to get it back.  Oh, goody.
> -----Original Message-----
> From: Hanssens Bart [mailto:Bart.Hanssens@fedict.be]
> Sent: Sunday, September 26, 2010 16:46
> To: dennis.hamilton@acm.org; 'David LeBlanc'; office@lists.oasis-open.org
> Cc: Cornelis Frank
> Subject: RE: [office] RE: Directories in Zip packages
>
> Dennis,
>
>>2. There is no reason that ODF 1.2 ever needs such things in a package,
>>since the manifest is independent of that stuff.
>
> Well, perhaps no "need", but if it's allowed...it can be in there...
>
>>3. It is not possible to sign a directory/folder entry in the Zip because
>>there is nothing to sign.
>
> Actually, the same goes for the 0-size file, even an empty file can be signed :-)
>
>
>> There is no data in such an entry and there should be no way to insert data
>> in such an entry without it being a file instead of a folder
>
> It is possible to craft a zip like that, although trying to unzip this could fail.
> But who knows, perhaps some strange bug could be exploited because it is
> not expected behavior.
>
>
>>Oddly enough, the 0-length file Configurations2\accelerator\current.xml
>>*has* data, and it is compressed, but the uncompressed size is 0.  Fancy
>>that.
>
> Since the storage method is deflate, not stored, it could perhaps be some
> deflate header ?
>
> Bart
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]