-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Labels
kind/design
relates to the fundamental design of a component
kind/feature request
wishes for new functionality/docs
priority/medium
desired functionality
Comments
This is absolutely going to have to be changed to support this behavior. I recommend looking into what vulnerability source you can use for nodejs, because iirc the licensing around the data is tricky. |
jzelinskie
changed the title
wildcards support for listers
tarutil: support regex/glob patterns
Sep 26, 2018
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
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?
The text was updated successfully, but these errors were encountered: