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..
pgpIz0l6JyP1P.pgp
Description: PGP signature
_______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
