Issue with GPG signature validation due to standalone="no" attribute added in proxied repomd.xml file

[reds2006]

---

What problem are you trying to solve?

We are encountering an issue when using Nexus Repository as a proxy for an external repository. The repomd.xml file served by Nexus has a different signature from the original file in the upstream repository. Specifically, an additional standalone="no" attribute is added to the XML file when proxied through Nexus, which causes the GPG signature verification to fail.

Here is the difference in the beginning of the repomd.xml file:

Original repomd.xml (from upstream repository):

<?xml version="1.0" encoding="UTF-8"?>
<repomd xmlns="http://linux.duke.edu/metadata/repo" xmlns:rpm="http://linux.duke.edu/metadata/rpm">
  <revision>1732151621</revision>

Proxied repomd.xml (from Nexus):

<?xml version="1.0" encoding="UTF-8" standalone="no"?><repomd xmlns="http://linux.duke.edu/metadata/repo" xmlns:rpm="http://linux.duke.edu/metadata/rpm">
  <revision>1732151621</revision>

The additional standalone="no" attribute in the Nexus version is causing the signature verification to fail, as it results in a mismatch between the signature of the proxied file and the signature in the upstream repository.

Proxied repository URL:

• Repository: https://pkgs.k8s.io/core:/stable:/v1.31/rpm/
• Repomd URL: https://pkgs.k8s.io/core:/stable:/v1.31/rpm/repodata/repomd.xml

The issue occurs when trying to access the repository, and the error message in SLES is as follows:

Signature verification failed for file 'repomd.xml' from repository 'K8s Repository'.

    Note: Signing data enables the recipient to verify that no modifications occurred after the data were signed. Accepting data with no, wrong or unknown signature can lead to a corrupted system and in extreme cases even to a system compromise.

    Note: File 'repomd.xml' is the repositories master index file. It ensures the integrity of the whole repo.

    Warning: This file was modified after it has been signed. This may have been a malicious change, so it might not be trustworthy anymore! You should not continue unless you know it's safe.

    Note: This might be a transient issue if the server is in the midst of receiving new data. The data file and its signature are two files which must fit together. In case the request hit the server in the midst of updating them, the signature verification might fail. After a few minutes, when the server has updated its data, it should work again.

Signature verification failed for file 'repomd.xml' from repository 'K8s Repository'. Continue? [yes/no] (no):

Do you have a workaround you are using at present?

At present, we manually verify and compare the repomd.xml file and its signature before trusting it, but this is not a sustainable solution. We would like to avoid this manual process and have a consistent way of verifying the file integrity.

What feature or behavior is this required for?

This issue is affecting our ability to automatically verify and trust the content served by Nexus as part of our continuous integration and deployment pipeline. We require accurate GPG signature verification for the integrity of the files being proxied.

How could we solve this issue? (Not knowing is okay!)

We believe the issue may be caused by Nexus modifying the repomd.xml file during the proxy process. We would like to understand if there is a setting in Nexus that prevents these changes (such as the addition of the standalone="no" attribute) to ensure that files are proxied exactly as they are in the source repository.

Alternatively, a feature that allows for stricter GPG signature checks during the proxying process could help us resolve this issue.

Tell us about your Nexus Repository deployment: what version, operating system, and database are you using?

• Nexus Repository version: 3.74.0-05
• Operating system: SLES 15 SP4

Anything else?

We have observed that the repomd.xml files served from different repositories (original and proxied) have small differences in content, which affects the signature validation. We would like to confirm if these modifications are intentional and if they can be prevented in the future.

---