Percona 提供的 MySQL Git Mirror...

MySQL 的開發者是用 Bazaar (bzr) 為版本控制系統,放在 Launchpad 上,不過 open source 領域目前總是有人會想要轉到 Git 上... XD

Percona 提供 Oracle MySQL 的 Git mirror,目前是實驗性質:「Experimental Git mirror of Oracle MySQL trees」。

如果只是要拉 MySQL source tree 下來看 (而且手上只有 Git,沒有裝 Bazaar 的人),可以透過這份拉出來... 還不確定更新的頻率 :o

OpenZFS 成立...

好幾個新聞來源都有看到 OpenZFS 成立:「OpenZFS Project Launches, Uniting ZFS Developers」(Slashdot)、「OpenZFS launch announcement」。

OpenZFS 的正式公告在「Announcement」這邊,雖然沒有明講是要脫離 Oracle 的控制,但宣示對社群更公開這點其實就很清楚了 (To encourage open communication about ongoing efforts to improve open source OpenZFS, ...)。

隔壁棚 Oracle 前員工 (現在在 Fusion-io) 弄出來的 Btrfs 的進展也不差,兩邊都在進步...

MySQL 5.7...

Oracle 的「MySQL :: MySQL 5.7 Reference Manual :: 1.4 What Is New in MySQL 5.7」列出 MySQL 5.7 預定會有的功能。由於還在發展階段,這頁還會繼續變動。

針對 ALTER TABLE 有不少改善,以下的條件下 ALTER TABLE 將不會產生 temporily table (不會卡住):

  • table 改名。
  • column 改名。
  • column 改 default value。
  • enum 或 set 在不修改原來值的情況下增加值。
  • partition 相關操作。
  • index 改名。
  • index 新增與刪除。(僅限 InnoDB)

幾個常見的操作變得更簡單了,pt-online-schema-change 的功能會慢慢被整合回 MySQL。

然後 InnoDB 要支援 spatial data types 了,不過 index 還沒支援... 不知道有沒有機會看到 :o

換 NoSQL 前的建議...

原文是「Medium Data: things to try before abandoning SQL」,放棄 SQL 前應該要嘗試的事情,原文一開始就用粗體說明帶有強烈的偏見 XD

First, my thesis: a lot of less-experienced developers are using big data and NoSQL technologies because they are new and cool, and because SQL is old and hard. A lot of these people would save themselves time and effort by learning more about SQL and tuning their databases and hardware just a little bit.

文章寫的相當概念性,主要是說明幾件事情:

  • 其實 SQL 可以解決大部分的事情,大家都知道 SQL 的瓶頸在哪裡,有哪些 workaround 可以避開。
  • 不要因為 MySQL 做不到就覺得 SQL 不好用,在這種情況下,PostgreSQL 的功能與成熟度很值得看看。
  • 不要用 Oracle 官方版本的 MySQL... XD
  • 通常可以用 cache 解決的就用 cache 試著解看看,雖然 invalidate 問題不太好處哩... XD
  • 如果是 Read 數量太多,可以用 replication 解決不少問題。
  • 試著去理解 index 的「原理」,也就是資料結構,這對於要怎麼用 index 絕對有強力的幫助。
  • 當上面都做完而發現還是不夠的時候就 sharding 吧。

MySQL 5.6 上線,以及 openSUSE 與 Fedora 對 MySQL 的反擊...

Oracle 正式將 MySQL 5.6 推上線 (GA,General Availability):「Oracle Announces General Availability of MySQL 5.6」。

在官方的「What's New in MySQL 5.6」有列出 MySQL 5.6 的進展。另外在 Percona 的創辦人 Peter Zaitsev 所整理的文章「MySQL 5.6: Improvements in the Nutshell」裡面也整理了一份資料。

在 Oracle 的工程師的 blog 上可以看到不少說明 InnoDB 在多 CPU 環境下的顯著進步,不過我是覺得看看就好... 進步是一定有,但實際用起來通常不會有官方說的那麼多 :p

可以預期不久後 Percona 應該會丟出對應的版本 (至少之前已經有風聲了),到時候就用 Percona 的版本吧。

