monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] Re: hypothetical - future-dated certs (Re: Monotone


From: Daniel Carosone
Subject: Re: [Monotone-devel] Re: hypothetical - future-dated certs (Re: Monotone Security)
Date: Mon, 20 Oct 2008 23:11:34 +1100
User-agent: Mutt/1.5.18 (2008-05-17)

On Mon, Oct 20, 2008 at 10:31:32AM +0200, Markus Wanner wrote:
> > In particular, my concern is that despite agreeing and acknowleding
> > that there can't be a global clock, warnings or errors like this help
> > to encourage in the users' minds that there is a global clock anyway.
> 
> Can we really get rid of that at all? If you continue this line of
> thinking, why do we have date certs at all? AFAICT it's just for users
> convenience so far.

That's kind of my point about the separate date certs we have
currently.  You propose a mechanism whereby an out-of-order or
future-dated date cert would be considered invalid and untrusted --
instead of now where it's trusted but essentially ignored (other than
for display and as a selector target).  It doesn't seem like much
benefit, which is why I think it only becomes interesting when we're
looking at signing-dates on certs that make other kinds of statements
(like asserting branch membership).  

> > However, if something
> > like that does turn out to be legitimately useful, my opinion is that
> > it should be via explicit valid-from and valid-until (optional) cert
> > fields, rather than by trying to overload the signing date.
> 
> Hm.. interesting use case. I fail to see a use case for a limit with
> "valid-until", yet, so let's discuss the "valid-from" thing first.
> 
> I've already encountered situations, where I wanted to postpone
> publication of a revision. Signing with a "valid-from" in the future
> could possibly solve this, yes. But that would benefit from the very
> same date checking, because descendant revisions must be valid from an
> even later point in the future. Otherwise you'd suddenly make your
> revision appear, just because it's descendant's cert is already valid.

Indeed. This is one use-case I've encountered a few times, but I have
a feeling that this mechanism isn't quite right as a solution. The
basic assumption is that I have a development line I want to keep 
"private" for some time until it is ready for wider circulation.  

I could attach a special netsync-instruction type of cert that says
"don't send until date X", or I could attach a branch cert that says
"add to branch Y after date X" (and then rely on netsync branch
pattern selection.   In practice and in general, I don't think this
really cuts it as a solution.  In particular, I probably do want to
sync these revisions in a limited context (such as between my own
machines just for backup purposes).[*]  Secondly, the decision for
when I'm ready to publicise that work is rarely date-based.

To me, a better use for "valid-from" might be on testresults and job
scheduling. Say I want to automatically build downloadable snapshots
for multiple architectures of the most recent revision to have passed
a set of tests, but the scheduling of when during the day to start the
build depends on some complex pattern that I can't easily represent in
the multiple platform's scheduling tool.  So, I make the build depend
on a summary test cert, that passes if all the other prerequisite
tests pass. As those test certs come in, I issue summary test certs
for revs during the day that have passed the set - and I future-date
them for the time this evening that the build should start.  The build
slaves just check on a basic interval for new work. When the cert
validity time comes around, the build slaves suddenly see all the
summary certs for the day, and build the latest (by ancestry) rev with
a valid cert. 

Oh, as a somewhat dumb use for a "valid-until" field: a suspend cert
for a head I want to come back to -- but not until next month. 

Or another: a tag cert that names the current base for patch
submissions for the next quarterly integration branch.  Next quarter,
the tag expires and a new one is made. 

Or another: maybe I'm doing a ZipperMerge, with an explicitly-named
intermediate zipper branch in the middle; perhaps I expect to take a
day or two to progress through the merge.  In any case, it's really
only the last few zipper merge certs that I care about - the current
central head, and whichever left or right node I next want to bring
in.  I could set these certs to expire quickly, and hold off syncing
until then - if expired certs aren't sent via netsync, they no longer
need to be passed around the rest of the world. 

--
Dan.

[*] I have in mind a different mechanism for this, based on a concept
of key-based netsync communities (to mostly replace the current
netsync permission hooks), which I've never taken the time to
write down - in part because I haven't really thought about how it
intersects with branch policy, and in part because I'd really like to
think of a nice way to make it work for revision encryption too..

Attachment: pgpxhZOG1G0rn.pgp
Description: PGP signature


reply via email to

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