Firefox 的 UI 修正方案

在「Firefox Proton UI userChrome.css fixes. (2021) (github.com/black7375)」這邊看到的,GitHub 上的專案頁面在「Lepton (old name: Proton Fix)」這邊。

作者先前有寫過,我在「Firefox 的 UI/UX 歷史」這篇,同一個 repository 裡面就包含了「修正方案」,補上了一些 icon,並且改了 css 效果。

不過我已經沒什麼在用 Firefox 了,而且目前看起來也不會回去了,看起來只有在交叉找問題的時候會用到...

PuTTY 使用 ecdsa-sha2-nistp521 的漏洞

看到「PuTTY vulnerability vuln-p521-bias (greenend.org.uk)」這個消息,官網的說明在「PuTTY vulnerability vuln-p521-bias」這邊。

DSA 類的簽名演算法有個得很小心的地方,是 nonce 選擇不當會造成 key recovery,這在原文有提到:

All DSA signature schemes require a random value to be invented during signing, known as the 'nonce' (cryptography jargon for a value used only once), or sometimes by the letter k. It's well known that if an attacker can guess the value of k you used, or find any two signatures you generated with the same k, then they can immediately recover your private key.

維基百科的業面上也有提到這點:

With DSA, the entropy, secrecy, and uniqueness of the random signature value {\displaystyle k} are critical. It is so critical that violating any one of those three requirements can reveal the entire private key to an attacker. Using the same value twice (even while keeping {\displaystyle k} secret), using a predictable value, or leaking even a few bits of {\displaystyle k} in each of several signatures, is enough to reveal the private key {\displaystyle x}.

這次爆炸的起因是 PuTTY 用了 SHA-512 產生 nonce,這邊只會有 512 bits 的輸出,而這對 P-521 需要 521 bits 是不夠的 (於是前 9 個 bit 會是 0):

PuTTY's technique worked by making a SHA-512 hash, and then reducing it mod q, where q is the order of the group used in the DSA system. For integer DSA (for which PuTTY's technique was originally developed), q is about 160 bits; for elliptic-curve DSA (which came later) it has about the same number of bits as the curve modulus, so 256 or 384 or 521 bits for the NIST curves.

In all of those cases except P521, the bias introduced by reducing a 512-bit number mod q is negligible. But in the case of P521, where q has 521 bits (i.e. more than 512), reducing a 512-bit number mod q has no effect at all – you get a value of k whose top 9 bits are always zero.

而更糟的是,這不僅僅是將降了 29 的安全性,而是因為 nonce 有 bias,這在 DSA 上已經足以從 60 次的簽出的 signature 中還原出 private key (也就是文章裡提到的 key recovery attack):

This bias is sufficient to allow a key recovery attack. It's less immediate than if an attacker knows all of k, but it turns out that if k has a biased distribution in this way, it's possible to aggregate information from multiple signatures and recover the private key eventually. Apparently the number of signatures required is around 60.

新版會改用 RFC 6979 (Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)) 實作:

To fix this vulnerability, we've completely abandoned PuTTY's old system for generating k, and switched to the RFC 6979 technique, for all DSA and ECDSA key types. (EdDSA keys such as Ed25519 already used a different system, which has not changed.) However, this doesn't affect the fact that information about existing P521 private keys has already been leaked whenever a signature was generated using the old k generator.

所以這次的 fix 得更新 PuTTY 版本,然後重新產生 private key (會假設已經 leak 了),然後看看系統有什麼要處理的...

UUID 的 UX

在「The UX of UUIDs (unkey.dev)」這邊看到的紋章,原文在「The UX of UUIDs」。

裡面有不少是有幫助的建議,像是第一個建議是把 UUID 裡面的 - 拿掉,這樣對於 copy 比較方便 (畢竟大多數人應該是 copy UUID,不會是念出來?)。

第二個建議是加上 prefix,這點不一定侷限在 UUID,只要是 token 上面都很適合。這個在不少系統上應該都有看過,像是 GitHub 的 token,或是 AWS 的 token 都算是這類。

