For xxx sake!

[Ken Ray]

On 9/14/04 3:43 PM, "Klaus Major" <klaus at major-k.de> wrote:

>> [1] I can appreciate protecting script and  copying access to prevent
>> circumventing protected stacks, but "clone" can do  nothing except
>> duplicate in the
>> same environment.
> 
> Yes, so it is kind of useless in protected stack...

No, it's actually useful regardless of whether the stack is protected or not
(it all depends on whether your app depends on being able to clone objects)
- I think Hugh's point is that if the concern is one of security, it's not
like "copy", which can copy one object from one stack to another which might
be used to copy an object from a protected stack to a non-protected stack;
with "clone", it only makes a copy on the same stack (protected or not), so
there's no security risk.
>> we need
>> to be able to  unlock, do whatever, then *re-set* the protection. This
>> last
>> step is not  available, and until 2.5 was not required. Not only
>> should it now
>> be available,  but it has become a CRITICAL command.
> 
> Sorry, don't get this one either...?
> 
> You mean setting the passkey, doing whatever, saving and closing the
> stack DOES remove the password/protection?

No, what he's saying is that currently we have the ability to unlock a stack
at runtime by setting the passkey. But you can't lock it back up again at
runtime; the password will protect the stack *after* it's been closed and
reopened (i.e. the passkey effect is temporary), but during the *session*
while the stack is open, you can't "re-protect" it. This is something that
is very much needed in order to "close the loop" on security.


Ken Ray
Sons of Thunder Software
Web site: http://www.sonsothunder.com/
Email: kray at sonsothunder.com