Skip to content

Do not leak Object.prototype when checking for core modules #203

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

Merged
merged 2 commits into from
Nov 25, 2019

Conversation

nicolo-ribaudo
Copy link
Contributor

Context:

I'm trying to use Yarn 2 (with PnP) in Babel.
Babel depends on browserify, which depends on browser-resolve which depends on an older version of resolve without PnP support (1.1.7).

I tried to upgrade resolve in browser-resolve, but a test started failing because it checked for toString resolution.

Since this worked in resolve 1.1.7, was the behavior changed on purpose?

Copy link
Member

@ljharb ljharb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure why toString resolution would have changed; https://github.com/browserify/resolve/blob/master/lib/core.js#L49 should already prevent any prototype leaks - meaning that this change should not be needed to make the test here pass.

@nicolo-ribaudo
Copy link
Contributor Author

meaning that this change should not be needed to make the test here pass.

The test I added in this PR fails without the patch. It's because resolve uses core[x] to check for builtins, instead of only checking own properties.

https://github.com/browserify/resolve/blob/master/lib/core.js#L49 isn't enough, because Object.prototype properties are already present in core's prototype chain even before running that loop.

@ljharb
Copy link
Member

ljharb commented Nov 25, 2019

Gotcha. In that case, can we instead fix

async.isCore = function isCore(x) { return core[x]; };
and https://github.com/browserify/resolve/blob/master/lib/sync.js#L71 and https://github.com/browserify/resolve/blob/master/lib/sync.js#L78? (also the sync ones should probably call into the same isCore function on the main export)

@nicolo-ribaudo
Copy link
Contributor Author

Already done in e5b0494!

@ljharb ljharb force-pushed the core-modules-obj-proto branch from e5b0494 to 8da1a8f Compare November 25, 2019 21:20
@ljharb ljharb force-pushed the core-modules-obj-proto branch from 8da1a8f to c448d08 Compare November 25, 2019 21:34
Copy link
Member

@ljharb ljharb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

adding is-core makes this technically semver-minor :-) will merge into both master and 1.x, and release shortly.

@nicolo-ribaudo
Copy link
Contributor Author

Thanks!

Btw, upgrading this package in browser-resolve has also other problems (second point in browserify/browser-resolve#93 (comment)). If I find any other issue/regression in this package I'll probably open another PR 😛

@ljharb
Copy link
Member

ljharb commented Nov 25, 2019

hm, these go back prettttty far :-) but thanks, would be appreciated.

@ljharb ljharb merged commit c448d08 into browserify:master Nov 25, 2019
ljharb pushed a commit that referenced this pull request Nov 25, 2019
ljharb added a commit that referenced this pull request Nov 25, 2019
 - [New] add `is-core` export (#203)
 - [Fix] `sync`/`async` Do not leak Object.prototype when checking for core modules (#203)
 - [Dev Deps] update `eslint`
 - [Tests] fix symlink tests for windows
@ljharb
Copy link
Member

ljharb commented Nov 25, 2019

v1.13.0 released.

var core = require('./core');

module.exports = function isCore(x) {
return Object.prototype.hasOwnProperty.call(core, x);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unfortunately this introduced a bug into v1.13.0 (see #231), by changing this from a "truthy" check, to a "presence" check - and the "core" object relies on true/false to differentiate between a core module in some version of node, versus a core module in the current version of node. This was inadvertently fixed when I extracted this logic into https://npmjs.com/is-core-module.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants