Travis CI 停止提供服務給 Open Source 專案

Hacker News Daily 上看到這個,在講 Travis CI 終止對 open source 專案的服務:「Travis CI is no longer providing CI minutes for open source projects」。

有不少專案已經改用其他 CI 服務的 free tier 做,像是 GitHub ActionsCircleCI 都有提供。

看了一下 Hacker News 上的討論,不少人是可以理解不會有永遠免費的午餐,只是這次 Travis CI 的處理讓大家覺得比較討厭的是,一方面官方一直跟 open source community 說我們很願意支援 open source community (前幾個禮拜官方 blog 還有發文重申這件事情),另外一方面是一直在朝著關閉服務走:從限制 10K credits 開始,到現在不會再提供 credit 給 open source 專案。

有人整理了對應的時間軸:

? 2018: Travis CI announces they are starting the process of merging travis-ci.org, which provided free builds for OSS projects, into travis-ci.com, which until then was only for paying customers. They promise OSS builds will continue to be free.

? 2020: Travis CI announces they are shutting down travis-ci.org at the end of the year and all projects have to move to travis-ci.com. They promise OSS builds will continue to be free.

Early November 2020: travis-ci.com switches from providing unlimited builds for OSS to only providing 10k one-time credits by default. Projects that meet certain guidelines (e.g. no one paid to work on them) can apply for recurring credits.

Later in November 2020: CI for many OSS projects that had migrated to travis-ci.com starts to fail, as they've exhausted their 10K credits.

Dec 2020: If what is reported here is accurate, Travis CI stop providing any recurring OSS credits. CI breaks for the remaining OSS projects on travis-ci.com.

Jan 2021: travis-ci.org shuts down. CI will be broken for all projects using it. They'll have the option of migrating to travis-ci.com, but will soon break again as they exhaust their 10k credits.

這種服務非常吃 CPU resource,大型專案如果每個 push 或是每個 pull request 都跑一輪完整的測試,成本應該不低,大概可以理解為什麼 Travis CI 會這樣決定,不過態度就...

其他家有提供 free tier 的 CI 最近應該會湧入不少人,這幾個月可以看看其他家會不會也跟進,另外一方面應該也會有人開始自架?

打穿蘋果的企業網路

上個禮拜丟出來很轟動的一篇「side project」,三個月不斷的打穿蘋果的企業網路:「We Hacked Apple for 3 Months: Here’s What We Found」,對應的 Hacker News 討論可以在「We Hacked Apple for 3 Months (samcurry.net)」這邊看到。

在最後面有提到這本來是打好玩的,但後來就投入愈來愈多時間進去:

This was originally meant to be a side project that we'd work on every once in a while, but with all of the extra free time with the pandemic we each ended up putting a few hundred hours into it.

這是五個人通力合作打了三個月出來的成果,依照他們的回報數字,共打出了 55 個「洞」,考慮到週休的情況,幾乎是天天打洞出來玩:

There were a total of 55 vulnerabilities discovered with 11 critical severity, 29 high severity, 13 medium severity, and 2 low severity reports. These severities were assessed by us for summarization purposes and are dependent on a mix of CVSS and our understanding of the business related impact.

文章裡沒有對每個安裝漏洞都描述,但有針對一些比較「有趣」的漏洞說明,雖然看了以後知道是怎麼一回事,但對這些手法沒這麼熟,你叫我打我還是不會打啊 XDDD 反而是當作表演藝術來看...

Scrum 的適合場景:「外包團隊」

在「工程師幹話」的『老闆想要成長 — 我們就讓老闆「看見」成長』這篇裡面提到了 Scrum

台灣最接近 Scrum 的組織是國軍。一個 Scrum team 不應該太大,所以一個班只有九個人,然後有一個直接的 PO,叫做班長;每天工作之前都有的 standup meeting 呢,叫做早點名;至於固定時間都有的 retrospective 會議呢,叫做榮團會。所以,如果我們真心相信有個 Scrum 外型的組織就可以提昇效率的話,就等於,我們居然會願意相信:中華民國國軍是個高效率的組織。

這篇文章花了半個小時才看完,真是有夠長的... 裡面描述了很多事情,與一些時間線對一下,大概知道哪個段落在講什麼事情。

之前跟其他朋友聊到 Scrum 的時候我都有先說我的結論,就是我覺得 Scrum 只適合用在「外包團隊」與「業主」之間的互動,目前看到的其他情境都不合理。

