每天都莫名其妙的在了解一些和主业毫不相关的知识，哈哈哈
今天不知道怎么的就突然对GitHub的Pull Requests有点好奇，就了解了一下，也提出了第一个PR请求，就学了下PR是什么；然后突然很好奇passkey是什么东西，就去了解了一下。
对于Passkey的一些了解
我第一次听到passkey这个词还是在iOS 16的发布会上听到的，2022年的WWDC上，苹果当时说apple设备将支持passkey，实现一个无密码登陆。听起来挺方便的，但是还是挺好奇是怎么做到的。不过其实直到iOS16正式版发布了，我也没有体验一下无密码登陆是怎么样的，感觉这个体验就很糟糕，生态不行。
最近发现很多网站，包括什么cloudflare，GitHub，npmjs都开始支持passkey登陆了，点击passkey登陆，电脑上手机上就弹出一个原生的Touch ID/Face ID验证界面，然后扫一下指纹/面容就能直接登陆了，感觉好神奇，也确实很方便，最重要的是他根本不需要mfa验证了，真的太方便了（实际上passkey也可以作为mfa方式）。
当然，passkey是需要登陆账号后在支持的设备上进行设置的，设置好后，就可以在你设置passkey的这台设备上进行无密码登陆了。如果你启用了iCloud钥匙串，你可以在你的所有iOS设备之间享受无密码登陆，真的很方便。
但是我在设置和验证passkey的时候发现了一个问题：很多网站设置验证passkey的选项，不叫passkey，而是叫物理安全密钥或者Physical Security Keys。导致我第一次的时候以为是那种加密狗，不是passkey的设置。
比如Microsoft的这个验证界面就是，可以扫描二维码也可以用下面的物理安全密钥，甚至是设置安全密钥的时候，点的也是USB设备，添加了也是FIDO安全设备，哈哈哈
我不禁好奇起来：是不是passkey就是那种USB加密狗（物理安全密钥）的一种，只不过是他的数字实现，实现了跨平台和统一标准？
然后就去了解了一下，好像大概就是这样的，确实是一种物理安全密钥的数字实现。
对于passkey自己的理解
在实现方式上，Passkey实际上就是物理安全密钥的另一种数字实现，都采用了公钥密码学，采用一对公私钥实现了用户的身份证明。
他们保护的信息都是私钥（我的理解里，私钥就是钥匙，公钥是生成的一把锁，只有私钥才能解开公钥加密的东西），不过他们的保护方式略有不同：
- 物理安全密钥是通过他的物理性质来进行保护的，物理的加密狗里存储着私钥，需要物理接触，不易传播，也不好复制，所以造就了物理安全密钥的安全性。
- 但是这种物理密钥也造成了用户的不方便，不方便多设备同步和密钥共享，不过还是很安全的。
但是Passkey既然是物理安全密钥的另一种数字实现，也保护着最重要的私钥，确保私钥安全的方式是设备端安全系统和生物识别等。
比如几乎所有手机的Soc和Apple silicon的Mac内都有“安全隔区”，Windows 11 PC要求的TPM2.0，intel-based Mac中的Apple T2安全芯片等，通过设备上的生物识别来进行授权使用。包括苹果的iCloud钥匙串，号称是使用了e2ee(End-to-End Encryption)端对端加密来实现的。
- 所以passkey的这种数字实现，就相当于是设备变成了一个大的安全密钥。通过设备上的生物识别进行实现。
看起来好像就是一个简单的传统物理密钥的更新这么简单吧，但是其实这个也是一个挺厉害的技术吧，确实带来了方便，不过方便的同时也会带来一些挑战。
不只是数字化实现那么简单，还有统一的标准
除了上面说的这些，这俩的区别其实还是有一些的。比如，Passkey是基于FIDO/WebAuthn标准的方案，所以带来了跨平台的优点，兼容性优秀，可以降低用户方便使用的成本。
这方面我其实是真的不怎么了解，都是很浅层的。不过我的理解就是，因为passkey是基于FIDO/WebAuthn标准的数字化实现，那么就可以融合统一标准的跨平台性和数字化的跨设备性，更加方便用户使用。
例如，若不支持统一标准，用户在A设备的浏览器上设置了一个密钥，但是由于是不兼容统一公开标准的，可能在B设备上的浏览器就不能使用，甚至是A设备上的另一个浏览器也无法使用。这就是统一标准的好处吧？
因为标准被广泛认可使用，所以几乎所有的浏览器、设备都支持这样的认证方式，所以只要一处设置，处处均可使用，无论什么设备、哪一台设备，浏览器/App/OS等都能支持这一套认证协议，从而带来了便利。
总结
- passkey是一种安全的基于公私钥密码学的登录方式，遵循常见公开标准，可以实现安全快捷的身份验证
- passkey的数字化属性可以轻松实现多设备同步、共享等操作
- passkey使用生物识别进行私钥的授权使用，快捷且相对安全
感觉passkey相对于物理安全密钥的优点都是数字化带给他的（估计是我知识太浅薄）
GitHub的Pull Requests
初中那会儿就很好奇，我每天用GitHub下载代理软件，都只会直奔releases，一直很好奇上面的那个issues和pull requests都是什么人才能点进去的。现在长大了，知道了issues是用户或者相同的开发者可以给仓库提建议和问题的入口，但是一直不知道这个pull requests是什么意思。
现在我终于知道了，Git本来就是用于多人协作完成代码编写的，Pull requests就是当我们想要修改仓库中的代码，就向作者发出一个pull requests请求，作者可以选择合并到代码中。
我的理解
我们平时提交代码到我们自己的仓库中一般是需要commit & push的，把本地的代码push到我们的远程仓库去。相反，从远程仓库获取代码到我们本地则是pull。所以在pull requests这个行为中，代码的修改者就相当于是远程仓库的存在，然后代码仓库的原作者就相当于是本地仓库。我们希望我们的代码加入到仓库原作者的代码中，所以我们就发出了一个请求，请仓库原作者将我们写的代码pull到他的仓库中，并进行merge合并。
我觉得我的这个理解并没什么问题吧，应该至少大概是对的，没有什么错误的存在。
了解pr重要的就是他的使用方法吧，我大概了解了一下
Pull requests的使用方法
- 先去把原作者的仓库fork了，这样就会在你的账户下生成一个一模一样的仓库
- 然后去把自己账户下的那个fork的仓库clone到本地去
- 最好还是创建一个新的分支，方便进行工作，可以用
git checkout -b <newbranchname>实现 - 在新创建的这个分支进行代码的修改，完成后直接git commit -m "your changes"即可，然后直接push到我们自己的仓库即可
- 这时候我们就可以转到GitHub上的网页，打开原作者的仓库，切换到Pull requests这个界面，就会有一个提示，我们直接进行pr请求即可
Note: 创建了PR后，作者也需要时间去审核，来决定是否merge我们修改的代码，所以打开你的PR页面后，有❌是正常的
其实GitHub上还有一种更简便的pr的方式，就是在原仓库找到代码文件，然后点击右边的笔就可以了，GitHub会帮你fork这个仓库，然后帮你创建一个新的分支。我们在IDE中只需要去checkout到这个分支就可以了。完成后一样我们正常commit & push到我们自己的仓库中即可，最后在原仓库的网页中创建一个pr请求即可。
我是六六，主页
知识还是太少，难免会有很多错误，欢迎大家交流、批评指正！
本文由 六六 创作，采用 知识共享署名4.0 国际许可协议进行许可。
本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名。