[
https://issues.apache.org/jira/browse/MASSEMBLY-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17693029#comment-17693029
]
Herve Boutemy commented on MASSEMBLY-941:
-----------------------------------------
{quote}Or just, encouraging more standard use of 0022 for everybody.{quote}
it's funny how this new 0022 is called "more standard", when until 2022, 002
was the norm everywhere: 002 would be what I'd call the "more standard", and
eventually 0022 could be called "better standard" by people now engaged into
securing more aggressively
The fact is that some tests done by one Maven dev using his machines upgraded
from Fedora 36 to Fedora 37 already shows failing reproducible IT for
maven-assembly-plugin, associated to the switch from Fedora from classical 002
to new 022 that seems to be partially applied (and sometimes, the results looks
more randomly applied than only partially)
While I perfectly understand why people wanted this issue to be solved, to
respect filesystem permissions, I fear what I'll see in terms of reproducible
builds for people using these new setups... But that's life, I hope that after
the hard time we have during the default umask change in the market, we'll get
something reasonably reproducible in the future
> 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: 3.5.0
>
>
> 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)
