IBMのテレコン英会話小冊子

日本IBMの小集団活動の成果物だとかいう話だったと思うのだが、「テレコン英会話小冊子」というのがある。 かつては、http://www-06.ibm.com/businesscenter/jp/hitoiki/pdf/telecon_eng.pdfで公開されていたのだが、今はこのURIは404である。 今は、https://www.ibm.com/downloads/cas/95W7L0JLで公開されている。 これは、https://www.ibm.com/downloads/documents/jp-ja/107a02e95948f43bへリダイレクトされて、ダウンロードすると、77031077.pdfというファイル名でダウンロードできる。 最終ページを見ると、2021年にも更新されている。

GnuPG2で、revoke済みのUIDを表示させる

20年以上利用して来たインターネット・サービス・プロバイダーの提供してくれている電子メールアドレスを廃止することにした。 近年は全く価値に見合うようなサービス品質ではないように考えられるアカウントもあったし、受信がほぼできなくなるような状態になったりすることもあった。 いずれにしても、近年の急激な値上げは、廃止しようという思いを強くさせていた。 ただ、なかなか廃止するのは大変であり、時折思いもしない所から、これらの電子メールアドレス宛てに届くこともある。 しかし、もう思い出すのも難しい所から以外から届くことはなさそうである。

と言うことで、長年メンテナンスをしていなかったPGP鍵をメンテナンスすることにした。 副鍵も暗号化のみであったので、sign、encrypt、authenticateの各capabilityのみを持つ副鍵を追加した。 主鍵にもCertifyの他にsignのcapabilityが設定されているし、年代物のencryptのみの副鍵もあるが、これらはとりあえずそのままにしている。

既に廃止することが決まっているUIDはrevokeした。 実際に解約したいが、PHPの脆弱性の影響らしく解約メニューは利用できない。 しかし、もうこの電子メールアドレスから発信することはないので、UIDはrevokeした。

UIDをrevokeしてしまうと、--list-keyでは表示されなくなってしまう。 もちろん、この動作で良いのだが、revokeされたUIDを表示させて確認もしたい。 以下のように--list-options show-unusable-uidsを指定すれば良かった。 2番目の副鍵が、remove済みのものである。

$ gpg --list-options show-unusable-uids --list-key XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
pub   rsa4096 2004-07-12 [SC]
      82A2DC9176E0A10A8ABBFD1BF40427FAC7D115F3
      XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
uid           [ultimate] First1 Lastname1 <user1@domain1>
uid           [ revoked] First2 Lastname2 <user2@domain2>
uid           [ultimate] First3 Lastname3 <user3@domain3>
uid           [ultimate] First4 Lastname4 <user4@domain4>
sub   rsa4096 2004-07-12 [E]
      XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
sub   ed25519 2026-10-26 [S]
      XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
sub   cv25519 2026-10-26 [E]
      XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
sub   ed25519 2026-10-26 [A]
      XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

OpenPGPの鍵を公開する

はじめに

GnuPGを使っているが、積極的に電子メールに署名も暗号化もしていないので、あまり役立てているとは言えないかもしれない。 利用しない理由は、PGPを使っている相手が少ないというものである気がするが、本当は特に署名したい内容も暗号化したい内容も書いていないからかもしれない。 最も利用しているのはファイルの暗号化であり、それを共有するということである。

しかし、鍵をきちんと公開しておきたい気持ちはある。 もう放棄しようとしているインターネット・サービス・プロバイダーの提供する電子メールアドレスについてはどうでも良いが、利用している独自ドメインの電子メールアドレスでは探せるようにしておきたい。 DNSSECを採用する予定はないので、Internet Draft draft-koch-openpgp-webkey-service-22であるOpenPGP Web Key Directory (WKD)を採用してみた。

鍵情報を生成する

どういう仕組みなのかというのは、どこかで解説されているだろうから省略して、実際の手順を書いておく。 まず、gnupg2パッケージをインストールしておく。

# cd /usr/pkgsrc/security/gnupg2
# make install

WKDの様式に従った鍵情報を配置するディレクトリーを作成する。

$ mkdir -p wkd/.well-known/openpgpkey

今回ターゲットとするのは1つの電子メールアドレスだけなので、絞り込んで作成する。 他は自分のドメインではないので、作成してもそもそも探しに来てはもらえないだろう。 gnupg2パッケージに含まれているgpg-wks-clientコマンドがうまく生成してくれる。 とりあえず、電子メールアドレスとドメインだけ、spamを防止するためにマスクしておく。

$ gpg --list-options show-only-fpr-mbox --list-key MYUSER@MYDOMAIN | grep MYUSER@MYDOMAIN |  gpg-wks-client -v --install-key --directory wkd/.well-known/openpgpkey
gpg-wks-client: using key with user id 'MYNAME <MYUSER@MYDOMAIN>'
gpg-wks-client: directory 'wkd/.well-known/openpgpkey/MYDOMAIN' created
gpg-wks-client: directory 'wkd/.well-known/openpgpkey/MYDOMAIN/hu' created
gpg-wks-client: policy file 'wkd/.well-known/openpgpkey/MYDOMAIN/policy' created
gpg-wks-client: key 82A2DC9176E0A10A8ABBFD1BF40427FAC7D115F3 published for 'MYUSER@MYDOMAIN'

どのように生成されたか確認してみる。これをhttps://openpgpkey.MYDOMAIN/.well-known/openpgpkey/MYUSER@MYDOMAIN/hu/tfjzips9n54e1w4edgiska367yec1bkh?l=ryoとしてアクセスできるように公開すれば良い。

$ find wkd
wkd
wkd/.well-known
wkd/.well-known/openpgpkey
wkd/.well-known/openpgpkey/MYUSER@MYDOMAIN
wkd/.well-known/openpgpkey/MYUSER@MYDOMAIN/hu
wkd/.well-known/openpgpkey/MYUSER@MYDOMAIN/hu/tfjzips9n54e1w4edgiska367yec1bkh
wkd/.well-known/openpgpkey/MYUSER@MYDOMAIN/policy

wkd.dp42.devで確認できる。 この場合、Content-Typeはapplication/octet-streamにしておくべきであるようだった。

GnuPGのwikiページによると、Thunderbird 128以降はWKDを使って公開鍵を取得できるようだ。 Thunderbird 158.8.1はビルド待ちなので、今度試してみたい。

文化庁の自由利用マーク

文化庁の自由利用マークというのがあって、ITmediaの記事「文化庁、CCライセンスを支援へ　独自ライセンス構築は断念」によると、2013年の時点で普及はあきらめているらしい。 文化庁のウェブページを見ても、そもそも「コピーOK」「障害者OK」「学校教育OK」という区分も良いとは思えないし、どんな側面でも日本の法律に直結してしまっているのも、利用できる範囲が狭いのも、発展性がないような気がする。 しかし利用されてしまうと、説明のウェブページを維持しないといけないので、こういうのは失敗できない難しいことであるような気がする。

Android用のWikipedia appを使ってみた

Wikipediaをログインしないで使っていて、WikipediaのAndroid appがあるという通知が表示された。 これまでWikipedia appがあるとは知らなかったので、インストールしてログインしてみた。

これまでの編集や編集後の閲覧数をActivityとして閲覧できるのはおもしろいのだが、Firefox for AndroidでWikipediaのウェブページを開くと、appで開くか聞かれるのは煩雑かつ私には意味がない。

Firefoxでapp単位でこの機能を無効化できたか記憶がない。 また、外部サイトはあくまで外部のウェブブラウザーで開くことになるので、便利でもない。 どんなウェブページも開けるように作るのはセキュリティー的な面も考慮すると避けたいのかもしれないが…。 でもWikipediaほどのウェブサイトを表示できるのであれば、外部サイトをapp内で開いても大差ないような気もする。

いずれにしても、そこまで便利ではないと言うか不便になる方の影響が大きいのでアンインストールすることにした。

YubiKeyを使えないウェブサービスでYubiKeyを無理やり使う

PassKeysは明らかに私にとってのSingle Point Of Failureなので、なぜこんなものが流行しているのか、いまいち分からない。 技術的にはパスワードを入力してやりとりするより安全なのは間違いなさそうだが、もっと良い方法はないのだろうか。 いずれにしてもPassKeysを設定しないといけないサービスにFirefox for NetBSDからログインしたいので、選択肢はない。

Firefox for NetBSDを常用していてPassKeysを使おうとすると、ハードウェアセキュリティーキーを使う以外に方法はない。 私はYubiKey 5 NFCを買って使っている。 古いもの(ファームウェアバージョン5.4.3)はFIDO2の保管上限数が25であり、すぐにいっぱいになってしまう。しかも、脆弱性がある。 新しいもの(ファームウェアバージョン5.7.4)は100まで保存できる。しかし100しかないとも言える。 software FIDO2 authenticatorとでも呼ぶべきプログラムは存在するのだが、それをNetBSDで動くようにするのは、面倒な気がする。 やってみたらそうでもない可能性もあるので、勝手な印象ではあるが。 では、スマートフォンでQRコードを読み取る方式はどうかと言うと、これはBluetoothサポートが必要なので、到底実現できるとは思えない。

同じようなことを考える人はいるもので、Passkey DictatorというFirefox addonを作っている人がいる。 Mozilla Firefoxのaddon storeでも公開されている。 こういうソフトウェアを無条件に信頼してインストールするのは危険であるのは確かなので、良く吟味してから使わないといけない。

これを使うと、READMEに書いてあるようにPixivには問題なくPassKeysの登録もログインもできるようになる。Firefox for NetBSDでもWindowsでも同様に問題ない。user agent stringも変更する必要はない。

私の問題としているもう1つはdアカウントなのだが、これはFirefox for NetBSDでid.smt.docomo.ne.jpへ送るuser agent stringをGoogle Chromeにすると、PassKeysの登録もログインも両方が問題なくできる。 しかしFirefox for Windowsでは、PassKeysの登録はできるのだが、ログインの際にはQRコードのパターンにしかならない。 幸運なことにdアカウントには複数のPassKeysを登録できるので、YubiKeyとAndroidのGoogle Password Managerの2つのPassKeysを登録しておくことにすれば、最終的には問題にはならなかった。 dアカウントでのログインは、PassKeysが必要なサービスとそうでないサービスがあるので、面倒である。

もう少し勉強すれば、Firefox for Windowsでdアカウントにログインできるようにできるのかもしれない。

mixed mode CDのデータトラックをマウントする

以前に「古いmixed mode CDをバックアップする」と題してバックアップ方法を書いたが、実際のmixed mode CDのディスクについてはあまり触らなかった。 気になっていたのは、データトラックがNetBSDでマウントできるかを確認していなかったし、データトラックをマウントした状態ではCDDAのクラックは再生できないだろうが、それも実際には確認していなかった。 そもそも、CDDAの実際のディスクを再生する簡単な方法も分かっていなかった。pkgsrc/multimdia/vlcで/dev/cd0を再生すれば間違いはないのだが、mplayerやmpvではどうすべきか分かっていなかった。

まず、データトラックをマウントしてみる。 これは簡単で、普通にマウントすれば良い。

# mount_cd9660 /dev/cd0 /mnt/cdrom

予想通り、マウントしている最中にはCDDAのトラックは再生できなかった。

後はmixed mode CDを作る方法を調べてやってみれば、mixed mode CDに関する疑問は解消できそうだ。