Ubuntu 的 Phased Update

Ubuntu 22.04 上面常常會遇到跑 apt upgrade 時系統跟你說有些 package 不打算升級:

$ sudo apt upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  python3-distupgrade ubuntu-release-upgrader-core ubuntu-release-upgrader-gtk
0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.

以往遇到這種情況,如果確定要裝就是開 dist-upgrade 下去,但會發現也還是不為所動:

$ sudo apt full-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  python3-distupgrade ubuntu-release-upgrader-core ubuntu-release-upgrader-gtk
0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.

這個可能是遇到 PhasedUpdates,這個設計是在最後一關推出去的階段,一次不要更新 100% 的機器。

可以從 apt policy 看到現在的比率是 20%:(這是我已經升級上去的樣子)

$ apt policy python3-distupgrade
python3-distupgrade:
  Installed: 1:22.04.18
  Candidate: 1:22.04.18
  Version table:
 *** 1:22.04.18 500 (phased 20%)
        500 http://tw.archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
        500 http://tw.archive.ubuntu.com/ubuntu jammy-updates/main i386 Packages
        100 /var/lib/dpkg/status
     1:22.04.10 500
        500 http://tw.archive.ubuntu.com/ubuntu jammy/main amd64 Packages
        500 http://tw.archive.ubuntu.com/ubuntu jammy/main i386 Packages

而對於 LTS 的使用者,這個功能在 APT 的支援是從 Ubuntu 22.04 開始,以前只有桌面的 Update Manager 才有支援,所以不太會遇到:

Up to Focal (20.04), Update Manager is the only package manager that supports phased updates (reference). Any other update mechanism installs all updates regardless of the Phased-Update-Percentage.

(話說 wiki 頁上面可以看到有「User stories」這段,用 User story 的格式把這個功能的目的描述出來了)

所以一般人可以忽略掉,而對於有意願想要幫忙測試的人,也可以透過設定蓋過 Phased Updates 的比例設定...

由 pnpm 做出來的效能比較:npm、yarn 以及 pnpm

找資料的時候看到 pnpm 有在做幾個常見的 javascript package manager 的比較:「Benchmarks of JavaScript Package Managers」。

裡面測了九個項目,其中前八個剛好就是 cache 的有無、lockfile 的有無以及 node_modules 的有無,這三者的組合剛好八個,最後一個是測 update 的速度。

pnpm 因為用了 hard link,我先跳過去,只先關注 npmyarn 的差異。

其中幾個比較重要的項目是 (由最重要開始列):

  • with cache, with lockfile, with node_modules:這個會是一般開發的情境。
  • update:套件有更新時的時間。
  • with lockfile:這個會是第一次 clone 下來後的環境,以及 CI 的環境。

在一般開發環境下,npm 比 yarn 快一些,這點讓我比較意外,我知道 npm 這幾年一直有在改善效率,但沒想到會在 benchmark 下反超,這個是以前 yarn 很大的宣傳點,現在已經不見了。

第二個是 update (upgrade) 的部份,這邊 yarn 比 npm 快一些。

第三個因為是 CI 環境,或是第一次 clone 時的環境,慢通常可以被接受,不要差太多就好,而這邊 npm 比 yarn 快一些。

但不管是哪個,差距都不像以前那麼大了,就效率上來說,官方的 npm 已經沒有太明顯的缺點,因為效率的差異而去選擇 yarn 的理由已經不存在了。

LastPass 離職員工的爆料

這次 LastPass 出包搞的蠻大的,在官方的「Notice of Recent Security Incident」的裡面有提到這次的資料外洩包括了使用的 encrypted vault data 也被洩漏了:

The threat actor was also able to copy a backup of customer vault data from the encrypted storage container which is stored in a proprietary binary format that contains both unencrypted data, such as website URLs, as well as fully-encrypted sensitive fields such as website usernames and passwords, secure notes, and form-filled data.

官方一直強調這是 encrypted data,但離職員工爆料加密強度不足的問題:「1606428769731878913.html」,其中這段在講 legacy 版本的加密問題,居然曾經用過 ECB mode

Lots of vault entries may be encrypted with ECB mode AES-256. I worked on supporting unauthenticated CBC mode. But re-encrypting a users vault entries requires having their master key.

