#oss

オープンソースのセキュリティ対応は、これまで「欠陥の詳細をしばらく伏せておけば、その間に利用者へ安全に直せる」という前提で回ってきました。Anil Madhavapeddy氏は、その前提がLLMや自律エージェントの登場で崩れつつある、と書いています。この記事は、OCamlのHTTPライブラリ `cohttp` のパッチ作業を起点に、公開前でも攻撃の兆候が走り出した現実を示し、OSSメンテナがどう守りを組み替えるべきかを考えるものです。単なる「AIで攻撃が速くなった」という話ではなく、公開・非公開・修正・配布の境界そのものが揺れている、というのが芯にあります。 著者はその日、OCaml向けの `cohttp` 6.3.0 に対するセキュリティ修正を出したと説明しています。内容は path traversal、つまり本来たどれないはずのパスにアクセスさせる脆弱性です。普通なら、こうした修正はまず私的に直し、影響を受ける利用者へ伝え、最後に公開アドバイザリを出す流れになります。ところが今回は、PR を開いてからほんの数分で、実運用中の自分のWebサーバーログに、そのバグの典型パターンを試す

オープンソースプロジェクトは「突然死」するというより、いろいろな形でじわじわ弱っていく 原因は、メンテナ不在だけではない。燃え尽き、資金切れ、組織変更、権限トラブル、依存先の消滅など、かなり多彩 「コードが動いている」ことと「プロジェクトが健全」なことは別物 外から見ると元気そうでも、実はリリースできない・引き継げない・誰も責任を持てない、というケースが多い 特に怖いのは、見た目は健康なのに実は危ない“benevolent zombie”や、権限を乗っ取られる“captured maintainer” オープンソースプロジェクトって、なんとなく「誰かがずっと面倒を見てくれるもの」だと思われがちです。 でも Andrew Nesbitt のこの記事は、その幻想をかなり痛快に、そして少し不穏に壊してくれます。 テーマはシンプルで、オープンソースプロジェクトには“くだらないほどいろいろな死に方がある”という話です。 しかも面白いのは、「死んだ」の定義が1つじゃないこと。 最後のコミットが何年も前なのに誰も気づかないケースもあれば、コードは更新されているのにリリースできないケースもある

Open Sourceは“余暇の趣味”ではなく、今や社会インフラだという主張 OSSメンテナは、会社の業務時間を使って依存先のOSSを維持すべきだと訴えている ポイントは「サボる」ことではなく、会社がすでに依存しているものを会社の時間で直すこと ただし、契約・秘密情報・知的財産の扱いには注意が必要 “正しい会社なら許可を出すべき”という穏健策もある一方で、本記事はもっと直球の行動を勧めている かなり挑発的だが、OSS維持の現実をかなり正確に突いていると感じる Open Source Resistance は、ざっくり言うと 「企業に勤めながらOSSメンテナンスをしている人は、夜や週末だけでなく、会社の勤務時間でもやるべきだ」 という“直行型”のマニフェストです。 ここで言うOSSは Open Source Software、つまりソースコードが公開されていて、誰でも利用・改変できるソフトウェアのことです。 たとえば、Webサービス、開発ツール、インフラ、パッケージ管理など、私たちの仕事の土台にはOSSが山ほどあります。 著

Radicleは、Gitを使った分散型のコード協業基盤です GitHubのような中央集権型サービスと違い、ひとつの運営者に依存しないのが大きな特徴です コードだけでなく、issuesやdiscussion、code reviewのような周辺情報もGit上で扱えるのが面白いところです local-firstなので、インターネットがなくてもある程度使える設計です CLI、Web、TUI、Desktopなど、複数の使い方に対応するモジュール構成になっています Linux、macOS、BSD系で利用可能で、インストールはかなり手軽です Radicleの紹介文には、`sovereign code infrastructure` という言葉が出てきます。直訳すると「主権的なコード基盤」ですが、要するに自分たちのコード管理を、特定企業の都合に握られたくないという考え方です。 これはかなり重要だと思います。 GitHubやGitLabのような便利なサービスはたくさんありますが、中央のサービスが止まったり、規約が変わったり、アカウントが制限されたりすると、