Encrypted stack doesn't behave properly - oops; yes it does.

[Robert Brenstein]

>Recently, "Robert Brenstein"  wrote:
>
>  > But is it possible to unlock the stack for the duration of a given
>  > script only? Assume a handler that needs to do sth that requires a
>>  stack to be unlocked. It sets the passkey and does its business.
>>  However, it seems that this unlocks the stack until it is closed,
>>  thus opening it potentially for mischief. Is the a way to lock the
>>  stack back before the handler ends? It would be logical if setting a
>>  password did that trick, but does it?
>
>I don't believe this is an issue.  Rev loads a stack into memory before
>running, and it doesn't save anything to the drive until you tell it to do
>so.  Thus if your stack was password protected on the drive, it will stay
>that way until you save it without a password.
>
>Also, keep in mind that setting a passkey allows you to edit scripts until
>the stack is closed; it does not remove the password from the stack.
>
>Regards,
>
>Scott Rossi
>Creative Director
>Tactile Media, Multimedia & Design

Yes, all true but that was not my issue.

Take 2. Is it possible to unlock the stack for the duration of a 
given script only? In other words, is it possible to restore locked 
state without closing the stack? I don't think so. I have tested a 
number of options and can't seem to be able to relock the stack once 
it is unlocked.

The issue is that once the passkey is set, the scripts are no longer 
protected. This means that a user may see what they may not be 
supposed to see. Remember that password protecting the stack has been 
advocated here not only to protect scripts but also sensitive data. 
However, dynamic scripting usually requires unlocking the stack to 
succeed.

Since setting password to empty removes protection, a logical 
extension would be that setting passkey to empty relocks the stack. I 
have just entered this into bugzilla as a suggestion (#546).

Robert Brenstein