[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] Re: Security is hard. Let's work on policy branches any
[Monotone-devel] Re: Security is hard. Let's work on policy branches anyway.
Fri, 13 Apr 2007 13:17:09 +0100
Gnus/5.11 (Gnus v5.11) Emacs/22.0.95 (gnu/linux)
Timothy Brownawell <address@hidden> writes:
> On Thu, 2007-04-12 at 12:36 +0100, Bruce Stephens wrote:
>> But can't you just ignore that?
>> i.e., in the above case, just stick with +abc and complain to the
>> user? I guess I'm imagining some statefulness: maybe my workspace
>> remembers not just its branch and revision, but also the most recent
>> policy branch revision.
> Probably not so good since you could get stuck on a microbranch without
> doing anything. Then you miss any legit changes to the other
> microbranch(es) until someone notices and merges them.
True, but you could just have monotone complain loudly when this
happens: perhaps require some positive choice of which branch to take
before doing anything further?
>> A reasonably monotone equivalent might be to (optionally) mark a
>> revision (maybe include this in the revision itself, rather than
>> attached with a certificate which might get lost) with the revision of
>> a policy branch. In that case, monotone might require that I use a
>> policy revision that's a descendent of the specified revision?
> No. Partly because that seems fairly distinct from what a revision (in a
> non-policy branch) is, and partly because there are reasons to want to
> use a different trust seed than the revision's author (forking a project
> or importing it as part of another come to mind).
Ah, true. That's an important thing to be able to do. As you
suggest, perhaps better to change netsync instead.
Though that requires that I'm syncing with a trustworthy (and
reliable) server: one that tells me about the relevant policy updates.
monotone doesn't currently require that: I can sync with anyone, and I
can verify everything that I receive. I may not receive some things,
of course, but that won't cause any problems. (An exception is
testsuite certs, I guess: a server could pass me revisions which have
failed tests, stripping off *all* testsuite certs, and I'd be none the
wiser, until I got at least some of them from somewhere else.)