アカウント名:
パスワード:
もちろん、Javaを使わない、というのが確実であるのは確かだけれど、javaを使わざるを得ない環境での回避策は、どれがベストであろうか。
a)openJDK7にするb)SunJava6にダウングレードするc)Webブラウザのプラグインの実行をnoscriptなどで制限し、信頼できるjavaアプリしか実行しない
とりあえず、個人的にはb)にしている。しかし、今回の脆弱性に対しては有効かもしれないが、潜在的に別のリスクも存在しうるよね。
最近のgdgdがみんなOracleのJava7になってからというのがなんともOracleの無能っぷりを際立たせてる。MicrosoftやAppleやAdobeが通った道をわざわざ忠実にたどることないじゃんよ。
つまり、Oracleの本業のプロプライエタリなデータベース群も、そういう水準の製品であるということ。
d)使わざるを得ないと凝り固まった発想から何とかする
前提を崩してどうする
なんか、一番頭かたいね。
そういや他のJava実装や他の言語にはこういう脆弱性はないんだろうか
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
回避策は? (スコア:0)
もちろん、Javaを使わない、というのが確実であるのは確かだけれど、javaを使わざるを得ない環境での回避策は、どれがベストであろうか。
a)openJDK7にする
b)SunJava6にダウングレードする
c)Webブラウザのプラグインの実行をnoscriptなどで制限し、信頼できるjavaアプリしか実行しない
とりあえず、個人的にはb)にしている。
しかし、今回の脆弱性に対しては有効かもしれないが、潜在的に別のリスクも存在しうるよね。
Re:回避策は? (スコア:1)
最近のgdgdがみんなOracleのJava7になってからというのがなんともOracleの無能っぷりを際立たせてる。
MicrosoftやAppleやAdobeが通った道をわざわざ忠実にたどることないじゃんよ。
Re:回避策は? (スコア:1)
つまり、Oracleの本業のプロプライエタリなデータベース群も、そういう水準の製品であるということ。
Re: (スコア:0)
Re: (スコア:0, すばらしい洞察)
d)使わざるを得ないと凝り固まった発想から何とかする
Re: (スコア:0)
前提を崩してどうする
Re: (スコア:0)
なんか、一番頭かたいね。
Re: (スコア:0)
そういや他のJava実装や他の言語にはこういう脆弱性はないんだろうか
Re: (スコア:0)