You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@camel.apache.org by Gregor Zurowski <gr...@list.zurowski.org> on 2025/12/11 21:08:39 UTC

Problem closing staging repository

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

Re: Problem closing staging repository

Posted by Claus Ibsen <cl...@gmail.com>.

Hi

I have not heard or seen this before.

A google search found this problem by others
https://github.com/sonatype/nexus-public/issues/378

Look at their solution ????



On Thu, Dec 11, 2025 at 10:09 PM Gregor Zurowski <gr...@list.zurowski.org>
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

Re: Problem closing staging repository

Posted by Gregor Zurowski <gr...@list.zurowski.org>.

This is great detective work. Thank you so much for looking into this Aurelien!

I'll pick up from here late Saturday or early Sunday.

Thanks,
Gregor

On Tue, Dec 16, 2025 at 3:07 PM Aurelien Pupier via dev
<de...@camel.apache.org> wrote:
>
> @Gregor
> I pushed a commit<https://github.com/apache/camel/commit/b5060ccf49380f7e1f4d71f30b841fd0673dcb9d> to the camel-4.14.3<https://github.com/apache/camel/tree/release/4.14.3> branch which will avoid the false positive from the scanner.
> You can rebuild and push another staging repository based on this build when you have time.
> ________________________________
> From: Aurelien Pupier via dev <de...@camel.apache.org>
> Sent: Tuesday, December 16, 2025 2:36 PM
> To: Claus Ibsen <cl...@gmail.com>; dev@camel.apache.org <de...@camel.apache.org>
> Cc: Aurelien Pupier <ap...@ibm.com>
> Subject: [EXTERNAL] RE: Problem closing staging repository
>
> I'm realizing that given that the version is part of the pom, it means that when we will move to a different version, it will change the md5 anyway so we won't need the specific change
>
> ________________________________
> From: Claus Ibsen <cl...@gmail.com>
> Sent: Tuesday, December 16, 2025 2:31 PM
> To: dev@camel.apache.org <de...@camel.apache.org>
> Cc: Aurelien Pupier <ap...@ibm.com>
> Subject: [EXTERNAL] Re: Problem closing staging repository
>
> Hi Aurelien Thanks a lot for the help. So lets update this pom file, such as adding some <!-- blah blah blah --> or something. And if we need to rebuild the release, then Gregor maybe then include the newer commits so we get the stuff
>
> Hi Aurelien
>
> Thanks a lot for the help.
>
> So lets update this pom file, such as adding some <!-- blah blah blah --> or something.
>
> And if we need to rebuild the release, then Gregor maybe then include the newer commits so we get the stuff that included that is for 4.14.4 as well.
>
>
> On Tue, Dec 16, 2025 at 2:19 PM Aurelien Pupier via dev <de...@camel.apache.org>> wrote:
> 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 <ap...@redhat.com>>
> Sent: Tuesday, December 16, 2025 1:14 PM
> To: dev@camel.apache.org<ma...@camel.apache.org> <de...@camel.apache.org>>
> Subject: [EXTERNAL] Re: Problem closing staging repository
>
> Hello,
>
> On Tue, Dec 16, 2025 at 10:06 AM Claus Ibsen <cl...@gmail.com>> 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 <gr...@list.zurowski.org>>
> > 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  <https://issues.apache.org/jira/browse/INFRA-27498   >  .
> > >
> > > Thanks,
> > > Gregor
> > >
> > > On Thu, Dec 11, 2025 at 10:33 PM Claus Ibsen <cl...@gmail.com>>
> > > wrote:
> > > >
> > > > Hi
> > > >
> > > > And here is another Grok AI reply (think harder mode)
> > > > https://grok.com/share/c2hhcmQtNQ_2c900d4c-f6e5-401a-9162-d526ac50c514  <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<http://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 <
> > > gregor@list.zurowski.org<ma...@list.zurowski.org>>
> > > > 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
>
>
> --
> 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
>
> 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