這個如同 Hacker News 上的討論「I worked at LastPass as an engineer (twitter.com/ejcx_)」提到的,以 1980 年代的標準就已經知道 ECB mode 的問題了:

> Lots of vault entries may be encrypted with ECB mode AES-256.
Wtf wtf wtf. This would be considered wildly insecure even by the standards of the 80s

其他提到 PBKDF2 的強度是逐步增加,從早期的 5000 到現在預設的 100100,這點倒是可以理解。

要避免依賴廠商的資安,一種方式是用目前成熟的開源 Password Manager,並且使用檔案儲存 (像是 KeePassXC 這類工具),再搭配 file sync 的工具跨機器使用 (像是 Syncthing 這樣獨立確認每個 device 身份的方式),但方便性不會像這些商用方案這麼好用就是了...

這次故事好像還沒結束,遇到西方的長假,反應都比較慢...

Xfce 4.18 出版

看到「Xfce 4.18 released」這個消息,可以放一個月讓 bug 飛一飛改一改再來更新...

看起來 thunar (Xfce 的檔案總管?) 改了不少東西,可以看到花了很多篇幅在介紹。看起來對我來說最有改變的是 undo 與 redo 的部份:

It is now possible to undo basic file operations and to redo them. Undo and Redo can be used for 'move', 'rename', 'trash', 'link' and 'create' operations. Per default, a history of the last 10 operations is stored, though the history length is configurable. Whenever an Undo/Redo is triggered, a notification with few details will be shown.

其他的應該是還好...

KeePassX 宣佈不再維護了

Daily Lobsters 上看到 KeePassX 宣佈不再繼續維護了:「Development stopped」,在 Lobsters 上的討論也可以翻翻:「KeePassX development stopped」。

KeePassX 與 KeePassXC 都是 open source 版本的 password manager,單檔的設計可以配合很多不同的服務同步,自己架 Syncthing 或是用 Dropbox 之類的同步都是可行的,看對安全性的要求如何。

KeePassX 上次的更新是 2016 年推出的 2.0.3,已經超過五年沒有更新了。官方建議的替代方案是 KeePassXC

KeePassX is no longer actively maintained.

You might want to switch to KeePassXC which is based on KeePassX.

算是接棒交接出去...

Kaspersky Password Manager 的漏洞

Hacker News Daily 上看到「Kaspersky Password Manager: All your passwords are belong to us」這篇,講 Kaspersky Password Manager (KPM) 嚴重的安全漏洞,另外在 Hacker News 上的討論「Kaspersky Password Manager: All your passwords are belong to us (ledger.com)」也有提到一些有趣的東西。

標題的 All your passwords are belong to us 是出自「All your base are belong to us」這個梗的變形。

這包安全問題主要的原因是因為 KPM 沒有使用 CSPRNG,而且也沒有正確 seed,所以極為容易被猜出密碼本身。

KPM 的 Web 版使用了 Math.random(),在各家瀏覽器主要是用 xorshift128+ 實做 Math.random(),作者沒有針對這塊再花時間研究,但很明顯的 Math.random() 不是個 CSPRNG:

The underlying PRNG used by Chrome, Firefox and Safari for Math.random() is xorshift128+. It is very fast, but not suitable to generate cryptographic material. The security consequences in KPM has not been studied, but we advised Kaspersky to replace it with window.crypto.getRandomValues(), as recommended by the Mozilla documentation page previously mentioned.

Note: Math.random() does not provide cryptographically secure random numbers. Do not use them for anything related to security. Use the Web Crypto API instead, and more precisely the window.crypto.getRandomValues() method.

而桌機版則是用了 MT19937,理論上取得 624 bytes 的輸出後就可以重建整個 PRNG 的內部狀態 (於是就可以預測後續的 output),但這代表你要知道其他網站的密碼,這點其實有點困難。

但作者發現 KPM 在產生 MT19937 的 seed 只跟時間有關,超級容易被預測:

So the seed used to generate every password is the current system time, in seconds. It means every instance of Kaspersky Password Manager in the world will generate the exact same password at a given second.

於是可以直接暴力解出所有的可能性:

The consequences are obviously bad: every password could be bruteforced. For example, there are 315619200 seconds between 2010 and 2021, so KPM could generate at most 315619200 passwords for a given charset. Bruteforcing them takes a few minutes.

Hacker News 上有不少陰謀論的討論,像是:

