git.tukaani.org/?p=xz.git;a=blobdiff;f=CMakeLists.txt;h=d2b1af7ab0ab759b6805ced3dff2555e2a4b3f8e;hp=76700591059711e3a4da5b45cf58474dac4e12a7;hb=328c52da8a2bbb81307644efdb58db2c422d9ba7;hpb=eb8ad59e9bab32a8d655796afd39597ea6dcc64d
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -901,10 +901,29 @@ endif()

＃ Sandboxing: Landlock
if(NOT SANDBOX_FOUND AND ENABLE_SANDBOX MATCHES "^ON$|^landlock$")

  • check_include_file(linux/landlock.h HAVE_LINUX_LANDLOCK_H)
  • ＃ A compile check is done here because some systems have
  • ＃ linux/landlock.h, but do not have the syscalls defined
  • ＃ in order to actually use Linux Landlock.
  • check_c_source_compiles("
  • ＃include <linux/landlock.h>
  • ＃include <sys/syscall.h>
  • ＃include <sys/prctl.h>
    +.
  • void my_sandbox(void)
  • {
  • (void)prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);
  • (void)SYS_landlock_create_ruleset;
  • (void)SYS_landlock_restrict_self;
  • (void)LANDLOCK_CREATE_RULESET_VERSION;
  • return;
  • }
    +
  • int main(void) { return 0; }
  • "
  • HAVE_LINUX_LANDLOCK)
  • if(HAVE_LINUX_LANDLOCK_H)
  • set(SANDBOX_COMPILE_DEFINITION "HAVE_LINUX_LANDLOCK_H")
  • if(HAVE_LINUX_LANDLOCK)

  • set(SANDBOX_COMPILE_DEFINITION "HAVE_LINUX_LANDLOCK")
    set(SANDBOX_FOUND ON)

    ＃ Of our three sandbox methods, only Landlock is incompatible

加了一个点

请教，没看出来那个点啊，上面加了那么一大段，后面 HAVE_LINUX_LANDLOCK_H 改成了 HAVE_LINUX_LANDLOCK

  • ＃include <sys/prctl.h>+.+ void my_sandbox(void)

我日，真的假的，这么厉害。

我觉得如果 AI 能辅助 code review 还挺好的 chat.openai.com/share/fe0cc11b-a207-4d8e-8c26-430aa0893a73

今后 AI 将让系统 bug 和后门不复存在。

＃6 天大的笑话

这个 . 会导致编译失败，即使系统支持 sandbox ，也不会开启

landlock...

如何确定维护者是不是恶意的？加了个 . 之后，还能编译成功吗？

你可以看下 5 楼贴出来的 chatgpt 的回答，仅仅通过这一段 diff ，就给出了这么多见解（包括认识到了这多出的一个点的影响），试问有几个人能够在短时间内达到这样的见解呢？而 AI 工具一直在进步，所以我有这样的推测。你认为是笑话就当笑话看吧。

就是因为编译永不成功，所以成问题了

＃10 这个是编译前的选项检查阶段，如果编译通过了就会开启 HAVE_LINUX_LANDLOCK ，维护就是要让它永远都编译失败，这样 HAVE_LINUX_LANDLOCK 就永远不会开启了

任何认为后门和 bug 将在某一天不复存在的想法都是一厢情愿和不切实际的，只要有人存在就不可能彻底解决这类问题。世界本来就是混沌的，你只能努力减少 bug ，永远也做不到杜绝。

让系统 bug 和后门不复存在不可能。能大量减少也许还有可能。写一个程序，来判断另外一个程序有没有 bug ，这类问题最终是个停机问题，是不可解的。AI 能做到的无非是和现在杀软的工作类似，能有多少的准确率预测出是否有 bug 。而且对于一个 AI 算法来说，存在对抗样本，肯定会有人发明出能欺骗 AI 的后门代码的。

不对，对手也先利用 AI 检测一次，找到更隐秘的方案，只是难度一点，同时也让这个事变得门槛更高，实力不够的人看不出来。

我朋友在快手，boss 让他做一个提前发现未知 bug 的方案😄

＃11 如果 bug 实际存在，但是 AI 不认定存在 bug ，请问这个 bug 还是 bug 吗？你的不复存在论很矛盾啊，薛定谔的猫？你换个说法，什么优化论、减少论，我都还能理解，不复存在论真是太天真了。

＃11 再说说你的其他的天真想法> 仅仅通过这一段 diff ，就给出了这么多见解这些见解是哪里来的，数据样本不是吗？那 AI 没见过的东西能解释吗？只要看不到 bug 就不存在 bug 咯？> 试问有几个人能够在短时间内达到这样的见解呢？如果你的脑子可以无损存储全部数据样本并且自由的根据需求去索引，我想人脑的算力应该是人类科技 AI 不能超越的。> AI 工具一直在进步，你用了工具一词，那么我相信你说的 AI 工具是人类创造的，而不是人工智能的自我创造，那么 AI 必然低于或等于人类的最高科技水平。人造的就一定存在 bug ，总有考虑不到的情况。那你说的 AI 怎么进步也没法超越数据样本去凭空推断吧？> 你认为是笑话就当笑话看吧。真话当笑话，笑话当假话，假话当真话，人真不像话。

＃11 这个帖子发在<信息安全>分类下面，我觉得分类简介已经给出了很好的结论。我们都希望自己管理的计算机系统在运转过程中不要遇到任何安全事件。只是，这个不完美的世界的现实告诉我们：学无止境。

看来这个作者也是用心良苦啊，为了植入后门应该想了不少吧

编译不成功，怎么还能打 tar ？没有单元测试的啊？这标准化流程做得不行啊。我是想说，怎么知道它这个点是错误输入的，还是恶意的？

顶级黑客最有效的社工手段，雇运维拔网线试问阁下如何防范放行漏洞的 AI

＃22 这个还没到编译阶段呢，是在 configure 阶段做的检查。在检查的时候怎么知道能不能开启 HAVE_LINUX_LANDLOCK 选项呢？就是在 configure 写一个简单的 demo 并编译它，这个 demo 就调用 LANDLOCK 的 api 函数，如果这个 demo 编译通过了，就认为可以使用 HAVE_LINUX_LANDLOCK ，反之就是不能使用。即使实际可以调用 LANDLOCK 的 api 函数，但是现在加了一个点，这个 demo 必然是编译失败的，所以 configure 就认为不支持 HAVE_LINUX_LANDLOCK 。

＃11 问题的个数要远大于程序的个数，不存在能解决任意问题的程序

这次是一个点，在 diff 里至少还能肉眼看到，如果用一个不可见字符，比如说 U+2800 (盲文的空白符)，那 reviewer (几乎一定) 看不见了啊……

好像只有 GPT4 能明确检查出 "." 的问题, 其他一众模型包括 GitHub Copilot 都只会告诉你 check_c_source_compiles 可能会因为系统不支持编译失败

GitHub Actions 能做到你说的这一步吧？不过看了下，官方的是自建的代码托管平台，没接入 CI 。

看来这个维护者过去的提交都得重新审查

＃5 附上 5 楼的贴图：