World: r3wp

Depends on where you put %user.r and your OS capabilities, I guess.

Until %user.r is validated, you can't trust it. We can compare against 
checksums for other scripts, but there's no safe place to store a 
checksum for %user.r where it can be updated by the user script, 
because we don't have a "trusted code" concept in R3.

Just store %user.r read-only and owned by an admin group and be done 
with it.

(And still assuming you have eliminated all other similar security 
leaks from your regular OS usage.)

But thanks for the reformulated explanation. I now understand your 
concerns.

Andreas, by %user.r, I mean a file that would be loaded from the 
user's home directory or some subdirectory of it (.rebol, %appdata%\REBOL, 
whatever), and which could be manually writeable by the user when 
REBOL isn't running (or else its syntax wouldn't need to be human-readable 
and writeable). If you decide to skip any of those constraints, you 
can secure it despite the limited security models of most the OSes 
we support.

Those are the standard constraints of a preferences file, but there 
are some programs that make exceptions.

Agreed on all points. But if you don't make the file writable without 
having to elevate your permissions first, does that not solve your 
immediate security concern?

Not all platforms supported by R3 have permissions elevation. We 
support Windows all the way back to 2000, and permissions elevation 
wasn't introduced until Vista. Plus, that wouldn't work for multiuser 
systems where the user doesn't have the admin password (possible 
because they're the target market of these restrictions).

Must run now, I'm late already :(

So that's a "yes, that would solve the security issue", I gather.

With a "but (some) OSes can't do this" constraint.

See you later.

With a "some OSes won't allow users to edit or save their own preferences, 
so preferences are half broken on those OSes" constraint, that would 
solve the issue.

I am still having issues with what is considered "secure" here. As 
far as REBOL goes, for me, it is not unsecure, if it relies on the 
user environment being secure. (How can any program be secure, if 
it runs in an insecure environment?) Thus, the only concern I do 
have as far as REBOL goes is my wish for the REBOL interpreter to 
not overwrite the %user.r file unless specifically allowed to do 
that.

Any additional security is just an illusion for me.

I agree.

It seems that rebol3 is having some real problems. What's this I 
hear about Carl getting a job?

He did

Is he still the benevolent overlord of r3?

He's the absent overlord

What's happened to development?

Well, he can only spend his time once

Has it stopped?

Pretty much

When did this start?

Almost half a year ago, at least visibly, in hindsight

Other people have the source code don't they?

No, why would they?

Otherwise the community will just rot.

Better pinch your nose

I feel let down. If Carl takes a break he has to entrust the source 
code and development to someone else.

Is there much action on boron?

That makes more of us. The overriding argument for REBOL and its 
closedness was always that Carl was the leader, he always knew best, 
and development always continued

Boron is going steady, but it's an isolated project, much in the 
same style as REBOL. The community is more interested in Red

I heard about it. What's red for?

Programming :-)

haha

How many people are working on it?

Four or five or so

maturity? what can it do atm?

One month :-)

Why is it more popular than boron? Did the boron guy start red?

It can do loops, but not indexing, so you could have called me out 
on claiming it can do programming ;-)

It seems very low level

Yes, so far, but that's only Red/System

What are the plans for it?

Have you read the sites?

Oh, there's a to do list

I was looking for more of a long term outlook