另外一方面,openSUSEFedora 都已經決定將系統內的 MySQL 改用 MariaDB 代替:

原因的話就不詳細寫了,上面有一些無關痛癢的官方說法。在「Oracle who? Fedora & openSUSE will replace MySQL with MariaDB」報導裡寫的比較直接。

大家對 Oracle 沒什麼好感 (於是 Solaris 的事情又被拿出來婊),可以看到在 mailing list 上對 Oracle 的人酸溜溜的 XD

SSL/TLS 的問題...

這篇與「對稱式加密系統的爆炸歷史 (Authenticated encryption 的問題)」這篇相關,建議可以一起看一看。

TLS (Transport Layer Security),前身是 SSL (Secure Sockets Layer),是目前 HTTPS 所使用的加密協議。發展的順序上是 SSLv2、SSLv3、TLSv1、TLSv1.1、TLSv1.2。

然後有兩篇文章可以看:

第一篇文章講 Padding oracle attack,第二篇文章是酸 SSL/TLS 的修正愈修愈歪... XD

AES 這類的 block cipher 在加密或解密時會要求切齊 block size,以 AES 的要求就是 128bits (16 bytes)。

而對於不齊的資料要怎麼加密呢?其中一個方法是 PKCS#7:(圖片取自第二篇文章)

Padding

要想辦法補齊 128bits (16bytes),如果像上圖需要補 7bytes 進去,就都補上 x07 (剛好就是補上長度),另外在最後面會補上 padding 的長度,而問題出就出在這個設計先天就有缺陷:在 SSL/TLS 所使用的 MAC-then-Encrypt 中,MAC 只計算原文的值,沒有保護到 padding 的部份,於是就可以針對 padding 的部份想辦法找到洞鑽。

pseudo code 可能是這樣:

// Decrypt to plaintext + mac + padding
$plaintext_mac_padding = decrypt($ciphertext);
if (NULL != $plaintext_mac_padding) {

    // Now decode padding part
    $plaintext_mac = decode_padding($plaintext_mac_padding, $padding_length);
    if (NULL != $plaintext_mac) {

        // Now check MAC part
        $plaintext = check_mac(plaintext_mac);
        if (NULL != $plaintext) {

            // Now it's okay
        }
    }
}

攻擊者亂改 $ciphertext 會導致解出來的 padding 也亂掉,但早期的 SSL 會回傳「padding error」這種對攻擊者有利的資訊,而導致攻擊者可以利用這個資訊想辦法得知更多內容。

而 TLS 並沒有從根本改善,而是試著加上機制補西牆:當遇到錯誤時就跳過,不要傳回錯誤資訊。

但因為攻擊者亂改封包造成 decode_padding() 會失敗,而沒有呼叫到 check_mac()。這導致了大量的計算時間差與能量差,而使得攻擊者可以藉由這些資訊而得知是否成功。而官方在 TLSv1.2 的建議是再補上機制來補洞:

In general, the best way to do this is to compute the MAC even if the padding is incorrect, and only then reject the packet. For instance, if the pad appears to be incorrect, the implementation might assume a zero-length pad and then compute the MAC.

而官方認為雖然這樣還是有 timing channel,但已經小到會被雜訊覆蓋,所以「應該」可以解決問題:

This leaves a small timing channel, since MAC performance depends to some extent on the size of the data fragment, but it is not believed to be large enough to be exploitable, due to the large block size of existing MACs and the small size of the timing signal.

於是,只要覺得「應該安全吧」,就會「應該會被破」:「Lucky Thirteen: Breaking the TLS and DTLS Record Protocols」:

The attacks apply to all TLS and DTLS implementations that are compliant with TLS 1.1 or 1.2, or with DTLS 1.0 or 1.2. They also apply to implementations of SSL 3.0 and TLS 1.0 that incorporate countermeasures to previous padding oracle attacks. Variant attacks may also apply to non-compliant implementations.

這 SSL/TLS 的設計讓人補到快起笑了... XD

資安的東西通常是愈複雜就愈容易被抓問題出來,在 SSL/TLS 的歷史包袱下,不知道什麼時候才想換 Encrypt-then-MAC 來改善底層問題...

