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

Add FIPS mode build to CI #264

Closed
mhdawson opened this issue Nov 23, 2015 · 11 comments
Closed

Add FIPS mode build to CI #264

mhdawson opened this issue Nov 23, 2015 · 11 comments
Labels

Comments

@mhdawson
Copy link
Member

I'm planning to add a config to node-test-pull-request which tests xLinux when built in FIPs mode.

See nodejs/node#3760 for discussion/details on the changes that have gone in to support this.

When built in FIPS mode, we need a "fipscanister" either built from source or a binary that we can link against. The source is not part of the standard openssl distribution , right now looks like we can pull directory from github. This does not follow the rules for building/distributing a FIPs capable runtime but for test it should be ok.

@mhdawson
Copy link
Member Author

Work in progress - https://ci.nodejs.org/job/node-test-commit-linux-fips/, note still builds non-fips just starting by cloning existing linux job and stripping down. Will then modify to build in fips mode

@mhdawson
Copy link
Member Author

Ok build is configured to build in FIPS capable mode and tests are passing. https://ci.nodejs.org/job/node-test-commit-linux-fips/,

@nodejs/build, @nodejs/crypto I'd like to add this so that its run as a sub-job as part of the regression tests as part of node-test-commit

Feedback I'd like:

  • agreement to go ahead and add as subjob
  • platforms we should run this on. So far I have it set up to run only on ubuntu 1404. Since we are not shipping releases in FIPS capable mode I don't necessarily think we should run across all of the linux platforms as that would potentially double the runtime/workload.

@mhdawson mhdawson added the build label Nov 24, 2015
@jbergstroem
Copy link
Member

@mhdawson is it compiled with ccache? looks slow.

@bnoordhuis
Copy link
Member

One problem is that FIPS mandates minimum key sizes for (EC)DH that are quite slow to generate.

See nodejs/node#3881 and nodejs/node#3902 - the ARM buildbots were affected most but even on comparatively beefy hardware it can take tens of seconds. I suggest we try it and see how well it works in practice.

@mhdawson
Copy link
Member Author

@jbergstroem I did not do anything to prevent it from being compiled with ccache. There is an extra step where is need to compile fipscanister. The actual job to compile/test took ~7 mins. The parent job shows as taking a lot longer because it had to wait for a machine.

@mhdawson
Copy link
Member Author

Any objections to stitching in what I have now (ubuntu14 only) and then we can expand the platforms covered once we have agreement in this issue ?

@jbergstroem
Copy link
Member

One is better than none. I'd like to keep it as a separate job from the -linux one (similar to what you have at the moment).

@mhdawson
Copy link
Member Author

Agreed, I'll add what I have now and mark this for discussion in the next build meeting to discuss what the full set of platforms we'd think it makes sense to cover.

@mhdawson
Copy link
Member Author

@nodejs/collaborators just added nod-test-commit-linux-fips as subjob to node-test- commit. Let me know if you see any issues

@mhdawson
Copy link
Member Author

Note that even if the top level jobs says it took 16 mins, the job itself only took 10 because it was waiting for a free machine. I think @jbergstroem was adding an additional ubuntu 14.04 machine that would address that

@mhdawson
Copy link
Member Author

mhdawson commented Dec 2, 2015

Based on discussion in the build workgroup meeting yesterday we agreed that running on a single platform provides the required coverage. At this point we think any regressions caught by these tests will be across platforms. Since we don't ship in FIPS capable mode on ay specific platforms running on the single on already enabled is therefore good enough. Going to leave as is unless we get additional input.

@mhdawson mhdawson closed this as completed Dec 2, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants