Merge remote-tracking branch 'upstream/master' into ce-to-ee-2018-11-28

# Conflicts:
#	.gitlab-ci.yml
#	app/controllers/projects/imports_controller.rb
#	app/workers/stuck_import_jobs_worker.rb
#	lib/gitlab/import_export/import_export.yml
#	locale/gitlab.pot
#	spec/factories/projects.rb
#	spec/models/project_spec.rb

[ci skip]

.gitlab-ci.yml

@@ -1152,6 +1152,7 @@ review-deploy:
     - source ./scripts/review_apps/review-apps.sh
     - gem install gitlab-qa --no-document ${GITLAB_QA_VERSION:+ --version ${GITLAB_QA_VERSION}}
     - wait_for_job_to_be_done "review-deploy"
+<<<<<<< HEAD
 
 review-qa-smoke:
   <<: *review-qa-base
@@ -1164,6 +1165,20 @@ review-qa-all:
     - gitlab-qa Test::Instance::Any "${QA_IMAGE}" "${CI_ENVIRONMENT_URL}"
   when: manual
 
+=======
+
+review-qa-smoke:
+  <<: *review-qa-base
+  script:
+    - gitlab-qa Test::Instance::Smoke "${QA_IMAGE}" "${CI_ENVIRONMENT_URL}"
+
+review-qa-all:
+  <<: *review-qa-base
+  script:
+    - gitlab-qa Test::Instance::Any "${QA_IMAGE}" "${CI_ENVIRONMENT_URL}"
+  when: manual
+
+>>>>>>> upstream/master
 review-stop:
   <<: *review-base
   <<: *single-script-job

app/controllers/projects/imports_controller.rb

@@ -68,6 +68,7 @@ class Projects::ImportsController < Projects::ApplicationController
   end
 
   def import_params
+<<<<<<< HEAD
     params.require(:project).permit(:import_url, :mirror, :mirror_user_id)
   end
 
@@ -75,5 +76,12 @@ class Projects::ImportsController < Projects::ApplicationController
     return import_params if valid_mirror_user?(import_params)
 
     import_params.merge(mirror_user_id: current_user.id)
+=======
+    params.require(:project).permit(:import_url)
+  end
+
+  def safe_import_params
+    import_params
+>>>>>>> upstream/master
   end
 end

app/workers/stuck_import_jobs_worker.rb

@@ -71,6 +71,7 @@ class StuckImportJobsWorker
 
   def error_message
     _("Import timed out. Import took longer than %{import_jobs_expiration} seconds") % { import_jobs_expiration: IMPORT_JOBS_EXPIRATION }
+<<<<<<< HEAD
   end
 
   def stuck_import_jobs_worker_runs_counter
@@ -84,5 +85,7 @@ class StuckImportJobsWorker
 
   def import_state_with_jid_metric
     @import_state_with_jid_metric ||= Gitlab::Metrics.gauge(:gitlab_projects_with_jid, 'Projects with Job ids')
+=======
+>>>>>>> upstream/master
   end
 end

doc/ci/yaml/README.md

@@ -1821,13 +1821,6 @@ These variables can be later used in all executed commands and scripts.
 The YAML-defined variables are also set to all created service containers,
 thus allowing to fine tune them.
 
-To turn off global defined variables in a specific job, define an empty hash:
-
-```yaml
-job_name:
-  variables: {}
-```
-
 Except for the user defined variables, there are also the ones [set up by the
 Runner itself](../variables/README.md#predefined-variables-environment-variables).
 One example would be `CI_COMMIT_REF_NAME` which has the value of

doc/development/code_review.md

@@ -5,7 +5,7 @@ having your code reviewed.
 
 All merge requests for GitLab CE and EE, whether written by a GitLab team member
 or a volunteer contributor, must go through a code review process to ensure the
-code is effective, understandable, and maintainable.
+code is effective, understandable, maintainable, and secure.
 
 ## Getting your merge request reviewed, approved, and merged
 
@@ -20,12 +20,24 @@ importance of involving reviewer(s) in the section on the responsibility of the
 If you need some guidance (e.g. it's your first merge request), feel free to ask
 one of the [Merge request coaches][team].
 
+If you need assistance with security scans or comments, feel free to include the 
+Security Team (`@gitlab-com/gl-security`) in the review.
+
 Depending on the areas your merge request touches, it must be **approved** by one
 or more [maintainers](https://about.gitlab.com/handbook/engineering/#maintainer):
 
 For approvals, we use the approval functionality found in the merge request
 widget. Reviewers can add their approval by [approving additionally](https://docs.gitlab.com/ee/user/project/merge_requests/merge_request_approvals.html#adding-or-removing-an-approval).
 
+Getting your merge request **merged** also requires a maintainer. If it requires
+more than one approval, the last maintainer to review and approve it will also merge it.
+
+### Approval guidelines
+
+As described in the section on the responsibility of the maintainer below, you
+are recommended to get your merge request approved and merged by maintainer(s)
+from teams other than your own.
+
    1. If your merge request includes backend changes [^1], it must be
       **approved by a [backend maintainer](https://about.gitlab.com/handbook/engineering/projects/#gitlab-ce_maintainers_backend)**.
    1. If your merge request includes frontend changes [^1], it must be
@@ -39,12 +51,12 @@ widget. Reviewers can add their approval by [approving additionally](https://doc
    1. If your merge request includes a new dependency or a filesystem change, it must be
       **approved by a [Distribution team member][team]**. See how to work with the [Distribution team](https://about.gitlab.com/handbook/engineering/dev-backend/distribution/) for more details.
 
-Getting your merge request **merged** also requires a maintainer. If it requires
-more than one approval, the last maintainer to review and approve it will also merge it.
+#### Security requirements
 
-As described in the section on the responsibility of the maintainer below, you
-are recommended to get your merge request approved and merged by maintainer(s)
-from other teams than your own.
+   1. If your merge request involves implementing, utilizing, or is otherwise related to any type of authentication, authorization, or session handling mechanism, it must be
+      **approved by a [Security Engineer][team]**.
+   1. If your merge request has a goal which requires a cryptographic function such as: confidentiality, integrity, authentication, or non-repudiation, it must be
+      **approved by a [Security Engineer][team]**.
 
 ### The responsibility of the merge request author
 
@@ -54,9 +66,10 @@ merge request author.
 Before assigning a merge request to a maintainer for approval and merge, they
 should be confident that it actually solves the problem it was meant to solve,
 that it does so in the most appropriate way, that it satisfies all requirements,
-and that there are no remaining bugs, logical problems, or uncovered edge cases.
-The merge request should also have a completed task list in its description and
-a passing CI pipeline to avoid unnecessary back and forth.
+and that there are no remaining bugs, logical problems, uncovered edge cases,
+or known vulnerabilities. The merge request should also have a completed task
+list in its description and a passing CI pipeline to avoid unnecessary back and
+forth.
 
 To reach the required level of confidence in their solution, an author is expected
 to involve other people in the investigation and implementation processes as
@@ -85,8 +98,8 @@ Since a maintainer's job only depends on their knowledge of the overall GitLab
 codebase, and not that of any specific domain, they can review, approve and merge
 merge requests from any team and in any product area.
 
-In fact, authors are recommended to get their merge requests merged by maintainers
-from other teams than their own, to ensure that all code across GitLab is consistent
+In fact, authors are encouraged to get their merge requests merged by maintainers
+from teams other than their own, to ensure that all code across GitLab is consistent
 and can be easily understood by all contributors, from both inside and outside the
 company, without requiring team-specific expertise.
 
@@ -103,6 +116,18 @@ as the maintainer to ultimately approve and merge it.
 Maintainers should check before merging if the merge request is approved by the
 required approvers.
 
+Maintainers must check before merging if the merge request is introducing new
+vulnerabilities, by inspecting the list in the Merge Request [Security
+Widget](https://docs.gitlab.com/ee/user/project/merge_requests/#security-reports-ultimate).
+When in doubt, a [Security Engineer][team] can be involved. The list of detected 
+vulnerabilities must be either empty or containing:
+
+- dismissed vulnerabilities in case of false positives
+- vulnerabilities converted to issues
+
+Maintainers should **never** dismiss vulnerabilities to "empty" the list,
+without duly verifying them.
+
 ## Best practices
 
 ### Everyone
@@ -153,7 +178,7 @@ first time.
 
 ### Assigning a merge request for a review
 
-If you want to have your merge request reviewed you can assign it to any reviewer. The list of reviewers can be found on [Engineering projects](https://about.gitlab.com/handbook/engineering/projects/) page.
+If you want to have your merge request reviewed, you can assign it to any reviewer. The list of reviewers can be found on [Engineering projects](https://about.gitlab.com/handbook/engineering/projects/) page.
 
 You can also use `ready for review` label. That means that your merge request is ready to be reviewed and any reviewer can pick it. It is recommended to use that label only if there isn't time pressure and make sure the merge request is assigned to a reviewer.
 
@@ -189,6 +214,9 @@ experience, refactors the existing code). Then:
   subsequent revisions for anything that would be spotted after that.
 - Consider using the [Squash and
   merge][squash-and-merge] feature when the merge request has a lot of commits.
+  When merging code a maintainer should only use the squash feature if the
+  author has already set this option or if the merge request clearly contains a
+  messy commit history that is intended to be squashed.
 
 [squash-and-merge]: https://docs.gitlab.com/ee/user/project/merge_requests/squash_and_merge.html#squash-and-merge
 

lib/gitlab/import_export/import_export.yml

@@ -122,6 +122,7 @@ excluded_attributes:
     - :mirror_overwrites_diverged_branches
     - :description_html
     - :repository_languages
+<<<<<<< HEAD
     - :packages_enabled
     - :mirror_last_update_at
     - :mirror_last_successful_update_at
@@ -130,6 +131,11 @@ excluded_attributes:
     - :jid
     - :last_update_at
     - :last_successful_update_at
+=======
+  project_import_state:
+    - :last_error
+    - :jid
+>>>>>>> upstream/master
   prometheus_metrics:
     - :common
     - :identifier

locale/gitlab.pot

@@ -4524,6 +4524,7 @@ msgstr ""
 msgid "Import timed out. Import took longer than %{import_jobs_expiration} seconds"
 msgstr ""
 
+<<<<<<< HEAD
 msgid "ImportButtons|Connect repositories from"
 msgstr ""
 
@@ -4536,6 +4537,8 @@ msgstr ""
 msgid "Improve search with Advanced Global Search and GitLab Enterprise Edition."
 msgstr ""
 
+=======
+>>>>>>> upstream/master
 msgid "In order to enable instance-level analytics, please ask an admin to enable %{usage_ping_link_start}usage ping%{usage_ping_link_end}."
 msgstr ""
 

package.json

@@ -24,7 +24,7 @@
     "@babel/plugin-syntax-dynamic-import": "^7.0.0",
     "@babel/plugin-syntax-import-meta": "^7.0.0",
     "@babel/preset-env": "^7.1.0",
-    "@gitlab/svgs": "^1.38.0",
+    "@gitlab/svgs": "^1.40.0",
     "@gitlab/ui": "^1.11.0",
     "apollo-boost": "^0.1.20",
     "apollo-client": "^2.4.5",

spec/factories/projects.rb

@@ -32,9 +32,12 @@ FactoryBot.define do
       group_runners_enabled nil
       import_status nil
       import_jid nil
+<<<<<<< HEAD
       last_update_at nil
       last_successful_update_at nil
       retry_count 0
+=======
+>>>>>>> upstream/master
     end
 
     after(:create) do |project, evaluator|
@@ -73,9 +76,12 @@ FactoryBot.define do
       if evaluator.import_status
         import_state = project.import_state || project.build_import_state
         import_state.status = evaluator.import_status
+<<<<<<< HEAD
         import_state.last_update_at = evaluator.last_update_at
         import_state.last_successful_update_at = evaluator.last_successful_update_at
         import_state.retry_count = evaluator.retry_count
+=======
+>>>>>>> upstream/master
         import_state.jid = evaluator.import_jid
         import_state.save
       end

spec/models/project_spec.rb

@@ -1815,6 +1815,7 @@ describe Project do
   end
 
   describe 'handling import URL' do
+<<<<<<< HEAD
     context 'when project is a mirror' do
       it 'returns the full URL' do
         project = create(:project, :mirror, import_url: 'http://user:pass@test.com')
@@ -1833,6 +1834,14 @@ describe Project do
 
         expect(project.reload.import_url).to eq('http://test.com')
       end
+=======
+    it 'returns the sanitized URL' do
+      project = create(:project, :import_started, import_url: 'http://user:pass@test.com')
+
+      project.import_state.finish
+
+      expect(project.reload.import_url).to eq('http://test.com')
+>>>>>>> upstream/master
     end
   end
 
@@ -3723,6 +3732,7 @@ describe Project do
 
       expect(project.wiki_repository_exists?).to eq(true)
     end
+<<<<<<< HEAD
 
     it 'returns false when the wiki repository does not exist' do
       project = create(:project)
@@ -3744,6 +3754,8 @@ describe Project do
         is_expected.to eq(root_ancestor)
       end
     end
+=======
+>>>>>>> upstream/master
 
     context 'when namespace is root ancestor' do
       let(:parent) { build(:group) }

yarn.lock

@@ -629,10 +629,10 @@
     eslint-plugin-promise "^4.0.1"
     eslint-plugin-vue "^5.0.0-beta.3"
 
-"@gitlab/svgs@^1.38.0":
-  version "1.38.0"
-  resolved "https://registry.yarnpkg.com/@gitlab/svgs/-/svgs-1.38.0.tgz#e2f6e73379d60c7c63af4df8242a94c4671a1dfe"
-  integrity sha512-Mzv6PxVbWEPvvMgXHaGxk8UE1Gard2gifca6loLgfLH7BtjXfESiZyJdQkkTSeBYp5MoqQa88Kw+vJYobwjsSw==
+"@gitlab/svgs@^1.40.0":
+  version "1.40.0"
+  resolved "https://registry.yarnpkg.com/@gitlab/svgs/-/svgs-1.40.0.tgz#58d7545fde3a7af3c290b419d1de2405973e58c5"
+  integrity sha512-Y5QkaZH5N84qSNSGPxaj+NNlI4kthUNet7eRS1QCnaskwcvuWd/vF0xYCPd/tbRnK9MIhkKzhbxatUYDZVgXTQ==
 
 "@gitlab/ui@^1.11.0":
   version "1.11.0"