Hi, Daniel Carosone wrote: > I'm not so sure.. I'd happily go for 'strange' or some other word, > rather than 'wrong'. At the very least, I'd like to try and work > through all the cases we can think of where this might arise, and just > confirm whether a sensible or legitimate interpretation could have > been intended. If we fail to come up with any, fine. If we do, > perhaps we'll have a new and interesting use case to consider > supporting properly..
Okay, let's see... > The question remains, however: when something like this is detected, > what should either the user or the software do to resolve the issue? That's the question, yes. > Let's say I decide to add another date cert with a more reasonable > value; this doesn't and can't get rid of the old one, so nothing is > really solved. True. You'd need to explicitly distrust the old cert. > 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. > I worry that this will just lead to confusion, rather than encouraging > users to fully embrace the realities of the distributed/disconnected > world. I don't think that's feasible. Users will always (want to) express themselves in "normal" dates and times. Otherwise you would have to encourage time definitions like: "before rev foo as signed by bar". > Again, fully support this, just not sure how it should be used. > Giving room to experiment and discover how it should be used is a good > end in itself. Good, I'm glad. ;-) I already have some code to compare dates, I'm thinking about adding that to "mtn db check" or something (as soon as I get time to clean up my spaghetti code...). > It seems to me to be a much more relevant thing to consider as part of > cert format rewrites, when we add a signing-date to certs, and that it > should be applied to the signing-date rather than the basic date. At > that point, signing a cert with a future date *could* be used to delay > the validity of a cert until some future date. 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. So AFAICT such a feature would even *require* proper timestamp checking. Otherwise you could not enforce such restrictions. Or put another way: as soon as we start to use the timestamps for more than just users convenience, we have to check and validate this information better. Regards Markus Wanner _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
