GitHub 放出了他們整理過的 GitHub Advisory Database

GitHub 宣佈開放他們整理過的 GitHub Advisory Database:「GitHub Advisory Database now open to community contributions」,Hacker News 上有 GitHub 的 PM 回答一些問題,也可以看看:「GitHub’s database of security advisories is now open source (github.blog)」。

對應的 repository 在「github/advisory-database」這邊可以看到,用的格式是 Open Source Vulnerability format,裡面都是 JSON 檔案。

裡面看起來是從 2017/10 開始的資料,這樣算起來大約累積了四年半,算是一個來源...

NGINX 官方給的十個常見的設定錯誤

也是在 Hacker News 上看到的,NGINX 官方給的 10 個設定上的常見錯誤:「Avoiding the Top 10 NGINX Configuration Mistakes」,對應的討論串在「Avoiding the top Nginx configuration mistakes (nginx.com)」這邊,看了一下裡面還蠻多蠻實用的?(雖然有些算是官方自己的偏見,或是官方自己在搞事...)

第一個是 worker_connections 設定與 fd 的上限沒有對應,因為每個連線會吃掉兩個 fd,所以要給夠才有辦法讓 connection 衝上去:

The common configuration mistake is not increasing the limit on FDs to at least twice the value of worker_connections. The fix is to set that value with the worker_rlimit_nofile directive in the main configuration context.

另外就是要檢查系統的 limit 設定,像是 /etc/security/limit.conf 這類的設定。

第二個是 error_log off 這個設法,在 NGINX 裡面是有 access_log off,但沒有 error_log off 這個設法,如果你這樣設的話會寫到 error 這個檔名內。所以如果真的要丟掉的話要丟到 /dev/null,像是官方給的範例這樣:

error_log /dev/null emerg;

第三個是 NGINX 對 upstream (backend) 沒有設定 keepalive,這會導致在量很大的時候會產生不少 overhead。

第四個是違反直覺的繼承設定,官方用這樣的範例來表達:

http {
    add_header X-HTTP-LEVEL-HEADER 1;
    add_header X-ANOTHER-HTTP-LEVEL-HEADER 1;

    server {
        listen 8080;
        location / {
            return 200 "OK";
        } 
    }

    server {
        listen 8081;
        add_header X-SERVER-LEVEL-HEADER 1;

        location / {
            return 200 "OK";
        }

        location /test {
            add_header X-LOCATION-LEVEL-HEADER 1;
            return 200 "OK";
        }

        location /correct {
            add_header X-HTTP-LEVEL-HEADER 1;
            add_header X-ANOTHER-HTTP-LEVEL-HEADER 1;

            add_header X-SERVER-LEVEL-HEADER 1;
            add_header X-LOCATION-LEVEL-HEADER 1;
            return 200 "OK";
        } 
    }
}

而你會發現 add_header 會蓋掉先前繼承的項目,但同一個 block 之間會疊加而不是蓋掉...

所以打 localhost:8081/test 的時候只會有 X-LOCATION-LEVEL-HEADER: 1;打 localhost:8081/correct 會有四個 HTTP headers...

第五個算是官方自己的偏見,我們一般都會希望壓低 TTFB (Time To First Byte),把 proxy_buffering 關閉算是常態了。

第六個是官方雖然實做了 if 但很不希望你拿來用。

第七個是 health check 的正確設法,避免多個 block 都有 health check,造成無用的功夫。

第八個是保護內部的資訊,這邊給的範例是 stub_status

第九個是個地雷,ip_hash 這個演算法可以依據 client 的 IP address 來打散流量到後端的伺服器上,對於 IPv6 他會拿整個 IPv6 當作 key (128 bits),但對 IPv4 他只會拿前面三碼 (24 bits) 當作 key:

The ip_hash algorithm load balances traffic across the servers in an upstream{} block, based on a hash of the client IP address. The hashing key is the first three octets of an IPv4 address or the entire IPv6 address. The method establishes session persistence, which means that requests from a client are always passed to the same server except when the server is unavailable.

這完全就是官方自己在搞... 而 workaround 是自己指定 key:

The fix is to use the hash algorithm instead with the $binary_remote_addr variable as the hash key.

第十個是沒有使用 upstream,大多數的情況就是測試發現會動,就直接上 production 的關係 XDDD

Mac 上 sprintf 的 scalability 問題

