Overleaf

線上 TeX 協同編輯工具 Overleaf 有印象用過幾次,不過 Hacker News 上看到 AGPLv3 版的專案才發現他們有開源:「Overleaf: An open-source online real-time collaborative LaTeX editor (github.com/overleaf)」,對應的 GitHub 專案在 overleaf/overleaf 這邊。

掃了一下 Hacker News 上的討論,大家都是提到在學校時協同修改論文的情況還蠻好用的,尤其是數學公式... 但也反應了出社會後 Google Docs 還是比較好用一點,如果只是要寫東西的話...。

另外一個會吸引的點大概就是字型排版的問題了,這也是為什麼我自己的 cv 一直都是用 TeX 寫 (然後套 Git 管理版本),輸出 PDF 後就是比較舒服。

dotenvx

清一清 tab... 兩個禮拜前還在日本時在 Hacker News 的「Show HN: From dotenv to dotenvx – better config management (dotenvx.com)」看到的東西,原文在推廣 dotenvx:「From dotenv to dotenvx: Next Generation Config Management」。

GitHub 的文件上可以看到幾個用法,一種是直接用,像是一般的 dotenv 的用法:

// index.js
require('@dotenvx/dotenvx').config()
console.log(`Hello ${process.env.HELLO}`)

另外一個是當 wrapper 用,像是這樣:

$ dotenvx run -- node index.js
Hello World # with dotenvx
> :-D

然後後者可以指定不同的 .env 多環境使用:

$ dotenvx run -f .env.production -- node index.js
[dotenvx][info] loading env (1) from .env.production
Hello production

另外還支援了 encrypt/decrypt 的能力降低 secret 的風險?不過這應該已經不是目前比較安全的方法了,這十年下來已經知道把 secret 放在環境變數裡太容易洩漏。

環境變數在呼叫外部程式時會被繼承,算是常見的 leaking 管道,另外就算不考慮外部程式,也會遇到環境變數算是一種全域變數,在寫測試時也很頭痛。

目前被提出來比較好的方法是把 secret 都放到 vault service 裡面,由 vault service 給一把讀取用的 API key,放進 dotenv 或是其他地方 (被稱為 secret zero)。

這樣這把 API key 去 vault service 抓取真正的 secret 放到程式內的物件取用 (像是資料庫的帳號密碼),而不是環境變數。

這樣做的 threat model 在 Hacker News 上有對應的討論,另外 AWS 的服務其實也做了類似的事情:「Amazon EC2 的 IMDSv2 計畫」。

所以 dotenvx 大概就看看,有個印象就好?

直接在 library 層將 MongoDB 用法轉換成 PostgreSQL 底層的 Pongo

看到這個「Mongo but on Postgres and with strong consistency benefits (github.com/event-driven-io)」算是另外一種用 PostgreSQL 取代 MongoDB 的嘗試,先前其他的方案是 proxy server 的方式實作 (像是 FerretDB),也就是 TCP 裡面傳的東西還是 MongoDB protocol,然後 proxy server 會轉譯成 PostgreSQL 的 SQL 語法。

這個作法的好處是不用管既有 application 是什麼程式語言開發的,另外改動比較少 (改個連線資訊 + 然後把目前還不支援的功能改寫),但缺點是多了一組 service 要維護 (如果是 HA 的話又還要設定 failover 或是 load balancer 的機制)。

Pongo 的作法則是移到 library 這邊做掉,所以就有程式語言的限制了:這個專案是用 TypeScript 開發,所以會是 JavaScript + TypeScript 生態系的方案。

不過好處就很明顯了,少了一組 service 要維護 (如果包括 HA 機制的話可能是兩組或三組),另外因為轉譯的部分在 application 端處理,沒有了 proxy server 也等於少了一個可能的 bottleneck。

這幾天上 Hacker News 後看 commit 頗熱鬧,從 Releases 頁可以看到連續出新版本。

不過... 不考慮直接用 PostgreSQL 嗎?

Reddit 的 robots.txt 要求阻擋所有機器人

