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

Syft looks for the config file in $PWD, not in the target directory. Intentional? #2465

Closed
chmeliik opened this issue Jan 3, 2024 · 3 comments
Labels
changelog-ignore Don't include this issue in the release changelog question Further information is requested

Comments

@chmeliik
Copy link

chmeliik commented Jan 3, 2024

What happened:

When a processing a directory, e.g. syft ~/repos/syft, Syft does not read the .syft.yaml config file in the target directory. It reads the one in the current directory instead.

What you expected to happen:

Expected Syft to read <target directory>/.syft.yaml rather than $PWD/.syft.yaml

Steps to reproduce the issue:

In the root of this repository:

cat << EOF > .syft.yaml
exclude:
- "**/test-fixtures"
- "./.github"
EOF

function count_packages_by_purl_type() {
  local dir=$1
  syft "$dir" -o cyclonedx-json |
    jq '.components[].purl | try match("pkg:[^/]*").string catch "<no purl>"' |
    sort | uniq -c | sort -h
}

count_packages_by_purl_type . 2>/dev/null 
#   1675 "pkg:golang"

cd ..

count_packages_by_purl_type ./syft 2>/dev/null 
#      1 "pkg:rpm"
#      2 "pkg:ebuild"
#      2 "pkg:nix"
#      4 "pkg:composer"
#     10 "pkg:swift"
#     13 "pkg:cargo"
#     13 "pkg:pub"
#     18 "pkg:apk"
#     18 "pkg:conan"
#     28 "pkg:nuget"
#     30 "<no purl>"
#     39 "pkg:github"
#     39 "pkg:pypi"
#     44 "pkg:hex"
#     46 "pkg:cocoapods"
#     47 "pkg:generic"
#     55 "pkg:hackage"
#     57 "pkg:npm"
#     59 "pkg:maven"
#    109 "pkg:gem"
#   1690 "pkg:golang"

Environment:

  • Output of syft version:
Application: syft
Version:    0.99.0-SNAPSHOT-0e5fb8e0
BuildDate:  2024-01-03T13:16:47Z
GitCommit:  0e5fb8e01fd0b4f48b69b5cedefd876e756f6d61
GitDescription: v0.99.0-8-g0e5fb8e0
Platform:   linux/amd64
GoVersion:  go1.21.5
Compiler:   gc

(built with make build from 0e5fb8e)

  • OS (e.g: cat /etc/os-release or similar): Fedora Linux 39 (Workstation Edition)
@chmeliik chmeliik added the bug Something isn't working label Jan 3, 2024
@tgerla
Copy link
Contributor

tgerla commented Jan 3, 2024

Hi @chmeliik, thanks for the report. I think our intention here is indeed to find the syft configuration file in the current working directory, and not in the target directory. However, if you'd like to include a config file in the directory to be scanned, you can specify a particular config file using --config or -c on the syft command line. Would that suit your needs? I can definitely understand the need for custom configurations per directory being scanned.

@tgerla tgerla moved this to Awaiting Response in OSS Jan 3, 2024
@chmeliik
Copy link
Author

chmeliik commented Jan 4, 2024

Given that some of the configuration options feel like they're scoped to the thing I'm scanning (e.g. exclude), it seemed strange that Syft should read the configuration in the current directory rather than the one it is scanning.

But if that's intended that's OK, using --config or making sure I'm in the right directory will work for me 👍

@tgerla tgerla removed the status in OSS Jan 4, 2024
@tgerla
Copy link
Contributor

tgerla commented Jan 4, 2024

Sure, I understand your reasoning here, but I think we will preserve existing behavior. Glad the --config method will work for you. I'll close this issue out but please let us know if you need anything else. For reference, here's the section of the README docs describing the config parsing: https://github.com/anchore/syft#configuration

@tgerla tgerla added changelog-ignore Don't include this issue in the release changelog question Further information is requested and removed bug Something isn't working labels Jan 4, 2024
@tgerla tgerla closed this as completed Jan 4, 2024
@github-project-automation github-project-automation bot moved this to Done in OSS Jan 4, 2024
@tgerla tgerla closed this as not planned Won't fix, can't repro, duplicate, stale Jan 4, 2024
chmeliik added a commit to chmeliik/build-definitions that referenced this issue Feb 21, 2024
STONEBLD-2095

Syft makes many things configurable:
https://github.com/anchore/syft#configuration

For example, users can take advantage of this to get rid of false
positives. This will be useful for the Syft build itself:
redhat-appstudio/rh-syft#21

