アカウント名:
パスワード:
なんだか元レスの人が誤解されているようなので指摘モード。
「同社がこの脆弱性に対応するパッチを月例パッチのリリースまで待たずに公開するかどうかは疑問」と考えておきながら、数日という短い期間で脆弱性の存在を公表したのは何かの営業目的ですかね。
これは、今までMicrosoftが行なってきたことからの反省でしょう。詳細を公開しないまでも存在を明かすことによってセキュリティパッチをできる限り迅速に出させる「目に見えない圧力」をかけるためのものではないかと思うのですが。 実際問題としてかなり致命的なセキュリティホールがその存在を一部の人間に知られたまま一年以上放置していた例もあることですし、ユーザの安全性という点から考えてもパッチ提供への圧力は強すぎない範囲で強いほうが良いと思います。
そうでしょうか。パッチが出たらユーザーの皆さんはちゃんと当てられてます?
パッチをきちんと管理する能力がある人なら自力で当てるでしょうし、ディストリビュータがその作業を代行する場合もあります。私の場合はディストリビュータには頼っていないので自力で当てていますが、自信を持って「ちゃんと当てられている」と答えられますよ。パッチとともにPOF (Proof Of Concept)が公開される場合が多いので、パッチが本当に意味のあるものなのかどうかを確認することもできますし。
パッチが出れば安全という思考停止も良くないのではないでしょうか。
オープンソースでのパッチというのは、変更箇所を余すところ無く公開することでソースコードを理解できる多数の大衆の目に触れさせ、本当に意味のあるものなのかどうかとさらなる危険性をはらんでいないかどうかを監視してもらうところに意味があります。
ですから、世の中にソースコードを理解できる人間が多数いて監視し続けている限りにおいて危険性は限りなくゼロに近づけるわけで、最終的に「パッチが出て大衆の目に触れさせておけば事実上安全」という結論に達することができるのだと思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
これでは。 (スコア:1)
ことなのでしょうか。勝手につなげにいくMSN Messengerでも
だめという話ならその時点でアウトではないかと。
実はもうしかけられてたりして(涙
Re:これでは。 (スコア:0)
Re:これでは。 (スコア:1, すばらしい洞察)
勿論 xinetd に脆弱性があったら大騒ぎになるだろうけど、
「何がどれだけ危ないのか」も公表されているだろうから、
冷静に対応できるだろうね。パッチもあっという間に出るだろうし。
Re:これでは。 (スコア:0)
パッチが出るまでは危険性の詳細は隠すものでは?
今回のは、「eEyeでは数日前にMicrosoftに通知済み」との
ことですが「同社がこの脆弱性に対応するパッチを月例パッチ
のリリースまで待たずに公開するかどうかは疑問」と考えて
おきながら、数日という短い期間で脆弱性の存在を公表したのは
何かの営業目的ですかね。(詳細を公表していないから、まあ
まだマシかという気もしますが)
>勿論 xinetd に脆弱性があったら大騒ぎになるだろうけど、
>「何がどれだけ危ないのか」も公表されているだろうから、
>冷静に対応できるだろうね。パッチもあっという間に出る
>だろうし。
そうでしょうか。パッチが出たらユーザーの皆さんはちゃんと
当てられてます?
パッチが出れば安全という思考停止も良くないのではないで
しょうか。
Re:これでは。 (スコア:1, すばらしい洞察)
なんだか元レスの人が誤解されているようなので指摘モード。
「同社がこの脆弱性に対応するパッチを月例パッチのリリースまで待たずに公開するかどうかは疑問」と考えておきながら、数日という短い期間で脆弱性の存在を公表したのは何かの営業目的ですかね。
これは、今までMicrosoftが行なってきたことからの反省でしょう。詳細を公開しないまでも存在を明かすことによってセキュリティパッチをできる限り迅速に出させる「目に見えない圧力」をかけるためのものではないかと思うのですが。
実際問題としてかなり致命的なセキュリティホールがその存在を一部の人間に知られたまま一年以上放置していた例もあることですし、ユーザの安全性という点から考えてもパッチ提供への圧力は強すぎない範囲で強いほうが良いと思います。
そうでしょうか。パッチが出たらユーザーの皆さんはちゃんと当てられてます?
パッチをきちんと管理する能力がある人なら自力で当てるでしょうし、ディストリビュータがその作業を代行する場合もあります。私の場合はディストリビュータには頼っていないので自力で当てていますが、自信を持って「ちゃんと当てられている」と答えられますよ。パッチとともにPOF (Proof Of Concept)が公開される場合が多いので、パッチが本当に意味のあるものなのかどうかを確認することもできますし。
パッチが出れば安全という思考停止も良くないのではないでしょうか。
オープンソースでのパッチというのは、変更箇所を余すところ無く公開することでソースコードを理解できる多数の大衆の目に触れさせ、本当に意味のあるものなのかどうかとさらなる危険性をはらんでいないかどうかを監視してもらうところに意味があります。
ですから、世の中にソースコードを理解できる人間が多数いて監視し続けている限りにおいて危険性は限りなくゼロに近づけるわけで、最終的に「パッチが出て大衆の目に触れさせておけば事実上安全」という結論に達することができるのだと思います。
Re:これでは。 (スコア:1, 興味深い)
> 公開することでソースコードを理解できる多数の大衆の目に触れ
> させ、本当に意味のあるものなのかどうかとさらなる危険性を
> はらんでいないかどうかを監視してもらうところに意味があります。
ある事象に関わる(ことが可能な)人間が増えれば増えるほど
「責任の分散」が生じるため、誰かが一人でやるよりも全体の
パフォーマンスは低下する…と昔、心理学の授業で習った記憶が
あります。
ただ、統制されない大衆にはそもそも責任は発生しないでしょうから
上記は適用しにくいことも考えられますが、だとしたら結局のところ
責任も義務もないため「誰かが作ってくれるの待ち~」になるので、
「事実上安全」というほどのことは言えないのではないかと。
Re:これでは。 (スコア:0)
それができなければ「事実上安全」なんて言われても嬉しくないですね。
Re:これでは。 (スコア:0)
甘えるなよ。
Re:これでは。 (スコア:0)
オープンソースによるセキュリティなんてその程度の物だという事です。
Re:これでは。 (スコア:0)
「豚に真珠」って言葉くらいは知ってるだろ?
Re:これでは。 (スコア:0)
>監視し続けている限りにおいて危険性は限りなくゼロに近づける
>わけで、最終的に「パッチが出て大衆の目に触れさせておけば
>事実上安全」という結論に達することができるのだと思います。
これはオープンソース推
Re:これでは。 (スコア:0)
叩くだけではだめですよ:-)