Hi,

The whitesource scan detected following vulnerability on set-value package:

Name: CVE-2019-10747
Description: A vulnerability was found in set-value before 2.0.1 and from 3.0.0 before 3.0.1 previously reported as WS-2019-0176
Publish date: 2019-07-24
Resolution: Upgrade To Version 2.0.1,3.0.1

I had upgraded set-value to version 3.0.1 but still whitesource scan shows above mentioned vulnerability. Can you please check if this vulnerability still exist in latest version and can you please resolve it?

Thanks and regards,
Joginder

setValue({}, 'list.0', 12) //{ list: {0: 12} }

Shouldn't it return { list: [12] } ?

Took me awhile to track this down to your package :).

I am using set-value to set a setter that's calling a rxjs next like so.

    Object.defineProperty(parent, name, {
      configurable: true,
      enumerable: true,
      get () {
        return rx.value
      },
      set (value) {
        rx.value = value
        rx.obs.next({value:value, path:path})
        self.emit(opts.event || self._rx_.event,{value:value, path:path})
        self.emit(path,value)
        self._rx_.hooks.forEach(hook=>hook.call(self,{value:value, path:path}))
      }
    })

In your code the "final" target[prop] (not the parent) is assigned a {} which after call to result is reset to the passed value. Normally no one would notice this double assignment except of course if you happen to be observing that assignment via a setter and a subscription.

    if (!isObject(target[prop])) {
      target[prop] = {};
    }

    if (i === len - 1) {
      result(target, prop, value, merge);
      break;
    }

it looks like this in my observer subscription handler an throws errors down th e line in my code cause it was expecting a primitive value not {}.

observed set value { value: {}, path: 'some.thing' }
observed set value { value: 'value that was to be set', path: 'some.thing' }

So I simply flopped the order

    if (i === len - 1) {
      result(target, prop, value, merge)
      break
    }

    if (!isObject(target[prop] && len)) {
      console.log('not object, set empty')
      target[prop] = {}
    }

and voila no assignment to {} first. Just the one firing of my observer.

Doesn't seem like this would cause any other issue in doing this and will eliminate an unnecessary conditional and assignment.

I'll fork, make this change, run your tests and submit pr.

