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

csaf_checker fails in jsonPath without referencing the input data it fails on #24

Closed
tolim opened this issue Jan 11, 2022 · 7 comments
Closed
Assignees

Comments

@tolim
Copy link

tolim commented Jan 11, 2022

When trying to check a domain with the csaf_checker, I get the following error message:

$ ./csaf_checker www.domain.com
2022/01/11 15:51:08 error: no document to extract data from

Why does the command fail?

Thanks in advance!
Tobi

@bernhardreiter
Copy link
Collaborator

Hi @tolim
note that we are still "work in progress", so some stuff may still fail or be suboptimal.

The failure comes from a call to

func (p *processor) jsonPath(expr string, doc interface{}) (interface{}, error) {
if doc == nil {
return nil, errors.New("no document to extract data from")

So I guess that some required attribute is missing from the provider-metatdata.json file.

We'll take this as a hint to add more diagnostic messages.
Thanks for the feedback!
Bernhard

@bernhardreiter bernhardreiter changed the title Support for use of csaf_checker required csaf_checker fails in jsonPath without referencing the input data it fails on Jan 12, 2022
@s-l-teichmann
Copy link
Collaborator

s-l-teichmann commented Jan 12, 2022

The decoding of the metadata fails earlier, but this error is wrongly rated as none essential and is only written to the report.
The analysis continues and dies later as the invariant of having the document loaded is not fulfilled.
The report then is never written out so that the reason of the error vanishes into nowhere.

I'm going to fix this.

s-l-teichmann added a commit that referenced this issue Jan 12, 2022
…tion pointless.

Fixes issue #24.

TODO: Improve handling of checks that are not run due to the stop.
They currently report success which is not correct.
@s-l-teichmann
Copy link
Collaborator

PR #26 introduces a mechanism to stop a running domain check and still dump out the report. This needs some work because the parts of the check which do not run due to the stop are currently marked as successful. This is not correct.

@tschmidtb51
Copy link
Collaborator

I was stumbling upon

url := "https://" + domain + "/.well-known/csaf/provider-metadata.json"
use(&p.badProviderMetadatas)
res, err := client.Get(url)

but I might be on the wrong track:

The provider-metadata.json can be found either

More than one may exist, however to be valid at least one MUST exist... Even though the .well-known path is preferred it is not the only option here.

@bernhardreiter
Copy link
Collaborator

I suggest we make the location of the provider-metadata.json a new issue and refer to 7.2.2: "satisfies at least one of the requirements 8 to 10"

As far as I know, the first issue here is improved: we get a diagnostic message now with current main.

@tschmidtb51
Copy link
Collaborator

I suggest we make the location of the provider-metadata.json a new issue and refer to 7.2.2: "satisfies at least one of the requirements 8 to 10"

Sounds good to me.

@bernhardreiter
Copy link
Collaborator

The situation has improved. A call like

./bin-linux-amd64/csaf_checker example.org

now contains the following in the output:

  "domains": [
    {
      "name": "example.org",
[..]
         "description": "provider-metadata.json",
          "messages": [
            "No provider-metadata.json found.",
            "STOPPING here - cannot perform other checks."

So we believe this issue to be resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants