On Fri, Sep 25, 2015 at 11:29:31AM -0700, Junio C Hamano wrote: > When I finally complain to the hosting site that it is deliberately > rejecting the fix that would rob them the illicit revenue source, it > does not help the hosting site to keep copies of push certificates > when it wants to refute such a complaint. "We publish all push > certificates and there is no record that gitster already tried to > fix the issue" has to be taken with faith in that scenario.
Right. Your earlier examples showed non-repudiation by the original signer (the hosting site says "you definite pushed this to us, and here is the signature to prove it, so you cannot deny it"). But in this example, it is going the other way: the pusher wants the hosting site to admit to an action. To do that, the hosting site would have to re-sign the push cert to say "we got this, it is published", and return the receipt to the original pusher, who can then use it as proof of the event. Or alternatively, it could be signed by a third-party notary. I don't think it is all that interesting an avenue to pursue, though. If you say "I have this update and the hosting site is not providing it to people", people are not that interested in whether the hosting site is being laggy, malicious, or whatever. They are interested in getting your update. :) So the more general problem is "I want to make sure I have Junio's latest push, and I do not want to trust anything else". For that, you could publish expiring certs (so you can fool me for up to, say, a week, but after that I consider the old certs to be garbage either way). Or you could do something clever with a quorum (e.g., N of K hosting sites say there is no update, so there probably isn't one). But I think all of that is outside of git's scope. Git provides the signed ref-state in the form of a push cert. Since it's a small-ish blob of data, you can use any external mechanism you want to decide on the correct value of it. > > So I wonder if it would be > > helpful to have a microformat that the client would use to look at this. > > E.g., it would fetch the cert tree, then confirm that the current ref > > values match the latest cert. > > Yeah, that is one possibility. Just a single flat file that > concatenates all the push cert in the received order would do as an > export format, too ;-) I agree that's a more logical format, in a sense; it really is a linear log. It's just that the receive-pack code already creates a blob for us, so it's cheap to reference that in tree (and then fetching it is cheap, too). IOW, git is much better at adding files to trees than it is at appending to files. :) -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
