用 Composer 的 require 限制,擋掉有安全漏洞的 library...

查資料的時候查到的,在 GitHub 上的 Roave/SecurityAdvisories 這個專案利用 Composerrequire 條件限制,擋掉有安全漏洞的 library:

This package ensures that your application doesn't have installed dependencies with known security vulnerabilities.

看一下 composer.json 就知道作法了,裡面的 description 也說明了這個專案的用法:

Prevents installation of composer packages with known security vulnerabilities: no API, simply require it

這方法頗不賴的 XDDD

microG 的進展...

留在 tab 上的東西,忘記在哪看到的... microG 發佈了新的專案:「LineageOS for microG」。

microG 是 AndroidGoogle 服務 API 的重新實作 (所以 open source),不像 Open GApps 還是屬於 proprietary software。

這次的事情是 microG 的人 fork 了 LineageOS 專案,因為 LineageOS 專案拒絕 microG 的 signature spoofing patch:

Why do we need a custom build of LineageOS to have microG? Can't I install microG on the official LineageOS?

MicroG requires a patch called "signature spoofing", which allows the microG's apps to spoof themselves as Google Apps. LineageOS' developers refused (multiple times) to include the patch, forcing us to fork their project.

另外也提到了他們覺得拒絕的原因很鳥:

Wait, on their FAQ page I see that they don't want to include the patch for security reasons. Is this ROM unsafe?

No. LineageOS' developers hide behind the "security reasons" shield, but in reality they don't care enough about the freedom of their users to risk to upset Google by giving them an alternative to the Play Services.
The signature spoofing could be an unsafe feature only if the user blindly gives any permission to any app, as this permission can't be obtained automatically by the apps.

Moreover, to further strengthen the security of our ROM, we modified the signature spoofing permission so that only system privileged apps can obtain it, and no security threat is posed to our users.

於是就 fork 了新的專案... 就觀察看看吧。

波多黎各的 Project Loon 啟動

先前在「Alphabet (Google) 的 Project Loon 拿到授權,支援波多黎各的救災計畫」提到 Project Loon 當時還在研究要跟誰一起合作,現在確認會跟 AT&T 合作提供服務了:「Turning on Project Loon in Puerto Rico」。

Thanks to their support, we are now collaborating with AT&T to deliver emergency internet service to the hardest hit parts of the island.

接下來應該還會有不少數字丟出來... (像是透過 Project Loon 傳輸了多少資料,或是多少分鐘的語音通話)

Alphabet (Google) 的 Project Loon 拿到授權,支援波多黎各的救災計畫

Project LoonAlphabet (Google 的母公司) 透過熱氣球建立網路的計畫。

這次波多黎各災後已經好幾個禮拜了,但還是有大量的基地台還是不通。於是 Project Loon 從 FCC 得到實驗性的執照,建立行動網路:「Alphabet’s Internet balloons will try to restore cell service in Puerto Rico」。

Nearly 82 percent of cell sites in Puerto Rico and 57 percent in the US Virgin Islands are out of service, the FCC said in its daily damage report yesterday. In nearly all counties in Puerto Rico, more than 75 percent of cell sites are not working, and "22 out of the 78 counties in Puerto Rico have 100 percent of their cell sites out of service." Large percentages of residents are also without cable or wireline service.

在 FCC 的公告裡提到授權了 900Mhz 頻段:「FCC GRANTS EXPERIMENTAL LICENSE FOR PROJECT LOON TO OPERATE IN PUERTO RICO」(PDF 檔但是標題是「Microsoft Word」...)。

Project Loon obtained consent agreements to use land mobile radio (LMR) radio spectrum in the 900 MHz band from existing carriers operating within Puerto Rico.

不過由於要讓使用者可以使用現有的 SIM 卡連上網,需要當地電信業者的合作,Google 目前還沒完全確認:

Alphabet hasn't announced a schedule for providing service in Puerto Rico, and the company says it is still determining whether it will be able to help.

