Wikimedia 新計畫:WikiFunctions

Wikimedia 的新計畫 WikiFunctions:「Introducing Wikifunctions: first Wikimedia project to launch in a decade creates new forms of knowledge」。

官方的說明中提到 WikiFunctions 是提供給 Wikimedia 其他的計畫用的程式碼:

Wikifunctions is a Wikimedia project for everyone to collaboratively create and maintain a library of code functions to support the Wikimedia projects and beyond, in the world's natural and programming languages.

這樣有點抽象,看「Wikifunctions:Catalogue」這邊的範例會比較具體一點,可以看到都是實作很基本的功能,像是「Function: To Uppercase」。

Hacker News 上也有討論:「Wikifunctions (wikimediafoundation.org)」,在 id=38549081 這邊有人比較清楚的說明了要解決的問題:

A lot of Wikipedia sites have scripts embedded in the wikitext which automatically generate or transform information on a page, e.g. automatically performing unit conversions to generate text like "I would walk 500 miles (804.67 km)", performing date math to automatically generate and update a person's age based on their birthdate, or querying structured data from Wikidata [1] to display in an infobox. One example of these scripts is the {{convert}} [2] template on the English Wikipedia.

Initially, these scripts were written in MediaWiki template logic [3], and were maintained individually on each wiki. This quickly proved unmaintainable, and some of those scripts were rewritten in Lua using the Scribunto extension [4], but these were still per-wiki, and there were frequently issues where different wikis would copy scripts from each other and introduce their own incompatible features.

The WikiFunctions project is an attempt to centralize development of these scripts, much like how Wikimedia Commons [5] centralizes hosting of freely licensed images and other media.

MediaWiki 本身的 template engine 還是有極限,所以很多的需求會希望使用程式語言開發,一方面是比較好維護,另外一方面是效率也比 template engine 硬幹來的好。

先前大家在 MediaWiki 上比較常用的方案是透過 Extension:ScribuntoLua script,而這個 extension 後來變得太重要 (好用),直接包進 MediaWiki 了。

拿個例子來說,常見的引用功能 Template:Citation 裡面直接是透過模組實作:

<includeonly>{{#invoke:citation/CS1|citation
|CitationClass=citation
}}</includeonly><noinclude>
{{Documentation}}
</noinclude>

而這邊的 #invoke 就是去使用「Module:Citation/CS1」這邊的 Lua 程式。

目前的架構上面,每個語言的 Wikipedia 都需要使用 Lua 維護自己的 Module:*,而 WikiFunctions 計畫則是希望能夠整合起來,算是重新打造基礎建設的工程。

目前看了一些 WikiFunctions 的實作,主要是以 PythonJavaScript 為主。

這樣看起來,技術上是蠻有機會讓 Scribunto 退役,但實際上要不要這樣推還沒查到討論,在 Wikifunctions:FAQ 這邊則是沒提到 Scribunto,不確定是不是想雙軌跑...

NVIDIA 開源 Linux GPU Kernel Driver

NVIDIA 宣佈開源 Linux 下的 GPU Kernel Driver:「NVIDIA Releases Open-Source GPU Kernel Modules」。

從一些描述上可以看出來,應該是因為 Datacenter 端的動力推動的,所以這次 open source 的版本中,對 Datacenter GPU 的支援是 production level,但對 GeForce GPU 與 Workstation GPU 的支援直接掛 alpha level:

Which GPUs are supported by Open GPU Kernel Modules?

Open kernel modules support all Ampere and Turing GPUs. Datacenter GPUs are supported for production, and support for GeForce and Workstation GPUs is alpha quality. Please refer to the Datacenter, NVIDIA RTX, and GeForce product tables for more details (Turing and above have compute capability of 7.5 or greater).

然後 user-mode driver 還是 closed source:

Will the source for user-mode drivers such as CUDA be published?

These changes are for the kernel modules; while the user-mode components are untouched. So the user-mode will remain closed source and published with pre-built binaries in the driver and the CUDA toolkit.

nouveau 來說,是可以從 open source driver 裡面挖一些東西出來用,不過能挖到跟 proprietary 同樣效能水準嗎?

雙 Gigabit Ethernet 的 RPi CM 4 擴充卡

看到「Dual Gigabit Ethernet Carrier Board for Raspberry Pi Compute Module 4」這個東西,一張可以接 Raspberry Pi Compute Module 4 擴充的母卡。

這張卡有兩個 Gigabit Ethernet (1Gbps),以及兩個 USB 3.0 接口:

然後大家都想到類似的用途了,可以拿來當 router,還可以走 USB 拉出來,接個硬碟當個簡單的 NAS 用用:

