也许和内核ACPI模块有关

> <@nyaacinth:mozilla.org> 哦，抱歉没看到 怎么看都是一切正常......

是新telegram哦

新鲜的 telegram-desktop-lily built against qt6-base 6.11beta https://build.archlinuxcn.org/~rocka/telegram-desktop-lily-6.5.1-1.1-x86_64.pkg.tar.zst

哦，抱歉没看到

就是这里的内容

你cat一下/sys/power/state，内容是什么

看了一些错误报告，感觉没什么共性

关掉试试看，我查了一下存在相关的错误报告

> <@telegram_748656009:nichi.co> 但是好像我这里不是这样的 你有没有在运行浏览器或者别的基于chromium的东西

把字面意义上的 wine 和 wine is not emulator 搞混了

[m.image] 神秘的内容农场

[m.image] 但是好像我这里不是这样的

按照https://www.kernel.org/doc/html/latest/power/basic-pm-debugging.html 的做法，我运行了 # echo reboot > /sys/power/disk # echo disk > /sys/power/state 电脑应该是会黑屏进入关机状态吧？

* 欸，好像已经优化了？ EDIT：对的！

文件系统和这里描述的事情无关吧。没有理由不能用（

欸，好像已经优化了？

Gnome Wayland现在的OSK似乎在一部分程序内无效

我在等Gnome（Plasma也行）优化Wayland下的OSK，这样我就可以给FydeTab上ALARM了

OwO

我试试

你试试不就知道了)

[m.image] 那我用btrfs+swapfile能用自动选择的交换空间吗

比如服务端

* 大厂项目，尤其是外包项目（但本部项目也跑不了）很多团队里只有一个或几个技术骨干，剩下的水平很可能不敢恭维，而这一个或几个技术骨干也只会关注他们认为的关键节点

大厂项目，尤其是外包项目（但本部项目也跑不了）很多团队里只有一个或几个技术骨干，剩下的水平很可能不敢恭维，而这一个或几个技术骨干也只会关注关键节点

没法期待太多

腾讯毕竟是那个腾讯

但...

我也觉得

但有一说一，这仍然可能存在 shell 注入

