00:06
はい、みなさんこんにちは。 keethことくわはらです。
本日もやっていきましょう。 keethのエンジニア雑談チャンネル。
この番組では、ウェブ業界やエンジニアリング、 いろんな技術についての情報を
雑談形式で発信していきたいと思います。
で、今日は、だいぶ前に読んだ、
NPMのモジュールですね、 全部に依存するeverythingっていう
ライブラリを作って公開した人の事件の話があって、
その中で言及されていた left-pad事件っていうのがあった
っていう話ですけど、 私がこれを知らなかったので、
これ、そもそもどういう事件なの? っていうのを調べていて、
それを見て、いろんな記事とか、 いろんな考察が書かれていて、
確かになって思うところがあったので、 紹介がてら振り返っていきたいなと
思っております。 まあ、みなさんの方でも
普通にググっていただければ 出てくると思うんですけど、
left-pad事件っていうやつですね。
えーと、作った方がですね、 ちょっと読み方がわかんないですけど、
今回はアザーさんと呼ばせていきます。 ごめんなさい、雑で。
そのアザーさんという方は、 われわれと同じソフトウェア開発者ではあります。
当時ですね、彼はノードJSで パッケージをいろいろ作っておられて、
273個もパッケージ作成者であると。
それはNPMにも公開したっていうお話ですね。
その中に彼が作っていた left-padっていうライブラリがあるわけですね。
left-padっていうのは名前の通りで、
文字列の左を指定の文字で 何文字分埋めるみたいなやつですね。
まあそういう簡単なライブラリです。
ソースコードにして実に11行だけの ただの1関数なんですけど、
細かい関数とかももうパッケージとして 公開をしていたというので、
それを含めて合計273個というふうになっているので、
厳密にライブラリを作ったというよりも、
チップス的な関数をひたすら 公開しまくったというような感じですね。
最近はそういうものといえば、 ローダッシュ的なものもありまして、
他にもいくつかそういう ユーティリティの塊みたいなライブラリがあるので、
そちらに集約されたりとかありますし、
そういう枝派の関数は、
エクマスクリプトとかTC39とかで議論されて、
JavaScript本体の方にも 組み込まれるという話は全然あると思うので、
そことの関係性だったり、
そこが対応してくれるようなライブラリに 依存しなくても良いという話は出てくると思います。
で、彼が作った273個のパッケージの中に left-padっていうものがあったんですね。
そのleft-padっていうのは、
これに依存するライブラリが実はいっぱいあって、
その中の一つにline-numbersライブラリがあるらしいですね。
line-numbersっていうやつです。
このライブラリがleft-padに依存をしてたんですけど、
このline-numbersに依存する 数千のパッケージが他にもありまして、
例えばバベルとかアトム、エンバー、リアクトネイティブなど、
名だたるフレームワークとかライブラリが このline-numbersに依存していて、
そのline-numbersが left-padにも依存していたというところですね。
で、ある時ですね、そのAzawaさんはKickっていうライブラリも作ってた。
03:03
で、それも公開したらしいですね。KIKです。
はい、で、KIKを公開してたんですけど、
KIKは小文字です、すべて。
なんですけど、頭大文字のKIKっていう企業が、
実は同盟の会社がいまして、
この会社がですね、
2億7千万のユーザーを持つメッセージアプリケーションを 開発してたらしいですね。
で、もちろん名称も自分の会社の名前でやって、
多数の国でしかも商標登録までしていたというところです。
ここでバッティングが起きたっていう話ですね。
会社の方のKIKも自分たちのパッケージをNBM上で、
自分たちの名前でリリースをしようとしたんですけど、
すでに同じ名称のもの、Azawaさんが作ったKIKっていうものがありました。
で、会社側の方はAzawaさんに連絡を取って、
問題をオンビーに解決する方法を探ろうとしたわけですね。
が、まあ決裂をしたと。
合意に至ることがなくて、
会社側の方のKIKはこの問題を、
いわゆる紛争解決を通じてやろうとしたというところですね。
あーちょっと辛い解決策に至ろうと。
ディスピュートリソリューションっていうやつですね。
ちょっとこれに対してまた別の記事のリンクがあって、
それはNBMにDocsとして公開もされてます。
ディスピュートリソリューションっていうページがあるんですけど、
ちょっとここを読んでいくとまだ長いので、
後ほどディスクリプションにこの記事のリンクも貼っておきます。
まあこの方法をNBMDocsが出していて、
それに従って解決をしようとしたというところですね。
で、そのNBMのユーザーたちが会社側のKIKの方を支持した。
それはだいたいユーザー数が多いからっていう理由で、
会社側の方を支援したというところです。
まあここは難しいですね。
トロッコ問題と同じ感じはちょっとします。
何を優先するかというところですね。
まあ人の命に関わるものではないですけど、
ライブラリの命というところで、
どっちを取るかでユーザー数が多いからっていう理由を
NBMの人たちは取ったというところですかね。
一応NBMが声明も発表してまして、
そこもちょっと拝見させていただいたので読ませていただきますと、
ポリシーの重要な目標はこれですと、
NBMユーザーが期待するパッケージを提供すること。
これにはスパム、タイプミス攻撃ですね。
誤解を招くパッケージ名。
さらには今回のようにより複雑なケースも含まれております。
この基準に従って私たちはキック。
全部小文字の方ですね。
のキックというパッケージ名は大文字の方のキック。
会社の方ですね。
のキックが維持すべきであるという結論に達し、
その旨を両者に通知しました。
KIKという名称をめぐってめぐり合う2つのパッケージがあると、
NPMインストールKIK、キックですね。
と入力したユーザーの多くが、
2億人のユーザーを持つメッセージングアプリとは
無関係の行動を受け取って、
困惑を覚えることになってしまうでしょう。
というので、マジョリティの方を取ったというのがNPMの態度です。
で、NPMJSはパッケージ名の所有権を
会社側の方のKIKに譲渡することを決定したと。
で、このアザラシはこの結論に正直納得をしてなくて、
次のように呟いておりますと。
この状況からNPMが特定の個人の所有物であって、
06:02
そこでは一般人よりも企業が力を持っているということを
申し知らされました。
ですから私は人々にもっと力を与えてくる
オープンソースを実践することにしたのです。
というところで、彼は自分の作ったKIKや
LeftPadを含む自身の273個のモジュールを
全て非公開にしちゃったらしいですね。
で、これが冒頭の事件に繋がったと。
で、個人的にはこれだけを読むと、
KIKというか、アザラシが出すかKIKが出すか悩ましいですけど、
企業側の方がオーガニゼーションのユーザーの中の
KIKというライブラリ名にすればいいんじゃないか
と思ったりしますね。
もちろんそのKIKという文字だけで、
名前だけでライブラリを公開することもできますけど、
アットユーザー名スラッシュモジュール名みたいな
公開の仕方もできるんですね。
多くのライブラリがそういう公開の仕方を
されていると思います。
自身のフレームワークが非大化したり、
パッケージに切り分けたりすることができると、
メインのなるものはコアなものとその他
サブモジュールという風に切り出して公開する。
で、インストールの仕方はそれを都度やるか
コアなもの一体をインストールするとか
いう方法ができるので、
その選択をしてもよかったんじゃないかと思いますけど、
彼らはKIKという名前だけのバッティングで
争ってしまったというところですね。
で、NPMは大多数の方を取って、
アザラシが全部公開にしたというか削除をしたと。
で、ここで何で問題になったかという話なんですけど、
LeftPadというソースコードは
いろんなところで既に公開されていますし、
JavaScriptの標準機能にもなっているので、
使う必要は正直ないんですけど、
当時そういう標準機能がなかったので、
自社たちで作るしかないんですけど、
難しいですね。
作ってあるものをいろんな全世界の人たちが
同じようなコードを毎回毎回書くぐらいだったら
ライブラリとかパッケージとして公開をして、
皆さんが書かなくても良いようにするというのは
思想としては理解はできますが、
たかだか11行のソースコードのために
皆さんが依存をして、で、その本体の人が
NPMから削除したせいで
ビルドが通らないというので、
全世界が混乱したという今回のLeftPad事件が起きるという
状況もあって、
ここが結構根深い問題だなというのはすごくありますね。
はい。こういうエコシステムに依存するというところの
脆弱性が露呈したなというところはあります。
またそのLeftPadのソースコード、
自分も見させていただきましたけど、
単純に文字列を左埋めするだけなので、
正直5分もあれば書こうと思ったら書けるはずですし、
今はチャットGPTとかあるので、
AIとかにそういう左埋めする関数書いてって言ったら
一瞬で書いてくれると思います。
なので別に依存することはないとは思っているんですけど、
結果その当時の世界では多くの人たちが
そのソースコードに依存をしまくってたというところがあるわけですね。
これを見ていろんな思うところがあるんですけど、
一つは他者依存をするっていうのが
当たり前すぎる文化は果たしどうなんだろう
っていうのを改めて思い知らされましたね。
09:01
そんな方の記事を書かれている方もいらっしゃって、
例えばバベルとかをインストールすると、
依存するライブラリーですね、ノードモジュールズの中って
実は4万ものモジュールに依存してるんですよね。
たかだかバベル1個インストールしたいだけなの?
っていうので、それもそれでどうなの?っていう話が一つあって、
だから僕も当たり前のように
NPMインストールホゲホゲって叩いて、
ノードモジュールズがインストールされるのを見てるのを
ずっと何年間もやってきたんですけど、
確かに依存関係のライブラリーがそんな大量にあるということは、
誰か一人がそうやってやっぱやめたとか、
もう公開しませんとかになったらいきなり動かなくなるっていう
そのリスクをそんだけ広めているっていうのは事実としてあるわけですよ。
果たしてではそれはどうなの?っていうのと、
それは本当にコーディングなのかっていう話はありますよね。
プログラミングとはソースコードを書くことではなく、
いろんなパッケージを上手いことがちゃんと組み合わせて
アプリケーションを作ることなのかという話が出てきてて、
それは確かに違うんじゃないっていう気もしますね。
もちろん無駄なコードを書かなくていいとか、
同じようなコードを別のプロジェクトでまた同じように書くっていうのは
時間がもったいないのは確かにあると思います。
あるんですけど、でも依存度を上げるということは
リスクも上がるっていうことは承知の上で、
たかだか10何行のコードだったら自分たちのほうでスニーペット化して
自分たちのチームとかコミュニティの中で
管理すればよくないって話は別であると思います。
そういうようなものが本当にたくさんあるし、
今回はレフトパッドって11行のソースコードですけど、
もっと短くて小さいスニーペット的な関数のライブラリっていう
世の中に本当にたくさんあるらしくて、
僕も全然調べたことがなかったんですけど、
いろんな方々が調べてます。
それは今の流れとか思想ってどうなんだろうっていうのを
すごく語られてて、
これを脆弱性と言ったらまあ確かに脆弱ではありますよね。
コミュニティとエコシステムとOSSの脆弱性とはあると思うんで。
いやー難しいですよね。
他者が同じことを書かなくてもよいっていうのはありますけど、
さっきAIの話を出したんですけど、
AIに聞いてコードを書く時代っていうのは
今後もっともっと加速するでしょうし、
JAPGPTをはじめ、リング、パワード、
あとコパイロットですよね。
コパイロットがかなり強くなったっていうのが正直あるので、
彼らが学習した範囲の中で勝手にソースコードを
サジェッションしてくれるじゃないですか。
いうのがあるので、
再利用するっていうことの価が下がったっていうのもあるので、
ライブラリーに依存しなくてよくないっていうのは
すごくあると思いますね。
はい、っていうのと、
もう一個僕的に思ったのは、
考えなくなるっていうのは果たして、
エンジニアというかプログラマーとしてどうなんだろう
っていうのはすごく思いましたね。
昨今僕がプログラミングをしない仕事にどんどんシフトして、
組織コミットすることになったんですけど、
やっぱ書かないとバンバンプログラミング力って
下がるなってすごく感じて、
今改めてプログラミングの筋トレを始めたんですね。
1日1回、5分か10分程度でいいので、
自分に縛りを設けてこういうコードを書きましょう
みたいなことをやってます。
12:01
例えばですね、
昨日の夜やったのは、
日本だと数字って3桁区切りでカンマつけるじゃないですか。
で、あれを一発でやろうとしたら、
なんだっけ、
2ロケールストリングっていう関数がすでに
Javascriptがあって、
ぶっちゃけそれを使って日本のロケールストリングで
やってしまえば一瞬でできるんですけど、
それをあえて自分で自前でやってみよう。
確かに5分くらいで書けたんですけど。
でも久しぶりにそういうアルゴリズムっぽいことをやると、
自分の能力下がってるなってちょっとツクツク感じたので、
空気のトレは改めてした方がいいなっていうのはちょっと思いました。
コードを書く側の人間としてはですね。
で、実際のプロジェクトではそれを別にしなくてよくないは正直思うんですし、
これは思想の違いではあるんですけど、
私はあんまこの程度だったら依存しない方が良いんじゃないかという思う派ですね。
やるんだったらそのプロジェクトのチーム内とか、
どうせGitHubとかリポジトリで管理をするので、
リポジトリのウィキとかにまとめるとかですね、
共通のチップスとか、
もしかもユーティルズという関数からディレクトリに放り込んでおいて、
それどうっていうのをチームにプルリク投げて、
相談するのがいいんじゃないかと思ったりします。
やはり難しいものとか、結構複雑なもの、
コアなものとかを自分たちがガチャガチャ再開発をする、
もったいないっていうところを他のOSSとかのライブラリに依存するならまだわかります。
けどその辺のもう誰か考えてもすぐ書けるようなものとか、
わかりやすいものに関して依存するっていうのは、
僕もなんか良くないなって正直思いましたね。
で、レフトパッド事件を見ながらそれを感じていたというところですね。
びっくりしたのは、さっき名前出したバベル、アトム、エンバー、リアクトネイティブなど、
7タルライブラリ自体が最終的にはその末端で、
そういうライブラリ、レフトパッドに依存をしていたっていうのがすごく、
そういう状況だってあったのは仕方ないんですけど、
LINEナンバーズというライブラリがそれに依存するのは果たしてどうなんだろうっていうのはちょっと思いましたね。
OSSですし個人開発の域を出ないので、
どこまで依存をするかはもう本人次第だし思想の違いではあるんですけど、
LINEナンバーズというライブラリを作った開発者が、
どなたか私は存じ上げないんですけど、
こんだけ全世界のライブラリに使っていただけるみたいな世界は、
もしかしたら見ていなかったのかもしれないですね。
見ているというか、だんだんそういう状況はOSSの開発者としては知っていくわけなので、
知る中で依存度っていうところはどうなんだろうっていうのは考え直してもいいかもしれないですね。
もし皆さんが自身で作られているライブラリがあるんであれば、
自分の作っているライブラリの影響度っていうのはしっかり見直しを図って、
ソースコード破綻した時どうでしょうっていうのは考え直すのは一つ。
定期的にやるのは全然いいのかなとちょっと思いましたね。
というので今回はOSSとかエコシステムの脆弱性に関する一つの問題定期、
大きな事件だったっていうのを振り返りつつ、
自分のソースコードとかOSSの振り返り的に使ってみた感じですね。
参考になれば幸いですし、
15:00
改めて皆さんの方でもF2Pad事件の記事とかブログを読んでいただいて、
思うところあると思いますよと考えていただければなと思ったりしました。
今回はこんなところで終わっていきたいと思います。
いつも聞いてくださり本当にありがとうございます。
ではまた次回の収録でお会いしましょう。
バイバイ。