A proposal for signing commits with gpg
Hi, Attached is a proposal for signing commits with gpg. I also added it to this branch (using number 104, although this number can still change before merging): https://gitweb.torproject.org/user/boklm/tor-browser-spec.git/commit/?h=bug_... Nicolas
On Tue, Apr 28, 2020 at 04:42:47PM +0200, Nicolas Vigier wrote:
Hi,
Attached is a proposal for signing commits with gpg.
Hi, this sounds incredibly useful. I'd love to contribute and also bring in the usage of push certificates where applicable? Is that something that has been considered? I can submit a post-receive hook to hash-chain push-certificates and verify them at checkout/tagging time... Cheers! -Santiago
On Tue, 28 Apr 2020, Santiago Torres-Arias wrote:
On Tue, Apr 28, 2020 at 04:42:47PM +0200, Nicolas Vigier wrote:
Hi,
Attached is a proposal for signing commits with gpg.
Hi, this sounds incredibly useful. I'd love to contribute and also bring in the usage of push certificates where applicable? Is that something that has been considered?
I have not considered it, because I didn't know push certificates existed. Do you have more details about those push certificates? Thanks Nicolas
On Tue, Apr 28, 2020 at 05:04:25PM +0200, Nicolas Vigier wrote:
On Tue, 28 Apr 2020, Santiago Torres-Arias wrote:
On Tue, Apr 28, 2020 at 04:42:47PM +0200, Nicolas Vigier wrote:
Hi,
Attached is a proposal for signing commits with gpg.
Hi, this sounds incredibly useful. I'd love to contribute and also bring in the usage of push certificates where applicable? Is that something that has been considered?
I have not considered it, because I didn't know push certificates existed. Do you have more details about those push certificates?
Yes! I think the best introduction is the patch series itself[1]. I also wrote a paper outlining the types of attacks when git references aren't signed at [2]. I feel that the full solution outlined in the paper may be too costly and it's not native to git, but signed push goes a long way in avoiding tag replacement attacks (e.g., check this patch for pacman[3]). Cheers! -Santago [1] https://public-inbox.org/git/1408485987-3590-1-git-send-email-gitster@pobox.... [2] https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presen... [3] https://lists.archlinux.org/pipermail/pacman-dev/2017-September/022123.html
On Tue, 28 Apr 2020, Santiago Torres-Arias wrote:
On Tue, Apr 28, 2020 at 05:04:25PM +0200, Nicolas Vigier wrote:
On Tue, 28 Apr 2020, Santiago Torres-Arias wrote:
On Tue, Apr 28, 2020 at 04:42:47PM +0200, Nicolas Vigier wrote:
Hi,
Attached is a proposal for signing commits with gpg.
Hi, this sounds incredibly useful. I'd love to contribute and also bring in the usage of push certificates where applicable? Is that something that has been considered?
I have not considered it, because I didn't know push certificates existed. Do you have more details about those push certificates?
Yes!
I think the best introduction is the patch series itself[1]. I also wrote a paper outlining the types of attacks when git references aren't signed at [2]. I feel that the full solution outlined in the paper may be too costly and it's not native to git, but signed push goes a long way in avoiding tag replacement attacks (e.g., check this patch for pacman[3]).
We also do something similar to pacman when verifying git tag signatures: https://gitweb.torproject.org/builders/rbm.git/commit/?id=e04f03f9626e993bb6... However for the cases where we don't use a tag (in nightly builds), it sounds like push certificates could be useful to check that the commit we are using was intended for the branch we use. Is it something that we can do with push certificates? Nicolas
We also do something similar to pacman when verifying git tag signatures: https://gitweb.torproject.org/builders/rbm.git/commit/?id=e04f03f9626e993bb6...
Cool!
However for the cases where we don't use a tag (in nightly builds), it sounds like push certificates could be useful to check that the commit we are using was intended for the branch we use. Is it something that we can do with push certificates?
Yes, definitely! I can sketch something out to stir discussion. Would that be desirable? :) Cheers! -Santiago
On Tue, 28 Apr 2020, Santiago Torres-Arias wrote:
We also do something similar to pacman when verifying git tag signatures: https://gitweb.torproject.org/builders/rbm.git/commit/?id=e04f03f9626e993bb6...
Cool!
However for the cases where we don't use a tag (in nightly builds), it sounds like push certificates could be useful to check that the commit we are using was intended for the branch we use. Is it something that we can do with push certificates?
Yes, definitely! I can sketch something out to stir discussion. Would that be desirable? :)
That sounds interesting to me. It looks like an improvement we can add after we start using signed commits. Maybe that is something that can be added in rbm as a new option to check the branch from push certificates. Nicolas
On Tue, Apr 28, 2020 at 04:42:47PM +0200, Nicolas Vigier wrote:
Hi,
Attached is a proposal for signing commits with gpg.
Thanks!
I also added it to this branch (using number 104, although this number can still change before merging): https://gitweb.torproject.org/user/boklm/tor-browser-spec.git/commit/?h=bug_...
Nicolas
[snip]
1. Motivation
While building stable or alpha Tor Browser releases, we verify all inputs using one of the following methods: - verifying the checksum of downloaded files - verifying the gpg signature of downloaded files - verifying the gpg signature on git tags - using a know git commit hash
In nightly builds however, we need to use the master branch of some components, without checking that the commit is signed. An attacker who manages to take control of our git repository could potentially compromise our build machines in this way. In order to remove this possibility, we should sign and verify commits on all master branches used in the nightly builds.
Recently I was thinking about this, too. I've seen some people dislike signing git commits from a technical perspective, but that's because they usually think people misuse commit signing in place of signed tags. As I understand commit signing, your proposal uses commit signing in a useful way. This requires a combination of compromising someone's PGP key and either gaining control of the git server or obtaining someone's ssh key, at least.
2. Proposal
[snip]
2.2 Git repositories which should have signed commits
The master of commit tor-browser-build.git should be signed by one of the members of the Tor Browser team. Additionally, all components included in Tor Browser, where the master branch is used in our nightly build, should have their master commit signed by one of the maintainer of those repositories.
The current list of repositories where we use the master branch in nightly builds is:
https://git.torproject.org/pluggable-transports/goptlib.git https://git.torproject.org/pluggable-transports/obfs4.git https://git.torproject.org/tor-launcher.git https://git.torproject.org/tor-browser.git https://git.torproject.org/tor.git
As an additional step, we can shorten this list. I know there are benefits to testing the master branch, but maybe that's not worth the extra complexity for all of these projects. In particular, obfs4 and goptlib are not changing frequently. Imposing the requirement that all new commits in tor.git are signed may be difficult. That is a conversation we should have on tor-dev@. For tor-browser and tor-launcher, I'm in favor of moving toward this requirement. I'll go further and suggest we follow the same process for torbutton and tor-browser-build, but that's outside the scope of this proposal. Thanks, Matt
Matthew Finkel:
On Tue, Apr 28, 2020 at 04:42:47PM +0200, Nicolas Vigier wrote:
Hi,
Attached is a proposal for signing commits with gpg.
Thanks!
I also added it to this branch (using number 104, although this number can still change before merging): https://gitweb.torproject.org/user/boklm/tor-browser-spec.git/commit/?h=bug_...
Nicolas
[snip]
1. Motivation
While building stable or alpha Tor Browser releases, we verify all inputs using one of the following methods: - verifying the checksum of downloaded files - verifying the gpg signature of downloaded files - verifying the gpg signature on git tags - using a know git commit hash
In nightly builds however, we need to use the master branch of some components, without checking that the commit is signed. An attacker who manages to take control of our git repository could potentially compromise our build machines in this way. In order to remove this possibility, we should sign and verify commits on all master branches used in the nightly builds.
Recently I was thinking about this, too. I've seen some people dislike signing git commits from a technical perspective, but that's because they usually think people misuse commit signing in place of signed tags. As I understand commit signing, your proposal uses commit signing in a useful way. This requires a combination of compromising someone's PGP key and either gaining control of the git server or obtaining someone's ssh key, at least.
2. Proposal
[snip]
2.2 Git repositories which should have signed commits
The master of commit tor-browser-build.git should be signed by one of the members of the Tor Browser team. Additionally, all components included in Tor Browser, where the master branch is used in our nightly build, should have their master commit signed by one of the maintainer of those repositories.
The current list of repositories where we use the master branch in nightly builds is:
https://git.torproject.org/pluggable-transports/goptlib.git https://git.torproject.org/pluggable-transports/obfs4.git https://git.torproject.org/tor-launcher.git https://git.torproject.org/tor-browser.git https://git.torproject.org/tor.git
As an additional step, we can shorten this list. I know there are benefits to testing the master branch, but maybe that's not worth the extra complexity for all of these projects. In particular, obfs4 and goptlib are not changing frequently.
Imposing the requirement that all new commits in tor.git are signed may be difficult. That is a conversation we should have on tor-dev@.
For tor-browser and tor-launcher, I'm in favor of moving toward this requirement. I'll go further and suggest we follow the same process for torbutton and tor-browser-build, but that's outside the scope of this
tor-browser-build is included in the proposal fwiw and is important. Georg
Nicolas Vigier:
Hi,
Attached is a proposal for signing commits with gpg.
I also added it to this branch (using number 104, although this number can still change before merging): https://gitweb.torproject.org/user/boklm/tor-browser-spec.git/commit/?h=bug_...
Our nightly builds do not build from every commit so one could think about the requirement being the tip of the master branch that always needs to be signed. That might be less of a burden for some folks and would work for me. An orthogonal thing we should do I think is having git push hooks in place that already enforce that, at least for browser related branches. There is no need to wait until tor-browser-build complains in a nightly build. Rather the push should already fail to make sure the nightly builds are not failing due to a non-signed tip. Thirdly, I think it is okay if we introduce this gradually, starting with browser related repos where we have full control over and there is no need for any coordination/workflow change with/by other groups involved. boklm: let me know when you feel you have incorporated the first round of feedback sufficiently and then I'll add the proposal to the repo. Good stuff! Georg
participants (4)
-
Georg Koppen -
Matthew Finkel -
Nicolas Vigier -
Santiago Torres-Arias