Re: [Gnu-arch-users] Re: Tlacontrib contribution: Alternative to .listing files

[Aaron Bentley]

Adrian Irving-Beer wrote:

> > Hmm.... since we care about security, wouldn't it be better to use
> > something else than C (like something where buffer-overflows are
> > simply not possible)? Maybe Perl, Python, Scheme, Elisp, or ... ?
>
>
> I think C is safe if you make sure all your operations on string
> buffers carefully cap the size, and don't do weird junk with pointers.

Whereas it's very difficult to produce a buffer overflow in a scripting 
language.

> In fact, even though I know all those languages can be generally close
> to 100% safe for this operation, technically a 'safe' C script would
> still be safer because every single operation is explicitly stated,
> rather than left up to the interpretor (i.e. unknown and with
> potential to change).

If you want that kind of 'safety', better write in in assembler.  Or 
better yet, machine code.  You can never be sure about the libraries. 
And the kernel.  Better write your own.  And the processor....

Okay, it's true that reducing the number of layers reduces the number of 
layers that may contain bugs.  But the more you write, the more bugs 
*you*'re likely to produce.  And scriping languages have already had 
many bugs fixed.

A program written in a scripting language would be much shorter.  Many 
scripting languages have operations to decode URL encoding, for example. 
  Using a well-tested URL-decoding routine is usually the right choice. 
This CGI program has its own built-in hex-string-to-integer decoder, 
even though the standard C facilities can do that, and are thoroughly 
tested.  The program may be safe, but it's so full of gotos and macros 
that I can't read it.

As for startup time, I doubt it's significant, considering the latency 
involved in HTTP connections.  Options like FastCGI or mod_perl may be 
helpful to reduce that, *if* it's an issue.

I say all this as the lead developer of a large CGI program written in C++.

Aaron

--
Aaron Bentley
Director of Technology
Panometrics, Inc.