-
Notifications
You must be signed in to change notification settings - Fork 5.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[match] improve encryption internals, solving flaky test (#21663) #21790
Conversation
Well apart from the new #21792 flaky test, the proposed implementation won't work with all openssl installations
|
private | ||
|
||
def keyivgen(cipher, password, salt, hash_algorithm) | ||
cipher.pkcs5_keyivgen(password, salt, 1, hash_algorithm) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I considered increasing this very low iteration value, but changing the value requires changing the encryption format anyway, so let's just change the cipher etc.
# salt should be randomly generated and provided unencrypted (like in the current implementation) | ||
# key is generated with OpenSSL::KDF::pbkdf2_hmac with properly chosen parameters | ||
# Short explanation about salt and IV: https://stackoverflow.com/a/1950674/6324550 | ||
class EncryptionV2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just as a suggestion but nothing blocking, I think this could be refactored so that the IV gen happens in one class per algorithm, and then there's a single encrypt/decrypt function that takes in the IV gen class. I think overall it would just cut down on the duplication a little bit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You mean as passing the ivgen function as a "strategy" to the same code that is shared between V1 and V2?
I thought about it, but decided against for now because
- I preferred to keep V2 on its own, completely unrelated to common code with V1, to make it more readable.
- There used to be a few lines, and now there are already 3 classes. I felt it was maybe enough abstractions
|
||
# by default, encrypt or decrypt in place | ||
class MatchFileEncryption | ||
def encrypt(file_path, password, output_path = nil) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another question I have: do we want to enforce keywords parameters instead?
I think it usually makes for better API management and backwards compatibility.
Should I update this file and use keywords args instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm all for keyword parameters whenever we can 🙏
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added some but not in all classes. Makes sense or inconsistent?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just some nitpick comments about docs and formatting, as I don't quite grasp the whole encryption details 😅 but the overall logic LGTM and I liked your approach of keeping this backwards compatible by trying both V1 and V2 👌
match_file encrypt "<fileYouWantToEncryptPath>" ["<encryptedFilePath>]" | ||
|
||
match_file decrypt "<fileYouWantToDecryptPath>" ["<decryptedFilePath>]" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this be bin/match_file
instead of match_file
?
Also, this looks like a typo:
match_file encrypt "<fileYouWantToEncryptPath>" ["<encryptedFilePath>]" | |
match_file decrypt "<fileYouWantToDecryptPath>" ["<decryptedFilePath>]" | |
match_file encrypt "<fileYouWantToEncryptPath>" "<encryptedFilePath>" | |
match_file decrypt "<fileYouWantToDecryptPath>" "<decryptedFilePath>" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that once you install the gem, everything under bin
will be in your CLASSPATH. SO match_file
should be enough.
The [] were because the second parameter is optional and match_file decrypts / encrypts in place when omitted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ooh 😮 gotcha. I didn't know about any of those 2 info you said haha good to know 💪
|
||
# by default, encrypt or decrypt in place | ||
class MatchFileEncryption | ||
def encrypt(file_path, password, output_path = nil) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm all for keyword parameters whenever we can 🙏
Co-authored-by: Roger Oba <rogerluan.oba@gmail.com>
Co-authored-by: Roger Oba <rogerluan.oba@gmail.com>
Co-authored-by: Roger Oba <rogerluan.oba@gmail.com>
Co-authored-by: Roger Oba <rogerluan.oba@gmail.com>
Co-authored-by: Roger Oba <rogerluan.oba@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! 🚀 thanks for addressing the CTRL+C exit 😊
Hi @lacostej I'm experiencing some issue with decryption since 2.220.0 was released. Could you confirm the following query: |
Just experienced the same issue. I saved provisioning profiles using fastlane 2.220.0, and fastlane 2.219.0 is no longer able to decrypt them. |
I have the same issue as above. If locally somebody is encrypting a profile or a certificate using 2.220, and the CI is decrypting it with 2.219, it will fail. So it's on a file-by-file basis. This must be mentioned as a breaking change in the release notes at least. |
…tlane#21663) (fastlane#21790)" This reverts commit 387691b.
Checklist
bundle exec rspec
from the root directory to see all new and existing tests passbundle exec rubocop -a
to ensure the code style is validci/circleci
builds in the "All checks have passed" section of my PR (connect CircleCI to GitHub if not)Motivation and Context
Resolves #21663
Description
See discussion in above issue.
Testing Steps