-
Notifications
You must be signed in to change notification settings - Fork 30.1k
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
crypto: remove POINT_CONVERSION_HYBRID #4956
Conversation
Please note: this is different from my other pull requests in that it doesn't fix something. As a personal preference I like to try and keep cryptography options simple. I'm pretty sure that that path to this appearing in node.js was that Bodo implemented very general ECC support in OpenSSL 15 years ago, because things weren't settled then, and node.js supported everything that OpenSSL did because it's not clear which things have since been effectively discarded. As noted, I'm not aware of any use of hybrid encoding at all and thus seeing this happened to trigger a "wtf" reaction—hence this pull request. But if you feel that you don't want to trim exposed API then that would be completely reasonable. |
Adding the semver-major tag because this is a backwards incompatible change. LGTM on the technical side but it's hard to say what the fallout of this change would be. It's quite possible the answer is 'none at all'. CI: https://ci.nodejs.org/job/node-test-pull-request/1434/ /cc @nodejs/crypto |
LGTM |
@nodejs/crypto @nodejs/ctc ... hmm... as opposed to removing it outright, this may be something we want to take through a deprecation cycle first. We can deprecate in v6 and remove in v7. |
Virtual shrug. We could also just remove the option from the documentation without actually removing or deprecating it. |
openssl supports it on the commandline although I agree with the sentiment on simplifying and removing clutter that nobody actually uses, I'm just not sure how we'd get data on this one |
OpenSSL has it because it is defined in ANSI X9.62. Apparently the hybrid format has no use so that it might be gone in SEC1 spec. Probably no one has ever used it, however, on the conservative side for deprecation it is good to remove it in the doc at first. |
@agl ... ping. Can you update this to only remove the option from the docs as suggested? |
7da4fd4
to
c7066fb
Compare
@nodejs/documentation |
@agl ping |
Compressed points are already rare and, as far as I know, nobody has used the 'hybrid' format anywhere, ever. It's prohibited in X.509 certificates too[1]. This change removes mentions of it from the documentation in the interests of trying to pare-down the complexity of cryptography. [1] https://tools.ietf.org/html/rfc5480#section-2.2
Sorry about the delay. This pull request has now been updated to only remove mention of |
LGTM |
1 similar comment
LGTM |
The `format` arguments specifies point encoding and can be `'compressed'`, | ||
`'uncompressed'`, or `'hybrid'`. If `format` is not specified, the point will | ||
be returned in `'uncompressed'` format. | ||
The `format` arguments specifies point encoding and can be `'compressed'` or |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
either "argument specifies" or "arguments specify"
LGTM |
Compressed points are already rare and, as far as I know, nobody has used the 'hybrid' format anywhere, ever. It's prohibited in X.509 certificates too[1]. This change removes mentions of it from the documentation in the interests of trying to pare-down the complexity of cryptography. [1] https://tools.ietf.org/html/rfc5480#section-2.2 PR-URL: #4956 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com> Reviewed-By: Shigeki Ohtsu <ohtsu@iij.ad.jp Reviewed-By: James M Snell <jasnell@gmail.com>
Landed in f4aa2c2 .. fixed the last little nit when landing. |
Compressed points are already rare and, as far as I know, nobody has used
the 'hybrid' format anywhere, ever. It's prohibited in X.509
certificates too[1].
This change removes support for it in the interests of trying to
pare-down the complexity of cryptography.
[1] https://tools.ietf.org/html/rfc5480#section-2.2