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

Add a Files field in the Package struct #198

Closed
alfredodeza opened this issue Sep 30, 2020 · 2 comments · Fixed by #329
Closed

Add a Files field in the Package struct #198

alfredodeza opened this issue Sep 30, 2020 · 2 comments · Fixed by #329
Labels
enhancement New feature or request

Comments

@alfredodeza
Copy link
Contributor

alfredodeza commented Sep 30, 2020

What would you like to be added: Many package specifications like Ruby Gems provide information regarding the files that belong to a package. This information is currently not present in the output from syft.

It seems that this information is very common among other package formats so that this could potentially mean a new field in the Package struct vs. just adding it to the metadata.

Either case, this is not present at all and is needed for the different analyzers that provide that information in Anchore Engine. For package types like Python, this might present a problem, where the egg parser looks at PKG-INFO which doesn't have access to files, although SOURCES.txt (within the same directory) has all the files for that package.

Why is this needed: Parity with Anchore Engine Analyzers, specifically related to this issue anchore/anchore-engine#629

Additional context:

@alfredodeza alfredodeza added the enhancement New feature or request label Sep 30, 2020
@wagoodman
Copy link
Contributor

Agreed that we should capture this information; a better spot for it would be within the Package.Metadata field . Currently we do not have a equivalent Metadata type as we do with others (say dpkg), adding a new metadata type and housing the Files[] would be consistent with other catalogers and how data is persisted after parsing.

@luhring
Copy link
Contributor

luhring commented Feb 21, 2021

It seems like this has been addressed by now (specifically, with Alex's suggestion of using a field within Metadata).

Closing, but let me know if I've overlooked something that hasn't actually been addressed yet.

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

Successfully merging a pull request may close this issue.

3 participants