- 06 Sep, 2017 1 commit
-
-
Ashley Dumaine authored
-
- 05 Sep, 2017 11 commits
-
-
Robert Schilling authored
-
Robert Schilling authored
-
blackst0ne authored
-
Shinya Maeda authored
-
Shinya Maeda authored
-
Shinya Maeda authored
- Fix spec
-
Shinya Maeda authored
-
Shinya Maeda authored
-
Shinya Maeda authored
-
Hiroyuki Sato authored
-
Hiroyuki Sato authored
-
- 04 Sep, 2017 11 commits
-
-
Shinya Maeda authored
-
Shinya Maeda authored
-
Shinya Maeda authored
-
Shinya Maeda authored
-
Shinya Maeda authored
-
Shinya Maeda authored
-
Shinya Maeda authored
-
Shinya Maeda authored
-
Shinya Maeda authored
-
Shinya Maeda authored
-
Shinya Maeda authored
-
- 03 Sep, 2017 3 commits
-
-
Shinya Maeda authored
-
Shinya Maeda authored
-
Shinya Maeda authored
-
- 31 Aug, 2017 3 commits
-
-
Alejandro Rodríguez authored
-
Robert Schilling authored
-
Sean McGivern authored
The initializers including this were doing so at the top level, so every object loaded after them had a `current_application_settings` method. However, if someone had rack-attack enabled (which was loaded before these initializers), it would try to load the API, and fail, because `Gitlab::CurrentSettings` didn't have that method. To fix this: 1. Don't include `Gitlab::CurrentSettings` at the top level. We do not need `Object.new.current_application_settings` to work. 2. Make `Gitlab::CurrentSettings` explicitly `extend self`, as we already use it like that in several places. 3. Change the initializers to use that new form.
-
- 30 Aug, 2017 6 commits
-
-
Nick Thomas authored
-
Nick Thomas authored
`allowed_key_types` is removed and the `minimum_<type>_bits` fields are renamed to `<tech>_key_restriction`. A special sentinel value (`-1`) signifies that the key type is disabled. This also feeds through to the UI - checkboxes per key type are out, inline selection of "forbidden" and "allowed" (i.e., no restrictions) are in. As with the previous model, unknown key types are disallowed, even if the underlying ssh daemon happens to support them. The defaults have also been changed from the lowest known bit size to "no restriction". So if someone does happen to have a 768-bit RSA key, it will continue to work on upgrade, at least until the administrator restricts them.
-
Nick Thomas authored
This is an amalgamation of: * Cory Hinshaw: Initial implementation !5552 * Rémy Coutable: Updates !9350 * Nick Thomas: Resolve conflicts and add ED25519 support !13712
-
Marc Siegfriedt authored
-
Sean McGivern authored
As we only override in two places, we could just ask for the value rather than the method name.
-
Robert Schilling authored
-
- 29 Aug, 2017 5 commits
-
-
Robert Schilling authored
-
Travis Miller authored
-
Travis Miller authored
-
Maxim Rydkin authored
-
Robert Schilling authored
-