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.
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).
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.
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
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
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.
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.
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.
--
Jakob Bohm, CIO, partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. direct: +45 31 13 16 10
This message is only for its intended recipient, delete if misaddressed.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
