Showing 102 of 102 total issues
ruby-ffi DDL loading issue on Windows OS Open
ffi (1.9.18)
- Read upRead up
- Exclude checks
Advisory: CVE-2018-1000201
Criticality: High
URL: https://github.com/ffi/ffi/releases/tag/1.9.24
Solution: upgrade to >= 1.9.24
Revert libxml2 behavior in Nokogiri gem that could cause XSS Open
nokogiri (1.8.2)
- Read upRead up
- Exclude checks
Advisory: CVE-2018-8048
URL: https://github.com/sparklemotion/nokogiri/pull/1746
Solution: upgrade to >= 1.8.3
OS Command Injection in Rake Open
rake (12.3.1)
- Read upRead up
- Exclude checks
Advisory: CVE-2020-8130
Criticality: High
URL: https://github.com/advisories/GHSA-jppv-gw3r-w3q8
Solution: upgrade to >= 12.3.3
Denial of Service Vulnerability in Rack Multipart Parsing Open
rack (2.0.5)
- Read upRead up
- Exclude checks
Advisory: CVE-2022-30122
Criticality: High
URL: https://groups.google.com/g/ruby-security-ann/c/L2Axto442qk
Solution: upgrade to >= 2.0.9.1, ~> 2.0.9, >= 2.1.4.1, ~> 2.1.4, >= 2.2.3.1
Possible DoS vulnerability in Rack Open
rack (2.0.5)
- Read upRead up
- Exclude checks
Advisory: CVE-2018-16470
URL: https://groups.google.com/forum/#!topic/ruby-security-ann/Dz4sRl-ktKk
Solution: upgrade to >= 2.0.6
Denial of service via header parsing in Rack Open
rack (2.0.5)
- Read upRead up
- Exclude checks
Advisory: CVE-2022-44570
URL: https://github.com/rack/rack/releases/tag/v3.0.4.1
Solution: upgrade to >= 2.0.9.2, ~> 2.0.9, >= 2.1.4.2, ~> 2.1.4, >= 2.2.6.2, ~> 2.2.6, >= 3.0.4.1
TZInfo relative path traversal vulnerability allows loading of arbitrary files Open
tzinfo (1.2.5)
- Read upRead up
- Exclude checks
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
Regular Expression Denial of Service in websocket-extensions (RubyGem) Open
websocket-extensions (0.1.3)
- Read upRead up
- Exclude checks
Advisory: CVE-2020-7663
Criticality: High
URL: https://github.com/faye/websocket-extensions-ruby/security/advisories/GHSA-g6wq-qcwm-j5g2
Solution: upgrade to >= 0.1.5
Nokogiri gem, via libxml2, is affected by multiple vulnerabilities Open
nokogiri (1.8.2)
- Read upRead up
- Exclude checks
Advisory: CVE-2018-14404
Criticality: High
URL: https://github.com/sparklemotion/nokogiri/issues/1785
Solution: upgrade to >= 1.8.5
Possible shell escape sequence injection vulnerability in Rack Open
rack (2.0.5)
- Read upRead up
- Exclude checks
Advisory: CVE-2022-30123
Criticality: Critical
URL: https://groups.google.com/g/ruby-security-ann/c/LWB10kWzag8
Solution: upgrade to >= 2.0.9.1, ~> 2.0.9, >= 2.1.4.1, ~> 2.1.4, >= 2.2.3.1
Api::V1::AuthsController has no descriptive comment Open
class AuthsController < ApplicationController
- Read upRead up
- Exclude checks
Classes and modules are the units of reuse and release. It is therefore considered good practice to annotate every class and module with a brief comment outlining its responsibilities.
Example
Given
class Dummy
# Do things...
end
Reek would emit the following warning:
test.rb -- 1 warning:
[1]:Dummy has no descriptive comment (IrresponsibleModule)
Fixing this is simple - just an explaining comment:
# The Dummy class is responsible for ...
class Dummy
# Do things...
end
Api::V1::BooksController assumes too much for instance variable '@book' Open
class BooksController < ApplicationController
- Read upRead up
- Exclude checks
Classes should not assume that instance variables are set or present outside of the current class definition.
Good:
class Foo
def initialize
@bar = :foo
end
def foo?
@bar == :foo
end
end
Good as well:
class Foo
def foo?
bar == :foo
end
def bar
@bar ||= :foo
end
end
Bad:
class Foo
def go_foo!
@bar = :foo
end
def foo?
@bar == :foo
end
end
Example
Running Reek on:
class Dummy
def test
@ivar
end
end
would report:
[1]:InstanceVariableAssumption: Dummy assumes too much for instance variable @ivar
Note that this example would trigger this smell warning as well:
class Parent
def initialize(omg)
@omg = omg
end
end
class Child < Parent
def foo
@omg
end
end
The way to address the smell warning is that you should create an attr_reader
to use @omg
in the subclass and not access @omg
directly like this:
class Parent
attr_reader :omg
def initialize(omg)
@omg = omg
end
end
class Child < Parent
def foo
omg
end
end
Directly accessing instance variables is considered a smell because it breaks encapsulation and makes it harder to reason about code.
If you don't want to expose those methods as public API just make them private like this:
class Parent
def initialize(omg)
@omg = omg
end
private
attr_reader :omg
end
class Child < Parent
def foo
omg
end
end
Current Support in Reek
An instance variable must:
- be set in the constructor
- or be accessed through a method with lazy initialization / memoization.
If not, Instance Variable Assumption will be reported.
Api::V1::AuthorsController assumes too much for instance variable '@author' Open
class AuthorsController < ApplicationController
- Read upRead up
- Exclude checks
Classes should not assume that instance variables are set or present outside of the current class definition.
Good:
class Foo
def initialize
@bar = :foo
end
def foo?
@bar == :foo
end
end
Good as well:
class Foo
def foo?
bar == :foo
end
def bar
@bar ||= :foo
end
end
Bad:
class Foo
def go_foo!
@bar = :foo
end
def foo?
@bar == :foo
end
end
Example
Running Reek on:
class Dummy
def test
@ivar
end
end
would report:
[1]:InstanceVariableAssumption: Dummy assumes too much for instance variable @ivar
Note that this example would trigger this smell warning as well:
class Parent
def initialize(omg)
@omg = omg
end
end
class Child < Parent
def foo
@omg
end
end
The way to address the smell warning is that you should create an attr_reader
to use @omg
in the subclass and not access @omg
directly like this:
class Parent
attr_reader :omg
def initialize(omg)
@omg = omg
end
end
class Child < Parent
def foo
omg
end
end
Directly accessing instance variables is considered a smell because it breaks encapsulation and makes it harder to reason about code.
If you don't want to expose those methods as public API just make them private like this:
class Parent
def initialize(omg)
@omg = omg
end
private
attr_reader :omg
end
class Child < Parent
def foo
omg
end
end
Current Support in Reek
An instance variable must:
- be set in the constructor
- or be accessed through a method with lazy initialization / memoization.
If not, Instance Variable Assumption will be reported.
Api::V1::AuthorsController has no descriptive comment Open
class AuthorsController < ApplicationController
- Read upRead up
- Exclude checks
Classes and modules are the units of reuse and release. It is therefore considered good practice to annotate every class and module with a brief comment outlining its responsibilities.
Example
Given
class Dummy
# Do things...
end
Reek would emit the following warning:
test.rb -- 1 warning:
[1]:Dummy has no descriptive comment (IrresponsibleModule)
Fixing this is simple - just an explaining comment:
# The Dummy class is responsible for ...
class Dummy
# Do things...
end
ApplicationController has no descriptive comment Open
class ApplicationController < ActionController::API
- Read upRead up
- Exclude checks
Classes and modules are the units of reuse and release. It is therefore considered good practice to annotate every class and module with a brief comment outlining its responsibilities.
Example
Given
class Dummy
# Do things...
end
Reek would emit the following warning:
test.rb -- 1 warning:
[1]:Dummy has no descriptive comment (IrresponsibleModule)
Fixing this is simple - just an explaining comment:
# The Dummy class is responsible for ...
class Dummy
# Do things...
end
Api::V1::BooksController assumes too much for instance variable '@author' Open
class BooksController < ApplicationController
- Read upRead up
- Exclude checks
Classes should not assume that instance variables are set or present outside of the current class definition.
Good:
class Foo
def initialize
@bar = :foo
end
def foo?
@bar == :foo
end
end
Good as well:
class Foo
def foo?
bar == :foo
end
def bar
@bar ||= :foo
end
end
Bad:
class Foo
def go_foo!
@bar = :foo
end
def foo?
@bar == :foo
end
end
Example
Running Reek on:
class Dummy
def test
@ivar
end
end
would report:
[1]:InstanceVariableAssumption: Dummy assumes too much for instance variable @ivar
Note that this example would trigger this smell warning as well:
class Parent
def initialize(omg)
@omg = omg
end
end
class Child < Parent
def foo
@omg
end
end
The way to address the smell warning is that you should create an attr_reader
to use @omg
in the subclass and not access @omg
directly like this:
class Parent
attr_reader :omg
def initialize(omg)
@omg = omg
end
end
class Child < Parent
def foo
omg
end
end
Directly accessing instance variables is considered a smell because it breaks encapsulation and makes it harder to reason about code.
If you don't want to expose those methods as public API just make them private like this:
class Parent
def initialize(omg)
@omg = omg
end
private
attr_reader :omg
end
class Child < Parent
def foo
omg
end
end
Current Support in Reek
An instance variable must:
- be set in the constructor
- or be accessed through a method with lazy initialization / memoization.
If not, Instance Variable Assumption will be reported.
Api::V1::BooksController assumes too much for instance variable '@books' Open
class BooksController < ApplicationController
- Read upRead up
- Exclude checks
Classes should not assume that instance variables are set or present outside of the current class definition.
Good:
class Foo
def initialize
@bar = :foo
end
def foo?
@bar == :foo
end
end
Good as well:
class Foo
def foo?
bar == :foo
end
def bar
@bar ||= :foo
end
end
Bad:
class Foo
def go_foo!
@bar = :foo
end
def foo?
@bar == :foo
end
end
Example
Running Reek on:
class Dummy
def test
@ivar
end
end
would report:
[1]:InstanceVariableAssumption: Dummy assumes too much for instance variable @ivar
Note that this example would trigger this smell warning as well:
class Parent
def initialize(omg)
@omg = omg
end
end
class Child < Parent
def foo
@omg
end
end
The way to address the smell warning is that you should create an attr_reader
to use @omg
in the subclass and not access @omg
directly like this:
class Parent
attr_reader :omg
def initialize(omg)
@omg = omg
end
end
class Child < Parent
def foo
omg
end
end
Directly accessing instance variables is considered a smell because it breaks encapsulation and makes it harder to reason about code.
If you don't want to expose those methods as public API just make them private like this:
class Parent
def initialize(omg)
@omg = omg
end
private
attr_reader :omg
end
class Child < Parent
def foo
omg
end
end
Current Support in Reek
An instance variable must:
- be set in the constructor
- or be accessed through a method with lazy initialization / memoization.
If not, Instance Variable Assumption will be reported.
JwtService has no descriptive comment Open
class JwtService
- Read upRead up
- Exclude checks
Classes and modules are the units of reuse and release. It is therefore considered good practice to annotate every class and module with a brief comment outlining its responsibilities.
Example
Given
class Dummy
# Do things...
end
Reek would emit the following warning:
test.rb -- 1 warning:
[1]:Dummy has no descriptive comment (IrresponsibleModule)
Fixing this is simple - just an explaining comment:
# The Dummy class is responsible for ...
class Dummy
# Do things...
end
AuthenticateUserCommand has no descriptive comment Open
class AuthenticateUserCommand < BaseCommand
- Read upRead up
- Exclude checks
Classes and modules are the units of reuse and release. It is therefore considered good practice to annotate every class and module with a brief comment outlining its responsibilities.
Example
Given
class Dummy
# Do things...
end
Reek would emit the following warning:
test.rb -- 1 warning:
[1]:Dummy has no descriptive comment (IrresponsibleModule)
Fixing this is simple - just an explaining comment:
# The Dummy class is responsible for ...
class Dummy
# Do things...
end
BaseCommand has no descriptive comment Open
class BaseCommand
- Read upRead up
- Exclude checks
Classes and modules are the units of reuse and release. It is therefore considered good practice to annotate every class and module with a brief comment outlining its responsibilities.
Example
Given
class Dummy
# Do things...
end
Reek would emit the following warning:
test.rb -- 1 warning:
[1]:Dummy has no descriptive comment (IrresponsibleModule)
Fixing this is simple - just an explaining comment:
# The Dummy class is responsible for ...
class Dummy
# Do things...
end