<unnamed>

Public Key

npub1vlgx34nzzqzrqq0uujch65yyzyknuduuqulj24ydlnarhwdhwzlsx69gsv

Profile Code

nprofile1qqsx05rg6e3pqppsq87wfvta2zzpztf7x7wqw0e92jxle73mhxmhp0cpzpmhxue69uhkummnw3ezuamfdejs0lupm0

Publishing to

nostr.wine

Last Notes

2023-06-07 15:21:53 UTC

- reply

📅 Original date posted:2014-05-21
📝 Original message: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 at 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 at gmail.com>"
> Author: Wladimir J. van der Laan <laanwj at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140521/39a9fcfc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140521/39a9fcfc/attachment.sig>

2023-06-07 15:21:53 UTC

- reply

📅 Original date posted:2014-05-21
📝 Original message:On May 21, 2014, at 10:25 PM, David A. Harding <dave at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140522/16681d8b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140522/16681d8b/attachment.sig>

2023-06-07 15:16:39 UTC

- reply

📅 Original date posted:2014-03-29
📝 Original message:Matt, could you expand on use cases for which you see Shamir's Secret Sharing as the best tool for the job? In particular, when do you see that it would be superior to simply going with multisig in the first place? Perhaps you see these as complimentary approaches, toward defense in depth? In any case, the Motivation and Rationale sections of the BIP in its current form are silent on these questions.
On Mar 29, 2014, at 9:05 AM, Matt Whitlock <bip at mattwhitlock.name> wrote:
> Abstract: A method is described for dividing a Bitcoin private key into shares in a manner such that the key can be reconstituted from any sufficiently large subset of the shares but such that individually the shares do not reveal any information about the key. This method is commonly known as Shamir's Secret Sharing Scheme. Additionally, an encoding methodology is proposed to standardize transmission and storage of shares.
>
> Complete BIP: https://github.com/whitslack/btctool/blob/bip/bip-xxxx.mediawiki
>
> I am looking to have this BIP assigned a number and added to the bitcoin/bips repository. I invite any comments, questions, or suggestions.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140329/7d13e0ea/attachment.sig>

2023-06-07 15:16:36 UTC

- reply

📅 Original date posted:2014-03-29
📝 Original message:Enlightening; thanks, Matt. And apologies to the list for my earlier inadvertent double-post.
On Mar 29, 2014, at 12:16 PM, Matt Whitlock <bip at mattwhitlock.name> wrote:
> On Saturday, 29 March 2014, at 10:08 am, Chris Beams wrote:
>> Matt, could you expand on use cases for which you see Shamir's Secret Sharing Scheme as the best tool for the job? In particular, when do you see that it would be superior to simply going with multisig in the first place? Perhaps you see these as complimentary approaches, toward defense-in-depth? In any case, the Motivation and Rationale sections of the BIP in its current form are silent on these questions.
>
> I have added two new sections to address your questions.
>
> https://github.com/whitslack/btctool/blob/bip/bip-xxxx.mediawiki
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140329/6d447c6b/attachment.sig>

2023-06-07 15:16:35 UTC

- reply

📅 Original date posted:2014-03-29
📝 Original message:Matt, could you expand on use cases for which you see Shamir's Secret Sharing Scheme as the best tool for the job? In particular, when do you see that it would be superior to simply going with multisig in the first place? Perhaps you see these as complimentary approaches, toward defense-in-depth? In any case, the Motivation and Rationale sections of the BIP in its current form are silent on these questions.
On Mar 29, 2014, at 9:05 AM, Matt Whitlock <bip at mattwhitlock.name> wrote:
> Abstract: A method is described for dividing a Bitcoin private key into shares in a manner such that the key can be reconstituted from any sufficiently large subset of the shares but such that individually the shares do not reveal any information about the key. This method is commonly known as Shamir's Secret Sharing Scheme. Additionally, an encoding methodology is proposed to standardize transmission and storage of shares.
>
> Complete BIP: https://github.com/whitslack/btctool/blob/bip/bip-xxxx.mediawiki
>
> I am looking to have this BIP assigned a number and added to the bitcoin/bips repository. I invite any comments, questions, or suggestions.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140329/f9a99d19/attachment.sig>