Update package-lock.json

[jason-upchurch]

Summary (required)

• Resolves [GitHub] [High] Signature Malleabillity in elliptic (due 9/25/20) #4585 and [GitHub] [High] Arbitrary code execution in serialize-javascript (due 9/25/20) #4584

Update package-lock.json

How to test the changes locally

Reviewers

JS experts
@rfultz @johnnyporkchops @patphongs (any one will work)

Snyk vulnerability CLI experts
@fec-jli

Optional
@lbeaufort

Part 1: reproduce the report

• update develop branch
• snyk test --file=package-lock.json --dev
• verify that the elliptic and the serialize-javascript vulnerabilities are shown on screen (different name for the elliptic one, but same vulnerability as reported through GitHub)

Part 2: verify the fix

• check out this branch
• remove node_modules and package-lock
• npm i
• snyk test --file=package-lock.json --dev
• pytest
• run local api, check that data returns

[fec-jli]

Great job.
I reproduce the issue and see 4 high severity vulnerability issues raised.

after your change, elliptic and the serialize-javascript gone. Great.
the other 2 high severity vulnerability issues left there. Do we need address them?
or leave them alone for now? Thanks

[rfultz]

package-lock will be re-generated with npm i (and during deployment) based on what's in package.json. If we've already updated package.json and we're updating package-lock to keep in sync, cool

[jason-upchurch]

package-lock will be re-generated with npm i (and during deployment) based on what's in package.json. If we've already updated package.json and we're updating package-lock to keep in sync, cool

Thanks @rfultz ! Yeah, I didn't actually touch package.json--this package is only present as a dev dependency in package-lock. I suspect npm i generated the package-lock at the upgraded version possibly because the parent package introduced an upgrade.