[#101179] Spectre Mitigations — Amel <amel.smajic@...>
Hi there!
5 messages
2020/12/01
[#101180] Re: Spectre Mitigations
— Chris Seaton <chris@...>
2020/12/01
I wouldn’t recommend using Ruby to run in-process untrusted code in the first place. Are people doing that?
[#101694] Ruby 3.0.0 Released — "NARUSE, Yui" <naruse@...>
We are pleased to announce the release of Ruby 3.0.0. From 2015 we
4 messages
2020/12/25
[ruby-core:101192] [Ruby master Bug#17354] Module#const_source_location is misleading for constants awaiting autoload
From:
mail@...
Date:
2020-12-01 18:48:34 UTC
List:
ruby-core #101192
Issue #17354 has been updated by exterm (Philip Mテシller). While returning the location of the `autoload` definition _seems_ to make sense when used with a symbol literal (e.g. `autoload :Foo, './foo'`), I don't think it actually does. That location does not define a constant. This becomes painfully obvious when used with autoloaders like zeitwerk, where the constant name is in a variable, and not statically known. `Module.const_source_location` then points to a location that implements a general autoloading mechanism, which is not helpful at all. There is no mention of the constant in question at the location pointed to. I think this is not a weird edge case, but it actually makes perfect sense because `Module.const_source_location` actually does two completely different things. While it usually points to the location that a constant is defined at, in this case it does not and has completely different behavior. The only reason why that makes sense on the surface in my opinion is that `autoload :Foo` looks a little bit like a constant definition. But it is not one, so we should also not treat it as one. `Module.const_source_location` should return the same value for a not-yet-loaded constant that has an autoload defined as it does for a not-yet-loaded constant that does not have an autoload defined: `nil`. ---------------------------------------- Bug #17354: Module#const_source_location is misleading for constants awaiting autoload https://bugs.ruby-lang.org/issues/17354#change-88873 * Author: tomstuart (Tom Stuart) * Status: Open * Priority: Normal * ruby -v: ruby 2.7.2p137 (2020-10-01 revision 5445e04352) [x86_64-darwin20] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- Feature #10771 added `Module#const_source_location` as a way to find the source location of a constant窶冱 definition. Bug #16764 reported that it didn窶冲 work correctly for autoloaded constants, instead giving the source location of the `autoload` call site. This was fixed in `v3_0_0_preview1` in commit:92730810 and backported to `v2_7_2` in commit:c65aae11. However, `#const_source_location` still returns the `autoload` call site for constants which have not yet been loaded: ``` % echo 'class Foo; end' > foo.rb % irb >> Module.const_defined?(:Foo) => false >> Module.const_source_location(:Foo) => nil >> autoload :Foo, './foo' => nil >> Module.const_defined?(:Foo) => true >> Module.const_source_location(:Foo) => ["(irb)", 3] >> Module.const_get(:Foo) => Foo >> Module.const_defined?(:Foo) => true >> Module.const_source_location(:Foo) => ["./foo.rb", 1] ``` This edge case is undocumented and surprising. It looks like a bug to the programmer who receives the `autoload` location instead of one of the documented return values of `#const_source_location` (`nil`, `[]`, or the definition窶冱 source location). We could either: * change the behaviour of `#const_source_location` to return `[]` for constants awaiting autoload, which is consistent with the [return value of `Module#const_defined?`](https://docs.ruby-lang.org/en/2.7.0/Module.html#method-i-const_defined-3F) in this case (窶彿f the constant is not present but there is an autoload for it, `true` is returned directly窶, as well as the [return value of `#const_source_location`](https://docs.ruby-lang.org/en/2.7.0/Module.html#method-i-const_source_location) for other constants whose source location is unknown (“if the constant is found, but its source location can not be extracted (constant is defined in C code), empty array is returned”); or * document the current behaviour of `#const_source_location` to make it less surprising. I recommend the first option — although the current behaviour was recently specified in source:spec/ruby/core/module/const_source_location_spec.rb@6d059674#L209, it doesn’t seem intentional — but if that’s not feasible, simply documenting this edge case would also be an improvement. -- https://bugs.ruby-lang.org/ Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>