Home » Posts tagged "update"

HTTPS Everywhere 改變更新 Ruleset 機制,變成定時更新...

HTTPS Everywhere 是我很喜歡的一個套件,裡面有 Ruleset,會將 Ruleset 表內認定有支援 HTTPS 網站的 HTTP request 都改成 HTTPS,這可以降低被攔截的風險。像是網站雖然有 HSTS 但第一次連線時走 HTTP 的情況,以及網站本身有支援 HTTPS 但沒有設定 HSTS 時,在網址列上誤打 HTTP 版本的情況。

先前版本的 Ruleset 是隨著軟體更新時,包在軟體內一起更新。這樣的缺點是更新速度比較慢,但好處是不需要伺服器端,而且隱私性也比較高。而現在 EFF 決定還是要推出線上更新的版本,以加速 Ruleset 更新的速度:「HTTPS Everywhere Introduces New Feature: Continual Ruleset Updates」。

We've modified the extension to periodically check in with EFF to see if a new list is available.

而頻寬的部份由 Fastly 贊助:

If you haven't already, please install and contribute to HTTPS Everywhere, and consider donating to EFF to support our work!

如果對這點有疑慮的,也還是可以關掉 auto updater 避免洩漏資訊給 EFF 或是 Fastly。

Python 2 的 EoL 日期將會是 2020 年年初

在「Python 2 EOL will be 2020-01-01」這邊看到的,文章標題的連結是 mailing list 上的內容:「[Python-Dev] Python 2.7 -- bugfix or security before EOL?」。

Guido van Rossum (Python 的發明人) 在回覆關於「Python Developer’s Guide — Python Developer's Guide」上面的資訊時的說明... 大約還有一年九個多月的時間。

然後發現原來 Python 在 release 時是會發佈 PEP 的,像是「PEP 373 -- Python 2.7 Release Schedule」這樣的資訊。其他版本可以在索引頁「PEP 0 -- Index of Python Enhancement Proposals (PEPs) | Python.org」翻到。

EnterpriseDB 打算推出的 zheap,想要解 VACUUM 問題...

前天被問到「DO or UNDO - there is no VACUUM」這篇,回家後仔細看一看再翻了一些資料,看起來是要往 InnoDB 的解法靠...

PostgreSQL 與 InnoDB 都是透過 MVCC 的概念實做 transaction 之間的互動,但兩者實際的作法不太一樣。其中帶來一個明顯的差異就是 PostgreSQL 需要 VACUUM。這點在同一篇作者八年前 (2011) 的文章就有提過兩者的差異以及優缺點:「MySQL vs. PostgreSQL, Part 2: VACUUM vs. Purge」。

UPDATE 時,InnoDB 會把新資料寫到表格內,然後把可能會被 rollback 的舊資料放到表格外:

In InnoDB, only the most recent version of an updated row is retained in the table itself. Old versions of updated rows are moved to the rollback segment, while deleted row versions are left in place and marked for future cleanup. Thus, purge must get rid of any deleted rows from the table itself, and clear out any old versions of updated rows from the rollback segment.

而被 DELETE 清除的資料則是由 purge thread 處理:

All the information necessary to find the deleted records that might need to be purged is also written to the rollback segment, so it's quite easy to find the rows that need to be cleaned out; and the old versions of the updated records are all in the rollback segment itself, so those are easy to find, too.

所以可以在 InnoDB 看到 purge thread 相關的設定:「MySQL :: MySQL 5.7 Reference Manual :: 14.6.11 Configuring InnoDB Purge Scheduling」,負責處理這些東西。

而在 PostgreSQL 的作法則是反過來,舊的資料放在原來地方,新資料另外存:

PostgreSQL takes a completely different approach. There is no rollback tablespace, or anything similar. When a row is updated, the old version is left in place; the new version is simply written into the table along with it.

新舊資料的位置其實還好,主要是因為沒有類似的地方可以記錄哪些要清:

Lacking a centralized record of what must be purged, PostgreSQL's VACUUM has historically needed to scan the entire table to look for records that might require cleanup.

這也使得 PostgreSQL 裡需要 autovacuum 之類的程序去掃,或是手動跑 vacuum。而在去年 (2017) 的文章裡也有提到目前還是類似的情況:「MVCC and VACUUM」。

而在今年 (2018) 的文章裡,EnterpriseDB 就提出了 zheap 的想法,在 UPDATE 時寫到 table 裡,把可能被 rollback 的資料放到 undo log 裡。其實就是把 InnoDB 那套方法拿過來用,只是整篇都沒提到而已 XD:

That brings me to the design which EnterpriseDB is proposing. We are working to build a new table storage format for PostgreSQL, which we’re calling zheap. In a zheap, whenever possible, we handle an UPDATE by moving the old row version to an undo log, and putting the new row version in the place previously occupied by the old one. If the transaction aborts, we retrieve the old row version from undo and put it back in the original location; if a concurrent transaction needs to see the old row version, it can find it in undo. Of course, this doesn’t work when the block is full and the row is getting wider, and there are some other problem cases as well, but it covers many useful cases. In the typical case, therefore, even bulk updates do not force a zheap to grow. Instead, the undo grows. When a transaction commits, all row versions that will become dead are in the undo, not the zheap.

