Protected stacks in 2.61 (was For goodness sake!)

[Richard Gaskin]

FlexibleLearning at aol.com wrote:
 >>> The first thing I always do when creating new stacks is to set
 >>> destroy on for the reasons that Ken outlined plus password
 >>> protection.  In fervor of testing the cloning, I forgot to set
 >>> it and was surprised  that password protection was not working.
 >>
 >> In such a circumstance the only risk is  others using your
 >> machine during the same MC session.  The  password is preserved
 >> on disk regardless of the state of the  destroyStack property.
 >
 > Which neatly returns us to the crucial issues of  either
 > re-introducing 'clone' for template stacks etc in password
 > protected stack, AND/OR allowing runtime password protection
 > to maintain  security.

Agreed.  The engine's ability to clone stacks while maintaining their 
security has become a critical part of many folks' designs for many 
years, apparently abandoned to solve a "vulnerability" in v2.5.

Since the password is known to migrate with the stack, it seems this 
"vulnerability" is only peripherally related to the clone command 
itself.  Although the precise nature of the vulnerability is not 
publicly known of course, because it appears to be only peripherally 
related to the clone command I'm confident that a solution can be found 
which preserves this long-standing and critical feature.

Hopefully will be restored in the very next bug-fix release.

Please consider adding your votes and comments to:
<http://support.runrev.com/bugdatabase/show_bug.cgi?id=2204>

-- 
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________________
  Ambassador at FourthWorld.com       http://www.FourthWorld.com