Use-Case 2: Giving Your Program To Untrusted Persons

Sometimes you would want to give your source code to a person who you do not really trust. For example, somebody offered you to port your program to another system, but you do not intend to release the source code to the public.

Another explanation can be that you simple want people be able to compile your program, but you do not want them to be able to change it. There are numerous reasons for this attitude, among them are:

Other people contributing to your source code usually do not know how it works, and often you will have to have to modify their changes, usually resulting into more work than if you would have done it on your own from the beginning.
Other people might port your program to a system you do not want to support because of ideologic reasons.
Other people doing changes usually do not care about your indention and naming style, do not add comments in a way you are used to and so on.
Other people tend to fix little problems they encounter on their local copy of the source code, but never report them to you.

When releasing your source code as vahunzed version, most of these things will be near to impossible to perform. However, if you receive a bug-report about a compiler problem, it often might look like:

sepp.c: error in line 129: symbol x3R unknown

If you vahunzed your source code with the default options, the only thing that will match with the original is the filename sepp.c. Finding out which line and symbol in the original relate to those mentioned in the error message can be very hard - even for the one with the original.

Fortunately, there are some command line options to avoid this.

With --line you can ensure that the line numbers in the vahunzed version will be the same as in the original. However, this will result into several empty lines, especially if you have many multi-line comments, for example for your Autodocs.

Another useful one is --random-seed, which will always create the same vahunzed names. Once x3R, always x3R. Of course this only works as long as you use the same original source codes, too. If the source code changes, so does the sequence of words found in it, and therefore also the sequence of randomly created words.

For example, you could use

vahunz --line --random-seed=37

and you do not even need to backup the vahunzed sources after the release, as you always can create identical ones from the original source every time you like. Of course this assumes you do a backup of your original source for every release version, or you can reestablish one by means of tools like CVS or RCS.

Still, it may be awful to trace back what the x3R from before meant initially. In that case, you can enable the flag --store, and for every vahunzed name the garbled text will also be stored in the dictionary.

Let's assume that the x3R once was called read_settings_file. It was garbled, because your dictionary contained a line like:

+read_settings_file

If --store is specified, after vahunzation the same line will look like this:

+read_settings_file=x3R

Therefore it should be easy to trace vahunzed names back, as all you will have to do is entering

search vahunz.names "=x3R"

and the line above should be displayed.

The only thing you will have to remember is the random seed you specified. Additionally you can include vahunz.names in your backup. But take care vahunz.names is not included in the release archives you tend to give to other people.

And also do not forget to change your random seed from time to time.