OSSをベースにしたサービス提供の難しさ - knqyf263's blog
背景 難しさ 利益相反になりがち 競合OSSの存在 コミュニティからのPull Request 競合サービスによる利用 レベニューシェアにならない 利用統計が取れない やっておくべきこと お金を払いたい機能を見極める 境界線を決める ライセンスについて考える 利用統計の取得方法について考える OSSから有償版へのスムーズな移行を考える まとめ 背景 弊社（Aqua Security）ではOSS開発をしており、そのOSSを組み込んだ有償サービスを売ることで利益を上げています。 自分はその中のOSS開発をフルタイムで担当しています。 会社は何を目的としてOSS開発をしているのか、というのは以前発表しました。 speakerdeck.com フルタイムOSS開発者をやってみての感想なども昔書いています。 knqyf263.hatenablog.com 今回はOSSをベースにしたサービス提供の難し
英語ミーティングを乗り切るために身につけたバッドノウハウ - knqyf263's blog
周りを見ていると何の苦もなく英語社会に適応しているわけですが、日々苦しんでいる人の奮闘記があっても良いのではないかと思って書きました。残念なエピソードを晒すことで実は自分もこうやって乗り切ってましたという人が現れお互いに助け合えることを期待しています。 概要 前提 バッドノウハウ 質問編 聞き取れなかった時にSorry?と聞き直さない 聞こえたところまで繰り返す 可能性のある質問全てに答える Do you mean ~ ? で可能性を潰していく うかつにYES/NOで答えない 他人に振ってみる 良い質問ですねぇを使う 何か言いそうな雰囲気を出して時間を稼ぐ 発言編 How are you?を速攻でキメる Can you hear me? Can you see my screen? に率先して答える How are you?にHow are you?で返す 発表編 話し続ける 質問が出ない
趣味で作ったソフトウェアが海外企業に買われ分野世界一になるまでの話 - knqyf263's blog
2年前の2019年8月に以下のブログを書きました。 knqyf263.hatenablog.com 今回はその続きです。前回のブログは多くの人に読んでもらうことを意識して書きましたが、今回はそうではないです。特に得た学びを書くわけでもなく何で作り始めたのか？とかどんなことがあったのか？とか思い出話を書いているだけなので、言ってしまえば自己満足の記事です。それで構わない人や前回の記事を見てその後どうなったか気になった人だけが読んでもらえますと幸いです。 誰かのためになるわけでもない過去の出来事について語るのは老人感が強くて基本的に好きではないのですが、自分の中で一番大きかった目標を達成したので節目として書いています。 英語版の記事も会社のブログから公開しています。英語版のほうが簡潔で良い可能性もあります。日本語版は誤った解釈をされると嫌だからもう少し詳細に書こう、を繰り返していつも長くなりす
コンテナイメージのlazy pullingをcurlで試してみる - knqyf263's blog
はじめに 参考 Stargz 概要 詳細 HTTP Range 互換性 Stargzまとめ eStargz 概要 最適化 TOC, TOCEntry Footer Stargz Snapshotter eStargzまとめ 実験 トークン取得 インデックス取得 マニフェスト取得 Footer取得 TOC取得 ファイル取得 実験まとめ 余談 応用例 自作ライブラリ 計測 まとめ はじめに コンテナイメージのlazy pullingが各ツールで利用可能になりつつあるようです。以下は stargz-snapshotter のメンテナである @TokunagaKohei さんによるブログです。 medium.com lazy pullingが何かを簡単に説明しておくと、コンテナイメージ全体を最初にpullせずにコンテナ実行後に必要なファイルのみを遅延でpullするものです。docker runしよ
Goバイナリの脆弱性検知 - knqyf263's blog
Trivyのv0.17.0をリリースしました。 github.com 長い道のりでしたが、ようやくこれでGoバイナリの脆弱性検知に対応できました。夜中0時ぐらいからリリース作業を初めて気付いたら朝5時でした。 概要 Go言語で書かれたプログラムをビルドすると依存しているモジュールがバイナリに含まれます。現代のソフトウェア開発において利用しているOSSのライブラリが0ということはまれなので、何かしらのOSSライブラリが作成されたバイナリに同梱されます。これらのOSSの古いバージョンには既知の脆弱性が含まれる可能性があります。これを手動で調べて追うのは手間なので最近では脆弱性スキャナを用いて検知するのが普通です。自分が開発したTrivyというOSSの脆弱性スキャナではコンテナイメージやファイルシステム上のGoバイナリに含まれるモジュールを特定し脆弱性を検知します。 Goのバイナリからどうやって
Semantic Versioningの闇 - knqyf263's blog
今回も誰も興味ないシリーズなので今まで書いてこなかったのですが、Semantic Versioningに関して幻想を抱いている人がいる可能性があり、そういう方にどうしても現実を知っておいて欲しかったので書きました。3行要約（と可能なら余談）だけでも読んでいただけると幸いです。 3行要約 Semantic Versioning 2.0.0にはバージョン"比較"の定義はあるが、バージョン"制約"（>= 2.1.3みたいなやつ）の定義がない その結果、同じsemver準拠ライブラリでも制約の解釈が異なり結果が真逆になる というかそもそもsemver使ってるエコシステムが少なすぎる 背景 セキュリティアドバイザリでは特定のバージョンが脆弱であることを示すためにバージョン制約が使われることが多いです。例えば >=1.2.0 <1.2.6みたいなやつです。この場合、1.2.5は脆弱だが1.2.6は修正
Berkeley DB (Hash) の実装 - knqyf263's blog
普段あまりこういう誰の役に立つのか分からない記事は書かないのですが、解析をするまでの背景がOSSに関するとても良い話なので重い腰を上げて書きました。 概要 古のアプリケーション組み込み型のデータベースとしてBerkeley DBがあります。元々はカリフォルニア大学バークレー校によって開発され、その後Oracleによって買収されています。データ操作にSQLは使えず、アプリケーションに埋め込んで使用します。RDBまでは必要ないけどちょっとしたDBが必要みたいな時に使われているようです。機能はシンプルで組み込みのため性能も良いとのこと。詳しくは以下に書いてます。 docs.oracle.com 本記事ではそのBerkeley DBの中身がどのように実装されているのかの雰囲気を記します。Berkeley DBはBtree accessやHash access, Queue/Recno access
OSSエンジニアを1年やってみた所感 - knqyf263's blog
最近脆弱性の話とか本業と一切関係ないことを書いていたので、今回は本業に関する話です。 前提 所感 楽しい やりがいがある 実績になる 得意な形でアウトプットできる 勉強になる 深く特定領域を学べる 得た知見を公の場で共有しにくい 広く触れない（可能性がある） なぜ会社としてOSSをやるのか？ということを真剣に考えられる 市場の熟成 有料化のしやすさ 品質の向上 カンファレンスでの発表 ファンを作る 会社の売上に貢献できる方が精神的に楽 ユーザからのフィードバックが助かる メンテナンスコストが高くなる 方針を決められなくなる 宣伝は必要 まとめ 2019/08/01にOpen Source Engineerという肩書になってから既に1年が経過しました。そういうポジションの人はまだ日本では少ないんじゃないのかなと思ったので何か参考になればと所感を書いておきます。ちなみに最初の頃Open Sou
Node.jsでプロトタイプ汚染後に任意コード実行まで繋げた事例 - knqyf263's blog
概要 前回Node.jsのプロトタイプ汚染を起こすためのバイパス方法について記事にしました。 knqyf263.hatenablog.com プロトタイプ汚染後に何が出来るのか、ということについては基本的にアプリケーション依存なのであまり話題になることは少ないです。 自分の知る限り一番多いのは if(user.isAdmin) { // do something } といったような重要なプロパティを書き換えることで権限昇格する例です。ただし、自分の理解では isAdmin が初期化されていないことが前提条件として必要です。 const obj1 = {}; const obj2 = JSON.parse('{"__proto__":{"isAdmin":true}}'); merge(obj1, obj2) var a = {} a.isAdmin // true var b = {isA
CVE-2020-10749（Kubernetesの脆弱性）のPoCについての解説 - knqyf263's blog
少し前ですが、Kubernetesの方から以下の脆弱性が公開されました。 github.com タイトルにはCVE-2020-10749と書きましたが、複数のCNI実装が影響を受ける脆弱性でCVE-2020-10749はcontainernetworking/pluginsにアサインされたものです。他にもCalicoはCVE-2020-13597、DockerはCVE-2020-13401、などとそれぞれCVE-IDがアサインされています。 このIssueの説明を読んで、はいはいあれね完全に理解した、と思って一旦閉じました。ですが、頭で分かった気になって手を動かさないのは一番やってはいけないことと念じ続けてきたのに、しれっと同じことをやりそうになっていた事に気づきました。なので数日経ってからちゃんとPoCを書いてみました。多少知識が増えてくるとついうっかりやってしまいがちなので気をつけなけ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
