List of Site [text.Baldanders.info]

Hugo v0.162.0 がリリースされた【Security fix あり】

2026-05-27T07:01:18+00:00

Hugo v0.162.0 がリリースされた。

Release v0.162.0 · gohugoio/hugo

Go コンパイラおよび関連パッケージのセキュリティ・アップデートがあるのはいつものことなのだが，今回は注意すべき修正がある。

Security fixes and hardening in Hugo

The following changes either fix a concrete issue or reduce the default attack surface of hugo builds.

Disallow text/html content files by default (e41a064). A new security.allowContent policy gates which content media types may be used for pages under /content. text/html is denied by default; sites that rely on hand-authored or adapter-emitted HTML content can opt back in with security.allowContent = ['.*'].

Re-check security.http.urls on every redirect hop in resources.GetRemote (86fbb0f).

Reject symlinked entries in resources.Get (f8b5fa0).

via Release v0.162.0 · gohugoio/hugo

このうち，最初の項目にまんまと引っかかった。こんな感じ：

ERROR error building site: assemble: failed to create page from pageMetaSource 
/remark/2015/gnupg-2-1-8: "/path/to/content/remark/2015/gnupg-2-1-8.html:1:1": 
access denied: "text/html" is not whitelisted in policy "security.allowContent"; 
the current security configuration is:

[security]
  allowContent = ['! ^text/html$']
  enableInlineShortcodes = false
  ...

どうも既定では HTML ファイルを拒否する設定になったらしい。それならば HTML を許可すればいいだろうと， “!” を取って

[security]
  allowContent = ["^text/html$"]

と hugo.toml に書いたら markdown ファイルが全拒否になってしまった（笑）。HTML と markdown のみを許可するには

[security]
  allowContent = ["^text/markdown$", "^text/html$"]

などとする必要がある。ちなみに Hugo では

Create your content using Markdown, HTML, Emacs Org Mode, AsciiDoc, Pandoc, or reStructuredText.

via Content formats

と多様なフォーマットに対応している。この中で HTML 形式を受け入れるのは（malware を埋め込まれたりとか）リスクが高いと判断して安全側に倒したものと思われる。実運用では security.allowContent に，実際に使用するドキュメントフォーマットのみを列挙するのが正しいのだろう。

エラーの出た gnupg-2-1-8.html はこのブログにおける最初の記事で，元々は Movable Type 用に書いた記事で「そのまま読み込ませてコンパイルできるかなぁ」と試してみた記事だった。記事本文の HTML 記述はともかく front matter を整えるのが面倒くさそうなので旧ブログからの移行は諦めたが。今なら変換ツールを AI に書かせたんだろうなぁ（笑）

最近は GitHub Copilot に Hugo のアップデートと redeploy をさせているのだが，今回の障害の分析と対処はすべてお任せで作業を完遂できた。「Hugo のマイナーバージョンアップは問題が出やすいから気をつけて」と指示に添えたのが功を奏したようだ。自力でやったら悩みまくって，ドキュメントを調べまくって30分くらい時間を無駄にしてただろう。いい時代になったものである。

GitHub Copilot はシェル芸達者

2026-04-09T06:57:34+00:00

最初に予防線を張っておくと，この記事は技術系の内容ではありませんし，私は生成 AI の扱いにも慣れてません。その辺を割り引いて読んでいただけるとありがたいです。

生成 AI にどこまで任せていいのか

最近は GitHub Copilot に開発支援だけじゃなくて，このブログのメンテナンスもさせている。なにせ，どこまで任せていいのか匙加減がさっぱり分からないので，できそうなところから徐々に任せていく感じ。気分は新卒社会人の OJT だぜ（笑）

今のところ GitHub Copilot に任せているのは以下の作業：

タイトル & slug の提案と記事ファイルの作成
書いた記事の校正とタグの提案
記事ファイルの commit & push
ブログのビルドと GitHub Pages への commit & push
Hugo の更新

記事そのものは書かせてない。

いや，生成 AI に書かせるとホンマに好き勝手な（私の意図とは程遠い）ことを書くのよ。一度，タイトルだけ決めたまっさらな状態で書かせようとしたら「何の論文を書く気？」って感じのアウトラインを組み始めて，さすがに止めた。ブログ記事に10個も章立てしてどうする（笑）

よくアフィリエイト記事を AI に書かせて云々みたいな話を聞くけど，ホンマに AI に書かせてるの？かなり無茶苦茶するぞ。ある意味，文才があるのかも知れないが。

というわけで「記事を書く」以外の作業をやらせている。

ちなみにモデルは GPT-5.3-Codex を使っている。あまり Premium Request を消費したくないので最初は GPT-5 mini を使ってたのだが，どうもこの手の「作業」には向かない感じ。最終的にはローカル LLM を構築したいのだが，お試しレベルならともかく，まともに動くモデルを個人環境で構築するのは難しいか？

タイトル & slug の提案と記事ファイルの作成

私は最初にタイトルを決めないとブログ記事が書けない。マイクロブログ程度の短文ならともかく，ブログ記事でタイトルも決めずに書き始めると大抵記事が迷走する（タイトルを決めて書いても迷走しがちなのだが，それはそれ）。

手順としては

日本語のタイトルを決める（ここだけ私の作業）
Copilot に英語の翻訳と対応する slug を提案させる（たいてい複数個の候補を提案してくれる）
slug が決まったら記事ファイルを作成させる
ファイル内の front matter を埋めさせる

という感じ。日本語タイトルを英訳させるための対話で，色々と気付きがあって面白い。

たとえば日本語タイトルが曖昧で英訳が頓珍漢な文になることがある。これは生成 AI 以前の機械翻訳サービスを使ってたときもそうだったが，機械と対話することで「文のこの部分が誤解を招いてるのか」と気づいたりできるわけだ。こういったやり取りが意外と面白かったりする。

記事ファイルの作成用にシェルスクリプトを組んでいるのだが，まずその挙動を理解させるところから始めた。したら「このスクリプトをリファクタリングするか？」と訊いてきたのでやらせてみたら，なかなかいい感じに仕上げてくれた。これなら AI にスクリプトを改善させることもできそうだ。

他の既存のスクリプトについても同様にリファクタリングさせ，それらの使い方を copilot-instructions.md および README.md にまとめさせた。

書いた記事の校正とタグの提案

私のブログは意図的に文体を崩して書いているので（設計書やビジネス文書じゃあるまいし），下手に賢い lint では却って使いづらかったりする。ためしに Copilot に「誤字だけ指摘して」と指示してみたら，いい感じに結果を返してくれた。以来，校正は Copilot に任せている。

誤字だけでなく慣用句の漢字間違いの指摘とかは結構ありがたかったり。それでいて崩した文体については一切スルーしてくれる（笑）偉い偉い。

もうひとつ悩んでいるのが記事に付与するタグの選択だ。これを普通に AI に任せるとメチャクチャにしてくれるので，まずは過去の記事を全て浚ってタグの一覧を作らせるところから始めた。

したらすごい勢いでシェルスクリプトを書き始めた。私はそれを「へぇ。なるほど」とか言いながら眺めるだけ。アレだ。ペアプログラミングってやつ（笑）機械相手にペアプロすることになるとは思わなかった。

せっかくいい感じのスクリプトを書いてくれたので，それをファイルにまとめていつでも呼び出せるようにさせた。タグの一覧を出現数の多いものからソートして CSV ファイルに出力させる。ここまでできれば，作成した記事に対してタグ一覧の中から妥当なタグを提案するよう指示すればよい。

