2026年8月アーカイブ

● 前置き
Linux From Scratchというプロジェクトがあり、
https://www.linuxfromscratch.org/
イマドキのLinuxシステムで使うソフトウェア類をすべてソースコードからビルドして環境を構築する、というテーマの手順書を作るプロジェクトになっている。しかしLinux From Scratchでは「コンパイラをビルドするためのコンパイラ」問題が解決しない。

この、最初のコンパイラを用意することも含めて、イマドキのUNIX likeシステムを構築するところまで再現可能な手順を整える、というのがソフトウェアブートストラップという考え方になる。一般的には、自身のコードをビルドできるようなコンパイラを作る(セルフホスト)のがゴールとされるが、イマドキの環境をとなるとコンパイラを用意するだけでは成立しない。

● なぜブートストラップが必要なのか
Bootstrappable builds
https://bootstrappable.org/
に書いてあることをそのまま受け売りするだけなんだけど、
- もし世界中のソフトウェアが破壊されたとしても、ソースコードさえあれば元と同じ世界を再構築できるようにする
- 悪意あるコンパイラのバイナリが紛れ込むとバックドアがないことを証明できなくなる、そうならないようにする
あたりが主な目的になる。

● GNU Guix
GNUのツールを使ったUNIX環境をゼロから構築できることを構成として提供する。
https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/
特に、M2-Planet や Mes (MesCC) が、原始的なコンパイラとして重要になる

● live-bootstrap
さらに踏み込み、イマドキのLinuxシステムをゼロから構築する手順を網羅しメンテしている。
https://github.com/fosslinux/live-bootstrap/blob/master/parts.rst
流れを熟読してみると、主観ではあるもののキーとなるツールが見えてきておもしろい。
新しいバージョンを作るために同じツールの古いバージョンを必要とする、という例も多い。
- まずは、なんでもいいからプログラムをシェル的に動かせるようにして、
- 10 で M2-Planet(超原始的なCコンパイラ)を用意し、
- 19 で M2-Planet を使ってmes 0.27 (原始的なCコンパイラ)を作り、
- 20 で mes を使って tinycc 0.9.26 (古代的なCコンパイラ)を作り、
- 22 で tinycc を使って fiwix 1.5.0-lb1 (Linux 2.0ベースのクローン)を作って古代的なUNIXの構築を開始し、
- 40 で musl 1.1.24 (古いlibc)を作って古代的なUNIXのユーザランドを構築する足がかりにして、
- 56 gawk 3.0.4 や 57 perl 5.000 から、近代的な gcc をビルドするためのツールを満たしていき、
- 84 で gcc 4.0.4 を作って近代的なUNIXを構築するための一歩になって、
- 99 で Linux kernel 4.14.341-openela を作って近代的なUNIX環境を動かせるようにして、
- 145 で gcc 4.7.4 を作って現代的なツールをビルドするのに必須のまともな C++コンパイラを手に入れて、
- 148 で python 2.0.1 を作って pythonに依存したイマドキのツールもビルドできるようにしていき、
- 167 で gcc 10.5.0 を、169 で gcc 15.2.0 を、となって、このあたりでようやく Linux From Scratch の開始地点に到着する

● 余談1
gcc 4.6.4 や gcc 4.7.4 あたりが、イマドキのC++をビルドできるコンパイラだけど、コンパイルするのにC++コンパイラを必要としない、というキーポイントになっているらしい。RISC-Vは比較的新しいCPUアーキテクチャだが、gccのこれらバージョンの頃はまだRISC-Vをサポートしていなかったため、RISC-V環境はこのままでは同じ手順でブートストラップできない。だったら、gcc 4.6.4ベースでRISC-Vサポートを追加したらええやん、ということでメンテしてるらしい。
Collectively maintaining GCC 4.6.4
https://bootstrappable.org/projects/gcc-464.html

● 余談2
もし突然に現代科学の成果物がすべて失われてしまったと仮定して、知識だけを頼りに、元の現代科学の成果物を取り戻すにはどのような手順が必要か、というテーマで書かれたマンガ・アニメにDr.Stoneというのがある。見ていておもしろくはあるものの、いやそこはそう簡単にはいかんやろ、と突っ込みたくなるところもある。現代科学が失われたら、という社会実験を実際にやるのはほぼ不可能だけど、ソフトウェアのブートストラップは実際にやってみることができるので、そういうところがソフトウェアならではなのかなと思った。

