Cocoapods: podspec files allow unencrypted http links

[KrauseFx]

Hey CocoaPods team,

Please let me know if that's the right place to start a discussion around this. I took a look at the CocoaPods/Specs repo and did a quick search on the sources of the available SDKs to see if there is any potential security vulnerability for the user, so I search for:

"http": "http://"

and I got 1484 matches, however man of them are just different versions from the same SDKs.

I totally understand that this is not something that can be changed instantly and without any side effects. I believe it might make sense to not only warn the user about those SDKs when running pod update / pod install, but maybe even have the user manually opt-in on unsafe binary and source downloads. Additionally I'd think it might be a good idea to update the pod lint command to reject .podspec files that include unsafe sources.

Let me know what you think 🌈

[orta]

I think we could negate a lot of the more negative aspects of using HTTP as a transport method pretty transparently (and without any additional work for library authors). On pod trunk push, we can generate a checksum of the HTTP resource, and store that as a part of the podspec JSON in trunk, and then verified again on the other side.

We do this for the version of Swift that the library was pushed with, as that's also really tricky to verify in Podspec metadata.

[KrauseFx]

Sounds like a great idea. From an outsiders perspective this seems like quite some work, and also isn't backwards compatible, meaning we only have those hashes on new releases, right?

I was thinking of updating the pod trunk push command to warn the library author that it's not encouraged to use http URLs, but still allowing them. At the same time, we can show a warning when the user runs pod update or pod install and one of the sources is unencrypted http://.

This approach is also used by the new Google Chrome: By showing a Not Secure badge in the address bar, people will reach out to library authors and ask why this is not secure, and library authors will slowly move over to https.

Let me know if that's something that's interesting - I'm happy to jump on diving into the CocoaPods codebase (best forrest) and looking into how to best implement it 👍

[orta]

Ah, so this is about just http? That's a bit different, I think passing a linter warning in pod trunk push which means you specifically have to declare you can ignore it is a good start.

Personally, I'm not adverse to outright banning http and saying that only https is acceptable, I mean, Apple have been doing it for years ATS so it's not that unexpected. http can continue to be downloaded, and given the runtime warning, (as you could be using a private repo) but pushing to the trunk spec repo could be banned.

FWIW: Both this and the checksum are about as much effort, some work in the core at the resolver, and some work in the trunk push command. They only affect people using the latest versions, but the cadence of Xcode releases force people to update /shrug.

[KrauseFx]

Sounds great. So I'm happy to spend some time to build the following

• Block the publication of new versions / new pods to trunk that have an unencrypted http source
• Show a warning to the user when running pod install and pod update if one of their sources uses http

This way everything will stay fully backwards compatible, and it will force the SDK providers to upgrade to HTTPs to provide a new release.

Let me know if that's something that makes sense working on from my side 👍

[orta]

Yep - this works for me 👍

[KrauseFx]

Glad to see both PRs merged, thanks for your time @dnkoutso and the rest of the team 👍