タグ一覧を作ったメリットはもうひとつあって typo がいくつか見つかったのと似たような意味のタグの重複が見つかった。見つけたのも Copilot だけど（なにせ10年以上の間にタグが450個以上できてるのだ）。これらも修正方針を提案させた上で修正させた。ファイル作業に関してはちゃんと手順を踏めば間違えることなくやってくれる。

記事ファイルの commit & push

記事ファイルの commit に関しては，念のため，最初に commit message を提案させて，私が確認してから実際の作業を行わせている。ここで GPT-5 mini と GPT-5.3-Codex の違いが大きく出た。

いや，ブログ記事の追加なんだから AI (君) のしたことを書くんじゃなくて，どんな記事を追加したのかを書けよ！

というわけで，GPT-5 mini は向いてないという結論になった。 commit & push するためのコマンドラインの組み立て自体はどちらも大差ないんだけどねぇ。

ブログのビルドと GitHub Pages への commit & push

ブログのビルドと GitHub Pages への commit & push についても以前からスクリプトファイルを作っていたので，それをそのまま Copilot に使わせている。まぁ，自分でやったほうが早いのだが，作業の一連を任せることに意味があると思ってるので，敢えて任せている。この辺も OJT っぽいよな（笑）

指示も最初はできるだけ具体的にしていたが，最近は「デプロイして」だけでも（過去の作業履歴や copilot-instructions.md の記述から）適切に処理してくれるようになった。

Hugo の更新

このブログは静的サイトジェネレータである Hugo を使って構築しているのだが，未だ v1 に到達せずベータ版のままである。古いテンプレート変数や関数のいくつかは deprecated になっているし，稀に破壊的変更が起きることもある。 Hugo のバージョンアップのたびにビルドし直して互換性等の確認をしているのだが，だんだん面倒くさくなってきたので，これも Copilot に任せてみることにした。

今回もゴリゴリとスクリプトを書き始める AI。私も前と同じく様子を眺めていたが，出来がよさそうなのでスクリプトファイルとして書き出してもらった。こんな感じ（長いぞ！）。

#!/usr/bin/env bash
set -euo pipefail

# Install latest Hugo Extended .deb from GitHub Releases using apt.
# Usage: ./hugo_inst.sh

REPO="gohugoio/hugo"
API_URL="https://api.github.com/repos/${REPO}/releases/latest"
WORK_DIR="${TMPDIR:-/tmp}/hugo-inst.$$"

cleanup() {
  rm -rf "$WORK_DIR"
}
trap cleanup EXIT

mkdir -p "$WORK_DIR"
cd "$WORK_DIR"

arch="$(dpkg --print-architecture)"
case "$arch" in
  amd64|arm64)
    ;;
  *)
    echo "Unsupported architecture: $arch" >&2
    echo "This script supports: amd64, arm64" >&2
    exit 1
    ;;
esac

echo "Current Hugo:"
if command -v hugo >/dev/null 2>&1; then
  hugo version || true
else
  echo "hugo command not found"
fi

echo "Fetching latest release metadata from ${REPO} ..."
release_json="$(curl -fsSL "$API_URL")"

version="$(awk -F '"' '/"tag_name"/ {print $4; exit}' <<<"$release_json")"
if [[ -z "$version" ]]; then
  echo "Failed to read latest release version." >&2
  exit 1
fi

asset_url="$(awk -F '"' '/"browser_download_url"/ && /hugo_extended_.*_linux-'"$arch"'\.deb/ {print $4; exit}' <<<"$release_json")"
if [[ -z "$asset_url" ]]; then
  echo "Failed to find hugo_extended .deb for architecture: $arch" >&2
  exit 1
fi

deb_file="${asset_url##*/}"

echo "Latest release: ${version}"
echo "Downloading: ${deb_file}"
curl -fL --retry 3 --retry-delay 2 -o "$deb_file" "$asset_url"

# Optional checksum verification when checksums.txt exists in latest release.
checksums_url="$(awk -F '"' '/"browser_download_url"/ && /checksums\.txt/ {print $4; exit}' <<<"$release_json")"
if [[ -n "$checksums_url" ]]; then
  echo "Downloading checksums.txt for verification ..."
  curl -fL --retry 3 --retry-delay 2 -o checksums.txt "$checksums_url"

  if awk '{print $2}' checksums.txt | grep -qx "$deb_file"; then
    echo "Verifying checksum ..."
    grep "  $deb_file$" checksums.txt | sha256sum -c -
  else
    echo "checksums.txt does not include ${deb_file}; skipping verification."
  fi
else
  echo "checksums.txt not found in latest release; skipping verification."
fi

echo "Installing ${deb_file} with apt ..."
sudo apt install -y "./$deb_file"

echo "Installed Hugo:"
hugo version

echo "Done."

これについては，私は1行も触っていない。

手順としては

インストールするマシンのアーキテクチャを確認して対応する .deb ファイルをダウンロードする
可能ならチェックサムの検証も行う
ダウンロードした .deb ファイルを apt install コマンドでインストールする

という感じ。

これを実行して Hugo を更新した後，ブログのビルドを行い，ビルド前後の差分を調べて問題がないことを確認する。問題がなければビルドしたものを commit & push させる。

「問題がないことを確認する」の部分は私が判断しているので完全な自動化ではないが，今のところ問題は起きていない。

GitHub Copilot はシェル芸達者

という感じで緩々と GitHub Copilot を使っている。

今回の一連で意外とシェル芸達者なのが分かったので，自宅機に CLI 版を入れようかなぁ。でも，結城浩さんほど使い倒す勇気はないんだよなぁ。それよりもローカル LLM 構築に向けて環境を整えるほうが先か？

参考

フルスクラッチから1日でCMSを作る_シェルスクリプト高速開発手法入門改訂2版 (アスキードワンゴ): 上田隆一 (著), 後藤大地 (著), ＵＳＰ研究所 (監修); ドワンゴ 2019-07-05 (Release 2019-07-05); Kindle版; B07TSZZPWN (ASIN); 評価

既存の常識に凝り固まったソフトウェア・エンジニアに「痛恨の一撃」を加える快書もしくは怪書。

reviewed by Spiegel on 2014-09-21 (powered by PA-APIv5)

ブログを Fediverse & Atmosphere に参加させる

2026-03-23T11:42:41+00:00

随分前に Bridgy Fed を利用して Bluesky と Mastodon を相互接続させる方法を紹介したが，同じサービスを使ってブログなどの Web サイト（の更新）を Bluesky/Atmosphere および Mastodon/Fediverse と連携させることが出来るようだ。

graph LR Website["Web site"] BridgyFed(("Bridgy Fed")) Mastodon["Mastodon (Fediverse)"] Bluesky["Bluesky (Atmosphere)"] Website-->BridgyFed BridgyFed-->Mastodon BridgyFed-->Bluesky

Federation with Bridgy Fed

登録自体は簡単で，以下のページでブログの URL を入力するだけ。

via Enter a web site to bridge:

成功すれば以下の画面に遷移する。

via text.baldanders.info profile - Bridgy Fed

RSS フィードを備えているサイトであれば問題なく登録できるはず。サイトの登録は誰でもどのサイトでもできる。勝手に登録されてしまい取り消したいのであれば，オプトアウトの手続きを行う必要がある。

If you’re on the web, email us from an address at your web site’s domain to show that you own it, or you can put the text #nobridge in the profile on your home page and then update your profile on your user page.

via How do I opt out and remove my site or account?

初期状態では Bluesky ハンドルは @yourdomain.com.web.brid.gy に， Mastodon ハンドルは @yourdomain@web.brid.gy になっている。

たとえばサイトのドメインが text.baldanders.info であれば，それぞれ

@text.baldanders.info.web.brid.gy (Bluesky)
@text.baldanders.info@web.brid.gy (Mastodon)

となる。

このうち Bluesky ハンドルはサイトのドメイン名に変更可能である。変更方法は以前書いた記事を参照のこと。 DNS の TXT レコードまたは /.well-known/atproto-did ファイルに DID を設置すれば勝手に更新してくれるみたい。

ちなみに，ここのブログのように GitHub Pages で独自ドメインにしている場合は DNS の TXT レコードが使えないため /.well-known/atproto-did ファイルに DID を書いて設置した。この場合 /_config.yml ファイルに以下の記述を追加する必要がある。

include: [".well-known"]

最終的には以下のハンドル名になった。

@text.baldanders.info

via text.baldanders.info - PDSls

Mastodon ハンドル名の web.brid.gy の部分を独自ドメインに変えることもできるようだが，このブログではメリットが薄い（かえってハンドル名が長くなる）のでやらないかな。

Fediverse の各サービスや Bluesky 等とやり取りするために IndieWeb や Webmention が推奨されているみたいだが，これは後日調査して可能なら対応するか。

今回はここまで。

ブックマーク

Using Web Mentions in a static site (Hugo) | Modern Web Development with Chrome
このブログがFediverseに対応しました
Bridgy-Fedのまとめ
Webmention.io
Long-Form Comes To Bridgy Fed : Bridgy Fed が長文ドキュメント用の Standard.site に対応

AT Protocol & ActivityPub 関連サービスの利用について

2026-03-06T02:36:06+00:00

ATProto/Atmosphere 関連サービス

AT Protocol ベースのサービスをいくつか試しているが，そろそろ覚えきれなくなってきたので，整理のためにここでまとめておく。

サービス	アカウント等	備考
Bluesky	`@baldanders.info`	メインアカウント (PDSls)
`@fanapod.baldanders.info`	非公式 APOD 配信ボット (PDSls)
`@crawler.baldanders.info`	Web クローラーボット (PDSls)
`@photos.baldanders.info`	お散歩カメラ, 実験用 (PDSls)
`@goark.bsky.social`	開発・実験用 (PDSls)
Pckt	お散歩カメラ	ブログ, photosアカウント使用
Streamplace	@baldanders.info	動画配信, メインアカウント使用
Leaflet	お散歩カメラ	ブログ（休眠中）, メインアカウント使用
TriLinesAt	—	三行日記（休眠中）, メインアカウント使用
Skyreader	—	休眠中, メインアカウント使用

他にも面白そうなサービスが色々と登場しているので，これからも増えていくかも知れない。自作ツールで bsky.social 以外の PDS で Bluesky の API を使えるようになれば pckt.cafe とかも使いやすくなるのだが… この辺は調査中。

ActivityPub/Fediverse 関連サービス

ついでに，私が利用している ActivityPub/Fediverse 関連サービスも挙げておく。といっても今のところは Mastodon しか使ってないのだが。

サービス	アカウント等	備考
Goark	`@spiegel@goark.fedicity.net`	メインアカウント
`@osanpo@goark.fedicity.net`	Web クローラーボット
`@goark@goark.fedicity.net`	開発・実験用, 今のところボット運用
Fedibird	`@spiegel@fedibird.com`	予備系
mstdn.jp	`@spiegel@mstdn.jp`	休眠中

PixcelFed も気になっているのだが，これも API とかどうなってるんだろうと踏み出せてない。まぁ Mastodon が問題なく使えてるので優先順位は低め。

Bridgy Fed 連携

Bridgy Fed は Bluesky や Mastodon 等の ActivityPub 連合（Fediverse）を連携させるサービスで，現在 Bluesky → Fediverse と Fediverse → Bluesky のブリッヂが提供されている。また Web サイトを Bluesky や Fediverse へ参加させる機能も提供されている。

Bridgy Fed について詳しくはドキュメントを参照のこと。ここでは本サイトで提供している Bridgy Fed 連携の設定を挙げておく。

Bluesky → Fediverse

graph LR BridgyFed(("Bridgy Fed")) Bluesky["Bluesky"] Mastodon["Fediverse\n(Mastodon, ...)"] Bluesky e2@--> BridgyFed BridgyFed e1@--> Mastodon e1@{ animate: true } e2@{ animate: true }

Bluesky	Fediverse
`@baldanders.info`	`@baldanders.info@bsky.brid.gy`
`@fanapod.baldanders.info`	`@fanapod.baldanders.info@bsky.brid.gy`

Mastodon → Bluesky

graph LR BridgyFed(("Bridgy Fed")) Bluesky["Bluesky\n(and Atmosphere)"] Mastodon["Mastodon"] Mastodon e1@--> BridgyFed BridgyFed e2@--> Bluesky e1@{ animate: true } e2@{ animate: true }

Mastodon	Bluesky
`@spiegel@goark.fedicity.net`	`@mstdn.baldanders.info` (PDSls)

※ @mstdn.baldanders.info アカウントは認証には使えない。

Web → Bluesky & Fediverse

graph LR Website["Web site"] BridgyFed(("Bridgy Fed")) Bluesky["Bluesky\n(and Atmosphere)"] Mastodon["Fediverse\n(Mastodon, ...)"] Website e1@--> BridgyFed BridgyFed e2@-->Mastodon BridgyFed e3@-->Bluesky e1@{ animate: true } e2@{ animate: true } e3@{ animate: true }

Web site	Fediverse / Bluesky
`text.baldanders.info`	`@text.baldanders.info@web.brid.gy`
`@text.baldanders.info` (PDSls)

※ @text.baldanders.info アカウントは認証には使えない。

ブックマーク

Mastodon/Bluesky で共有するためのボタンを追加・更新

2026-02-26T06:32:46+00:00

そろそろ重い腰をあげようかな，ということで。

このブログ各記事ページの右上には共有のためのボタンがある（目立たないようにわざと小さくしているが）。今まで Bluesky の共有ボタンを付けてなかったのだが，今回これを追加した。ボタンに対応する URL の組み立ては以下の公式ドキュメントを参考にした。

Action Intent Links | Bluesky

ついでに Mastodon の共有ボタンも更新した。第三者サービスを経由してポストするのはそろそろやめようかなと思って（信用してないわけじゃないけど）。参考にしたのは以下の記事。

サイトに「Mastodonで共有」ボタンを設置する。 - freefielder.jp

このページで公開している CSS および JavaScript コードをそのまま使わせてもらった。権利の帰属先および利用ライセンスはこちら。

ありがたや 🙇

なお Pocket への共有ボタンは外した。私が使わなくなったので。はてなへの共有ボタンも付けない。そもそもはてなのアカウント持ってないしな。

Amazon PA-API にアクセスできなくなった

2025-11-17T09:15:09+00:00

先日から Amazon の PA-API (Product Advertising API) にアクセスできなくて困っている。なんか 403 が返ってくるんだよな。 API で何か破壊的変更でもあったのかと PA-API のサイトを見てみるも，それらしい情報が見当たらず途方に暮れていたのだが…

