robots.txt 的標準化

雖然聽起來有點詭異,但 robots.txt 的確一直都只是業界慣用標準,而非正式標準,所以各家搜尋引擎加加減減都有一些自己的參數。

在經過這麼久以後,Google 決定推動 robots.txt 的標準化:「Formalizing the Robots Exclusion Protocol Specification」,同時 Google 也放出了他們解讀 robots.txt 的 parser:「Google's robots.txt Parser is Now Open Source」,在 GitHubgoogle/robotstxt 這邊可以取得。

目前的 draft 是 00 版,可以在 draft-rep-wg-topic-00 這邊看到,不知道其他搜尋引擎會給什麼樣的回饋...

Microsoft 釋出一個效能極佳的 Malloc Library

Hacker News 上看到的:「Mimalloc – A compact general purpose allocator with excellent performance (github.com)」,專案網站在 GitHub 上:「mimalloc is a compact general purpose allocator with excellent performance.」。

現代伺服器軟體比較常用的應該是 jemalloc,許多軟體也直接把 jemalloc 包進去 (像是 Firefox),所以各種測試主要就是看與 jemalloc 的差異。

測試的機器有點怪,既然都是在 AWS 上測試,卻不是選目前主流的 Intel,而且就算是 AMD 也不是選最大台的 r5a.24xlarge (都是在去年 2018 年十一月發表的):

Testing on a big Amazon EC2 instance (r5a.4xlarge) consisting of a 16-core AMD EPYC 7000 at 2.5GHz with 128GB ECC memory, runningUbuntu 18.04.1 with LibC 2.27 and GCC 7.3.0.

尋著留言有看到 daanx/mimalloc-bench 這邊有使用 Intel 平台的測試,也有類似的結果,所以應該是還 ok...

Anyway,依據目前官方給的的效能測試,看起來頗不賴:

而且實際的記憶體用量也比以前少,這邊在看資料時官方有附註,有些測試在這邊因為執行方式所以不會準:

(note: the xmalloc-testN memory usage should be disregarded is it allocates more the faster the program runs).

至於實際上是不是真的在 general purpose 都可以提昇效能,應該會等著比較大的社群玩看看... 尤其是 Percona 對只要換個 library 就能提昇效能的東西,他們基本上都不會放棄嘗試...

加州大學宣佈不與 Elsevier 續約

加州大學 (這是一個大學系統,包括了十個校區,超過 25 萬的學生與 14 萬的教職員) 認為 Elsevier 沒有達到 open access 應有的標準,決定將不再跟 Elsevier 續約,並且發出新聞稿抨擊 Elsevier:「UC terminates subscriptions with world’s largest scientific publisher in push for open access to publicly funded research」。

As a leader in the global movement toward open access to publicly funded research, the University of California is taking a firm stand by deciding not to renew its subscriptions with Elsevier. Despite months of contract negotiations, Elsevier was unwilling to meet UC’s key goal: securing universal open access to UC research while containing the rapidly escalating costs associated with for-profit journals.

這應該是美國頂尖學院裡面的第一槍?後續會帶動多少單位不續訂...

GitHub Actions

GitHub 藉著 open source 函式庫,說明了目前還在 beta 的 GitHub Actions 是什麼:「An open source parser for GitHub Actions」。

GitHub Actions 是 GitHub 規劃將自動化設定包裝成設定檔的服務,以往是透過 GitHub 網站上設定,現在則是把這些設定放到 git repository 內。

重點在於 Actions 其實是透過 HCL (HashiCorp Configuration Language) 語法定義:

All Actions workflow files are valid HCL, but not all HCL files are valid workflows.

OpenSSL 的版號規則打算要改變...

在「The Holy Hand Grenade of Antioch」這邊看到 OpenSSL 的版號規則要改變了,變得比較接近 Semantic Version 的架構。

本來是 MAJOR.MINOR.FIX[PATCH] 這樣的形式,之後打算改成 MAJOR.MINOR.PATCH,不過現有的 1.1.1 與 1.0.2 會先維持原來的規則:

The current 1.1.1 and 1.0.2 versioning scheme will remain unchanged.

另外下一個大版本會是 3.0.0,而不是 2.0.0 (被其他計畫用掉了,所以為了避免混淆中獎,就直接跳過去了):

