PHP 8 將會移除 XML-RPC,改放到 PECL 內

Twitter 上看到「PHP RFC: Unbundle ext/xmlrpc」這則消息,PHP 官方打算把 XML-RPC (也就是 git repository 裡面的 ext/xmlrpc) 拆出去,移到 PECL

Unbundle ext/xmlrpc (i.e. move it to PECL) without any explicit deprecation.

主要的考慮是在於目前的 library 已經年久失修:

ext/xmlrpc relies on on libxmlrpc-epi, which is abandoned. Even worse, we are bundling a modified 0.51, while the latest version is 0.54.1. This is exacerbated by the fact that the system library is usually built against libexpat, but the bundled library is likely to be built against libxml2 using our compatibility layer.

另外應該也是因為 XML-RPC 用的人不多吧,投票是沒什麼玄念的 50:0,而且在 Packagist 上面也可以翻到一些用 PHP 實做的替代品,拿 xmlrpc 這個關鍵字搜了一下可以看到一些...

JSON Canonicalization

這篇是講 JSON object 上的簽名,但實際上就是在討論 JSON Canonicalization 的前因後果:「How (not) to sign a JSON object」。

在處理 JSON 資料時,「判斷兩個 JSON object 是否相同」是一個不怎麼簡單的問題,其中一個想法是找一個機制可以把意義相同的 JSON object 都轉成相同的 (byte)string representative,這也就是 JSON Canonicalization。當你可以確保意義相同的 JSON Canonicalization 後,你就可以對 string 本身簽名。

這件事情其實在 XML 就有過同樣的歷史故事 (yeah,總是有人愛在某種資料格式上面疊上簽名),也就是「XML Signature」這個方式。

在 XML 這邊不幸的是,還不少標準選用 XML Signature,像是當年為了實做 Google Apps (現在叫做 G Suite) 的 SSO,而需要接 SAML...

回到原來的 JSON Canonicalization,可以馬上想到的變化包括了空白與 object 裡 key 的順序,也就是這兩個:

{"a":1,"b":2}
{
  "b": 2,
  "a": 1
}

但不幸的是,還有 Unicode 來一起亂,也就是下面這個跟上面有相同的意思:

{
  "\u0062": 2,
  "\u0061": 1
}

另外還有其他的地雷是平常不會想到的,如果你因為複雜而決定用 library 來做,那也代表 library 必須面對這些複雜的情境,未必沒有 bug...

所以文章作者在最後面才會請大家不要再來亂了 XDDD

Maybe you don’t need request signing? A bearer token header is fine, or HMAC(k, timestamp) if you’re feeling fancy, or mTLS if you really care.

Canonicalization is fiendishly difficult.

Add a signature on the outside of the request body, make sure the request body is complete, and don’t worry about “signing what is said versus what is meant” – it’s OK to sign the exact byte sequence.

Ubuntu 16.04 上多螢幕時登入畫面的設定問題

我的 Ubuntu 桌機在登入後的螢幕設定是這樣,設定在 ~/.config/monitors.xml 裡:

但登入時還是預設值 (四個螢幕都是打橫的),雖然只是輸入個密碼沒有什麼大礙,但還是想找個方法讓登入畫面吃到正確的 monitors.xml

查了文件在「Fixing Ubuntu’s Login Resolution」這邊發現 Ubuntu 16.04 (Unity) 是用 LightDM,在登入畫面是透過 lightdm 權限在跑,所以去 ~lightdm/.config/monitors.xml 下設定就可以了,如果用 symbolic link 的話要注意權限的問題。

不小心搞爛的話,可以用 Ctrl-Alt-F1 切到 command line 下登入修正...

RFC 的 Feed...

想說應該有這樣的東西,就找到「https://tools.ietf.org/html/new-rfcs.rss」這頁,本來以為直接就是 RSS feed 了 (因為網址),一打開來發現看起來像是個網頁,結果最上面這樣說明:

Don't panic. This web page is actually a data file that is meant to be read by RSS reader programs.

馬上打開來看 page source code,果然是 XSL

<?xml-stylesheet title="CSS_formatting" type="text/css" href="css/rss.css"?>
<?xml-stylesheet title="XSL_formatting" type="text/xml" href="rss2html.xsl"?>

好久沒看到這個了,大概是十年前想要做到資料與效果分離 (client-side rendering) 的方式...

StackOverflow 預設全上 HTTPS 了...

HTTPS Everywhere 沒什麼感覺,但對於一般人應該不簡單,所以 Nick Craver (根本就是他們家非正式的 PR Engineer XDD 他這幾年寫了不少內部的資訊...) 寫了一篇關於上 HTTPS 的故事:「HTTPS on Stack Overflow: The End of a Long Road」。