利用 Scrum 的架構,可以改善傳統的外包情境:

  • 通常業主給不出完整的 spec,於是外包團隊無法估算成本,所以外包團隊利用 Scrum 機制,每個 sprint 可以要求業主每次提供一點 spec,然後依照這些 spec 估時 (點數) 並且計費 (換算成 manhour,然後得出人力成本與利潤)。
  • 如果業主一開始就可以給出完整的 spec 也沒關係,spec 先切出第一個 sprint,在每個 sprint 結束後,跟業主確認下一輪的內容。

Scrum 在外包團隊可以掌握的範圍,大幅改善了傳統外包簽約的困難。

對於業主不知道要做什麼的,可以降低業主一開始就需要提供很多資料 (spec) 的門檻。

而對於業主已經知道要做什麼的,可以提供修改的時間點。這對於超長期的合作時特別有用,像是軍事外包案常常一個外包就是五年或是更長,sprint 的機制讓業主可以在中間很自然的修改規格,而不是加簽附約的方式修改 spec。

另外,在簽署 Agile Manifesto 的 17 人名單也可以看出來,裡面專搞 Scrum 的差不多都是在外包或是在當顧問,那麼,推出一個「學派」再告訴客戶這樣做會更好,是個自然不過的事情了。

而從 Scrum 裡面的其他細節也可以看出來他們怎麼把外包團隊想要避開的問題「包裝」起來賣給客戶:

  • 透過大幅縮短 milestone 的設計「sprint」,可以依照每個 sprint 收款,也因為通常 sprint 的單位長度比 milestone 的時間短很多,外包團隊的現金流的品質會比以前好。
  • 在 daily standup meeting 可以取得目前專案的進度,一方面可以在內部追蹤,避免有項目出事,另外一方面可以向業主回報,讓業主有安全感。
  • 再來是 Scrum 要求每個 sprint 的內容不可以被變更的問題,這點則是避免了客戶端的手伸進來,而改變了成本結構導致虧本。但也提供客戶修改的空間:允許下個 sprint 修改,重點在於該收的錢有收到。

而以上的這些東西放到公司內就會變得很奇怪:

  • 外包公司不在意手上做的產品是不是合理,只在意工時 (人力成本) 合不合理。而公司內的團隊合理性的才會下去執行,甚至有可能做到一半才發現不合理而需要全面中斷 (因為 startup 常常在做一些以前的人沒做過的事情)。
  • 在外包公司裡,PO 無法伸手進 sprint 修改既定事項,要硬改就是得照合約先把這個 sprint 的錢付掉,所以這情不太會發生。而在公司內 PO 常常是老闆或是大主管,伸手進來改不會有什麼賠償成本,Scrum 的這條規定在公司裡面就是沒有罰則的法律。
  • 公司成員遇到問題卡住 (不知道怎麼解、自己不會解、需要別人一起幫忙解) 或是進度會跟不上的情況應該是發現時馬上通知,而不是擺爛等到隔天的 standup meeting 才提出來。於是你會發現找不到 daily standup meeting 的目的。

另外一個問題是:

  • 營運端的成本造成估時不準確。像是上線後,系統的 downtime、bugfix 而使得原來團隊成員需要支援的情況,導致一個人的輸出不可能有 40 hours/week。

這點也是在外包公司不會遇到,而公司內不可避免會遇到的情況。

差不多把該講的都列出來了,這是我覺得外包時用 Scrum 適合的原因。

擋廣告的 Pi-hole

Pi-hole 最近愈來愈紅的一個計畫,技術上是透過 DNS 把不想要的網域名稱擋掉,通常就是擋掉各種 tracking 與廣告系統。

因為是透過 DNS 擋,當然沒有像 uBlock Origin 直接 parse 網頁內容來的有效,但對於方便性來說則是大勝,只需要在網路設備上設一次,所有的裝置都可以用到。

剛剛看到「How a Single Raspberry Pi made my Home Network Faster」這篇,可以看到 Pi-hole 有不錯的介面可以看 (讓你自我感覺良好?XD):

文章作者跑了一個月後,也直言還是有些東西會壞掉,需要設定一些白名單讓他動:

