アカウント名:
パスワード:
やっぱりjavaのように、非nativeコードかつセキュリティモデルに囲われたモノでないと ネットワーク(に限らないが)プログラムとしては事実上それっぽいトラブルを根絶できないのかな?とか
つーかこっちも「java「とか」」というように 対象を特定しないように書いてあったのは、そういう意図からです。 べつにrubyでもschemeでも良いと思います。
のこり半分は、アプレットとかのクライアントサイドで動くモノの話。
え? ここでいう危険度は、それ(ら)が1つきりか複数か?に相関する事柄では、ないのではないですか?
むしろ、1つだからそこさえ固めれば死なずに済む、というメリット
>Flash ムービーとして書かれた Java VM があったら、…… 当然ですが、それとてFlashPlayerが壊れていればアウトであるわけですよね。
でも実行を制限する機能を持ってないので、VM より実現できることが少ないですね。
VM なら個々の動作ごとにやだって言えるタイミングがあるけど、ActiveX は一旦実行させてしまうと手を出せない。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生unstable -- あるハッカー
やっぱjavaか?(弱気発言) (スコア:1)
聞くたびに、やっぱりjavaのように、非nativeコードかつセキュリティモデルに囲われたモノでないと
ネットワーク(に限らないが)プログラムとしては事実上それっぽいトラブルを根絶できないのかな?とか
(弱気にも)思ってしまったりするんですが、どうなんでしょう?
メジャーなものでそれっぽいものといえば一番に思いだされるのはjavaっすかね。
#ん?MSもC#にソレを期待しているんだろうか???違うかな?
「どうなんでしょう?」ってのは、javaみたいなやりかたでもやっぱり
こういうトラブルは起きるものなんだろうか?という意味(の便乗質問)でして(^^;、
そういやjavaとかで出来たソフトでこういうトラブルを起こした話って
実際聞いたことが無いような気がします。
それとも俺が無知なだけか、さもなくば事例の分母が少ないので世間で見いだされてないだけか、
とかいうものなんでしょうか、ね?
いや、つまるところ乱暴にいえば、「なんでまだC(++)で書いてるの?」という遠回しの質問でもあります(^^;;;;;;;;;;;;;;
Re:やっぱjavaか?(弱気発言) (スコア:2, 参考になる)
「Web 配信プログラムとか(のセキュリティ穴の話)」というのが何を指しているのかわかりませんが、 CGI プログラムのことを言っているなら、大きな問題は設計のバグと cross-site scripting で、どちらも Java の言語機構で防ぐことはできないと思います。
Java が安全だというのは、たいてい「悪意のある(実行者が信頼していない)アプレットを実行してしまっても安全」という意味です。 Web ページの部品という規模より大きなアプリケーションを動かすためには、そのアプリケーションを信頼する必要があり、その点に関しては Java の(Perl などに対する)セキュリティの面での優位性はないでしょう。
C/C++ ではポインタの演算・変換が自由なので、セキュリティはプログラマの注意力にかかっています。個人的には C/C++ はアプリケーション開発に不向きだと思いますが、ソフトウェアの開発のための言語として C/C++ を採用することは既存のライブラリや既存のプログラマや既存の教育方法 :) を使えるというメリットがあります。言語仕様がこの先簡単には変わらないだろうというのもメリットかもしれません。
鵜呑みにしてみる?
Re:やっぱjavaか?(弱気発言) (スコア:1)
了解です。つーかこっちも「java「とか」」というように
対象を特定しないように書いてあったのは、そういう意図からです。
べつにrubyでもschemeでも良いと思います。
>CGI プログラムのことを言っているなら
半分はご指摘のとおりです。
のこり半分は、アプレットとかのクライアントサイドで動くモノの話。
今回話題のActiveXもソレですよね。
>Web ページの部品という規模より大きなアプリケーションを動かすためには、そのアプリケーションを信頼する必要があり
…どうなんでしょうね…
そもそも頁の部品かどうかってのは、「規模」の問題ではない(はずだ)し…
>既存の教育方法 :) を使えるというメリット
うぎゃーーー(笑)
>言語仕様がこの先簡単には変わらないだろう
javaあたりはこれを満たすことが期待できないかなーとか思ったりはします。
Sunが強権(よりによって不評な点ですが)で言語仕様を堅持してるわけですから。
#まあ勿論、標準化なんたら委員会でもいいんですが…
Re:やっぱjavaか?(弱気発言) (スコア:1)
では、どうして Flash Player は Java アプレットとして書かれていないか、といえば、 Flash Player は Java VM と同列に並ぶものであることを狙っているからです。 Java VM さえ安全なら、知らないアプレットでも安全に動かすことができるのと同じように、 Flash Player さえ安全なら、知らない Flash ムービーを安全に再生することができます。
つまり、安全性の保証がツリー構造になっているわけです。安全性を保証するツリーのルートがあまりたくさんあると意味がありませんが、一つしかないのも危険です。
できれば、 Java アプレットとして書かれた Flash Player という選択肢も用意してあったら、 Macromedia の書いたプログラムを信頼したくないという人も安心できるのですが、ぼくが考えるに、ネイティブな Flash Player のほうが重要です。
逆に Flash ムービーとして書かれた Java VM があったら、 Java VM のメーカを信頼しなくても安全に Java アプレットが使えるけど……。
// Flash のことを全然知らないのですが、無理ですよね?> Flash に詳しいかた
鵜呑みにしてみる?
Re:やっぱjavaか?(弱気発言) (スコア:1)
そうですね。
>アプレットを信頼していなくても安全に実行できる点で VM+中間コード
こっちについてはどうでしょうか?
これまたrubyやschemeでも同じことが言えるのではないかと。
スクリプトのインタプリタってのはいわばテキストをコードとするVMです(笑)から…
>安全性を保証するツリーのルートがあまりたくさんあると意味がありませんが、一つしかないのも危険です。
え? ここでいう危険度は、それ(ら)が1つきりか複数か?に相関する事柄では、ないのではないですか?
確率的な攻撃者(^^;から見れば「どれか1個所が」穴あいていれば攻撃が成立しちゃうわけですから、
1つだから危険度が増す、などと考える暇は無いんじゃないかと思うのですが。
むしろ、1つだからそこさえ固めれば死なずに済む、というメリットとして機能することのほうが
考えやすいかと…
>Flash ムービーとして書かれた Java VM があったら、 Java VM のメーカを信頼しなくても安全に Java アプレット
当然ですが、それとてFlashPlayerが壊れていればアウトであるわけですよね。
Re:やっぱjavaか?(弱気発言) (スコア:1)
鵜呑みにしてみる?
えーと (スコア:1)
Re:えーと (スコア:1)
それは、手間の「数」の問題かと。
ライブラリというものの存在意義(おおげさか)に関わる話ですが、
その「一箇所を」直せば全部直るという側面があるわけですよね。
JVM「さえ」直せばOKという面が。
アプリ(?)側でのテストのやりなおしという代償は有りますが、
テストの手間は、問題発生個所が分散していようがいまいが
乱暴にいえば同じなわけですから、気にしても意味がない。
また、
>結局OSから全部セキュア
たとえばVMがOSの不都合を「ラップ」するように作る、ということもできるわけですよね。
#効率とか色々な面で馬鹿げた選択と言えてしまう場合「も」有るとはいえ。
下層のOSから見ても、上層のアプリ(?)から見ても、ものごとがいったん「一点」に集約
してしまうってのが、VMってものの強み(活かせるならば)ですよね。
で、逆に、
旧来(^^;のように、修正必要個所が分散していたら、どうなんでしょう?
それって世間でよく言うような「リスク分散」に、なっているんでしょうか?
プログラムはしばしば複数が協調して動く必要が有り、そのどれもが
完全(ってのか)であることを求められるわけです(よね)から、
修正個所を分散しても、ちっとも「リスク分散」したことに成らないと、思うのです。
つまり、VMってものの有りようは、弱みよりも強みとして顕在化することのほうが「多い」のではないか?と、愚考するのですがどうでしょうか?
Re:えーと (スコア:2, すばらしい洞察)
Re:えーと (スコア:1)
でも実行を制限する機能を持ってないので、VM より実現できることが少ないですね。
VM なら個々の動作ごとにやだって言えるタイミングがあるけど、ActiveX は一旦実行させてしまうと手を出せない。
Re:やっぱjavaか?(弱気発言) (スコア:1)
> 聞くたびに、やっぱりjavaのように、非nativeコードかつセキュリティモデルに囲われたモノでないと
> ネットワーク(に限らないが)プログラムとしては事実上それっぽいトラブルを根絶できないのかな?とか
> (弱気にも)思ってしまったりするんですが、どうなんでしょう?
そんな事は無いと思う。
Cだってセキュアな記述をしようとすれば出来る。>根絶できる
それはjavaとかとは難易度が低いか高いかの差であって、javaだからボケたプログラムでOKって訳じゃないよね。
javaで楽できるからって程度の低いプログラマでいい訳じゃないし、
それがC(++)でプログラムするなって事にはならないでしょ?
「なんでまだC(++)で書いてるの?」ってそりゃそっちの方が楽だから。
javaの方が楽できればjavaで書くべし。
streamのparseなんかをjavaとCで書き比べてみれば、
程度にもよるけどCの方が半分くらいのコード量で済むんじゃないかな?
# javaよりCの方が実行速度が速い訳ではなくって、
# (Cで書くよりも何倍も)苦労すれば速度差はそれほどないです。
要は労の少ない選択をして、
適切な苦労のかけどころに、適切な苦労をする事でしょ:-)
Re:やっぱjavaか?(弱気発言) (スコア:1)
その差を無視できないことを以って「(理学ではなく)工学的である」と言う、とか聞いたような記憶が有ります。
つまりゲンジツ的であるかどうかという事。
現にこれだけ事実として事故が起きているのですから、無視できないのでは?
>javaだからボケたプログラムでOKって訳じゃない
極論すればそれは「ボケる余地すら無い」かどうかの問題ですよね。
つまり1行も書かないのがバグが出ない一番の手であり、
javaのような(Cよりは高級な)言語で書けば、ある場面において、
Cでならば「書かないとならない」がjavaだと「書く必要が無い」
(ときとして「書くことが不可能」ですらある)、ということが有るわけで、
バグの量はそこで差がつくわけです。
#それ以外の場面では、当然ですが技量の差が直接出るはずです(^^;
>そりゃそっちの方が楽だから。
(俺が)Cのほうが楽だなと思える場面といったら、
文字列のコード(の変換)について考えなくて済む(まさに上記参照…)場面と、
byte(?)配列の操作がゴリゴリ直感的に書けるという場面、だけ、
のような気がしています(^^;
#配列といえば、java1.4にはBufferとかいうクラスが増えたそうですね。
#いままでBufferdHogehogeは有ったけど、その相方たるBufferそのものは暗黙化されていて不便だった、と…
Cをどう思うか?は、文字列そのものとか生byte配列とかを頼る率の多寡に、依存するかもと思います。
データの構造化がもっと華々しくなると、Cみたいなのだとキツい…
>streamのparse
StreamTokenizer(ぉ
parseそのものはともかく、そのparseの結果として生じる状態とかの管理が
ややこしくなると、非OO(=状態の管理単位を整理しにくい)だったり非GC(^^;だったりする言語では、辛いです…
>要は労の少ない選択をして
では、Cでセキュアなプログラムを(セキュアさが必要とされる場面で)書くことは、
どれくらい労が少ないと言えるのでしょうか?(^^;;;;