in reply to making perl more forgetting

Many operators in perl have a private variable called a "target" that is used to return the result. This is basically a hidden lexical that you can't directly act on. You can try keeping all your sensitive code in coderefs: 
$sensitive_code = eval 'sub {
    my ($foo,$bar,$baz) = @_;
    $sensitive = "D-$foo-$bar-$baz";
    # do stuff with $sensitive
    return;
}';
$sensitive_code->("charanga","Boom","BANG");

[download]
and then undef $sensitive_code; when you want to clean up (followed by a lot of miscellanous code to allocate different sizes of blocks of memory and wipe them). But it's going to be pretty difficult to guarantee success. I'd resort to XS or Inline::C for this.

Update: actually, not sure you need the eval to get/clear a fresh pad.

Replies are listed 'Best First'.
Re: Re: making perl more forgetting
by nothingmuch (Priest) on May 16, 2004 at 19:57 UTC
    Interesting...

    Perhap's some of diotalevi's work with **cking up closures can help in cleaning up these $sensitive_code references.

    -nuffin
    zz zZ Z Z #!perl
[reply]
[d/l]
      I don't believe in any solution to this problem and won't attempt it. Don't bother trying. In fact, see Abigail-II's comments. In theory this is something you can do in C but some discussions on sec-prog lead me to think that it may be difficult to impossible to reliably remove something from memory because the compiler is handy at optimizing away these "useless" optimizations. I recall both MSVC and gcc were under discussion.
[reply]
        To do it right, you need a patch to perl's Perl_sv_clear to wipe the PV buffer, and you need to make sure you don't keep any pads around longer than necessary (by freeing the code that used them). Even so, you are only shortening the window that sensitive data is accessible via /dev/mem. If it's all that sensitive, it's hard to see how that could be good enough.
[reply]

In Section Seekers of Perl Wisdom