Node.js 20

看到 Node.js 推出 20 了,官方的公告:「Node.js 20 is now available!」。

裡面提到的 Permission Model,設計上看起來有點雷?這種東西應該要有白名單機制才對,目前看起來是實做黑名單機制...

然後結尾有提到 14 是這個月收攤,16 則是因為 OpenSSL 1.1.1 EoL,打算切齊而提前到今年九月收 (參考 OpenSSL 官方前陣子發的「OpenSSL 1.1.1 End of Life」):

Also of note is that Node.js 14 will go End-of-Life in April 2023, so we advise you to start planning to upgrade to Node.js 18 (LTS) or Node.js 20 (soon to be LTS).

Please, consider that Node.js 16 (LTS) will go End-of-Life in September 2023, which was brought forward from April 2024 to coincide with the end of support of OpenSSL 1.1.1.

查了 18 會是 2025 年四月底,20 則會是 2026 年四月底...

GitHub 推出 Package Registry

GitHub 推出了「GitHub Package Registry」,可以代管自己開發的軟體。

目前支援 npm (Node.js)、DockerMaven (Java)、NuGet (.NET)、RubyGems (Ruby) 五個平台,

隔壁 GitLab 說我們早就有了而氣噗噗中:「Packaging now standard, dependency proxy next?」。

Anyway,省下一些事情,以前會透過 CI/CD 丟到像是 packagecloud.io 這樣的服務上讓內部使用,現在看起來 GitHub 上面可以解決一些簡單的情境...

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 慢」,程式會愈來愈難維護都是你們這種人引入一堆複雜的東西 -_-

Node.js 第一個 8.x LTS 推出

推出啦:「Node v8.9.0 (LTS)」,另外可以看「NEWS: Node.js 8 Moves into Long-Term Support and Node.js 9 Becomes the New Current Release Line」這篇。

從 6 到 8 多了 async & await (ES7),應該會是對整個生態系改變最大的功能了,可以預期會有一堆人濫用... XD

剛剛測 nlts 參數發現還沒更新,先用 n 8.9.0 換上去...

Node.js 安全性更新:zlib...

前幾天「Node.js 預定在十月 24 號發表安全性更新」提到 Node.js 會發表安全性更新,已經看到 4/6/8 都出新版了:「Node v4.8.5 (Maintenance)」、「Node v6.11.5 (LTS)」、「Node v8.8.0 (Current)」。

這次安全更新的 CVECVE-2017-14919

CVE-2017-14919 - In zlib v1.2.9, a change was made that causes an error to be raised when a raw deflate stream is initialized with windowBits set to 8. On some versions this crashes Node and you cannot recover from it, while on some versions it throws an exception. Node.js will now gracefully set windowBits to 9 replicating the legacy behavior to avoid a DOS vector. nodejs-private/node-private#95

zlib 的 manualwindowBits 說明:

For the current implementation of deflate(), a windowBits value of 8 (a window size of 256 bytes) is not supported. As a result, a request for 8 will result in 9 (a 512-byte window). In that case, providing 8 to inflateInit2() will result in an error when the zlib header with 9 is checked against the initialization of inflate(). The remedy is to not use 8 with deflateInit2() with this initialization, or at least in that case use 9 with inflateInit2().

唔?XD

另外文章可以看出來 Node.js 團隊是選擇在 GitHub 上用另外一個 organization 在管這類不會事前公開的事情...

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),所以比較不適合開發者使用...

Node.js 預定在十月 24 號發表安全性更新

在「DOS security vulnerability, October 2017」這邊先發佈了日期與影響範圍,細節預定在 10/24 發表:

The Node.js project will be releasing new versions of 4.x, 6.x, and 8.x the week of the 24th of October to incorporate a security fix.

Versions 4.8.2 and later of Node.js are vulnerable.
Versions 6.10.2 and later of Node.js are vulnerable.
Versions 8.x of Node.js are vulnerable.

有心人應該可以去翻 4.8.2 改了什麼 (或是 6.10.2),不知道是不是跟前陣子的「V8 對 Hash Flooding 的防禦措施」有關...

V8 對 Hash Flooding 的防禦措施

Hash Flooding 問題是指 Hash 這個資料結構是可以被預測 collision 所造成的問題,在隨機的情況下會是 O(1) 的操作,在特定挑選故意讓他 collision 而變成 O(n),當有 n 個元素時,乘起來就會變成 O(n^2)。這算是一種阻斷攻擊 (DoS attack)。

在「About that hash flooding vulnerability in Node.js...」這邊提到了 V8 之前為了避免 Hash Flooding 的問題,關掉了 Startup snapshot 而造成的效能問題,以及後續的很多故事,最後找了長期的解法。

這個解法已經併入 Node.js 裡,預定下個包括的版本是 8.3.0:

The patch to re-enable startup snapshot has been merged into Node.js. It is part of the recent Node.js v8.3.0 release.

不過這表示現有的 LTS (4.8.4 以及 6.11.2) 還是... XD

AWS Lambda 的 Node.js 支援 6.10 了

AWS Lambda 總算是支援 Node.js 6.10 了:「AWS Lambda Supports Node.js v6.10」。不過 6 還是沒有原生的 async/await,目前的 7 才有... 還是要靠 module 支援。

繼續用 Python 2.7 寫... @_@

在 CloudFront 的 edge 上跑 Lambda

所以 Amazon CloudFront 讓使用者在 edge 上跑程式了 (雖然目前是 limited preview):「Lambda@Edge – Preview」。

分成 Viewer Request、Origin Request、Origin Response 以及 Viewer Response 四個階段可以插入修改。另外有些限制:

Because your JavaScript code will be part of the request/response path, it must be lean, mean, and self-contained. It cannot make calls to other web services and it cannot access other AWS resources. It must run within 128 MB of memory, and complete within 50 ms.

要在 128MB 內搞定,而且不能呼叫其他資源。不過這樣已經可以做很多事了... 基本上就是一台 turing machine 了 :o