Git 在 SHA-256 支援上遇到的問題

在 Hacker News 首頁上的「Whatever happened to SHA-256 support in Git?」這篇,大概半年前,今年六月的文章,在講 GitSHA-256 支援上遇到的問題。

最大的問題還是沒有 transition plan:

Bjarmason pointed out that there is still no interoperability between SHA-1 and SHA-256 repositories, and that none of the Git hosting providers appear to be supporting SHA-256.

這點導致了目前場上看的到的服務與 open source 軟體都沒有支援的計畫,這點算是一個超級失敗的 transition plan。

另外乾脆請 OpenAIChatGPT 幫忙寫:

Git是一種源代碼管理系統,它使用散列函數將每個對象(例如文件的每個版本)和每個提交都轉換為一個數值,用於存儲該對象。散列函數的安全性是整個倉庫完整性的重要組成部分。如果攻擊者可以用具有相同散列值的另一個提交替換提交,他們可能會在不冒檢測風險的情況下將惡意代碼植入倉庫中。這種前景令任何依賴 Git 倉庫中代碼安全性的人感到擔心,也就是所有人。

Git 項目早已選擇 SHA-256 作為 SHA-1 的替代品。Git 最初是使用 SHA-1 寫成的,但是這些代碼已被重構,並且可以處理多種散列類型,其中 SHA-256 是第二種支持的類型。現在可以使用 SHA-256 創建 Git 倉庫(只需使用 --object-format=sha256 標誌),大多數本地操作都會正常工作。Git 中支持替代散列算法的基礎是2020年發布的2.29版本的一部分,並且似乎很穩定。

然而,自從2021年3月發布的2.31版本中出現了修復程序以來,2.29版本是最後一個在任何重大方面支持替代散列的版本。專

續寫前文,Git 專案在支持 SHA-256 之前一直使用 SHA-1 作為散列算法。然而,由於 SHA-1 的終極破解,Git 項目被迫尋找替代方案。Git 原本的代碼是深深地嵌入 SHA-1 的,但是這些代碼已經被重構,並且可以處理多種散列類型,其中 SHA-256 是第二種支持的類型。因此,現在可以使用 SHA-256 創建 Git 倉庫(只需使用 --object-format=sha256 標誌),大多數本地操作都會正常工作。

然而,目前尚不存在 SHA-1 和 SHA-256 倉庫之間的相互操作性,並且 Git 托管提供商似乎都不支持 SHA-256。這種支持(或缺乏支持)很重要,因為無法推送到 Git 熔爐的倉庫對許多人來說將是無用的。此外,使用 SHA-256 的較長散列可能會破壞 Git 項目以外開發的工具,這種風險也無法完全消除。整體而言,這是一種尚未準備好用於現實世界的功能。

雖然如此,值得注意的是,迄今為止完成大部分散列轉換工作的 brian m. carlson 對 Bjarmason 的評估持不同看法。在他看來,目前唯一“可以辯解

的”使用 SHA-1 的原因是與 Git 熔爐提供商的相互操作性。否則,他認為 SHA-1 已經過時,並且使用 SHA-256 的性能可能“大幅提升”。但是,他同意所需的相互操作性目前尚不存在,且沒有人表示它即將在短期內到來。

因此,目前看來,Git 專案在支持 SHA-256 方面的工作似乎已經停止。至於什麼原因導致了這種情況,目前還不清楚。但是,這並不意味著 Git 將永遠不會支持 SHA-256 或其他散列算法。相反,可能是因為尚未解決所有技術問題,或者可能是因為其他原因(例如技術資源有限)。無論原因是什麼,重要的是要記住,Git 項目的開發人員一直在努力使其更強大、更安全,並且將繼續努力。

Mac 上用 Homebrew 安裝 Java 的方式

寫個自己看的,順便整理一些簡單的歷史。

一開始可以先看一下 java 跑起來如何:

$ java --version
The operation couldn't be completed. Unable to locate a Java Runtime.
Please visit http://www.java.com for information on installing Java.

順便一提,這邊的 java 可以用 which java 看到是出自 /usr/bin/java

