Add latest changes from gitlab-org/gitlab@master

3 files changed, 14 insertions, 11 deletions

diff --git a/doc/user/compliance/license_scanning_of_cyclonedx_files/index.md b/doc/user/compliance/license_scanning_of_cyclonedx_files/index.md
index 5d7a689e610..05c939d4cae 100644
--- a/doc/user/compliance/license_scanning_of_cyclonedx_files/index.md
+++ b/doc/user/compliance/license_scanning_of_cyclonedx_files/index.md
@@ -11,7 +11,20 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/385176) in GitLab 16.4. Feature flags `license_scanning_sbom_scanner` and `package_metadata_synchronization` removed.
 
 NOTE:
-The legacy License Compliance analyzer was deprecated in GitLab 15.9 and removed in GitLab 16.3. To continue using GitLab for License Compliance, remove the License Compliance template from your CI/CD pipeline and add the [Dependency Scanning template](../../application_security/dependency_scanning/index.md#configuration). The Dependency Scanning template is now capable of gathering the required license information so it is no longer necessary to run a separate License Compliance job. The License Compliance CI/CD template should not be removed prior to verifying that the instance has been upgraded to a version that supports the new method of license scanning. To begin using the Dependency Scanner quickly at scale, you may set up a [scan execution policy](../../application_security/policies/scan-execution-policies.md) at the group level to enforce the SBOM-based license scan for all projects in the group. Then, you may remove the inclusion of the `Jobs/License-Scanning.gitlab-ci.yml` template from your CI/CD configuration. If you wish to continue using the legacy License Compliance feature, you can do so by setting the `LICENSE_MANAGEMENT_VERSION CI` variable to `4`. This variable can be set at the [project](../../../ci/variables/index.md#for-a-project), [group](../../../ci/variables/index.md#for-a-group) or [instance](../../../ci/variables/index.md#for-an-instance) level. This configuration change will allow you to continue using the existing version of License Compliance to generate [license scanning report](../../../ci/yaml/artifacts_reports.md#artifactsreportslicense_scanning) artifacts in your pipelines. However, since legacy license scanning support is being removed from our codebase, switching back to this legacy analyzer prevents other License Compliance features from working as expected, so this approach is not recommended. In addition to this, **bugs and vulnerabilities in this legacy analyzer will no longer be fixed.**
+The legacy License Compliance analyzer was deprecated in GitLab 15.9 and removed in GitLab 16.3.
+To continue using GitLab for License Compliance, remove the License Compliance template from your
+CI/CD pipeline and add the [Dependency Scanning template](../../application_security/dependency_scanning/index.md#configuration).
+The Dependency Scanning template is now capable of gathering the required license information so it
+is no longer necessary to run a separate License Compliance job. The License Compliance CI/CD
+template should not be removed prior to verifying that the instance has been upgraded to a version
+that supports the new method of license scanning. To begin using the Dependency Scanner quickly at
+scale, you may set up a [scan execution policy](../../application_security/policies/scan-execution-policies.md)
+at the group level to enforce the SBOM-based license scan for all projects in the group.
+Then, you may remove the inclusion of the `Jobs/License-Scanning.gitlab-ci.yml` template from your
+CI/CD configuration. If you wish to continue using the legacy License Compliance feature, you can do
+so by setting the `LICENSE_MANAGEMENT_VERSION CI` variable to `4`. This variable can be set at the
+[project](../../../ci/variables/index.md#for-a-project), [group](../../../ci/variables/index.md#for-a-group)
+or [instance](../../../ci/variables/index.md#for-an-instance) level.
 
 To detect the licenses in use, License Compliance relies on running the
 [Dependency Scanning CI Jobs](../../application_security/dependency_scanning/index.md),
diff --git a/doc/user/packages/container_registry/authenticate_with_container_registry.md b/doc/user/packages/container_registry/authenticate_with_container_registry.md
index c5773ba4fe3..ef1f675bad3 100644
--- a/doc/user/packages/container_registry/authenticate_with_container_registry.md
+++ b/doc/user/packages/container_registry/authenticate_with_container_registry.md
@@ -6,11 +6,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Authenticate with the container registry **(FREE ALL)**
 
-<!--- start_remove The following content will be removed on remove_date: '2023-11-22' -->
-WARNING:
-In GitLab 16.0 and later, [external authorization](../../../administration/settings/external_authorization.md) prevents personal access tokens and deploy tokens from accessing container and package registries and affects all users who use these tokens to access the registries. You can disable external authorization if you want to use personal access tokens and deploy tokens with the container or package registries.
-<!--- end_remove -->
-
 To authenticate with the container registry, you can use a:
 
 - [Personal access token](../../profile/personal_access_tokens.md).
diff --git a/doc/user/packages/package_registry/index.md b/doc/user/packages/package_registry/index.md
index e5e9cdf5c18..af099edc5f7 100644
--- a/doc/user/packages/package_registry/index.md
+++ b/doc/user/packages/package_registry/index.md
@@ -43,11 +43,6 @@ For information on how to create and upload a package, view the GitLab documenta
 
 ## Authenticate with the registry
 
-<!--- start_remove The following content will be removed on remove_date: '2023-11-22' -->
-WARNING:
-In GitLab 16.0 and later, [external authorization](../../../administration/settings/external_authorization.md) prevents personal access tokens and deploy tokens from accessing container and package registries and affects all users who use these tokens to access the registries. You can disable external authorization if you want to use personal access tokens and deploy tokens with the container or package registries.
-<!--- end_remove -->
-
 Authentication depends on the package manager being used. For more information, see the docs on the
 specific package format you want to use.