OpenSSHサーバに公開鍵認証でログインしたユーザができることを制限したい場合、authorized_keys の公開鍵にオプションを書き連ねる。

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="..." ssh-rsa ...

これらのうち no-* は、restrict オプションひとつで置き換えることができる。

restrict,command="..." ssh-rsa ...

より正確には、restrict は以下の設定と等価になる。

• no-port-forwarding
• no-agent-forwarding
• no-X11-forwarding
• no-pty
• no-user-rc

さらに将来同様のオプションが新設された場合も restrict でカバーされることが期待できる。 必要なオプションがあれば一部を明示的に有効化することもできるので、restrict をベースに設定するのがいい。

詳しくはsshd(8)や、ソースコードの auth-options.c を参照。

自分の中では新発見だったのだけど、restrict オプション自体は2016年にリリースされたOpenSSH 7.2（リリースノート）で新設されたもので、まったくもって目新しいものではない。

Gitのpull／pushにしか使わない公開鍵を持っていて、できることを制限しようと思い立った。 git-shell を使えばいいことはすぐにわかったのだけど、他にどんなオプションがあったかと調べていたらたまたま見つけた。

このBlosxomではずっとMarkdown原理主義を貫いてきた。 Daring Fireballで供された Markdown.pl をパーサとして使っている。

‥‥のだけど、よそで世俗的なMarkdownばかり書いていたらさすがに辛くなってきたので、宗旨替えすることにした。 GFMやMultiMarkdownまでいくと俗っぽすぎるきらいがあるので、CommonMarkで手を打つ。

Blosxomプラグインを書く必要がある。

Cによるリファレンス実装であるところのcmarkを利用するのがいいと思った。 PerlにもCommonMarkモジュールというlibcmarkインタフェースが存在するのだけど、維持管理が面倒で二の足を踏む。

場当たり的にcmarkコマンドを叩くプラグインを書いてみた。 当然ながら変換処理自体は Markdown.pl より圧倒的に速いのだけど、コマンド実行のオーバーヘッドがやはり気になる。 いち記事ごとにプロセスを起動するというのも気分が良くない。

結局、libcmarkの cmark_markdown_to_html() をInline::Cで呼び出すかたちでひとまず落ち着いた。 メモリ管理まわりにいまいち自信が持てないのでソースは伏せる。 まあ100万回くらい回してもリークしてる様子はないし、所詮CGIプログラムなのでリークしていたところで実害もないのだけど、SVを正しく管理できてるかわからない。

CommonMarkモジュールのパッケージがGentooにあれば迷わず使っていたとは思う。 そうでなくとも使うべきだとも思う。

g-cpanは避けたいしCartonも使わなくなってしまったので、Perlモジュールの維持管理に対する心理的ハードルが上がってしまっている。

すこし前の話。 仕事でそこそこのボリュームのMarkdown文書を書くことになった。 諸般の事情から主に会社のWindows機で書いていて、しばらくはVisual Studio Codeで頑張っていたのだけど、ある日ついに限界に達した。

WindowsでEmacsといえば遠い昔にMeadowを使ったことがあって、正直あまり良い印象はなかったのだけど、ものは試しと思ってGNU公式のWindows向けインストーラを使ってみたらいい感じに動いてしまった。 IMEとの相性はだいぶ厳しく感じたので、package.el をはじめて（そう、はじめて）使ってddskkを入れてみたら、これまたいい感じに動いてしまった。 ついでに markdown-mode.el もサクっとインストールして、一抹の満足感とともに文書を書き進めた。

おかしなもので、EmacsをMacやリモートのLinuxで使っていても小指がShiftキーを探すようになってしまった。 気が向いたときだけ使えばいいんだし、と思ってそいつらにもddskkをインストールしたら、待ってましたとばかりに手がC-x C-jを叩く。 SKKなんて最後に使ったのがいつだったかすら思い出せないのに、本当に不思議でしょうがない。

以前、目にした記事を思い出す。

グイドは「Emacsは新しいエンジニアには本当にオススメしない（つまり使うな）」と言っていて、 その理由として「It just exists for old brain compatibility.（古い頭脳との互換性のために存在している）」と述べている。

風になりたい奴だけがEmacsを使えばいい2020 | 日々、とんは語る。

思い返せばEmacsと出会って20年以上が経っていた。 使う頻度は仕事柄もあってかVimのほうが高いのだけど、汎用テキストエディタとして使う気にはまったくなれない（みんな入力モードとIMEの操作にどう折り合いをつけてるわけ？）。 VS Codeや少し前だとAtomなんかを試した時期もあったのだけど、なんだかどうも他人行儀というか疎外感というか、こう、安心して背中を預けられない感覚みたいなものが拭えなかった。 これも古い頭脳の一つの表出なのだろう。

長い付き合いとはいえ正直こっちはElispもろくに書けないのだけど、それでも、少なくともまだ当分の間は、こんな素人の面倒も変わらず見てくれるだろうなという信頼がある。 そんな安心感を守りつづけてくれている開発者とユーザのコミュニティに感謝しかない。