Vendor CDN blocked by the firewall

The manifest is fine. The package resolves. Then the download fails, because winget install fetches the installer from whatever host the vendor put in the manifest — and your egress policy has never heard of it.

Why an allowlist does not scale here

Every package points somewhere different, and vendors move. Allowlisting per-vendor download hosts means a list that grows with your catalog, breaks without warning when a vendor changes CDN, and gets a firewall change request attached to every new application.

It also means the thing your endpoints install is fetched, at install time, from a host you do not control. Which is a supply-chain question as much as a connectivity one.

Serve the bytes yourself

When a package is admitted, the installer has already been downloaded — that is how it was detonated and hashed. Rather than discarding those verified bytes, they are retained and stored content-addressed.

The catalog then flips that coordinate’s serve origin, and the manifest handed to your endpoints rewrites the installer URL to point at your own feed, addressed by digest. The pinned SHA-256 in the manifest is unchanged, so the endpoint performs exactly the same verification it would have against the vendor copy.

The result is that a fenced endpoint needs one host allowlisted: your feed. Not a vendor per package.

The authorisation is not just “knows the hash”

Because the attested digest appears in every manifest, a byte endpoint that served anything on presentation of a valid-looking hash would be a public download service. It is gated properly: a digest is servable only when it belongs to a row that is attested, active in that endpoint’s ring, and scoped to that tenant — and the check keys on serve origin, so a coordinate demoted back to vendor serving immediately stops authorising its old digest.

If you point the byte store at object storage rather than local disk, that path refuses to start at all unless it can prove the bucket blocks public access. An attested digest published in every manifest plus a world-readable bucket is a download URL that bypasses the token gate entirely, so this fails closed rather than warning.

What still needs to reach out

Being direct about the limit, because this is where similar products oversell.

Your endpoints can be locked down to one host. Your control plane cannot. Ingest fetches the package manifest from upstream and downloads the installer so it can be detonated. That is a deliberate, operator-initiated act rather than something happening on every endpoint at install time — but it is outbound traffic, and it needs to be allowed somewhere.

There is one more sharp edge worth knowing. The fetcher that performs those ingest downloads resolves DNS itself and connects to the resolved address directly, and it hard-rejects private address ranges. If your plan was to point ingest at an internal mirror on an RFC1918 address, that is currently refused rather than supported.