Project Loon must be integrated with the network of a cellular company in order to provide service, and Alphabet is “making solid progress on this next step," the spokesperson said. Project Loon is part of Alphabet's X division, formerly known as "Google X."

是一戰成名的機會...

最新的 Firefox 56 對 AES-GCM 效能的改善

昨天釋出的 Firefox 56 對於 AES-GCM 在老電腦上改善了不少效能:「Improving AES-GCM Performance」。

首先是 Firefox 自己的數據分析,可以看到 AES-GCM 佔目前加密連線裡的大宗,再來是 AES-CBC:

先以 Linux 64bits 環境的數據來看,Firefox 56 的 NSS 3.32 大幅改善了老電腦的效能 (不支援 AES-NI 硬體加解密的 CPU,甚至是不支援 PCLMUL 的 CPU,以及不支援 AVX 的 CPU):

在 Linux 32bits 環境上則是連預設值大幅改善,不過用的人應該少很多了:

Windows 下則是因為 64bits 或是 32bits 都有足夠的使用者,所以平常就花了不少力氣。但也可以看出對於老電腦的速度提升:

Mac (64bits only) 算是這次比較大的提升,連新電腦的預設值都大幅變快:

加上之後陸續的改善 (尤其是下一版 Firefox 57 的 Project Quantum),這幾版應該會拉出不少效能...

Tor 在考慮使用 Rust 改寫

不過也不確定是不是愚人節消息就是了:「[tor-dev] Tor in a safer language: Network team update from Amsterdam」。

Tor 考慮使用 Rust 改寫,目前已經完成的部份,以及接下來的規劃:

What has already been done:
- Rust in Tor build
- Putting together environment setup instructions and a (very small) initial draft for coding standards
- Initial work to identify good candidates for migration (not tightly interdependent)

What we think are next steps:
- Define conventions for the API boundary between Rust and C
- Add a non-trivial Rust API and deploy with a flag to optionally use (to test support with a safe fallback)
- Learn from similar projects
- Add automated tooling for Rust, such as linting and testing

目前看到後續的討論只有「[tor-dev] Tor in a safer language: Network team update from Amsterdam」這篇,也許等全世界的 4/1 都過了之後再回來確認吧...

GitHub 允許員工在閒暇時間使用公司設備創作他們自己的東西

看到「GitHub now lets its workers keep the IP when they use company resources for personal projects」這則新聞,GitHub 正式的條款在「Balanced Employee IP Agreement (BEIPA)」這邊可以看到。

如同報導所提到的,只要不與工作內容相關 (或競爭),員工都可以保留權利:

This allows its employees to use company equipment to work on personal projects in their free time, which can occur during work hours, without fear of being sued for the IP. As long as the work isn’t related to GitHub’s own “existing or prospective” products and services, the employee owns it.

V8 對 for-in 的最佳化

V8 引擎的人對 for-in 的最佳化寫了一篇解釋「Fast For-In in V8」,比較直接的結果就是維基百科Facebook 都變快了:

For example, in early 2016 Facebook spent roughly 7% of its total JavaScript time during startup in the implementation of for-in itself. On Wikipedia this number was even higher at around 8%.

可以看得出來是挑比較大的來改,而下一版的 Google Chrome (57) 將會對 for-in 會到另外一個極致:

The most important for-in helpers are at position 5 and 17, accounting for an average of 0.7% percent of the total time spent in scripting on a website. In Chrome 57 ForInEnumerate has dropped to 0.2% of the total time and ForInFilter is below the measuring threshold due to a fast path written in assembler.

主要是因為 spec 對 for-in 的定義寫得很模糊,所以就有很多實作的空間可以調整:

When we look at the spec-text of for-in, it’s written in an unexpectedly fuzzy way,which is observable across different implementations.

Cloudbleed:Cloudflare 這次的安全問題

