[#43077] problems committing — Aaron Patterson <tenderlove@...>
It seems like the disk might be full on the svn server:
5 messages
2012/03/05
[#43090] "\\".gsub("\\", "\\\\") == "\\" ?!!! — Rodrigo Rosenfeld Rosas <rr.rosas@...>
Please, help me understand what is happening here.
6 messages
2012/03/06
[#43094] Re: "\\".gsub("\\", "\\\\") == "\\" ?!!!
— Xavier Noria <fxn@...>
2012/03/06
A literal passed as second argument to gsub goes over two
[#43120] [ruby-trunk - Bug #6124][Open] What is the purpose of "fake" gems in Ruby — Vit Ondruch <v.ondruch@...>
27 messages
2012/03/07
[#43142] Questions about thread performance (with benchmark included) — Rodrigo Rosenfeld Rosas <rr.rosas@...>
A while ago I've written an article entitled "How Nokogiri and JRuby
10 messages
2012/03/08
[#43785] Re: Questions about thread performance (with benchmark included)
— Tomoyuki Chikanaga <nagachika00@...>
2012/03/28
Hello, Rodrigo.
[#43797] Re: Questions about thread performance (with benchmark included)
— Rodrigo Rosenfeld Rosas <rr.rosas@...>
2012/03/28
Em 27-03-2012 23:22, Tomoyuki Chikanaga escreveu:
[#44213] Re: Questions about thread performance (with benchmark included)
— SASADA Koichi <ko1@...>
2012/04/09
Hi,
[#44214] Re: Questions about thread performance (with benchmark included)
— Urabe Shyouhei <shyouhei@...>
2012/04/09
#### MRI threads myths and facts #####
[#44220] Re: Questions about thread performance (with benchmark included)
— Rodrigo Rosenfeld Rosas <rr.rosas@...>
2012/04/09
Hi Urabe, thank you for your input, but I think you have
[#43245] [ruby-trunk - Bug #6131][Open] Ctrl-C handler do not work from exec process (Windows) — Luis Lavena <luislavena@...>
10 messages
2012/03/12
[#43279] [ruby-trunk - Bug #6148][Open] ruby_1_9_3 revision conflict — Jon Forums <redmine@...>
4 messages
2012/03/14
[#43313] [ruby-trunk - Feature #6150][Open] add Enumerable#grep_v — Suraj Kurapati <sunaku@...>
17 messages
2012/03/15
[#43325] [ruby-trunk - Bug #6154][Open] Eliminate extending WaitReadable/Writable at runtime — Charles Nutter <headius@...>
25 messages
2012/03/16
[#43326] [ruby-trunk - Bug #6154] Eliminate extending WaitReadable/Writable at runtime
— Charles Nutter <headius@...>
2012/03/16
[#43369] Re: [ruby-trunk - Bug #6154][Open] Eliminate extending WaitReadable/Writable at runtime
— Tanaka Akira <akr@...>
2012/03/17
2012/3/16 Charles Nutter <headius@headius.com>:
[#43334] [ruby-trunk - Bug #6155][Open] Enumerable::Lazy#flat_map raises an exception when an element does not respond to #each — Dan Kubb <dan.kubb@...>
9 messages
2012/03/16
[#43345] [ruby-trunk - Bug #6159][Open] Enumerable::Lazy#inspect — Benoit Daloze <redmine@...>
10 messages
2012/03/16
[#43497] [ruby-trunk - Bug #6179][Open] File::pos broken in Windows 1.9.3p125 — "jmthomas (Jason Thomas)" <jmthomas@...>
24 messages
2012/03/20
[#43502] [ruby-trunk - Feature #6180][Open] to_b for converting objects to a boolean value — "AaronLasseigne (Aaron Lasseigne)" <aaron.lasseigne@...>
17 messages
2012/03/20
[#43529] [ruby-trunk - Bug #6183][Open] Enumerator::Lazy performance issue — "gregolsen (Innokenty Mikhailov)" <anotheroneman@...>
36 messages
2012/03/21
[#43814] [ruby-trunk - Feature #6219][Open] Return value of Hash#store — "MartinBosslet (Martin Bosslet)" <Martin.Bosslet@...>
20 messages
2012/03/28
[#43904] [ruby-trunk - Feature #6225][Open] Hash#+ — "trans (Thomas Sawyer)" <transfire@...>
36 messages
2012/03/29
[#43909] [ruby-trunk - Feature #6225][Assigned] Hash#+
— "mame (Yusuke Endoh)" <mame@...>
2012/03/29
[#43923] [ruby-trunk - Feature #6225] Hash#+
— "shyouhei (Shyouhei Urabe)" <shyouhei@...>
2012/03/30
[#43951] [ruby-trunk - Bug #6228][Open] [mingw] Errno::EBADF in ruby/test_io.rb on ruby_1_9_3 — "jonforums (Jon Forums)" <redmine@...>
28 messages
2012/03/30
[#43996] [ruby-trunk - Bug #6236][Open] WEBrick::HTTPServer swallows Exception — "regularfry (Alex Young)" <alex@...>
13 messages
2012/03/31
[#44015] [Ruby 1.8 - Bug #6239][Open] super Does Not Pass Modified Rest Args When Originally Empty — "mudge (Paul Mucur)" <mudge@...>
6 messages
2012/03/31
[ruby-core:43817] [ruby-trunk - Feature #5741] Secure Erasure of Passwords
From:
"nobu (Nobuyoshi Nakada)" <nobu@...>
Date:
2012-03-28 21:38:59 UTC
List:
ruby-core #43817
Issue #5741 has been updated by nobu (Nobuyoshi Nakada). What kind of methods will be needed for "Secure Password", do you think? Is there any reason that it has to be real String instance? For example, I guess it should be BINARY or US-ASCII always, so shouldn't have encode method. sub string of it makes no sense, so no [], slice, and etc. sub, tr, upcase, et al too. Of course, to_sym must be prohibited as it makes the string permanent. ---------------------------------------- Feature #5741: Secure Erasure of Passwords https://bugs.ruby-lang.org/issues/5741#change-25321 Author: MartinBosslet (Martin Bosslet) Status: Assigned Priority: Normal Assignee: matz (Yukihiro Matsumoto) 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://bugs.ruby-lang.org/