Tag: package

HashiCorp 家的軟體看起來都支援 APT repository 了

以前 HashiCorp 家的軟體大多都是自己下載 binary 後放到 /usr/bin 或是 /usr/local/bin 下使用，剛剛翻了一下 Nomad 與 Vault，看起來都支援 APT repository 了：「https://apt.releases.hashicorp.com」；另外也有 RPM repository：「https://rpm.releases.hashicorp.com」。

這樣下個禮拜分享會的投影片也要改一改了...

另外看了一下架構，從錯誤訊息觀察，看起來後面是 Amazon S3，前面是 Fastly 的 CDN。

Arch Linux 決定把套件壓縮演算法從 xz 換成 Zstandard

看到 Arch Linux 的公告，他們決定把套件的壓縮演算法從 xz 換成 Zstandard：「Now using Zstandard instead of xz for package compression」。

從 xz 換成 Zstandard 主要的原因在於不用犧牲太多空間 (多 0.8% 的空間)，但解壓縮的速度可以大幅提昇 (提昇 13 倍)：

zstd and xz trade blows in their compression ratio. Recompressing all packages to zstd with our options yields a total ~0.8% increase in package size on all of our packages combined, but the decompression time for all packages saw a ~1300% speedup.

看起來是不斷發酵... 在幾個月前隔壁棚的 Fedora 先換過去了，計畫在「Changes/Switch RPMs to zstd compression」這邊可以翻到，而 issue tracking system 上的記錄可以參考「Issue #350: F31 System-Wide Change: Switch RPMs to zstd compression - release-notes - Pagure.io」。

看起來會是趨勢了...

pipenv 的凋零與替代方案 poetry

看到「If this project is dead, just tell us」這個，裡面討論到了 pipenv 的前景愈來愈讓人疑惑，要官方給個意見，結果下面就馬上有人建議跳槽到 poetry。

剛好前陣子看到另外一篇文章「My Python Development Environment, 2020 Edition」，裡面也提到了他把 pipenv 換成 poetry，而且提到了 pipenv 的問題：

pipenv → poetry. This move’s more complex. I stoped using Pipenv for a couple of reasons:

  • Governance: the lead of Pipenv was someone with a history of not treating his collaborators well. That gave me some serious concerns about the future of the project, and of my ability to get bugs fixed.
  • Bugs and rapid API changes. About a year ago, Pipenv had lots of bugs, and a rapid pace of change introducing or changing APIs. I ran into minor issues at least once a week. Nothing was seriously bad, but it generally felt fairly unstable. I kept having to update various automated deploy workflows to work around issues or changes to Pipenv.

看起來 tech stack 裡面要把 pipenv 轉移抽離了...

GitHub 推出 Package Registry

GitHub 推出了「GitHub Package Registry」，可以代管自己開發的軟體。

目前支援 npm (Node.js)、Docker、Maven (Java)、NuGet (.NET)、RubyGems (Ruby) 五個平台，

隔壁 GitLab 說我們早就有了而氣噗噗中：「Packaging now standard, dependency proxy next?」。

Anyway，省下一些事情，以前會透過 CI/CD 丟到像是 packagecloud.io 這樣的服務上讓內部使用，現在看起來 GitHub 上面可以解決一些簡單的情境...

Ondřej Surý 的 PPA 將會繼續支援 PHP 5.6 與 PHP 7.0 的安全性更新

在 Twitter 上看到 Ondřej Surý 因為得到協助 (包括 Microsoft)，所以會繼續支援 PHP 5.6 與 PHP 7.0 的 PPA 更新：

在「PHP 5.6 and PHP 7.0 will stay (for now)」裡面有提到這是 best effort，沒有保證會維持多久：

Please note that this is based on best effort and without any warranty.

對於還在這兩個版本掙扎的人再多了一些時間...

APT 不使用 HTTPS 的說明

居然有個獨立的網站在說明：「Why does APT not use HTTPS?」。主要是 HTTPS 沒有增加太多保護，但會使得維護的複雜度變高很多。

首先是被竄改的問題，APT 本身就有簽名機制 (參考「SecureApt」)，即使 mirror site 被打下來也無法成功竄改內容，反而比起單純的 HTTPS 保護還好。

而對於隱私問題，由於內容是可以公開取得的，這代表可以看封包的大小與流動順序猜測是哪些 package 被下載 (也就是類似「利用 Side-channel 資訊判斷被 HTTPS 保護的 Netflix 影片資訊」這篇提到的方法)，加上 APT 這邊還多了時間性的資訊 最近被更新的軟體被下載的機率比較高)，所以隱私的保護上其實有限。

而針對攻擊者刻意提供舊版的問題 (某種形式的 replay attack)，APT 降低風險的解法是把時間簽進去，當用戶端發現太久沒更新時，就當作過期失效而提出警告。

就以上來看，把所有的 APT 伺服器都加上 HTTPS 的工程太浩大，而得到的效益太小。所以願意提供 HTTPS 的站台就提供，但主要的保護還是從本來的 SecureApt 機制上提供。

2018 年矽谷科技公司的薪資

不太意外的，排名起來加州這一區的科技公司的薪資還是最高的 (這邊包括了所有的所得，包括薪資、股票與分紅)：「Top Paying Tech Companies of 2018」。

已經先整理出來的前五名分成「Entry-level / 1+ Yrs of Experience」、「Mid-level / 3+ Yrs of Experience」、「Been Around the Block / 5+ Yrs of Experience」三類，可以看到相對於年資的增加，薪資的調整也很快...

不過這邊相同名次的不會佔多個位置，只會佔一名，跟我們平常用的方式不太一樣，所以雖然是前五名但是都有六個公司。

把本來 dehydrated 的 PPA 改成 dehydrated-lite

本來有做 dehydrated 的 PPA (在「PPA for dehydrated : Gea-Suan Lin」這邊)，後來在 17.10+ 就有更專業的人包進去了 (參考「Ubuntu – Package Search Results -- dehydrated」)，為了避免名稱相同但是內容物差很多，我把 PPA 的名字換成 dehydrated-lite 了 (參考「PPA for dehydrated (lite) : Gea-Suan Lin」)。

然後 0.6.2 的 dehydrated 針對 ACMEv2 有修正，這在 0.6.1 時會產生 certificate 裡有多餘資訊 (而 PPA 版的 gslin/dehydrated 只會停留在 0.6.1)，這點需要注意一下：

Don't walk certificate chain for ACMEv2 (certificate contains chain by default)

之後再找機會拔掉 gslin/dehydrated，也許會照著現在 APT 內的架構來做...

用 Composer 的 require 限制，擋掉有安全漏洞的 library...

查資料的時候查到的，在 GitHub 上的 Roave/SecurityAdvisories 這個專案利用 Composer 的 require 條件限制，擋掉有安全漏洞的 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

Google 推出比較兩個 Docker Image 的 container-diff

Google 放出來的工具，可以比較兩個 Docker Image 的內容：「Introducing container-diff, a tool for quickly comparing container images」，GitHub 的連結在「GoogleCloudPlatform/container-diff」這邊。

不是單純的 binary diff，而是分析裡面的內容。像是安裝套件的差異，或是 pip 與 npm 的差異：

主要是開發者會用到，可以觀察不同 container 之間的差異。