パスワードを忘れた? アカウント作成
5944 story

Linux/Unixでのセキュアなプログラムの書き方 89

ストーリー by yourCat
灯台の下を照らす 部門より

hisai 曰く、 "JFにて『Secure Programming for Linux and Unix HOWTO』を公開しました。このドキュメントには、安全なプログラムを書く上で必要な技術について幅広い内容を記載してあります。著者のDavid A. Wheeler氏は、ソースコード検査ツールのFlawfinderの開発者でもあります。
セキュリティというとネットワーク/サーバ/既存アプリケーションの問題に注意がいきがちですが、皆さんが作成するソフトウェアにもあらためてセキュリティの眼を向けてみてはいかがでしょうか。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2003年06月21日 0時53分 (#342203)
    ここ [ipa.go.jp]も参考になりますね。
    • そこ、俺は文字サイズを大きくしているので左のメニューがスクロールを禁止されていて全部表示出来ません(10章まで表示)。
      通販サイトとかで何度か同様の問題を抱えているサイトを見かけますね。

      特定商取引法による表示、会員規約、取引規定、送料についてなどが見えないようになっているところもある。そういった面では「安全ではなく危険な反面教師サイト」だね。
      親コメント
      • by Anonymous Coward on 2003年06月22日 7時47分 (#342875)
        >そこ、俺は文字サイズを大きくしているので左のメニューがスクロールを禁止されていて全部表示出来ません(10章まで表示)。

        私は通常、画面サイズを全画面にはしてないから、やはり同様。
        アンカー以外のところにカーソル持っていって、マウスをプレスしたままドラッグすれば(要するに範囲選択)スクロールはしますけどね...

        どうして他人の画面サイズ、決め付けるかなぁ。
        しかも推奨サイズすら書いてないし。
        親コメント
      • by shiraga (14233) on 2003年06月22日 21時35分 (#343118)
        • スクロール禁止やウインドウサイズを指定することにどのようなメリットがあるのか?
        • なぜwebデザイナーはそんなデザインをするのか?
        親コメント
        • by chanbaba (13080) on 2003年06月23日 7時08分 (#343388) ホームページ
          >スクロール禁止やウインドウサイズを指定することにどのようなメリットがあるのか?
          >なぜwebデザイナーはそんなデザインをするのか?

          俺はしていなので推測でしかないが、デザイナーだからデザインを重要視していると思う。
          メニューが全部表示されることより、スクロールバーが表示されデザインが崩れることを嫌っているのだろう。

          困るのは表示されないだけではなく、下にまだあるのかすら分からないことだな。

          ちなみに、大抵のブラウザではスクロールバーが出るってことは、下にまだあるってこと。
          出ない場合は、全部表示されたことになる。
          と考えると、やはり意図的にスクロールの禁止属性を指定しているのって、デザイン重視でスクロールバーが表示されるよりはメニューが全部表示されないほうがマシと思っているんじゃないの?
          単に詳しく知らないで使っているだけかもしれないが....
          親コメント
  • by Mogami (9104) on 2003年06月21日 6時08分 (#342319)
    「5.2.3. strlcpy と strlcat」で、size_t型の引数変数「size」の事を示す
    単語として日本語訳では全て「大きさ」と書いてありますが、ここは変数名そ
    のまま「size」と書くべきのような気がします。
    (原文では「6.2.3. strlcpy and strlcat」)

    特に以下の2個所の(太字の)「大きさ」は文章の途中なのか式の一部なのか判
    別しずらいので。

    > strlcpy は、NUL で終端した元の文字列から、その大きさ - 1 の文字をコ
    > ピーし、NIL で終端します。 strlcat は、NIL で終端してある文字列を末
    > 尾に追加します。多く見積もっても大きさ - strlen(dst) - 1 バイトを追
    > 加し、NIL で終端します。

    翻訳者のアドレスに直接メールで伝えるべきでしょうか?
    とりあえず、皆様の意見を待ちます。
  • 8.2. コメントはいれない [linux.or.jp]とあるけれど、どの程度コメントならOKでどの程度のコメントならまずいのだろうか?

    # 「最終更新日」とかまずそうだね...

    サーバーとか調べれば、OSとか使っているサーバーとか分かってしまうのが多いと思う(←良く知らない)のですが、そういうのもちゃんと隠したほうが良いということでしょうか?
    Apacheにはバージョン情報を隠すオプションがあったのをかすかに記憶していますが、そういうオプションをつけておくというのほうがベストなのでしょう。もちろんデフォルトは「バージョン情報は隠す」というような感じにしてセキュリティを高めるというのはソフトウェア開発者の責任ですが。
    --
    // Give me chocolates!
    • by L.Nizah (7804) on 2003年06月21日 1時15分 (#342224)
      バージョン情報を隠しても、本質的なセキュリティは変わらないと思います。
      攻撃者がバージョンからセキュリティホール(や、その他の動作)を把握する事が可能なため、バージョン情報を隠すことによって攻撃者に与える情報を*減らす*事は出来ても、バージョンを隠す事によって、そのバージョンのソフトウェアにある不具合が消えるわけではないでしょう。

      僕が攻撃者ならば、攻撃対象が自称するバージョン情報は信じませんね。
      無差別攻撃するなら、とりあえず穴のあるバージョンを吐いている所だけを狙うかもしれませんが ;)

      # 穴が見つかった時、とりあえず(fix済みの)嘘バージョンを吐くようにした事があったりなかったり...
      親コメント
    • そこで言ってるのはあくまで <!-- --> のコメントを出すなと言ってるだけなのでは?
      例えば PHP なら <?php // コメント ?> は問題ないでしょう。
      でもどうせなら、攻撃の徴候を検出して偽のコメントやエラーメッセージ吐かせるとかした方がおもしろそう。

      それから、ソフト名やバージョン隠す事にどれ程の効果があるかは疑問です。
      メジャーなソフト使ってる限り、2~3程度の代表的なソフトに絞り込まれちゃいますし、バージョンに関しても最新(笑)のセキュリティホールで攻撃する限りは、何の解決にもならないように思います。
      その辺りはいかがなものでしょうか?
      --
      uxi
      親コメント
      • by Anonymous Coward on 2003年06月21日 3時18分 (#342279)
        いちいちバージョンチェックしてから穴突くよりはイキナリ穴突いた方が早いですからね。

        Debianの場合パッチが当たっててもバージョンが変化しない事が多いのですが、表示されるバージョンだけを見て「古いバージョンだ」とか騒ぎ立てるセキュリティ厨が良くいます。
        バージョンを出さないようにしておけば、そういう輩の相手をしなくても済むので、それはそれで嬉しい。
        バージョン隠しても、そういうバカ除け以上の意味は無いですね。

        元の文書で言う「情報を与えるな」というのは、例えばDBをアクセスするようなソフトで、エラーの表示にエラーを発生させたSQL文を表示しちゃうと不正なQuery(を注入できる入力データ)を作りやすくなるとか、そういう話ですね。
        他の例で言えば、CGIなどでファイルのロックをかけていて、ロックができなかった時にそのファイル名を表示しちゃうとターゲットのファイル名を知られてしまうので、「Index表示しないようにしてるから大丈夫」とか言ってhttpでGETできるような所にファイル置いてると抜かれるとか。(まぁそもそもGETできるような所に置くのがマヌケなんだが)

        親コメント
        • by Anonymous Coward on 2003年06月21日 13時56分 (#342448)
          > いちいちバージョンチェックしてから穴突くよりはイキナリ穴
          > 突いた方が早いですからね。

          それをやると相手先に痕跡が残ります。
          もし穴が開けば入って痕跡を消せば良いのですが、
          穴がなかったら無意味どころか不要な痕跡を残すだけマイナスです。
          ターゲットを絞らず世界中無闇やたらに無差別攻撃をすると
          世界中に自分が攻撃をしたことの痕跡が残ります。
          この痕跡の量は多ければ多いほど攻撃者にとって損ですので
          もしあらかじめ攻撃先を絞ることができるならば絞っておきたいと
          考えるのが犯罪者心理です。

          身代金目的で子供を誘拐する場合も大抵の犯人は
          あらかじめ金持ちを捜し出しておいて、
          その中で成功率が高いと予想できるターゲットだけを攻撃します。
          やたらめったら片っ端に子供を誘拐していって片っ端に身代金を請求していき、
          そのうち1人からでもすぐに大金が入金されたら
          そこで仕事を終了して全員を殺すという豪快な手法をとる犯罪者は少数派です。

          いちいちターゲットの資産状況をチェックしてから誘拐するより
          イキナリ全部誘拐した方が仕事は早いかもしれませんが
          デメリットが大きいため流行しないのです。
          クラッキングという犯罪も同様です。
          親コメント
        • >Debianの場合パッチが当たっててもバージョンが変化しない事が多いのですが

          Red Hatもそうですね。
    • PHP で Web アプリケーションを開発した以外に経験が無いのでその話になりますが、

      う~ん、、コメント入れないとメンテナンス性が落ちますよね。
      勿論必要以上のコメントを入れないようにはしていますがメンテナンス性を落としてまで削るほどなのか、と。
      元々秘匿を期待していない
  • ざっと眺めてみようとして分量にびびりました。翻訳も大変だったでしょうね。感謝&お疲れ様。存分に活用させて頂きます。
    • こういう言葉がほんと、はげみになります。うれしいです。
      翻訳には1年以上かかりました。通勤中+子供が寝てから
      訳していました。
      でも原文が素晴らしいと思っていたので、頑張れました。

      ご指摘にあるように、とても長いドキュメントです。
      校正が至らないところがまだあると思います。問題点は
      どんどんご指摘ください
      # 所詮素人訳なので...。
      親コメント
      • by t (1631) on 2003年06月21日 13時53分 (#342446) 日記
        いやいやほんと、お疲れ様でした。
        この文章の存在は、ruby-listで知りました。

        何時ぞや、原著者がRubyに興味を持って
        その記述が追加されるといいですね。
        その際には、hisaiさんが訳註でまとめられた
        部分も大いに役に立つでしょう。
        親コメント
    • これって今月の頭に公開されてました。
      私も分量にびびりました。いまだに読み切っていません。
      Cの常識に関する部分は、学生にも十分教えるべきだと思いました。
      scanf("%s",..)とかgets()とか、NULLチェックしないとか普通に行われてますし。

      それはそれでいいのかも。。。
      # segmentation fault
      親コメント
    • 確かに長いですね。
      ざっと目を通しましたが、やっぱり、C/C++プログラマとして、
      文字列処理系の問題は頭が痛いなぁと思いました。
      最後の方に、

      printf(some_string_text);

      は、

      printf("%s", some_string_text);

      としなさいというのがあり、目から鱗が
      • by oku (4610) on 2003年06月21日 3時28分 (#342282) 日記
        printf(some_string_text);

        は、

        printf("%s", some_string_text);

        としなさいというのがあり、目から鱗が落ちました。
        弊社の若人には、

        fputs(some_string_text, stdout);

        にせよ、と教えてるんですけど... (セキュリティ以前の問題で)。
        親コメント
        • それだと動作が変わってしまうよ、、、
          親コメント
          • だから、それで問題無いときはそうしなさいって事でしょ?

            なんで、ID持ちがこんな重箱の隅つつくような指摘するかな?
            • 「若人」に「教える」んだから、まず動作が変らない
              ものを教えるべき。

              動作が違っていても「それで問題無い」かどうか判るなら
              そこまで教える必要はない。
    • 手元に残して暇なとき読もうとしてプリントアウトしようとしたら
      152ページと言うことで断念。今、紙がないのよ ;_;
      会社でコッソリ出してこよう。
  • いくつかのページを見てみました.さすがに長いので全部は見切れておりません.

    「2.2. セキュリティの原則」

    第2段落の次の箇条書きの「機密を保持する」及び「完全な状態を保つ」は, 「可用性」とバランスが取れていない. 原文を見ると前二者はそれぞれ "Confidentiality" 及び "Integrity" で, "Confidentiality" は普通「機密性」又は「秘匿性」, "Integrity" は「完全性」などと訳すことが多い.

    第3段落で,「たとえば、拒否しないことを…」の non-repudiation は, 普通は「否認防止」. その次の文の, 「これには送り手側や受け手側が送受信するメッセージを「検証」する能力が…」は,
    「これは、送り手側がメッセージを送ったこと、受け手側がメッセージを受け取ったこと、 又はその両方を「証明」する (たとえ送り手側又は受け手側があとでそれを否定したくなったとしても) 能力のことです。」
    (これはたとえば,注文書等を送っているにも関わらず,送り手側が「送っていない」と主張したり, 受け手側が受け取っているにも関わらず「受け取っていない」と主張することを 防止するためのもの.)

    「信頼性」は,"authenticity" の訳なら違うのでは. "authentication" が「本人認証」のことだから,"authenticity" は 「正真正銘の本人であると認証されていること」という意味になり, 「信頼性」ではちょっと広すぎる.

    第4段落,「何らかの脅威をともなう場合」は「既知の脅威に対する対抗手段である場合」. 「この法律では…」以降は, 「共有される個人情報を開示すること及びそれらを安全にすることを必須とし、 第三者との間で共有される個人情報の開示を要求し、 さらに、それらの機関に対して顧客がデータ共有を止めさせる機会を与えるよう指導しています。」

    用語については, IPA ネットワークセキュリティ関連用語集 [ipa.go.jp]を参照.

    「4.7. 日常言語(ロカール)の選択」

    "localization" は「地域化」と訳すのが普通. 「ロカール」も「ロケール」の方が多いが,これは趣味の問題か. それから,「日常言語」は「自然言語」の方がいいかも.

    4.7.1. 第1段落."locally-run programs" は, そのマシンで「ローカルに起動されるプログラム」で, 「特定地域向けのプログラム」ではない.

    4.7.1. 第2段落.これは,HTTP リクエストの Accept-Language: ヘッダーフィールドで言語を指定できるが, ブラウザがそれを正しく設定しているとは限らないので, 結局ウェブページに「言語選択」というメニューを作って, ユーザーに選ばせることになるということ. (選んだ結果がフォーム入力になって送られてくる.)

    4.7.2. 第1段落."X/Open Portability Guide, Volume 3" は "X/Open Portability Guide, Issue 3" の間違い. (これは原文の間違い.)

    4.7.3. 第1段落. 「(アプリケーションは、実質 Content-Language ヘッダで 返ってくる言語設定のデータを表示しなければいけません)」は, 「(アプリケーションは,Content-Language: ヘッダーを使って, 返されるデータの実際の言語設定を示すべきである)」ということ.

    「4.8. 文字のエンコード」

    4.8.1. 第2段落.「共通で」は不要.「コード化文字集合」は「符号化文字集合」. 「日常の会話をほぼカバーする」ではなく「今日使用されている言語のほとんどすべてをカバーする」. "Unicode forum" ではなく "Unicode Consortium" (原文の間違い.後ではご丁寧にも Uniforum と混同している.やれやれ.)

    4.8.2. 第1段落.第1文は, 「ソフトウェアの大半は、16 ビットや 32 ビットの文字を扱うように設計されておらず、 8 ビット以上が必要な多言語文字集合を作成してもいない。」. 「多言語を 1 つのフォーマットにして、 より容易に既存のプログラムやライブラリが扱えるように開発されました。」は, 「多言語を表現できる文字列を、既存のプログラムやライブラリが容易に扱えるような形式に エンコードするため開発されました。」.

    箇条書き第3項目.「(それぞれ UCS-2 や UCS-4 を呼び出します)」は 「それぞれ UCS-2 及び UCS-4 と呼ばれます)」.

    4.8.4. 第1段落.「正しい値の範囲(に含まれる)」は「正しい値の範囲(両端を含む)」.(つまり,「○○から××まで」という範囲指定は,「以上・以下・未満・超える」のどの意味なのかという話)

    4.8.4. 第3段落.「正しい値は決め難いものです」は「正しい値の範囲を特定するのは難しい」. 「これが難しくなっている原因です」は 「チェックを正しく行うのはとても難しいので (チェックをライブラリ関数として用意した方が

    • by hisai (470) on 2003年06月25日 7時53分 (#345002) 日記
      訳者です。校正ありがとうございます。
      とても助かります。指摘していただいた内容を理解した上で修正します。

      P.S.
      もっと校正していただけると...うれしい...です。
      # おずおず
      親コメント
      • それでは遠慮なく.1.~2. です.今週三個目の訳文チェック.

        [訳文と原文との間でバージョンが違うので,訳文に訳されている部分のみについてチェックした.訳文を見て引っかかった部分のみ原文に当たったのであり,細かく付き合わせて見てはいない.]

        1. はじめに

        第1段落.
        「セキュリティの防衛線」は「セキュリティの境界線」くらいが適切.
        「この文書は複数の言語,つまり…個別の手引きにもなっています.」では, 「複数の言語」というからそれらに共通する話題かと思えば, 実は「個別の」話をしているわけで,ちょっと変. 「この文書は,いくつかの言語(具体的には…)に固有な手引きも含みます.」 ではいかが.

        第2段落.
        「慣習的な方法」の "formal" は「慣習的」ではなく「形式的」.
        「安全に関連した」で,"security" を「安全」にするか「セキュリティ」にするか訳語を統一すること.

        第3段落.
        「The U.S. National Secutiry Agency (NSA)」は,「米国国家安全保障局 (NSA)」.

        第4段落.
        「興味深いのは ISO 17799 と IEC 2000 の意見が分かれているところです。ベルギーやカナダ、フランス、ドイツ、イタリア、日本、米国は採択に反対しています。」 は, ISO/IEC 17799:2000 の採択時の投票に,ベルギー以下が反対投票をした(過去形)ということ.「ISO/IEC」は ISO と IEC とが共同で制定した規格を表し,「17799」は規格の番号を表し,「:2000」は規格の制定年度を表す.
        「(GNU FDL ライセンスとすることで、この先誰もが利用できるようになります)」は, 「(将来の文書の派生物が誰にでも入手可能であり続けられるように, GNU FDL ライセンスにした)」ということ.

        第5段落.
        「コンピュータのセキュリティ一般、つまり Unix ライクなシステムやネットワーク(特に TCP/IP ベース)、C 言語について」で, 「セキュリティ一般」とそれ以降とが「つまり」ではつながらない. これは,「コンピュータのセキュリティ一般や,Unix ライクなシステムの一般セキュリティモデル,ネットワーク(特に TCP/IP ベースの),C 言語について」.

        第6段落.
        「この文書は Unix ライクなシステムを全て網羅しています。Linux をはじめ、さまざまな系列の Unix を含んでいます。しかし Linux に特に焦点を当て、Linux に特化した情報を提供します。」は,まず,文章を恣意的に切らないこと.それに,"and" は「しかし」じゃない. 「この文書は,Linux やさまざまな系列の Unix を含む,すべての Unix ライクなシステムをカバーしており,また,特に Linux に焦点を当て,Linux に特化した情報を提供します.」

        第9段落.
        「セキュリティの性質とそれを実現しているプロセスやファイルシステムその他について」は,「プロセスやファイルシステム等のセキュリティに関する属性や操作について」. 「引き続き、この文書のポイントを論じます。それは Linux と Unix システム上でアプリケーション開発をするに当たっての、設計と実装のガイドラインです。」は, 「この文書の本体である,…ガイドラインがそれに続きます.」. 「ポイント」は「要点」の意味で使われる言葉で,ここにはふさわしくない.

        第10段落.
        「ランダムな数」は「乱数」.

        2.2.1. Unix

        第3段落.
        「こうして Unix は起源を seventh edition とし、多彩なバージョンが 」は,「こうして,seventh edition を起源とする多彩なバージョンの Unix が」. 前者だと,「Unix」というもの自体が「seventh edition」を起源とするように見えてしまう.

        2.1.4. オープンソースとフリーソフトウェア

        第1段落.
        「この例としてよく出されるのは「言論の自由」であって「ただ酒」ではない」は, 英語の free には「自由」と「無料」という2つの意味があるということを説明しないと, ここは理解不能.
        「ただこの言い回しでは、まだ説明が足りません。」ではなく, 「どちらの用語も完璧ではありません.」ということで,つぎに「誤用」の例を出している.「フリーソフトウェア」として,利用が無料だがソース非公開のものを指すことがあり,「オープンソース」として,ソース公開だが再利用できないものを指すことがある,と.
        「時として、真意と異なる意味でこの用語が使われます。」ではなく,「言葉を使う動機に違いがある場合がある」ということ.その続きで「フリーソフトウェア」を prefer する人と use する人との違いが説明されている.prefer は,この文脈では,「オープンソース」ではなく「フリーソフトウェア」だ

        親コメント
        • by hisai (470) on 2003年06月28日 23時35分 (#347696) 日記
          再度のチェックありがとうございます。

          前回いただいた指摘に対する疑問点を投稿しようと思っていたところでしたが、
          numa さんのチェックが一段落するまで待とうと思います。
          # スレッドが見難くなって、見落としがでないように。

          「もうここまで!」とおっしゃっていただくと助かります。
          > numa さん
          親コメント
          • とりあえず第1章・第2章についてはこれで済みです. それより後ろについては,もうちょっと根性が回復してからに したいと思います.

            いままでコメントした部分については,これ以上の追加はないとおもっていただいてかまいません.ご意見はもちろん歓迎です.

            親コメント
            • by hisai (470) on 2003年06月29日 5時44分 (#347880) 日記
              了解です。
              まず、これまでチェックしていただいた点を見直して、チェックに対する疑問点を
              解消した上で、公開しているものを更新します。

              「根性」が入った段階で、またお願いできれば。ただ、無理なさらないでくださいね、
              くれぐれも。
              # 根性って、「くうぅ、うおりゃ」、つー感じすかね(笑)

              P.S.
              今回タレ込んで、本当によかったと思っています。numa さんをはじめとして、
              貴重なご指摘をいただけるのは、本当に(うれしい)^10です。
              親コメント
            • あらためて、ご指摘ありがとうございます。

              以下ご指摘の中で疑問に思った点を書きます。
              なお、疑問の部分は、私の訳した版とnumaさんがご覧になった版とでは差分は
              ありませんでした。

              > 1. はじめに
              > 第6段落.
              > 「この文書は Unix ライクなシステムを全て網羅しています。Linux をはじめ、
              > さまざまな系列の Unix を含んでいます。しかし Linux に特に焦点を当て、
              > Linux に特化した情報を提供します。」は,まず,文章を恣意 的に切らないこと.
              > それに,"and" は「しかし」じゃない.「この文書は,Linux やさまざまな系列の
              > Unix を含む,すべての Unix ライクなシステムをカバーしており,また,特に
              > Linux に焦点を当て,Linux に特化した情報を提供します.
              原文は、
                This book covers all Unix-like systems, including Linux and the
                various strains of Unix, and it particularly stresses Linux and provides
                details about Linux specifically.

              1 他の部分でも指摘されていますが、「恣意的に切る」という意味がわかりません。
                まさか、原文でコンマが入っているところで訳文も読点で区切ってつなげる、
                という意味ではないですよね。
                試訳していただいた文は、日本語として句点が多過ぎて読みづらいと思います。
                したがって、原文を分解して日本語として再構成した方が読みやすいと思います。
                原文を分解して再構成するという行為は、翻訳を行う上で必要な技術です。
              2 「and」の用法には、対照的な内容のものを結んで使うというものもあります。
                例 She's a bank manager and I'm just a road-sweeper.
                  彼女は銀行の支店長なのに、私は一介の道路清掃人にすぎない
                  ※オックスフォード 実例現代英語用法辞典より引用
                ここの部分も、「さまざまに扱っている『が』、特にLinuxに焦点を当てて
                いる」という意味ではないでしょうか。
                ただ、「しかし」では、おさまりが悪いので、

                「 さまざまな系列の Unix を含んでいますが、特に Linux に焦点を当て、」

                とするのはいかがでしょうか。

              > 2.4. オープンソースはセキュリティに効果があるのか
              > その次の段落.
              > 「プログラム作成の工程管理を考慮に入れていない、」は, "open source rules
              > out control of the construction process, though in practice there is such
              > control" だから,「オープンソースは構築プロセスにおける管理 (control) を
              > 排除している (rules out) といっているが,実際はそういう管理があるのだ 」と
              > いうこと.たいていのソフトウェアには「責任者」がいて,その人たちが自分の
              > 評判を賭けてリリースを出しているじゃないか,と.
              rule outはこの場合「排除する」では日本語として強過ぎだと思います。
                rule out: to say that(something or someone)is not under considerration
                                      as a possibility
                ※LDCEより引用
              の方だと思います。

              > その次の引用文.
              > 「あるオープンシステムのオペレーティングシステムは、残り 2 つの商用
              > オペレーティングシステムよりも無防備な状態に置かれませんでした。商用
              > オペレーティングシステムのどちらもが、12 か月以上にも渡って既知
              > の脆弱さがあるにもかかわらず、パッチがない状態となっていました。」は,
              > 「あるオープンソースのオペレーティングシステムは,12ヶ月以上の期間,
              > 他の2つの商用システムに比べて,既知の脆弱性が修正されないという形で
              > 無防備な状態をさらすことが少なかった」ということ.書いてないことまで
              > 訳さない.次の文も同様 .
              原文は、
                vulnerable to nonmalicious faults. Third, a survey of three operating
                systems indicates that one open source operating system experienced less
                exposure in the form of known but unpatched vulnerabilities over a 12-month
                period than was experienced by either of two proprietary counterparts.
              ですが、「書いてないこと」とは、どこの部分でしょうか。
              ただし、私の訳もこなれていないので、もう少し考えてみました。

              「第三に、12 か月以上に渡ってパッチが無い状態で、既知の脆弱性をさらした
                2 つの商用システムよりも、残り 1 つのオープン
              親コメント
              • お返事が遅れました.

                したがって、原文を分解して日本語として再構成した方が読みやすいと思います。
                原文を分解して再構成するという行為は、翻訳を行う上で必要な技術です。

                一般論としてはそうですが,それはけっこう難しい技術です. 実際,自分でもなかなかうまくいかないものだと思っています. また,私の見た限りでは, そうやって再構成した部分に問題が見つかることが多かったように感じます.

                「 さまざまな系列の Unix を含んでいますが、特に Linux に焦点を当て、」
                とするのはいかがでしょうか。

                いいと思います.

                rule outはこの場合「排除する」では日本語として強過ぎだと思います。

                これについては,どっちがいいのか分からなくなりました.

                「第三に、12 か月以上に渡ってパッチが無い状態で、既知の脆弱性をさらした (以下略)」

                これは,

                • 既知の脆弱性があり,なおかつ,
                • その状態を修正しないまま12ヶ月以上に渡って放置した

                そういうシステムがあって,それと, そうではないオープンソースのシステムがあったと,そう解釈されていますね.

                でも,それは違うと思います. もしそうなら, そういう事実が「あったか,なかったか」の二分法の議論になるはずです. しかし,原文を見ると "less exposure" とある通り, 「多かったか,少なかったか」の議論なのです.

                これは,ある12ヶ月以上の期間について見たところ, 「脆弱性が見つかり,かつ,パッチがない」という状態になった日数が, 「オープンソースのシステムの方が,他の2つの proprietary なシステムよりも少なかった」という話だと解釈すべきだと思います.いかがでしょうか. (「それはおまえの勝手な解釈だろ」といわれれば,その通りなんですが.)

                ぜひ日本語版謝辞の中にお名前を掲載させていただきたいと思います。

                どうしましょうかねえ.一応, ここでは実名は出していないのですが. (いやまあ,知っている人にはばればれのようなのですが.)

                親コメント
              • > 一般論としてはそうですが,それはけっこう難しい技術です.実際,自分でも
                > なかなかうまくいかないものだと思っています.また,私の見た限りでは,
                > そうやって再構成した部分に問題が見つかることが多かったように感じます.
                確かにそうですね。
                英語で理解できてしまう人が、必ずしも日本語をうまく書くとは限らないですから。
                わかりやすい日本語とは、なんて勉強してませんもんね、日本だと。
                # 以前聞いた話で、某大手日の丸のコンピュータも製造しているメーカーでは、
                # 原文の順序がわかる訳を求められているそうです。そんなこったから、ろくな
                # ドキュメントも出せないんだろうな、と思ったり。

                > だと思います.いかがでしょうか. (「それはおまえの勝手な解釈だろ」
                > といわれれば,その通りなんですが.)
                「勝手な解釈」なんて、とんでもない。たいへん勉強になります。
                この点については、おっしゃる通りだと思えてきました。
                もう少し考えて、他のご指摘とあわせて訳文本体を更新します。

                > どうしましょうかねえ.一応,ここでは実名は出していないのですが.
                > (いやまあ,知っている人にはばればれのようなのですが.)
                numa さん次第なので、載せる、載せないはおまかせします。
                名前についても、さすがに「Anonymous Coward さん」はアレなんですが、
                「/.J では numa さん」でも、私はかまいません。

                どうされますか?
                親コメント
        • by hisai (470) on 2003年07月13日 15時00分 (#357926) 日記
          ご指摘いただいた内容を検討して、翻訳文を更新しました。
          親コメント
typodupeerror

一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy

読み込み中...