in reply to Re: 'Restricted' data, an additional security mechanism for Perl.
in thread 'Restricted' data, an additional security mechanism for Perl.

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;

[download]

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

Abigail

Replies are listed 'Best First'.
Re: Re: 'Restricted' data, an additional security mechanism for Perl.
by exussum0 (Vicar) on Feb 09, 2004 at 18:34 UTC
    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.


    Play that funky music white boy..
[reply]
      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

[reply]
        I agree with you 100% on your post about it not protecting the user. I'm just discussing what the point of it is there for. :)

        It's not security against people and getting secrets from the system. Lemme give you an example. Say someone who is writing an encryption module, doesn't want you messing with the initialization vector because it holds no value to other developers, then making it private is up to that developer. The users aren't always people on the other end of a program, but also people who develop using your API. Those people who write the API are the ones who define the architecture to be "upheld".

        I'm just pointing out that while yeah, it doesn't protect end users in the long run from getting data out of the system. Just make the process core dump, right? That protection is against people extending the system (or playing with it) in awkward ways that they shouldn't depend on. It might change, or may break something. That's what upholding the architecture is about. It means developers don't do stupid things and make it really hard for them to do just that and keeping the ideas behind the system right

        It's the bars around dangerous machinery. People aren't trusted to not hurting themselves. For perl, the bars are a simple line in the sand saying, don't cross this line. For some languages, it's a steel wall.


        Play that funky music white boy..
[reply]

In Section Meditations