-
Notifications
You must be signed in to change notification settings - Fork 81
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
Comments
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? |
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 : |
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 |
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 Even tho it should be : Suite: stable Based on my Release that I create with a POST to this endpoint : /pulp/api/v3/content/deb/releases/ with this data If I don't sign, I have the right Suite and Codename, no problems at all. I would get these errors after an apt update : I also tried to do a fresh install of pulp/pulp on the new version and I still get the same errors. |
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 The question is how can this be happening? Looking at the code I have no ideas. @hstct Do you have any ideas? |
I have tried this :
It does get rid of the "File exists" error, however the InRelease problem is still the same: Suite: trixie Maybe it is a problem around the Release and not the signature ? However like I said, I'm not doing anything fancy :
|
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. |
Doing the same workflow using curl works !
Meaning that my release must have a problem somewhere, it's not interpreted correclty, then it does
Explaning my problem of "suite:trixie codename:trixie" I will look into my code, thanks for the help ! |
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:
Expected behavior
I expected the InRelease file to be signed without any modifications to the "Suite", "Codename", or package paths.
The text was updated successfully, but these errors were encountered: