Home » 2018 » February

義大利政府的反貪組織用 Tor 的 Onion (Hidden Service) 接受檢舉

在「Italian Anti-Corruption Authority (ANAC) Adopts Onion Services」這邊看到,義大利政府因為法令要求必須保護告密者,而不只是在需要提供身份的階段才保護:

Many national laws (such as Italian Dlgs. 231/2001) require companies to adopt corporate governance structures and risk prevention systems, which can include allowing whistleblowing submissions. However, most whistleblowing laws only protect whistleblowers when their identity is disclosed, which can put the person reporting corruption at risk.

In 2016, the International Standards Organization (ISO) released a new model for organizations setting up and operating anti-bribery management systems, ISO 37001:2016. To meet ISO standards, organizations or companies implementing anti-corruption procedures must allow anonymous reporting, as explicitly indicated in point 8.9 of section C of ISO 37001:2016.

Furthermore, national laws (such as recent Italian 179/2017) require the adoption of IT systems for whistleblowing, leading to the practical integration and use of Tor for its technological anonymity features.

而義大利政府的系統選擇用 Tor 的 Onion (Hidden Service) 提供服務接受檢舉:

To comply with these standards, the Italian Anti-Corruption Authority (ANAC), an administrative watchdog, just launched their national online whistleblowing platform using onion services, giving whistleblowers who come forward a secure way to report illegal activity while protecting their identities.

這使用了 hidden service 的特性,讓伺服器端完全無法得知 client 的位置,對於使用有足夠保護的 browser 來說 (像是 Tor Browser),這可以完全讓 server 端無法得知身份,即使政府的伺服器都入侵也沒辦法知道告密者是誰。

這點頗先進的...

GitHub 的 Gist 要移除匿名發表的功能了...

GitHubGist 變成要註冊使用者才能貼了:「Deprecation notice: Removing anonymous gist creation」。主要的原因也還是因為太多 spam 之類的訊息:

In 30 days, we'll be deprecating anonymous gist creation—a decision we made after a lot of deliberation. Anonymous gists are a handy tool for quickly putting a code snippet online, but as the only way to create anonymous content on GitHub, they also see a large volume of spam. In addition, many people already have a combination of tools authenticated with GitHub that allow them to create gists they own.

預定是 3/19 關閉... 只好繼續貼 Pastebin 了... XD

總算把手上的 Trac 1.0 升級到 1.2 了...

就如同上一篇提到的,Trac 在 1.1.1 後新增了 time 格式,所以本來的 DateFieldPlugin 有些資料要轉換。我這邊只有用在 Due Date,所以就是轉 due_date 的資料而已。

先把 due_date 都改成 due_date_bak

UPDATE ticket_custom SET name = 'due_date_bak' WHERE name = 'due_date';

然後重新計算資料,這邊是因為所有的系統都是 UTC,所以直接轉就可以了:

INSERT INTO ticket_custom (ticket, name, value) SELECT ticket, 'due_date', LPAD(UNIX_TIMESTAMP(STR_TO_DATE(value, '%Y-%m-%d')) * 1000000, 18, '0') FROM ticket_custom WHERE name = 'due_date_bak';

而我的 Report 有用到 due_date 欄位的東西,本來是 c.value 直接輸出,現在要改成:

FROM_UNIXTIME(CONVERT(c.value / 1000000, UNSIGNED INTEGER), '%Y-%m-%d') AS due_date

Trac 1.2 相較於 1.0 最不習慣的地方應該是修改界面的位置改變了,現在 Add Comment 變成在 Modify 下面,有點不太習慣,但之後用久了應該就會習慣了。其他的修一修改一改都會動了...

Trac 1.1 增加的 time 欄位,以及 Due Date 資料的轉移

Trac 的版本玩法跟早期 Linux Kernel 的模式有點像,也就是版號偶數是正式版,奇數是開發版... 雖然現在 Linux Kernel 已經不玩這套了,但 Trac 還是維持這樣的開發方式。

先前一直都是用 Trac 1.0,其中 Due Date 的功能則是用「DateFieldPlugin」這個套件,讓 Trac 支援 date 格式,於是就可以在 [ticket-custom] 裡面指定 Due Date 了:

due_date = text
due_date.date = true
due_date.date_empty = false
due_date.label = Due Date
due_date.value = <now>

在套件的頁面也有提到在 Trac 1.1.1 後就有內建的方式可以用了:

Notice: This plugin is deprecated in Trac 1.2 and later. Custom fields of type ​time were added in Trac 1.1.1.

連結是連到 1.1 的,我要測 1.2 的,所以往現在的版本翻資料,可以看到在 TracTicketsCustomFields 這邊的說明:(這邊就懶的照原來 html 排了,用 pre 直接放縮排)

