I have a problem after upgrading my iPhone SDK 3.0. Xcode does not get the developer certificate, but it's in the key chain.
Sometimes the certificates are added to the system as opposed to the login keychains. When that happens XCode doesn't see the certificates. If this is the case, you have to go into "Keychain Access" (/Applications/Utilities) and add the certificate to the correct keychain (and optionally remove it from the wrong keychain).
These certificates are the bane of a lot of iPhone developers lives. I've lost a lot of time wrestling with them.
All I can suggest - as there's too much to cover in detail - is that you read very carefully the help text that goes along with each section on the iPhone Developer Portal, paying more attention to the ones in red.
I remeber having to delete and recreate them. And if you've up graded to 3.0.1, read this very carefully
Related
I am developing an app (for like a year) and it works fine , when it comes to submitting to App Store -> all my problems started:
1)The app store would me to make my app to run in a sandbox(Why Apple ? Why !?).
It took like 2 days to understand why just toggling "ON" in capabilities doesn't make it...
etc ... in the end I somehow managed to convince my app to run in sandbox.
2)now the app passing the validation fine and can be submitted to the bloody App Store
However when I checked the app before the submitting I discovered that it simply don't want to work (running from Xcode or product).
It just crashes before it comes to `applicationDidFinishLaunchingWithOptions"
The crash itself is even more epic "thread1: EXC_BAD_INSTRUCTION (code=EXC_i386_INVOP, subdued = 0x0)"
and I see a lot of assembly lines -> from the comments inside the assembly I understood that the app tries to "Open" a sandbox , but then comes the bad instruction :( ud2
The stuck I see is:
_libseinit_initialize_once
0 _libsecinit_setup_secinitd_client
1 _libsecinit_initialize_once
2 _dispatch_client_callout
3 dispatch_once_f
4 libSystem_initializer
5 ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) ()
I think the rest are not relevant since they are all about some IMAGE loader :/
lately I ensured that removing the app sandbox key or setting it to NO Resolves my Issue but if I do so i getting back to issue number 1
so I kinda stuck with an egg and a turkey problem :(
maybe some 1 knows any interesting workaround or solution to submit the bloody app to the mighty app store ?
Sounds like what Apple document here:
OS X’s enforcement of container integrity impacts your development and
distribution cycle. This is because, in the course of creating and
distributing an app, the app is code signed using various signatures.
Here’s how the process works:
Before you create a project, you obtain three code signing
certificates from Apple: a development certificate, a distribution
certificate, and (optionally) a Developer ID certificate. (To learn
how to obtain these code signing certificates, read App Distribution
Guide.) When used in conjunction with the corresponding private keys
from your keychain, these certificates form three separate digital
identities. For development and testing, you sign your app with your
development identity. When you submit a version to the app store, you
use your distribution identity. If you are distributing a version
outside the app store, you use your Developer ID identity.
When the Mac App Store distributes your app, it is signed with an
Apple code signature. For testing and debugging, you may want to run
both versions of your app: the version you sign and the version Apple
signs. But OS X sees the Apple-signed version of your app as an
intruder and won’t allow it to launch: Its code signature does not
match the one expected by your app’s existing container.
If you try to run the Apple-signed version of your app, you get a
crash report containing a statement similar to this:
Exception Type: EXC_BAD_INSTRUCTION (SIGILL) The solution is to
adjust the access control list (ACL) on your app’s container to
recognize the Apple-signed version of your app. Specifically, you add
the designated code requirement of the Apple-signed version of your
app to the app container’s ACL.
I also had this problem, and although Droppy's answer was correct, it doesn't really resolve the problem (at least, not for me).
After messing around a bit, I found that the reason I had this problem is that, (although I had disabled keychain sharing in 'Capabilities' in Xcode's project editor) I still had a keychain value added. Removing this, or completely disabling all app capabilities (yes, including sandbox) will solve this problem.
Hopefully, this saves someone some time in the future.
Since nokia doesn't sign symbian apps any more,is there any alternative to sign app for symbian?
may be some behind the scene hack or bypass?
symbiansigned.com and cer.opda.cn are dead, don't even mind getting developer certificates - just hack your phone, no way to do this otherwise nowadays:
https://shahbazalam781.blogspot.com/2013/04/hack-all-symbian-phones-s60v3-s60v5-s3.html
This works great, just try setting your phone Date & Time to somewhere about 2010-2012 when installing apps until it clicks. After hacking phone you won't need to do this anymore.
In case link dies:
SIMPLEST PROCEDURE: First Download 3 Files
DOWNLOAD-Norton-Symbian-Hack http://gallery.mobile9.com/f/3177996/
DOWNLOAD-Rom-Patcher-Plus-v31 http://gallery.mobile9.com/f/3178010/
DOWNLOAD-Xplore V1.58 http://gallery.mobile9.com/f/3175430/
Install “NortonSymbianHack.sisx”.
Launch it.
Go Options – Anti-Virus – Quarantine list.
Go Options – Restore. Accept prompt.
Exit application. Delete Norton from Application Manager (Symantec Symbian Hack). Also delete “C:\shared\” folder.
Install “RomPatcherPlus_3.1.sisx”.
Launch and apply patches:
Open4all for full access to file system.
Installserver for installing any unsigned applications.
(If “Installserver” has red cross, follow steps 8 to 15.) (If checked,
reboot now your phone.)
Note: Set patches to auto if needed. (Options – Add to auto)
Install X-Plore.
Open it.
Press (Menu – Tools – Configuration).
Check all (Show Hidden Files, etc.).
Open “installservers_pack.zip”.
Choose what Symbian OS you have. (List below)
Copy “installserver.exe” from the folder of your OS to “C:/sys/bin”. (No need to apply patch on RomPatcher.)
Reboot phone. Phone is now hacked.
Officially, you could of course continue using the developer certificates you might have, and if they are expired, the device time might be needed to be adjusted for the installation time.
Then also the self-signing works just as it used to. For any new certificates or signings, unfortunately there are no official help available.
You can use this app to sign Symbian apps.
The signing process is fail-able but the self-signing works perfectly.
Here's the link
I was recently given a VB.NET project for fixing some bugs and creating an installer for it. I was told to use Install Shield LE.
All went well with creating the install script but Windows 8 is giving me a smart screen warning when downloading the application from a web site and trying to install it.
I am aware of Windows 8 policy where popular applications get more "trust points" and become popular but the application is targeted for a fairly small audience of people therefore we can not rely on this option. Even more, people without proper knowledge would be repelled by the warning message and that could cause MS to never raise the trust for the application.
My question is, do I have to sign both - the application and the installer with a certificate? If so how do I sign the installer, as there is a signing tab for the project but I can't find one for the installer.
Bonus points if anyone can tell me if acquiring a proper certificate will remove the warning message telling this isn't a commonly downloaded file and might be dangerous from chrome/IE when downloading the application. There are many threads about this, I know, but most of them suggest adding the site to webmaster tools but that hasn't helped and we're still receiving the message
Thanks.
If I have read your post correctly then you are talking about an application as opposed to a website, and for that you would need a code signing certificate. Certificates that sign websites are different so first and foremost decide what it is that you are producing and want to sign.
Having decided that then you need to decide who you will use to supply your certificate. Typical sources would be VeriSign, Thwaite or Globalsign to name but three. All charge different prices but essentially do the same thing.
Once you have the certificate then the installer that you use to build your application signs the code files you select and the actual installer (msi or exe) itself.
That should eliminate the message that you now see warning people about potentially dangerous files that they are about to download.
I cannot stress enough however that you need to be clear about which type of certificate you need BEFORE you go ahead and buy one. I think from your description you are talking about a code signing certificate but do check first.
Following CAB forum regulation you will need to have an Extended Validation code signing in order to bypass the smart screen filter.
Extended Validation code signing will establish immediate trust with the machine, as you go through a more stringent validation process to obtain it! (or at least that's the rationale behind it!)
I think you can get an extended validation code signing either from SYmantec or GLobalsign.
I'm trying to understand the whole provisioning-proccess, but I just don't get it..
I have tried to read up, but it's too weird and difficult for me to understand, especially when English is neither my primary or secondary language..
I have been developing for a while, and I remember stressing alot when setting up my iphone for development the first time. When I go into Settings->General on my phone I have 17 profiles, but at least I got it working in the end.
Now, I'm porting my app to iPad, and I'm trying to add my iPad to the table.
This is what I did:
I went to developer.apple.com, added my udid in devices, I then went to provisioning on the same webpage, and saw three profiles, one uneditable(controlled by xcode), one connected to my app's AppID, and one connected to myself as an AppID.
I added my new iPad-device to all three of them to be sure, and downloaded them again.
I dragged the .mobileprovisions to iTunes and to Xcode, and I went into organizer and clicked Refresh to update them. I clicked Use for development on my iPad, and it says it contains those profiles. They're also in Settings->General on my iPad.
In my XCode project, I go under Targets->Build Settings->Code Signing, and set one of my new profiles to Debug, and one of the other to Any iOS Sdk inside it. I've tried multiple combinations. I also went to Project->Build Settings->Code Signing and did the same thing.
When I run my app on my device, it pops up two of the same error message saying A valid provisioning profile for this executable was not found.
When I now connect my iPhone, which has been working perfectly fine all along, the exact same thing happens. Two of the same error message.
The question:
Which profiles goes where? What is the difference between the profile containing myself as an AppID and the one containing my actual app's ID as AppID? What is the difference between Target->Build Settings and Project->Build Settings when it comes to Code Signing?
Also, we spent a lot of time making push work, and out app is on AppStore rigth now, so I don't want to start deleting profiles and ID's, cause I think I read somewhere that that could make the notification stop working.
Oh, and I downloaded a new certificate as well at some point, containing the new profiles, and it ended up in keychain named along with 1000 others..
Help :( ?
Sorry for long and extremely boring/noobish question.
I think that your code doesn't build because of a certificate issue - like you said at the end of your question - you "downloaded a new certificate at some point containing the profiles..." You need to understand that a certificate does not 'contain' profiles, but profiles are created and signed using a specific certificate. Check that you have the private key of this certificate - if the signing request was not issued by you, it will require someone else exporting this certificate for you from his own keychain. Keep in mind that downloading the certificate available in your developer account will not suffice.
As for everything else:
Which profiles goes where?
Make sure you're creating relevant profiles with correct bundle IDs for your apps. Distribution profiles should include AdHoc and AppStore profiles, while Development profiles are, well, for development :)
What is the difference between the profile containing myself as an AppID and the one containing my actual app's ID as AppID?
Not sure what you mean here. Myself as an AppID? Each profile is linked to a specific App ID that has a bundle ID - it can be used to compile any app that has this bundle or any sub-domain of it in the info.plist of the project.
What is the difference between Target->Build Settings and Project->Build Settings when it comes to Code Signing?
You can think of your Project->Build Settings as the global settings and the Target->Build Settings as the target-specific settings. If XCode can't figure out which profile to use from the target settings, it will go and fetch it from the project settings.
The problem was that after we had released our app to the AppStore, we forgot to put the "Edit Scheme->Run" back to Debug from Release. This had no effect on my iPhone because I have added it to the release-provisioning-test thing.
I'm getting a "new" kind of error in the provisioning hell from iPhone. Does anyone have an idea what's going on .. because reinstalling , redownloading of the profile doesn't work.
I've uploaded a screenshot.
http://img94.imageshack.us/img94/1559/picture15f.png
So the part where it says cannot be installed on devices?
If that is your distribution certificate (as your title implies) then the error message is correct. Distribution certificates are only for submitting applications to Apple for review.
Instead you will want to install a development certificate on your phone. That will allow you to load your phone with your own code for testing before submitting to Apple.
I would absolutely call it hell. Signing my first app for Apple is taking 100 times longer than it took for Android. I'm not quite sure why such tight security is needed. I've been spending an entire day on this security stuff. I'm sure once I figure it out it won't be too horrible, but this is a real pain so far.