Debianの「どんな環境でビルドしても同一のバイナリを生成できる」試み 38
ストーリー by hylom
検証可能性の担保 部門より
検証可能性の担保 部門より
insiderman 曰く、
Debianがバイナリファイルの信頼性向上のため、「どんな環境でビルドしても同じバイナリが生成される」ような仕組み（Reproducible builds）の普及に取り組んでいるそうだ（Slashdot、Motherboard）。
Debianではソースパッケージを利用することでソースコードからのビルドは簡単に行えるが、ビルドに使用した環境の違いなどによって生成されるバイナリは異なるものになる可能性がある。Debianはこの問題を解決し、どのような環境でも常に同一のバイナリを生成できるような仕組みを導入することで、改変されたバイナリを簡単に判別できるようにすることを目指しているという。
Debianが今これに注力する理由として、諜報機関などがソフトウェアにバックドアを仕込む、という問題が挙げられている。Reproducible buildsを導入することで、こういった問題への対策になるということのようだ。なお、現在、Debianの全パッケージのうち83％がReproducible buildsに対応しており、この割合は徐々に増加し続けているという。
近年ではLinuxの世界でも第三者がビルドしたソフトウェアをダウンロードして使うことが普通になっており、最近では第三者がビルドした仮想マシンをダウンロードして使う、という例も増えている。そのバイナリが本当に安全なのか、バックドアは仕込まれていないか、利用者はその点を注意・確認してから利用するべきだろう。
公開された仮想マシン (スコア:0)
他人の公開した仮想マシンを使うなんてまともな考えとは思わない。
バックドアが仕込まれたとかもそうだけど、うっかり危険な設定にしてないとも限らないし、
そもそも作成者はセキュリティについての意識が甘い人なのかもしれない。
個人的には新人に公開サーバーを任せるようなレベルの危険性だと思っている。
Re:公開された仮想マシン (スコア:2)
新バージョンのOSのお試しとか
Androidアプリの開発で実機が無いときとか
使っちゃいますねぇ。
Re:公開された仮想マシン (スコア:1)
現実: http://cpplover.blogspot.jp/2015/04/hadoop.html [blogspot.jp]
Re: (スコア:0)
dockerもmavenも同じような理由で怖い。
でもaptもyumも使ってる俺に文句を言う資格はない。
Re: (スコア:0)
ActiveXは危険だとかいうくせにダウンロードした実行ファイルはホイホイ実行して遠隔操作されたりしちゃう破綻した人っていますよね。
Re: (スコア:0)
ActiveXはまともな使い方よりも悪意ある使い方される物のほうが圧倒的に多かった。
まともな使い方される奴はほんの一握り。(代わりにそれらの実行頻度は高いんだが)
あと用途はまともでも脆弱性もワンセットになってるActiveXコンポーネントも多い。
FlashとかFlashとかFlashとかAcrobatとかJavaとかFlashとかAcrobatとか…orz
# ActiveX普及率が高いとか言う某国は兎も角
公開された実行ファイルを実行するのは正気の沙汰なんですか? (スコア:0)
信頼の対象が実行ファイルから仮想マシンに変わっただけだわな。
Re: (スコア:0)
仮想マシンに署名がつく流れ？
Re: (スコア:0)
データとプログラムの分離が上手いこと出来たとしてもプログラムの構成が激変しまくり…
配布時点での署名なら可能だろうけど、それは信頼できる手段で入手したハッシュをチェックするだけで良いし。
# そもそも自分でビルドできるやつが居ない [security.srad.jp]から配布元の保証が役に立たない可能性が……
なにがやりたいのかさっぱりわからない (スコア:0)
同じコードがビルドできるなら署名されたバイナリ使えばいいんじゃないのか。
バイナリなんてプロセッサのキャッシュサイズに最適化する程度で変わるのに、そんなこともしないならつるしでいいじゃないか。
それとも、自分でビルドしないと死んじゃう病なんだろうか、全部のソースを確認できるわけでもなし、ビルドしたから安全なんてとても思えないのだが。
Re:なにがやりたいのかさっぱりわからない (スコア:1)
公開されているバイナリに、ソースコードに無い機能がこっそり追加されていたりしないか、
ソースコードをオプション合わせてコンパイルすれば確認できるようにしよう、ってことでしょ
Re: (スコア:0)
だね。
もしディストリビュータがこういうこと [it.srad.jp]をしても、改変されたものかどうかを第三者が容易に確認できるようになる。
どの環境でも同一のバイナリが生成されるということは、配られたバイナリと、手元でビルドしたバイナリは全く同じになるはずだから、それこそcmpコマンド [wikipedia.org]一発で。
Re:なにがやりたいのかさっぱりわからない (スコア:1)
ケン・トンプソン「せやな」
Re: (スコア:0)
私もよくわからんが、アプリのパッケージ開発者やディストロ開発者を想定したものじゃないかな。
（要はバイナリに署名をつける側の話）
「あらゆる環境で同一バイナリ」っていうほどのものじゃなくて、
「些細なコンパイラのオプションやツールセットのバージョンに影響されない」程度の代物ではないかと思う。
細かい条件でいちいちバイナリが変化しないことによって、バイナリの署名のやり直しが減ったり、複数人での共同作業がやりやすくなったりする効果はあるだろう。
例えば、あるRPMのメンテナが交代した場合、新しいメンテナのビルド環境でも旧メンテナと同じバイナリが簡単にビルドできれば嬉しいと思う。
一方Gentooは (スコア:0)
以下略。
Re:一方Gentooは (スコア:2)
それを言うなら「一方BSDは」じゃなくって？
ソースからビルドする目的 (スコア:0)
ソースからビルドするのは、CPUとか環境に最適化したいからだろう？
どんな環境でも同じバイナリが得られるならば、バイナリに署名でもつけておけばよいのでは？
＃にわかGentooなひとより
Re: (スコア:0)
バイナリーパッケージについては、
architecture(ビルドオプション)毎に一次配布元で生成し、
丸ごと配布しているが、ハッシュ値か何か同一である事の検証用データだけ配布すれば済むようになれば、
architectureを増やす事による通信コストが一次配布元およびミラーサイトで減るはずなので、
きめ細かく環境に最適化したバイナリパッケージが提供できるようになるかもしれないですね。
Re: (スコア:0)
RedHat系のrpmパッケージって、もう何年も前から署名付きだったよね。
セキュリティ問題で頻繁にアップデートされたパッケージが公開されているのに、いちいち自前でビルドして検証なんてやっていられないよ。
せいぜい、テスト機に運まかせでインストールして、アップデート前と同じ動きをするかどうか確認するのが精いっぱいでさ。
近年ではLinuxの世界でも第三者がビルドしたソフトウェアをダウンロードして使うことが普通になってお (スコア:0)
>> 近年ではLinuxの世界でも第三者がビルドしたソフトウェアをダウンロードして使うことが普通になっており
開発元がバイナリを配布してないソフトを
ディストリビューションの開発元とも違う誰かが
コンパイルして配ってるなんてこと、普通はないように思うけど。
Re: (スコア:0)
普通にあるでしょ。Debianだって、全てのコンパイラを最初から同梱してるわけじゃないし、コンパイル時にしか使わない環境のインストールを全てのユーザーがやるのは筋が悪すぎる。
Re: (スコア:0)
そんなのそのソフトウェアの開発元がバイナリ配ればいいだけじゃない?
Re: (スコア:0)
必要なライブラリを全部静的にリンクしてですか？
Re: (スコア:0)
それができないなら、ユーザの他にだれがコンパイルするんですか?
Re: (スコア:0)
コンパイルというか、親コメントの意図は当然動的なリンクを言ってるんだと思うんですけど。
Re: (スコア:0)
開発元がやればいいのも正論ですけど、実際には開発元がやってないので、第三者が非公式なリポジトリ作って公開なんてのも腐るほどあるので、もう普通のことでしょうね。
Re: (スコア:0)
CentOSとかのRHEL互換ディストリだと、インストール・アップグレードを
全てyumで済まそうとするばかり、どこのものともしれぬ野良レポジトリを
登録しちゃう面倒臭がり屋さんは多そう
# epelまでは許そう
環境など (スコア:0)
他に、バイナリに差異を生じさせる要素は何があるの？
「環境」をどの程度の範囲の言葉として使ってるかにもよるけど。
Re:環境など (スコア:1)
昆虫の数は環境に含まれるんですかね。
Re: (スコア:0)
1) コンパイラのバージョン違い
2) 実行モジュールがリンクしているライブラリのバージョン違い
3) autoconf等の環境順応用設定自動化ツールのバージョン違い
4) autoconf等の環境順応用設定自動化ツールの実行による環境の差異の反映
RedHat系だと、ディストリビュータがビルドに使用しているバージョンのコンパイラ等が外部に提供されていなかったりして、同じソースパッケージから自動ビルドしても、ディストリビュータ提供のバイナリーと同じバイナリーにはならないのは有名な話。
Re: (スコア:0)
いや、それらはなんで「環境」じゃないのかって話。
Re: (スコア:0)
「環境に依存しない」ってことは結局「環境を無視してる」ってことですからね。
バイナリに影響するような変更を無視して「やあ揃った揃った」で済ますのって、
警告レベルを下げてビルドログが綺麗になったと言うようなもんじゃないのかな…。
Re: (スコア:0)
横レスだけど「ビルドに使用した環境の違いによって」ではなく、
「ビルドに使用した環境の違いなどによって」とあるが、
「など」に含まれる環境以外の要素とは何なのかって疑問だと思いますよ。
タイムスタンプとか乱数値がビルド時に算出されて埋まるのであれば環境以外の違いと呼べる…かな？
# ビルド時刻やRNGの状態まで環境に含むとか言われたら反論しきれんけど…さすがに言わないよね？
Re: (スコア:0)
configureスクリプトでautodetectされるライブラリも問題です。たしか、Debian系だと、chrootで隔離された環境に、必要最小限の開発ライブラリやツールをインストールして、ビルドを行っていたはず。
GPL汚染戦術が (スコア:0)
同一ソースから同一バイナリ、ということなら、
腹いせにGPLバイナリを紛れ込ませるテロが難しくなるね
暗黒面に囚われた雇われ開発者よ、C++を使い給え
Re: (スコア:0)
Debianのパッケージに対してGPL汚染とか何言ってるのか意味がさっぱりわからないがGPLが嫌いだという強い意思だけは伝わってきた。
そのバイナリが本当に安全なのか (スコア:0)
>そのバイナリが本当に安全なのか、バックドアは仕込まれていないか、利用者はその点を注意・確認してから利用するべきだろう。
どうもこういう話を読むと、
http://security.srad.jp/story/08/05/15/1636213/ [security.srad.jp]
を思い出さずにはいられない。
一時情報見ようよ。。。 (スコア:0)
https://wiki.debian.org/ReproducibleBuilds/About [debian.org] に何故このような取り組みをしているのかが簡単に書いてある。
あと、reproducible buildsはLinux foundationのCIIの支援を受けて実施されています。
https://www.coreinfrastructure.org/news/announcements/2015/06/linux-fo... [coreinfrastructure.org]