C23 的 #embed 看起来还早着呢
https://en.cppreference.com/w/c/preprocessor/embed
https://en.cppreference.com/w/c/compiler_support/23
https://github.com/llvm/llvm-project/pull/68620

今天是 Pi Day！来试试挑战徒手画一个 pi = 3.14 的圆吧！

https://matrix67.itch.io/pi-day-challenge

Plasma 5.18 and above has hidden the “lock widgets” toggle. It’s very easy to enter “edit mode” with a long press. If you want to get the old locked mode behavior, run the following command:

qdbus org.kde.plasmashell /PlasmaShell evaluateScript 'lockCorona(!locked)'

If you want an easier way to toggle locking widgets in Plasma 5.18, install Win7ShowDesktop widget which has a “Lock Widgets” toggle in it’s right click menu.

https://forum.garudalinux.org/t/kde-plasma-desktop-is-locked-for-editing-and-i-cant-unlock-it/973

In case anyone is looking for this.

当教室突然安静——扰动，突变与回复 - BaoPinsUi啊的文章 - 知乎
https://zhuanlan.zhihu.com/p/679862117

xz 软件包被植入后门

简单讲：立即升级系统和容器镜像！

大家可能已经听说了 [1]，xz 上游发布的 5.6.0 和 5.6.1 版本的代码包（tarball）中含有添加后门的恶意代码。

Arch Linux Security Tracker 记录了该漏洞 [2]。

xz 软件包旧于 5.6.1-2 的版本（即 5.6.0-1 和 5.6.1-1）包含该后门。

以下发布内容（release artifacts）也包含了受影响的 xz 版本：

- 安装镜像：2024.03.01 版
- 虚拟机镜像：20240301.218094 和 20240315.221711 版
- 容器镜像：任何 2024-02-24 到 2024-03-28 之间（包括这两个日期）构建的版本

受影响的发布内容已经从我们的镜像站上移除。

强烈建议不要使用受影响这些受影响的发布内容。请下载当前的最新版本！

升级系统
如果你的系统当前安装了 xz 5.6.0-1 或 5.6.1-1，强烈建议你立即进行完整系统升级：

pacman -Syu

升级容器镜像
要确定否正在使用受影响的容器镜像，使用以下命令（podman 用户）：

podman image history archlinux/archlinux

或者（docker 用户）：

docker image history archlinux/archlinux

所有旧于 2024-03-29 且新于 2024-02-24 的 Arch Linux 容器镜像都受到了影响。

使用以下命令升级受影响的容器镜像到最新版本（podman 用户）：

podman image pull archlinux/archlinux

或者（docker 用户）：

docker image pull archlinux/archlinux

升级之后，请确保重新构建基于受影响版本的任何容器镜像，并检查所有运行中的容器！

sshd 认证绕过 / 代码执行问题
根据上游报告 [1]：

openssh 不直接使用 liblzma。但 debian 和其他几个发行版对 openssh 打了补丁，引入了 systemd 通知支持，而 libsystemd 确实依赖于 lzma。

Arch 并不直接将 openssh 链接到 liblzma，因此这种攻击途径是不可能的。可以通过以下命令来确认这一点：

ldd "$(command -v sshd)"

但是，出于谨慎，我们建议用户通过升级系统/容器镜像移除恶意代码 —— 因为可能有其他还没有被发现的后门利用方法。

https://www.archlinuxcn.org/the-xz-package-has-been-backdoored/

它怎么还在代码里骂人的

今天有人提到 Lasse Collin 对于 xz 项目早就疲惫不堪，Jia Tan 是极少数愿意真正贡献代码的“开发者”，这都是这场悲剧不可或缺的背景条件。

在无人关心的角落，Florian Westphal 最近辞去了内核 netfilter co-maintainer，所以现在 nf 只剩 Pablo Neira Ayuso 一人维护。这可是无数人每天使用的 netfilter。

在无人关心的角落，我最爱的工具之一 strace 依然只由一个捷克人 Dmitry V. Levin 默默维护。

在无人关心的角落，tcpdump/libpcap 在由 the-tcpdump-group 持续更新，其中一位 Denis Ovsienko 的自我介绍是 sometimes I work jobs for living, sometimes I contribute pro bono to free and open source software projects, often I do both，给人一种很孤独的感觉。

在无人关心的角落，bash group 只有三位 active members，其中一位 Bob Proulx 有个古典博客，里面有记录他和妻子的平静生活。

我以前赞美人月神话，但我现在更关心默默无闻的开发者们，就像 vim 作者 Bram Moolenaar 一生没有和任何人建立亲密关系，我只想问，你这一生过得开心吗？

你们这些伟大的开发者们过得开心吗？

0 Day 安全提醒: Telegram Desktop <=4.16.4 有自动执行代码漏洞

消息来源:
https://t.me/strykerapp/453
https://t.me/exploitorg/30

后续: https://vxtwitter.com/telegram/status/1777677055837995151

结论：疑似攻击者通过利用错误MIME type实现客户端欺骗。

涉及Telegram中的两个API功能——sendVideo和InputFile。

sendVideo中的video字段支持两种输入方式，“InputFile or String”，

- （String）传递一个文件 ID（以字符串形式）来发送存储在 Telegram 服务器上的视频（推荐做法）
- （String/InputFile）传递一个 HTTP URL（以字符串形式）以便 Telegram 从互联网获取视频
- （InputFile）使用 multipart/form-data 上传一个新视频。

问题出在第二种，InputFile - Sending by URL时，目标资源可以拥有一个自定义的MIME标签，以指示其他Telegram客户端应该以什么方式加载这个资源。

而这些不怀好意的.pyzw文件，（可能由于漏洞）在这里都被指定为了video/mp4，导致其他Telegram客户端将以播放器模式展示这个文件。



响应标头：>图1<
请求方json：

{
  "dcId": number,
  "location": {
    "_": "inputDocumentFileLocation",
    "id": "*",
    "access_hash": "*",
    "file_reference": [
      *, *, *, *
    ]
  },
  "size": 42,
  "mimeType": "video/mp4",
  "fileName": "***.pyzw"
}

另外，Telegram Desktop的影片播放方式决定了Telegram Desktop将会把这些较小的视讯资源放置在本地下载目录，然后通过“执行”的方式来加载本地影片至内嵌播放器，这也就是为什么在用户点击这些“假影片”后会自动执行攻击者编写的代码。

今天是中国互联网30岁的生日！🎉
无论如何，三十年间，它将亿万个你我相连，纵使远隔万里，亦能心意相通！
让我们期待下一个三十年是什么样子吧！

git CVE-2024-32002, CVE-2024-32004, CVE-2024-32020 and CVE-2024-32021
fixed versions: v2.39.4, v2.40.2, v2.41.1, v2.42.2, v2.43.4 and v2.44.1, v2.45.1

* CVE-2024-32002:

Recursive clones on case-insensitive filesystems that support symbolic
links are susceptible to case confusion that can be exploited to
execute just-cloned code during the clone operation.

* CVE-2024-32004:

Repositories can be configured to execute arbitrary code during local
clones. To address this, the ownership checks introduced in v2.30.3
are now extended to cover cloning local repositories.

* CVE-2024-32020:

Local clones may end up hardlinking files into the target repository's
object database when source and target repository reside on the same
disk. If the source repository is owned by a different user, then
those hardlinked files may be rewritten at any point in time by the
untrusted user.

* CVE-2024-32021:

When cloning a local source repository that contains symlinks via the
filesystem, Git may create hardlinks to arbitrary user-readable files
on the same filesystem as the target repository in the objects/
directory.