Percona 說明關於為什麼花這麼多時間修正 MySQL 5.5.28 安全問題...

Percona 的 Stewart Smith 解釋為什麼花這麼多時間才修正這個安全漏洞:「CVE-2012-4414 strikes back in MySQL 5.5.29 (and what we’re doing in Percona Server 5.5.29)

MariaDB 的人在得知問題後先建立了 MDEV-382 這個 issue,然後建立了 rpl_mdev382.test 這份測試資料,讓其他參與者可以測試手上的 MySQL 是否有問題。

Oracle 在修正問題時並沒有使用 MariaDB 這份測試資料測過 (或是測過但因為種種因素...) 就推出 MySQL 5.5.29,但 MySQL 5.5.29 用 rpl_mdev382.test 測試會失敗,而實際確認發現 Oracle 並沒有把問題解乾淨。所以本來 Percona 預定要使用官方 MySQL 5.5.29 版本為基礎推出 Percona Server 5.5.29 (可以降低 Percona 維護成本),變成將會改用 MariaDB 的 patch。

讓 Percona 的人特地寫一篇出來,看起來對 Oracle 不太爽... XD

測試 MariaDB 後的一些感想...

Monty Program ABMySQL 的發起人 Monty 在離開 Sun 之後所創辦的公司 (他同時也是 MySQL AB 的創辦人),這家公司目前以 MariaDB 為發展主力。

先說對 MariaDB 目前的看法:暫時還是會用 Percona 所提供的版本,以及 XtraDB (基於 InnoDB 的產品)。

MariaDB 發展的重點在於 Aria storage Engine,但目前的 1.5 版只支援 crash-safe,要到 2.0 才會支援 InnoDB 主要功能,而到了 2.5 才會針對效能調整,看起來要到「能用」必須要到 2.5 之後... (參考「Aria FAQ」的說明)

InnoDB 控制權在 Oracle 手上,XtraDB 控制權在 Percona 手上,而 MyISAM 拿不上檯面。所以 Monty 想要一個控制權在他自己手上的 storage engine...

對於社群來說,因為 XtraDB 還是基於 InnoDB 的分支,所以當 Oracle 從 InnoDB 抽手後大家會擔心 Percona 能夠自己發展到什麼程度。這使得對於 Aria 有所期待,也趁著現在 Oracle 被歐盟盯著不致於做的太明顯趕快發展。

這也可能是 WikimediaMozilla 選 MariaDB 當 slave 測試的原因?當然也有可能只是「看名字比較順眼」之類的原因而選... XD

Ubuntu 下用 MegaRAC 界面管理機器...

這個週末把之前在 Ubuntu 下不順的地方搞定... (之前是透過 VirtualBox 開 Windows 管理)

首先遇到的問題是 Ubuntu 下 Chromium 沒辦法開 jnlp 檔案 (永遠都是 Save as 視窗),所以用 Firefox 開流程會比較順。

再來是 Ubuntu 提供的 OpenJDK 無法讀取 MegaRAC 給的 jnlp 檔案,需要裝 Oracle 的版本,這部份可以透過「Oracle Java (JDK) 7 Installer」處理。

http://imgur.com/Wf8Ql

Oracle 與 Google 的 Java 專利官司:先教法官 Java 是什麼...

Oracle 認為 Google 侵犯 Oracle 在 Java 使用的專利,而 Google 認為 Oracle 的專利不成立,所以兩邊現在在打官司...

但這牽扯太多專業問題,要了解專利本身的內容才有辦法判斷,所以兩邊的律師決定讓法官先知道 Java 是什麼東西,開兩個禮拜的課程讓 William Alsup 法官了解 Java 的背景與細節:「Judge In Oracle-Google Case Given Crash Course in Java」、「Judge in Oracle-Google case gets a lesson in Java」,引用其中一段:

Judge William Alsup of the U.S. District Court in San Francisco was given an overview of Java and why it was invented, and an explanation of terms such as bytecode, compiler, class library and machine-readable code.

成人速成班 XDDD