On Sun, Jan 20, 2013 at 6:51 PM, <jb-open...@wisemo.com> wrote: > On 18-01-2013 20:26, Jeffrey Walton wrote: >> >> On Fri, Jan 18, 2013 at 11:01 AM, Memmott, Lester >> <lester.memm...@landesk.com> wrote: >>>> >>>> All modern Versions of Microsoft's C Runtime are thread safe. That >>>> occurred around Visual Studio 6.0 (circa 2000 or so). >>> >>> >From http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx: "The >>> single-threaded CRT (libc.lib, libcd.lib) (formerly the /ML or /MLd >>>> >>>> options) is no longer available. Instead, use the multithreaded CRT." >>> >>> Thanks for the quick response. My proposal isn't to use the single >>> threaded C runtime, but instead to use the statically linked (multithreaded) >>> C runtime instead of the dynamically linked (multithreaded) runtime. >> >> My bad. I read that wrong (I think I crossed wires on /MT and /ML). >> Your installer should unconditionally install vcredist_*.exe before >> installing the program proper. I say 'unconditionally' because some >> installers don't offer a way to check for the CRT version. Since >> vcredist_x86.exe is a Microsoft executable, the Microsoft installer >> will exit if its not needed; and the binary should not have any >> negative platform side effects. >> ... > > This is so obviously a non-solution, you should have thought about this > before making the rookie mistake of FIPS-certifying the MSVCRTxx.DLL > needing build option. I'm not sure what you mean. For OpenSSL, the CMVP considers the platform golden. Any interaction with vendor provided components - such as runtimes - are irrelevant and have no bearing on FIPS validation. That means if he needs the runtime supplied with Visual Studio 2008 SP1, he packages it and installs it.
This is on contrast with, for example, using Crypto++'s FIPS module. In the Crypto++ case, the binary module was validated against a specific OS and runtime environment, and it requires the specific environment (and specific version of the runtime). > As every seriously experienced Visual C++ developer knows, Microsoft has > a terrible track record when it comes to making their DLL C runtimes > useful for reliable or secure software (I will not bother to enumerate > their epic fails here, they are actually documented in various individual > Microsoft documents that each try to talk down the problems). All platforms have their problems. I could go on and on about Drepper and his runtime and loader (that make regular appearances on Bugtraq and Full Disclosure). But its irrelevant for the source code validation since the platform is golden. > In practice for library designs (such as future releases of the OpenSSL > FIPS module), the realistic design options are: > > A. Require any memory, FILE* objects and "POSIX-like" int file handles > allocated by library functions to be freed by other library functions > and also require that the FILE* objects and int file handles are used > exclusively through the library. And the converse for any such things > allocated outside the library. Then the library can use a private > statically linked C runtime even if the calling application does not. > Many aspects of OpenSSL already do this, but there may be a few unsafe > functions laying around, maybe in the BIO_ family. OK. I believe this is the approach of Microsoft's Net API. > B. Create the one-compilation-only part (the FIPS module in this case) > not to call the stateful parts of the C runtime (especially malloc/free > etc.) directly but leave that to the recompilable part (the > FIPS-compatible OpenSSL library in this case). This way a single code That's kind of tenuous :) > blob becomes independent of such factors and also becomes reusable > across compiler versions, and even operating systems (imagine an x86_64 > module that is compiled once by a known good compiler, FIPS certified The compiler is part of the platform, so its considered golden too. All compilers are 'knonw good' (some handwaiving). > for different CPU capabilities and then reused on all the many OSes for > that architecture with Apple's legal requirements as a possible > exception). This also creates a clearer specification of the module > "boundary", as this no longer includes an unknown C runtime library, > just a specific environment condition on helper functions supplied by > the FIPS-compatible OpenSSL library. It does not sound bad from an architectural point of view, but I'm not sure I'd want to implement it; and I'm not sure what the CMVP would think about it. Perhaps Steve Marquess has some insight due to all his experience with the CMVP. >> Its also a recommended solution with, for example, Inno Installer when >> the setup program carries around both an x86 and x64 copy of the >> program to install. I can't give you a reference since it appears >> http://news.jrsoftware.org/read/thread.php?group=jrsoftware.innosetup >> is not indexed. But I asked a similar question a few years ago. > > This won't work for code running outside the protective bubble of a > completely installed multi-megabyte application. Anything running during > install/uninstall/upgrade or downloaded as a small piece of mobile code > will not be able to satisfy this, by definition. I'm not sure how installing the runtime you need won't work. Perhaps you could explain it in detail for me? If its specific to installers, all I can say is: all that I have used just work - that includes Install Shield, Inno, Wix, and the stuff we build using Windows Mobil setup (RIP). >> That sidesteps the FIPS requirements, and the nasty interactions >> between mixing/matching static and dynamic libraries with >> /NODEFAULTLIB. > > The nasty side effects have been deliberately exaggerated by the > documentation writers, the realities are much more manageable as explained > above. I have experienced the nasty side effects in the past. Mixing static and dynamic linking is more trouble than its worth, and it leads to hard to determine issues. For example, I had problems determining the correct function that was failing in an MFC module because the module would not symbolicate correctly. In this instance, the debugger was telling me the problem was in a totally irrelevant CTime object. I suppose its a matter of preference in the end. If it works for you, then go for it. Jeff ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
