幹壞事是進步最大的原動力
AWS 宣布 Amazon DynamoDB 也可以透過 VPC Endpoints 接通了 (雖然是 public preview，表示要申請...)：「Announcing VPC Endpoints for Amazon DynamoDB, Now in Public Preview」。
但看起來只有特定的區域才有，大家比較常用的 us-east-1、us-west-2 都不在本次範圍內：
這樣讓內部完全無法連外的 private subnet 又多了一些應用可以跑。
BitTorrent 已經有足夠的技術與環境 (ecosystem) 做出完全分散式架構的搜尋引擎了，類似於 eDonkey Network (或是說後來變成主流的 eMule) 上的 search 功能，但一直沒看到類似的東西...
而 magnetico 算是一個嘗試，完全透過 DHT 搜尋取得結果：
不過這套軟體的 license 是攻擊性超強的 AGPLv3，算是實驗性質吧。要真正普及應該要像 eMule 一樣直接做進 client 內...
OpenSSL 最近打算把原本的 license 換成 Apache License, Version 2.0：「Licensing Update」。
主要的原因是希望相容於現有大多數的 open source project：
OpenSSL Re-licensing to Apache License v. 2.0 To Encourage Broader Use with Other FOSS Projects and Products
但這非常詭異啊，舊的 license 最大的問題就是與 GPLv2 不相容，而預定要換的 AL 2.0 也還是不相容啊，搞屁啊。
順著 SHA-1 正式被打穿，Mozilla 也正式宣佈從下一個版本的 Firefox 將完全關閉 SHA-1 支援 (看敘述應該還是可以透過 about:config 開)：「The end of SHA-1 on the Public Web」。
As announced last fall, we’ve been disabling SHA-1 for increasing numbers of Firefox users since the release of Firefox 51 using a gradual phase-in technique. Tomorrow, this deprecation policy will reach all Firefox users. It is enabled by default in Firefox 52.
大家都開始有動作了...
看到這張圖在講不同 server (service) 如何處理今年的 leap second (UTC 的跨年，台灣時間早上八點)，出自 leap smear 這邊：
在很早前就有 time.google.com 這個 domain，但是當時 Google 的人有跳出來說明這個服務不是公開服務 (當時)，不保證這個服務的正確性與穩定性：「timeX.google.com provide non standard time」。
不過一個月前公佈出來的 Google Public NTP 服務算是把整個系統搞定了。
其中在 Configuring Clients 這邊直接推薦用 iburst 參數，不愧是家大業大的 Google XDDD：
When the server is unreachable and at each poll interval, send a burst of eight packets instead of the usual one. As long as the server is unreachable, the spacing between packets is about 16s to allow a modem call to complete. Once the server is reachable, the spacing between packets is about 2s. This is designed to speed the initial synchronization acquisition with the server command and s addresses and when ntpd is started with the -q option.
回到原來的 leap smear 的比較圖，可以看出 Google 對 leap second 的解法是往前十二小時與往後十二小時各拉緩衝時間來避開，有些是沒在管，另外有些有種來亂的感覺 XDDD
現有常見的幾個加密基礎在量子電腦上都有相當快速的解 (像是整數質因數分解、離散對數)，只是現在建不出對應夠大台的量子電腦... 但畢竟只是時間的問題了，所以 NIST 照著慣例對外尋求能夠抵抗量子電腦的演算法：「NIST Asks Public to Help Future-Proof Electronic Information」、「Announcing Request for Nominations for Public-Key Post-Quantum Cryptographic Algorithms」。
類似於 Google 先前在 Google Chrome 上實做的 CECPQ1，對 key exchange 的部份加上保護 (Google Chrome 引入 CECPQ1，開始測試 Post-Quantum Cryptography)，這次 NIST 是針對 public key crytpsystem 的部份而發的...
投稿時間在 2017 的十一月底，大約一年後就可以看到有哪些演算法要參加競賽了... 不過因為 NSA 的惡名，不知道會不會有其他單位在同個時段啟動類似的活動...
關於 HPKP，可以參考「HTTP Public Key Pinning 介绍」這篇介紹，寫得很清楚。
HPKP 是解決 CA 架構錯發憑證的方案 (無論是無意或是故意)，像是最近吵的比較熱的 WoSign 發出 GitHub 的憑證的問題就可以用 HPKP 解。
原理上來說，就是在 HTTP header 裡面指出這個站台所允許的 Root CA 有哪些。所以跟 HSTS 一樣是走 Trust On First Use 架構，當 client 第一次連上的時候會記下資訊，之後就可以使用這個資訊來驗證。
但 HPKP 與 HSTS 不同的地方在於，HSTS 只是個 Yes/No 問題 (i.e. 是否強迫使用 HTTPS)，而且通常 migrate 上去後就不會拔掉。
但 HPKP 則是要指定 Root CA，這代表不能隨便換一家簽。當你用的那家 Root CA 出包時就苦了... (就像 WoSign 免費憑證的問題)
這使得 HPKP 的實作成本過高，而且得到效益太低，另外也因為替代的方案有不少 (像是 Certificate Transparency)，導致 HPKP 根本沒什麼人用：「Is HTTP Public Key Pinning Dead?」。
在 comment 有人直接拉出來統計，使用的比率反而在下降：
From my stats looking to the Alexa 1K top websites from 2015-07-26 to 2016-07-31 the number of websites NOT using HPKP increase from 99.47% to 99.58% which means almost nothing.
不過我覺得算是平行發展吧，這些驗證的技術都不怎麼衝突... HPKP 解決問題的方法非常的技術面，而 Certificate Transparency 還是走稽核路線讓 Root CA 回報每一個發出的 Certificate...
Bitcoin.org 發出了有點摸不著頭緒的警告：「0.13.0 Binary Safety Warning」。
Bitcoin.org has reason to suspect that the binaries for the upcoming Bitcoin Core release will likely be targeted by state sponsored attackers. As a website, Bitcoin.org does not have the necessary technical resources to guarantee that we can defend ourselves from attackers of this calibre.
而且直接是點名可能是針對中國區的用戶：
We ask the Bitcoin community, and in particular the Chinese Bitcoin community to be extra vigilant when downloading binaries from our website.
由於 Bitcoin.org 全站走 HTTPS，這是在暗示會出現「不小心發出 Bitcoin.org 的 SSL certificate」的事情？另外官方也建議使用 PGP public key 驗證：
We strongly recommend that you download that key, which should have a fingerprint of 01EA5486DE18A882D4C2684590C8019E36C2E964. You should securely verify the signature and hashes before running any Bitcoin Core binaries. This is the safest and most secure way of being confident that the binaries you’re running are the same ones created by the Core Developers.
來拿板凳蹲著看，順便拉一張目前 certificate 看到的資訊，目前是從 RapidSSL SHA256 CA - G3 簽出來：
以往 GitHub 在個人頁面上的 contribution 只會計算 public repository，現在則可以設定將 private repository 也統計進去：「More contributions on your profile」。
private repository 的部份只會顯示數量，不會公開任何細節，像是我用 incognito mode (無痕模式) 可以看到在沒有登入時的資訊：
但如果是登入後就會有詳細資料：
