Advisory: CVE-2017-8418

Criticality: Low

URL: https://github.com/bbatsov/rubocop/issues/4336

Solution: upgrade to >= 0.49.0

Advisory: CVE-2014-10077

URL: https://github.com/svenfuchs/i18n/pull/289

Solution: upgrade to >= 0.8.0

Advisory: CVE-2019-16779

Criticality: Medium

URL: https://github.com/excon/excon/security/advisories/GHSA-q58g-455p-8vw9

Solution: upgrade to >= 0.71.0

Advisory: CVE-2020-10663

Criticality: High

URL: https://www.ruby-lang.org/en/news/2020/03/19/json-dos-cve-2020-10663/

Solution: upgrade to >= 2.3.0

Advisory: CVE-2023-22796

URL: https://github.com/rails/rails/releases/tag/v7.0.4.1

Solution: upgrade to >= 5.2.8.15, ~> 5.2.8, >= 6.1.7.1, ~> 6.1.7, >= 7.0.4.1

Advisory: CVE-2020-8165

Criticality: Critical

URL: https://groups.google.com/forum/#!topic/rubyonrails-security/bv6fW4S0Y1c

Solution: upgrade to >= 5.2.4.3, ~> 5.2.4, >= 6.0.3.1

Cognitive Complexity

Cognitive Complexity is a measure of how difficult a unit of code is to intuitively understand. Unlike Cyclomatic Complexity, which determines how difficult your code will be to test, Cognitive Complexity tells you how difficult your code will be to read and comprehend.

A method's cognitive complexity is based on a few simple rules:

• Code is not considered more complex when it uses shorthand that the language provides for collapsing multiple statements into one
• Code is considered more complex for each "break in the linear flow of the code"
• Code is considered more complex when "flow breaking structures are nested"

Further reading

• Cognitive Complexity docs
• Cognitive Complexity: A new way of measuring understandability

This cop checks if the length of a block exceeds some maximum value. Comment lines can optionally be ignored. The maximum allowed length is configurable. The cop can be configured to ignore blocks passed to certain methods.

Advisory: CVE-2022-31163

Criticality: High

URL: https://github.com/tzinfo/tzinfo/security/advisories/GHSA-5cm2-9h8c-rvfx

Solution: upgrade to ~> 0.3.61, >= 1.2.10

Gems should be alphabetically sorted within groups.

Example:

# bad
gem 'rubocop'
gem 'rspec'

# good
gem 'rspec'
gem 'rubocop'

# good
gem 'rubocop'

gem 'rspec'

# good only if TreatCommentsAsGroupSeparators is true
# For code quality
gem 'rubocop'
# For tests
gem 'rspec'

Gems should be alphabetically sorted within groups.

Example:

# bad
gem 'rubocop'
gem 'rspec'

# good
gem 'rspec'
gem 'rubocop'

# good
gem 'rubocop'

gem 'rspec'

# good only if TreatCommentsAsGroupSeparators is true
# For code quality
gem 'rubocop'
# For tests
gem 'rspec'

This cop checks for the formatting of empty method definitions. By default it enforces empty method definitions to go on a single line (compact style), but it can be configured to enforce the end to go on its own line (expanded style).

Note: A method definition is not considered empty if it contains comments.

Example: EnforcedStyle: compact (default)

# bad
def foo(bar)
end

def self.foo(bar)
end

# good
def foo(bar); end

def foo(bar)
  # baz
end

def self.foo(bar); end

Example: EnforcedStyle: expanded

# bad
def foo(bar); end

def self.foo(bar); end

# good
def foo(bar)
end

def self.foo(bar)
end

This cops checks the indentation of the here document bodies. The bodies are indented one step. In Ruby 2.3 or newer, squiggly heredocs (<<~) should be used. If you use the older rubies, you should introduce some library to your project (e.g. ActiveSupport, Powerpack or Unindent). Note: When Metrics/LineLength's AllowHeredoc is false(not default), this cop does not add any offenses for long here documents to avoid Metrics/LineLength's offenses.

Example:

# bad
<<-RUBY
something
RUBY

# good
# When EnforcedStyle is squiggly, bad code is auto-corrected to the
# following code.
<<~RUBY
  something
RUBY

# good
# When EnforcedStyle is active_support, bad code is auto-corrected to
# the following code.
<<-RUBY.strip_heredoc
  something
RUBY