[unprotect]
[1/4] from: maximo::meteorstudios::com at: 17-Mar-2004 18:45
Funny,
I just discovered 'unprotect word ...
is there a higher order 'protect, which actually does not allow unprotect?
Maybe a refinement should be added to protect, so that no malicious code can play around
with stuff you've protected in your user.r... like read/write/save/load/open for example
something like protect/permanent or protect/forever
this is especially true when one adds sandbox capabilities to his setup and does not
want downloaded code to seep through it...
just a tought... does any one agree?
-MAx
---
You can either be part of the problem or part of the solution, but in the end, being
part of the problem is much more fun.
[2/4] from: ammon:addept:ws at: 17-Mar-2004 17:04
I definitely agree here, especially in light of hte new plugin.
Enjoy!!
~~Ammon ;~>
----- Original Message -----
From: "Maxim Olivier-Adlhoch" <[maximo--meteorstudios--com]>
To: "Rebol-List (E-mail)" <[rebol-list--rebol--com]>
Sent: Wednesday, March 17, 2004 4:45 PM
Subject: [REBOL] [unprotect]
> Funny,
>
> I just discovered 'unprotect word ...
>
> is there a higher order 'protect, which actually does not allow unprotect?
>
> Maybe a refinement should be added to protect, so that no malicious code
can play around with stuff you've protected in your user.r... like
read/write/save/load/open for example
[3/4] from: atruter:labyrinth:au at: 18-Mar-2004 12:04
> is there a higher order 'protect, which actually does not allow
> unprotect?
How about:
unset 'unprotect
(perhaps followed by a couple of selective removes from system/words)
Regards,
Ashley
[4/4] from: nitsch-lists:netcologne at: 18-Mar-2004 12:49
On Donnerstag, 18. M=E4rz 2004 00:45, Maxim Olivier-Adlhoch wrote:
> Funny,
>
> I just discovered 'unprotect word ...
>
> is there a higher order 'protect, which actually does not allow unprotect?
>
> Maybe a refinement should be added to protect, so that no malicious code
> can play around with stuff you've protected in your user.r... like
> read/write/save/load/open for example
>
Will not protect against malicious code anyway, as you can change the
functions code anyway by [second :my-func].
protect is a helper to find coding-bugs.
unprotect makes sense when one wants to patch an inbuild functions, like
protect-system unprotect[prin print]
security-rule: do not put important data in the process before calling dubious
code. use launch or call to fire up such code in its own exe if you really
need to run it. i use 'call with a wrapper-script, which sets security higher
in such cases. allows also to choose a old exe which has better sandbox.
while using a fresh beta for my own stuff.
> something like protect/permanent or protect/forever
> this is especially true when one adds sandbox capabilities to his setup and
<<quoted lines omitted: 4>>
> "You can either be part of the problem or part of the solution, but in the
> end, being part of the problem is much more fun."
-Volker
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted