Nginx + FastCGI + Trac

先前試著逼自己用 Phabricator,用了一個多月後發現設計的邏輯還是跟 Trac 差了不少,算是為了 Facebook 特化的產品吧。在這一個月查資料的過程也發現當初 Wikimedia 要採用的時候也花了不少力氣送 patch 回官方,然後針對不少地方客製化調整。

另外比較痛的地方是 plugin 的支援能力還沒有很好,變成很多東西都要改主體... 而且效能也不太好 (不支援 PHP 7.0 還蠻痛的),在比較低階的 VPS 上跑特別明顯。

這幾天花了點時間把 Trac 給架起來,之前都是用 FreeBSD ports 架,但已經愈來愈沒有再接觸 FreeBSD 了,所以這次在 Ubuntu 上用 pyenv 裝起來再用 pip 裝起來。

另外一個跟之前不同的,是先前都用 Apachemod_wsgi,在低階的 VPS 上則是要找省資源的方案,這次則是用 nginx + FastCGI 去接,比起之前複雜不少...

最主要是參考了官方的文件以及「Gentoo下使用nginx+fastcgi部署trac」這邊的說明達到效果,重點是這段 location 的設定:

    location / {
        auth_basic "trac realm";
        auth_basic_user_file /srv/domain.example.com/.htpasswd;

        include fastcgi.conf;
        fastcgi_param AUTH_USER $remote_user;
        fastcgi_param HTTPS on;
        fastcgi_param PATH_INFO $fastcgi_script_name;
        fastcgi_param REMOTE_USER $remote_user;
        fastcgi_param SCRIPT_NAME "";
        fastcgi_pass unix:/var/run/trac/trac.sock;
    }

    location /.well-known/acme-challenge/ {
        alias /var/www/dehydrated/;
    }

網路上有找到用 location ~ (/.*) 去 match,然後拉出 $1PATH_INFO 用的,這這會使得這段 location 的優先權太高 (參考官方對於 location 的順序說明),而蓋掉下面 Let's Encrypt 的 acme challenge 過程,所以還是得這樣搞。

另外是自己一個人用,就用 .htpasswd 的方式認證了,沒必要弄 LDAP 之類的認證...

接下來就是裝一堆 plugin 並且調整 css/js 與 SQL query 了...

Python 3.6 對 Dict 的改善

