Author: mumumu Date: Sat Oct 18 14:42:51 2008 New Revision: 1525 Log: - translated "Case study: the CVS password-authentication protocol" section.
Modified: trunk/ja/ch05.xml Modified: trunk/ja/ch05.xml ============================================================================== --- trunk/ja/ch05.xml (original) +++ trunk/ja/ch05.xml Sat Oct 18 14:42:51 2008 @@ -1583,8 +1583,12 @@ </para> <sect3 id="cvs-pserver"> +<!-- <title>Case study: the CVS password-authentication protocol</title> +--> +<title>ケーススタディ: CVS パスワード認証プロトコルの場合</title> +<!-- <para>In 1995, I was one half of a partnership that provided support and enhancements for CVS (the Concurrent Versions System; see <ulink url="http://www.cvshome.org/"/>). My partner Jim and I were, @@ -1593,21 +1597,33 @@ volunteer CVS development community. We just assumed that they'd send in patches, and we'd apply them, and that was pretty much how it worked.</para> +--> + +<para> + 1995年、私は CVS (Concurrent Versions System : <ulink url="http://www.cvshome.org/"/> を参照して下さい) のサポートと機能強化を行うために二人でチームを組んでいました。パートナーのジムと私は、その時点では非公式ながら CVS のメンテナーでした。しかし、私たちは既にいる CVS の開発コミュニティーとどう連携していくかについて、あまり深く考えたことはありませんでした。ただ、コミュニティーの人たちがパッチを送ってくれば、自分たちはそれを適用するだけ、といった感じでした。 +</para> +<!-- <para>Back then, networked CVS could be done only over a remote login program such as <literal>rsh</literal>. Using the same password for CVS access as for login access was an obvious security risk, and many organizations were put off by it. A major investment bank hired us to add a new authentication mechanism, so they could safely use networked CVS with their remote offices.</para> +--> +<para> + そのとき、ネットワークを介して CVS を操作するには、<literal>rsh</literal> のようなリモートログインのプログラムを使うしかありませんでした。CVS にアクセスするのにログインパスワードを使うのは、セキュリティ上のリスクがあるのが明らかでした。新しい認証機構を追加することで、CVS を離れたオフィスからネットワーク越しに安全に操作できるようにするために、ある投資銀行が私たちを雇ったのです。 +</para> + +<!-- <para>Jim and I took the contract and sat down to design the new authentication system. What we came up with was pretty simple (the United States had export controls on cryptographic code at the time, so the customer understood that we couldn't implement strong authentication), but as we were not experienced in designing such protocols, we still made a few gaffes that would have been obvious to -an expert. These mistakes would easily have been caught had we taken +an expert. These mistakes would easily have been caught had we taken the time to write up a proposal and run it by the other developers for review. But we never did so, because it didn't occur to us to think of the development list as a resource to be used. We knew that people @@ -1618,7 +1634,13 @@ authentication protocol was not very good, and of course, once it became established, it was difficult to improve, because of compatibility concerns.</para> +--> + +<para> + Jim と私は契約を結び、新しい認証機構を設計する作業に腰を据えて取り組みました。私たちが思いついたのはとても単純なもの (アメリカ合衆国は、当時暗号化に関するプログラムに輸出規制をかけていました。よって、暗号化の強度が高い認証機構を実装できなかったのですが、このことは顧客も理解してくれていました) でしたが、この手のプロトコルは設計したことがなかったので、専門家から見れば明らかな間違いが残っていました。この手の間違いは、設計を提案する文書を書いて、他の開発者にレビューして貰えば容易に発見できるものでした。しかし、当時の私たちには開発用のメーリングリストをリソースとして使うという考えがなかったため、そうしませんでした。コミュニティーの人たちは私たちが何をコミットしても受け入れることがわかっていましたし、それに — 自分たちが無知であることがわからなかったので — 自分たちがやっていることを他人が見える形にはしなかったのです。たとえば、修正プログラムを頻繁に投稿したり、小さな理解しやすい単位で特別なブランチにコミットしたりするなど、です。結果としてできた認証プロトコルは、あまり出来がよくありませんでしたし、一度作ってしまったら、互換性の問題を考えると改良も難しいものだったのです。 +</para> +<!-- <para>The root of the problem was not lack of experience; we could easily have learned what we needed to know. The problem was our attitude toward the volunteer development community. We regarded @@ -1626,9 +1648,15 @@ process by which the quality of the changes could be improved. Since we were confident that almost anything we did would be accepted (as it was), we made little effort to get others involved.</para> +--> + +<para> + 問題の根本は、経験不足でした。私たちは知るべきことを容易に学ぶことができたはずなのに、学ぼうとしなかったのです。開発コミュニティに対する態度にも問題がありました。私たちは、レビューをして貰った上で変更を取り入れてもらうことを変更の質を上げるためのプロセスというよりは、障害だと考えていたのです。自分たちがやることはほとんど全て受け入れてもらえると(当時は)思い込んでいたので、他の人を巻き込もうとする努力をしなかったのです。 +</para> </sect3> +<!-- <para>Obviously, when you're choosing a contractor, you want someone with the right technical skills and experience for the job. But it's also important to choose someone with a track record of constructive @@ -1636,6 +1664,11 @@ you're getting more than just a single person; you're getting an agent who will be able to draw on a network of expertise to make sure the work is done in a robust and maintainable way.</para> +--> + +<para> + 契約する相手を選ぶときは、適切な技術スキルと経験を持った人を選びたいのは明らかですが、コミュニティにいる他の開発者と建設的なやりとりをしている記録を追いかけられるようにしてくれる人を選ぶこともまた重要なことです。そうすれば、実質的にひとりがする仕事以上の成果を得ることができます。つまり、堅固で維持しやすいやり方で仕事をやってくれる、専門家のネットワークと繋がりがあるエージェントを雇うことになるのです。 +</para> </sect2> _______________________________________________ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