Review after 1 month in operation
The Pi-Hole has been running for 1 month now on my home network. I have had to whitelist 1 or 2 URLs which was blocking a reset of an Alexa which had an issue, and a video conferencing system had all sorts of tracking and metrics built in which were causing some havoc until I whitelisted them. Otherwise, the Pi has been chugging along at 8% memory utilization, and the network is considerably faster when surfing the web.

對於手癢自己玩應該還可以,拿到辦公室的話應該會有不少東西掛掉... (不過文章作者好像想這樣做)

非 Google 的 Android 手機環境

主要是記錄下來,完全不靠 Google 目前還是有點難度:「De-Googling my phone」。

主要是刷機成 LineageOS (還是 Android),然後上面不裝 OpenGApps,而是靠其他軟體來補足... 在英文版維基百科的「List of free and open-source Android applications」也有不少資訊可以看。

另外一個蠻重要的應該是 microG Project,不過在文章裡沒提到...

Spectre 與 Meltdown 兩套 CPU 的安全漏洞

The Register 發表了「Kernel-memory-leaking Intel processor design flaw forces Linux, Windows redesign」這篇文章,算是頗完整的說明了這次的安全漏洞 (以 IT 新聞媒體標準來看),引用了蠻多資料並且試著說明問題。

而這也使得整個事情迅速發展與擴散超出本來的預期,使得 GoogleProject Zero 提前公開發表了 Spectre 與 Meltdown 這兩套 CPU 安全漏洞。文章非常的長,描述的也比 The Register 那篇還完整:「Reading privileged memory with a side-channel」。

在 Google Project Zero 的文章裡面,把這些漏洞分成三類,剛好依據 CVE 編號分開描述:

  • Variant 1: bounds check bypass (CVE-2017-5753)
  • Variant 2: branch target injection (CVE-2017-5715)
  • Variant 3: rogue data cache load (CVE-2017-5754)

前兩個被稱作 Spectre,由 Google Project Zero、Cyberus Technology 以及 Graz University of Technology 三個團隊獨立發現並且回報原廠。後面這個稱作 Meltdown,由 Google Project Zero 與另外一個團隊獨立發現並且回報原廠。

這兩套 CPU 的安全漏洞都有「官網」,網址不一樣但內容一樣:spectreattack.commeltdownattack.com

影響範圍包括 IntelAMD 以及 ARM,其中 AMD 因為架構不一樣,只有在特定的情況下會中獎 (在使用者自己打開 eBPF JIT 後才會中):

(提到 Variant 1 的情況) If the kernel's BPF JIT is enabled (non-default configuration), it also works on the AMD PRO CPU.

這次的洞主要試著透過 side channel 資訊讀取記憶體內容 (會有一些條件限制),而痛點在於修正 Meltdown 的方式會有極大的 CPU 效能損失,在 Linux 上對 Meltdown 的修正的資訊可以參考「KAISER: hiding the kernel from user space」這篇,裡面提到:

KAISER will affect performance for anything that does system calls or interrupts: everything. Just the new instructions (CR3 manipulation) add a few hundred cycles to a syscall or interrupt. Most workloads that we have run show single-digit regressions. 5% is a good round number for what is typical. The worst we have seen is a roughly 30% regression on a loopback networking test that did a ton of syscalls and context switches.

KAISER 後來改名為 KPTI,查資料的時候可以注意一下。

不過上面提到的是實體機器,在 VM 裡面可以預期會有更多 syscall 與 context switch,於是 Phoronix 測試後發現在 VM 裡效能的損失比實體機器大很多 (還是跟應用有關,主要看應用會產生多少 syscall 與 context switch):「VM Performance Showing Mixed Impact With Linux 4.15 KPTI Patches」。

With these VM results so far it's still a far cry from the "30%" performance hit that's been hyped up by some of the Windows publications, etc. It's still highly dependent upon the particular workload and system how much performance may be potentially lost when enabling page table isolation within the kernel.

這對各家 cloud service 不是什麼好消息,如果效能損失這麼大,不太可能直接硬上 KPTI patch... 尤其是 VPS,對於平常就會 oversubscription 的前提下,KPTI 不像是可行的方案。

可以看到各 VPS 都已經發 PR 公告了 (先發個 PR 稿說我們有在注意,但都還沒有提出解法):「CPU Vulnerabilities: Meltdown & Spectre (Linode)」、「A Message About Intel Security Findings (DigitalOcean)」、「Intel CPU Vulnerability Alert (Vultr)」。

