アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
望まれない復活というと (スコア:1)
Mozillaよお前もか、と少々哀しい出来事です。
とりあえず、Konquerorとw3mを使いますが(w
/.configure;oddmake;oddmake install
Re:望まれない復活というと (スコア:0)
だよなぁ。
新しい穴が見つかるよりも印象悪いし。
Re:望まれない復活というと (スコア:3, 参考になる)
つい先日「セキュアプログラミング」という本を読んだところなのですが、
その本には「コーディングよりも設計、運用の方が大事」というようなことが
書いてあり、パッチ当ての方針も「設計」として重視すべきだとありました。
バッファオーバーフローでも任意のコマンドが実行されないようにする方法さえ
いろいろ出てきている今、真の意味でセキュリティを考えているならば
コード自体よりも、こうしたプロジェクト運営などの面での工夫が重要と
言えそうです。それを裏付ける点として、最近発見された脆弱性は(これまた
本で警告されていたことですが)、正常に動作して
Re:望まれない復活というと (スコア:0)
Re:望まれない復活というと (スコア:0)
Re:望まれない復活というと (スコア:1)
私の書いたコメントでは http://www.openbsd.org/security.html の
「継続的・多面的な audit」や「proactivity」の中に含まれている
(ただし、たぶんすべてが明文化されているわけではない)指針を
意識していました。
実例としては Hackathon で unionfs や telnetd が消えたことを
挙げられると思います。コードは audit されているので問題ない
としても、実際に使われる場面を想定したときの安全性について
疑問が残るので消した、ということでしょうから。
「便利だから」「みんな実装してるから」という理由を理由として
認めない……と言えるかもしれません。mozilla のほうが明文化
され確固としたプロジェクト運営指針を持っているように見えるの
ですが、実際にはそうしたものを開発者個人の哲学として持っている
OpenBSD のほうがセキュリティの向上に成功しているので、そこで
用いられている理念をお手本にできないかな、と思ったのでした。
でも最後のカッコで書いただけなので、あんまりつっこまないでください。
私自身はヘボいタコですし、知ったかぶりでウソつくことがよくあります。
Re:望まれない復活というと (スコア:0)
実際にはtelnetdを必要とする人は自分でmake install するでしょう
そうすれば OSの責任外な所でユーザーが独自にパッチを当てないといけなくなります
将来 telnetd にプログラム的なセキュリティホールが発見さ