Neil Van Dyke wrote at 04/24/2012 03:13 PM:
One reason for avoiding linking native code libraries is that they are
often written in C/C++, and this means that memory-corrupting bugs
often exist in them. Memory-corrupting bugs can be a nightmare for
debugging, and I prefer to keep sources of them isolated in native
processes, separate from the native processes that are hosting Racket
code.
For example, mere hours later, this security advisory came through:
Tomas Hoger, Red Hat, discovered that the fix for CVE-2012-2110 for
the 0.9.8 series of OpenSSL was incomplete. It has been assigned the
CVE-2012-2131 identifier.
For reference, the original description of CVE-2012-2110 from DSA-2454-1
is quoted below:
CVE-2012-2110
Tavis Ormandy, Google Security Team, discovered a vulnerability
in the way DER-encoded ASN.1 data is parsed that can result in
a heap overflow.
With C/C++ code, sometimes even the security fixes to memory bugs have bugs.
These kinds of bugs are pretty common in C/C++ code. Keeping as much
C/C++ code as practical in separate processes from Racket reduces
opportunities for C/C++ code bugs to stomp on the Racket VM and JIT. As
much as practical, I want to avoid having to try to debug a reported
"bug in the Racket app" that is actually due to heap or stack corruption
by some C/C++ library that the Racket app links through FFI.
--
http://www.neilvandyke.org/
____________________
Racket Users list:
http://lists.racket-lang.org/users
