git-crypt 加密 远程仓库

c 复制代码
gpg采用的是非对称加密方式,简单理解就是用公钥加密文件,用私钥解密文件。
如果你需要发送加密信息,首先获取接收者的公钥,然后利用该公钥加密后传递,对方利用对应的私钥就可解密。
也就是说,公钥是锁,私钥是钥匙。
非对称加密方式很好地解决了传递信息的问题。 

你的理解大体是正确的,尤其是关于 GPG 的非对称加密 工作方式。不过,对于 git-crypt 的具体实现和如何加密仓库中的文件,需要稍微调整一下细节。

非对称加密的核心概念:

  • 公钥加密,私钥解密 :你所描述的流程基本上是正确的------公钥用于加密,私钥用于解密。这是非对称加密的核心原则。每个用户都有一个唯一的公钥和私钥对,公钥可以公开,私钥必须保密。
    • 公钥是锁,可以用来加密数据。
    • 私钥是钥匙,用来解密通过对应公钥加密的数据。

git-crypt 的具体实现方式:

与标准的 GPG 加密方式稍有不同,git-crypt 使用 混合加密 ,结合了 对称加密非对称加密 。这意味着,git-crypt 并不是对每个文件分别使用 GPG 公钥进行加密,而是使用 GPG 公钥加密对称密钥,再用这个对称密钥加密文件内容。

工作流程简述:
  1. 对称密钥加密文件git-crypt 使用对称加密算法(如 AES-256)加密文件。所有需要加密的文件都使用同一个对称密钥进行加密。
  2. 公钥加密对称密钥 :为了确保不同用户能够解密这些文件,git-crypt 使用每个用户的 GPG 公钥 加密这个对称密钥。每个用户的公钥加密后的密钥都存储在 .git-crypt/keys/default 文件中。
  3. 解密文件的过程 :当某个用户想要解密文件时,git-crypt unlock 会使用该用户的 GPG 私钥 来解密对应的对称密钥。然后使用该对称密钥来解密仓库中的文件。
c 复制代码
 1721  git init 
 1722  vi .gitattributes
 1723  git add .gitattributes  # 此时是没加密的
 1724  git commit -m add.gitattributes
 1725  gpg --full-generate-key
 1727  git-crypt init
 1728  git-crypt add-gpg-user user_name # 这是一次commit # 这个是git add 是否加密的分界线 
 1729  git status . 
 1738  touch test.md 
 1740  git add test.md   # 此时 添加 "加密后的 test.md" 到 缓存区
 1741  git commit -m "add file" # 此时 添加 "加密后的 test.md" 到 本地版本库
 1742  git-crypt status 
 1746  git remote add origin git@gitee.com:user_name/crypt.git
 1747  git push -u origin "master" # 此时 将所有的commit 推送到 远程版本库

git-crypt unlock
git add <文件名>
git commit -m "添加加密提交"
git-crypt status


commit 287cfc30faf6b188f06bd60435a40fdd27d008d4 (HEAD -> master, origin/master)
Author: user_name <user_email@foxmail.com>
Date:   Tue Oct 8 16:21:55 2024 +0800

    add file

commit a4471b34b2555d30330fd75ee50cbedf7ca82efa
Author: user_name <user_email@foxmail.com>
Date:   Tue Oct 8 16:20:29 2024 +0800

    Add 1 git-crypt collaborator
    
    New collaborators:
    
            7BB69A62 user_name <user_email@foxmail.com>

commit 2a0bc5729f5e48163ecc58f8652c976c4d967f25
Author: user_name <user_email@foxmail.com>
Date:   Tue Oct 8 16:19:08 2024 +0800

    add.gitattributes


git clone git@gitee.com:user_name/crypt.git  crypt3

git-crypt  unlock 


git-crypt export-key


$ git-crypt export-key  xxx.key 
$ file xxx.key 
xxx.key: data
c 复制代码
git add .gitattributes
将 .gitattributes 文件添加到 Git 暂存区,标识需要加密的文件类型。
git commit -m add.gitattributes
提交对 .gitattributes 的更改。

// 以上只会影响 git add , unlock ,lock 操作时 加密哪些文件 , 是否加密该文件

gpg --full-generate-key
生成一对 GPG 密钥(私钥和公钥)。
私钥:存储在本地 GPG 密钥环中,路径通常为 ~/.gnupg/private-keys-v1.d/。
公钥:也存储在本地,路径为 ~/.gnupg/pubring.kbx。

git-crypt init
初始化 Git-crypt,并生成对称密钥 K, 生成K 到内存里
// 创建新用户公钥, 怎么保证是同一个密钥K
// 解密现有的 KA ,得到 K

git-crypt add-gpg-user user_name
将指定用户的公钥添加到 Git 仓库的加密设置中。
KA:用公钥 A 加密后的对称密钥 K,将其存储在 .git-crypt/keys/default/ 下。

