Atlassian 在 ToS 內禁止使用者討論 Cloud 產品的效能

Hacker News Daily 上看到的:「Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues (atlassian.com)」,引用的頁面是「Atlassian Cloud Terms of Service」這邊。

翻了下 Internet Archive,看起來在 2018/11/01 生效的版本就有這條了:「20181102013014」。

出自這條:

3.3. Restrictions. Except as otherwise expressly permitted in these Terms, you will not: [...]; (i) publicly disseminate information regarding the performance of the Cloud Products; [...]

這個條文已經生效兩年多了,不過我猜就是被大家批一批還是依舊...

這類條款類似於 OracleMicrosoft 在資料庫系統上面的條款 (可以參考「Is it against license to publish Oracle and SQL Server performance test?」這邊的回答),看起來除非從法律層級禁止,不然應該只會有愈來愈多公司納入這類條款...

Visa 網站上面的 Opt-Out 功能被拿來玩 Timing Attack...

Hacker News Daily 上看到「Visa Advertising Solutions (VAS) Opt Out (visa.com)」這篇講 Visa 的 Visa Advertising Solutions (VAS) Opt Out,本來以為是在討論企業賣資料的問題 (下面的討論的確是有在討論這個),但最上面的討論居然是在討論 timing attack,像是這篇:

morpheuskafka 2 days ago [–]

Checked and the Mastercard one someone posted below doesn't seem to be vulnerable to this. My real card number and a dummy mastercard number with valid prefix and check digit both returned a 200 OK in around 1.01s. A random 16digit number without valid check digit returned 400 Bad Request in about 800ms. Decided to check that one since they have a completely useless machine-readable catchpa.

For Visa it was 835ms for valid, 762ms for dummy, prefix and check digit appears to be checked client side.

我印象中這類方式已經發展很久了 (透過網路反應時間的 timing attack),討論裡面有提到「Exploiting remote timing attacks」這篇,也是十多年前的資料了... 不過官方網站玩起來總是有中特別爽的感覺 XDDD

不過 Visa 的這個網站前面用了 Cloudflare,用機器人掃感覺很容易被擋,這又是另外一回事了...

Vault 裡 AppRole 的設計,以及怎麼解決 Secret Zero 問題

VaultHashiCorp 拿來管理各種敏感資訊的軟體,像是 API token 或是資料庫的帳號密碼。把這些資訊集中控管後就不需要把這些資訊放進 Git (超爽的?),而是在需要的時候由應用程式呼叫 Vault 取得。

而 Vault 的設計裡面要求應用程式需要「認證」後才能取得,結果這個「認證」又是一組敏感資訊,這就是 Secret Zero 問題,屬於雞蛋問題的一種。

找了一輪發現 HashiCorp 自家的說明解釋的最清楚,不過這篇是放在 blog 上的文章:「Tackling the Vault Secret Zero Problem by AppRole Authentication」。

Vault 在解決 Secret Zero 的方法是使用 AppRole,這邊的認證包括了 role_idsecret_id 的設計。比較特別的是一組 role_id 可以有多組 secret_id 對應。

在 AppRole 這樣的設計下,權限會綁在 role_id 上,而 secret_id 則可以在部屬時動態產生,像是官方提到的 TerraformChef,或是依照組織裡面使用的管理工具:

這樣就可以透過 role_id 管理權限,但不用在 Git 裡面寫死 Secret Zero 資訊,而且每台機器都有自己的 secret_id 可以提供稽核記錄,把幾個比較明顯的問題解了不少...

Vultr 也推出 Kubernetes 服務 (Beta)

看到 Vultr 也打算要推出 Kubernetes 這個產品線了:「Announcing Vultr Kubernetes Engine!」。

這樣加上之前的 LinodeLinode Kubernetes Engine (LKE)DigitalOceanDigitalOcean Kubernetes (「DigitalOcean 也推出 Kubernetes 的服務」),比較知名的幾家 VPS 都推出 K8S 的產品線了。

對於不是 cloud provider 的 VPS provider 來說,直接拿 K8S 整合可以建了一組 mini-AWS 的架構出來,而且因為軟體還算紅,既有的 ecosystem 也可以直接拉進來,不需要另外重新學。不過因為 K8S 發展很快,還是可以常常看到各種踩雷抱怨文... XD

對於使用者來說,如果有一定的量與技術能力,加上想要省錢的話,用這些 VPS 提供的 K8S 服務看起來是個不錯的選擇。

應該找些時間更新之前自己摸索的那些東西了 (之前整理在「Kubernetes」這邊),理解底層會怎麼弄的對於在分析問題時還是蠻重要的 (i.e. 通靈),記得兩年前如果自己要弄 K8S master HA 還是 beta 功能...

vim-polyglot 把預設的 tabstop 改成 2

發現 VimMakefile 類的檔案 (包括 GNUmakefile) 的 tab 都變成 2 格,交叉測了一下發現是 vim-polyglot 造成的:「Polyglot is wrongly setting tabstop to 2 on several file types #648」。

目前先用作者提到的方式 let g:polyglot_disabled = ["autoindent"] 解 (在首頁也有提到這個)。

目前看起來正常一些了...

IdenTrust 願意再幫 Let's Encrypt 交叉簽三年

先前在「Let's Encrypt 在 Android 平台上遇到的問題」這邊提到了 IdenTrustLet's Encrypt 交叉簽名的有效日會在 2021 年的八月底左右到期,而這會導致比較舊的 Android 平台因為沒有內建 ISRG Root X1 這個憑證,造成 Let's Encrypt 簽出來的憑證在這些舊的 Android 裝置上都認不出來。

文章出來過了一個多月後,剛剛看到 Let's Encrypt 發佈消息,IdenTrust 願意再交叉簽名三年:「Extending Android Device Compatibility for Let's Encrypt Certificates」,當時猜測發文是要讓 IdenTrust 表態,看起來目的達成了...

話說中間跑出來的「ZeroSSL 也提供免費的 SSL Certificate (DV) 了」不知道後續會怎麼樣,之後可以看看 Certificate Transparency 的資料來看看到底有多少人用...

FreeBSD 要從 Subversion 換到 Git

#bsdchat 上面看到 FreeBSD 提供了 Git repository,翻了一下看起來是最近在切換,這邊有翻到慣例的 HEADS UP:「HEADS UP: FreeBSD changing from Subversion to Git this weekend」。

The FreeBSD project will be moving it's source repo from subversion to git starting this this weekend. The docs repo was moved 2 weeks ago. The ports repo will move at the end of March, 2021 due to timing issues.

大概是 2008 年先把 src tree 從 CVS 換到 Subversion 上:「FreeBSD src 部份由 CVS 轉換到 Subversion」。

然後 2012 年把 ports tree 換過去:「FreeBSD ports 將從 CVS 轉移到 Subversion 上...」。

雖然已經很久沒用 FreeBSD 了 (最近碰到最接近的系統應該是 pfSense),但還是先恭喜他們總算要切換了,兩邊的能量差太多了...

AWS 淘汰 Amazon RDS (MySQL 5.5) 的計畫

AWS 規劃要淘汰 Amazon RDS (MySQL 5.5),不過我是從 Percona 這邊看到...:「Amazon RDS for MySQL 5.5 EOL Date is Approaching – Act Now!」,找了一下官方的文件,在「Announcement: Amazon RDS for MySQL 5.5 End-of-Life date is approaching」這邊可以翻到。

如果硬要待在 MySQL 5.5 的話,目前看起來比較容易的解法應該是自己用 EC2 架,不過這樣的話 High Availability 的架構就頗麻煩了,用 ELB 可能是個方法...

話說回來,好久沒用 MySQL 5.5 了,這個版本記得是 InnoDB Plugin 整合進 MySQL 的第一個版本,先前應該是 MySQL 5.1 + InnoDB Plugin 的方式跑,我記得當時就是要 COMPRESSED 格式,算是 MySQL 當時蠻重大的進展...

手上還有在 5.5 上跑的人應該要自己安排時間換,儘量不要等到 AWS 硬升級的時候換,這樣炸掉的機會蠻高的...

找出非同溫層的書籍

前幾天在 Hacker News Daily 上看到有趣的服務:「Break the Bubble!」,這是由 A Book Like Foo 提供的服務,你輸入至少兩本你喜歡的書,然後他就丟一些非同溫層外的書籍出來...

我隨便丟了 1984 + TAOCP + CLRS 三本進去,推薦出來的書丟到 wikipedia 翻了一下,看起來的確都是平常不會想看的內容 XDDD

找時間問一下同事,看看這後面的演算法會怎麼玩...

AWS 推出 Amazon Location

AWS 推出了 Amazon Location:「Amazon Location – Add Maps and Location Awareness to Your Applications」,目前是 Preview 階段,但開放給所有人使用,而且不收費。

目前合作的圖資是 EsriHERE Technologies

You can choose between maps and map styles provided by Esri and by HERE Technologies, with the potential for more maps & more styles from these and other partners in the future.

先比較了一下 Amazon Location 在 map 這塊預定收費的價錢與 Mapbox pricing 這邊列出來的價錢,看起來兩邊的算法不太一樣,AWS 這邊是照 tile 數量算錢,Mapbox 則是算 load 次數算錢,看起來 AWS 這邊服務的在大量互動的情況下會比較貴 (會拉很多 tile),但對於像是只是展示可能會便宜不少,像是 591 的那種用法。

其他的項目就先暫時懶的看了...

開放的區域是老面孔了,其實比較好奇為什麼這類服務不是一次把商業區全開:

Amazon Location is available in the US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), and Asia Pacific (Tokyo) Regions.