RE: Problem closing staging repository

Posted by Aurelien Pupier via dev <de...@camel.apache.org>.

@Gregor
I pushed a commit<https://github.com/apache/camel/commit/b5060ccf49380f7e1f4d71f30b841fd0673dcb9d> to the camel-4.14.3<https://github.com/apache/camel/tree/release/4.14.3> branch which will avoid the false positive from the scanner.
You can rebuild and push another staging repository based on this build when you have time.
________________________________
From: Aurelien Pupier via dev <de...@camel.apache.org>
Sent: Tuesday, December 16, 2025 2:36 PM
To: Claus Ibsen <cl...@gmail.com>; dev@camel.apache.org <de...@camel.apache.org>
Cc: Aurelien Pupier <ap...@ibm.com>
Subject: [EXTERNAL] RE: Problem closing staging repository

I'm realizing that given that the version is part of the pom, it means that when we will move to a different version, it will change the md5 anyway so we won't need the specific change

________________________________
From: Claus Ibsen <cl...@gmail.com>
Sent: Tuesday, December 16, 2025 2:31 PM
To: dev@camel.apache.org <de...@camel.apache.org>
Cc: Aurelien Pupier <ap...@ibm.com>
Subject: [EXTERNAL] Re: Problem closing staging repository

Hi Aurelien Thanks a lot for the help. So lets update this pom file, such as adding some <!-- blah blah blah --> or something. And if we need to rebuild the release, then Gregor maybe then include the newer commits so we get the stuff

Hi Aurelien

Thanks a lot for the help.

So lets update this pom file, such as adding some <!-- blah blah blah --> or something.

And if we need to rebuild the release, then Gregor maybe then include the newer commits so we get the stuff that included that is for 4.14.4 as well.


On Tue, Dec 16, 2025 at 2:19 PM Aurelien Pupier via dev <de...@camel.apache.org>> wrote:
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 <ap...@redhat.com>>
Sent: Tuesday, December 16, 2025 1:14 PM
To: dev@camel.apache.org<ma...@camel.apache.org> <de...@camel.apache.org>>
Subject: [EXTERNAL] Re: Problem closing staging repository

Hello,

On Tue, Dec 16, 2025 at 10:06 AM Claus Ibsen <cl...@gmail.com>> 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 <gr...@list.zurowski.org>>
> 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  <https://issues.apache.org/jira/browse/INFRA-27498   >  .
> >
> > Thanks,
> > Gregor
> >
> > On Thu, Dec 11, 2025 at 10:33 PM Claus Ibsen <cl...@gmail.com>>
> > wrote:
> > >
> > > Hi
> > >
> > > And here is another Grok AI reply (think harder mode)
> > > https://grok.com/share/c2hhcmQtNQ_2c900d4c-f6e5-401a-9162-d526ac50c514  <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<http://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 <
> > gregor@list.zurowski.org<ma...@list.zurowski.org>>
> > > 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


--
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

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

RE: Problem closing staging repository

Posted by Aurelien Pupier via dev <de...@camel.apache.org>.

I'm realizing that given that the version is part of the pom, it means that when we will move to a different version, it will change the md5 anyway so we won't need the specific change

________________________________
From: Claus Ibsen <cl...@gmail.com>
Sent: Tuesday, December 16, 2025 2:31 PM
To: dev@camel.apache.org <de...@camel.apache.org>
Cc: Aurelien Pupier <ap...@ibm.com>
Subject: [EXTERNAL] Re: Problem closing staging repository

Hi Aurelien Thanks a lot for the help. So lets update this pom file, such as adding some <!-- blah blah blah --> or something. And if we need to rebuild the release, then Gregor maybe then include the newer commits so we get the stuff

Hi Aurelien

Thanks a lot for the help.

So lets update this pom file, such as adding some <!-- blah blah blah --> or something.

