RFC 9512:application/yaml

看到「RFC 9512: YAML Media Type」這個,原來還沒有註冊 application/yaml 啊...

另外在 media type 的文件裡面,意外的給出了安全性的建議:

Code execution in deserializers should be disabled by default and only be enabled explicitly. In the latter case, the implementation should ensure (for example, via specific functions) that the code execution results in strictly bounded time/memory limits.

這邊用的是 should 不是 SHOULD,所以當一般的英文句子在讀,而非具有規範性的敘述。

但還是給了預設關閉 code execution 的建議...

LSAs 與 application password 不同...

前天在「使用 application password 的 Google 服務將在 2024/09/30 停止支援」這邊寫完後,yan12125 在文章留言的地方提到:

看起來這次只有停止支援 Less Secure Apps, application password 還是可以用的。公告中提到:

> If the app you are using does not support OAuth, you will need to switch to an app that offers OAuth or create an app password to access these apps.

回頭去翻了一下 LSA 是什麼 (出自「Limiting access to less secure apps to protect G Suite accounts」這篇):

A less secure app (LSA) is an app that connects to Google accounts using only username and password verification for access and not OAuth. Generally, you should only allow your users to use external apps that connect to Google accounts via OAuth, as LSAs make user accounts more vulnerable to hijacking.

看起來這邊指的是用原始的 Google 帳號與密碼登入,我一直以為這個方式早就被拔掉了,所以這次的公告以為是拔掉 application password,但看起來不是這樣。

玩了一下 OpenSnitch,Linux 下的 Application Firewall

這是在 Hacker News 上的討論「Brute-forcing a macOS user’s real name from a browser using mDNS (fingerprint.com)」這篇看到的,裡面一開始是提到 Mac 上面的 Little Snitch,可以針對特定應用程式設定防火牆規則,而在 Linux 上對應的解決方案則是 OpenSnitch,但一直沒有嘗試,所以就試著用看看...

套件分成兩個部分,一個是 OpenSnitch 的主程式,另外一個是 GUI 的部分。

而在 Ubuntu 22.04 上裝有點麻煩,因為 Ubuntu 22.04 上預設的 grpc package 似乎是有 bug,需要裝新版解決。

不過我在找 PPA 的時候發現有人包了輔助套件:「OpenSnitch - application firewall (Xenial & newer)」。

這個套件本身是沒有包 OpenSnitch 主程式與 GUI 套件的,他只是要「補充」官方套件安裝的問題,所以需要照他的說明安裝:(我把下面指令提到的 1.5.2 換成目前新版的 1.6.0 裝,目前看起來是會動的)

sudo add-apt-repository ppa:savoury1/opensnitch
sudo apt-get update && sudo apt-get upgrade
sudo dpkg -i opensnitch_1.5.2-1_amd64.deb
sudo dpkg -i python3-opensnitch-ui_1.5.2-1_all.deb
sudo apt-get -f install

這邊用 dpkg -i 裝,而不是用 apt install 的原因是故意讓他不裝 dependency,等到後面的 apt-get -f install 時再裝 PPA 裡面提供的 dependency。

裝好後把跑 opensnitch-gui 起來後就會陸陸續續收到系統內不同的應用程式嘗試的連線,像是官網提供的 screenshot 這樣 (會跳出像左邊這樣的視窗):

這樣可以控的比較細,不過剛開始用會需要花時間把系統內常態性的 request 先設定過一次,還蠻煩的 XD

AWS ALB 支援 TLS 1.3?

AWSALB 宣佈支援 TLS 1.3:「Application Load Balancer now supports TLS 1.3」。

本來以為早就支援了,翻了一下發現應該是太多產品線的關係搞混了:

ALB 則是到了 2023 才支援 TLS 1.3...

「SMS 認證」被電信商 (以及第三方) 拿來套利的市場

