[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] Re: [RFC] versioned policy -- bootstrapping
From: |
Wim Oudshoorn |
Subject: |
[Monotone-devel] Re: [RFC] versioned policy -- bootstrapping |
Date: |
Sun, 10 Sep 2006 20:00:31 +0200 |
User-agent: |
Gnus/5.1002 (Gnus v5.10.2) Emacs/22.0.50 (darwin) |
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.