Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Post History
How can we use git-send-email(1) to sign patches (emails) with the gpg(1) keyring? The git-send-email command does not have any CLI options to perform cryptographic operations, so, to the best...
Answer
#2: Post edited
by
ghost-in-the-zsh
·
2022-06-14T12:12:31Z (over 2 years ago)
Rephrase points and last sentence
- > How can we use git-send-email(1) to sign patches (emails) with the gpg(1) keyring?
- The `git-send-email` command does not have any CLI options to perform cryptographic operations, so, to the best of my knowledge, you cannot really tell it to sign anything.
- What you *can* do is sign commits with a GPG key using `git commit -S` after telling Git which key it should use, but these are *commits*, not patches or emails. In addition, this is only good for the repository into which the commits are made. When you use `git format-patch`, the GPG signature is not part of the `*.patch` files themselves (which is unfortunate).
- The only alternatives off the top of my head are:
1. manually send an email that is both encrypted (with your recipient's public GPG key) and signed (with your GPG private key) where you include the `*.patch` files as attachments, but this means you're not really using `git-send-email` at this point; or2. tell the other person to directly `git fetch` or `git pull` from your branch where the GPG signed commits can be found, but again, this means you're not using `git-send-email`; or3. rely on the "web of trust" principle where, in short, you accept patches *only* from people that you trust (i.e. how Linux kernel development is typically done).
- > How can we use git-send-email(1) to sign patches (emails) with the gpg(1) keyring?
- The `git-send-email` command does not have any CLI options to perform cryptographic operations, so, to the best of my knowledge, you cannot really tell it to sign anything.
- What you *can* do is sign commits with a GPG key using `git commit -S` after telling Git which key it should use, but these are *commits*, not patches or emails. In addition, this is only good for the repository into which the commits are made. When you use `git format-patch`, the GPG signature is not part of the `*.patch` files themselves (which is unfortunate).
- The only alternatives off the top of my head are:
- 1. manually send an email that is both encrypted (with your recipient's public GPG key) and signed (with your GPG private key) where you include the `*.patch` files as attachments; or
- 2. tell the other person to directly `git fetch` or `git pull` from your branch where the GPG signed commits can be found; or
- 3. rely on the "web of trust" principle where, in short, you accept patches *only* from people that you trust (i.e. how Linux kernel development is typically done).
- Unfortunately, this means you're not really using `git-send-email` at this point, which is not what you originally wanted, but I hope at least one of the alternatives above can work for you.
#1: Initial revision
by
ghost-in-the-zsh
·
2022-06-14T12:09:14Z (over 2 years ago)
> How can we use git-send-email(1) to sign patches (emails) with the gpg(1) keyring? The `git-send-email` command does not have any CLI options to perform cryptographic operations, so, to the best of my knowledge, you cannot really tell it to sign anything. What you *can* do is sign commits with a GPG key using `git commit -S` after telling Git which key it should use, but these are *commits*, not patches or emails. In addition, this is only good for the repository into which the commits are made. When you use `git format-patch`, the GPG signature is not part of the `*.patch` files themselves (which is unfortunate). The only alternatives off the top of my head are: 1. manually send an email that is both encrypted (with your recipient's public GPG key) and signed (with your GPG private key) where you include the `*.patch` files as attachments, but this means you're not really using `git-send-email` at this point; or 2. tell the other person to directly `git fetch` or `git pull` from your branch where the GPG signed commits can be found, but again, this means you're not using `git-send-email`; or 3. rely on the "web of trust" principle where, in short, you accept patches *only* from people that you trust (i.e. how Linux kernel development is typically done).