アカウント名:
パスワード:
ところで、「注意はよく読みましょう部門」とのことですが、その「注意」というのは、「全く安全ではないですが,とても便利です」のことでしょうか?
タレコミにも書きましたが、BUGTRAQで報告されたときの、slashcodeのメンテナの第一声は、「きちんと警告している」という弁明でした。原文 [securityfocus.com] では、
...you were impatient, I guess. But the explanation is simple. Our users access that link from these pages: (略) which inform him
一般に、脆弱性の指摘を受けたときは、問題ないとする反論をまず考えようとするのではなく(ついそうしてしまうのはわかるが)、問題がないように思えるなら、指摘者が何を問題視しているのかを、尋ねるなりして確認するよう努める姿勢を心がけたいものです。指摘をした側も、「問題ない」と否定されると(そしてそれが間違っていると)それに再反論するのに余計なエネルギーを必要としてしまうのが人情だと思います。
今回の件も「パスワードが漏れる」じゃなくて、「誤入力した(ログインできない)パスワードのMD5値が漏れる」だろ?
それともMD5値から元のパスワードを復元する方法でも見つけたの?それは素晴らしい!!
問題を見つけても、鬼の首を取ったように騒ぎ立てるんじゃなくて、
「報告」というのは真意が相手に伝わってこそ意味があるんだから、相手が理解に届かなかったら理解できるように説明すべきだろ。
それもせずに「はい時間切れです。大公開」ってやっちゃうから、「何だかわかんないけど大問題があるらしい」って公表せずに
何かしら間違いはおこしてしまう。 間違いは正さなきゃいけないけど、その間違いを本人が気付いていなければ他者からの「報告」によってしか知る事はできない。 理解の届いていない問題をコードから読み取って直すというのはすごいエネルギーの必要な作業だから、
自分が理解している問題なんだったらちゃんと説明して理解を得る努力をした方が結局は短時間で問題が解決するんじゃないか?
あんたらセキュリティゴロがよく言う「時限を切ってそれを過ぎたら公表する」とか「直したんなら謝罪文を載せろ」というのは、
回線切ってLANケーブルで首吊ってください
誤解があるようですが、私は叩くということをしていません。
あなたは他人の痛みがわからない人なんですね。
また、他のサイトで同じパスワードを使用している場合にも警戒が必要で
「MD5値からパスワードを復元できる」という前提が成り立てばその通りですが、そういう前提は成り立ちません。
パスワードによっては短時間で復元されることがあります。
は?何言ってるんですか? 類推可能なパスワードをMD5して該当MD5値と一致したら「復元された」と言ってますか? それはMD5値を復元したのではなく、類推したパスワードをMD5値で検証しただけ
は?何言ってるんですか? 類推可能なパスワードをMD5して該当MD5値と一致したら「復元された」と言ってますか?
パスワードが類推可能なのであれば、ターゲットへ類推したパスワードを入れてみれば検証できます。
そもそも、漏れてしまった場合のセーフティーネットとして生パスワードではなく、MD5値を使っているのですから、その漏洩対策の一つに穴があったからと言って即「パスワードが漏れる脆弱性」というのは騒ぎすぎなのではないですか?
多重に防護すればするほど安全性は向上しますが、その代わりコードは肥大しますからバグの侵入する可能性も増えます。
10の安全性を確保した上で更に5の安全性を加えて、その5の部分に穴があっても10に落ちるだけで0まで落ちてしまうわけではありません。 MD5値が漏れるという事象に対して直ちに「パスワードが漏れる脆弱性がある」というのは、安全性が15から10に落ちだだけなのに、0だって言ってるようなものです。
無論15の安全性を目指しているのですから穴は塞ぐ必要はありますが、「パスワードが漏れる脆弱性がある」というのは誇張しすぎです。
もしかしてあなたはいわゆる辞書攻撃というものをご存じないのでしょうか?
もしかして私バカにされてるんだろうか? まぁACだからいいけど。
私は、MD5値が漏れる事=パスワードが漏れる事、という論理が飛躍しすぎていると言ってるのであって、辞書攻撃で解読されてしまう程度のパスワードはユーザのパスワード管理の問題だと思います。
そもそも、MD5値が漏れるのが「パスワード漏洩の脆弱性」と言うのであれば、APOPも「パスワード漏洩の脆弱性」を抱えている事になりますね。 SlashcodeにAPOP以上のセキュリティを求めるあなたのバランス感覚がおかしいとは思いませんか?
もしかして私バカにされてるんだろうか?
辞書攻撃で解読されてしまう程度のパスワードはユーザのパスワード管理の問題だと思います。
私は、MD5値が漏れる事=パスワードが漏れる事、という論理が飛躍しすぎていると言ってるのであって、
SlashcodeにAPOP以上のセキュリティを求めるあなたのバランス感覚がおかしいとは思いませんか?
いいえ。MD5値であっても、それが漏れたら即、スラッシュドットには成りすましログインができますよ 論理のすりかえですね。 私は「MD5値の漏洩」=「パスワードが漏れる脆弱性」というあなたの論理が飛躍しすぎている(=騒ぎすぎ)という話をしているのであって、スラッシュドットのアカウントが乗っ取られるとか、そういう事は一切言っていません。
いいえ。MD5値であっても、それが漏れたら即、スラッシュドットには成りすましログインができますよ
スラッシュドットへのログインに関しては、MD5値が漏れることとパスワードが漏れることは同等です。アカウントが乗っ取られることを一般読者にわかるようにパスワードが漏れたと表現しました。タレコミ文の中には実際にはMD5値であることは示してあります。
スラッシュドットへのログインに関しては、MD5値が漏れることとパスワードが漏れることは同等です。
同等の効果が得られても同じ事ではありませんね。 指摘する側が、そういう「センセーショナルな嘘(というか誇大表現)」をするから反発を受けるのでは?
アカウントが乗っ取られることを一般読者にわかるようにパスワードが漏れたと表現しまし
なぜ「パスワードが漏れるリスク」というセンセーショナルな誇大表現をしますか?
だから「同等でも同じものじゃない」でしょ。
なぜ「アカウント乗っ取りのリスク」という正確な表現ができるのに、「パスワード漏洩のリスク」という似ているけど嘘の表現をしますか?
それどころか、むしろ、「アカウントを乗っ取られる」というタイトルでは、「セッションIDの漏洩が原因」と解釈される方が普通(世の中ではそのようなセキュリティホール(セッションID漏洩によるアカウント乗っ取り)が大半を占める)ですから、それでは危険度を低めに説明してしまう(セッションIDは使い捨てなので時間が経っていると乗っ取れないという点で脅威の現実性が低めになる)不適切なタイトルになってしまいます。
つまり、この種の話題の伝達で正確さを期すには、できるだけ結果よりも原因に近い部分を説明するのが適切です。結果の方を書くと、その結果がもたらされる現実性の高さの情報が失われてしまいがちです。 しかし、原因に近い部分というのは、より技術的な説明となりがちなので、一般利用者にわかる範囲で最も原因に近い部分を示すことになります。これがこの種の話題の伝達の際にタイトルに選ぶべきポイントです。
さらに言えば、タレコミではタイトルは「Slashcodeが一部ユーザのパスワードを漏らす」としていました。(「…リスク」という表現は編集担当者によるものです。) これは、パスワード(のMD5値)が実際に私のサーバに漏れてきていた事実を伝えることが、このタレコミの重要な要点のひとつであったからです。
あなたは「触れる必要がある」程度のものをタイトルに付けるのですね。
他で使っているパスワードを知る大きな手がかりを与える事になります。
スラッシュドットへのログインに関しては、MD5値が漏れることとパスワードが漏れることは同等です。同等の効果が得られても同じ事ではありませんね。
指摘する側が、そういう「センセーショナルな嘘(というか誇大表現)」をするから反発を受けるのでは?
タイトルに正確な情報をすべて詰め込むことはできないので、タイトルの表現が多少不正確だったり足りなかったりするのはしかたのないことです。 今回 jbeef さんが、正確には (M+A) であるこの弱点を多少不正確でもいいから短く書こうとして、小さすぎる (A) という書きかたではなく大きすぎる (P) という書きかたを使った理由も、ぼくにはわかりません。
今回 jbeef さんが、正確には (M+A) であるこの弱点を多少不正確でもいいから短く書こうとして、小さすぎる (A) という書きかたではなく大きすぎる (P) という書きかたを使った理由も、ぼくにはわかりません。
また、「P」は原因です(もたらされる脅威の)が、「A」は原因ではなく(もたらされる)脅威ですので、「A」を言っただけでは、それが常に起きることなのか、短期間に限り起きることなのかといったを言い表せていません。「P」が原因の「A」という脅威は、常に起きることですが、単に「A」と言っただけではそこまで表現できていません。このことについては既に#171634 [srad.jp] で述べてあります。
あなたは生パスワードの漏洩とMD5値の漏洩は同値であると主張してる
MD5値で生パスワードが漏洩するという事だけに付いて議論してるんだからね
(ユーザ向けのニュースにおいて)小さすぎる書き方は、責任を問われかねないという点に注意してみてください。
また、「P」は原因です(もたらされる脅威の)が、「A」は原因ではなく(もたらされる)脅威です
「P」が原因の「A」という脅威は、常に起きることですが、単に「A」と言っただけではそこまで表現できていません。
不正確に小さく書くのと不正確に大きく書くのとでどちらが読者のためなのか はそう簡単に判断できることではないと思います。
また、「P」は原因です(もたらされる脅威の)が、「A」は原因ではなく(も たらされる)脅威です いいえ、ぼくはここでは「パスワードが漏洩する」ということ自体を脅威の一 つと数えています。
また、「P」は原因です(もたらされる脅威の)が、「A」は原因ではなく(も たらされる)脅威です
「P」が原因の「A」という脅威は、常に起きることですが、単に「A」と言っ ただけではそこまで表現できていません。 (P) ならば (A) ですが、逆は成り立たないという意味ですね。それならその 通りです。
「P」が原因の「A」という脅威は、常に起きることですが、単に「A」と言っ ただけではそこまで表現できていません。
同様に、 (P) ならば (M+A) だし、 (M+A) ならば (A) ですが、ともに逆は一 般的には成り立ちません。
「(A) と表現することが不正確」というだけでは、タイトルに (P) を掲げる ほうが (A) を掲げるよりもいい理由を説明したことになりません。
世の中には「ユーザのため」と言いながら自分のために弱点を大きく書く人が いてもおかしくありません。
Aと言っただけでは別のタイプの(別の原因の)脆弱性(例えばセッションID 盗用の場合は一定期間だけアカウント乗っ取りの脅威にさらされる)のことと区別できていない(ので不十分な説明)ということを述べています。原因Pを示せば、一時的ではなく常時Aの危険に晒されること(追記すれば「パスワードを変更している場合には脅威がない」ことも)を説明し切れる点で厳密性があることを述べています。
世の中には「ユーザのため」と言いながら自分のために弱点を大きく書く人がいてもおかしくありません。本文中の話とタイトルの話は区別して書いた方がよいです。
世の中には「ユーザのため」と言いながら自分のために弱点を大きく書く人がいてもおかしくありません。
ならば、完全に間違いでしょう。今回 (A) が起きる原因は (P) ではなく、パスワードの MD5 が漏洩することなのですから。
そうですか? タイトルを大きく書いて必要以上に人目を引いたら、それはそれで問題のある書きかたです。今回、「必要以上」だったかどうかはよくわかりませんが。
スラッシュドットへのログインに関しては、PもMも結果に与える影響が同等です。私は、Aをタイトルとすることの不十分さを説明するために上のことを書きました。
短いタイトルに厳密さを求めるのには限界があるというというのはtixさんもおっしゃったではないですか。
ユーザ向けには安全側に倒す必要があるという論点も出ました。
その初出の部分で「(のMD5値)」と括弧書きで書かれているという点こそ、まさにjbeefさんが「(P)==(M)である」と認識していた(=(P)が不正確な表現であるとは認識していなかった)という証左ではないでしょうか?
#171458さんとは別人です。私が書いたのは#173647,#172697, #172510ぐらいかな?
多少流れがわかりやすくなりました。どうも。
私はいわゆる「商業プログラマ」ですが、「Re:私刑、ですか……」という方も興味深いですね。
たくさんのコメントをすべて読んではいませんが、このコメントは読んでみました。たしかに面白いです。ソフトウェアの開発者と弱点の発見者のコミュニケーションがどうしてうまくいかないかを説明できる可能性がありますね。 でも、その後のコメントで、やっぱり「ハッカーコミュニティとセキュリティコミュニティの対立」(?)という雰囲気のフレームが起きているようなので、悲しくなります。 なお、ぼくは商業的なソフトウェアの弱点を発見したり指摘したりしたことはありませんが、フリーか商業的かで指摘の方法を大きく変えることはないだろうと想像しています。 ぼくは今までにフリーソフトのセキュリティホールを少しだけ指摘したことがありますが、いずれも、無視されたり、不完全な修正にとどまったりしています。修正されないソフトは使わなければ個人的にはそれで済むので、社会的な責任を考えないようにして黙っていますが、もう少しぼくにコミュニケーションの能力があれば修正してもらえたのかもしれないと思うと悔しいです。 そんなぼくが書いても説得力がありませんが、ぼくがソフトウェアの弱点を作者に報告するときには、報告を読んだ作者が「直そう」と思ってくれるような報告を書くことを心掛けています。これが当然と思う人は幸せなのですが、ぼくの場合、ともすれば、作者にぼくの力を見せ付けてやろうとか、要らぬ考えが浮かんでくるので、そういう邪念を抑えて報告を書くのは労力を要します。 例えば、「こんな弱点だらけのソフトウェアを何の警告もなく公表しているようでは、あなたの正義感や開発者としてのセンスを疑います」のようなことを書きそうになったこともあります。こんなことを書いても、作者はやる気を出してはくれないでしょう。怒って読むのをやめるか、悲しんでソフトウェアを書くのをやめるか、いずれにしても弱点は修正されない可能性が高いです。 何が言いたいかというと、問題が理想的に解決に至るためには開発者がやる気を出してくれることが必要であり、開発者がやる気を出してくれるような報告を書くべきだということです。この点では、べつにフリーか商業的かなんてあまり関係がないと思います。 ただ、商業的なソフトウェアの場合「こんなソフトウェアで金を取るなよ」とか考え始めるとまたいろいろな邪念が出てきて、まともな報告(報告を読んだ開発者が「直そう」と思ってくれるような報告)がしづらいだろうとは思います。
でも実際の所、フリーの場合だと自分で「公表する」と決めたら即公表できますが、商業プログラマなんて「公表するかしないか」という意思決定に直接関与できないので、ツラい面もありますね。
商業的なプロジェクトであっても、「公表するかしないか」の意思決定をする人がセキュリティに詳しければ、すべて自分でやらなければならない個人プログラマよりもかえっていい行動が取れると思うのですが、難しいのでしょうね……。 フリーソフトウェアであっても、多人数のプロジェクトだと、「弱点を公表するかどうかの意思決定に関われない開発者」という存在が出てくると思うのですが、そちらでも同じように辛い思いをしている人がいるのか、気になります。
その2点は間違っていません。でも、(P) と (M) はスラッシュドットへのログイン以外の点で影響が異なります。
Aと言っただけでは別のタイプの(別の原因の)脆弱性(例えばセッションID 盗用の場合は一定期間だけアカウント乗っ取りの脅威にさらされる)のことと区別できていない(ので不十分な説明)ということを述べています。原因Pを示せば、一時的ではなく常時Aの危険に晒されること(追記すれば「パスワードを変更している場合には脅威がない」ことも)を説明し切れる点で厳密性があることを述べています。 ならば、完全に間違いでしょう。今回 (A) が起きる原因は (P) ではなく、パスワードの MD5 が漏洩することなのですから。 スラッシュドットへのログインに関しては、PもMも結果に与える影響が同等です。私は、Aをタイトルとすることの不十分さを説明するために上のことを書きました。 その2点は間違っていません。でも、(P) と (M) はスラッシュドットへのログイン以外の点で影響が異なります。
Aと言っただけでは別のタイプの(別の原因の)脆弱性(例えばセッションID 盗用の場合は一定期間だけアカウント乗っ取りの脅威にさらされる)のことと区別できていない(ので不十分な説明)ということを述べています。原因Pを示せば、一時的ではなく常時Aの危険に晒されること(追記すれば「パスワードを変更している場合には脅威がない」ことも)を説明し切れる点で厳密性があることを述べています。 ならば、完全に間違いでしょう。今回 (A) が起きる原因は (P) ではなく、パスワードの MD5 が漏洩することなのですから。 スラッシュドットへのログインに関しては、PもMも結果に与える影響が同等です。私は、Aをタイトルとすることの不十分さを説明するために上のことを書きました。
Aと言っただけでは別のタイプの(別の原因の)脆弱性(例えばセッションID 盗用の場合は一定期間だけアカウント乗っ取りの脅威にさらされる)のことと区別できていない(ので不十分な説明)ということを述べています。原因Pを示せば、一時的ではなく常時Aの危険に晒されること(追記すれば「パスワードを変更している場合には脅威がない」ことも)を説明し切れる点で厳密性があることを述べています。 ならば、完全に間違いでしょう。今回 (A) が起きる原因は (P) ではなく、パスワードの MD5 が漏洩することなのですから。
公表者には、小さすぎる表現をするリスクと大きすぎる表現をするリスクの二つの間でバランスを取るという難しい作業が求められているのだと思います。
jbeef さんは、「タイトルに (A) と書くよりも (P) と書いたほうがよい」というのを盲目的に信じていませんか?
括弧書きというのは通常「無くても意味は通じるが、詳しく説明するため」に付けるものであって「不正確な表現を訂正するため」に使われる記法ではありません。
これでもtixさんは正常な議論をしていると思いますか?
jbeef さんは
と書かれていますが、その部分では本当に文字通り、 (A) をタイトルとすることの問題点を書いていただけなのですね。わかっていませんでした。すみません。 (A) が不十分なのは承知しています。 (A) が不十分な理由を、ぼくは「今回の弱点の被害は (M+A) だが、 (A) だからといって (M+A) とは限らないから」つまり「(A) だけでは説明できない被害があるから」と思っており、 jbeef さんは「(A) は弱点により引き起こされる結果 (の一つ) でしかないから」(強調部はぼくが補った)と思ってみえるようですが、この理由の差は表面的なもので、議論には関係ないと思います。 (P) をタイトルにすることの問題点はどうなってしまったのでしょう。 弱点を (A) だと述べることは弱点を過小に評価しています。それと対称的に、 (P) は過大に評価しています。 (A) が過小でタイトルとして不適格なら、 (P) は過大であってタイトルとして不適格です。 だから過小でも過大でもないタイトルを付けるなど無理だ、というなら、タイトルは過小でも過大でもいいのです。本文で正しく説明すればいいのだから。あるいは、スラッシュドットへのタレコミなど、正確でなくたっていいとも思います。正確でなくて重要なことなら、誰かが指摘するので(希望的観測?)。 でも、 jbeef さんは過大なほうに倒そうとなさっているようです。 jbeef さんは、過大な表現ばかり使うことで、報告を読んだ人に信用してもらえなくなるリスクをどう考えてみえるのですか?
ちなみに、一次情報源のタイトルは「slashdot / slashcode disclosing passwords」でした。
知りませんでした。これが理由でタイトルを (P) としたというなら、理解できます。でも、一般論として「過小に書くより過大に書いたほうがまだましだ」と思ってみえるのなら、それには同意できません。
「と書いた方がよい」の根拠を論理的に説明しているのに、「盲目的に信じていませんか?」とおっしゃるのですか。 #172307でせっかく書いた説明はシカトしておいて。
#172307 を書いていただいたことは感謝していますが、 #172307 は反論としては不十分です。ぼくは「小さく書くのと大きく書くのは両方とも問題であり、どちらがいいとは一概に言えない」と主張しています。大きく書くことが問題であることの根拠は #172228 [srad.jp] にも一言だけ書きました。 jbeef さんは「小さく書くのは問題だ」とばかりおっしゃって、「大きく書くことも問題だ」という点をどう考えているのか書いていただくことができずにいます。その様子から、考えるのを拒んでいるという印象を受けたので、「盲目的に」と表現してしまいました。お気に障ったらごめんなさい。
ちなみに、この件で私は「公表者」ではありませんよ。ニュースのタレコミ者です。
「公表者」というのを「弱点を発見した人」や「誰かの見つけた弱点を Web で告知する人」(スラッシュドットでは投稿というプロセスが挟まりますが、基本的にはタレコミ者もこの範疇だと思って書いています)などを総称する言葉として使っていました。説明なしに使ってしまったのはわかりにくかったかもしれません。
tixさんは、
jbeef さんは「小さく書くのは問題だ」とばかりおっしゃって、「大きく書くことも問題だ」という点をどう考えているのか書いていただくことができずにいます。
どう考えているのか書いていただくことができずにいます。
その様子から、考えるのを拒んでいるという印象を受けたので、「盲目的に」と表現してしまいました。
#172307 を書いていただいたことは感謝していますが、 #172307 は反論としては不十分です。ぼくは「小さく書くのと大きく書くのは両方とも問題であり、どちらがいいとは一概に言えない」と主張しています。
ちなみに、この件で私は「公表者」ではありませんよ。ニュースのタレコミ者です。 「公表者」というのを「弱点を発見した人」や「誰かの見つけた弱点を Web で告知する人」(スラッシュドットでは投稿というプロセスが挟まりますが、基本的にはタレコミ者もこの範疇だと思って書いています)などを総称する言葉として使っていました。説明なしに使ってしまったのはわかりにくかったかもしれません。
ちなみに、この件で私は「公表者」ではありませんよ。ニュースのタレコミ者です。スラッシュドットがいつもそうであるように、どこかの一次情報源をきちんと参照した上で、二次情報源として紹介しているだけです。 私が一時情報源となる場合には、正確さが要求されるだけに、紙面の限られるような場には書きません。
一般論か個別論かという分類はよく理解できません。
以下はようやく個別論について述べて頂けたようですが、
二次情報であって許される文章の量が限られているからといって甘く考えず、注意して書いていただければよかったと思います。文章の量が限られていても、できることはあったはずです。
ぼくは、タレコミ文を読んだ後で事実を知って「また大袈裟に騒いでいるのか」と思ったわけです。
スラッシュドットのユーザページ [srad.jp]にある「パスワード」というリンク [srad.jp]の先には、 このリンクをクリックすると,自動的にログインすることができます.クリックした先のページをブックマークしてください.全く安全ではないですが,とても便利です. というリンクがある。そのURLにはユーザ名とパスワード(のMD5値)が含まれているので、アクセスするだけでログインできるわけだが、
このリンクをクリックすると,自動的にログインすることができます.クリックした先のページをブックマークしてください.全く安全ではないですが,とても便利です.
元報告に「パスワード」と書かれていたので、「パスワード」と信じて間違いに気付かないほど無能だった 「パスワードのMD5値」の事を「パスワード」と書けば正しく皆に伝わると考えるほど無能だった 未だに「パスワードのMD5値」を「パスワード」と書くのは正しいと信じるほど無能である の、どれ?
だけど、「セキュリティ専門家」は「無能を無能と言うのは正しい」という文化のようだから、あなたがたの文化に合わせてるだけ。
あなたは一度も代案を示そうともしてこなかった(つまり、この件でのタイトルの難しさを理解している)
今回の書きかたの裏に、弱点の影響を大きく書いて目立ちたいという心理があるのではないかと疑っていました。その疑念のせいでまっとうな議論ができなかったとしたら、ぼくのせいです。
この書きかたにもいろいろ問題点はあって、まず「ログイン用 URL」では何のことかわからないので本文中で説明する必要があるし、タイトルが長すぎるかもしれません。結局「ログイン用 URL の漏洩」によって何が起きるかはタイトルだけではわからないわけですし。
そして、ご自身、お気づきのように、このケースではそんなに簡単に完璧なタレコミ文を書くことはできないものでした。もちろん若干の改善方法はあったでしょう。しかし、「注意せずに書いた」と非難されるほどのものではないと考えているということです。
パスワード(のMD5値)
「時限を切ってそれを過ぎたら公表する」
「直したんなら謝罪文を載せろ」
個人的な金銭目的の恐喝ではないんだろうから(中には自社や関連会社のセキュリティサービスを買わせるような本当のゴロもいるみたいだけど)多少は大目に見れるけど、やってる事は一緒。
「いゃそんな事は無い」とおっしゃるかもしれませんが、受け取る側はそう受け取っているという事で、指摘する側が「これで十分だ」と思っている「思いやり」では足らないという指摘をしているつもり。
何もプログラマから「コントロールしている実感」を奪い取ってまで「セキュリティ専門家」が行わなくても良いのではないですか?
プログラマ自らが情報公開をするよう促し、お願いする事でも満たされる要件ではないですか?
「初っ端にいきなりコワモテで来られれば」という特定条件下での行動として「逃げる」と書いてるだけなのに、そういう前提条件を無視して「逃げるようなヤツは思いやりが無い」ですか。はぁ。
「セキュリティーホールの発見」というのは、自分で見つけたのであれ、他人に指摘されたのであれ、「他者からの賞賛」を減ずるもので、フリーソフトプログラマの糧に対する直接的ダメージです。 そのダメージを受けている所に「○○日までに~」という他からの「コントロール」が入る、あるいは、プログラマ本人に知らせる前に他者へセキュリティーホールを公表されてしまうと「自分がコントロールしている」という実感さえも失ってしまう結果となります。 その上、「セキュリティ専門家」が自分のプログラムのセキュリティーホールを見つけて公表する事により賞賛を浴びるというのは、自分が開墾したノウアスフィアに入り込んで成果物を奪っていく行為にも等しい事です。
ところで、あなたはノウアスフィアの開墾 [cruel.org]という論文を読んだことがありますか?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
注意はよく読みましょう部門? (スコア:3, 参考になる)
ところで、「注意はよく読みましょう部門」とのことですが、その「注意」というのは、「全く安全ではないですが,とても便利です」のことでしょうか?
タレコミにも書きましたが、BUGTRAQで報告されたときの、slashcodeのメンテナの第一声は、「きちんと警告している」という弁明でした。原文 [securityfocus.com] では、
Re:注意はよく読みましょう部門? (スコア:3, 参考になる)
一般に、脆弱性の指摘を受けたときは、問題ないとする反論をまず考えようとするのではなく(ついそうしてしまうのはわかるが)、問題がないように思えるなら、指摘者が何を問題視しているのかを、尋ねるなりして確認するよう努める姿勢を心がけたいものです。指摘をした側も、「問題ない」と否定されると(そしてそれが間違っていると)それに再反論するのに余計なエネルギーを必要としてしまうのが人情だと思います。
Re:注意はよく読みましょう部門? (スコア:1)
Re:注意はよく読みましょう部門? (スコア:0)
おそらくjbeefさんのことではなく、この手の話にありがちな人についての話をしてるんじゃないでしょうか?
Re:注意はよく読みましょう部門? (スコア:0)
なんなんだろ。
説明プリーズ。
Re:注意はよく読みましょう部門? (スコア:0)
回線切ってLANケーブルで首吊ってください。
Re:注意はよく読みましょう部門? (スコア:1)
#オフトピか?
Re:注意はよく読みましょう部門? (スコア:0)
あなたは他人の痛みがわからない人なんですね。
「MD5値からパスワードを復元できる」という前提が成り立てばその通りですが、そういう前提は成り立ちません。
は?何言ってるんですか?
類推可能なパスワードをMD5して該当MD5値と一致したら「復元された」と言ってますか?
それはMD5値を復元したのではなく、類推したパスワードをMD5値で検証しただけ
Re:注意はよく読みましょう部門? (スコア:2)
Re:注意はよく読みましょう部門? (スコア:0)
もしかして私バカにされてるんだろうか?
まぁACだからいいけど。
私は、MD5値が漏れる事=パスワードが漏れる事、という論理が飛躍しすぎていると言ってるのであって、辞書攻撃で解読されてしまう程度のパスワードはユーザのパスワード管理の問題だと思います。
そもそも、MD5値が漏れるのが「パスワード漏洩の脆弱性」と言うのであれば、APOPも「パスワード漏洩の脆弱性」を抱えている事になりますね。
SlashcodeにAPOP以上のセキュリティを求めるあなたのバランス感覚がおかしいとは思いませんか?
Re:注意はよく読みましょう部門? (スコア:1)
スラッシュドットへのログインに関しては、MD5値が漏れることとパスワードが漏れることは同等です。アカウントが乗っ取られることを一般読者にわかるようにパスワードが漏れたと表現しました。タレコミ文の中には実際にはMD5値であることは示してあります。
Re:注意はよく読みましょう部門? (スコア:0)
同等の効果が得られても同じ事ではありませんね。
指摘する側が、そういう「センセーショナルな嘘(というか誇大表現)」をするから反発を受けるのでは?
Re:注意はよく読みましょう部門? (スコア:1)
Re:注意はよく読みましょう部門? (スコア:1)
どこが同じでないのですか?つまり、 スラッシュドットだけにしかそのパスワードを使わない人にとって、 「アカウントを乗っ取られる」と説明されるのと「パスワードが漏れる」と説明されるのとで、理解する内容において何が違いますか?そして、その違いを認識することにどのような意義がありますか?
それどころか、むしろ、「アカウントを乗っ取られる」というタイトルでは、「セッションIDの漏洩が原因」と解釈される方が普通(世の中ではそのようなセキュリティホール(セッションID漏洩によるアカウント乗っ取り)が大半を占める)ですから、それでは危険度を低めに説明してしまう(セッションIDは使い捨てなので時間が経っていると乗っ取れないという点で脅威の現実性が低めになる)不適切なタイトルになってしまいます。
つまり、この種の話題の伝達で正確さを期すには、できるだけ結果よりも原因に近い部分を説明するのが適切です。結果の方を書くと、その結果がもたらされる現実性の高さの情報が失われてしまいがちです。 しかし、原因に近い部分というのは、より技術的な説明となりがちなので、一般利用者にわかる範囲で最も原因に近い部分を示すことになります。これがこの種の話題の伝達の際にタイトルに選ぶべきポイントです。
さらに言えば、タレコミではタイトルは「Slashcodeが一部ユーザのパスワードを漏らす」としていました。(「…リスク」という表現は編集担当者によるものです。) これは、パスワード(のMD5値)が実際に私のサーバに漏れてきていた事実を伝えることが、このタレコミの重要な要点のひとつであったからです。
当然ですね。タイトルで触れる必要があるものなのですから、タイトルに付けるのは当然としか言いようがない。Re:注意はよく読みましょう部門? (スコア:1)
Re:注意はよく読みましょう部門? (スコア:1)
Re:注意はよく読みましょう部門? (スコア:1)
Slashcode に限らない一般論では、弱点の大きさは (P) ≧ (M+A) ≧ (A) です。
(P) と (M+A) の差がどの程度かは、辞書攻撃の有効性によるでしょう。また、 (M+A) と (A) は、じつは Slashcode では同じことですが、一般にはアカウントを乗っ取ってもパスワードの MD5 がわかるとは限らないので差があります。
この記事のタイトルに「パスワード漏洩」と書いてあるより「パスワードの MD5 の漏洩+アカウント乗っ取り可能」と書いてあるほうが、ぼくにはわかりやすかったと思います。
しかし、タイトルに正確な情報をすべて詰め込むことはできないので、タイトルの表現が多少不正確だったり足りなかったりするのはしかたのないことです。どういうタイトルを付けるかは、タレコんだ人(それと最終的には投稿した人)の裁量でしょう。 ベンダ以外によるセキュリティホールの公表を見て、弱点を実際よりも大きく見せるような書きかたをしていると感じたことは何度かあります。大きく見せたほうが自分がすごいことをしたように思ってもらえるからかもしれないし、大きく見せないと注目してもらえないからかもしれないし、別の理由かもしれません。
今回 jbeef さんが、正確には (M+A) であるこの弱点を多少不正確でもいいから短く書こうとして、小さすぎる (A) という書きかたではなく大きすぎる (P) という書きかたを使った理由も、ぼくにはわかりません。いろいろ勘繰れば、妄想だけならいろいろ思いつくのですが、理由がわからない段階で、 jbeef さんの書きかたを「センセーショナルな嘘あるいは誇大表現」とまで呼ぶのは、それ自体も少々扇情的な表現ではないかと思います(jbeef さんのことを言っているのでなければ、ぼくの読み間違いです、失礼)。
鵜呑みにしてみる?
Re:注意はよく読みましょう部門? (スコア:1)
また、「P」は原因です(もたらされる脅威の)が、「A」は原因ではなく(もたらされる)脅威ですので、「A」を言っただけでは、それが常に起きることなのか、短期間に限り起きることなのかといったを言い表せていません。「P」が原因の「A」という脅威は、常に起きることですが、単に「A」と言っただけではそこまで表現できていません。このことについては既に#171634 [srad.jp] で述べてあります。
Re:注意はよく読みましょう部門? (スコア:1)
Re:注意はよく読みましょう部門? (スコア:1)
不正確に小さく書くのと不正確に大きく書くのとでどちらが読者のためなのかはそう簡単に判断できることではないと思います。 いいえ、ぼくはここでは「パスワードが漏洩する」ということ自体を脅威の一つと数えています。もちろん、なぜそれが脅威かというと、それによってスラッシュドットや他のシステムにログインするためのパスワードが類推されるなどの結果が引き起こされるからですが、だからといって「パスワードの漏洩」は脅威の原因であって脅威そのものではないなどと言い出すとわかりにくいので、「パスワードの漏洩」自体を脅威と呼んでいます。 (P) ならば (A) ですが、逆は成り立たないという意味ですね。それならその通りです。
同様に、 (P) ならば (M+A) だし、 (M+A) ならば (A) ですが、ともに逆は一般的には成り立ちません。事実は (M+A) であり、それを (P) と表現することも (A) と表現することも不正確です。「(A) と表現することが不正確」というだけでは、タイトルに (P) を掲げるほうが (A) を掲げるよりもいい理由を説明したことになりません。
いや、既に書いたように、不正確でもしかたがないとは思うんですよ。タイトルが長いのは読みにくいので。それに、大きすぎる書きかたを選んだのはユーザのためを思ってのことなのでしょう。
でも、世の中には「ユーザのため」と言いながら自分のために弱点を大きく書く人がいてもおかしくありません。セキュリティホールの報告者がベンダから信用されない場合があるとしたら、原因の一つは、報告者が脅威を実際よりも小さく書くよりは大きく書くほうを選ぶところにあるのではないかと思っています。だったら小さく書けばいいかというとそうでもないので、解決するのは難しいですが。
鵜呑みにしてみる?
Re:注意はよく読みましょう部門? (スコア:1)
なぜそれを述べたのかというのは、それに続く部分を言うためです。つまり、 前のコメントにも書いた、脆弱性を語るときはできるだけ原因に近い事象を述べるのが良いという点を述べるためです。 原因方向の事象(極はexploitを示すこと)ほど厳密ですがユーザには理解が 困難です。結果方向の事象ほどユーザには理解しやすいですが厳密でなくなり ます。「A」を示すことは厳密さが足りないと言っているのです。何が足りな いと言っているかは以下に続く部分です。 そのようなことは書いてありません。(書いてあることだけを解釈する癖を付 けましょう。)
何を言っているのかはそれに続く部分に書いてあります。tixさんならもう 一度読んでくださればおわかり頂けると思いますが、もう一度述べておくと、 Aと言っただけでは別のタイプの(別の原因の)脆弱性(例えばセッションID 盗用の場合は一定期間だけアカウント乗っ取りの脅威にさらされる)のことと 区別できていない(ので不十分な説明)ということを述べています。原因Pを 示せば、一時的ではなく常時Aの危険に晒されること(追記すれば「パスワードを変更している場合には脅威がない」ことも)を説明し切れる点で厳密性があることを 述べています。 その手の話をしているのではないのです。 既に述べたように、ユーザ向けニュースにおいてタイトルで小さい方に倒すの には問題があるのです。もちろんそれは程度問題ですが、MD5値に対する辞書 攻撃の可能性(同値などとはもちろん言っていない)も付随しているので、 程度問題として妥当だと判断したということです。これはタレコミ時から十分 に考慮して書いたもので、ミスではありません。 本文中の話とタイトルの話は区別して書いた方がよいです。
Re:注意はよく読みましょう部門? (スコア:1)
スラッシュドットの場合は、辞書攻撃なしに、不正ログインことが出来ます。
全く違う話です。
Re:注意はよく読みましょう部門? (スコア:1)
鵜呑みにしてみる?
Re:注意はよく読みましょう部門? (スコア:1)
Re:注意はよく読みましょう部門? (スコア:1)
鵜呑みにしてみる?
Re:注意はよく読みましょう部門? (スコア:1)
鵜呑みにしてみる?
Re:注意はよく読みましょう部門? (スコア:1)
多少流れがわかりやすくなりました。どうも。
たくさんのコメントをすべて読んではいませんが、このコメントは読んでみました。たしかに面白いです。ソフトウェアの開発者と弱点の発見者のコミュニケーションがどうしてうまくいかないかを説明できる可能性がありますね。
でも、その後のコメントで、やっぱり「ハッカーコミュニティとセキュリティコミュニティの対立」(?)という雰囲気のフレームが起きているようなので、悲しくなります。
なお、ぼくは商業的なソフトウェアの弱点を発見したり指摘したりしたことはありませんが、フリーか商業的かで指摘の方法を大きく変えることはないだろうと想像しています。
ぼくは今までにフリーソフトのセキュリティホールを少しだけ指摘したことがありますが、いずれも、無視されたり、不完全な修正にとどまったりしています。修正されないソフトは使わなければ個人的にはそれで済むので、社会的な責任を考えないようにして黙っていますが、もう少しぼくにコミュニケーションの能力があれば修正してもらえたのかもしれないと思うと悔しいです。
そんなぼくが書いても説得力がありませんが、ぼくがソフトウェアの弱点を作者に報告するときには、報告を読んだ作者が「直そう」と思ってくれるような報告を書くことを心掛けています。これが当然と思う人は幸せなのですが、ぼくの場合、ともすれば、作者にぼくの力を見せ付けてやろうとか、要らぬ考えが浮かんでくるので、そういう邪念を抑えて報告を書くのは労力を要します。
例えば、「こんな弱点だらけのソフトウェアを何の警告もなく公表しているようでは、あなたの正義感や開発者としてのセンスを疑います」のようなことを書きそうになったこともあります。こんなことを書いても、作者はやる気を出してはくれないでしょう。怒って読むのをやめるか、悲しんでソフトウェアを書くのをやめるか、いずれにしても弱点は修正されない可能性が高いです。
何が言いたいかというと、問題が理想的に解決に至るためには開発者がやる気を出してくれることが必要であり、開発者がやる気を出してくれるような報告を書くべきだということです。この点では、べつにフリーか商業的かなんてあまり関係がないと思います。
ただ、商業的なソフトウェアの場合「こんなソフトウェアで金を取るなよ」とか考え始めるとまたいろいろな邪念が出てきて、まともな報告(報告を読んだ開発者が「直そう」と思ってくれるような報告)がしづらいだろうとは思います。
商業的なプロジェクトであっても、「公表するかしないか」の意思決定をする人がセキュリティに詳しければ、すべて自分でやらなければならない個人プログラマよりもかえっていい行動が取れると思うのですが、難しいのでしょうね……。
フリーソフトウェアであっても、多人数のプロジェクトだと、「弱点を公表するかどうかの意思決定に関われない開発者」という存在が出てくると思うのですが、そちらでも同じように辛い思いをしている人がいるのか、気になります。
鵜呑みにしてみる?
Re:注意はよく読みましょう部門? (スコア:1)
それから、元の文脈で話をしていただけませんか?元はこうですよ。 これでもtixさんは正常な議論をしていると思いますか? 1個前のコメントだけを解釈してコメントしていませんか? ちなみに、この件で私は「公表者」ではありませんよ。ニュースのタレコミ者です。スラッシュドットがいつもそうであるように、どこかの一次情報源をきちんと参照した上で、二次情報源として紹介しているだけです。
私が一時情報源となる場合には、正確さが要求されるだけに、紙面の限られるような場には書きません。
ちなみに、一次情報源のタイトルは「slashdot / slashcode disclosing passwords」でした。 「と書いた方がよい」の根拠を論理的に説明しているのに、 「盲目的に信じていませんか?」とおっしゃるのですか。 #172307でせっかく書いた説明はシカトしておいて。
Re:注意はよく読みましょう部門? (スコア:1)
Re:注意はよく読みましょう部門? (スコア:1)
jbeef さんは
と書かれていますが、その部分では本当に文字通り、 (A) をタイトルとすることの問題点を書いていただけなのですね。わかっていませんでした。すみません。
(A) が不十分なのは承知しています。 (A) が不十分な理由を、ぼくは「今回の弱点の被害は (M+A) だが、 (A) だからといって (M+A) とは限らないから」つまり「(A) だけでは説明できない被害があるから」と思っており、 jbeef さんは「(A) は弱点により引き起こされる結果 (の一つ) でしかないから」(強調部はぼくが補った)と思ってみえるようですが、この理由の差は表面的なもので、議論には関係ないと思います。
(P) をタイトルにすることの問題点はどうなってしまったのでしょう。
弱点を (A) だと述べることは弱点を過小に評価しています。それと対称的に、 (P) は過大に評価しています。 (A) が過小でタイトルとして不適格なら、 (P) は過大であってタイトルとして不適格です。
だから過小でも過大でもないタイトルを付けるなど無理だ、というなら、タイトルは過小でも過大でもいいのです。本文で正しく説明すればいいのだから。あるいは、スラッシュドットへのタレコミなど、正確でなくたっていいとも思います。正確でなくて重要なことなら、誰かが指摘するので(希望的観測?)。
でも、 jbeef さんは過大なほうに倒そうとなさっているようです。 jbeef さんは、過大な表現ばかり使うことで、報告を読んだ人に信用してもらえなくなるリスクをどう考えてみえるのですか?
知りませんでした。これが理由でタイトルを (P) としたというなら、理解できます。でも、一般論として「過小に書くより過大に書いたほうがまだましだ」と思ってみえるのなら、それには同意できません。
#172307 を書いていただいたことは感謝していますが、 #172307 は反論としては不十分です。ぼくは「小さく書くのと大きく書くのは両方とも問題であり、どちらがいいとは一概に言えない」と主張しています。大きく書くことが問題であることの根拠は #172228 [srad.jp] にも一言だけ書きました。 jbeef さんは「小さく書くのは問題だ」とばかりおっしゃって、「大きく書くことも問題だ」という点をどう考えているのか書いていただくことができずにいます。その様子から、考えるのを拒んでいるという印象を受けたので、「盲目的に」と表現してしまいました。お気に障ったらごめんなさい。
「公表者」というのを「弱点を発見した人」や「誰かの見つけた弱点を Web で告知する人」(スラッシュドットでは投稿というプロセスが挟まりますが、基本的にはタレコミ者もこの範疇だと思って書いています)などを総称する言葉として使っていました。説明なしに使ってしまったのはわかりにくかったかもしれません。
鵜呑みにしてみる?
Re:注意はよく読みましょう部門? (スコア:1)
私が述べていることは、私が今回書いたタレコミという特定の事例についてのものです。
Re:注意はよく読みましょう部門? (スコア:1)
tixさんは、
と述べているわけですが、一般論として、大きく書くことがもたらす問題点が存在し得ることは、当たり前のことで、誰にも疑う余地がないでしょう。しかし、ここではそのような議論をしているのではありません。私の今回のタレコミが適切であったかという個別論をしているのです。 私のタレコミの問題点が指摘されたからこそ、そのように書く必要性があったことを説明することで、このケースでの妥当性を説明しているわけです。そのような状況において、 という理由によって、 と言われても困ります。 tixさんがどうやら個別論を無視して一般論を展開しているらしいという疑いを持ったのは、 という部分からです。元々「一概に言う」などという議論は行われていないのです。#172307で述べたのは、このケースにおいての必要性の理由を述べたものです。 それで、前者(弱点を発見した人)と後者(タレコミ者)は、この問題において同格なのですか?あなたが引用からわざわざ削除なさった前回の私の説明を再掲しておきます。なぜ削除してコメントなしなのですか?Re:注意はよく読みましょう部門? (スコア:1)
ずっと書いていることですが、 jbeef さんは、弱点を大きく書くことのリスクを過小に評価していると思います。
今回の jbeef さんのタレコミは、一次情報と同じくらいの重み(効果? 権威?)があったと思います。「パスワード自体は漏れないのに、パスワードが漏れるかのように大袈裟に書くな」という非難はその表れかもしれません。二次情報であって許される文章の量が限られているからといって甘く考えず、注意して書いていただければよかったと思います。文章の量が限られていても、できることはあったはずです。
ぼくは、タレコミ文を読んだ後で事実を知って「また大袈裟に騒いでいるのか」と思ったわけです。間違えていたならともかく、こんなことを繰り返していると、信頼できなくなるように思います。これがぼくだけのことなら、全体から見ればどうでもいい話ですが、多くの人の信頼を失うようなことにはなってほしくありません。
鵜呑みにしてみる?
Re:注意はよく読みましょう部門? (スコア:1)
以下はようやく個別論について述べて頂けたようですが、
私が注意せずに書いたのだとおっしゃるわけですね。私は注意して書いたと証拠を挙げて述べてきました。 これまでもずっとチャンスがあったにもかかわらず、あなたは一度も代案を示そうともしてこなかった(つまり、この件でのタイトルの難しさを理解している)くせに、よくもまあそう言えますね。 一次情報源のタイトルを知らなかった程度に読んだだけ(#174549参照)なのにですか(まあ、そういう読者がいるというのは、スラッシュドットの全ての記事に存在する問題点ではあるのですが)。また、私はタレコミ文の冒頭で、以下のようにわざわざリンクを設けて、自分で何が漏れるのかを確認できるように工夫もしたのですよ。 そういうのも確かめなくて「ぼくは、タレコミ文を読んだ後で事実を知って」なのですね。Re:注意はよく読みましょう部門? (スコア:1)
Re:注意はよく読みましょう部門? (スコア:1)
ぼくがタレコミの文章を読んで呆れたのを、 jbeef さんがぼくの側の問題だと思うなら、もうぼくのほうに議論を続ける理由はありません。
反論するのも疲れました。 jbeef さんがお忙しい中ぼくのコメントを読んで反応してくださるのは嬉しいのですが、ぼくは jbeef さんのおっしゃることに反論している時間的・精神的余裕がありません。お付き合いいただきありがとうございました。 タイトルは「Slashcode で一部ユーザのログイン用 URL が referer として漏洩」くらいでしょうか。本文中では「パスワード(の MD5)」という曖昧な括弧の使いかたを避けるため、危険の内容を一言で「ログイン用 URL の漏洩」と表現し、それによって「アカウントが乗っ取られる」「パスワードの MD5 が漏洩する」という二つの結果が生じると書けば多少わかりやすくなりそうです。
この書きかたにもいろいろ問題点はあって、まず「ログイン用 URL」では何のことかわからないので本文中で説明する必要があるし、タイトルが長すぎるかもしれません。結局「ログイン用 URL の漏洩」によって何が起きるかはタイトルだけではわからないわけですし。いいことなし? まあ一つの案として。
鵜呑みにしてみる?
Re:注意はよく読みましょう部門? (スコア:1)
そして、ご自身、お気づきのように、このケースではそんなに簡単に完璧なタレコミ文を書くことはできないものでした。もちろん若干の改善方法はあったでしょう。しかし、「注意せずに書いた」と非難されるほどのものではないと考えているということです。
Re:注意はよく読みましょう部門? (スコア:1)
スラド的な言い回し(って勝手な想像だけど)なら、本文中に
タイトルではパスワードと書いたが、実際にはパスワードのMD5値である。しかしその悪用のされ方によってはパスワードが漏れることと同じくらいの威力があるともいえる。/.J諸兄も注意されたし。
うーん、こんな感じかなあ。まあこんなフーなのが書いてあれば良かったのではなんて思ったりしますた。
Re:注意はよく読みましょう部門? (スコア:0)
> あなたは他人の痛みがわからない人なんですね。
関係者ですか???
普通に見て叩いているようには見えませんよ。
私刑、ですか…… (スコア:1)
実際に、「公表する」というカードを切らないと担当者からの response が得られなかった、という経験が私自身にもあります。 報告者が通常望んでいるのは、問題の修正と、修正後の利用者に対する告知、であって「謝罪文を載せろ」ではないでしょう。どちらも、利用者の安全性を最大限保つための行為です。
Re:私刑、ですか…… (スコア:1)
にもかかわらず問題発見者がソフトの作者に「事前に通知する」のは、単にそのソフト自体のセキュリティだけでなく、そのソフトの利用者のセキュリティをも考慮しているからに他なりません。 そして「時限を設定」することにより、修正を強く促すわけです。
もちろん、たいていのソフトには「無保証」と書いてあるので、ソフトの作者は修正する「義務」はありません。 ソフトの作者は修正しない権利を持っています。 ほんとうに「やってる事は一緒」だというのなら、警察に相談するのがよろしいのでしょうね。 AC さんは問題発見者の「思いやり」の足りなさを強く主張なさっていらっしゃいますが、では、「どうやって逃げるか」などと考えるようなソフトの作者は、その利用者に対して十分な「思いやり」があるのでしょうか? 私は利用者の安全性が最大限尊重されるべきだと思っています。
正直に言って、「どうやって逃げるか」などと考えるような人間がつくったソフトは、とっとと捨ててしまうのが最善だと思いますし、利用者にそれを促すためにも、そのような場合は問題をとっとと公開してしまうのがよいと思ってます。 リスクの存在を知った上で、それでも利用するのはその利用者の自由ですし。
Re:私刑、ですか…… (スコア:1)
> 「とりあえず防衛しよう」と考えるのは罪な事ですか?
即座に対策をとらないことは「防衛」じゃなくて攻撃の続行なんですが、わかりませんか?それともわざとわからないフリをしてるのですか?
> プライドだけを糧にしているフリーソフトプログラマのプライドに付けられた傷は癒す方法がありません。
何をプライドにすべきかを完全に誤っているからそんな訳のわからないことを言うのですね。「人を危険に陥れていること」を黙っていてもらえれば「プライド」ですか。一見動くように見えるけれど、実はでたらめなプログラムをばらまき人を陥れ続けることによって得られたプライドがそんなに大切ですか?無能に「無能」と知らしめないことが思いやりなんですか?こりゃお笑いだ。自分の誤りを指摘してもらった時に、迅速かつ適切に対応や謝罪を行うということを積み重ね、信用を勝ち得れば、それは大いにプライドになるでしょうけどね。
> ハッカー文化では、こうした行動はいささか強力にタブー視されている
これは「ハッカー」の狭いコミュニティの中の話で、ユーザに強要すべきものだとはどこにも書いてありません。あなたは、
>そこに書かれたフリーソフトプログラマの思考形態をじっくりと理解できるだけ丁寧に読
む能力「も」ないようですね。
office
Re:私刑、ですか…… (スコア:1)
フリーソフトというものは基本的に使用者の自己責任で使用するものではないのでしょうか?
その自己責任において使用者が情報交換することに作者が文句をつける根拠はないと思います。
それはその情報をもっているのが一般的なユーザーでなく「セキュリティ専門家」でも同じ事ですよね。 他の方も書いているように、一般的にはそうなっていますよね?
期限を決められたら強要になるのでしょうか?
対策が期限に間に合わないようであれば情報提供者に公開を待ってもらうように依頼することもできますよね。期限以内にして欲しいことは対策ではなく対応ですから。
何の連絡もないからこそ、プログラマのコントロールを尊重するよりもリスクを放置する危険を重視して公開しているだけではないでしょうか。
うじゃうじゃ
Re:私刑、ですか…… (スコア:1)
>相手が包丁振りかざして来たら謝るより先に逃げませんか?
包丁つきつけた相手が逃げなかったら、ゴロ呼ばわりすると。ほほう。
>商業プログラムのメーカに「バグを発見したから○○円返却せよ」という訴訟
誰がそんな事を言いました?
> 「謝罪」を要求する
いゃ、私はそのような主張は一度もしていません。
なぜなら、そのような議論をしていないからです。
「ノウアスフィアの開墾」は、ハッカー文化の中の人々、つまりプログラミングをすることができる人を読者として想定してます。プログラミングできて、他人の愚かなプログラムを直してあげることができるにもかかわらず、評論して何もしないのはハッカーの態度としてよくないと書いてあるのです。なぜ「アカデミズム」と対比して書いてあるのかわからないのですか?
あなたはネットにいる人々が皆ハッカーになってプログラミングできるようになることを「コミュニケーション」と勘違いしているようですが、ユーザがそういうあなたの傲慢な思いに従わなければならない理由はどこにもありません。
office
Re:私刑、ですか…… (スコア:1)
自分が作ったプログラムが手に負えなくなったら、ユーザに労働まで強要するんですか?無能ですね。
office
Re:私刑、ですか…… (スコア:1)
> 何千倍、何万倍、物によってはそれを上回る「労働」の成果であるソフト
を無価値にしてしまうそのセキュリティホールを直そうともせず、貢献してきた人々全てを貶める無能の輩が言うわ言うわ。けらけら。
> ××さん。頼むからofficeは「セキュリティ専門家」じゃなくて「セキュリティゴロ」だと言ってください。
議論で勝てなくなったら、泣き落としですか。
> 48時間以内の返答を要求します。
盗人猛々しいという言葉があるが、この場合は何というのかねぇ。
office
Re:私刑、ですか…… (スコア:1)
報告はまず伊藤忠テクノサイエンスがすべきものでしょ。知りたいならまず伊藤忠テクノサイエンスに聞いてください。
それに伊藤忠テクノサイエンスの立場だってあるでしょうに、ここはそういうスレじゃなかったのですか?
> 人のミスを晒してネタにして飯食ってるんだから、
いったいどこをどう曲げたらこうなるのかわからん。が、事の顛末が気になっていて、私にききたい人がいることはわかりました。
office
Re:私刑、ですか…… (スコア:1)
一方で、素早い fix と適切な情報開示により、利用者の賞賛を得る場合だって多々あるわけです。slashdot.jp を含め、賞賛が足りないという面がないとは言いませんが、中長期的には「よくメンテナンスされている」という評価になると思います。
セキュリティ脆弱性の報告なんて、要は bug report の特殊な形にすぎないと思うんですが、なぜそこまで恐れる必要があるんでしょう。さくっと fix して制御を奪い返してしまえばそれでいいと思うのですが。 実際問題、「フリーソフトだからこそ」商用ソフトよりも素早い fix が実現され、「やっぱフリーソフトの方が安全だね」という評価が得られる事の方が多いと思うのですが。 「逃げ」るなんてヨワヨワな態度と、「Hacking」「ハッカー」「フリーソフト」とは、私の頭の中では結び付かないのですが、AC さんの頭の中では結びつくのですか?
はぁ…… (スコア:1)
AC さんは、どのような報告形態が望ましいと考えていらっしゃるのかを書いた方がいいんじゃないんですか?
Re:注意はよく読みましょう部門? (スコア:0)
カッコ悪。もちろん↑のコメントを書いた君のことだけどね。
Re:注意はよく読みましょう部門? (スコア:0)
まともに議論しようとしない君のほうがよほどカッコ悪いよ。