likelylee 最近的时间轴更新 likelylee 最近的时间轴更新 |
likelyleeV2EX 第 405920 号会员，加入于 2019-04-25 10:00:41 +08:00今日活跃度排名 9201 |
likelylee 最近回复了
2025 年 12 月 29 日 回复了 usingkk 创建的主题 › MacBook Pro › Linux 十年用户，我的需求是否适合购买 Macbook? |
没有明确爱国需求的话也可以考虑 dell 的笔记本，对 linux 的支持很好，我之前的 22 年 inspiron 14p 一直在用 arch ，没有任何驱动之类的问题，并且还有一定的扩展性。唯一问题就是至少直到 22 年为止的 win/linux 笔记本，电池都做不到正常使用 4 个小时以上。所以如果里的需求是电池，那么没的选就上 mac 吧。
不过我干杂活，写代码但不多，现在 m 系列的 mac 本地使用 clang ，如果使自己写的代码还好，如果是用别人的代码，要注意 clang 和 gcc 的一些细微区别，或者单独安装配置 gcc ，这个挺烦的。
至于终端，我用 warp ，好多时候忘了的命令或者懒得搜的时候就直接在终端里问了，它也能直接写好命令让你确认，比较省心，类似预装的 gemini cli 吧。只是现在免费额度越来越少。
最近刚从 dell 的换到便宜的 M4 air ，十年前用过十年的 mac ，实话说界面什么的变化虽然大，架构也从 x86 变成了 arm ，但是体验基本和之前是一样的，不像 arch 能调整的非常跟手，但也没有 windows 那么耗资源。
不过我干杂活，写代码但不多，现在 m 系列的 mac 本地使用 clang ，如果使自己写的代码还好，如果是用别人的代码，要注意 clang 和 gcc 的一些细微区别，或者单独安装配置 gcc ，这个挺烦的。
至于终端，我用 warp ，好多时候忘了的命令或者懒得搜的时候就直接在终端里问了，它也能直接写好命令让你确认，比较省心，类似预装的 gemini cli 吧。只是现在免费额度越来越少。
最近刚从 dell 的换到便宜的 M4 air ，十年前用过十年的 mac ，实话说界面什么的变化虽然大，架构也从 x86 变成了 arm ，但是体验基本和之前是一样的，不像 arch 能调整的非常跟手，但也没有 windows 那么耗资源。
2025 年 12 月 21 日 回复了 shendaowu 创建的主题 › 信息安全 › 我写的 Restic 备份脚本，求好心的大中小佬免费给审查一下代码，不到一百行， PowerShell 写的 |
可以考虑用 resticprofile ，直接在配置文件里指定 schedule 就可以了，我本地已经稳定运行两三年了。
2025 年 12 月 10 日 回复了 hahawode 创建的主题 › Windows › Windows 平台下类 Spotlight 快速启动工具 |
如果你需要在打开窗口的快速文件夹跳转，尝试 listary 或者 flowlauncher
如果你需要插件生态，尝试 flowlauncher 或者 raycast beta
如果希望和 mac 平台统一，那就 raycast
如果不想装第三方，那就 powertoys 自带的 command palette
如果不喜欢 alt+space 打开，那就 listary ，可以双击 ctrl
其他的相比上边基本没有显著特点了。
如果你需要插件生态，尝试 flowlauncher 或者 raycast beta
如果希望和 mac 平台统一，那就 raycast
如果不想装第三方，那就 powertoys 自带的 command palette
如果不喜欢 alt+space 打开，那就 listary ，可以双击 ctrl
其他的相比上边基本没有显著特点了。
2025 年 11 月 18 日 回复了 LittFlower 创建的主题 › 程序员 › 2025 年求推荐 mac 远控 Linux 桌面方案 |
rustdesk 在 wayland 环境下不能无人值守。比较可行的做法，要么是直接端口转发直接 rdp 客户端连接到 krdp ，要么是通过 tailscale 或者 zerotier 等虚拟组网，或者 vpn 回去之后 rdp 连接。krdp 我没深度使用过，但是 gnome wayland 下的 rdp 服务器是可用的，但也仅仅是可用而已。如果实在有非常高的远程桌面的需求，目前建议还是上 x11 。
所以我现在的解法是 windows 机器加移动硬盘 vtoyboot 到 linux 环境...
所以我现在的解法是 windows 机器加移动硬盘 vtoyboot 到 linux 环境...
2025 年 9 月 8 日 回复了 marcosteam 创建的主题 › NAS › 截止发帖时，最好的 6 盘位以上 NAS 系统方案是不是 Unraid 底层+飞牛应用层？ |
从疫情元年到现在我用 unraid 已经 5 年多了，除了 smb 速度是个最大的问题，其他方面我还没有遇到过问题。网络部分我用 r5s 独立了主路由+翻墙之类的功能，除此以外 30 多个 docker 和 2 个虚拟机都是架在 unraid 上，硬盘没做 raid 因为比较乱，一个 4T 的 nvme 做 cache ，一个 12T 做主存储，一个 4T 和一个 2T 做备份，通过 user script 把主存储上的重要数据定期 rsync 过去，平时都是停转状态。
飞牛之类的之前试过，但是他的功能都能有 docker 替代，因此没有长期去用。不过如果都考虑用飞牛了，直接底层 pve 就得了没必要上 unraid 。我没上 pve 的主要原因就是 unraid 买的早...
飞牛之类的之前试过，但是他的功能都能有 docker 替代，因此没有长期去用。不过如果都考虑用飞牛了，直接底层 pve 就得了没必要上 unraid 。我没上 pve 的主要原因就是 unraid 买的早...
2025 年 9 月 3 日 回复了 liuidetmks 创建的主题 › 信息安全 › X 虽然是端到端消息，但是密码只有四个数字？ |
im 类的端到端加密，请搜索 gpg 的 email 实现机制，或者 smime 的实现，都是类似的。
简单的逻辑，个人到个人的场景下各自交换公钥，通过公私钥协商会话密钥，会话密钥加密消息体。群组消息的话，首先随便一方生成对称密钥，使用组内所有人的公钥分别加密对称密钥放在消息头，每个人拿到后用自有私钥解密，然后解密消息。
群组这个思路是相当早年看到的，不保真现在 gpg 是不是还这么干。
至于你说的 4 位数字，我没用过 x 的 app...确定不是身份验证用的？也有概率是用来派生对称密钥然后解密私钥。
简单的逻辑，个人到个人的场景下各自交换公钥，通过公私钥协商会话密钥，会话密钥加密消息体。群组消息的话，首先随便一方生成对称密钥，使用组内所有人的公钥分别加密对称密钥放在消息头，每个人拿到后用自有私钥解密，然后解密消息。
群组这个思路是相当早年看到的，不保真现在 gpg 是不是还这么干。
至于你说的 4 位数字，我没用过 x 的 app...确定不是身份验证用的？也有概率是用来派生对称密钥然后解密私钥。
2025 年 7 月 15 日 回复了 couture 创建的主题 › Android › 安卓有没有好用的邮箱软件，各位大佬推荐一下 |
我们办公要求用 thunderbird ，但是手机端我装的是 canary ，自带 gpg 工具，不需要像 thunderbird 额外装 openkeychain 。而且总体颜值比大部分邮箱类软件要高，除了付费......我是早年的付费用户，当时非常便宜，现在似乎贵了不少。
2025 年 7 月 13 日 回复了 WngShhng 创建的主题 › 程序员 › 少数派发了一篇文章，偶遇“大神” fastQ |
@WngShhng 你看啊，如果你不考虑认证要求，不考虑最佳实践，那你的应用不论你想怎么实现都可以。现在的问题不是你想让大家认可你这个 RSA 的实现，那对不起至少我不太认可。
如果你的出发点是 android 的安全性，可以考虑调用 TEE 去做密钥相关处理，这也是最佳实践的做法。如果你连 TEE 的安全性都存疑，可以考虑不支持 android 只做 iOS 。但是不论如何，你希望说明你的 RSA 服务器实现的安全性高于 TEE ，那至少你得从各方面都给出来做够的说服力，而不是仅仅重复“Android 本身并不安全”，因为国内几个手机的 CC MDFPP 认证也是我做的。
自己实现一套机制没问题，我也经常会帮客户想一些奇怪的思路，比如白盒加密之类，但是不代表这些方式是足够安全的，只是在接受了某些风险的场景下可用。对于你现在的应用场景，是不是你得先想明白到底需要应对什么风险或者安全问题，然后才去看你的实现机制是不是足够的？
如果你的出发点是 android 的安全性，可以考虑调用 TEE 去做密钥相关处理，这也是最佳实践的做法。如果你连 TEE 的安全性都存疑，可以考虑不支持 android 只做 iOS 。但是不论如何，你希望说明你的 RSA 服务器实现的安全性高于 TEE ，那至少你得从各方面都给出来做够的说服力，而不是仅仅重复“Android 本身并不安全”，因为国内几个手机的 CC MDFPP 认证也是我做的。
自己实现一套机制没问题，我也经常会帮客户想一些奇怪的思路，比如白盒加密之类，但是不代表这些方式是足够安全的，只是在接受了某些风险的场景下可用。对于你现在的应用场景，是不是你得先想明白到底需要应对什么风险或者安全问题，然后才去看你的实现机制是不是足够的？
2025 年 7 月 13 日 回复了 WngShhng 创建的主题 › 程序员 › 少数派发了一篇文章，偶遇“大神” fastQ |
@WngShhng 想突出端到端就不要加服务器，忘了就忘了，或者参考 bitlocker 提供离线的恢复密码的助记码之类的方式。如果一定要做 RSA 且服务器保存，那么至少参考上边几楼的说法，做好身份认证之类的事情，比如额外引入 CA......
2025 年 7 月 13 日 回复了 WngShhng 创建的主题 › 程序员 › 少数派发了一篇文章，偶遇“大神” fastQ |
怎么说呢，我先摆资历来增加说服力，国内的 FIPS140-2/3 认证，基本都是我做的。如果有做过认证的或者关心过认证的，应该就知道我是谁。
当然你的产品不做认证前提下，随便怎么开发都没问题，但是如果你希望哪怕参考一点所谓的“最佳实践”，你就会发现那个“大神”说的大差不差。语气问题可能以下我也有，见谅。
端到端加密没有一个准确的定义，但是按照常规的实现思路来说，“没有第三人持有任何可用于解密的材料”这个应该是共识，那么按照你现在的做法引入一个 RSA 公私钥做加密，私钥在你的服务器侧用作密码恢复，先不提所谓的算法安全强度的事情，至少你说端到端这个就不准确了。这里不讨论 RSA 用于加密的一堆要求，也不讨论怎么身份认证的事情，就单纯存在一个中心点可能会解密密码这个场景，作为明确有端到端需求的人可能就不选了。
其他的问题，诸如 KDF 密钥派生算法，常规的方式都是考虑把密码作为 PBKDF2 的输入，提高 iteration 次数到 10000 以上，然后用派生出来的密钥作为 AES 密钥使用。AES 的 IV 要看使用场景来判断长度和生成方式，通常来说至少是随机数 96 bits 以上。在做到这些之后，你怎么做拼接 base64 之类的都无所谓。
我们都能理解不要自创算法的重要性，但同时正确使用算法，正确的组合算法也相当重要。
当然你的产品不做认证前提下，随便怎么开发都没问题，但是如果你希望哪怕参考一点所谓的“最佳实践”，你就会发现那个“大神”说的大差不差。语气问题可能以下我也有，见谅。
端到端加密没有一个准确的定义，但是按照常规的实现思路来说，“没有第三人持有任何可用于解密的材料”这个应该是共识，那么按照你现在的做法引入一个 RSA 公私钥做加密，私钥在你的服务器侧用作密码恢复，先不提所谓的算法安全强度的事情，至少你说端到端这个就不准确了。这里不讨论 RSA 用于加密的一堆要求，也不讨论怎么身份认证的事情，就单纯存在一个中心点可能会解密密码这个场景，作为明确有端到端需求的人可能就不选了。
其他的问题，诸如 KDF 密钥派生算法，常规的方式都是考虑把密码作为 PBKDF2 的输入，提高 iteration 次数到 10000 以上，然后用派生出来的密钥作为 AES 密钥使用。AES 的 IV 要看使用场景来判断长度和生成方式，通常来说至少是随机数 96 bits 以上。在做到这些之后，你怎么做拼接 base64 之类的都无所谓。
我们都能理解不要自创算法的重要性，但同时正确使用算法，正确的组合算法也相当重要。
Select Language