弄清楚 >/dev/null 2>&1 與 2>&1 >/dev/null 的差異

以前都是硬背起來的,如果要把所有的輸出都丟到 /dev/null,要用前面的方式才會是對的,但其實在 bash 的 manpage 裡面有提到:

Note that the order of redirections is significant. For example, the command

    ls > dirlist 2>&1

directs both standard output and standard error to the file dirlist, while the command

    ls 2>&1 > dirlist

directs only the standard output to file dirlist, because the standard error was duplicated from the standard output before the standard output was redirected to dirlist.

這是因為照順序跑 dup2() 的關係 (參考 bash 的 redir.c)。

前者會先把 dirlist 開起來後透過 dup2() 複製到 fd=1,再用一次 dup2() 把 fd=1 複製到 fd=2,達到我們要的效果。

後者則是先把 fd=1 複製到 fd=2 (於是大家都丟到 stdout 了),接下來再把 dirlist 開起來,丟到 fd=1。這樣變成 ls 寫到 stderr 的東西變成到 stdout 了,而本來寫到 stdout 的東西進到 dirlist 這個檔案裡。

剛剛寫 code 時想找一下有沒有官方文件或是 source code 有描述 ordering 或是有定義行為,結果發現 bash 的 manpage 裡面就有提到了...

X/Twitter 又繼續在搞競爭對手的外部連結了...

八月的時候提過「X/Twitter 在惡搞外部連結結果被抓包玩陰的」這個,X (Twitter) 故意對某些網站 delay 個幾秒鐘再重導,當時爆料出來後就馬上拿掉了,結果這幾天又被抓到故技重施:「Twitter is Still Throttling Competitors’ Links—Check for Yourself」。

依照測試,Meta 家的 FacebookInstagram 以及 Threads 都中獎,另外沒什麼意外的,Twitter 前頭頭跳出來開的 Bluesky 也都有被搞...

而且這次爆料出來後也沒有「迅速修正」了,到目前也都還是如此... 來看看後續?

apt-get 的安全性漏洞

前幾天寫的「APT 不使用 HTTPS 的說明」的當下就已經有看到在講這個漏洞,但沒讀完就一直放著沒寫:「Remote Code Execution in apt/apt-get」。

漏洞出在實作上的問題,對於 HTTP 重導的程式碼沒有處理好外部字串,在還沒修正的機器上用這個指令關閉 redirect,避免在修正的過程反而被 RCE 打進去:

sudo apt update -o Acquire::http::AllowRedirect=false
sudo apt upgrade -o Acquire::http::AllowRedirect=false

但也不是 HTTPS 就能避免這個問題,因為 HTTPS 連線用的程式碼又是另外一份,裡面不知道有沒有問題 (像是之前經典的 Heartbleed),所以應該還是會繼續爭吵吧...