Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GPG signing_service script corrupts my InRelease and Release.gpg. files #1245

Open
Mav-Joel opened this issue Feb 27, 2025 · 8 comments
Open

Comments

@Mav-Joel
Copy link

Version
pulpcore version : 3.71.2
pulp_deb version : 3.5.1
Installed via Docker with pulp/pulp image

Describe the bug
When using the signing service created via : https://pulpproject.org/pulp_deb/docs/user/guides/signing_service/

I encounter a "File exists" error. To bypass this, I added the --yes parameter to the GPG commands to force the signing. While this resolves the error, it causes unexpected changes in the InRelease file:

The "Codename" and "Suite" values are altered to "trixie".
The InRelease file becomes unusable because the package paths are modified or missing compared to a correctly generated InRelease file.

To Reproduce
Steps to reproduce the behavior:

  • Create a signing service via https://pulpproject.org/pulp_deb/docs/user/guides/signing_service/
  • Add --yes to the gpg commands in the script (otherwise it won't work at all and will return "File exists")
  • Generate an InRelease file with a specific Suite and Codename
  • Try to use the signing service to sign a deb package
  • Check the created InRelease file

Expected behavior
I expected the InRelease file to be signed without any modifications to the "Suite", "Codename", or package paths.

@quba42
Copy link
Collaborator

quba42 commented Feb 27, 2025

What does "Try to use the signing service to sign a deb package" mean?

What commands are you actually using to create your Pulp publication that results in the error?

@Mav-Joel
Copy link
Author

I'm using the PULP API via requests in Python, So I do POST to this endpoint : "/pulp/api/v3/publications/deb/apt/"

with these parameters :
data = {
"structured": "true",
"repository": repository_href,
"signing_service": signing_service_href
}

@quba42
Copy link
Collaborator

quba42 commented Feb 27, 2025

I am stumped. The signing service is meant to just take whatever Pulp hands to it and sign it. It cannot alter anything (like Suite or Codename). This suggests that the wrong release file is being passed in. Or else the wrong release file is being collected after the signing. The signing and writing of the signed InRelease should all happen in a temporary folder, so I don't understand how there can already be a file there to get the "File exists" error. Maybe generating temporary directories is somehow broken.

Could you extend your script to write the contents of "${PULP_TEMP_WORKING_DIR}" and perhaps "${INLINE_SIGNATURE_PATH}" to a file somewhere so we can check if they contain something sane?

@Mav-Joel
Copy link
Author

I did, the ${PULP_TEMP_WORKING_DIR} is /var/lib/pulp, I have tried using literal temporary directories, without success.

"${INLINE_SIGNATURE_PATH}" returns the right path however, the data is altered with this at the top :

Suite: trixie
Codename: trixie

Even tho it should be :

Suite: stable
Codename: default

Based on my Release that I create with a POST to this endpoint : /pulp/api/v3/content/deb/releases/

with this data
data = {"codename": codename,
"suite": suite,
"distribution": distribution}

If I don't sign, I have the right Suite and Codename, no problems at all.
If I do sign, I get an altered InRelease

I would get these errors after an apt update :
default InRelease' changed its 'Suite' value from 'stable' to 'trixie'
default InRelease' changed its 'Codename' value from 'default' to 'trixie'

I also tried to do a fresh install of pulp/pulp on the new version and I still get the same errors.

@quba42
Copy link
Collaborator

quba42 commented Mar 3, 2025

PULP_TEMP_WORKING_DIR should not be /var/lib/pulp. Looking at the code for pulp_deb 3.5.1, I don't see how it could be /var/lib/pulp/: https://github.com/pulp/pulp_deb/blob/3.5.1/pulp_deb/app/tasks/publishing.py#L600

We are explicitly creating a random sub-folder within whatever the base-path is. This does explain your issue. If for some reason your instance is always signing directly in /var/lib/pulp then there will already be files there from previous publish tasks, and if those files are incorrectly used from another publish then that explains why you have InRelease files with the wrong "Codename" and "Suite" values: They are simply the wrong InRelease files for that publish.

The question is how can this be happening? Looking at the code I have no ideas. @hstct Do you have any ideas?

@Mav-Joel
Copy link
Author

Mav-Joel commented Mar 3, 2025

I have tried this :

#!/bin/bash

set -e

RELEASE_FILE="$(/usr/bin/readlink -f $1)"

PULP_TEMP_WORKING_DIR="/tmp/pulp_$(date +%s%N)"
mkdir -p "$PULP_TEMP_WORKING_DIR"

OUTPUT_DIR="${PULP_TEMP_WORKING_DIR}"
DETACHED_SIGNATURE_PATH="${OUTPUT_DIR}/Release.gpg"
INLINE_SIGNATURE_PATH="${OUTPUT_DIR}/InRelease"
GPG_KEY_ID="pulp1"
COMMON_GPG_OPTS="--batch --armor --digest-algo SHA256"

# Create a detached signature
/usr/bin/gpg ${COMMON_GPG_OPTS} \
  --detach-sign \
  --output "${DETACHED_SIGNATURE_PATH}" \
  --local-user "${GPG_KEY_ID}" \
  "${RELEASE_FILE}"

# Create an inline signature
/usr/bin/gpg ${COMMON_GPG_OPTS} \
  --clearsign \
  --output "${INLINE_SIGNATURE_PATH}" \
  --local-user "${GPG_KEY_ID}" \
  "${RELEASE_FILE}"

# Print the result in JSON format
echo { \
       \"signatures\": { \
         \"inline\": \"${INLINE_SIGNATURE_PATH}\", \
         \"detached\": \"${DETACHED_SIGNATURE_PATH}\" \
       } \
     }
     

It does get rid of the "File exists" error, however the InRelease problem is still the same:

Suite: trixie
Codename : trixie

Maybe it is a problem around the Release and not the signature ? However like I said, I'm not doing anything fancy :

release_href = pulp_deb.createRelease(
        "default", "stable", distribution)

def createRelease(self, codename, suite, distribution):
        data = {"codename": codename,
                "suite": suite,
                "distribution": distribution}
        filters = {"codename": codename,
                   "suite": suite,
                   "distribution": distribution}
        return createResource(self, self.releases, data, filters)[0]

def createResource(self, endpoint, data={}, filters={}):
    print(f"Creating resource : {endpoint}")
    if filters:
        resources_infos = searchResource(self, endpoint, filters)
        if resources_infos:
            return resources_infos['pulp_href'], False
    try:
        r = requests.post(self.url+endpoint, json=data,
                          verify=False, auth=(self.username, self.password))

@quba42
Copy link
Collaborator

quba42 commented Mar 3, 2025

In order to comment on what Suite/Codename you should or shouldn't be seeing, I would need to know what repo you are syncing (remote options). You have already posted your publication options above, so I already have those.

@Mav-Joel
Copy link
Author

Mav-Joel commented Mar 3, 2025

Doing the same workflow using curl works !
So it must be a problem with my code, from what I can tell, the problem comes from :

if not release:
  codename = distribution.strip("/").split("/")[0]
  release = Release(
      distribution=distribution,
      codename=codename,
      suite=codename,
      origin="Pulp 3",
  )

Meaning that my release must have a problem somewhere, it's not interpreted correclty, then it does

codename=codename
suite=codename

Explaning my problem of "suite:trixie codename:trixie"

I will look into my code, thanks for the help !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants