From: gwtmp01@...
Date: 2006-01-08T15:08:10+09:00
Subject: Re: Ideas on "Why Living Dangerous can be A Good Thing" in Ruby?


On Jan 8, 2006, at 12:01 AM, Gregory Brown wrote:

> On 1/7/06, Gregory Seidman <gsslist+ruby@anthropohedron.net> wrote:
>
>> I'm not clear on what openness we're talking about. Do you mean  
>> one or more
>> of the following:
>
>> 3) duck typing allows unintended objects to be used in unintended  
>> ways
>>
>> 4) the ability to add/replace methods in existing classes allows  
>> library
>>    internals to be inspected or modified
>
> These two.
>
> Which are considered as features by most, but often as vulnerabilities
> by outsiders :)

If there are vulnerabilities, who are the attackers?  I think there are
reasonable issues to discuss in this area but I think the language  
choice
kind of skews the discussion.  Why is the situation characterized as a
'security' issue?  Why are the contents of a library viewed as some sort
of national secret that must be protected from prying eyes/objects?
What is being 'protected'?  Why? From Whom?

I don't think C/C++/Java library designers view programmers of client
code as actively hostile, like some sort of foreign agent trying to  
sneak
in to commit sabotage, yet it sounds like that is the scenario that  
is in
their mind when they ask how Ruby/Python/Perl/Smalltalk/etc can  
"protect" against
such problems.

I think it is really just a matter of phrasing the concern in
a different way:

    In a statically typed language, the compiler can help to identify
    programming errors during the compilation process instead of
    at run time.  What tools and/or techniques can be used with Ruby to
    identify programming errors before the code is put into production?

Gary Wright