fix(merge): Avoid protototype pollution when parsing properties

[benoitf]

What it does

Avoid prototype pollution

How to test

Tests should pass
But you can try using configuration of plug-ins on workspace level and user level and see that merge correctly happen

Review checklist

• as an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• as a reviewer, I agree to behave in accordance with the review guidelines

[paul-marechal]

LGTM, thanks for the fix!

[max-schaefer]

Does this also guard against prototype pollution via .constructor.prototype, or is that not possible in this context? (Note that {}.constructor.prototype === Object.prototype.)

[benoitf]

I updated test case with constructor (it seems it's only affecting parseConfigurationData method)
@marechal-p if you can review again (I pushed a new commit)

[paul-marechal]

There was an unescaped . in the regexp. I pushed the fix for this and also used Object.create(null) where it made sense. I don't see anything else, feel free to squash and merge.

[benoitf]

@marechal-p would be nice to have it in the upcoming release

[paul-marechal]

@benoitf it will since it looks like a complete fix now :)

[paul-marechal]

@max-schaefer please tell us if you still see something, we can do a patch release in the worst case.

We'll now proceed with the 1.7.0 release.

[max-schaefer]

LGTM

it seems it's only affecting parseConfigurationData method

Yes, that sounds plausible. The other method has an isObject check, which will prevent the .constructor.prototype vector, since .constructor is a function.