json - npm Package Versions

Backward incompatible and security-related change to parsing the -d DELIM option. (#148)

The -d DELIM option allows specifying the field delimiter in output:

  % echo '{"name":"trent","age":38}' | json -a name age
  trent 38
  % echo '{"name":"trent","age":38}' | json -a name age -d,
  trent,38

The given "DELIM" string is parsed to allow escapes. For example:

  % echo '{"name":"trent","age":38}' | json -a name age -d'\t'
  trent	38
  % echo '{"name":"trent","age":38}' | json -a name age -d'\n'
  trent
  38

Before this change, that parsing used eval(), which allowed for unintended code execution if an untrusted argument to -d was provided. The fix for this vulnerability changes to use JSON.parse() to support escapes. However that results in a backward incompatible change, because the set of JSON escapes is a subset of JavaScript escapes.

The only escape I expect that would affect any current user would be the null byte escape (\0) which can be useful for processing values that may have spaces or other likely delimiter characters. For example:

  # BEFORE
  % echo '{"title":"Monsters, Inc.","year":"2001"}' \
    | json -a title year -d'\0' \
    | xargs -0 node -e 'console.log(process.argv)'
  [ 'node', 'Monsters, Inc.', '2001\n' ]

  # AFTER
  % echo '{"title":"Monsters, Inc.","year":"2001"}' | json -a title year -d'\0'
  json: error: Unexpected number in JSON at position 2

One must now use the JSON unicode escape syntax, '\u0000':

  % echo '{"title":"Monsters, Inc.","year":"2001"}' \
    | json -a title year -d'\u0000' \
    | xargs -0 node -e 'console.log(process.argv)'
  [ 'node', 'Monsters, Inc.', '2001\n' ]

Backward incompatible and security-related change to parsing "lookup" strings.

This version restricts the supported syntax for bracketed "lookup" strings to fix a possible vulnerability (CVE-2020-7712). With a carefully crafted lookup string, command injection was possible. See #144 for a repro. If you use json (the CLI or as a node.js module) and run arbitrary user-provided strings as a "lookup", then you should upgrade.

For the json CLI, a "lookup" string is the 'foo' in:

  echo ...some json... | json foo

which allows you to lookup fields on the given JSON, e.g.:

  $ echo '{"foo": {"bar": "baz"}}' | json foo.bar
  baz

If one of the lookup fields isn't a valid JS identifier, then the JS array notation is supported:

  $ echo '{"https://example.com": "my-value"}' | json '["https://example.com"]'
  my-value

Before this change, json would effectively exec the string between the brackets as JS code such that things like the following were possible:

  $ echo '{"foo3": "bar"}' | json '["foo" + 3]'
  bar

This change limits supported bracket syntax in lookups to a simple quoted string:

  ["..."]
  ['...']
  [`...`]      # no variable interpolation

Otherwise generating an error of the form:

  json: error: invalid bracketed lookup string: "[\"foo\" + 3]" (must be of the form ['...'], ["..."], or [`...`])

[issue #52] Fix termination on EPIPE in some cases.

Add -0, -2, -4 options to more conveniently set the JSON indentation without changing the mode.

[pull #64] Add -M, --items option for "itemizing" key/value pairs in an object for easy iteration. For example:

  $ echo '{"trent":{"age":38},
           "ewan": {"age":4}}' | json -M
  [
    {
      "key": "trent",
      "value": {
        "age": 38
      }
    },
    {
      "key": "ewan",
      "value": {
        "age": 4
      }
    }
  ]

  $ echo '{"trent":{"age":38},
           "ewan": {"age":4}}' | json -Ma key value.age
  trent 38
  ewan 4

  # List people that can vote.
  $ echo '{"trent":{"age":38},
           "ewan": {"age":4}}' | json -M -c 'this.value.age > 18' -a key
  trent

Thanks to AndrewO for providing this!

Backward incompatible change to -c CODE and -e CODE changing their implementation to use a JS function for processing rather than vm.runInNewContext. This is the technique for which the -C CODE and -E CODE options were added in version 7.0.0. Basically: This technique is obviously better because it is 10x faster, so it is being made the only supported way. -C and -E, then, become synonyms and may be removed in a later release.

Unfortunately this does mean a few semantic differences in the CODE, the most noticeable of which is that this is required to access the object fields:

  # Bad. Works with json < v9...
  $ echo '{"green": "eggs"}' | json-v8 -e 'green="ham"'
  {
    "green": "ham"
  }

  # ... does *not* work with json v9.
  $ echo '{"green": "eggs"}' | json -e 'green="ham"'
  {
    "green": "eggs"
  }

  # Good. Works with all versions of json.
  $ echo '{"green": "eggs"}' | json -e 'this.green="ham"'
  {
    "green": "ham"
  }

The old behaviour of -c and -e can be restored with the JSON_EXEC=vm environment variable:

  $ echo '{"green": "eggs"}' | JSON_EXEC=vm json -e 'green="ham"'
  {
    "green": "ham"
  }

See the notes on json 7.0.0 below for full details on the performance improvements and semantic changes.