Extending the Provenance Commits idea

Context: Refer my 2008 posting, particularly the "Provenance Commits Idea" 2/3 of the way down.

A person who's not a committer, and who's made a change on their (say) Github fork of a project, with a consequential 'pull request' for the originator to consume the change as a contribution, could sign each commit.

Whether the CLA is as I penned it, or one like Apache's or Google's for accepting back contributions, the contributor could a line detailing the hash of the contribution they have made.

It gets merged in too, along with the actual change, and consequentially has a lasting presence in the bottom of a "contributions.txt" file that has the CLA as the first few paragraphs in "we, the undersigned" style.

Source control gets to prove that the contribution is correlated with the CLA signing. Such contributors have to keep re-signing subsequent contributions to cover for the eventuality that they are one day going to change employers.

Full blown committers should be exempt from this process of course, but then they are likely to not do business in nom-de-plume style, be be known to the other developers.

Note also that committers could reject pull requests until the contributor had completed the workflow of adding to the contributions.txt file.

Maybe Github could add some workflow/automation around this....

Update:
A question from an OSS buddy: Is that "sign" as in "cryptographically sign" or some other sense?

The hashes of changes are irrefutable an part of git's way of working. The follow-up addition of that hash to the contributions.txt file would be committed by the same user (by convention), and also hashed as a change in the same way.

Now the person COULD effect both of those without PKI being involved, but they are authenticated as far as Github is concerned, but virtue of other their id/password. Its as good as cryptographic signing to all intents and purposes. Provided Github has no XSS issues (etc) where someone can commit in the name of another.