mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-10 22:21:11 +08:00
Translated by qhwdw
This commit is contained in:
qhwdw
parent
094a0a8c8c
commit
6ab2e0d451
@ -1,319 +0,0 @@
|
||||
Translating by qhwdw
|
||||
Protecting Code Integrity with PGP — Part 6: Using PGP with Git
|
||||
======
|
||||
|
||||
|
||||
In this tutorial series, we're providing practical guidelines for using PGP, including basic concepts and generating and protecting your keys. If you missed the previous articles, you can catch up below. In this article, we look at Git's integration with PGP, starting with signed tags, then introducing signed commits, and finally adding support for signed pushes.
|
||||
|
||||
[Part 1: Basic Concepts and Tools][1]
|
||||
|
||||
[Part 2: Generating Your Master Key][2]
|
||||
|
||||
[Part 3: Generating PGP Subkeys][3]
|
||||
|
||||
[Part 4: Moving Your Master Key to Offline Storage][4]
|
||||
|
||||
[Part 5: Moving Subkeys to a Hardware Device][5]
|
||||
|
||||
One of the core features of Git is its decentralized nature -- once a repository is cloned to your system, you have full history of the project, including all of its tags, commits and branches. However, with hundreds of cloned repositories floating around, how does anyone verify that the repository you downloaded has not been tampered with by a malicious third party? You may have cloned it from GitHub or some other official-looking location, but what if someone had managed to trick you?
|
||||
|
||||
Or what happens if a backdoor is discovered in one of the projects you've worked on, and the "Author" line in the commit says it was done by you, while you're pretty sure you had [nothing to do with it][6]?
|
||||
|
||||
To address both of these issues, Git introduced PGP integration. Signed tags prove the repository integrity by assuring that its contents are exactly the same as on the workstation of the developer who created the tag, while signed commits make it nearly impossible for someone to impersonate you without having access to your PGP keys.
|
||||
|
||||
### Checklist
|
||||
|
||||
* Understand signed tags, commits, and pushes (ESSENTIAL)
|
||||
|
||||
* Configure git to use your key (ESSENTIAL)
|
||||
|
||||
* Learn how tag signing and verification works (ESSENTIAL)
|
||||
|
||||
* Configure git to always sign annotated tags (NICE)
|
||||
|
||||
* Learn how commit signing and verification works (ESSENTIAL)
|
||||
|
||||
* Configure git to always sign commits (NICE)
|
||||
|
||||
* Configure gpg-agent options (ESSENTIAL)
|
||||
|
||||
|
||||
|
||||
|
||||
### Considerations
|
||||
|
||||
Git implements multiple levels of integration with PGP, first starting with signed tags, then introducing signed commits, and finally adding support for signed pushes.
|
||||
|
||||
#### Understanding Git Hashes
|
||||
|
||||
Git is a complicated beast, but you need to know what a "hash" is in order to have a good grasp on how PGP integrates with it. We'll narrow it down to two kinds of hashes: tree hashes and commit hashes.
|
||||
|
||||
##### Tree hashes
|
||||
|
||||
Every time you commit a change to a repository, git records checksum hashes of all objects in it -- contents (blobs), directories (trees), file names and permissions, etc, for each subdirectory in the repository. It only does this for trees and blobs that have changed with each commit, so as not to re-checksum the entire tree unnecessarily if only a small part of it was touched.
|
||||
|
||||
Then it calculates and stores the checksum of the toplevel tree, which will inevitably be different if any part of the repository has changed.
|
||||
|
||||
##### Commit hashes
|
||||
|
||||
Once the tree hash has been created, git will calculate the commit hash, which will include the following information about the repository and the change being made:
|
||||
|
||||
* The checksum hash of the tree
|
||||
|
||||
* The checksum hash of the tree before the change (parent)
|
||||
|
||||
* Information about the author (name, email, time of authorship)
|
||||
|
||||
* Information about the committer (name, email, time of commit)
|
||||
|
||||
* The commit message
|
||||
|
||||
|
||||
|
||||
|
||||
##### Hashing function
|
||||
|
||||
At the time of writing, git still uses the SHA1 hashing mechanism to calculate checksums, though work is under way to transition to a stronger algorithm that is more resistant to collisions. Note, that git already includes collision avoidance routines, so it is believed that a successful collision attack against git remains impractical.
|
||||
|
||||
#### Annotated tags and tag signatures
|
||||
|
||||
Git tags allow developers to mark specific commits in the history of each git repository. Tags can be "lightweight" \-- more or less just a pointer at a specific commit, or they can be "annotated," which becomes its own object in the git tree. An annotated tag object contains all of the following information:
|
||||
|
||||
* The checksum hash of the commit being tagged
|
||||
|
||||
* The tag name
|
||||
|
||||
* Information about the tagger (name, email, time of tagging)
|
||||
|
||||
* The tag message
|
||||
|
||||
|
||||
|
||||
|
||||
A PGP-signed tag is simply an annotated tag with all these entries wrapped around in a PGP signature. When a developer signs their git tag, they effectively assure you of the following:
|
||||
|
||||
* Who they are (and why you should trust them)
|
||||
|
||||
* What the state of their repository was at the time of signing:
|
||||
|
||||
* The tag includes the hash of the commit
|
||||
|
||||
* The commit hash includes the hash of the toplevel tree
|
||||
|
||||
* Which includes hashes of all files, contents, and subtrees
|
||||
* It also includes all information about authorship
|
||||
|
||||
* Including exact times when changes were made
|
||||
|
||||
|
||||
|
||||
|
||||
When you clone a git repository and verify a signed tag, that gives you cryptographic assurance that all contents in the repository, including all of its history, are exactly the same as the contents of the repository on the developer's computer at the time of signing.
|
||||
|
||||
#### Signed commits
|
||||
|
||||
Signed commits are very similar to signed tags -- the contents of the commit object are PGP-signed instead of the contents of the tag object. A commit signature also gives you full verifiable information about the state of the developer's tree at the time the signature was made. Tag signatures and commit PGP signatures provide exact same security assurances about the repository and its entire history.
|
||||
|
||||
#### Signed pushes
|
||||
|
||||
This is included here for completeness' sake, since this functionality needs to be enabled on the server receiving the push before it does anything useful. As we saw above, PGP-signing a git object gives verifiable information about the developer's git tree, but not about their intent for that tree.
|
||||
|
||||
For example, you can be working on an experimental branch in your own git fork trying out a promising cool feature, but after you submit your work for review, someone finds a nasty bug in your code. Since your commits are properly signed, someone can take the branch containing your nasty bug and push it into master, introducing a vulnerability that was never intended to go into production. Since the commit is properly signed with your key, everything looks legitimate and your reputation is questioned when the bug is discovered.
|
||||
|
||||
Ability to require PGP-signatures during git push was added in order to certify the intent of the commit, and not merely verify its contents.
|
||||
|
||||
#### Configure git to use your PGP key
|
||||
|
||||
If you only have one secret key in your keyring, then you don't really need to do anything extra, as it becomes your default key.
|
||||
|
||||
However, if you happen to have multiple secret keys, you can tell git which key should be used ([fpr] is the fingerprint of your key):
|
||||
```
|
||||
$ git config --global user.signingKey [fpr]
|
||||
|
||||
```
|
||||
|
||||
NOTE: If you have a distinct gpg2 command, then you should tell git to always use it instead of the legacy gpg from version 1:
|
||||
```
|
||||
$ git config --global gpg.program gpg2
|
||||
|
||||
```
|
||||
|
||||
#### How to work with signed tags
|
||||
|
||||
To create a signed tag, simply pass the -s switch to the tag command:
|
||||
```
|
||||
$ git tag -s [tagname]
|
||||
|
||||
```
|
||||
|
||||
Our recommendation is to always sign git tags, as this allows other developers to ensure that the git repository they are working with has not been maliciously altered (e.g. in order to introduce backdoors).
|
||||
|
||||
##### How to verify signed tags
|
||||
|
||||
To verify a signed tag, simply use the verify-tag command:
|
||||
```
|
||||
$ git verify-tag [tagname]
|
||||
|
||||
```
|
||||
|
||||
If you are verifying someone else's git tag, then you will need to import their PGP key. Please refer to the "Trusted Team communication" document in the same repository for guidance on this topic.
|
||||
|
||||
##### Verifying at pull time
|
||||
|
||||
If you are pulling a tag from another fork of the project repository, git should automatically verify the signature at the tip you're pulling and show you the results during the merge operation:
|
||||
```
|
||||
$ git pull [url] tags/sometag
|
||||
|
||||
```
|
||||
|
||||
The merge message will contain something like this:
|
||||
```
|
||||
Merge tag 'sometag' of [url]
|
||||
|
||||
[Tag message]
|
||||
|
||||
# gpg: Signature made [...]
|
||||
# gpg: Good signature from [...]
|
||||
|
||||
```
|
||||
|
||||
#### Configure git to always sign annotated tags
|
||||
|
||||
Chances are, if you're creating an annotated tag, you'll want to sign it. To force git to always sign annotated tags, you can set a global configuration option:
|
||||
```
|
||||
$ git config --global tag.forceSignAnnotated true
|
||||
|
||||
```
|
||||
|
||||
Alternatively, you can just train your muscle memory to always pass the -s switch:
|
||||
```
|
||||
$ git tag -asm "Tag message" tagname
|
||||
|
||||
```
|
||||
|
||||
#### How to work with signed commits
|
||||
|
||||
It is easy to create signed commits, but it is much more difficult to incorporate them into your workflow. Many projects use signed commits as a sort of "Committed-by:" line equivalent that records code provenance -- the signatures are rarely verified by others except when tracking down project history. In a sense, signed commits are used for "tamper evidence," and not to "tamper-proof" the git workflow.
|
||||
|
||||
To create a signed commit, you just need to pass the -S flag to the git commit command (it's capital -S due to collision with another flag):
|
||||
```
|
||||
$ git commit -S
|
||||
|
||||
```
|
||||
|
||||
Our recommendation is to always sign commits and to require them of all project members, regardless of whether anyone is verifying them (that can always come at a later time).
|
||||
|
||||
##### How to verify signed commits
|
||||
|
||||
To verify a single commit you can use verify-commit:
|
||||
```
|
||||
$ git verify-commit [hash]
|
||||
|
||||
```
|
||||
|
||||
You can also look at repository logs and request that all commit signatures are verified and shown:
|
||||
```
|
||||
$ git log --pretty=short --show-signature
|
||||
|
||||
```
|
||||
|
||||
##### Verifying commits during git merge
|
||||
|
||||
If all members of your project sign their commits, you can enforce signature checking at merge time (and then sign the resulting merge commit itself using the -S flag):
|
||||
```
|
||||
$ git merge --verify-signatures -S merged-branch
|
||||
|
||||
```
|
||||
|
||||
Note, that the merge will fail if there is even one commit that is not signed or does not pass verification. As it is often the case, technology is the easy part -- the human side of the equation is what makes adopting strict commit signing for your project difficult.
|
||||
|
||||
##### If your project uses mailing lists for patch management
|
||||
|
||||
If your project uses a mailing list for submitting and processing patches, then there is little use in signing commits, because all signature information will be lost when sent through that medium. It is still useful to sign your commits, just so others can refer to your publicly hosted git trees for reference, but the upstream project receiving your patches will not be able to verify them directly with git.
|
||||
|
||||
You can still sign the emails containing the patches, though.
|
||||
|
||||
#### Configure git to always sign commits
|
||||
|
||||
You can tell git to always sign commits:
|
||||
```
|
||||
git config --global commit.gpgSign true
|
||||
|
||||
```
|
||||
|
||||
Or you can train your muscle memory to always pass the -S flag to all git commit operations (this includes --amend).
|
||||
|
||||
#### Configure gpg-agent options
|
||||
|
||||
The GnuPG agent is a helper tool that will start automatically whenever you use the gpg command and run in the background with the purpose of caching the private key passphrase. This way you only have to unlock your key once to use it repeatedly (very handy if you need to sign a bunch of git operations in an automated script without having to continuously retype your passphrase).
|
||||
|
||||
There are two options you should know in order to tweak when the passphrase should be expired from cache:
|
||||
|
||||
* default-cache-ttl (seconds): If you use the same key again before the time-to-live expires, the countdown will reset for another period. The default is 600 (10 minutes).
|
||||
|
||||
* max-cache-ttl (seconds): Regardless of how recently you've used the key since initial passphrase entry, if the maximum time-to-live countdown expires, you'll have to enter the passphrase again. The default is 30 minutes.
|
||||
|
||||
|
||||
|
||||
|
||||
If you find either of these defaults too short (or too long), you can edit your ~/.gnupg/gpg-agent.conf file to set your own values:
|
||||
```
|
||||
# set to 30 minutes for regular ttl, and 2 hours for max ttl
|
||||
default-cache-ttl 1800
|
||||
max-cache-ttl 7200
|
||||
|
||||
```
|
||||
|
||||
##### Bonus: Using gpg-agent with ssh
|
||||
|
||||
If you've created an [A] (Authentication) key and moved it to the smartcard, you can use it with ssh for adding 2-factor authentication for your ssh sessions. You just need to tell your environment to use the correct socket file for talking to the agent.
|
||||
|
||||
First, add the following to your ~/.gnupg/gpg-agent.conf:
|
||||
```
|
||||
enable-ssh-support
|
||||
|
||||
```
|
||||
|
||||
Then, add this to your .bashrc:
|
||||
```
|
||||
export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)
|
||||
|
||||
```
|
||||
|
||||
You will need to kill the existing gpg-agent process and start a new login session for the changes to take effect:
|
||||
```
|
||||
$ killall gpg-agent
|
||||
$ bash
|
||||
$ ssh-add -L
|
||||
|
||||
```
|
||||
|
||||
The last command should list the SSH representation of your PGP Auth key (the comment should say cardno:XXXXXXXX at the end to indicate it's coming from the smartcard).
|
||||
|
||||
To enable key-based logins with ssh, just add the ssh-add -L output to ~/.ssh/authorized_keys on remote systems you log in to. Congratulations, you've just made your ssh credentials extremely difficult to steal.
|
||||
|
||||
As a bonus, you can get other people's PGP-based ssh keys from public keyservers, should you need to grant them ssh access to anything:
|
||||
```
|
||||
$ gpg --export-ssh-key [keyid]
|
||||
|
||||
```
|
||||
|
||||
This can come in super handy if you need to allow developers access to git repositories over ssh. Next time, we'll provide tips for protecting your email accounts as well as your PGP keys.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.linux.com/blog/learn/pgp/2018/3/protecting-code-integrity-pgp-part-6-using-pgp-git
|
||||
|
||||
作者：[KONSTANTIN RYABITSEV][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://www.linux.com/users/mricon
|
||||
[1]:https://www.linux.com/blog/learn/2018/2/protecting-code-integrity-pgp-part-1-basic-pgp-concepts-and-tools
|
||||
[2]:https://www.linux.com/blog/learn/pgp/2018/2/protecting-code-integrity-pgp-part-2-generating-and-protecting-your-master-pgp-key
|
||||
[3]:https://www.linux.com/blog/learn/pgp/2018/2/protecting-code-integrity-pgp-part-3-generating-pgp-subkeys
|
||||
[4]:https://www.linux.com/blog/learn/pgp/2018/3/protecting-code-integrity-pgp-part-4-moving-your-master-key-offline-storage
|
||||
[5]:https://www.linux.com/blog/learn/pgp/2018/3/protecting-code-integrity-pgp-part-5-moving-subkeys-hardware-device
|
||||
[6]:https://github.com/jayphelps/git-blame-someone-else
|
||||
@ -0,0 +1,318 @@
|
||||
保护代码完整性（六）：在 Git 上使用 PGP
|
||||
======
|
||||
|
||||
|
||||
在本系列教程中，我们提供了一个使用 PGP 的实用指南，包括基本概念和工具、生成和保护你的密钥。如果你错过了前面的文章，你可以查看下面的链接。在这篇文章中，我们谈一谈在 Git 中如何集成 PGP、使用签名的标签，然后介绍签名提交，最后添加签名推送的支持。
|
||||
|
||||
[第一部分：基本概念和工具][1]
|
||||
|
||||
[第二部分：生成你的主密钥][2]
|
||||
|
||||
[第三部分：生成 PGP 子密钥][3]
|
||||
|
||||
[第四部分：将主密钥移到离线存储中][4]
|
||||
|
||||
[第五部分：将子密钥移到硬件设备中][5]
|
||||
|
||||
Git 的核心特性之一就是它的去中心化本质 —— 一旦仓库克隆到你的本地系统，你就拥有了项目的完整历史，包括所有的标签、提交和分支。然而由于存在着成百上千的克隆仓库，如何才能验证你下载的仓库没有被恶意的第三方做过篡改？你可以从 GitHub 或一些貌似官方的位置来克隆它们，但是如果有些人故意欺骗了你怎么办？
|
||||
|
||||
或者在你参与的一些项目上发现了后门，而 "Author" 行显示是你干的，然而你很确定 [不是你干的][6]，会发生什么情况？
|
||||
|
||||
为解决上述问题，Git 添加了 PGP 集成。签名的标签通过确认它的内容与创建这个标签的开发者的工作站上的内容完全一致来证明仓库的完整性，而签名的提交几乎是不可能在不访问你的 PGP 密钥的情况下能够假冒你。
|
||||
|
||||
### 清单
|
||||
|
||||
* 了解签名的标签、提交、和推送（必要）
|
||||
|
||||
* 配置 git 使用你的密钥（必要）
|
||||
|
||||
* 学习如何签名标签和验证工作（必要）
|
||||
|
||||
* 配置 git 总是签名注释的标签（推荐）
|
||||
|
||||
* 学习如何签名提交和验证工作（必要）
|
||||
|
||||
* 配置 git 总是签名提交（推荐）
|
||||
|
||||
* 配置 gpg-agent 选项（必要）
|
||||
|
||||
|
||||
|
||||
|
||||
### 考虑事项
|
||||
|
||||
Git 实现了 PGP 的多级集成，首先从签名标签开始，接着介绍签名提交，最后添加签名推送的支持。
|
||||
|
||||
#### 了解 Git 哈希
|
||||
|
||||
Git 是一个复杂的东西，为了你能够更好地掌握它如何集成 PGP，你需要了解什么是”哈希“。我们将它归纳为两种类型的哈希：树哈希和提交哈希。
|
||||
|
||||
##### 树哈希
|
||||
|
||||
每次你向仓库提交一个变更，对于仓库中的每个子目录，git 都会记录它里面所有对象的校验和哈希 —— 内容（blobs）、目录（trees）、文件名和许可等等。它只对每次提交中发生变更的树和内容做此操作，这样在只变更树的一小部分时就不必去重新计算整个树的校验和。
|
||||
|
||||
然后再计算和存储处于顶级的树的校验和，这样如果仓库的任何一部分发生变化，校验和将不可避免地发生变化。
|
||||
|
||||
##### 提交哈希
|
||||
|
||||
一旦创建了树哈希，git 将计算提交哈希，它将包含有关仓库和变更的下列信息：
|
||||
|
||||
* 树哈希的校验和
|
||||
|
||||
* 变更前树哈希的校验和（父级）
|
||||
|
||||
* 有关作者的信息（名字、email、创作时间）
|
||||
|
||||
* 有关提交者的信息（名字、email、提交时间）
|
||||
|
||||
* 提交信息
|
||||
|
||||
|
||||
|
||||
|
||||
##### 哈希函数
|
||||
|
||||
在写这篇文章时，虽然研究一种更强大的、抗碰撞的算法的工作正在进行，但 git 仍然使用的是 SHA1 哈希机制去计算校验和。注意，git 已经包含了碰撞防范程序，因此认为对 git 成功进行碰撞攻击仍然是不可行的。
|
||||
|
||||
#### 注释的标签和标签签名
|
||||
|
||||
在每个 Git 仓库中，标签允许开发者标记特定的提交。标签可以是 “轻量级的” —— 几乎只是一个特定提交上的指针，或者它们可以是 “注释的”，它成为 git 树中自己的项目。一个注释的标签对象包含所有下列的信息：
|
||||
|
||||
* 成为标签的提交哈希的校验和
|
||||
|
||||
* 标签名字
|
||||
|
||||
* 关于打标签的人的信息（名字、email、打标签时间）
|
||||
|
||||
* 标签信息
|
||||
|
||||
|
||||
|
||||
|
||||
一个 PGP 签名的标签是一个带有将所有这些条目封装进一个 PGP 签名的注释标签。当开发者签名他们的 git 标签时，他们实际上是向你保证了如下的信息：
|
||||
|
||||
* 他们是谁（以及他们为什么应该被信任）
|
||||
|
||||
* 他们在签名时的仓库状态是什么样：
|
||||
|
||||
* 标签包含提交的哈希
|
||||
|
||||
* 提交哈希包含了顶级树的哈希
|
||||
|
||||
* 顶级哈希包含了所有文件、内容和子树的哈希
|
||||
* 它也包含有关作者的所有信息
|
||||
|
||||
* 包含变更发生时的精确时间
|
||||
|
||||
|
||||
|
||||
|
||||
当你克隆一个仓库并验证一个签名标签时，就是向你以密码方式保证仓库中的所有内容、包括所有它的历史，与开发者签名时在它的计算机上的仓库完全一致。
|
||||
|
||||
#### 签名的提交
|
||||
|
||||
签名的提交与签名的标签非常类似 —— 提交对象的内容是 PGP 签名过的，而不是标签对象的内容。一个提交签名也给你提供了开发者签名时，开发者树上的全部可验证信息。标签签名和提交 PGP 签名提供了有关仓库和它的完整历史的完全一致的安全保证。
|
||||
|
||||
#### 签名的推送
|
||||
|
||||
为了完整起见，在这里包含了签名的推送这一功能，因为在你使用这个功能之前，需要在接收推送的服务器上先启用它。正如我们在上面所说过的，PGP 签名一个 git 对象就是提供了开发者的 git 树当时的可验证信息，但不提供开发者对那个树意图相关的信息。
|
||||
|
||||
比如，你可以在你自己 fork 的 git 仓库的一个实验分支上尝试一个很酷的特性，为了评估它，你提交了你的工作，但是有人在你的代码中发现了一个恶意的 bug。由于你的提交是经过正确签名的，因此有人可能将包含有恶意 bug 的分支推入到 master 分支中，从而在生产系统中引入一个漏洞。由于提交是经过你的密钥正确签名的，所以一切看起来都是合理合法的，而当 bug 被发现时，你的声誉就会因此而受到影响。
|
||||
|
||||
在 `git push` 时，为了验证提交的意图而不仅仅是验证它的内容，添加了要求 PGP 推送签名的功能。
|
||||
|
||||
#### 配置 git 使用你的 PGP 密钥
|
||||
|
||||
如果在你的钥匙环上只有一个密钥，那么你就不需要再做额外的事了，因为它是你的默认密钥。
|
||||
|
||||
然而，如果你有多个密钥，那么你必须要告诉 git 去使用哪一个密钥。（[fpr] 是你的密钥的指纹）：
|
||||
```
|
||||
$ git config --global user.signingKey [fpr]
|
||||
|
||||
```
|
||||
|
||||
注意：如果你有一个不同的 gpg2 命令，那么你应该告诉 git 总是去使用它，而不是传统的版本 1 的 gpg：
|
||||
```
|
||||
$ git config --global gpg.program gpg2
|
||||
|
||||
```
|
||||
|
||||
#### 如何使用签名标签
|
||||
|
||||
创建一个签名的标签，只要传递一个简单地 -s 开关给 tag 命令即可：
|
||||
```
|
||||
$ git tag -s [tagname]
|
||||
|
||||
```
|
||||
|
||||
我们建议始终对 git 标签签名，这样让其它的开发者确信他们使用的 git 仓库没有被恶意地修改过（比如，引入后门）：
|
||||
|
||||
##### 如何验证签名的标签
|
||||
|
||||
验证一个签名的标签，只需要简单地使用 verify-tag 命令即可：
|
||||
```
|
||||
$ git verify-tag [tagname]
|
||||
|
||||
```
|
||||
|
||||
如果你要验证其他人的 git 标签，那么就需要你导入他的 PGP 公钥。请参考 “可信任的团队沟通” 一文中关于此主题的指导。
|
||||
|
||||
##### 在拉取时验证
|
||||
|
||||
如果你从项目仓库的其它 fork 中拉取一个标签，git 将自动验证签名，并在合并操作时显示结果：
|
||||
```
|
||||
$ git pull [url] tags/sometag
|
||||
|
||||
```
|
||||
|
||||
合并信息将包含类似下面的内容：
|
||||
```
|
||||
Merge tag 'sometag' of [url]
|
||||
|
||||
[Tag message]
|
||||
|
||||
# gpg: Signature made [...]
|
||||
# gpg: Good signature from [...]
|
||||
|
||||
```
|
||||
|
||||
#### 配置 git 始终签名注释的标签
|
||||
|
||||
很可能的是，你正在创建一个带注释的标签，你应该去签名它。强制 git 始终签名带注释的标签，你可以设置一个全局配置选项：
|
||||
```
|
||||
$ git config --global tag.forceSignAnnotated true
|
||||
|
||||
```
|
||||
|
||||
或者，你始终记得每次都传递一个 -s 开关：
|
||||
```
|
||||
$ git tag -asm "Tag message" tagname
|
||||
|
||||
```
|
||||
|
||||
#### 如何使用签名提交
|
||||
|
||||
创建一个签名提交很容易，但是将它纳入到你的工作流中却很困难。许多项目使用签名提交作为一种 "Committed-by:” 的等价行，它记录了代码来源 —— 除了跟踪项目历史外，签名很少有人去验证。在某种意义上，签名的提交用于 ”篡改证据“，而不是 git 工作流的 ”篡改证明“。
|
||||
|
||||
为创建一个签名的提交，你只需要 `git commit` 命令传递一个 -S 标志即可（由于它与另一个标志冲突，所以改为大写的 -S）：
|
||||
```
|
||||
$ git commit -S
|
||||
|
||||
```
|
||||
|
||||
我们建议始终使用签名提交，并要求项目所有成员都这样做，这样其它人就可以验证它们（下面就讲到如何验证）。
|
||||
|
||||
##### 如何去验证签名的提交
|
||||
|
||||
验证签名的提交需要使用 verify-commit 命令：
|
||||
```
|
||||
$ git verify-commit [hash]
|
||||
|
||||
```
|
||||
|
||||
你也可以查看仓库日志，要求所有提交签名是被验证和显示的：
|
||||
```
|
||||
$ git log --pretty=short --show-signature
|
||||
|
||||
```
|
||||
|
||||
##### 在 git merge 时验证提交
|
||||
|
||||
如果项目的所有成员都签名了他们的提交，你可以在合并时强制进行签名检查（然后使用 -S 标志对合并操作本身进行签名）：
|
||||
```
|
||||
$ git merge --verify-signatures -S merged-branch
|
||||
|
||||
```
|
||||
|
||||
注意，如果有一个提交没有签名或验证失败，将导致合并操作失败。通常情况下，技术是最容易的部分 —— 而人的因素使得项目中很难采用严格的提交验证。
|
||||
|
||||
##### 如果你的项目在补丁管理上采用邮件列表
|
||||
|
||||
如果你的项目在提交和处理补丁时使用一个邮件列表，那么一般很少使用签名提交，因为通过那种方式发送时，签名信息将会丢失。对提交进行签名仍然是非常有用的，这样引用你托管在公开 git 树的其他人就能以它作为参考，但是上游项目接收你的补丁时，仍然不能直接使用 git 去验证它们。
|
||||
|
||||
尽管，你仍然可以签名包含补丁的电子邮件。
|
||||
|
||||
#### 配置 git 始终签名提交
|
||||
|
||||
你可以告诉 git 总是签名提交：
|
||||
```
|
||||
git config --global commit.gpgSign true
|
||||
|
||||
```
|
||||
|
||||
或者你每次都记得给 `git commit` 操作传递一个 -S 标志（包括 —amend）。
|
||||
|
||||
#### 配置 gpg-agent 选项
|
||||
|
||||
GnuPG agent 是一个守护工具，它能在你使用 gpg 命令时随时自动启动，并运行在后台来缓存私钥的密码。这种方式让你只需要解锁一次密钥就可以重复地使用它（如果你需要在一个自动脚本中签署一组 git 操作，而不需要重复输入密钥，这种方式就很方便）。
|
||||
|
||||
为了调整缓存中的密钥过期时间，你应该知道这两个选项：
|
||||
|
||||
* default-cache-ttl（秒）：如果在 time-to-live 过期之前再次使用同一个密钥，这个倒计时将重置成另一个倒计时周期。缺省值是 600（10 分钟）。
|
||||
|
||||
* max-cache-ttl（秒）：自首次密钥输入以后，不论最近一次使用密钥是什么时间，只要最大值的 time-to-live 倒计时过期，你将被要求再次输入密码。它的缺省值是 30 分钟。
|
||||
|
||||
|
||||
|
||||
|
||||
如果你认为这些缺省值过短（或过长），你可以编辑 ~/.gnupg/gpg-agent.conf 文件去设置你自己的值：
|
||||
```
|
||||
# set to 30 minutes for regular ttl, and 2 hours for max ttl
|
||||
default-cache-ttl 1800
|
||||
max-cache-ttl 7200
|
||||
|
||||
```
|
||||
|
||||
##### 额外好处：与 ssh 一起使用 gpg-agent
|
||||
|
||||
如果你创建了一个 [A]（验证）密钥，并将它移到了智能卡，你可以将它用到 ssh 上，为你的 ssh 会话添加一个双因子验证。为了与 agent 沟通你只需要告诉你的环境去使用正确的套接字文件即可。
|
||||
|
||||
首先，添加下列行到你的 ~/.gnupg/gpg-agent.conf 文件中：
|
||||
```
|
||||
enable-ssh-support
|
||||
|
||||
```
|
||||
|
||||
接着，添加下列行到你的 .bashrc 文件中：
|
||||
```
|
||||
export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)
|
||||
|
||||
```
|
||||
|
||||
为了让改变生效，你需要 kill 掉正在运行的 gpg-agent 进程，并重新启动一个新的登入会话：
|
||||
```
|
||||
$ killall gpg-agent
|
||||
$ bash
|
||||
$ ssh-add -L
|
||||
|
||||
```
|
||||
|
||||
最后的命令将列出代表你的 PGP Auth 密钥的 SSH（注释应该会在结束的位置显示： cardno:XXXXXXXX，表示它来自智能卡）。
|
||||
|
||||
为了启用 ssh 的基于密钥的登入，只需要在你要登入的远程系统上添加 `ssh-add -L` 的输出到 ~/.ssh/authorized_keys 中。祝贺你，这将使你的 SSH 登入凭据更难以窃取。
|
||||
|
||||
作为一个福利，你可以从公共密钥服务器上下载其它人的基于 PGP 的 ssh 公钥，这样就可以赋予他登入 ssh 的权利：
|
||||
```
|
||||
$ gpg --export-ssh-key [keyid]
|
||||
|
||||
```
|
||||
|
||||
如果你有让开发人员通过 ssh 来访问 git 仓库的需要，这将让你非常方便。下一篇文章，我们将提供像保护你的密钥那样保护电子邮件帐户的小技巧。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.linux.com/blog/learn/pgp/2018/3/protecting-code-integrity-pgp-part-6-using-pgp-git
|
||||
|
||||
作者：[KONSTANTIN RYABITSEV][a]
|
||||
译者：[qhwdw](https://github.com/qhwdw)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://www.linux.com/users/mricon
|
||||
[1]:https://www.linux.com/blog/learn/2018/2/protecting-code-integrity-pgp-part-1-basic-pgp-concepts-and-tools
|
||||
[2]:https://www.linux.com/blog/learn/pgp/2018/2/protecting-code-integrity-pgp-part-2-generating-and-protecting-your-master-pgp-key
|
||||
[3]:https://www.linux.com/blog/learn/pgp/2018/2/protecting-code-integrity-pgp-part-3-generating-pgp-subkeys
|
||||
[4]:https://www.linux.com/blog/learn/pgp/2018/3/protecting-code-integrity-pgp-part-4-moving-your-master-key-offline-storage
|
||||
[5]:https://www.linux.com/blog/learn/pgp/2018/3/protecting-code-integrity-pgp-part-5-moving-subkeys-hardware-device
|
||||
[6]:https://github.com/jayphelps/git-blame-someone-else
|
||||
Loading…
Reference in New Issue
Block a user