[#114062] [Ruby master Bug#19751] Ruby 3.2.2 Fails to Compile from Source — "martin_vahi (Martin Vahi) via ruby-core" <ruby-core@...>

Issue #19751 has been reported by martin_vahi (Martin Vahi).

9 messages 2023/07/01

[#114064] [Ruby master Feature#19752] Allow `--backtrace-limit` to appear in RUBYOPT — "tomstuart (Tom Stuart) via ruby-core" <ruby-core@...>

SXNzdWUgIzE5NzUyIGhhcyBiZWVuIHJlcG9ydGVkIGJ5IHRvbXN0dWFydCAoVG9tIFN0dWFydCku

8 messages 2023/07/01

[#114070] [Ruby master Bug#19753] IO::Buffer#get_string can't handle negative offset — "noteflakes (Sharon Rosner) via ruby-core" <ruby-core@...>

Issue #19753 has been reported by noteflakes (Sharon Rosner).

10 messages 2023/07/03

[#114072] [Ruby master Bug#19754] `IO::Buffer#get_string` raises unsuitable exception for too large offset — "nobu (Nobuyoshi Nakada) via ruby-core" <ruby-core@...>

Issue #19754 has been reported by nobu (Nobuyoshi Nakada).

7 messages 2023/07/03

[#114074] [Ruby master Feature#19755] Module#class_eval and Binding#eval use caller location by default — "byroot (Jean Boussier) via ruby-core" <ruby-core@...>

Issue #19755 has been reported by byroot (Jean Boussier).

15 messages 2023/07/03

[#114080] [Ruby master Bug#19756] URI::HTTP.build does not accept a host of `_gateway`, but `URI.parse` will. — "postmodern (Hal Brodigan) via ruby-core" <ruby-core@...>

Issue #19756 has been reported by postmodern (Hal Brodigan).

9 messages 2023/07/04

[#114168] [Ruby master Misc#19766] DevMeeting-2023-08-24 — "mame (Yusuke Endoh) via ruby-core" <ruby-core@...>

Issue #19766 has been reported by mame (Yusuke Endoh).

9 messages 2023/07/13

[#114222] [Ruby master Misc#19772] API Naming for YARP compiler — "jemmai (Jemma Issroff) via ruby-core" <ruby-core@...>

Issue #19772 has been reported by jemmai (Jemma Issroff).

31 messages 2023/07/17

[#114276] [Ruby master Bug#19784] String#delete_prefix! problem — "inversion (Yura Babak) via ruby-core" <ruby-core@...>

Issue #19784 has been reported by inversion (Yura Babak).

10 messages 2023/07/25

[#114309] [Ruby master Feature#19787] Add Enumerable#uniq_map, Enumerable::Lazy#uniq_map, Array#uniq_map and Array#uniq_map! — "joshuay03 (Joshua Young) via ruby-core" <ruby-core@...>

Issue #19787 has been reported by joshuay03 (Joshua Young).

7 messages 2023/07/29

[#114319] [Ruby master Feature#19790] Optionally write Ruby crash reports into a file rather than STDERR — "byroot (Jean Boussier) via ruby-core" <ruby-core@...>

SXNzdWUgIzE5NzkwIGhhcyBiZWVuIHJlcG9ydGVkIGJ5IGJ5cm9vdCAoSmVhbiBCb3Vzc2llciku

13 messages 2023/07/31

[ruby-core:114244] [Ruby master Feature#19720] Warning for non-linear Regexps

From: "Eregon (Benoit Daloze) via ruby-core" <ruby-core@...>
Date: 2023-07-20 09:24:51 UTC
List: ruby-core #114244
Issue #19720 has been updated by Eregon (Benoit Daloze).


@matz Given ReDoS are AFAIK the most common (by far) security vulnerability in Ruby, it warrants a reliable way to detect it, fix it and avoid it.
This way seems the best to me.
In fact I think only this approach or something very similar would be able to truly address ReDoS in Ruby.

For instance https://www.ruby-lang.org/en/news/ shows there were 3 ReDoS in stdlib in just 3 months (28 March - 29 June).

The warning would be opt-in, like performance warnings, so it would not be disruptive.

For gem (and app) maintainers which care about security, I think it would make sense to enable the warning and potentially customize `Warning.warn` for the :regexp category to `raise` (as shown in description).
That would discourage gems to use these often unsafe and non-linear regexp features.
I think this is exactly what we want for the Ruby community to solve this very frequent and serious security problem.

People can still use back references (or other extended regexp) features in their local scripts/programs if they like, and it won't even warn them unless they choose to enable regexp warnings.

BTW the exact list of features not supported is at https://bugs.ruby-lang.org/issues/19104#note-3
I believe these Regexp features are not necessary for 99+% gems, and not using them is by far the easiest way to guarantee no ReDoS is possible.
As we know, it's very very hard to estimate if a Regexp is susceptible to ReDoS if it's not detected as linear by the regexp engine (IOW it's very easy for programmers to accidentally write a non-linear regexp without the help of this warning).

@matz Could you reconsider? Maybe I should attend a dev meeting to understand what are the concerns about this feature?

----------------------------------------
Feature #19720: Warning for non-linear Regexps
https://bugs.ruby-lang.org/issues/19720#change-103932

* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
----------------------------------------
I believe the best way to solve ReDoS is to ensure all Regexps used in the process are linear.
Using `Regexp.timeout = 5.0` or so does not really prevent ReDoS, given enough requests causing that timeout the servers will still be very unresponsive.

To this purpose, we should make it easy to identify non-linear Regexps and fix them.

I suggest we either use
1. a performance warning (enabled with `Warning[:performance] = true`, #19538) or
2. a new regexp warning category (enabled with `Warning[:regexp] = true`).

I think we should warn only once per non-linear Regexp, to avoid too many such warnings.
We could warn as soon as the Regexp is created, or on first match.
On first match might makes more sense for Ruby implementations which compile the Regexp lazily (since that is costly during startup), and also avoids warning for Regexps which are never used (which can be good or bad).
OTOH, if the warning is enabled, we could always compile the Regexp eagerly (or at least checks whether it's linear), and that would then provide a better way to guarantee that all Regexps created so far are linear.

Because warnings are easily customizable, it is also possible to e.g. `raise/abort` on such a warning, if one wants to ensure their application does not use a non-linear Regexp and so cannot be vulnerable to ReDoS:
```ruby
Warning.extend Module.new {
  def warn(message, category: nil, **)
    raise message if category == :regexp
    super
  end
}
```
A regexp warning category seems better for that as it makes it easy to filter by category, if a performance warning one would need to match the message which is less clean.

As a note, TruffleRuby already has a similar warning, as a command-line option:
```
$ truffleruby --experimental-options --warn-truffle-regex-compile-fallback -e 'Gem'
truffleruby-dev/lib/mri/rubygems/version.rb:176: warning: Regexp /\A\s*([0-9]+(?>\.[0-9a-zA-Z]+)*(-[0-9A-Za-z-]+(\.[0-9A-Za-z-]+)*)?)?\s*\z/ at_start=false encoding=US-ASCII requires backtracking and will not match in linear time
truffleruby-dev/lib/mri/rubygems/requirement.rb:105: warning: Regexp /\A\s*(=|!=|>|<|>=|<=|~>)?\s*([0-9]+(?>\.[0-9a-zA-Z]+)*(-[0-9A-Za-z-]+(\.[0-9A-Za-z-]+)*)?)\s*\z/ at_start=false encoding=US-ASCII requires backtracking and will not match in linear time
```

So the warning message could be like
`FILE:LINE: warning: Regexp /REGEXP/ requires backtracking and might not match in linear time and might cause ReDoS`
or more concise:
`FILE:LINE: warning: Regexp /REGEXP/ requires backtracking and might cause ReDoS`



-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/

In This Thread