[Prev][Next][Index][Thread]

Re: Dylan's direction

James Dominy <jdominy@openscript.com> writes:

>    I'd like to hear other people's opinions on the future of dylan 
> and where people think we should focus our efforts.

There are two things that I think are worth talking about. The first
one is that the usefulness of a language is closely coupled to the
number of packages available for that language. The key to perl's
success (besides being a dynamic language with garbage collection) is
the CPAN, the archive network of readily available, useful perl
modules.

We need the same for Dylan. At the moment, it would be very useful if
everybody contributes all the code he has written to the public. This
serves as a pool for ideas of both what would be useful and how one
would implement certain things. Even code snippets are welcome. In the
long run, we need someone who maintains a web site plus database to
organize this.

The second interesting aspect of Dylan is security. If you read
Bugtraq, you'll notice that about 90% of all problems are related to
buffer overflows. They try to retrofit some security by making the
stack non-executable, and guarding the return address on the stack,
but in the long run, only real bounds checking will ensure security.

C doesn't have bounds checking. So all the software has to be
rewritten. We're talking things like SMTP servers, POP3 servers, name
servers etc. here. This is a lot of work, and the workload is reduced
by using a high-level, dynamic, object-oriented language - you get the
drift. Note that people require performance here, perl and python
won't cut it.

An example of an application in this area is David Lichteblaus
dfingerd. It is a secure replacement for fingerd, and it gains it's
security from two aspects:

- it is designed not to disclose any useful information to an
  attacker. This is an idea from ffingerd by Felix von Leitner.
  Here are the 10% security *not* covered by a bounds checker.

- It is written in Dylan. ffingerd gains it's security against buffer
  overflows from auditing, dfingerd from Dylan's bounds checking.

Now finger is an example where it is possible to do an
auditing. There's software out there which is plain impossible to
audit, witness sendmail and bind.

dfingerd can be found at:

ftp://ftp.gwydiondylan.org/pub/contributions/dfingerd-1.0.tar.gz

Andreas

-- 
"We should be willing to look at the source code we produce not as the
end product of a more interesting process, but as an artifact in its
own right. It should look good stuck up on the wall."
 -- http://www.ftech.net/~honeyg/progstone/progstone.html
References: