Python 2.7 的延伸支援

Python 2 在大約四年前 2020/04/18 推出了最後一版 Python 2.7.18 後,後續的安全性更新就變成要找第三方支援了。

在 2023/09 出的 Trac 1.6 總算是換到 Python 3 後,手上就沒有遇到要用 Python 2.7 的東西了...

剛剛在「PyPy v7.3.16: release of python 2.7, 3.9, and 3.10」這邊看到跟 Python 2.7 有關的消息,一時興起翻了翻有哪些延長的商業支援可以買,看起來有兩個:

真的遇到的話再來寫信問問看好了...

MySQL 5.7 已經 EoL

查資料發現忘記這件事情了... 先前就有寫過 MySQL 5.7 到今年十月就 EoL 了:「MySQL 5.7 的支援只到今年十月 (Oct 2023)」。

最後一版是 2023/10/25 釋出的 5.7.44:「Changes in MySQL 5.7.44 (2023-10-25, General Availability)」。

MySQL 5.7.44 is the final release of the MySQL 5.7 series.

然後 MySQL 8.1 也是十月 EoL。

雖然目前已經有 MySQL 8.2 了,但 MySQL 8.0 是 LTS,目前預定支援到 2026 年四月 (大約還有兩年多),所以除非有需要用到 MySQL 8.2 的新功能或是特性,不然應該還是會先繼續用 MySQL 8.0...

然後翻了一下 Percona Server for MySQL,看起來還是沒有提供 ARM 的 binary 可以裝,所以在 ARM 上面的機器比較方便的還是裝 MariaDB 了...

OpenSSL 1.1.1 EoL

看到 OpenSSL 官方的公告,1.1.1 版 EoL:「OpenSSL 1.1.1 End of Life」(btw,我不知道他們為什麼網址上會放兩個 /blog/...)。

OpenSSL 1.x 與 3.x 最大的差異就是他的 license 了,1.x 版是 dual license,但這兩個 license 都與 GPL 不相容:

OpenSSL was dual-licensed under the OpenSSL License and the SSLeay License, which means that the terms of either licenses can be used. The OpenSSL License is Apache License 1.0 and SSLeay License bears some similarity to a 4-clause BSD License.

As the OpenSSL License was Apache License 1.0, but not Apache License 2.0, it requires the phrase "this product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit" to appear in advertising material and any redistributions (Sections 3 and 6 of the OpenSSL License). Due to this restriction, the OpenSSL License and the Apache License 1.0 are incompatible with the GNU GPL.

後續 3.x 的版本則改成 Apache License 2.0 了:

OpenSSL announced in August 2015 that it would require most contributors to sign a Contributor License Agreement (CLA), and that OpenSSL would eventually be relicensed under the terms of Apache License 2.0.

不過 Apache License 2.0 與 GPLv2 還是不相容 (但相容於 GPLv3),這個更換只是換成一個比較常見的 license:

The Free Software Foundation considers all versions of the Apache License to be incompatible with the previous GPL versions 1 and 2.

話說 Ubuntu 20.04 內的 OpenSSL 是 1.1.1f,看起來光是標準的 LTS (到 2025/04) 期間都得自己維護了?其他作業系統應該也會有類似的問題...

ISC DHCPD 要 EoL

看到「ISC DHCP Server has reached EOL」這個,月初的時候 ISC 宣佈了 EoL,除非有嚴重的安全性問題冒出來,不然官方打算停止維護了:

The 4.4.3-P1 and 4.1-ESV-R16-P2 versions of ISC DHCP, released on October 5, 2022, are the last maintenance versions of this software that ISC plans to publish. If we become aware of a significant security vulnerability, we might make an exception to this, but it is our intention to cease actively maintaining this codebase.

ISC 則是在推 Kea

Network and system administrators deploying DHCP in new environments should look beyond ISC DHCP for a solution, as it would be irresponsible to invest in new deployments of this software which is now end-of-life. Naturally, ISC suggests new users consider our Kea DHCP server, but there are alternatives.

從維基百科上的「Comparison of DHCP server software」這頁可以看到目前 DHCP server 的選擇。最直接的差異是,其他非 ISC 的全部都是 GPL,只有 ISC 的是 non-GPL。

不過一般不太會自己架 DHCP server,大多是用設備內建裝的跑,以後如果有機會要裝的話,也許得去熟悉 Kea 了...

GOV.UK 拔掉網頁上的 jQuery

英國政府的網站拔掉 jQuery 了:「GOV.UK drops jQuery from their front end.」,Hacker News 上的討論也可以看一下:「Gov.uk drops jQuery from their front end (web.dev)」。

當年會選擇用 jQuery 大概有幾個原因,第一個是當年 (很舊的 browser 版本) 對 DOM 的操作非常的混亂,像是:

而 jQuery 在那個年代就已經把這堆 DOM operation 都窮舉支援了 (可以直接看「Category: DOM Insertion, Around」、「Category: DOM Insertion, Inside」、「Category: DOM Insertion, Outside」這三個大分類),可以注意 jQuery 1.0 就已經把基本界面都弄出來了,而 jQuery 1.0 是 2006 年八月出的,另外 IE7 是在 2006 年十月出,也就是說在 IE6 的年代就提供一整套完整的方案。

另外 jQuery 幫忙處理了早期 IE 與 W3C 標準的不一致行為,像是經典的 attachEvent (出自 DOM events):

Microsoft Internet Explorer prior to version 8 does not follow the W3C model, as its own model was created prior to the ratification of the W3C standard. Internet Explorer 9 follows DOM level 3 events, and Internet Explorer 11 deletes its support for Microsoft-specific model.

就功能面上來說,jQuery 提供的 Sizzle engine 也提供了 CSS selector 的能力,這在早期還沒有 querySelectorAll() (IE9+) 的時候方便不少,而且就算有了 querySelectorAll(),Sizzle 支援的 CSS selector 更完整。

上面提到的解決 browser 早期的各種亂象,jQuery 其實也帶入了不少好用的 pattern,其中一個是 fluent interface 讓人寫起來很舒服:(這個範例只是要介紹 fluent interface,不要管實際上在亂搞什麼 XD)

$('#foo').html('<p>bar</p>').css('width: 100px;');

另外就是不需要對 null object 做太多處理:

$('#foo').css('width: 100px;');

與這樣比較:

let elem = document.querySelector('#foo');
if (elem) {
    // ...
}

不過在這些年,負面的部份已經大幅改善了,所以也陸陸續續可以看到很多人在討論要怎麼拔掉 jQuery。而這次英國的 GOV.UK 拔掉 jQuery 有看到一些效果:

  • Less front end processing time overall.
  • 11% less blocking time at the 75th percentile.
  • 10% less blocking time for users at the 95th percentile. These are users who experience seriously adverse network and device conditions, and every performance gain matters especially for them.

但說實話,~10% 左右的 performance 改變比預期中少很多耶?可以看出來 John Resig 當年在上面為了效能花了多少功夫...

這次的結果反倒是讓我在思考,如果可以用 jQuery 降低開發的瓶頸,我還蠻偏好就拿 jQuery 進來用...

棄用 Keybase (Zoom 買下 Keybase 的新聞)

前幾天的新聞,Zoom 的新聞稿:「Zoom Acquires Keybase and Announces Goal of Developing the Most Broadly Used Enterprise End-to-End Encryption Offering」,Keybase 的新聞稿:「Keybase joins Zoom」,看到後就把本來的服務刪一刪了...

這篇屬名由 Zoom 創辦人發出的公告,裡面多到讓人不知道怎麼吐槽的部份,我們就把唯一的粗體字拉出來討論好了:

We are excited to integrate Keybase’s team into the Zoom family to help us build end-to-end encryption that can reach current Zoom scalability.

先不講先前被戳破根本就不是 end-to-end encryption 的問題,影音上面因為 transcoding 的問題,如果要在 video stream 上做 end-to-end encryption 的話分成兩種方式可以做:

a) 一種是發送端直接產生出多個不同 bitrate 的 video stream,這種方式其他家都已經很熟悉了,缺點也很明顯,就是吃各種資源,包括發送端的壓縮能力與頻寬。

b) 另外一種方式是產生出可以疊加的 video stream,有點像是 progressive image 的方式,第一個 stream1 的畫質最低,第二個 stream2 則是「補強」第一個 stream1,這樣子可以降低資源的需求。

另外有想到 Homomorphic encryption 的方式,直接可以疊加加密後的 stream1 + stream2,不過 bitrate 應該不會降低,就算真的設計的出來應該也沒用...

如果是 a) 的方式,業界對於 key 的交換都已經解的還不錯了,但這個方式沒什麼競爭性 (因為其他家也都已經做完了)。

如果是 b) 的方式,很明顯該找的是 codec 的公司 (要做出可以疊加的 codec),而不是搞密碼學的公司。

回到原來的問題,現有的團隊有 2500 人,裡面的技術團隊沒辦法搞定 end-to-end encryption,ok 沒關係,那現在的 CTO Brendan Ittelson 應該可以建一個團隊吧?所以我翻了一下他的 LinkedIn 看了一下他的經歷,對不起我錯了,我瞬間不知道怎麼寫下去了,我豆頁痛...

