GNU bug report logs - #10338
23.3; Firefox includes a jar file which is not recognied as a zip file (omni.jar)

Previous Next

Full log

Message #8 received at 10338 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: "Brooks\, Daniel" <Daniel.Brooks <at> ask.com>
Cc: 10338 <at> debbugs.gnu.org
Subject: Re: bug#10338: 23.3;
	Firefox includes a jar file which is not recognied as a zip file
	(omni.jar)
Date: Thu, 22 Dec 2011 22:02:20 +0200

> They've optimized for read performance by rearranging the sections of
> the file (and the files inside the archive). As a result the magic is
> slightly different and Emacs doesn't recognize the file, even though the
> zip/unzip tools the user has may be well able to handle it.

Here is what the author of InfoZip says about this non-standard jar format
in https://bugzilla.mozilla.org/show_bug.cgi?id=605524#c11 :

  - Fifth, the first 10 bytes of this archive are (in hex):
           b8    b6    14    00    50    4b    01    02    17    0b
                                   P     K     1     2

  The P K 1 2 is the first Central Directory signature.  The 4 bytes
  before that appear to be some index.  Using little endian math, this
  ends up being 1357496, which happens to be the offset to local record
  #210, a .png file.  Not sure if this is what it is or why this is
  useful.  However, if everyone starts tucking their own bytes into the
  .zip structure without using the established procedures for doing that,
  I think it's asking for chaos.  The standard allows leading bytes, but
  usually the EOCDR can point a utility to the beginning of the real
  archive data, but in this case the EOCDR is buried where no one can find
  it without scanning the archive.

For testing purposes such jar files can be produced with the following utility:

  http://hg.mozilla.org/mozilla-central/raw-file/default/config/optimizejars.py

> === modified file 'lisp/arc-mode.el'
> --- lisp/arc-mode.el    2011-12-15 07:24:10 +0000
> +++ lisp/arc-mode.el    2011-12-20 22:32:35 +0000
> @@ -748,6 +748,7 @@
>    ;; as an archive by other software.
>    (let (case-fold-search)
>      (cond ((looking-at "\\(PK00\\)?[P]K\003\004") 'zip)
> +          ((looking-at "....PK\001\002") 'zip)
>           ((looking-at "..-l[hz][0-9ds]-") 'lzh)
>           ((looking-at "....................[\334]\247\304\375") 'zoo)
>           ((and (looking-at "\C-z")     ; signature too simple, IMHO
>
> I'm including a patch to 24.0.50, which I just checked out. I haven't
> been using it on this machine.

Thanks, your patch makes reading of non-standard jar files more permissive.

There are two other places with the regexps for ZIP headers in
`magic-fallback-mode-alist' and `auto-coding-regexp-alist'
intended to read ZIP archives with non-standard filename extensions.
Without adding "....PK\001\002" to them too, you won't able to open the
"omni.ja" file (another non-standard filename extension from Mozilla).
But perhaps this is not necessary - it would be too much to allow
reading of files with both non-standard filename extensions and
non-standard headers at the same time.

More important problem is that most archivers don't understand this
format, so after opening such files, extra lines are inserted into the
file buffer:

  warning [/tmp/omni.jar]:  6552040 extra bytes at beginning or within zipfile
    (attempting to process anyway)
  error [/tmp/omni.jar]:  reported length of central directory is
    -6552040 bytes too long (Atari STZip zipfile?  J.H.Holm ZIPSPLIT 1.1
    zipfile?).  Compensating...

It seems this problem prompted the bug#10347.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.