幫你打理伺服器環境的 piku

但文件寫的很糟:「The tiniest PaaS you've ever seen. Piku allows you to do git push deployments to your own servers.」。

名字來自於 Dokku,另外應該是用到了 pico 這個數量級詞:

piku, inspired by dokku, allows you do git push deployments to your own servers, no matter how small they are.

這個工具是在「Piku: Allows git push deployments to your own servers (github.com/piku)」這邊看到的,就如同說明提到的,希望透過 git push 就可以發佈軟體。

不過在討論裡面也有人抱怨文件的問題,像是在 id=40625339 這邊就有人提到。

實際到 AWS 上開了一台 EC2 instance 測,看起來就是提供一包 script 把伺服器端設定好,包括了 Let's Encrypt + nginx 以及 SSHGit 相關的設定,接著你可以直接將這台 server 設為 git remote,然後就可以用 git push 推軟體上去了。

對於只是想要跑軟體,而且容易接 CI/CD 的方案來說還算 OK,但如果想要自己客製化 nginx 或是一些工具的情境就不是那麼適用了。

OpenSSL 決定把 release site 改到 GitHub 上

OpenSSL 宣佈了之後會以 GitHub 為主要發佈平台:「Releases Distribution Changes」。

舊的 ftp & rsync 以及 git protocol (9418/tcp 的協定) 都打算淘汰掉:

We’re no longer using our old ftp, rsync, and git links for distributing OpenSSL. These were great in their day, but it’s time to move on to something better and safer.

其中 FTP 與 rsync 都已經停掉了,接下來是今年六月要停掉 ftp.openssl.org 的 HTTPS 介面以及 git.openssl.org 的 git protocol:

ftp://ftp.openssl.org and rsync://rsync.openssl.org are not available anymore. As of June 1, 2024, we’re also going to shut down https://ftp.openssl.org and git://git.openssl.org/openssl.git mirrors.

然後主力轉戰到 GitHub 上面:

GitHub is becoming the main distributor of the OpenSSL releases.

算是省事的作法,畢竟自己弄 infrastructure 不算太輕鬆

另外 OpenSSL 畢竟是個歷史頗久的軟體了,有「遵循古法」所以 release 都會有 PGP/GPG sign,這部分如果還是獨立於 GitHub 平台的話就沒什麼問題,代表還是有非 HTTPS 的 integrity 方法可以確認檔案沒被抽換過。

(但如果綁進 CI/CD 流程的話就廢了?)

讓 git blame 可以忽略掉某些 restyle/reformat 的 commit

在 X (Twitter) 上看到這則推,提到了可以讓 git blame 自動忽略掉某些 restyle 或是 reformat 的 commit:

查了一下是在 2019 年八月出的 2.23.0 引入的,從 Documentation/RelNotes/2.23.0.txt 可以看到說明:

 * "git blame" learned to "ignore" commits in the history, whose
   effects (as well as their presence) get ignored.

除了可以在專案內單獨設定外,也可以在 ~/.gitconfig 內設定:

[blame]
    ignoreRevsFile = .git-blame-ignore-revs

我是拿 rss-bridge 裡的 bridges/ARDMediathekBridge.php 測試,可以看到這個檔案最後的修改是「Reformat codebase v4」這包,也就是被放進 ignore 清單的 commit。

這個 commit 中,對 ARDMediathekBridge.php 這個檔案的 diff 則可以在「這裡」看到。