然後透過 Homebrew,可以選擇不同的 JDK 套件安裝,在網路上常見的答案是 temurin (adoptopenjdk 的後繼者):

brew install temurin

這個好處是裝完可以直接用:

$ java --version
openjdk 19.0.1 2022-10-18
OpenJDK Runtime Environment Temurin-19.0.1+10 (build 19.0.1+10)
OpenJDK 64-Bit Server VM Temurin-19.0.1+10 (build 19.0.1+10, mixed mode)

另外一種是 OpenJDK,裝完後還得補個 symbolic link:

brew install openjdk
sudo ln -sfn /opt/homebrew/opt/openjdk/libexec/openjdk.jdk /Library/Java/JavaVirtualMachines/openjdk.jdk

可以看到這個版本的輸出不太一樣:

$ java --version
openjdk 19.0.1 2022-10-18
OpenJDK Runtime Environment Homebrew (build 19.0.1)
OpenJDK 64-Bit Server VM Homebrew (build 19.0.1, mixed mode, sharing)

然後不管哪種裝法都記得設定 JAVA_HOME

export JAVA_HOME="$(/usr/libexec/java_home)"

基本上就能動了。

Ruby 3.2.0 把 YJIT 列為穩定功能了

去年有寫過 RubyYJIT 帶來的效能提昇:「YJIT 帶給 Ruby 大量的效能提昇」。

在這次的 Ruby 3.2.0 發布就把 YJIT 列為穩定功能了:「Ruby 3.2.0」。

  • YJIT is no longer experimental
    • Has been tested on production workloads for over a year and proven to be quite stable.

另外就是支援的平台,看起來是多了 arm64 這邊的支援,所以馬上列表就多了一堆新機器:

  • YJIT now supports both x86-64 and arm64/aarch64 CPUs on Linux, MacOS, BSD and other UNIX platforms.
    • This release brings support for Apple M1/M2, AWS Graviton, Raspberry Pi 4 and more.

另外是每個程式語言幾乎都會遇到的 regexp 類的問題,這次 Ruby 3.2.0 利用 Memoization 的方式降低某些 regexp 的消耗:

# This match takes 10 sec. in Ruby 3.1, and 0.003 sec. in Ruby 3.2
/^a*b?a*$/ =~ "a" * 50000 + "x"

而另外一組 regexp 也可以看出類似的效果:

用一些記憶體空間換取效能,降低被 DoS 的一些機會。另外一方面,引入了 regexp timeout 的 workaround,緩解真的被打的時候的資源消耗上限:

The optimization above cannot be applied to some kind of regular expressions, such as those including advanced features (e.g., back-references or look-around), or with a huge fixed number of repetitions. As a fallback measure, a timeout feature for Regexp matches is also introduced.

LastPass 離職員工的爆料

這次 LastPass 出包搞的蠻大的,在官方的「Notice of Recent Security Incident」的裡面有提到這次的資料外洩包括了使用的 encrypted vault data 也被洩漏了:

The threat actor was also able to copy a backup of customer vault data from the encrypted storage container which is stored in a proprietary binary format that contains both unencrypted data, such as website URLs, as well as fully-encrypted sensitive fields such as website usernames and passwords, secure notes, and form-filled data.

官方一直強調這是 encrypted data,但離職員工爆料加密強度不足的問題:「1606428769731878913.html」,其中這段在講 legacy 版本的加密問題,居然曾經用過 ECB mode

Lots of vault entries may be encrypted with ECB mode AES-256. I worked on supporting unauthenticated CBC mode. But re-encrypting a users vault entries requires having their master key.

這個如同 Hacker News 上的討論「I worked at LastPass as an engineer (twitter.com/ejcx_)」提到的,以 1980 年代的標準就已經知道 ECB mode 的問題了:

> Lots of vault entries may be encrypted with ECB mode AES-256.
Wtf wtf wtf. This would be considered wildly insecure even by the standards of the 80s

其他提到 PBKDF2 的強度是逐步增加,從早期的 5000 到現在預設的 100100,這點倒是可以理解。

