«

I'm writing a library that is supposed to be customized with
potentially sensitive info (passwords, etc.). All these variables
are defined in a file MyModule/Config.pm:

package MyModule::Config;

our %Config = (
user => 'yours_truly',
password => 'topsecret',
# etc., etc.
);

During development, my working copy of MyModule/Config.pm holds
real values for various variables, which obviously I don't want to
publicize. This means that, in order to build the distribution
package for release, one of the things I must do is change all the
values of these variables. Conversely, if I want to test a released
version of our software, as stored in our CVS repository, I first
must change the values of these variables back to those that make
sense for our system. There is always a mismatch between what we
release and what we use locally , and at least one of these must
necessarily be different from what is stored in our CVS repository.
Hence, there's a major conflict between the desire to make our CVS
repository world-accessible, and the the developers' wish to be
able to commit to the repository files that have sensitive information.

Some possible ways to solve or mitigate this problem (e.g.
/usr/bin/make) have nothing to do with Perl, but I was wondering
if there are Perl techniques to architect such software that would
facilitate implementing a solution to this problem.

Thank you very much for your thoughts,

kj
--
NOTE: In my address everything before the period is backwards.

Quoth kj <>:
>
> I'm writing a library that is supposed to be customized with
> potentially sensitive info (passwords, etc.). All these variables
> are defined in a file MyModule/Config.pm:
>
> package MyModule::Config;
>
> our %Config = (
> user => 'yours_truly',
> password => 'topsecret',
> # etc., etc.
> );
>
> During development, my working copy of MyModule/Config.pm holds
> real values for various variables, which obviously I don't want to
> publicize.

> Hence, there's a major conflict between the desire to make our CVS
> repository world-accessible, and the the developers' wish to be
> able to commit to the repository files that have sensitive information.

You could perhaps always keep the fake data in your dev tree (and in
CVS), and then have a separate directory /path/to/private with a
different MyModule/Config.pm in containing sensitive data. If you add
this /path/to/private to $PERL5LIB in your working environment, perl
will find and use the real data while you are testing, but the real data
never comes near the dev tree so definitely won't get shipped or checked
into CVS.

Ben

--
Joy and Woe are woven fine,
A Clothing for the Soul divine William Blake
Under every grief and pine 'Auguries of Innocence'
Runs a joy with silken twine.

kj wrote:

>
> I'm writing a library that is supposed to be customized with
> potentially sensitive info (passwords, etc.).

Maybe try a symmetric encryption algorithm eg DES
This will at least hide the values to a casual observer.

gtoomey

kj <> wrote:
> I'm writing a library that is supposed to be customized with
> potentially sensitive info (passwords, etc.). All these variables
> are defined in a file MyModule/Config.pm:
>
> package MyModule::Config;
>
> our %Config = (
> user => 'yours_truly',
> password => 'topsecret',
> # etc., etc.
> );
>
> During development, my working copy of MyModule/Config.pm holds
> real values for various variables, which obviously I don't want to
> publicize. This means that, in order to build the distribution
> package for release, one of the things I must do is change all the
> values of these variables. Conversely, if I want to test a released
> version of our software, as stored in our CVS repository, I first
> must change the values of these variables back to those that make
> sense for our system. There is always a mismatch between what we
> release and what we use locally , and at least one of these must
> necessarily be different from what is stored in our CVS repository.

Make two MyModule::Config.pm, one that has dummy data, is included in
CVS and in your ordinary dev source tree, and another with the real data.
Make sure the path to the one with the real data is in @INC before the
path to the dev source tree, so it will find the right one.

Xho

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB