rike422/loose-leaf

View on GitHub

Showing 119 of 119 total issues

ruby-ffi DDL loading issue on Windows OS
Open

    ffi (1.9.14)
Severity: Critical
Found in Gemfile.lock by bundler-audit

Advisory: CVE-2018-1000201

Criticality: High

URL: https://github.com/ffi/ffi/releases/tag/1.9.24

Solution: upgrade to >= 1.9.24

Path Traversal in Sprockets
Open

    sprockets (3.7.0)
Severity: Critical
Found in Gemfile.lock by bundler-audit

Advisory: CVE-2018-3760

Criticality: High

URL: https://groups.google.com/forum/#!topic/ruby-security-ann/2S9Pwz2i16k

Solution: upgrade to < 3.0.0, >= 2.12.5, < 4.0.0, >= 3.7.2, >= 4.0.0.beta8

Regular Expression Denial of Service in websocket-extensions (RubyGem)
Open

    websocket-extensions (0.1.2)
Severity: Critical
Found in Gemfile.lock by bundler-audit

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

File Content Disclosure in Action View
Open

    actionview (5.0.0.1)
Severity: Critical
Found in Gemfile.lock by bundler-audit

Advisory: CVE-2019-5418

Criticality: High

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

Solution: upgrade to >= 4.2.11.1, ~> 4.2.11, >= 5.0.7.2, ~> 5.0.7, >= 5.1.6.2, ~> 5.1.6, >= 5.2.2.1, ~> 5.2.2, >= 6.0.0.beta3

Denial of service via header parsing in Rack
Open

    rack (2.0.1)
Severity: Minor
Found in Gemfile.lock by bundler-audit

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

Possible shell escape sequence injection vulnerability in Rack
Open

    rack (2.0.1)
Severity: Minor
Found in Gemfile.lock by bundler-audit

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

Denial of Service Vulnerability in Action View
Open

    actionview (5.0.0.1)
Severity: Critical
Found in Gemfile.lock by bundler-audit

Advisory: CVE-2019-5419

Criticality: High

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

Solution: upgrade to >= 6.0.0.beta3, >= 5.2.2.1, ~> 5.2.2, >= 5.1.6.2, ~> 5.1.6, >= 5.0.7.2, ~> 5.0.7, >= 4.2.11.1, ~> 4.2.11

Denial of Service Vulnerability in Rack Multipart Parsing
Open

    rack (2.0.1)
Severity: Critical
Found in Gemfile.lock by bundler-audit

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

XSS vulnerability in rails-html-sanitizer
Open

    rails-html-sanitizer (1.0.3)
Severity: Minor
Found in Gemfile.lock by bundler-audit

Advisory: CVE-2018-3741

URL: https://groups.google.com/d/msg/rubyonrails-security/tP7W3kLc5u4/uDy2Br7xBgAJ

Solution: upgrade to >= 1.0.4

Arbitrary path traversal and file access via yard server
Open

    yard (0.9.5)
Severity: Critical
Found in Gemfile.lock by bundler-audit

Advisory: CVE-2019-1020001

Criticality: High

URL: https://github.com/lsegal/yard/security/advisories/GHSA-xfhh-rx56-rxcr

Solution: upgrade to >= 0.9.20

Method symbolize_keys has a Cognitive Complexity of 7 (exceeds 5 allowed). Consider refactoring.
Open

    def symbolize_keys(hash)
      hash.each_with_object({}) do |(key, value), new_hash|
        new_key = key.is_a?(String) ? key.to_sym : key
        new_value = value.is_a?(Hash) ? symbolize_keys(value) : value
        new_hash[new_key] = new_value
Severity: Minor
Found in rakelib/task_helpers.rb - About 35 mins to fix

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

'protect_from_forgery' should be called in LooseLeaf::ApplicationController
Open

  class ApplicationController < ActionController::Base

Cross-site request forgery is #5 on the OWASP Top Ten. CSRF allows an attacker to perform actions on a website as if they are an authenticated user.

This warning is raised when no call to protect_from_forgery is found in ApplicationController. This method prevents CSRF.

For Rails 4 applications, it is recommended that you use protect_from_forgery :with => :exception. This code is inserted into newly generated applications. The default is to nil out the session object, which has been a source of many CSRF bypasses due to session memoization.

See the Ruby Security Guide for details.

rails-html-sanitizer 1.0.3 is vulnerable (CVE-2018-3741). Upgrade to 1.0.4
Open

    rails-html-sanitizer (1.0.3)
Severity: Minor
Found in Gemfile.lock by brakeman

Loofah 2.0.3 is vulnerable (CVE-2018-8048). Upgrade to 2.1.2
Open

    loofah (2.0.3)
Severity: Minor
Found in Gemfile.lock by brakeman

Favor modifier unless usage when having a single-line body. Another good alternative is the usage of control flow &&/||.
Open

      unless client_version > version

Checks for if and unless statements that would fit on one line if written as a modifier if/unless. The maximum line length is configured in the Metrics/LineLength cop.

Example:

# bad
if condition
  do_stuff(bar)
end

unless qux.empty?
  Foo.do_something
end

# good
do_stuff(bar) if condition
Foo.do_something unless qux.empty?

Read-only global 'process' should not be modified.
Open

process = require('process')
Severity: Minor
Found in client/webpack.config.js by eslint

Disallow assignment to native objects or read-only global variables (no-global-assign)

JavaScript environments contain a number of built-in global variables, such as window in browsers and process in Node.js. In almost all cases, you don't want to assign a value to these global variables as doing so could result in losing access to important functionality. For example, you probably don't want to do this in browser code:

window = {};

While examples such as window are obvious, there are often hundreds of built-in global objects provided by JavaScript environments. It can be hard to know if you're assigning to a global variable or not.

Rule Details

This rule disallows modifications to read-only global variables.

