Add latest changes from gitlab-org/gitlab@15-3-stable-eev15.3.0-rc42

7 files changed, 63 insertions, 26 deletions

diff --git a/doc/security/crime_vulnerability.md b/doc/security/crime_vulnerability.md
index 7956e692887..5a6578f218b 100644
--- a/doc/security/crime_vulnerability.md
+++ b/doc/security/crime_vulnerability.md
@@ -32,7 +32,7 @@ Although SPDY is enabled in Omnibus installations, CRIME relies on compression
 
 ## Nessus
 
-The Nessus scanner, [reports a possible CRIME vulnerability](https://www.tenable.com/plugins/index.php?view=single&id=62565) in GitLab
+The Nessus scanner, [reports a possible CRIME vulnerability](https://www.tenable.com/plugins/nessus/62565) in GitLab
 similar to the following format:
 
 ```plaintext
@@ -59,7 +59,7 @@ vulnerability.
 ## References
 
 - NGINX ["Module `ngx_http_spdy_module`"](https://nginx.org/en/docs/http/ngx_http_spdy_module.html)
-- Tenable Network Security, Inc. ["Transport Layer Security (TLS) Protocol CRIME Vulnerability"](https://www.tenable.com/plugins/index.php?view=single&id=62565)
+- Tenable Network Security, Inc. ["Transport Layer Security (TLS) Protocol CRIME Vulnerability"](https://www.tenable.com/plugins/nessus/62565)
 - Wikipedia contributors, ["CRIME"](https://en.wikipedia.org/wiki/CRIME) Wikipedia, The Free Encyclopedia
 
 <!-- ## Troubleshooting
diff --git a/doc/security/index.md b/doc/security/index.md
index 73ac5028db5..9e05621333b 100644
--- a/doc/security/index.md
+++ b/doc/security/index.md
@@ -28,8 +28,6 @@ type: index
 - [Project Import decompressed archive size limits](project_import_decompressed_archive_size_limits.md)
 - [Responding to security incidents](responding_to_security_incidents.md)
 
-## Securing your GitLab installation
+To harden your GitLab instance and minimize the risk of unwanted user account creation, consider access control features like [Sign up restrictions](../user/admin_area/settings/sign_up_restrictions.md) and [Authentication options](../topics/authentication/index.md) .
 
-Consider access control features like [Sign up restrictions](../user/admin_area/settings/sign_up_restrictions.md) and [Authentication options](../topics/authentication/) to harden your GitLab instance and minimize the risk of unwanted user account creation.
-
-Self-hosting GitLab customers and administrators are responsible for the security of their underlying hosts, and for keeping GitLab itself up to date. It is important to [regularly patch GitLab](../policy/maintenance.md), patch your operating system and its software, and harden your hosts in accordance with vendor guidance.
+Self-managed GitLab customers and administrators are responsible for the security of their underlying hosts, and for keeping GitLab itself up to date. It is important to [regularly patch GitLab](../policy/maintenance.md), patch your operating system and its software, and harden your hosts in accordance with vendor guidance.
diff --git a/doc/security/information_exclusivity.md b/doc/security/information_exclusivity.md
index 0d55881c147..754d5fff843 100644
--- a/doc/security/information_exclusivity.md
+++ b/doc/security/information_exclusivity.md
@@ -24,8 +24,8 @@ limitation.
 You can take steps to prevent unintentional sharing and information
 destruction. This limitation is the reason why only certain people are allowed
 to [add users to a project](../user/project/members/index.md)
-and why only a GitLab administrator can [force push a protected
-branch](../user/project/protected_branches.md).
+and why only a GitLab administrator can 
+[force push a protected branch](../user/project/protected_branches.md).
 
 <!-- ## Troubleshooting
 
diff --git a/doc/security/reset_user_password.md b/doc/security/reset_user_password.md
index 06934b187c1..992a8585a47 100644
--- a/doc/security/reset_user_password.md
+++ b/doc/security/reset_user_password.md
@@ -81,7 +81,15 @@ If you know the username, user ID, or email address, you can use the Rails conso
    new_password = ::User.random_password
    user.password = new_password
    user.password_confirmation = new_password
-    ```
+   ```
+  
+   To set a specific value for the new password:
+
+   ```ruby
+   new_password = 'examplepassword'
+   user.password = new_password
+   user.password_confirmation = new_password
+   ```
 
 1. Optional. Notify the user that an administrator changed their password:
 
diff --git a/doc/security/two_factor_authentication.md b/doc/security/two_factor_authentication.md
index 5907860f5cc..93d77a69f0e 100644
--- a/doc/security/two_factor_authentication.md
+++ b/doc/security/two_factor_authentication.md
@@ -71,7 +71,7 @@ The following are important notes about 2FA:
   2FA for the project. For example, if project *P* belongs to 2FA-enabled group *A* and
   is shared with 2FA-disabled group *B*, members of group *B* can access project *P*
   without 2FA. To ensure this scenario doesn't occur,
-  [prevent sharing of projects](../user/group/index.md#prevent-a-project-from-being-shared-with-groups)
+  [prevent sharing of projects](../user/group/access_and_permissions.md#prevent-a-project-from-being-shared-with-groups)
   for the 2FA-enabled group.
 - If you add additional members to a project within a group or subgroup that has
   2FA enabled, 2FA is **not** required for those individually added members.
@@ -129,6 +129,7 @@ sudo -u git -H bundle exec rake gitlab:two_factor:disable_for_all_users RAILS_EN
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/270554) in GitLab 13.7.
 > - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/299088) from GitLab Free to GitLab Premium in 13.9.
 > - It's deployed behind a feature flag, disabled by default.
+> - Push notification support [introduced](https://gitlab.com/gitlab-org/gitlab-shell/-/issues/506) in GitLab 15.3.
 
 FLAG:
 On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the feature flag](../administration/feature_flags.md) named `two_factor_for_cli`. On GitLab.com, this feature is not available. The feature is not ready for production use. This feature flag also affects [session duration for Git Operations when 2FA is enabled](../user/admin_area/settings/account_and_limit_settings.md#customize-session-duration-for-git-operations-when-2fa-is-enabled).
@@ -136,14 +137,20 @@ On self-managed GitLab, by default this feature is not available. To make it ava
 Two-factor authentication can be enforced for Git over SSH operations. However, we recommend using
 [ED25519_SK](../user/ssh.md#ed25519_sk-ssh-keys) or [ECDSA_SK](../user/ssh.md#ecdsa_sk-ssh-keys) SSH keys instead.
 
-The one-time password (OTP) verification can be done using a command:
+To perform one-time password (OTP) verification, run:
 
 ```shell
 ssh git@<hostname> 2fa_verify
 ```
 
-After the OTP is verified, Git over SSH operations can be used for a session duration of
-15 minutes (default) with the associated SSH key.
+Then authenticate by either:
+
+- Entering the correct OTP.
+- In GitLab 15.3 and later, responding to a device push notification if
+  [FortiAuthenticator is enabled](../user/profile/account/two_factor_authentication.md#enable-one-time-password-using-fortiauthenticator).
+
+After successful authentication, you can perform Git over SSH operations for 15 minutes (default) with the associated
+SSH key.
 
 ### Security limitation
 
diff --git a/doc/security/user_file_uploads.md b/doc/security/user_file_uploads.md
index dcdd18a9f0b..7c11d01396d 100644
--- a/doc/security/user_file_uploads.md
+++ b/doc/security/user_file_uploads.md
@@ -5,21 +5,45 @@ group: Authentication and Authorization
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
-# User File Uploads **(FREE)**
+# User file uploads **(FREE)**
 
-Images that are attached to issues, merge requests, or comments
-do not require authentication to be viewed if they are accessed directly by URL.
-This direct URL contains a random 32-character ID that prevents unauthorized
-people from guessing the URL for an image, thus there is some protection if an
-image contains sensitive information.
+> - Enforced authorization checks [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/80117) in GitLab 14.8 [with a flag](../administration/feature_flags.md) named `enforce_auth_checks_on_uploads`. Disabled by default.
+> - Enforced authorization checks became [generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/352291) in GitLab 15.3. Feature flag `enforce_auth_checks_on_uploads` removed.
+> - Project settings in the user interface [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/88567) in GitLab 15.3.
 
-Authentication is not enabled because images must be visible in the body of
-notification emails, which are often read from email clients that are not
-authenticated with GitLab, such as Outlook, Apple Mail, or the Mail app on your
-mobile device.
+In private or internal projects, GitLab restricts access to uploaded files (such as PDFs)
+to authenticated users only. By default, image files are not subject to the same
+restriction, and unauthenticated users can use the URL to view the
+file. If you enable authorization checks for all media files, images
+receive the same protection and are viewable only by authenticated users.
 
-NOTE:
-Non-image attachments do require authentication to be viewed.
+Users can upload files to issues, merge requests, or comments in a project. Direct URLs
+to these images in GitLab contain a random 32-character ID to help prevent
+unauthorized users from guessing image URLs. This randomization provides some protection
+if an image contains sensitive information.
+
+Authentication checks for images can cause display issues in the body of notification emails.
+Emails are frequently read from clients (such as Outlook, Apple Mail, or your mobile device)
+not authenticated with GitLab. Images in emails appear broken and unavailable if
+the client is not authorized to GitLab.
+
+## Enable authorization checks for all media files
+
+Non-image attachments (including PDFs) always require authentication to be viewed.
+You can use this setting to extend this protection to image files.
+
+Prerequisite:
+
+- You must have the Maintainer or Owner role for the project.
+- Your project visibility settings must be **Private** or **Internal**.
+
+To configure authentication settings for all media files:
+
+1. On the top bar, select **Menu > Projects** and find your project.
+1. On the left sidebar, select **Settings > General**.
+1. Expand **Visibility, project features, permissions**.
+1. Scroll to **Project visibility** and select **Require authentication to view media files**.
+   You cannot select this option for projects with **Public** visibility.
 
 <!-- ## Troubleshooting
 
diff --git a/doc/security/webhooks.md b/doc/security/webhooks.md
index c3d445103c4..f2066ee4a42 100644
--- a/doc/security/webhooks.md
+++ b/doc/security/webhooks.md
@@ -74,7 +74,7 @@ allowlist:
 The allowed entries can be separated by semicolons, commas or whitespaces
 (including newlines) and be in different formats like hostnames, IP addresses and/or
 IP ranges. IPv6 is supported. Hostnames that contain Unicode characters should
-use [Internationalized Domain Names in Applications](https://www.icann.org/resources/pages/glossary-2014-02-04-en#i)
+use [Internationalized Domain Names in Applications](https://www.icann.org/en/icann-acronyms-and-terms/internationalized-domain-names-in-applications-en)
 (IDNA) encoding.
 
 The allowlist can hold a maximum of 1000 entries. Each entry can be a maximum of