Currently, our SBOM generation does not respect the user configuration.
Syft reads the config from the current working directory, not from the
target directory (anchore/syft#2465).

Set the working directory to the root of the user's repository to ensure
we respect the configuration.

Signed-off-by: Adam Cmiel <[email protected]>
chmeliik added a commit to chmeliik/build-definitions that referenced this issue Feb 21, 2024
STONEBLD-2095

Syft makes many things configurable:
https://github.com/anchore/syft#configuration

For example, users can take advantage of this to get rid of false
positives. This will be useful for the Syft build itself:
redhat-appstudio/rh-syft#21

Currently, our SBOM generation does not respect the user configuration.
Syft reads the config from the current working directory, not from the
target directory (anchore/syft#2465).

Set the working directory to the root of the user's repository to ensure
we respect the configuration.

Signed-off-by: Adam Cmiel <[email protected]>
chmeliik added a commit to chmeliik/build-definitions that referenced this issue Feb 21, 2024
STONEBLD-2095

Syft makes many things configurable:
https://github.com/anchore/syft#configuration

For example, users can take advantage of this to get rid of false
positives. This will be useful for the Syft build itself:
redhat-appstudio/rh-syft#21

Currently, our SBOM generation does not respect the user configuration.
Syft reads the config from the current working directory, not from the
target directory (anchore/syft#2465).

Set the working directory to the root of the user's repository to ensure
we respect the configuration.

Signed-off-by: Adam Cmiel <[email protected]>
chmeliik added a commit to chmeliik/build-definitions that referenced this issue Feb 28, 2024
STONEBLD-2095

Syft makes many things configurable:
https://github.com/anchore/syft#configuration

For example, users can take advantage of this to get rid of false
positives. This will be useful for the Syft build itself:
redhat-appstudio/rh-syft#21

Currently, our SBOM generation does not respect the user configuration.
Syft reads the config from the current working directory, not from the
target directory (anchore/syft#2465).

Set the working directory to the root of the user's repository to ensure
we respect the configuration.

---

This also allows the user to - intentionally or otherwise - exclude
packages that should be reported, causing false negatives. That seems
like an acceptable tradeoff, given that:

* For hermetic builds, the SBOM should still report everything that got
  in from outside, regardless of Syft configuration.
* We should assume some level of co-operation from the user, we don't
  have to design accurate SBOMs for users that actively sabotage the
  proces

Signed-off-by: Adam Cmiel <[email protected]>
chmeliik added a commit to chmeliik/build-definitions that referenced this issue Mar 1, 2024
STONEBLD-2095

Syft makes many things configurable:
https://github.com/anchore/syft#configuration

For example, users can take advantage of this to get rid of false
positives. This will be useful for the Syft build itself:
redhat-appstudio/rh-syft#21

Currently, our SBOM generation does not respect the user configuration.
Syft reads the config from the current working directory, not from the
target directory (anchore/syft#2465).

Set the working directory to the root of the user's repository to ensure
we respect the configuration.

---

This also allows the user to - intentionally or otherwise - exclude
packages that should be reported, causing false negatives. That seems
like an acceptable tradeoff, given that:

* For hermetic builds, the SBOM should still report everything that got
  in from outside, regardless of Syft configuration.
* We should assume some level of co-operation from the user, we don't
  have to design accurate SBOMs for users that actively sabotage the
  proces

Signed-off-by: Adam Cmiel <[email protected]>
chmeliik added a commit to chmeliik/build-definitions that referenced this issue Mar 1, 2024
STONEBLD-2095

Syft makes many things configurable:
https://github.com/anchore/syft#configuration

For example, users can take advantage of this to get rid of false
positives. This will be useful for the Syft build itself:
redhat-appstudio/rh-syft#21

Currently, our SBOM generation does not respect the user configuration.
Syft reads the config from the current working directory, not from the
target directory (anchore/syft#2465).

Set the working directory to the root of the user's repository to ensure
we respect the configuration.

---

This also allows the user to - intentionally or otherwise - exclude
packages that should be reported, causing false negatives. That seems
like an acceptable tradeoff, given that:

* For hermetic builds, the SBOM should still report everything that got
  in from outside, regardless of Syft configuration.
* We should assume some level of co-operation from the user, we don't
  have to design accurate SBOMs for users that actively sabotage the
  proces

Signed-off-by: Adam Cmiel <[email protected]>
chmeliik added a commit to chmeliik/build-definitions that referenced this issue Mar 4, 2024
STONEBLD-2095

Syft makes many things configurable:
https://github.com/anchore/syft#configuration

For example, users can take advantage of this to get rid of false
positives. This will be useful for the Syft build itself:
redhat-appstudio/rh-syft#21

Currently, our SBOM generation does not respect the user configuration.
Syft reads the config from the current working directory, not from the
target directory (anchore/syft#2465).

Set the working directory to the root of the user's repository to ensure
we respect the configuration.

---

This also allows the user to - intentionally or otherwise - exclude
packages that should be reported, causing false negatives. That seems
like an acceptable tradeoff, given that:

* For hermetic builds, the SBOM should still report everything that got
  in from outside, regardless of Syft configuration.
* We should assume some level of co-operation from the user, we don't
  have to design accurate SBOMs for users that actively sabotage the
  proces

Signed-off-by: Adam Cmiel <[email protected]>
chmeliik added a commit to chmeliik/build-definitions that referenced this issue Mar 5, 2024
STONEBLD-2095

Syft makes many things configurable:
https://github.com/anchore/syft#configuration

For example, users can take advantage of this to get rid of false
positives. This will be useful for the Syft build itself:
redhat-appstudio/rh-syft#21

Currently, our SBOM generation does not respect the user configuration.
Syft reads the config from the current working directory, not from the
target directory (anchore/syft#2465).

Set the working directory to the root of the user's repository to ensure
we respect the configuration.

---

This also allows the user to - intentionally or otherwise - exclude
packages that should be reported, causing false negatives. That seems
like an acceptable tradeoff, given that:

* For hermetic builds, the SBOM should still report everything that got
  in from outside, regardless of Syft configuration.
* We should assume some level of co-operation from the user, we don't
  have to design accurate SBOMs for users that actively sabotage the
  proces

Signed-off-by: Adam Cmiel <[email protected]>
chmeliik added a commit to chmeliik/build-definitions that referenced this issue Mar 5, 2024
STONEBLD-2095

Syft makes many things configurable:
https://github.com/anchore/syft#configuration

For example, users can take advantage of this to get rid of false
positives. This will be useful for the Syft build itself:
redhat-appstudio/rh-syft#21

Currently, our SBOM generation does not respect the user configuration.
Syft reads the config from the current working directory, not from the
target directory (anchore/syft#2465).

Set the working directory to the root of the user's repository to ensure
we respect the configuration.

---

This also allows the user to - intentionally or otherwise - exclude
packages that should be reported, causing false negatives. That seems
like an acceptable tradeoff, given that:

* For hermetic builds, the SBOM should still report everything that got
  in from outside, regardless of Syft configuration.
* We should assume some level of co-operation from the user, we don't
  have to design accurate SBOMs for users that actively sabotage the
  proces

Signed-off-by: Adam Cmiel <[email protected]>
chmeliik added a commit to chmeliik/build-definitions that referenced this issue Mar 6, 2024
STONEBLD-2095

Syft makes many things configurable:
https://github.com/anchore/syft#configuration

For example, users can take advantage of this to get rid of false
positives. This will be useful for the Syft build itself:
redhat-appstudio/rh-syft#21

Currently, our SBOM generation does not respect the user configuration.
Syft reads the config from the current working directory, not from the
target directory (anchore/syft#2465).

Set the working directory to the root of the user's repository to ensure
we respect the configuration.

---

This also allows the user to - intentionally or otherwise - exclude
packages that should be reported, causing false negatives. That seems
like an acceptable tradeoff, given that:

* For hermetic builds, the SBOM should still report everything that got
  in from outside, regardless of Syft configuration.
* We should assume some level of co-operation from the user, we don't
  have to design accurate SBOMs for users that actively sabotage the
  proces

Signed-off-by: Adam Cmiel <[email protected]>
chmeliik added a commit to chmeliik/build-definitions that referenced this issue Mar 7, 2024
STONEBLD-2095

Syft makes many things configurable:
https://github.com/anchore/syft#configuration

For example, users can take advantage of this to get rid of false
positives. This will be useful for the Syft build itself:
redhat-appstudio/rh-syft#21

Currently, our SBOM generation does not respect the user configuration.
Syft reads the config from the current working directory, not from the
target directory (anchore/syft#2465).

Set the working directory to the root of the user's repository to ensure
we respect the configuration.

---

This also allows the user to - intentionally or otherwise - exclude
packages that should be reported, causing false negatives. That seems
like an acceptable tradeoff, given that:

* For hermetic builds, the SBOM should still report everything that got
  in from outside, regardless of Syft configuration.
* We should assume some level of co-operation from the user, we don't
  have to design accurate SBOMs for users that actively sabotage the
  proces

Signed-off-by: Adam Cmiel <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
changelog-ignore Don't include this issue in the release changelog question Further information is requested
Projects
Archived in project
Development

No branches or pull requests

2 participants