曲者に権限が渡らない OSS 権限移譲プロトコルが難しい - Qiita
曲者に OSS の権限が付与され、悪意のあるコードを埋め込まるような事件をおこさない OSS 権限移譲フローを考えてみました。 TL;DR 基本的に OSS の権限譲渡を 選ばない方 が安全といえそうです。なぜなら、次のように権限譲渡の安全性を担保することはとても難しく、かつ高価につくからです。 代わりに、プロジェクトを停止するか、信頼できる人物に fork を依頼する（現状の project は archive）のが、責任回避の意味で有効だと思われます。 背景 「2018/11/27に判明したnpmパッケージ乗っ取りについて」が世間を騒がせていますが、個人的に驚いたのは件の package の元々の作者である方への非難の声が多いことでした。 個人的には、この事件の根本は npm 側の機能不足が問題という認識（postinstall フックなどの自動的なフックによって操作ユーザーの権限で任
テストがなかった無法地帯にテストを導入して開発速度を1.7倍にした話 - Qiita
テストがなかった無法地帯のプロジェクトに自動テストを導入して、開発速度を1.7倍にした話をします。 自動テストがなぜないのか 自動テストのないプロジェクトには、そうなる理由が必ず存在します。よくみる理由は、「時間がないから1」「テストの書き方がわからないから」「無理やりテストを書いたつらい経験があったから2」といったものです。今回のプロジェクトの場合は、以下の2点でした： 自動テストの書き方がわからないから レビューがテスト代わりだったから まず、チーム編成が変わって私ともう一人がチームに加わるまで、実装者の中に自動テストの経験者はいませんでした。このような状況では、自動テストは困難になります。なぜなら、何をどうやってどこまでテストするかを決めるには、多少の慣れが必要だからです。この慣れがないと、何をしたらいいかわからないという状態に陥りがちで、結果として自動テストが後回しにされてしまいま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
