BranchMetrics/ios-branch-deep-linking-attribution

Pod hash changed for an existing version

Closed this issue ยท 8 comments

Describe the bug

The pod hash changed for existing releases. Assuming this is intentional and not malicious, this is very bad practice for security and reliability.

Steps to reproduce

  1. run pod install on an existing integration (in our case version 1.41.0)

expected: should succeed with existing hash bd6c472d6cab03206877ac86c1241327a3f217d1
actual: integration builds fail due to hash not matching, now 5b53e039f5d5cdd12dc5d34b1a6b165168cab9d2

Expected behavior

should succeed with existing hash

SDK Version

1.41.0

XCode Version

14.2 (14C18)

Device

n/a

OS

n/a

Additional Information/Context

No response

+1 noticed as well. Can we get an explanation from Branch team about this?

SDK version 1.43.2

  • old hash: 74cc856025984f691833c8fa332834ac38a0cf4e
  • new hash: 4ac024cb3c29b0ef628048694db3c4cfa679beb0

I see that @echo-branch deprecated all of the versions yesterday? Is this related?

I'm running into the same issue -- this is breaking our iOS builds and deploys because of the checksum from installing Branch (on SDK version 1.39.2)

Thanks for the heads up. I was trying to put in a notification that the Branch pod was renamed to BranchSDK from version 2.0.0+, but it seems I messed it up. Looking into it now.

Does the problem resolve with pod update?
How about removing the Podfile.lock and Pods folder then reinstalling?

I'm not certain I can easily roll this back as it appears to be the way cocoapods implemented the pod trunk deprecate NAME --in-favor-of=OTHER_NAME command. It appears to modify the podspec with a notice which would change the hash.

For example:
CocoaPods/Specs@209f859

I ran a pod update which updated the version from 1.39.2 to 1.39.4, which fixed the issue for me.

Yea, looks like the issue has to do with these commits which added a deprecated_in_favor_of field to the Podspecs for a bunch of the older SDKs which ended up changing the hash value for the Pod in Podfile.lock.

Looks like we're not going to be able to fix this as it is an unfortunate design choice by Cocoapods. Workaround is to ignore the warning and just remove the lock and pod update.

Weird implementation choice from cocoapods, but thank you for taking it seriously and investigating.