Category: Library

Laravel 5.5 釋出，第二個 LTS 版本

Laravel 推出第二個 LTS 版本，5.5 版：「Laravel 5.5 LTS is Now Released」。

當初 Taylor Otwell 對 LTS 還蠻感冒的 (參考去年的 tweet)，居然推出了...

有 LTS 對於商業應用的維護來說還是方便不少... 大概是考慮到這個原因，所以還是推出了 :o

React 的專利授權議題

在 ASF (Apache Software Foundation) 全面禁止 Facebook 的 BSD+PATENTS 後 (「Apache Foundation 宣佈禁止使用 Facebook BSD+Patents 的軟體」)，整件事情開始熱起來了...

簡單來說，Facebook 有意為之，而且不打算撤回這個有攻擊性的授權模式，參考「Explaining React's license」這邊官方的說明以及有人寫了一篇解讀：「If you’re a startup, you should not use React (reflecting on the BSD + patents license)」。

Facebook 內的意見其實也不一樣，像是 Yarn 之所以沒有 PATENTS 是因為爭取出來的：

接下來應該會有更多爭議討論了...

Apache Foundation 宣佈禁止使用 Facebook BSD+Patents 的軟體

在「RocksDB Integrations」這邊討論到 RocksDB 裡 Facebook 所使用的 Facebook BSD+Patents License。

不過因為 RocksDB 最近在換 license (從 Facebook BSD+Patents 換到 Apache License, Version 2.0)，移除了 PATENTS 內的限制，需要看 PATENTS 的舊檔案可以在 PATENTS 這邊看到。

Chris Mattmann 正式發出決議禁用 Facebook BSD+Patents License。(參考最後)

另外也提到了 Facebook 是故意埋下這些限制：

Note also Roy's comment that he has discussed the matter with FB's counsel and the word is that the FB license is intentionally incompatible. It is hard to make the argument that it is compatible after hearing that. Pragmatically speaking, regardless of any semantic shaving being done, having a statement like that from the source of the license is very daunting. If they think it is incompatible, we need to not try to wheedle and convince ourselves it is not.

這個 license 之後應該會有更多挑戰...

Hi,

As some of you may know, recently the Facebook BSD+patents license has been
moved to Category X (https://www.apache.org/legal/resolved#category-x).
Please see LEGAL-303 [1] for a discussion of this. The license is also referred
to as the ROCKSDB license, even though Facebook BSD+patents is its more
industry standard name.

This has impacted some projects, to date based on LEGAL-303
and the detective work of Todd Lipcon:

Samza, Flink, Marmotta, Kafka and Bahir

(perhaps more)

Please take notice of the following policy:

o No new project, sub-project or codebase, which has not
  used Facebook BSD+patents licensed jars (or similar), are allowed to use
  them. In other words, if you haven't been using them, you
  aren't allowed to start. It is Cat-X.

o If you have been using it, and have done so in a *release*,
  you have a temporary exclusion from the Cat-X classification thru
  August 31, 2017. At that point in time, ANY and ALL usage
  of these Facebook BSD+patents licensed artifacts are DISALLOWED. You must
  either find a suitably licensed replacement, or do without.
  There will be NO exceptions.

o Any situation not covered by the above is an implicit
  DISALLOWAL of usage.

Also please note that in the 2nd situation (where a temporary
exclusion has been granted), you MUST ensure that NOTICE explicitly
notifies the end-user that a Facebook BSD+patents licensed artifact exists. They
may not be aware of it up to now, and that MUST be addressed.

If there are any questions, please ask on the legal-discuss@a.o
list.

Thanks.

Cheers,
Chris Mattmann
VP Legal Affairs

[1] https://issues.apache.org/jira/browse/LEGAL-303

BoringSSL 的 FIPS 140-2 驗證

看到由 Google 主導的 BoringSSL 有計劃將其中一塊申請 FIPS 140-2 的驗證計畫 (BoringCrypto 的部份)：「FIPS 140-2」。

其中 FIPS 140-2 最有名的後門應該是 Dual_EC_DRBG (定義於 NIST SP 800-90A，被 FIPS 140-2 引用)，所以特地講清楚他們選擇哪個演算法：

FIPS 140-2 requires that one of its PRNGs be used (which they call DRBGs). In BoringCrypto, we use CTR-DRBG with AES-256 exclusively and RAND_bytes (the primary interface for the rest of the system to get random data) takes its output from there.

而且還花了不少篇幅解釋 PRNG 的細節。

又是 ImageMagick 出包...

ImageMagick 的 information leaking，然後 Yahoo! 很無奈的中獎，所以被稱為 Yahoobleed：「Yahoo! retires! bleeding! ImageMagick! to! kill! 0-day! vulnerability!」。發現問題的作者把問題寫在「*bleed continues: 18 byte file, $14k bounty, for leaking private Yahoo! Mail images」這邊。

作者利用 ImageMagick 的不當處理，取得 uninitialized memory 的資訊，藉以取得可能是上次轉檔的記憶體內容。而這個 jpeg 只有 18bytes (所以作者戲稱每個 byte 價值 USD$778)：

A robust bounty of $14,000 was issued (for this combined with a similar issue, to be documented separately). $778 per byte -- lol!

目前的 workaround 也很簡單 (官方採用了)，呼叫 ResetMagickMemory 避免 leaking (咦，這方法好像哪邊怪怪的)：「Reset memory for RLE decoder (patch provided by scarybeasts)」。

用 Go 寫的 Badger

Dgraph 在推銷自家發展出來的 Badger：「Introducing Badger: A fast key-value store written natively in Go」。

標靶是 RocksDB，號稱比 RocksDB 快好幾倍：

Based on benchmarks, Badger is at least 3.5x faster than RocksDB when doing random reads. For value sizes between 128B to 16KB, data loading is 0.86x - 14x faster compared to RocksDB, with Badger gaining significant ground as value size increases. On the flip side, Badger is currently slower for range key-value iteration, but that has a lot of room for optimization.

不過我覺得有些重要的功能在 Badger 不提供，這比起來有種橘子比蘋果的感覺... 像是 RocksDB 提供了 Transaction，而 Badger 則是直接講明他們不打算支援 Transaction：

Keep it simple, stupid. No support for transactions, versioning or snapshots -- anything that can be done outside of the store should be done outside.