Proving ownership of code with mercurial?

Thu Jan 3 01:32:34 CST 2008

Thanks to everyone for your replies.

I've finally met the client and ended the relationship but not in the  
best way I wanted.

Best,

Francesc

On Jan 2, 2008, at 5:57 PM, Matt Mackall wrote:

>
> On Wed, 2008-01-02 at 10:44 +0100, Francesc Esplugas wrote:
>> I've been working on a project during three months and as I work
>> freelance they say I only worked the first 6 weeks. Everything is
>> under Mercurial with daily changesets (and these changesets contain
>> data). The repo distributed in a few machines, but I keep the master.
>>
>> I know all the work that I've made, and I've printed the list of
>> changesets, so I can explain my client all the work, but they might
>> say I've changed the repos to reflect this "log history".
>>
>> The question should be ... should I trust the repos? In a Git
>> conference Linus Torvals talked about the security of Git, about
>> trust. He can know if someone has hacked the repository ... bla bla
>> bla ... so the idea would be to show to my client, that the repos
>> hasn't changed and that he can trust it ...
>>
>> Francesc
>>
>> On Jan 2, 2008, at 10:32 AM, Peter Arrenbrecht wrote:
>>
>>> On Jan 2, 2008 9:34 AM, Dustin Sallings <dustin at spy.net> wrote:
>>>>
>>>> On Jan 1, 2008, at 23:59, Francesc Esplugas wrote:
>>>>
>>>>> I want to prove all the work I've done. I understand some of my  
>>>>> code
>>>>> can be a copy and paste from other projects or other developers,  
>>>>> but
>>>>> the idea is to prove I've been working on the project.
>>>>>
>>>>> Proving the integrity (hg verify) of the repository, could prove
>>>>> nobody hacked it?
>>>>
>>>>
>>>>       If you can update to a version whose ancestry includes your
>>>> changes,
>>>> then those changes are there.  Anyone who's cloned the tree would
>>>> notice if you tried to rewrite history somewhere and pass it off as
>>>> their upstream.
>>>>
>>>>       Sounds like you might be fighting an uphill battle, though.
>>>> Good luck.
>>>
>>> Key point: If no one ever cloned your repo, then the repo's  
>>> integrity
>>> won't help you. It is easy to create a brand new repo with backdated
>>> history. And if the repo contains only your changes (not interleaved
>>> with changes by others), you would need the other party to have
>>> demonstrably old clones which show your changes really are as old as
>>> you claim.
>>>
>>> But, as someone noted before, this is about who has to prove what.  
>>> So:
>>> what exactly do you want to prove? Time spent? Goals achieved? Lines
>>> of code contributed? What?
>>>
>>> And why do you feel you need to prove this? If they claim you
>>> reattributed changes done by others to yourself, where are those
>>> others? What grounds have they for making the claim? If they claim  
>>> the
>>> result is not worth 3 months' time, then the repo should show the
>>> evolution of the result, which might show otherwise. But this does  
>>> not
>>> hinge on the repo's integrity.
>
> Here's what we can know about a repository:
>
> If you give me a changeset ID, and I compare it to a changeset ID in  
> my
> repository, I can know that the following things have not changed if  
> the
> IDs match and the repo passes verify:
>
> - commit description (date/author/branch/etc.)
> - list of files in the changeset, including their permissions
> - contents of each of those files[1]
> - the parent commit IDs (and therefore, their contents and history!)
>
> Any of these things may have tampered with, plagiarized, etc. before  
> you
> gave me the commit ID, but I know they haven't changed in between.
>
> It's also possible to GPG-sign commits. This demonstrates that the
> person who signed a particular commit had access to the private key
> corresponding with signature.
>
> The question then becomes what can we show about authorship and date  
> of
> creation from the above?
>
> Logically, there is very little we can show about authorship. Anything
> can be cut and pasted from other unknown sources. Legally, if no one
> steps forward to claim authorship, then there's nothing to say you
> weren't the author. But once you've published, someone can always  
> claim
> to have authored it and then it falls to what documentation each side
> has about the creation process. Having documentation (ie your repo
> history) and earlier publication greatly helps. One nice thing about
> Mercurial here is you can publically post just your changeset IDs to
> create a verifiable record of when your not-yet-published work was
> actually created.
>
> As for dates, it's not possible to prove that you didn't complete work
> all on the first day and then check it in over the course of months.  
> The
> best you can do is document it with a version control system, and
> correlate that with other activities (related email, phone calls,  
> login
> records, etc.). Also, there are a number of industry-standard  
> techniques
> for estimating developer hours from lines of code[2]. If you're  
> close to
> these, your employer really has no grounds for complaint.
>
> [1] There are attacks based on SHA1 collisions that allow you to  
> change
> the contents of specially-designed files without detection, but these
> won't work on typical source code. If you need stronger protection,  
> you
> can always publish stronger hashes of your source tree (and you can
> check these in)
>
> [2]http://en.wikipedia.org/wiki/Cocomo
>
> -- 
> Mathematics is the supreme nostalgia of our time.
>

--
name. Francesc Esplugas i Martí
voice. +34 678.681.603