The massive bug at the heart of the npm ecosystem
Disclosure: I was the Staff Engineering Manager for the npm CLI team between July 2019 & December 2022. I was a part of the GitHub acquistion of npm inc. in 2020. I left GitHub, for various reasons, in December. tldr;a npm package's manifest is published independently from its tarballmanifests are never fully validated against the tarball's contentsthe ecosystem has broadly assumed the contents of
JSR: the JavaScript Registry
JSR is designed for TypeScript. You publish TypeScript source, and JSR handles generating API docs, .d.ts files, and transpiling your code for cross-runtime compatibility. JSR packages are distributed as web-standard ECMAScript modules. JSR isn't a replacement for the npm registry; it's a superset of npm. JSR modules can be used with any JavaScript package manager, and in any project with a node_m
OSSすぐ死ぬ - kmuto’s blog
（結論はなく、ダラダラ昔話を書いただけ。） サービスやプロダクトの開発にあたって、自社外で開発されたオープンソースソフトウェア（OSS）を外部コンポーネントとして使うという場面は今や当たり前だと思うけど、そのOSSができるだけ長く保守開発を続けてくれるにはどうしたらよいか、ということまで考えることは少ないだろう。 OSSはそのライセンス遵守の上では金銭を支払うことなく自由にサービスやプロダクトに使えるし、うまく機能がハマれば開発の費用・時間コストを大幅に軽減できる。 ただ、そうしてできた素晴しいサービス、プロダクトのアーキテクチャを見返してみると、個人の手弁当のOSSが危ういバランスを支えてSPOF的に存在していることがある。ジェンガの絵がよく出てくるよね( File:dependency.png - explain xkcd )。 Someday ImageMagick will fin
メルカリiOSアプリのBazelを使った高速・高信頼性ビルド | メルカリエンジニアリング
ここまでBazel の利点をいくつか紹介しましたが、採用には懸念点もありました。次のセクションからは、どのような懸念があったか、それをどのように解決したのかを紹介します。 Xcode 統合 Bazel と Xcode の統合は Bazel の採用においてもっとも大きな懸念でした。 Xcode はビルドシステムと密結合したやや特殊な IDE なので、外部ビルドシステムとの統合が難しいのです。特に indexing や LLDB デバッグを正しく動作させるのは困難でした。 統合とはつまり、Bazel によるビルドのアウトプットを利用して Xcode がサポートする動作を再現することを意味していて、主に下記のような要件を満たす必要があります。 Bazel のビルド構成ファイル群を解析して Xcode プロジェクトを生成する Xcode ビルドの実行を抑制し、代わりに Bazel ビルドを実行する
Maintainer Month: オープンソースをメンテナンスするコツ
週に一度まとめて更新のようなパターンだと、体調が悪いときなどにその週はスキップされ、また次の週も更新しようとして偶然タイミングが合わなかった場合などに、1ヶ月更新が止まるみたいな状態は起きやすいです。 1ヶ月更新を止めてしまうと、そこで更新する習慣が失われて、この書籍でいう逆戻りが起きるのかなと思っています。 そのため、JSer.infoではタスクを細分化して進められる時にやっていけるような形を作っています。 ライブラリのメンテナンスのリズムをツール化する JavaScript周りは顕著ですが、ライブラリが細かく分かれていることが多いため、リポジトリの数も多いです。 そのため、リポジトリのCI設定や依存ライブラリのアップデートなどをメンテナンスするだけで無限の時間がかかります。 このメンテナンス作業を手動で毎回やるととても疲れるので、自分の場合はツール化していることが多いです。 作ったり、
「オープンソース」は壊れている
christine.websiteのブログより。 または: お金を払わない限り、有用なソフトウェアを書かないのか? 最近、重要なJavaエコシステム・パッケージに大きな脆弱性が見つかりました。この脆弱性が完全に兵器化されると、攻撃者はLDAPサーバから取得した任意のコードを実行するよう、Javaサーバを強制することができます。 <マラ> もしこれがニュースで、あなたがJavaショップで働いているなら、残念ですが、あなたには2、3日が待っています。 私は、これが「オープンソース」ソフトウェアの主要なエコシステム問題の全ての完璧な縮図だと考えています。log4j2が、この問題の最悪のシナリオの1つの完璧な例であると思うので、このすべてについていくつか考えを持っています。この問題に関与したすべての人が、現実世界の問題に対する完全に妥当な解決策のためにこれらすべてを行ったことは完全に合理的であり、
パッケージマネージャで配布されるマルウェア、対策と課題について - ぶるーたるごぶりん
はじめに 画像は記事に全く関係ないカニのフィギュアです👋 近年、善良なパッケージを騙ったマルウェアが配布されているケースが増えてきています。 これらのマルウェアはパッケージマネージャ上で配布され、開発者端末やそれをビルトインしたシステムを利用するユーザー端末で悪事を働きます。 これは俗にいうサプライチェーン型攻撃で、 これらの関連ニュースを目にする機会が増えてきていることを、多くの開発者が体感されていると思います。 ただ、これらのサプライチェーン型攻撃の記事は、 どうしてもエンドユーザー（パッケージを利用する開発者側・それらを組み込んだアプリを実行するユーザー側）の対策に焦点が当てられたものが殆どのように感じています。 そこで本記事では、このエンドユーザー側の対策だけではなく、 パッケージマネージャメンテナーたちがどう対策しているのかも含めて、 「パッケージマネージャ上で行われるマルウェ
あんまり考えてないよね / jmuk - Message Passing
オープンソースなのにわりかし再発明しがち勢として @jmuk どうですか。 というふうに（内部的に）話題をふられてしまった。再利用ねえ。あんまり考えてないよね。 Chromiumはモノリシックなコードベースだけど、もちろんいろんな他のライブラリを再利用している。だいたい third_party というところに、そういうのは押し込められている。再利用のためには、ソースコードをもってきて、自分たち用にビルドするという立場。システムに入っているライブラリ（DLL）を再利用する、みたいなことはやらない。バージョンの互換性とかABIの互換性とかがしんどすぎるから。まぁこれは普通か。 ChromiumはGNという独自のビルドシステムでビルドするが（ここがすでに独自なのかよ、というツッコミがあるかもしれませんがスルーしてください）、独自なのでこれをあらかじめサポートしている外部ライブラリというものは、事
［速報］Windows用パッケージマネージャ「winget」がプレビューリリース。コマンドラインからアプリケーションをインストール。Microsoft Build 2020
オンラインイベント「Microsoft Build 2020」を開催中のマイクロソフトは、コマンドラインから利用するWindows用パッケージマネージャ「Windows Package Manager」のプレビューリリースを発表しました。 Windows Terminalのコマンドラインから「winget install」と入力、実行するだけで、アプリケーションがWindows 10にインストールされます。 例えば「winget install powertoys」と入力すればpowertoysが、「winget install vscode」と入力すればVisual Studio Codeがインストールされる、という具合です。 インストールはあらかじめ用意されたmanifestファイルに従って行われます。 Windows Package ManagerはGitHub上でオープンソースとし
政治的問題のためRuby GemsとGitHubからChef関連の諸々が消えた件について
アメリカ合衆国のとある政府機関への抗議のため、Chef関連のGemやGitHub上のソースコードを作者が削除した。 雇用期間に業務にてGemが作成されていたため、Chef SoftwareがGemの所有権を主張してGemを復活させた。 最終的には抗議行動に対してChef Softwareが折れることで決着が付いた。 現在Chef界隈が混乱している。 どうやら政治的問題のためにRuby Gemsに登録されたGemやGitHub上のソースコードが消されたらしい。 なかなか興味深い出来事で、なおかつ日本語圏に情報が出ていないので適当に記録しておく。 用語 Ruby：プログラミング言語の１種。日本においては超広範囲で使用されている超メジャーな言語。 RubyGems：Rubyにおけるパッケージシステム。他人のRubyプログラムやライブラリを簡単に取り込むことができる。 Chef: 構成管理ツールの
JavaScript Registryの今後 - from scratch
さて、前回は tink と yarn v2 における CLI 戦略の話でした。次は JavaScript Registry についてです。 ちなみにこの内容が今回 JSConf.EU 2019 で一番盛り上がったトピックです。 JavaScript Registry とは JavaScript Package をバックエンドで管理しているサービスです。 npm が管理しているものがいちばん有名です。他にも GitHub が管理する Registry が公開される予定です。 The economics of Package Management the economics of package management slide: github.com video: www.youtube.com 「Package Managementの経済」というタイトルです。 聴講者からすると、何話すのか
さよなら、愛しのFreeBSD｜力武 健次 / りきたけ けんじ｜note
2019年1月末でFreeBSDに関連する開発活動を止めることにした。とても愛していたOSだけに身を切られるような思いは否めなかったが、別れが来るなら自分の自由になるうちにと思い、決断した。以下は個人的な想いを綴っている。 BSDの大元は、カリフォルニア大学バークレイ校で作られたオペレーティングシステム、今風に言えば基本ソフトだ。Berkeley Software Distributionというのがもともとの名前だ。 1985年に自分がUNIXに触れたころから憧れていたのがこのBSDだった。当時のBSDはまだオープンソースではなかったAT&TのUNIXのライセンス制限の傘下にあり、自由にソースコードが読めなかった。でもAT&TのUNIXであるSystem V（システムファイヴ）よりはずっと自由だった。その後、DECのULTRIXやSunのSunOS 4など、多くの先進的なUNIXマシンがB
クラウドベンダなどによるサービス利用を制限したMongoDBの新ライセンス「SSPL」を理由にDebian、Fedora、RHELがMongoDBの配布取りやめを表明 － Publickey
クラウドベンダなどによるサービス利用を制限したMongoDBの新ライセンス「SSPL」を理由にDebian、Fedora、RHELがMongoDBの配布取りやめを表明 MongoDBがAWSなど大手クラウドベンダによるサービス化に反発し、商用サービス化を制限する新ライセンスに変更したことは以前の記事で紹介しました。 参考：Redis、MongoDB、Kafkaらが相次いで商用サービスを制限するライセンス変更。AWSなどクラウドベンダによる「オープンソースのいいとこ取り」に反発 新ライセンスはAGPLをベースにMongoDBが独自に作成したもので、「Server Side Public License」（以下、SSPL）と呼ばれています。 SSPLではサービス提供元もソースコード公開を義務化 SSPLでは、MongoDBをサービスとして提供する場合、サービス提供元が独自に変更した部分を含めて
他言語から来た人がGoを使い始めてすぐハマったこととその答え - Qiita
環境構築するまでに知りたかったこと Golangの最新バージョンは？ 1.16.6 (2020/07/12リリース) Goのインストール方法は? macOS の場合は brew で OK この場合、goのsdkは /usr/local/Cellar/go/<バージョン>/libexec にインストールされます。 IntelliJ IDEA や GoLand にような IDE に「GOROOT」というものの指定を求められたら、このパスを使います。 brew で入らないバージョンの go が必要だったり、いくつかのバージョンを併用したい場合は $ go get golang.org/dl/go1.14.4 $ go1.14.4 download # 1.xx.0 の場合 $ go get golang.org/dl/go1.15 $ go1.15 download # 上記でgo getしたg
Anaconda は Environment Isolation Tool (環境分離ツール) ではない
pyenvが必要かどうかフローチャート 私の周りでも pyenv に対して良い印象をもって語らない風潮はあってその理由がよく分かりました。ここで @shibukawa が書いていることを私は正しいと思うし、pyenv というツールそのものを批判しているのではなく、目的や用途を理解せずに pyenv を勧めたり使ってしまったりしてしまう人への懸念があるというのは理解できました。 ちなみに私は普段 OS X と Linux (Ubuntu) を使っているのですが、Linux では pyenv を、OS X では MacPorts を使って複数の Python バージョンの管理をしています。件の記事の分類でいうと「ライブラリの開発者」のところだと思います。 pyenv の議論は件の記事を読んでもらうとして、そこでは Anaconda についても触れています。Anaconda を pyenv の議
Homebrewでインストールされる/usr/local/bin/pythonが再びPython2に変更
B! 199 0 68 0 先日Homebrewのパッケージの改変が行われ、pythonというFormulaはPython3をインストールするようになり、 /usr/local/bin/pythonもpython3へのリンクになっていました。 これがまた変更され、 /usr/local/bin/pythonはpython2へのリンクに戻されました。 python2 to python3 PEP 394 – The “python” Command on Unix-Like Systems 現在の状況 python3をpythonで呼びたい場合 Homebrewチームの暴走感 python2 to python3 1.5.0 — Homebrew 以前から予告されていたこととして、3月に入った時に Homebrewのpython Formulaがpython3をインストールするようになりまし
セルフまとめ - Diary
セルフまとめ 力武さんが FreeBSD の開発者コミュニティは衰退して ports がやばいみたいな話書いたら、日本の利用者コミュニティの悪口みたいなエントリ上がってくるのまさに BSD 界隈のしょうもなさが象徴されていると思った — アラブ (@ssig33) January 11, 2017 力武さんが「FreeBSD は衰退しました」と言ったところ、佐藤先生がやってきて「俺はやっておるぞ、それはそうとして日本人はダメ」って叫び始めたという光景であり、本当に壮絶。 — アラブ (@ssig33) January 11, 2017 佐藤先生のエントリこの部分が一番やばくて、「老人ばっかだって力武さんはいうけど、若者もいるし、老人は沢山もどってきたし老人は沢山います」ってかいてある。力武さんの懸念が完全にただしいことがわかる。 pic.twitter.com/Bsqh3gUDp3 — ア
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
新横浜密着情報シンヨコのサイト
Libraries - The Open Source Discovery Service
GitHub - pivotal/LicenseFinder: Find licenses for your project's dependencies.
