Re: [Monotone-devel] Re: Re: Future of monotone

[Markus Schiltknecht]

Hi,

Stephen Leake wrote:
> > There's already a warning in place, which pops up if untrusted
> > revisions could be used, but aren't because they're not trusted. IMO
> > that's sufficient (since it's just fighting misconfiguration) and
> > covers all cases.
>
> "Used" here means "needed for a merge, checkout, or update"?

Last I checked, "used" here for certain means "update". But I strongly 
suspect (and hope) it's pretty much the same code path for "heads" and 
"checkout" and "merge" as well, yes.

> That works, except if there are revisions present which really should
> not be trusted, Beth will get used to ignoring trust warnings, and
> miss one.

What do you mean by "missing a warning"? A warning is a warning. If Beth 
disagrees with the warning, and changes his mind to trusting Abe, he 
will have to change his cert_trust hook.

> Then we need a setting that says "yes, I know this revision won't be
> used; don't warn me anymore".

You can do that by simply killing the revision from the database. IMO 
there's not much point in maintaining an untrusted revision together 
with a flag that it will never be trusted anyway...

> Hmm. I guess Beth can commit a new revision that reverts the ignored
> revision, and then she won't get the original warning anymore? That
> makes sense.

That's another option, although I dislike it somewhat, because you are 
sucking in the untrusted revision forever into the history of your 
repository.

> As long as warnings are fixable in some way, I prefer treating all
> warnings as errors. But that's a UI choice; as long as the UI (I mean
> a UI external to monotone) has a way of detecting the problem, I'm
> happy. Better would be for monotone to provide a
> --treat-warnings-as-error option.

I don't quite agree here. Warnings are quite different from errors, IMO. 
And a UI external to monotone (you mean, build on top of monotone, 
right?) should use the automate interface anyway.

> > A direct error message and failure on sync isn't always possible,
> > because Abe and Beth could be syncing via Chuck, who trusts Abe. In
> > that case, Abe can push his revision to Chuck. But Beth certainly
> > shouldn't get a permission error when pulling from there (because
> > there might be other trusted revisions he wants to pull). This isn't
> > completely solvable with direct error messages, IMO.
>
> That won't happen in the central policy case, but we have to allow for
> all reasonable cases.

Agreed, as long as that central policy is enforced...

> In this case, Beth would get a warning if Abe's revision could be
> "used" in the above sense?

I'd say so, yes.

> > > I hope if Abe is listed as not trusted for some branch in his own
> > > get_revision_cert_trust or policy, any attempt on his part to commit
> > > to that branch would be an error? Otherwise he won't see his own
> > > commits?
> > That doesn't really make much sense to me. How can Abe not trust
> > himself? 
>
> Because the central policy says Abe is not allowed to commit to branch
> "documentation" (which is implemented as 'Abe not trusted on branch
> "documentation"'), but he forgets that and tries to commit a patch on
> that branch anyway.

Uh.. I was referring to the "he won't see his own commits". That's 
certainly something that should never happen.

If Abe should be allowed to commit or not is certainly debatable. If we 
disallow it, we certainly have to add "--force" option to disregard that 
(non fatal) error. I'm generally not a fan of such "--force" options, 
because I'm assuming clever users as well as software, which can easily 
undo unwanted changes.

> > Abe can then either ask the project to trust him and sync later on. 
>
> Or have someone else commit the same change, after review.

Which I'm considering pretty painful, but YMMV.

> It's a question of having the tool support the desired policy in the
> simplest way, with the most immediate error/warning messages. We have
> to agree that perfect policy enforcement is not possible, but find the
> right balance between user friendliness and strict enforcement.

See above.  I'd like to be able to commit and continue working, probably 
commit multiple times, and only later on make sure I get permissions to 
upload my work. Any kind of "--force" options are just plain annoying, 
IMO.  Or do you know of any real Unix user who hasn't hard-wired "rm 
-rf" in his fingers?

> Personally, I have never limited write permissions on a per-developer
> basis. But I think that's because I've only worked on small teams;
> everyone is trusted equally, and mistakes are easy to find and fix.
>
> I have worked on teams where write and read permissions where overly
> restrictive, and they definitely limit productivity when used poorly.

Exactly, that's why a warning is enough. Chances are pretty high, that 
the user known what he's doing.

> I have granted read-only access to a central CVS repository, when
> there was another team that needed that, but I did _not_ want to worry
> about them making mistakes.

In the above example, the only person who would have to worry about 
Abe's erroneous commit would be Abe himself. Because all the others have 
the correct policy in place.

Note, that the above issue about the warning is how it *currently* 
works. While all of this "policy" discussion is how it *should* work. 
Thus I'm also stating that Abe's malicious revision shouldn't be 
propagated via netsync, because the project's policy distrusts it. So 
there's no warning and nothing for Beth to worry about.

> Monotone supports that use case in a simple way only at the database
> level.

That's annoying, yes. But it's the current state and not how we want it 
to be.

> Since the tendency is to put all projects in one database, that
> is not very useful. It is complicated to list the other team as not
> trusted, and if they do commit, I have to deal with the trust
> warnings, and explain to them why their patch is not in the next
> release.

IMO, you are mixing things here. The warning is the best we can 
currently do. Policy branches don't exist, yet. Maybe I'm ready with the 
nuskool sync algorithm by the time policy branches are landing? Maybe not.

I certainly agree, that Beth shouldn't have to worry (not even about a 
warning) if Abe committed to a branch, to which he doesn't have "write 
access" to.

> Another solution would be to extend the mtn sync command to support
> multiple databases per session,

That would be pretty annoying to code, I think. It seems more doable, to 
respect the (local copy of the) policy and refuse to pull in untrusted 
revisions. (with nuskool, i.e. a DAG based refinement, that is).

> Would it be difficult to extend write permissions to branches?

For me, that's one of the reasons to favor a DAG based sync algorithm. 
I.e. nuskool.

Regards

Markus