Getting some DUAL_EC prng vibes.

Insert Kaspersky owned by Russia intelligence conspiracy here...

另外 Kaspersky 跟俄羅斯軍方的關係也是很知名,這些東西大概要到十來年後才會知道...

Reddit 的前 EM 提到 Reddit 用的 Dark Pattern

Hacker News Daily 上看到「Reddit's disrespectful design」這個,在講 Reddit 用到的 dark pattern, 不過我覺得更棒的是在 Hacker News 上的討論:「Reddit’s disrespectful design (ognjen.io)」。

討論裡面出現了之前在 Reddit 裡面負責這塊的 EM (engineer manager),wting

I was the EM for Reddit's Growth team around this time. I am responsible for / contributed to a few features like the current signup flow, AMP pages, push notifications, email digests, app download interstitials, etc.

然後他提到他當初拒絕實做其中一些 dark pattern,然後在經過 [0] 的事情後,他決定換團隊:

There was a new product lead who joined with many good ideas, but some of them were dark patterns that I heavily protested. After a few months of this, it was obvious that I was going to be reigned in or let go[0]; I immediately transferred to a different org.

其中 [0] 的部份是,公司把他 reporting line 改成到 product lead XDDD

0: They changed it so I would report to the product lead, which is odd for an EM to report into a product chain and the only instance within the company ever.

另外他也講了一個事情,就是強姦使用者是有用的,而且超級有用:

Now let me explain the other side of the story. 4 years later, Reddit's DAU, MAU, and revenue have all grown at ridiculous rates[1]. Yes, power users complain—and still continue using the site—but the casual user does not. These dark patterns have been normalized on other websites.

These practices are done because it works.

1: Many friends are startup founders and I've been at a few startups myself—a byproduct of being in the Bay Area—and Reddit's growth numbers are impressive. As a former employee, I am quite happy about my equity growth.

這幾乎是共識了,dark pattern 看起來很邪惡沒錯,但他就是有用...

AWS 推出 Incident Manager 服務

AWS 推出了 Incident Manager 服務,掛在 AWS Systems Manager 下,這類似於 PagerDuty 這類的服務:「Resolve IT Incidents Faster with Incident Manager, a New Capability of AWS Systems Manager」。

比較特別的是費用的部份,可以參考「AWS Systems Manager pricing」這邊的資料,他是依照 incident 的次數算錢,每個 incident 算 USD$7,另外加上對應的 SMS 或是 voice message 費用。

回頭來看 PagerDuty 的部份,費用的部份是以人頭計算,Business Plan 是 USD$39/user/month,然後已經包括括無限數量的 SMS 通知了。

功能上看起來 PagerDuty 還是比較好,Incident Manager 如果要把外部服務拉進來的話看起來得透過 EventBridge 去接,麻煩不少...

Dropbox 也要搞自己的密碼管理器

Dropbox 也要搞自己的密碼管理器 Dropbox Passwords:「Dropbox Passwords coming soon for all users」。

看起來只要是 Dropbox 的付費方案就可以無限使用,而免費版的則是 50 組。從下載頁看起來目前在 PC 上只支援 Microsoft WindowsmacOS,不支援 Linux

Come back to this page on a PC with Windows 10 or a Mac with at least macOS Sierra 10.12 to get the Passwords desktop app.

而行動平台就是 iOSAndroid

How do I use the Android and iPhone password manager?

Once you sign in to the Passwords app, it automatically fills in your usernames and passwords so you can access frequently used apps and websites on your mobile device.

從示意圖看起來有整合瀏覽器,而加密技術的部份沒有講太多,只說是 zero-knowledge encryption,先觀望看看...

LastPass 的 Android App 的資安問題

Hacker News Daily 上看到的,LastPass 的 Android App「LastPass Password Manager」裡面引用了大量的 SDK,引起不少人的資安疑慮:「LastPass Android app has got 7 trackers in it (eu.org)」。

裡面有七個 tracker,看了一下大概知道想要做什麼,但如果以一個資安為主打的 app,其中的 Google Tag Manager 讓人不怎麼舒服,基本上就是個 Remote code execution 的後門,光就這點能不要用就不要用...

我自己還是儘可能不要依照這些 vendor,繼續用 KeePassXC 加上同步機制,不過這對於一般人來說麻煩了不少...