Node EOL からNode LTS まで、そしてその間のすべてのバージョン
やあ、マルコ、マテオ、君たちが来てくれて本当に嬉しいよ。
こんにちは。素晴らしいですね。
では、皆さんに自己紹介をしていただく前に、私についても少しお話しさせてください。実は皆さんとはNode.jsという共通点があります。私たち3人は、Node.jsを使っているアイルランドの企業で働いていると思います。これはちょっとした面白い豆知識ですね。
さて、まず自己紹介から始めます。私はハビエル・ペレスと申します。HeroDevsにて、テクニカルプロダクトマネジメントのリーダーを務めています。JavaScriptエコシステム内の25以上の技術に加え、JavaScriptエコシステム外のいくつかの技術、そしてもちろんNode.jsも担当しています。
私が言いたかったのは、マテオやマルコとのつながりについてですが――まあ、今となっては随分昔のこと、およそ12年ほど前の話になりますが――当時、私はアイルランドのウォーターフォードにあるFeedHenryという会社で働いていました。2012年のことですが、Node.jsがまだバージョン0.7か0.10だった頃、私たちはすでにNodeを使っていたんです。0.10、そして0.12の頃を覚えています。そのすべてのバージョンを経験してきました。 フォークや再統合といった歴史については、ここで詳しく語る必要はないでしょう。それらはすでに十分に記録されていますから。
しかし、その頃はNode.jsを非常に密接に活用していました。私たちはRSS技術や、クラウドサービスに接続するモバイルアプリの開発に取り組んでいました。当時はまだ非常に新しい技術だった高負荷なI/O処理でしたが、それが私たちにとって不可欠な技術であることはわかっていました。そして、私たちの判断は間違っていなかったと思います。CTOやエンジニアリングチームも間違っていなかったのです。
まず最初に言いたいのは、皆さんとこうして一緒にいられること、そして皆さんがNode を活用してくださっていることに、ただただワクワクし、嬉しく思っているということです。Node 多くのことがありましたね。状況は半年ごとに変わっていきますよね？時には劇的に変わることもあります。だからこそ、その話題について話すのはとても楽しみです。それでは、マテオさん、まずあなたから始めましょうか？簡単に自己紹介をお願いします。Node、OpenJS、そしてTSCとの関わりについて、お話しいただけますか？
もちろん。ああ、もちろん、もちろん。
ええと、Nodeを使い始めたのは、確か2010年頃だったと思います。2011年には博士課程に進みました。それ以前はRubyやJavaを使っていましたが、Javaと同じくらい高速で、かつRubyと同じくらい開発しやすい環境が欲しかったんです。Rubyは開発段階では非常に高速でしたが、実行時はとても遅かった――少なくとも当時はそうでした。今でもそうだと思います。
そして、ある動画を見たんです……「これだ、これこそが技術だ」と思いました。でも正直なところ、あの瞬間が転機だったわけではありません。 決定的な瞬間は、NPMを理解した時、そしてNPMがリリースされた時でした。それはすぐには起こらず、少し後のことでした。そして、HeroDevsの皆さんとこの話をしていた時に気づいたのですが、NPMが本質的に「ソフトウェアを大規模に再利用する方法」を解決してくれると確信した瞬間です。これは、それ以前のJavaの世界、さらにはRubyの世界にとっても大きな課題でした。 NPMが登場するまで、誰もその解決策を見出せていませんでした。それがNPMの最大の発明であり、その結果として世界最大のレジストリが誕生しました。そこには優れたものが溢れている一方で、マルウェアも溢れており、それが最大の標的となっています。つまり、最も魅力的な標的であり、といった具合です。
国家機関による攻撃の標的となり、コンピュータへのアクセスを狙われた一人として――その点では不運だった。でも、それは素晴らしい経験だった。だから、私はNode 早い段階からNode を使い始め、left-padの問題が起きる数ヶ月前からその危険性を予見していたし、長い間、最前線で戦ってきた。
実は私たちにはちょっとした縁があるんです。2013年、2014年頃、私はNearFormという小さな会社で働いていましたが、そのオフィスはFeedHenryのすぐ隣――文字通り隣――にあったんです。だから、私たちにはこうしたちょっとした縁があるわけです。ここ数年で、FeedHenryからNearFormへ、あるいはその逆へと移った人も何人かいました。実に興味深い道のりでした。 おそらく私たちは同じ時期にアイルランドにいて、隣同士で働いていたのでしょう。あの頃は本当に楽しい日々でした。
あの騒動の後、Node.jsへの貢献を始めました。IOJSの分裂は大きな出来事でしたし、その後、財団が設立されました。Node には直したい点が山ほどあったのですがNode 手が出せませんでした。財団が設立されてから、ようやくその作業に取り掛かるようになったのです。Node貢献を少しずつ始め、数年後にはCTCのメンバーになりました。その後、CTCはTSCに統合されました。そして、どういうわけか、くじ引きで負けてしまったのか、Node.js TSCの議長に選出されることになりました。
TSCについてはまた後で詳しく話しましょう。マッテオ、君がやってきたことについて話すだけでも何時間もかかりそうですよ。ピノとFastifyについてはどうですか？
この1年間で、私がこのエコシステム内でメンテナンスを担当しているすべてのモジュールのダウンロード回数が、420億回に達したようです。
信じられない。ありえない。
そして、Fastify、その名の通り、最も高速なフレームワークですよね？
うん。そうかもね。
マルコさん、ご自身について教えてください。Node どのような経緯で関わることになったのですか？
ええ、僕は間違いなくアーリーアダプターの部類には入らないね。Node に興味を持ち始めたのはNode 8年Node 。それまではJavaをやっていたんだけど、いつも「こんな定型コードばかり書きたくない」って思ってたんだ。退屈だったからね。当時、Node.jsは最も新しい技術で、今でも最先端の技術だ。
久しぶりですね。私がNearFormに入社した数年前から、少しずつ貢献し始めました。確か、マッテオが辞めた翌週に入社したと思います。まさに偶然でしたね。その後、JavaScriptエコシステムのセキュリティにもっと深く関わるようになり、当時相次いでいた様々な攻撃に興味を持つようになりました。
それは素晴らしいね。ところで、マルコはまだ22歳くらいだよね？ マルコ、君はまだすごく若いね。
いいえ、私は28歳です。
28歳。なるほど。それはとても若いですね。
では、Node.jsの周りで起きている様々な動きについてお話ししたいと思います。その前に――今回OpenJSと共同でこのイベントを企画した理由の一つですが――私たちはここ数年、OpenJSと協力関係を築いてきました。実際、ちょうど2年前に、そこでエコシステム・サステナビリティ・プログラムを開始しました。ご存知の通り、HeroDevsはサポート終了を迎えたソフトウェアの管理を行っています。 そしてOpenJSは、次のように率直に語っています。「私たちは、さらなるイノベーションや貢献を求めている一方で、セキュリティと持続可能性にも配慮したいと考えています。」
私たちも承知しています。大規模な環境を展開している組織にとって、単にアップグレードしたり、あるバージョンから別のバージョンへ移行したりすることが、時にどれほど困難であるかについては、何時間でも語れるほどです。互換性を損なう変更のリスクなど、様々な課題があります。しかし、つい先日、Node サポート終了を迎えました。4月30日、つまり4月末、わずか1ヶ月足らず前に、非常に重要なバージョンであり、広く利用されていたNode サポートが終了しました。 メンテナンスの終了、アップデート、マイナーリリース、パッチの提供も終了しました。
お邪魔してすみません。Node 何回ダウンロードされたかご存知ですか？
今はnpmには行かないけど、教えてよ。
9,500万回。
ただ言ってみただけ。
ここで一言申し上げたいのですが、多くの人がアプリ、特に特定のデプロイ環境においてNode.Nodeを導入した後、一切アップグレードを行っていないのが現状です。Node .Node 採用が進むにつれて、多くの企業やチームがまったくアップデートを行っていないという実態が見えてきています。彼らにとってNode 大変なNode なぜなら、依存関係ツリーが大幅に古くなってしまっているため、依存関係ツリー全体を更新するには大規模なリファクタリングや再構築が必要になるからです。そのため、少しずつ行うのではなく、一気に大規模なリリースを行わなければならないのです。
とはいえ、Node 9,000万件の大台から一向に動こうとしません。正直なところ、Node.jsのダウンロード数が最も多かったのは、昨年の6月か7月のことで、その時の月間ダウンロード数は約1億2,500万件でした。マッテオはそこに関する有益なデータをたくさん持っています。あなたのグラフをいくつか拝見しましたが、本当に素晴らしい内容でした。
ええ、もう一つの画面にグラフを表示しているので、事実は正確に把握しています。
マルコ、Node すべてのリリースのスクリーンショットを見せてくれたね。そのほとんどは、君が直接リリース作業に携わったものだ。その経験について教えてほしい。どんな感じだった？
Node がLTSになった際のリリースのうち、およそ70％は私や他のボランティアによって行われたと思います。
Node リリースは大変なNode 。不具合が発生しがちなので忍耐も必要ですし、多くの人とやり取りしたり、分からない部分については助けを求めたりしなければなりません。とにかく、かなりの労力がかかります。 HeroDevsNode 私のオープンソース活動を支援してくれていることを嬉しく思います。なぜなら、持続可能性における課題の一つは、こうした面倒で時に退屈な作業を行うボランティアへの資金提供にあるからです。そして、それがリリーススケジュールを変更する主な理由の一つでもあるのだと思います。
それでは、その件について話しましょう。Node における大きなニュースの一つは、リリーススケジュールの変更です。マルコ、まずそこから話してもらえますか？その決定に至った経緯はどのようなものでしたか？
さて、まずご存知ない方のために説明すると、これまで私たちは6ヶ月ごとにリリースを行ってきました。奇数バージョンはLTSではありません。LTSとなるのは偶数バージョン、つまり18、20、22といったバージョンです。しかし、これからは年1回のリリースに変更され、すべての偶数バージョンがLTSとなる予定です。
あと、このコミュニティのもう一つの魅力は、すべてが本当にオープンな点ですよね。数ヶ月前にこの件が議論されていた掲示板を見つけてきました。
ええ、その主な理由は、4つのリリースを同時に維持すること――時には4つのリリースを公開しなければならないこともあるため――が、特にセキュリティリリースの場合、負担が大きすぎるからです。主にボランティアの貢献者たちにとって、大きなストレスとなっています。もう一つの問題は、メンテナンスの分岐があまりにも大きくなってしまうことです。 LTSリリースは最新バージョンとは大きく異なるため、修正をバックポートするのが非常に困難です。そのため、ボランティアだけで維持するには負担が大きすぎるほどの作業量になってしまいます。
そこで考えたのは、大幅な変更を伴うメジャーリリースを頻繁に行うのではなく、継続的に提供していくリリースの範囲を縮小してみてはどうか、ということです。そこで2027年には、Node リリースする予定です。これは、奇数バージョンとしては初めてLTSとなるバージョンです。つまり、年間1回のメジャーリリースに限定されるため、リリース担当者の負担が軽減されます。また、企業にとってもメリットがあると思います。メジャーバージョンの更新が2回から1回に減るからです。
マッテオ、それについて何かコメントはありますか？他に話し合われた事項はありますか？
ところで、いい点といえば、バージョン27が年号と一致するようになるんですよね？ 2028年に。
何よりも重要なのは、年次と整合させることです。
つまり、Node となり、Node LTSとなります。いくつか理由があります。根本的な理由はデータに基づいています。この決定は、他のどの決定よりも、実際のデータに基づいているのです。 非LTSリリースを実際に使っている人はいません。ほぼ皆無です。ですから、意味がありません。リリース担当者がこれらを公開するために費やす労力は、ごくわずかな人のためだけのものになってしまいます。また、モジュール作成者にとっては、テストやメンテナンスが必要なリリースが増えるだけなのに、その寿命はわずか6ヶ月です。繰り返しますが、それだけの価値はないのです。
オープンソースの世界では、どのプロジェクトにおいてもよく知られていることですが、コミュニティによる正式なLTS（長期サポート）の約束があれば、人々はそれを活用します。なぜわざわざLTSではないバージョンを選ぶのでしょうか？
ええ、その通りです。新しい機能を試してみたいという理由で利用する人もいます。新しいプログラムの構成上、大規模な変更や互換性を損なう変更を盛り込める長いアルファ版期間を設けています。ですから、最先端の環境で使いたいという方には、そちらをご利用いただけます。 今でもアルファ版はリリースしているので、その作業自体は行われます。ただし、大きな違いは、それらのアルファ版にはセキュリティ保証がないという点です。つまり、バックポートを行う必要も、その他何もありません。これにより、セキュリティリリースに必要な作業量が削減されます。現在、有効な報告が大量に寄せられていることを考えると、これは私たちの最大の懸念事項の一つなのです。
これが今回の議論におけるもう一つの重要なポイント、つまりセキュリティと脆弱性についてです。その話に入る前に、もう一つ重要な点があると思います。それは、半年ごとに多くの新機能が追加されているということです。単にCVEの修正だけではないですよね？そこで皆さんにお聞きしたいのですが、どうやって対応されているのでしょうか？ボランティアの方も大勢いらっしゃいますし、常に新しいAPIを追加したり、パフォーマンスを改善したりと……
正直なところ、その点を掘り下げてみましょう。パフォーマンスは向上しているのでしょうか？はい、多少は、おそらく。しかし、最大の懸念は、下位互換性を損なわないことと、ユーザーがアップグレードできない理由を最小限に抑えることです。それが主な原動力です。私がいつも言っているように、Node.jsを大幅に高速化することは可能ですが、そうすれば何かが壊れてしまうでしょう。 もっと高速化したいですか？そのために、どこまで互換性を犠牲にしますか？そういう問題があるのです。また、Node.jsとの互換性を40％や50％程度確保できれば十分だというケースもあることは実証済みです。実際にそうしているプロジェクトもあり、それで問題ないのです。しかし現実には、大規模なデプロイメントを行っている企業は移行しようとはしません。それは難しい。本当に難しいのです。
マルコ、他に何かある？
もう一つ言いたいことがあります。 ユーザーはアップグレードしていません。新規ユーザー層が増えるたびに、Node の利用率はNode ものの、彼らはそのバージョンから移行しないのです。まさに二極化が進んでいます。確認したところ、Node ダウンロード数は依然としてかなりの数に上っています。今でも月間2,000万回ほどダウンロードされているようです。一体なぜ、こんなものでテストしているのでしょうか？もう過去のものなのに。これは本当に問題です。
機能面では、新しいものを次々とリリースし続けています。しかし、実のところ、私たちはある程度非常に保守的です。もっと多くの機能をリリースすることもできたはずです。チームメンバーはもっと多くの機能をリリースしたがっていましたが、私たちは彼らが実際にリリースしたかった内容よりも、少し控えめな範囲に収めるよう努めました。
マルコ、何か付け加える？
信じられない話ですが、Node.jsコミュニティの皆さんには脱帽です。彼らは常に新しい機能を追加し続けているからです。現実問題として、下位互換性を維持し、内部実装に基づいて構築されたレガシーシステムやフレームワークを壊さないように――つまり、ユーザーに迷惑をかけないように――努めているのです。本当に信じられない話です。 単純なメジャーチェンジであっても、その影響があまりにも多くの人々やパッケージに及ぶ可能性があるため、機能を削除しないという判断を下すこともあります。本当の問題はエコシステムにあります。例えば、過去15年間npmに存在し、私たちが非推奨にしたい内部実装に依存しているパッケージがあります。しかし、そのパッケージはメンテナンスされておらず、週に5,000万回もダウンロードされているため、非推奨にすることはできません。これが、Node.Nodeが非常に保守的になりがちな理由です。 多くのAPIを非推奨にしたり、公開されてきたレガシーな内部実装を削除したりすることも可能ですが、実際にはできません。ですから、どのメジャーバージョンの変更履歴を見ても、もっと多くのものを非推奨にすべきだった、もっと多くのことができたはずなのに、それができないのだと常々思います。
皆さんの話を聞いて、このコミュニティとこのプロジェクトについて私が以前から知っていたことが改めて裏付けられました。つまり、これは非常にうまく運営されているプロジェクトだということです。ボランティアの方々、協力者の皆さん、本当に素晴らしい仕事をしてくれています。彼らは、可能な限り既存の機能を壊すことなく、このプロジェクトを維持し続けるという強い決意を持っています。 新しいバージョンがリリースされるたびに、互換性を損なう変更や非推奨となるAPIは発生しますが、そこには確固たる姿勢があります。そして、私の考えでは、Node.Nodeの成功の鍵であり、これほど多くの組織やアプリケーションがNode.jsを採用した理由です。つまり、正式なプロセスが確立されており、長期的なサポートへの確固たる姿勢があるからです。
それでは、セキュリティに関する話題に移りましょう。楽しい話ではありませんが、興味深く、時には悲しい状況でもあります。TSCのMateoが最近発表した大きな変更点の一つに、バウンティプログラムの一時停止があります。これについてはブログ記事で説明されていますが、読者の皆さんのためにここでコメントしていただければと思います。ただし、脆弱性の修正プロセス自体に変更はないことを明確にしておいてください。
問題は2つあります。まず、昨年初めから、脆弱性の報告に使われるAIによる粗悪なコードが信じられないほど大量に見られるようになりました。その規模は膨大でした。そこで、いくつかの事実が同時に当てはまります。Node.jsの脆弱性を報告する場合、Node ユーザーに影響を及ぼしNode 実質的にサービス拒否攻撃の「特効薬」となり得る脆弱性が報告される可能性があります。これは非常に深刻です。これが起こり得る事態の一つです。 あるいは、技術的には脆弱性ではあるものの、特定の環境下でのみ発生する脆弱性が見つかることもあります。まるで月と金星が一直線に並ぶような条件が必要で、それを引き起こす唯一の方法は、右足で3回、左足で3回ジャンプし、魔法の言葉を唱えることだけ、といった類いのものです。こうしたものが報告されているのです。
正直なところ、これらは紛れもない脆弱性です。そうではないと言っているわけではありません。ただ、これらはせいぜい些細な欠陥に過ぎず、より長い攻撃チェーンの中で悪用されれば攻撃者の侵入範囲を広げる可能性はあるものの、単独ではほとんど重要ではないということです。とはいえ、これらはCVEとして登録されているため、そのように扱う必要があります。しかし、コードベースの中からこれらを見つけ出すコストは、ほぼゼロに等しいのです。
そこで問題となるのは、彼らに報奨金を支払うべきか、ということです。費用を負担すべきでしょうか？私はトークンを消費してトークンを生成し、そこからお金を得ています。こう考えてみましょう。100ユーロ分のトークンを消費して、1,000ユーロの報奨金を得られるものを入手する――これは素晴らしい投資です。100ドルのサブスクリプションが、報奨金によって月1,000ユーロの収入に変わるのです。これだけで生計を立てられる人もいます。
しかし、これは私たちが奨励したり、維持したりすべきことなのでしょうか？もしスポンサーになってくれる企業があるなら、もちろん大歓迎です。私たちが選別を行い、その作業を引き受けることも喜んでやります。しかし現実には、もはやスポンサーはいませんでした。そして正直なところ、私たちはこの「雑な仕事」を止めたいと考えていました。この「雑な仕事」こそが最大の問題だったのです。なぜなら、多くの人々がこれを、報告内容に全く専門性が欠如した「手っ取り早い金儲けの手段」と見なしてしまうからです。 AIと対話すること自体には何の問題もありませんが、そのAIの方が、これまで目にしてきた多くの事例よりもはるかに有能です。実際に、プロンプトをそのままレポート内にコピー＆ペーストしただけの事例を目にしてきました。その「能力」は、正しくコピー＆ペーストすることさえできていなかったのです。
もちろん、AIについて話したいですね。聴衆の皆さんもAIについて話したいはずです。でもその前に、マルコ、もう一つ重要な点があります。報奨金プログラムが一時停止されたとしても、セキュリティ報告のプロセスには何の変化もありません。その点は変わりません。
そのプロセスについて詳しく説明していただけますか？受付やトリアージについてです。
ええ、報告の受付はHackerOneを通じて行っています。 HackerOneを通じて報告を受け取っています。その報告の優先順位付けを行っていますが、これはボランティアベースなので、時間のある人がその作業を担当しています。報告の数が非常に多いため、この作業に興味を持つ人は多くありません。また、現在、報告を作成する時間と優先順位付けを行う時間との間に不均衡があります。報告内容が事実かどうかを確認し、再現するには時間がかかります。これが最大の問題の一つです。
しかし、HackerOneで報告を受け取り、リリースを行うのに十分な数の報告が集まったら、例えば「2週間後にセキュリティリリースを行う」といった発表を行います。その間、社内でそれらの脆弱性に対するパッチを作成します。 また、更新版と同時にリリースできるよう、いくつかのリリースを調整する必要があります。これが最も大変な部分です。なぜなら、脆弱性を修正する担当者とリリース担当者を一堂に集め、同時に作業を進めなければならないため、2、3人、時にはそれ以上の人員を調整しなければならないからです。そのため、セキュリティリリースがあるときは、非常に多くの作業が発生します。その数週間は、関係者全員にとって非常に多忙な期間となります。
それがスケジュールを変更した理由の一つでもあります。つまり、そうした期間の作業量を減らすためです。もちろん、言うまでもありませんが、レポートには情報が多ければ多いほど良いのです。もしすでに修正案をお持ちであれば、その内容をすべてレポートに記載してください。
修正プログラムが添付されることは極めて稀です。たいていの場合、それは不可能です。たとえ修正プログラムがあったとしても、ほとんどの人は添付しません。しかし、私たちはそれを歓迎しています。非常に優れたパッチがあることもあれば、そうでないこともあります。
このプロセスは機能していますが、一連の処理が連鎖しているため、非常に負荷が高いのです。Node.js組織内でNode がいくつかあります。特に「LLHTTP」という、私たちのHTTPパーサーがあります。このHTTPパーサーのリリースを行う必要があります――ちなみに、これは興味深い技術なので、いつかパオロに話してもらったほうがいいですよ。 とにかく、そのHTTPパーサーがあります。それから、Fetchや多くの新しいWhatWGベースのAPIに使用しているライブラリであるUndiciもあります。 私はUndiciのメインメンテナですが、Nodeセキュリティリリースが行われるたびに、多数のUndiciの修正が組み込まれます。現在Node 3つのLTSNode 、Node 、そしてアクティブなNode Node 、これらすべてに対してパッチを発行する必要があります。Node Undici 6を使用しており、他のバージョンにはそれぞれ独自のバージョンがあります。
このコミュニティや貢献者、協力者たちが注いでいる労力は計り知れません。そして、Node.Node、TypeScriptなどを活用して本番環境を運用している組織は数え切れないほど存在します。だからこそ、HeroDevsのような企業は、こうしたコミュニティに還元し、貢献しているのです。単に支援するだけでなく、コミュニティの一員となることで、多くの専門知識や経験を得ることができるのです。
さて、AIについて話しましょう。もちろん、みんなAIの話をしたがるでしょうから。 世の中には新しいツールが山ほど出てきて、そのAIの「ごちゃごちゃしたコード」に起因する脆弱性を報告する人もいます。でも、マルコ、君もその件について素晴らしいブログを書いていたけど、単に報告するだけじゃなく、文脈と知識こそが最も重要だって話も聞きました。でも、実際に状況は良くなってきているという事実についても話したいんです。たぶん今や、これらのLLMから本当の脆弱性が報告されるようになってきているんじゃないかな。
その通りです。本当に脆弱性が見つかりました。これは現実の問題です。LLMの機能については、その多くは依然として単なるバグに過ぎませんが、今では真の脆弱性さえ存在しています。その発生率は大幅に増加していると思います。前回確認した時点では、以前の50％から66％に上昇していたと思います。 一時は非常に深刻な状況でしたが、その後回復しました。これまでのところ、報告される問題のほとんどは十分に説得力があり、デバッグが容易ではないものばかりだと言えます。些細な問題はすでに文書化されています。私たちは、セキュリティMDにおいて、優れた脆弱性とそうでないものを区別する基準をすべて文書化する取り組みを進めています。
Node.jsはMitreと関係があるのでしょうか？
残念ながら、まだです。アクセス権を申請しましたが、今のところ許可されていません。いずれ許可されるはずです――これは主要なオープンソースプロジェクトの一つですから。とはいえ、たとえアクセス権がなくても、LLMが報告する課題には改善が見られます。そして、私が読んでいて非常に興味深かったのは、人間の能力を超えて、複数の脆弱性を連鎖させ、現実世界でのエクスプロイトを作り出せるという点です。
そうですね、そこが難しいところなんです。そこが「新しさ」――つまり、その一点に集約される部分なんです。場合によっては、それ単体では深刻度が「低」や「中」程度のCVEでも、他のCVEと組み合わさることで、極めて深刻な問題に発展することがあるんです。
マルコ、一つ聞きたいんだけど。新しいCVEが公開され、脆弱性に対する修正プログラムも提供されるわけだけど、そのたびに、サポート終了済みのバージョンに対してもパッチを適用しなきゃいけないよね。その作業には、具体的にどんな手間がかかるの？
ええと……私が「Node 、Node 、Node 作業している」と言うと、他のメンバーは「えっ？」って顔をするんです。Node 、依存関係がかなり古いため、かなりNode 。もう一つの大きな問題は、これらの古いバージョンがどれほどセキュリティ面で脆弱かということです。そういうことはよくあります。 そして脆弱性を修正している時、私はいつも自問します。「6、7年前、私たちは一体どうやってこれを使ってやっていけたんだろう？」と。なぜなら、開発を進めていくにつれて、多くの脆弱性やバグが見つかるからです。新しいセキュリティリリースが公開されるたびに、私はそれがサポート終了済みのバージョンにも適用されるかどうかを必ず確認しますが、ほとんどの場合、適用されます。つまり、開発が進んでも、古いバージョンにはまだバグが見つかるのです。信じられない話です。
聴衆の皆様に明確にしておきますが、長期サポートの終了とは、アップストリームからの修正が提供されなくなることを意味します。Node の場合、HeroDevsのような商用サービスを利用する必要があります。これは明らかに大きな課題であり、プロジェクトが前進し続けること、そして率直に言って、可能な限り迅速に前進することは、極めて理にかなっています。もちろん、それには移行や互換性の破綻といった課題も伴います。 また、先ほどMatteoが言及していたように、企業や組織が必ずしも移行しているわけではないことがわかります。彼らはバージョン18や20、あるいはそれより古いバージョンを使い続けているのです。
マルコ、これは本当に大変な作業だよね。君やHeroDevsの他のエンジニアたちは、その開発やテストに多大な労力を注いでくれた。実は、それについて君たちに聞こうと思っていたんだ。リリースごとに、とんでもない量のテストが必要になるはずだけど、どうやってこなしているの？
はい。リリース作業で最も大変なのは、CIを通過させることです。非常に多くの特殊なプラットフォームでテストを実施しています。また、「Canary in the Goldmine」と呼ばれる仕組みがあり、リリース候補版をエコシステム内のnpmパッケージに対して実行し、パッケージに不具合が生じないことを確認しています。数時間かかるCIジョブが山ほどあります。1つでも失敗すると、再実行して数時間待たなければなりません。かなり面倒ですが、重要な作業です。
それは決して過ぎ去らない。
この問題は一向に解決しない。ある時期、私は文字通り信頼性の向上に取り組んでいた。毎日、不安定なテストがいくつあるかを示す信頼性レポートが届くのだが、しばらくの間はそれらにパッチを当て、そのレポートをAIに読み込ませていた。PRの質があまり良くないという不満の声もいくつかあったが、少なくとも私は改善しようとしていたのだ。そして、私はそれをやめた。しかし、問題は非常に厄介で、そうした修正をマージすることさえ難しい。単純な話ではないのだ。
ええ、本当に大変な作業ですね。リリース作業に携わる開発者なら、誰でもその気持ちはわかるはずです。
最後に、もう一点お伝えしたいことがあります。先日ロンドンで、Node.jsコミュニティが集まる会合が開催されました。そこでは数多くの取り組みについて議論が行われ、その際に今回のリリーススケジュールの変更が発表されました。マルコさん、マッテオさん、Node.jsの今後の展開について、何か付け加えることはありますか？例えばセキュリティの面では――CVE報告件数の増加への対応に関して、他に何かニュースや変更点はありますか？
私はOpenJS Foundationの理事も務めており、現在、報奨金プログラムの開発費用を負担してくれると申し出てくれたベンダー各社と協力しています。 私たちは、ベンダーにとってプログラムを支援し、見返りを得られる合理的な仕組みであると同時に、メンテナーにとっても時間を費やす価値があるような仕組みを模索しています。比較的簡単に解決できる問題に報奨金を設定すれば、それは文字通り「一攫千金」のスキームになってしまいます。報奨金は、おそらく重大かつクリティカルな脆弱性にのみ設定すべきでしょう。
正直なところ、こう考えることもできるでしょう。「この大金を使って、トークンを燃やし、自分たちですべての脆弱性を発見しよう」と。もはや数字の勝負になってしまっているのです。 本当に、確かな実証に基づいた研究を行い、何百万人もの人々に影響を与えうる重大な問題を発見した研究者には、多額の報奨金を贈りたいと心から思っています。実際、そうした事例もいくつかあり、中には非常に高額なものもありました。しかし、通常はごく些細なエッジケースだったり、あるいはCDNやロードバランサーの背後にnode 置かない場合にのみ成立するようなケースだったりします。率直に言って、現時点でそのような環境にある人は誰もいないでしょう。
あるいは、誰かがインスペクタープロトコルの問題を報告し続けている。 私たちは至る所で書いてきました：インスペクタープロトコルを使用する場合は、自己責任で利用してください。これらは開発用のデバッグツールです。本番システムでこれを開放したままにしないでください。それなのに、人々はこれを攻撃シナリオとして報告し続けています。しかし、文字通り、これをセキュリティで守ることは不可能です。セキュリティを確保する方法などありません——これは文字通り、誰かがnode 乗っ取れるように設計されているのです。不可能です。
以前、アプリセキュリティの仕事に深く関わっていた頃、私はよくこんなプレゼンをしていました。「世の中には何百万もの脆弱性が存在します。しかし、公開されているエクスプロイトの方により注意を払うべきです。とはいえ、そうしたエクスプロイトでさえ、たいていはごく些細なものなのです。」
前回のセキュリティ関連の記事で取り上げた、Undiciにおける脆弱性についてお話ししましょう。Node.jsには、仕様書に基づいたWebSocketの実装が組み込まれています。あまり優れた標準とは言えませんが、それはまた別の話です。 とにかく、WebSocket規格にはパケット圧縮を行うオプションが用意されています。WebSocketパケットはTCPの上に独自のフレーム構造を持っているからです。つまり、HTTP、WebSocket、そしてその上に独自のフレーム構造が乗っている形です。そして、これらのパケットを圧縮することができます。私はそのことを知りませんでしたが、私たちの実装ではこれをサポートしています。
そして、何らかの理由で信頼できないリモートWebSocketインスタンスにNode.jsを使って接続すると、そのサーバーから「シルバー・バレット」と呼ばれるパケットが送信され、サービス拒否（DoS）を引き起こしてアプリをクラッシュさせてしまうことが判明しました。これは、例えば100キロバイトのデータがメモリ内で100ギガバイトにまで膨れ上がり、アプリがクラッシュしてしまうためです。実に簡単です。
そういう事情があったわけです。そしてもう一方の側面として――ここでもUndiciの話になりますが――これは明示的に有効化しなければならない機能だということです。この脆弱性が生じるのは、実験的な機能を有効にし、手動でそれを有効にするコードを書いた場合に限られます。つまり、その範囲はこうなります。一方では、悪用するのは難しいのです。 リモートWebSocketサーバーを入力として受け入れるWebSocketに接続するアプリケーションが必要であり、そのために影響範囲は非常に限定的です。
本当に、本当に細かいところまで行き届いています。私にとって、それこそが、このプロジェクトとすべてのボランティアがこのエコシステムにもたらす価値なのです。
質問をざっと目を通してみましたが、ほぼ網羅できたと思います。AIに起因する脆弱性の種類に関する質問もありましたね。最後に一言だけ言わせていただければ、「楽しい時間はあっという間」ですね。この話題なら、あと2、3時間は話し続けられたことでしょう。
参加者の皆様にとって、今回のウェビナーが有益なものだったことを願っています。今後もこのようなウェビナーを開催していく予定です。改めて申し上げますが、HeroDevsはOpenJS Foundationの「エコシステム・サステナビリティ・プログラム」の創設メンバーです。私たちはオープンソースコミュニティを支援すると同時に、サポート終了版（EOL）Nodeまだ運用している組織向けのビジネスも展開しています。バージョン12からのサポートを行っていますが、マルコ、合っていますか？
12歳、14歳、16歳、18歳、そして今は20歳。
また、サポート終了を迎える前に準備を整えたいお客様向けに、バージョン22および24のカスタム版もご用意しております。
素晴らしいですね。さて、マッテオさん、マルコさん、ご参加いただき誠にありがとうございました。お時間を割いていただき感謝しています。またお話しできるのを楽しみにしています。ご覧いただいた皆様、ありがとうございました。それでは、また。さようなら。
