Home » Posts tagged "library"

curl 將支援 DNS over HTTPS

curl 的維護者 Daniel Stenberg 在他的 blog 上宣佈 curl 將會支援 DNS over HTTPS:「DoH in curl」。

從給的範例可以看出來就是多一個 CURLOPT_DOH_URL 可以設,對於要用的人很簡單:

curl = curl_easy_init();
curl_easy_setopt(curl, CURLOPT_URL,
curl_easy_setopt(curl, CURLOPT_DOH_URL,
res = curl_easy_perform(curl);

Ethereum Smart Contracts 裡的 PRNG

現代密碼學的安全性有很大一塊是基於亂數產生器 (RNG) 非常難被預測。如果這個前提不成立的話,利用亂數產生器產生出來的各種資訊都會被預測出來 (尤其是 Private Key)。

但真正的 RNG 需要靠硬體支援,而且產生速度很慢,一般都會使用 PRNG (Pseudorandom number generator) 產生。也就是「看起來」很亂的亂數產生器。

PRNG 通常是指在統計學上通過許多測試,像是在多種測試都是 Discrete uniform distribution,不需要防止有惡意人,可以從產生出的 PRNG 的值而推導出後續結果的用途。

在「Predicting Random Numbers in Ethereum Smart Contracts」這篇裡面,作者列出了一堆實做 Ethereum Smart Contracts 卻誤用 PRNG 的行為。

文章裡提到的問題都是因為 PRNG 拿著可被預測的資訊當作 entropy source (e.g. seed),而且提出來的範例都是拿 block 本身或衍生的資訊 (像是 block 的 hash) 來用:

  • PRNGs using block variables as a source of entropy
  • PRNGs based on a blockhash of some past block
  • PRNGs based on a blockhash of a past block combined with a seed deemed private
  • PRNGs prone to front-running

然後列了大量的程式碼當例子,建議有需要接觸的人看過一次,或是有時間的人都值得看這些負面範例... XDDD

不過作者在文章裡面也給了一堆有問題的方法,像是從外部網站取得亂數之類的 XDDD

正確的方法是使用 CSPRNG (Cryptographically secure pseudorandom number generator),這是專門設計給密碼學用的 PRNG。

CSPRNG 有幾種方法可以取得:

  • 在大多數的程式語言內都有對應的 library 可以用,另外在比較近代的瀏覽器內 (如果問 IE 的話,是 11+),可以透過 RandomSource.getRandomValues() 得到。
  • 如果打算自己搞底層而需要直接取得 CSPRNG 的產出,在 Unix-like 的環境下可以透過 /dev/urandom 取得,在 Microsoft Windows 下則可以透過 CryptGenRandom 取得。

別學作者那邊奇怪方法啊 XDDD

Seam Carving (接縫裁剪)

看到有人實做 Seam Carving (接縫裁剪) 了,用 Golang 寫的,放在 GitHubesimov/caire 這邊,副標題「Content aware image resize library」。實做了「Seam Carving for Content-Aware Image Resizing」這篇論文。

Seam Carving 指的是知道內容的 resize,像是把上面這張變成下面這張:


馬上可以想到的應用是需要保留資訊內容,但又想要大量提供資訊的地方,像是 Nuzzle 的縮圖 (或是以前的 Zite),或是網路新聞媒體的首頁所用的縮圖。不知道還有沒有其他地方可以用...

用 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

Twitter 放出來的 Vireo,一套 Open Source 授權的 Video Processing Library

Twitter 放出 Vireo,一套以 MIT License 釋出的 Video Processing Library:「Introducing Vireo: A Lightweight and Versatile Video Processing Library」。專案庫在 GitHubtwitter/vireo 可以取得。

C++ 寫的,另外也已經提供 Scala 的接口,這應該是讓 Twitter 的人可以方便使用:

Vireo is a lightweight and versatile video processing library that powers our video transcoding service, deep learning recognition systems and more. It is written in C++11 and built with functional programming principles. It also optionally comes with Scala wrappers that enable us to build scalable video processing applications within our backend services.

在 Tools 的部份也可以看到很多功能,像是:

thumbnails: extracts keyframes from the input video and saves them as JPG images

viddiff: checks if two video files are functionally identical or not (does not compare data that does not affect the playback behavior)

另外要注意的是,預設不會將 GPL 的套件納入編譯,需要指定 --enable-gpl 才會編進去:

The following libraries are disabled by default. To enable GPL licensed components, they have to be present in your system and --enable-gpl flag have to be explicitly passed to configure

看起來主要就是最常見的那包... (libavformat / libavcodec / libavutil / libswscale / libx264)

LINE 將內部的座位表由 Excel 改成 Web 界面...

LINE 將內部的座位表由 Excel 管理,改用 Web 界面了:「Excel管理の座席表をLeafletでWeb化した話」,這邊不確定是全球的 LINE,還是只有日本的 LINE...

如果跟日本人有過業務合作的話,就會知道他們對 Excel 的用法只能用


來形容啊... 所以看到 LINE 特地寫了一篇來說明他們開發內部系統的事情,覺得還蠻有趣的...

起因是今年四月換辦公室,所以就順便換系統,把本來用 Excel 管理的座位表改用 Web 管理 (然後用了 Leaflet 這個 JavaScript Library):


這是 Excel 版本的樣子:

這是新版本的樣子,UI 上有更多互動的界面可以操作:

然後文末提到了總務業務量減少,而且因此變更座位變自由了而大受好評 (大概是不會讓總務煩死,所以就可以更自由換來換去 XDDD):


翻了一下英文版的 blog,好像沒有提到這件事情?XDDD

JSON 的 Object 裡 Key 重複的問題

tl;dr:不要亂來啦... 這是 UB (Undefined behavior) 的一種。

因為看到這則 tweet,所以去查一下 JSON 的資料:

首先是找標準是什麼。在維基百科的 JSON 條目裡提到了有兩份標準,一份是 RFC 7159,一份是 ECMA-404

Douglas Crockford originally specified the JSON format in the early 2000s; two competing standards, RFC 7159 and ECMA-404, defined it in 2013. The ECMA standard describes only the allowed syntax, whereas the RFC covers some security and interoperability considerations.

ECMA-404 裡面就真的只講語法沒講其他東西,而在 RFC 7159 內的 Object 則是有提到 (重點我就用粗體標起來了):

An object structure is represented as a pair of curly brackets surrounding zero or more name/value pairs (or members). A name is a string. A single colon comes after each name, separating the name from the value. A single comma separates a value from a following name. The names within an object SHOULD be unique.

   object = begin-object [ member *( value-separator member ) ]

   member = string name-separator value

An object whose names are all unique is interoperable in the sense that all software implementations receiving that object will agree on the name-value mappings. When the names within an object are not unique, the behavior of software that receives such an object is unpredictable. Many implementations report the last name/value pair only. Other implementations report an error or fail to parse the object, and some implementations report all of the name/value pairs, including duplicates.

JSON parsing libraries have been observed to differ as to whether or not they make the ordering of object members visible to calling software. Implementations whose behavior does not depend on member ordering will be interoperable in the sense that they will not be affected by these differences.

粗體有描述唯一性,但尷尬的地方在於他用 SHOULD 而非 MUST,所以 library 理論上都要能接受。但後面提到如果不唯一時,行為無法預測 (會到 rm -rf / 嗎?XDDD 最像的應該還是 crash?),所以還是不要亂來啦...

不過如果真的會 crash 的話,應該也會因為 DoS issue 而被發 CVE,所以實務上應該是不會 crash 啦...

CircleCI 的隱私問題

作者看 CircleCI 網站時發現的問題:「CircleCI trusts 8 analytics companies with your source code and API tokens」。

CircleCI 網站引用了這八個網站的 javascript:

  • Pusher
  • Intercom
  • Launch Darkly
  • Amplitude
  • Appcues
  • Quora (??)
  • elev.io
  • Optimizely

有些有很明顯目的而且也夠大,但有些就沒聽過了... 不過照 BuiltWith 上分析的資料「circleci.com Technology Profile」,遠超過這些啊 XDDD

可以看到 GitHub 站上只引用了 Facebook (不過這是哪邊出現的啊?),另外因為使用 Fastly 的 CDN 服務,所以 Fastly 也是屬於 GitHub 的信任名單;這兩家都算夠大的 vendor:「github.com Technology Profile」。

Travis CI 則是 Google Analytics 與 Fastly,也是兩家夠大的 vendor:「travis-ci.com Technology Profile」。