Python 3 的 Dict 將會有重大的改變:「[Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered」。

在 3.5 時:

Python 3.5.1 (default, Jun 20 2016, 14:48:22)
>>> def func(**kw): print(kw.keys())
...
>>> func(a=1, b=2, c=3, d=4, e=5)
dict_keys(['c', 'd', 'e', 'b', 'a'])   # random order

對上目前還在開發的 3.6:

Python 3.6.0a4+ (default:d43f819caea7, Sep  8 2016, 13:05:34)
>>> def func(**kw): print(kw.keys())
...
>>> func(a=1, b=2, c=3, d=4, e=5)
dict_keys(['a', 'b', 'c', 'd', 'e'])   # expected order

在「Compact and ordered dict」這邊可以看到記憶體的使用量降低:

It seems like the memory usage is between 20% and 25% smaller. Great job!

Memory usage, Python 3.5 => Python 3.6 on Linux x86_64:

./python -c 'import sys; print(sys.getsizeof({str(i):i for i in range(10)}))'

* 10 items: 480 B => 384 B (-20%)
* 100 items: 6240 B => 4720 B (-24%)
* 1000 items: 49248 B => 36984 B (-25%)

Note: the size is the the size of the container itself, not of keys nor values.

不過效能上似乎慢了一些:

3% slowdown in microbench is not surprising.
Compact dict introduces one additional indirection.

Instead, I've added freelist for most compact PyDictKeys.
So I think overall performance is almost same to before compact dict.

不過也有人提到應該拿 3.5 + patch 測,而不是直接拿 3.6 測:

There are a lot of other changes in interpreter core between 3.5 and 3.5 (such as new bytecode and optimized function calls). Could you compare the performance between the version just before adding new dict implementation and the version just after this?

看起來後續還在進行中...

舊 bug 新名字:httpoxy

依照慣例,security issue 都會取個名字,這次叫做 httpoxy:「A CGI application vulnerability for PHP, Go, Python and others」。

事情發生在兩個命名變數上的衝突:

  • RFC 3875 (The Common Gateway Interface (CGI) Version 1.1) 定義了 CGI 環境會把 Header 裡的 Proxy 欄位放到環境變數裡的 HTTP_PROXY
  • 而很多程式會拿環境變數裡的 HTTP_PROXY 當作 proxy 設定。

這件事情 2001 年在 libwww-perl 就有發生過 (並且修正),curl 也發生過 (然後修正),2012 年在 Ruby 的 Net::HTTP 也發生過 (也修正了)。

然後在 2016 年還是被發現有很多應用程式會中獎... 這頭好痛啊 :o

對 GDB 十五分鐘的介紹

看到「CppCon 2015: Greg Law 'Give me 15 minutes & I'll change your view of GDB'」這篇去年 CppCon 上介紹 GDB 的影片:

不是給初學者看的,而是給碰壁很多次的人看的... 裡面提到的 Ctrl-X 與內嵌 python 的部份讓人很驚豔,另外也實戰了 Reverse Execution 救 call stack 的技巧,拿來找破壞掉 stack 後不知道問題在哪裡的 case。

很值得看的 15 分鐘 (實際上大概花了半個小時,邊看邊實際操作練習)。

在 Python 的 pip、Nodejs 的 npm、Ruby 的 RubyGems 上面放木馬研究?

在 Python 領域裡常用 pip 安裝軟體:

$ pip install reqeusts

或是:

$ sudo pip install reqeusts

其他的平台也大致類似於這樣的動作。而在「Typosquatting programming language package managers」這篇文章裡,作者用 typo 之類的方式列出可能的名稱,像是這樣的名稱:

$ sudo pip install reqeusts

然後在這三個平台上發動攻擊,上傳了數百個套件並且觀察:

All in all, I created over 200 such packages and equipped them with a small program and uploaded them over the course of several months. The idea is to add some code to the packages that is executed whenever the package is downloaded with the installing user rights.

而這是「成果」:

Terminal 下操作 VMware 的 vSphere

Twitter 上看到 zmx 提到:

其中 Ruby vSphere Console (rvc) 被標成 deprecated:

Note: This Fling is deprecated, so the download is no longer available, and it will not be updated. Also, feedback is no longer monitored.

Python vSphere Client with a dialog(1) interface (pvc) 看起來比較新:

不過我自己測試後發現死在 SSL certificate 上,之後再來研究要怎麼閃開吧...

也是個加強 Debugger UI 的套件:Voltron

在「更絢麗的 .gdbinit 檔」這篇裡面提過「GDB dashboard」這組設定,以及用 Python 寫的的加強工具。

在「A hacky debugger UI for hackers」這邊則看到了另外一套也是 Python 寫的工具,叫做 Voltron:

比較一下原來 GDB dashboard 的畫面:

其實兩者看起來都還蠻棒的?用的習慣最重要...

把塗鴉透過深度類神經網路轉成油畫...

看到「Neural Doodle」這個專案,可以把塗鴉轉成帶有油畫筆觸的圖:

看起來是實作新的演算法:

Use a deep neural network to borrow the skills of real artists and turn your two-bit doodles into masterpieces! This project is an implementation of Semantic Style Transfer (Champandard, 2016), based on the Neural Patches algorithm (Li, 2016).

另外一組範例:

程式可以用純 CPU 跑,也可以用 GPU 跑,不管哪種都很吃記憶體 XDDD

Linode 針對 2015 年的安全問題,以及 2016 年年初密碼重設行為的說明

Linode 寫了相當長的一篇報告說明 2015 發生的兩件安全事件,以及 2016 年年初重設密碼的行為:「Security Investigation Retrospective」。

結論是 Linode 沒有找出證據被攻破,但還是打算改善不少東西以確保安全性。

2015 年七月曾經有一個 Linode 的客戶報案,並且向 Linode 回報帳號被入侵的問題,而後來發現是客戶帶有 2FA 資訊的手機遺失。

2015 年十二月有個資安專家在分析時發現有人取得了許多服務的帳號密碼,其中有可能有 Linode 的使用者使用相同的密碼,所以通報 Linode 並且提供一些 IP 資訊,Linode 調查後發現提供的 IP 資訊有登入到 Linode 上的帳號,而這些帳號也的確都沒有啟用 2FA,而且詢問這些帳號的主人也確認了被盜用的情況。

接下來 Linode 還是決定投入資源繼續研究問題,尋找外部的資安團隊來確認情況,最後得到上面提到的結論:沒有找出證據被入侵:

The findings of our security partner’s investigation concluded there was no evidence of abuse or misuse of Linode’s infrastructure that would have resulted in the disclosure of customer credentials. Furthermore, the security partner’s assessment of our infrastructure and applications did not yield a vector that would have provided this level of access.

在 Lish 上有發現問題,但沒有找出被使用的證據:

Linode’s security team did discover a vulnerability in Lish’s SSH gateway that potentially could have been used to obtain information discovered on December 17, although we have no evidence to support this supposition. We immediately fixed the vulnerability.

不過 Linode 還是決定把一些架構改掉,可以在原文看到。

可以看到打算規劃類似 HSM 架構的設計,,避免密碼直接被存取。把密碼從 Salt + SHA256 (以及千次運算) 轉移到 bcrypt。然後把 ColdFusion 寫的系統改用 Python 寫。並且計畫把後台 open source 出來,讓更多人可以檢視確保安全性。

Python 的 Repository 將搬到 GitHub 上

Python 宣佈將會搬到 GitHub 上:「[core-workflow] We will be moving to GitHub」,而目前應該是在 Mercurial 架的「Python.org Mercurial repositories index」上。

看討論有很多反對意見啊...