[EMAIL PROTECTED] 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 ___________________________________________________________ [EMAIL PROTECTED] http://www.FourthWorld.com
_______________________________________________ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
