依存地獄の解決
新しいブログ記事が読みたいといういう声が聞こえてきたので、久しぶりにブログを書く。最近仕事で依存地獄の解決をしているので、その方法を書いてみる。 現代のソフトウェアは様々なライブラリに依存するものだ。ソフトウェアAがライブラリBに依存する場合を考える。 A B ソフトウェアAとライブラリBはそれぞれ別のgitレポジトリで管理されている。依存はパッケージマネージャーで管理されていて、レポジトリの中に設定ファイルがある。レポジトリAの中にはレポジトリBに依存する設定ファイルがある。npm, cargo, pip, rebar3といったパッケージマネージャーを考えるといい。 もちろんライブラリBも別のライブラリC, Dに依存している。 A B C D この場合、AはC, Dに間接的に依存していることになる。 実はさらにFというライブラリがあり、これはA, B, Dが依存している。 A B F C
log4jの脆弱性について
log4jとはJava用のloggingライブラリだ。loggingライブラリというのはログとして記録すべき文字列を受け取り、それをどこかに出力するものだ。文字列の中身を通常のloggingライブラリは気にしない。 log4jが通常のloggingライブラリと違うのは、文字列の中身を見て、一部の文字列を変数とみなして置換することだ。これはlog4jのドキュメントではlookupと呼ばれている。 Log4j – Log4j 2 Lookups 例えばプログラムを実行中のJava runtimeのバージョンをログに含めたい場合は、"Java Runtime: ${java:runtime}"などとすると、"Java Runtgime: Java(TM) SE Runtime Environment (build 1.7.0_67-b01) from Oracle Corporation"などの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
