Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@wagoodman
Copy link
Contributor

@wagoodman wagoodman commented Sep 24, 2020

Adds the ability to scan OCI images from tar archive or directory:

# explicitly
grype oci-archive:path/to.tar
grype oci-dir:path/to/dir

# or implicitly
syft path/to/tar/or/dir

Also hinted in the example above, this PR incorporates changing the URL approach for specifying the source transport to a URI oriented approach (see anchore/stereoscope#41 PR description for more details). TL;DR is :// is being replaced with : to fall in line with the URI RFC.

Lastly, migrates to using the stereoscope fixture utils instead of the functions from go-testutils.

Closes #157

@wagoodman wagoodman requested a review from dakaneye September 24, 2020 13:06
@wagoodman wagoodman requested a review from luhring September 24, 2020 13:06
@wagoodman wagoodman added the enhancement New feature or request label Sep 24, 2020
@wagoodman wagoodman self-assigned this Sep 24, 2020
The output format for Grype is configurable as well:
```
grype <image> -o json
grype <image> -o <format>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is a great way to format the help

# scan a directory
grype dir://path/to/dir
grype path/to/dir
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand this has probably been discussed a lot, but I thought these changes were to put some order in the usage of schemes, not generalize them to be able to infer the destination. Specifically this line in the in this PR's subject:

TL;DR is :// is being replaced with : to fall in line with the URI RFC.

Automatically inferring is going to be problematic for integrations because it was the way to detect what the source type is (dir, tar, docker, etc..). If grype allows these inputs, then the integrations need to enforce a constraint, by either not allowing these free-styling of input, or separating input in the form of configuration.

That would mean that instead of these:

    - name: Run directory Scan Action
      uses: anchore/scan-action@v1
      with:
        source: "dir://tests/python"

    - name: Run Image Scan Action
      uses: anchore/scan-action@v1
      with:
        source: "alpine:3.12"

The action would require prefixing the scheme or separating the options like this:

    - name: Run directory Scan Action
      uses: anchore/scan-action@v1
      with:
        dir-source: "tests/python"

    - name: Run Image Scan Action
      uses: anchore/scan-action@v1
      with:
        img-source: "alpine:3.12"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What prevents grype from inferring from generic input? That is, what prevents this:

    - name: Run directory Scan Action
      uses: anchore/scan-action@v1
      with:
        source: "tests/python"

    - name: Run Image Scan Action
      uses: anchore/scan-action@v1
      with:
        source: "alpine:3.12"

or more explicitly from the user:

    - name: Run directory Scan Action
      uses: anchore/scan-action@v1
      with:
        source: "dir:tests/python"

    - name: Run Image Scan Action
      uses: anchore/scan-action@v1
      with:
        source: "docker:alpine:3.12"

Which would be the same as grype options:

grype docker:alpine:3.12
grype alpine:3.12
grype dir:tests/python
grype tests/python

Is there something in particular with the integration that it requires knowledge of the source type?

Copy link
Contributor

@alfredodeza alfredodeza Sep 24, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It isn't that there is something that prevents it. But the integration must know if the source is a path or an image for reporting.
Using dir:// explicitly as it is the current state, works well. The free-form doesn't allow to understand what the integration is dealing with.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that implicit input from a user is OK here, as the user does not need to understand explicit schemes. Also this does not block extensions from enforcing explicit usage of schemes (either by prepending strings, string validation, or otherwise). I think your comments are quite notable, but mostly impact the integration implementation, not the CLI surface area on grype meant for the user.

@wagoodman wagoodman merged commit 326afa3 into main Sep 25, 2020
@wagoodman wagoodman deleted the add-oci-support branch September 25, 2020 18:18
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 this pull request may close these issues.

Update CLI syntax for input source specification

3 participants