Provided by: libstore-opaque-perl_0.03-1build6_amd64 bug


       Store::Opaque - Opaque objects to prevent accidental Dumping or appearance in stack traces


         package MyCreditCardInfo;
         use strict; use warnings;
         use Store::Opaque;
         our @ISA = qw(Store::Opaque);

         sub get_creditcard_number {

         sub set_creditcard_number {
           $_[0]->_set("ccnumber", $_[1])

         # use this like any other object...


       Before you go any further, please do realize that this module is not directly about
       security in the sense of preventing malicious action!  It's about preventing mistakes that
       could turn out to be a security or compliance issue.

       Consider that you have code that handles sensitive data that should never end up in your

         use Carp;
         foo("This does not belong in logs");
         sub foo {
           my $super_sensitive = shift;
         sub this_can_die {
           Carp::confess("Gotcha"); # stack trace

       If you're logging erros, you get this in your logs:

         Gotcha at /tmp/ line 8
                 main::this_can_die() called at /tmp/ line 5
                 main::foo('This does not belong in logs') called at /tmp/ line 2

       Great, not! Various techniques can be used to fix this. The easiest one is simply using
       hash-based objects to store this info and pass it around.  In general, you'd pass it
       around as some sort of reference to prevent this.

       Alas, that is easily defeated by accident if developers write stuff like this:

         sub foo {
           warn Data::Dumper->Dump(\@_); # FIXME just for debugging
           my $super_sensitive = shift;

       Again, there's a myriad of ways to explicitly defeat that, but I'd bring up the more
       powerful Data::Dump::Streamer (in conjunction with PadWalker and B::Deparse) next. Even
       inside out objects can accidentally be dumped if you're using Data::Dump::Streamer to dump
       their methods.  It's becoming progressively less easy to make a mistake like the above,
       but why bother?

       This module implements an opaque object implementation that does not suffer from these
       issues. Let me repeat. This isn't about hiding anything from an attacker.  It's about
       preventing mistakes from people who have legitimate access.

       Oh, and don't use this for *all* of your objects as it comes with a small memory and
       moderate performance overhead.


       If you do not fully understand the previous section, look elsewhere and do not use this


       You use this module by subclassing. If that doesn't work for you, you can manually import
       the methods in the class. If you don't know how that works, you shouldn't be doing it.

       Your subclass will inherit the following methods:

       Simple constructor that takes no arguments. You can override is as follows:

         sub new {
           my $class = shift;
           my $self = $class->SUPER::new;
           # initialize here
           return $self;

       Generic setter for the stored information:

         sub set_ccinfo {
           my $self = shift;
           my $value = shift;
           $self->_set("ccinfo", $value);

       where "ccinfo" is the key to store the $value under. If this feel reminiscent of a hash,
       then that's not coincidental as the object is a hash under the hood.

       You can use any string has a key that would otherwise work in a normal hash-based object.

       Generic accessor for the stored information. Works just liek "_set" without the $value.


       Steffen Mueller, <>


       Copyright (C) 2011 by Steffen Mueller

       This library is free software; you can redistribute it and/or modify it under the same
       terms as Perl itself, either Perl version 5.8.1 or, at your option, any later version of
       Perl 5 you may have available.