The Dual Gigabit Carrier Board powered by Raspberry Pi Compute Module 4 is equipped with Dual Gigabit Ethernet ports and dual USB 3.0 ports, making it suitable for soft router applications, while keeping the hardware to minimal.

不過無線網路的部份得自己搞,在買 RPi CM 4 的時候得選擇有無線網路的版本,母卡 (擴充卡) 本身不負責這塊業務。

翻了一下資料,以前 CM3 (不是 CM3+) 也有廠商推出兩個網路孔的板子,不過當時是兩個 Fast Ethernet (100Mbps):「Compulab IOT-GATE-RPi Industrial IoT Computer is Powered by Raspberry Pi CM3 Module」。

這次推出的板子跑起 software router 效能不知道怎麼樣,單純就可玩性來看似乎是頗有趣東西?

把 SSH Key 放進 Secure Enclave 裡保護

看到 Secretive 這個專案,是利用蘋果的 Secure Enclave 機制,把 SSH private key 放進去在裡面進行運算,避免 private key 檔案被惡意程式讀取就洩漏出去了。

從 Secure Enclave 的介紹頁面可以看到這個需要有 T1 或是 T2 晶片才有 Secure Enclave 功能:

Mac computers that contain the T1 chip or the Apple T2 Security Chip

而從 Apple Silicon 這邊可以看到 Apple T1 chip 是 2016 年後的機種引入的:

The Apple T1 chip is an ARMv7 SoC (derived from the processor in S2 SiP) from Apple driving the System Management Controller (SMC) and Touch ID sensor of the 2016 and 2017 MacBook Pro with Touch Bar.

然後對於沒有 Secure Enclave 的古董機,可以透過有支援 smart card 的硬體掛上去,像是 YubiKey

For Macs without Secure Enclaves, you can configure a Smart Card (such as a YubiKey) and use it for signing as well.

照著他講的建議去翻了「YubiKey Smart Card Deployment Guide」這邊的資料,看起來 YubiKey 在 4 系列之後就有產品支援 Smart Card 了,不過要注意純 U2F 的版本沒支援。

GCP 推出 Cloud HSM (beta)

這算是 Google Cloud Platform 在補產品線,讓那些有強制使用 HSM 的需求的應用 (通常是遇到一定要 FIPS 140-2 的規範) 可以搬上雲端:「Introducing Cloud HSM beta for hardware crypto key security」。

從圖片上可以看到 LiquidSecurity,應該是「LiquidSecurity® General Purpose HSM Adapters and Appliances」這個產品:

如同 AWSCloudHSM 服務,GCP 的 Cloud HSM 也是提供 FIPS 140-2 Level 3:

Cloud HSM allows you to host encryption keys and perform cryptographic operations in FIPS 140-2 Level 3 certified HSMs (shown below).

演算法上,支援 AESRSAECC (NIST 的 P-256 與 P-384):

In addition to symmetric key encryption using AES-256 keys, you can now create various types of asymmetric keys for decryption or signing operations, which means that you can now store your keys used for PKI or code signing in a Google Cloud managed keystore. Specifically, RSA 2048, RSA 3072, RSA 4096, EC P256, and EC P384 keys will be available for signing operations, while RSA 2048, RSA 3072, and RSA 4096 keys will also have the ability to decrypt blocks of data.

目前只支援 us-east1us-west1,另外價錢也比軟體服務版本的 Cloud KMS 貴不少:

Billable item For keys with protection level SOFTWARE For keys with protection level HSM
Active AES-256 and RSA 2048 key versions $0.06 per month $1.00 per month
Active RSA 3072, RSA 4096 or Elliptic Curve key versions $0.06 per month $2.50 per month for the first 2,000
$1.00 per month thereafter
Destroyed key versions Free Free
Key operations: Cryptographic $0.03 per 10,000 operations $0.03 per 10,000 operations for AES-256 and RSA 2048 keys
$0.15 per 10,000 operations for RSA 3072, RSA 4096, and Elliptic Curve keys
Key operations: Admin Free Free

不過一般情況應該不會得用 CloudHSM,先有個印象就好...

Rust 是不錯啦,不過...

作者寫了一篇「Creating Rust-based NodeJS modules」講同樣演算法 Node.js 要跑 3.5 秒,Rust 只要跑 130ms,所以 Rust 很棒棒之類的...

So about 3.5 seconds for an answer, in web time that is like an eternity. Our algorithm is a very straight forward one, basically just a filter on a large array.

The exact same algorithm, with the exact same CSV and coordinates is now executing in about 130ms.

然後仔細看了一下他的範例,holy...