And if we need to rebuild the release, then Gregor maybe then include the newer commits so we get the stuff that included that is for 4.14.4 as well.


On Tue, Dec 16, 2025 at 2:19 PM Aurelien Pupier via dev <de...@camel.apache.org>> wrote:
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 <ap...@redhat.com>>
Sent: Tuesday, December 16, 2025 1:14 PM
To: dev@camel.apache.org<ma...@camel.apache.org> <de...@camel.apache.org>>
Subject: [EXTERNAL] Re: Problem closing staging repository

Hello,

On Tue, Dec 16, 2025 at 10:06 AM Claus Ibsen <cl...@gmail.com>> 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 <gr...@list.zurowski.org>>
> 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<https://issues.apache.org/jira/browse/INFRA-27498 >  .
> >
> > Thanks,
> > Gregor
> >
> > On Thu, Dec 11, 2025 at 10:33 PM Claus Ibsen <cl...@gmail.com>>
> > wrote:
> > >
> > > Hi
> > >
> > > And here is another Grok AI reply (think harder mode)
> > > https://grok.com/share/c2hhcmQtNQ_2c900d4c-f6e5-401a-9162-d526ac50c514<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<http://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 <
> > gregor@list.zurowski.org<ma...@list.zurowski.org>>
> > > 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


--
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

Re: Problem closing staging repository

Posted by Claus Ibsen <cl...@gmail.com>.

Hi Aurelien

Thanks a lot for the help.

So lets update this pom file, such as adding some <!-- blah blah blah -->
or something.

And if we need to rebuild the release, then Gregor maybe then include the
newer commits so we get the stuff that included that is for 4.14.4 as well.


On Tue, Dec 16, 2025 at 2:19 PM Aurelien Pupier via dev <
dev@camel.apache.org> wrote:

> 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 <ap...@redhat.com>
> Sent: Tuesday, December 16, 2025 1:14 PM
> To: dev@camel.apache.org <de...@camel.apache.org>
> Subject: [EXTERNAL] Re: Problem closing staging repository
>
> Hello,
>
> On Tue, Dec 16, 2025 at 10:06 AM Claus Ibsen <cl...@gmail.com>
> 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 <
> gregor@list.zurowski.org>
> > 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 <cl...@gmail.com>
> > > 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 <
> > > gregor@list.zurowski.org>
> > > > 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
>


-- 
Claus Ibsen

Re: Problem closing staging repository

Posted by Andrea Cosentino <an...@gmail.com>.

This is an amazing analysis, thank a lot Aurelien!

Il giorno mar 16 dic 2025 alle ore 14:25 Aurelien Pupier via dev <
dev@camel.apache.org> ha scritto:

> 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 <ap...@ibm.com>
> *Sent:* Tuesday, December 16, 2025 2:19 PM
> *To:* dev@camel.apache.org <de...@camel.apache.org>
> *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 <ap...@redhat.com>
> *Sent:* Tuesday, December 16, 2025 1:14 PM
> *To:* dev@camel.apache.org <de...@camel.apache.org>
> *Subject:* [EXTERNAL] Re: Problem closing staging repository
>
> Hello,
>
> On Tue, Dec 16, 2025 at 10:06 AM Claus Ibsen <cl...@gmail.com>
> 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 <
> gregor@list.zurowski.org>
> > wrote:
> >
> > > Hi Everyone:
> > >
> > > I wasn't able to resolve this. Therefore, I have created the following
> > > ticket for the INFRA team:
> > >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_INFRA-2D27498&d=DwIFaQ&c=BSDicqBQBDjDI9RkVyTcHQ&r=0vLfrqGC45Y6-8J0B2MbyQ&m=6beKzAziw9t-9equCQkeqGr7WVt88nRn43ROdXfgXRACXpwCY6363YmbLzYVXnUe&s=5tSbiji3cI8NsLfUoeH6yFjTliyo5ApnCJc8ANMlwjQ&e=
> <https://issues.apache.org/jira/browse/INFRA-27498> .
> > >
> > > Thanks,
> > > Gregor
> > >
> > > On Thu, Dec 11, 2025 at 10:33 PM Claus Ibsen <cl...@gmail.com>
> > > wrote:
> > > >
> > > > Hi
> > > >
> > > > And here is another Grok AI reply (think harder mode)
> > > >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__grok.com_share_c2hhcmQtNQ-5F2c900d4c-2Df6e5-2D401a-2D9162-2Dd526ac50c514&d=DwIFaQ&c=BSDicqBQBDjDI9RkVyTcHQ&r=0vLfrqGC45Y6-8J0B2MbyQ&m=6beKzAziw9t-9equCQkeqGr7WVt88nRn43ROdXfgXRACXpwCY6363YmbLzYVXnUe&s=NOEJnGeFZtx5uTjdEvqu2hpH86X0t2c8w8Q6Cln4Imk&e=
> <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 <
> > > gregor@list.zurowski.org>
> > > > 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
>

