如何避免 Commit Message 拼錯字?

文件打錯字還好,隨時可以修。 但在 commit message 中打錯字,可是會流傳千古。

身為一個 RD,有個極簡的解決方法.. 把底下這行設定放到 .vimrc 內即可。 (O

1
autocmd FileType gitcommit setlocal spell

(對於屬 Git commit message 的 buffer 自動啟用 spell check 功能)

設定完之後,當出現 vim 不認識的單字時,就會有醒目的顏色提示, 提醒自己該回頭看一下是不是又拼錯字了。

當然,要有舒適的拼字檢查體驗,字典檔的維護也是很重要的一環。 不過那又是另一個話題了..

Reference

GitHub 即日起支援使用 Security Key 進行 Git 操作

GitHub 開始支援使用 security key 進行 Git 操作啦!

這應該是各家科技巨頭當中,第一個支援 security key 進行 SSH login 的服務吧。 筆者昨天 5/10 才在公司內分享如何使用 security key 來做 SSH login, 沒想到 Yubico 和 GitHub 也剛好在昨天一起同步更新 blog 文章,通知大家這個新功能。 喜極而泣..

以下簡單介紹如何使用這個新功能。 為了方便解說及避免誤會,後述內容均以正式名稱 authenticator 代稱 security key。

如何使用

首先當然要有一把 authenticator,如果還沒有,趕快去買一把囉。 :D

第一步,在 authenticator 內產生新的 key pair。

產生 key pair 的流程和傳統放在檔案系統上的差不多,只是 key type 要指定代表 authenticator 的 type。

1
ssh-keygen -t ecdsa-sk

產生的過程,根據不同的 authenticator,會有要求按一下 且/或 輸入 PIN code 驗證身分。 此步驟會在 authenticator 內產生一組 key pair,並將 public key 寫到檔案系統上。 平常放 private key 的那個檔案還是會產生,不過這次裡面放的會是一個 key handle。

第二步,透過 GitHub 的 web UI 上傳 public key

上傳完之後,沒意外就可以順利使用了,可以試著 clone 一些 project

1
2
3
4
$ git clone git@github.com:github/secure_headers.git
Cloning into 'secure_headers'...
Confirm user presence for key ECDSA-SK SHA256:........
User presence confirmed

若確認 OK,之後的 Git 操作都可以透過隨身攜帶的 authenticator 保護, 只要按一下 authenticator 即可。

設定完之後,若沒有拿出 authenticator,就不能進行 push / pull 操作。 只要確保 authenticator 還在身上,就可以安心睡大覺。 (再也不用擔心 private key 放在公司電腦上會被摸走了!)

進階使用方式

FIDO 2 authenticator 博大精深,除了上述的基本使用流程外,還有些細節可以設定。

以下分別介紹三個進階使用技巧:

要求身分驗證 (User Verification) 才能使用 Authenticator

根據每個人平常保管鑰匙習慣的差異,可能有人會擔心 authenticator 真的被摸走。

但 authenticator 也有支援一定要驗甚身分 (e.g. PIN code or 指紋辨識) 後才能 使用內部的 key pair 的功能。

要如何使用呢? 只要在產生 key pair 的過程中多下一個 flag 即可。

1
ssh-keygen -t ecdsa-sk -O verify-required

若之後要使用由此方式產生的 key pair,除了手指按一下 authenticator 之外,還會要求 使用者輸入 PIN code 才能順利完成操作。如此即使 authenticator 被偷走了,也不用太緊張。

全自動使用 Authenticator (避免 User Presence Check)

若把 authenticator 插上電腦後,想要隨時隨地都進行 push / pull, 但不要每次都手按一下 authenticator。這種自動化的使用情境 OpenSSH 其實也是有支援的。

使用的方式也是在產生 key pair 時多帶一個參數。

1
ssh-keygen -t ecdsa-sk -O no-touch-required

同時在將 public key 部屬到目標機器上時,在 public key 該行前面多下 no-touch-required 即可。 (詳情請見 ssh-keygen(1)sshd(8))

以此方始產生的 key pair 在使用時就不需要每次都手按一下,可以全自動使用。

不過,雖然 OpenSSH 有支援此種使用情境,但目前 GitHub 禁止這種使用方式

節錄自上述 blog 文章

While we understand the appeal of removing the need for the taps, we determined our current approach to require presence and intention is the best balance between usability and security.

所以在 GitHub 上,若想要全自動操作,只能回去用一般的 SSH key 或 API token 囉。

避免手動複製 Key Handle

前面有提到,原先檔案系統上用來放 private key 的檔案會變成拿來擺放 key handle。

這意味著,當我們想在新的機器上透過 SSH 進行 Git 操作時,除了拿出 authenticator 之外, 也需要把原先的 key handle 檔案複製到新的機器上。 且若 key handle 檔案掉了,該組 key pair 就不能使用了。

若要避免此問題,就要用上 authenticator 的另一個進階功能 discoverable credentials / resident keys 。

1
ssh-keygen -t ecdsa-sk -O resident

使用此類型的 key pair 時,會在 authenticator 上消耗一些儲存空間。但換來的好處是, 使用者可以在新的機器上,把 key handle 從 authenticator 內抽出來。

1
ssh-keygen -K # extract discoverable credentials

如此就不用手動複製擺放 key handle 的 private key 檔案了。

但要注意的是此類型 key pair 會消耗 authenticator 的空間。 每把 authenticator 可以放多少 key pair 要再自行查閱官方文件。

結語

以上介紹了基本使用情境及三種可能的進階使用方式。

筆者在 2014 年第一次注意到 FIDO (U2F) 標準,當時就在想像沒有密碼的世界。 如今,藉由 FIDO 2 security key 的普及,當初所想的美好願景似乎在慢慢地實現中..

希望未來能看到 security key 運用在更多場景上!

Samba 內檔案的異常執行權限

許多場合會利用 Samba 來建立給所有工作者共用的 SMB 工作目錄。

SMB 是 Microsoft 針對 Windows 體系設計的 protocol,但因為種種因素, 目前 Mac 及各 Linux 桌面發行版也都有不錯的 SMB client 支援。 已 SMB 提供共用的工作目錄,似乎已成為最常見的協同工作方法。

在另一方面,Samba 是一套基於 Unix 環境開發的開源 SMB server 實作。 但因為 Windows 與 Unix 在檔案系統上設計的根本性差別,儘管 Samba 歷史悠久且功能齊全, 仍然會有一些先天性的問題。

為了解釋問題到底從何而來,以下要簡單介紹一下 Windows 與 Unix 的檔案相關特性。

Windows File Attribute 與 Unix File Mode

傳統上,Windows 系統下的每個檔案都會需要有以下四個屬性:

  • Archive: 紀錄此檔案在上次備份後是否更動過。
  • Hidden: 紀錄此檔案是否要隱藏。Windows 內建 dir 或檔案總管均會遵從此設定。
  • System: 紀錄此檔案是否爲系統檔案。
  • Read-only: 紀錄此檔案是否只能讀取。

Unix 作業系統採取了與 Windows 不同的設計。 在 Unix 內,每個檔案紀錄針對檔案擁有者、檔案擁有群組及其他人分別紀錄三組權限

  • Readable: 檔案是否可讀取
  • Writable: 檔案是否可寫入
  • Executable: 檔案是否可執行

現在我們可以知道,Windows 與 Unix 對於檔案應該紀錄的特性/模式其實有不一樣的要求。 許多和檔案系統相關的功能也會用不同的方式來達成。

比方說,有關檔案 是否隱藏 這件事情,在 Windows 上會有一個獨立的 attribute 來處理。 而在 Unix 上,則是依據 “. 開頭的檔案應被隱藏” 的常規。除了檔名看起來有點不一樣之外, 隱藏檔案和一般檔案在檔案系統裡沒有差別。

另外我們也可以注意到Windows 和 Unix 對於 可執行 這個概念的處理方式也不同。 在 Unix 的世界中,每個檔案的 mode 中會紀錄這個檔案是否可執行。而在 Windows 中, 檔案並沒有是否可執行的概念,而是讓作業系統維護一個表單,裡面紀錄各種副檔名的檔案應該如何開啟或執行。

Samba 的設計與產生的問題

Samba 是個 SMB 的 server 實作,作為在 Unix 環境上跑的服務,但同時也要支援 Windows 的 file attribute,亦即前述提到的 Archive、Read-only 等。這些 attribute 是必得以某種 方式存在 Samba server 上。在這裏 Samba 的實作非常有趣:

利用 Unix 環境中 Windows 用不到的 executable bit 來存放 Windows 需要的 file attribute。

具體來說,Archive、System 與 Hidden 屬性會分別存在擁有者、擁有群組與其他人的 file mode 的 executable bit 當中。而 Read-only 則是影響檔案擁有者的寫入權限是開啟。 簡單圖示如下:

1
2
3
4
5
6
    Owner    Group    Others
+----------------------------+
| r w x r w x r w x |
+-^--^--^--------^--------^--+
| | | | |
ReadOnly Archive System Hidden

但此做法舉其實會導致其他問題。這會其他在 Mac 或 Unix 環境下掛載 SMB share 的使用者, 會看到檔案有時莫名的變成可執行,或原本可執行的 script 突然變成不可執行。

於是乎,在 Window 與 Linux 混用的工作環境中,RD 的 terminal 下常會看到一片花花綠綠的 source code 資料夾。(一般 shell 都會預設開 ls 的 colorize 選項)

Executable Bit 異常的解決方式

若要避免 Samba 的這類行為,可以在 smb.conf 中加入以下設定

1
2
3
4
map archive = no
map system = no
map hidden = no
map read only = no

如此 Samba 就不會嘗試利用 Unix 的 file mode 來存放這些 attribute。

又或是如果想支援 Windows 的 attribute,但又不想影響 Unix 下的執行權限,可以將這些 attribute 寫進 extended attributes 裡。這需要使用以下設定

1
store dos attributes = yes

碎碎唸

作為一個軟體工程師,常聽到 Every detail matters 或其他類似精神的標語。 魔鬼蔵在細節裏,確保每個細節的正確(或至少看起來正確)是每個工程師都應該追求的境界。 而這個追求細節的精神,必須從乾淨的工作環境開始做起。

為什麼會寫出這邊文章?其實就只看到公司的 VCS 內各種怪異的檔案權限, 感到困惑而已。清楚的變數命名、符合直覺的 API 設計有助於開發人員理解專案。正確的檔案權限 其實也是如此。設定檔應該是 rw-,script 應該是 r-x,不違背直覺的專案狀態才不會 阻礙工程師工作。

當然,一切的根本原因還是在於 Samba 的預設設定會把 Archive attribute map 到 file mode 裡面。在 Window 環境工作的工程師一般都是在無意的情況下把 file mode 的異動 寫道 VCS 裡面。這時只能抱怨爲何當年 Samba 的作者要做出這種設計了。

相關連結