Re: [Bitcoin-development] PSA: Please sign your git commits
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 -amTest commit speed --no-gpg-sign [...] real0m0.031s and with: $ echo '' README.md; time git commit -amTest commit speed --gpg-sign [...] real0m0.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 laa...@gmail.com wrote: On Wed, May 21, 2014 at 7:10 PM, Wladimir laa...@gmail.com wrote: Hello Chris, On Wed, May 21, 2014 at 6:39 PM, Chris Beams ch...@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 signature.asc Description: Message signed with OpenPGP using GPGMail -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://www.hpccsystems.com___ 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
On Thu, May 22, 2014 at 8:06 PM, Jeff Garzik jgar...@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
On Wed, May 21, 2014 at 7:10 PM, Wladimir laa...@gmail.com wrote: Hello Chris, On Wed, May 21, 2014 at 6:39 PM, Chris Beams ch...@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 -- 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
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 jgar...@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
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 jgar...@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 -- 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
On Fri, May 23, 2014 at 9:48 AM, Kyle Jerviss bitcoin-de...@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. -- 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
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 gmaxw...@gmail.com wrote: On Wed, May 21, 2014 at 1:30 PM, Mark Friedenbach m...@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/ -- 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
[Bitcoin-development] PSA: Please sign your git commits
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 laa...@gmail.com Author: Wladimir J. van der Laan laa...@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
Re: [Bitcoin-development] PSA: Please sign your git commits
Hello Chris, On Wed, May 21, 2014 at 6:39 PM, Chris Beams ch...@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 -- 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
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
--
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
On Wed, May 21, 2014 at 1:30 PM, Mark Friedenbach m...@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
Re: [Bitcoin-development] PSA: Please sign your git commits
On May 21, 2014, at 10:25 PM, David A. Harding d...@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 signature.asc Description: Message signed with OpenPGP using GPGMail -- 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
