[Monotone-devel] Re: [RFC] versioned policy -- bootstrapping

[Wim Oudshoorn]

Timothy  Brownawell <address@hidden> writes:

>> Oh, and I don't like the fact that everyone who ever had commit
>> access could always stall the project.  
>> 
>> I want that if I distrust Mallory, that all revisions signed
>> by him will NOT enter my database.
>
> There are different levels of trust/distrust. That's why admin
> permissions, commit permissions (so that the commit is visible), and
> netsync permissions (whether it even gets to your database) should all
> be different.

I agree with that.  However it seems silly to have two totally independend
security mechanisms with completely different sementics:

1 - netsync with LUA trust hooks
2 - Content with a trust tree model.

Isn't it likely that I want to express similar statements for both?
Like:  I do not want (to See | have in my database) revisions from Mallory
       in the FOO.Stable branch.  
But:   I do want to get revisions from Mallor in the FOO.Mallory branch.

the "to See" vs. "in my database" correspond to Content trust and netsync trust.
But I will need to configure this completely separate?

>> Also I don't like it that the decision who to trust, by picking a new
>> trust seed, is forced on all users.
>> When I am a user, I more or less trusts the owner of the database I sync 
>> with.
>> He can do whatever he wants with his database, if he is evil, he can just
>> stuff the database with useless data or just take it off-line.  
>> So I have a basic trust in the owner.
>
> Well, this would be one of the UI issues mentioned in the other post. A
> sane way to handle initial setup would be to ask the server what its
> trust seed is, and use that.

Sorry, I was not clear enough.
Imagine:  Me simple user wants to get source of project FOO.
So what do I do:

1 - Go to the website www.FOO_is_GREAT.somewhere
2 - See that they use monotone, great!
3 - I create a FOO database and pull/sync with netsync.FOO_is_GREAT.somewhere.

Now later Mallory is kicked out and pulls his fork trick.
Next time I sync, what do I get:

4 - monotone:  Sorry, there are conflicting trust policies.  
               Please figure out which one to trust and come back later.

5 - Looks puzzled at the trust conflict, Mallory vs. Alice.
    I don't care, for now I want to trust the owner or who is responsible
    for the netsync.FOO_is_GREAT.somewhere database.

Ok, maybe I am going overboard.  But I can see a lot of headaches for the
casual user.   Most users have trouble getting a SCM system to do what they
want.  Imagine the confusion.

>> If mallory wants to fork and
>> Alice the owner does not agree, let mallory start his owner server
>> and I will connect to that one.  
>
> What if the server is owned by someone else (shared hosting site,
> maybe), who wants to serve both forks?

Well, that owner should make his own policy/trust model which
incorperates both.  
To me it seems that in the current proposed solution,
the default would be:  serve both, but you can't use what you
get until you decide which fork to take.

Anyway,  another concern that I have.  If it happens that once in a while
the trust tree gets multiple heads and the users are asked to change
there trust seed.  Than after a while different users will use 
different trust seeds.  Because some choose new trust seed B others C and
some stay at A and wait until someone merged the trust seeds.

This could theoretically lead to some weird dialogs:

User A - I just saw yesterday that feature X is finally implemented!
User B - I don't see that revision.
User A - Did you sync?
User B - Yes.
User A - huh?
Developer - Try using trust seed 1213232......ada.23
Users - huh? thanks.


>> Furthermore, if there are two rival branches, I as a user might
>> want to sync with them both.  So how is that managed?
>
> Probably by having something like a trust seed <=> project name mapping
> in a file under ~/.monotone . You can say you trust both forks, but
> would probably have to (locally) override the name that one of them
> wanted.

Two things I don't get.

1 - seed <=> project name mapping.  How do you identify a project in
    monotone?  Isn't it a collection of branches?  So it would be more
    like wildcard matching on the branch certificate??

2 - Which name I need to overwrite.  A branch name?  A user name?  



Sorry if I am being difficult. I would like trust policies, but more on
the netsync level I guess.  But I am just trying to understandd what is 
happening.  Especially because it probably has a large impact on 
how we setup our databases.

Wim Oudshoorn.