在「Reddit's Robots.txt Changed (reddit.com)」這邊看到的,可以看到現在 https://www.reddit.com/robots.txt 的內容變成 (刪掉註解的部分):

User-agent: *
Disallow: /

這個改變倒是沒預料到的... 來觀察看看 HN 上後續的討論?

使用 SQLite 實作出 API 相容 Amazon SQS 的 SmoothMQ

在「Show HN: Drop-in SQS replacement based on SQLite (github.com/poundifdef)」這邊看到的,就如同標題所提到的,是個 Amazon SQS 的相容 API 實作,專案在 GitHub 上的「SmoothMQ」這邊。

底層是 SQLite,實作語言是用 Go,然後有 web interface 可以觀察與管理。

不過 Amazon SQS 的 API 層有特別優秀嗎...?而且大多數的情況都不是直接呼叫,應該是透過 message queue sdk 處理,像是作者自己寫的 sample code 用 Celery?如果是 Celery 的話後面應該有很多 backend 可以抽換...

也許在測試的角度用的到?

Lazybird 瀏覽器計畫在 2026 夏天推出 Alpha 版

在「Welcome to Ladybird, a truly independent web browser (ladybird.org)」這邊看到的,指到官網 Ladybird 上。

最主要的資訊應該是這個日期,目前計畫是 2026 夏天在 LinuxmacOS 上推出 alpha 版:

We are targeting Summer 2026 for a first Alpha version on Linux and macOS. This will be aimed at developers and early adopters.

也就是大約再兩年,看起來得花不少時間開發... 畢竟是要完全獨立開發不使用現有瀏覽器的 code。

AWS Direct Connect 開始提供 400Gbps 的選擇

AWS Direct Connect 開始有 400Gbps 的選擇了:「AWS Direct Connect announces native 400 Gbps Dedicated Connections at select locations」。

依照裡面的 AWS Direct Connect Locations 連結可以知道目前開放的地點都在北美:

  • CoreSite VA1, Reston, VA
  • Equinix DC2/DC11, Ashburn, VA
  • CoreSite SV4, Santa Clara, CA
  • Equinix SV5, San Jose, CA

Terabit Ethernet 這邊翻400Gbps 的部分,是 2017 年的標準,另外有些比較長距離的選擇是後續推出來的。

這樣算是給了一些需要穩定大流量的企業的選擇,不然 internet 集縮比的問題造成線路頻寬時高時低。

話說 Direct Connect 在台灣的兩個點目前都還是掛到東京區 (ap-northeast-1) 上,後續台北 region 開點後不知道是會支援多個 region (i.e. 可以掛東京,也可以掛台北),還是會另外找機房接?

regreSSHion:OpenSSH RCE

人在機場準備要回台灣,在 Hacker News 上看到「RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems (qualys.com)」這個整個被抽醒,Qualys 的 security advisory 在這:「regreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems (CVE-2024-6387)」。

剛剛看 Ubuntu 套件已經更新了,請儘快更新...

OpenSSH 官方的「release-9.8」內有提到這是 race condition 造成的問題,在 32-bit 的 lab 環境上面大約六到八小時可以打進去,64-bit 環境理論上應該也是可行的,但時間還沒有被驗證:

Successful exploitation has been demonstrated on 32-bit Linux/glibc systems with ASLR. Under lab conditions, the attack requires on average 6-8 hours of continuous connections up to the maximum the server will accept. Exploitation on 64-bit systems is believed to be possible but has not been demonstrated at this time. It's likely that these attacks will be improved upon.

在 security advisory 裡面有提到更細節的部分,解釋了 race condition 的攻擊對象,以及為什麼 OpenBSD 沒中獎:

This vulnerability is exploitable remotely on glibc-based Linux systems, where syslog() itself calls async-signal-unsafe functions (for example, malloc() and free()): an unauthenticated remote code execution as root, because it affects sshd's privileged code, which is not sandboxed and runs with full privileges. We have not investigated any other libc or operating system; but OpenBSD is notably not vulnerable, because its SIGALRM handler calls syslog_r(), an async-signal-safer version of syslog() that was invented by OpenBSD in 2001.

