[e-lang] Introducing Emily,
a High Performance Language For SecureCooperation
cap at isg.axmor.com
Mon Feb 20 05:48:36 EST 2006
>> I think forbidding new exceptions is too harsh. There is a
>> solution to
>> this problem. See my old article:
>> If it is an incorrect solution, I would like to know why.
> 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
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