[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 利用ユーザが権限を持つ別のファイルの
| パーミッションの変更をさせる攻撃が可能です。
と,「パーミッション」を使っています.
--
タケイノブミツ