IFTTT 與 n8n

看到「Goodbye IFTTT」這篇在講 IFTTT 收費後的替代方案。

我自己還是繼續用 IFTTT,主要是 Line 的 bot 申請起來太麻煩了,就花錢丟著,其他的大多都有方案可以處理。

但不管怎麼樣,open source 的方案還是可以玩看看... 文章裡其中一個提到的是 n8n,用 Node.js 寫的,裝起來也蠻簡單的 (我是用 nvm + npm 裝起來),而目前支援的項目在「Integrations (Nodes)」這邊可以看到。

跑起來後連上去,這界面看起來更像當年 Yahoo! 家的 Yahoo! Pipes,而不是 IFTTT... 有點唏噓的感覺。

晚點再多花點時間玩玩 n8n...

另外一個是用 Rails 寫的 Huginn,純粹個人偏好,應該暫時不會碰...

新版 PttBBS 用到的 flatbuffers

留個記錄上後面的人知道怎麼編...

我自己有用 PttBBS 架個站自己丟一些東西,本來是想要修改發文時延遲一秒的 sleep(1); 保護 (反正整個站也只有我自己用,patch 在 Remove sleep(1) protection. 這邊),結果升級的過程中間發現 PttBBS 上個月引入了 Google 家的 flatbuffers,就編不過去了...

找了一下找到給 Ubuntu 18.04 (bionic) 用的 PPA,是 1.11 版:「flatbuffers」,裝起來之後發現用了 --filename-suffix 語法,這個功能在 1.12 才被引入:「Added --filename-suffix and --filename-ext to flatc」。

另外就算故意拿掉 --filename-suffix,看起來 fbs 檔內也有用到 1.12 才吃的格式,所以還是照「How to install flatc and flatbuffers on linux ubuntu」這邊講的,乖乖的自己編了一個 flatc 出來用。

編好以後在 ~/.profile 裡面設定 PATH,讓編譯時可以吃到:

export PATH="${HOME}/flatbuffers:${PATH}"

然後再回去 pmake all 應該就會過了,我這邊是遇到記憶體吃爆 OOM 的情況,另外加 swapfile 就解決了...

Let's Encrypt 在 Android 平台上遇到的問題

同樣是「Standing on Our Own Two Feet」這篇文章,Let's Encrypt 預期明年九月後會在 Android 上遇到嚴重的相容性問題。

很舊的裝置主要是透過 IdenTrust 的 Root CA (DST Root CA X3) 對 Let's Encrypt 的 Intermediate CA (目前主要是 Let's Encrypt Authority X3) 簽名,從而建立憑證的信任鍊,而新的裝置除了 IdenTrust 的 CA 外,也信任了 Let's Encrypt 自家的 Root CA (ISRG Root X1):(出自「Chain of Trust」)

在 2016 年四月正式對外啟用時主要是靠 IdenTrust 的 cross-sign,而也是在 2016 年時 Let's Encrypt 自家的 Root CA (ISRG Root X1) 陸陸續續被各家收進 CA store。

所以這個時間點之前的 Android (大約是 7.1.1) 算是個相容性的分界線,在這個版本前 (而且系統無法更新的) 都只能靠 IdenTrust 的 cross-sign,這看起來大約有 33.8%,實際的流量大約是 1%~5%:

Currently, 66.2% of Android devices are running version 7.1 or above. The remaining 33.8% of Android devices will eventually start getting certificate errors when users visit sites that have a Let’s Encrypt certificate. In our communications with large integrators, we have found that this represents around 1-5% of traffic to their sites. Hopefully these numbers will be lower by the time DST Root X3 expires next year, but the change may not be very significant.

目前還有大約十個月左右的緩衝期,但大家都知道 Android 的更新速度,就十個月來說看起來不太樂觀...

官方有給他們不願意再取得一次 cross-sign 的原因,不過我覺得這個理由就很怪了,這個描述看起來是 IdenTrust 不願意再簽發一次?直覺覺得 IdenTrust 站在商業立場應該是很願意才對?而且除了 IdenTrust,應該也有其他家會有興趣?

Can we get another cross-signature? We’ve explored this option and it seems unlikely. It’s a big risk for a CA to cross-sign another CA’s certificate, since they become responsible for everything that CA does.

也有可能是放個話讓 IdenTrust 表態?先繼續看下去...

最差的情況應該就是沒有 cross-sign,然後也沒提供其他的 workaround,這樣就是買一般的 SSL certificate 來解了...

現在的 Android 市場分佈情況

剛剛看 Let's Encrypt 的「Standing on Our Own Two Feet」這篇時才發現現在 Android 市場分佈情況需要從 Android Studio 上翻:

Google no longer provides version numbers on its Distribution Dashboard, but you can still get some data by downloading Android Studio.

一路往前對應的報導分別是「Android Version Distribution statistics will now only be available in Android Studio」以及「Google kills Android distribution numbers on the web, but we’ve got you covered」。

