For reference, how I found it, I built the tag locally then went to ~/.m2/org/apache/camel folder and call: md5sum **/4.14.3/* > checklist.chk Then I searched in the file for 07070. After findig the file, I double-checked with the correspondig md5 file in the staging repository which contains effectively the same md5.
I found no way to download the full staging repository. i failed to use various options of -DcreateChecksum=true (removed with Maven 3+) or some specific md5 maven plugin to genrate md5. ________________________________ From: Aurelien Pupier <[email protected]> Sent: Tuesday, December 16, 2025 2:19 PM To: [email protected] <[email protected]> Subject: Re: [EXTERNAL] Re: Problem closing staging repository Hi, It seems to be the camel-jbang-main.pom which is causing the false positive. it is the only one which has a checksum which is starting with 07070. More precisely: 070702d0bfee415543562bceb0a5d862 camel-jbang-main/4.14.3/camel-jbang-main-4.14.3.pom So modifying the camel jbang main pom and rebuild, should do the trick regards, ________________________________ From: Aurélien Pupier <[email protected]> Sent: Tuesday, December 16, 2025 1:14 PM To: [email protected] <[email protected]> Subject: [EXTERNAL] Re: Problem closing staging repository Hello, On Tue, Dec 16, 2025 at 10:06 AM Claus Ibsen <[email protected]> wrote: > Hi > > 1) > Is this only for camel-core project, and not camel-spring-boot? > > 2) > I wonder if we have similar problem on main branch if we attempt to release > it as 4.17.0 ? > > 3) > I wonder if we redo a 4.14.3 with latest code from camel-4.14.x branch (new > code since current attempt) does it work then? > > 4) > I guess we don't know which file sonartype complains about, and as such its > not easy to find out. There is no additional logging? > In a previous message, it was mentioning a way to find it which is to go through all MD5 files and search for a specific pattern at the beginning of the file. Can you point me to the nexus repository causing problem, i can try to download it and then try to search in it. or the way to generate the MD5 with build locally? > > 5) > Are there other ASF projects that releases without MD5 hashes? (see my > other mail thread). > IMHO those are outdated today, and we should consider dropping them and > jump from SHA1 to SHA256. > But finding other ASF projects releasing that way would be good to see its > already done, and this can help us analyze what we can do to upgrade. > Maybe this is better for newer releases like 4.17 or later. But if all > above fails and this is the only way to do 4.14.3 release then we can try > this. > > 6) > Any other ideas? > > > > On Mon, Dec 15, 2025 at 5:23 PM Gregor Zurowski <[email protected]> > wrote: > > > Hi Everyone: > > > > I wasn't able to resolve this. Therefore, I have created the following > > ticket for the INFRA team: > > https://issues.apache.org/jira/browse/INFRA-27498 . > > > > Thanks, > > Gregor > > > > On Thu, Dec 11, 2025 at 10:33 PM Claus Ibsen <[email protected]> > > wrote: > > > > > > Hi > > > > > > And here is another Grok AI reply (think harder mode) > > > https://grok.com/share/c2hhcmQtNQ_2c900d4c-f6e5-401a-9162-d526ac50c514 > > > > > > > > > > > > The error you're encountering during the staging repository closure is > > due > > > to Nexus's security validation rule > > ("no-traversal-paths-in-archive-file") > > > misidentifying one of your uploaded MD5 checksum files (e.g., something > > > like `artifact-name.pom.md5` or `artifact-name.jar.md5`) as a > compressed > > > archive file (specifically, a cpio format archive). This happens > because > > > the content of that particular MD5 file starts with a string like > > "070701" > > > or "070702", which matches the magic number for cpio archives. > > > > > > When Nexus attempts to inspect it as an archive to check for insecure > > paths > > > (e.g., path traversal vulnerabilities), the parsing fails because it's > > not > > > actually an archive—it's just a text file containing a hash and > filename. > > > This leads to the WalkerException and the nested > IllegalArgumentException > > > about the "unknown mode," as the random bytes in the file don't conform > > to > > > a valid cpio header structure (e.g., the mode field is interpreted as > > > invalid hex like "5543562b"). > > > > > > ### How to Identify the Problematic File > > > - Log in to your Sonatype Nexus OSSRH account and view the contents of > > the > > > staging repository (`orgapachecamel-1911`). > > > - Download all the .md5 files. > > > - Open them in a text editor or hex viewer and check which one starts > > with > > > "07070..." (e.g., "070702xxxxxxxx filename"). > > > > > > ### Solutions > > > - **Short-term workaround:** Slightly modify the artifact associated > with > > > the problematic .md5 file (e.g., add a space in a comment or update a > > > non-functional part of the POM) to regenerate a new hash that doesn't > > start > > > with the conflicting magic number. Then, redeploy to a new staging > > > repository. > > > - **Alternative:** Bump the version number of the affected artifact > > (e.g., > > > from x.y.z to x.y.z+1) and redeploy. This will change the hash and > avoid > > > the issue. > > > - **Long-term recommendation:** Consider generating and uploading > > stronger > > > checksums like SHA-256 (.sha256 files) alongside or instead of > MD5/SHA1, > > as > > > longer hashes reduce the chance of magic number collisions. Update your > > > Maven build configuration to include this (e.g., via the > > > `maven-assembly-plugin` or `maven-deploy-plugin`). Sonatype supports > > > SHA-256, and it may help avoid similar edge cases in the future. > > > - If this persists across versions or you can't modify the artifacts, > > > contact Sonatype support via their OSSRH Jira (issues.sonatype.org) > and > > > provide the staging repo ID and error logs for assistance—they may be > > able > > > to override or investigate server-side. > > > > > > This is a known edge case in Nexus (versions around 2.x and 3.x), > > stemming > > > from content-based file type detection prioritizing magic numbers over > > file > > > extensions in some scenarios. > > > > > > On Thu, Dec 11, 2025 at 10:09 PM Gregor Zurowski < > > [email protected]> > > > wrote: > > > > > > > Hi Everyone: > > > > > > > > I have built the Camel 4.14.3 release candidate, but I am getting the > > > > following error when attempting to close the staging repository in > > > > Nexus: > > > > > > > > ``` > > > > Event: Failed: Archives must not contain insecure paths > > > > > > > > typeId no-traversal-paths-in-archive-file > > > > failureMessage Rule evaluation unexpectedly failed: > > > > org.sonatype.nexus.proxy.walker.WalkerException: Aborted walking on > > > > repository ID='orgapachecamel-1911' from path='/'. > > > > x.x.causedBy.1 java.lang.IllegalArgumentException: Unknown mode. > Full: > > > > 5543562b Masked: 5000 > > > > x.x.causedBy.0 org.sonatype.nexus.proxy.walker.WalkerException: > > > > Aborted walking on repository ID='orgapachecamel-1911' from path='/'. > > > > ``` > > > > > > > > Any ideas what might be causing this? > > > > > > > > Thanks in advance, > > > > Gregor > > > > > > > > > > > > > -- > > > Claus Ibsen > > > > > -- > Claus Ibsen > Unless otherwise stated above: Compagnie IBM France Siège Social : 17, avenue de l'Europe, 92275 Bois-Colombes Cedex RCS Nanterre 552 118 465 Forme Sociale : S.A.S. Capital Social : 664 614 175,50 € SIRET : 552 118 465 03644 - Code NAF 6203Z
