Akihiro Motoki
amoto****@gmail*****
2013年 10月 11日 (金) 00:49:19 JST
元木です。 引用していないところはお任せします。 2013/10/10 長南洋一 <cyoic****@maple*****>: >>> `-z' >>> `--elide-empty-files' >>> Suppress the generation of zero-length output files. (In cases >>> where the section delimiters of the input file are supposed to >>> mark the first lines of each of the sections, the first output >>> file will generally be a zero-length file unless you use this >>> option.) The output file sequence numbers always run >>> consecutively starting from 0, even when this option is specified. >>> >>> サイズ 0 の出力ファイルができないようにする (入力ファイルを部分に >>> 区切る行が、各部分の最初の行でもある。そういう想定の場合に、この >>> オプションを使わないと、一番目の出力ファイルがたいていサイズ 0 に >>> なる)。このオプションが指定されているときでも、出力ファイルの >>> 連続番号が 0 から始まって、順番に増えていくことに変わりはない。 >> >> この部分が少し曖昧だったのですが、ここで言いたいのは、 >> サイズ 0 のファイルを作成しない場合であっても、 >> 番号がずれるわけではない、ということでしょうか？ >> 言い換えると、作成されなかったファイルは欠番になる、ということ？ >> それとも、番号が詰められるのでしょうか。 > > 少し前にある文章「デフォルトの接尾辞は、二桁の 10 進数を `00' から > `99' まで順番に増やして行ったものである」に呼応しています。ですから、 > -z の使用、不使用にかかわらず、デフォルトでは、ファイル名は xx00, xx01, > xx02 ... となります。 了解です。 >>> "In cases ..." の "are supposed to" がうまく訳せないでいます。 >> >> 入力ファイルの区切り行が各部分の最初の行のような場合には、 >> 最初の出力ファイルはサイズが 0 のファイルとなる。 >> >> くらいでどうでしょうか。 > > 意味が伝わりさえすれば、"are supposed to" にこだわらなくてもよいかも > しれませんね。ただ、原文は、実行者が「区切り行を同時に各部分の最初の > 行にする」という意図を持っていることを強調したいのだと思います。 > > 考えてみれば、二番目以降の出力ファイルでは、当然ながら、区切り行が > 必ず最初の行になるわけですから、一番目のファイルでもそうしたい場合 > ということにすぎません。 > > 入力ファイルを部分に区切る行が、どの部分においてもその最初の行に > なることになっている場合に > > 素直に訳してみたのですが、「なることになる」がちょっとたどたどしい。 > それなら、「... なることを想定している場合に」。 be supposed to は仮定だと思います。 「〜という状況を考えると」といった感じだと思います。 「なることになる」はちょっと意味が違うと思います。 以下でも「現れるようにする」は個人的には変だと感じました。 「現れるような場合」の方が個人的にはしっくり来ます。 選択はお任せします。 > あるいは、"the section delimiters of the input file" を原文どおり、 > 行ではなくデリミタ (具体的には、文字列) として、 > > 入力ファイルを部分に区切る文字列が各部分の最初の行に現れるように > する場合に > > いっそのこと、 > > 入力ファイルを部分に区切る行を、どの部分でもその最初の行にする場合に > > でも充分かもしれません。 > >>> 6.4 `md5sum' >>> >>> Note: The MD5 digest is more reliable than a simple CRC (provided by >>> the `cksum' command) for detecting accidental file corruption, as the >>> chances of accidentally having two files with identical MD5 are >>> vanishingly small. However, it should not be considered secure against >>> malicious tampering: although finding a file with a given MD5 >>> fingerprint is considered infeasible at the moment, it is known how to >>> modify certain files, including digital certificates, so that they >>> appear valid when signed with an MD5 digest. For more secure hashes, >>> consider using SHA-2. *Note sha2 utilities::. >>> >>> 注意: MD5 ダイジェストは、ファイルの不測の損傷を検知することに >>> 関して、単純な CRC (`cksum' コマンドで使用できる) よりも信頼性が高い。 >> >> 「検知に関して」の方が読みやすいです。 > > 「ファイルの不測の損傷の検知について」と「の」を三つ続けたくなかった > のです。「MD5 ダイジェストは、」の読点を取れば、このままでも少し読み > やすくなるのではないでしょうか。 読点を単にとればよい問題ではないと思います。 この文の骨子が崩れてしまうからです。 この文章の骨子は「MD5 ダイジェストは単純な CRC よりも信頼性が高い」で、 「〜に関して」と訳されている部分はあくまで条件にすぎません。 読点を単純に消すということは、「MD5 ダイジェストは」と「〜に関して」を 一体にするということなので、文脈上変になります。 > # ほかのメールでご指摘なさっていますが、わたしの文章に読点が多いのは、 > # 自分でも気がついています。原則として、節などの意味の切れ目に読点を > # 入れていますが、「が」や「は」の前に少し長い句が来ると、つい点を > # 打ってしまいます。「もし、」や「でも、」も同じで、そうしないと > # どうも落ち着かないのです。 私が気になったのは、単純に読点の数が多い点ではありません。 上に書きましたが、文章の骨格を維持する上で必要な読点がないのに、 修飾節の中で読点があり、その結果、修飾節が分割され、本来切れている部分が 切れていない文がいくつか見られました。 全体を流し読みして、コメントをつけて行ったので、どこだったか後から探し出せませんでした。 >>> 二つのファイルがたまたま同一の MD5 値を持っている確率は、ほとんどゼロ >>> だからである。だからと言って、悪意のある改竄に対して安全だと考えては >>> ならない。ある特定の MD5 指紋を持つファイルを見つけ出すことは、現在の >>> ところ事実上不可能だと考えられているが、デジタル証明書を含むある種の >>> ファイルが署名に MD5 ダイジェストを使用しているとき、そうしたファイル >>> に手を加えて、有効に見えるようする方法なら、周知のことだからである。 >>> もっと安全なハッシュ値が必要なら、SHA-2 の使用を考慮した方がよい。 >>> >>> "it is known how to modify certain files" 以下が具体的にどういうことか、 >>> よくわかっていません。そんなわけで、訳に自信がありません。 > >> 意味としては、MD5 ダイジェストでの署名では正当に見えるようにしたまま >> 特定のファイルを変更する方法が知られている、ということです。 > > ja.wikipedia.org の md5sum の項なども見てみたのですが、やっぱりわかり > ません。これは、要するに MD5 の脆弱性を言っているのでしょう。でも、 > 「ある特定の MD5 指紋を持つファイルを見つけ出す」、つまり、あるファイル > の MD5 値と同じ MD5 値を持つ別のファイルを見つけ出すことと、(元木さんの > まとめ方を借用するなら) 「MD5 ダイジェストでの署名では正当に見えるように > したまま特定のファイルを変更する」こととの違いがわかりません。署名という > のは、要するにデータのハッシュ値を署名者の秘密鍵で暗号化したものなので > しょう。ここで暗号 (復号) 化に問題がないとすれば、「署名が正当に見える」 > ということは、ハッシュ値が (この場合 MD5 値が) 正当に見えるということ > ではないでしょうか。ということは、改変されたデータが元のデータと同じ > MD5 値を持っていることになりませんか。つまり、あるファイルの MD5 値と > 同じ MD5 値を持つ別のファイルが作れるということになり、"finding a file > with a given MD5 fingerprint is considered infeasible" と矛盾するのでは > ないでしょうか。矛盾するというよりも、二つの状態の違いを原文がうまく > 説明し切れていないのではないか、という気もしますけれど。 暗号の専門家ではないので、詳しいことは分かりませんが、 一般に、元データの差分を元にチェックサムの更新を行うことができます。 IP ヘッダにチェックサムがありますが、フィールド更新を行った際にチェックサムを 更新する必要があります。このとき、全部再計算する方法もありますが、 差分を元に計算することもできます。ということで、 ハッシュ関数で元の値を知ることと、ある元のファイルに変更を加えても MD5 ダイジェストを同じにすることは、難しさが違うと思います。 > このようにさっぱりわかっていないので、この部分はわたしの手に負えません。 > 訳文が大体通用するようならよいのですが、そうでないならば、適切な案を > 教えていただけると、ありがたいと思います。 意味がわからないという話だったので、訳へのコメントは避けていたのですが、 コメントします。訳はだいたい正しいと思います。 certain files は「ある種のファイル」と訳すのに個人的には違和感がありますが、 まあいいです。「certain」といっているのは「MD5 で署名されている」のと関係が あるのではないでしょうか。訳としては「ある種の」がない方がしっくり来ます。 >>> 二つのファイルがたまたま同一の MD5 値を持っている確率は、ほとんどゼロ >>> だからである。だからと言って、悪意のある改竄に対して安全だと考えては >>> ならない。ある特定の MD5 指紋を持つファイルを見つけ出すことは、現在の >>> ところ事実上不可能だと考えられているが、デジタル証明書を含むある種の >>> ファイルが署名に MD5 ダイジェストを使用しているとき、そうしたファイル >>> に手を加えて、有効に見えるようする方法なら、周知のことだからである。 >>> もっと安全なハッシュ値が必要なら、SHA-2 の使用を考慮した方がよい。 > なお、valid は「有効、正当、正規のもの」などを考えました。、どれもイマイチ > ピッタリしないと思っていたのですが、「有効」より「正当」の方がよいですか。 この場合は「正当」の方がよいと思います。 > > -- > 長南洋一 > > _______________________________________________ > linuxjm-discuss mailing list > linux****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/linuxjm-discuss -- Akihiro MOTOKI <amoto****@gmail*****>
Fork