Closed ileitch closed 5 years ago
@orta ping?
We're hitting this too; would you be interested in merging a pull request to fix this?
Yeah, for sure. We've just always re-ran pod install
, but getting this fixed would be 👍
@ileitch do you want to open a pull request from your fork? :)
Fixed by #192 and shipped in 2.0.7
Awesome, thanks @orta :)
Given a simple Podfile config:
and an empty macOS keychain and no files generated in ~/.cocoapods/keys, I can demonstrate that the
TophatHmacKey
is not recorded in the generated YML, and thus is not included in the generated ObjC class.In a nutshell, this commit from @colinta makes no sense: https://github.com/orta/cocoapods-keys/commit/7743a9be8ebadedc4d8efa4b655d86cc3697cc96
It appears the reasoning for the commit is that we need to re-save the keychain if the user was prompted and provided a value for a missing key. However, saving of a new key is performed here & here which loads and saves its own instance of
CocoaPodsKeys::Keyring
. Once all missing key values have been provided and saved the line from the commit is executed which saves aKeyring
instanced created before the missing keys were saved. The end result is that the YML is overwritten with an emptykeys
array.This output should make things more clear:
Note: the final call in
setup
has line 75 in the backtrace, this is due my debugging modifications. The line number without any modifications is 68.Perhaps there used to be some caching of
Keyring
instances that made this work previously, but it seems to be now that https://github.com/orta/cocoapods-keys/commit/7743a9be8ebadedc4d8efa4b655d86cc3697cc96 should be reverted.There appears to be at least one other bug report of this incorrect behavior: https://github.com/orta/cocoapods-keys/issues/153