RE: Problem closing staging repository

Posted by Aurelien Pupier via dev <de...@camel.apache.org>.

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 <ap...@ibm.com>
Sent: Tuesday, December 16, 2025 2:19 PM
To: dev@camel.apache.org <de...@camel.apache.org>
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 <ap...@redhat.com>
Sent: Tuesday, December 16, 2025 1:14 PM
To: dev@camel.apache.org <de...@camel.apache.org>
Subject: [EXTERNAL] Re: Problem closing staging repository

Hello,

On Tue, Dec 16, 2025 at 10:06 AM Claus Ibsen <cl...@gmail.com> 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 <gr...@list.zurowski.org>
> 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 <cl...@gmail.com>
> > 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 <
> > gregor@list.zurowski.org>
> > > 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

RE: Problem closing staging repository

Posted by Aurelien Pupier via dev <de...@camel.apache.org>.

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 <ap...@redhat.com>
Sent: Tuesday, December 16, 2025 1:14 PM
To: dev@camel.apache.org <de...@camel.apache.org>
Subject: [EXTERNAL] Re: Problem closing staging repository

Hello,

On Tue, Dec 16, 2025 at 10:06 AM Claus Ibsen <cl...@gmail.com> 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 <gr...@list.zurowski.org>
> 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 <cl...@gmail.com>
> > 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 <
> > gregor@list.zurowski.org>
> > > 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

Re: Problem closing staging repository

Posted by Aurélien Pupier <ap...@redhat.com>.

Hello,

On Tue, Dec 16, 2025 at 10:06 AM Claus Ibsen <cl...@gmail.com> 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 <gr...@list.zurowski.org>
> 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 <cl...@gmail.com>
> > 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 <
> > gregor@list.zurowski.org>
> > > 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
>

Re: Problem closing staging repository

Posted by Claus Ibsen <cl...@gmail.com>.

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?

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 <gr...@list.zurowski.org>
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 <cl...@gmail.com>
> 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 <
> gregor@list.zurowski.org>
> > 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

Re: Problem closing staging repository

Posted by Gregor Zurowski <gr...@list.zurowski.org>.

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 <cl...@gmail.com> 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 <gr...@list.zurowski.org>
> 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

Re: Problem closing staging repository

Posted by Claus Ibsen <cl...@gmail.com>.

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 <gr...@list.zurowski.org>
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

Re: Problem closing staging repository

Posted by Claus Ibsen <cl...@gmail.com>.

Hi

This is what grok ai (free version) suggests


The error you're seeing occurs during the **close** operation of a Nexus
staging repository (typically when preparing to release to Maven Central
via Sonatype OSSRH or your own Nexus instance with Central Sync rules
enabled).

### What the Error Means
- The rule `no-traversal-paths-in-archive-file` is a security validation
enforced by Sonatype (both in their public OSSRH staging and in Nexus
instances with Central Sync enabled).
- It scans every archive (JAR, sources JAR, javadoc JAR, etc.) in the
staging repository for **insecure paths** that could enable path traversal
attacks (e.g., paths containing `../` or absolute paths like `/etc/passwd`).
- If such a path is detected, Nexus aborts the walk through the repository,
resulting in the `WalkerException` and the message **"Archives must not
contain insecure paths"**.

The `Unknown mode. Full: 5543562b Masked: 5000` part is an internal Java
`FileAttributes` or `PosixFilePermissions` parsing error that sometimes
appears when the walker encounters a problematic file during the scan
(often related to corrupted or unusual file metadata).

### Common Causes
The most frequent reasons for this failure are:

1. **Path traversal in archive entries** (the classic case):
   - Files inside a JAR with names like `../../some/file.txt`, `../..`, or
absolute paths.
   - This often happens when build scripts (e.g., Gradle, Maven assembly,
or custom packaging) accidentally include files from outside the project
directory.

2. **Special characters or invalid Unicode in file names**:
   - Non-ASCII characters, emoji, or malformed Unicode in class/file names
inside the JAR (e.g., Greek letters, symbols).
   - This can cause `java.nio.file.InvalidPathException` during the scan.

3. **Corrupted or malformed JARs**:
   - Broken checksums, zero-byte files, or archives that Nexus can't fully
read.

4. **Recently introduced stricter validation**:
   - Sonatype tightened the rule around 2024, so artifacts that previously
passed now fail even if they haven't changed.

### How to Fix It
1. **Identify the offending archive**:
   - In the Nexus UI, go to the staging repository → Staging Repositories →
select your repo → **Preview** (or **Close** again) → look at the detailed
failure report.
   - It usually lists the exact artifact (e.g.,
`your-artifact-1.0-sources.jar`) and the bad path(s) (e.g.,
`../../some/file` or a Unicode filename).

2. **Fix the problematic archive**:
   - If it's path traversal (`../` or absolute paths):
     - Review your build configuration (Maven assembly plugin, Gradle jar
task, etc.) to ensure no files are copied from parent directories.
     - Common culprits: scripts, resources, or test files placed outside
`src/main`/`src/test` and then included with relative paths.
   - If it's invalid Unicode characters:
     - Rename the offending files/classes to use only ASCII characters.
     - Rebuild the affected JAR(s).
   - After fixing, re-deploy the corrected artifacts to the same staging
repository (or drop and recreate the staging repo).

3. **Re-close the staging repository**:
   - Once the bad paths are removed, the close operation should succeed.

4. **If you can't find the bad path**:
   - Download the failing JAR from the staging repo and inspect its
contents with `jar tvf your-artifact.jar` or unzip it.
   - If the JAR is corrupted, rebuild it cleanly.

### Prevention
- Use tools like `zipinfo` or `unzip -l` on JARs before deploying.
- For Maven Central releases, always test the staging close locally or in a
dev Nexus instance with the same Central Sync rules enabled.
- Keep your Nexus version up to date (the walker code has improved handling
in newer releases).

This is a very common issue when releasing to Maven Central, and fixing the
bad path(s) in the archive(s) always resolves it. If you share the exact
artifact name and the bad path(s) from the failure report, I can help
pinpoint the cause more precisely.

On Thu, Dec 11, 2025 at 10:24 PM Claus Ibsen <cl...@gmail.com> wrote:

> Hi
>
> And is that all the log / error information there is? That is not very
> much to go after.
>
> On Thu, Dec 11, 2025 at 10:09 PM Gregor Zurowski <gr...@list.zurowski.org>
> 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

Re: Problem closing staging repository

Posted by Claus Ibsen <cl...@gmail.com>.

Hi

And is that all the log / error information there is? That is not very much
to go after.

On Thu, Dec 11, 2025 at 10:09 PM Gregor Zurowski <gr...@list.zurowski.org>
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