跑 ldd 有可能會執行裡面的程式碼

Daily Lobsters 上看到「ldd(1) and untrusted binaries」這篇,這次的重點在 ldd 的 manpage ldd(1) 裡提到可能會執行裡面的程式碼,所以不適合拿來處理 untrusted binary:

Be aware, however, that in some circumstances, some versions of ldd may attempt to obtain the dependency information by directly executing the program. Thus, you should never employ ldd on an untrusted executable, since this may result in the execution of arbitrary code.

另外在原文裡面的 comment 有人提到 macOS 上面沒有 ldd,而是用其他工具給出類似的資訊,看起來是避開了這種實作方式:

macOS and other Darwin-based systems, which use Mach-O rather than ELF, and have an 4.x/SVR4-inspired dynamic linking mechanism (not surprising, given that the person who did a lot of the work on the 4.x system left Sun to go to NeXT), but don't have an "ldd" program. Instead, there's "otool -L", which produces output such as [...]

FreeBSD 上的 ldd(1) manpage 上沒有提到安全問題,但從他的實作描述看起來也不太妙:

ldd lists the dependencies of an executable by setting rtld(1) environment variables and running the executable in a child process.

回到原來主題,Linux manpage 裡面提到的 objdump 跟 ldd 的功能還是差蠻多的啊?不知道合理的替代品到底是什麼...

Rocky Linux 提出兩個方法取得 RHEL 的 source code

在「AlmaLinux 與 Rocky Linux 看起來都暫時無解」這邊提到了檯面上目前沒有好方法穩定取得 source code 後,Rocky Linux 提出了兩個方法,在不需要同意 RHEL 的條款下取得 RHEL 的 source code:「Keeping Open Source Open」。

中間還有一些小插曲可以提一下,在社群不少抗議聲後,IBM & Red Hat 的 VP 出來直接說他們認為 RHEL rebuild 沒有任何價值,而且是故意讓 rebuilder 更難實作 RHEL rebuild:「Red Hat’s commitment to open source: A response to the git.centos.org changes」。

Ultimately, we do not find value in a RHEL rebuild and we are not under any obligation to make things easier for rebuilders; this is our call to make.

回到 Rocky Linux 的文章,他們提出來的兩個方法都是基於 GPL 的重要性質:如果你可以合法拿到 binary,那麼散佈者就有義務要提供 source code。

第一個方法是透過 RHEL 目前公開提供的 container image:

One option is through the usage of UBI container images which are based on RHEL and available from multiple online sources (including Docker Hub). Using the UBI image, it is easily possible to obtain Red Hat sources reliably and unencumbered. We have validated this through OCI (Open Container Initiative) containers and it works exactly as expected.

另外一種方式是透過雲端服務的 cloud instance 跑 RHEL:

Another method that we will leverage is pay-per-use public cloud instances. With this, anyone can spin up RHEL images in the cloud and thus obtain the source code for all packages and errata. This is the easiest for us to scale as we can do all of this through CI pipelines, spinning up cloud images to obtain the sources via DNF, and post to our Git repositories automatically.

這兩個方法都不需要同意 RHEL 目前在網站上的 TOS 與 EULA,而且短時間內應該不好防堵:前者要關掉的話,應該有一堆既有 RHEL 客戶在用會直接抱怨,真的要硬幹的話得給這些客戶時間從 public repository 轉移到要認證的 repository 上;而後者要堵的話,除非 IBM & Red Hat 決定直接不做雲端生意?

看起來 Rocky Linux 與 AlmaLinux 用這套方法可以撐一陣子,直到 IBM & Red Hat 想出新方法來搞?

AlmaLinux 與 Rocky Linux 看起來都暫時無解

昨天提到的「IBM 決定停止公開發布 RHEL 的 source code」有了另外一邊的說明了:

如同 AlmaLinux 所說的,重新散佈程式碼是受限的:

Unfortunately the way we understand it today, Red Hat’s user interface agreements indicate that re-publishing sources acquired through the customer portal would be a violation of those agreements.

所以目前 AlmaLinux 的意思是沒有什麼好解法,而 Rocky Linux 的公告文章只有幹話,沒有實質內容。

但我猜既有的客戶裡面有不受這個條款影響的族群,像是直接跟 IBM 談授權合約的公司,有可能會有排除單方面修改授權的條款,這個應該會是目前 RHEL 8/9 的破口,但後續再釋出的版本應該會被 IBM 的法務給補上?

IBM 決定停止公開發布 RHEL 的 source code

Hacker News 首頁上看到的新聞,IBM 決定停止公開發布 RHEL 的 source code:「Red Hat cutting back RHEL source availability」,原始的文章在「Furthering the evolution of CentOS Stream」這邊。

可以猜測這與 Rocky LinuxAlmaLinux 有關。

