可以看 Chrome Extension 程式碼的 Chrome extension source viewer

好像沒有提過「Chrome extension source viewer」這個套件,來介紹一下...

這個套件可以在尚未安裝前看 Chrome Web Store 裡 extension 的原始程式碼,算是可以在安裝前看一下 extension 在幹什麼。

以前還會遇到會 obfuscated code,導致很難看出來在幹什麼,但在 2018 年以後 Google 公告直接禁止這類行為,就不太會遇到這種情況了 (除非是很舊的 extension):「Trustworthy Chrome Extensions, by default」。

先前跟 Brave 還會打架,不過後來看起來沒這個問題了...

AWS App Runner 總算可以存取 VPC 內的資源了

算是上個星期的消息了,App Runner 這個產品剛出來的時候無法連到 VPC 內的資源,不知道要怎麼用,現在總算是把這個功能補上了:「New for App Runner – VPC Support」。

不過還是不看好,旁邊還有 AWS Elastic BeanstalkAWS Amplify 同質性超高的服務,都是只寫 code 丟上去就能跑:

AWS App Runner is a fully managed service that makes it easy for developers to quickly deploy containerized web applications and APIs, at scale and with no prior infrastructure experience required. Start with your source code or a container image. App Runner builds and deploys the web application automatically, load balances traffic with encryption, scales to meet your traffic needs, and makes it easy for your services to communicate with other AWS services and applications that run in a private Amazon VPC. With App Runner, rather than thinking about servers or scaling, you have more time to focus on your applications.

AWS Elastic Beanstalk is an easy-to-use service for deploying and scaling web applications and services developed with Java, .NET, PHP, Node.js, Python, Ruby, Go, and Docker on familiar servers such as Apache, Nginx, Passenger, and IIS.

You can simply upload your code and Elastic Beanstalk automatically handles the deployment, from capacity provisioning, load balancing, auto-scaling to application health monitoring. At the same time, you retain full control over the AWS resources powering your application and can access the underlying resources at any time.

AWS Amplify is a set of purpose-built tools and features that lets frontend web and mobile developers quickly and easily build full-stack applications on AWS, with the flexibility to leverage the breadth of AWS services as your use cases evolve. With Amplify, you can configure a web or mobile app backend, connect your app in minutes, visually build a web frontend UI, and easily manage app content outside the AWS console. Ship faster and scale effortlessly—with no cloud expertise needed.

更不用說旁邊還有 Lambda 類的架構...

另外一個 monospace 的字型 Hera

Lobsters Daily 上看到的字型 Hera

Source Code Pro 為主,混入了 Fira MonoInconsolataIBM Plex Mono

Hera is a monospace font which is a customised version of Source Code Pro which was originally created by Paul Hunt.

Hera consists mainly of glyphs from Adobe Source Code Pro mixed with glyphs from popular monospace fonts like Fira Mono, Inconsolata, IBM Plex Mono, etc.

Hera emphasises readability and uniformity for sigils and symbols which makes it suitable for use in coding environments.

GitHub 上有 screenshot 可以參考:

以及:

用了幾天還可以,應該會繼續用,放入常態性的替換清單... (我同一個字型看久了會想換)

Log4j2 的 RCE

昨天爆出來 Log4j2 的 RCE,看了一下 pattern,只要是 Java stack 應該都很容易中獎:「Log4Shell: RCE 0-day exploit found in log4j2, a popular Java logging package」,Hacker News 上對應的討論在「Log4j RCE Found (lunasec.io)」這邊可以看。

LunaSec 宣稱這是 0-day RCE,不過 Log4j2 的修正版本 2.15.0 在 2021/12/06 出了,而 exploit 被丟出來是 2021/12/09,但不確定在這之前是不是已經有 exploit 在 internet 上飛來飛去了...

丟出來的 exploit sample (CVE-2021-44228-Apache-Log4j-Rce) 是用 LDAP 來打,雖然大多數的 Java 版本不受影響,但還是有其他的面可以攻擊,所以整體上還是很容易打穿,該升級的還是得趕快升級:

Updates (3 hours after posting): According to this blog post (see translation), JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 are not affected by the LDAP attack vector. In these versions com.sun.jndi.ldap.object.trustURLCodebase is set to false meaning JNDI cannot load remote code using LDAP.

