Skip to content
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

fix: use purl as bomref #84

Merged
merged 17 commits into from
Dec 20, 2024
Merged

fix: use purl as bomref #84

merged 17 commits into from
Dec 20, 2024

Conversation

jeremylong
Copy link
Contributor

For the metadata component it would be great if we had a purl. As such, if we just make the bomref a purl we can use the value for both the bomref and the purl.

@jeremylong jeremylong requested a review from a team as a code owner December 13, 2024 21:12
@macblazer
Copy link
Contributor

macblazer commented Dec 14, 2024

The metadata component is the thing being analyzed. pkg:cocoapods/ is the purl prefix to use for packages that are available to be imported with CocoaPods. If the thing being analyzed is, itself, a Pod then this is change to use purl could work.

However, normally the thing being analyzed is an application being built that uses CocoaPods as its dependency manager. So it should maybe have something like an app:... prefix, although I am not aware if there are any standards around this.

The purl specification specifically says

A purl is a URL composed of seven components:
scheme:type/namespace/name@version?qualifiers#subpath
...
scheme: this is the URL scheme with the constant value of "pkg".

This specific set of code is not going to work for the metadata component. Maybe if the metadata component's type is library then this code might be better than the name/version bom-ref that was originally used.

@macblazer macblazer self-assigned this Dec 15, 2024
@jeremylong
Copy link
Contributor Author

I'll look into adding a purl type as an option that defaults to generic.

@jeremylong
Copy link
Contributor Author

After looking at the code some more - I think we can infer the package type from the specified component type. The purl type should be ' generic ' if the component type is anything but library. If the component type is library then the purl type should be cocoapods. If you want, we could add another option to override this behavior.

@jeremylong
Copy link
Contributor Author

@macblazer I think this is ready for your re-review now. I believe I have addressed your concerns about using the package type of cocopods with 9fda73d and I have added a test with ce9bcaf. Yes, this is abusing the 'type' slightly, but I felt this was better than upping the parameter count to 7.

@jeremylong jeremylong requested a review from macblazer December 18, 2024 11:11
Copy link
Contributor

@macblazer macblazer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good other than the one duplicate function that seems unused. I like this ability to read the podspec file and generate the purl of the thing being analyzed if it is a Pod.

lib/cyclonedx/cocoapods/component.rb Outdated Show resolved Hide resolved
Signed-off-by: Jeremy Long <[email protected]>
@macblazer macblazer merged commit d39e38e into CycloneDX:main Dec 20, 2024
5 checks passed
@jeremylong jeremylong deleted the fix/purl branch December 20, 2024 19:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants