貯金はいずれ使う運命にあるので、貯金はすなわち支出。だったら貯めずに今使った方が QoL 高いよ (?)

うーんやばい、テスト回したら案の定 inconsistency が発生しているのがわかる (が、汎用のコンテナは debug print が難しいのでとにかく厄介)

まあやばいなどと言いつつテストコケて安心しているわけだが (これでテスト落ちなかったらテストがクソなのを疑って永遠にテストを書き加え続ける破目になっていた)

GPG2 で keytocard するとローカルの鍵 (を表現するファイル) が smart card のシリアル番号を記録したスタブに置き換わるので

同じ鍵を2つの別々の YubiKey に入れていて前回と違う方を使う場合など、 YubiKey を接続した後で

gpg-connect-agent "scd serialno" "learn --force" /bye

してスタブ内のシリアルナンバーを今接続されているものの番号で置き換える必要があったりする

target の close 後に root が close されてないから、 target.parent は正しくリセットされていて、 parent.first_child が更新されなかった？

木構造を実装するときは depth-first traversal (open/close イベント列の出力) を最優先で実装する

はい修正できました、俺の勝ち

うーん……そうなのだろうか？

むしろ私の理解としては逆で、暗号化/復号については単一の鍵対をすべてのデバイスで共有あるいは持ち運びしなければうまくいかないと思ってた

YubiKey に暗号鍵を突っ込んだ場合、 keytocard 後の鍵ファイルはスタブなので安全に他のデバイスにコピーできるので、そのようにする

* 安全な鍵生成用マシンで鍵を生成する
* この状態の .gnupg をバックアップする
* 指を挿して keytocard する
* keytocard 後の .gnupg (あるいは最低でもスタブファイル) を普段使いマシンへ持ってくる

という感じの運用

@zundan ひとつの primary key に対して仕事用暗号化 subkey と、私用暗号化 subkey の2対を紐付けたい、みたいな感じでしょうか

うーん、なるほど

どうなんだろう

ID (primary key) をどこで切るべきかというの、たしかに悩ましい話かもしれない

たとえば会社のドメインのメールアドレスとかは私用の ID として使ったり紐付けたりするなよみたいな話はあって、まあ鍵が正当であると認める権威が誰なのみたいな文脈を考えるとそれが妥当なのはわかるんだけど。
たとえばこれがフリーランスとか自営業とかだとどうなるのというのは確かによくわからん

これ駄目なのかぁ

@zundan HOW to encrypt by a subkey(multiple subkey(e)) in GPG(GnuPG) - Stack Overflow
https://stackoverflow.com/questions/43732404/how-to-encrypt-by-a-subkeymultiple-subkeye-in-gpggnupg

subkey を指定するとき ! を最後に付けないといけないとかでは

やっぱりいけると思う、というかいけない仕様はおかしい

たぶん ! なしで指定したやつだと、その鍵そのものではなく一度 UID とかを引いてきてから使う鍵の選定フェーズに入るんじゃないですかね。
雑に public key を指定しても secret key を指定しても同じ結果になるように……みたいな理由で。

@zundan まあ encryption key を分ける動機ってデバイス単位での compromise に対応したいみたいなのが想定されている気がするので (というかそれしか聞いたことがないかも)、素朴に作るとひとつのデバイスにひとつの暗号鍵ということになりますよね。もどかしいですが……

identity を仕事用で分けるのが正攻法なのかなぁ。 OpenKeychain で複数のアイデンティティに対応してるのか知らないけど……

うーん

暗号化して送る側から考えてみると、相手の encryption subkey を適切に選択して送るというのはかなり困難だもんなぁ。 UID と違って subkey にはコメント付けられないわけだし……

となると、やっぱりアイデンティティ自体を分けるというのが正道なのか

そうっぽいな

YubiKey setup memo (2021-12-10) ($2283925) · スニペット · スニペット · GitLab
https://gitlab.com/-/snippets/2283925

mitome.out

あれ、暗号鍵対って YubiKey に入らないんだっけ……

@zundan あー、たしかに key 1 とかでサブキーを選択してなくて primary key の転送しかしてませんね……
これたぶん primary key が sign の capability を持っているから署名できてるだけで、 certify 機能しか持ってない primary key で同じ手順を踏んだら sign すらできない気がします

いやまて、そもそも certify 専用キーって YubiKey に突っ込めたっけか？

OpenPGP 鍵を3つ突っ込めるとのことなので、たぶん certify, sign, encrypt の3つ入れる想定だと思うけど……

いやわからん、 sign, encrypt, authenticate の3つか？

GPG に SSH 任せるつもりがないので authenticate 系の機能の使い方は何もわからん

SSH の鍵なんて所詮サーバ-クライアント対ごとに簡単に再生成できるものなので、気になるなら文脈ごとに軽率に鍵生成したり定期的に鍵を切り替えたりすればいいじゃんという

それに SSH 操作は署名機能と違って credential を直打ちする操作がありうるので (たとえば鯖に入ったら sudo したり何らかのサービスのパスワードを打つ可能性が十分高い)、出先のマシンでちょっと私物サーバに接続……なんてことは基本的に厳しそう。 git commit に sign するのと違って key logger 一発で全てが破滅するので

ぼちぼち湿度40%とかになってきたので弱運転していた防湿庫の乾燥機能をちょっと強めたら、あっという間に24%とかになった。頼りになるなぁ

あっという間 (数日)

超絶有用な機能を実装したら API が超絶複雑になったので険しい顔になってる

この機能抜きでも十分すぎるくらい使えるんだけど、入れると保証のレベルが段違いになるので……

実装の複雑度くらいならどうとでもなるけど、 API の複雑度は割と †本質† へのダメージが……

このアカウントは、notestockで公開設定になっていません。

sakura と kero 、また balloon 2つを同じウィンドウに描画して、 D&D はウィンドウ内での描画を弄ることでうまくやるという手がある (ない) (WM と compositor の再発明)

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

立ち上がりの逆が立ち下がりなの、ﾃｸﾆｶﾙﾀｰﾑ感が強烈すぎてウケる

私も今度から椅子には座らず立ち下がることにするか (?)

このアカウントは、notestockで公開設定になっていません。