這幾天應該會有更多測試出來,另外 Hacker News 上有人提到上個月 OpenSSH 打算內建阻擋系統的事情,有在猜測跟這個 security advisory 有關?(參考「OpenSSH 要內建阻擋系統了」)...

Anyway,後續可以再研究看看,但現在先趕緊把手上機器更新一輪比較要緊...

OpenDNS 停止在法國的 DNS Resolver 服務

前陣子法國法院要求在 DNS 層阻擋的事情 (參考「Google Public DNS 接受法國法院的阻擋要求」) 有新的進度了,OpenDNS 直接停止在法國的 DNS Resolver 服務:「OpenDNS Suspends Service in France Due to Canal+ Piracy Blocking Order」。

不是把法國當地的服務停掉改由其他地區的 anycast 提供服務,而是在服務本身上面直接阻擋法國的使用者:

Reports of problems with the OpenDNS service seemed to begin on Friday, and it didn’t take long to discover the cause. The technical issues were isolated to France and apparently parts of Portugal too, with an explanation having appeared on the OpenDNS website, perhaps as early as Thursday evening.

網站上的公告則是:

Effective June 28, 2024: Due to a court order in France issued under Article L.333-10 of the French Sport code and a court order in Portugal issued under Article 210-G(3) of the Portuguese Copyright Code, the OpenDNS service is not currently available to users in France and certain French territories and in Portugal. We apologize for the inconvenience.

這下衝突升級了...

polyfill.io 被放 malicious code 的事件

台灣的圈子蠻多人是從「請儘速遠離 cdn.polyfill.io 之惡意程式碼淺析」這邊看到的,一些 code 相關的分析部分可以移駕過去看。裡面提到的 GitHub 上面 alitonium 所寫的 comment 蠻值得讀一下 (第一次點的時候會出現 GitHub 的警告,再點一次應該就會跳到正確的 comment 上)。

polyfill.js 算是老專案了,從 https://github.com/polyfillpolyfill/polyfill-service/graphs/contributors 這邊可以看到是 2013 年開始有記錄,主要是針對舊的瀏覽器 (像是 IE11),透過 javascript 的方式補上對應的功能。

現在的瀏覽器都是一直在更新,大多數的情況不太需要 polyfill 了,但畢竟很多舊的案子還在用,在這次 domain 被中國公司拿走後,Cloudflare 在今年 2024/2/29 就有先寫一篇算是預警的文章了:「polyfill.io now available on cdnjs: reduce your supply chain risk」,不過這種事情都是還沒發生前大家不會有太多重視,接下來就是 GitHub 上面的討論,然後是真的被動手加 malicious code 進去後,有人發現的討論。

後續大家都被迫要開始處理這件事情,GitHub 的作法看起來沒什麼問題:先標注 malicious repository 但是還是讓人可以進去翻歷史資料與討論。

不過 Cloudflare 這邊動作有點大,直接主動幫 CDN 客戶過濾了:「Automatically replacing polyfill.io links with Cloudflare’s mirror for a safer Internet」,這篇在 Hacker News 上也有討論:「Cloudflare automatically fixes Polyfill.io for free sites (cloudflare.com)」。

這個「越界」有點多,這應該也是直接讓 CEO Matthew Prince 出來掛文章作者的原因。這次 Cloudflare 主動做的事情包括了將免費的客戶預設開啟過濾,而付費的客戶則不會主動開啟,但提供一鍵開關:

Any website on the free plan has this feature automatically activated now. Websites on any paid plan can turn on this feature with a single click.

另外也允許所有客戶關掉這個保護:

All customers can turn off the feature at any time.

所以後續就會有另外一條大支線討論:在使用者沒有事前同意的情況下,以「安全」為名主動更改使用者頁面上的東西,這件事情是不是可以接受?如果以「安全」為名可以接受,為什麼是免費的先動,付費的卻不動?雖然我猜 Cloudflare 會裝死到底就是了...