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

[Markus Wanner]

Hi,

Daniel Carosone wrote:
> 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).  

Looks like we are just approaching the problem from different angles.
I've been analyzing what's required to convert to atomic certs (or
super-certs or whatever you'd like to call it). I'm thinking that we
need to clean up our current certs to be able to convert them.

> 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.

I fully agree here. I'm in the need for such a feature often enough as
well. But it looks like it depends on atomic certs *and* policy
branches, so we are not likely to get that feature in the near future,
IMO. :-(

> 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.

Hm.. do we really want to dig into scheduling of build bots? I don't
quite think that fits the scope of monotone. Certainly not yet.

> 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. 

You can 'un-suspend' the branch at any time by simply committing a new
revision. So I don't think this us an utterly needed feature.

> 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.

Hm.. that might count. Although, doesn't policy branches provide a more
flexible mechanism to do these things? (I.e. general purpose cert
revocation, instead of only time based).

> 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. 

Again, sorry, but I don't think saving a few kbytes for these certs is
worth the effort (and confusion) introduced by certs expiring by date.

> [*] 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..

Sounds very much like something that could work together with policy
branches, no?

Regards

Markus Wanner