On 1/21/2013 1:29 AM, Jeffrey Walton wrote:
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.
> ... (Snipped discussion of my proposed solutions and its CMVP
> implications)
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).
The issue is the bootstrap problem that the code that runs before/during
the act of installing the C runtime DLLs obviously cannot use those
runtime DLLs during that time. A typical *example* would be code that
verifies digital signatures on a downloaded installer/patch, including
the included copy of the C runtime DLLs.
The other issue is that the vcredist*.exe packages are rather large
(on the order of 3MB for x86 and x86_64 each) compared to small
programs such as browser plugins, thus including the full runtime DLL
bundle becomes a non-option (and downloading them on demand triggers
the bootstrap problem above).
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.
Symbolication would typically only fail if you told the linker to
include references to both runtimes in a single binary, something which
is explicitly blocked in more recent libraries.
Mixing the runtimes within a process, with different DLLs using
different copies and versions works nicely as long as you understand
that certain objects returned by the runtimes (such as FILE* structures)
are usable only by the copy that allocated them, due to embedded indexes
into static arrays in the owning runtime. Thus the limitation that if
e.g. X509_new() returns memory allocated by the C runtime used by that
copy of OpenSSL, then it may only be freed by calling the X509_free()
which uses the same C runtime to free that memory.
Note that this is a much weaker and shallower encapsulation than the
.NET OOP system, certain "homesick" objects simply belong to certain
DLLs or clusters of DLLs and need to be treated as opaque by others,
even if they have near identical object types themselves.
I suppose its a matter of preference in the end. If it works for you,
then go for it.
Well it sounds like I cannot use the current FIPS modules then, which
is the subject of this thread.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, 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 Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