AmazonのPA-APIでエラー発生！こっそり規約が変更されていた！？ | 忘れられたおもちゃ部屋

によると（引用の引用でゴメン）

お調べいたしましたところ、11月12日からポリシーが変更となり、PA-APIへのアクセスは過去30日以内に10件の的確な売上(10件の注文)を発生させていただく必要があることが確認できました。

こちら当プログラムサイト上ではまだお知らせ等が間に合っておりませんが、随時更新させていただきます。

AmazonのPA-APIでエラー発生！こっそり規約が変更されていた！？より

なんじゃそらぁ (╯°□°）╯︵ ┻━┻

いやまじかんべんしてください。

このサイトは確かにアソシエイトプログラムに参加しているけど，アフィリエイト目的のサイトじゃない。書影とか商品画像を合法的に使いたくて PA-API を使っているだけで，売上件数も微々たるもの。年に数回 Amazon ギフトもらって「これでマンガ単行本が1冊余分に買える」とか細やかに喜んでるレベルの運用なのよ。月に1件でも危ない時があったのに，10件以上とか絶対無理無理無理！

これはもう Amazon を頼るのは駄目かもしれん。他の方法を考えないと。

…と考えて，そういえば今どきは出版社の書籍紹介ページの OGP イメージで書影を使ったりするよな。ということは，別に Amazon のサービスを使わなくても画像を含むリンクカードを生成する仕組みを作ればいいのか。うーん，この線で考えてみよう。

他にも

Amazon SP-API有料化の真相。SaaS依存のリスクと内製化という次の一手 | EC・ネット通販を中心とした物販ビジネス専門メディア「コマースピック」

なんてな話もあるようで¹，自前で管理システムを構築できない企業などはしんどいことになりそうだ。まぁ，かつての「ロングテール理論」とか今のインターネット老人が若き日の妄想だったということかな。

ブックマーク

PA-API v5 への移行
goark/pa-api: APIs for Amazon Product Advertising API v5 by Golang : このパッケージは皆さまからの PR で運用されています（笑）

SP-API は Seller Partner API のことで， Amazon に出品している商品の管理をするための API らしい。実際には間にサードパーティの SaaS サービスが入ることが多いそうで，それら SaaS サービスに対して2026年から料金が発生するよってことのようだ。最終的にその費用はエンドユーザが負担することになるんだろうけど。 ↩︎

変体仮名をサポートした

2025-10-03T04:08:59+00:00

昨年の古い話題になるのだが Google NOTO フォントが変体仮名¹ をリリースした。

というわけで変体仮名を Web フォントとして組み込むことができる。このサイトでの設定はこんな感じ。

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=BIZ+UDGothic:wght@400;700&family=BIZ+UDMincho:wght@400;700&family=Intel+One+Mono:wght@400;700&family=Noto+Color+Emoji&family=Noto+Sans:wght@400;700&family=Noto+Serif+Hentaigana:wght@400;700&family=Noto+Serif:wght@400;700&display=swap" rel="stylesheet">

これで CSS の font-family に 'Noto Serif Hentaigana' を追加すればよい。

body {
  font-family: 'Noto Serif', 'BIZ UDMincho', 'Noto Serif Hentaigana', serif;
}

ちょっと表示させてみよう。以前「Unicode のカタカナを調べる」で書いたコードを流用して Unicode で変体仮名を含む仮名補助（Kana Supplement; U+1B000 - U+1B0FF）および仮名拡張A（Kana Extended-A; U+1B100 – U+1B12F）を列挙してみる。こんな感じ。

package main

import (
    "fmt"
    "unicode"
)

func main() {
    i := 0
    for c := rune(0x1b000); c <= rune(0x1b12f); c++ {
        if unicode.In(c, unicode.Hiragana) || unicode.In(c, unicode.Katakana) {
            fmt.Printf("%#U ", c)
            i++
            i &= 0x0f
            if i == 0 {
                fmt.Println()
            }
        }
    }
    fmt.Println()
}

実行結果は以下の通り。

$ go run main.go
U+1B000 '𛀀' U+1B001 '𛀁' U+1B002 '𛀂' U+1B003 '𛀃' U+1B004 '𛀄' U+1B005 '𛀅' U+1B006 '𛀆' U+1B007 '𛀇' U+1B008 '𛀈' U+1B009 '𛀉' U+1B00A '𛀊' U+1B00B '𛀋' U+1B00C '𛀌' U+1B00D '𛀍' U+1B00E '𛀎' U+1B00F '𛀏' 
U+1B010 '𛀐' U+1B011 '𛀑' U+1B012 '𛀒' U+1B013 '𛀓' U+1B014 '𛀔' U+1B015 '𛀕' U+1B016 '𛀖' U+1B017 '𛀗' U+1B018 '𛀘' U+1B019 '𛀙' U+1B01A '𛀚' U+1B01B '𛀛' U+1B01C '𛀜' U+1B01D '𛀝' U+1B01E '𛀞' U+1B01F '𛀟' 
U+1B020 '𛀠' U+1B021 '𛀡' U+1B022 '𛀢' U+1B023 '𛀣' U+1B024 '𛀤' U+1B025 '𛀥' U+1B026 '𛀦' U+1B027 '𛀧' U+1B028 '𛀨' U+1B029 '𛀩' U+1B02A '𛀪' U+1B02B '𛀫' U+1B02C '𛀬' U+1B02D '𛀭' U+1B02E '𛀮' U+1B02F '𛀯' 
U+1B030 '𛀰' U+1B031 '𛀱' U+1B032 '𛀲' U+1B033 '𛀳' U+1B034 '𛀴' U+1B035 '𛀵' U+1B036 '𛀶' U+1B037 '𛀷' U+1B038 '𛀸' U+1B039 '𛀹' U+1B03A '𛀺' U+1B03B '𛀻' U+1B03C '𛀼' U+1B03D '𛀽' U+1B03E '𛀾' U+1B03F '𛀿' 
U+1B040 '𛁀' U+1B041 '𛁁' U+1B042 '𛁂' U+1B043 '𛁃' U+1B044 '𛁄' U+1B045 '𛁅' U+1B046 '𛁆' U+1B047 '𛁇' U+1B048 '𛁈' U+1B049 '𛁉' U+1B04A '𛁊' U+1B04B '𛁋' U+1B04C '𛁌' U+1B04D '𛁍' U+1B04E '𛁎' U+1B04F '𛁏' 
U+1B050 '𛁐' U+1B051 '𛁑' U+1B052 '𛁒' U+1B053 '𛁓' U+1B054 '𛁔' U+1B055 '𛁕' U+1B056 '𛁖' U+1B057 '𛁗' U+1B058 '𛁘' U+1B059 '𛁙' U+1B05A '𛁚' U+1B05B '𛁛' U+1B05C '𛁜' U+1B05D '𛁝' U+1B05E '𛁞' U+1B05F '𛁟' 
U+1B060 '𛁠' U+1B061 '𛁡' U+1B062 '𛁢' U+1B063 '𛁣' U+1B064 '𛁤' U+1B065 '𛁥' U+1B066 '𛁦' U+1B067 '𛁧' U+1B068 '𛁨' U+1B069 '𛁩' U+1B06A '𛁪' U+1B06B '𛁫' U+1B06C '𛁬' U+1B06D '𛁭' U+1B06E '𛁮' U+1B06F '𛁯' 
U+1B070 '𛁰' U+1B071 '𛁱' U+1B072 '𛁲' U+1B073 '𛁳' U+1B074 '𛁴' U+1B075 '𛁵' U+1B076 '𛁶' U+1B077 '𛁷' U+1B078 '𛁸' U+1B079 '𛁹' U+1B07A '𛁺' U+1B07B '𛁻' U+1B07C '𛁼' U+1B07D '𛁽' U+1B07E '𛁾' U+1B07F '𛁿' 
U+1B080 '𛂀' U+1B081 '𛂁' U+1B082 '𛂂' U+1B083 '𛂃' U+1B084 '𛂄' U+1B085 '𛂅' U+1B086 '𛂆' U+1B087 '𛂇' U+1B088 '𛂈' U+1B089 '𛂉' U+1B08A '𛂊' U+1B08B '𛂋' U+1B08C '𛂌' U+1B08D '𛂍' U+1B08E '𛂎' U+1B08F '𛂏' 
U+1B090 '𛂐' U+1B091 '𛂑' U+1B092 '𛂒' U+1B093 '𛂓' U+1B094 '𛂔' U+1B095 '𛂕' U+1B096 '𛂖' U+1B097 '𛂗' U+1B098 '𛂘' U+1B099 '𛂙' U+1B09A '𛂚' U+1B09B '𛂛' U+1B09C '𛂜' U+1B09D '𛂝' U+1B09E '𛂞' U+1B09F '𛂟' 
U+1B0A0 '𛂠' U+1B0A1 '𛂡' U+1B0A2 '𛂢' U+1B0A3 '𛂣' U+1B0A4 '𛂤' U+1B0A5 '𛂥' U+1B0A6 '𛂦' U+1B0A7 '𛂧' U+1B0A8 '𛂨' U+1B0A9 '𛂩' U+1B0AA '𛂪' U+1B0AB '𛂫' U+1B0AC '𛂬' U+1B0AD '𛂭' U+1B0AE '𛂮' U+1B0AF '𛂯' 
U+1B0B0 '𛂰' U+1B0B1 '𛂱' U+1B0B2 '𛂲' U+1B0B3 '𛂳' U+1B0B4 '𛂴' U+1B0B5 '𛂵' U+1B0B6 '𛂶' U+1B0B7 '𛂷' U+1B0B8 '𛂸' U+1B0B9 '𛂹' U+1B0BA '𛂺' U+1B0BB '𛂻' U+1B0BC '𛂼' U+1B0BD '𛂽' U+1B0BE '𛂾' U+1B0BF '𛂿' 
U+1B0C0 '𛃀' U+1B0C1 '𛃁' U+1B0C2 '𛃂' U+1B0C3 '𛃃' U+1B0C4 '𛃄' U+1B0C5 '𛃅' U+1B0C6 '𛃆' U+1B0C7 '𛃇' U+1B0C8 '𛃈' U+1B0C9 '𛃉' U+1B0CA '𛃊' U+1B0CB '𛃋' U+1B0CC '𛃌' U+1B0CD '𛃍' U+1B0CE '𛃎' U+1B0CF '𛃏' 
U+1B0D0 '𛃐' U+1B0D1 '𛃑' U+1B0D2 '𛃒' U+1B0D3 '𛃓' U+1B0D4 '𛃔' U+1B0D5 '𛃕' U+1B0D6 '𛃖' U+1B0D7 '𛃗' U+1B0D8 '𛃘' U+1B0D9 '𛃙' U+1B0DA '𛃚' U+1B0DB '𛃛' U+1B0DC '𛃜' U+1B0DD '𛃝' U+1B0DE '𛃞' U+1B0DF '𛃟' 
U+1B0E0 '𛃠' U+1B0E1 '𛃡' U+1B0E2 '𛃢' U+1B0E3 '𛃣' U+1B0E4 '𛃤' U+1B0E5 '𛃥' U+1B0E6 '𛃦' U+1B0E7 '𛃧' U+1B0E8 '𛃨' U+1B0E9 '𛃩' U+1B0EA '𛃪' U+1B0EB '𛃫' U+1B0EC '𛃬' U+1B0ED '𛃭' U+1B0EE '𛃮' U+1B0EF '𛃯' 
U+1B0F0 '𛃰' U+1B0F1 '𛃱' U+1B0F2 '𛃲' U+1B0F3 '𛃳' U+1B0F4 '𛃴' U+1B0F5 '𛃵' U+1B0F6 '𛃶' U+1B0F7 '𛃷' U+1B0F8 '𛃸' U+1B0F9 '𛃹' U+1B0FA '𛃺' U+1B0FB '𛃻' U+1B0FC '𛃼' U+1B0FD '𛃽' U+1B0FE '𛃾' U+1B0FF '𛃿' 
U+1B100 '𛄀' U+1B101 '𛄁' U+1B102 '𛄂' U+1B103 '𛄃' U+1B104 '𛄄' U+1B105 '𛄅' U+1B106 '𛄆' U+1B107 '𛄇' U+1B108 '𛄈' U+1B109 '𛄉' U+1B10A '𛄊' U+1B10B '𛄋' U+1B10C '𛄌' U+1B10D '𛄍' U+1B10E '𛄎' U+1B10F '𛄏' 
U+1B110 '𛄐' U+1B111 '𛄑' U+1B112 '𛄒' U+1B113 '𛄓' U+1B114 '𛄔' U+1B115 '𛄕' U+1B116 '𛄖' U+1B117 '𛄗' U+1B118 '𛄘' U+1B119 '𛄙' U+1B11A '𛄚' U+1B11B '𛄛' U+1B11C '𛄜' U+1B11D '𛄝' U+1B11E '𛄞' U+1B11F '𛄟' 
U+1B120 '𛄠' U+1B121 '𛄡' U+1B122 '𛄢'

皆さんの環境では見えるだろうか。

ちなみに U+1B000 (𛀀) および U+1B001 (𛀁) は Unicode 6 で “Historic Katakana” および “Historic Hiragana” として収録されたそうで，これまでの NOTO 日本語フォント等で表示できる。また U+1B120 (𛄠), U+1B121 (𛄡), U+1B122 (𛄢) は “Historic Katakana” として Unicode 14 で追加されたそうだ。

同じく Unicode 14 で追加された U+1B11F は表示されないのか？いや U+1B11F は “Historic Hiragana” に分類されているから “Hentaigana” ではないという判定なのかな？でもでも，上述の “Historic Katakana” は U+1B122 まで表示できるんだよな。うーむ，よく分からん。

まっ，細かいことは置いておいて，例として蕎麦屋の看板や暖簾に書かれている変体仮名「𛁛𛂦゙」を挙げてみる。あれって元は「楚（そ）」「者（は）」なんだそうで

楚 → 𛁛 (U+1B05B)
者 → 𛂦゙ (U+1B0A6 + U+3099; 濁点が付いてる)

ってな感じらしい。勉強になりました。

「変体仮名一覧」に変体仮名の各文字に対応する読みと元になる漢字を表にまとめてみた。参考にどうぞ。 𛂙（乃）や 𛃀（本）といった文字は今でもたまに見かける。そういえば，花札の赤短に書かれている「あかよろし²」の「か」は変体仮名で「𛀙（可）」と表記されているため，つい「あのよろし」とか読んでしまう（笑）こんな感じで変体仮名がしれっと紛れていることがあるので油断できない。

ブックマーク

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

著者のひとりは（あの「バイブル」とも呼ばれる）通称 “K&R” の K のほうである。この本は Go 言語の教科書と言ってもいいだろう。と思ったら絶版状態らしい（2025-01 現在）。復刊を望む！

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

変体仮名とは，簡単に言うと仮名の異体字のこと。変体仮名は明治時代に廃止されたが，店の看板などで依然使われている。コンピュータ・システムでは，地名や古い戸籍の人名などで使われていることがあるそうで「住民基本台帳収録変体仮名」として一部の変体仮名が運用されていたらしい。その後 Unicode 10 から本格的に変体仮名がサポートされるようになった。フォントとしては「IPAmj明朝フォント」が変体仮名を含む異体字を幅広くカバーしている。 ↩︎
「あかよろし」は「めっちゃいい！」くらいの意味（笑） ↩︎

text.Baldanders[.]info 10周年

2025-10-01T08:51:20+00:00

このブログサイトを正式にオープンしてからちょうど10年が経った。

text.Baldanders.info 正式オープン

日記やブログのツール・サービスに関しては割と頻繁に乗り換えているのだが，単一のツールでは2番目に長続きしている。我が事ながら Hugo ＋ GitHub Pages という組み合わせは性に合ってるらしい。

前のブログは11年続いたのが，このブログを再来年まで続ければ最長不到記録に至る。いつまで続けられるかねぇ。ともかく，これまでどおり「書きたくないときには書かない」「他人の評価など気にしない」というスタンスで緩々とやって行く所存である。

あっ，今回は「自分にご褒美」とか特にないっス。今年は色々と節目の年なのでそれどころじゃないっちうか…

ブックマーク

Intel One Mono フォントに換装する

2025-09-16T03:31:07+00:00

五十路に入ってからから近視・乱視・老眼の三重苦になり，2種類の眼鏡を使い分けてるのだが，特にモニタでプログラム・コードを読むのがしんどくなりつつある。

というところで以下の記事を見かけた。

Intelが開発したフォント「Intel One Mono」、目が悪くても読みやすいコーディング向けフォント【レビュー】 - 窓の杜

ひょっとしてこれは私向きか？

via intel/intel-one-mono: Intel One Mono font repository

私は古い人間なので，ゼロは “$\emptyset$” (empty set) みたいに斜線が入ってないと嫌なのよ（だから今までずっと Inconsolata を使っていた）。数字の 1 と大文字の I と小文字の l，小文字の i と j の区別も分かりやすいし，記号類もデフォルメされてる感じで見やすい。これならイケそうかな。早速ローカルにインストールしてみよう。

リポジトリのリリースページにある最新版の otf.zip (zip 圧縮されている) を取ってくる。 Ubuntu の場合は，展開して取得した *.otf ファイルを全て /usr/local/share/fonts/ または ~/.local/share/fonts/ ディレクトリに放り込めばOK。その後

$ fc-cache -fv

でフォントキャッシュを更新するのを忘れないように。上手くインストールできれば

$ fc-list | grep Intel
/usr/local/share/fonts/IntelOneMono-Light.otf: Intel One Mono,Intel One Mono Light:style=Light,Regular
/usr/local/share/fonts/IntelOneMono-Italic.otf: Intel One Mono:style=Italic
/usr/local/share/fonts/IntelOneMono-Medium.otf: Intel One Mono,Intel One Mono Medium:style=Medium,Regular
/usr/local/share/fonts/IntelOneMono-Regular.otf: Intel One Mono:style=Regular
/usr/local/share/fonts/IntelOneMono-MediumItalic.otf: Intel One Mono,Intel One Mono Medium:style=Medium Italic,Italic
/usr/local/share/fonts/IntelOneMono-LightItalic.otf: Intel One Mono,Intel One Mono Light:style=Light Italic,Italic
/usr/local/share/fonts/IntelOneMono-Bold.otf: Intel One Mono:style=Bold
/usr/local/share/fonts/IntelOneMono-BoldItalic.otf: Intel One Mono:style=Bold Italic

みたいな感じにリスト表示できる。

VS Code で Intel One Mono フォントを使うには “Font Family” 項目で

Font Family の設定例

という感じに 'Intel One Mono' または 'Intel One Mono Medium' を最初に指定すればよい。 VS Code は複数フォントを（並び順で優先順位を決めて）指定できるのが嬉しい。

リポジトリを見ると現在最新の V1.4.0 のリリースは 2024-07-26 らしい。これって Google Fonts にも収録されている？と思って探したらありました。

Intel One Mono - Google Fonts

ってことは，Web フォントとしても使えるってことか。このブログサイトでの設定は以下のようにしてみた。

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=BIZ+UDGothic:wght@400;700&family=BIZ+UDMincho:wght@400;700&family=Intel+One+Mono:ital,wght@0,300..700;1,300..700&family=Noto+Color+Emoji&family=Noto+Sans:ital,wght@0,100..900;1,100..900&family=Noto+Serif:wght@100..900&display=swap" rel="stylesheet">

試しに何かコードを表示してみよう。今年の始めに紹介した2025年の干支を求める Go プログラムを表示してみる。

package main

import (
    "fmt"

    "github.com/goark/koyomi/zodiac"
)

func main() {
    year := 2025
    干, 支 := zodiac.ZodiacYearNumber(year)
    fmt.Printf("%d年は%v%v，恵方は%v (%v°)", year, 干, 支, 干.DirectionJp(), 干.Direction())
}

2025年も心臓リハビリ＠がんばらないより

上手く表示できてるかな。皆さんの環境ではどうだろう。

括弧などの記号が見やすいのがよい。エディタと Web フォントは Intel One Mono でいこう。私文書は Inconsolata のままでいいかな。そもそも紙（含PDF）に書くような文書でコードを書くことは少ないしな。

ブックマーク

OpenPGP 公開鍵を新しくした

2025-03-30T12:03:33+00:00

OpenPGP 公開鍵を新しくした

昨年，ようやく Ubuntu 内の GnuPG が 2.4 系に上がったので，いよいよ OpenPGP 公開鍵を新しくすることにした。新しい鍵は本家サイトの以下のページにある。

OpenPGP 公開鍵リスト

最初「来年からまた短期の運用に戻そう」と思っていた。ここ3年間，有効期限の延長しかしてないけど… 正直ダルい。というわけで2030年までの長期運用にした。なぜ無期限にしなかったのかについては後述する。

OpenPGP 鍵作成手順

今回は

証明専用の主鍵を作成する
署名用の副鍵を作成する
暗号用の副鍵を作成する

という3ステップで作成した¹。

まずは主鍵の作成²：

$ gpg --full-gen-key --expert
gpg (GnuPG) 2.4.4; Copyright (C) 2024 g10 Code GmbH
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

ご希望の鍵の種類を選択してください:
   (1) RSA と RSA
   (2) DSA と Elgamal
   (3) DSA (署名のみ)
   (4) RSA (署名のみ)
   (7) DSA (機能をあなた自身で設定)
   (8) RSA (機能をあなた自身で設定)
   (9) ECC (署名と暗号化) *デフォルト
  (10) ECC (署名のみ)
  (11) ECC (機能をあなた自身で設定)
  (13) 既存の鍵
  (14) カードに存在する鍵
あなたの選択は? 11

このECC鍵にありうる操作: Sign Certify Authenticate
現在の認められた操作: Sign Certify

   (S) 署名機能を反転する
   (A) 認証機能を反転する
   (Q) 完了

あなたの選択は? s

このECC鍵にありうる操作: Sign Certify Authenticate
現在の認められた操作: Certify

   (S) 署名機能を反転する
   (A) 認証機能を反転する
   (Q) 完了

あなたの選択は? q
ご希望の楕円曲線を選択してください:
   (1) Curve 25519 *デフォルト
   (2) Curve 448
   (3) NIST P-256
   (4) NIST P-384
   (5) NIST P-521
   (6) Brainpool P-256
   (7) Brainpool P-384
   (8) Brainpool P-512
   (9) secp256k1
あなたの選択は? 1
鍵の有効期限を指定してください。
         0 = 鍵は無期限
      <n>  = 鍵は n 日間で期限切れ
      <n>w = 鍵は n 週間で期限切れ
      <n>m = 鍵は n か月間で期限切れ
      <n>y = 鍵は n 年間で期限切れ
鍵の有効期間は? (0) 1828
鍵は2030年04月01日 13時21分30秒 JSTで期限切れとなります
これで正しいですか? (y/N) y

GnuPGはあなたの鍵を識別するためにユーザIDを構成する必要があります。

本名: Spiegel
電子メール・アドレス: spiegel@example.com
コメント: main
次のユーザIDを選択しました:
    "Spiegel (main) <spiegel@example.com>"

名前(N)、コメント(C)、電子メール(E)の変更、またはOK(O)か終了(Q)? o

...

GnuPG 2.4 系では EdDSA が既定になった³。楕円曲線に Curve 25519 または Curve 448 を選択すれば EdDSA にできる。

署名用の副鍵の作成：

$ gpg --edit-key --expert 1A69C1BE7345EDF6EF52B2EE21FD7CE9BC554D13
gpg (GnuPG) 2.4.4; Copyright (C) 2024 g10 Code GmbH
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

秘密鍵が利用できます。

gpg: 信用データベースの検査
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: 深さ: 0  有効性:   4  署名:   4  信用: 0-, 0q, 0n, 0m, 0f, 4u
gpg: 深さ: 1  有効性:   4  署名:   0  信用: 2-, 0q, 0n, 1m, 1f, 0u
gpg: 次回の信用データベース検査は、2025-04-01です
sec  ed25519/21FD7CE9BC554D13
     作成: 2025-03-30  有効期限: 2030-04-01  利用法: C
     信用: 究極        有効性: 究極
[  究極  ] (1). Spiegel (main) <spiegel@example.com>

gpg> addkey
ご希望の鍵の種類を選択してください:
   (3) DSA (署名のみ)
   (4) RSA (署名のみ)
   (5) Elgamal (暗号化のみ)
   (6) RSA (暗号化のみ)
   (7) DSA (機能をあなた自身で設定)
   (8) RSA (機能をあなた自身で設定)
  (10) ECC (署名のみ)
  (11) ECC (機能をあなた自身で設定)
  (12) ECC (暗号化のみ)
  (13) 既存の鍵
  (14) カードに存在する鍵
あなたの選択は? 10
ご希望の楕円曲線を選択してください:
   (1) Curve 25519 *デフォルト
   (2) Curve 448
   (3) NIST P-256
   (4) NIST P-384
   (5) NIST P-521
   (6) Brainpool P-256
   (7) Brainpool P-384
   (8) Brainpool P-512
   (9) secp256k1
あなたの選択は? 1
鍵の有効期限を指定してください。
         0 = 鍵は無期限
      <n>  = 鍵は n 日間で期限切れ
      <n>w = 鍵は n 週間で期限切れ
      <n>m = 鍵は n か月間で期限切れ
      <n>y = 鍵は n 年間で期限切れ
鍵の有効期間は? (0) 1828
鍵は2030年04月01日 13時27分57秒 JSTで期限切れとなります
これで正しいですか? (y/N) y
本当に作成しますか? (y/N) y

...

今回は gpg --edit-key コマンドで対話モードを起動し addkey コマンドで署名鍵を追加している⁴。署名鍵も EdDSA で作成する。

さくさく行こう。次は暗号用の副鍵の作成：

gpg> addkey
ご希望の鍵の種類を選択してください:
   (3) DSA (署名のみ)
   (4) RSA (署名のみ)
   (5) Elgamal (暗号化のみ)
   (6) RSA (暗号化のみ)
   (7) DSA (機能をあなた自身で設定)
   (8) RSA (機能をあなた自身で設定)
  (10) ECC (署名のみ)
  (11) ECC (機能をあなた自身で設定)
  (12) ECC (暗号化のみ)
  (13) 既存の鍵
  (14) カードに存在する鍵
あなたの選択は? 12
ご希望の楕円曲線を選択してください:
   (1) Curve 25519 *デフォルト
   (2) Curve 448
   (3) NIST P-256
   (4) NIST P-384
   (5) NIST P-521
   (6) Brainpool P-256
   (7) Brainpool P-384
   (8) Brainpool P-512
   (9) secp256k1
あなたの選択は? 1
鍵の有効期限を指定してください。
         0 = 鍵は無期限
      <n>  = 鍵は n 日間で期限切れ
      <n>w = 鍵は n 週間で期限切れ
      <n>m = 鍵は n か月間で期限切れ
      <n>y = 鍵は n 年間で期限切れ
鍵の有効期間は? (0) 1828
鍵は2030年04月01日 13時34分28秒 JSTで期限切れとなります
これで正しいですか? (y/N) y
本当に作成しますか? (y/N) y

...

EdDSA と対となるよう楕円曲線暗号（ECDH アルゴリズム）で Curve 25519 を選択する。

ついでに作成した鍵に私の眠り猫アイコンを仕込んでおく。

gpg> addphoto

あなたのフォトIDに使う画像を決めてください。画像はJPEGファイルである必
要があります。画像は公開鍵といっしょに格納される、ということを念頭にお
いておきましょう。もし大きな写真を使うと、あなたの鍵も同様に大きくなり
ます! 240x288くらいにおさまる大きさの画像は、使いよいでしょう。

フォトID用のJPEGファイル名を入力してください: /path/to/avatar.jpg
この写真は正しいですか (y/N/q)? y

...

最後に save コマンドで保存し edit モードを終了する。

OpenPGP と LibrePGP

今回の鍵の変更や拙作 gpgpdump のための調査で気がついたが OpenPGP と LibrePGP は仕様レベルで違うものらしい。

OpenPGP は2024年7月にリリースされた RFC 9580 で標準化されているが，それとは別に LibrePGP ってのがあって draft-koch-librepgp にて議論されているっぽい。

OpenPGP (RFC 9580) と LibrePGP の最大の違いはパケットバージョンで， LibrePGP が RFC 4880bis の V5 パケット仕様を引き継いでいるのに対し OpenPGP は RFC 4880bis を仕切り直した draft-ietf-openpgp-crypto-refresh の議論の中で V5 パケットを捨て V6 パケットを定義している。この違いで影響するのが楕円曲線暗号, AEAD (Authenticated Encryption with Associated Data; 認証付き暗号), 鍵指紋, および耐量子コンピュータ暗号 (Post-Quantum cryptography) である。

ちなみに耐量子コンピュータ暗号は OpenPGP 側は draft-ietf-openpgp-pqc にて LibrePGP 側は draft-koch-librepgp にて検討されている。また公開テスト中の GnuPG 2.5 系では draft-koch-librepgp 仕様ベースで耐量子コンピュータ暗号の実装を行っているようだ（確認してない）。

私は draft-ietf-openpgp-crypto-refresh で仕切り直される2021年あたりから次期 OpenPGP の議論を追い切れなくなっていて，こんなヘンテコなことになってるのに気づかなかった。 RFC 9580 の “Authors” を見ると Proton AG や Sequoia PGP の中の人が名を連ねているのに対し draft-koch-librepgp は g10 Code GmbH の Werner Koch さん（GnuPG のメイン開発者）の名前が見える。

なんか面倒臭いことになってる？

ユーザ側が OpenPGP と LibrePGP との間の差異で混乱するのは面白くないので，当面の間，以下の運用を行うことをオススメする。

V5 および V6 パケットは使わない
AEAD は使わない
耐量子コンピュータ暗号には手を出さない

パケットバージョンの組み合わせに関しては RFC 9580 で以下のように決められている。

Signing Key Version	Signature Packet Version	One-Pass Signature Packet Version	Generate?
v3	v3	v3	No
v4	v3	v3	No
v4	v4	v3	Yes
v6	v6	v6	Yes

OpenPGP 鍵および署名のバージョン

RFC 9580 では “Generate?” の項目が “Yes” の組み合わせのみ生成が許容される（“No” の組み合わせは後方互換のために残される）。この表の下から2番目の組み合わせ（v4-v4-v3）であれば GnuPG 2.4 系の通常の操作で作成・処理が可能である。

AEAD に関しては OpenPGP と LibrePGP との間に互換性はない。

GnuPG 2.4 系で新たに生成した鍵に対し gpg --edit-key コマンドを起動し選好（preferences）を showpref コマンドで確認する。

$ gpg --edit-key --expert 1A69C1BE7345EDF6EF52B2EE21FD7CE9BC554D13
gpg (GnuPG) 2.4.4; Copyright (C) 2024 g10 Code GmbH
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

秘密鍵が利用できます。

sec  ed25519/21FD7CE9BC554D13
     作成: 2025-03-30  有効期限: 2030-04-01  利用法: C
     信用: 究極        有効性: 究極
ssb  ed25519/74DCA828DC07B24C
     作成: 2025-03-30  有効期限: 2030-04-01  利用法: S
ssb  cv25519/0E25614837E634DC
     作成: 2025-03-30  有効期限: 2030-04-01  利用法: E
[  究極  ] (1). Spiegel (main) <spiegel@example.com>
[  究極  ] (2)  [jpeg image of size 5707]

gpg> showpref
[  究極  ] (1). Spiegel (main) <spiegel@example.com>
     暗号方式: AES256, AES192, AES, 3DES
     AEAD: OCB
     ダイジェスト: SHA512, SHA384, SHA256, SHA224, SHA1
     圧縮: ZLIB, BZIP2, ZIP, 無圧縮
     機能: MDC, AEAD, 鍵サーバ 修正しない
[  究極  ] (2)  [jpeg image of size 5707]
     暗号方式: AES256, AES192, AES, 3DES
     AEAD: OCB
     ダイジェスト: SHA512, SHA384, SHA256, SHA224, SHA1
     圧縮: ZLIB, BZIP2, ZIP, 無圧縮
     機能: MDC, AEAD, 鍵サーバ 修正しない

ここで機能として AEAD がリストアップされている場合は (相手が AEAD を使えるなら) AEAD を暗号化に使用する。 AEAD を使わせないようにするため OCB を除くアルゴリズムを setpref コマンドで指定する。

gpg> setpref AES256 AES192 AES SHA512 SHA384 SHA256 SHA224 ZLIB BZIP2 ZIP
優先指定の一覧を設定:
     暗号方式: AES256, AES192, AES, 3DES
     AEAD:
     ダイジェスト: SHA512, SHA384, SHA256, SHA224, SHA1
     圧縮: ZLIB, BZIP2, ZIP, 無圧縮
     機能: MDC, 鍵サーバ 修正しない
優先指定を本当に更新しますか? (y/N) y

sec  ed25519/21FD7CE9BC554D13
     作成: 2025-03-30  有効期限: 2030-04-01  利用法: C
     信用: 究極        有効性: 究極
ssb  ed25519/74DCA828DC07B24C
     作成: 2025-03-30  有効期限: 2030-04-01  利用法: S
ssb  cv25519/0E25614837E634DC
     作成: 2025-03-30  有効期限: 2030-04-01  利用法: E
[  究極  ] (1). Spiegel (main) <spiegel@example.com>
[  究極  ] (2)  [jpeg image of size 5707]

gpg> showpref
[  究極  ] (1). Spiegel (main) <spiegel@example.com>
     暗号方式: AES256, AES192, AES, 3DES
     AEAD:
     ダイジェスト: SHA512, SHA384, SHA256, SHA224, SHA1
     圧縮: ZLIB, BZIP2, ZIP, 無圧縮
     機能: MDC, 鍵サーバ 修正しない
[  究極  ] (2)  [jpeg image of size 5707]
     暗号方式: AES256, AES192, AES, 3DES
     AEAD:
     ダイジェスト: SHA512, SHA384, SHA256, SHA224, SHA1
     圧縮: ZLIB, BZIP2, ZIP, 無圧縮
     機能: MDC, 鍵サーバ 修正しない

gpg> save

最後の耐量子コンピュータ暗号についてだが OpenPGP にせよ LibrePGP にせよ，まだドラフト段階のため（公開テスト等に参加するのでなければ）急ぐ必要はない。その辺も含め2030年頃には OpenPGP と LibrePGP の歪な状況もどうにか解決してないかなぁ，と希望を込めて2030年で有効期限を切ったのであった。

この記事の内容をもう少し整理して「OpenPGP の実装」セクションにまとめる予定（予定は未定）。

ブックマーク

参考図書

暗号化プライバシーを救った反乱者たち: スティーブン・レビー (著), 斉藤隆央 (翻訳); 紀伊國屋書店 2002-02-16; 単行本; 4314009071 (ASIN), 9784314009072 (EAN), 4314009071 (ISBN); 評価

20世紀末，暗号技術の世界で何があったのか。知りたかったらこちらを読むべし！

reviewed by Spiegel on 2015-03-09 (powered by PA-APIv5)

暗号技術入門第3版　秘密の国のアリス: 結城浩 (著); SBクリエイティブ 2015-08-25 (Release 2015-09-17); Kindle版; B015643CPE (ASIN); 評価

SHA-3 や Bitcoin/Blockchain など新しい知見や技術要素を大幅追加。暗号技術を使うだけならこれ1冊でとりあえず無問題。

reviewed by Spiegel on 2015-09-20 (powered by PA-APIv5)

主鍵から署名機能を分離することで個別に有効期限を設定したりトラブルで署名鍵が（秘密鍵漏えい等で）使えなくなったときに簡単に分離できるようになる。まぁ主鍵が使えなくなったら副鍵もまとめてアウトだけど（笑）運用する際は（オリジナルのバックアップを取った上で）主鍵の秘密鍵だけ分離して使うやりかたもある。 ↩︎
gpg --quick-generate-key でコマンドライン上でユーザID，アルゴリズム，用途，有効期限を指定できる。楕円曲線暗号の場合は楕円曲線名を指定する。 ↩︎
RFC 9580 では RSA, ElGamal, DSA は deprecated になった。多分この影響で既定から外れたのだろう。なお EdDSA は NIST FIPS 186-5 にて標準のアルゴリズムになった。これで政府調達でもなんでも大手を振って EdDSA を使える。 ↩︎
gpg --quick-add-key でコマンドライン上で副鍵のアルゴリズム，用途，有効期限を指定できる。 ↩︎