Re: hiding global variables

On Nov 8, 11:38 pm, "Donal K. Fellows"
<donal.k.fell...@xxxxxxxxxxxxxxxx> wrote:
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...

do you know where this info can be found?

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].

info body is smartly hidden when you use tclcompiler.

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.
this already requires the hacker to work harder.

Added to which I've heard of code that makes use of many of the
subcommands for non-hacking purposes too, which you seem to be proposing
to break...
we also use 'info exists'. Still there is tradeoff. if you compile
your code you get it hidden and you 'lose' info body. you could also
accept the fact that you give up info commands/procs/args when
compiling code. if you want them, do not compile your code.

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!)

with info commands it does not really matter. but if it was blocked
the way info body is?

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

that is an interesting idea. I will check it.

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.
As I sayed my fear is the package we use for data decrypting. hacker
can try to use it from the command line and open all encrypted data.
We created a package as many of our scripts needs decrypting and also
the package handles the keys in a more securer way BUT the package
itself is a weak chain.

I did also hacking in the past (all legal :-)) and what I learned is
that where it was easy I was able to use things to my wishes easily.
where it was harder I gave up. All I want is to make it harder. I have
no illusion of foolproof.