[#38782] [Bug:trunk] Re: [ruby-cvs:31281] Ruby:r24063 (trunk): * ext/tk/extconf.rb: New strategy for searching Tcl/Tk libraries. — "U.Nakamura" <usa@...>

こんにちは、なかむら(う)です。

15 messages 2009/07/14
[#38784] Re: [Bug:trunk] Re: [ruby-cvs:31281] Ruby:r24063 (trunk): * ext/tk/extconf.rb: New strategy for searching Tcl/Tk libraries. — Hidetoshi NAGAI <nagai@...> 2009/07/14

永井@知能.九工大です.

[#38790] Re: [Bug:trunk] Re: [ruby-cvs:31281] Ruby:r24063 (trunk): * ext/tk/extconf.rb: New strategy for searching Tcl/Tk libraries. — "U.Nakamura" <usa@...> 2009/07/15

こんにちは、なかむら(う)です。

[#38791] Re: [Bug:trunk] Re: [ruby-cvs:31281] Ruby:r24063 (trunk): * ext/tk/extconf.rb: New strategy for searching Tcl/Tk libraries. — Hidetoshi NAGAI <nagai@...> 2009/07/15

永井@知能.九工大です.

[#38792] Re: [Bug:trunk] Re: [ruby-cvs:31281] Ruby:r24063 (trunk): * ext/tk/extconf.rb: New strategy for searching Tcl/Tk libraries. — "U.Nakamura" <usa@...> 2009/07/15

こんにちは、なかむら(う)です。

[#38793] Re: [Bug:trunk] Re: [ruby-cvs:31281] Ruby:r24063 (trunk): * ext/tk/extconf.rb: New strategy for searching Tcl/Tk libraries. — Hidetoshi NAGAI <nagai@...> 2009/07/15

永井@知能.九工大です.

[#38794] Re: [Bug:trunk] Re: [ruby-cvs:31281] Ruby:r24063 (trunk): * ext/tk/extconf.rb: New strategy for searching Tcl/Tk libraries. — "U.Nakamura" <usa@...> 2009/07/15

こんにちは、なかむら(う)です。

[#38843] 複素数リテラルについて — Yukihiro Matsumoto <matz@...>

まつもと ゆきひろです

32 messages 2009/07/21
[#38855] Re: 複素数リテラルについて — Yusuke ENDOH <mame@...> 2009/07/22

遠藤です。

[#38857] Re: 複素数リテラルについて — Tadayoshi Funaba <tadf@...> 2009/07/22

> は十分検討されたのでしょうか。積極的に反対なわけではないですが、

[#38912] String#valid_encoding?にオプションが欲しい — Fujioka <fuj@...>

xibbarこと藤岡です。(なぜか届かないので再送します)

19 messages 2009/07/27
[#38918] Re: String#valid_encoding?にオプションが欲しい — "NARUSE, Yui" <naruse@...> 2009/07/27

成瀬です。

[#38925] Re: String#valid_encoding?にオプションが欲しい — Fujioka <fuj@...> 2009/07/27

xibbarです。

[#38927] Re: String#valid_encoding?にオプションが欲しい — Fujioka <fuj@...> 2009/07/28

xibbarです。

[#38914] [Bug #1819] Ruby-1.9.1を使用しDB(MySQL)接続時にエラー — Ryouhei Saita 斉田 <redmine@...>

Bug #1819: Ruby-1.9.1を使用しDB(MySQL)接続時にエラー

11 messages 2009/07/27

[#38932] Enumerator#peek — Tanaka Akira <akr@...>

Enumerator#peek を新設するのはどうでしょうか。

16 messages 2009/07/28

[ruby-dev:38889] Re: セキュリティモデルのドキュメント

From: Shugo Maeda <shugo@...>
Date: 2009-07-23 13:02:35 UTC
List: ruby-dev #38889
前田です。

2009/07/20 10:51 に Tanaka Akira<akr@fsij.org> さんは書きました:
>> === ライブラリにおけるuntaint
>>
>> メソッドの引数などでユーザから与えられたデータが汚染されたオブジェクト
>> でない場合は、ユーザが指定した操作の実行を意図していると判断し、処理の
>> 実行に必要な内部データのuntaintは、ライブラリ側で行うことが望ましい。
>>
>> ライブラリ内部で生成されるオブジェクトについては、ライブラリのユーザ側
>> からuntaintすることができないため、上記のようなuntaintを行わないと、そ
>> のライブラリをセーフレベル1以上では利用することができないためである。
>
> これだけだと untaint しても安全かどうかどうやって判断したら
> いいのかわかりませんねぇ。
>
> 動かなかったら何も考えずに untaint するのが正しいとはちょっ
> と思えませんし。
>
> 安全性について何を考えて検討すればいいのかというところがわか
> りません。

以前書いたことの繰り返しになりますが、セーフレベル1〜3のtaint機構は
あくまでもアプリケーションプログラマのミスに対するフェールセーフ機構
であり、安全性の確認はライブラリ側ではなくアプリケーション側の責任だと
考えています。
今のセキュリティモデルでは、アプリケーションから渡されたオブジェクトが
汚染されていない場合は、ライブラリはアプリケーションに指示された通りに
動作することが期待されているように思います。
# 設計者のまつもとさんに違うと言われれば別ですが。

中途半端だと言われればそうかもしれませんが、まずは現在の設計の意図
を明確にしたいと思います。
その上で、変えた方がよい、あるいはいっそのことなくしてしまった方がよい、
といった議論をしたいです。

-- 
Shugo Maeda

In This Thread