Hacker News 上看到個有趣的 scalability 問題,在 Mac 上的 sprintf() 因為有 lock 造成的 scalability 問題:「Curious lack of sprintf scaling (aras-p.info)」。

作者注意到 Mac 在多 CPU 下 sprintf() 會有 scalability 的問題,要注意到這邊的 Y 軸是對數比例:

用了 std::stringstream << 反而更慢 (作者還酸了一句「Zero cost abstractions」):

然後用了 Instruments 跑 profiling 找問題,可以看到看起來跟 locale 有關:

一般的情況下應該不會是問題,但如果是需要大量 sprintf() 組字串的人就會比較要注意了。

在「What else can we do?」這段有提到一些解法,包括了 stb_sprintf 當作替代品,以及 {fmt} 作為 iostreams 的替代品,然後另外是利用 to_chars 來解決,如果只是要把數字轉成字串。

算是蠻有趣的 bug hunting 過程,對於開發者來說,一般性的重點還是在 profiling,找到對的問題然後再往下提出解法...

關於 Hacker News 上在討論 Microsoft Teams 的一些有趣的發現

Hacker News 上看到「Ask HN: Why is MS Teams so slow, do devs test Teams on less powerful machines?」這串討論,發起的作者提到了超級吃資源的問題:

I have a laptop with an i5 processor and 8G of RAM. Hard drive is an SSD. It sometimes takes me a full minute and a half to get Teams open and ready to join a meeting. It is driving me crazy.

可以預期下面本來就會有一堆人在抱怨,不過意外看到有趣的回應:

Ex office dev here. Actual dev work is done on i9 workstations running 64 gb of ram, and usually located very near an Azure data center, regardless of where the dev works. The result is that it's fast for us.

Everyone knows that it runs like poop, but there are other priorities, and no performance regression tests.

所以你應該只要電腦夠暴力 + 離機房夠近就會快了 XDDD

的確像是最上面的 comment 提到的,開發者因為都用 MBP,至少還能動 (因為機器夠快),但其他團隊則是一直幹勦:

At my company, the developers are all on fairly powerful MacBook Pros, and everyone else in the company has Windows laptops (I think generally Surface devices)

For the developers, Teams works... as good as Teams can. So not great, but it works most of the time (for me, anyway). For everyone else though, I hear nothing but issues. Constantly having to restart to make Teams work. And again, this is on Surface devices, so Microsoft is making the app, the OS, and the hardware!

I have no capslock and I must scream

前幾天看到「I have no capslock and I must scream (marginalia.nu)」這個討論,原文的標題是致敬於「I Have No Mouth, and I Must Scream」這篇小說,所以就決定把原標題留起來好了...

原文在「I have no capslock and I must scream」這邊,在原文的後面提到了 Mozilla 的這張 ticket,應該就是寫這篇文章的「主因」了:「Replace the Text Encoding menu with a single override item Repair Text Encoding」。

這種行為也是為什麼即使 Chrome 愈來愈爛,也不打算跳去 Firefox 的原因...

Amazon S3 支援 MD5 以外的檢查演算法了

Amazon S3 宣佈支援 MD5 以外的檢查演算法了:「New – Additional Checksum Algorithms for Amazon S3」。

多支援了 SHA-1SHA-256 以及 CRC-32CRC-32C

In particular, you can specify the use of any one of four widely used checksum algorithms (SHA-1, SHA-256, CRC-32, and CRC-32C) when you upload each of your objects to S3.

雖然有拿 cryptographic hash function 來用,但其實是當作 checksum algorithm 在用,拿來檢查檔案正確性的,而不是防中間被竄改之類 (這個部份是靠 HTTPS),本來支援的 MD5 應該算是夠用,只是現在多了不少選擇。

然後全商用區都可以用了:

The four additional checksums are now available in all commercial AWS Regions and you can start using them today at no extra charge.

心情不好時自動送貓貓圖推播的專案

Hacker News 上看到「I wrote a program that sends cats to my phone when I'm sad at the computer (healeycodes.com)」這個東西,居然是用 cam 判斷,當判斷心情不好的時候就推播貓貓的圖片,像是這樣:

除了 machine learning 的部份快,這邊還用到了幾個服務,像是 PushoverThe Cat API (居然有這種服務 XDDD)...

馬上想到前陣子看的 Don't Look Up (千萬別抬頭),裡面好像也有類似的產品 XDDD

jless:檢視 JSON 的工具