主要なソフトでも、リリースされたバージョンと日付の一覧を明記したものがない場合が多いので、自分のためにもメモ書きして残しておく。

● Linux
https://kernelnewbies.org/LinuxVersions
● gcc
https://gcc.gnu.org/news.html
https://github.com/gcc-mirror/gcc/blob/master/gcc/ChangeLog
● binutils あまりまとまってなさげ
https://github.com/gittup/binutils/blob/gittup/ChangeLog
https://ftp.gnu.org/gnu/binutils/?C=M;O=A
https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=binutils&submit=Search%21&idxname=info-gnu&max=100&result=normal&sort=field%3Auri%3Adescending
● gdb あまりまとまってなさげ
https://github.com/intel/gdb/blob/master/ChangeLog
https://ftp.gnu.org/gnu/gdb/?C=M;O=A
https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=gdb+released&submit=Search%21&idxname=info-gnu&max=100&result=normal&sort=field%3Auri%3Adescending
● glibc Changelogファイルがでかかったり分割されたりしてていまいち
https://sourceware.org/glibc/wiki/Glibc%20Timeline
● coreutils あまりまとまってなさげ
https://github.com/tar-mirror/gnu-coreutils/blob/master/ChangeLog
https://ftp.gnu.org/gnu/coreutils/?C=M;O=D
https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=coreutils+released&submit=Search%21&idxname=info-gnu&max=100&result=normal&sort=field%3Auri%3Adescending
● util-linux あまりまとまってなさげ
https://www.kernel.org/pub/linux/utils/util-linux/

ググって調べるよりも、愚直に確認したほうが早い場合も多い模様。
- パッケージに同封されている Changelog/NEWS ファイルを見る
- git log や git tag を見る (ただしgitが広まるよりも前のリリースまでは確認できない)
- FTPサーバなどに置かれたファイルのタイムスタンプを見る
- メーリングリストなどでのリリース案内のメッセージを探す

● 背景
2010年とかそれ以前は、いわゆる一般家庭向けのルータ、BB(ブロードバンド)ルータは、設定管理画面にアクセスするのに、HTTP Basic認証を使っていた。ので、curlなどのコマンドを使って一発でいろいろできた。
2010年中ばからは、さすがに HTTP Basic認証はないだろうということで、ID/PASSWORDをPOSTしてセッションクッキーをもらってアクセスするものが増えてきた。ので、例えば下記の記事のように、Cookieを保持するHTTP Clientを動かして対応することになる。
AndroidスマホでWi-Fiルータを定期再起動！Termux＋Pythonで自動化
https://qiita.com/kamajiro/items/41d14f92c407aa06c087

● この記事のお題
たまたま使うことになった BUFFALOのWSR-1500AX2L は、さらにもう一歩踏み込んでいて、セッションIDやセッションクッキーはもちろん必要として、パスワードをPOSTするときにクライアントで暗号化して送る必要がある、という中身になっていた。スクリプトなどから利用しようと思った場合に、もう一段階しきいが高くなった。

● 実装の中身
作ったスクリプトがあまりにも汚いので、文章でのみメモっておくことにする
- 1) Cookieをtmpで保持するHTTP clientを作る
- 2) /login_time.html へ GET でアクセスして session_num を記録する
- 3) /login.html へ、下記を添えてPOSTする
----- nosave_Username - ユーザID
----- nosave_encryptedPassword - 後述する
----- MobileDevice - 0 固定でいい
----- nosave_session_num - 2)で記録したもの
- 4) /index.html へ GET でアクセスして sessionID を記録し、以後アクセスするときの Cookie に追加する
- 5) 例えば /info.html へアクセスすれば、WAN側のIPアドレスなどの機器情報を取得できる

● nosave_encryptedPasswordの補足
ルータはクライアントに jsencrypt.min.js を配信することで、クライアントがログインするときにクライアントにパスワードを RSA暗号(PKCS#1 v1.5 パディング) で暗号化させてからPOSTさせる。公開鍵は login.html に固定値でベタ書きされている。パディングありの方式なので、同じ文字列を同じ鍵で暗号化しても毎回異なる結果を得るが、秘密鍵を持つ側は復号化すればそれらが同じものであると判断できる。つまり、1回ChromeブラウザなどでログインしてそのときのPOSTのペイロードをダンプして記録しておけば、スクリプトからは毎回この同じダンプしたものを使うだけで良くなる。なので、先の 3) について、正しくダンプして記録しさえすれば nosave_encryptedPassword は固定値で問題ない。