アカウント名:
パスワード:
セキュリティが重要な部分といったら真っ先に暗号を思いつくんだけど、実際に使用されている暗号ってアルゴリズムは公開されているよね？
だから、悪意を持ったやつがその穴を利用する前に、他の専門家から穴を指摘されてふさぐことができるんだ。
"この裏口は少なくとも 1996 年以来存在してきたようである。つまり四年間 -- 四年間だよ -- そのコードを書いたいたずら者だけが裏口について知っていたことになる。勿論、何年も前に裏口を発見した未知数のクラッカーや破壊者どもを除いて、だ。ワールドワイドなメディアが取り上げた今となっては、世界中のクラッカーは確実にその存在に気付いてしまった。"
"ゴキブリは人知れず繁殖する。クラッカーはコードの秘密主義につけこむ。今こそそれらを日の光の元に晒すべきときなんだ。"
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
新規開発するもの (スコア:1)
利用者が限定されるアプリのソース公開は危険かも (スコア:0)
カスタムかつオプソなソフトは危険だと思うなァ…
（バグと攻撃対象が同時に見つかる）
オプソなアプリは、どこでどう使われてるか
分からないからこそオープンでも安全なんだし…
Re:利用者が限定されるアプリのソース公開は危険かも (スコア:1)
>分からないからこそオープンでも安全なんだし…
「どこで」については、ダウトっす。
それが本当なら、Apacheあたりの本家サイトはとっくに沈没してます(^^;
「どう」については、パスワードを筆頭とする(笑)顧客ローカルなデータを
適切に隠蔽してるかどうかにかかってくる事ですよね。
まあ、LinuxなりApacheなりなんなりの巷の多くのオプソソフトは、
顧客の案件を実現するための「部品」でしかない、それゆえに
それ自体をなんぼホジってもヤバイ情報は見つからない、という点については同意します。
ただ、じゃあ特定業種に特化したソフトが危険か、というと、それはちょっと違うような気がするし。
顧客依存データ部分をいかにカスタムプログラムから切り離すか、という点については、
たしかに、そのソフトが使われる客先が少なければ少ないほど、いちいち分離する手間を
かけたくない(笑)という欲求は、無いでもないですねえ…。
いちいち設定データファイルのParserを組み込むより、ソースにconstantとして書くほうが楽みたいな。
とはいえあんまり誘惑に負けてると、プログラムとしての綺麗さも損なわれるんで、痛いんですけども。
最終的には「Framework＋少量の追加Code＋設定データ(ParserはFrameworkに組み込み済み)」で一丁挙がり、なのが理想ですね。
え？業者が仕事をする余地が無い？こりゃまた失礼しました。
#でも将来「プロ」なんか要らない世の中になっても尚、プロを自称する連中が金を取ってるとしたら、それはそれで憂慮モノだけど。
Re:利用者が限定されるアプリのソース公開は危険かも (スコア:0)
Apache本家サイトを攻撃するメリットは殆ど無いじゃん。
（穴が埋まるのみで、攻撃者は得るものが無い）
それに多くのWebサイトではApacheやOSのバージョン
誤魔化してるよね。これは何の為?
Re:利用者が限定されるアプリのソース公開は危険かも (スコア:1)
>カスタムかつオプソなソフトは危険だと思うなァ…
それ以前に、なんか「オープンソースだと大丈夫！」
だと思っていそうなところがすげぇ怖いんですけど。
別にオープンソースなソフトだからといって、必ずしもセキュリティがWindowsよりも優れてるっていうわけじゃないので・・・。
Re:利用者が限定されるアプリのソース公開は危険かも (スコア:1)
>> カスタムかつオプソなソフトは危険だと思うなァ…
>> （バグと攻撃対象が同時に見つかる）
危険にさらされているからこそ「こういう実装がされています」と、堂々と見せるほうがいいんだよ。
セキュリティが重要な部分といったら真っ先に暗号を思いつくんだけど、実際に使用されている暗号ってアルゴリズムは公開されているよね？
だから、悪意を持ったやつがその穴を利用する前に、他の専門家から穴を指摘されてふさぐことができるんだ。
マイクロソフト -- 不安定に設計されて [neweb.ne.jp] より。