文章裡面沒有提到,但這個建議也可以幫助你在 CI 上設定 regex,擋下把 secret token 寫進去的行為。

第三個提到用 base58,一方面是減少長度,另外一方面是想要避免 1IiLl0Oo 的問題,這點我覺得還好... 既然都是 copy & paste 了,我覺得拿 base62 (i.e. 大小寫加上數字) 不錯,這避免特殊字元無法選擇到,也就是文章裡面第一個建議。

第四個建議是建議重新思考 range,因為 UUID 的 128-bit range 很大,但不是所有應用都需要用到這麼大的範圍確保 collision-free (於是可以當 primary key)。

這點讓我想到 X (Twitter) 當初發表的 Snowflake ID,在 Twitter 這種規模下 64-bit range 也已經夠用。

後面的文章內容就是在推銷自家東西,我就... 跳過了。

把 terminal 軟體從 xfce4-terminal 換成 wezterm

我自從換到 Xubuntu 後一直都是用 xfce4-terminal,直到三月中的時候換成 wezterm 了,記得當時是在 Fediverse 上看到 gugod 說他用這套,測了一下覺得比 xfce4-terminal 好用,可以微調不少 xfce4-terminal 做不到的東西,就換過去了。

前陣子看到「Just How Much Faster Are the GNOME 46 Terminals?」這篇 (via),在 Hacker News 的討論裡面有提到另外一篇文章有測試 terminal latency 的問題:「Terminal Latency」,看了一下 wezterm 的速度不算快,不過 terminal 的速度目前不是我的痛點,所以還好:

(話說 xterm 居然是最快的...)

翻了一下之前在 2021 的時候有提到過 wezterm,不過當時是在講 vttest:「用 vttest 測試 terminal 程式實做的相容性」。

wezterm 是透過一個 Lua 檔案 (~/.wezterm.lua) 在管理設定的,而且預設支援 hot reload,所以不用太擔心會需要一直調整後重啟。

我的設定檔在 config repository 裡面有,不過我是建議自己花些時間調整,如果你是 terminal-heavy user 的話...

Automattic 買下 Beeper

沒想到後續消息居然會是這個,在 Hacker News 上看到 Automattic 買下 Beeper 的消息:「Beeper acquired by Automattic (WordPress) (beeper.com)」,原文在「Beeper is joining Automattic」這邊。

先前因為弄出與 iMessage 相通的工具而知名,當時還追過這個新聞:

看起來之前就有投資的關係了:

Matt, Automattic’s CEO, and I have known each other for years. He was an early user, supporter and investor in Beeper.

不確定買下來能做什麼,新聞稿上講得是很冠冕堂皇... 但對 Beeper 的創辦人這邊大概就是順利脫手?當時 Apple 的態度讓 iMessage 相容性這條路走到 dead end;對 Automattic 這邊大概就是希望這群人做 IM project?

不過當時已經買了 Texts.com (參考當時的新聞「WordPress.com owner buys all-in-one messaging app Texts.com for $50M」),原來這組人是有什麼狀況嗎...?

利用信件裡面的 CSS,讓文字只在轉寄後才出現

在「Kobold letters: HTML emails are a risk (lutrasecurity.com)」這邊看到的 security advisory (算... 是吧?),原文在「Kobold Letters」這邊,如同標題寫的,方法其實意外的簡單...

Thunderbird 是透過 .moz-text-html>div> 指定就可以達到效果:

Outlook on the web (i.e. 雲端版本) 則是有在 id 上面增加隨機的 prefix 避免,但可以用 body>div> 避開,另外有些眉眉角角的地方會稍微複雜一點,但還是可行的:

Gmail 則是直接用個簡單的 css selector 掛上 display: none; 就 OK 了:在 sender 端 (轉寄者) 看不到,在 receiver 端則可以 (效果更好?):

