elharo commented on issue #539: URL: https://github.com/apache/maven-war-plugin/issues/539#issuecomment-5070722141
The target permission should be `644` (`rw-r--r--`). Using `600` (`rw-------`) is too restrictive. In many production environments, the user that deploys or expands the WAR file is not the same user that runs the application server process (e.g., a `deploy` user unpacks the file, but the `tomcat` or `jetty` user runs the server). If the permissions are `600`, the application server will be denied read access to its own dependency JARs, causing `ClassNotFoundException` errors at runtime. `644` ensures the owner can write to the file while the runtime process can read it. Regarding copying the existing permissions: Yes, the underlying copy mechanisms (like `java.nio.file.Files.copy` or Maven's Plexus `FileUtils`) can preserve POSIX file attributes. However, **we absolutely should not do this** for two reasons: 1. **It reproduces the bug:** The core issue in MWAR-471 is that the source file system (WSL) is lying about the permissions and presenting them as `755`. If you copy the existing permissions, you carry that bad data directly into the WAR file. 2. **It breaks reproducible builds:** A major goal of modern Maven plugins is deterministic output. If a WAR is built on a standard Linux machine where the local repository has `644` permissions, and then built on a WSL machine where the local repository has `755` permissions, preserving local attributes will result in WAR files with different cryptographic hashes. To ensure stability and bit-for-bit reproducible builds, the plugin should actively discard the local file system's permissions and force normalization to `644` for all data files packaged into the archive. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