許多 VPS 同時宣佈停止營業的消息

前陣子有許多 VPS 同時宣佈停止營業的消息:「20 VPS providers to shut down on Monday, giving customers two days to save their data」。

文章裡面列了 20 個 VPS,而這 20 個在 LowEndBox 上都有出現,我就把搜尋的連結直接整理出來了,想確認的人可以展開來看 XDDD:

話說我之前也中了兩個 (SupremeVPS 與 UMaxHosting),後來就覺得 LowEndBox 上的站台都怪怪的... 結果最近就有人開一個站整理出倒閉表格 XDDD:「LowEndDeadPool」。

開頭也講得很直接,現在 LowEndBox 基本上的貨色基本上都是... XD:

As of December 2019, it is pretty safe to say that all hosts listed at LowEndBox are a scam at best (except for QuadraNet and Virmach).

現在得透過其他方式找...

便宜 VPS 主機的找法...

因為手上 side project 很多,有時候想要長期測一些東西,就需要租用性價比比較好的 VPS。

其中 VPS 的基準點應該是以 LinodeDigitalOcean 以及 Vultr 這幾家為主,而目前這幾家的基準點都是 RAM 的部份,目前是 1GB RAM VPS 約 $5/month。

如果你不想花太多時間在研究,選這幾家應該沒什麼問題,Linode 與 Vultr 都算是很不錯的方案。另外雖然 DigitalOcean 的 CPU 比較差,但可以看出他在非 IaaS 的服務上花了不少力氣,想要朝類似 AWS 的方向在走,如果你想要用到他們的服務,但又不想要用純正的 cloud service 的話 (通常是價位考量),可以考慮看看他們家的服務。

另外一方面,因為我自己喜歡設定底層系統,所以會朝「便宜」的方向找 VPS (能設定的東西比起 Web Hosting 多很多),然後因為機器數量愈來愈多,所以在我自己的 wiki 上整理了「Hosting」這個條目,之後就有些朋友看到價錢就會問怎麼找的... (像是 1.5GB RAM + 20GB Disk 一年只要 USD$14 這種價錢)

我主要是透過 Low End Box - Cheap VPS Hosting Providers Listing & Reviews 這邊找的,這邊常常會有各家 VPS 提供促銷,這時候可以朝幾個方向看:

  • 公司成立時間:透過 whois 資料可以看到一些,另外文章上面通常會直接對 vps 下 tag,可以看看之前是不是有跟 Low End Box 合作過。
  • 以往的評價:透過 tag 找到之前的促銷,然後看看 comment 的評價。先記住這種便宜的 VPS 不會有完美的狀態,如果負評可以接受的話就可以考慮。

另外要注意的是,這類 VPS 我通常都是先假設「資料掉了不會痛」的想法在用,然後主要是以 PayPal 為付款方式,避免主機商跑路後沒辦法拿到退款 (yeah 我遇過 XD)。

這類 VPS 主機有兩種形式:

  • 最常見的是 OpenVZ 類的,通常這類會很便宜,但限制是 RAM 與 Swap 的數量一開始就決定了,也就是你沒有辦法透過 file swap 增加可以用的記憶體。另外因為是 OpenVZ 的關係,上面不能跑 Docker 之類的 container。
  • 另外一種是虛擬機類的,通常會比 OpenVZ 類貴一些,像是 KVM 或是 Xen,這類因為技術上是全虛擬化,通常都可以跑 Docker 這類 container 技術。

接下來就是踩地雷了... XD

Python 2 的 EoL 日期將會是 2020 年年初

在「Python 2 EOL will be 2020-01-01」這邊看到的,文章標題的連結是 mailing list 上的內容:「[Python-Dev] Python 2.7 -- bugfix or security before EOL?」。

Guido van Rossum (Python 的發明人) 在回覆關於「Python Developer’s Guide — Python Developer's Guide」上面的資訊時的說明... 大約還有一年九個多月的時間。

然後發現原來 Python 在 release 時是會發佈 PEP 的,像是「PEP 373 -- Python 2.7 Release Schedule」這樣的資訊。其他版本可以在索引頁「PEP 0 -- Index of Python Enhancement Proposals (PEPs) | Python.org」翻到。

End-to-End Encryption 的標準?

看到「The Messaging Layer Security (MLS) Protocol」這個被提出來的標準,還在討論中...

簡介就說明了這個標準除了標準的 E2E 外,還設計了有效率的 Group 機制:

Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two participants need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy and post-compromise security for groups in size ranging from two to thousands.

要設計機制的人可以拿來翻翻看...