人気のある npm パッケージ event-stream (DL数: 2M/週) が悪意ある攻撃に利用されるというセキュリティ インシデントがありました。 私が管理する npm-run-all (DL数: 440K/週) も間接的に event-stream に依存していたため、インシデントの詳細と私の対応について触れておきます。 何をすべき? あなたのプロジェクトが event-stream に依存している場合は、この依存を削除し、代替手段を探すと良さそうです。event-stream の作者は、このパッケージをメンテナンスしないと明言しています。ただ、これだけ騒ぎになったので、信用できる誰かが引き継ぐ可能性はあります。 [編集(2018/11/30)] 現在は npm 社がパッケージ管理を引き継いでいます。ただ、リポジトリは凍結されており、今後変更されることはないでしょう。 次に、あな
概要 event-streamというnpmパッケージに攻撃コードが混入されました。攻撃コードはflatmap-streamというパッケージに含まれており、event-stream パッケージはこの flatmap-stream への依存性を追加される形で間接的に攻撃コードの実行を行う状態になっていました。 攻撃コードが分析された結果、copayというBitcoinウォレットからクレデンシャルを盗むことを目的とされていたことが確認されています。 参考リンク 調査が行われているGitHub Issue HackerNewsスレッド Details about the event-stream incident - The npm Blog 影響をうけたパッケージ event-stream@3.3.6 flatmap-stream@0.1.1 flatmap-stream@0.1.1 パッケージ
きっかけ 「xxxx.lock」(以下lockファイル)みたいなファイルを作るパッケージ管理システムと、作らないものがありますよね。 作る側の例 : Gem(ruby)、cocoa-pods(iOS)、昔のcarthage(iOS)、YARN(js) 作らない側の例 : maven(java系)、最近のcarthage(iOS)、npm(js) 作る側を使っている人たちは、ほとんど「Gemfile.lockをgitにcommitしましょう」という旨の主張をしていますが、 ただ、cocoa-podsを使っている人たちの一部(2割くらいかな？)は、 「Podfile.lockをgit-ignoreするべきだ」という旨の主張をしています。 そこで、lockファイルを作る/作らないの違いと、gitに入れる/入れないの主張の違いが気になって調べて見ました。 そもそも、なぜlockファイルが必要なのか
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 追記：2017/07/12 gist連携時の理解が間違ってたので修正 npm 5.2リリース。npmパッケージのダウンロードと実行を一度に行うCLIツールnpxが同梱された / “Release v5.2.0 (2017-07-05) · npm/npm · GitHub” https://t.co/2CXccPBqcq — Teppei Sato (@teppeis) 2017年7月11日 へー、と思って見に行ったら結構面白かったので雑な紹介を書いてみることにする。 v.5.2.0 リリースノート npxの紹介記事 この記事は紹介記事
絶対に忘れる自信があるので今のうちにメモっておく。 Lerna is 何 Lerna はmonorepoを管理するためのツール Babelのように、単一レポジトリで複数のnpmパッケージを管理できる レポジトリ内パッケージ間の依存関係をsimlinkにより解決してくれる（勝手に npm link してくれるイメージ） やりたいこと 開発者がmasterへコード修正commit(PRのmergeなど) CIでテスト実行 開発者がリリース意思表示 CIでリリース実行 lerna publish が実行されて、npmへpublish完了! 今回はCIサービスにはCircleCI(2.x)を選択。 特にCircleCIにこだわっているわけでもなく、workflow的な仕組みが備わっているCI Serviceであれば問題ないはず。WerckerCIとか。 準備 lerna publish は下記を逐
タイトルに要素を詰め込みすぎましたが、要は CircleCIを使ってbundle updateを定期実行する - Qiita の npm update 版です。web appのJavaScriptライブラリ管理にnpmを使うとき、依存関係のアップデートを継続的に行うためのツールです。 https://github.com/bitjourney/ci-npm-update これはいまのところGitHub専用です*1。CIサービスはドッグフーディングも兼ねてCircle CI用の起動スクリプトを同梱してますが、実際には ci-npm-update を定期実行するだけなので簡単に代替可能です。 これはCircle CI + Heroku Schedulerで動かしていて、以下のようなフローです。Circle CIはJenkins含め他のCIでも動かせますし、Heroku Schedulerはcr
npmrcのドキュメントを読みなおしていたら、.npmrcは/path/to/my/project/.npmrcのようにプロジェクト毎に配置することが出来る事に気づいて、ちょっと使ってみたら便利だった。 globalやhomeディレクトリへの設定を前提としたnpm configの記事は結構あるが、プロジェクト毎でnpm-configについて書かれている記事があんまり無かったのでまとめてみる。 npm-configの何が良いのか？ project毎に出来ると何が良いのか？ npm-configの設定をすると、色々コマンドを省略出来たりして良い事がある。 (参考:2016年版 Node.jsで幸せになれる10の習慣) npmrcやnpm-configは、個人開発用であれば、$HOME/.npmrcへの設定だったりnpm config setでの設定で十分。 また、npm registryに登録
npm shrinkwrap とは? npm shrinkwrapは、Node.jsプロジェクトの依存モジュールのバージョンを固定するコマンドです。 使い方についてはこちらの記事が参考になります。 今回は、npm shrinkwrapをより安定して使うためのコツを記載しました。 1. CIを活用し、テストしたバージョンで固定しリリース npm shrinkwrapコマンドではnpm-shrinkwrap.jsonというファイルが生成されます。 継続的インテグレーションのサービスを活用し、そこでテストしたバージョンで固定するとよいでしょう。 CIでのフローとすれば以下になると思います。 npm updateで、可能な限り新しいバージョンを利用 テスト (npm test) npm shrinkwrap npm-shrinkwrap.jsonを追加しコミット、別tagや別branchとしてpu
Electron を試す 7 - Electron v1.0 対応で npm-scripts に環境変数を定義してそれを scripts 内から参照する方法を書いたのだが、この方法は Windows 環境だと利用できない。 と、これだけで話を終えるのはもったいないので、私がおこなった調査や見解についてまとめる。 2016/5/19 追記 本記事の問題を解決するための npm を作成した。詳しくは npm-scripts でクロスプラットフォームに環境変数を参照するための npm を作成してみたを参照のこと。 package.json の config package.json に config の説明がある。 A "config" object can be used to set configuration parameters used in package scripts that
さいきん個人でNode.jsを使って、ちょっとしたWebツールを作っているのですが、作るものがそこそこの規模になってくると、どんどん依存するnpmモジュールが増えていきます。 (npmのモジュール粒度問題みたいな形で、少し前に話題にもなりました) 加えて、これまた最近話題になっていましたが、Webフロントエンドにはライブラリやツールが乱立している、ということで、Web開発をしていると、何を使うべきかの判断に迫られる場面が数多く発生するように思います。 READMEを読んだり、実際に使ってみたり、コードを読む等して、一つ一つ判断していけると良いのですが、npmのような粒度で依存モジュールが増えていくと、中々にしんどいものがあります。個人で気楽に作っているツールなら尚更です。 手っ取り早く確認できそうな指標としては、DL数やGitHubのスター数、誰(どこ)が作っているのか、誰(どこ)が使って
https://www.npmjs.com/package/what-do-i-depend-on github.com 先日のleft-pad騒動で、自分のプロジェクトのnode_modulesを慌ててチェックした。 普段依存の依存とかまったく意識してないけど、いざ見なおしてみるとその数の多さにビックリする。 全ての依存を把握するのは正直無理だけど、ざっと見てみるだけでも発見がある。 意外とscoped packageが使われてたり。めちゃくちゃミニマルなパッケージが人気だったり。 babel関係のパッケージが多すぎて目眩がしたり。 というわけで、自分のプロジェクトの依存パッケージを再帰的に調べて、依存度合いをチェックするツールを作った。 node_modules/ 内の package.json を再帰的に調べて、パッケージが登場した回数を表示する。 使い方 インストール npm i
npm公式のレポート : http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm uasiさんによる日本語まとめ : http://uasi.hatenablog.com/entry/2016/03/23/215308 状況 npmによると、元@azer氏のパッケージは全て安全なものらしい 悪意のあるユーザーに取られないよう、有志が事前に確保しといてくれてた npm直轄のパッケージにするよう交渉中 ただしビルドが壊れうるという状況は変わっていない 例: after-time after-timeはnpm直轄となり、'0.0.1-security', '1.0.0' の2つのバージョンが配信されている プロジェクトが after-time@0.0.1 に依存していた場合、一からビルドすると壊れる すべきこと https://g
（最終更新：3月24日16:50ごろ） 事件の流れ kik の作者が同名の会社 KIK の弁護士特許出願代理人からパッケージ名を変更するよう要請される 作者が拒否したところ弁護士代理人は npm の運営にコンタクトする 運営が作者の許可なくパッケージを unpublish するパッケージの所有権を移し替える 作者がこれに反発し自身が所有する270あまりのパッケージをすべて unpublish する I’ve Just Liberated My Modules — Medium unpublish されたパッケージは npmjs.com からダウンロードできなくなる unpublish されたうちのひとつである left-pad に間接的に依存したパッケージが多数あったため世界中でビルドがぶっ壊れる npmjs.org tells me that left-pad is not availa
無駄にラノベみたいに長いタイトル書いちゃったんですが、まぁやっぱり一言くらいは残しておくかと思ったので書きます。長いのでまとめだけでも見てもらえると良いかもしれません。 leftpadの話はかなり大事になっていて、Node.js界隈を中心としてその他のOSSをやっている全体的に話が波及しています。幾つかの記事を読みました。今回はJSの文化と歴史についてちょっとずつ書いていこうかなと思います。 本の虫: npmからkikとその他諸々が消されたまとめ 江添さんの話はすごくよくまとまっていて、ネタも含めた上で一番面白い話になっていました、ここで言われている下記の疑問に答えていこうと思います。 もっと憂うべきパッケージがある。isArrayだ。このパッケージは一日88万回もダウンロードされていて、2016年2月だけの一ヶ月間に1800万回もダウンロードされていて、72個ものNPMパッケージが依存し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