However, there are other attack vectors targeting this vulnerability which can result in RCE. An attacker could still leverage existing code on the server to execute a payload. An attack targeting the class org.apache.naming.factory.BeanFactory, present on Apache Tomcat servers, is discussed in this blog post.

週末苦命時間...

用 PostgreSQL 的 int4range 與 GiST

發現自己根本還不熟悉 PostgreSQL 的特性,寫一下記錄起來。

產品上常常會有 coupon 與 voucher 之類的設計,這時候通常都會設定 coupon 或 voucher 的有效期間,在 MySQL 的環境下可能會這樣設計:

CREATE TABLE coupon (
  id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
  code VARCHAR(255) NOT NULL,
  started_at INT UNSIGNED NOT NULL,
  ended_at INT UNSIGNED NOT NULL
);

另外是設計 index 的部份,在產品推出夠久後,通常是過期的 coupon 或 voucher 會比目前還有效的多,而還沒生效的 coupon 與 voucher 通常都不多,所以會設計成對 ended_at 放一組 B-tree index:

CREATE INDEX ON t1 (ended_at);

這個設計不算差,不過用了一些假設。

如果不想要用這些假設,可以改用 Spatial 的資料型態去模擬並且加上 index (使用到 LineString Class),這樣就直接對 a < x < b 這類查詢更有效率,不過缺點就是可讀性會比較差。

在 PostgreSQL 這邊就有更清晰的資料結構來處理這些事情,主要是有一般性的 int4rangeint8range 以及時間類的 tsrangetstzrangedaterange (參考「Range Types」這邊有更多資料型態),所以會變成:

CREATE TABLE coupon (
  id INT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
  code VARCHAR NOT NULL,
  active_at INT4RANGE NOT NULL
);

然後用 GIST 建立 index:

CREATE INDEX ON t1 USING GIST(active_at);

後續的 query 語法就用 <@ 的語法:

SELECT COUNT(*) FROM coupon WHERE 10000 <@ active_at;

塞了 10M 筆資料後的 table 可以看到本來需要的時間是:

Time: 779.542 ms

變成:

Time: 5.510 ms

不過缺點就是 SQLite 沒支援這些資料型態,對於 test case 就一定得跑個 PostgreSQL 起來測...

Ansible 的爭論

前幾天在 Hacker News Daily 上看到「Five Ansible Techniques I Wish I’d Known Earlier」這篇,裡面提到了一些 Ansible 的用法還蠻有用的,算是開始用 Ansible 後應該都會有幫助的用法... 不過 Hacker News 上的討論「Ansible Techniques I Wish I’d Known Earlier (zwischenzugs.com)」比較精彩...

目前在頂端的留言對 Ansible 幹到不行,尤其是那個 YAML 格式:

Ansible is abysmal. I don't know why anyone still chooses it. It's a mess of yaml and what feels like a million yaml files that is always extremely hard to follow. Honestly writing some python, or bash is a lot easier to follow, read, and understand. The only thing it has going for it is the inventory system. I wish ansible would die already.

然後講到 bash 與 python 之類的工具時有人提到 idempotent:

>bash and python
Neither of those of idempotent.

馬上就有人幹勦,大多數人在寫 Ansible playbook 時根本沒人在注意 idempotent,而且一堆 shell script 的東西被塞進 YAML 只能說痛苦 XDDD

Most of the ansible roles I come across written by my team are not idempotent either, its a huge lie that Ansible is idempotent. Its idempotent if you put the effort into make it be but if I see tons of shell or command module invocations without prerequisite checks to see if the work should be done. Most devs I see using Ansible treat it like a shell script written in YAML and to that purpose it sucks.

我自己目前會挑 Ansible 主要還是因為 server 不需要另外裝軟體,是個 production 為導向的設計,再更大的時候就要想一下要怎麼繼續搞下去了...

GitHub Copilot 產生出來程式的安全性問題

看到「Encoding data for POST requests」這篇大家才回頭注意到 GitHub Copilot 首頁的範例本身就有安全漏洞:

async function isPositive(text: string): Promise<boolean> {
  const response = await fetch(`http://text-processing.com/api/sentiment/`, {
    method: "POST",
    body: `text=${text}`,
    headers: {
      "Content-Type": "application/x-www-form-urlencoded",
    },
  });
  const json = await response.json();
  return json.label === "pos";
}

其中 text=${text} 是一個 injection 類的漏洞,首頁的範例應該是被挑過的,但仍然出現了這個嚴重的問題,從這邊可以看出 GitHubOpenAI 在這條線上的問題...

GitHub 與 OpenAI 合作推出的 GitHub Copilot

Hacker News 首頁上的第一名看到 GitHubOpenAI 合作推出了 GitHub Copilot,對應的討論可以在「GitHub Copilot: your AI pair programmer (copilot.github.com)」這邊看到。

GitHub Copilot 會猜測你接下來會想要寫的「完整片段」,像是這樣:

不過 Hacker News 上面的討論有參與 alpha 測試的人的評價,大概 1/10 機率會猜對,即使如此,他還是給了很多有用的資訊 (像是函式與變數的名稱):

fzaninotto

I've been using the alpha for the past 2 weeks, and I'm blown away. Copilot guesses the exact code I want to write about one in ten times, and the rest of the time it suggests something rather good, or completely off. But when it guesses right, it feels like it's reading my mind.

It's really like pair programming, even though I'm coding alone. I have a better understanding of my own code, and I tend to give better names and descriptions to my methods. I write better code, documentation, and tests.

Copilot has made me a better programmer. No kidding. This is a huge achievement. Kudos to the GitHub Copilot team!

然後也有人笑稱總算找到理由寫 comment 了:

pfraze

They finally did it. They finally found a way to make me write comments

反過來的另外一個大問題就是 copyright,這點在目前的問答集沒看到... 在 Hacker News 裡面的討論有提到這點,但目前沒有完整的定論。

目前只支援 VSCode,以後也許會有機會透過 LSP 支援其他的編輯器?

另外我想到 Kite 這個 machine learning 的 auto complete 工具,沒有那麼強大但也還不錯?

PHP 的 Git Server 被打穿,決定把整個 Git 系統搬到 GitHub 上

就如同標題說的:「Changes to Git commit workflow」,Hacker News 上的討論也可以看一下:「PHP's Git server compromised, moving to GitHub (php.net)」。

Yesterday (2021-03-28) two malicious commits were pushed to the php-src repo [1] from the names of Rasmus Lerdorf and myself. We don't yet know how exactly this happened, but everything points towards a compromise of the git.php.net server (rather than a compromise of an individual git account).

While investigation is still underway, we have decided that maintaining our
own git infrastructure is an unnecessary security risk, and that we will
discontinue the git.php.net server. Instead, the repositories on GitHub,
which were previously only mirrors, will become canonical. This means that
changes should be pushed directly to GitHub rather than to git.php.net.

不知道發生什麼事情,要等事後的報告出來...

用 Amazon SNS 送簡訊可以固定發送號碼了

Amazon SNS 的簡訊功能可以申請固定發送號碼了:「Amazon SNS now supports selecting the origination number when sending SMS messages」。

固定的號碼包括了短碼與長碼:「Requesting dedicated short codes for SMS messaging with Amazon SNS」、「Requesting dedicated long codes for SMS messaging with Amazon SNS」。

短碼是三到七碼,依照地區而有差異:

A short code typically contains between three and seven digits, depending on the country or region that it's based in.

要注意的是短碼的部份需要開 support case 申請,而不是直接在 web console 上操作:

Open a case with AWS Support by completing the following steps.

長碼則是有可能到 12 碼,依照不同地區的設計有所不同:

A long code (also referred to as a long virtual number, or LVN) is a standard phone number that contains up to 12 digits, depending on the country that it's based in.

不過現在長碼的部份只有美國可以用,而且有速率限制:

Support for long codes is restricted to the United States only. Sending rates for long codes are restricted to 1 message per second. This restriction is set by the telecom carriers, and isn't a limitation of Amazon SNS. If you send a large volume of messages from a long code, wireless carriers might begin to block your messages. Your applications that use Amazon SNS should limit the number of messages that they send each second.

說道 Amazon SNS 送簡訊的費用,實在不怎麼好看,量小加減用 (包在 AWS 費用裡,省人力另外跑請款的單子),量大還是要找其他家接比較划算...