Skip to content
This repository has been archived by the owner on Apr 22, 2023. It is now read-only.

tls: throw an error on getLegacyCipher #14572

Closed
wants to merge 7 commits into from

Conversation

jasnell
Copy link
Member

@jasnell jasnell commented Apr 8, 2015

throw an error on unknown getLegacyCipher input
rather than returning the default. Makes the
behavior more explicit and matches up with the
behavior on the command line switches.

@jasnell
Copy link
Member Author

jasnell commented Apr 14, 2015

@misterdjules @mdawsonibm

@misterdjules
Copy link

Can we add a test to make sure that getLecagyCiphers throws/doesn't throw as expected?

@misterdjules misterdjules added this to the 0.10.39 milestone Apr 14, 2015
jasnell added a commit to jasnell/node-joyent that referenced this pull request Apr 14, 2015
jasnell added a commit to jasnell/node-joyent that referenced this pull request Apr 14, 2015
@jasnell
Copy link
Member Author

jasnell commented Apr 14, 2015

Done

jasnell added a commit to jasnell/node-joyent that referenced this pull request Apr 14, 2015
@misterdjules
Copy link

@jasnell Do we want to throw an error on a call to getLegacyCiphers() when the first parameter passed is not a string (undefined, null or anything else that is not a string)? The error message would be different, instead of 'Error: Unknown legacy cipher list', it would be something like 'Error: getLegacyCiphers requires a string as first parameter".

Also, I think we miss the "full" documentation for the getLegacyCiphers function in the API docs, including what the parameter is, its type, etc. Currently it is only briefly mentioned in the Modifying the Default Cipher Suite section.

@jasnell
Copy link
Member Author

jasnell commented Apr 15, 2015

@misterdjules ... PR updated to address feedback.

@jasnell
Copy link
Member Author

jasnell commented Apr 15, 2015

#15445 @misterdjules

@misterdjules
Copy link

@jasnell Thank you, I think that's a significant improvement! 👍

@mhdawson
Copy link
Member

One minor nit. Should the tests validate the type of the Error, ie a TypeError or an Error as appropriate ? Otherwise lgtm.

@jasnell
Copy link
Member Author

jasnell commented Apr 22, 2015

/cc @mhdawson @misterdjules ok, please check the two additional commits. if these look good I'll squash the pr down and land.

// Test NODE_LEGACY_CIPHER_LIST takes precendence over --cipher-list
args.unshift('--cipher-list=XYZ');
if (env) options = {env:{"NODE_LEGACY_CIPHER_LIST": env}};
break;

Choose a reason for hiding this comment

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

We would probably need to have more tests than that to test the whole matrix of command line switches and environment variables. I would do that in a separate PR though, as this one is about ls: throw an error on getLegacyCipher.

@misterdjules
Copy link

@jasnell I think @mhdawson meant that we should check for the type of the error thrown by tls.getLegacyCiphers. I didn't see anything related to that in the latest two commits.

I would not add a lot to this PR so that we can reason about it easily and land something reasonably quickly. We can work on other aspects of ciphers list related changes in other PRs.

Thank you again very much for your work!

@jasnell
Copy link
Member Author

jasnell commented Apr 22, 2015

@misterdjules after talking with @mhdawson today, I realize now that I missed an important aspect of your discussion with him regarding the order of precedence on the command line switches and environment variables, as well as the error type check in test test case. I'm going to make those additional changes and squash these PR's down this evening with the goal of landing them by Friday.

This commit squashes down several previous commits on this change
to clean up before landing. There are several changes to the
new cipher list command line switches:

1. It includes the type checking fix on getLegacyCiphers
2. It has the command line switches override the environment
   variables
3. It documents it order of precedence
4. Expands the test case to test for order of precedence
test that the type of error thrown is correct
@jasnell
Copy link
Member Author

jasnell commented Apr 23, 2015

@misterdjules @mhdawson ... ok the changes discussed have been made and the multiple commits have been squashed down into two distinct commits.

