[File] Regression in Chrome extension detection

[Christoph Biedl]

Hi there,

the logic in the second hunk of

| commit c2ef6d0e6226d10621e9e67999dd2c3ee35d79a0 (HEAD, refs/bisect/bad)
| Author: Christos Zoulas <christos at zoulas.com>
| Date:   Tue Apr 9 18:34:15 2019 +0000
|
|     PR/73: enkeli: Require the actual central directory record, not just the
|     end of central directory for zip.
|
| @@ -53,7 +53,7 @@
|  >>0    leshort         x               v?[%#x]
|
|  # Zip End Of Central Directory record
| --22    string          PK\005\006      Zip archive data
| +-22    string          PK\005\006
|  #>4    leshort         >1              \b, %d disks
|  #>6    leshort         >1              \b, central directory disk %d
|  #>8    leshort         >1              \b, %d central directories on this disk

is not clear to me.

As a result, this block now is

| # Zip End Of Central Directory record
| -22           string          PK\005\006
| >(16.l)       use             zipcd
| >20           pstring/l       >0              \b, %s

So if the first line matches, it file will happily print any
non-empty ASCIIZ string starting at offset 20.

To make things worse, this change introduces a new strength line

| Strength =  71 at 63: , %s []

which defeats several other and betters rules. That's why for example
the detection of Chrome extensions is now broken:

-Google Chrome extension, version 2
+, \206H\206\367\015\001\001\001\005

Care to take a look?

    Christoph