Subversion 1.5.6以前と1.6.0～1.6.3に脆弱性が発見される 27
ストーリー by hylom
アップデートを推奨 部門より
アップデートを推奨 部門より
あるAnonymous Coward 曰く、
Subversion 1.5.6以前と、1.6.0～1.6.3にヒープオーバーフローの脆弱性が発見された。すでにこの問題を修正したSubversion 1.6.4と、1.5.7が8月6日付けでリリースされている。
問題の脆弱性は「libsvn_delta」ライブラリ内で入力値のチェックに不備があり、それによる複数個所のinteger overflowが原因とのこと。この脆弱性を悪用することで、認証済みのリモートユーザーおよびリモートSubversionサーバーに対しsvndiff経由で任意のコードを実行させることが可能になるとのこと。
APRとAPR-util にも関連した脆弱性があるようです (スコア:2, 参考になる)
Apache 2.2.13 Released [apache.org]
これを読むと、Apacheもバージョンアップしないといけないですね。
Subversionは人気がないのですかね？ (スコア:1)
反応が薄いですねえ。
Disるわけじゃなく、純粋に質問したいのですが、GitがSubversionより良いところってどんなものなのでしょう。
私は小規模なプロジェクトにしか関わっていないせいか、類似ソフトにしか見えないのです。
Re:Subversionは人気がないのですかね？ (スコア:2, 参考になる)
良い悪いではなく、Git の特徴として：
「Linuxの開発で使われている」
というのはありますね。
で、この手のバージョン管理ソフトは、余程の特徴がない限り一種類あればいい、と皆思う。日常的に使わなくちゃいけないが、同じようなことをする操作方法が全然違うソフトが 3つも4つもあっても 使わないわけで… そうなると、
「xxx の開発では aaa を使っているから、他も全部 aaa で管理しよう」
と言うことになったりします。なので、Git の利用者が多いのは当然ではないかと。
また、Gitの仕様が大規模開発に向いている、というのも大きなプロジェクトでよく採用される理由でしょう。結果として、大勢がそのようなプロジェクト以外でも「Git でいいか」となる。
なので、大勢が使う理由の主要因として、SubVersion の出来が悪い、とかそういうことではないと思います。
.
Ｇｉｔ の特徴としてはブランチが莫大になっても耐えられる、という面が挙げられるのではないでしょうか?
SubVersion は本質的に全てデータをリポジトリに保存します。なのでブランチのブランチのブランチ…だとか、Aさんが作ったブランチに対するBさんとCさんがそれぞれブランチを作って、そのうちBさんのブランチに対しては Dさんがさらに… などという状態が起こると、リポジトリがすさまじいことになります。また、これだけの人たちが常時アクセスするとリポジトリを管理するサーバは泣きが入ります。
Git は親ブランチと子ブランチの間のリレーションはありますが、本質的に子ブランチは子ブランチで独立して管理されます。なので親ブランチを管理するサーバが死んでいても子ブランチには (親ブランチにマージできないと言う問題以外) 問題なく動作します。基本的にブランチの各データはブランチを造った側の人間のマシン上にありますし、親ブランチは子ブランチがいくつあろうが知ったこっちゃありません。なので子ブランチを管理するサーバがいくつ死亡しようが親ブランチに対する影響もない。
fjの教祖様
Re:Subversionは人気がないのですかね？ (スコア:1)
なるほど、統制を取ることの難しいプロジェクトで有効ということですね。
Re: (スコア:0)
私は逆にGitのよいところが知りたいです。
非常に小規模なプロジェクトなため、分散管理にメリットは感じられません。
対象OSが、Windows なため、環境を整えるのも結構手間取りました。
日本語の扱いも多少難がありますし。
対象OSが、Linux だったり、大人数が係わるプロジェクトだとGitの方がいいのかな、と思いましたが。
今のところ、TortoiseSVN + SVK に落ち着いています。
とりあえず家マシンはバージョンアップしました。
会社のは夏休み後に（忘れないようにしないと）
＃何でLinus は subversion を、あんなに攻撃するんでしょうか？
Re:Subversionは人気がないのですかね？ (スコア:1, 興味深い)
Mercurialは、日本語が使えないし、Gitは、GUIがまだまだひどすぎる。
あとは、Mercurial/Gitまで来ると、概念を新人に説明するのがだんだん大変になってくるというのもあるかもしれません。
Subversionは、コピーでバックアップという運用をしていた人たちには理解がたやすいと思います。
Re: (スコア:0)
> + SVK
SVKのリポジトリを自分のPCローカルじゃなく
複数のPC(のユーザ)から共同で使えるようにする方法って、
あったっけ？あるなら是非ご伝授を。
＃SVKリポジトリをSVN鯖に食わせちゃえば動くっちゃー動くんだが、なんか怖い。
なんでそんなことしたいかというと、
上流(ぶっちゃけ仕事だ)がSVNリポジトリ握ってて、
そいつらがアホ運用をするもんだから、
(たとえば「レビューが終わるまでCOMMITするな」とか。なんのためのVer管理なのか理解してないたぐい※)
こっちはこっちの自衛のために内輪のみんなが使うリポジトリを建てつつ、
それを上流と自動連動できるようにSVKにしておきたい、と。
Re: (スコア:0)
Subversionの管理者やってますが、逆にレビューが終わってないのをCommitするのに
何のVer管理のメリットがあるのか聞きたいですね
Ver管理を行っているのは、不具合、その他が起こった場合にどこでバグが発生したのかのチェックと
そのVerへ戻せる環境を作る為のはずです。
まぁ、小規模なプロジェクトならしょうがないですが・・
Ver管理 = バックアップと思ってる人が多すぎる。
1日の作業が終わったらCommitとかどうやって履歴を管理しろと言うのか
バックアップに使うのなら個人の環境で取るかブランチ作って勝手にやってくれ
Re:Subversionは人気がないのですかね？ (スコア:1)
別にレビューなしでコミットしても、過去バージョンには戻せますよね。
レビュー云々は運用次第だからどうでもいいけど、作業のスナップショットとしてコミットするのは問題ないと思います。
まあ、作業終わりでコミットされるの嫌なら分散SCM使って、ローカルとマスターリポジトリで運用してはどうでしょう。
#やたらリビジョン番号あがるのをいやがったり、ログが汚れるのをいやがる人がいるけど、そんなん気にしても仕方ないよなあ
Re: (スコア:0)
レビューは都度tagを打って行えばいい。
>まぁ、小規模なプロジェクトならしょうがないですが・・
いちいちレビューしてからcommitするなんていう、ちんたらした体制こそ小規模向きですよ。
それとも、そこまで慎重にやらないとひどいコードが溢れるような環境なんでしょうか？
だったらバージョン管理より、まず優秀な人材を揃えるなり教育をする方が先では？
まあ釣りだと思うけど。本気でレビューしてからcommitなんてやっているならどこか教えてくれ。
絶対に関わらないようにするから。
Re: (スコア:0)
UnitTestレベルのテストを通してからCommitするとの意味で反応しました。
単体テストも何もしてないものを後で戻せるからといって
バカみたいにリビジョン上げる人は多いですが、trunkはある程度綺麗に保つっていうのは
ソース管理するに当たって必要な条件だと思ってます。
前にも書きましたが、修正単位でCommitを意識しないならbranche作ってやって欲しいです。
VSSじゃなくSubversion使ってるなら尚更ですね。
Re:Subversionは人気がないのですかね？ (スコア:2)
そういう subversion の"使いにくさ"を踏まえて、 git が開発された訳ですが。
そもそも git 使ったことあります？
Re: (スコア:0)
Windows環境での開発を行う場合、個人では使えますが
日本語使えないなど制限多すぎて、後1年ぐらいは待ちですね。
後、Trac、Redmineなどのバグ追跡系との連携もまだまだ未成熟なので。
ただ、外注時の分散開発などでのソース同期はかなり使えると思います
今時点でWindows環境ではMercurialですかねぇ
Re: (スコア:0)
この話題の元ACです。
上流は何を考えているのやら、と思います。
たぶん、
「管理」という概念を何か勘違いしている人間が上流で「管理」権限を握ってる、
といったことなのでしょう。
>何のVer管理のメリットがあるのか聞きたいですね
>そのVerへ戻せる環境を作る為のはずです。
ほかのひとも言っていますが、どの段階をCommitしようが「戻せる」わけですし、
交通整理をしたいならCommitするかどうかじゃなく、
Truncや(運用で決めたしかるべき)BranchにいつCommitするか、で整理するほうが上策です。
>小規模なプロジェクトならしょうがない
いえ。「大規模」なプロジェクト(をおこな
Re: (スコア:0)
> Commitは面倒だ、Commit頻度をいかに少なくするかが生産性の鍵である、
> と思い込んでる人のほうが多かったりします。
> 困ったもんだ。
こういう結構やってる人のコメントを見ると
やはりバージョン管理行う目的に非常に差異を感じます。
> Commitは面倒だ、Commit頻度をいかに少なくするかが生産性の鍵である、
たぶん、管理者はこんな事考えてなくて、勝手にバンバン増やされたリビジョンで
問題発生した時どこまでどうやって戻せばいいの？
っていうだけだと思います。作った人ならそりゃわかるでしょうが・・
Re: (スコア:0)
>問題発生した時どこまでどうやって戻せばいいの？
>ある修正を行うことに対するリビジョンはできる限り少なくするのが当たり前と思ってます。
いや、だから、
それは「バージョン」(リビジョン)管理じゃなく「タグ」管理によって実現してください。
戻す単位はタグで管理してください。
修正の「単位」もタグで単位付けをしてください。
そして両方を同じツールで地続きに管理するほうが、二重管理にならなくて扱い易いってことです。
>プログラマの生産性とか(中略)では無くて
(バージョン管理が)生産性に寄与しないんだったら、
邪魔とまでいわないけど控えめに言っても「無駄」なツールだ、と
Re: (スコア:0)
Re: (スコア:0)
ただ、Git、Mercurialなどの分散管理システムと違って
説明されている「タグ」ってSVNで言うTagの事ですよね？
タグ付けって単なるリビジョンのその時点でのスナップショットでしかないので
修正単位でタグ付けするためには、Commit順序を厳密に管理してないと
好ましいもののみ集まった「タグ」にはならないですよね？
普段、ブランチでリビジョン上げておいて集まったリビジョンをTrunkへマージして
タグを作るっていうんならわかりますが、そのリビジョンを集めるのも
好き勝手にリビジョン上げられているとどうやって把握してマージするのでしょう？
チケットに紐づいてるのは全部マージだろって話でしょうが、
管理者にとってはもの凄い負担です。
そういった使い方だと、やはりブランチで勝手にやっててもらって修正が終わったら
まとめてトランクにマージしてね。っていうぐらいしかまともに管理できる方法は思いつかないですね
Re: (スコア:0)
プログラマとして履歴を取りたい物と、プロジェクトとして履歴を取りたい
物が一致してないのが問題だとは思います。
本来であればGitなどの分散管理システム使えばうまくいきそうなのはわかってるのですが
Windows環境、日本語問題など通常の開発現場に持ち込むのはどうにも躊躇しています
こういうソース管理ってかなり大切な部分だと思うのですが
日本の開発現場だとほんとおざなりだと思います。
こういう議論できる場も人もほとんどなくて開発に流される事が多いので
今の議論も結構楽しかったりします
Re: (スコア:0)
リポジトリの粒度を考えるのが面倒というなら、確かに分散系のが向いてる。
ただ根本問題として、修正単位一つ一つに対して、戻せるようにしたいという要求がちょっとズレているというか、マイクロマネージメントの傾向が高すぎるんじゃないかな。
開発中盤でそんな事はしないだろうから、おそらくリリース直前の状況と思うけど、それはバージョン管理ではなくリリースエンジニアリング技術の問題になるのだと思うよ。
つまりリポジトリ管理者であるあなたの権限の外側に問題がある = 全体のマネージメントがおかしいので、プロマネにクレームを挙げるべきかと。
Re: (スコア:0)
某社に出向してた時の事。
当時（もう5年位前ですかね…）その出向先のプロジェクトはCVSサーバでバージョン管理をしてた。
そこでのルールは、レビュー後コミットみたいなものは無かった。
が、何処の誰か知らないけれど（プロジェクト全体は、当方は全く把握しておらず、
プロパーのPLクラスの人と直接コミュニケーションをとりながら作業を進めていた）
ろくに動作確認もせずコードをアップする馬鹿が居た。
当方窓口のPLからは動作確認を強要され（ま、常識なんですが…）、コミット
Re: (スコア:0)
>動かんソフトにバージョン付加してもしょうがないよね
違います。その言い方に合わせて説明するならば、(動く)ソフトに付加すべきは、バージョンではなく「タグ」です。
つまりSVN(CVSもだが)のバージョン管理は、少なくとも「二段構え」になってる、と捉えるべきなのです。
まずバージョン(リビジョン)がある。
その上位にタグがある。
だいたい「動く」かどうかなんてのは、主観が絡んだり、相対的なもの(UTではOKだが結合すると没だったり)なので、それを基準にCommitじたいを受け付けるか否か決めるなんてのは無理です。まずセーフネットとしてとりあえず全部Comm
Re: (スコア:0)
Re: (スコア:0)
問題は、Commitされたバージョンが正しく動くバージョンかどうか
どうやって判断するのか？じゃないのか
そのための知恵として trunk と branche 、unittest なんかがあるわけで
ソース管理って本気でやろうとするとどうやっても難しいよ
使い方を制限するか、すべて分かってるメンバー揃えるしか無い
タイムスタンプを・・・ (スコア:0)
ローカルの変更時刻を保持できるようになったら使おうと思っているが、
どんどん先送りされてしまうので、未だにSourceSafeを使っている。
リビジョン番号で管理しろって言われるけど、
やっぱりタイムスタンプも重要なんです・・・
Re: (スコア:0)
ああ、同じことを考える人が。
ファイル日時が「最後にコミットした日付」となるように設定が変えられるので、今から作成するファイルはコミット日付を正とするよう運用を変えると吉。
古いファイルはしょうがないからユーティリティ自作したよ。
リポジトリに１ファイルずつインポートして、FSFSの管理情報をごりごり書き直した。
1.4|1.5|1.6でそれぞれ構成が違うからだるかった。
がんばれ。
Re: (スコア:0)