[CONTRIBUTING] Release and auditing tooling/policy

One reason I sign my commits as much as possible is because I make it a habit so that if someone sees a commit with me as the author without my signature, they can assume I didn’t verify the commit.

If possible, merge my commits without re-committing them (thus removing the signatures) please.

EDIT The below is my summary of the issue based on the rename of the issue to “Set Logic for Merging Pull Requests”

---

Reasoning

1. The reason why pull requests exist is to allow for maintainers to review the branch, and merge it.
2. We can be sure you have merged it only if we A. trust Github or B. you GPG sign a merge (or squash) commit and we can verify your GPG key.
3. Currently this repo is based on the “trust Github” model, and should be changed.

Proposal

GPG

1. All maintainers of the repo should create GPG keys and make them public. Upload them to the repo under a folder called “pubkeys” or something just for redundancy, as well as making sure to update them to the keyservers like mit.
2. All maintainers should verify each other’s Fingerprints in a way where a man in the middle attack is not possible (or highly unlikely) and sign each others keys, uploading the signatures to the keyservers.
3. If any one maintainer has the chance to get their pubkey signed by a respected member of the community, do so… it will extend their web of trust into the bitcoinjs-lib maintainers.
4. When possible, all commits and tags should be GPG signed (this requires performing the actions locally, as Github’s web UI does not and should never support GPG signing in the browser.)
5. When merging a pull request, ensure they follow pull request guidelines, and merge locally using git merge --no-ff -S theiruser/theirbranch and push to the branch they were requesting to. (-S is not needed if you set git config --global commit.gpgsign 1) This is the “merge commit” method… which I think helps keep the chain of responsibility in the git tree itself. Rebasing does not leave a record of who rebased which commits into the tree, and when they did it.

Pull Requests

1. All pull requests should be cleaned before merging. (ie. five “fix” commits in a row modifying the same value over and over should be squashed into one commit, etc.)
2. Large commits are fine, but only if they all serve one purpose. If not, they should be split into multiple commits.
3. Renaming a file and changing that file in the same commit is hard to review, and should be avoided. Rename in one commit, change in another commit.
4. All merge conflicts should be resolved before merging, and if two pull requests are conflicting, merge one, then ask the author of the other to rebase on master and resolve any merge conflicts.

[dcousens]

I’m re-opening this as it wasn’t completely satisfied by https://github.com/bitcoinjs/bitcoinjs-lib/pull/1042, and we do want to maybe introduce some tooling or documentation about how to audit/verify the repository against npm or a package management provided bundle.

GPG, SHA256 sums, or otherwise.

[junderw]

I guess I could rebase locally?

You could try it on the maximumfee PR…

so you would want to be on master, make sure it was up to date with origin, then rebase my branch…

git checkout master
git pull origin master
git add remote junderw [e-mail]:junderw/bitcoinjs-lib.git
git fetch junderw
git rebase junderw/fixmaxfees

Then check git log via git log --show-signature to check if my commit signatures are intact…