[
https://issues.apache.org/jira/browse/MASSEMBLY-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17633393#comment-17633393
]
Christopher Tubbs commented on MASSEMBLY-941:
---------------------------------------------
I still don't understand how this is a problem.
Your local machine probably shouldn't default to granting write permission to
other members of your group, but let's assume you have a good reason to do that.
git ignores group permissions entirely when it stores file information. It only
stores 644 and 755, from what I understand. So if you build a project with
files that have other group/other permissions, then check those into git,
whoever checks out the same commit and rebuilds, isn't going to see the same
result. I think this is a useful behavior to mimic with the assembly plugin. It
should only set 644 or 755, unless explicitly overridden with a specific mode
in the descriptor.
But, I'm also having a hard time understanding how to reproduce this problem.
Where are the permissions modes getting mangled? Is it during the archive?
Wouldn't it be during the extraction of the archive? If it's during the
extraction, you can use {{-p, --preserve-permissions, --same-permissions}} to
preserve the mode in the archive when you use {{tar}} to extract, and then your
umask settings shouldn't have an impact. If the umask in your local environment
or in the CI environment, is causing problems with the reproducibility tests, I
would suggest that the problem is buggy tests that don't take into account the
umask during extract... it's not a problem with the behavior of the plugin for
reproducibility.
As for the Windows case... I'm not sure how to address that... it really
depends on the filesystem. As I understand it, NTFS and FAT don't really
support POSIX file modes to begin with.
Regarding the suggestion [~hboutemy] made above, I do not think it is a good
idea to force the group POSIX permissions from the user permissions. That would
grant the group write permission on the user's files and directories by
default. That's a bad idea, and there's a reason why most *nix systems have a
default umask of at least 0022, and not something like 0002 or 0000. If
anything, the default group could be forced from the "other" permissions, so
you only get 644 and 755 in the end.
> 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 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)
