幹壞事是進步最大的原動力
DuplicateTicketSearchPlugin 是 Trac 的 plugin，在開新票時會搜尋系統內可能重複開過的票給出建議。
之前在寫 wiki 上的「Trac」條目時沒寫到，大概是最早的時候都沒裝，後來有人找出來要我裝的東西，所以印象沒那麼深刻。剛剛是在找 Trac + Elasticsearch 有沒有現成的方案可以搭，結果先看到這個...
產生的效果是這樣，在改變 summary 後會出現 (focus 從 summary 移開時)：
當然就算裝了還是難免會重複開 (尤其組織夠大的時候)，但算是有幫助的東西...
在先前的文章提到了把自己在用的事件管理系統 Trac 從 1.0 升級到 1.2，然後 Due Date 的設計改變了：「Trac 1.1 增加的 time 欄位，以及 Due Date 資料的轉移」、「總算把手上的 Trac 1.0 升級到 1.2 了...」。
Trac 1.2 的資料型態是在底層存 unix timestamp 的變形 (乘以 1000000，然後前端補上 0 存成文字)，這幾天用下來才發現一些以前沒遇到的問題。
一開始轉到 Trac 1.2 是設成 date，但意外的發現 (因為伺服器時間不是 UTC)，不同時區的使用者在更新 ticket 時，系統會判定 Due Date 有變動而產生變更記錄，想了一下就改用 datetime 來處理這個問題。
用了 datetime 一陣子後，才發現先前的公司遇到的情境中，時區差異都很小，所以不會有 Due Date 理解上的問題 (像是從 +7 到 +9 的時區)，如果今天是美國西岸跟台灣互相合作的話，只用 date 就會產生很明顯的理解問題了...
算是這陣子用 Trac 1.2 而對 Due Date 設計有不一樣的理解...
在 MariaDB 的「MyISAM and KPTI – Performance Implications From The Meltdown Fix」這篇看到頗驚人的數字，這篇提到了他們收到回報 (回報的 ticket 可以參考「[MDEV-15072] Massive performance impact after PTI fix - JIRA」)，說 KPTI (Meltdown Mitigation) 對 MyISAM 效能影響巨大：
Recently we had a report from a user who had seen a stunning 90% performance regression after upgrading his server to a Linux kernel with KPTI (kernel page-table isolation – a remedy for the Meltdown vulnerability).
他們發現 90% 是因為 VMware 舊版本無法使用 CPU feature 加速，在新版應該可以改善不少。但即使如此，文章內還是在實體機器上看到了 40% 的效能損失：
A big deal of those 90% was caused by running in an old version of VMware which doesn’t pass the PCID and INVPCID capabilities of the CPU to the guest. But I could reproduce a regression around 40% even on bare metal.
然後後面就在推銷 MariaDB 的 Aria Storage Engine 了，不是那麼重要... 不過知道 MyISAM 在 KPTI 下這麼傷還蠻重要的，因為接下來五年應該都還是愈的到 KPTI，應該還是有人在用 MyISAM...
在「Ballot 218 - Remove validation methods 1 and 5 - CAB Forum」看到「Ballot 218: Remove validation methods #1 and #5」這則議案以 78% 的同意票通過，限縮 SSL Certificate 的認證方式。眼睛瞄到中華電信投下反對票：
14 Yes votes: CFCA, Cisco, Comodo CA, D-TRUST, DigiCert, GDCA, GlobalSign, GoDaddy, Izenpe, Let’s Encrypt, Logius PKIoverheid, SSL.com, TrustCor, Trustwave
4 No votes: Buypass, Chunghwa Telecom, Entrust Datacard, SwissSign
4 Abstain: Actalis, Disig, HARICA, OATI
78% of voting CAs voted in favor
找了一下在 BR (Baseline Requirements) 的 3.2.2.4.1 與 3.2.2.4.5，其中前者是透過註冊商認證：
3.2.2.4.1 Validating the Applicant as a Domain Contact
Confirming the Applicant's control over the FQDN by validating the Applicant is the Domain Contact directly with the Domain Name Registrar.
後者是透過文件認證：
3.2.2.4.5 Domain Authorization Document
Confirming the Applicant's control over the FQDN by relying upon the attestation to the authority of the Applicant to request a Certificate contained in a Domain Authorization Document.
在想投下反對的原因，會不會是因為中華自己的 domain 應該都是透過後者方式發的？透過內部公文系統...
看得出來 Linus 對於 Intel 的行為很不爽：「Re: Avoid speculative indirect calls in kernel」。
Please talk to management. Because I really see exactly two possibibilities: - Intel never intends to fix anything OR - these workarounds should have a way to disable them. Which of the two is it?
那個 possibibilities 應該是 typo，但不知道為什麼看起來很有味道 XDDD
The Register 發表了「Kernel-memory-leaking Intel processor design flaw forces Linux, Windows redesign」這篇文章，算是頗完整的說明了這次的安全漏洞 (以 IT 新聞媒體標準來看)，引用了蠻多資料並且試著說明問題。
而這也使得整個事情迅速發展與擴散超出本來的預期，使得 Google 的 Project Zero 提前公開發表了 Spectre 與 Meltdown 這兩套 CPU 安全漏洞。文章非常的長，描述的也比 The Register 那篇還完整：「Reading privileged memory with a side-channel」。
在 Google Project Zero 的文章裡面，把這些漏洞分成三類，剛好依據 CVE 編號分開描述：
前兩個被稱作 Spectre，由 Google Project Zero、Cyberus Technology 以及 Graz University of Technology 三個團隊獨立發現並且回報原廠。後面這個稱作 Meltdown，由 Google Project Zero 與另外一個團隊獨立發現並且回報原廠。
這兩套 CPU 的安全漏洞都有「官網」，網址不一樣但內容一樣：spectreattack.com 與 meltdownattack.com。
影響範圍包括 Intel、AMD 以及 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 來抵抗這兩套漏洞，現在也只能先等了...
這個好讚，在告知安全漏洞後還是不更新選舉用伺服器，於是就被告了，而在被告以後選舉單位就把證據給幹掉 XD：「Georgia election server wiped after lawsuit filed」。
The lawsuit, filed on July 3 by a diverse group of election reform advocates, aims to force Georgia to retire its antiquated and heavily criticized election technology. The server in question, which served as a statewide staging location for key election-related data, made national headlines in June after a security expert disclosed a gaping security hole that wasn’t fixed six months after he reported it to election authorities.
然後現在還找不到是誰下令幹掉的...
It’s not clear who ordered the server’s data irretrievably erased.
執政者用的方法都差不多...
看到「The OpenVPN post-audit bug bonanza」這個只有苦笑啊...
作者在 OpenVPN 經過一連串的安全加強後 (包括 harden 計畫與兩個外部單位的程式碼稽核找到不少問題)，決定出手挖看看：
After a hardening of the OpenVPN code (as commissioned by the Dutch intelligence service AIVD) and two recent audits 1 2, I thought it was now time for some real action ;).
然後就挖出不少問題了...
可以看到作者透過 fuzzing 打出一卡車，包含了不少 crash XDDD：(然後有一個是 stack buffer corruption，不知道有沒有機會變成 RCE)
PHP 7.x 的效能已經趕上 HHVM (甚至在某些項目超越，參考下面的連結)，這使得後來大家為了相容性與擴充性的考量，HHVM 的社群一直沒有成長 (參考「PHP Versions Stats - 2017.1 Edition」這邊，作者從 packagist.org 上得到的數據)：
這使得 Symfony 決定在 Twitter 上蒐集意見，而後決定下一個 major version (4) 將不再支援 HHVM：「Symfony 4: End of HHVM support」。
Is it time to drop #HHVM support in #Symfony 4? Or anyone willing to see how make tests pass? https://t.co/qm3fQbcFat
— Fabien Potencier (@fabpot) May 18, 2017
馬上想到的是 Laravel 用了一堆 Symfony 的元件啊，之後應該會看到 Laravel 也開槍... 可以預料 HHVM 接下來會只剩下 Facebook 用，甚至過個幾年後有可能看到 Facebook 又換回 PHP (然後再打自己的 patch 上去)。
cURL 的維護老大放話要大家注意接下來的安全性更新：「An alert on the upcoming 7.51.0 release」。
最少 11 個安全性更新：
This release will bundle no less than _eleven_ security advisories and their associated fixes (unless we get more reported in the time we have left).
由於這些 security issue 的特性，會採取不公開的 branch 修正再 merge 回來，再加上這麼大的數量，對於穩定性的衝擊是未知的：
Merging eleven previously non-disclosed branches into master just before a release is not ideal but done so to minimize the security impact on existing users when the problems get known.
所以目前的規劃是會在 release 的 48 個小時前公開 (希望藉由這封信讓有能力的人一起集中來看)，藉此來降低衝擊：
My plan is to merge them all into master and push around 48 hours before release, watch the autobuilds closesly, have a few extra coverity scans done and then fix up what's found before the release.
這安全更新的數量好像有點多 orz