You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When calling the Publish API without the Signing Options even though aptly uses an encrypted GPG key, signing RELEASE file and publishing obviously fails, but the API returns 202 Accepted
Detailed Description
When using a GPG key that was generated with a passphrase, calling the Publish API without Signing Options unexpectedly return 202 Accepted instead of 4xx:
Meanwhile the logs on the server side look like this:
[GIN] 2024/04/11 - 13:28:12 | 202 | 11.431911ms | 172.17.0.1 | POST "/api/publish/:."
Signing file 'Release' with gpg, please enter your passphrase when prompted:
gpg: signing failed: Inappropriate ioctl for device
gpg: signing failed: Inappropriate ioctl for device
and a simple GET request to list published repos shows that the repo was not published.
Context
When utilizing the REST API to build own applications around it, it's common to assume a 2xx response code usually means that the API call was fine. There is no clear error message visible to the caller. Instead, it's only visible within the server only. It's best practice to return a status code indicating an issue.
Possible Implementation
Modify returned HTTP status code to e.g. 400 Bad Request
When calling the Publish API without the Signing Options even though aptly uses an encrypted GPG key, signing RELEASE file and publishing obviously fails, but the API returns
202 Accepted
Detailed Description
When using a GPG key that was generated with a passphrase, calling the Publish API without Signing Options unexpectedly return
202 Accepted
instead of 4xx:Meanwhile the logs on the server side look like this:
and a simple
GET
request to list published repos shows that the repo was not published.Context
When utilizing the REST API to build own applications around it, it's common to assume a 2xx response code usually means that the API call was fine. There is no clear error message visible to the caller. Instead, it's only visible within the server only. It's best practice to return a status code indicating an issue.
Possible Implementation
Modify returned HTTP status code to e.g.
400 Bad Request
Your Environment
Docker with Dockerfile (excerpt):
The text was updated successfully, but these errors were encountered: