{"action":"opened","issue":{"url":"https://api.github.com/repos/andsens/bootstrap-vz/issues/336","repository_url":"https://api.github.com/repos/andsens/bootstrap-vz","labels_url":"https://api.github.com/repos/andsens/bootstrap-vz/issues/336/labels{/name}","comments_url":"https://api.github.com/repos/andsens/bootstrap-vz/issues/336/comments","events_url":"https://api.github.com/repos/andsens/bootstrap-vz/issues/336/events","html_url":"https://github.com/andsens/bootstrap-vz/issues/336","id":171037360,"number":336,"title":"Sign the code available in master","user":{"login":"nbraud","id":1155801,"avatar_url":"https://avatars.githubusercontent.com/u/1155801?v=3","gravatar_id":"","url":"https://api.github.com/users/nbraud","html_url":"https://github.com/nbraud","followers_url":"https://api.github.com/users/nbraud/followers","following_url":"https://api.github.com/users/nbraud/following{/other_user}","gists_url":"https://api.github.com/users/nbraud/gists{/gist_id}","starred_url":"https://api.github.com/users/nbraud/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/nbraud/subscriptions","organizations_url":"https://api.github.com/users/nbraud/orgs","repos_url":"https://api.github.com/users/nbraud/repos","events_url":"https://api.github.com/users/nbraud/events{/privacy}","received_events_url":"https://api.github.com/users/nbraud/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2016-08-14T01:50:24Z","updated_at":"2016-08-14T01:50:24Z","closed_at":null,"body":"@myhro suggested signing the release tags in #278.  I would like to suggest going one step further, and keeping the code in `master` signed.\r\n\r\nThere are several reasons to do so:\r\n- users of the `master` branch can still be confident (to a large extent) that they obtained code you published (however, Github could serve *older* (but signed!) code);\r\n- having the `master` branch signed gives you confidence, when tagging a release, that you are signing the code you authored (or reviewed).\r\n\r\nOne way to do it, that I use and [some other projects adopted](https://github.com/micahflee/onionshare/issues/221#issuecomment-220317661) goes as follows:\r\n- work as usual, without signing, in a non-`master` branch;\r\n- when you want to merge your changes in `master`, do a signed merge: `git merge -S --no-ff feature-branch`;\r\n- same thing after having reviewed and accepted a pull request;\r\n- when updating your copy of master, use `git pull [--ff-only] --verify-signatures` to ensure that no untrusted code can be sneaked in.\r\n\r\nSome important points:\r\n- It's not strictly required to work on separate (non-`master`) branches, as long as the tip of the `master` branch (on Github) is signed.\r\n- This ties together (by convention) signing and reviewing.\r\n- This doesn't require to always have the key material available: when developing from an untrusted machine, the process for a regular PR from an external contributor can be followed.\r\n- Signing code that is not meant to be merged in master can actually be a security problem:\r\n  if somebody who is trusted for reviewing/merging branches publishes a development branch with signed commits, the adversary can serve any of the signed commit instead of the development branch."}}
{"actor":{"display_login":"nbraud"}}