also kinda wondering if
if (merge && isPlain(target[path]) && isPlain(value)) {
might not work as intended if isPlain doesn't resolve the setter to see if it contains a plain object or not. (i.e it thinks it's not cause it's a setter)

Would it make sense to replace the dependency on is-plain-object with:
const isPlain = obj => typeof obj === 'object'; ?

This would reduce the total number of dependencies to zero, which is always a great aim on itself.

get-value supports get(obj, 'e[0].f'). See jonschlinkert/get-value#4
But set-value does not create an array given set(obj, 'e[0].f', 'g').
It returns { 'e[0]': { f: 'g' } }.

Hey there!

I'd like to report a security issue but cannot find contact instructions on your repository.

If not a hassle, might you kindly add a SECURITY.md file with an email, or another contact method? GitHub recommends this best practice to ensure security issues are responsibly disclosed, and it would serve as a simple instruction for security researchers in the future.

Thank you for your consideration, and I look forward to hearing from you!

(cc @huntr-helper)

please check assignment value for date, regex and maybe others which i forgot

Hi, I have been getting issues when trying to use this library.

The overall code works as it should.

However, I have some issues with the following.
The code is trying to set the property that I passed in to be an object if it is not an object. The property is an integer at the moment, and it stores the previous value that I have set.

for (let i = 0; i < len; i++) {
  let prop = keys[i];

  if (!isObject(target[prop])) {
    target[prop] = {};
  }

  if (i === len - 1) {
    result(target, prop, value, merge);
    break;
  }

  target = target[prop];
}

With this, the private value that I saved in my class, is going to be NaN instead, before it is being set to the correct value on the next parse.

So if I were to compare the previous value with the new value in my class object, it's going to see it as NaN instead of an integer that was previously set.

Hi,

According to some public reports (i.e GHSA-4jqc-8m5r-9rpr, https://www.cve.org/CVERecord?id=CVE-2021-23440)
,CVE-2021-23440 is fixed in 4.0.1 along with a backport to 2.0.1.

As is understand, this is the fix for 4.0.1: 383b72d
That was reached via 4.0.0...4.0.1.

However, when inspecting the changelog between 2.0.0 and 2.0.1 (2.0.0...2.0.1), it seems the fix for CVE-2021-23440 does not exist. This commit cb12f14 seems to be the fix for CVE-2019-10747, while CVE-2021-23440 states that CVE-2019-10747 is bypassed.

When inspecting it even furtherly, there is a pull request for fixing 2.0.1 #38, but it was not merged neither in the GH repo nor the NPM package itself.

Can you confirm the vulnerable range and the fix here (CVE-2021-23440)? It raises some confusion and I would like to make sure 2.0.1 is safe.

Thanks in advance!

Hey,

There is an error: set(null, 'a.b', 'c'); call throws TypeError: Cannot read property 'a' of null

Fix: #13

// argsPath = [ '505', '508' ]
set(obj, argsPath, metrics);

returns:
{
"505": [
null,
null,
null,
null,
null,
null,
null,
null,
(508 times null) ]
}

P.S. it wasworking on on version 3.0.2

because this is possible currently and it fails on escape split

var set = require('set-value')
var obj = {}
set(obj, true, 'foo')
console.log(obj)

throws

/home/charlike/dev/node_modules/set-value/index.js:48
  return str.split('\\.').join(nc[1]);
             ^

TypeError: str.split is not a function

This is my tree structure of set-value :

i want to upgrade it to 4.0.1

i tried to update set-value with latest and its parent packages but issue is still not resolved.

Hi, there

Since our team recently upgraded set-value from v3 to v4, we found there's a severe problem dealing with numeric path.
before v4 paths are treated as properties, so it worked as expected like the following example

but since array index supported in v4, path contains numbers that causes target object's value transformed into an array anyway, and all its properties are gone.

the root cause might be on

I made a codesandbox to reproduce this issue, versions switch is available on the left panel, please let me know if any further information is needed

There's already another similar library called object-path, just FYI

Hi ,

I am facing

18186 verbose stack Error: 403 Requested item is quarantined: set-value@http://nexus/repository/npmpublic/set-value/-/set-value-2.0.1.tgz ..

I am using angular :^6.0.1 and i have explicitly added set-value:^3.0.1.! After npm install i am facing same issue again

Hi there, any chance of releasing patch versions with the security fix for the older major versions? Many very popular libraries depend on ^2.0.0 or even 0.X. Thanks!

I'm missing an option to insert value into Array instead of overwriting the existing value. Similar to the merge option that currently exists for Objects. Something like:

obj = {"path": {"to": {"array": ["oldValue"]}}}
set(obj, ["path", "to", "array", 0], "newValue", { insert: true ))

console.log(obj)
{"path": {"to": {"array": ["newValue", "oldValue"]}}}

I checked out the related projects but did not find a way to do this, please let me know if I missed something.

I am asking for the immutability to implement this with redux.
Thanks for the awesome work!!

What you think about to force set-value to only create values if they not exists in object?
And we can use tunnckoCore/put-value(s) to only update values if they exist in the given object.

I've also created del-value (which also works as reset for deletion and will push up in a bit put-values and del-values

Brief

tunnckoCore/del-value - del(obj, key)

• if key not string or array returns original obj
• if obj is not an object return empty object

tunnckoCore/del-values - del(obj, key)

• where key can be array of dot notation paths

tunnckoCore/put-value - put(obj, key, value)

• updates value of key only if key exists
• updates only existing values of obj when object is given to key (like assign-deep)
• because set-value update values if exist and add if not exist
• returns original object if key is not an object or string
• returns empty object if obj is not an object
• returns modified object otherwise

tunnckoCore/put-values - put(obj, key, value)

• where key can be array of dot notation paths, as seen in del-value for now

set-value proposal - set(obj, key, value)

• sets value only if it not exist in obj
• if key is object, extend obj without overwriting existing values (like defaults-deep)

And all that because im writing tunnckoCore/store-cache (i'll push up in a bit) in which i want to have different methods for different behaviors - store, set, get, put, del, has. At the moment it mostly looks like option-cache but with different idea and behaviors.

Node sure how out-of-date your benchmarking package is, but it doesn't seem to want to run, something about the file globbing just not working

C:\Git\set-value\benchmark>node .
Error: ENOENT: no such file or directory, open 'C:\Git\set-value\benchmark\fixtures\*.js'
    at Object.openSync (node:fs:585:3)
    at Object.readFileSync (node:fs:453:35)
    at Benchmarked.toFile (C:\Git\set-value\benchmark\node_modules\benchmarked\index.js:66:22)
    at Benchmarked.toFile (C:\Git\set-value\benchmark\node_modules\benchmarked\index.js:118:18)
    at Benchmarked.addFile (C:\Git\set-value\benchmark\node_modules\benchmarked\index.js:173:17)
    at Benchmarked.addFiles (C:\Git\set-value\benchmark\node_modules\benchmarked\index.js:199:14)
    at Benchmarked.addFixtures (C:\Git\set-value\benchmark\node_modules\benchmarked\index.js:266:8)
    at Benchmarked.defaults (C:\Git\set-value\benchmark\node_modules\benchmarked\index.js:84:10)
    at new Benchmarked (C:\Git\set-value\benchmark\node_modules\benchmarked\index.js:48:8)
    at C:\Git\set-value\benchmark\node_modules\benchmarked\index.js:439:19 {
  errno: -4058,
  syscall: 'open',
  code: 'ENOENT',
  path: 'C:\\Git\\set-value\\benchmark\\fixtures\\*.js'
}

Would love to be able to run the benchmarks myself and potentially add some others to see how this library stacks up

Node 16.13.1
NPM 8.1.2
Tried in both Command Prompt/Git Bash shells
Windows 10

EDIT:
so it works on WSL, just not Windows. is there a reason why a node script (which I assume should be cross-platform) doesn't work on Windows?

console.log(setValue({}, "{a..b}.c", "d"));
// => { '{a': { '': { 'b}': [Object] } } }

I don't think this should be the result.

Some test cases you may want to add.

https://replit.com/@trajano/lodash#index.js

const _ = require('lodash');
const set = require('set-value');

const spec = {
  a: "foo",
  b: { x: 12, y: 11 },
  c: [
    { x: 11, y: 11 },
    { x: 22, y: 22 },
    // for keys that are strings which are 
    // reserved so simple splits can't be used
    { "foo[0].1": 22, "e.y": 22 }, 
  ],
};

console.log(spec)

const c = _.cloneDeep(spec)
_.set(c, 'b.x', 99);
_.set(c, 'c[1].y', 99);
_.set(c, "c[2]['foo[0].1']", 199);
console.log(c)

const d = _.cloneDeep(spec)
set(d, 'b.x', 99);
set(d, 'c[1].y', 99);
set(d, "c[2]['foo[0].1']", 199);
console.log(d)

Escaping not working for keys with slash on the end:

'a.b\\\\.c.d' => ['a', 'b\\.c', 'd']

instead of

'a.b\\\\.c.d' => ['a', 'b\\', 'c', 'd']

I see a number of warnings from yarn audit because some project dependencies still rely on set-value v2 and v3. While it’s technically possible to force-install v4 via package.json → resolutions, it’s not clear whether that’s a save move or not.

It’d be great if the repo had CHANGELOG.md, UPGRADING.md, MIGRATION.md or info on the Releases page. If major versions are only related to supported Node versions or some rare edge cases, library users can make informed decisions to force-upgrade from v2 or v3.

Examples: jest → CHANGELOG.md & Releases, sentry-javascript → MIGRATION.md & Releases

Related to #38 & #39