[#26664] refactoring tcltklib.c (deleted ip check) — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
山本です。
永井@知能.九工大です.
山本です。
永井@知能.九工大です.
山本です。
永井@知能.九工大です.
山本です。
永井@知能.九工大です.
山本です。
山本です。
永井@知能.九工大です.
山本です。
永井@知能.九工大です.
[#26711] --with-static-linked-extするとrequireできないライブラリがある — IWATSUKI Hiroyuki <don@...>
岩月と申します。
なかだです。
[#26721] TkVariable.new_hash 経由だと trace が発生しない — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
山本です。
[#26723] Fixnum演算メソッド中のcoerceの削減 — Tadashi Saito <shiba@...2.accsnet.ne.jp>
斎藤と申します。
[#26743] zsuper in a method with optional arg — "NAKAMURA, Hiroshi" <nakahiro@...>
-----BEGIN PGP SIGNED MESSAGE-----
まつもと ゆきひろです
-----BEGIN PGP SIGNED MESSAGE-----
[#26745] TkCheckbutton#variable as getter? — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
山本です。
永井@知能.九工大です.
山本です。
永井@知能.九工大です.
永井@知能.九工大です.
山本です。
永井@知能.九工大です.
[#26753] some questions about tcltklib.c — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
山本です。
永井@知能.九工大です.
山本です。
[#26764] multi-thread and logger — Nobuhiro IMAI <nov@...>
いまいです。
[#26791] Failure: test_block_passing(TestIterator) — Kazuhiro NISHIYAMA <zn@...>
西山和広です。
まつもと ゆきひろです
[#26800] reducing PUSH_TAG in rescue, and useless exceptions — nobu@...
なかだです。
[#26808] test/nkf/test_kconv.rb — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
山本です。
[#26817] test/socket/test_tcp.rb freeze on windows — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
山本です。
こんにちは、なかむら(う)です。
山本です。
山本です。
こんにちは、なかむら(う)です。
山本です。
こんにちは、なかむら(う)です。
山本です。返信が遅れてすみません。
[#26829] cannot check EOF of pipe on windows — "U.Nakamura" <usa@...>
こんにちは、なかむら(う)です。
山本です。
こんにちは、なかむら(う)です。
山本です。
なかだです。
山本です。
こんにちは、なかむら(う)です。
なかだです。
こんにちは、なかむら(う)です。
なかだです。
こんにちは、なかむら(う)です。
山本です。
[#26840] [BUG] oniguruma + utf-8 — "NAKAMURA, Hiroshi" <nakahiro@...>
-----BEGIN PGP SIGNED MESSAGE-----
[#26851] ripper for 1.8 — Tanaka Akira <akr@...17n.org>
ruby-1.8 で動かす gonzui で、ruby code の解析をしたいという要望があっ
[#26872] irb -I/ruby -Iと$LOAD_PATH — akira yamada / やまだあきら <akira@...>
Debianユーザからruby -Iとirb -Iで
なかだです。
nobuyoshi nakada wrote:
けいじゅ@いしつかです.
けいじゅ@いしつかです.
なかだです。
けいじゅ@いしつかです.
まつもと ゆきひろです
けいじゅ@いしつかです.
[#26883] top level include on load(filename, true) — Shugo Maeda <shugo@...>
前田です。
[#26897] fail on make install — KIMURA Koichi <kimura.koichi@...>
木村です。
こんにちは、なかむら(う)です。
木村です。
木村です。
木村です。
こんにちは、なかむら(う)です。
木村です。
こんにちは、なかむら(う)です。
なかだです。
山本です。
なかだです。
なかだです。
山本です。
こんにちは、なかむら(う)です。
なかだです。
まつもと ゆきひろです
山本です。
なかだです。
[#26900] multiplying empty string — nobuyoshi nakada <nobuyoshi.nakada@...>
まつもと ゆきひろです
In article <1125327516.070646.12845.nullmailer@x31.priv.netlab.jp>,
まつもと ゆきひろです
In article <1125356798.802509.8788.nullmailer@x31.priv.netlab.jp>,
まつもと ゆきひろです
In article <1125369966.174424.13781.nullmailer@x31.priv.netlab.jp>,
[ruby-dev:26849] Re: $SAFE=1 の open-uri で redirect 時にエラー
In article <4302A37D.2010801@ruby-lang.org>, Shugo Maeda <shugo@ruby-lang.org> writes: >> その操作の量の違いは大きな違いではないでしょうか。 > > その点については、同意します。 > 田中さんの主張は、「Perlの方が指針がはっきりしているため、Rubyよりも > 好ましい」というものだと理解していましたので、それに対する反論として > 上記のように書きました。 > taint機構の対象範囲の違いを軽視しているわけではありません。 どの操作が許可・禁止されるのかは指針から決まるので、この違いはまさに指 針に直結していると認識しています。 前田さんの提案では、操作の許可・禁止は安全性の指針以外の点から決まって いるんでしょうか? 外界との全ての通信をデフォルトで禁止するという指針 自体ははっきりしていて、はっきりしていること自体には違いは無いと思って いたのですが。 >> たくさんあればあるほど、判断に失敗する機会が増え、また判断自体は適切で >> あったとしてもその判断がユーザが伝わらずに齟齬が生じて失敗する可能性が >> 増えます。 > > 前者に関しては、Perlでは何もチェックしないケースに対してチェックミス > があったとしても、Perlより危険になることはないと考えます。 考えずに untaint することに慣れてしまうことに恐れを感じています。 untaint はセキュリティ機構を回避するものですから、untaint を呼ぶときに はそれが適切であることを確信したいと思っています。 しかし、外界との通信のすべて (ほとんど?) に untaint が必要というのは、 ユーザが要求する安全性とは大きく離れていて、場当たり的に多くの untaint を書かなければならず、考えずに untaint に慣れてしまいがちなのではない だろうか、と考えています。 perl の指針は前田さんの案よりもデフォルトで緩く、ユーザが要求する安全 性と近いように感じているので、untaint を行うケースが少なく、untaint に 慣れてしまう可能性が低いんじゃないかと思っています。 > また、 > > def delete_files(list_filename) > open(list_filename) do |f| > for line in f > File.unlink(line.chomp.untaint) > end > end > end > > のようなメソッドがあった場合、Rubyではlist_filenameが汚染されていれば > open操作で失敗するわけですが、Perlの場合には同様のコードだとopenの時点 > では処理が続行されてしまいます。 > 上記の例そのままのようなコードはあまりありそうにないように思われますが、 > たとえば、URLを引数に取って、そのURLから取得した情報をもとにプログラム > の外部に影響を及ぼすような操作をすることは十分に考えられると思います。 > そのような際には安全なライブラリにするためには、汚染チェックを自前で > 行ったエラーを発生させるようなコードを書かなければなりません。 これは delete_files の作者がどういう安全性を提供しようとするかによるの ではないでしょうか。 perl の原則に従って、外部へ影響しないという安全性を提供しようとしたの であれば、これは単に untaint を間違えて入れてしまったというバグでしょ う。もし untaint を入れなければ、このメソッドは意図通りに失敗し、その 挙動は原則に従っているのでユーザはドキュメントを読まなくてもその挙動を 予想できます。 perl の原則から逸脱してドキュメントに記述した上で、delete_files の機能 を list_filename が taint でないときだけに提供しするのであれば、たしか に自前で検査する必要がありそうです。これは外界からの情報の取り込みにお ける結果に引数が taint だったかの情報が含まれないためですが、この点は 考えていませんでした。たしかにそこには利点がありそうです。 > Perlの方が判断が楽なので安全だとは、一概には言えないのではないでしょうか。 はい。どちらかがもう一方よりもすべてのケースで一方的に良いという結論が 出ることは期待していません。 (むろん、一方的に良い方法があるんだったらぜひその方法を推したいところ ですが。) したがって、両方 (もしくは、可能なら taint 機構としてあり得る様々な方 法) の利点・欠点を理解し、自分の感覚による重みをつけて判断したいと思っ ているのですが、今のところ判断できるほどには理解できていません。その点 で前田さんがどう比較するか参考にしたいと思っているのですが... 理解に困 難さを感じています。 -- [田中 哲][たなか あきら][Tanaka Akira]