Can't build projects if user ID or group ID is a big number
Description
Environment
Activity
Ian YoungJuly 12, 2023 at 3:10 PM
That seems to get us to the point where the projects I have been smoke-testing now build correctly, and all their output distributions are confirmed to have 1000:1000 as ownership of files within the generated .tar.gz archives regardless of the current user.
I will note that I haven’t tweaked the jetty-base project; as far as I can tell it’s only ever built by jenkins:jenkins and although it’s weird to see that in the .tar.gz pulled into .m2 by the testbed, it’s not harmful and I don’t really want to spray changes onto all the many branches of that repo if I don’t have to.
There will undoubtedly be other related tweaks as we go forward (for example, if I add more repos to my smoke testing environment) but for now I’m going to declare victory.
Ian YoungJuly 12, 2023 at 1:20 PM
Cherry-picked to maintenance branch:
java-identity-provider
java-idp-oidc
java-idp-plugin-duo (same two sites)
java-idp-plugin-scripting (two sites from main branch, plus another which is no longer present)
java-oidc-common
java-plugin-storage-jdbc
java-parent-project
xmlsectool
Added to both branches of java-idp-plugin-totp at the same time by moving the branch forward.
Ian YoungJuly 12, 2023 at 8:26 AM
Changed main branches:
java-identity-provider
java-idp-oidc
java-idp-plugin-duo (two sites)
java-idp-plugin-scripting (two sites)
java-oidc-common
java-plugin-storage-jdbc
This gets my Java 17 smoke test environment working, for now. I will need to iterate as more of the plugins are moved across to the Java 17 stack, and in any case I need to apply these changes to the maintenance branches to get the Java 11 environment building.
Ian YoungJuly 12, 2023 at 8:19 AM
Changed the main branch of xmlsectool, although it won’t do anything at present as that project currently only builds a .zip and not the problematic .tar.gz distribution. That may well change, though, so it’s worth making sure being consistent.
Ian YoungJuly 12, 2023 at 8:15 AM
Added to the parent POM’s release profile on the main branch, but then removed that assembly configuration entirely as part of https://shibboleth.atlassian.net/browse/JPAR-195. Performed the same removal on the copy of the release profile that is now part of the Maven signature enforcer project’s private parent.
This appears to affect any project which packages as a
.tar.gz. I’m filing it in JPAR to start the discussion.Maven’s assembly plugin uses
tarto package, and that in turn puts each file’s current uid and gid into the archive. This doesn’t seem like a good idea to me to start with, as it implies that you will get different output files depending on who builds the product, or for that matter which machine they build on, depending on for example whether their user was the first created on a machine.It’s worse if you build in a context like an IDM directory with ID ranges outside the “little integers” range normally associated with local users. For example:
[root@r9c ~]# id iay uid=1051000015(iay) gid=1051000015(iay) groups=1051000015(iay)In this case, the build will reliably fail because that number is bigger than
0x1FFFFF.One way to work round this would be to change from
<tarLongFileMode>gnu</tarLongFileMode>in the assembly configuration to<tarLongFileMode>posix</tarLongFileMode>.It would be ideal if there was a way to force, say,
1000:1000for every file regardless of their ownership on the source filesystem, but I don’t see any evidence that’s possible.See: https://stackoverflow.com/questions/33819438/maven-assembly-plugin-group-id-1377585961-is-too-big-error/ , https://issues.apache.org/jira/browse/MASSEMBLY-728