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

tarutil: support regex/glob patterns #456

Closed
paolochiodi opened this issue Aug 30, 2017 · 1 comment
Closed

tarutil: support regex/glob patterns #456

paolochiodi opened this issue Aug 30, 2017 · 1 comment
Labels
kind/design relates to the fundamental design of a component kind/feature request wishes for new functionality/docs priority/medium desired functionality

Comments

@paolochiodi
Copy link

paolochiodi commented Aug 30, 2017

I’m exploring the possibility to build a nodejs/npm extension for Clair.
The major roadblock I've found so far is in the “listers”: they require previous knowledge of the exact path of the file containing the list of installed features.
With npm this is a problem because location of the file depends on how the user has structured the project, and there's no clear standard.

Would the maintainers be open to a change in https://github.com/coreos/clair/blob/master/pkg/tarutil/tarutil.go#L81 to support wildcards, either through regexp or glob patterns?

@jzelinskie
Copy link
Contributor

jzelinskie commented Sep 6, 2017

This is absolutely going to have to be changed to support this behavior.
I suspect the API should change such that tarutil would take an list of some kind of new detection interface rather than just filename strings.

I recommend looking into what vulnerability source you can use for nodejs, because iirc the licensing around the data is tricky.

@jzelinskie jzelinskie changed the title wildcards support for listers tarutil: support regex/glob patterns Sep 26, 2018
@jzelinskie jzelinskie added kind/design relates to the fundamental design of a component kind/feature request wishes for new functionality/docs priority/medium desired functionality component/ext/featurefmt labels Sep 26, 2018
Allda pushed a commit to Allda/clair that referenced this issue Apr 3, 2019
Some features do not exist in set locations, but can be anywhere in the layer.
This allows those featurefmt to specify the filenames to be scanned by
regexp, as opposed to purely by path prefix.
If any current users of this express paths which use regexp special characters
this could be a breaking change for them (with the exception of . which will
continue to work as it matches against the literal character .), however
none of the code in this repo does that.

fixes quay#456
Allda pushed a commit to Allda/clair that referenced this issue Apr 3, 2019
Some features do not exist in set locations, but can be anywhere in the layer.
This allows those featurefmt to specify the filenames to be scanned by
regexp, as opposed to purely by path prefix.
If any current users of this express paths which use regexp special characters
this could be a breaking change for them (with the exception of . which will
continue to work as it matches against the literal character .), however
none of the code in this repo does that.

fixes quay#456
ericysim pushed a commit to erics1989/clair that referenced this issue Apr 11, 2019
Some features do not exist in set locations, but can be anywhere in the layer.
This allows those featurefmt to specify the filenames to be scanned by
regexp, as opposed to purely by path prefix.
If any current users of this express paths which use regexp special characters
this could be a breaking change for them (with the exception of . which will
continue to work as it matches against the literal character .), however
none of the code in this repo does that.

fixes quay#456
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/design relates to the fundamental design of a component kind/feature request wishes for new functionality/docs priority/medium desired functionality
Development

No branches or pull requests

2 participants