前幾天在「Show HN: Jless, a command-line JSON viewer (pauljuliusmartinez.github.io)」這邊看到用 Rust 寫的 jless 這個工具,官網有個動圖可以參考:

這樣方便不少,就不需要自己在對半天...

另外也剛好拿來練手,把 Rust 寫的套件包成 Ubuntu PPA:「PPA for jless」。

主要是 cargo vendor 這個指令可以把相依套件都抓下來放到 vendor/ 下面,然後設定 .cargo/config.toml 後就可以在本地端處理了,這對於 build farm 限制 internet 連線的情況會好用很多...

168.95.1.1 與 168.95.192.1 對 CloudFront 的差異

tl;dr 版本:目前先用 PPPoE 發出來的 DNS resolver 設定,如果要自己設定的話,用 168.95.192.1 (主) + 168.95.1.1 (次) 然後關掉 round-robin 模式。

剛剛看 SmokePing 時發現的奇怪現象,同樣都是在 HiNet 下面的機器與 DNS resolver,但 CloudFront 會給出不同的機房提供服務。

講的更仔細的是,168.95.192.1 這組會給出 tpe 系列的機房,所以 latency 會比較低,但如果你用的是 168.95.1.1 的話,就會到處丟,包括日本的 nrt 系列,與香港的 hkg 系列。

這邊拿 d36cz9buwru1tt.cloudfront.net 這組網域觀察,這是 AWS 官網用的資源,從官網的 html 原始碼裡面可以看到。

以第四台網路上面的機器上面來看 (北都,我分配到的線路是走台灣智慧光網的線路),可以看到這邊 latency 會飄:「d36cz9buwru1tt.cloudfront.net (CloudFront)」。

看了一下 DNS 設定,第四台的 ISP 給了兩組 DNS resolver 設定給分享器,分別是 168.95.1.18.8.8.8,然後分享器的 DNS resolver 是 round-robin,所以有時候會在台灣,有時候就連出國...

不過這組不能直接說是 AWS 的問題,因為 ISP 自己不架 DNS server,還跑去用 HiNet 的,有 sub-optimal 的問題也是很正常...

另外就是確認放在 HiNet 線路上的機器,這邊 ISP 透過 PPPoE 給了 168.95.192.1168.95.1.1,但因為是直接進到 /etc/resolv.conf,所以只有在第一組爛掉的時候才會導去第二組 (預設值),所以看起來就很穩:「d36cz9buwru1tt.cloudfront.net (CloudFront)」。

實際分析從 HiNet 去 168.95.1.1168.95.192.1 查時,也可以看到類似的情況,像是用這樣的 command 去看 168.95.1.1 的情況:

( repeat 1000 host d36cz9buwru1tt.cloudfront.net 168.95.1.1 ) | grep 'has address' | awk '{print $NF}' | awk -F. '{print $1 "." $2 "." $3}' | sort -u | awk '{print $1 "." 1}' | xargs -n1 host | awk '{print $NF}'

可以看到給出來的點都是日本 (nrt 與 kix):

server-13-225-178-1.nrt57.r.cloudfront.net.
server-143-204-74-1.nrt12.r.cloudfront.net.
server-18-65-171-1.nrt57.r.cloudfront.net.
server-18-65-99-1.kix50.r.cloudfront.net.
server-54-192-254-1.nrt51.r.cloudfront.net.
server-54-230-123-1.kix56.r.cloudfront.net.
server-99-84-55-1.nrt20.r.cloudfront.net.

如果改掃 168.95.192.1 的話:

( repeat 1000 host d36cz9buwru1tt.cloudfront.net 168.95.192.1 ) | grep 'has address' | awk '{print $NF}' | awk -F. '{print $1 "." $2 "." $3}' | sort -u | awk '{print $1 "." 1}' | xargs -n1 host | awk '{print $NF}'

就會完全在台灣機房:

server-13-35-163-1.tpe50.r.cloudfront.net.
server-13-35-36-1.tpe51.r.cloudfront.net.

用先前提到的「用 Akamai 提供的 akahelp 分析 DNS Resolver 的資訊」看起來 ECS 相關資訊都被拔掉了,但不確定關聯性是怎麼樣,但可以確定的是如果你設到 168.95.1.1 的話會是 sub-optimal experience...

有人吃飯工具用 CloudFront 的 (像是公司的服務),而且手上有 bussiness support 或是 enterprise support 的,可以自己測過確認後去開 ticket 跟 AWS 看看怎麼弄,我這邊沒這些管道 XD