Advice: hiding sensitive info used in devel

Discussion in 'Perl Misc' started by kj, Jun 5, 2004.

  1. kj

    kj Guest

    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.
    kj, Jun 5, 2004
    #1
    1. Advertising

  2. kj

    Ben Morrow Guest

    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.
    Ben Morrow, Jun 5, 2004
    #2
    1. Advertising

  3. 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
    Gregory Toomey, Jun 5, 2004
    #3
  4. kj

    Guest

    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
    , Jun 5, 2004
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Martin

    Web Devel Express .NET 2.0.40903

    Martin, Feb 2, 2005, in forum: ASP .Net
    Replies:
    0
    Views:
    307
    Martin
    Feb 2, 2005
  2. .
    Replies:
    0
    Views:
    715
  3. Alexander
    Replies:
    9
    Views:
    529
    Jorgen Grahn
    Jan 12, 2011
  4. Ste
    Replies:
    41
    Views:
    804
    Thomas 'PointedEars' Lahn
    Aug 1, 2007
  5. goldtech
    Replies:
    2
    Views:
    582
    Stefan Behnel
    Nov 11, 2012
Loading...

Share This Page