[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Re: hypothetical - future-dated certs (Re: Monotone
From: |
Markus Wanner |
Subject: |
Re: [Monotone-devel] Re: hypothetical - future-dated certs (Re: Monotone Security) |
Date: |
Mon, 20 Oct 2008 14:30:27 +0200 |
User-agent: |
Thunderbird 2.0.0.16 (X11/20080916) |
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
- Re: [Monotone-devel] Monotone Security, (continued)
- Re: [Monotone-devel] Monotone Security, Zack Weinberg, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Daniel Carrera, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Daniel Carosone, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Jack Lloyd, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Markus Wanner, 2008/10/17
- [Monotone-devel] hypothetical - future-dated certs (Re: Monotone Security), Daniel Carosone, 2008/10/19
- [Monotone-devel] Re: hypothetical - future-dated certs (Re: Monotone Security), Markus Wanner, 2008/10/20
- Re: [Monotone-devel] Re: hypothetical - future-dated certs (Re: Monotone Security), Daniel Carosone, 2008/10/20
- Re: [Monotone-devel] Re: hypothetical - future-dated certs (Re: Monotone Security),
Markus Wanner <=
- Re: [Monotone-devel] Re: hypothetical - future-dated certs (Re: Monotone Security), Daniel Carosone, 2008/10/20
- Re: [Monotone-devel] Monotone Security, hendrik, 2008/10/16
- Re: [Monotone-devel] Monotone Security, John Bailey, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Daniel Carrera, 2008/10/16
- Re: [Monotone-devel] Monotone Security, hendrik, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Daniel Carrera, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Brian May, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Timothy Brownawell, 2008/10/15
- Re: [Monotone-devel] Monotone Security, Daniel Carrera, 2008/10/15