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

Additional fields for package_info rule / PackageInfo provider #163

Open
adam-azarchs opened this issue Oct 22, 2024 · 0 comments
Open

Additional fields for package_info rule / PackageInfo provider #163

adam-azarchs opened this issue Oct 22, 2024 · 0 comments

Comments

@adam-azarchs
Copy link
Contributor

In the interest of not having everyone invent their own keys to add to ExperimentalMetadataInfo, I'm opening this issue to request a few more standardized fields for the PackageInfo provider.

Current fields, for reference:

"package_name": "string: Human readable package name",
"package_url": "string: URL from which this package was downloaded.",
"package_version": "string: Human readable version string",
"purl": "string: package url matching the purl spec (https://github.com/package-url/purl-spec)",

Additional fields I would like to see are fields which are either commonly provided by package managers and potentially useful when generating reports in some contexts, or are required for some SBOM-like APIs, e.g. GitHub's dependency submission API. I don't much care to bike-shed the names of these fields as long as there's a place to put this information.

  • homepage: The project's home page. This is often available for rust crates, npm packages, PyPi or conda packages, and so on, and is often helpful to a reviewer asking the question "what is this dependency for?"
  • manifest: The manifest file (e.g. requirements.txt, go.mod, Cargo.lock) that declares this dependency. Used by the GitHub dependency submission API, and useful for "we need to update this dependency, which file do I need to edit?"
  • ecosystem (definitely open to suggestions for a better name here): which package manager this package came from, e.g. debian, maven, conda, pypi, cargo, npm. Helpful for interpreting the package name (e.g. "is this numpy the python package or is this the rust crate?" Convenient for report-generating rules that want to sort things, but arguably redundant with first component of the purl (after the scheme).
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

No branches or pull requests

1 participant