本篇文章探討的也是資安系列問題，而這次的目標主角則是 MAC 系統上廣為流傳的 Homebrew 系統。

結論:
作者透過觀察 Homebrew 的 Github Action 流程，成功得上傳一個會列印一行的程式碼到 iterm2 套件中，讓所有安裝的使用者都會於 Terminal 上看到一行作者客製化的訊息。

本次的漏洞是作者刻意從 Homebrew 的 Vulnerability Disclosure Program 專案中去嘗試尋找可能的問題，所有的操作都有跟官方專案的人探討過流程，並且一切的 PoC 都是單純證明該攻擊的可行性，所以有興趣研究的人請遵循一樣的想法去做，不要認真的想攻擊。

原因:
1. Homebrew 透過 Github Action 執行 CI/CD 動作
2. Homebrew 撰寫了一個自動合併 Pull Request 的 Action
3. CI 內會透過一個Ruby的 Git Diff 第三方函式庫來驗證，只要符合下列條件就可以自動合併
- Modifying only 1 file
- Not moving/creating/deleting file
- Target filepath matches \ACasks/[^/]+\.rb\Z
- Line count of deletions/additions are same
- All deletions/additions matches /\A[+-]\s*version "([^"]+)"\Z/ or - -\A[+-]\s*sha256 "[0-9a-f]{64}"\Z
- No changes to format of versions (e.g. 1.2.3 => 2.3.4)

作者一開始想要從該規則下手，找尋有沒有可能塞入惡意攻擊並且騙過系統讓其自動合併，然而這些規則看起來沒有什麼太多問題，於是作者轉往其他領域去找尋問題，其中一個想法就是到底該 Ruby 的 Git Diff 是如何實作，也許從實作下手更有辦法去欺騙這一切。

很順利的是，作者真的於該函式庫中找到問題，對於一個 Git Diff 的結果來說，該函式庫會透過 +++ "?b/(.*) 這樣的正規表達式來判別檔案路徑的資訊而並非程式修改內容，譬如下列 diff
```
diff --git a/source file path b/destination file path
index parent commit hash..current commit hash filemode
--- a/source file path
+++ b/destination file path
@@ line information @@
Details of changes (e.g.: `+asdf`,`-zxcv`)
```

作者就開始思考，如果讓程式碼可以符合 +++ "?b/(.*) 的規則，是否有辦法讓程式碼不被視為一個檔案的修改，因此就可以修改多行程式碼但是讓 CI 系統認為只有一行程式碼於是進行自動合併

作者最初的想法如下，第一行用來放惡意程式碼，第二行用來偽裝檔案路徑，經過一番嘗試後作者真的成功塞入了類似 PRINTF 的程式碼到環境中並觸發自動合併。接者各地使用者透過 brew 安裝 iterm 版本都會看到使用者塞入的程式碼。
```
++ "b/#{Arbitrary codes here}"
++ b/Casks/cask.rb
```

原文還有更多作者的思路過程，有興趣的不要錯過

原文:
https://blog.ryotak.me/post/homebrew-security-incident-en/#fn:7
測試用PR:
https://github.com/Homebrew/homebrew-cask/pull/104191

Mehdi在Hackaday發表了CM4 custom PCIe開源專案，並將NAS機殼的3D列印檔案以及所需擴充母板的設計圖等資源上傳至GitHub，使用者能夠將Raspberry Pi 4運算模組改裝成4 Bay土砲NAS。

其電路板設計以Raspberry Pi基金會官方推出的Compute Module 4 IO Board為基礎，保留PCIe Gen2x1插槽以及RJ-45 GbE乙太網路、HDMI等端子，並移除其他與NAS應用無關的I/O端子，以利騰出4個3.5吋硬碟的安裝空間。

今天的文章不是一個技術文，反而是探討身為一個軟體工程師，該怎麼撰寫相關的技術文件

鑑於 WFH (Work From Hoem) 習慣的興起，人與人面對面的溝通減少，這意味即時的訊息傳遞變少了，取而代之的是非同步的訊息傳遞，簡單來說就是技術文件。

好的技術文件能夠讓需要的人快速找到問題，解決疑惑，但是一個好的技術文件到底該怎麼寫，這部分其實非常困難，並不是向程式碼一樣可以 copy&paste 馬上看到成果的，反而是需要時間練習，將整個過程與思路消化起來，用自己習慣的語言與形式將其撰寫出來。

首先，作者非常推崇由 Google 撰寫的系列文章，Tech Writing Course，整個課程內容不到兩小時，從不同章節來跟大家分享如何撰寫技術文章

接者撰寫技術文章時，作者個人是喜歡 divio 這個平台，不過更重要的則是其推薦的分類模式，根據內容分類成四大項

1. Tutorials - 學習導向
2. How-To Guides - 問題解決導向
3. Explanation - 深度理解導向
4. Reference - 資運分享導向

Google: https://developers.google.com/tech-writing
Divio: https://www.divio.com/

最後寫作語法方面，作者認為寫出一個能夠被有效搜尋的文章是非常重要的，譬如透過 word 等方式上傳檔案到系統中反而是一個不利於搜尋的方式。
取而代之的是，作者認為可以採用 Markdown 類似的語法作為基礎去撰寫文章，這種方式對於維護與撰寫都相對容易

今天有任何 Diagrams 的畫圖需求，可以考慮使用 Mermaid 這套解決方案，對於 GitLab/Azure 的使用者來說，已經內建其中。 GitHub/Atlassian Confluence 則有相關的 Plugin 可以安裝使用

最後則是文章的樣版內容，針對特定的文章格式，已經有不少的範本可以參考，透過這些範本可以更清楚的去描述你的內容，讓整體文章看起來更佳簡潔與流暢

1. Software Architecture Review Template
2. Architecture Decision Record Template
3. Incident Postmortem Template
4. DevOps Runbook
5. Decision Template
6. Writing Guidelines
7. OKR Template
8. Etc.

有興趣的點選原文學習更多
https://medium.com/better-programming/best-practices-when-documenting-your-code-for-software-engineers-941f0897aa0