Linux/Unixでのセキュアなプログラムの書き方 89
ストーリー by yourCat
灯台の下を照らす 部門より
灯台の下を照らす 部門より
hisai 曰く、 "JFにて『Secure Programming for Linux and Unix HOWTO』を公開しました。このドキュメントには、安全なプログラムを書く上で必要な技術について幅広い内容を記載してあります。著者のDavid A. Wheeler氏は、ソースコード検査ツールのFlawfinderの開発者でもあります。
セキュリティというとネットワーク/サーバ/既存アプリケーションの問題に注意がいきがちですが、皆さんが作成するソフトウェアにもあらためてセキュリティの眼を向けてみてはいかがでしょうか。"
Unix類に限らないなら (スコア:3, 参考になる)
反面教師サイト？ (スコア:1)
通販サイトとかで何度か同様の問題を抱えているサイトを見かけますね。
特定商取引法による表示、会員規約、取引規定、送料についてなどが見えないようになっているところもある。そういった面では「安全ではなく危険な反面教師サイト」だね。
Re:反面教師サイト？ (スコア:1, 参考になる)
私は通常、画面サイズを全画面にはしてないから、やはり同様。
アンカー以外のところにカーソル持っていって、マウスをプレスしたままドラッグすれば(要するに範囲選択)スクロールはしますけどね...
どうして他人の画面サイズ、決め付けるかなぁ。
しかも推奨サイズすら書いてないし。
Re:反面教師サイト？ (スコア:1)
まぁ、逆に一部の章では横サイズがオーバーして入りきらない....
疑問 (スコア:1)
Re:疑問 (スコア:1)
>なぜwebデザイナーはそんなデザインをするのか？
俺はしていなので推測でしかないが、デザイナーだからデザインを重要視していると思う。
メニューが全部表示されることより、スクロールバーが表示されデザインが崩れることを嫌っているのだろう。
困るのは表示されないだけではなく、下にまだあるのかすら分からないことだな。
ちなみに、大抵のブラウザではスクロールバーが出るってことは、下にまだあるってこと。
出ない場合は、全部表示されたことになる。
と考えると、やはり意図的にスクロールの禁止属性を指定しているのって、デザイン重視でスクロールバーが表示されるよりはメニューが全部表示されないほうがマシと思っているんじゃないの？
単に詳しく知らないで使っているだけかもしれないが....
誤訳？：「大きさ」→「size」 (スコア:2, すばらしい洞察)
単語として日本語訳では全て「大きさ」と書いてありますが、ここは変数名そ
のまま「size」と書くべきのような気がします。
(原文では「6.2.3. strlcpy and strlcat」)
特に以下の2個所の(太字の)「大きさ」は文章の途中なのか式の一部なのか判
別しずらいので。
> strlcpy は、NUL で終端した元の文字列から、その大きさ - 1 の文字をコ
> ピーし、NIL で終端します。 strlcat は、NIL で終端してある文字列を末
> 尾に追加します。多く見積もっても大きさ - strlen(dst) - 1 バイトを追
> 加し、NIL で終端します。
翻訳者のアドレスに直接メールで伝えるべきでしょうか？
とりあえず、皆様の意見を待ちます。
Re:誤訳？：「大きさ」→「size」 (スコア:1)
Re:誤訳？：「大きさ」→「size」 (スコア:1)
「Appendix B. おことわり」なんですが、
John Levonさんだけ、mailアドレスにthanksがついていないのと
大元とmailアドレスが違うみたいです、と言いたかったのだが
大元のバージョンがVer 3.010に上がっちゃって、mailアドレスが
変わっちゃってるのかも。
少なくもthanksだけはあった方がいいような気もするんだけど
大元もついてなからな～
Re:誤訳？：「大きさ」→「size」 (スコア:1)
皆さんに誤訳をさらにたくさん(笑)指摘していただいたところで、
まとめて修正して、更新作業を行います。
どうぞ、引き続きよろしくお願いします。
ソフト名も隠さなければいけない (スコア:1)
# 「最終更新日」とかまずそうだね...
サーバーとか調べれば、OSとか使っているサーバーとか分かってしまうのが多いと思う(←良く知らない)のですが、そういうのもちゃんと隠したほうが良いということでしょうか？
Apacheにはバージョン情報を隠すオプションがあったのをかすかに記憶していますが、そういうオプションをつけておくというのほうがベストなのでしょう。もちろんデフォルトは「バージョン情報は隠す」というような感じにしてセキュリティを高めるというのはソフトウェア開発者の責任ですが。
// Give me chocolates!
Re:ソフト名も隠さなければいけない (スコア:2, 興味深い)
攻撃者がバージョンからセキュリティホール(や、その他の動作)を把握する事が可能なため、バージョン情報を隠すことによって攻撃者に与える情報を*減らす*事は出来ても、バージョンを隠す事によって、そのバージョンのソフトウェアにある不具合が消えるわけではないでしょう。
僕が攻撃者ならば、攻撃対象が自称するバージョン情報は信じませんね。
無差別攻撃するなら、とりあえず穴のあるバージョンを吐いている所だけを狙うかもしれませんが ;)
# 穴が見つかった時、とりあえず(fix済みの)嘘バージョンを吐くようにした事があったりなかったり...
Re:ソフト名も隠さなければいけない (スコア:1)
例えば PHP なら ＜?php // コメント ?＞ は問題ないでしょう。
でもどうせなら、攻撃の徴候を検出して偽のコメントやエラーメッセージ吐かせるとかした方がおもしろそう。
それから、ソフト名やバージョン隠す事にどれ程の効果があるかは疑問です。
メジャーなソフト使ってる限り、2～3程度の代表的なソフトに絞り込まれちゃいますし、バージョンに関しても最新(笑)のセキュリティホールで攻撃する限りは、何の解決にもならないように思います。
その辺りはいかがなものでしょうか？
uxi
Re:ソフト名も隠さなければいけない (スコア:2, 参考になる)
Debianの場合パッチが当たっててもバージョンが変化しない事が多いのですが、表示されるバージョンだけを見て「古いバージョンだ」とか騒ぎ立てるセキュリティ厨が良くいます。
バージョンを出さないようにしておけば、そういう輩の相手をしなくても済むので、それはそれで嬉しい。
バージョン隠しても、そういうバカ除け以上の意味は無いですね。
元の文書で言う「情報を与えるな」というのは、例えばDBをアクセスするようなソフトで、エラーの表示にエラーを発生させたSQL文を表示しちゃうと不正なQuery（を注入できる入力データ）を作りやすくなるとか、そういう話ですね。
他の例で言えば、CGIなどでファイルのロックをかけていて、ロックができなかった時にそのファイル名を表示しちゃうとターゲットのファイル名を知られてしまうので、「Index表示しないようにしてるから大丈夫」とか言ってhttpでGETできるような所にファイル置いてると抜かれるとか。（まぁそもそもGETできるような所に置くのがマヌケなんだが）
Re:ソフト名も隠さなければいけない (スコア:3, 興味深い)
> 突いた方が早いですからね。
それをやると相手先に痕跡が残ります。
もし穴が開けば入って痕跡を消せば良いのですが、
穴がなかったら無意味どころか不要な痕跡を残すだけマイナスです。
ターゲットを絞らず世界中無闇やたらに無差別攻撃をすると
世界中に自分が攻撃をしたことの痕跡が残ります。
この痕跡の量は多ければ多いほど攻撃者にとって損ですので
もしあらかじめ攻撃先を絞ることができるならば絞っておきたいと
考えるのが犯罪者心理です。
身代金目的で子供を誘拐する場合も大抵の犯人は
あらかじめ金持ちを捜し出しておいて、
その中で成功率が高いと予想できるターゲットだけを攻撃します。
やたらめったら片っ端に子供を誘拐していって片っ端に身代金を請求していき、
そのうち1人からでもすぐに大金が入金されたら
そこで仕事を終了して全員を殺すという豪快な手法をとる犯罪者は少数派です。
いちいちターゲットの資産状況をチェックしてから誘拐するより
イキナリ全部誘拐した方が仕事は早いかもしれませんが
デメリットが大きいため流行しないのです。
クラッキングという犯罪も同様です。
Re:ソフト名も隠さなければいけない (スコア:0)
Red Hatもそうですね。
Re:ソフト名も隠さなければいけない (スコア:0)
Re:ソフト名も隠さなければいけない (スコア:0)
う～ん、、コメント入れないとメンテナンス性が落ちますよね。
勿論必要以上のコメントを入れないようにはしていますがメンテナンス性を落としてまで削るほどなのか、と。
元々秘匿を期待していない
Re:ソフト名も隠さなければいけない (スコア:0)
分量がすごそうなんですけど… (スコア:1)
訳者です(Re:分量がすごそうなんですけど…) (スコア:3, 参考になる)
翻訳には1年以上かかりました。通勤中＋子供が寝てから
訳していました。
でも原文が素晴らしいと思っていたので、頑張れました。
ご指摘にあるように、とても長いドキュメントです。
校正が至らないところがまだあると思います。問題点は
どんどんご指摘ください
# 所詮素人訳なので...。
Re:訳者です (スコア:1)
この文章の存在は、ruby-listで知りました。
何時ぞや、原著者がRubyに興味を持って
その記述が追加されるといいですね。
その際には、hisaiさんが訳註でまとめられた
部分も大いに役に立つでしょう。
Re:分量がすごそうなんですけど… (スコア:1)
私も分量にびびりました。いまだに読み切っていません。
Cの常識に関する部分は、学生にも十分教えるべきだと思いました。
scanf("%s",..)とかgets()とか、NULLチェックしないとか普通に行われてますし。
それはそれでいいのかも。。。
# segmentation fault
Re:分量がすごそうなんですけど… (スコア:0)
ざっと目を通しましたが、やっぱり、C/C++プログラマとして、
文字列処理系の問題は頭が痛いなぁと思いました。
最後の方に、
printf(some_string_text);
は、
printf("%s", some_string_text);
としなさいというのがあり、目から鱗が
Re:分量がすごそうなんですけど… (スコア:2, 参考になる)
fputs(some_string_text, stdout);
にせよ、と教えてるんですけど... (セキュリティ以前の問題で)。Re:分量がすごそうなんですけど… (スコア:1)
Re:分量がすごそうなんですけど… (スコア:0)
なんで、ID持ちがこんな重箱の隅つつくような指摘するかな？
Re:分量がすごそうなんですけど… (スコア:0)
ものを教えるべき。
動作が違っていても「それで問題無い」かどうか判るなら
そこまで教える必要はない。
Re:分量がすごそうなんですけど… (スコア:2, 参考になる)
1.成功時の戻り値の仕様
printf：転送された文字数を返す。
fputs： 非負の値を返す。
2.エラー時の戻り値の仕様
printf：出力エラーが発生したときは、負の値を返す。
fputs：書込みエラーが発生するとEOFを返す。
3.変更、拡張への対応
"%s"を前提としている場合でも、printfでは"%10s"のような文字数指定への拡張が可能です。
fputsではできません。
それで、printfと等価なのは、fprintfの第一引数にstdoutを指定したものというところでしょう。
ご参考になればよいのですが。
Re:分量がすごそうなんですけど… (スコア:1)
使いますよね。それならfputs(3)を使えばよくて
(puts,getsは末尾の改行を扱う、fputs,fgetsは扱わない)
元コメント [srad.jp]
は多分「printfのほうがfputsより重いから」
ではないですか?
Re:分量がすごそうなんですけど… (スコア:1, 興味深い)
どーでもいいことかも知れませんが、gcc の一部には printf("string constant\n")をputs("string constant")にすげ替えちゃうのがいるようです。
# printf 書いて気づいた
Re:分量がすごそうなんですけど… (スコア:0)
152ページと言うことで断念。今、紙がないのよ ;_;
会社でコッソリ出してこよう。
訳文チェック (スコア:1)
いくつかのページを見てみました．さすがに長いので全部は見切れておりません．
「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段落．「正しい値は決め難いものです」は「正しい値の範囲を特定するのは難しい」． 「これが難しくなっている原因です」は 「チェックを正しく行うのはとても難しいので (チェックをライブラリ関数として用意した方が
Re:訳文チェック (スコア:1)
とても助かります。指摘していただいた内容を理解した上で修正します。
P.S.
もっと校正していただけると...うれしい...です。
# おずおず
Re:訳文チェック (スコア:1)
それでは遠慮なく．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 は，この文脈では，「オープンソース」ではなく「フリーソフトウェア」だ
Re:訳文チェック (スコア:1)
前回いただいた指摘に対する疑問点を投稿しようと思っていたところでしたが、
numa さんのチェックが一段落するまで待とうと思います。
# スレッドが見難くなって、見落としがでないように。
「もうここまで！」とおっしゃっていただくと助かります。
> numa さん
Re:訳文チェック (スコア:1)
とりあえず第1章・第2章についてはこれで済みです． それより後ろについては，もうちょっと根性が回復してからに したいと思います．
いままでコメントした部分については，これ以上の追加はないとおもっていただいてかまいません．ご意見はもちろん歓迎です．
Re:訳文チェック (スコア:1)
まず、これまでチェックしていただいた点を見直して、チェックに対する疑問点を
解消した上で、公開しているものを更新します。
「根性」が入った段階で、またお願いできれば。ただ、無理なさらないでくださいね、
くれぐれも。
# 根性って、「くうぅ、うおりゃ」、つー感じすかね(笑)
P.S.
今回タレ込んで、本当によかったと思っています。numa さんをはじめとして、
貴重なご指摘をいただけるのは、本当に(うれしい)^10です。
チェックに対する疑問点 (スコア:1)
以下ご指摘の中で疑問に思った点を書きます。
なお、疑問の部分は、私の訳した版と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 つのオープン
Re:チェックに対する疑問点 (スコア:1)
お返事が遅れました．
一般論としてはそうですが，それはけっこう難しい技術です． 実際，自分でもなかなかうまくいかないものだと思っています． また，私の見た限りでは， そうやって再構成した部分に問題が見つかることが多かったように感じます．
いいと思います．
これについては，どっちがいいのか分からなくなりました．
これは，
そういうシステムがあって，それと， そうではないオープンソースのシステムがあったと，そう解釈されていますね．
でも，それは違うと思います． もしそうなら， そういう事実が「あったか，なかったか」の二分法の議論になるはずです． しかし，原文を見ると "less exposure" とある通り， 「多かったか，少なかったか」の議論なのです．
これは，ある12ヶ月以上の期間について見たところ， 「脆弱性が見つかり，かつ，パッチがない」という状態になった日数が， 「オープンソースのシステムの方が，他の2つの proprietary なシステムよりも少なかった」という話だと解釈すべきだと思います．いかがでしょうか． (「それはおまえの勝手な解釈だろ」といわれれば，その通りなんですが．)
どうしましょうかねえ．一応， ここでは実名は出していないのですが． (いやまあ，知っている人にはばればれのようなのですが．)
Re:チェックに対する疑問点 (スコア:1)
> なかなかうまくいかないものだと思っています．また，私の見た限りでは，
> そうやって再構成した部分に問題が見つかることが多かったように感じます．
確かにそうですね。
英語で理解できてしまう人が、必ずしも日本語をうまく書くとは限らないですから。
わかりやすい日本語とは、なんて勉強してませんもんね、日本だと。
# 以前聞いた話で、某大手日の丸のコンピュータも製造しているメーカーでは、
# 原文の順序がわかる訳を求められているそうです。そんなこったから、ろくな
# ドキュメントも出せないんだろうな、と思ったり。
> だと思います．いかがでしょうか． (「それはおまえの勝手な解釈だろ」
> といわれれば，その通りなんですが．)
「勝手な解釈」なんて、とんでもない。たいへん勉強になります。
この点については、おっしゃる通りだと思えてきました。
もう少し考えて、他のご指摘とあわせて訳文本体を更新します。
> どうしましょうかねえ．一応，ここでは実名は出していないのですが．
> (いやまあ，知っている人にはばればれのようなのですが．)
numa さん次第なので、載せる、載せないはおまかせします。
名前についても、さすがに「Anonymous Coward さん」はアレなんですが、
「/.J では numa さん」でも、私はかまいません。
どうされますか？
更新しました (スコア:1)
Re:以前から公開されていたのでは? (スコア:1, 参考になる)
これを「同一文書のバージョンが上がっただけ」というのは、例えば Linux カーネルの 2.2→2.4 への変化を「バージョンが上がっただけ」と評するような物じゃないかしら。著者と訳者をがっかりさせてこういう情報を公開させるのを防ぎたい、というのならわからんでもない表現ですが…。
＃ 「だけ」という部分に引っかかったので。
Re:以前から公開されていたのでは? (スコア:1)
私が翻訳をする理由は、
1 まずは自分の勉強のため(記述されている技術と翻訳技術)
2 自分にとって役立ったなら、皆さんにも役立つかもしれない
3 で、公開するとちょっとは有名になれて、感謝される
# 私は、/.Jでもよくけなされ対象になっている中間管理職層
# に属してますから、うれしいんだ、これが(笑)。
です。
したがって、一人でも「役に立った」とおっしゃる方がいれば、
もうそれで十分報われてます。
今回のドキュメントは、旧版も含めて今まで私が翻訳してきた
ドキュメントの中で一番ボリュームがありかつ、内容も優れていたので、
JF以外にも情報を流してみました。
Re:以前から公開されていたのでは? (スコア:0)
例えば Linux カーネルの 2.4 が公開されたときに、
『～にて Linux カーネルが公開された。』
とだけ書かれたらどうでしょう。
Re:以前から公開されていたのでは? (スコア:1)
新規翻訳がそれまでの数倍あれば、きっと訳者の感覚としては新規リリースの方が近いでしょう。その結果のタレコみ文だとしても理解できる気がするのです。
どんな情報も意味はあるけど、無用に功労者ががっかりしそうな文章にするのはどうかなと。
Re:以前から公開されていたのでは? (スコア:1)
最初のコメント末尾に書きましたが、バージョンが上がった「だけ」という表現がどうかと思っただけで、これが例えば「バージョンが上がった物のように見える」とされていれば良かったのではないかという程度の指摘のつもりでした。で、論理展開の(1)(2)辺りまではわたしの主張に入っていると思いますが、(3)(4)まで明確に主張するつもりはありません。特に(3)に関しては「正しい」「間違っている」の二分法で考えるつもりは全くありませんし、従って(3)から(4)が主張できるとも思ってません。今までの文章に(3)(4)のニュアンスまで含まれてしまっていたらごめんなさい。
Re:以前から公開されていたのでは? (スコア:1)
の
Re:HTML的には (スコア:1, 興味深い)
原文のDOMツリーを変えずに改行入れる場合、の間で改行を入れないといけないのです。タグの外で改行やインデントをするとそこに文字列が入るのでテキストノードが追加されたり、テキストノードの内容で空白が追加されることになるから。
htmllint -170点台 (スコア:1, 参考になる)
このようなlint結果は非常にまずい状況だと思う。
compilerやlintの警告を無視せず対策を取るというのは
Secure Programmingの基本。