OF-2877 Reproducible builds

[stokito]

Pin the build timestamp and disable Built-By, Created-By and Build-Jdk-Spec fields from generated manifest. The Maven JAR plugin is updated to latest version that has the new option addDefaultEntries

https://igniterealtime.atlassian.net/browse/OF-2877

[stokito]

Note: I also changed the plugins parent pom so plugins jars also should have the manifest without generated fields.

[guusdk]

Can/should we modify the static dates that are introduced in this PR with one that is more tied to the state of the code, like the date of the last commit, or something?

Some of these changes are likely going to confuse future developers ("This date shouldn't be static! Lets make it a variable!"). Can you please add a reference to OF-2877 in the comments that you've already added. That will help people find more of the background of this change.

[stokito]

yes, we can use the git commit date https://maven.apache.org/guides/mini/guide-reproducible-builds.html#faq
It looks like we already have the git-commit-id-plugin but with a different group id pl.project13.maven.

The timestamp is used inside of the JAR as mtime for entries. It looks like it doesn't really used elsewhere and not shown to a user. We may change to 1/1/1970 to make it for anyone to not worried to update it. The comment should be enough.

Also later I noticed that the xmppserver.jar is actually not stable. It contains the Admin Console with JSP files that may (almost) randomly compiled differently. Disassembly show that it may use or not use the early return in generated methods.
Still, now it's much easier to detect such a change. As a partial solution we may extract the admin console to a separate jar (war?). This may be good idea for someone who actually aren't interested in the Admin Console.
I'll back to this on the weekend.

[stokito]

I don't think it's a good idea to use a git tag as a build timestamp. It's not only over complication but also may make comparing artifacts of different versions harder.
The build timestamp itself may be confusing but the comment and the git blame should be enough.
But generally speaking this can be solved by introducing a special constant and I proposed this to Maven https://issues.apache.org/jira/browse/MJAR-314
Meanwhile I changed the timestamp to 1 Feb 1980 because this will be the default value in future.

Here remains one problem with CSS and images assets of the Web Admin Console. The browser uses If-Modified-Since header for caching and remembers the Last-Updated header which is taken from the mtime of a JAR. So users have to re-upload all assets.

It's not a big deal because the Admin Console is not a highly loaded server but only one-two users occasionally will open its web page.
But this may be a problem with some other plugins like Converse or maybe something else.

[stokito]

Once you'll have a minute please review the PR. I commented in the Jira
https://igniterealtime.atlassian.net/browse/OF-2877?focusedCommentId=23127

[Fishbowler]

Whilst I don't quite understand the end goal beyond what's stated on the Reproducible Builds website, I similarly have no objections to moving in that direction, assuming we're not making unreasonable compromises for other users' needs along the way.

[stokito]

The change will make it easier to find exploits in the distribution files. Nice thing to have but not critical.