--===============1561268081==
Content-Type: multipart/signed;
  boundary="nextPart1297242.fumWlvKRbI";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1297242.fumWlvKRbI
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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=20
uncompressed, they'd be 100-200 bytes in size, more or less. And they are=20
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=20
>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=20
in other emails: there are very legitimate uses for pushing other=20
people's patches.

But I agree it's overkill.

>b) to further reduce=20
>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,=20
the kde-commits mailing list is the accountability we need. It's archived=20
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=20
git-am. It requires a full-fledged merge.

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

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

=2D-=20
=A0 Thiago Macieira =A0- =A0thiago (AT) macieira.info - thiago (AT) kde.org
=A0 =A0 PGP/GPG: 0x6EF45358; fingerprint:
=A0 =A0 E067 918B B660 DBD1 105C =A0966C 33F5 F005 6EF4 5358

--nextPart1297242.fumWlvKRbI
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQBIkjnnM/XwBW70U1gRArPOAJ9oyh9pGqGHvs/bOLBlvGFWSQf37QCglQ2k
K5rujpm7WAGnHqB6fDtEa28=
=a3K0
-----END PGP SIGNATURE-----

--nextPart1297242.fumWlvKRbI--

--===============1561268081==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Kde-scm-interest mailing list
Kde-scm-interest@kde.org
https://mail.kde.org/mailman/listinfo/kde-scm-interest

--===============1561268081==--