Xcode archives successfully using the latest - and correct - provisioning profile.
However, the Bots configured in Xcode Server still use an older profile.
This can be seen if one authenticates as xcodeserver user and navigates to ~/Library/MobileDevice/Provisioning Profiles.
Running security cms -D -i myuuid.mobileprovision confirms this.
Having tried reconfiguring a new Bot, restarting Xcode Server, deleting the old profile, and so on, nothing works.
How can we help Xcode 9 Server do what it promised, and use the latest provisioning profile from the Apple Provisioning Portal?
A dirty hack will work. This is assuming Xcode will correctly Archive using the correct profile. Unarchived the resulting .app file, then rename the embedded.mobileprovision file according to it's UUID, e.g.
myuuid.mobileprovision
Next, copy myuuid.mobileprovision to the ~/Library/MobileDevice/Provisioning Profiles folder.
Identify any older profiles linked to the same bundle identifier and delete. To play it safe, consider moving temporarily to ~/Desktop.
Finally, integrate the Bot, unarchive the resulting .app., and inspect to confirm creation expiry date, UUID, and UDID array are all as expected:
security cms -D -i embedded.mobileprovision
Related
I have a Mac app that requires custom downloads for each user. I've done everything to sign the app for Gatekeeper, and it all verifies on the build. But when the app gets downloaded from the website with the custom file added, Gatekeeper no longer verifies.
Is there a way to do custom files without re-signing the app for each download? I just need to update a .plist file in the app bundle. The website is written in ASP.Net, so signing on the server probably won't work.
It sounds like you are attempting to sign your .app bundle, upload it to a web-server, and them modify a .plist value inside the .app wrapper before the .app bundle is downloaded and given to a customer.
Gatekeeper will not allow this. (At least, it will not allow it with "version 2" signatures, which are required for deployment on OS X 10.9.5 or later. It was permitted with the older signing system, so if you are content to deploy on OS X < 10.9.5, you could get away with it.)
See Apple Tech Note 2206 for reference (in particular the FAQ "I want to exclude files so I can fix my bundle after I build it"):
https://developer.apple.com/library/mac/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG302
Note: If you modify your .plist entry as you say you will end up with a broken signature, but all hope is not lost. If your users have the default security settings, they can still right-click on your .app bundle and say 'Open.' This will result in some scary security warnings from Apple, but if your users persist in clicking 'OK' then they will be able to run your app just fine.
I love using RStudio for it's built-in integration with version control systems. However with RStudio on Windows is there a way to change the Git protocol from http to ssh or vice versa for a project already under version control without first having to delete and recreate the project?
I might be missing something, but I originally cloned my repo using http which I subsequently found to be a massive pain because every time I want to push project changes to GitHub I have to re-enter my username and password. So I removed the project from version control(Project -> Project Option -> Git/SVN -> Version Control System: none) and then tried to re-add version control hoping to use ssh but it will only allow you to go back to the original protocol you selected when creating the project in the first place.
The only way I have found to change protocol it is to delete the project and then create a new project from GitHub using the correct ssh parameters. I'd really like to be able to change projects version control protocol from http to ssh without deleting and re-cloning first.
Is this possible?
Check out git config and the whole configuration stuff. You can configure several remotes to make the "distributed" aspect of git work.
You can try just copying the whole repository (or just .git/config, keep a copy!) and check what happens with your specific case when you change the configuration. It depends on lots of things that aren't under git's control, like firewall configurations en route, and the configuration on the other end.
I submitted a couple apps last week that were revoked by Apple. I fixed them and tried to sumbit these apps again.
I have been getting this error for two days. I erased all my certificates and provisioning files on the provisioning portal and created all new ones . Also, I cleaned up everything in my keychain.
I am sure I am using the correct provisioning file in Xcode's build settings, and yet I still get this error. Why?
I solved this problem by the following steps:
Go to the file path where you save your provisioning file:
~/Library/MobileDevice/Provisioning Profiles
and remove all the provisioning files you have downloaded today.
Download the new provisioning file from the Apple member center that matches your project.
Press Command+B, rebuild the project, and see if this issue still exists.
My client wants to submit the project by himself so he asked me to get the xcode xcarchive of the project and send him to sign it and upload it.
He gave me his development certificate, I installed it and sign the target with its provision profile.
The build configuration that I'm using for signing is a copy of "Release".
Now when he tries to resign the archive and submit it, iTunes throw an error Invalid Binary and the culprit is the Signature
Its says :
Invalid Signature - Make sure you have signed your application with a
distribution certificate, not an ad hoc certificate or a development
certificate. Verify that the code signing settings in Xcode are
correct at the target level (which override any values at the project
level). Additionally, make sure the bundle you are uploading was built
using a Release target in Xcode, not a Simulator target. If you are
certain your code signing settings are correct, choose "Clean All" in
Xcode, delete the "build" directory in the Finder, and rebuild your
release target. Once you have corrected these issues, go to the app's
version details page (found in the Manage Your Applications module of
iTunes Connect) and click Ready to Submit Binary. Proceed through the
submission process until the app's status is Waiting for Upload. You
can then use Application Loader to upload the corrected binary.
Do I need the private key used by my client?
Can someone please point me to the right direction? Can I get any tutorial or video how to resign the archive and submit it to the store.
I think you should ask your client to generate a distribution certificate and then sign your project with it.
I haven't really used the archive function under Xcode 3, but got used to it now in Xcode 4. So far I always used to have three or four build settings in all my projects: Debug, Distribution AdHoc and Distribution AppStore. Distr. AdHoc and AppStore were both copies of "Release" and only differed in regard to their provisioning profile selected for Codesigning (so essentially they were a thing of convenience, making sure I never sent the wrong person the wrongly signed build).
Now I noticed that Xcode asks me with which profile I would like to sign my build with whenever I export an archived build form the organizer, yet at the same time the build would also fail if the selected provisioning profile in the build settings was not valid. Are Xcode 4 archives provisioning profile independent from or are thy tied to a provisioning profile? How do you solve the "challenge" of having to build for AdHoc and AppStore without having too many build settings groups (switching the groups associated with the build schemes has become somewhat cumbersome in Xcode 4)?
Thanks!
in Xcode 4 if you archive an application it is signed with the provision profile that you have indicated to use under its build configuration. Most likely a settings that was carried over from an Xcode 3 project.
An archived app can be resigned with a different provision profile at a later time (though the organizer or command line), so in a way, yes they are independent of provision profile.
Two suggestions for managing building for AdHoc and AppStore:
1)
The first is taking advantage of Xcode 4 schemes, and creating a new schemes for AdHoc and AppStore
Under the Schemes Menu: Edit Scheme -> Duplicate Scheme, then under the Archive you can select your desired build configuration (AdHoc, AppStore, etc...), you can then name this scheme AdHoc, AppStore to match too. When you want to build for release just select the target scheme and it will sign it with the associated provision profile from the build configuration.
2)
Maintain 1 scheme, remove code signing from your build configurations, and code sign apps exclusively though the organizer after archiving.