On 19/04/2016 01:51, Steve Marquess wrote:
On 04/18/2016 04:05 PM, Leaky wrote:
plus you're constrained by the
requirements of the Security Policy to build the module with precisely
the commands:
gunzip -c openssl-fips-2.0.12.tar.gz | tar xvf -
cd openssl-fips-2.0.12
./config
make
Silly question... I know that you should only run the above commands, but
can you deviate from the unzip tool, i.e. use 7zip?
I managed to get it to work without editing anything, but I am now wondering
if my process to compile the FIPS canister is bad purely because i am
storing the deflated tarball on our SVN and using that uncompressed code to
build from. Putting aside the fact that this is automated, and that it is
best to "run once and use many", should my script work with the raw tarball
straight from the web, and not a locally expanded copy?
This is a mistake I've seen many times ("storing the deflated tarball on
our SVN"). You're thinking like a software engineer, when you should be
thinking like Alice down in the FIPS 140-2 rabbit hole.
There is no point in attempting to do the usual configuration management
and software version control on the contents of the
openssl-fips-2.0.12.tar.gz tarball. You CANNOT change the content; there
can be no changes to manage!!!
Almost true. If it wasn't banned by the FIPS security policy, checking in
the uncompressed tarball could be used to efficiently manage and track new
upstream releases of the tarball and to document which exact upstream FIPS
cannister source code (and hence corresponding validation date) was
incorporated into which product version (an aspect of FIPS compliance which
someone might want to audit
But alas, as you clarify below, this is not permitted by the OpenSSL FIPS
security policy directly incorporated into the validation.
The slightly less efficient idea of putting the compressed tarball into
the configuration control repository (which in this case *is* tracking the
build configuration, not the code versions) is probably (I am not sure)
againstthe policy that the tarball must be taken "securely" from the
physical CD mailed out by the OpenSSL foundation.
So the thing that can probably be put into a repository is the binary
FIPSCannister.o file along with copies of any documents certifying how,
where, from what and by whom said FIPS cannister was built.
Of cause, one could, purely for debugging/documentation purposes, include
a copy of the FIPS Cannister source code in the repository, one just
cannot compile anything releasable from it.
The Security Policy is quite specific on the requirements, which make no
allowance for the common sense (to a software engineer) fact that there
are equivalent multiple ways to accomplish each step (such as unzipping
the tarball). You are also specifically required to begin with the
official tarball. Per the Security Policy, you *must* do:
gunzip -c openssl-fips-2.0.12.tar.gz | tar xf -
and *not* any functionally equivalent alternative such as:
tar -zxf openssl-fips-2.0.12.tar.gz
or even worse, a checkout of the expanded contents from your version
management system.
This is why I recommend you build the FIPS module once, manually,
exactly per the documented requirements. It doesn't make sense, from the
software engineering viewpoint, but is what the FIPS 140-2 validation
bureaucracy insists on.
-Steve M.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