Hacker News 上看到「Twitter Lost $60M a Year Because 390 Telcos Used Bot Accounts to Pump A2P SMS (commsrisk.com)」這篇,內文報導是這裡:「Elon Musk Says Twitter Lost $60mn a Year Because 390 Telcos Used Bot Accounts to Pump A2P SMS」。

簡訊的實際成本極低,但利潤超級高,發送方與接收方都有極大的獲利空間。

而這邊提到的 SMS pumping 的方式就是電信商自己做,或是電信商與第三方合作,利用各種發簡訊的方式 (內容不重要),讓 app 端要付出大量的簡訊成本,進而產生出大量的利潤。

Twilio 的「SMS Traffic Pumping Fraud」這頁就有這張圖:

簡訊的特點是很好 scale,你無法同時間接大量的電話,但可以同時間收大量的簡訊。在「SMS Fraud is costing you more than you realize」這邊也有提到這個問題。

這個問題在去年年底在我們自家的服務上就有看到跡象 (東南亞市場頗明顯),當時搜尋有一些討論,而現在看起來 Elon Musk 這次吵應該又會有更多熱度...

話說這樣演化下去,SMS 認證的退場又多了一個理由,除了 SS7 在資安上的安全問題外,看起來成本問題也會跑進來。

DOS 下的 TCP/IP 程式組

Hacker News 上看到「mTCP: TCP/IP applications for DOS PCs (brutman.com)」這個有趣的東西,在 DOS 環境下的 TCP/IP 程式組,原網站在「TCP/IP applications for your PC compatible retro-computers」這邊。

不過我覺得比較神奇的是,他的測試環境是真的包括一堆老機器跟網卡耶 XDDD

裡面提到的 NE1000ISA 界面的卡,這樣聽起來保養的都還不錯...

NLB 接 ALB?

AWS API Changes 上看到這個修改:「2021/09/27 - Elastic Load Balancing - 3 updated api methods」。

說明是這樣:

Adds new ALB-type target group to facilitate forwarding traffic from NLB to ALB

所以是 NLB 可以接到 ALB 嗎,這看起來讓彈性變大不少...

PostgreSQL 的 Job Queue、Application Lock 以及 Pub/Sub

Hacker News Daily 上看到一篇講 PostgreSQL 做 Job Queue、Application Lock 以及 Pub/Sub 的方法:「Do You Really Need Redis? How to Get Away with Just PostgreSQL」,對應的討論在「Do you really need Redis? How to get away with just PostgreSQL (atomicobject.com)」這邊可以翻到。

拿 PostgreSQL 跑這些東西的確有點浪費,不過如果是自己的專案,不想要把 infrastructure 搞的太複雜的話,倒是還不錯。

首先是 Job Queue 的部份,從他的範例看起來他是在做 async job queue (不用等回傳值的),這讓我想到很久前寫的 queue service (應該是 2007 年與 2012 年都寫過一次),不過我是用 MySQL 當作後端,要想辦法降低 InnoDB 的 lock 特性。

async job queue 設計起來其實很多奇怪的眉角,主要就是在怎麼處理失敗的狀態。大多數的需求可以放到兩個種類,最常見用的是 at-least-once,保證最少跑一次,大多數從設計上有設計成 idempotence 的都可以往這類丟,像是報表類的 (重複再跑一次昨天的報表是 OK 的),另外每天更新會員狀態也可以放在這邊。

另外少見一點的是 at-most-once 與 exactly-once,最多只跑一次與只跑一次,通常用在不是 idempotence 的操作上,像是扣款之類的,這邊的機制通常都會跟商業邏輯有關,反正不太好處理...

第二個是 Application Lock,跨機器時的 lock 機制,量沒有很大時拿 PostgreSQL 跑還行,再大就要另外想辦法了,馬上想到的是 ZooKeeper,但近年設計的系統應該更偏向用 etcdConsul 了...

最後提到的 Pub/Sub,一樣是在量大的時候拿 PostgreSQL 跑還行,更大的時候就要拿 Kafka 這種專門為了效能而設計出來的軟體出來用...