Being safe on the internet (was Re: Here we go again - ISP DPI, but is it interception?)

[Ian Batten]

So, if I'm three weeks from starting a PhD in which the production of  
a large slab of secure code (let us gloss over whether that's formally  
secure or pragmatically secure), what toolchain should I use?  I'm  
guessing my favoured "first to reach for" tools at my advanced age of  
C and Perl aren't cool, C++ horrifies me aesthetically, Java is dull.

I think it's time for a Lisp revival.

ian


On 7 Aug 2010, at 07:07, Peter Tomlinson wrote:

> Tom Thomson wrote:
>> Roland Perry wrote:
>>
>>> It seems to be worse than that... why are these products so  
>>> susceptible
>>> to vulnerabilities? For example, one that used to occur over and  
>>> over
>>> again was "buffer overflow". Surely there must be programming (or  
>>> memory
>>> management) techniques that could eliminate them entirely?
>>>
>> There are indeed appropriate techniques, but these techniques  
>> involve either or both of using hardware which supports memory  
>> management (as implemented by old-fashioned mainframe providers and  
>> some old-fashioned mini-computer providers) and programming in  
>> languages whose operational semantics requires bound checking and  
>> separation of code and data.  Systems using the technologies  
>> developed in the late 1960s and the 1970s by companies such as  
>> Burroughs, ICL, and even CTL could not have suffered from most of  
>> the vulnerabilities that we see today.
> The memory stirs, taking me back to 1968 when I designed the very  
> simple memory management hardware for the ICL 1904A (and in the  
> process fixed an error in the 1906A's MMU). Took the software people  
> another 2 years to get George 4 running. So that was old-fashioned,  
> was it, Tom? It was state of the art then, in the commercial  
> environment that soon after took a wrong turn...
>
> Peter
>
>