[#30872] segv when reentering into Fiber with callcc — sheepman <sheepman@...>
こんばんは、sheepman です。
ささだです。
遠藤と申します。
ささだです。
遠藤です。
ささだです。
まつもと ゆきひろです
In article <E1Hw9be-0002Rs-Qg@x31>,
まつもと ゆきひろです
[#30920] Integer#prime_division と Prime — TOYOFUKU Chikanobu <nobu_toyofuku@...>
豊福です。
[#30929] secrand.rb — "NAKAMURA, Hiroshi" <nakahiro@...>
-----BEGIN PGP SIGNED MESSAGE-----
In article <4669066C.2080307@sarion.co.jp>,
-----BEGIN PGP SIGNED MESSAGE-----
In article <46694461.4060706@sarion.co.jp>,
-----BEGIN PGP SIGNED MESSAGE-----
In article <46697C0B.8060402@sarion.co.jp>,
-----BEGIN PGP SIGNED MESSAGE-----
In article <4669DAB0.4050705@sarion.co.jp>,
-----BEGIN PGP SIGNED MESSAGE-----
In article <466AA73C.9030407@sarion.co.jp>,
-----BEGIN PGP SIGNED MESSAGE-----
なかだです。
-----BEGIN PGP SIGNED MESSAGE-----
In article <466D5B1D.8030205@sarion.co.jp>,
-----BEGIN PGP SIGNED MESSAGE-----
In article <469253E9.9010203@sarion.co.jp>,
-----BEGIN PGP SIGNED MESSAGE-----
-----BEGIN PGP SIGNED MESSAGE-----
In article <4694338C.7090303@sarion.co.jp>,
-----BEGIN PGP SIGNED MESSAGE-----
In article <4694E6A6.2060303@sarion.co.jp>,
-----BEGIN PGP SIGNED MESSAGE-----
なかだです。
-----BEGIN PGP SIGNED MESSAGE-----
なかだです。
-----BEGIN PGP SIGNED MESSAGE-----
[#30971] Linux/ia64で'ucontext_t' undeclared — akira yamada / やまだあきら <akira@...>
最近のRuby 1.9をLinux/ia64上でmakeしようとすると
まつもと ゆきひろです
Yukihiro Matsumoto さんは書きました:
まつもと ゆきひろです
Yukihiro Matsumoto さんは書きました:
まつもと ゆきひろです
In article <E1HygwQ-0001OA-4f@x31>,
ささだです。
[#30996] new block parameter rule — SASADA Koichi <ko1@...>
ささだです。
[#31002] ("a".."f").step(2) {|x| p x} — Tanaka Akira <akr@...>
string の range の step で引数が効かないように思います。
まつもと ゆきひろです
ささだです。
まつもと ゆきひろです
[#31028] rb_get_interned — Nobuyoshi Nakada <nobu@...>
なかだです。
[#31034] Re: [ruby-cvs:19815] Ruby:r12579 (trunk): * parse.y (rb_intern2): name may not be NUL-terminated. — "U.Nakamura" <usa@...>
こんにちは、なかむら(う)です。
[#31046] Conditional jump or move depends on uninitialised value(s) in TOPLEVEL_BINDING — Tanaka Akira <akr@...>
valgrind をかけたところとりあえず最初のが
ささだです。
[#31063] make error at bcc32 — "Nebata" <tnebata@...>
ねばたです。
[#31066] consts for gdb support — Nobuyoshi Nakada <nobu@...>
なかだです。
[#31068] $&;[] dumps core — "Yusuke ENDOH" <mame@...>
遠藤と申します。
ささだです。
遠藤です。
ささだです。
遠藤です。
[#31072] {*0} dumps core — "Yusuke ENDOH" <mame@...>
遠藤と申します。
ささだです。
[ruby-dev:30946] Re: secrand.rb
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 相変わらず本筋以外の脇道だけ。そういえば去年のRubyKaigi2006では、そんな プレゼンをさせていただいたのでした。 http://dev.ctor.org/download/RubyKaigi2006_SAP_20060610.pdf SecRandネタ Tanaka Akira wrote: > ゆぞさんに口頭で尋ねてみたんですが、SecureRandom がいいとの > ことで、なひさんとゆぞさんの二人からそういわれると、そっちの > 業界の見識というものだと感じざるを得ません。というわけで > SecureRandom かなぁ、と思っています。 JavaがSecureRandomなんですよ。で、広く使われてるセキュリティAPIのOOなも のはJavaが初めてで、他に.NETくらいしかないですからね。.NETは System.Security.Cryptography.RandomNumberGeneratorです(暗号用のRNG)。 というわけで、「業界」というとJava重視になるので、あまり業界云々は考えな いでいいと思います(なので触れてこなかった)。 > 他の意見もあれば聞きたいです。 というわけで再び待ち。 / / / Random新設ネタ。 >>> そういう pseudo random number generator のクラスを最初から >>> ruby が提供するのはありうると思いますが、 >> 提供したほうがいいと思ってます。お前がやれって? > > まぁ、手を動かす人が一人もいなければ提供されませんからね。 > > Random という名前のクラスで Random#srand と Random#rand とい > うメソッドがあって中身のアルゴリズムが srand/rand と同じ、と > いうのをだれかが実装つきで出せばすぐに入っちゃうんじゃないか > という気がします。 #rand、#srandはまた名前でもめるかもしれませんね。例えばSecRandは #random_bytesだし。 / / / PRNGネタ。 >> もちろんわかってる人は自前で作るでしょうが、例えば現状のcgi/session.rbで >> もやってなかったわけで。Railsのどこぞのプラグインがsrandしたおかげで、認 >> 証機構が役立たなくなってたとか、いつか起こるんじゃないですかね。 >> >> 簡単に使える代替案があれば、「ライブラリ作者はrandは危険だから使うな」と >> 主張し易くなる。 > > どうも危険性に実感が湧かないなぁ、と思ってその原因をしばらく > 考えたところ、上で述べた Random のようなクラスが必要になる認 > 証機構の具体例を知らないからだ、と思い至りました。 > > 具体的にはどの認証機構がそういうクラスを必要とするんですか? 想定していたのは、cgi/session.rbでの利用のような、「推測不可能な識別子を 作る」という目的での利用でした。「認証機構が」というのは、横でnonceの話 をしている時には、不要に紛らわしい書き方でした。 / / / nonceネタ。 >>> # nonce って secure random でないとよろしくないですよね? >> 厳密に言えば、onceであることがその存在意義なので、secure randomである必 >> 要性はありません。例えば0からincrementalでもOKです。で、Rubyでは、randで >> 生成しちゃ駄目です。先の話のように、誰かが意図的に、srand(1)とか埋め込む >> かもしれない(毎回同じ値になる可能性があり、onceじゃなくなる)。 > > ふむ。私はあまりよくわかっていないようです。 > (言い訳にはなりませんが、事実として素人に近いのです) > > digest auth で、古い nonce を受け付けることの得失について論 > じている項があります。 > (RFC 2617 の 4.3 Limited Use Nonce Values) > > それを読むと転送効率のために古い nonce をある程度受け付ける > こともある、と思えます。 > > そういう場合はどうなんでしょう? はい、機構から考えると、replay attack避けのために「一度だけ」としたほう がよいのですが、障害による切断→リクエスト再送などの状況を考えると、ある 程度古いnonceを受け付けざるを得ないと思います。(RFC2617をちゃんと読んで はいないので、用語とか変かもしれません)。 つまりonceじゃないじゃん、どうして? という指摘だと思いますが、このような 場合でも、古いonceを無制限に受け付けても問題が起こらないということではな く、可能な限りonceなものとして扱うべきです。nonceにタイムスタンプを埋め て署名したり、サーバ側で時刻と共に記憶したり。 という回答であってます? 元の話と離れすぎなので、「そういうことが聞きたい んじゃないよ」な気がしています。 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (Cygwin) iQEVAwUBRms3Rh9L2jg5EEGlAQLUIwf/X536+hI84iuRiNcLVHKmFj5B6J422Jmb JXThOM4hh/PXaXdokFziGVhUFxqy2YO1mTU8pQJ6povK58kjClotQMJMi0TmYyus adpn0h2kERPL1mYGM9Xo6+ezK4k2/UcMy6KoA3a67CDTu/pG47Y1X+xmdbqbPtXw k9UkkPuPZmkKezbzHU9eGcFNnSXG1rIXsDylw3vSHxPoWy8DIY7iS8GfPm8S+aoH i6lU8qTbAd6chx5jtDr7w7GNtZdYa2zi9NGGEmuwWhGtV45hSD7ZS3y3WUhC3yzE MNDmzuTSgPdGr+No7k+WUrd3PcSvPem7Y/6fKalG2bN0RueJD8PF8w== =bykI -----END PGP SIGNATURE-----