On 10 July 2014 01:08, Jonathan S. Shapiro <[email protected]> wrote:
> On Tue, Jul 8, 2014 at 5:47 PM, William ML Leslie
> <[email protected]> wrote:
>>
>> This is my understanding too. You can do sensible security whether you
>> admit downcasting or not, and if you don't have to give it up why would you?
>> Really it is much of a muchness, besides questions about identity.
>
> You can, but it becomes a feature that you then have to think about
> constantly to make sure its use doesn't bite you in the ass. If you are
> handing a reference across a "suspicious" interface boundary, its best to
> *think* of it has handing over a leaf class reference.

It could be useful to say that, but I don't think this is a common
interpretation.

> From a security perspective, it's better to eliminate such worries from the
> beginning, or at least narrow the number of places where attention must be
> paid.

I think you have a good place to pay such attention: downcasting
requires that the target type be lexically visible.  By not exporting
the concrete type, you prevent such downcasts.

> The real question, as I attempted to say elsewhere, is: "is this the right
> conceptual layer at which to be thinking about mutual suspicion?"

I'm not entirely sure either way.  I'm suspicious of B&D constructs
for their own sake.  I would like to ask the question, under what
conditions _should_ I be able to downcast?  If I have a reference to
the original object, for example, can I determine if something of an
interface type is the same object?  Because then I can just substitute
one reference for another.

-- 
William Leslie

Notice:
Likely much of this email is, by the nature of copyright, covered
under copyright law.  You absolutely MAY reproduce any part of it in
accordance with the copyright law of the nation you are reading this
in.  Any attempt to DENY YOU THOSE RIGHTS would be illegal without
prior contractual agreement.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev

Reply via email to