[ https://issues.apache.org/jira/browse/MASSEMBLY-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17618677#comment-17618677 ]
Herve Boutemy commented on MASSEMBLY-941: ----------------------------------------- [~ctubbsii] umask issue is the following: particularly on group permissions, the effective value depends on the user configuration more than explanations, here is an example with a Gradle build (because this issue is the same whatever the build tool): https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/org/mockito/mockito-core/mockito-core-4.5.1.diffoscope and https://github.com/mockito/mockito/pull/2642 this puts a prerequisite on the environment to rebuild I probably did too much by simply not checking any on-disk permission: now I see that perhaps using owner permissions for group could match the intent another aspect: if you only build on Unix, you probably do not care, but if you accept that people may build on Windows (= what we do on Maven), permissions extracted from Windows build probably don't match at all permissions taken from Unix > 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 > Priority: Critical > > 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)