含`和$都会返回上传已中断

就是禁止发送带有特殊符号的文件

我用安卓测试了一下

* 虽然我觉得应该用QDesktopServices替换这个乱七八糟的逻辑就是了

虽然我觉得应该用QDesktopServices替换这个乱七八糟的逻辑

> <@telegram_824372155:nichi.co> 那至少我觉得这不算彻底修复（ 腾讯也不是个技术导向的公司，阻止大范围影响的效果达成了应该他们就会认可

那至少我觉得这不算彻底修复（

> <@telegram_824372155:nichi.co> 还有昨天爆出来那个 shell 注入漏洞，据说是在服务器侧修复了，但一个客户端点击文件触发的漏洞如何在服务器修复？我只能盲猜客户端本身有点击文件时发送网络请求，并可以被服务器拒绝的逻辑 在服务器上给文件名提前转义一次

但大范围影响已经被阻止

> <@telegram_824372155:nichi.co> 那之前已经发出去的呢（ 没辙

这样也可以是服务端修复

那之前已经发出去的呢（

热修复吗 🙈

> <@telegram_824372155:nichi.co> 还有昨天爆出来那个 shell 注入漏洞，据说是在服务器侧修复了，但一个客户端点击文件触发的漏洞如何在服务器修复？我只能盲猜客户端本身有点击文件时发送网络请求，并可以被服务器拒绝的逻辑 也不必如此，我猜是禁止发送带有相关文件名的文件

还有昨天爆出来那个 shell 注入漏洞，据说是在服务器侧修复了，但一个客户端点击文件触发的漏洞如何在服务器修复？我只能盲猜客户端本身有点击文件时发送网络请求，并可以被服务器拒绝的逻辑

它完全可能不是故意的，如果确实不是故意那更好

also Tencent: 获取磁盘和主板信息

但腾讯软件过往的行为改变了我对它的预期

> <@telegram_1071194014:nichi.co> 感觉故意应该有待商榷吧 嗯...如果它不是腾讯，我会觉得有待商榷

还没检测 namespace 就偷着乐吧（

我猜微信对 QT 应该是有修改

感觉故意应该有待商榷吧

我也厌烦套一堆VM了

> <@telegram_824372155:nichi.co> 这个讨论也不局限于 flatpak 那我就没有意见了，期待相关解决方案

它并没有使用一个古老的Qt版本，但几乎完全不兼容Wayland

> <@kimiblock:kimiblock.top> 微信: 故意删掉 wayland module 和 portal picker y

微信: 故意删掉 wayland module 和 portal picker

这个讨论也不局限于 flatpak

我还是觉得这超出了flatpak的职责范围，因为这么做反而会限制flatpak的用途

至少目前 Linux 桌面上的闭源软件似乎还没有这么做的

如果闭源程序铁了心要检测沙盒并拒绝运行的话，那就是没有很好的办法的

* ...要如何避免闭源软件通过刻意不兼容相关API的方式阻止用户使用沙箱技术呢

所以就先不考虑动态授权喽，考虑静态配置的权限

> <@telegram_824372155:nichi.co> 动态授权必须要单独设计 api ...要如何确保闭源软件通过刻意不兼容相关API的方式阻止用户使用沙箱技术呢

应用程序沙箱应该是什么样，可以看看 android app。在“正常情况”下，一个恶意的 app 也不能任意读取其它 app 的数据，也不能获取 root 权限

这和应用程序沙箱不是一回事，是不同的用途

zathura 会设置一个 GUI，不受限制地加载其配置文件（这本身并无害），然后在执行解析目标文档的危险部分之前，加载一个 seccomp 过滤器，阻止大部分系统调用的执行。这样，当目标文档加载完毕，潜在的解析漏洞可能导致代码执行时，进程已经无法打开具有写入权限的新文件或访问套接字。在容器沙箱中无法实现此类限制

否则只能重启应用程序生效

在我看来这种需求至少应该寻求一个真正的沙箱方案

动态授权必须要单独设计 api

那个依赖 ebpf 吧

不可能这一时刻允许，那一时刻拒绝

我想问一下，为什么各位一定要flatpak解决这个问题

这都是 flatpak 限制太宽松，并不是不可解决的

主要观点是 flatpak 不能在时间上对程序做限制

所以...我觉得这种需求不是flatpak应该解决的，它看来也确实不是

我看了一眼 systemd 还不支持 user manager 下的 IPAddressAllow

这篇文章提到两种沙盒的区别

> <@telegram_824372155:nichi.co> 我觉得限制局域网的话 mdns 一起被限制应该是预期的？ 好像确实

https://hanako.codeberg.page/

有道理, 现在就剩怎么限制了 (

我觉得限制局域网的话 mdns 一起被限制应该是预期的？

总感觉已经超出flatpak的职责范围了

对

mdns 吗

还有 Bounjour 这类服务怎么办)

怎么越来越重了啊

嗯……确实。这个我觉得也不难，给每个应用程序一个 dns proxy，然后在沙盒里 bind 进一个 resolv.conf 和 nsswitch.conf

至少不能对程序声称的功能做限制

也许之后这一点会改变

因为我不信任在相同硬件上隔离可访问资源的技术

其实除了能不能直接与内核对话之外没什么区别

因为用户的 DNS server 可能在任何地方, 不允许就炸了)

* 是的，我目前的方法是隔离设备以及VM

网页直接在浏览器上运行，浏览器能做的控制更多一些吧。但是把预计自己在机器上运行的程序弄到沙盒里面那就不一样了

为什么要涉及 dns（

> <@kimiblock:kimiblock.top> 某些闭源软件当然想方设法阻挠你使用沙盒 是的，我目前的方法是隔离设备

有什么可靠的方法 parse DNS server 吗 (

我觉得限制 localhost 和局域网应该对绝大部分程序来说不会 break