1. 第 1740 步:git add test.md 是将文件加密并添加到暂存区

  • 在第 1740 步,当你执行 git add test.md 时,git-crypt 会根据你在 .gitattributes 中的配置,将 test.md 文件加密并添加到 Git 的暂存区。
  • 暂存区(staging area) 中的 test.md 文件已经被加密,但你的 工作区(working directory) 中的文件仍然是明文。

2. 第 1743 步:git-crypt lock 是将工作区中的文件加密

  • 在第 1743 步,执行 git-crypt lock 后,git-crypt 会将你的 工作区 中的文件加密。也就是说,工作区中的 test.md 文件会从明文变为密文形式。
  • 这一步不会影响已经提交的文件,它只会加密当前工作区中的明文文件。

操作回顾:

  • 1740: git add test.md :将文件 test.md 加密并添加到 Git 的暂存区。加密是基于 .gitattributes 中的规则完成的,确保文件提交时是加密的。
  • 1743: git-crypt lock :将工作区中的文件(如 test.md)从明文加密为密文。这一步主要是防止其他人通过直接访问你的文件系统读取明文文件内容。

注意 : 暂存区和版本库里面的总是加密的 , unlock 和 lock 只是影响工作区的加解密

总结:

  • 1740 是将文件加密并添加到 暂存区
  • 1743 是将文件在 工作区 中加密,使文件在工作区也变成密文。
c 复制代码
公钥A加密 对称密钥K , 加密后的对称密钥 KA 储到 .git-crypt/keys/default/ 下的文件, 即 (每个公钥有一份.git-crypt/keys/default/ 下的文件)
对称密钥K 加密 源数据 ,存储到源数据同名文件,即(对称密钥K加密后的源文件)

在这个过程中, 两个用户
不同的东西
    1. 公钥A
    2. 加密后的对称密钥 KA(.git-crypt/keys/default/下的文件 )
相同的东西
    1. 对称密钥K
    2. 对称密钥K加密后的源文件



clone 仓库时(每个人clone出的仓库是相同的)
    下载所有的 KA .git-crypt/keys/default/中的文件 到本地 , 里面有 <用户名,KA> 信息
    下载 对称密钥K加密后的源文件 到 本地(工作区)
	// 此时需要unlock 工作区
unlock 时
    用 私钥a 解密 .git-crypt/keys/default/* 中 该用户对应的 KA 文件, 然后得到 K
    用 K 解密 对称密钥K加密后的源文件 , 得到源文件


管理员不管丢没丢私钥,它总是可以解码的

正确的部分:

  1. 不同的东西
    • 公钥A:每个用户都有自己唯一的公钥。
    • 加密后的对称密钥 KA :每个用户的 .git-crypt/keys/default/ 文件中包含由他们的公钥加密的对称密钥 K 的版本(KA)。
  2. 相同的东西
    • 对称密钥 K:所有用户解锁后得到的对称密钥是相同的。
    • 对称密钥 K 加密后的源文件:这些文件是通过相同的对称密钥 K 加密的,因此内容是相同的。

克隆仓库时:

  • 每个人克隆出的仓库确实是相同的,包含以下内容:
    • 所有的 KA.git-crypt/keys/default/* 中存储了所有用户的加密对称密钥(KA),这个文件是共享的。
    • 对称密钥 K 加密后的源文件:这些文件是存储在仓库中的,所有用户下载时都能获得相同的文件。

解锁时:

  • 解锁过程
    • 用户用自己的 私钥 解密 .git-crypt/keys/default/* 中与其公钥对应的 KA 文件,得到 对称密钥 K
    • 然后,用户使用这个 K 来解密那些由 K 加密的源文件,得到原始文件。
c 复制代码
解密只需要私钥,和账户没有关系

gpg --import /path/to/your/private.key
git-crypt unlock
如果你的私钥被加密,可能会提示你输入密码以解锁该私钥。
相关推荐
丁总学Java7 分钟前
git branch -r(--remotes )显示你本地仓库知道的所有 远程分支 的列表
git
yylの博客3 小时前
Windows通过git-bash安装zsh
windows·git·bash·zsh
丁总学Java4 小时前
(Z Shell)zsh: no matches found: ? 使用单引号包裹
git·zsh
萌狼蓝天4 小时前
【NAS】绿联NAS+极狐Gitlab+1Panel
git
deja vu水中芭蕾9 小时前
git push origin HEAD:refs/for/分支名
git
海岛日记13 小时前
git常用操作
git
喝鸡汤13 小时前
一起学Git【番外篇:如何在Git中新建文件】
git
“αβ”13 小时前
Windows下使用git配置gitee远程仓库
git
谢家小布柔18 小时前
Git图形界面以及idea中集合Git使用
java·git
winner888120 小时前
git merge 冲突 解决 show case
java·git·git merge·git冲突