unpack doesn't preserve (executable) permissions

[dtaskoff]

Bug description
cabal unpack doesn't preserve permissions of executable files.

To Reproduce

$ curl https://hackage.haskell.org/package/hhwloc-0.2.0/hhwloc-0.2.0.tar.gz > hhwloc-0.2.0.tar.gz
$ cabal unpack hhwloc-0.2.0.tar.gz
$ ll hhwloc-0.2.0/hwloc/autogen.sh

shows autogen.sh's permissions to be -rw-r--r--, while

$ curl https://hackage.haskell.org/package/hhwloc-0.2.0/hhwloc-0.2.0.tar.gz > hhwloc-0.2.0.tar.gz
$ tar -xzf hhwloc-0.2.0.tar.gz
$ ll hhwloc-0.2.0/hwloc/autogen.sh

shows them to be -rwxr-xr-x, which are the original permissions.

Expected behavior
Permissions to be preserved.

System information

• macOS, linux
• cabal 3.0.0.0, ghc 8.8.2

Additional context

• this seems like a regression since sdist drops executable permissions for files in the tarball #620 (comment)
• the hackage CI build of my package fails because of this.

[phadej]

See #6454 and #5813. Most likely we'll make sdist create tarballs without executable bits for files, and make unpacking also not set anything executable.

• distributing native binaries is most likely wrong
• and script files can be run with their respective interpreter

I.e. not setting bits on unpacking is by design.

[dtaskoff]

I agree that distributing native binaries is wrong, however, one will not always be able to modify existing scripts.
Anyway, if you decide to go the -x way, it'd be nice if the behaviour is documented somewhere.

[vmchale]

@dtaskoff this is partly due to tar, viz. haskell/tar#25

[hasufell]

* and script files can be run with their respective interpreter

I don't think that's fair, because the shebang might contain additional information and is now ignored.

I.e. not setting bits on unpacking is by design.

It's a bug ;)

[phadej]

sdist creates files without executable bits, so this issue is obsoleted.

[hasufell]

@phadej so how do you figure out which interpreter to use? Eg whether a script is a posix, shell or ksh script? They'll likely have the same extension (or none). Parse the shebang?

[phadej]

Maintainer of package should know which kind of script they are writing. (or python or ruby or ...)

[hasufell]

Maintainer of package should know which kind of script they are writing. (or python or ruby or ...)

Scripts may be "data files" and used by users as well.

[phadej]

Scripts may be "data files" and used by users as well.

In cabal nix-style setup user barely see tarballs. I argue that if "bigger" package is assembled and distributed then cabal sdist and cabal unpack are wrong tools to do it. As far as I see it, Hackage is for Haskell code. Write auxiliary scripts as Haskell executables, and there will be no problems (ok, different problems).

Also it is data-files, not code-files.

Don't speculate. If you have real use-case, it would be helpful. The OP case, users can be advised to call sh .../autogen.sh and IMO it's fair trade-off for the simplicity of implementation in Cabal / cabal-install. For cabal-install the reproducibility of packaging (e.g. on Windows compared to Linux) is more important.

[hasufell]

@phadej so if the tar package is fixed (because it is a bug there), you will adjust the cabal-install code? The current behavior relies on a bug to be present. I suggest cabal-install explicitly removes the executable bits then.

[phadej]

Yes, we should be explicit on unpack too. PR welcome.

[hasufell]

Yes, we should be explicit on unpack too. PR welcome.

Maybe, but then again, we shouldn't use tar at all. It is unmaintained and has major issues: it's easy to break cabal sdist if you know about tar's shortcomings, such as missing long filepath support (or broken unicode support).