World: r3wp

But the slowness of validating would be offset by the speed of loading 
and saving, so it might be worth it.

Another disadvantage is that loading errors are currently harder 
to recover from with serialized constructors than they are with normal 
literal values like blocks. There's a ticket about this already. 
However, if you are loading the entire preference file in one go 
and just catching the error with TRY, there's no difference in the 
error handling.

The only consensus we reached was that %user.r would be a good place 
to store preferences, and that it should only store data. Executable 
code would be prohibited in %user.r, and screened for.
 - frankly, that decision never made sense to me.

In my opinion, it is not more secure at all.

...and I am afraid, that it is not hard to prove

...serialized constructors...
 - For me, the terminology is quite unfortunate, because

     "1 2"

is not "more serialized" than

    "#[false] #[true]"


I still do not understand, why it is so important to pretend the 
opposite.

Such an approach just leads to bugs.

Instead of saying 'not "more serialized"', I should have said 'not 
"more or less serialized"'

Interesting point.  I would suspect the goal is to have the first, 
or top level be "code free", such that it is just settings.

But then, if you "want" you can call upon other files that contain 
code.

As a concept it sounds smart, which is unrelated to the reality that 
it might not be possible.

So, "is it" possible.

Serialized constructors as opposed to serialized values. I used the 
"constructors" term to emhpasize the difference because the important 
distinction in that statement is the additional code that those constructions 
run in the loading process, beyond that in TRANSCODE itself. See 
http://issue.cc/r3/1857for the bug in question.

The security issue is to not have a file that is done automatically 
be writeable using the same permissions that the scripts are run 
under. It's a way to prevent worms.

The real distinction is between serialized constructors: #[map! [a 
1]]

and programmatic constructors that you have to DO: make map! [a 1]

The security issue is to not have a file that is done automatically 
be writeable using the same permissions that the scripts are run 
under.

- I do not have any problem to agree with that. But, in my opinion, 
this does not require to ban files, that are done automatically. 
Rather, we should make it possible to define special rights for such 
files.

real distinction is between serialized constructors: #[map! [a 1]]...

 - in my opinion, these are not "constructors" for REBOL programmers, 
 since they cannot define them

Not at the OS level. We can only define permissions within REBOL 
itself, not permissions when it isn't running. And REBOL doesn't 
have any facility for user-specific permissions.

Ladislav, REBOL programmers can't define constructors, but they are 
still constructors. We can't define MAKE behavior either (until we 
get user-defined types).

as said, for me the formulation: "...a file that is done automatically 
be writeable using the same permissions that the scripts are run 
under..." is substantial, and it can be done, as far as I know.

Technically, the #[map! []] syntax is not a constructor itself, it 
merely calls a constructor :)

The security issue is to not have a file that is done automatically 
be writeable using the same permissions that the scripts are run 
under.

sorry, i don't get that. could you try reformulate the problem?

REBOL programmers can't define constructors, but they are still constructors
 - technically not, since they are not definable

The definability is a property that is used to explain what a constructor 
is.

Being defineable doesn't make it a constructor. Constructing something 
does.

OK, my opinion:


The user does neither "see" nor is able to define any constructors. 
What you are referring to are some syntactic constructs, that are 
not constructors at all.

The difference between #[map! [...]] and a constructor is roughly 
the same as the difference between a constructor, and a list of arguments 
given to the constructor, when a constructor is called - it is a 
totally different thing.

I am talking about the code that is called when those syntactic constructs 
are loaded, which is type-specific and constructs a value of that 
type. REBOL types have 3 builtin constructors (#[type ...], MAKE 
and TO). The user can't create new constructors because the user 
can't create new types.

For me, it is just a mess, the "serialized constructors" don't exist 
at all.

And #1857 indicates that the #[type ...] constructors are seperate 
code from TRANSCODE, and called by it.

...and it surely does not make sense to call #[map! [...]] a "serialized 
constructor" - it is just a syntactic "construct" used as data by 
something.

Quoting myself from above: "Technically, the #[map! []] syntax is 
not a constructor itself, it merely calls a constructor :)"

It clearly does not correspond to the definition of the "constructor"

That is why I am not a fan of using such a terminological mess

But using them counts (indirectly) as using constructors.

I agree that it is a terminological mess, which is why I was careful 
with my phrasing.

I do not know whether I should repeat my opinion or not, but, here 
goes:

#[map! [...]]


and similar syntaxes are not "constructors" in the standard sense 
of the word. That is why I do not like seeing such phrases in documentation 
or elsewhere.

I agree that it is a terminological mess

Andreas, in the OSes with which I am familiar, you can't set a file 
to read-only and then count on that file staying read-only unless 
the user is asked for permission to change that setting. In REBOL 
you can. The security of a DOable %user.r depends on it not being 
writeable between when REBOL shuts down and when it starts up again. 
So that means using OS permissions to guard it, and those are based 
on user capabilities, not enough protection. The situation is different 
with %rebol.r since we only load it from the same location as the 
R3 executable, and that location can be protected with user permissions; 
this is why we can still DO %rebol.r in R3.

The security of a DOable %user.r depends on it not being writeable 
between when REBOL shuts down and when it starts up again.

Why?

I do not agree with "The security of a DOable %user.r depends on 
it not being writeable between when REBOL shuts down and when it 
starts up again."

Because you can have a worm spread using a combination of REBOL and 
code that is not written in REBOL but writes %user.r to do its propagation.

you can have a worm spread using a combination of REBOL and code 
that is not written in REBOL but writes %user.r to do its propagation

- yes, you can, but when you run a worm like that, then you are insecure 
anyway, since the worm could overwrite even your rebol.exe file.

Sure, and such a worm could spread much more easily by writing my 
.bashrc to do the propagation.

And I don't really trust .bashrc for that reason, though there might 
be some OS protection for that file of which I'm not aware.

Ladislav, you can put the rebol.exe file in a place that only admins 
can write to; %rebol.r too. You can't do the same with %user.r.

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.