ESLint has the capability to configure global variables as read-only.

  • [Specifying Environments](../user-guide/configuring#specifying-environments)
  • [Specifying Globals](../user-guide/configuring#specifying-globals)

Examples of incorrect code for this rule:

/*eslint no-global-assign: "error"*/

Object = null
undefined = 1
/*eslint no-global-assign: "error"*/
/*eslint-env browser*/

window = {}
length = 1
top = 1
/*eslint no-global-assign: "error"*/
/*globals a:false*/

a = 1

Examples of correct code for this rule:

/*eslint no-global-assign: "error"*/

a = 1
var b = 1
b = 2
/*eslint no-global-assign: "error"*/
/*eslint-env browser*/

onload = function() {}
/*eslint no-global-assign: "error"*/
/*globals a:true*/

a = 1

Options

This rule accepts an exceptions option, which can be used to specify a list of builtins for which reassignments will be allowed:

{
    "rules": {
        "no-global-assign": ["error", {"exceptions": ["Object"]}]
    }
}

When Not To Use It

If you are trying to override one of the native objects.

Related Rules

Block must not be padded by blank lines.
Open

export default class TextAreaAdapter {

require or disallow padding within blocks (padded-blocks)

Some style guides require block statements to start and end with blank lines. The goal is to improve readability by visually separating the block content and the surrounding code.

if (a) {

    b();

}

Since it's good to have a consistent code style, you should either always write padded blocks or never do it.

Rule Details

This rule enforces consistent empty line padding within blocks.

Options

This rule has one option, which can be a string option or an object option.

String option:

  • "always" (default) requires empty lines at the beginning and ending of block statements (except switch statements and classes)
  • "never" disallows empty lines at the beginning and ending of block statements (except switch statements and classes)

Object option:

  • "blocks" require or disallow padding within block statements
  • "classes" require or disallow padding within classes
  • "switches" require or disallow padding within switch statements

always

Examples of incorrect code for this rule with the default "always" option:

/*eslint padded-blocks: ["error", "always"]*/

if (a) {
    b();
}

if (a) { b(); }

if (a)
{
    b();
}

if (a) {

    b();
}

if (a) {
    b();

}

if (a) {
    // comment
    b();

}

Examples of correct code for this rule with the default "always" option:

/*eslint padded-blocks: ["error", "always"]*/

if (a) {

    b();

}

if (a)
{

    b();

}

if (a) {

    // comment
    b();

}

never

Examples of incorrect code for this rule with the "never" option:

/*eslint padded-blocks: ["error", "never"]*/

if (a) {

    b();

}

if (a)
{

    b();

}

if (a) {

    b();
}

if (a) {
    b();

}

Examples of correct code for this rule with the "never" option:

/*eslint padded-blocks: ["error", "never"]*/

if (a) {
    b();
}

if (a)
{
    b();
}

blocks

Examples of incorrect code for this rule with the { "blocks": "always" } option:

/*eslint padded-blocks: ["error", { "blocks": "always" }]*/

if (a) {
    b();
}

if (a) { b(); }

if (a)
{
    b();
}

if (a) {

    b();
}

if (a) {
    b();

}

if (a) {
    // comment
    b();

}

Examples of correct code for this rule with the { "blocks": "always" } option:

/*eslint padded-blocks: ["error", { "blocks": "always" }]*/

if (a) {

    b();

}

if (a)
{

    b();

}

if (a) {

    // comment
    b();

}

Examples of incorrect code for this rule with the { "blocks": "never" } option:

/*eslint padded-blocks: ["error", { "blocks": "never" }]*/

if (a) {

    b();

}

if (a)
{

    b();

}

if (a) {

    b();
}

if (a) {
    b();

}

Examples of correct code for this rule with the { "blocks": "never" } option:

/*eslint padded-blocks: ["error", { "blocks": "never" }]*/

if (a) {
    b();
}

if (a)
{
    b();
}

classes

Examples of incorrect code for this rule with the { "classes": "always" } option:

/*eslint padded-blocks: ["error", { "classes": "always" }]*/

class  A {
    constructor(){
    }
}

Examples of correct code for this rule with the { "classes": "always" } option:

/*eslint padded-blocks: ["error", { "classes": "always" }]*/

class  A {

    constructor(){
    }

}

Examples of incorrect code for this rule with the { "classes": "never" } option:

/*eslint padded-blocks: ["error", { "classes": "never" }]*/

class  A {

    constructor(){
    }

}

Examples of correct code for this rule with the { "classes": "never" } option:

/*eslint padded-blocks: ["error", { "classes": "never" }]*/

class  A {
    constructor(){
    }
}

switches

Examples of incorrect code for this rule with the { "switches": "always" } option:

/*eslint padded-blocks: ["error", { "switches": "always" }]*/

switch (a) {
    case 0: foo();
}

Examples of correct code for this rule with the { "switches": "always" } option:

/*eslint padded-blocks: ["error", { "switches": "always" }]*/

switch (a) {

    case 0: foo();

}

if (a) {
    b();
}

Examples of incorrect code for this rule with the { "switches": "never" } option:

/*eslint padded-blocks: ["error", { "switches": "never" }]*/

switch (a) {

    case 0: foo();

}

Examples of correct code for this rule with the { "switches": "never" } option:

/*eslint padded-blocks: ["error", { "switches": "never" }]*/

switch (a) {
    case 0: foo();
}

if (a) {

    b();

}

When Not To Use It

You can turn this rule off if you are not concerned with the consistency of padding within blocks. Source: http://eslint.org/docs/rules/

Block must not be padded by blank lines.
Open

export default class Events {
Severity: Minor
Found in client/src/loose-leaf/events.js by eslint

require or disallow padding within blocks (padded-blocks)

Some style guides require block statements to start and end with blank lines. The goal is to improve readability by visually separating the block content and the surrounding code.

if (a) {

    b();

}

Since it's good to have a consistent code style, you should either always write padded blocks or never do it.

Rule Details

This rule enforces consistent empty line padding within blocks.

Options

This rule has one option, which can be a string option or an object option.

String option:

  • "always" (default) requires empty lines at the beginning and ending of block statements (except switch statements and classes)
  • "never" disallows empty lines at the beginning and ending of block statements (except switch statements and classes)

Object option:

  • "blocks" require or disallow padding within block statements
  • "classes" require or disallow padding within classes
  • "switches" require or disallow padding within switch statements

always

Examples of incorrect code for this rule with the default "always" option:

/*eslint padded-blocks: ["error", "always"]*/

if (a) {
    b();
}

if (a) { b(); }

if (a)
{
    b();
}

if (a) {

    b();
}

if (a) {
    b();

}

if (a) {
    // comment
    b();

}

Examples of correct code for this rule with the default "always" option:

/*eslint padded-blocks: ["error", "always"]*/

if (a) {

    b();

}

if (a)
{

    b();

}

if (a) {

    // comment
    b();

}

never

Examples of incorrect code for this rule with the "never" option:

/*eslint padded-blocks: ["error", "never"]*/

if (a) {

    b();

}

if (a)
{

    b();

}

if (a) {

    b();
}

if (a) {
    b();

}

Examples of correct code for this rule with the "never" option:

/*eslint padded-blocks: ["error", "never"]*/

if (a) {
    b();
}

if (a)
{
    b();
}

blocks

Examples of incorrect code for this rule with the { "blocks": "always" } option:

/*eslint padded-blocks: ["error", { "blocks": "always" }]*/

if (a) {
    b();
}

if (a) { b(); }

if (a)
{
    b();
}

if (a) {

    b();
}

if (a) {
    b();

}

if (a) {
    // comment
    b();

}

Examples of correct code for this rule with the { "blocks": "always" } option:

/*eslint padded-blocks: ["error", { "blocks": "always" }]*/

if (a) {

    b();

}

if (a)
{

    b();

}

if (a) {

    // comment
    b();

}

Examples of incorrect code for this rule with the { "blocks": "never" } option:

/*eslint padded-blocks: ["error", { "blocks": "never" }]*/

if (a) {

    b();

}

if (a)
{

    b();

}

if (a) {

    b();
}

if (a) {
    b();

}

Examples of correct code for this rule with the { "blocks": "never" } option:

/*eslint padded-blocks: ["error", { "blocks": "never" }]*/

if (a) {
    b();
}

if (a)
{
    b();
}

classes

Examples of incorrect code for this rule with the { "classes": "always" } option:

/*eslint padded-blocks: ["error", { "classes": "always" }]*/

class  A {
    constructor(){
    }
}

Examples of correct code for this rule with the { "classes": "always" } option:

/*eslint padded-blocks: ["error", { "classes": "always" }]*/

class  A {

    constructor(){
    }

}

Examples of incorrect code for this rule with the { "classes": "never" } option:

/*eslint padded-blocks: ["error", { "classes": "never" }]*/

class  A {

    constructor(){
    }

}

Examples of correct code for this rule with the { "classes": "never" } option:

/*eslint padded-blocks: ["error", { "classes": "never" }]*/

class  A {
    constructor(){
    }
}

switches

Examples of incorrect code for this rule with the { "switches": "always" } option:

/*eslint padded-blocks: ["error", { "switches": "always" }]*/

switch (a) {
    case 0: foo();
}

Examples of correct code for this rule with the { "switches": "always" } option:

/*eslint padded-blocks: ["error", { "switches": "always" }]*/

switch (a) {

    case 0: foo();

}

if (a) {
    b();
}

Examples of incorrect code for this rule with the { "switches": "never" } option:

/*eslint padded-blocks: ["error", { "switches": "never" }]*/

switch (a) {

    case 0: foo();

}

Examples of correct code for this rule with the { "switches": "never" } option:

/*eslint padded-blocks: ["error", { "switches": "never" }]*/

switch (a) {
    case 0: foo();
}

if (a) {

    b();

}

When Not To Use It

You can turn this rule off if you are not concerned with the consistency of padding within blocks. Source: http://eslint.org/docs/rules/

Avoid when branches without a body.
Open

  when 'minor'
Severity: Minor
Found in rakelib/release.rake by rubocop

This cop checks for the presence of when branches without a body.

Example:

# bad

case foo
when bar then 1
when baz then # nothing
end

Example:

# good

case foo
when bar then 1
when baz then 2
end

Use %i or %I for an array of symbols.
Open

task default: [:spec, :lint]
Severity: Minor
Found in Rakefile by rubocop

This cop can check for array literals made up of symbols that are not using the %i() syntax.

Alternatively, it checks for symbol arrays using the %i() syntax on projects which do not want to use that syntax.

Configuration option: MinSize If set, arrays with fewer elements than this value will not trigger the cop. For example, a MinSize of3` will not enforce a style on an array of 2 or fewer elements.

Example: EnforcedStyle: percent (default)

# good
%i[foo bar baz]

# bad
[:foo, :bar, :baz]

Example: EnforcedStyle: brackets

# good
[:foo, :bar, :baz]

# bad
%i[foo bar baz]
Severity
Category
Status
Source
Language