RE: Anyone looked at security features of D programming language compared to Spark?

["Michael Canty" <mcanty () cloudchasers com>]

i've been following this thread and have an observation i'd like to make that
will probably get me strung up in the closest pine tree.
using a language as an excuse for poor security is simply saying that we have
failed to properly train the programmers who are building the software.
i'm a dinosaur, i wrote high security apps in 370 assembler back in the 80's,
'c' on unix boxes in the 90's and now i dabble on the softy platform.
regardless of what language i was using, i was taught to never trust my input,
to always verify, and to manage every aspect of my operating environment.  that
is what is missing today.
there is no magic bullet, no new language that is going to solve all of the
problems.  sure 'c' has problems.  so does java.  so will the next language.
education is the key, not protecting programmers from themselves.  (and yes, i
agree 100% that tools for managing software safety and security are a huge key
but they should not be a replacement for teaching).
what i mean about not trying to protect programmers from themselves is that we
can't design languages that prevent everything so that nobody will make a
mistake.  innovation normally is a mistake.
mjc



-----Original Message-----


> I am hard put to find an example of a language feature which makes a
> system more secure but less safe or vice versa, in any context. Can
> anyone else think of one?

Dynamic type checking (or any kind of run-time fail-stop checking)
enhances security (attacks are halted) but degrades reliability
(processes that might live with a harmlessly inconsistent state may be
halted).

Now, that is in isolation, considering only the language impact on an
individual process, in response to Jim/Mary's question. Of course you
can compose fail-stop mechanisms with redundancy techniques to archive
strong availability in the presence of weak individual process
reliability. In fact, it is much easier to achieve high availability in
the presence of fail-stop failure modes instead of Byzantine failure modes.

Crispin

--
Crispin Cowan, Ph.D.  http://immunix.com/~crispin/
CTO, Immunix          http://immunix.com
Immunix 7.3           http://www.immunix.com/shop/