Re: 'Restricted' data, an additional security mechanism for Perl.

[hardburn]

A quick brainstorm: A Tie::Scalar::SelfDestruct module. After FETCH is called a given number of times (default 1, but can be changed via a param passed to tie), the data inside is undefed. Of course, you have to be careful that you call FETCH only that number of times. Any more, and you'll just get undef back. Any less, and you were better off not using it at all (though a quick while($tied_scalar) { 0 } would take care of that if you had to). The usual problems with tie apply, of course.

[Abigail-II]

That would give a false sense of security. It'll only protect you by accident, and not at all in the following situation:

    my $super_secret = tie 'Tie::Scalar::SelfDestruct', 1;
    $super_secret = whatever ();
    print EMAIL_TO_BAD_GUY $super_secret;
    print DATABASE $super_secret;

In fact, you are even worse off, because you don't know what you have send to the bad guy.

Abigail

[exussum0]

Well, it's a matter of upholding the architecture. Nothing more. Some people don't value it, some do. It's the entire "backyard" thing.

For most languages, that type of interpretation gets done at compile time. If you can play with pointers/change the permissions dynamically, it's easy to get around, you are right.

[Abigail-II]

Huh? This has nothing at all to do with pointers, or changing permission dynamically. You propose a scheme were information isn't available anymore after N uses, to avoid leaking (by accident or on purpose) of sensitive data into forbidden channels.

I merely point out that that scheme isn't going to work, as the leakage might as well occur before the intended usuage.

What "upholding the architecture" has got to do with it beats me.

Abigail