比較慘的是目前大家都沒有想到比較好的解法,就算這次提到的方法被補上了,應該還是很容易被繞過去:

Unfortunately, for the foreseeable future, it is sadly not realistic to expect email clients to implement robust mitigation. This means that it is up to the users to be aware of the dangers of HTML emails and to take the necessary precautions.

另外文章裡面提到了 Can I email 這個網站,看起來如果要自己處理 email 內容的話是個不錯的資源...

把 MIT license 當歌詞寫歌...?

在「AI-generated sad girl with piano performs the text of the MIT License (twitter.com/goodside)」這邊看到的推,把 MIT License 的條文當歌詞丟進去寫歌 (應該是最近很紅的 Suno.ai?):

WTF...

下雨天才會通的網路

Hacker News 上看到「The Wi-Fi only works when it's raining (predr.ag)」,原文是「The Wi-Fi only works when it's raining」,基於文章的發表日期,雖然作者宣稱是 true story,但我還是沒辦法確定... 但內容還蠻有趣的:

Happy April 1st! This post is part of April Cools Club: an April 1st effort to publish genuine essays on unexpected topics. Please enjoy this true story, and rest assured that the tech content will be back soon!

文章裡面提到作者的老爸是工程師,他老爸自己開的公司跟家距離算近,所以他老爸用指向性天線,把公司的商用 internet 橋接到家裡用,用了十年都沒什麼問題,但最近幾個禮拜開始只有下雨天才會通?

這聽起來蠻反常的,下雨應該只會讓訊號更差才對...

直接跳到最後的揭曉,原因是鄰居的樹在這十年內長高擋到訊號了,而下雨天會讓植物稍微垂下來,於是下雨天時訊號就通了...

作者的解法則是升級設備,把本來 802.11g 的設備換成 802.11n 的設備,抗干擾的能力更好 (這邊應該是指 coding & 5GHz):

We replaced our old 802.11g devices with new 802.11n ones, which took advantage of new magic math and physics to make signals more resistant to interference.

另外作者文章用的子標題應該是與 Five stages of grief 相關,不過文章裡是 Denial-Bargaining-Determination-Debugging-Realization。

台灣 3G 網路的停用:2024/06/30

iThome 上面看到的消息,三大電信業者都將在 2024/06/30 停止 3G 網路:「中華電信、遠傳、台灣大將在6/30前關閉3G網路,手機不支援VoLTE將無法通話」。

翻了一下 iPhone 的部分,從 2014 年九月推出的 iPhone 6 就支援 VoLTE 了,差不多快十年了;這樣 Android 陣營應該也是差不多的時間才對...

到時候可以看看 iPhone 5s 的訊號會是怎麼樣... (應該會是完全沒訊號?)

拿 WireGuard 當作 SOCKS5 Proxy 的用戶端

pufferffish/wireproxyHacker News 上看到「Wireproxy: WireGuard client that exposes itself as a HTTP/SOCKS5 proxy (github.com/pufferffish)」這個有趣的東西,GitHub 上的專案頁在 pufferffish/wireproxy 這邊:

A wireguard client that exposes itself as a socks5/http proxy or tunnels.

不需要連上完整版本的 WireGuard VPN,而是透過 proxy 協定讓使用者可以使用,這樣配合瀏覽器的工具 (像是 SwitchyOmega) 可以很方便的設定各種變化,像是針對日本限定的網站走日本的 VPS instance 出去。

另外值得一提的是,這是一個 userland 而且不需要 root 權限的實作;這點蠻容易可以理解的,只是聽一個 TCP port 然後用 WireGuard protocol 跟遠端溝通,的確是不需要 root 權限。

另外在 Hacker News 的留言裡面還看到了 aramperes/onetun 這個工具,看起來是 server 端的實作,支援 TCP 與 UDP:

A cross-platform, user-space WireGuard port-forwarder that requires no root-access or system network configurations.

這兩個看起來剛好可以搭在一起...?