アカウント名:
パスワード:
Damien Miller 氏によれば、暗号そのものは恐らく安全であろう、とのことです。http://permalink.gmane.org/gmane.os.openbsd.tech/22559 [gmane.org]
何かを仕込むとすればネットワーク関連のコードで、鍵データがパディングに混入するようにしたり、秘密データに隣接する部分を読むとき「うっかりはみ出す」ようにしたり、mbuf を「うっかり再利用する」ようにしたり、タイミング攻撃によるサイドチャネル (2000年当時はあまり知られていなかった) を用意したりといった可能性が思いつく、と書いています。
そのうちの幾つかは対策が取られていますが、すべて疑念を晴らすには地道なコード監査以外ないようです。
OpenBSD の場合は、誰かから ok をもらわないと cvs commit もできませんから、ある程度は防いでいるとは思いますし、新規に知られるようになった exploit 手法についても source tree 全体を見てまわりますが、基本的に開発者を疑っているわけではないので、ご期待のレベルには達していないかもしれません。
http://www.itwire.com/opinion-and-analysis/open-s [itwire.com]
＞基本的に開発者を疑っているわけではないので、ご期待のレベルには達していないかもしれません。
言い方が悪かったです。Theo としてはむしろ、開発者を (友情に基づいて) 信頼しているからこそ、それを金で壊そうとしたのだとしたら許せない! という意見なのでしょう。http://permalink.gmane.org/gmane.os.openbsd.tech/22642 [gmane.org]
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
バックドアの余地は (スコア:5, 参考になる)
Damien Miller 氏によれば、暗号そのものは恐らく安全であろう、とのことです。
http://permalink.gmane.org/gmane.os.openbsd.tech/22559 [gmane.org]
何かを仕込むとすればネットワーク関連のコードで、
鍵データがパディングに混入するようにしたり、
秘密データに隣接する部分を読むとき「うっかりはみ出す」ようにしたり、
mbuf を「うっかり再利用する」ようにしたり、
タイミング攻撃によるサイドチャネル (2000年当時はあまり知られていなかった) を用意したり
といった可能性が思いつく、と書いています。
そのうちの幾つかは対策が取られていますが、
すべて疑念を晴らすには地道なコード監査以外ないようです。
Re: (スコア:0)
これって、OS全体のソースの量的規模が大きすぎてチェックする人的資源のほうが届かないため、指摘されない限りは不正なコードを仕込み放題ってことなんですかね？せっかくのオープンソースも、ホンネとしては機能していないってことでしょうか。
Re: (スコア:2)
OpenBSD の場合は、
誰かから ok をもらわないと cvs commit もできませんから、ある程度は防いでいるとは思いますし、
新規に知られるようになった exploit 手法についても source tree 全体を見てまわりますが、
基本的に開発者を疑っているわけではないので、ご期待のレベルには達していないかもしれません。
http://www.itwire.com/opinion-and-analysis/open-s [itwire.com]
Re:バックドアの余地は (スコア:2)
＞基本的に開発者を疑っているわけではないので、ご期待のレベルには達していないかもしれません。
言い方が悪かったです。
Theo としてはむしろ、開発者を (友情に基づいて) 信頼しているからこそ、
それを金で壊そうとしたのだとしたら許せない! という意見なのでしょう。
http://permalink.gmane.org/gmane.os.openbsd.tech/22642 [gmane.org]