Repository navigation
Conversation
PackageQuerySerializer accepted any string as a purl. With ignore_qualifiers_subpath set, the view then called PackageURL.from_string on it and the ValueError surfaced as a 500. Without that flag the bad purl was silently ignored and the request returned 200 with no results. Validate each purl in the serializer so both cases get a 400 that says which purl is wrong. Signed-off-by: Sahil Lenka <76817449+Sahil-u07@users.noreply.github.com>
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Sending a malformed purl to
POST /api/v3/packageseither crashes or gets silently ignored, depending onignore_qualifiers_subpath:ignore_qualifiers_subpath: true, the view callsPackageURL.from_stringon it and theValueErrorisn't caught, so it's a 500ignore_qualifiers_subpath: false, the bad purl just doesn't match anything and the response is a 200 with no results, which hides the mistake from the callerPackageQuerySerializeraccepted any string as a purl, so I added avalidate_purlscheck there. Since the view already callsis_valid(raise_exception=True), both cases now return a 400 with the parse error, e.g.The advisories endpoint (
AdvisoryQuerySerializer) also takes purls, but it only uses them in a DB lookup and never parses them, so I left it alone to keep this focused. Happy to add the same check there if you'd like the two to behave the same.Added a test that posts an invalid purl with the flag both on and off and expects a 400. All the tests in
test_api_v3.pypass locally.