其中他們為了支援舊設備 (沒有支援 SNI 的),決定直接把所有 wildcard 類的 SSL certificate 都包進去 (另外找 DigiCert 處理):

然後中間提到這個真的頗無奈的,抱怨 SVG 的 XML... XDDD:

Finding and killing these was a little fun because you can’t just search for "http://". Thank you so much W3C for gems like this:

<svg xmlns="http://www.w3.org/2000/svg"...

一條辛苦路 XD

Pinterest 在 InnoDB Compression 的努力

Pinterest 用 InnoDB 儲存各式資料,而且使用了 InnoDB Compression 的功能。他們花了不少力氣跟 Percona 合作改善 InnoDB Compression 的效能:「Evolving MySQL Compression - Part 1」。

文章有點長度,重點在於他們在 MySQL 裡面放了大量的 JSON:

A Pin is stored as a 1.2 KB JSON blob in sharded MySQL databases.

他們發現新版 zlib 的 predefined dictionary 可以讓壓縮率變得更高 (從本來的 ~50% 到 ~66%);而除了壓縮率變高外,由於事先定義了字典內容,對於效能的提昇也不少 (warm up):

Zlib version 1.2.7.1 was released in early 2013 and added the ability to use a predefined “dictionary” to prefill the lookback window for LZ77. This seemed promising since we could “warm up” the lookback window with field names and other common strings. We ran a few tests using the Python Zlib library with a naive predefined dictionary consisting of an arbitrary Pin JSON blob. The compression savings increased from ~50% to ~66% at what appeared to be relatively little cost.

另外他們做了 read-only 的 benchmark (畢竟這是重點)。圖片資料有點糊,但可以看出 y 軸是 Queries/sec。而 x 軸上則用文字給了些說明,黃色是 TokuDB,紅色是本來的 InnoDB Compression,剩下的都是不同的字典集的成果:

Below is a graph from our presentation which showed a read-only version of our production workload at concurrency of 256, 128, 32, 16, 8, 4 and 1 clients. TokuDB is in yellow, InnoDB page compression is in red and the other lines are column compression with a variety of dictionaries.

整體效率都比之前高不少,尤其是當 concurrent query 的數量偏高的時候差距會很大。

而這個功能將會納入未來的 Percona 版本,對於在 MySQL 裡面會塞 JSON 或是 XML 的人應該會很有幫助:

We worked with Percona to create a specification for column compression with an optional predefined dictionary and then contracted with Percona to build the feature.

Flash 的 crossdomain.xml 架構問題

在「"Lax" Crossdomain Policy Puts Yahoo Mail At Risk」這篇裡面看到不安全的 Flash 造成的問題:「Seizing Control of Yahoo! Mail Cross-Origin... Again」。

找有問題的 swf 檔案 (hosting 在 crossdomain.xml 允許的網段下),然後利用 injection 或是根本就沒檢查權限來打趴... 把 swf 當跳板用就是了 :p

文章後面那個 Disclosure Timeline 看起來頗心酸 :o

GNU GPLv2 的判例

OSNews 上看到 GNU GPLv2 在美國的判例:「The GNU GPL to be tested in court」。

引用的報導在「GPLv2 goes to court: More decisions from the Versata tarpit」這篇,裡面有幾個角色:

  • Ximpleware:撰寫了一套 XML parser,同時以 GPLv2 與商用版權釋出。
  • Versata:在自家產品 DCM software 使用了 Ximpleware 的 XML parser,依照後面的訴訟,看起來是沒有付錢買商用版本。而 DCM software 裡面沒有引用 GPLv2 條款,同時也當然沒有公開程式碼。
  • Ameriprise:付錢給 Versata 購買 DCM software 使用權的公司,另外取得 Versata 的授權,可以找外包商修改 Versata 的 DCM software。
  • Infosys:Ameriprise 的外包商。

起因在於 Versata 不爽 Infosys 拿他們的軟體開發同性質的軟體,結果告下去後這件事情牽扯到 GPLv2 的授權問題。

然後 Ximpleware 也跳出來告了所有人,還因為專利關係,告了 Versata 的其他客戶。

問題分成兩塊討論,一塊是 copyright,另外一塊是 patent。看了一下文章的說明,案子似乎還沒結束,但已經有些結論出來了。

在 copyright 的部份,法院要求明年二月底前必須上 patch 修正問題。也就是 GPLv2 的感染力是有效的,如果你不打算服從就要賠錢,然後把 GPLv2 程式碼拔乾淨。

而 patent 的部份有點複雜啊... Ximpleware 的控訴都不成立,不過理由沒有看懂 @_@

等有更多時間再來看其他的說明研究...