time: Date and time picker. (Since 1.1.1.)
    label: Descriptive label.
    value: Default date.
    order: Sort order placement.
    format: One of:
        relative for relative dates.
        date for absolute dates.
        datetime for absolute date and time values.

這樣一來設定就會變成:

due_date = time
due_date.format = date
due_date.label = Due Date
due_date.value = now

但底層資料怎麼存?先看 ticket_custom 這個表格的結構,可以看到是 EAV 的架構:

+--------+------------+------+-----+---------+-------+
| Field  | Type       | Null | Key | Default | Extra |
+--------+------------+------+-----+---------+-------+
| ticket | int(11)    | NO   | PRI | NULL    |       |
| name   | mediumtext | NO   | PRI | NULL    |       |
| value  | mediumtext | YES  |     | NULL    |       |
+--------+------------+------+-----+---------+-------+
3 rows in set (0.00 sec)

隨便拉一些可以看出來放法很簡單:

+--------+----------+------------+
| ticket | name     | value      |
+--------+----------+------------+
|      1 | due_date | 2016-10-03 |
+--------+----------+------------+

改成 Trac 1.2 內建的 time 後,塞 2018/02/28 變成:

+--------+----------+--------------------+
| ticket | name     | value              |
+--------+----------+--------------------+
|      1 | due_date | 001519776000000000 |
+--------+----------+--------------------+

拿掉後面的六個 0 後可以看到就是 2018/02/28 了,要注意的是,這邊會受到時區影響,我一開始測試的時候沒調整,寫進去的時間是用伺服器預設的時區計算的。另外也大概能理解前面放兩個 0 的目的,是為了讓 string 比較時的大小就會是數字實際的大小。

$ date --date=@1519776000
Wed Feb 28 00:00:00 UTC 2018

這樣就知道要怎麼做人工轉換了...

nginx 的 HTTP/2 要支援 Server Push 了

Twitter 上看到 nginx 的 HTTP/2 也要支援 server push 的消息了:

看起來是只要送出對應的 HTTP Header,後續 nginx 就會幫你處理...

這功能總算是要進 nginx 了... 像是透過 cookie 判斷使用者是第一次瀏覽,就透過 server push 預先把 css/js 丟出去,加速頁面呈現。

KPTI (Meltdown Mitigation) 對 MyISAM 的痛點

MariaDB 的「MyISAM and KPTI – Performance Implications From The Meltdown Fix」這篇看到頗驚人的數字,這篇提到了他們收到回報 (回報的 ticket 可以參考「[MDEV-15072] Massive performance impact after PTI fix - JIRA」),說 KPTI (Meltdown Mitigation) 對 MyISAM 效能影響巨大:

Recently we had a report from a user who had seen a stunning 90% performance regression after upgrading his server to a Linux kernel with KPTI (kernel page-table isolation – a remedy for the Meltdown vulnerability).

他們發現 90% 是因為 VMware 舊版本無法使用 CPU feature 加速,在新版應該可以改善不少。但即使如此,文章內還是在實體機器上看到了 40% 的效能損失:

A big deal of those 90% was caused by running in an old version of VMware which doesn’t pass the PCID and INVPCID capabilities of the CPU to the guest. But I could reproduce a regression around 40% even on bare metal.

然後後面就在推銷 MariaDB 的 Aria Storage Engine 了,不是那麼重要... 不過知道 MyISAM 在 KPTI 下這麼傷還蠻重要的,因為接下來五年應該都還是愈的到 KPTI,應該還是有人在用 MyISAM...

NAVER CLOUD PLATFORM

在「HashiCorp Packer 1.2.0」這篇看到的雲端平台:

New builder: ncloud for building server images using the NAVER Cloud Platform.

NAVERLine 母公司,這是他們推出的雲端平台,看起來相似的產品是 AWS。在 https://www.ncloud.com/charge/region 這邊可以看到提供了韓國、美國、新加坡、香港、日本與德國,可以看出因為是韓國公司,擴了不少亞洲的點...

找時間看一看好了,目前看起來 routing 好像還不錯?

Googlebot 的 Math.random()

Hacker News Daily 上看到「Googlebot’s Javascript random() function is deterministic」這則有趣的發現。作者發現 Googlebot 的 Math.random() 並不隨機,甚至是固定的:

The first time Googlebot calls Math.random() the result will always be 0.14881141134537756, the second call will always be 0.19426893815398216. The script I linked to above simply uses this fact but obfuscates it a little and ‘seed’ it with something that doesn’t look too arbitrary.

需要無法預測的 random number (有安全性需求的) 應該用 RandomSource.getRandomValues() 這類函數,而不是用 Math.random(),所以這點倒是還好...

Archives