至少有資料可以翻... 這樣看起來如果以 1% 為界線的話得要支援到 4.2?如果放寬到 2% 的話也得 4.4。如果只支援 5.0+,表示放掉快 6% 的使用者?

如果是走東南亞的話應該會更痛苦了,明天去找人聊聊好了 @_@

Mutt 跳版推出 2.0

看到「Mutt 2.0 released」這篇,Mutt 推出 2.0 版,官方的 release notes 則是在這:「Mutt 2.0 Release Notes」。

這次版本跳到 2.0 主要是因為有 incompatible changes,實質上的變更其實沒有太多:

This release was bumped to 2.0, not because of the magnitude of features (which is actually smaller than past releases), but because of a few changes that are backward incompatible.

我自己還是保留一個信箱用 Mutt 在看信,主要是有一個信箱是完全控制在自己手上,所以自己架設 mail server 並且在上面看信...

上面主要是透過 procmail 拿來收各種信件 (尤其是 mailing list),對於純文字的閱讀還是頗方便...

這幾天 blog 被掃,用 nginx 的 limit_req_zone 擋...

Update:這個方法問題好像還是不少,目前先拿掉了...

這幾天 blog 被掃中單一頁面負載會比較重的頁面,結果 CPU loading 變超高,從後台可以看到常常滿載:

看了一下是都是從 Azure 上面打過來的,有好幾組都在打,IP address 每隔一段時間就會變,所以單純用 firewall 擋 IP address 的方法看起來沒用...

印象中 nginx 本身可以 rate limit,搜了一下文件可以翻到應該就是「Module ngx_http_limit_req_module」這個,就設起來暫時用這個方式擋著,大概是這樣:

limit_conn_status 429;
limit_req_status 429;
limit_req_zone $binary_remote_addr zone=myzone:10m rate=10r/m;

其中預設是傳回 5xx 系列的 service unavailable,但這邊用 429 應該更正確,從維基百科的「List of HTTP status codes」這邊可以看到不錯的說明:

429 Too Many Requests (RFC 6585)
The user has sent too many requests in a given amount of time. Intended for use with rate-limiting schemes.

然後 virtual host 的設定檔內把某個 path 放進這個 zone 保護起來,目前比較困擾的是需要 copy & paste try_filesFastCGI 相關的設定:

    location /path/subpath {
        limit_req zone=myzone;
        try_files $uri $uri/ /index.php?$args;

        include fastcgi.conf;
        fastcgi_intercept_errors on;
        fastcgi_pass php74;
    }

這樣一來就可以自動擋下這些狂抽猛送的 bot,至少在現階段應該還是有用的...

如果之後有遇到其他手法的話,再見招拆招看看要怎麼再加強 :o

Amazon MQ 支援 RabbitMQ

Amazon MQ 本來只支援 ActiveMQ,剛剛看到消息支援 RabbitMQ 了:「Announcing Amazon MQ for RabbitMQ」。

用的版本還算可以,查了一下 3.8.6 是今年八月出的:

Amazon MQ currently supports RabbitMQ version 3.8.6 and has support for version upgrades.

基本上 ActiveMQ 版本與 RabbitMQ 版本的價錢相同,不過 RabbitMQ 看起來就只支援比較新的機器了,像是 t2 系列的機器基本上就不支援了。

然後費用相當貴,差不多是機器本身三倍左右的價錢,看起來能自己架還是可以考慮自己架...

kernel.org 推動 git push 的簽名

LWN 上看到 kernel.org 解釋並且推動 git push 的電子簽名:「Signed pushes for kernel.org」。

在「Signed git pushes」這篇裡面解釋了除了 git commit 本身的簽名外,另外 git push 的簽名也有重要性。

而在「Introducing the kernel.org git transparency log」這邊則是公開了對應的 git transparency log。

這個方法讓 kernel.org 上的 git repository 會更透明,加上 kernel.org 上的 git repository 會被很多人 mirror,在真的出問題的時候,大家手上也都有資料可以交叉比對...

在視訊會議裡面,用肩膀的移動猜測輸入的字串

在「Determining What Video Conference Participants Are Typing from Watching Shoulder Movements」這邊看到的方法,利用視訊會議時肩膀的移動猜測輸入的字串,原始的論文在「Zoom on the Keystrokes: Exploiting Video Calls for Keystroke Inference Attacks」這邊可以看到。

就論文有提到的,單就這個資訊的準確度看起來不高,看起來主要是想驗證這也是一個攻擊手法... 但馬上想到視訊會議裡如果有聲音的話,可以透過分析鍵盤的聲音攻擊,這在 2005 年的時候就有類似的手法了,而且準確率很高,不過不知道過了視訊會議軟體後會差多少:「Snooping on Text by Listening to the Keyboard」。

算是個頗特別的方法就是了...