Cloudflare 把完整的時間軸與影響範圍都列出來了:「Incident report on memory leak caused by Cloudflare parser bug」。

出自於 2/18 時 GoogleTavis Ormandy 直接在 Twitter 上找 Cloudflare 的人:

Google 的 Project Zero 上的資料:「cloudflare: Cloudflare Reverse Proxies are Dumping Uninitialized Memory」。

起因在於 bug 造成有時候會送出不應該送的東西,可能包含了敏感資料:

It turned out that in some unusual circumstances, which I’ll detail below, our edge servers were running past the end of a buffer and returning memory that contained private information such as HTTP cookies, authentication tokens, HTTP POST bodies, and other sensitive data.

不過這邊不包括 SSL 的 key,主要是因為隔離開了:

For the avoidance of doubt, Cloudflare customer SSL private keys were not leaked. Cloudflare has always terminated SSL connections through an isolated instance of NGINX that was not affected by this bug.

不過由於這些敏感資料甚至還被 Google 收進 search engine,算是相當的嚴重,所以不只是 Cloudflare 得修好這個問題,還得跟眾多的 search engine 合作將這些資料移除:

Because of the seriousness of such a bug, a cross-functional team from software engineering, infosec and operations formed in San Francisco and London to fully understand the underlying cause, to understand the effect of the memory leakage, and to work with Google and other search engines to remove any cached HTTP responses.

bug 影響的時間從 2016/09/22 開始:

2016-09-22 Automatic HTTP Rewrites enabled
2017-01-30 Server-Side Excludes migrated to new parser
2017-02-13 Email Obfuscation partially migrated to new parser
2017-02-18 Google reports problem to Cloudflare and leak is stopped

而以 2/13 到 2/18 的流量反推估算,大約是 0.00003% 的 request 會可能產生這樣的問題:

The greatest period of impact was from February 13 and February 18 with around 1 in every 3,300,000 HTTP requests through Cloudflare potentially resulting in memory leakage (that’s about 0.00003% of requests).

不過不得不說 Tavis Ormandy 真的很硬,在沒有 source code 以及 Cloudflare 幫助的情況下直接打出可重製的步驟:

I worked with cloudflare over the weekend to help clean up where I could. I've verified that the original reproduction steps I sent cloudflare no longer work.

事發後完整的時間軸:

2017-02-18 0011 Tweet from Tavis Ormandy asking for Cloudflare contact information
2017-02-18 0032 Cloudflare receives details of bug from Google
2017-02-18 0040 Cross functional team assembles in San Francisco
2017-02-18 0119 Email Obfuscation disabled worldwide
2017-02-18 0122 London team joins
2017-02-18 0424 Automatic HTTPS Rewrites disabled worldwide
2017-02-18 0722 Patch implementing kill switch for cf-html parser deployed worldwide
2017-02-20 2159 SAFE_CHAR fix deployed globally
2017-02-21 1803 Automatic HTTPS Rewrites, Server-Side Excludes and Email Obfuscation re-enabled worldwide

另外在「List of Sites possibly affected by Cloudflare's #Cloudbleed HTTPS Traffic Leak」這邊有人整理出受影響的大站台有哪些 (小站台就沒列上去了)。

Akamai 阻擋 DDoS 能力的上限

這應該是最近在看 DDoS 事件中比較重要的新聞了,從這次的事件知道 Akamai 沒有能力擋下某種 620Gbps 以上的 DDoS 攻擊,而這是攻擊者已經有能力「示範」出來的量:「Akamai kicked journalist Brian Krebs' site off its servers after he was hit by a 'record' cyberattack」。

The assault has flooded Krebs' site with more than 620 gigabits per second of traffic — nearly double what Akamai has seen in the past.

然後現在 Krebs on Security 的整個站台都轉移到 GoogleProject Shield 計畫上了,接下來就是時間的考驗了:「The Democratization of Censorship」。