Re: [RFC/PATCH v1] Add Travis CI support

[Jeff King <peff@peff.net>]

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