※ 引述《LeonH (Leon)》之铭言：
: 我来响应一下，要怎么说服工程团队领导重构
: 拿安全性压他，资安这东西，大家都懂，但大家也都不专业
: 旧架构要嘛运行的环境有已知漏洞、要嘛依赖套件有已知漏洞
: 去 CVEdetails.com 查一下，整理一下已知漏洞高危清单
: 用魔法对付魔法，“不改的话有问题你要负责吗？”
: 保证没人敢挺身说我负责，就这样，改善软件供应链的同时，顺便重构。
: 如果有人敢挺身而出，那恭喜，以后背锅侠就是他了。
有个满有趣的案例
OpenSSH 2006年有个CVE-2006-5051
是因为SIGALRM不当 导致heap管理的执行续被中断
后来被修正 但在2021的时候又被错改回来 叫CVE-2024-6387
OpenSSH 8.5p1 的release notes说明中为：
This release is focused on new features and internal refactoring.
https://bugzilla.redhat.com/show_bug.cgi?id=2294604
Marco Benatto提到
This regression was introduced in October 2020 (OpenSSH 8.5p1) by commit
752250c ("revised log infrastructure for OpenSSH"), which accidentally
removed an "#ifdef DO_LOG_SAFE_IN_SIGHAND" from sigdie(), a function that is
directly called by sshd's SIGALRM handler.
https://github.com/openssh/openssh-portable/commit/752250c
看来这哥们确实是在重构 因为原本sigdie变成sshsigdie
至于为什么他要删除#ifdef DO_LOG_SAFE_IN_SIGHAND
可能他觉得本来就很safe 也有可能他觉得行为一致
反正也没有前人留下充满怨念的注解警告
(反正大家一定见过那种"祖宗之法不可变"的程式码注解警告
就跟进饭店房间要先敲门一样 宁可信其有不可信其无)
所以他可能就直接删除了
所以说以资安避免CVE出现的观点来进行重构提议
老实讲 我的想法是 嗯~~~