[
https://issues.apache.org/jira/browse/MASSEMBLY-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17684479#comment-17684479
]
Christopher Tubbs commented on MASSEMBLY-941:
---------------------------------------------
{quote}
FYI, here is an example of different build results: by default, my local env
has umask 002, but reference build was done with umask 022 => I had to add the
umask requirement to rebuild with success the affected artifact
https://github.com/jvm-repo-rebuild/reproducible-central/commit/626485c96d069fea2107a8162e8f388b358ebb67
{quote}
Thanks for the link, and the explanation. I think that helps clarify a lot of
the questions I had about how users might be impacted by this. In my mind, I
was thinking it would only matter if unpacking a source tarball (which could be
set to preserve permissions and ignore umask), but your example shows that
another use case is checking out a git branch with umask set. Unfortunately,
git doesn't have an option to ignore umask and use the permissions stored in
the repository. Besides that, it only stores either 644 or 755 and can't
express anything else either.
Many users have suggested workarounds for git at
https://stackoverflow.com/questions/11574271/git-change-default-umask-when-update-file
As for Windows, I don't even know how one deals with filesystems that can't
understand executable flags... that's just so foreign to me. I don't think
there's any good solution for Windows. I think you did the best you could for
that... I think if projects needs to use Windows, they really need to configure
the assembly descriptor with permissions for each file, explicitly.
{quote}
once this new maven-assembly-plugin will be released, such cases will happen
more often: I had hoped to avoid this rebuild env prerequisite...
{quote}
Unfortunately, it doesn't seem to be avoidable. But, maybe pointing users to
some of the suggestions on the StackOverflow link above for git users might
help. Or just, encouraging more standard use of {{0022}} for everybody. I can't
imagine too many cases where {{0002}} is preferable.
> file permissions removed during assembly:single since 3.2.0
> -----------------------------------------------------------
>
> Key: MASSEMBLY-941
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-941
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: permissions
> Affects Versions: 3.2.0, 3.3.0
> Reporter: Christopher Tubbs
> Assignee: Herve Boutemy
> Priority: Critical
> Fix For: next-release
>
>
> Since MASSEMBLY-921 in 3.2.0, existing file permissions seem to be ignored
> when creating a tarball assembly, and files stored in the assembly do not
> have their original file permissions preserved.
> Using version 3.1.1 of this plugin and earlier, when creating a tar.gz,
> existing file permissions are normally preserved. This is now broken in
> 3.2.0, unless the component descriptor explicitly sets the fileModes.
> This was discovered trying to prepare a release candidate for Apache Accumulo
> using the apache-23.pom parent POM's predefined `source-release-tar`
> descriptor using the `single` goal. We noticed that the resulting
> source-release tarball had stripped all the executable permissions from our
> scripts, instead of preserving them. This makes the resulting source release
> more difficult to build from source.
> A source-release assembly, and any other assembly that does not specify the
> file permissions explicitly, should preserve the existing file permissions,
> just as it used to with 3.1.1 and earlier.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
