@nerkeler #23

> 具体安全性可以有你自己的算法把控

这就非常贴近我在 #3 发的链接里提到的 "roll your own crypto"，属于密码学家们强烈不建议的。

> 举个简单例子，我现在要生成一个密码，我的原始数据是 88888888 ，我现在要把这个数据 md5 后 base64 ，重复 10 遍得出密码，这个密码你感觉容易破解吗

这就是我在 #20 说你的思路是弱化版的 KDF 的原因，或者你可以先了解一下这个词，再点进 #20 的链接看一下 slow KDFs 为什么没有增加弱密码的安全性。

> 这个加密过程如果你不告诉第二个人，我相信是没人知道的。

这就是我在 #3 发的链接里提到的 obscurity ，可以再认真看一遍为什么它在你的场景中提供的是虚假的安全性。

我不打算与你继续讨论了，因为我觉得你不但很主观，而且在讨论时的语气还很差。

@nerkeler #12

强烈建议你阅读 #3 的两个链接，说明一下你是怎么规避这两个问题的回复里提到的那些弊端的。

> 加密等级高很容易实现

完全不赞同，从你记住的信息到实际使用的密码之间的过程类似于弱化版（因为你描述的方案并不如 slow KDFs 那样 slow ）的 KDF 、Key stretching ，这增加不了多少安全性 https://crypto.stackexchange.com/questions/1662

所以这个过程你不公开就是 #3 提到的 obscurity ，公开就可以认为安全性与你容易记住的信息一致 （ bits of entropy ）。

至于容易记住的密码，有 passphrase ，容易记住且安全的密码，有 diceware passphrase 和 EFF word list https://www.eff.org/dice

> 这个文件

什么文件？所以需要推算密码的时候需要先保证文件的完整性吗？怎么保证？

> 属于自己的加密方案

https://stackoverflow.com/questions/533965

> 加密等级又很高

https://security.stackexchange.com/questions/168261

/t/1041354

> 各个镜像加速站，基本都是站点方尽可能提供全面的“资源”

以前看到本站宣传的一些源是用户请求了对应包才去请求上游并缓存

> 大厂提供的还好，小厂提供的安全性其实很难有保障，存在一个信任问题

我不赞同前半句，但赞同后半句，但是你的方案并没有提出怎么解决这个信任问题。

一般都包含一些机制，我认为这个问题没办法也不应该由镜像服务提供方来解决：

- /t/1048042
- https://sum.golang.org/
- https://docs.npmjs.com/about-registry-signatures

我的看法：不存在也不该存在信任问题，存在的话说明上游设计有漏洞，人们就完全不应该用镜像源 （例如动态的 polyfill https://ex.noerr.eu.org/t/1056428#r_14978775 ）；其实只是政策和成本问题，或者说成本也不是问题： https://ex.noerr.eu.org/t/1002435#r_14106496

常用的加入 git alias 更方便

git config --global alias.foo '!git config user.name Name && git config user.email [email protected]'

git foo

你可以在源码里搜 puppeteerGet ，用到的就需要浏览器

> 私人库：这里面的文件将会被加密存储，即使有人知道了您存储文件的 CID 获取了文件也无法解密读取

客户端开源吗？不开源的话你有别的让人信任的因素吗？是本地加密吗？未加密的数据会离开客户端吗？密钥是仅本地的吗？你们能解密吗？

> 资金足以支持服务器运行 100 年以上都没问题，…，以及对冲掉币价波动的费用

暴跌怎么办？

OP 多少岁啊？这个手术和恢复一共需要持续多久？

zed 最近火了好几次，正面负面都有。所以对于想尝试 zed 但又比较在意安全的人，仅作提醒：

https://github.com/zed-industries/zed/issues/7054#issuecomment-1916315391

https://github.com/zed-industries/zed/pull/14034

@yuzo555 #7 “获取管理员权限”后，你可以认为它能做任何坏事。此外这个问题其实讨论过， 本来就是为了 MITM 。

/t/879778
/t/1036217

1. 是
2. 可能会有区别，但不会破坏 1 ，例如 RFC 8470
3. 前提一定是客户端是安全的，服务器是安全的，证书是安全的。那么考虑的只是会不会被例如 POODLE attack 影响，那只要工具实现是安全的，服务端正确配置了，就不需要担心。

我实在不赞同供应链安全这种国内外都很火的技术话题被水深火热 @Livid

https://www.google.com/search?q=polyfill+site%3Anews.ycombinator.com

https://www.google.com/search?q=xz+utils+site%3Anews.ycombinator.com