monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Re: Using monotone in a team


From: hendrik
Subject: Re: [Monotone-devel] Re: Using monotone in a team
Date: Thu, 30 Nov 2006 12:58:16 -0500
User-agent: Mutt/1.5.9i

On Thu, Nov 30, 2006 at 10:49:25AM -0600, Timothy Brownawell wrote:
> On Thu, 2006-11-30 at 11:32 -0500, address@hidden wrote:
> > On Thu, Nov 30, 2006 at 12:24:27AM -0600, Timothy Brownawell wrote:
> > > On Thu, 2006-11-30 at 17:06 +1100, Brian May wrote:
> > > > >>>>> "Daniel" == Daniel Carosone <address@hidden> writes:
> > > > 
> > > >     Daniel> Again, it's not about permissions to change things, it's
> > > >     Daniel> about whether your trust (ie, how you pay attention to)
> > > >     Daniel> what they do.
> > > > 
> > > >     Daniel> In this context, this means that everyone accepts changes
> > > >     Daniel> in the junior branch from junior and denior developers,
> > > >     Daniel> and in the main branch only from the senior developers.
> > > >     Daniel> More specifically, that I only trust main-branch certs
> > > >     Daniel> signed by senior developers.
> > > > 
> > > >     Daniel> From time to time, a senior developer looks at revs in the
> > > >     Daniel> junior branch.
> > > > 
> > > > What happens if a trusted developer's key becomes compromised
> > > > (e.g. laptop stolen) or the developer becomes untrustworthy
> > > > (e.g. fired)?
> > > > 
> > > > Can you somehow say that old signatures are still valid, but new ones
> > > > aren't?
> > > 
> > > Define "new" (monotone has no concept of time).
> > 
> > Except for a partial order of revisions after other revisions.  You 
> > could still give a list of recent valid revisions and let the partial 
> > order fend a lot of older revisions whose certs would also be valid.
> 
> But certs can be added to revisions at any time. So even if a revision
> is known to have been committed before the key was revoked, it's
> entirely possible that some certs attached to it could have been added
> after the key was revoked.

You're right ... so the best we can do is for each repository/server to 
remember when it first heard of each cert.  In general, this will be 
diferent for different servers so we wouldn't want to pass this 
information around on a sync.  In fact, if we don's trust clocks to be 
monotonic, we could arbitrarily but monotonically number them.

Then someone on any one particular server could identify certs which 
were reliably old and recertify those.  Recertification sould spread via 
sync.

But it's getting complicated.

-- hendrik




reply via email to

[Prev in Thread] Current Thread [Next in Thread]