[Bitcoin-development] PSA: Please sign your git commits

[Bitcoin-development] PSA: Please sign your git commits

[Wladimir]

Hello all,

When you're contributing to Bitcoin Core development please sign your
git commits. This is easy to do and will help in assuring the
integrity of the tree.

How to sign your commits?
------------------------------------------

Provide the `-S` flag (or `--gpg-sign`) to git commit when you commit
your changes, for example

    git commit -m "Commit message" -S

Optionally you can provide a key id after the -S option to sign with a
specific key.

What if I forgot?
-------------------------

You can retroactively sign your previous commit using --amend, for example

    git commit -S --amend

If you need to go further back, you can use the interactive rebase
command with 'edit'. Replace HEAD~3 with the base commit from which
you want to start.

    git rebase -i HEAD~3

Replace 'pick' by 'edit' for the commit that you want to sign and the
rebasing will stop after that commit. Then you can amend the commit as
above. Afterwards, do

    git rebase --continue

As this will rewrite history, you cannot do this when your commit is
already merged. In that case, too bad, better luck next time.

If you rewrite history for another reason - for example when squashing
commits - make sure that you re-sign as the signatures will be lost.

How to check if commits are signed?
-------------------------------------------------------

Use git log with show-signature,

    git log --show-signature

    commit 6fcdad787f1fb381a3a0fe6b1a1e45477426dccb
    gpg: Signature made Wed 21 May 2014 12:27:55 PM CEST using RSA key
ID 2346C9A6
    gpg: Good signature from "Wladimir J. van der Laan <laanwj@gmail.com>"
    Author: Wladimir J. van der Laan <laanwj@gmail.com>
    Date:   Wed May 21 12:27:37 2014 +0200

        qt: Periodic language update
    ...

You can also pass the --show-signature option to `git show` to check a
single commit.

If you do this on the current repository you'll see that I'm almost
the only person signing commits. I would like more people to get into
this habit.

How to sign merges?
--------------------------------

When using the github interface to merge a pull request, the resulting
merge commit is not signed.

Pieter Wullie wrote a script that simplifies merging and signing. It
can be found in contrib/devtools. Setup instructions can be found in
the README.md in that directory. After setting it up for the
repository you can use the script in the following way:

    contrib/devtools/github-merge.sh 1234

Replace 1234 by the pull request number that you want to merge. It
will merge the pull request and drop you into a shell so you can
verify changes and test. Once satisfied, exit the shell and answer the
questions to merge and sign it and push upstream automatically (or
not).

Please use this script when possible for merging instead of the github
interface.

--------------------------

Wladimir

Re: [Bitcoin-development] PSA: Please sign your git commits

[Chris Beams]

