Secure by design discusses the security issues related to computer programs, and the features of Tcl that facilitate the development of secure programs.
Description
Sarnold: although lots of system applications are written in C/C++, we can consider that writing a new application in these languages is a lot more work, and lead to security holes.
And scripting languages are now strong, so according to Ousterhout's Dichotomy, we should write in C/C++/Java the critical part of the application that cannot be written in a scripting language, or would be unbeareably slow.
The rest of this page is trying to compare Tcl security against other programming languages to serve Tcl marketing. (Of course, we will exclude C/C++/whatever compiled language from this comparison)
- Tcl is immune to many "format string vulnerabilities"
- Tcl programs are immune to buffer overflows (as long as the Tcl interpreter is; DStrings help a lot)
- No Y2K bug
- Fully integrated Unicode, where most other languages need special syntax and still have problems handling UTF-8 strings.
- Tcl can be compiled with Threads. AOLServer has been multithreaded long before Apache/PHP.
- Backwards-compatibility: Tcl provides the best effort in this dimension.
- Safe interps makes it possible to run user-defined scripts without fearing an attack.
- You do not have to check nils as in Java, Python, Lua...
- It is easy to manage Tcl packages. With starkits and starpacks, deployment is easy. You would not ask yourself a long time what package is outdated or missing to make work your application.
- Prowrap and ActiveState tools can encrypt the sources.
- Although there is no official debugger, interactive debugging in GUI mode is terrific. Just embed tkcon in your project and you have a full control on your application under your fingertips.
- There is a huge testing work that has been done on the Tcl interpreter, as well as the Tk toolkit. Tcl has been ported to a wide range of existing systems. Tk is one of the most well-tested GUI toolkits.
- Because of EIAS, the The Java deserialization bug and vulnerabilities in its class aren't going to happen, simply because it isn't common practice in Tcl programming to serialize arbitrary object types.
Safe Intepreters
Safe interpreters are a feature missing in almost every other language (Java has a similar functionality, but with such complexity that I cannot even think of it).
Unicode
Tcl currently (summer 2007) only supports the Basic Multilingual Plane of Unicode (16-bit character codes, as up to version 2.1 of the standard), but this is mostly an internal implementation detail, and neither Tcl scripts nor compiled extensions should need to be changed when full support gets implemented.