有購買 RHEL 的人 (取得 binary 的人) 可以在 Red Hat Customer Portal 上取得 source code,這部份應該是遵守 GPL 的關係。

但不確定後續 Rocky Linux 與 AlmaLinux 會怎麼處理,看了看 GPLv2 裡面的條文,不是很確定是否可以限制散佈 source code 的行為...

XFCE (Xubuntu) 下的手動 lock + screensaver + DPMS 組合

桌機換成 Xubuntu 22.04 後會遇到手動鎖定螢幕時,螢幕不會進入省電模式,遇到的情況有點像是「DPMS Suspend on Screen Lock」這邊提到的情境。

這類問題如果用 search engine 一時間沒有找到解法的話,最好的方法都是直接去讀 source code,然後就發現透過 Ctrl+Alt+L 觸發的 /usr/bin/xflock4 其實是個 shell script,從 code 讀可以發現裡面只負責 lock 的部分,本來就跟 DPMS 無關。

我在下面提供的方案就是自己處理螢幕的部分,也就是自己先跑 DPMS 指令,然後再回頭呼叫 /usr/bin/xflock4

#!/bin/sh
/usr/bin/xset dpms force off
exec /usr/bin/xflock4

Ctrl+Alt+L 的觸發程式掛上來,這樣就會正常處理了...

用 aptitude 找出合適的降版組合

在跟 Nvidia 提供的各種驅動程式以及套件奮戰,結果遇到經典的 apt 每次都講的不明不白的老問題,像是依照「NVIDIA Deep Learning TensorRT Documentation」這篇的說明,你需要指定需要的版本安裝對應的套件,像是我這邊就是要裝 CUDA 11 的版本,但系統就跟你說不能裝:

sudo apt install tensorrt=8.5.3.1-1+cuda11.8
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 tensorrt : Depends: libnvinfer8 (= 8.5.3-1+cuda11.8) but 8.6.1.6-1+cuda12.0 is to be installed
            Depends: libnvinfer-plugin8 (= 8.5.3-1+cuda11.8) but 8.6.1.6-1+cuda12.0 is to be installed
            Depends: libnvparsers8 (= 8.5.3-1+cuda11.8) but 8.6.1.6-1+cuda12.0 is to be installed
            Depends: libnvonnxparsers8 (= 8.5.3-1+cuda11.8) but 8.6.1.6-1+cuda12.0 is to be installed
            Depends: libnvinfer-bin (= 8.5.3-1+cuda11.8) but 8.6.1.6-1+cuda12.0 is to be installed
            Depends: libnvinfer-dev (= 8.5.3-1+cuda11.8) but 8.6.1.6-1+cuda12.0 is to be installed
            Depends: libnvinfer-plugin-dev (= 8.5.3-1+cuda11.8) but 8.6.1.6-1+cuda12.0 is to be installed
            Depends: libnvparsers-dev (= 8.5.3-1+cuda11.8) but 8.6.1.6-1+cuda12.0 is to be installed
            Depends: libnvonnxparsers-dev (= 8.5.3-1+cuda11.8) but 8.6.1.6-1+cuda12.0 is to be installed
            Depends: libnvinfer-samples (= 8.5.3-1+cuda11.8) but 8.6.1.6-1+cuda12.0 is to be installed
E: Unable to correct problems, you have held broken packages.

以前比較簡單的套件可以用 apt-cache showpkg 慢慢看組合自己解,但這種巨大套件實在沒辦法。

在「How do I resolve `The following packages have unmet dependencies`」這邊則是有提到這個問題,下面有給個一般性的通解:用 aptitude 提供降版的組合,每一套組合你都可以選 n 讓他提供另外一套組合,直到你覺得這套組合 OK 了再選擇 y 讓他裝起來。

然後裝完以後記得用 apt-mark hold 把主套件的版本固定住,避免 upgrade 的時候又被搞中爛掉出事。

自己小修一下 fcitx5-mcbopomofo 的選詞數量

之前有提過「Linux 上 fcitx5 的小麥輸入法」,在我自己桌面都換成 Ubuntu 22.04 後都能裝了,就用了一陣子。

但選字的數量一直覺得怪怪的,本來的數量是九個,像是這樣:

看了一下 Windows 上的新酷音,介面上因為設計成 3x3 的關係,所以看起來就不會不舒服:

