Fix panic in APK version specifier handling

[luhring]

A bug was introduced in #1063 where Syft would panic if a package listed in the installed DB doesn't "provide" anything.

This PR reworks the logic so that Syft allows for empty "provides" values (edit: no longer part of this PR, see #1494 (comment)). It also adjusts the stripVersionSpecifier helper function to remove the possibility of panicking (index out of range).

[luhring]

Having trouble making sense of the failure logs: https://github.com/anchore/syft/actions/runs/3963383936/jobs/6791170964#step:6:159

Help appreciated 😃

[spiffcs]

@luhring we've updated this in main now where this CLI test is fixed - if you're able to merge from upstream you should no longer see this failure

[Nirusu]

I basically submitted the same fix for #1484, just in a different way.

Don't mind in which way this is fixed, though this also applies to "dependencies", not just "provides" from what I remember correctly. So you would also have to add

if depSpecifier  == "" {
   continue
}

later since that can also be empty by the packages you provide with apko (at least if you want to keep the same logic as for "provides" - you could also remove the if-checks and due to the workaround in the stripVersionSpecifier function it would still not crash, but not sure whether what would end up with garbage later - I'am not that familiar with the Syft code).

But instead of doing these if-checks, maybe merging a part of this PR and my PR could make sense? So keeping your modification in stripVersionSpecifier so that it should not panic in case something empty is passed in, but also instead of checking and skipping on empty strings, not filling them into the array in the first place (what my PR does)?

Otherwise having empty strings in the Metadata struct seems like a way to shoot yourself in the foot later on anyways since it will be enumerated over in for loops. Unless of course you somehow want to know if the field existed in the APK definition but was left empty deliberately.

[luhring]

@Nirusu Ah! I hadn't seen your PR, sorry — I'm glad you caught this. I actually like your solution better! I say we merge it, and I can close mine. My PR was just trying to stop the bleeding.

Yours might need a rebase, and I like the idea of incorporating the changes to stripVersionSpecifier to prevent panics in the future — but to me the first priority is preventing panics, which your PR does elegantly. 👏

[wagoodman]

@luhring I'm going to merge the PR that @Nirusu provided for this, however I do think keeping the stripVersionSpecifier fix also make sense -- if you'd like you could rescope this PR to just that enhancement or open another PR.

[luhring]

@luhring I'm going to merge the PR that @Nirusu provided for this, however I do think keeping the stripVersionSpecifier fix also make sense -- if you'd like you could rescope this PR to just that enhancement or open another PR.

Sounds good, thanks @wagoodman!

[wagoodman]

note: the force push was to rebase on the latest in main (fixes the failing CLI test)

changes made:

• added some explicit tests for stripVersionSpecifier
• removed the empty value check before calling stripVersionSpecifier