幹壞事是進步最大的原動力
收到 IFTTT 的通知信件，本來的 Legacy Pro (US$1.99/mo) 要變成 Pro+ 變成 US$3.99/mo：
翻了一下 Hacker News，看起來前幾天有提到：「IFTTT is killing its pay-what-you-want Legacy Pro plan (2023) (techhive.com)」，原文看起來是去年六月的文章：「IFTTT is killing its pay-what-you-want Legacy Pro plan」，當時 IFTTT 的公告則是在「Important Update to the Legacy Pro Plan」這邊。
這看起來不是什麼好消息... 不是因為對 Legacy Pro 動手這件事情，而是這次的動作代表 (i.e. 我的解讀) 沒有足夠的新進用戶去「忽略」掉 Legacy Pro 的成本。
接下來應該是要思考拆出來的事情？畢竟手上有 VPS instance 可以跑...
前幾天 Let's Encrypt 決定撤銷大約兩百萬個以 tls-alpn-01 簽發的憑證：「2022.01.25 Issue with TLS-ALPN-01 Validation Method」，在 Hacker News 上的討論「Issue with TLS-ALPN-01 Validation Method (letsencrypt.org)」也可以翻一下。
這次主要是有兩個修改，第一個是要 TLSv1.2 以上，不支援舊版的 TLS 驗證：
First, we now guarantee that our client which reaches out to conduct the “acme-tls/1” handshake will negotiate TLS version 1.2 or higher. If your ACME client or integration only supports a maximum TLS version of 1.1 when conducting the TLS-ALPN-01 challenge, it will break. We are not aware of any ACME clients with this limitation.
另外一個是淘汰掉 legacy OID：
Second, we no longer support the legacy 1.3.6.1.5.5.7.1.30.1 OID which was used to identify the acmeIdentifier extension in earlier drafts of RFC 8737. We now only accept the standardized OID 1.3.6.1.5.5.7.1.31. If your client uses the wrong OID when constructing the certificate used for the TLS-ALPN-01 handshake, it will break. Please either update your client, or switch to using a different validation method.
目前還是以 http-01 與 dns-01 為主，暫時不用管，但如果有人用 tls-alpn-01 的稍微注意一下吧...
本來的舊的 Ubuntu ESM 是額外的三年 (加上本來的 LTS 五年，共八年)，14.04 會支援到 2022 年四月 (參考 Internet Archive 上的存檔資料「Ubuntu 14.04 LTS has transitioned to ESM support」)，然後 16.04 會支援到 2024 年四月 (參考 Internet Archive 上的存檔資料「Ubuntu 16.04 LTS transitions to Extended Security Maintenance (ESM)」)，而 18.04 與 20.04 以後的 Ubuntu ESM 則是額外五年。
現在則是宣佈 14.04 與 16.04 都切齊額外五年了，所以總共都是十年：「Ubuntu 14.04 and 16.04 lifecycle extended to ten years」。
另外在 Hacker News 上的討論可以看一下：「Ubuntu 14.04 and 16.04 lifecycle extended to ten years (ubuntu.com)」，有人覺得這個政策很糟，但我覺得還好，有些商業環境就是花錢解決懶得升級... (沒有 support 只有 security update 的方案，一台實體機器才 USD$225/year，如果是虛擬機的話就更便宜了)
算是對付 legacy application 還蠻重要的方案...
在 Red Hat 的 blog 上看到 SCTP over UDP 的方式，讓不支援 SCTP 的 NAT 裝置也能使用 SCTP：「An easier way to go: SCTP over UDP in the Linux kernel」。
這個方式也是個標準，在 RFC 6951：「UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication」。
Linux kernel 則是在 5.11 之後才支援，不過翻了一下 5.11 是一般版，在 2021 年二月釋出，在五月底就已經 EoL：
Stream Control Transmission Protocol over User Datagram Protocol (SCTP over UDP, also known as UDP encapsulation of SCTP) is a feature defined in RFC6951 and implemented in the Linux kernel space since 5.11.0.
上一個 LTS 版本是 5.10，下一個不知道是什麼時候了...
先前在「Let's Encrypt 在 Android 平台上遇到的問題」這邊提到了 IdenTrust 幫 Let's Encrypt 交叉簽名的有效日會在 2021 年的八月底左右到期，而這會導致比較舊的 Android 平台因為沒有內建 ISRG Root X1 這個憑證，造成 Let's Encrypt 簽出來的憑證在這些舊的 Android 裝置上都認不出來。
文章出來過了一個多月後，剛剛看到 Let's Encrypt 發佈消息，IdenTrust 願意再交叉簽名三年：「Extending Android Device Compatibility for Let's Encrypt Certificates」，當時猜測發文是要讓 IdenTrust 表態，看起來目的達成了...
話說中間跑出來的「ZeroSSL 也提供免費的 SSL Certificate (DV) 了」不知道後續會怎麼樣，之後可以看看 Certificate Transparency 的資料來看看到底有多少人用...
在「Migrating to MySQL 8.0 without breaking old application」這邊看到這個有趣的故事 XD 這是作者的應用程式 Drupal 從 MySQL 5.5 一路升級到 8.0 的過程記錄...
真正的問題發生在 5.7 到 8.0：
原因是 Drupal 用到關鍵字了：
In fact, this old Drupal, uses a table name that is now part of the reserved keywords. It’s always advised to verify what are the new keywords reserved for MySQL itself. New features can also mean new keywords sometimes.
修正後就好了：
話說依照「File:Drupal release timeline.png」這邊的資訊，Drupal 6.2 也十年左右了？應該是 PDO 剛開始要推廣的年代，不知道他跑哪個版本的 PHP...
另外 MySQL 的升級意外的順利？雖然是一步一步升，但沒遇到什麼大問題...
在 Bruce Schneier 那邊看到的：「Attack on Old ANSI Random Number Generator」，攻擊的網站在「The DUHK Attack」，論文在「Practical state recovery attacks against legacy RNG implementations (PDF)」。
攻擊的對象是 ANSI X9.31 Random Number Generator：
DUHK (Don't Use Hard-coded Keys) is a vulnerability that affects devices using the ANSI X9.31 Random Number Generator (RNG) in conjunction with a hard-coded seed key.
Traffic from any VPN using FortiOS 4.3.0 to FortiOS 4.3.18 can be decrypted by a passive network adversary who can observe the encrypted handshake traffic.
如果照說明的只到 4.3.18，那麼去年 11 月更新的 4.3.19 (參考「FortiOS 4.3.19 Release Notes」) 應該是修正了？不過裡面沒翻到類似的資料，是剛好把 RNG 換掉了嗎？
