www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <...@daniel.shahaf.name>
Subject Re: Git and Provenance
Date Wed, 09 Aug 2017 17:41:28 GMT
Greg Stein wrote on Wed, 09 Aug 2017 06:37 -0500:
> On Tue, Aug 8, 2017 at 10:08 AM, Daniel Shahaf <d.s@daniel.shahaf.name>
> wrote:
> 
> > Greg Stein wrote on Mon, 07 Aug 2017 18:51 -0500:
> > > The ASF will capture email diffs and push logs of all changes made, to
> > all
> > > branches. These are stored in our email archives and in a push log
> > > database. So provenance might not be stored entirely in the repository,
> > but
> > > we still have all the data (caveat: bugs in our recording).
> >
> > Isn't there a size limit on commit diffs, any commit larger than
> > which isn't fully recorded in the mail archives?
> >
> > Also, trying to _use_ commit emails as a history-digging subject isn't
> > going
> > to be very friendly.  (You can't run log/blame on a mailing list archive)
> >
> 
> Agreed. Friendly isn't a requirement in this case, however.
> 
> Recall that we're talking edge cases here, about proving provenance. And an
> even further edge case is the ASF *defending* provenance. ... With that in
> mind, my court-untested belief is that having half-a-change throws the ball
> to the other side of the court. "Looks like my ICLA-covered peep committed
> this change, and the ICLA says it was Proper. ... Your ball: prove
> otherwise."
> 

IANAL.

> Second, the "only in an email archive" would imply it never got merged to
> master/trunk/develop. Or that it got merged to a deleted release branch.
> (or whatever other scenarios, I don't have in mind) ... Those are even
> further edge cases.
> 

You can make it a lot more of a center case by assuming a project that
supports two major release lines in parallel.  Only one of the two
major lines can be master/develop/trunk, the other is then fair game
for deletes.

> This is where (IMO) we decide the business risk is so freakishly low, that
> we do not require any operational changes to mitigate that risk. (*)

Yes, but the cost of for
archiving every commit object ever seen on *git*.apache.org is _also_
freakishly low.  (The storage cost of commit objects is bounded by some
constant times the typing speed of whoever authored the commit...)

> (*) and even then, we contend with other factors like intent, fraud by ICLA
> signers, downstream mispackaging, or a million other things.

What we do about provenance of honest committers has little effect on
these "other factors".

Cheers,

Daniel

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Mime
View raw message