diff --git a/.gitignore b/.gitignore index 8a7e8fa16..7080279cf 100644 --- a/.gitignore +++ b/.gitignore @@ -1,3 +1,5 @@ .DS_Store .vscode package-lock.json +website/build.log +website/install.log diff --git a/website/blog/2025-10-24-dynamo-on-aks/index.md b/website/blog/2025-10-24-dynamo-on-aks/index.md index 262ea0de9..60fd812c2 100644 --- a/website/blog/2025-10-24-dynamo-on-aks/index.md +++ b/website/blog/2025-10-24-dynamo-on-aks/index.md @@ -7,7 +7,7 @@ authors: - sachi-desai - sertac-ozercan - rita-zhang -tags: ["dynamo-series", "ai", "gpu", "oss", "GB200"] +tags: ["dynamo-series", "ai", "gpu"] --- *This blog post is co-authored with @@ -28,6 +28,8 @@ play a crucial role by coordinating execution across nodes, managing memory resources efficiently, and accelerating data transfers between GPUs to keep latency low. + + However, software alone cannot solve these challenges. The underlying hardware must also support this level of scale and throughput. Rack-scale systems like [Azure ND GB200-v6](https://learn.microsoft.com/azure/virtual-machines/sizes/gpu-accelerated/nd-gb200-v6-series) diff --git a/website/blog/2025-11-18-azure-linux-gpu-on-aks/index.md b/website/blog/2025-11-18-azure-linux-gpu-on-aks/index.md index 10c6b5458..316f19c71 100644 --- a/website/blog/2025-11-18-azure-linux-gpu-on-aks/index.md +++ b/website/blog/2025-11-18-azure-linux-gpu-on-aks/index.md @@ -14,6 +14,8 @@ tags: Running GPU workloads on AKS enables scalable, automated data processing and AI applications across Windows, Ubuntu, or Azure Linux nodes. [Azure Linux](https://learn.microsoft.com/azure/aks/use-azure-linux), Microsoft’s minimal and secure OS, simplifies GPU setup with validated drivers and seamless integration, reducing operational efforts. This blog covers how AKS supports GPU nodes on various OS platforms and highlights the security and performance benefits of Azure Linux for GPU workloads. + + ### Unique challenges of GPU nodes Deploying a GPU workload isn’t just about picking the right VM size. There is also significant operational overhead that developers and platform engineers need to manage. diff --git a/website/blog/2025-11-19-nftables-in-kube-proxy/index.md b/website/blog/2025-11-19-nftables-in-kube-proxy/index.md index 1330834ac..e86d8273a 100644 --- a/website/blog/2025-11-19-nftables-in-kube-proxy/index.md +++ b/website/blog/2025-11-19-nftables-in-kube-proxy/index.md @@ -3,15 +3,15 @@ title: "Preview: nftables support for kube-proxy in Azure Kubernetes Service (AK description: "Learn about how to use the nftables mode of kube-proxy on AKS." date: 2025-11-19 authors: [jack-ma] -tags: - - nftables - - kube-proxy +tags: [ networking ] --- ## Summary We're announcing the preview availability of **nftables** mode for kube-proxy in Azure Kubernetes Service (AKS). This feature was requested in [GitHub issue #5061](https://github.com/Azure/AKS/issues/5061) and is now aligned with the upstream Kubernetes GA release of the nftables backend. + + ## Background Kubernetes 1.33 introduced **nftables** as a fully supported kube-proxy mode. It serves as the modern replacement for iptables, offering a more efficient rule model and improved performance characteristics on newer Linux kernels. As highlighted by the upstream project, nftables reduces rule churn and avoids the scaling and latency limitations seen in large clusters using iptables. diff --git a/website/blog/2026-05-11-kernel-lpe-cve-patching-at-scale-with-fleet-manager/index.md b/website/blog/2026-05-11-kernel-lpe-cve-patching-at-scale-with-fleet-manager/index.md new file mode 100644 index 000000000..e302b0a04 --- /dev/null +++ b/website/blog/2026-05-11-kernel-lpe-cve-patching-at-scale-with-fleet-manager/index.md @@ -0,0 +1,450 @@ +--- +title: "Apply Copy Fail and DirtyFrag CVE mitigations at-scale using Azure Kubernetes Fleet Manager" +description: "See how to apply mitigations for CVE-2026-31431 (Copy Fail) and CVE-2026-43284 / CVE-2026-43500 (DirtyFrag) across AKS clusters using Azure Kubernetes Fleet Manager with a DaemonSet and node image upgrades." +authors: [simon-waight] +tags: [security, fleet-manager, kube-fleet] +date: 2026-05-11 +--- + +This post shows how to use Azure Kubernetes Fleet Manager to simplify the safe rollout of mitigations for [CVE-2026-31431](https://github.com/advisories/GHSA-2274-3hgr-wxv6) ("Copy Fail") and [CVE-2026-43284](https://github.com/advisories/GHSA-mmw8-mxmc-8w2r) / CVE-2026-43500 ("DirtyFrag") across multiple AKS clusters. This vulnerability allows a container to escalate to root on the node and impacts AKS Linux nodes until mitigations are applied. Existing nodes require either a node image upgrade or a self-service DaemonSet mitigation. + + + +The approaches covered in this post apply mitigations as follows: + +1. [Immediate mitigation](#immediate-mitigation---daemonset-rollout): deploy a DaemonSet using Fleet Manager resource placement. Best for clusters where a node image upgrade can't yet be applied. +2. [Permanent mitigation](#permanent-mitigation---node-image-upgrade): upgrade node images using Fleet Manager update runs. Applies patches when new node image version is available in the cluster's region. + +The original AKS advisory and detailed mitigation guide for per-cluster application can be found in [GitHub Issue 5753](https://github.com/Azure/AKS/issues/5753). + +## Before you begin + +- Azure CLI version 2.86.0 or later installed ([instructions](https://learn.microsoft.com/cli/azure/install-azure-cli?view=azure-cli-latest)). +- Fleet Manager Azure CLI extension installed and updated. + +```bash +az extension add --name fleet +az extension update --name fleet +``` + +- A Fleet Manager with a hub cluster ([instructions](https://learn.microsoft.com/azure/kubernetes-fleet/quickstart-create-fleet-and-members?pivots=public-hub)). You can add a hub cluster if you are already using Fleet without one. +- AKS clusters added as member clusters with update group and member labels set. Groups and labels are required for controlling the rollout via placement and update runs. + +```bash +az fleet member create \ + --resource-group $GROUP \ + --fleet-name $FLEET \ + --name $MEMBER_CLUSTER_NAME \ + --update-group canary \ + --labels upgroup=canary +``` + +- kubectl configured for the hub cluster ([instructions](https://learn.microsoft.com/azure/kubernetes-fleet/access-fleet-hub-cluster-kubernetes-api?pivots=public-hub)). + +## Immediate mitigation - DaemonSet rollout + +:::important +Make sure to review the steps in [before you begin](#before-you-begin), especially adding labels to member clusters. +::: + +For immediate protection, apply a DaemonSet that disables the vulnerable kernel module. The DaemonSet is deployed into its own Namespace on each cluster, making it easy to discern intent and easier to distribute across clusters. Given how DaemonSets function, the protection is applied to the node, even though we don't use the `kube-system` Namespace as shown in the [original AKS mitigation guide](https://github.com/Azure/AKS/issues/5753). + +Fleet Manager's [cluster-scoped resource placement](https://learn.microsoft.com/azure/kubernetes-fleet/quickstart-resource-propagation?tabs=azure-cli) enables: + +- Multi-cluster selection for a resource via [ClusterResourcePlacement](https://learn.microsoft.com/azure/kubernetes-fleet/quickstart-resource-propagation?tabs=azure-cli#use-clusterresourceplacement-to-place-resources-onto-member-clusters). +- Controlled rollout of the resource via [ClusterStagedUpdateRun](https://learn.microsoft.com/azure/kubernetes-fleet/howto-staged-update-run?pivots=cluster-scope). + +### Step 1: Create the mitigation Namespace and DaemonSet + +Create the `01-kernel-lpe-mitigate.yaml` file with the following contents. The DaemonSet blocks vulnerable modules covered by the CVEs. + +```yaml +apiVersion: v1 +kind: Namespace +metadata: + name: kernel-lpe-cve-mitigate-ns +--- +apiVersion: apps/v1 +kind: DaemonSet +metadata: + name: kernel-lpe-mitigate + namespace: kernel-lpe-cve-mitigate-ns + labels: + app: kernel-lpe-mitigate + purpose: security-mitigation +spec: + selector: + matchLabels: + app: kernel-lpe-mitigate + template: + metadata: + labels: + app: kernel-lpe-mitigate + spec: + hostPID: true + priorityClassName: system-node-critical + nodeSelector: + kubernetes.io/os: linux + tolerations: + - operator: Exists + containers: + - name: mitigate + image: mcr.microsoft.com/cbl-mariner/busybox:2.0 + command: + - /bin/sh + - -c + - | + echo "=== Kernel LPE Module Mitigation ===" + echo "Covers: CVE-2026-31431 (algif_aead), DirtyFrag (esp4/esp6/rxrpc)" + + MODULES="algif_aead esp4 esp6 rxrpc" + + for mod in $MODULES; do + if ! grep -qs "install ${mod} /bin/false" /host/etc/modprobe.d/*.conf 2>/dev/null; then + printf "install %s /bin/false\nblacklist %s\n" "$mod" "$mod" >> /host/etc/modprobe.d/disable-kernel-lpe.conf + echo "Blocked ${mod}" + else + echo "${mod} already blocked" + fi + + if chroot /host grep -q "^${mod} " /proc/modules 2>/dev/null; then + if chroot /host modprobe -r "$mod" 2>/dev/null; then + echo "Unloaded ${mod}" + else + echo "WARNING: Could not unload ${mod} (in use). Reboot node." + fi + fi + done + + echo "=== Mitigation complete. Sleeping ===" + sleep infinity + resources: + requests: + cpu: 10m + memory: 16Mi + limits: + memory: 32Mi + securityContext: + privileged: true + volumeMounts: + - name: host-root + mountPath: /host + volumes: + - name: host-root + hostPath: + path: / + type: Directory +``` + +Stage the mitigation namespace and DaemonSet on the Fleet Manager hub cluster. + +```bash +kubectl apply -f 01-kernel-lpe-mitigate.yaml +``` + +:::note +The DaemonSet is not instantiated (0 pods are scheduled) on the Fleet Manager hub cluster. This is expected behavior. +::: + +### Step 2: Create a ClusterResourcePlacement + +Create a placement manifest `02-fleet-pick-clusters-mitigation.yaml` that selects all Fleet Manager member clusters (`PickAll`) as suitable to receive the Namespace and its DaemonSet. We set the strategy to `External` so we can define and control the rollout order for clusters, which we will do in following steps. + +```yaml +apiVersion: placement.kubernetes-fleet.io/v1 +kind: ClusterResourcePlacement +metadata: + name: kernel-lpe-cve-mit-ns-place +spec: + resourceSelectors: + - group: "" + version: v1 + kind: Namespace + name: kernel-lpe-cve-mitigate-ns + policy: + placementType: PickAll + strategy: + type: External +``` + +Apply the placement on Fleet Manager hub cluster. + +```bash +kubectl apply -f 02-fleet-pick-clusters-mitigation.yaml +``` + +You can validate how many clusters will receive the mitigation using this command. + +```bash +kubectl get clusterresourceplacement kernel-lpe-cve-mit-ns-place -o jsonpath="{.status.conditions[?(@.type=='ClusterResourcePlacementScheduled')].message}" +``` + +The message in the response shows how many clusters were selected. + +```output +found all cluster needed as specified by the scheduling policy, found 2 cluster(s) +``` + +### Step 3: Create a ClusterStagedUpdateStrategy + +A strategy is used to define the rollout order and soak duration per rollout stage. Note that all selected clusters must be in a stage. This is determined by the labels set of the cluster when it was added to the Fleet Manager. + +In this sample `03-fleet-mitigation-rollout-strategy.yaml` we have three stages, with a 4 hour soak time between each stage. You can also add approvals if required. + +```yaml +apiVersion: placement.kubernetes-fleet.io/v1 +kind: ClusterStagedUpdateStrategy +metadata: + name: kernel-lpe-cve-mit-ds-strategy +spec: + stages: + - name: stage1 + labelSelector: + matchLabels: + upgroup: canary + afterStageTasks: + - type: TimedWait + waitTime: 4h + maxConcurrency: 1 + - name: stage2 + labelSelector: + matchLabels: + upgroup: nonprod + afterStageTasks: + - type: TimedWait + waitTime: 4h + maxConcurrency: 1 + - name: stage3 + labelSelector: + matchLabels: + upgroup: prod +``` + +Apply the strategy on Fleet Manager hub cluster. + +```bash +kubectl apply -f 03-fleet-mitigation-rollout-strategy.yaml +``` + +### Step 4: Start rollout + +Finally, create a ClusterStagedUpdateRun `04-fleet-mitigation-rollout-run.yaml` to begin the rollout. + +:::note +To start the rollout later, set `state` to `Initialize`. You can patch the resource to `Run` to begin rollout (see below). +::: + +```yaml +apiVersion: placement.kubernetes-fleet.io/v1 +kind: ClusterStagedUpdateRun +metadata: + name: kernel-lpe-cve-mit-ds-rollout +spec: + placementName: kernel-lpe-cve-mit-ns-place + stagedRolloutStrategyName: kernel-lpe-cve-mit-ds-strategy + state: Run +``` + +Apply the update run on Fleet Manager hub cluster. If you have `Run` as the state, the rollout begins. + +```bash +kubectl apply -f 04-fleet-mitigation-rollout-run.yaml +``` + +### Step 5: Monitor and control rollout + +Use the following command to retrieve the status of the rollout. Inspect the `conditions` and `stageStatuses` arrays to review progress. + +```bash +kubectl get clusterstagedupdaterun kernel-lpe-cve-mit-ds-rollout -o yaml +``` + +:::note +You can also use the preview version of [KubeFleet's Headlamp plugin](https://github.com/kubefleet-dev/kubefleet-headlamp-plugin) to help monitor and control the rollout. Connect it to the Fleet Manager hub cluster to use. +::: + +If you want to stop the rollout, you can patch the update run: + +```bash +kubectl patch clusterstagedupdaterun kernel-lpe-cve-mit-ds-rollout --type merge -p '{"spec":{"state":"Stop"}}' +``` + +Restart the rollout by patching the update run: + +```bash +kubectl patch clusterstagedupdaterun kernel-lpe-cve-mit-ds-rollout --type merge -p '{"spec":{"state":"Run"}}' +``` + +### Step 6: Validate mitigation is applied + +Select clusters in your fleet that have received the mitigation and run the following check. + +```bash +kubectl logs -n kernel-lpe-cve-mitigate-ns -l app=kernel-lpe-mitigate +``` + +If the mitigation is applied successfully you should see. + +```output +=== Kernel LPE Module Mitigation === +Covers: CVE-2026-31431 (algif_aead), DirtyFrag (esp4/esp6/rxrpc) +Blocked algif_aead +Blocked esp4 +Blocked esp6 +Blocked rxrpc +=== Mitigation complete. Sleeping === +``` + +:::note +In some cases where the module is in use, the node will require a reboot. The log message will indicate this is required. +::: + +### Step 7: Roll back or remove + +If issues occur, or the DaemonSet is no longer required as the node image has been updated to a permanently patched release, you can remove the mitigation DaemonSet by deleting the ClusterResourcePlacement on the Fleet Manager hub cluster. + +```bash +kubectl delete clusterresourceplacement kernel-lpe-cve-mit-ns-place +``` + +### DaemonSet Rollout Outcome + +- Immediate mitigation applied across clusters via DaemonSet. +- Controlled rollout reduces risk, allows testing on clusters in batches. +- No node reboot required when module not in use. + +## Permanent mitigation - node image upgrade + +:::important + +- Make sure to review the steps in [before you begin](#before-you-begin), especially adding update groups to member clusters. + +- Depending on the regional spread of your clusters, it is possible that the update run may pause for periods as it waits for the node image to be published to a region. This is expected behavior. You can apply the DaemonSet to your clusters to ensure they are protected while waiting for the updated node image to be available. + +::: + +Once AKS provides a permanent mitigation via updated node images you can use Fleet Manager update runs to update the node image across your clusters. + +Fleet Manager's [safe multi-cluster updates](https://learn.microsoft.com/azure/kubernetes-fleet/concepts-update-orchestration) feature enables: + +- Application of consistent node image across clusters using the [Node Image channel](https://learn.microsoft.com/azure/kubernetes-fleet/concepts-update-orchestration#nodeimage-channel). +- Controlled rollout of the node image update via [Update Strategies](https://learn.microsoft.com/azure/kubernetes-fleet/update-create-update-strategy?tabs=azure-portal). + +### Step 1: Define an update strategy + +An update strategy defines the order in which clusters will receive the node image update. Strategies are defined using a simple JSON format as shown next. + +In the following sample we have one group of clusters per stage, with clusters grouped based on the `update-group` on the member cluster. We continue with the 4 hour soak time and have a 100% concurrency which allows up to 50 clusters to update at once. You can also set these up via the Azure portal if desired. + +```json +{ + "stages": [ + { + "name": "stage-1", + "maxConcurrency": "100%", + "groups": [ + { + "name": "canary", + "maxConcurrency": "100%" + } + ], + "afterStageWaitInSeconds": 14400 + }, + { + "name": "stage-2", + "maxConcurrency": "100%", + "groups": [ + { + "name": "nonprod", + "maxConcurrency": "100%" + } + ], + "afterStageWaitInSeconds": 14400 + }, + { + "name": "stage-3", + "maxConcurrency": "100%", + "groups": [ + { + "name": "prod", + "maxConcurrency": "100%" + } + ] + } + ] +} +``` + +Save the strategy as a file (`nodeimage-strategy.json`) and then submit via the Azure CLI to create the Strategy ready for use in Fleet Manager. + +```bash +export GROUP=resource-group +export FLEET=fleet-name +export STRATEGY=copyfail-mitigation-strategy + +az fleet updatestrategy create \ + --resource-group $GROUP \ + --fleet-name $FLEET \ + --name $STRATEGY \ + --stages nodeimage-strategy.json +``` + +:::note +To update a strategy after you have created it, make changes to the JSON file and simply call the `create` command again. +::: + +### Step 2: Create an update run for node image upgrades + +Next, let's create a new update run for updating just the node image on selected clusters. + +The update run won't automatically start, so you can create this once AKS releases the patched node images, then start the run at a later time that suits your schedule. + +```bash +az fleet updaterun create \ + --resource-group $GROUP \ + --fleet-name $FLEET \ + --name copyfail-nodeimage-update \ + --upgrade-type NodeImageOnly \ + --update-strategy-name $STRATEGY +``` + +### Step 3: Start the update run + +Once you are satisfied that all clusters to be upgraded are included, you can start the update run. + +```bash +az fleet updaterun start \ + --fleet-name $FLEET \ + --resource-group $GROUP \ + --name copyfail-nodeimage-update +``` + +### Step 4: Monitor progress + +You can review the status using the Azure CLI shown below, or use the [Azure portal's web interface](https://learn.microsoft.com/azure/kubernetes-fleet/update-orchestration?tabs=azure-portal#manage-an-update-run) to view the rollout graphically. + +```bash +az fleet updaterun show \ + --resource-group $GROUP \ + --fleet-name $FLEET \ + --name copyfail-nodeimage-update +``` + +### Node Image Upgrade Outcome + +- All nodes are updated to the patched node image. +- DaemonSet no longer required and can be removed. + +## Summary and next steps + +In this post we've looked at the multiple ways in which Azure Kubernetes Fleet Manager can help you safely apply mitigations for the Copy Fail CVE across all your clusters. + +Fleet Manager continues to add new capabilities regularly, with the goal of simplifying at-scale Kubernetes cluster management for everyone. + +Here's some recommended next steps: + +- [Review AKS Advisory and Mitigation for CVE-2026-31431 (Copy Fail)](https://github.com/Azure/AKS/issues/5753). +- [Learn more about Fleet Manager Safe Multi-cluster Updates](https://learn.microsoft.com/azure/kubernetes-fleet/concepts-update-orchestration). +- [Learn more about Fleet Manager resource placement](https://learn.microsoft.com/azure/kubernetes-fleet/concepts-resource-placement?pivots=cluster-scope). +- [View the Fleet Manager public roadmap](https://aka.ms/kubernetes-fleet/roadmap). Feature requests always welcome! +- [Join a KubeFleet community call](https://aka.ms/kubefleet/commcalls) to learn about Fleet Manager's open source resource placement. diff --git a/website/blog/authors.yml b/website/blog/authors.yml index 3eee6a883..a6fbb3b45 100644 --- a/website/blog/authors.yml +++ b/website/blog/authors.yml @@ -526,3 +526,13 @@ kevin-thomas: socials: linkedin: kevin-krupa-thomas github: kevinkrp93 + +simon-waight: + name: Simon Waight + title: Product Manager for Azure Kubernetes Fleet Manager + url: https://www.linkedin.com/in/simon-waight/ + image_url: https://github.com/sjwaight.png + page: true + socials: + linkedin: simon-waight + github: sjwaight diff --git a/website/blog/tags.yml b/website/blog/tags.yml index 5789a35e6..10c8c40d2 100644 --- a/website/blog/tags.yml +++ b/website/blog/tags.yml @@ -167,6 +167,11 @@ flatcar-container-linux: permalink: /flatcar-container-linux description: Flatcar Container Linux distribution available on AKS. +fleet-manager: + label: Azure Kubernetes Fleet Manager + permalink: /fleet-manager + description: Azure Kubernetes Fleet Manager for multi-cluster management and governance. + flux: label: Flux permalink: /flux @@ -223,9 +228,9 @@ kaito: description: KAITO project usage for model fine-tuning, inference, and RAG on AKS. kube-fleet: - label: Kube-Fleet + label: KubeFleet permalink: /kube-fleet - description: Using Kube-Fleet for multi-cluster application deployment and management with AKS. + description: Using KubeFleet for multi-cluster application deployment and management with AKS. kubevirt: label: KubeVirt @@ -326,6 +331,7 @@ scheduler: label: Scheduler permalink: /scheduler description: Scheduling workloads and managing scheduling constraints on AKS. + security: label: Security permalink: /security diff --git a/website/docusaurus.config.ts b/website/docusaurus.config.ts index bcacc0c82..4aadd15bd 100644 --- a/website/docusaurus.config.ts +++ b/website/docusaurus.config.ts @@ -27,7 +27,6 @@ const config: Config = { projectName: 'aks-blog', // Usually your repo name. onBrokenLinks: 'throw', - onBrokenMarkdownLinks: 'warn', // Even if you don't use internationalization, you can use this field to set // useful metadata like html lang. For example, if your site is Chinese, you @@ -75,6 +74,9 @@ const config: Config = { markdown: { mermaid: true, + hooks: { + onBrokenMarkdownLinks: 'warn', + }, }, themes: ['@docusaurus/theme-mermaid'], themeConfig: { diff --git a/website/package-lock.json b/website/package-lock.json index 84ae3511a..48b951c1b 100644 --- a/website/package-lock.json +++ b/website/package-lock.json @@ -6883,12 +6883,15 @@ "license": "MIT" }, "node_modules/baseline-browser-mapping": { - "version": "2.8.12", - "resolved": "https://registry.npmjs.org/baseline-browser-mapping/-/baseline-browser-mapping-2.8.12.tgz", - "integrity": "sha512-vAPMQdnyKCBtkmQA6FMCBvU9qFIppS3nzyXnEM+Lo2IAhG4Mpjv9cCxMudhgV3YdNNJv6TNqXy97dfRVL2LmaQ==", + "version": "2.10.27", + "resolved": "https://registry.npmjs.org/baseline-browser-mapping/-/baseline-browser-mapping-2.10.27.tgz", + "integrity": "sha512-zEs/ufmZoUd7WftKpKyXaT6RFxpQ5Qm9xytKRHvJfxFV9DFJkZph9RvJ1LcOUi0Z1ZVijMte65JbILeV+8QQEA==", "license": "Apache-2.0", "bin": { - "baseline-browser-mapping": "dist/cli.js" + "baseline-browser-mapping": "dist/cli.cjs" + }, + "engines": { + "node": ">=6.0.0" } }, "node_modules/batch": { @@ -7207,9 +7210,9 @@ } }, "node_modules/caniuse-lite": { - "version": "1.0.30001748", - "resolved": "https://registry.npmjs.org/caniuse-lite/-/caniuse-lite-1.0.30001748.tgz", - "integrity": "sha512-5P5UgAr0+aBmNiplks08JLw+AW/XG/SurlgZLgB1dDLfAw7EfRGxIwzPHxdSCGY/BTKDqIVyJL87cCN6s0ZR0w==", + "version": "1.0.30001792", + "resolved": "https://registry.npmjs.org/caniuse-lite/-/caniuse-lite-1.0.30001792.tgz", + "integrity": "sha512-hVLMUZFgR4JJ6ACt1uEESvQN1/dBVqPAKY0hgrV70eN3391K6juAfTjKZLKvOMsx8PxA7gsY1/tLMMTcfFLLpw==", "funding": [ { "type": "opencollective",