Larry Wall wrote:
Do bear in mind that Perl can execute bits of code as it's compiling,
so if a bit of code is untrustworthy, you shouldn't be compiling it
in the first place, unless you've prescanned it to reject Cuse,
CBEGIN, and other macro definitions, or (more usefully) have hooks
in the
At 2:57 PM +0100 3/26/04, James Mastros wrote:
Larry Wall wrote:
Do bear in mind that Perl can execute bits of code as it's compiling,
so if a bit of code is untrustworthy, you shouldn't be compiling it
in the first place, unless you've prescanned it to reject Cuse,
CBEGIN, and other macro
On Fri, Mar 26, 2004 at 09:26:45AM -0500, Dan Sugalski wrote:
: Yup. Subroutines and methods are privilege boundaries, and code with
: extra rights may call into less privileged code safely. We need to
: work out the mechanism though.
One thing you'll have to do in that case is disable the
[EMAIL PROTECTED] (Dan Sugalski) writes:
At 5:48 PM -0500 3/23/04, Joe Schaefer wrote:
[...]
IMO, the advantage would be that parrot apps will have a better idea
of what security model is appropriate.
Well... maybe.
Parrot apps don't get a whole lot of say here--this is more on the
[EMAIL PROTECTED] wrote:
It can be safe. Normally, PCC works by certifying the code during
compilation, and attaching the machine-checkable certificate with the
resulting compiled code (be that bytecode, machine code or whatever).
During runtime, a certificate checker then validates the
At 1:06 PM -0500 3/24/04, Joe Schaefer wrote:
[EMAIL PROTECTED] (Dan Sugalski) writes:
At 5:48 PM -0500 3/23/04, Joe Schaefer wrote:
[...]
IMO, the advantage would be that parrot apps will have a better idea
of what security model is appropriate.
Well... maybe.
Parrot apps don't get a
Do bear in mind that Perl can execute bits of code as it's compiling,
so if a bit of code is untrustworthy, you shouldn't be compiling it
in the first place, unless you've prescanned it to reject Cuse,
CBEGIN, and other macro definitions, or (more usefully) have hooks
in the compiler to catch and
Larry Wall wrote in perl.perl6.internals :
Do bear in mind that Perl can execute bits of code as it's compiling,
so if a bit of code is untrustworthy, you shouldn't be compiling it
in the first place, unless you've prescanned it to reject Cuse,
CBEGIN, and other macro definitions, or (more
Rafael Garcia-Suarez wrote:
prevent
eval 'while(1){}'
or
eval '$x = take this! x 1_000_000'
Or hog both (for a small while):
eval 'while([EMAIL PROTECTED],0){}'
or my personal favourite, the always funny
eval 'CORE::dump()'
unless you set up a very restrictive set of
At 11:35 PM +0200 3/25/04, Jarkko Hietaniemi wrote:
Rafael Garcia-Suarez wrote:
prevent
eval 'while(1){}'
or
eval '$x = take this! x 1_000_000'
Or hog both (for a small while):
eval 'while([EMAIL PROTECTED],0){}'
Which, if the interpreter's running with quotas, will be caught
[EMAIL PROTECTED] (Dan Sugalski) writes:
[...]
#s 34 deal with security. This... this is a dodgier issue. Security's
easy to get wrong and hard to get right. (Though quotas are
straightforward enough. Mostly) And once the framework's in place,
there's the issue of performance--how do we get
Dan Sugalski [EMAIL PROTECTED] wrote:
At any rate, perl 5's Safe module is a good example of the Wrong Way
to do security, and as such we're going to take it as a cautionary
tale rather than a template.
Ok. What about Ponie?
leo
At 2:50 PM +0100 3/24/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
At any rate, perl 5's Safe module is a good example of the Wrong Way
to do security, and as such we're going to take it as a cautionary
tale rather than a template.
Ok. What about Ponie?
What about it?
Dan Sugalski wrote in perl.perl6.internals :
At 2:50 PM +0100 3/24/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
At any rate, perl 5's Safe module is a good example of the Wrong Way
to do security, and as such we're going to take it as a cautionary
tale rather than a
At 2:50 PM + 3/24/04, Rafael Garcia-Suarez wrote:
Dan Sugalski wrote in perl.perl6.internals :
At 2:50 PM +0100 3/24/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
At any rate, perl 5's Safe module is a good example of the Wrong Way
to do security, and as such we're
At 5:48 PM -0500 3/23/04, Joe Schaefer wrote:
[EMAIL PROTECTED] (Dan Sugalski) writes:
[...]
#s 34 deal with security. This... this is a dodgier issue. Security's
easy to get wrong and hard to get right. (Though quotas are
straightforward enough. Mostly) And once the framework's in place,
At 12:36 PM +1100 3/24/04, [EMAIL PROTECTED] wrote:
On 24/03/2004, at 6:38 AM, Dan Sugalski wrote:
At any rate, perl 5's Safe module is a good example of the Wrong
Way to do security, and as such we're going to take it as a
cautionary tale rather than a template. For security I want to go
with
On Mar-24, Dan Sugalski wrote:
At 12:36 PM +1100 3/24/04, [EMAIL PROTECTED] wrote:
On 24/03/2004, at 6:38 AM, Dan Sugalski wrote:
This is a question without a simple answer, but does Parrot provide
an infrastructure so that it would be possible to have
proof-carrying[1] Parrot bytecode?
On 25/03/2004, at 2:39 PM, Steve Fink wrote:
On Mar-24, Dan Sugalski wrote:
At 12:36 PM +1100 3/24/04, [EMAIL PROTECTED] wrote:
On 24/03/2004, at 6:38 AM, Dan Sugalski wrote:
This is a question without a simple answer, but does Parrot provide
an infrastructure so that it would be possible to
Okay, we'll try this again... (darned cranky mail clients)
We've two big issues to deal with here--safety and security. While
related they aren't the same and there are different things that need
doing. As far as I can see it, we need four things:
1) An oploop that checks branch destinations
At any rate, perl 5's Safe module is a good example of the Wrong Way
to do security, and as such we're going to take it as a cautionary
tale rather than a template. For security I want to go with an
explicit privilege model with privilege checking in parrot's
internals, rather than
On 24/03/2004, at 6:38 AM, Dan Sugalski wrote:
At any rate, perl 5's Safe module is a good example of the Wrong Way
to do security, and as such we're going to take it as a cautionary
tale rather than a template. For security I want to go with an
explicit privilege model with privilege checking
22 matches
Mail list logo