所以就在想,如果是一行的為什麼不是十個?翻了翻程式碼,看起來在 src/McBopomofo.cpp 這邊:

  if (keysConfig == SelectionKeys::Key_asdfghjkl) {
    selectionKeys_.emplace_back(FcitxKey_a);
    selectionKeys_.emplace_back(FcitxKey_s);
    selectionKeys_.emplace_back(FcitxKey_d);
    selectionKeys_.emplace_back(FcitxKey_f);
    selectionKeys_.emplace_back(FcitxKey_g);
    selectionKeys_.emplace_back(FcitxKey_h);
    selectionKeys_.emplace_back(FcitxKey_j);
    selectionKeys_.emplace_back(FcitxKey_k);
    selectionKeys_.emplace_back(FcitxKey_l);
  } else if (keysConfig == SelectionKeys::Key_asdfzxcvb) {
    selectionKeys_.emplace_back(FcitxKey_a);
    selectionKeys_.emplace_back(FcitxKey_s);
    selectionKeys_.emplace_back(FcitxKey_d);
    selectionKeys_.emplace_back(FcitxKey_f);
    selectionKeys_.emplace_back(FcitxKey_z);
    selectionKeys_.emplace_back(FcitxKey_x);
    selectionKeys_.emplace_back(FcitxKey_c);
    selectionKeys_.emplace_back(FcitxKey_v);
    selectionKeys_.emplace_back(FcitxKey_b);
  } else {
    selectionKeys_.emplace_back(FcitxKey_1);
    selectionKeys_.emplace_back(FcitxKey_2);
    selectionKeys_.emplace_back(FcitxKey_3);
    selectionKeys_.emplace_back(FcitxKey_4);
    selectionKeys_.emplace_back(FcitxKey_5);
    selectionKeys_.emplace_back(FcitxKey_6);
    selectionKeys_.emplace_back(FcitxKey_7);
    selectionKeys_.emplace_back(FcitxKey_8);
    selectionKeys_.emplace_back(FcitxKey_9);
  }

看起來是為了跟 asdfghjkl 九個鍵對齊設計的,但這樣覺得不舒服... 所以在 selectionKeys_.emplace_back(FcitxKey_9); 後面加上 selectionKeys_.emplace_back(FcitxKey_0);,再重新編 + 裝 + 重啟後再輸入就變成十個了:

這樣自己用是沒問題,但暫時想不到怎麼找出一個好方法併回去... 也許多一組 SelectionKeys::Key_1234567890

Linux 6.2 的 Btrfs 改進

Hacker News 上看到 Btrfs 的改善消息:「Btrfs With Linux 6.2 Bringing Performance Improvements, Better RAID 5/6 Reliability」,對應的討論在「 Btrfs in Linux 6.2 brings performance improvements, better RAID 5/6 reliability (phoronix.com)」這邊。

因為 ext4 本身很成熟了,加上特殊的需求反而會去用 OpenZFS,就很久沒關注 Btrfs 了,這次看到 Btrfs 在 Linux 6.2 上的改進剛好可以重顧一下情況。

看起來是針對 RAID 模式下的改善,包括穩定性與效能,不過看起來是針對 RAID5 的部份多一點。

就目前的「情勢」看起來,Btrfs 之所以還是有繼續被發展,主要還是因為 OpenZFS 的授權條款是 CDDL,與 Linux kernel 用的 GPLv2 不相容,所以得分開維護。

但 OpenZFS 這邊的功能性與成熟度還是比 Btrfs 好不少,以現階段來說,如果架構上可以設計放 OpenZFS 的話應該還是會放 OpenZFS...

用 reprepro 建立 APT repository

在「用 fpm 這個工具包 .deb 安裝」這篇題到了 fpm,另外在同一篇文章裡面 (「Using Cloudflare R2 as an apt/yum repository」這篇) 也有提到要怎麼生出一個有簽名過的 APT repository,裡面就提到了 reprepro 這個工具。

Debian Wiki 上面的「SetupWithReprepro」就有一步一步告訴你設定的方式,另外 Wikimedia 的技術 wiki 上也有提到常用的操作:「Reprepro」。

然後可以丟到很多不同的地方,最常見的 apache 或是 nginx 外,S3 或是其他可以吐 HTTP/HTTPS 的 object storage 服務都可以。

也是先記錄起來,等要用的時候可以回來 blog 上翻到...

在 Ubuntu (Xfce) 上改用 Albert Launcher

在噗浪上的這篇看到的工具,讓我想起來之前有想要在 Ubuntu + Xfce 上找類似的工具:

macOS 上我最常用的就是計算機與匯率換算,另外就是開應用程式。

但是因為沒辦法直接用 super key 啟動 (也稱作 meta key,或是大家更熟悉的微軟鍵),所以得迂迴設定,先透過 xcape 把左邊的 super key 對應到 Ctrl-Esc 上:

xcape -e 'Super_L=Control_L|Escape'

然後把本來的 Ctrl-Esc 拔掉:

然後這時候用 super key 時就會改抓到 Ctrl-Esc 了:

接下來就可以勾選 extensions 了,這邊勾了幾個:

然後 Python 這邊把 Currency convert 的部份勾起來:

用法是 1 usd to twd 這樣的句子:

這兩天用起來還不錯,之後遇到問題再來調整...