The current development version (master branch) will be identified as version 3.0.0. The OpenSSL FIPS module currently under development will also follow this versioning scheme. We are skipping the 2.0.0 major version because the previous OpenSSL FIPS module has already used this number.

另外授權也變成 Apache License 2.0 了:

OpenSSL version 3.0.0 will be the first version that we release under the Apache License 2.0. We will not be applying the Apache License to earlier releases of OpenSSL.

我記得 Apache License 2.0 跟 GPLv2 是不相容的... 本來使用 OpenSSL 的軟體為了 OpenSSL 的授權而加的例外條款,這次又要再修嗎...?

OpenSSL 1.1.1 出版,TLSv1.3!

OpenSSL 1.1.1 推出了:「OpenSSL 1.1.1 Is Released」。先前在「OpenSSL 1.1.1 將支援 TLS 1.3」這邊有提到 OpenSSL 當時就計畫要等 TLSv1.3 出了才會釋出 1.1.1,結果這一等就是一年多...

這樣後續應該會有人包 PPA 出來讓大家用了...

curl 將支援 DNS over HTTPS

curl 的維護者 Daniel Stenberg 在他的 blog 上宣佈 curl 將會支援 DNS over HTTPS:「DoH in curl」。

從給的範例可以看出來就是多一個 CURLOPT_DOH_URL 可以設,對於要用的人很簡單:

curl = curl_easy_init();
curl_easy_setopt(curl, CURLOPT_URL,
                 "https://curl.haxx.se/");
curl_easy_setopt(curl, CURLOPT_DOH_URL,
                 "https://doh.example.com/");
res = curl_easy_perform(curl);

ORM 常見的效能問題

在「How not to structure your database-backed web applications: a study of performance bugs in the wild」這邊看到的,裡面提到的論文是以 Rails 的 ActiveRecord 分析,不過概念上還算通用...

重點在最後一張 (Table 7 那張):

看一下在腦裡留個印象,之後遇到的時候至少大概知道怎麼查...

Ethereum Smart Contracts 裡的 PRNG

現代密碼學的安全性有很大一塊是基於亂數產生器 (RNG) 非常難被預測。如果這個前提不成立的話,利用亂數產生器產生出來的各種資訊都會被預測出來 (尤其是 Private Key)。

但真正的 RNG 需要靠硬體支援,而且產生速度很慢,一般都會使用 PRNG (Pseudorandom number generator) 產生。也就是「看起來」很亂的亂數產生器。

PRNG 通常是指在統計學上通過許多測試,像是在多種測試都是 Discrete uniform distribution,不需要防止有惡意人,可以從產生出的 PRNG 的值而推導出後續結果的用途。

在「Predicting Random Numbers in Ethereum Smart Contracts」這篇裡面,作者列出了一堆實做 Ethereum Smart Contracts 卻誤用 PRNG 的行為。

文章裡提到的問題都是因為 PRNG 拿著可被預測的資訊當作 entropy source (e.g. seed),而且提出來的範例都是拿 block 本身或衍生的資訊 (像是 block 的 hash) 來用:

  • PRNGs using block variables as a source of entropy
  • PRNGs based on a blockhash of some past block
  • PRNGs based on a blockhash of a past block combined with a seed deemed private
  • PRNGs prone to front-running

然後列了大量的程式碼當例子,建議有需要接觸的人看過一次,或是有時間的人都值得看這些負面範例... XDDD

不過作者在文章裡面也給了一堆有問題的方法,像是從外部網站取得亂數之類的 XDDD

正確的方法是使用 CSPRNG (Cryptographically secure pseudorandom number generator),這是專門設計給密碼學用的 PRNG。

CSPRNG 有幾種方法可以取得:

  • 在大多數的程式語言內都有對應的 library 可以用,另外在比較近代的瀏覽器內 (如果問 IE 的話,是 11+),可以透過 RandomSource.getRandomValues() 得到。
  • 如果打算自己搞底層而需要直接取得 CSPRNG 的產出,在 Unix-like 的環境下可以透過 /dev/urandom 取得,在 Microsoft Windows 下則可以透過 CryptGenRandom 取得。

別學作者那邊奇怪方法啊 XDDD