Bug#1026976: Upcoming test suite regression due to changes in file/libmagic

[FC Stegerman]

* Christoph Biedl <debian.axhn at manchmal.in-ulm.de> [2022-12-29 16:39]:
> Chris Lamb wrote...
> > However, this "extra data prepended" doesn't fit well under the rubric
> > of "data". Yes, this "#!/usr/bin/python3\n" shebang is definitely
> > "data" of a kind, but a shebang isn't really data in that way given
> > the special-treatment afforded to it by UNIX systems. Even if this
> > noun was replaced by the more general "bytes", the magic nature of the
> > shebang would still remain… as would the desire to discriminate
> > between pyzip files and other ZIP files with prepended data.
> >
> > Could another — different — string be emitted in the case that these
> > prepended bytes are a shebang? We could potentially look for the file
> > starting with #! and for that to take precedence over this new case.
> 
> After some more thinking: I suggest you do nothing for the time being
> while I take this to upstream. If all else fails, I'll revert the change
> for the next upload. By the way, that will be 1:5.44-1, but the changes
> to 1:5.43-3 are minimal.

FWIW I've attached a patch that makes it discriminate between ZIP
files with prepended data with or without a shebang:

  $ file -b zipfile-with-data-prepended
  Zip archive, with extra data prepended
  $ file -b pyzip
  a /usr/bin/python3 script executable (Zip archive)

I'm not sure that completely solves the issue, because there could be
other (executable) file formats affected, not just pyzip and other
formats using a shebang.  So perhaps reverting the change completely
is better after all.  We probably need upstream to figure that out.

- FC
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pyzip.patch
Type: text/x-diff
Size: 805 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20221231/67938b6c/attachment.patch>