オープンソース・ソフトは危険? 97
ストーリー by wakatono
提灯レポート? 部門より
提灯レポート? 部門より
Anonymous Coward曰く、"お馴染みの「マイクロソフトによるFUD」っていうセンが濃厚ですが、オープンソースのソフトは危険という内容の報告書がアレクシ・ド・トクビル協会から出るらしいです。
この手のFUDがクソなのは言うまでもないですが、個人的には「オープンソースだから安全という考えは間違い」というのは事実だとは思います。マイクロソフトの製品に安全性が欠けているのは、単にマイクロソフトが書いているコードがボロボロなだけであって、原理的にはソースが非公開であることとは全く関係ない話ですよね。
...と言いつつも、マイクロソフトの行動には「何だかなぁ」と呆れるのもまた事実。こんなセコい工作をする暇や時間があるなら、バグ潰しに精を出して、実力で「マイクロソフトの製品は安全だ」という評価を勝ち取って頂きたいものです。"
評価はレポートが出てからでも遅くない…とは思うが、アレゲな提灯レポートである確率、結構高そうだなぁ…
オープンソースソフトウェアのメリット (スコア:5, すばらしい洞察)
「自分の目で実際に動いているコードそのものを確認することができ」「技術さえあれば問題のある箇所を自力で直すことができ」「技術がなくても金があるなら、自分が信頼する任意の技術者に直させることができる」という点ではプロプラなパッケージソフトウェアよりもメリットがあるでしょう。ただ、このメリットを活かすには、使う側に技術と見識と金、信頼できる技術者を確保することが必要になるわけで、誰でも簡単に活かせるわけではありません。
# 結局、自己責任がぐっと重くなるぶん、それによって得られるものが増えるってだけだよね。
オープンソースだから安全という考えは間違い (スコア:4, すばらしい洞察)
改ざんされたサイトのOpenPort(TCP)ランキング(2002.05.01-31) [geocities.co.jp]を見ても、LinuxとWindowsはほぼ同数ですね。だんだん、いい加減な設定で放置してあるLinuxサーバが増えてきている模様。
ソフトウェアが安全でも、危険なユーザーが使えば危険になり得るということでしょう。
…なんてアタリマエな結論なんだ>ワタシ
いい加減な設定が危険 (スコア:3, 参考になる)
いい加減な設定は「動けばよい」という理念から来るようです。
うちの学校のOracleサーバはSYSTEM/MANAGERで繋がる。
おいおい、初期パスワードかよ。
しかも、キャパシティプランニングされていない為、
生徒80人が一気にアクセスしてダウンしましたとさ。
.::.:... .::....: .::...:: .::.:.:: .::..:.: .:::..:.
I 1 2 B H4[keR. :-)
Re:ORACLEって (スコア:1)
Copyright (c) 2001-2014 Parsley, All rights reserved.
Re:ORACLEって (スコア:1)
ゲストアカウントのようなものが、SCOTT/TIGERでした。確か。
今までOracle7と8のサーバを4箇所くらいで見てきましたが、
パスワードを変更しているところは皆無でした。
危険すぎる…。
どうぞ狙ってください。 (スコア:2, 興味深い)
むぅ、複合技で「データを少しずつじっくり改竄していく」ワーム
というのが出たら、「とても脅威」だと思うけど。
改竄は全てのデータの信用性がなくなる恐ろしいものだと個人的に思う。
まして、少しずつだとしたら、全てのデータを入れなおしになるかも・・・
その際の損失は、とんでもない大きなものになるでしょうね(滝汗)
# データが消えると言うはっきりした症状がすぐ出るものはある意味安全。
# その逆は、AIDSのように人々に気づかれずに広まるのかもしれない。
## 例えが悪すぎるかもしれませんが(滝汗)
Re:ORACLEって (スコア:1)
>パスワードを変更しているところは皆無でした。
個人的に(参考になる+1)
パスワードは業者が変わっても誰でもわかるように
初期パスワードという事なんでしょうか??
チューニングされていないOracleサーバを
そのまま動かしている事もありですか?
.::.:... .::....: .::...:: .::.:.:: .::..:.: .:::..:.
I 1 2 B H4[keR. :-)
Re:ORACLEって (スコア:1)
さらに SYS/CHANGE_ON_INSTALL っつーのもあります。
#っていうか、こっちのほうが最強だった覚えあり
開発用のサーバで、そのまんま使っていたことはあります。(懺悔)
でも、こっちのほうはパスワードもなしです(^^;;;。
MS,SQL Serverに感染する「CBLAD」ワームに注意呼び掛け [zdnet.co.jp]
結局の所、OSを問わず (スコア:4, すばらしい洞察)
ただ、ロクに管理することが不可能なものがWindowsというわけで(笑)
理由については、このトピックのあっちこっちで既出なので、あえて書きませんが。
穴は塞ぐのが重要なのではないかと (スコア:3, すばらしい洞察)
-- 哀れな日本人専用(sorry Japanese only) --
Re:穴は塞ぐのが重要なのではないかと (スコア:1)
Re:穴は塞ぐのが重要なのではないかと (スコア:1)
なかなか興味深い。
しかし実際、いくつ穴があるのだか。
Re:穴は塞ぐのが重要なのではないかと (スコア:1, おもしろおかしい)
失礼な,穴なんてありません.広大な空間に点がまさに点在するのです.
その点をある程度の精度で飛び歩かせる技術があるのは世界広しといえども
Microsoftだけです.素晴らしい.
えー (スコア:2, 参考になる)
オープンであるメリットとして、「目玉の数さえ十分あれば、どんなバグも深刻ではない [cruel.org]」というのがあったように記憶していますし、そう信じているのですが、そうではないのでしょーか?
まぁ「目玉の数」が問題なのであって、「オープン/クローズであること」が問題ではないと言われればそうなのかもしれませんが、現実問題としてオープンソースと同じだけの目玉をそろえることは、クローズドな場合には難しいのではないでしょうか。
プロプリエタリな製品でもパブリックベータみたいなことをやってることもありますが、それって「現象を報告」がせいぜいでしょう?
「オープンソースであるから(間違いなく)安全」というのはfalseだとしても、「オープンソースだと安全性が高くなる(傾向にある)」というのはtrueであって欲しい、というかtrueだと信じてるんですが。
というか、そうでなかったら、セキュリティを理由にフリーソフトを採用する自治体や国が存在する [srad.jp]のはなぜ?
バグは表出しなければバグではない、ということであれば、クローズドだと安全なんでしょうけど。シュレディンガーの猫でもあるまいし。
Re:えー (スコア:3, 興味深い)
セキュリティ問題の発見自体に関して言えば、オープンソースであろうと、クローズだろうと目玉の「数」は同条件でしょう。
またセキュリティ問題の修正に関して言えば、「情報をオープンなところに出すな」という習慣があり、「オープンソース」であってもセキュリティ情報に関しては「クローズド」です。従って目玉の数が開発者の数だけしかなく、やはりオープンソースだろうとクローズだろうと同条件しょう。
また、ソースがオープンであっても、個々のユーザの設定内容の情報のほとんどの場合クローズドにされていますから、オープンソースだから監視の目玉の数が多くなる理由はありません。
さらに、セキュリティ上の理由とか称して、プロダクト名やバージョン表示を消すのが大流行のようです。ネットで公開される部分で表示される「商標にかかわる部分」を消して使用するのは法律違反になる可能性があるため、オープンソースでない商用製品の場合には、商標は「オープン」にされていますが、「オープンソース」で商標などをとっていないプロダクトについては、平然とこれら表示が消されて「クローズド」で使用されている場合が多々あります。実に逆説的です。
で、その結果、古いバージョンなどを使っていても平気、あるいはバージョンアップなどした場合に再びプロダクト名を消すのが面倒という理由があるからなのか、プロダクト名が消去されている場合、古いバージョンのままという例が数多く見られます。従って傾向としては、「オープンソース」なプロダクトを「クローズド」に使ってい場合の方がセキュリティレベルは低いように思われます。
これらから、オープンソースであってもセキュリティ問題に関して「目玉の数が多い」とは思われず、また「オープンソースであるからセキュリティレベルが高い」と説明する強い根拠を見いだせません。
また、オープンソースの多くのプロジェクトがボランティアベースに行われていますが、この場合、「修正の義務はない」とか、「ユーザが自分で修正しろ」とかいう理由をつけて開発者が修正を怠るという場合が多々あり、セキュリティ対策が遅れるというような状況を度々目にしてきています。
私の経験が著しく偏ってることは確かですが、MSに比べて、オープンソースコミュニティのセキュリティ問題対応が「オープンソースだから」迅速だという傾向は感じられません。
そもそも、オープンソースなところにも、クローズなところにも、どちらに対しても数多くのセキュリティ問題を指摘し、その対応の期間や、ユーザへの告知などの傾向について、統計的な根拠のある「一般論」が述べられるほどの体験がある人となると、日本では産総研の高木さん以外にはいらっしゃらないのではありませんか?実際高木さんはどう仰ってますか?
ここで、「オープンソースならばセキュリティレベルが高い」という立場で意見を述べている方々の根拠って、一体何なんでしょう?
office
Re:えー (スコア:3, 参考になる)
それは議論の対象外です。それはopensourceだろうがproprietaryだろうが同じです。
> また、オープンソースの多くのプロジェクトがボランティアベースに行われていますが、この場合、「修正の義務はない」とか、「ユーザが自分で修正しろ」とかいう理由をつけて開発者が修正を怠るという場合が多々あり、セキュリティ対策が遅れるというような状況を度々目にしてきています。
それはある意味当然ですが、そういうときに別の人が手を上げて対処することができる、というのがオープンソースのメリットであると思います。
それに、そのソフトウェアを無料で使っているとすれば、それは当然でしょう。他人に労働を求める場合、対価を支払うべきであり、それはオリジナルの作者である必要性はまったくありません。それもオープンソースのメリットだと思ってます。
それに、そのためにディストリビューションのメーカーが存在しているのだと考えています。
> ここで、「オープンソースならばセキュリティレベルが高い」という立場で意見を述べている方々の根拠って、一体何なんでしょう?
いや、まさにそれを議論しているわけですが、「私の経験」から言えば、Linuxを始めとするフリーソフトウェアコミュニティのセキュリティフィックスは極めて迅速ですし(バグ発覚から半日以内に、とかもザラ)、Microsoftの製品に出たバグがフィックスされる早さと比べたら雲泥の差があるように感じています。個人的な経験によるバイアスがかかっていることは否めませんが。
Open?Free? (スコア:2, すばらしい洞察)
確かにソースコードが公開されている/いないというのは、どちらもセキュアであることには直結しないと思うんですが、セキュリティホールの指摘者を含む、ソフトウェアの作成者以外が対策patchを作成し得るか否かという点が決定的に異なると思います。これが可能であるがゆえに、オープンソースプロダクトの方がセキュリティ問題に対して迅速な対応がなされる場合が多い、というのが(一般的であるかはともかく)私のスタンスです。
無論、その対策案を受け入れ、かつ対策版 or 対策patchを公式にリリースするかどうかは、作成者側の判断にゆだねられます。しかし、使う側には事前に対策が実施できる自由がある。それがオープンソース(どちらかというと、GNUの言う「フリーソフトウェア」の方かも)の理念でしょう。
なお、ソフトウェアの実装面と運用面のセキュリティ問題をあえてごちゃまぜにした意見のように見えるのですが、切り離して考える必要あるのではないでしょうか?単なるユーザー(オンラインショップなどの顧客)から見れば、どちらだろうが同じことですが、そうしないとこの場での議論が発散してしまいます。
セキュリティホールが指摘されているバイナリパッケージを使いつづけるなんてのは、Windowsのセキュリティpatchを当てていないのと同様、単なる運用側の怠慢です。プロダクトがオープンソースであるかプロプライエタリであるかという話には全く関係ないと思うんですが。
目玉の数 (スコア:2, 興味深い)
また、kterm など、誰もメンテナンスしていない (目玉の数がゼロかもしれない) ソフトウェアが広く使われているという現状も、まずいんじゃないかと思っています。
そうですね、オープンソースのほうが確実に安全と言えるのは、バックドアがない (作ってもばれるかもしれないから作れない) ということでしょうか。
Re:目玉の数 (スコア:2, 参考になる)
Re:目玉の数 (スコア:2, 興味深い)
> (目玉の数がゼロかもしれない) ソフトウェアが広く使われている
> という現状も、まずいんじゃないかと思っています。
日本語入力システムに、セキュリティホールが結構あるとか
聞いたことがあります。
問題視されないのは、海外(英語圏)で騒がれず、翻訳文書を見て
口真似する日本人もいないからかしら?
# 痛いところをつかれた人には失礼(^^;
Re:目玉の数 (スコア:2, 参考になる)
ユーザ数、開発者数も多いはずなのになぜなんでしょうね?
ついでに言うと、昨日雑誌に付いていた、RedHat7.3をセキュリティレベル高でインストールしたのにjserverが動いていて困惑しました。
Re:目玉の数 (スコア:1)
こういう例 [cert.org]もあったりしますが・・・
# この例 1 つで「オープンソースは危険」と言う気はありませんが
# 「オープンソースだから確実に安全」とも言う気はありません。
Re:目玉の数 (スコア:1)
見てみぬフリをしているかもしれない。
というのもあるかもしれない。
最初の誰かに期待しちゃったりして。 (スコア:1)
ていうか、ソースがあるからといっても
よほど必要がなければそのままbuildしてしまうから
みることはほとんどないというのは言えてますね。
でも、そのソースに関して
すくなくとも、他の人が1人くらい見てくれるかもしれないと
かってに期待しちゃだめですかね?逝ってよし?
Re:えー (スコア:2, すばらしい洞察)
自分たちで納得いくまで確認ができ、不都合のある部分を自分たちで好きなように直せるから。NSAやFBI向けのバックドアがあるかもしれないソフトウェアを、普通の国は国防用途には使いたくないでしょうからね。この場合、あるかどうかが問題なんじゃなくて、ないことを自分たちで確認できない点が問題になるわけです。
Re^2: えー (スコア:1, 興味深い)
題名は、「Open Source Software May Offer Target for Terrorists, 」というような感じで始まっています。内容もそれに準拠するような形になっています。
Hotwired の記事の方にはこの、テロリストが関与(悪用)する危険についてまるで触れられていないのが、私にはむしろ疑問に感じました。何を持って「本質的に危険」かについての言及がなされていませんので。
個人的にはこちらの文章の内容(テロリスト製の巧妙にバックドアが仕込まれたオープンソースソフトウェアの危険性に気付かずに、安易に軍関係のシステムとして利用した場合の危険性)に加えて、テロリストとは関係のない人達が作ったソフトウェアであっても、いち早くテロリストがそのソフトウェアの危険性のある欠陥を見つけた場合に、そこを確実に突かれて被害を及ぼされる危険性というのもあるように思いました。外的な状況からソフトウェアの欠陥を予測されるより危険だと思います。
そういう意味では、オープンソースであるソフトウェアを利用する方が、自家製でクローズドなソフトウェアを利用するよりも本質的に”外部からの関与に対して”危険である、と言えるのかも知れないと思いました。
#と、ここまで云わせていただきつつも、読み間違えていましたらごめんなさい。
補足です (スコア:2, 参考になる)
その歪曲された話を基盤にスラドの人達が議論してしまっているのでは? ということで、以上のような発言をさせて頂きました。
#でも、結局私の勘違い(マイクロソフトの工作だった)でしたらすみません。
#モデレートして頂いてありがとうございました。
Re:えー (スコア:2, すばらしい洞察)
『目玉に直結した手』の数が十分あるから安全な方向に向かうんだと思います。
たくさん穴が見付かってるのは、 目玉だけならたくさんある(十分かどうかはともかく)からでしょうし。
Re:えー (スコア:2, すばらしい洞察)
「プロプラだから安全性が低い」というのは明らかにfalseですし、「プロプラだと安全性が低くなる傾向にある」というのもfalseではないですか?
結局、個々の開発方針体制や開発方針による差異の方が大きいはずで、オープンソースだろうとプロプラだろうと、例えば「便利だからあんな機能もこんな機能も入れちゃおうぜー」とかいうノリで安全性を考えずに開発してたらヤバいことになる、というだけの話だと思いますが。オープンソースの代表格OS(と言っても良いですよね?)のLinuxとSolarisを比較して、Linuxの方が安全だと言い切れますか?
オープンソースとプロプラを比較する時に、ほぼ確実に「GNU、Linux、BSD一派、X11などなど」と「Microsoft」という無意識の対比から「プロプラってダメだよね」という話になりやすいんじゃないかと思いますが、マイクロソフトを基準にプロプラ全般の話をしたら、SunやOracleなどは激怒しますよ。
Re:えー (スコア:1)
Sunの技術者たちにとっての「いつかきた道」がMSの技術者たちにとっては「今進んでる道」。
Re:えー (スコア:1)
いや、それを言ったら結局そうなんですけど、例えば同じ開発陣が
開発するとして、open sourceな方法とclosed sourceな方法を取った場合、
どちらがバグ潰しが早く進むか、セキュリティホールが早く潰れるか、という
ことを考えると、open sourceな方のメリットが見えてくるんじゃないでしょうか。
そりゃもちろん、死ぬほど優秀なプログラマがclosedな方法で開発する方が、
私がopenな方法で開発するよりよっぽどいいモノを作るだろうし、
バグも少ないでしょうけど、そういう議論をしてるわけじゃないですよね。
Re:えー (スコア:1)
>開発するとして、open sourceな方法とclosed sourceな方法を取った場合、
>どちらがバグ潰しが早く進むか、セキュリティホールが早く潰れるか、という
>ことを考えると、open sourceな方のメリットが見えてくるんじゃないでしょうか
必ずしもそうともいえないかも。
オープンソースの場合は、「外部の優秀な人のレビュー/テストを期待する」
というだけであって、それが保証されているわけではないよね。
プロプライエタリな場合、ある程度の質のレビュー/テストは保証されているわけで。
だから、外部の人の関心が高いプロジェクトの場合、オープンソースのメリットは出やすいけど、
そうでない場合はプロプライエタリなソフトのほうがメリットは出やすいんじゃないかなあ。
あと、オープンソースの場合、あまり使われない部分はそもそもバグが
発見されない可能性があるのではないか、という気がする。
プロプライエタリな場合、あまり使われない部分でも一通りテストはするはずだよね。
逆に、みんなが使うような部分はオープンソースのほうがすぐにバグが潰されるのではないか、という気がするし。
なので、結局「オープンソース/プロプライエタリなソフトのほうが早くバグがつぶれる」
というのはどっちも幻想でしかないと思う。
Re:えー (スコア:2, おもしろおかしい)
それをやれば成果が直結する、とは言えないとはいえ一応、
たとえば、UnitTestのツールとかが色々フリーソフトウェアとして出回っているわけですよね。
ならば使えばいいじゃん、という感じかと。
一通りのテストを「楽に」やれるならば、趣味ソフトでもテストやるだろうし、
XPの頁によれば(信じるならば)UnitTestはヤミツキになるものだそうだから、
趣味性と相容れないという事は無いはず。
そういやRubyApplicationArchiveにアップされてるクラスって、しばしばRUnitとか使ってるよね。
>プロプライエタリな場合、ある程度の質のレビュー/テストは保証されているわけで。
>プロプライエタリな場合、あまり使われない部分でも一通りテストはするはずだよね。
「保証」とまで言われたら、甘い!、と言いたくなります。はい。
きちんとしたレビュー/テストの手順を踏んでいる保証が有れば、「いい」んですけどねえ…(まぁそれはフリーでも同じだが)
そうそう。こないだの雑誌(Cマガだったかソフデザだったか…)に
猟師プログラマとかいう人(だっけ)が書いてた記事を読むと、
たとえそれが本当でなかったとしても、そういうことが生じ得る「可能性」に寒けを覚えると思いますよ。
段ボール数箱の仕様書、というクダリで笑えなかった俺(T_T)。
仕様書ってソフトと違ってそれを「(きちんと)デバッグ」することができないんだよね、という話も笑えなかった俺(T_T)。
職業(という概念)には貴賤はなくても、職場(個々の実在)には貴賤は有ります。はい。
もしそうでないなら、誰が、契約相手を「選ぶ」必要を感じたりするでしょうか?
ゆめ油断めさるな。
Re:えー (スコア:1, すばらしい洞察)
同じ開発陣しか開発に携わらないなら、open sourceだろうとclosed sourceだろうと同じでは?
というツッコミはさておき、仮にWindowsのコードがGPL等で公開されたとして、あっという間にbug fixされて安全なOSになると思いますか?私はそうは思いませんね。
例えばNetscapeだって、せっかく苦労して公開したソースは、見切りを付けられて捨てられちゃいましたね。で、そのときにNetscapeだかMozillaだかから出てたコメントにありましたが、「オープンソースという魔法の粉を振り掛けると全てが上手くいく、というワケじゃない。ダメなものはオープンだろうが何だろうがダメなんだ」ということです。
Re:えー (スコア:1)
技術的なフィードバックが可能かどうかで、ずいぶん違ってくると思うのですが…。
> 「オープンソースという魔法の粉を振り掛ける と全てが上手くいく、というワケじゃない。ダメなものはオープンだろうが何だろうがダメなんだ」
jwz氏のコメントだったと思いますが、それはそれで正しいんだと思います。というか、別に最初のコードベースがポシャったのは方法論の優劣ではなく、「ダメなものはダメ」ということ以上でも以下でもないと思いますが。
「タラコにはどんな調味料をかけてもキャビアにはならない」というか。
Re:えー (スコア:2, 興味深い)
でも、それが分かっただけでもオープンソースにした意義があるんでない?
クローズドのままだったら、それすら分からずひたすらだめなコードをいじくり回しつづけてたかもしれないわけだし。
オープンにして多くの目にさらされたからこそ、「ダメなモノはダメ」と分かったんじゃないかな?
あるいは企業内なんかだと、分かっていても返られない状況ってあるでしょ?
たった一人の「ぴー」な上司の命令で方向転換が出来なくなっちゃう状況って。
オープンソースならプロジェクトに参加している人は(当然最終意思決定者がいるにしても)みなほぼ同列なわけだから、ダメだと判断したら比較的柔軟に対処できる素地はあると思うんだけどどうだろう?
テストをする目玉の数 (スコア:2, 興味深い)
クローズドなソフトウェアであっても、動作をテストする人が100人、1000人と
いれば、問題を見つけて報告し、完成度を高める上では同等の効果が
あるのではないでしょうか。
「目玉の多さ」の中には、たとえコードは読めなくても、
使って評価してくれる人の数も忘れてはならないと思う。
Re:えー (スコア:1, すばらしい洞察)
自分が要求する機能の部分以外は、なかなか見ないものです。
ソース読むのはそれなりに労力かかりますもん。
Re:えー (スコア:1)
もちろん自分で使った上でクラックされてる某社は論外なわけですが。
Re:えー (スコア:1)
もうやってないのかな?
フィクションでなければ、ですがゲイツが「自分達で使えないモノを出荷する
気か」みたいなことを言って、自ら率先して前日ビルドされたWindows(当然
落ちまくり)を使ってた、とか言う話だったと記憶してます。
Re:えー (スコア:1)
オープンソースの違い (スコア:2, 興味深い)
オープンソースの最大の利点はやはりそれなりの能力のある人間には中身が透明である、ということ。つまり、一般の「利用するだけ」の人は利用できればよいのであって、オープンソースであるかどうかは、どうでもいいことなんですよね。だから一般利用者にとっては「オープンソースものはよくない」という言い方も「オープンソースものはいい」と言う言い方とおなじくらい価値がない。
つまり、この文章自身が本当はあまり価値をもたないものなのではないのでしょうかね?。
つまり、内容はなくとも、このような文章を「発表」することによって、オープンソースを推進する側になんらかのダメージを与えよう、という魂胆なんだろうと思います。つまりこういう文章を発表することに意義がある、ということと思います。
Re:オープンソースの違い (スコア:3, 興味深い)
前半から後半へは、論理の飛躍が過ぎるようです。現実には、自分で現象から不具合を見つけた時、自分で該当するソースを調べ、自分で修正してバイナリを構築できるって話が大半なわけで、少なくともシステム屋であるわたしにはこれで十二分なメリットです。もちろんプロプライエタリなソフトウェアでも、バイナリパッチを当てたりAPIの呼び出しにフックをかけたりして対処する豪の者がいるにはいますが、さすがにそんな技術を持つ人は相対的に少ないでしょうし、そんなまわりくどいことをしなきゃいけないことが大きな足枷であると感じます。
あちこちで書いたことを繰り返しますけど、ソースがオープンでかつそれを改変できるというのは、一種の自由でしかないわけで、それを活かすのは簡単ではありません。が、活かせる可能性が存在することは非常に大きなメリットだと思います。
セキュリティ云々をいうなら (スコア:2, すばらしい洞察)
オープンソースが安全か、商用だと安全だとかいう
議論よりもいかにセキュリティパッチが早く安全に
当てられるようになっているかを議論すべきでしょう。
ソフトのセキュリティ強度を比較するならバグの個数ではなく
パッチが適用されているシステム数 / システム数で
比較すべきだとおもいます。
Re: オープンソース・ソフトは危険? (スコア:1)
Re:FFFTP (スコア:1)
それでも自発的に直そうとする人がいないのなら、 あなたが直すか、その能力がなければ誰かを雇って直してもらえばいい。 それが可能なのも、オープンソースならではのことですよ。
FFFTP&オープンソース (スコア:1)
作者のページを見ると再頒布は自由ですが、派生ソフトを作るのは明示的に認めてはいない [biglobe.ne.jp]ようですが。
派生ソフトを作れないのでは、オープンソースとは言えない [opensource.jp]のでは。つまり、 よね?
/.configure;oddmake;oddmake install
Re:FFFTP (スコア:1)
ところが現実にはFFFTPぐらいしか対案はないわけで、そのFFFTPが持ち出されているこの親コメントに対するこの一連のフォローの論調はかなりおかしいと思います。
また、104451 [srad.jp]の「IEの脆弱性の記事の真下に、こうした記事が載る、というのもなかなか興味深い。」というのも、最もに見えます。ところが、例えばここの読者の方が100%利用していてお馴染み、かつ影響の大きい「slashdot.jp」自身に数多くのXSS脆弱性が見つかってますが、スレッドは 「Slashcodeにバグ、任意のユーザーに成りすまし可能 [srad.jp]」の1回しか立っていないのです。おかしいとは思いませんか?
スレッドのネタになった、「オープンソースのソフトは危険という内容の報告書」も恐らく最初に結論ありきなのでしょうが、ここで書かれている多くの方の姿勢も、最初に結論ありきのような気がします。
office
Re:FFFTP (スコア:1)
>最初にこのソフトの名上げた方
関係者ですか?変なの。
一応仕事で使ってますけど、上記ソフト。
機能少なめなので、常時使ってるのは某シェアウェアです。
バグってて使えないなら、さっさと別のに乗り換えましょう。
文句言うのは筋違いだと思います。
おそらく (スコア:1)
自分で調べるべき範囲をズケズケと作者にメールで聞いてきたり、機能追加の要求(要望ではない)してきたり、ちょっとバグがでてくれば「すぐに直せ、馬鹿野郎」という罵倒の嵐。高圧的な態度のメールは日常茶飯事...。
でも作者は、こういう彼らを懇切丁寧に相手しなければなりませんし、あるときには手取り足取り指導しなければなりません。
もし、相手にしなかったり、誠意をもった対応をしなければ彼らは腹いせにいろいろなサイトの掲示板で中傷を書き込むことがあります。
おそらく、FFFTPの作者も「不満があるなら自分で好きに直してね」という意味を込めてソースを公開したのでしょうけど、それでもこのようにコメントが書き込まれるのが現状です。