不過馬上就會想到問題,如果要改善問題,不是個找地方記錄哪些位置要回收就好了嗎?順便改變方法是為了避免 fragment 嗎?

等著看之後變成什麼樣子吧...

Ubuntu 開始更新 Kernel 了...

這波 CPU 安全問題,UbuntuLinux Kernel 的更新計畫 (workaround patch) 放在「Information Leak via speculative execution side channel attacks (CVE-2017-5715, CVE-2017-5753, CVE-2017-5754 aka Spectre and Meltdown)」這邊。

不是所有版本的 kernel 都有更新,像是我之前跑 4.10 發現這次沒在清單內,就換成 linux-image-generic-hwe-16.04-edge 了... 換完後需要再裝 linux-headers-generic-hwe-16.04-edge,然後把舊的 kernel 都清乾淨,最後 nvidia-387 需要重新編過。

這次苦哈哈啊...

蘋果對於電池的新聞稿

前幾天提到 Apple 在新版 iOS 上搞出的電池問題:「iPhone 換電池恢復效能的事情傳到 Geekbench 後...」,結果看起來是 PR 部門整個加班處理 XDDD

台灣版的公告在「致廣大顧客關於 iPhone 電池與效能的說明」這邊可以看到,英文版的則是在「A Message to Our Customers about iPhone Batteries and Performance」這邊。

前面講的都是大家都已經知道的事情了,重點在後續的部份:

  • Apple 為需要更換電池的 iPhone 6 或後續機種使用者,降低更換已過保固期的 iPhone 電池價格,從 NT$2,590 降為 NT$890,降幅為 NT$1,700。自 2018 年 1 月底至 12 月,全球同步進行。詳細優惠資訊將在近期於 apple.com/tw 公布。
  • 在 2018 年初,我們將發布一項 iOS 軟體更新,其中的新功能可為使用者更清楚顯示 iPhone 電池的健康狀態,讓他們可以自己看到電池的狀態是否影響效能。
  • Apple is reducing the price of an out-of-warranty iPhone battery replacement by $50 — from $79 to $29 — for anyone with an iPhone 6 or later whose battery needs to be replaced, starting in late January and available worldwide through December 2018. Details will be provided soon on apple.com.
  • Early in 2018, we will issue an iOS software update with new features that give users more visibility into the health of their iPhone’s battery, so they can see for themselves if its condition is affecting performance.

所以總算是能在 iPhone 上面直接看到電池的情況了...

AWS 的 Patch Manager 支援 Linux

在「Amazon EC2 Systems Manager Patch Manager now supports Linux」這邊 AWS 宣佈了 Patch Manager 支援 Linux 的消息。

目前支援的包括了:

  • Amazon Linux 2014.03 and later (2015.03 and later for 64-bit)
  • Ubuntu Server 16.04 LTS, 14.04 LTS, and 12.04 LTS
  • RHEL 6.5 and later (7.x and later for 64-Bit)

連已經超過 LTS 支援期的 Ubuntu 12.04 都支援了... 不過 CentOS 看起來沒順便支援?

可以設計一些規定 (與組織內規範相關的,像是 approval process) 讓 Patch Manager 決定要怎麼佈:

可以用這個直接處理安全性更新...

iOS 透過無線網路的 RCE...

在「About the security content of iOS 10.3.1」這邊的說明:

Available for: iPhone 5 and later, iPad 4th generation and later, iPod touch 6th generation and later
Impact: An attacker within range may be able to execute arbitrary code on the Wi-Fi chip
Description: A stack buffer overflow was addressed through improved input validation.
CVE-2017-6975: Gal Beniamini of Google Project Zero

這描述看起來就不太妙...

cURL 接下來的安全性更新...

cURL 的維護老大放話要大家注意接下來的安全性更新:「An alert on the upcoming 7.51.0 release」。

最少 11 個安全性更新:

This release will bundle no less than _eleven_ security advisories and their associated fixes (unless we get more reported in the time we have left).

由於這些 security issue 的特性,會採取不公開的 branch 修正再 merge 回來,再加上這麼大的數量,對於穩定性的衝擊是未知的:

Merging eleven previously non-disclosed branches into master just before a release is not ideal but done so to minimize the security impact on existing users when the problems get known.

所以目前的規劃是會在 release 的 48 個小時前公開 (希望藉由這封信讓有能力的人一起集中來看),藉此來降低衝擊:

My plan is to merge them all into master and push around 48 hours before release, watch the autobuilds closesly, have a few extra coverity scans done and then fix up what's found before the release.

這安全更新的數量好像有點多 orz

FreeBSD 11.0 重新發行...

本來已經發行的 FreeBSD 11.0,因為最近的安全性問題 (應該是講 OpenSSL?),決定不以 security update 的方式更新,而是直接發新版了:「[REVISED] [HEADS-UP] 11.0-RELEASE status update」。

Although the FreeBSD 11.0-RELEASE has not yet been officially announced, many have found images on the Project FTP mirrors.

However, please be aware the final 11.0-RELEASE will be rebuilt and republished on the Project mirrors as a result of a few last-minute security fixes we feel are imperative to include in the final release.

我以為應該是發 11.0.1,然後把架上的 11.0 拿掉...

Archives