[#41431] [ruby-trunk - Bug #5694][Open] Proc#arity doesn't take optional arguments into account. — Marc-Andre Lafortune <ruby-core@...>
27 messages
2011/12/01
[#41442] [ruby-trunk - Bug #5694] Proc#arity doesn't take optional arguments into account.
— Thomas Sawyer <transfire@...>
2011/12/01
[#41443] Re: [ruby-trunk - Bug #5694] Proc#arity doesn't take optional arguments into account.
— Yehuda Katz <wycats@...>
2011/12/01
Maybe we can add a new arity_range method that does this?
[#41446] Re: [ruby-trunk - Bug #5694] Proc#arity doesn't take optional arguments into account.
— Joshua Ballanco <jballanc@...>
2011/12/02
On Thu, Dec 1, 2011 at 6:54 PM, Yehuda Katz <[email protected]> wrote:
[#41450] Re: [ruby-trunk - Bug #5694] Proc#arity doesn't take optional arguments into account.
— Yehuda Katz <wycats@...>
2011/12/02
You could probably extract the information from #parameters, yeah.
[#41452] Re: [ruby-trunk - Bug #5694] Proc#arity doesn't take optional arguments into account.
— Trans <transfire@...>
2011/12/02
On Thu, Dec 1, 2011 at 11:13 PM, Yehuda Katz <[email protected]> wrote:
[#41454] Re: [ruby-trunk - Bug #5694] Proc#arity doesn't take optional arguments into account.
— Yehuda Katz <wycats@...>
2011/12/02
Yeah=85 it would be nice to be able to do:
[#41435] [ruby-trunk - Feature #5695][Open] CoffeeScript "is" and "isnt" keywords — Suraj Kurapati <sunaku@...>
6 messages
2011/12/01
[#41456] [ruby-trunk - Bug #5700][Open] fork {} segfaults during VM cleanup when run inside Fiber — Eric Wong <normalperson@...>
6 messages
2011/12/03
[#41478] [ruby-trunk - Feature #5707][Open] temporary file creation without finalizer and delegate. — Akira Tanaka <akr@...>
7 messages
2011/12/04
[#41481] Re: [ruby-trunk - Feature #5707][Open] temporary file creation without finalizer and delegate.
— Eric Wong <normalperson@...>
2011/12/04
Akira Tanaka <[email protected]> wrote:
[#41484] Re: [ruby-trunk - Feature #5707][Open] temporary file creation without finalizer and delegate.
— Tanaka Akira <akr@...>
2011/12/05
2011/12/5 Eric Wong <[email protected]>:
[#41496] [ruby-trunk - Bug #5714][Open] Unexpected error of STDIN#read with non-ascii input on Windows XP — Heesob Park <phasis@...>
22 messages
2011/12/06
[#41500] [ruby-trunk - Bug #5714] Unexpected error of STDIN#read with non-ascii input on Windows XP
— Heesob Park <phasis@...>
2011/12/06
[#41501] Re: [ruby-trunk - Bug #5714] Unexpected error of STDIN#read with non-ascii input on Windows XP
— "U.Nakamura" <usa@...>
2011/12/06
Hello,
[#41578] [ruby-trunk - Bug #5714] Unexpected error of STDIN#read with non-ascii input on Windows XP
— Luis Lavena <luislavena@...>
2011/12/09
[#41601] Re: [ruby-trunk - Bug #5714] Unexpected error of STDIN#read with non-ascii input on Windows XP
— "U.Nakamura" <usa@...>
2011/12/12
Hello,
[#41671] [ruby-trunk - Bug #5714] Unexpected error of STDIN#read with non-ascii input on Windows XP
— Hiroshi Shirosaki <h.shirosaki@...>
2011/12/15
[#41684] Re: [ruby-trunk - Bug #5714] Unexpected error of STDIN#read with non-ascii input on Windows XP
— "U.Nakamura" <usa@...>
2011/12/16
Hello,
[#41511] [ruby-trunk - Bug #5719][Open] Hash::[] can't handle 100000+ args — Nick Quaranto <nick@...>
13 messages
2011/12/07
[#41541] [ruby-trunk - Feature #5726][Open] Process::EXIT_SUCCESS and Process::EXIT_FAILURE — Akira Tanaka <akr@...>
4 messages
2011/12/08
[#41557] [ruby-trunk - Bug #5730][Open] Optinal block parameters assigns wrong — Yukihiro Matsumoto <matz@...>
14 messages
2011/12/08
[#41559] Re: [ruby-trunk - Bug #5730][Open] Optinal block parameters assigns wrong
— Tanaka Akira <akr@...>
2011/12/09
2011/12/9 Yukihiro Matsumoto <[email protected]>:
[#41560] Re: [ruby-trunk - Bug #5730][Open] Optinal block parameters assigns wrong
— Yukihiro Matsumoto <matz@...>
2011/12/09
Hi,
[#41581] [ruby-trunk - Bug #5737][Open] WEBrick doesn't support keep alive connections for 204 and 304 responses — Aaron Patterson <aaron@...>
8 messages
2011/12/10
[#41586] [ruby-trunk - Feature #5741][Open] Secure Erasure of Passwords — Martin Bosslet <Martin.Bosslet@...>
17 messages
2011/12/10
[#41592] My bug evaluation criteria — Marc-Andre Lafortune <ruby-core-mailing-list@...>
I don't think there is an official way to judge a bug, but for me it
4 messages
2011/12/11
[#41594] [ruby-trunk - Bug #5746][Open] Proc#curry too strict about lambda's arity. — Marc-Andre Lafortune <ruby-core@...>
7 messages
2011/12/11
[#41618] [ruby-trunk - Bug #5754][Open] Double require bug in 1.9.3 — Evan Phoenix <evan@...>
5 messages
2011/12/12
[#41630] redmine.ruby-lang.org -> bugs.ruby-lang.org — Shugo Maeda <shugo@...>
Hello,
6 messages
2011/12/13
[#41634] [ruby-trunk - Bug #5759][Open] flatten calls to_ary on everything — Thomas Sawyer <transfire@...>
8 messages
2011/12/13
[#41656] [ruby-trunk - Bug #5763][Open] sprintf not throwing error for wrong number of arguments — NagaChaitanya Vellanki <me@...>
8 messages
2011/12/14
[#41662] [ruby-trunk - Bug #5765][Open] [PATCH] modernize Timeout usage in net/{http,pop,smtp,telnet} — Eric Wong <normalperson@...>
9 messages
2011/12/15
[#41668] [ruby-trunk - Feature #5766][Open] Hash.each_with_object should behave differently when block's arity is 3 — Rodrigo Rosenfeld Rosas <rr.rosas@...>
5 messages
2011/12/15
[#41672] [ruby-trunk - Feature #5767][Open] Cache expanded_load_path to reduce startup time — Yura Sokolov <funny.falcon@...>
13 messages
2011/12/15
[#41681] Documentation of the language itself (syntax, meanings, etc) — Rodrigo Rosenfeld Rosas <rr.rosas@...>
Since Ruby is built on top of simple concepts, most of the documentation
23 messages
2011/12/15
[#41683] Re: Documentation of the language itself (syntax, meanings, etc)
— Gary Wright <gwtmp01@...>
2011/12/15
[#41686] Re: Documentation of the language itself (syntax, meanings, etc)
— Rodrigo Rosenfeld Rosas <rr.rosas@...>
2011/12/16
Em 15-12-2011 19:23, Gary Wright escreveu:
[#41688] Re: Documentation of the language itself (syntax, meanings, etc)
— Gary Wright <gwtmp01@...>
2011/12/16
[#41732] Re: Documentation of the language itself (syntax, meanings, etc)
— Eric Hodel <[email protected]>
2011/12/19
On Dec 15, 2011, at 7:39 PM, Rodrigo Rosenfeld Rosas wrote:
[#41734] Re: Documentation of the language itself (syntax, meanings, etc)
— Rodrigo Rosenfeld Rosas <rr.rosas@...>
2011/12/19
Em 19-12-2011 19:38, Eric Hodel escreveu:
[#41738] Re: Documentation of the language itself (syntax, meanings, etc)
— Eric Hodel <[email protected]>
2011/12/20
On Dec 19, 2011, at 3:04 PM, Rodrigo Rosenfeld Rosas wrote:
[#41753] Re: Documentation of the language itself (syntax, meanings, etc)
— Rodrigo Rosenfeld Rosas <rr.rosas@...>
2011/12/20
Em 19-12-2011 23:35, Eric Hodel escreveu:
[#41691] Ruby IRC Presence Problem — Eero Saynatkari <ruby-ml@...>
Hi,
3 messages
2011/12/16
[#41717] Feature : optional argument in File.join — Michel Demazure <michel@...>
In Windows, when using File.join, one often ends with a path containing
13 messages
2011/12/19
[#41719] Re: Feature : optional argument in File.join
— Luis Lavena <luislavena@...>
2011/12/19
On Mon, Dec 19, 2011 at 6:09 AM, Michel Demazure <[email protected]> wrot=
[#41720] Re: Feature : optional argument in File.join
— Michel Demazure <michel@...>
2011/12/19
Luis Lavena wrote in post #1037331:
[#41737] Re: Feature : optional argument in File.join
— Nobuyoshi Nakada <nobu@...>
2011/12/20
Hi,
[#41740] Re: Feature : optional argument in File.join
— Nikolai Weibull <now@...>
2011/12/20
On Tue, Dec 20, 2011 at 02:12, Nobuyoshi Nakada <[email protected]> wrote:
[#41742] Re: Feature : optional argument in File.join
— Nobuyoshi Nakada <nobu@...>
2011/12/20
Hi,
[#41744] Re: Feature : optional argument in File.join
— Nikolai Weibull <now@...>
2011/12/20
On Tue, Dec 20, 2011 at 08:17, Nobuyoshi Nakada <[email protected]> wrote:
[#41750] Re: Feature : optional argument in File.join
— Michel Demazure <michel@...>
2011/12/20
Nikolai Weibull wrote in post #1037488:
[#41721] Ruby and oniguruma relation. — V咜 Ondruch <v.ondruch@...>
Hi everybody,
5 messages
2011/12/19
[#41725] [ruby-trunk - Feature #5778][Open] Allow WEBrick::HTTPResponse to send IO-duck-typed bodies — Alex Young <alex@...>
6 messages
2011/12/19
[#41728] [ruby-trunk - Feature #5781][Open] Query attributes (attribute methods ending in `?` mark) — Thomas Sawyer <transfire@...>
15 messages
2011/12/19
[#41755] [ruby-trunk - Feature #5781] Query attributes (attribute methods ending in `?` mark)
— Yukihiro Matsumoto <matz@...>
2011/12/20
[#41774] [ruby-trunk - Feature #5788][Open] Thread#at_exit — Masaki Matsushita <glass.saga@...>
10 messages
2011/12/22
[#41798] [ruby-trunk - Feature #5788] Thread#at_exit
— Masaki Matsushita <glass.saga@...>
2011/12/24
[#41780] [Backport93 - Backport #5793][Open] Please backport r33662, r33666 — Jon Forums <redmine@...>
8 messages
2011/12/22
[#41787] Breaking while loading — Nikolai Weibull <now@...>
Hi!
4 messages
2011/12/22
[#41797] [ruby-trunk - Feature #5805][Open] object_hexid — Thomas Sawyer <transfire@...>
9 messages
2011/12/24
[#41799] Best way to separate implementation specific code? — Luis Lavena <luislavena@...>
Hello,
15 messages
2011/12/24
[#41800] Re: Best way to separate implementation specific code?
— KOSAKI Motohiro <kosaki.motohiro@...>
2011/12/24
2011/12/24 Luis Lavena <[email protected]>:
[#41811] Re: Best way to separate implementation specific code?
— "U.Nakamura" <usa@...>
2011/12/26
Hello,
[#41817] Re: Best way to separate implementation specific code?
— Luis Lavena <luislavena@...>
2011/12/26
On Sun, Dec 25, 2011 at 10:51 PM, U.Nakamura <[email protected]> wrote:
[#41828] Re: Best way to separate implementation specific code?
— Luis Lavena <luislavena@...>
2011/12/27
Hello,
[#41830] Re: Best way to separate implementation specific code?
— "U.Nakamura" <usa@...>
2011/12/28
Hello,
[#41831] Re: Best way to separate implementation specific code?
— Yukihiro Matsumoto <matz@...>
2011/12/28
Hi,
[#41832] Re: Best way to separate implementation specific code?
— Luis Lavena <luislavena@...>
2011/12/28
On Tue, Dec 27, 2011 at 11:21 PM, Yukihiro Matsumoto <[email protected]> w=
[#41833] Re: Best way to separate implementation specific code?
— Yukihiro Matsumoto <matz@...>
2011/12/28
Hi,
[#41840] Re: Best way to separate implementation specific code?
— Luis Lavena <luislavena@...>
2011/12/29
On Tue, Dec 27, 2011 at 11:44 PM, Yukihiro Matsumoto <[email protected]> w=
[#41812] [ruby-trunk - Feature #5809][Open] Benchmark#bm: remove the label_width parameter — Benoit Daloze <redmine@...>
11 messages
2011/12/26
[#41841] YAML has become very slow under 1.9 — j.wuttke <j.wuttke@...>
The simple script
7 messages
2011/12/29
[#41848] [ruby-trunk - Feature #5826][Open] When the RUBY API_VERSION will be increased? — Ayumu AIZAWA <ayumu.aizawa@...>
5 messages
2011/12/30
[ruby-core:41586] [ruby-trunk - Feature #5741][Open] Secure Erasure of Passwords
From:
Martin Bosslet <Martin.Bosslet@...>
Date:
2011-12-10 21:02:15 UTC
List:
ruby-core #41586
Issue #5741 has been reported by Martin Bosslet. ---------------------------------------- Feature #5741: Secure Erasure of Passwords http://redmine.ruby-lang.org/issues/5741 Author: Martin Bosslet Status: Open Priority: Normal Assignee: Category: Target version: 2.0.0 In other languages it is considered good practice to securely erase passwords immediately after they were used. Imagine authentication in a web app - ultimately a String containing the password arrives at the server, where it will be processed and compared to some previously stored value. After this is done, there is no need to store these password Strings any longer, so they should be discarded right away (more on why later). In C, you would simply overwrite the array of bytes with zeroes or random values. In Java, Strings are immutable, that's why there it is common practice to use char[] for all things password and overwrite them when done. Currently, there is no way in Ruby to overwrite the memory that was used by a String. String#clear and String#replace both use str_discard internally, which only frees the underlying pointer without overwriting it. The problem with not erasing passwords is this: the contents of the String stay in memory until they are finally GC'ed. But even then only the pointer will be freed, leaving the contents mostly intact until the memory is reclaimed and overwritten later on. This could be exploited if an attacker had access to the memory of the server. This could happen in many ways: a core dump after a crash, access to the host if the server runs in a VM, or even by deep-freezing the DRAM :) [1] It could be argued that given the examples above, much more devastating attacks would be possible since in all of those cases you more or less have physical access to the machine. But I would still consider this to be a valid concern, if not only for the reason of never opening additional attack surfaces if they can be avoided relatively easily. I also found [2], which seems to show that Python deals with similar problems and it also contains more background info. Eric Hodel and I discussed this yesterday and Eric came up with a C extension that can be used to illustrate the problem (attached). If you inspect the resulting core dump, you will find the following: - the untouched String remains in memory fully intact - the String#clear'ed String remains to a large extent, typically the first character is missing - so if you typed "PASSWORD", search for "ASSWORD" (unintentional pun) instead - The String#clear_secure'ed will have been completely erased, no traces remain My questions: 1. Would you agree that we need this functionality? 2. Where would we ideally place it? I'm not sure whether String is the perfect place, but on the other hand, String is the only place where we have access to the implementation details. 3. Are there better alternative ways how we could achieve this? [1] http://www.schneier.com/blog/archives/2008/02/cold_boot_attac.html [2] http://stackoverflow.com/questions/728164/securely-erasing-password-in-memory-python -- http://redmine.ruby-lang.org