要避免依賴廠商的資安,一種方式是用目前成熟的開源 Password Manager,並且使用檔案儲存 (像是 KeePassXC 這類工具),再搭配 file sync 的工具跨機器使用 (像是 Syncthing 這樣獨立確認每個 device 身份的方式),但方便性不會像這些商用方案這麼好用就是了...

這次故事好像還沒結束,遇到西方的長假,反應都比較慢...

讓使用者可以自己選擇 Push notification service 的 UnifiedPush

前幾天 Hacker News Daily 上看到的,F-Droid 寫了一篇文章介紹可以讓使用者自己選擇 Push notification service 的 UnifiedPush:「UnifiedPush: A decentralized, open-source push notification protocol (f-droid.org)」。

一般在 Android 平台上是透過 Google 自家提供的 FCM 傳遞 push notification 訊息:

A modern Android smartphone relies on a lot of services, from app stores and calendars to messaging and push notifications. Most of them have open alternatives, but until now, the only option for push notifications was Google’s proprietary service, Firebase Cloud Messaging (FCM).

但這樣很明顯會遇到隱私問題 (i.e. Google 可以知道所有的 push notification),所以一直都有要怎麼解決的討論。

而看起來 UnifiedPush 給了一個方案:使用者在 Android 手機上安裝一隻程式 (ntfy),這隻程式可以連到使用者指定的伺服器接收 push notification (可以是自架或是用現有的服務),另外一方面,當然也會跟 app 說要把 push notification 送到哪邊。

另外也考慮到使用者如果極度在意電池的問題,還是可以 fallback 回去使用 Google 的 FCM,也就是不影響現有使用者的體驗。

這樣就可以做到還是單一連線 (降低電力使用),但是是分散式的架構,而且使用者有一定的控制權。

目前支援的 app 看起來不多,但可以以預期後續 F-Droid 上面的 app 應該會有不少 app 會支援:「Apps using UnifiedPush」。

FBI 建議用擋廣告軟體降低瀏覽時的風險

在「Even the FBI says you should use an ad blocker」這邊看到的新聞,FBI 的公告則是在「Cyber Criminals Impersonating Brands Using Search Engine Advertisement Services to Defraud Users」這邊可以看到。

起因是有很多網路犯罪行為會透過購買廣告,在搜尋引擎上曝光誘導使用者點擊:

Cyber criminals purchase advertisements that appear within internet search results using a domain that is similar to an actual business or service. When a user searches for that business or service, these advertisements appear at the very top of search results with minimum distinction between an advertisement and an actual search result. These advertisements link to a webpage that looks identical to the impersonated business’s official webpage.

其中一種方式是,使用者輸入關鍵字想要下載某些特定的軟體,這時候網路犯罪者就會透過下廣告的方式,誘導使用者到假的網站下載有後門木馬的軟體:

In instances where a user is searching for a program to download, the fraudulent webpage has a link to download software that is actually malware. The download page looks legitimate and the download itself is named after the program the user intended to download.

這個方式讓我想到之前北韓政府對 PuTTY 的攻擊:「Trojanized versions of PuTTY utility being used to spread backdoor」。

而 FBI 建議個人的保護方式包括了 ad blocking extension,這算是減少被攻擊的管道:

Use an ad blocking extension when performing internet searches. Most internet browsers allow a user to add extensions, including extensions that block advertisements. These ad blockers can be turned on and off within a browser to permit advertisements on certain websites while blocking advertisements on others.

然後建議擋廣告軟體就是用 uBlock Origin,無論是 Chromium 系列的瀏覽器 (包括 Google Chrome),或是 Firefox 都有支援。

Twitter 新政策禁止推廣其他社交平台的連結

看到 Paul Graham 這個宣告:

裡面提到的新政策在「Promotion of alternative social platforms policy」這邊,直接禁止其他社交平台:

At both the Tweet level and the account level, we will remove any free promotion of prohibited 3rd-party social media platforms, such as linking out (i.e. using URLs) to any of the below platforms on Twitter, or providing your handle without a URL:

  • Prohibited platforms:
    • Facebook, Instagram, Mastodon, Truth Social, Tribel, Post and Nostr
    • 3rd-party social media link aggregators such as linktr.ee, lnk.bio

