[E-Lang] Re: expression-style syntax is insecure? (was: multiple-domain language, plus Super Newbie is lost without "The Dot" (was: down with `define' (was: newbie syntax: picayune points from a prejudiced programmer)))

zooko@zooko.com zooko@zooko.com
Fri, 02 Mar 2001 12:53:19 -0800


> > With the default being ":any", authority can be accidentally leaked
> > from code in an unintentional return value.  With the default being
> > ":void", then authority does not unintentionally leak from a ":void"
> > function, but it *does* still unintentionally leak from an ":any"
> > function, for example:
> 
> An intriguing observation. Actually, my experiences to date do not support a
> belief that this problem in principle is a problem in practice.


A very valuable kind of data, and one that we should frequently update
with more experience...  


One problem with this bug/security leak is that it is unlikely to be
noticed, especially if the types of the intentional and unintentional
return values match.


It seems wrong to automatically hand out references by default and then
try to catch errors with typing and code-auditing.



> However, this still doesn't get rid of the type declaration in the prolog of
> the method definition, where the absence of a type declaration still has to
> default to "void".


The solution that has proven itself starting with ML is type inferenc.
with optional human type annotations.


It provides support for shell scripting, rapid-prototyping, and Real
Engineering, and IMHO it is sufficiently secure, especially in the Real
Engineering environment.


> Another of the reasons for putting the type declaration
> there--another reason I find compelling on its own--is security auditing.


Certainly.  A programmer or a shop could easily implement a policy of
routinely annotating with the most restrictive appropriate type, and
automated tools could help a great deal:

1.  Your Ebrowser and the like could insert or just display the
principal type (the most restrictive type that allows all the actual
values returned).

2.  Real type checkers could (perhaps even statically) verify the
consistency of all the types.


Note that none of this would have helped with the example of
myFavoriteRabbit, because myFavoriteRabbit had the same type as the
other rabbits.  Type-checking and type-annotations are useful but far
from sufficient for security.



> For the security auditor, having the type declaration in the method prolog
> is an enormous (I believe required) benefit.


I certainly agree.  If it were my development team, I would instruct
people to start with whatever they felt was easiest while doing
rapid-prototyping and then start adding type annotations as they
"firmed up" the code or as they did security audits.  This would, IMO,
strike the right balance between rapid coding and bug detection.


I think that E can be successful in the C++/Java field with required
type annotations, but that it cannot be successful in the bash/ksh
field nor *even* in the Python/Perl field unless the type annotations
are optional.


And I think that regardless of the annotations that "expression style"
language in which you automatically hand out a reference to whatever
you were just doing is inherently insecure.


Regards,

Zooko