[#47787] Ruby Parallelism — Miguel Palhas <mpalhas@...>
Greetings
[#47790] [ruby-trunk - Bug #7097][Open] Thread locals don't work inside Enumerator — "tenderlovemaking (Aaron Patterson)" <aaron@...>
I don't have any objection.
On Fri, Oct 26, 2012 at 02:40:53PM +0900, SASADA Koichi wrote:
On Tue, Oct 02, 2012 at 03:05:17AM +0900, kosaki (Motohiro KOSAKI) wrote:
(2012/10/02 3:12), Aaron Patterson wrote:
(2012/10/02 8:22), SASADA Koichi wrote:
On Tue, Oct 02, 2012 at 08:32:51AM +0900, SASADA Koichi wrote:
>> For example:
[#47832] [ruby-trunk - Feature #7106][Open] FileUtils.touch should allow touching the symlink itself rather than the file the link points to — "cirrusthinking (Alessandro Diaferia)" <alessandro@...>
[#47841] [ruby-trunk - Bug #7109][Open] File.utime doesn't set nanoseconds — "bkabrda (Bohuslav Kabrda)" <bkabrda@...>
2012/10/5 bkabrda (Bohuslav Kabrda) <bkabrda@redhat.com>:
[#47847] [ruby-trunk - Bug #7110][Open] CGI: Add support for HTML5 <header> tag — "stomar (Marcus Stollsteimer)" <redmine@...>
[#47880] [ruby-trunk - Bug #7134][Open] Signal handling bug in Mac OS X — "auastro (Andy Kitchen)" <kitchen.andy+rubybug@...>
[#47881] [ruby-trunk - Bug #7135][Open] GC bug in Ruby 1.9.3-p194? — "alexdowad (Alex Dowad)" <alexinbeijing@...>
[#47887] [ruby-trunk - Bug #7137][Open] Date.parse overly lenient when attempting to parse Monday? — "garysweaver (Gary Weaver)" <garysweaver@...>
[#47927] new ruby 1.9.3 maintainer — "U.Nakamura" <usa@...>
Hello everyone of the Ruby development community
[#47930] [ruby-trunk - Feature #7148][Open] Improved Tempfile w/o DelegateClass — "Glass_saga (Masaki Matsushita)" <glass.saga@...>
[#47963] [ruby-trunk - Bug #7154][Open] For whatever reason \s doesn't match \u00a0. — "t0d0r (Todor Dragnev)" <todor.dragnev@...>
[#47970] [ruby-trunk - Bug #7158][Open] require is slow in its bookkeeping; can make Rails startup 2.2x faster — "gregprice (Greg Price)" <price@...>
(2012/10/28 7:10), h.shirosaki (Hiroshi Shirosaki) wrote:
Thank you for the careful work.
[#48032] [Backport93 - Backport #7174][Open] Advocating for backporting 36811 — "jonforums (Jon Forums)" <redmine@...>
[#48040] Should Hash#dup automatically rehash — Aaron Patterson <tenderlove@...>
Hi,
Hello,
On Wed, Oct 17, 2012 at 11:21:15AM +0900, U.Nakamura wrote:
[#48072] [ruby-trunk - Bug #7184][Open] --disable-gems commandline parameter does not show up with ruby -h — "steenslag (siep korteling)" <s.korteling@...>
[#48132] [ruby-trunk - Bug #7201][Open] Setting default_external affects STDIN encoding but default_internal does not — "brixen (Brian Ford)" <brixen@...>
[#48154] Patch to test_ssl to validate server-side support for SNI — Patrick Toomey <ptoomey3@...>
I recently made a pull request to JRuby (
We have incorporated Patrick's SNI patch for upcoming release JRuby
[#48191] [ANN] 2.0.0 feature freeze — Yusuke Endoh <mame@...>
Japanese later; 日本語は後で
Em 24-10-2012 09:39, Yusuke Endoh escreveu:
(2012/10/24 5:39), Yusuke Endoh wrote:
Hello ko1,
Hi,
AFAIK matz has not accepted #6636 completely yet.
Sorry, late to the party, but what's the status of #6679?
What status of #6638 <https://bugs.ruby-lang.org/issues/6638>
[#48260] [ruby-trunk - Bug #7214][Open] Ruby 2.0 breaks support for some debugging tools — "banister (john mair)" <jrmair@...>
[#48292] [ruby-trunk - Bug #7216][Open] object.c defines clone method for objects that cannot be cloned. — "therevmj (Michael Johnson)" <mj@...>
[#48315] [ruby-trunk - Bug #7220][Open] StringIO#initialize_copy causes aliasing between the objects — "brixen (Brian Ford)" <brixen@...>
[#48475] [ruby-trunk - Feature #3222] Can bignums have singleton class & methods? — "matz (Yukihiro Matsumoto)" <matz@...>
(2012/10/27 23:25), matz (Yukihiro Matsumoto) wrote:
[#48551] [ruby-trunk - Feature #7241][Open] Enumerable#to_h proposal — "nathan.f77 (Nathan Broadbent)" <nathan.f77@...>
On Tue, Oct 30, 2012 at 07:58:33PM +0900, rosenfeld (Rodrigo Rosenfeld Rosas) wrote:
Em 30-10-2012 16:23, Aaron Patterson escreveu:
[#48679] [ruby-trunk - Feature #905] Add String.new(fixnum) to preallocate large buffer — "headius (Charles Nutter)" <headius@...>
[ruby-core:48361] [ruby-trunk - Feature #5741] Secure Erasure of Passwords
Issue #5741 has been updated by ko1 (Koichi Sasada). ping. status? I think matz doesn't know this ticket. Could someone grab this ticket? ---------------------------------------- Feature #5741: Secure Erasure of Passwords https://bugs.ruby-lang.org/issues/5741#change-31672 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/