- 05 Sep, 2017 11 commits
-
-
Alexis Reigel authored
-
Alexis Reigel authored
-
Alexis Reigel authored
-
Alexis Reigel authored
this is used to make a difference between a committer email that belongs to user, where the user used a different email for the gpg key. this means that the user is the same, but a different, unverified email is used for the signature.
-
Alexis Reigel authored
the updated verification of a gpg signature requires the committer's email to also match the user's and the key's emails.
-
Alexis Reigel authored
we need the commit object for the updated verification that also checks the committer's email to match the gpg key and user's emails.
-
Shinya Maeda authored
-
Shinya Maeda authored
- Fix spec
-
Shinya Maeda authored
-
Shinya Maeda authored
-
Shinya Maeda authored
-
- 04 Sep, 2017 4 commits
-
-
Shinya Maeda authored
-
Shinya Maeda authored
-
Shinya Maeda authored
-
Shinya Maeda authored
-
- 03 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
Re-organize schema. Drop protected from runner. Add access_level to runner. Drop protected from pipeline. Add protected to ci_bilds.
-
Shinya Maeda authored
-
Shinya Maeda authored
Solution 1. Persists protected(ref) flag on ci_pipelines table. builds_for_shared_runner and builds_for_specific_runner read the flag instead of executing protected_for? one by one.
-
Shinya Maeda authored
-
- 01 Sep, 2017 3 commits
-
-
Jacob Vosmaer authored
-
Grzegorz Bizon authored
-
Tiago Botelho authored
-
- 31 Aug, 2017 5 commits
-
-
Felipe Artur authored
-
Jacob Vosmaer 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.
-
Grzegorz Bizon authored
-
Zeger-Jan van de Weg authored
In this instance its subgroups, and given we can't deploy it, we shouldn't allow it to be shown. Fixes gitlab-org/gitlab-ce#34864
-
- 30 Aug, 2017 6 commits
-
-
Nick Thomas authored
-
Jacopo authored
The special characters of a wiki title are now escaped correctly.
-
Nick Thomas authored
-
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
-