本篇文章探討的也是資安系列問題，而這次的目標主角則是 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

--目前免費課程--
通過寫命令、學習理論和參加測驗，成為 Git 和 GitHub 的專家。 4小時之內學會 Git

🌿從這 4.5 小時的課程，你會學到
✔️充分了解 Git，包括 Git 理論，並應用到現實世界中
✔️理解 Git 和 GitHub 之間的區別，以及它們的用途
✔️理解 GitHub，它是什麼，以及如何與它互動
✔️理解什麼是原始碼控制，以及它背後的動機
✔️理解貯存庫( repository )是什麼，以及本地和遠端貯存庫之間的差異
✔️理解基本的和進階的 Git 命令，例如新增( add )、移除( remove )、提交( commit )和簽出( checkout )
✔️充分理解 Git 的分期暫存區 (staging area )，以及如何與它互動
✔️理解 Git 分支( Branches )以及如何新增( add )、移除( remove )和合併( merge )它們
✔️使用 Git 和 GitHub，讓你的專案讓全世界都看到

>udemy 現在有支援字幕逐字稿功能，詳細操作請參考 http://bit.ly/2O4lJok

小編上星期花了一點時間跟公司同事分享這幾年使用 Git 的經驗，其中也包含了 Git for Teams 的內容。如果你想要進一步改善 Git 工作流程的朋友，這本書真的是必備。

小編自己整理的內容還蠻多的，但有點可惜沒辦法包含所有常見的指令或情境，像是 rebase -i, stash, subtree, submodule 都沒提到，希望之後有機會再來重新整理一下。

## 簡易大綱

* 介紹四種權限模型
* rebase, merge, merge commit 的使用情境
* semver 的使用情境
* 與 redmine 的整合情境
* 外包使用情境
* 開所有權限的使用情境
* 合併時會發生衝突的原因
* reset, revert, checkout 等各種回復到特定點的使用情境
* cherry-pick 的使用情境
* gitignore 使用情境
* bisect, reflog 使用情境
* squash 使用情境
* ff 及 no-ff 的使用情境
* push -f 的使用情境
* 雲端 backend deployment 分享

#git #gitforteams #github #gitlab