[e-lang] Introducing Emily, a High Performance Language For SecureCooperation

Constantine Plotnikov cap at isg.axmor.com
Mon Feb 20 05:48:36 EST 2006

marcs wrote:
>> I think forbidding new exceptions is too harsh. There is a
>> solution to 
>> this problem. See my old article:
>> http://sebyla.sourceforge.net/prototype/design-notes/exceptions.html
>> If it is an incorrect solution, I would like to know why.
>> Constantine
> 2 observations:
> 1) Just for clarity, in case I misled you in earlier descriptions: Emily
> does not forbid new exceptions, it forbids new exception types. There are,
> in the standard library, several existing exception types that allow you to
> include a character string when you create a new exception of that type, so
> the programmer has some flexibility in creating informative exceptions. 
Yes. I meant new exception types. String is not enough as it could not 
be reliably used in pattern matching. There are cases when information 
is lost when converted to string and back using built-in primitives. 
Floats come to mind first, hex or bin encoding should be used to 
preserve value. Also  there might be an ambiguity when independent 
modules generate the same value by the chance.
> 2) Even so, you are correct, fobidding the creation of new exception types
> is harsher than is necessary to prevent the propagation of authority. It
> would be allowable, for the goal of preventing propagation of authority, to
> allow creation of new exception types as long as the new type was
> deep-pass-by-copy. However, it would take amazingly more time and effort to
> build a verifier that could check that then it took to build a verifier that
> just rejects the creation of new exceptions. I consider the harshness of the
> Emily strategy to be acceptable for a version 1.0 implementation, because I
> don't see the lack of ability to create deep pass by copy exception types as
> a serious impediment to the creation of high quality software. 
The problem is that it is not consistent. Strings still allows to leak 
password, private keys, and other sensitive data. The deep-pass-by-copy 
is not a solution to security problem if predefined exceptions are still 
allowed to roam freely.

Alas high-quality software require rich exception system when we get 
into world of Web and Databases. External components can fail in a 
number of interesting ways.

Compilers are a bit simpler case, but even in case of them one might 
want to report ReadAccessDenined and FileNotFound errors differently. 
Strings will complicate matter in this case if localization is required 
(we are talking about high quality software after all), because they 
have to be parsed and constructed again.
> 3) While I can't say I understood the sebyla page on exceptions very well,
> it looks from here like it shares with Emily the defect that data can still
> be passed from one object to another object with which it shares no visible
> communication path (the exception propagation path being pretty invisible).
> To get a full-power solution, one must do something like what Kevin is doing
> for E on CL, which is, sealing the exception and only allowing the stuff
> inside the exception to be read by a catch clause that has its hands on the
> unsealer. While I am glad to see such rigor in E, I believe the risks
> associated with the leak of data through exception propagation to be
> unimportant for many applications for which Emily is applicable, fixing this
> is not even a version 2 feature in my Emily future fantasies :-) Though,
> ironically, I think a crude version of such exceptions can be implemented in
> current Emily 0.9 by the powerbox: the powerbox author would create and pass
> to the CapMain a special exception type and an unsealer for that exception
> type, and the CapMain would distribute them as it sees fit.
It does not look like my proposal have been explained well enough. Let 
me clarify proposal.

Sealing everything is still too harsh. Exception still might contain 
useful information. For example sealing FileNotFound exception, will 
prevent caller from handling the case of missing file. Fields of 
SQLException are often used in Object-Relational Mapping layers for 
error recovery. Some errors means that connection should be closed and 
opened again, other means that the operation should be retried again 
after short pause. Sometimes a text of message should be examined to 
make a correct decision. And ORM component should not have a general 
unsealing capability.

1. The sebyla approach uses sealing too. There is a special exception 
UnhandledException that contains a sealed exception inside it. The 
exception can be thrown from any method. Owner of unsealer (typically a 
logger library) can unseal the exception.

2. The sebyla allows for implementation method to declare which 
exception can escape from it in unsealed from. The exception declaration 
is a feature of implementation rather than of interface. The declaration 
is guard. If the guard is not specified explicitly, it is assumed to 
contain only UnhandledException. Declaring that method throws Exception 
specify that any exception can escape from it. Such declaration is 
useful for utility functions that do not require additional authority 
like array sorting. In that case exception from comparator function will 
be just thrown to upper layer. Declaring that method could throw an 
SQLException will allow SQLExceptions to escape from method.

I believe that sebyla solution provides better balance between security 
and usability than proposed E and Emily solution. It limits 
communication by default. And allows to communicate necessary 
information when it makes sense (SQLException and File*Exception case) 
or when prohibiting communication does not provides additional security 
(the case of comparator).

More information about the e-lang mailing list