Fix a minor typo in the tls.markdown and add additional
precedence tests in test-tls-cipher-list
Per the feedback from Julien, refactor the test-tls-cipher-list
test to avoid using the confusing switch statement. Add tests
to ensure that using `--enable-legacy-cipher-list=v0.10.38`
or `NODE_LEGACY_CIPHER_LIST=v0.10.38` disables the use of the
default cipher list but setting the `--cipher-list` equal to
the v0.10.38 list explicitly does not.

Minor refactor to tls.js to ensure the above behavior.
@@ -1338,7 +1352,8 @@ exports.connect = function(/* [port, host], options, cb */) {
var defaults = {
rejectUnauthorized: '0' !== process.env.NODE_TLS_REJECT_UNAUTHORIZED
};
if (DEFAULT_CIPHERS != _crypto.getLegacyCiphers('v0.10.38')) {
if (!usingV1038Ciphers()) {

Choose a reason for hiding this comment

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

Maybe add a comment to clarify why there's an exception for v0.10.38 here? Otherwise I'm concerned it's going to be difficult to understand a few months/years from now.

// test the right-most command line option takes precedence
doTest('XYZ',
[
'--cipher-list=XYZ',

Choose a reason for hiding this comment

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

Do we want another value for the first --cipher-list command line switch (e.g ABC)? Otherwise how do we know that the value for ciphers list was taken from the second --cipher-list and not the first one?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, actually that's just a typo... it should have been different

@misterdjules
Copy link

@jasnell Added a few comments, but it's definitely getting better, thank you!

Per the latest round of feedback from julien.
Fix a couple of typos, add some explanatory text,
refactor the test case.
@@ -19,36 +19,21 @@
// OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
// USE OR OTHER DEALINGS IN THE SOFTWARE.

var spawn = require('child_process').spawn;
var spawn = require('child_process').spawn;

Choose a reason for hiding this comment

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

Style: the current style used does not align the = operator for assignment statements.

@jasnell
Copy link
Member Author

jasnell commented May 9, 2015

@misterdjules @mhdawson

@misterdjules
Copy link

@jasnell Thank you, I'll take a look on Sunday!

@@ -4199,12 +4199,18 @@ const char* ToCString(const node::Utf8Value& value) {

Handle<Value> DefaultCiphers(const Arguments& args) {
HandleScope scope;
unsigned int len = args.Length();
if (len != 1 || !args[0]->IsString()) {
return ThrowException(Exception::TypeError(String::New("A single string parameter is required")));

Choose a reason for hiding this comment

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

Style: wrap at 80 columns.

@jasnell
Copy link
Member Author

jasnell commented May 12, 2015

@misterdjules ... I'll refactor that last test to split things out more. No problem there. Will see if I can get that in this morning. Beyond that, are there any other remaining issues on this?

Refactor the default cipher list test to separate
concerns a bit, make the test clearer based on
Julien's feedback.

Also, fix the 80-char wrap issue in the related
node_crypto.cc DefaultCiphers method.
@jasnell
Copy link
Member Author

jasnell commented May 12, 2015

@misterdjules

@misterdjules
Copy link

@jasnell I would like to come up with a good solution for #23947 too, and add support for the new command line switches in test/external/ssl-options. I can add that since I'm familiar with how this test works.

We don't have to rush it though. As we discussed during the latest weekly meeting, if we want to release v0.12.3 before these changes are ready, we can revert the work in progress in v0.12 and include them back in time for the next v0.12.4 release.

@jasnell
Copy link
Member Author

jasnell commented May 12, 2015

Yes, I'm going to look at that one tonight again
On May 12, 2015 1:11 PM, "Julien Gilli" notifications@github.com wrote:

@jasnell https://github.com/jasnell I would like to come up with a good
solution for #23947 #23947 too, and
add support for the new command line switches in test/external/ssl-options.
I can add that since I'm familiar with how this test works.

We don't have to rush it though. As we discussed during the latest weekly
meeting, if we want to release v0.12.3 before these changes are ready, we
can revert the work in progress in v0.12 and include them back in time for
the next v0.12.4 release.


Reply to this email directly or view it on GitHub
#14572 (comment).

@misterdjules
Copy link

Moving to milestone v0.10.40, as v0.10.39 was released today.

@misterdjules
Copy link

Closing in favor of #25603.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants