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
- 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.