[Kde-scm-interest] Accountability, concrete suggestion

[Thiago Macieira]

Oswald Buddenhagen wrote:
>On Thu, Jul 31, 2008 at 03:07:37PM +0200, Thomas Zander wrote:
>> This will mean the content of both the master and the loggingOfMaster
>> branches will be identical.  The merge action creates a commit.  A
>> commit on the logging branch and one that the server automatically
>> creates.
>
>that means that every branch will have a shadow branch, and every commit
>(or commit group, as in push) will have a shadow commit. considering
>that everyone will have the *entire* history of each module he is using
>on his disk, i'm not really happy about that.

The extra cost is minimal. If each of the shadow commits were completely 
uncompressed, they'd be 100-200 bytes in size, more or less. And they are 
compressed, so that the end result is pretty small.

Besides, you don't have to clone the shadow commits.

>also, i think it is simly 
>overkill: a) the server could append to the log message something like
>that: "Warning: author's email address does not match any registered
>address of the submitting account (thiago)."

It can't. The server can't change commits.

It could only reject commits, but that goes back to the problems I listed 
in other emails: there are very legitimate uses for pushing other 
people's patches.

But I agree it's overkill.

>b) to further reduce 
>clutter, this warning could be appended only to the mail sent to
>kde-commits. as an actual dispute over authenticity is an absolutely
>marginal case, it can be very well referred to server logs. for
>transparency and efficiency, the logs could be made available through a
>web interface.

Indeed. That's what I argued with Thomas as well: for our (KDE) purposes, 
the kde-commits mailing list is the accountability we need. It's archived 
in several independent websites, so tampering with is very difficult.

>> For this usecase I want to introduce a completely separate
>> accountability concept that is similar, but different, from the git
>> concept of signing off.
>
>i wonder why you introduce two concepts instead of suggesting this one
>for both cases?

We just listed both possibilities.

>an alteration to the concept: instead of removing the received
>signature, you would sign it, too. this would actually *be* the
>kernel-style signed-of-by concept, only that it would be
>cryptographically signed.

Indeed. Our idea was a "Signed-off by" that cryptographically signs.

Unlike the kernel-style signing off, this cannot be used with rebases and 
git-am. It requires a full-fledged merge.

When we were discussing, we started off on signatures like git tag -s. But 
we can't sign a commit's SHA-1 before we have that SHA-1. So, instead of 
signing the digest, we decided we could sign the information that would 
have been digested: the headers and message of the commit.

The other solution (which has appeared here) is to sign your diff. The 
idea has its merits, but it's actually harder to implement given Git's 
object model. Besides, as soon as there's a single line of difference (a 
fuzz of one line because someone added a blank line somewhere above the 
lines that the patch touches), the signature wouldn't work.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20080801/70ac5496/attachment.pgp