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

Constraints in state objects #359

Closed
ghost opened this issue Apr 6, 2019 · 3 comments
Closed

Constraints in state objects #359

ghost opened this issue Apr 6, 2019 · 3 comments
Labels
2.1.0-CSD.1 Will be fixed in SARIF v2.1.0 CSD.1. enhancement impact-non-breaking-change merged Changes merged into provisional draft. resolved-fixed

Comments

@ghost
Copy link

ghost commented Apr 6, 2019

@kupsch made this suggestion in a comment on #168:

For many of the tools that I have seen that include flows or traversals, when explaining a flow or graph traversal state, they specify the value of an expression as a literal value (expressible in this current design), or as a constraint on the value (currently not not expressible). Such as

{
  "i":  "i < 5",
  "j":  "j >= 10 && j < 100",
  "p":  "p != NULL ",
  "r":  "r == NULL",
  "s":  "strlen(s) > 100",
  "t":  "buffer t is not NULL terminated"
}

This state constraint information that many tools report, could incorporate this without changing the schema by describing that a magic string value such as "{expr}" is used to represent a constraint expression. If "{expr}" exists in the value then it is a constraint (the value may substitute the actual expression for {expr}. If "{expr}" does not exist in the value then this is an equality constraint equivalent to "{expr} == VALUE" where VALUE is the value of the JSON property.

The above constraints would then become a state object of

{
  "i":  "{expr} < 5",
  "j":  "{expr} >= 10 && {expr} < 100",
  "p":  "{expr} != NULL ",
  "r":  "NULL",
  "s":  "strlen({expr}) > 100",
  "t":  "buffer {expr} is not NULL terminated"
}

For viewer just displaying the values above would probably be deciphered with the correct meaning by most developers, and advanced viewers could do more to indicate a general constraint instead of just equality.

@ghost ghost self-assigned this Apr 6, 2019
@ghost ghost added 2.1.0-CSD.1 Will be fixed in SARIF v2.1.0 CSD.1. enhancement impact-non-breaking-change to-be-written labels Apr 6, 2019
@ghost
Copy link
Author

ghost commented Apr 6, 2019

This is a non-breaking change and I have time to take care of it, so I will.

@ghost ghost changed the title Arbitrary expressions in state objects Constraints in state objects Apr 6, 2019
@michaelcfanning
Copy link
Contributor

@lgolding, shouldn't these all be string to multiformat string dictionaries? what happens when someone gets to the place where they want to render this content as markdown otherwise?

we should probably do a quick sanity check in the schema for this situation...

@ghost
Copy link
Author

ghost commented Apr 7, 2019

I can certainly see wanting to bold part of an expression, or to render "expr" in italics. I take it you're willing to accept the break. (Jim's proposal as written was non-breaking.)

@ghost ghost added merged Changes merged into provisional draft. resolved-fixed and removed to-be-written labels Apr 8, 2019
@ghost ghost closed this as completed Apr 8, 2019
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2.1.0-CSD.1 Will be fixed in SARIF v2.1.0 CSD.1. enhancement impact-non-breaking-change merged Changes merged into provisional draft. resolved-fixed
Projects
None yet
Development

No branches or pull requests

1 participant