Private Artifact Bundle downloads sometimes fail with 403 error

[vsarunas]

Is it reproducible with SwiftPM command-line tools: swift build, swift test, swift package etc?

• Confirmed reproduction steps with SwiftPM CLI. The description text must include reproduction steps with either of command-line SwiftPM commands, swift build, swift test, swift package etc.

Description

We have several private artifact bundles used that randomly cannot be downloaded and fail with:

error: failed downloading 'https://api.github.com/repos/ordo-one/model/releases/assets/273301740-linux-313.1.0.zip' which is required by binary target 'Ordo': badResponseStatusCode(403)

This started happening frequently this month for some reason, potentially change of handling in Azure storage or caching. When the bundle is cached by the Varnish layer, the downloads succeed. When Varnish cache layer has a cache miss and forwards the request to Azure Storage, downloads fail with 403.

What is happening:

1. API request is made to https://api.github.com/repos/ordo-one/model/releases/assets/273301740 with basic Authorization header filled in from netrc
2. GitHub responds with a 302 redirect to https://release-assets.githubusercontent.com/github-production-release-asset/[...]
3. The same Authorization header that authenticates api.github.com is preserved and sent to a different host that doesn't require authentication since the redirect location already has a SAS token, resulting in rejection:

<?xml version="1.0" encoding="utf-8"?>
<Error><Code>AuthenticationFailed</Code><Message>Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.
RequestId:9eedc347-101e-0026-1136-f6a94d000000
Time:2025-07-16T09:49:35.6509894Z</Message></Error>

This can be visible in mitmproxy, there are 4 bundles to download: 2 worked and 2 failed:

The ones that are failed have mentioned authentication failure response:

The request that is made includes the original authentication for api.github.com, but this should not be sent to the redirected domain:

macOS appears to be using some slightly different implementation to fetch the files which is not affected by this (bundle downloads are also not visible in mitmproxy); this affects Linux only.

Expected behavior

Bundle should be downloaded successfully.

Actual behavior

Bundle fails to be downloaded and build process fails.

Steps to reproduce

On a private GitHub repository, attach a artifact bundle to the releases and add URL of it to Package.swift, URL + Checksum can be obtained from:

gh api /repos/owner/package/releases/tags/313.1.0 -q '.assets[] | "\(.url) \(.browser_download_url) \(.digest))"'

Fill in ~/.netrc with gh auth token:

machine api.github.com login gho_token password x-oauth-basic

Wipe the local cache and try to fetch:

rm -rf .build ~/.cache/org.swift.swiftpm/artifacts ~/.cache/org.swift.foundation.URLCache; ~/swift-package-manager/.build/debug/swift-build

Swift Package Manager version/commit hash

6.2 / 55f0a83

Swift & OS version (output of swift --version ; uname -a)

swift --version
Swift version 6.2-dev (LLVM 8835b75a8ce3615, Swift 3c98a1e76fae702)
Target: x86_64-unknown-linux-gnu
Build config: +assertions

[plemarquand]

Is there an issue filed with GitHub for this? Seems like a change in behaviour on their end.

[vsarunas]

I created a support case, but haven't received a reply yet.

The authorisation header should not be sent to the new domain; for example curl does not add the initial authorisation header, and writes a log message about that:

curl --verbose --netrc -L  -H "Accept: application/octet-stream" -o /dev/null https://api.github.com/repos/ordo-one/data/releases/assets/273301369
[...]
> GET /repos/ordo-one/package-data-model/releases/assets/273301369 HTTP/2
> Host: api.github.com
> Authorization: Basic my_token
> User-Agent: curl/8.5.0
> Accept: application/octet-stream

[...]

< date: Thu, 17 Jul 2025 14:06:23 GMT
< content-type: text/html;charset=utf-8
< content-length: 0
< location: https://release-assets.githubusercontent.com/github-production-release-asset/480324547/46435518-135f-45df-b39d-b5d8059fc37c?sp=r&sv=2018-11-09&sr=b&spr=https&se=2025-07-17T15%3A07%3A00Z&rscd=attachment%3B+filename%3DOrdo-ubuntu-24.04-x86_64.artifactbundle.zip&rsct=application%2Foctet-stream&skoid=96c2&sktid=398&skt=2025-07-17T14%3A06%3A23Z&ske=2025-07-17T15%3A07%3A00Z&sks=b&skv=2018-11-09&sig=0A[..]A&response-content-disposition=attachment%3B%20filename%3DOrdoubuntu-24.04-x86_64.artifactbundle.zip&response-content-type=application%2Foctet-stream
< x-github-api-version-selected: 2022-11-28
< x-ratelimit-limit: 5000
< x-ratelimit-remaining: 3235

[...]

* Couldn't find host release-assets.githubusercontent.com in the .netrc file; using defaults

* Host release-assets.githubusercontent.com:443 was resolved.

> GET /github-production-release-asset/480324547/46435518-[...] HTTP/2
> Host: release-assets.githubusercontent.com
> User-Agent: curl/8.5.0
> Accept: application/octet-stream
>
{ [5 bytes data]
< HTTP/2 200
< last-modified: Wed, 16 Jul 2025 06:53:00 GMT
< etag: "0x8DDC435674A1CEA"
< server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
< x-ms-request-id: d3c11f8e-e01e-0050-1323-f72305000000
< x-ms-version: 2018-11-09
< x-ms-creation-time: Wed, 16 Jul 2025 06:53:00 GMT
< x-ms-blob-content-md5: x/ydqPtxHf0vGnAWHs1cyQ==
< x-ms-lease-status: unlocked
< x-ms-lease-state: available
< x-ms-blob-type: BlockBlob
< x-ms-server-encrypted: true
< via: 1.1 varnish, 1.1 varnish
< accept-ranges: bytes
< date: Thu, 17 Jul 2025 14:06:23 GMT
< age: 9
< x-served-by: cache-iad-kcgs7200125-IAD, cache-hel1410024-HEL
< x-cache: MISS, HIT
< x-cache-hits: 0, 1
< x-timer: S1752761184.595767,VS0,VE1
< content-disposition: attachment; filename=Ordo-ubuntu-24.04-x86_64.artifactbundle.zip
< content-type: application/octet-stream
< content-length: 8091116
[...]