Update browser gem to 2.2.0
A user with a certain browser would hit an Error 500:
```
ArgumentError: invalid value for Float(): "0."
from browser/accept_language.rb:45:in `Float'
from browser/accept_language.rb:45:in `quality'
from browser/accept_language.rb:15:in `each'
from browser/accept_language.rb:15:in `sort_by'
from browser/accept_language.rb:15:in `parse'
from browser/base.rb:13:in `initialize'
from browser.rb:125:in `new'
from browser.rb:125:in `block in new'
from browser.rb:125:in `map'
from browser.rb:125:in `new'
from browser/action_controller.rb:15:in `browser'
from abstract_controller/helpers.rb:67:in `browser'
from app/views/layouts/_head.html.haml:38:in `_app_views_layouts__head_html_haml__1626593241142487258_59224880'
```
The root cause when the `Accept-Language` header would contain a float for the quality value (e.g. en-GB,en;q=0.v5).
Fixes https://github.com/fnando/browser/issues/241
Seen today via Sentry: https://sentry.gitlap.com/gitlab/gitlabcom/issues/7644/
See merge request !4811
Replace raphael-rails with raphael.js and split it from the rest of the JS
## What does this MR do?
Removes raphael.js and its related libraries from the default JS bundle.
It also removes raphael-rails because the gem is unmaintained and – for whatever reason – didn't want to cooperate with the way I was trying to require it.
This brings the default (compressed and minified) application.js from 354KB after the d3 MR (!4394) down to 324KB.
## Are there points in the code the reviewer needs to double check?
That tests pass and that there aren't errors on any pages (especially the Network page).
## Why was this MR needed?
It's only used on the Network page and was using way too much bandwidth for just one page.
## What are the relevant issue numbers?
#14372#13165
Follow-up to !4394 and !4516.
cc: @jschatz1
See merge request !4519
License finder gem
Every time a gem is added to the Gemfile, or a gem is updated with a new dependency or change of license, LicenseFinder will check to ensure that the license in use has been whitelisted for use in the project. GPLv2 and GPLv3 libraries are not allowed to be linked-to from non-GPL projects (e.g. the MIT-licensed GitLab CE or proprietary EE), otherwise we're violating the license.
https://github.com/pivotal/LicenseFinder
See also: gitlab-com/operations#164
See merge request !3775
In order to rehost all our gems in our own gem host, we need to have the legal rights to do so for every gem should they be taken down from RubyGems. License Finder automates checking of gems to ensure that we're in the clear legally.
Approved the MIT License because it essentially allows us to do "whatever" with those gems.
I am not a lawyer.
https://github.com/pivotal/LicenseFinder
- To hold registrations from U2F devices, and to authenticate them.
- Previously, `User#two_factor_enabled` was aliased to the
`otp_required_for_login` column on `users`.
- This commit changes things a bit:
- `User#two_factor_enabled` is not a method anymore
- `User#two_factor_enabled?` checks both the
`otp_required_for_login` column, as well as `U2fRegistration`s
- Change all instances of `User#two_factor_enabled` to
`User#two_factor_enabled?`
- Add the `u2f` gem, and implement registration/authentication at the
model level.
Colorize is a gem licensed under the GPLv2, so we can’t use it in GitLab without relicensing GitLab under the terms of the GPL. Rainbow is licensed under the MIT license and does the exact same thing as Colorize, so Rainbow was added in place of Colorize.
The syntax is slightly different for Rainbow vs. Colorize, and was updated in accordance.
The gem is still a dependency of Spinach, so it’s included in the development/test environments, but won’t be packaged with the actual product, and therefore doesn’t require we relicense the product.
An attempt at relicensing Colorize was made, but didn’t succeed as the library owner never responded.
Rainbow library: https://github.com/sickill/rainbow
Relevant issue regarding licensing in GitLab's gems: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/3775
Upgrade devise, devise-two-factor, and attr_encrypted
Devise 4 includes support for Rails 5, working towards #14286. devise-async doesn't support Devise 4.0 and in 4.1 the bug that was blocking using Devise's built-in ActiveJob integration was fixed. So devise-async is removed. devise-two-factor 3.0.0 is required for Devise 4 support.
attr_encrypted and encryptor are optional but recommended upgrades for devise-two-factor 3.0.0. The mode and algorithm will need to be changed in order to update to attr_encrypted 4.x in the future.
See merge request !4216
attr_encrypted (1.3.4 => 3.0.1) Changelog:
https://github.com/attr-encrypted/attr_encrypted/blob/master/CHANGELOG.m
d
attr_encrypted 2.x included a vulnerability, so that major version is
skipped. 3.x requires that the algorithm and mode used by each
encrypted attribute is specified explicitly.
`nil` is no longer a valid value for the encrypted_value_iv field, so
it’s changed to a randomly generated string.
POC: Updated contrib calendar
In an effort to cut down the JS file size - i've removed the heatmap calendar used for the contributing calendar on users profiles. We already have d3 on the page so why not use it instead of using a library which uses it?
cc. @jschatz1
See merge request !3944
In 8278b763d9 the default behaviour of annotation
has changes, which was causing a lot of noise in diffs. We decided in #17382
that it is better to get rid of the whole annotate gem, and instead let people
look at schema.rb for the columns in a table.
Fixes: #17382
Revert "Remove the Devise Async gem."
This reverts commit 1cc614f2bd.
It was causing the ActiveJob integration to fail, so unfortunately we'll have to add the gem again.
Resolves#17250.
See merge request !4027
Douwe MaanandRobert Speicher
Robert SpeicherandRobert Speicher
Jacob SchatzandRobert Speicher
Kamil Trzcinski
Connor Shea
Rémy Coutable
Stan Hu
Timothy Andrew
Douwe Maan
Alfredo Sumaran
DJ Mountney
Jeroen van Baarsen