這讓我想到之前在「看到 zmx 貼了之前的連結,更確信 Uber 的問題不是技術問題了...」這篇提到的文章「Unwinding Uber’s Most Efficient Service」:

很想講「傻逼你先把演算法修好再來怪 Node.js 慢」,程式會愈來愈難維護都是你們這種人引入一堆複雜的東西 -_-

便宜的 HSM

當然速度就不用想太多了...

一個是 Yubico 推出的 YubiHSM 2:「YubiHSM 2 is here: Providing root of trust for servers and computing devices」。

另外一個是 Mozilla 在 2013 年提到的 CryptoStick,不過現在連過去看到的是 Nitrokey HSM:「Using CryptoStick as an HSM」。

兩個都是走 USB 1.1 Type A,運算效能都普普通通,感覺自己用比較合適?像是 GnuPG 加解密。拿給線上服務用的效能還是要夠好...

nvm 換 n

前幾天在 Twitter 上抱怨 nvm 很慢,導致 Zsh 開起來很頓 (然後也同步到 Facebook 上):

原因在於 .bashrc 或是 .zshrc 內初始化 nvm 時會呼叫 npm config get prefix,而這個命令很慢:「`npm config get prefix` takes incredibly long (7 - 70 seconds) #14458」。

後來在 Facebook 的留言處有朋友提了幾個方案... 其中一個是 n,花了些時間看軟體架構,有夠簡單... XD 對於不是拿 Node.js 開發的人應該是夠用了 (我只拿來跑一些用 Node.js 寫的工具)。

整個軟體就一個 shell script,把他丟進 ~/bin/ 裡面 (我有把 ~/bin/ 放到 PATH 裡),就可以用了。透過 N_PREFIX 設定他的基地 (預設是 /usr/local,我是設成 $HOME),剩下就跑 n lts,他就把 nodenpm 兩個檔案裝好給你用。

路徑的部份要自己設定,將 $N_PREFIX/node_modules/.bin 放進 PATH,這樣安裝起來的模組如果有可執行工具可以用才能直接跑 (像是 gulp.js 的命令)。

另外,之所以會說不適合開發者用的部份,是因為 module 是跨版本共用的 (切換 node 版本時就是用另外一個版本配上去 XD),所以比較不適合開發者使用...

AWS CloudHSM 支援 FIPS 140-2 Level 3 了

AWS CloudHSM 推出了一些新功能:「AWS CloudHSM Update – Cost Effective Hardware Key Management at Cloud Scale for Sensitive & Regulated Workloads」。

其中比較特別的是從以前只支援 Level 2 變成支援 Level 3 了:

More Secure – CloudHSM Classic (the original model) supports the generation and use of keys that comply with FIPS 140-2 Level 2. We’re stepping that up a notch today with support for FIPS 140-2 Level 3, with security mechanisms that are designed to detect and respond to physical attempts to access or modify the HSM.

在維基百科裡面有提到 Level 2 與 Level 3 的要求:

Security Level 2 improves upon the physical security mechanisms of a Security Level 1 cryptographic module by requiring features that show evidence of tampering, including tamper-evident coatings or seals that must be broken to attain physical access to the plaintext cryptographic keys and critical security parameters (CSPs) within the module, or pick-resistant locks on covers or doors to protect against unauthorized physical access.

In addition to the tamper-evident physical security mechanisms required at Security Level 2, Security Level 3 attempts to prevent the intruder from gaining access to CSPs held within the cryptographic module. Physical security mechanisms required at Security Level 3 are intended to have a high probability of detecting and responding to attempts at physical access, use or modification of the cryptographic module. The physical security mechanisms may include the use of strong enclosures and tamper-detection/response circuitry that zeroes all plaintext CSPs when the removable covers/doors of the cryptographic module are opened.

主動式偵測以及銷毀算是 Level 3 比 Level 2 安全的地方。

另外就是計價方式的修正,先前有一筆固定的費用,現在變成完全照小時計費了:

Pay As You Go – CloudHSM is now offered under a pay-as-you-go model that is simpler and more cost-effective, with no up-front fees.

nginx 的 mirror 功能

nginx 1.13.4 出的新功能,ngx_http_mirror_module

The ngx_http_mirror_module module (1.13.4) implements mirroring of an original request by creating background mirror subrequests. Responses to mirror subrequests are ignored.

範例其實就講的還蠻清楚的:

location / {
    mirror /mirror;
    proxy_pass http://backend;
}

location /mirror {
    internal;
    proxy_pass http://test_backend$request_uri;
}

如果拿 nginx 當 load balancer 的人,可以用這個功能做些事情...