2016/03/24

aptitude update 找不到 GPG key 的處理

執行的 aptitude update 以後,出現錯誤訊息:
W: GPG error: http://ppa.launchpad.net trusty InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 00A6F0A3C300EE8C
W: GPG error: http://ppa.launchpad.net trusty InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 4F4EA0AAE5267A6C

可以透過下列指令去 import keys:
sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com {KEY}

例如上面的錯誤,可以這樣 import key:
sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 00A6F0A3C300EE8C
sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 4F4EA0AAE5267A6C

reference: How do I fix the GPG error “NO_PUBKEY”?

2016/03/17

Ubuntu PPA for new version of Git

舊版本的 git 有安全性漏洞,需要升級到 2.7.1 以上版本
server and client side remote code execution through a buffer overflow in all git versions before 2.7.1 (unpublished ᴄᴠᴇ-2016-2324 and ᴄᴠᴇ‑2016‑2315)


Ubuntu 14.04 的 git 還在 1.x,只好靠 PPA 抓新版本:
sudo add-apt-repository ppa:git-core/ppa
sudo aptitude update && sudo aptitude upgrade

2016/03/02

SSLv2 可能也不安全了

More than 11 million HTTPS websites imperiled by new decryption attack
http://arstechnica.com/security/2016/03/more-than-13-million-https-websites-imperiled-by-new-decryption-attack/

解釋:
最新的 SSL connection 攻擊:DROWN attack
https://blog.gslin.org/archives/2016/03/02/6381/


目前自己的機器好像沒受到影響,被份一下 nginx 的 HTTP 設定 (從多方搜尋來得設定值):
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
ssl_prefer_server_ciphers on;


若不清楚自己的 server 設定是否安全,可以透過 SSL Labs 提供的服務,來檢查是否有什麼潛在的問題。

2016/02/23

準備離開 StartSSL

Why I stopped using StartSSL (Hint: it involves a Chinese company)
https://pierrekim.github.io/blog/2016-02-16-why-i-stopped-using-startssl-because-of-qihoo-360.html

由於 cert 被扔到大陸機房去,所以還是換家 SSL provider 比較安全一點。

噗浪上有不少朋友提供 Let's Encrypt 的解決方案,除了「root can only help」以外,好像沒什麼奇怪的地方。另外 JoeHorn 寫了一個全自動 renew 的 script,假日的時候來玩玩看 ~

2016/02/04

xargs -P 在 stdout 可能會遇到 race condition

爬 log 發現 log 格式不正確,而且還是經常發生,而手動追蹤時又找不到錯誤在哪裡:
find . -name '*2016-01*.log.gz' | xargs -I'{}' -P 4 zgrep keyword {} | awk ...

做了測試以後才發現 xargs -P 時,各個 process 只要有 stdout 就會和其他 process 打架,造成資料還沒寫完就被其他 process 插單,導致最後出來的資料不正確。



先建立二個檔案,儲存不同的二個資料。

0.test.log (每行 50 字):
.................................................
.................................................
.................................................
....

1.test.log (每行 50 字):
1111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111
...


接下來使用 xargs 來 echo 這二個檔案內容:
find . -name '*test.log' | xargs -I'{}' -P 2 cat {} > output.xargs.log

接下來寫個 script 來檢查 output.xargs.log 的內容是否都正確:
for LINE in `cat output.xargs.log `; do
    if [ 50 -lt ${#LINE} ]; then
        echo $LINE
    fi
done

結果會發現 output 有一行超過 50 個自得情況發生:
111111111111111111111111111111111111.................................................

而相同的情況下,parallel 就不會有相同的情況發生:
find . -name '*test.log' | parallel -j 2 cat {} > output.xargs.log

原因是 parallel 會將 jobs (process) 的 output 先 buffer 起來,等到整個 job 都結束以後在一起送到 stdout。若使用上述的範例改用 parallel 的操作來測試的話,可以發現不同 job 的 output 有被完全區隔開來,沒有混在一起:

...
.................................................
.................................................
.................................................
1111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111
...


總之,以後用到 xargs -P 時,要小心 race condition ... (暈)