I create an app and I sign it and send it to Apple, along with bitcode.
Apple redistributes to millions of people and they can verify my code signature.
Now Apple recompiles my app and distributes again.
How are they able to sign the app so that it will run on those millions of people's devices? Do they have access to my private key and are they forging my signature?
The words of Felix Krause, the "Professional iOS Code Signing Issue Resolver" and the creator of fastlane tool:
"You sign your app and Apple has to sign it also... The fact that you have to code sign on local machine is actual nonsense because Apple basically resigns your app anyway once it gets approved."
For us that means that Apple uses another key pair to sign the app even if they don't have to rebuild it from bitcode. So that's the answer - they don't have access to user's private key, they resign the App with their key. And in case of recompiling app from bitcode - even simpler: compile bitcode, sign binary with App Store key.
Related
I don’t have access to apple developer account.
but I have the p12 distribution and mobile provisional certificates from the client.
When I try to create ios app with expo cli without login:
It ask me the password for the certificate. There’s no password set
on the certificate how can I give a blank input?
Then it ask for apple team ID (from where can I get it?)
I also want to know what else are required to build app without login.
There’s no documentation or resources available on the expo site for it.
As far as i know , getting build versions for ios apps without apple developer account is not possible.
although , this article might be helpfulcheck this
TLDR:
Does Google check the validity of an iOS app's bundle identifier when restricting the API key to a specific iOS app?
Or is it possible for anyone to mimic the bundle ID in order to launch an attack?
If the latter is false, why not include the API key in the iOS app?
UPDATE 1:
I'm guessing Google doesn't check for Team ID?
Apple Glossary
App ID A string that identifies one or more apps from a single team. An App ID consists of a bundle ID search string preceded by the Team ID, a 10-character string generated by Apple to uniquely identify a team.
I need some directions... (pun intended)
Say I'm building an iOS app that needs to consume the Google Directions API.
Google suggests to "proxy the web service via your server when you're using the API in a mobile app, to protect your API key".
In my project settings in Google Console (API Manager -> Credentials etc) I can restrict the API key to only iOS apps with my bundle identifier (com.example.MyApp).
Since I don't need a server, what's the worse that can happen if I include the key in the app?
The only thing I can think of right now is someone steals the API key and builds an app faking my bundle ID (or even fake the iOS host itself) and fires "unlimited requests" to bring down my service/make me pay a lot of money.
Is this possible?
And if it is, couldn't he do the same even if I hid the API key in the server? Just call my server instead of the API directly.
So what's the gain of having a server in that case?
And would the only solution to prevent this abuse be to require authentication and rate limit each user?
But couldn't then someone create "unlimited" random accounts?!
Do I use captcha?
By then the UX has become pretty awful, especially since authorisation is not even required for my app...
Is there a solution to this, or do I just choose the simplest solution (include the key in the app) and hope for the best?
Now,I have a big question.I'm doing iOS dynamically compiled function, I want to use an iOS project, compile several different ipa file, use the Enterprise so that these items can be installed to the phone, I use xcodebuild command. But I do not know how to dynamically generate .mobileprovision file. I do not want every time manually generated from the Apple Developer Center
.mobileprovision files comply with RFC 3852 "Cryptographic Message Syntax (CMS)". In addition to the plain-text signing identities, app identifiers, entitlements, permitted test device UDIDs, and other related metadata, these files are cryptographically signed by Apple at the time they are generated on the Certificates, Identities, and Profiles tool. As only Apple holds the cryptographic keys that protect these documents, you will not be able to dynamically alter these files yourself -- you will have to work with the Certificates, Identities, and Profiles tool to be able to generate, request, download, and install profiles Apple generates.
Alternatively, the Certificates, Identities, and Profiles tool permits you to define what is called a Wildcard App ID (ex: com.mycompany.apps.*) that would allow you to use that one provisioning profile with apps under that app id tree:
com.mycompany.apps.myfirstapp
com.mycompany.apps.yetanotherapp
would both work, while:
com.mycompany.someotherapp
would require a different provisioning profile. Use of Wildcard App Ids also limits the kinds of entitlement based services you are permitted to use -- notably things like Push Notifications, Apple Pay, In-App Purchases, and Game Center are specifically disallowed under wildcard provisioning. If your app template requires use of these restricted entitlement based services, wildcard provisioning is not a viable solution and you will have to fall back to interacting with the Certificates, Profiles, and Identities tool.
In an application I made for Mac, when I ran the process for validating the archive, it came up with the error:
The archived application has entitlements that require Mac App Store distribution.
The invalid entitlements were:
com.apple.developer.aps-environment.
I looked at this link: Enabling Push Notifications and the entitlement, I think, is in relation to the push notifications.
I tried adding the
com.apple.developer.aps-environment
to my entitlements file as a boolean set to YES, but the error still came up.
How can I fix this?
It looks like you're maybe trying to sign the app for distribution outside the App Store, and Xcode is telling you it's not going to let you do that because you're using App Store only features.
I'm no expert in signing stuff, but to get my last app to submit I signed it with the "3rd Party Mac Developer Application:..." identity, not my "Developer ID:" identity. The latter is only for when you're distributing apps directly to customers from your own website.
It's not a boolean. It's a string that's either 'development' or 'production'. It's also only for apple store only.
I've developed application which communicates with my own server over HTTPS. And I use .p12 certificate for mutual authorization. The problem is that after I send first request on server I receive OSX's dialog message:
I know that need to make code sign but:
Can I make some workaround/hack/trick to prevent it? Please note that my app is not going to go on Mac Store. So I could use any private API.
If we can't prevent this dialog then what should I do:
1. Code sign my application via Mac Developer Program?
2. Or make trusted my p12 certificate?
If need to make some of these items above please provide a quote as proof from Apple's documentation.
I use OSX 10.8 an later.
Code signing your application is the most straightforward way to avoid this dialog. When importing the certificate and private key your signed application and future versions that match its designated requirement will be given access to the key for all purposes. See Mac OS X Code Signing In Depth and the Code Signing Guide for more information.
On your development systems that have already imported the key into the keychain you may see the authorization prompt one additional time, on systems that do not yet have the key in the keychain the prompt shouldn't appear at all.