Skip to content
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: only try to set FIPS mode if different #12210

Merged
merged 1 commit into from
Sep 26, 2017

Conversation

gibfahn
Copy link
Member

@gibfahn gibfahn commented Apr 4, 2017

Turning FIPS mode on (or off) when it's already on (or off) should be a
no-op, not an error.

Fixes: #11849

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
Affected core subsystem(s)

crypto (FIPS)

Patch shamelessly stolen from @bnoordhuis here. PR'd to remind myself to test this properly.

@gibfahn gibfahn added crypto Issues and PRs related to the crypto subsystem. wip Issues and PRs that are still a work in progress. labels Apr 4, 2017
const bool enabled = FIPS_mode();
const bool enable = args[0]->BooleanValue();
if (enable == enabled)
return; // No action needed.
if (force_fips_crypto) {
Copy link
Member

Choose a reason for hiding this comment

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

Given this change, should we also only throw if attempting to turn FIPS off when force_fips_crypto is on? Turning it on should likely just non-op

Copy link
Member Author

@gibfahn gibfahn Apr 4, 2017

Choose a reason for hiding this comment

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

@jasnell if force_fips_crypto is on, then FIPS_mode() should already be enabled right? So doesn't the if (enable == enabled) branch already cover that?

Copy link
Member

Choose a reason for hiding this comment

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

good point. ok

Copy link
Member

@richardlau richardlau left a comment

Choose a reason for hiding this comment

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

Needs tests (marking so this doesn't land without them).

Copy link
Member

@mhdawson mhdawson left a comment

Choose a reason for hiding this comment

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

LGTM

@BridgeAR
Copy link
Member

@gibfahn would you be so kind and add some tests for this?

@gibfahn gibfahn self-assigned this Sep 2, 2017
@BridgeAR BridgeAR added the stalled Issues and PRs that are stalled. label Sep 12, 2017
@BridgeAR
Copy link
Member

Ping @gibfahn

@BridgeAR
Copy link
Member

Closing due to long inactivity. @gibfahn please reopen if you still want to pursue this.

@gibfahn
Copy link
Member Author

gibfahn commented Sep 24, 2017

Note to self, if a PR is closed, don't push to the branch before reopening the PR. If you do it's undoable as long as you force-push back to the commit hash the branch pointed to when the PR was closed.

@gibfahn gibfahn removed wip Issues and PRs that are still a work in progress. stalled Issues and PRs that are stalled. labels Sep 24, 2017
@gibfahn
Copy link
Member Author

gibfahn commented Sep 24, 2017

Added a test to confirm that enabling fips when --force-fips is set is a no-op. There are already tests covering everything else AFAICT.

PTAL.

['--force-fips'],
compiledWithFips() ? FIPS_ENABLED : OPTION_ERROR_STRING,
'(require("crypto").fips = true,' +
'require("crypto").fips)',
Copy link
Member

Choose a reason for hiding this comment

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

I personally would use a single line for this argument as all other arguments are also on a single line but that is just taste and does not have to be addressed.

Copy link
Member Author

Choose a reason for hiding this comment

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

I copied this from a test further up. There are a few things I'd change about this test file, but I thought I'd try to keep this diff clean.

@gibfahn
Copy link
Member Author

gibfahn commented Sep 25, 2017

@richardlau does this LGTY now?

@gibfahn
Copy link
Member Author

gibfahn commented Sep 26, 2017

CI: https://ci.nodejs.org/job/node-test-commit/12618/

@nodejs/crypto I'd appreciate a quick look if you have time.

@gibfahn
Copy link
Member Author

gibfahn commented Sep 26, 2017

CI has these failures (I think all unrelated):

sequential/test-benchmark-buffer on fedora24
not ok 1743 sequential/test-benchmark-buffer
  ---
  duration_ms: 3.848
  severity: fail
  stack: |-
    
    buffers/buffer-base64-decode-wrapped.js
    buffers/buffer-base64-decode-wrapped.js n=1: 8.777361625508389
    
    buffers/buffer-base64-decode.js
    buffers/buffer-base64-decode.js n=1: 10.883984248741532
    
    buffers/buffer-base64-encode.js
    buffers/buffer-base64-encode.js n=1 len=2: 6,010.662916013007
    
    buffers/buffer-bytelength.js
    buffers/buffer-bytelength.js n=1 len=2 encoding="utf8": 6,914.0036229378975
    
    buffers/buffer-compare-instance-method.js
    buffers/buffer-compare-instance-method.js millions=1 args=1 size=1: 6.75575174739039
    
    buffers/buffer-compare-offset.js
    buffers/buffer-compare-offset.js millions=1 size=1 method="": 20.340541756904937
    
    buffers/buffer-compare.js
    buffers/buffer-compare.js millions=1 size=1: 7.3398795370162535
    
    buffers/buffer-concat.js
    buffers/buffer-concat.js n=1 withTotalLength=0 pieceSize=1 pieces=1: 427.32997394996477
    
    buffers/buffer-creation.js
    buffers/buffer-creation.js n=1 len=2 type="": 1,094.8405638428903
    
    buffers/buffer-from.js
    buffers/buffer-from.js n=1 len=2 source="array": 422.5531846565868
    
    buffers/buffer-hex.js
    buffers/buffer-hex.js n=1 len=2: 1,095.9312456573725
    
    buffers/buffer-indexof-number.js
    /home/iojs/build/workspace/node-test-commit-linux/nodes/fedora24/benchmark/common.js:202
          throw new Error('insufficient clock precision for short benchmark');
          ^
    
    Error: insufficient clock precision for short benchmark
        at Benchmark.end (/home/iojs/build/workspace/node-test-commit-linux/nodes/fedora24/benchmark/common.js:202:13)
        at main (/home/iojs/build/workspace/node-test-commit-linux/nodes/fedora24/benchmark/buffers/buffer-indexof-number.js:22:9)
        at Benchmark.process.nextTick (/home/iojs/build/workspace/node-test-commit-linux/nodes/fedora24/benchmark/common.js:34:28)
        at _combinedTickCallback (internal/process/next_tick.js:131:7)
        at process._tickCallback (internal/process/next_tick.js:180:9)
        at Function.Module.runMain (module.js:643:11)
        at startup (bootstrap_node.js:187:16)
        at bootstrap_node.js:607:3
    assert.js:44
      throw new errors.AssertionError({
      ^
    
    AssertionError [ERR_ASSERTION]: 1 === 0
        at ChildProcess.child.on (/home/iojs/build/workspace/node-test-commit-linux/nodes/fedora24/test/common/benchmark.js:25:12)
        at emitTwo (events.js:125:13)
        at ChildProcess.emit (events.js:213:7)
        at Process.ChildProcess._handle.onexit (internal/child_process.js:210:12)
  ...
parallel/test-http-writable-true-after-close on centos5-64
not ok 755 parallel/test-http-writable-true-after-close
  ---
  duration_ms: 0.214
  severity: fail
  stack: |-
    Mismatched <anonymous> function calls. Expected exactly 1, actual 0.
        at Object.exports.mustCall (/home/iojs/build/workspace/node-test-commit-linux/nodes/centos5-64/test/common/index.js:482:10)
        at ClientRequest.common.mustCall (/home/iojs/build/workspace/node-test-commit-linux/nodes/centos5-64/test/parallel/test-http-writable-true-after-close.js:24:28)
        at ClientRequest.<anonymous> (/home/iojs/build/workspace/node-test-commit-linux/nodes/centos5-64/test/common/index.js:514:15)
        at Object.onceWrapper (events.js:316:30)
        at emitOne (events.js:115:13)
        at ClientRequest.emit (events.js:210:7)
        at HTTPParser.parserOnIncomingClient [as onIncoming] (_http_client.js:564:21)
        at HTTPParser.parserOnHeadersComplete (_http_common.js:116:23)
        at Socket.socketOnData (_http_client.js:453:20)
  ...
parallel/test-http-writable-true-after-close on centos5-32
not ok 755 parallel/test-http-writable-true-after-close
  ---
  duration_ms: 0.286
  severity: fail
  stack: |-
    Mismatched <anonymous> function calls. Expected exactly 1, actual 0.
        at Object.exports.mustCall (/home/iojs/build/workspace/node-test-commit-linux/nodes/centos5-32/test/common/index.js:482:10)
        at ClientRequest.common.mustCall (/home/iojs/build/workspace/node-test-commit-linux/nodes/centos5-32/test/parallel/test-http-writable-true-after-close.js:24:28)
        at ClientRequest.<anonymous> (/home/iojs/build/workspace/node-test-commit-linux/nodes/centos5-32/test/common/index.js:514:15)
        at Object.onceWrapper (events.js:316:30)
        at emitOne (events.js:115:13)
        at ClientRequest.emit (events.js:210:7)
        at HTTPParser.parserOnIncomingClient [as onIncoming] (_http_client.js:564:21)
        at HTTPParser.parserOnHeadersComplete (_http_common.js:116:23)
        at Socket.socketOnData (_http_client.js:453:20)
  ...
inspector/test-bindings on win2016
not ok 442 inspector/test-bindings
  ---
  duration_ms: 0.286
  severity: fail
  stack: |-
    Expecting warning to be emitted
    (node:7428) Error: We expect this
    c:\workspace\node-test-binary-windows\COMPILED_BY\vs2017\RUNNER\win2016\RUN_SUBSET\1\test\common\index.js:789
                 (err) => process.nextTick(() => { throw err; }));
                                                   ^
    
    AssertionError [ERR_ASSERTION]: [ 'Iteration 1 variable: i expected: 1 actual: 0',
      'Iteration 2 variable: i expected: 2 actual: 1',
      'Iteration 2 variable: a deepStrictEqual []
        at testSampleDebugSession (c:\workspace\node-test-binary-windows\COMPILED_BY\vs2017\RUNNER\win2016\RUN_SUBSET\1\test\inspector\test-bindings.js:104:10)
        at doTests (c:\workspace\node-test-binary-windows\COMPILED_BY\vs2017\RUNNER\win2016\RUN_SUBSET\1\test\inspector\test-bindings.js:131:3)
        at <anonymous>
        at process._tickCallback (internal/process/next_tick.js:188:7)
        at Function.Module.runMain (module.js:643:11)
        at startup (bootstrap_node.js:187:16)
        at bootstrap_node.js:607:3
  ...

Turning FIPS mode on (or off) when it's already on (or off) should be a
no-op, not an error.

PR-URL: nodejs#12210
Fixes: nodejs#11849
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
@gibfahn gibfahn merged commit 0919dff into nodejs:master Sep 26, 2017
@gibfahn gibfahn deleted the crypto-fips branch September 26, 2017 22:51
MylesBorins pushed a commit that referenced this pull request Sep 28, 2017
Turning FIPS mode on (or off) when it's already on (or off) should be a
no-op, not an error.

PR-URL: #12210
Fixes: #11849
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
MylesBorins pushed a commit that referenced this pull request Sep 29, 2017
Turning FIPS mode on (or off) when it's already on (or off) should be a
no-op, not an error.

PR-URL: #12210
Fixes: #11849
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
addaleax pushed a commit to addaleax/ayo that referenced this pull request Sep 30, 2017
Turning FIPS mode on (or off) when it's already on (or off) should be a
no-op, not an error.

PR-URL: nodejs/node#12210
Fixes: nodejs/node#11849
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
@MylesBorins MylesBorins mentioned this pull request Oct 3, 2017
MylesBorins pushed a commit that referenced this pull request Oct 3, 2017
Turning FIPS mode on (or off) when it's already on (or off) should be a
no-op, not an error.

PR-URL: #12210
Fixes: #11849
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
@MylesBorins
Copy link
Contributor

@gibfahn I've backported to v6.x, can you test this out once the r.c. drops

MylesBorins pushed a commit that referenced this pull request Oct 17, 2017
Turning FIPS mode on (or off) when it's already on (or off) should be a
no-op, not an error.

PR-URL: #12210
Fixes: #11849
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
@MylesBorins MylesBorins mentioned this pull request Oct 17, 2017
MylesBorins pushed a commit that referenced this pull request Oct 25, 2017
Turning FIPS mode on (or off) when it's already on (or off) should be a
no-op, not an error.

PR-URL: #12210
Fixes: #11849
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
@MylesBorins MylesBorins mentioned this pull request Nov 3, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
crypto Issues and PRs related to the crypto subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants