-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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] import P12 codesigning certificate to match's repo, updated, fixed #9752
Conversation
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed, please reply here (e.g.
|
I signed it! |
CLAs look good, thanks! |
need this very much |
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.
Looking good, I have a few grammar/spelling tweaks and some feature questions.
match/README.md
Outdated
@@ -327,7 +327,7 @@ Once you've decided which approach to take, all that's left to do is to set your | |||
|
|||
### Nuke | |||
|
|||
If you never really cared about code signing and have a messy Apple Developer account with a lot of invalid, expired or Xcode managed profiles/certificates, you can use the `match nuke` command to revoke your certificates and provisioning profiles. Don't worry, apps that are already available in the App Store / TestFlight will still work. Builds distributed via Ad Hoc or Enterprise will be disabled after nuking your account, so you'll have to re-upload a new build. After clearing your account you'll start from a clean state, and you can run `match` to generate your certificates and profiles again. | |||
If you never really cared about code signing and have a messy Apple Developer account with a lot of invalid, expired or Xcode managed profiles/certificates, you can use the `match nuke` command to revoke your certificates and provisioning profiles. Don't worry, apps that are already available in the App Store / TestFlight will still work. Builds distributed via Ad Hoc or Enterprise will be disabled after nuking your account, so you'll have to re-upload a new build. After clearing your account you'll start from a clean state, and you can run `match` to generate your certificates and profiles again. If revoking your certificates is not an option for you, please consider to use match's [import](#import_certificate) feature 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.
Grammar nitpick: "please consider using match's [import]...."
match/README.md
Outdated
@@ -358,6 +358,19 @@ If you want to manually decrypt a file you can. | |||
openssl aes-256-cbc -k "<password>" -in "<fileYouWantToDecryptPath>" -out "<decryptedFilePath>" -a -d | |||
``` | |||
|
|||
### <a name="import_certificate"></a>Import an existing certificate | |||
|
|||
To quickly and easily get started with `match`, it is adviced to revoke your existing certificates. Although, if revoking code signing certificates is not an available option for you, match provides an `import` feature that let's you import an existing code signing identity certificate, to your match's repository. |
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.
couple of grammar/spelling nits:
"it is advised that"
"feature that lets you" (no apostrophe)
match/README.md
Outdated
|
||
To quickly and easily get started with `match`, it is adviced to revoke your existing certificates. Although, if revoking code signing certificates is not an available option for you, match provides an `import` feature that let's you import an existing code signing identity certificate, to your match's repository. | ||
|
||
Before using this feature it is required that the code signing certificate you want to import is properly installed in your Keychain and it is associated with an active code signing identity registered in your Apple Developer account. Check this [fastlane.docs page](<to-do-link-to-fastlane-docs-page>) to easily speed up with this requirements. |
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.
Is there a corresponding docs pr?
match/README.md
Outdated
match import "<path-to-p12-code-signing-certificate>" "<p12-password-if-not-empty-string>" | ||
``` | ||
|
||
The command will validate the certificate that you want to import and associate it with its Apple Developer's representation. The information retrieved from the Apple Developer account will make sure that the certificate to import is properly processed and analyzed by `match` that finally imports, and encrypts it, in its repository. |
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.
"The command will validate the certificate and associate it with the Apple Developer Portal entity. This will ensure that the certificate is correctly processed by match
and imported into the repository."?
match/lib/match/spaceship_ensure.rb
Outdated
end | ||
|
||
return found if found | ||
UI.user_error!("The certificate to import can not be associated with any existing certificate in the Apple Developer Portal.") |
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.
"We could not find a matching certificate in the Apple Developer Portal"?
params[:import_certificate] = args[0] if params[:import_certificate].nil? | ||
UI.user_error!("Missing path to the certificate to import") if params[:import_certificate].nil? | ||
|
||
params[:import_certificate_password] = args[1] if params[:import_certificate_password].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.
This currently breaks in the case where you specify import_certficate
as an env var, but the password on the command line. Not sure how best to handle this though
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.
@dantoml not sure what do you mean. Anyway, fixed all other comments, thanks! Let me know if you need something else :)
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.
@razum2um Hey, so currently:
if you ran:
MATCH_IMPORT_CERTIFICATE=/path_to_cert fastlane match import $CERTIFICATE_PASSWORD
it would fail to find the password, and could be somewhat confusing. This is however, potentially fine, I was mostly interested to see what your thoughts were and if you'd considered it.
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.
@dantoml I think specifying cert & pass in a different way is a strange choice. Should we really handle it? Maybe refuse positional arguments (but I'm rather not)?
af2f7e4
to
a62dc94
Compare
match/README.md
Outdated
To import your code signing certificate, P12 encoded, run: | ||
|
||
``` | ||
match import "<path-to-p12-code-signing-certificate>" "<p12-password-if-not-empty-string>" |
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.
Should probably be fastlane match
and not just match
, right?
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.
@KrauseFx fixed, thanks :)
let me know, what can I do to get this finally merged? ;)
a62dc94
to
8d89cd0
Compare
Sorry to be so negative on this, but I'm not very comfortable merging this. I can already see this feature causing lots of incoming GitHub issues from people that import invalid certificates and keys, or mismatching profiles, causing more confusion. The beauty of match is that you can be sure things work as expected. I said the same thing a few times in the past, I know that this is a feature people wish for, but I'm not super comfortable with it, and I don't think I'm the one ready to merge it. |
@KrauseFx I understand your worries, features are coming with the cost of supportability :) What can we do in order to prevent "issues from people that import invalid certificates and keys" - check CNs, expiration dates? Can we turn "so negative on this" to constructive suggestions? |
still nothing about this feature ? :) |
This is still my position: #9752 (comment) If someone else feels comfortable reviewing, testing, merging and maintaining the code, I'm okay, but I won't sign off, sorry again, but that's my opinion on this feature (has nothing to do with the code) |
Maybe we can find a compromise if we can understand the exact reasons for wanting this. My understanding is the following:
|
@matthewellis no, there was no such intention and last time I used it myself I synced dev certs, right, will sort it out as soon as I can |
@milch my reason (maybe I've just chosen wrong approach): we have different match repos with different credentials for different projects. We were trying to separate dev certificates as well, but apple restricted the number of total possible dev certificates to 5, so in order to maintain the flow I imported one created earlier into next project's match repo |
@razum2um Yeah, that doesn't sound like how match is intended to be used. The idea is more or less to have 1 match repo per Apple account. Is there a reason why you can't have a single repo for all projects? |
As for me, I think this feature is needed to prevent legacy enterprise certificates from being revoked by match at first use, as it would disable all the existing apps (unless I'm misunderstanding somehting). |
You don't necessarily have to nuke, if you still have a free spot for a new certificate, match will just use that 👍 |
@KrauseFx sure, but if we have no spots left, the feature would be useful :P (even if, when we have two certificates, we can nuke the unused (yet) one) And thank you for your answer (and for Fastlane, which is an amazing toolsuit) |
Hey folks! I am going to close this PR for now as it has been inactive for quite some time. That being said, please feel free to continue conversation on here and let us know if we should reopen it at any point! 🚀 |
@milch To add to your list, I learned that revoking an Enterprise cer/profile combination (via nuke) makes the app unusable that moment. So not like with a normal app store cert that you just replace with the next update, your users can't use your app until they get one built with the new cert. |
As KrauseFx understandable is cautious about adding this to fastlane itself, how about reworking it into a plugin with its own Github repo @razum2um @MajinRaph? Then problems using it would end up at the issues of that repository and one could make sure that all information for this "advanced usage" is collected there. |
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 validMotivation and Context
Asked here #6900 and continued here #6972
Description
In comparison to #6972 it matches certificates by issuer and serial which according to rfc identify a unique certificate, I also addressed all the comments from previous version