Page MenuHomePhabricator

Prevent Git from signing commits generated by "arc patch"
Open, Needs TriagePublic


We are using a Git workflow where everything is signed with GnuPG. This means, among other things, that we have commit.gpgsign = true set in our Git configurations.

When downloading a patch from Differential using arc patch, that gets inserted into the working repository as a new commit. But since we've told Git to sign all commits, the downloaded patch gets signed locally, by the developer who happens to run arc patch. This is wrong for two reasons:

  1. Patches are probably mainly downloaded from Differential for review, not for integration, so they shouldn't be signed at all.
  2. Commits should be signed by the original author of the code, which is probably not the developer running arc patch.

This is not a huge problem, since the commits created by arc patch will get thrown out once they have been reviewed and thus nobody else will se the erroneous signature. However, it is a UI problem, since developers either

  1. Get trained to enter their GnuPG passphrase at any random prompt, or
  2. Turn up the passphrase retention time in their GnuPG agents to ridiculous amounts to avoid thinking about the problem.

We have no PHP developers, but we have managed to patch Arcanist to never sign commits generated by arc patch, simply by editing the command line sent to Git (currently at src/workflow/ArcanistPatchWorkflow.php, line 724) to always include --no-gpg-sign. I expect a proper solution would be to introduce a setting in .arcrc.

Event Timeline

I second this, I sign all my commits too, and only just now discovered (because of this task) that things I have landed are signed by me.

@kaendfinger This task is about arc patch. arc land is separate, and I don't believe there's anything Arcanist can do (other than not signing at all) because it must mutate the commits in order to land them. Since you don't have the original author's private key when landing, it can't be signed correctly when you do arc land.

@hach-que My bad, misread the title. Thanks for the clarification :)