Pod install fails for private pod being served as binary from private repo

Question

I have a private pod and a private spec repo. I am serving the pod as a binary, i.e. the podspec says:

s.source = { 
  :http => 'https://github.com/COMPANY/PROJECT/releases/download/v1.0/PrivatePod.zip' 
}

My Podfile has the following source information:

source 'https://github.com/CocoaPods/Specs.git'
source 'https://github.com/COMPANY/Specs.git'

When I run pod install git prompts for a password to clone my private spec repo, which is great.

However, pod install tries to get the binary zip package using curl with no authentication, so GitHub returns 404:

Installing PROJECT 1.0 (was 1.0)

[!] Error installing PROJECT [!] /usr/bin/curl -f -L -o /var/folders/_g/52mwshws60v8622n81hv7h7w0000gn/T/d20170608-80045-1l3flqz/file.zip https://github.com/COMPANY/PROJECT/releases/download/v1.1/PrivatePod.zip --create-dirs --netrc-optional
...
curl: (22) The requested URL returned error: 404 Not Found

I don't want to make the binary public. Is there a way I can tell CocoaPods to do some auth here?

I tried putting credentials in .netrc, which CocoaPods seems happy to use, but GitHub still fails the request with 404, even though I see curl is now using basic auth. If I make API requests with curl using netrc for auth, I get responses just fine. But I can't download the release asset.

I can get the release asset from the api endpoint using .netrc, but only if I specify -H 'Accept: application/octet-stream', which I don't see how I can make CocoaPods do that.

Reglet

Possible solution: #43886263 ? – Me

I did see that work-around. The problem there is you have to commit the release binaries, instead of using Github's non-SCM hosting of bits. – Reglet

GitHub support is saying they just don't support auth for release downloads. They added it to some internal feature request list which will probably be ignored forever. Oh well. Answer: NOT POSSIBLE. Host that crap somewhere else. – Reglet

Do you need it just for yourself/small group of users? One approach that seems to work is to "fake" curl - write a shell script that, given the curl arguments, "does the right thing", and then replace the real curl by putting a symlink to your fake curl earlier in the path (such as /usr/local/bin). Of course, this doesn't scale well since every user of the library would have to do the same hack. There is also github.com/CocoaPods/cocoapods-downloader but I'm not sure how it works. – Clovis

My goal is binary distribution for third parties. The solution is to just not host the binary packages on github, since they don't support auth for non-api calls, as confirmed by their support people. – Reglet

Running into the same issue here... Maybe we can fix this by sending a PR to CocoaPods to include the missing header? What do you think? – Lagerkvist

You could try. I no longer work at the company that needed this solution. – Reglet

Answer 1

GitHub just doesn't support this. Solution: don't host the binary on github if the repo hosting it is private.

GitHub support is saying they just don't support auth for release downloads. They added it to some internal feature request list

Reglet