| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
There was a problem hiding this comment.
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
Sorry, something went wrong.
There was a problem hiding this comment.
@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?
Sorry, something went wrong.
There was a problem hiding this comment.
good point. ok
Sorry, something went wrong.
There was a problem hiding this comment.
Needs tests (marking so this doesn't land without them).
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM
Sorry, something went wrong.
|
@gibfahn would you be so kind and add some tests for this? |
Sorry, something went wrong.
|
Closing due to long inactivity. @gibfahn please reopen if you still want to pursue this. |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
There was a problem hiding this comment.
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.
Sorry, something went wrong.
There was a problem hiding this comment.
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.
Sorry, something went wrong.
|
CI: https://ci.nodejs.org/job/node-test-commit/12618/ @nodejs/crypto I'd appreciate a quick look if you have time. |
Sorry, something went wrong.
|
CI has these failures (I think all unrelated): sequential/test-benchmark-buffer on fedora24not 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)
...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)
...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)
...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
... |
Sorry, something went wrong.
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>
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>
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>
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>
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>
|
@gibfahn I've backported to v6.x, can you test this out once the r.c. drops |
Sorry, something went wrong.
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>
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>
| Back | FazBrowse Home | New Git URL |
Turning FIPS mode on (or off) when it's already on (or off) should be a
no-op, not an error.
Fixes: #11849
Checklist
Affected core subsystem(s)
crypto (FIPS)
Patch shamelessly stolen from @bnoordhuis here. PR'd to remind myself to test this properly.