Hacker News 的討論上面,Paul Graham 有回應 (帳號是 pg),他又提出了一些猜測與見解,包含了他覺得這個新政策會被收回:「Paul Graham is leaving Twitter for now (twitter.com/paulg)」。

I'm not leaving Twitter. It seems more likely than not that Elon will reverse the ban on links to other social media sites. I just don't want to hang out there in the meantime. Plus given the way things are going, it seemed like a good time to learn about alternatives.

I still think Elon is a smart guy. His work on cars and rockets speaks for itself. Nor do I think he's the villain a lot of people try to make him out to be. He's eccentric, definitely, but that should be news to no one. Plus I don't think he realizes that the techniques that work for cars and rockets don't work in social media. Those two facts are sufficient to explain most of his behavior.

He could still salvage the situation. He's the sort of person it would be a big mistake to write off. And I hope he does. I would be delighted to go back to using Twitter regularly.

不過的確如他說的,這是個好機會嘗試其他的 social network...

Let's Encrypt 支援 ACME-CAA,可以再進一步限縮可以申請的使用人

前幾天在 Hacker News 上看到 Let's Encrypt 支援 ACME-CAA 的新聞:「Let's Encrypt now supports ACME-CAA: closing the DV loophole (devever.net)」,原文在「Let's Encrypt now supports ACME-CAA: closing the DV loophole」。

先前的「RFC 6844 - DNS Certification Authority Authorization (CAA) Resource Record」已經先定義了 DNS 上 CAA record 的規範,另外在 CA/Browser ForumBaseline Requirements 裡面也要求了 CA 簽發單位必須遵守 CAA 設定。

但這邊還是有一些風險,像是當網站被其他人控制後 (或是中間有 BGP hijacking 的方式取得 TCP 層的控制權),控制人就可以透過 http-01 的方式通過認證申請到 SSL certificate。而這次 Let's Encrypt 實做的 ACME-CAA 則是試著降低這個風險。

第一個是 accounturi 參數,可以指定只有某個 CA 裡的某個帳號可以申請,像是這樣:

example.com. IN CAA 0 issue "letsencrypt.org; accounturi=https://some/lets-encrypt/account-id"

第二個是限制 validationmethods 參數,限制只有某些方式可以申請,像是這邊限制只能透過 dns-01 申請:

example.com. IN CAA 0 issue "letsencrypt.org; validationmethods=dns-01"

不過支援 http-01 的不只 Let's Encrypt,至少也還有 ZeroSSLBuypass,後續可以看看其他家會不會跟上,以及會不會放到 Baseline Requirements 裡面...

John Carmack 離開 Meta (Facebook)

這幾天另外一個比較大的人事變化,John Carmack 決定離開 Meta (Facebook):「I resigned from my position as an executive consultant for VR with Meta.」,裡面直接提到的是效率問題,但應該是搞不定政治問題。

接下來他會跑去搞自己在八月弄的新創 Keen Technologies,主打 AGI 主題,八月當時的新聞在這:「John Carmack’s AGI startup raises $20M from Sequoia, Nat Friedman, Patrick Collison and others」。

不過有個好奇的點,是這篇的 url 是不帶 encrypted tracking parameters 的,這是怎麼拿到的...

WordPress 打算要支援 SQLite 作為後端資料庫

目前 WordPress 只有支援 MySQL,而昨天在 Hacker News 上看到 WordPress 有打算要支援 SQLite 作為後端資料庫的消息:「WordPress testing official SQLite Support (github.com/wordpress)」,原文在 GitHub 上:「Implement new experimental SQLite integration module」。

理論上對使用者會更方便,但對 extension 開發者會麻煩一些 (或是直接標不支援?),尤其是用到 MySQL 特有的語法就要注意了。

實質上 PHP + MySQL hosting 其實蠻常見的,這個作法有多少幫助就不知道了。

但突然想到,如果做一個 read-only 版本的 WordPress 站台,然後把 SQLite 的讀取部份改用 sql.js 之類的計畫,再把一堆 server side rendering 的部份變成 client side rendering,好像有機會可以整包直接上 GitHub Pages 之類的服務?雖然這樣有點拖褲子放屁...