從 diff log 可以看到幾乎是所有的縮排都被改變了,但 GitHub 上面的 Blame 資訊,以及拉下來後用 git blame 或是 tig blame 可以注意到大多數有意義的地方都有被找出來「還原」,只有很簡單的內容沒有被辨識出來 (像是整行只有 /* 或是 { 之類的地方)。

看起來還是蠻有用的,先丟進 dotfiles 裡面了...

Gitea 推出了自己的 Cloud 版本:Gitea Cloud

Gitea 推出了 Gitea Cloud:「Gitea Cloud: A brand new platform for managed Gitea Instances」。

費用是 $19/user/mo 或是 $190/user/y,這個價位會對應到 GitHub 裡 Enterprise 等級的費用 ($21/user/mo 或是 $231/user/y)。GitLab 的話 Premium 的費用是 $348/user/y,高出不少...

依照官方的說明,看起來是 instance 直接拆開,所以也可以選擇 region:

Dedicated instances, full control in your hand:

Chose your cloud provider and region

這應該算是架構面上與其他兩家最大的差異了,走的應該是 multi-tenancy 的模式。但市場接受度不曉得如何...

FreeBSD 14.0 釋出

FreeBSD 14.0-RELEASE 的公告也出來了:「FreeBSD 14.0-RELEASE Announcement」,比較完整的 release notes 在「FreeBSD 14.0-RELEASE Release Notes」。

先從官方列的 highlight 來看,首先比較重要的是 GENERIC kernel 支援 1024 cores:

FreeBSD supports up to 1024 cores on the amd64 and arm64 platforms.

看了一下 commit log 是從 256 變成 1024

先就 x86-64 這邊來看,目前「家用」最多的應該是 AMD7995WX (96 cores),舊版的 256 限制應該也還能撐住,但看 commit log 有提到,主要是預期這幾年應該會有更暴力的機器出現。

另外一塊是伺服器端,Intel 這邊有 8 sockets 的版本 (參考「Intel Xeon Sapphire Rapids to Scale to 4 and 8 Sockets」),如果都是接 8490H 的話就是 480 cores 了。

ARM 的話好像也可以堆,但不熟...

另外一個提到的重點是 TCP 預設的 congestion control 改成 CUBIC

The default congestion control mechanism for TCP is now CUBIC.

翻 commit log 可以看到是從 NewReno 換成 CUBIC 的,這樣就跟 Linux kernel 預設值一樣了。

再來比較重要的是在 release notes 裡面提到的,FreeBSD 15.0 將會拔光 32-bit 環境的支援,只留 armv7,這代表 Raspberry Pi 第一代的 armv6 也被淘汰掉了:

FreeBSD 15.0 is not expected to include support for 32-bit platforms other than armv7. The armv6, i386, and powerpc platforms are deprecated and will be removed. 64-bit systems will still be able to run older 32-bit binaries.

然後有些我自己翻覺得還蠻有趣的。

首先是看到 non-root 的 chroot

The chroot facility supports unprivileged operation, and the chroot(8) program has a -n option to enable its use. a40cf4175c90 (Sponsored by EPSRC)

然後把 OpenSSH 內對 FIDO/U2F 的支援開起來了:

The use of FIDO/U2F hardware authenticators has been enabled in ssh, using the new public key types ecdsa-sk and ed25519-sk, along with corresponding certificate types. FIDO/U2F support is described in https://www.openssh.com/txt/release-8.2. e9a994639b2a (Sponsored by The FreeBSD Foundation)

ASLR 預設開啟:

Address Space Layout Randomization (ASLR) is enabled for 64-bit executables by default. It can be disabled as needed if applications fail unexpectedly, for example with segmentation faults. To disable for a single invocation, use the proccontrol(1) command: proccontrol -m aslr -s disable command. To disable ASLR for all invocations of a binary, use the elfctl(1) command: elfctl -e +noaslr file. Problems should be reported via the problem reporting system, https://bugs.freebsd.org, or posting to the freebsd-stable@FreeBSD.org mailing list. b014e0f15bc7 (Sponsored by Stormshield)

然後先前被罵臭頭的 WireGuard 支援也放回來了:(「FreeBSD & pfSense 上的 WireGuard 問題」)

The kernel wg(4) WireGuard driver has been reintegrated; it provides Virtual Private Network (VPN) interfaces using the WireGuard protocol. 744bfb213144 (Sponsored by Rubicon Communications, LLC ("Netgate") and The FreeBSD Foundation)

然後看到 Netflix 贊助的 kTLS 支援 TLS 1.3:

KTLS (the kernel TLS implementation) has added receive offload support for TLS 1.3. Receive offload is now supported for TLS 1.1 through 1.3; send offload is supported for TLS 1.0 through 1.3. 05a1d0f5d7ac (Sponsored by Netflix)

然後 FreeBSD 長久以來 root 預設用的 /bin/csh 改成 /bin/sh 了:

The default shell for the root user is now sh(1), which has many new features for interactive use. d410b585b6f0

預設的 MTA 變成 dma (Dragonfly Mail Agent),看名字加上翻了一下 manpage,確認是從 Dragonfly BSD 移植過來的:

The default mail transport agent (MTA) is now the Dragonfly Mail Agent (dma(8)) rather than sendmail(8). Configuration of the MTA is done via mailer.conf(5). sendmail(8) and its configuration remain available. a67b925ff3e5

然後 portsnap 被拔掉了,現在就建議直接用 git 拉了,算是功成身退了:

The portsnap(8) utility has been removed. Users are encouraged to fetch the ports tree by using pkg install git and then git clone https://git.FreeBSD.org/ports.git /usr/ports. df53ae0fdd98

而 mergemaster 也被換成 etcupdate 了:

mergemaster(8) has been deprecated. Its replacement is etcupdate(8). 398b12691b4f (Sponsored by The FreeBSD Foundation)

然後支援 tarfs,而且可以用 zstd

The tarfs(5) file system has been added, which is backed by POSIX tar archives optionally compressed with zstd(1). 69d94f4c7608 (Sponsored by Juniper Networks, Inc.) (Sponsored by Klara, Inc.)

好久沒看 FreeBSD 的 release notes...

Firefox 宣布從 Mercurial 換到 Git

Firefox 宣佈從 Mercurial 換到 Git:「Firefox Development Is Moving From Mercurial To Git」。

目前是 Mercurial 與 Git 都支援,理由是不想要維持兩套:

For a long time Firefox Desktop development has supported both Mercurial and
Git users. This dual SCM requirement places a significant burden on teams which
are already stretched thin in parts. We have made the decision to move Firefox
development to Git.

不過不知道決策的過程到底是怎麼產生的,算是 Mozilla 的老問題了...

讓 git diff 可以直接顯示 SQLite3 裡面的差異

從「Tracking SQLite Database Changes in Git」這邊看到的,然後作者 Simon Willison 又是從 Lobste.rs 的「Tracking SQLite Database Changes in Git databases」這邊看到的,而原文在「Tracking SQLite Database Changes in Git」。

一般 SQLite 檔案的 diff 會出現這樣:

diff --git a/a.sqlite3 b/a.sqlite3
index a4a8cfa..714f34a 100644
Binary files a/a.sqlite3 and b/a.sqlite3 differ

作者想要透過 sqlite3 的指令加工,讓 git-diff 的演算法可以展現出像是這樣的指令:

diff --git a/a.sqlite3 b/a.sqlite3
index a4a8cfa..714f34a 100644
--- a/a.sqlite3
+++ b/a.sqlite3
@@ -3,4 +3,5 @@ BEGIN TRANSACTION;
 CREATE TABLE tbl (id SERIAL, username TEXT, password TEXT, created_at INT, updated_at INT);
 INSERT INTO tbl VALUES(NULL,'gslin','$1$yRgoNPev$nOc5Hpr5JZAYISbHjp7LA/',0,0);
 INSERT INTO tbl VALUES(NULL,'dk','$1$yRgoNPev$nOc5Hpr5JZAYISbHjp7LA/',0,0);
+INSERT INTO tbl VALUES(NULL,'darkkiller','$1$yRgoNPev$nOc5Hpr5JZAYISbHjp7LA/',0,0);
 COMMIT;

方法是先設定 diff 工具部分,這個可以放到 ~/.gitconfig 裡面:

[diff "sqlite3"]
    binary = true
    textconv = "echo '.dbconfig trusted_schema no\n.dump' | sqlite3"

這邊跟原文不太一樣,主要是參考了 SQLite 官方網站上「Defense Against The Dark Arts」這邊的「Untrusted SQLite Database Files」部分,增加了 .dbconfig trusted_schema no 的設定加減擋一下...

然後我依照「Where should I place my global 'gitattributes' file?」這邊的問題與解答,把 attributes 設定放在 ~/.config/git/attributes 裡面:

*.sqlite diff=sqlite3
*.sqlite3 diff=sqlite3

這樣就會對這個使用者所有的 git repository 都生效。

作者原文提到的方法也可以用,不過主要是在單一 repository 裡面設定,針對 *.db 這類只有在 repository 內才會知道規則的告訴 git 要怎麼認。

Gitea 推出 Actions

Hacker News 上看到 Gitea 出 1.19 的消息:「Gitea 1.19 (gitea.io)」,在討論裡面就有人提到 Gitea Actions,從名字就知道是抄自 GitHub Actions,算是 Gitea 開始建立自己的 DevOps 生態系的一個重要功能。

目前這個功能還被掛在 EXPERIMENTAL 上,預設是關閉的,而且我自己試了一下也的確試跑不太起來,出現這樣的錯誤訊息,暫時也沒空去細追:

time="2023-03-28T17:36:37Z" level=info msg="poller: request stage from remote server" func=pollTask
time="2023-03-28T17:36:37Z" level=error msg="cannot accept task" error="unknown: rpc error: code = Internal desc = pick task: CreateTaskForRunner: Error 1366 (HY000): Incorrect string value: '\\xF0\\x9F\\x8E\\x89 T...' for column 'name' at row 1" func=pollTask
time="2023-03-28T17:36:37Z" level=error msg="can't find the task: unknown: rpc error: code = Internal desc = pick task: CreateTaskForRunner: Error 1366 (HY000): Incorrect string value: '\\xF0\\x9F\\x8E\\x89 T...' for column 'name' at row 1" func=Poll

接下來會有更多人跳進去試,之後再來看看成熟度如何...

GitHub 宣佈將在 2024 移除對 Subversion 支援

GitHub 從 2010 年的愚人節時宣佈支援 Subversion:「Announcing SVN Support」,雖然是愚人節的功能,但這個功能是會動的。

而這個功能出現十多年後,可以預期用的人愈來愈少。前幾天 GitHub 宣佈將在大約一年後的 2024/01/08 停止支援 Subversion:「Sunsetting Subversion support」。

然後在 Hacker News 上的討論「GitHub Sunsetting Subversion Support (github.blog)」則是直接讓 Scott Chacon (GitHub co-founder,同時也是第一篇公告文的作者 + 這個功能的兇手之一) 出來解釋當初搞出這個東西的前因與後果,還有一些感想。

裡面有提到這個功能當初推出來的時候是個好玩的性質,但意外的在上線後發現也讓一些老系統可以比較容易轉移:也就是讓 developer 可以先開始用 Git,但 CI 類的工具可以先不用改。

As one of the GitHub cofounders and the brainchild of this particular feature, I want to let everyone know that this is maybe the funniest thing I've ever done.

We released this feature and published the announcing blog post, on April Fool's Day, 2010. I remember demoing it to the other GitHub guys and saying how funny it would be if we made this an April Fool's day post as though it was a big stupid joke but then it actually completely worked on every repository we had and we all thought it would be great. Until nobody believed us. Which in hindsight we should have seen coming, since that was the joke, but nobody actually tried it. Then people tried it and it worked and they thought it was a trick or something.

It was really helpful for people migrating from legacy SVN based systems to us (CI and stuff) but I'm surprised to some degree that it's still running 13 years later when nobody is really facing that issue anymore. And I'm still undecided if the joke was worth the massive confusion it caused. But if I'm pressed, I would say that I would 100% release it on April Fool's Day again.

不過想要拔掉這個功能的起因不知道是什麼,技術債不知道有多少...

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 項目的開發人員一直在努力使其更強大、更安全,並且將繼續努力。