Sync from docker/docs@eec987c by PCIT

.github/vale/Vocab/Technology/accept.txt

@@ -117,6 +117,7 @@ macvlan
 mfsymlinks
 minikube
 musl
+npm
 osquery
 osxfs
 paravirtualization

.github/workflows/validate-upstream.yml

@@ -82,7 +82,7 @@ jobs:
           targets: validate-upstream
           set: |
             *.cache-from=type=gha,scope=docs-upstream
-            *.cache-to=type=gha,scope=docs-upstream,mode=max
+            *.cache-to=type=gha,scope=docs-upstream
         env:
           UPSTREAM_MODULE_NAME: ${{ inputs.module-name }}
           UPSTREAM_REPO: ${{ github.repository }}

content/build/hydrobuild.md

@@ -74,9 +74,9 @@ local Docker configuration.
    $ docker buildx create --driver cloud <ORG>/default
    ```
 
-   Replace `<ORG>` with the Docker Hub namespace of your Docker organization.
+   Replace `ORG` with the Docker Hub namespace of your Docker organization.
 
-This creates a builder named `cloud-<org>-default`.
+This creates a builder named `cloud-ORG-default`.
 
 {{< /tab >}}
 {{< tab name="GUI" >}}
@@ -105,7 +105,7 @@ To build using Hydrobuild, invoke a build command and specify the name of the
 builder using the `--builder` flag.
 
 ```console
-$ docker buildx build --builder cloud-<org>-default --tag <org>/<image> .
+$ docker buildx build --builder cloud-<ORG>-default --tag <IMAGE> .
 ```
 
 If you want to use Hydrobuild without having to specify the `--builder` flag
@@ -117,7 +117,7 @@ each time, you can set it as the default builder.
 Run the following command:
 
 ```console
-$ docker buildx use cloud-<org>-default --global
+$ docker buildx use cloud-<ORG>-default --global
 ```
 
 {{< /tab >}}
@@ -153,19 +153,19 @@ Loading the build result for multi-platform images is not supported. Use the
 the output to a registry.
 
 ```console
-$ docker buildx build --builder cloud-<org>-default \
+$ docker buildx build --builder cloud-<ORG>-default \
   --platform linux/amd64,linux/arm64 \
-  --tag <org>/<image> \
+  --tag <IMAGE> \
   --push .
 ```
 
 If you want to build with a tag, but you don't want to load the results to your
-local image store, you export the build results to the build cache only:
+local image store, you can export the build results to the build cache only:
 
 ```console
-$ docker buildx build --builder cloud-<org>-default \
+$ docker buildx build --builder cloud-<ORG>-default \
   --platform linux/amd64,linux/arm64 \
-  --tag <org>/<image> \
+  --tag <IMAGE> \
   --output type=cacheonly .
 ```
 
@@ -175,9 +175,9 @@ To run multi-platform builds, you must specify all of the platforms that you
 want to build for using the `--platform` flag.
 
 ```console
-$ docker buildx build --builder cloud-<org>-default \
+$ docker buildx build --builder cloud-<ORG>-default \
   --platform linux/amd64,linux/arm64 \
-  --tag <org>/<image> \
+  --tag <IMAGE> \
   --push .
 ```
 
@@ -235,12 +235,12 @@ jobs:
         with:
           version: "lab:latest"
           driver: cloud
-          endpoint: "<org>/default"
+          endpoint: "<ORG>/default"
       - name: Build and push
         uses: docker/build-push-action@v5
         with:
           context: .
-          tags: "<org>/<image>"
+          tags: "<IMAGE>"
           # For pull requests, export results to the build cache.
           # Otherwise, push to a registry.
           outputs: ${{ github.event_name == 'pull_request' && 'type=cacheonly' || 'type=registry,push=true' }}
@@ -268,13 +268,13 @@ jobs:
           chmod a+x ~/.docker/cli-plugins/docker-buildx
 
       - run: echo "$DOCKER_PASS" | docker login --username $DOCKER_USER --password-stdin
-      - run: docker buildx create --use --driver cloud "<org>/default"
+      - run: docker buildx create --use --driver cloud "<ORG>/default"
 
       - run: |
           docker buildx build \
           --platform linux/amd64,linux/arm64 \
           --push \
-          --tag "<org>/<image>" .
+          --tag "<IMAGE>" .
 
   # Build an image and discard the result
   build_cache:
@@ -291,7 +291,7 @@ jobs:
           chmod a+x ~/.docker/cli-plugins/docker-buildx
 
       - run: echo "$DOCKER_PASS" | docker login --username $DOCKER_USER --password-stdin
-      - run: docker buildx create --use --driver cloud "<org>/default"
+      - run: docker buildx create --use --driver cloud "<ORG>/default"
 
       - run: |
           docker buildx build \
@@ -327,7 +327,7 @@ chmod a+x ~/.docker/cli-plugins/docker-buildx
 echo "$DOCKER_PASS" | docker login --username $DOCKER_USER --password-stdin
 
 # Connect to your builder and set it as the default builder
-docker buildx create --use --driver cloud "<org>/default"
+docker buildx create --use --driver cloud "<ORG>/default"
 
 # Cache-only image build
 docker buildx build \
@@ -339,7 +339,7 @@ docker buildx build \
 docker buildx build \
     --platform linux/amd64,linux/arm64 \
     --push \
-    --tag "<org>/<image>" \
+    --tag "<IMAGE>" \
     .
 ```
 
@@ -459,7 +459,7 @@ If you want to stop using Hydrobuild, and remove it from your system, remove
 the builder using the `docker buildx rm` command.
 
 ```console
-$ docker buildx rm cloud-<org>-default
+$ docker buildx rm cloud-<ORG>-default
 ```
 
 This doesn't deprovision the builder backend, it only removes the builder from

content/desktop/release-notes.md

@@ -24,7 +24,7 @@ Take a look at the [Docker Public Roadmap](https://github.com/docker/roadmap/pro
 
 For frequently asked questions about Docker Desktop releases, see [FAQs](faqs/releases.md).
 
-# 4.24.2
+## 4.24.2
 
 {{< release-date date="2023-10-12" >}}
 
@@ -37,7 +37,7 @@ For frequently asked questions about Docker Desktop releases, see [FAQs](faqs/re
 - Fixed a bug where Docker Desktop would send multiple requests to `notify.bugsnag.com`. Fixes [docker/for-win#13722](https://github.com/docker/for-win/issues/13722).
 - Fixed a performance regression for PyTorch.
 
-# 4.24.1
+## 4.24.1
 
 {{< release-date date="2023-10-04" >}}
 
@@ -49,7 +49,7 @@ For frequently asked questions about Docker Desktop releases, see [FAQs](faqs/re
 
 - Fixed a bug on Docker Desktop for Windows where the Docker Dashboard wouldn't display container logs correctly. Fixes [docker/for-win#13714](https://github.com/docker/for-win/issues/13714).
 
-# 4.24.0
+## 4.24.0
 
 {{< release-date date="2023-09-28" >}}
 

content/docker-hub/api/latest.yaml

@@ -83,7 +83,10 @@ tags:
       The Advanced Image Management API endpoints allow you to manage Docker
       images across all repositories.
 
-      For more information, see [Advanced Image Management dashboard](https://docs.docker.com/docker-hub/image-management/).
+      **<span style="color: red;">Deprecated</span>**: Advanced Image
+      Management is deprecated, and scheduled for removal on November 15th, 2023.
+
+      For more information, see [Deprecation of Advanced Image Management](https://github.com/docker/roadmap/issues/534)
   - name: audit-logs
     x-displayName: Audit Logs
     description: |
@@ -307,6 +310,7 @@ paths:
           $ref: "#/components/responses/NotFound"
   /v2/namespaces/{namespace}/repositories/{repository}/images-summary:
     get:
+      deprecated: true
       tags:
         - images
       summary: Get summary of repository's images
@@ -353,6 +357,7 @@ paths:
                 $ref: "#/components/schemas/ErrorResponse"
   /v2/namespaces/{namespace}/repositories/{repository}/images:
     get:
+      deprecated: true
       tags:
         - images
       summary: Get details of repository's images
@@ -446,6 +451,7 @@ paths:
                 $ref: "#/components/schemas/ErrorResponse"
   /v2/namespaces/{namespace}/repositories/{repository}/images/{digest}/tags:
     get:
+      deprecated: true
       tags:
         - images
       summary: Get image's tags
@@ -503,6 +509,7 @@ paths:
                 $ref: "#/components/schemas/ErrorResponse"
   /v2/namespaces/{namespace}/delete-images:
     post:
+      deprecated: true
       tags:
         - images
       summary: Delete images

content/docker-hub/image-management.md

@@ -4,14 +4,19 @@ keywords: dashboard, images, image management, inactive
 title: Advanced Image Management dashboard
 ---
 
-> **Note**
+> **Deprecated**
 >
-> Image management requires a
-> [Docker Pro, Team, or Business subscription](../subscription/index.md).
+> The Advanced Image Management dashboard and API are deprecated, and scheduled
+> for removal on November 15th, 2023. You can continue to use the **Tags** in
+> Docker Hub to manage tags for your repository.
+>
+> For more information, see [Deprecation of Advanced Image Management](https://github.com/docker/roadmap/issues/534)
+{ .warning }
 
 Advanced Image Management allows you to manage Docker images across all repositories and streamline storage in Docker Hub.
 
 It provides:
+
 - A snapshot of your existing images
 - Allows you to view, sort, and filter images by tags, activity status, and date
 - Contains options to clean up your workspace by deleting images that are no longer required
@@ -25,7 +30,7 @@ It provides:
 
 ## Understand image activity status and tags
 
-An image retains its 'active' status if it's pulled or pushed in the last month. If there isn’t any activity on the image in the last month, it's considered 'inactive'. 
+An image retains its 'active' status if it's pulled or pushed in the last month. If there isn’t any activity on the image in the last month, it's considered 'inactive'.
 
 The dashboard also displays the old versions of images you have pushed. When you push an image to Docker Hub, you push a manifest, which is a list of all the layers of your image and the layers themselves. When you update an existing tag, only the new layers are pushed along with the new manifest which references the new layers. This new manifest gets the tag you specify when you push the image, such as `myNamespace/mytag:latest`. This doesn't remove the old manifests or the unique layers referenced by them from Hub. You can still use and reference these using the digest of the manifest if you know the SHA.
 
@@ -37,4 +42,4 @@ For example, let's assume that Image A is tagged as ‘latest’. You push anoth
 
 ## Advanced Image Management API
 
-The Advanced Image Management API endpoints allow you to manage Docker images across all repositories. For more information, see [Advanced Image management API](./api/latest.md).
+The Advanced Image Management API endpoints allow you to manage Docker images across all repositories. For more information, see [Advanced Image management API](./api/latest.md).

content/scout/advisory-db-sources.md

@@ -21,9 +21,10 @@ advisory database and CVE-to-package matching service works.
 Docker Scout creates and maintains its vulnerability database by ingesting and
 collating vulnerability data from multiple sources continuously. These
 sources include many recognizable package repositories and trusted security
-trackers, such as:
+trackers, including:
 
 - [Alpine secdb](https://secdb.alpinelinux.org/)
+- [AlmaLinux Security Advisory](https://errata.almalinux.org/)
 - [Amazon Linux Security Center](https://alas.aws.amazon.com/)
 - [CISA Known Exploited Vulnerability
   Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)
@@ -39,29 +40,30 @@ trackers, such as:
 - [Python Packaging Advisory
   Database](https://github.com/pypa/advisory-database)
 - [RedHat Security Data](https://www.redhat.com/security/data/metrics/)
+- [Rocky Linux Security Advisory](https://errata.rockylinux.org/)
 - [RustSec Advisory Database](https://github.com/rustsec/advisory-db)
 - [SUSE Security CVRF](http://ftp.suse.com/pub/projects/security/cvrf/)
 - [Ubuntu CVE Tracker](https://people.canonical.com/~ubuntu-security/cve/)
 - [Wolfi Security Feed](https://packages.wolfi.dev/os/security.json)
 - [Chainguard Security Feed](https://packages.cgr.dev/chainguard/security.json)
 
-Docker Scout correlates this data by making a full inventory of a container
-image and storing that inventory in a [software bill of materials
-(SBOM)](https://ntia.gov/sites/default/files/publications/sbom_at_a_glance_apr2021_0.pdf).
+Docker Scout correlates the vulnerability data from these advisories with the
+Software Bill of Materials (SBOM) of container images to detect what
+vulnerabilities affect an image. The SBOM summarizes the contents of an image,
+and Docker Scout stores the SBOM in its database.
 
-The SBOM summarizes the contents of the image and how the contents got there
-meaning that when there is information about a new vulnerability, Docker Scout
-correlates it with the SBOM. If Docker Scout finds a match for a vulnerability,
-it can identify the artifact that’s now vulnerable, why, and where it’s in use.
+When there is information about a new vulnerability, Docker Scout correlates
+the vulnerable package with the SBOMs in the database to identify affected
+images.
 
-When a customer enrolls with Docker Scout, the organization receives their own
-instance of the database. This database tracks timestamped metadata about your
+When you enable Docker Scout for your organization, you receive your own
+instance of the database. The database tracks timestamped metadata about your
 images that Docker Scout can then match to CVEs. Find more details on how this
 works in the [image analysis page](./image-analysis.md).
 
-Docker Scout is ideal for analyzing images in Docker Desktop and Docker Hub, but
-the flexibility of the approach also means it can integrate with other systems,
-see [Integrating Docker Scout with other systems](./integrations/index.md).
+Docker Scout image analysis integrates seamlessly with Docker Desktop and
+Docker Hub, and you can also enable integrations with other systems, see
+[Integrating Docker Scout with other systems](./integrations/index.md).
 
 ## How Docker Scout makes more precise matches
 
@@ -77,7 +79,7 @@ cpe:<cpe_version>:<part>:<vendor>:<product>:<version>:<update>:<edition>:<langua
 ```
 
 For example `cpe:*:*:*:calendar:*:*:*:*:*:*:*` returns a match on anything with
-the product name “calendar”. If there is a vulnerability present in an NPM
+the product name “calendar”. If there is a vulnerability present in an npm
 package, this CPE match would also return packages and modules for all other
 languages too.