[-- Attachment #1.1: Type: text/plain, Size: 4753 bytes --]

Hi Wladimir,

I'm personally happy to comply with this for any future commits, but wonder if you've considered the arguments against commit signing [1]? Note especially the reference therein to Linus' original negative opinion on signed commits [2].

I came across these when searching for a way to enable signing by default, e.g. a `git config` option that might allow for this. Unfortunately, there isn't one, meaning it's likely that most folks will forget to do this most of the time.

If you're really serious about it, you should probably reject pull requests without signed commits; otherwise, signing becomes meaningless because only honest authors do it, and forgetful or malicious ones can avoid it without penalty.

That said, I'm not sure that creating such a barrier to contribution is worth it.

- Chris

[1]: http://stackoverflow.com/a/10166916/622403
[2]: http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html

On May 21, 2014, at 2:23 PM, Wladimir <laanwj@gmail.com> wrote:

> Hello all,
> 
> When you're contributing to Bitcoin Core development please sign your
> git commits. This is easy to do and will help in assuring the
> integrity of the tree.
> 
> How to sign your commits?
> ------------------------------------------
> 
> Provide the `-S` flag (or `--gpg-sign`) to git commit when you commit
> your changes, for example
> 
>    git commit -m "Commit message" -S
> 
> Optionally you can provide a key id after the -S option to sign with a
> specific key.
> 
> What if I forgot?
> -------------------------
> 
> You can retroactively sign your previous commit using --amend, for example
> 
>    git commit -S --amend
> 
> If you need to go further back, you can use the interactive rebase
> command with 'edit'. Replace HEAD~3 with the base commit from which
> you want to start.
> 
>    git rebase -i HEAD~3
> 
> Replace 'pick' by 'edit' for the commit that you want to sign and the
> rebasing will stop after that commit. Then you can amend the commit as
> above. Afterwards, do
> 
>    git rebase --continue
> 
> As this will rewrite history, you cannot do this when your commit is
> already merged. In that case, too bad, better luck next time.
> 
> If you rewrite history for another reason - for example when squashing
> commits - make sure that you re-sign as the signatures will be lost.
> 
> How to check if commits are signed?
> -------------------------------------------------------
> 
> Use git log with show-signature,
> 
>    git log --show-signature
> 
>    commit 6fcdad787f1fb381a3a0fe6b1a1e45477426dccb
>    gpg: Signature made Wed 21 May 2014 12:27:55 PM CEST using RSA key
> ID 2346C9A6
>    gpg: Good signature from "Wladimir J. van der Laan <laanwj@gmail.com>"
>    Author: Wladimir J. van der Laan <laanwj@gmail.com>
>    Date:   Wed May 21 12:27:37 2014 +0200
> 
>        qt: Periodic language update
>    ...
> 
> You can also pass the --show-signature option to `git show` to check a
> single commit.
> 
> If you do this on the current repository you'll see that I'm almost
> the only person signing commits. I would like more people to get into
> this habit.
> 
> How to sign merges?
> --------------------------------
> 
> When using the github interface to merge a pull request, the resulting
> merge commit is not signed.
> 
> Pieter Wullie wrote a script that simplifies merging and signing. It
> can be found in contrib/devtools. Setup instructions can be found in
> the README.md in that directory. After setting it up for the
> repository you can use the script in the following way:
> 
>    contrib/devtools/github-merge.sh 1234
> 
> Replace 1234 by the pull request number that you want to merge. It
> will merge the pull request and drop you into a shell so you can
> verify changes and test. Once satisfied, exit the shell and answer the
> questions to merge and sign it and push upstream automatically (or
> not).
> 
> Please use this script when possible for merging instead of the github
> interface.
> 
> --------------------------
> 
> Wladimir
> 
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[-- Attachment #1.2: Type: text/html, Size: 5756 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

Re: [Bitcoin-development] PSA: Please sign your git commits

[Wladimir]

Hello Chris,

On Wed, May 21, 2014 at 6:39 PM, Chris Beams <chris@beams.io> wrote:
> I'm personally happy to comply with this for any future commits, but wonder
> if you've considered the arguments against commit signing [1]? Note
> especially the reference therein to Linus' original negative opinion on
> signed commits [2].

Yes, I've read it. But would his alternative, signing tags, really
help us more here? How would that work? How would we have to structure
the process?

At least signed commits are easy to integrate into the current
development process with github - only a different way of merging has
to be used.

> I came across these when searching for a way to enable signing by default,
> e.g. a `git config` option that might allow for this. Unfortunately, there
> isn't one, meaning it's likely that most folks will forget to do this most
> of the time.

I'll remind people if they forget to do it, but I won't require it. As
you say, that would be an extra barrier, and I'm not suggesting this
because I to see people jumping through bureaucratic hoops.
But it is a pretty simple thing to do...

> If you're really serious about it, you should probably reject pull requests
> without signed commits; otherwise, signing becomes meaningless because only
> honest authors do it, and forgetful or malicious ones can avoid it without
> penalty.

This is not because I'm afraid of malicious authors, but because I
want to reduce the risk that github hacks would pose.

Something to watch for would be authors that normally sign pull
requests/merges and suddenly don't. Someone malicious may have gained
access to their github account. This just adds an extra layer of
protection.

Cheers,
Wladimir

Re: [Bitcoin-development] PSA: Please sign your git commits

[Mark Friedenbach]

On 05/21/2014 10:10 AM, Wladimir wrote:
> On Wed, May 21, 2014 at 6:39 PM, Chris Beams <chris@beams.io> wrote:
>> I'm personally happy to comply with this for any future commits, but wonder
>> if you've considered the arguments against commit signing [1]? Note
>> especially the reference therein to Linus' original negative opinion on
>> signed commits [2].
> 
> Yes, I've read it. But would his alternative, signing tags, really
> help us more here?

Honest question: what would signed commits do to help us here anyway?
What's the problem being solved?

Unfortunately git places signatures in the history itself, so it's not
like we could use easily use signatures to indicate acceptance after
code review, like we could if we were using monotone for example. Git
just wasn't designed for a commit-signing workflow.

Re: [Bitcoin-development] PSA: Please sign your git commits

[Gregory Maxwell]

On Wed, May 21, 2014 at 1:30 PM, Mark Friedenbach <mark@monetize.io> wrote:
> Honest question: what would signed commits do to help us here anyway?
> What's the problem being solved?
>
> Unfortunately git places signatures in the history itself, so it's not
> like we could use easily use signatures to indicate acceptance after
> code review, like we could if we were using monotone for example. Git
> just wasn't designed for a commit-signing workflow.

Just makes it easier to sort out things like your git account (or the
git site) being compromised and used to submit commits.

Re: [Bitcoin-development] PSA: Please sign your git commits

[Jeff Garzik]

Related:  Current multi-sig wallet technology being rolled out now,
with 2FA and other fancy doodads, is now arguably more secure than my
PGP keyring.  My PGP keyring is, to draw an analogy, a non-multisig
wallet (set of keys), with all the associated theft/data
destruction/backup risks.

The more improvements I see in bitcoin wallets, the more antiquated my
PGP keyring appears.  Zero concept of multisig.  The PGP keyring
compromise process is rarely exercised.  2FA is lacking.  At least
offline signing works well. Mostly.



On Wed, May 21, 2014 at 5:02 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> On Wed, May 21, 2014 at 1:30 PM, Mark Friedenbach <mark@monetize.io> wrote:
>> Honest question: what would signed commits do to help us here anyway?
>> What's the problem being solved?
>>
>> Unfortunately git places signatures in the history itself, so it's not
>> like we could use easily use signatures to indicate acceptance after
>> code review, like we could if we were using monotone for example. Git
>> just wasn't designed for a commit-signing workflow.
>
> Just makes it easier to sort out things like your git account (or the
> git site) being compromised and used to submit commits.
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

Re: [Bitcoin-development] PSA: Please sign your git commits

[Peter Todd]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I've got a PGP smart card reader and card with a securely generated key and pin entered per signature.

Re: multisig, that's precisely why we want more than just a single maintainer signing commits.

PGP isn't perfect, but perfect is the enemy of good.


On 22 May 2014 21:06:10 GMT+03:00, Jeff Garzik <jgarzik@bitpay.com> wrote:
>Related:  Current multi-sig wallet technology being rolled out now,
>with 2FA and other fancy doodads, is now arguably more secure than my
>PGP keyring.  My PGP keyring is, to draw an analogy, a non-multisig
>wallet (set of keys), with all the associated theft/data
>destruction/backup risks.
>
>The more improvements I see in bitcoin wallets, the more antiquated my
>PGP keyring appears.  Zero concept of multisig.  The PGP keyring
>compromise process is rarely exercised.  2FA is lacking.  At least
>offline signing works well. Mostly.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQFQBAEBCAA6BQJTfpWNMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhfVGB/448B6UvhN7bmFQxmLS
9+wlhWGYioJKUPspz2Wtk0p8v1y1XlDt0UxC+5ODin4a/Zk0+0x4G4MWyaUP1TnA
Wq9FquY3MwTXDrwWzmeQR4QcRbC+EMMk6kXswzT4d/2clUwB1pLl2MYGnS9DjUK2
of0kzZEbaQvxSKcFmvuqhz0QqGy84pkHAFBHfopS1j4WqIZpelUMzBGRYP8D1IQd
H/M2YxdQ7T8peiNigqWSyllchKqGoLG+KEr3mvTYRLkxoYw5XTcFyc5AmuTRfzEC
yhRc7CJwTZjHYahgZRPGJQM0qeopdIVAifCu9NoPgdkyuQL+X8XSidrU5Kbv/YeZ
Scv/
=GdA4
-----END PGP SIGNATURE-----

Re: [Bitcoin-development] PSA: Please sign your git commits

[Wladimir]

On Thu, May 22, 2014 at 8:06 PM, Jeff Garzik <jgarzik@bitpay.com> wrote:
> Related:  Current multi-sig wallet technology being rolled out now,
> with 2FA and other fancy doodads, is now arguably more secure than my
> PGP keyring.  My PGP keyring is, to draw an analogy, a non-multisig
> wallet (set of keys), with all the associated theft/data
> destruction/backup risks.
>
> The more improvements I see in bitcoin wallets, the more antiquated my
> PGP keyring appears.  Zero concept of multisig.  The PGP keyring
> compromise process is rarely exercised.  2FA is lacking.  At least
> offline signing works well. Mostly.

Would be incredible to have multisig for git commits as well. I don't
think git supports multiple signers for one commit at this point -
amending the signature replaces the last one - but it would allow for
some interesting multi-factor designs in which the damage when a dev's
computer is compromised would be reduced.

Sounds like a lot of work to get a good workflow there, though.

My mail about single-signing commits was already longer than I
expected when I started writing there. Even though the process is
really simple.

Though if anyone's interest is piqued by this, please pick it up.

Wladimir

Re: [Bitcoin-development] PSA: Please sign your git commits

[Mark Friedenbach]

I know the likelihood of this happening is slim, but if these are the
desired features we should consider switching to monotone (monotone.ca)
which has a much more flexible DAG structure and workflow built around
programmable multi-sig signing of commits. We could still maintain the
github account as a two-way repository interface, but acceptance of a
pull request would require some threshold signature sign-off in monotone.

I would seriously suggest anybody on this list exploring monotone if you
haven't already, at least for your personal projects if it is too late
to make that choice for bitcoin. Besides the benefits of using it, we
should be supporting build infrastructure that enables less trusted,
less centralized development.

http://www.monotone.ca/

Mark

On 05/23/2014 12:12 AM, Wladimir wrote:
> On Thu, May 22, 2014 at 8:06 PM, Jeff Garzik <jgarzik@bitpay.com> wrote:
>> Related:  Current multi-sig wallet technology being rolled out now,
>> with 2FA and other fancy doodads, is now arguably more secure than my
>> PGP keyring.  My PGP keyring is, to draw an analogy, a non-multisig
>> wallet (set of keys), with all the associated theft/data
>> destruction/backup risks.
>>
>> The more improvements I see in bitcoin wallets, the more antiquated my
>> PGP keyring appears.  Zero concept of multisig.  The PGP keyring
>> compromise process is rarely exercised.  2FA is lacking.  At least
>> offline signing works well. Mostly.
> 
> Would be incredible to have multisig for git commits as well. I don't
> think git supports multiple signers for one commit at this point -
> amending the signature replaces the last one - but it would allow for
> some interesting multi-factor designs in which the damage when a dev's
> computer is compromised would be reduced.
> 
> Sounds like a lot of work to get a good workflow there, though.
> 
> My mail about single-signing commits was already longer than I
> expected when I started writing there. Even though the process is
> really simple.
> 
> Though if anyone's interest is piqued by this, please pick it up.
> 
> Wladimir
> 

Re: [Bitcoin-development] PSA: Please sign your git commits

[Kyle Jerviss]

Multisig is great for irreversible actions, but pointless most of the 
time, which is why no PGP developer or user ever thought to implement it.

If you lose a key and an attacker signs a bogus email or commit with it, 
we all roll back with no lasting harm done.

Wladimir wrote:
> On Thu, May 22, 2014 at 8:06 PM, Jeff Garzik <jgarzik@bitpay.com> wrote:
>> Related:  Current multi-sig wallet technology being rolled out now,
>> with 2FA and other fancy doodads, is now arguably more secure than my
>> PGP keyring.  My PGP keyring is, to draw an analogy, a non-multisig
>> wallet (set of keys), with all the associated theft/data
>> destruction/backup risks.
>>
>> The more improvements I see in bitcoin wallets, the more antiquated my
>> PGP keyring appears.  Zero concept of multisig.  The PGP keyring
>> compromise process is rarely exercised.  2FA is lacking.  At least
>> offline signing works well. Mostly.
> Would be incredible to have multisig for git commits as well. I don't
> think git supports multiple signers for one commit at this point -
> amending the signature replaces the last one - but it would allow for
> some interesting multi-factor designs in which the damage when a dev's
> computer is compromised would be reduced.
>
> Sounds like a lot of work to get a good workflow there, though.
>
> My mail about single-signing commits was already longer than I
> expected when I started writing there. Even though the process is
> really simple.
>
> Though if anyone's interest is piqued by this, please pick it up.
>
> Wladimir
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] PSA: Please sign your git commits

[Gregory Maxwell]

On Fri, May 23, 2014 at 9:48 AM, Kyle Jerviss <bitcoin-devel@jerviss.org> wrote:
> Multisig is great for irreversible actions, but pointless most of the
> time, which is why no PGP developer or user ever thought to implement it.
>
> If you lose a key and an attacker signs a bogus email or commit with it,
> we all roll back with no lasting harm done.

PGP in general is not very thoughtful about security. There are a lot
of things it does poorly. This is easily excusable considering the
historical context it came from— it was the first real cryptographic
tool I used, at the time its distribution had concerns about legality,
just getting things into people's hands was an achievement enough.

From a cryptosystem perspective much more powerful things can be done
now, but there is a long way to go in figuring out how to many any
cryptographic tool usable to people.

PGP is a general purpose tool— which is the hardest kind to write— its
also used in a lot of irreversible contexts: If your key deploys a bad
software release and it steals everyone's data or wipes their disks—
thats not an irreversible action by any means.

If you want threshold pgp though— it's possible. The RSA cryptosystem
is directly compatible with threshold cryptography. It's just that no
one has written the tools. There are implementations of the bare
cryptosystem however.

One of my longer term would-be-nice goals for a upgrade bitcoin script
2.0 would be being thoughtful enough in the design that it could be
adopted as a signing cryptosystem in other applications (e.g. tools
similar to GPG)— allowing for things like creating a public key which
can only issue trust level 0 certifications, only certifications for
certain organizations (e.g. *.debian.org) unless thresholded with an
offline key, or only signing for messages meeting a certain
programmatic predicate generally.

Re: [Bitcoin-development] PSA: Please sign your git commits

[Wladimir]

On Wed, May 21, 2014 at 7:10 PM, Wladimir <laanwj@gmail.com> wrote:
> Hello Chris,
>
> On Wed, May 21, 2014 at 6:39 PM, Chris Beams <chris@beams.io> wrote:
>> I'm personally happy to comply with this for any future commits, but wonder
>> if you've considered the arguments against commit signing [1]? Note
>> especially the reference therein to Linus' original negative opinion on
>> signed commits [2].
>
> Yes, I've read it. But would his alternative, signing tags, really
> help us more here? How would that work? How would we have to structure
> the process?

I think a compromise - that is similar to signing tags but would still
work with the github process, and leaves a trail after merge - would
be: if you submit a stack of commits, only sign the most recent one.

As each commit contains the cryptographic hash of the previous commit,
which in turns contains the hash of that before it up to the root
commit, signing every commit if you have multiple in a row is
redundant.

I'll update the document and put it in the repository.

Wladimir

Re: [Bitcoin-development] PSA: Please sign your git commits

[Chris Beams]

[-- Attachment #1: Type: text/plain, Size: 2798 bytes --]

An update on this topic:

With the release of Git 2.0, automatic commit signing is now possible with the 'commit.gpgsign' configuration option [1]. This means that interactively rebased or cherry-picked commits are also re-signed on the fly. The absence of this ability in prior versions of Git meant that signing every commit wasn't a practical policy for anyone using rebase as a regular part of their local development workflow. Now it can be.

Merging also works as expected with this feature turned on.

One caveat I've identified thus far is a negative impact on speed when a large number of commits are involved. Any time you're signing a commit, you're interacting with the gpg-agent daemon, and this is roughly an order of magnitude slower than signing without committing.

Speed without signing:

    $ echo '' >> README.md; time git commit -am"Test commit speed" --no-gpg-sign
    [...]
    real    0m0.031s

and with:

    $ echo '' >> README.md; time git commit -am"Test commit speed" --gpg-sign
    [...]
    real    0m0.360s

For a single commit, this slowdown is negligible as it is still well below sub-second. However, if one were rebasing a local development branch with dozens of commits, you can see how the time would quickly add up.

Personally, I think that in practice I'll be willing to deal with with a few seconds' wait on those relatively rare occasions, and therefore I'm going to keep auto-signing enabled for now [2].

- Chris

[1]: http://article.gmane.org/gmane.comp.version-control.git/250341
[2]: https://github.com/cbeams/dotfiles/commit/d7da74

On May 23, 2014, at 12:23 PM, Wladimir <laanwj@gmail.com> wrote:

> On Wed, May 21, 2014 at 7:10 PM, Wladimir <laanwj@gmail.com> wrote:
>> Hello Chris,
>> 
>> On Wed, May 21, 2014 at 6:39 PM, Chris Beams <chris@beams.io> wrote:
>>> I'm personally happy to comply with this for any future commits, but wonder
>>> if you've considered the arguments against commit signing [1]? Note
>>> especially the reference therein to Linus' original negative opinion on
>>> signed commits [2].
>> 
>> Yes, I've read it. But would his alternative, signing tags, really
>> help us more here? How would that work? How would we have to structure
>> the process?
> 
> I think a compromise - that is similar to signing tags but would still
> work with the github process, and leaves a trail after merge - would
> be: if you submit a stack of commits, only sign the most recent one.
> 
> As each commit contains the cryptographic hash of the previous commit,
> which in turns contains the hash of that before it up to the root
> commit, signing every commit if you have multiple in a row is
> redundant.
> 
> I'll update the document and put it in the repository.
> 
> Wladimir


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

Re: [Bitcoin-development] PSA: Please sign your git commits

[David A. Harding]

On Wed, May 21, 2014 at 06:39:44PM +0200, Chris Beams wrote:
> I [was] searching for a way to enable signing by default [...]
> Unfortunately, there isn't one, meaning it's likely that most folks
> will forget to do this most of the time.

For all of my projects, I now I put this script in
.git/hooks/post-commit and post-merge:

    #!/bin/bash -eu

    if ! git log -n1 --show-signature | grep -q 'gpg: Good signature'
    then
        yes "FORGOT TO SIGN COMMIT MESSAGE"
        exit 1
    fi

So anytime I forget to sign, I get an obvious error and can immediately
run git commit --amend -S.

To automatically add a script like the one above to all new projects (plus
quickly add it old current projects), you can follow these instructions:

    http://stackoverflow.com/questions/2293498/git-commit-hooks-global-settings

> If you're really serious about it, you should probably reject pull
> requests without signed commits; otherwise, signing becomes
> meaningless because only honest authors do it

I find signing my commits quite useful even on projects without a
default signing policy because it lets me diff from the last time I
provably reviewed the code.  Here's my script for that:

    #!/bin/bash -eu

    KEY=F29EC4B7

    last_signed_commit=$( git log --topo-order --show-signature --pretty=oneline \
        | grep -m1 " gpg: Signature made.*RSA key ID $KEY" \
        | sed 's/ .*//' \
        | grep .
    ) || { echo "No signed commit found.  Dying..." ; exit 1 ; }

    set -x
    git diff $last_signed_commit

By diffing against the last signed commit I made, I also review any
commits that were made using my name but which I didn't actually make,
such as squashes and rebases of my commits (and, of course, forgeries).

For anyone who's bored and wants to read a lot of text, I think the
definitive work on git signing is this:

    http://mikegerwitz.com/papers/git-horror-story.html

-Dave
-- 
David A. Harding

Re: [Bitcoin-development] PSA: Please sign your git commits

[Chris Beams]

[-- Attachment #1.1: Type: text/plain, Size: 2714 bytes --]


On May 21, 2014, at 10:25 PM, David A. Harding <dave@dtrt.org> wrote:

> On Wed, May 21, 2014 at 06:39:44PM +0200, Chris Beams wrote:
>> I [was] searching for a way to enable signing by default [...]
>> Unfortunately, there isn't one, meaning it's likely that most folks
>> will forget to do this most of the time.
> 
> For all of my projects, I now I put this script in
> .git/hooks/post-commit and post-merge:
> 
>    #!/bin/bash -eu
> 
>    if ! git log -n1 --show-signature | grep -q 'gpg: Good signature'
>    then
>        yes "FORGOT TO SIGN COMMIT MESSAGE"
>        exit 1
>    fi

Funny, I was just in the middle of writing a pre-push hook to do something similar when I decided to check my email :) Your post-commit approach is indeed simpler, so I've gone with it for the moment [1]. Thanks.

However, I noticed in the process of testing that this approach messes with rebase workflows. For example: if I make several commits (all of which are properly signed), and then rebase to reorder them, rebase ends up hanging because it delegates to `commit` and the use of `yes` in the post-commit hook blocks forever. I've changed `yes` to `echo` to avoid this, but it still means that one must be rather diligent to keep signatures in place when rebasing. Gerwitz does address rebasing in the presence of commit sigs in the "horror story" doc you linked to [2], but there's no magic: this makes the whole rebasing process considerably more tedious, and linearly so with however many commits you're modifying.

This may amount to a rationale for going with a pre-push hook after all, i.e. in order to defer the check for signatures until the last possible moment. This would allow for cheap iterative rebasing once again.

I suppose the proper solution would be a `git config` option such as 'commit.sign', that if set to true would mean your commits are always signed, even if rebase is the one calling `commit`. This would obviate the need for the alias I mention below as well.


> So anytime I forget to sign, I get an obvious error and can immediately
> run git commit --amend -S.

If one is already in the habit of using an alias for `commit` (I've long used `ci` for concision), the -S can be included in the alias:

    git config alias.ci 'commit -S'


> To automatically add a script like the one above to all new projects (plus
> quickly add it old current projects), you can follow these instructions:
> 
>    http://stackoverflow.com/questions/2293498/git-commit-hooks-global-settings

This was a great tip, thanks!

- Chris

[1]: https://github.com/cbeams/dotfiles/commit/58d6942
[2]: http://mikegerwitz.com/papers/git-horror-story.html#_option_3

[-- Attachment #1.2: Type: text/html, Size: 3872 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]