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

Specify Maven classifiers / types as part of PURLs / metadata #42

Open
sschuberth opened this issue Jul 5, 2023 · 8 comments
Open

Specify Maven classifiers / types as part of PURLs / metadata #42

sschuberth opened this issue Jul 5, 2023 · 8 comments
Labels
enhancement New feature or request

Comments

@sschuberth
Copy link
Contributor

Maven has the concept of a classifier that "distinguishes artifacts that were built from the same POM but differ in content". An example is the struts2-assembly dependency which has "lib", "min-lib" etc. variants that also are ZIPs instead of JARs (see Maven's "type").

As contents between such artifact variants differ, e.g. different vulnerabilities may apply. Also, when trying to use the PURL to construct the exact download location of the artifact for further inspection, that is not possible in this case without knowing about the classifier and type.

PURL already specifies how to map Maven classifier and type to its qualifiers, so it would be nice to have them there. Additionally, maybe a package's metadata object in GitHub's dependency submission API could be used to also list these properties.

@JLLeitschuh
Copy link
Contributor

I had always intended to do this, but I couldn't figure out where to get this information out of the Gradle API. Hoping that @bigdaz has a better idea where to find this information

@sschuberth
Copy link
Contributor Author

I couldn't figure out where to get this information out of the Gradle API.

That's indeed something I've been banging my head for, too. In ORT, we currently have some not-so-nice code that searches all resolved artifacts for the id of a ResolvedComponentResult, which seems rather inefficient. It would be nice to learn if there's a better way...

@JLLeitschuh
Copy link
Contributor

Oh, interesting! You should consider presenting ORT to the Open Source Security Foundation in one of the WG meetings.

https://openssf.org/getinvolved/
https://slack.openssf.org

@sschuberth
Copy link
Contributor Author

You should consider presenting ORT to the Open Source Security Foundation

I was actually assuming OSSF to already be aware of ORT as both are Linux Foundation projects in more or less the same domain 😉 But I'll reach out on Slack, thanks!

@bigdaz bigdaz added the enhancement New feature or request label Jul 10, 2023
@bigdaz bigdaz self-assigned this Jul 10, 2023
@sschuberth
Copy link
Contributor Author

In ORT, we currently have some not-so-nice code that searches all resolved artifacts for the id of a ResolvedComponentResult, which seems rather inefficient. It would be nice to learn if there's a better way...

To add to that, the challenge is that also when determining the classifier / type of a (Maven) artifact, you don't want to download the (binary) artifact itself, but just its metadata, for performance reasons. I'm not sure if that's even possible with Gradle right now, or if the resolution process in this case always triggers the download of the artifact.

@sschuberth
Copy link
Contributor Author

sschuberth commented Oct 23, 2023

I couldn't figure out where to get this information out of the Gradle API.

For reference, @ov7a just mentioned over here that no API is planned for this, and that Maven classifiers / types should be parsed from the file name...

@sschuberth
Copy link
Contributor Author

@bigdaz, since you assigned this to yourself, is there any time frame for adding support for this?

@bigdaz bigdaz removed their assignment Dec 7, 2023
@bigdaz
Copy link
Member

bigdaz commented Dec 7, 2023

@sschuberth No, I don't have any plans to tackle this soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants