那你既不愿意安装二进制的包，又不愿意装编译器从源码来编译，还能怎么办？

LTSC 没有这个 feedback

检查有没有循环引用数据结构的问题。

@v2lhr
1 、开源是信任的基础，没有这个基础就不存在任何信任。没有信任确大谈安全是无意义的。

2 、我指的是密码管理器可以为被管理密码的网站的两步验证提供支持。
（比如 Apple 的两步验证，需要输入的那个 6 位按照时间变动的验证码）

3 、KeePass 的抗穷举是以拿到加密后数据为前提的。
抗穷举的实质是加大穷举出正确密钥的难度，KeePass 使用了 AES-KDF 或者 Argon2 来提高穷举密码的代价以降低穷举速度。
简单的说直线思维上：
AES( 密码 , 加密数据 ) = 结果
而使用 AES-KDF 会变成
AES( AES-KDF( 盐, 密码, 迭代次数 ) , 加密数据 ) = 结果
由于 KDF 的运算代价，在固定的硬件上可能需要近似的时间才能确定密钥是否正确，如果迭代的次数足够多那么你确定密钥正确的速度就会非常慢。
最终从效果来说，可能同一台机器上使用了 KDF 只能做到每秒穷举 1 个密码，而不带 KDF 则可以每秒穷举成千上万个密码。

4 、对于小程序，微信实质上就是操作系统。
如果对我 Windows 不放心，我还可以选择 MacOS，对 MacOS 不放心我还可以选择 Linux 等等等，而用你这个小程序，从头到尾都只能选择微信。
另外还有信任链的问题，信任链越长对信任的难度就越高。
要信任你的小程序需要同时信任底层的操作系统+微信，如果你不信任 Windows，那么在 Windows 上运行的微信同样也没有信任的基础。

5-6 、这些问题是一开始你就应该说明的，也许说明清楚有些人的看法会有所不同。

看来楼主还是不明白。

对于密码管理器这种东西，安全体现在 2 个维度上。
1 、数据的保密性
1.1 对于数据的保密性，仅有楼主自称采用了什么算法来保证，并没有任何的证明。
只贴个加密库的开源地址是没办法说明任何问题的。
1.2 对这类产品用户同样需要信任开发者
以目前的言行来看谈不上对开发者的信任。
1.3 对操作环境的信任
就跟大家都知道不应该在不信任的环境下输入密码一样。
微信对于公众来说是黑盒无法指定它内部是怎么样实现并且会做什么，而你的程序完全依赖于微信这个黑盒。
大家的回帖已经充分说明了，显然对于注重安全的群体来说是无法信任的。

2 、数据的储存的可靠性
基于数据是加密保存的前提下，数据储存的可靠是另一个问题。

微信云提供的免费空间始终是免费提供给你的，这种免费服务是随时可以取消，不应该把数据的唯一希望寄托于这种免费的服务。
另外有人问微信封号怎么办？你只回答要正确使用微信。绝大多数人都是没办法接受这种答案的，因为封号不封号是不可控的，应该也不会有人愿意以限制自己为条件来使用这个可替代的产品。

一直纠结究竟是国内还是国外的服务可信是没有意义的，因为任何非自己物理上可控制的设备都不可以彻底的信任，这才是数据必须加密储存的原因。
此外还要要预防数据丢失的问题，任何单一的储存介质都是不可信任的，这是基本原则。数据储存在微信云虽然腾讯保证数据的可用性，但是仍然是不应该信任的。数据能否自己导出这个问题楼主你自己并没有说明，就算可以，用户依然无法不依赖于微信来使用，这是个很大的问题。



最后，无论楼主的产品怎么样，被人拿来和其他产品比较是不可避免的。
对比我使用的 KeePass 来看：
KeePass 开源。楼主的程序没有开源。
KeePass 针对各种两步验证提供了解决方案（比如：TOTP ）。楼主的产品对此毫无说明。
KeePass 针对对密码管理器的各种攻击做了足够多的措施（比如：对抗密码穷举）。楼主的产品对此毫无说明。
KeePass 本身只依赖于操作系统，并且在多种操作系统上都有对其协议的实现。楼主的产品必须依赖于微信。
KeePass 的数据可以多地保存（无论是各种云产品还是存在本地的物理介质上），楼主的程序并没有说明这个问题。
所以说对比各类竞品楼主的产品并没有什么优势。

我觉得说了这么多应该是没人敢用的。

Windows 的话可以通过 job 来限制 CPU 使用，也可以通过限制运行再某一个核心的方式来限制 CPU 。
Linux 的话 cgroup 是正解。

另外，恐怕楼主找到的都不是 bug，反倒是乱改可能改出 bug 了。

@vk42
这里的 kill 不是命令行的 kill 而是指 kill().

pid 为-1 时会给除了 init 以外的所有有权限访问的进程都发送一遍指定的信号。
文档写的很清楚：

If pid equals -1, then sig is sent to every process for which the calling process has permission to send signals, except for process 1 (init).

可以想象楼主的焦虑。

我是觉得，只要找到相对稳定的收入，这个焦虑应该能减轻很多。

1 、MD5 没有也不存在加密功能
2 、搜索引擎搜索一下，大把大把的。

建议直接买新的。

我个人是很喜欢数字专辑的，排除纪念和收藏一类意义的话，数字专辑比实体 CD 要方便很多。
Apple Music 、mora 这样的地方购买了的数字专辑都是可以下载的。
我印象中我很早以前在 QQ 音乐购买的数字专辑也是可以下载的，现在我虽然不太清楚不过我觉得应该不会改。


只不过平台订阅的利润来的多，所以平台商更喜欢卖 VIP 这种订阅制的产品。
国内的环境下面，专辑发行商实体不好卖，卖数字专辑利润又不稳定，所以最后就衍生出了你付我订阅费我一锤子把旗下版权都授权给你用的这种商业模式吧。
毕竟老专辑的销售量必然是很低很低的，我打包卖授权显然赚的更多。

只是单纯的瞬时功率太大线路不能承受吧。

装修的时候设计不良导致的，想彻底解决估计得重新走线，如果是租房只是想缓解一下找个 UPS 或者稳压器。

不满 1w 每个月 1 块小额管理费很早就有，如果没有自己申请减免的话这个费是可以继续收的，而且看图这个是补扣以前的管理费。

有些东西在不同语言的 Windows 版本里面是写死的，没办法切换的。
比如英文版的 Windows 你装中文语言包也还是有一堆地方显示英语的。

完全可以，只看人家是不是想这么做而已。
当然，这样做以后的效果怎么样另论。

邮件加密是双方的事情，另一方不想的话那就不能加。
大多数时间是碰不到可以加密通信的对象的。

一般大型连锁的快餐品牌都是有所谓料理包的。
区别只是有的是半成品，有的只是调料，也有的是完全的成品。

另外，其实工厂管理规范的话，料理包比店里直接做要好，毕竟店里的水平参差不齐，管理也不见得规范。

@cest

一般来说协议的实现都不能保证是绝对安全的，无论是 SSH 还是 RDP 都一样，所以才需要经常性的做更新。
Windows 系列的市占率并不低，大家基本都是用的 RDP 来管理的。
对于 RDP Server 这种实现来说如果出现什么远程代码执行或者绕过验证登录之类的漏洞，MS 是无论如何都必须修复好的，对用户来说，经常更新系统就无需担心什么。