world

前幾天綠界 *.ecpay.com.tw 憑證爆掉的事情

前幾天社群蠻熱鬧在討論綠界的 *.ecpay.com.tw 憑證被上游 Sectigo 給 revoke，而導致 login.ecpay.com.tw 無法連線的問題 (ba:d3:26:14:db:53:1b:56:49:8d:de:d5:0c:68:b9 這張，另外參考點了 OCSP 檢查的 https://crt.sh/?id=3608838685&opt=ocsp 結果)，可以看 domain 知道這個網域比較偏使用者的用途 (而非 API 類)，會買 EV 主要就是要用在瀏覽器上，所以這邊主要就討論瀏覽器受到影響的部份...

因為 Sectigo 是透過 CRL 與 OCSP 兩個機制把 revoke 資訊送出來，所以各家瀏覽器的處理方式會不太一樣...

首先是市占率最高的 Chrome，因為有自家的機制在處理 revoke，不走 CRL 或是 OCSP，所以大多數的使用者應該都沒有受到影響 (不確定...)，但 Firefox 與 Safari 都吃 OCSP，所以都會炸掉。

這次有看到兩個社群有一些討論，一個是「https://www.facebook.com/groups/rayforum/posts/4417812681632189/」，另外一個是「https://www.facebook.com/groups/616369245163622/posts/2497356027064925/」這邊。

Vincent Liang 有貼了 Sectigo 送 revoke 的原因，在 Mozilla 的 Bugzilla 上面有 Sectigo 的主動通報：「Sectigo: Subject field with unvalidated information included in certificates」，看起來是因為在內部 code review 的時候發現 postOfficeBox (~~以台灣來說就是郵遞區號~~郵政信箱) 這個欄位的問題：

Though the postOfficeBox field is permissible for inclusion in OV certificates, any field containing unvalidated information is not permissible. Furthermore, the EV Guidelines prohibit this field at all for EV certificates.

也就是說，在 OV 憑證內可以列入 postOfficeBox，但需要確認後才能列進去；而 EV 憑證則是不允許列 postOfficeBox 的；因為這兩個原因，這些憑證都要 revoke，另外也因為 Baseline Requirements 與 EV SSL Certificate Gudidelines 的要求而需要主動通報。

Sectigo 有列出 453 個受到影響的憑證，不過發文者 Lorex L. Yang 有注意到綠界的這個憑證沒有被列在這 453 個受到影響的憑證內，但是後來也有被 revoke 掉...

所以現在問題就來了，會不會 Sectigo 根本沒通知綠界要換憑證？另外 Sectigo 的通報內容不實也是一個大問題，因為沒有人在 Bugzilla 上提到，所以我就在上面回個 comment 把這個議題拋出來，讓 Mozilla 的人知道後繼續查下去...

當然綠界花了十八個小時解決也是個問題，不過那個就不是我們能管到的了...

連安裝 Windows 95 都可以 Speedrun...

看到「Speedrunning Windows 95」這篇，連裝 Windows 95 都可以有 speedrun：

Now, there’s a world record speedrun, installing Windows 95B in just 1 minute 10.9 seconds.

可以看到是在 VirtualBox 裡面裝的，這樣看起來也跟電腦速度有關... (把所有東西都塞到 memory 裡面？)

Go 1.9 的 GC 改善

Update：被提醒後仔細看了一下，是 1.8 預設生效 (但保留選項切回來 debug)，如果沒問題的話 1.9 把舊的方式拔乾淨：

Assuming things go smoothly, we will remove stack re-scanning support when the tree opens for Go 1.9 development.

標題就不改了... 以下原文。

在「Sub-millisecond GC pauses」這邊看到的。Golang 想辦法將 GC 造成的影響降低：「Proposal: Eliminate STW stack re-scanning」。

目標是解決最大的 GC pause 來源：

As of Go 1.7, the one remaining source of unbounded and potentially non-trivial stop-the-world (STW) time is stack re-scanning.

然後拿新的解法來戰，目前初步的測試看起來可以降到 50µs (== 0.05ms)：

We propose to eliminate the need for stack re-scanning by switching to a hybrid write barrier that combines a Yuasa-style deletion write barrier [Yuasa '90] and a Dijkstra-style insertion write barrier [Dijkstra '78]. Preliminary experiments show that this can reduce worst-case STW time to under 50µs, and this approach may make it practical to eliminate STW mark termination altogether.

在「runtime: eliminate stack rescanning · Issue #17503 · golang/go」這邊可以看到進度，現在已經在 master branch 上了，看起來會在 1.9 的時候被放出來... 不過 worst case 的時間上修了 XDDD

The high level summary is that this reduces worst-case STW time to about 100 µs and typical 95%ile STW time to 50 µs (assuming, of course, that the OS doesn't get in the way and that the system isn't otherwise overloaded).

但看起來應該還是很大的效能改善，尤其是 CPU bound 的應用？

Mark Callaghan 講最近的 MySQL 的行銷活動...

Mark Callaghan 這篇倒是沒提到什麼技術的東西，主要是講最近 MySQL 的兩大 conference，一個是 Oracle 的 Oracle Open World，另外一個是 Percona 的 Percona Live Amsterdam 2016，然後用了 benchmarketing 這個酸酸的詞 XDDD：「Peak benchmarketing season for MySQL」。

裡面有些也很有趣的東西：

My joke is that each of these makes a different group happy: performance -> marketing, usability -> developers, manageability -> operations, availability -> end users, efficiency -> management.

另外提到了 RocksDB 建出來的 MyRocks 在 memory fit 時可能會比 InnoDB 還要好：

One last disclaimer. If you care about read-mostly/in-memory workloads then InnoDB is probably an excellent choice. MyRocks can still be faster than InnoDB for in-memory workloads. That is more likely when the bottleneck for InnoDB is page write-back performance. So write-heavy/in-memory can still be a winner for MyRocks.

這就有趣了，找個時間來測試看看...