Add latest changes from gitlab-org/gitlab@master

app/views/admin/application_settings/_signup.html.haml

@@ -7,6 +7,8 @@
         = f.check_box :signup_enabled, class: 'form-check-input'
         = f.label :signup_enabled, class: 'form-check-label' do
           Sign-up enabled
+          .form-text.text-muted
+            = _("When enabled, any user visiting %{host} will be able to create an account.") % { host: "#{new_user_session_url(host: Gitlab.config.gitlab.host)}" }
     .form-group
       .form-check
         = f.check_box :send_user_confirmation_email, class: 'form-check-input'

changelogs/unreleased/30968-make-open-user-registration-setting-more-prominent-to-admins.yml

+---
+title: Add documentation & helper text information regarding securing a GitLab instance
+merge_request: 18987
+author:
+type: changed

doc/api/group_milestones.md

@@ -98,7 +98,7 @@ Parameters:
 
 ## Delete group milestone
 
-Only for user with developer access to the group.
+Only for users with Developer access to the group.
 
 ```
 DELETE /groups/:id/milestones/:milestone_id

doc/api/milestones.md

@@ -96,7 +96,7 @@ Parameters:
 
 ## Delete project milestone
 
-Only for user with developer access to the project.
+Only for users with Developer access to the project.
 
 ```
 DELETE /projects/:id/milestones/:milestone_id
@@ -137,7 +137,7 @@ Parameters:
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/53861) in GitLab 11.9
 
-Only for users with developer access to the group.
+Only for users with Developer access to the group.
 
 ```
 POST /projects/:id/milestones/:milestone_id/promote

doc/development/contributing/issue_workflow.md

@@ -29,7 +29,7 @@ the affected files to find someone.
 We also use [GitLab Triage](https://gitlab.com/gitlab-org/gitlab-triage) to automate
 some triaging policies. This is currently set up as a scheduled pipeline
 (`https://gitlab.com/gitlab-org/quality/triage-ops/pipeline_schedules/10512/editpipeline_schedules/10512/edit`,
