crypto: deprecate aliases for randomBytes

[tniessen]

There are three aliases for crypto.randomBytes now, all of them are undocumented. I think we should strive to have as little undocumented API surface as possible, so the next logical step would be to either document or deprecate these aliases.

crypto.pseudoRandomBytes used to be a different function but became an alias for crypto.randomBytes in #557 (three years ago). It has been undocumented ever since and is rarely used within the ecosystem.

The other two aliases, crypto.rng and crypto.prng have never been documented as far as I can tell and their names are unintuitive for people who are not familiar with crypto and the concept of CSRNGs / CSPRNGs.

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

[nodejs-github-bot]

@tniessen build started: https://ci.nodejs.org/blue/organizations/jenkins/node-test-pull-request-lite-pipeline/detail/node-test-pull-request-lite-pipeline/669/pipeline

[tniessen]

cc @nodejs/crypto @nodejs/security-wg

Deprecation was suggested back in #557 by the way.

[tniessen]

CI: https://ci.nodejs.org/job/node-test-pull-request/16750/
Resumed in: https://ci.nodejs.org/job/node-test-pull-request/16751/
Resumed in: https://ci.nodejs.org/job/node-test-pull-request/16758/

[ryzokuken]

LGTM.

[Trott]

Nit: has been -> is for consistency with the rest of the deprecation messages (with one exception that should also be changed but not in this PR).

[mcollina]

LGTM

[mcollina]

@dougwilson which module is that? why is it doing that check?

[mcollina]

@dougwilson I would release a new major version of that module, and drop support for Node < 4 (even Node < 6). However, you could still detect this without version checking via crypto.propertyIsEnumerable('pseudoRandomBytes'). It will tell you if the property is there and it has not been deprecated. Let me know if you would like to get a PR with this fix.

Note that when this land any user of random-bytes would see the warning.

[mcollina]

As for the warning, wouldn't the warning only occur on calling the method? The module doesn't call the method, just checks equality.

My bad.

[mcollina]

As for that check, I can do that. I read through the docs on deprecate and it didn't say that was a method to detect, so if that's the official way to detect if something is deprecated, I can make a PR to add it to the docs and make a test to add to the Node.js test suite

I would say go for it.

[mcollina]

Can you please add a comment:

// The ecosystem needs those to exists for backwards compatibility with// ancient Node.js runtimes (0.10, 0.12).

[tniessen]

Added it. IMO this kind of makes it sound as if we couldn't remove these functions in the future though.

[mcollina]

Exactly, this is the sound of #22519 (comment) comment.

[tniessen]

that point of the module is to provide that back-compat, so releasing a new major version without it is kind of pointless -- modules can just use Node.js API directly if they didn't need that. SO making that change doesn't make any sense.

@dougwilson Thanks for weighing in! Are you sure that people are still using that package for backcompatibility? The only Node.js releases which require this kind of check are from 2015 or even older and have long been EOL. Maybe people just want to use promises?

[tniessen]

Are you sure that people are still using that package for backcompatibility? The only Node.js releases which require this kind of check are from 2015 or even older and have long been EOL. Maybe people just want to use promises?

How can I make this determination?

@dougwilson I don't know. Your previous comment suggested that backcompatibility was the primary intention of people using the package, but I'd be surprised if that was true. There are barely any packages depending on random-bytes, so maybe the majority of downloads is caused by people using uid-safe?

It is cool that packages such as yours try to support "ancient" versions as @mcollina called them, but that shouldn't stand in the way of improving Node.js.

[tniessen]

@dougwilson I am sorry for the misunderstanding, this was in no way directed at you! This was entirely based on #22519 (comment), which suggests that we cannot remove these functions.

[thefourtheye]

Nit: exists -> exist?

[tniessen]

Rebased, old HEAD was 8a304fe59a87cf8be7e0a804c860d017b91375ab.

[tniessen]

Landed in 221df22.

[targos]

This affects a module used by npm: https://github.com/npm/unique-slug
I have Node canary on my system and get a warning when I install git dependencies.

[tniessen]

@targos I opened npm/unique-slug#6.

[Trott]

The deprecation warning causes an npm test to fail, at least when run via our make test-npm task.

 # Subtest: tarball paths should update port if updating protocol not ok 1 - no error output --- found: > (node:51947) [DEP0115] DeprecationWarning: crypto.pseudoRandomBytes is deprecated. wanted: '' compare: === at: line: 75 column: 9 file: test/tap/add-named-update-protocol-port.js type: global

Hopefully npm/unique-slug#6 can land soon, but if not, I wonder if we should document pseudoRandomBytes() as an alias for randomBytes() and move it back to doc-only deprecation.

We could also consider the Buffer constructor route and only produce a runtime warning on use outside of node_modules.

Updating the npm test somehow may also be an option, I suppose, although it's not obvious to me how in this case, as the whole point of this test is probably to check that there isn't stderr output on success.

[tniessen]

@Trott I think npm/unique-slug#6 should land even if we un-deprecate pseudoRandomBytes. It has been open for four months now...

I am +0.5 on the deprecation itself. I suggested documentation as an alternative, but I still prefer the deprecation.

[addaleax]

Aliases are very cheap, and if this adds a deprecation warning to npm output in some cases, I’d prefer to undo the deprecation (or make it a --pending-deprecation-only thing)

[tniessen]

I’d prefer to undo the deprecation (or make it a --pending-deprecation-only thing)

@addaleax I think you already did that in #23017 :)

[addaleax]

@tniessen oh, ha 😄 Is there actually anything to do for us then? Does the npm test still fail without --pending-deprecation?

[Trott]

Does the npm test still fail without --pending-deprecation?

Oh, right, I have --pending-deprecation on by default. Let's try make test-npm without it...

Heh, the test still fails on master but not because of this. It's instead because it gets this warning:

npm WARN npm npm does not support Node.js v12.0.0-pre

The test in question is making sure that there are no warnings emitted. So as-is, I suppose it will always fail on master. Wonder if we should make it an expected failure in our wrapper or if the test itself should be updated to be tolerant about -pre releases. Or maybe there's a way to invoke npm such that it suppresses only that warning?]

EDIT: Will be solved by updating core's npm from 6.5.0-next to 6.5.0. So: There's no problem.