[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: News/weekly/2005/47/index.wml [part 1]



タケイです.
delegation 以外はチェックできていたので,それだけでも出せば良かった…
delegation にてこずりました.

 Mon, 28 Nov 2005 12:41:51 +0900
 Message-ID: <20051128.124148.07611443.nori1@xxxxxxxxxxxxxxxxxxxxxxx>
> DWN 2005-47 の序盤記事 4 本と Security Updates 情報を訳しました。
> 査読をお願いいたします。

Security Updates はかねこさんの訳を参考にすれば,作業が速くすすむのでは?

> <p><strong>Project Leader Delegations.</strong> Branden Robinson released a <a
> href="http://lists.debian.org/debian-devel-announce/2005/11/msg00009.html";>\
> document</a> explaining how project leader delegations work.  The <a
> href="$(HOME)/devel/constitution">constitution</a> suggests that there may be
> other powers which the project leader may not directly wield, and which they
> must delegate instead.  If a particular decision is delegated, the project
> leader cannot take back responsibility for the decision personally, but can
> re-delegate it to someone else.</p>

> <p><strong>プロジェクトリーダの委任。</strong>
> Branden Robinson さんは、
> プロジェクトリーダの委任がどのように機能するかを説明した<a
> href="http://lists.debian.org/debian-devel-announce/2005/11/msg00009.html";>\
> 文書</a>を公開しました。<a href="$(HOME)/devel/constitution">憲章</a>では、
> プロジェクトリーダーが直接行使してはいけなく、

行使してはならず、 or 行使できず、
のほうが自然かと思います.

それから, delegatiton は「(権限)移譲」と訳すとカッコいいなあと思いました.
リーダーの職務は委任できないものですが,権限なら移譲できると思うので.

> 代わりに委任しなければならない権力もあるとされています。

プロジェクトリーダーには,本人は直接行使できず,他人に移譲しなければ
ならない権限があるとされている.

という感じかしら.「…も」とはしていません.

> 何らかの決定権を委任する場合プロジェクトリーダは、

…場合、プロ…
と読点を入れたほうが読みやすいです.

> なされる決定の責任を個人的に撤回することはできませんが、
> 別の人にそれを再委任することは可能です。</p>
  
「責任を撤回」ってどういう意味かしら?(でもそのようにしか訳せないよ
うに見える原文だしなあ)
……ここ,ちょっと深めに読んでみます.

まずは Branden のメールから該当部分を引用↓
|  5. If the DPL delegates a particular decision, he or she cannot retake
|     responsibility for the decision personally, but can re-delegate it to
|     someone else.[1]
|     (§5.1.1, §8.2)
(中略)
| [1] One might argue that the prohibition on rescinding delegation of
| a particular decision is tied the individual(s) to whom it is given,
| rather than the decision in question.  This is important if the
| person or people to whom the decision is delegated prove unable to
| make it.  This is another variant on the old "what if Linus
| (Torvalds) gets hit by a bus?" problem.  One developer has told me
| that my interpretation poses a different threat, however: "It looks
| like you're going to decide this one issue in a way I don't like, so
| I'll take it away and give the decision to someone who will decide
| it the way I want to."  Why a Leader would do this, or how he or she
| could expect to get away with it, is not clear to me, but this
| scenario is not impossible.  If this ever proves to be a
| non-hypothetical problem, I would ask for the Project Secretary's
| interpretation of the Constitution.

rather than the decision in question の the decision が何と同格になっ
ているのか分からなかったのですが,これより前で the を前置する名詞は 
individual(s) しかないので,そう考えると,
"the individual 略, rather than the decision" は「決定ではなく個人」
と解釈できます.しかし,よくわからんな.

第1文からおおざっぱに訳すと↓

当の決定ではなく,権限が与えられた個人が特定の決定をすることに委任さ
れた権限を取り返す(rescinding)のを禁止する.
これは,権力を移譲された個人(person)や人々(people)がそれを完遂できな
いと証明されたときに重要となる.
Linus がバスに轢かれちゃったらどうしよう問題の新種だ.
ある開発者が言うには,私の翻案は異なる脅威をひきおこす,つまり,
「私が好まない方法で問題が決定されようとしていたら,
私は決定権を取り去り,私が好む方法で決定するだろう誰かに決定権をあずける」

ということかなあ.

原文に戻ります.
> If a particular decision is delegated, the project
> leader cannot take back responsibility for the decision personally, but can
> re-delegate it to someone else.</p>

の英文を日本語で言いかえるとこういうことかしらん.

問題を対処を誰かに頼んだけど,その人に能力がなくって完遂できないと分
かったとき,DPL 個人に問題が戻ってきて DPL が自分で対処するのはルール違反.
DPL は他の誰かに問題処理を再度割り振るのはできる.

よって訳案は以下↓

ある決定権が移譲されたならば、
プロジェクトリーダーは、その決定に対する責務を個人的には取り戻せませんが、
決定権を他の誰かに再委任はできます。



> <li>DSA 900: <a href="$(HOME)/security/2005/dsa-900">fetchmail</a> --
>     Potential information leak.
> # 「potential ...」は「潜在的な……」と「……の可能性」のどちらがよいか?
>     情報漏洩の可能性。

肯定的・否定的なニュアンスの両方を含む「可能性」よりは,
否定的なニュアンスのみを含む「おそれ」という日本語もあります.

かねこさんのdebian-users:45220 の訳では,
|   fetchmailconfig が新規の設定ファイルを安全でない方法で作成するため、
|   ローカルユーザのメールアカウントのパスワードが漏洩する可能性があります。
と「可能性」で訳されています.

> <li>DSA 903: <a href="$(HOME)/security/2005/dsa-903">unzip</a> --
>     Unauthorised permissions modification.
> # 「permission」は「パーミッション」と「許可属性」と「権限」のどれがよいか?
>     認証されていないパーミッション変更。

unauthorised は"権限がない"です.

で,permission の訳ですが,「権限」だとファイル自体のフラグではなく
て,PAM とかの実行許可権限も含んでしまいそうに思えるので,*ここでは* 
パーミッションか許可属性のどちらかがいいなあ."変更"の前に「の」が入っ
たほうが僕は好きです.
よって「権限のないパーミッションの変更。」or「権限のない許可属性の変更。」

かねこさんのdebian-users:45188での訳では,
| 攻撃者にアクセス権限のあるディレクトリ中のファ
| イルを伸張する際に、unzip に unzip 利用ユーザが権限を持つ別のファイルの
| パーミッションの変更をさせる攻撃が可能です。
と,「パーミッション」を使っています.

-- 
タケイノブミツ