Re: hiding global variables

yahalom wrote:
I still wish there was some way of disabling info commands and info

In 8.5 you can. The [info] command is an ensemble and those subcommands
are implemented as calls to other commands (whose names I forget right
now). You can simply delete the commands that they map to, and the
capability will be gone. But...

Without them tcl compiled code was much securer.

That's so deluded it's rather funny. You've forgotten to list many other
info subcommands that would probably be useful to the attacker too. For
example [info procs], [info body], [info default]. You'll also have to
disable [load], as it's really easy to take the code to implement, e.g.,
[info args] and put that in an extension.

Added to which I've heard of code that makes use of many of the [info]
subcommands for non-hacking purposes too, which you seem to be proposing
to break...

I could even
change procedure names using sed before compilation and then even
developers where finding it hard to hack the program.

You could write it in classical Basque too, but it wouldn't actually
make much difference other than annoying your developers. The command
names aren't really that important to anyone who is taking the trouble
to pry. (Really!)

Another approach
could be requiring a password in a package like:
package require cryptic -password secretPass
so you cannot load the package without the password.

What you *could* do is require a special global variable (containing the
password) to be set before the package is loaded, with the package
deleting the variable during load. Or you could only distribute the
package on an encrypted virtual filesystem, requiring the password to
mount. But it's really *much* more secure to put the encrypted code in
another interpreter so that user scripts can only execute *exactly*
those special commands of yours that you want them to and which you've
presumably documented for them. Note that the separate interpreter
mechanism is designed to be a real security system, and in particular is
designed to handle the case where the called code (e.g. the users') is
actively antagonistic to the caller (yours). At that point, you're much
safer because you never run code that would want to probe your secrets
in a context where you expose them.