SPM support basic auth for non-git binary dependency hosts

@tomerd @NeoNacho Any updates on this? I'd be happy to look into opening a PR if we agree on the approach... Is it a matter of adding 302 to the list of valid response codes or should the http client be revised?

PR is absolutely welcome, thank you for offering! as @Jon_Shier points out above this is less about adding 302 to the accepted response codes, and more about making sure SwiftPM use of URLSession is correct - in the sense of configuring URLSession to follow redirects.

Sorry, my point was, looking at the SPM code, SPM does not implement the delegate that would prevent automatic redirect handling, so the 302 -> 200 redirect should be working now, unless there's something I'm missing in SPM's URLSession implementation (it's surprisingly simple). However, I can't rule out issues in the open source version of URLSession or Apple's private fork of SPM.

@tomerd: looking at SPM's code and as @Jon_Shier points out, it seems like SPM's use of URLSession is correct insofar as it should follow redirects. It's my understanding that that's URLSession's default behaviour, is that being overridden somewhere?

not that I know, SwiftPM's wrapper of URLSession is pretty straight forward

However, I can't rule out issues in the open source version of URLSession or Apple's private fork of SPM.

@tallariel is this happening on macOS or Linux?

@tallariel did we confirm that this does not solve the issue you are seeing? or iow are we sure its a redirect problem?

@tomerd This is happening on Xcode 13. The issue is that it fails to add Swift packages that specify a binaryTarget with the URL of a GitHub asset in a private repo (even with a correctly formatted ~/.netrc file with suitable credentials). I suspect this could be because

A) the ensuing redirect isn't followed
B) Xcode doesn't read the netrc file

I dont believe Xcode 13 has the change in Add accept header to download request by jimmya · Pull Request #3795 · apple/swift-package-manager · GitHub which could explain this behavior as well

That's correct, the changes aren't in any released Xcodes since those ship with Swift 5.5 which corresponds to the release/5.5 branch in OSS.

@tomerd @NeoNacho Ok, good to know that a future Xcode will read the netrc file. That's one of the requirements for downloading GitHub release assets in private repos, another one being following redirects.

It seems like SPM's HTTPClient.Request only accepts 200 as a valid response code and the GitHub REST API initially responds with a 302 when we ask it for a release asset (see my sample curl call above).

So is this a matter of adding 302 to the list of valid response codes or should the HTTP client be revised?

Accepting only 200 is correct, as URLSession should never provide the 302 as a response by default. If it is there's something wrong, as SPM isn't telling it not to follow redirects automatically.

as @Jon_Shier points out, SwiftPM check of the response code is for the final / pos-redirect status code, and as such no changes are required in SwiftPM to that end.

@tallariel I think we should come back and test this when a beta of the next Xcode is out


Even if the redirects are followed in the next Xcode beta, there is also this problem due to the GitHub asset URL not ending in .zip:
unsupported extension for binary target 'TestBinaryTarget'; valid extensions are: 'zip'

I got the above error when I tested this with Xcode 13.2 beta 2, which I assume is what you meant by a beta of the next Xcode.

I've found that GitHub API will disregard a file extension if you add it, so you can just append .zip to the URL declaration to appease SPM (though perhaps the need to do this should also be revised).

1 Like

I just tested on Xcode 13.2 beta and wasn't successful.

To recap: I created a release on my private github repo, added the zipped xcframework as a release asset, and updated the Package.swift file thus:

    targets: [
            name: "FrameworkName",
            url: "https://api.github.com/repos/{owner}/{repo}/releases/assets/{release_id}",
            checksum: "f7c06...."

When resolving packages, Xcode sends out the following error:

unsupported extension for binary target 'ClarityMiddleware'; valid extensions are: 'zip' in git@github.com:shapedbyiris/clarity-middleware.git

could be due to:

1 Like

I tried doing this and Xcode 13.2 produced the following error:

failed downloading 'https://api.github.com/repos/{owner}/{repo}/releases/assets/{release_id}.zip' which is required by binary target 'TargetName': badResponseStatusCode(404)

1 Like

We ended up setting up a proxy on AWS that rewrites requests from a custom domain to the GitHub domain.



We had to rewrite the Accept header to Accept: application/octet-stream as well. Our .netrc contains an entry with our custom domain but uses a GitHub login and token for the auth.

It feels like it's held together by duct tape, but it does work.