GET /api/v1/package/{uuid} fails with some packages

[carlosthe19916]

Steps to reproduce:

• Start a clean instance of trustify
• Enable only the "redhat-csaf" importer. Wait some minutes
• Search for packages like ose-powervs-cloud-controller-manager-rhel8 and try to fetch it by their uuid, we will see an error:

{
    "error": "Database error",
    "message": "Query Error: error returned from database: invalid input syntax for type numeric: \"sha256:f579ee538e6f4bfa4d9c20bf2680d7fc3ec7a757a40637a743b7962187b4d6a1\""
}

Screencast.from.2024-06-27.10-44-54.mp4

Hint: it seems to happen with package whose version are something like sha256:cfb31631b19c2e9d2ef28bac6d4471c97e79976b0c9590032cf0206bfcd3e4f3 ; on the other hand, packages with versions like 1.2.3 work fine

[ctron]

This looks like a mix of data types. "Packages" is most like "PURLs" (which we still label incorrectly). Actual packages have an ID which is a UUID (because we use UUIDs in many cases internally).

What looks like a "package version" here is, most likely, actually the "version" component of a "PURL" from a container. Same format, but unknown to our system.

The endpoint /api/v1/package/{uuid} does NOT work with packages, but with PURLs. The UUID is just accidentally a UUID, that should just be an "ID" field (which happens to be a UUID, but that's an implementation detail).

[bobmcwhirter]

Can we verify if this is still an issue?

[carlosthe19916]

Can we verify if this is still an issue?

It is still happening. Unfortunately, it is tricky to reproduce. I needed to run the CVE 2024 importer and then the CSAF importer wait for some time and search for packages as the video below

Screencast.from.2024-07-19.13-30-42.mp4

[bobmcwhirter]

Your video seems to show /api/v1/package/{id} usage, and I no longer know what endpoint that is.

If it's SBOM packages, that'd be under /api/v1/sbom/{id}/packages.

For purls, it'd be /api/v1/purl/{id}

I'll try to reproduce...