On Wed, Jul 21, 2010 at 13:19, Jakob Bohm <jb-open...@wisemo.com> wrote: > On 21-07-2010 18:26, Bryan wrote: >> >> On Wed, Jul 21, 2010 at 10:33, Jakob Bohm<jb-open...@wisemo.com> wrote: >>> >>> On 19-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. >
Well, the good thing is I am building this on an XP machine inside a VM, and I created a snapshot before I started all this, so backing out is an option to be able to start over and configure the environment correctly. This might even be what I have to do, since I thought that I'd need programs like nasm, and mingw to build it. I did a lot of searching before I started asking questions... >> >>>> 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. > So when I build the library, I need to stuff in a directory where it will be protected from unauthorized access, but still have enough permissions to allow it to be accessed. >>>> >>>> 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. > > Gonna save that... Thanks for that bit o' info... It's almost like Microsoft wants to make it difficult to compile source or something. If they'd just add FIPs-enabled SSH/SSL to their OS, things would be much easier... SSH is BSD licensed, after all... Did you happen to build SSH as well? If you did, was it all that difficult? We are wanting to get away from having to use a program called "Attachmate" to automate remote linux security installs. Right now, we use Attachmate to push updates to our Linux boxen from windows. We'd like to save the company some coin by being able to get rid of Attachmate. > >>>> 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). > I appreciate your insight, and taking the time to answer my questions. I'll add the needed directories to $LIB. How active is this list? I'm on all the openssl lists, but I haven't seen a lot of traffic. Is there another place you'd recommend (forum, IRC chat, etc) that would be of use? Thanks again, Bryan Brake ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
