On 21-07-2010 18:26, Bryan wrote:
On Wed, Jul 21, 2010 at 10:33, Jakob Bohm<jb-open...@wisemo.com> wrote:
On 21-07-2010 16:18, Bryan wrote:
I am trying to build openssl 0.9.8o with the fips-1.2 source. I'm
building it using cygwin as the interface, since I am trying to script
this into an installation process.
When building with Visual Studio, you are better off using a perl version
itself compiled as a native program (such as Strawberry perl
or ActiveState perl), and not putting CYGWIN on your path.
Sorry, I failed to mention that I installed ActiveState Perl... and am
using it. When I run "which perl" states "/cygdrive/c/Perl/bin/perl"
which is where I installed ActivePerl.
Good.
The big problem however is that some CYGWIN binaries may have name
clashes with Microsoft binaries that do something *completely*
different, leading to nasty surprises whenever a shell (including make)
picks up the wrong one.
The cygwin interface is using
Visual Studio 8 to build the source, using the cl.exe. After disabling
cygwin's "link.exe", I was able to build the FIPS libraries, but when
I try to build openssl with fips enabled, I receive an error.
As discussed in another recent thread about the FIPS module, it is not
really intended to be built automatically. Any deviation from the very
specific *manual* procedure in the certification documents voids the
FIPS certification, making the exercise useless.
I just joined last night. I googled for the error message before
joining, but I couldn't get a straight answer from yahoo/google that
concerned openssl/fips that was within the last few years. Mayhaps I
didn't search efficiently...
The thread did not mention your error messages as that thread was about
someone doing the same on Linux with rpms.
So you are saying that you don't build the FIPS module first? You
build OpenSSL with FIPS at the same time? We downloaded the separate
"openssl-fips-1.2.tar.gz" and build it and then build
openssl-0.9.8o.tar.gz. Back to the drawing board... I'll just back
everything out... guess we read too much into the 140-2 doc...
assumed that FIPS had to be build, and then build openssl pointing to
the FIPS lib.
No.
I am saying that the FIPS binary blob exists for only one purpose:
to satisfy the bureaucratic rules required by the FIPS certification.
Typically, the FIPS module is compiled *once* by a developer who
slavishly follows the exact bureaucratic steps in the openssl specific
FIPS certification documents, with no deviations or improvements however
sane, (not even security fixes are allowed without recertification!)
Then the resulting .o, .obj, .a or .lib file is stored away as a binary
file which will then be used every time you (automatically) build the
rest of openssl-with-fips-certified-core.
We found the location of crypt32.lib and added that directory to the
very beginning of our $PATH, but it does not appear to be working.
Remember that with MS compilers, library directories need to be on the
path described by the environment variable "LIB", not the path
described by the environment variable "PATH"
I have no idea how MS compilers work. I am used to building using ONLY
Unix (.configure&& make&& make install). Ultimately, I have to
compile OpenSSH to create executables for windows. OpenSSL-fips is
needed for our customers.
I see a LIBPATH, and LIB when I do a "printenv" in cygwin. Can I
permanently set this in my .bashrc?
OK, here are the path-like environment variables for MS compilers and
shells (all have uppercase names and use semicolon, not colon as
separator, CYGWIN shells sometimes try to hide this).
1. PATH the path for executable programs, just like on UNIX. The
current dir (.) is always searched before PATH, even if . is also
mentioned on it.
2. PATHEXT is the list of file extensions appended to command names to
get the file names of executable binaries, it is searched left to right
like other paths. The behavior if there is a file with one extension in
one directory on PATH and a file with a higher priority extension in a
lower priority directory on PATH is somewhat unspecified. Windows
versions before Windows 2000 don't use this. Some shells also ignore this.
3. LIBPATH is used only be a very few non-native programs to locate
shared libraries (DLLs). Corresponds to ld.so.conf, but only for a
few program types (such as OS/2 binaries).
4. LIB the path for .LIB files (same file format is used for static
libraries (UNIX format .a files) and import libraries (special files
telling the linker how to embed references to a dll, similar to the
.so symlinks on Linux, but with no need to have the .DLL itself
available at link time). Corresponds to
'/usr/local/lib:/usr/lib:/lib'
on UNIX.
5. INCLUDE the path for .h files etc. used by the C preprocessor,
corresponds to
'/usr/share/gcc/version/include:/usr/local/include:/usr/include'
on Linux.
PATH, LIB and INCLUDE are typically set by sourcing the "vcvars32.bat"
script in the MS compilers bin directory. E.g.
CALL "C:\whatever it is\VC\BIN\VCVARS32.BAT"
There are alternate file names for this script if you want the 64 bit
cross compiler, or settings for debug builds etc. The start menu
has menu items which open a shell and do this for you.
I
thought that since we are using VS8, that we need the 8.0 SDK... and
if that is the case, then we can deal with that... below is the
output of the openssl build, with attempting to add FIPS support.
The "Visual Studio SDK" is typically not needed for stuff like openssl.
That SDK is only for building Visual Studio plugins such as new toolbars
for the MSDEV GUI etc.
The SDK that you need is the platform SDK for the targeted Windows version
(limited to those editions of the platform SDK which are compatible with
your version of VS). These days you would typically
use the "Windows Vista Platform SDK" with VS8 (aka Visual Studio 2005).
We are still using XP, and are doing our best to get our remaining
form factor boxes off of Windows 2000. Our customer moves slowly...
Me too, but you need a platform SDK compatible with the chosen compiler
version, if they are too many years apart, compiler errors result.
Anyway, adding "-D_WIN32_WINNT=0x0501" to your compiler flags tells the
SDK headers to approximate the definitions and feature set of Windows
with NT kernel 5.01 aka XP for the i386 and ia64 CPU families. Other
kernel version values available:
0x0400 NT 4.0 for i386 and some other CPUs
0x0500 Windows 2000 for i386
0x0501 XP for i386 or ia64
0x0502 XP for amd64 or Server 2003 for i386/ia64/amd64
0x0600 Vista for i386 or amd64, Server 2008 for i386/ia64/amd64
0x060? "Windows 7" for i386 or amd64, Server 2008 R2 for ia64/amd64
(The last line should read either 0x0601 or 0x060a corresponding to
kernel version 6.01 or 6.10, I don't remember which).
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