現在可以預期會有更多人投入研究,要怎麼樣用比較少的 performance penalty 來抵抗這兩套漏洞,現在也只能先等了...

用 Composer 的 require 限制,擋掉有安全漏洞的 library...

查資料的時候查到的,在 GitHub 上的 Roave/SecurityAdvisories 這個專案利用 Composerrequire 條件限制,擋掉有安全漏洞的 library:

This package ensures that your application doesn't have installed dependencies with known security vulnerabilities.

看一下 composer.json 就知道作法了,裡面的 description 也說明了這個專案的用法:

Prevents installation of composer packages with known security vulnerabilities: no API, simply require it

這方法頗不賴的 XDDD

microG 的進展...

留在 tab 上的東西,忘記在哪看到的... microG 發佈了新的專案:「LineageOS for microG」。

microG 是 AndroidGoogle 服務 API 的重新實作 (所以 open source),不像 Open GApps 還是屬於 proprietary software。

這次的事情是 microG 的人 fork 了 LineageOS 專案,因為 LineageOS 專案拒絕 microG 的 signature spoofing patch:

Why do we need a custom build of LineageOS to have microG? Can't I install microG on the official LineageOS?

MicroG requires a patch called "signature spoofing", which allows the microG's apps to spoof themselves as Google Apps. LineageOS' developers refused (multiple times) to include the patch, forcing us to fork their project.

另外也提到了他們覺得拒絕的原因很鳥:

Wait, on their FAQ page I see that they don't want to include the patch for security reasons. Is this ROM unsafe?

No. LineageOS' developers hide behind the "security reasons" shield, but in reality they don't care enough about the freedom of their users to risk to upset Google by giving them an alternative to the Play Services.
The signature spoofing could be an unsafe feature only if the user blindly gives any permission to any app, as this permission can't be obtained automatically by the apps.

Moreover, to further strengthen the security of our ROM, we modified the signature spoofing permission so that only system privileged apps can obtain it, and no security threat is posed to our users.

於是就 fork 了新的專案... 就觀察看看吧。

波多黎各的 Project Loon 啟動

先前在「Alphabet (Google) 的 Project Loon 拿到授權,支援波多黎各的救災計畫」提到 Project Loon 當時還在研究要跟誰一起合作,現在確認會跟 AT&T 合作提供服務了:「Turning on Project Loon in Puerto Rico」。

Thanks to their support, we are now collaborating with AT&T to deliver emergency internet service to the hardest hit parts of the island.

接下來應該還會有不少數字丟出來... (像是透過 Project Loon 傳輸了多少資料,或是多少分鐘的語音通話)

Alphabet (Google) 的 Project Loon 拿到授權,支援波多黎各的救災計畫

Project LoonAlphabet (Google 的母公司) 透過熱氣球建立網路的計畫。

這次波多黎各災後已經好幾個禮拜了,但還是有大量的基地台還是不通。於是 Project Loon 從 FCC 得到實驗性的執照,建立行動網路:「Alphabet’s Internet balloons will try to restore cell service in Puerto Rico」。

Nearly 82 percent of cell sites in Puerto Rico and 57 percent in the US Virgin Islands are out of service, the FCC said in its daily damage report yesterday. In nearly all counties in Puerto Rico, more than 75 percent of cell sites are not working, and "22 out of the 78 counties in Puerto Rico have 100 percent of their cell sites out of service." Large percentages of residents are also without cable or wireline service.

在 FCC 的公告裡提到授權了 900Mhz 頻段:「FCC GRANTS EXPERIMENTAL LICENSE FOR PROJECT LOON TO OPERATE IN PUERTO RICO」(PDF 檔但是標題是「Microsoft Word」...)。

Project Loon obtained consent agreements to use land mobile radio (LMR) radio spectrum in the 900 MHz band from existing carriers operating within Puerto Rico.

不過由於要讓使用者可以使用現有的 SIM 卡連上網,需要當地電信業者的合作,Google 目前還沒完全確認:

Alphabet hasn't announced a schedule for providing service in Puerto Rico, and the company says it is still determining whether it will be able to help.

Project Loon must be integrated with the network of a cellular company in order to provide service, and Alphabet is “making solid progress on this next step," the spokesperson said. Project Loon is part of Alphabet's X division, formerly known as "Google X."

是一戰成名的機會...