-must have at least developer access to the project) running on [quality/triage-ops](https://gitlab.com/gitlab-org/quality/triage-ops)
+must have at least Developer access to the project) running on [quality/triage-ops](https://gitlab.com/gitlab-org/quality/triage-ops)
 project.
 
 ## Labels

doc/development/documentation/workflow.md

@@ -284,7 +284,7 @@ To update GitLab documentation:
 1. Follow GitLab's [Merge Request Guidelines](../contributing/merge_request_workflow.md#merge-request-guidelines).
 
 TIP: **Tip:**
-Work in a fork if you do not have developer access to the GitLab project.
+Work in a fork if you do not have Developer access to the GitLab project.
 
 Request help from the Technical Writing team if you:
 

doc/development/policies.md

@@ -95,8 +95,8 @@ Each line represents a rule that was evaluated. There are a few things to note:
 
 Here you can see that the first four rules were evaluated `false` for
 which user and subject. For example, you can see in the last line that
-the rule was activated because the user `root` had at reporter access to
-the `Project/4`.
+the rule was activated because the user `root` had Reporter access to
+`Project/4`.
 
 When a policy is asked whether a particular ability is allowed
 (`policy.allowed?(:some_ability)`), it does not necessarily have to

doc/development/testing_guide/end_to_end/index.md

@@ -15,15 +15,15 @@ a black-box testing framework for the API and the UI.
 
 ### Testing nightly builds
 
-We run scheduled pipeline each night to test nightly builds created by Omnibus.
+We run scheduled pipelines each night to test nightly builds created by Omnibus.
 You can find these nightly pipelines at `https://gitlab.com/gitlab-org/quality/nightly/pipelines`
 (need Developer access permissions). Results are reported in the `#qa-nightly` Slack channel.
 
 ### Testing staging
 
-We run scheduled pipeline each night to test staging.
+We run scheduled pipelines each night to test staging.
 You can find these nightly pipelines at `https://gitlab.com/gitlab-org/quality/staging/pipelines`
-(need developer access permissions). Results are reported in the `#qa-staging` Slack channel.
+(need Developer access permissions). Results are reported in the `#qa-staging` Slack channel.
 
 ### Testing code in merge requests
 

doc/install/README.md

@@ -87,3 +87,7 @@ the above methods, provided the cloud provider supports it.
 - [Install GitLab on DigitalOcean](https://about.gitlab.com/blog/2016/04/27/getting-started-with-gitlab-and-digitalocean/): Install Omnibus GitLab on DigitalOcean.
 - _Testing only!_ [DigitalOcean and Docker Machine](digitaloceandocker.md):
   Quickly test any version of GitLab on DigitalOcean using Docker Machine.
+
+## Securing your GitLab installation
+
+After completing your installation, check out our [recommended practices to secure your GitLab instance](../security/README.md#securing-your-gitlab-installation).

doc/security/README.md

@@ -19,3 +19,9 @@ type: index
 - [Send email confirmation on sign-up](user_email_confirmation.md)
 - [Security of running jobs](https://docs.gitlab.com/runner/security/)
 - [Proxying images](asset_proxy.md)
+
+## Securing your GitLab installation
+
+To make sure your GitLab instance is safe and secure, please consider implementing
+[Sign up restrictions](../user/admin_area/settings/sign_up_restrictions.md) to avoid
+malicious users creating accounts.

doc/user/admin_area/settings/sign_up_restrictions.md

@@ -4,20 +4,42 @@ type: reference
 
 # Sign-up restrictions **(CORE ONLY)**
 
-You can use sign-up restrictions to require user email confirmation, as well as
-to blacklist or whitelist email addresses belonging to specific domains.
+You can use sign-up restrictions to:
 
->**Note**: These restrictions are only applied during sign-up. An admin is
+- Disable new signups.
+- Require user email confirmation.
+- Blacklist or whitelist email addresses belonging to specific domains.
+
+NOTE: **Note:**
+These restrictions are only applied during sign-up from an external user. An admin is
 able to add a user through the admin panel with a disallowed domain. Also
 note that the users can change their email addresses after signup to
 disallowed domains.
 
+## Disable new signups
+
+When this setting is enabled, any user visiting your GitLab domain will be able to sign up for an account.
+
+![Disable signups](img/disable_signup_v12_7.png)
+
+You can restrict new users from signing up by themselves for an account in your instance by disabling this setting.
+
+### Recommendations
+
+For customers running public facing GitLab instances, we highly recommend that you
+consider disabling new signups if you do not expect public users to sign up for an
+account.
+
+Alternatively, you could also consider setting up a
+[whitelist](#whitelist-email-domains) or [blacklist](#blacklist-email-domains) on
+email domains to prevent malicious users from creating accounts.
+
 ## Require email confirmation
 
 You can send confirmation emails during sign-up and require that users confirm
 their email address before they are allowed to sign in.
 
-![Email confirmation](img/email_confirmation.png)
+![Email confirmation](img/email_confirmation_v12_7.png)
 
 ## Minimum password length limit
 

doc/user/markdown.md

@@ -160,7 +160,7 @@ It is possible to generate diagrams and flowcharts from text in GitLab using [Me
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/15107) in
 GitLab 10.3.
 
-Visit the [official page](https://mermaidjs.github.io/) for more details.
+Visit the [official page](https://mermaidjs.github.io/) for more details. If you are new to using Mermaid or need help identifying issues in your Mermaid code, the [Mermaid Live Editor](https://mermaid-js.github.io/mermaid-live-editor/) is a helpful tool for creating and resolving issues within Mermaid diagrams.
 
 In order to generate a diagram or flowchart, you should write your text inside the `mermaid` block:
 

doc/user/project/new_ci_build_permissions_model.md

@@ -48,7 +48,7 @@ It is important to note that we have a few types of users:
   via another project's job.
 
 - **External users**: CI jobs created by [external users](../permissions.md#external-users-core-only) will have
-  access only to projects to which user has at least reporter access. This
+  access only to projects to which the user has at least Reporter access. This
   rules out accessing all internal projects by default.
 
 This allows us to make the CI and permission system more trustworthy.
@@ -114,7 +114,7 @@ docker login -u gitlab-ci-token -p $CI_JOB_TOKEN registry.gitlab.com
 
 Using single token had multiple security implications:
 
-- The token would be readable to anyone who had developer access to a project
+- The token would be readable to anyone who had Developer access to a project
   that could run CI jobs, allowing the developer to register any specific
   Runner for that project.
 - The token would allow to access only the project's sources, forbidding from

doc/user/project/repository/repository_mirroring.md

@@ -22,7 +22,7 @@ There are two kinds of repository mirroring supported by GitLab:
 When the mirror repository is updated, all new branches, tags, and commits will be visible in the
 project's activity feed.
 
-Users with at least [developer access](../../permissions.md) to the project can also force an
+Users with at least [Developer access](../../permissions.md) to the project can also force an
 immediate update, unless:
 
 - The mirror is already being updated.

locale/gitlab.pot

@@ -20423,6 +20423,9 @@ msgstr ""
 msgid "When a runner is locked, it cannot be assigned to other projects"
 msgstr ""
 
+msgid "When enabled, any user visiting %{host} will be able to create an account."
+msgstr ""
+
 msgid "When enabled, users cannot use GitLab until the terms have been accepted."
 msgstr ""
 

spec/frontend/notes/components/discussion_notes_replies_wrapper_spec.js

@@ -30,7 +30,7 @@ describe('DiscussionNotesRepliesWrapper', () => {
     });
 
     it('renders children directly', () => {
-      expect(wrapper.html()).toEqual(`<ul>${TEST_CHILDREN}</ul>`);
+      expect(wrapper.element.outerHTML).toEqual(`<ul>${TEST_CHILDREN}</ul>`);
     });
   });
 
@@ -45,7 +45,7 @@ describe('DiscussionNotesRepliesWrapper', () => {
       const notes = wrapper.find('li.discussion-collapsible ul.notes');
 
       expect(notes.exists()).toBe(true);
-      expect(notes.html()).toEqual(`<ul class="notes">${TEST_CHILDREN}</ul>`);
+      expect(notes.element.outerHTML).toEqual(`<ul class="notes">${TEST_CHILDREN}</ul>`);
     });
   });
 });