アカウント名:
パスワード:
「バージョンアップをサボる」というと語弊があるけど、24/7で 実運用中のシステムの場合、一般的にはバージョンを上げる前に かなりの検証が必要なわけだ。日頃の業務に追われる管理者なら、 なるべく手軽に優先順位を判断したい、 という気持ちもあるだろう。
「ならオープンソースは使うな」と言ってしまうのも正論だが、 ユーザの裾野を広げるという点では、そこをフォローする 何かが欲しいよね。
一番正攻法なのはサポートビジネスかな（Namazuはどっかの 会社がサポートビジネスをやってなかったっけ?） ただ、今回のような議論を見てると、 ソフトウェア単位のサポートってだけじゃなくて、 いろんなパッケージのセキュリティアップデートだけに 注目して、忙しい管理者が「このバージョンのアップデートの 緊急度は?」と問い合わせたらすぐに調べて返答するような サービスってのもあったら良さそう。 Linuxのディストリビュータがやってることと重なるところはあるか。
「自分で作れないから他人に作ってもらおう」とするならば、 作ってもらう人に対して金を払って土下座するくらいの態度でお願いしろ。
んー、対価を払って作ってもらうって契約が成立したなら、 「土下座する態度」は必要ないんじゃない? 札束でひっぱたかれるようなのはやだけど、 作る方が一方的に偉いわけでもない。 それこそ対等な関係でしょ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
セキュリティ面は強化なのか欠陥修正なのか (スコア:0)
欠陥修正だったらすぐにでもアップデートするけど、
強化なんだったらサボりたい。
ユーザとしてはそこんとこをまず第一に知りたいんだけど。
サボりたければ読め (スコア:1, 参考になる)
Re:サボりたければ読め (スコア:-1, フレームのもと)
Re:サボりたければ読め (スコア:1)
まさに一番上に書いてあります。
(最初親コメント [srad.jp]が何を希望してるのか意味がわからんかった)
> "今回のバージョンアップの詳細は、以下のようになっています。
>
> 1. セキュリティ面の強化
> * サーバーへ無理な負荷を与える複雑な正規表現検索への対策
> * バッファオーバーフローの可能性がある箇所を修正
セキュリティ関係情報をトップに持ってくるかどうかは、商用フリーに
無関係な気がする今日このごろ。
ユーザがそれを読むか読まないかは、それにもまして無関係。
# 漏れがこんなネタに釣られクマーーーーなのでAP
Re:脆弱性対応の基本がなってない (スコア:0, すばらしい洞察)
脆弱性対応の基本がなっていないのは「自分で詳細を調べない」あなたの方だと思いますよ。
もし、説明が不足している、説明が必要だと思うのであれば「自分で用意する」のがオープンソースではないのですか？
そして、それが出来るようにソースコードが開示されているのですし、メーリングリストがあるのですよ。
本当にそのセキュリティ関連の修正内容が知りたいのであれば、文句を撒き散らす前にメーリングリストのログを読むなり、ソースコードのdiffを取るなりして「自分で」調べれば
Re:脆弱性対応の基本がなってない (スコア:1, すばらしい洞察)
「バージョンアップをサボる」というと語弊があるけど、24/7で 実運用中のシステムの場合、一般的にはバージョンを上げる前に かなりの検証が必要なわけだ。日頃の業務に追われる管理者なら、 なるべく手軽に優先順位を判断したい、 という気持ちもあるだろう。
「ならオープンソースは使うな」と言ってしまうのも正論だが、 ユーザの裾野を広げるという点では、そこをフォローする 何かが欲しいよね。
一番正攻法なのはサポートビジネスかな（Namazuはどっかの 会社がサポートビジネスをやってなかったっけ?） ただ、今回のような議論を見てると、 ソフトウェア単位のサポートってだけじゃなくて、 いろんなパッケージのセキュリティアップデートだけに 注目して、忙しい管理者が「このバージョンのアップデートの 緊急度は?」と問い合わせたらすぐに調べて返答するような サービスってのもあったら良さそう。 Linuxのディストリビュータがやってることと重なるところはあるか。
Re:脆弱性対応の基本がなってない (スコア:1)
>MSやその他プロプライエタリな硬直組織と違って、
>脆弱性情報は正直にアナウンスされるものだと期待していたのだが。
その期待の根拠は何なのでしょうか？
普通に考えると、
プロプライエタリにしろ、オープンソースにしろ、公開しないで済むなら楽であることにはかわりは無いのでは？
思い込みで、非難するのはやめるのがよろしいかと。
Re:脆弱性対応の基本がなってない (スコア:0)
実際、検証と言いつつ放置に近いことされるなら、サボりたくなるのもわかるような気はします。
#実際、検証がいるようなAPI使っているとは思えないケースも多々あったり。
Re:脆弱性対応の基本がなってない (スコア:0)
欲しかったら作ってみてはいかが？
Re:脆弱性対応の基本がなってない (スコア:0)
> 必要としていない機能拡張と同時のバージョンアップしかでき
> ないのでは、他にどういう影響が出るかもわからない。
セキュリティ修正分だけのパッチが存在してほしいと考えるならば
オープンソースの風習に従って
君がそのようなパッチを書き、公開すれば良い。
> 個人的には、オープンソース・プロジェクトというものは、
> MSやその他プロプライエタリな硬直組織と違って、脆弱性
> 情報は正直にアナウンスされるものだと期待していたのだが。
ソースコードそのものが公開されているのだから
Re:脆弱性対応の基本がなってない (スコア:0)
Re:脆弱性対応の基本がなってない (スコア:0)
namazuとwindowsの何をどういう条件で比較してる？
Re:脆弱性対応の基本がなってない (スコア:0)
んー、対価を払って作ってもらうって契約が成立したなら、 「土下座する態度」は必要ないんじゃない? 札束でひっぱたかれるようなのはやだけど、 作る方が一方的に偉いわけでもない。 それこそ対等な関係でしょ。
Re:脆弱性対応の基本がなってない (スコア:0)
オープンソースプロジェクトへの寄附は
商契約における対価の支払いとは性質がちがいますね
Re:脆弱性対応の基本がなってない (スコア:0)
>> ボる」という考え方になるのでしょうか。
>「強化」ということは、そのまま使い続けてもよいという意味だから。
http://www.namazu.org/security.html みて判断したら?
何でニュースの内容だけで判断しようとする?
> これで萎えるようなプロジェクトなら、今後にも期待できないの> で、使うのをやめることにする。
使う使わないは、あなた
Re:脆弱性対応の基本がなってない (スコア:0)
> 必要としていない機能拡張と同時のバージョンアップしかできない
> のでは、他にどういう影響が出るかもわからない。
常に最新版にしか、セキュリティ対策は施されないと思うよ。
最新版がでたら、バージョンアップしておいた方がいいよ。
> 「強化」という
Re:脆弱性対応の基本がなってない (スコア:0)
> 24/7で実運用中のシステムの場合、一般的にはバージョンを
> 上げる前にかなりの検証が必要なわけだ。
１年７ヶ月ぶりのバージョンアップなら、検証に時間を割いてでも
バージョンアップを検討したら？
24/7で実運用して使っているのなら、なおさら。
Re:脆弱性対応の基本がなってない (スコア:0)
> ローカルからしか攻撃され得ないのか、
>
> そんな基本的なことすら、説明されてない。
changelog（のようなもの）にもそこまで書けと？
Re:脆弱性対応の基本がなってない (スコア:0)
オープンソースソフトウェアに限ったことではないと思うけど。
というより、changelogにでも書かれているだけマシ。
ソース見せないソフトだと、黙ってバグフィックスされることも多いわけで。
＃開発が黙ってバグフィックスしたことがばれて、客に激怒されたことあり。
Re:脆弱性対応の基本がなってない (スコア:0)
へんなところに反応するけど、それは違う。
開発者はちゃんと変更点は伝えているけど、それをどう扱うかは、セールスとかサポートとかの問題。
問題を一緒にしないでほしいな。
（だたし、どこそこのソースを読めって書くこともあるけど...その方が正確なんだ！）
Re:脆弱性対応の基本がなってない (スコア:0)
「 バッファオーバーフローの可能性がある箇所を修正」って、コードのサニタイズをして
芽が出る前に問題をつぶしましたよ、以上のことはないと思う。
Re:脆弱性対応の基本がなってない (スコア:1, すばらしい洞察)
「サニタイズ」という言葉の使い方が間違っているよ。
最近何でもかんでも「サニタイズ」と書く似非セキュリティ専門家が増えてるなあ。
> 「ローカル」だの「リモート」だのの以前の話だから、
> ほんとにExploitされるかどうかは知るわけもなく。
開発者にはわりとわかりやすいはず。
開発者意外がソースコードを分析してそれを見極めるのは、開発者がそれを行う場合に比べてきわめてコストが大きい。
Re:脆弱性対応の基本がなってない (スコア:0)