I'm a software developer who works as a freelancer, and my question has two parts.
First part:
I was working on a project then out of nowhere while testing on windows 10 VM windows security start blocking my app, I have a legit Bitdeferter and Malwarebytes on my main machine, and when I scanned my app (the EXE file from C# project) everything is clean, yet when I uploaded the file to virustotal.com it shows 5 detections
I start doubting my code and NuGet packages (I use Microsoft.AspNet.WebApi.Client and Newtonsoft.Json) so I removed them and to my surprise, I only got 2 detections out of 5.
I even create an empty Console app and still get those 2 detections, and my main machine still shows nothing as a virus.
So does that mean that my app is good but needs to be signed?
Second part:
If my issue is just a signing certificate, do I need as a developer to obtain that or my client, and then I only sign his/her app under his/her certificate?
Thank you.
Many engines treat VirusTotal samples very harshly, and any new executable has very low reputation (never having been seen before).
Therefore you will get lots of false-positives from VirusTotal when looking at your own new binary.
Signing is likely to help somewhat - at least there's a chance that you can build reputation in your certificate rather than each binary separately.
As far as I know, you get the signing certificate for you as a developer, although that might be different if you are providing source code and the client is building the end executable.
Related
I’ll set my outrage with the way this process works (to whom can I speak?) aside for the moment: we are attempting to provide FB with a link to our ~200 mb app for approval. We have been rejected 3 times because they are incapable of extracting our zip file (they request a zip for some unknown reason — it has minimal size impact).
Some detail: we are linking to the zip on our Dropbox. We have removed all punctuation from our app title (Pandamonium!.app becomes Pandamonium.app). We have eliminated spaces from our source folder. I thought all these could be causing a problem with iOS-sim.
I’m not sure what is left to do, but I am hoping someone can present a clear set of instructions (NOT THEIR INSTRUCTIONS, WHICH I HAVE READ) they have followed particularly if you have met similar snags or ANY ideas for resolution. All they send me is useless screenshots of their simulator unable to open the app which I have simulated and opened successfully daily with iOS-sim for the last week.
After a great deal of trial and error I found that using Facebook's command-line instructions was what was causing the issue. You should just compress your .app file in an ordinary fashion (right click and compress -- I used a Windows computer just to make sure everything was copasetic after reading about bizarre Mac .cbgz compression issues).
Regardless, in summary, I can now see why no one else has had an issue with this: it's because no one reads their instructions and rather just creates their .zip files in the ordinary way; unsurprisingly, you're better off using your common sense rather than listening to others.
Aside: ironically, after being told my use case was fine and the only issue was not being able to unzip, Facebook (India) has now told me they couldn't find my login button (which is gigantic, in multiple places, and clearly described in my instructions). This process is an absolute joke. I wish anyone going through this hell good luck.
I have a ClickOnce application deployed on our internal network. As this is only an "internal" application, I don't really need an "officially signed" certificate for any reason. When I went to publish an update today, I got the error message
The signers's certificate is not valid for signing.
When I check the "Signing" tab in Visual Studio 2010, I can see that I am past the expiration date. I know that I created this TemporaryKey using the "Create Test Certificate" button on this same tab in Visual Studio.
In the past, I just created a new test certificate, and used that. This essentially "buys" me another year until I have to do this all over again. I would like to correctly sign a new certificate that is good for X number of years (or never expires).
I have done some research, but as I am unfamiliar with this whole scenario, the nomenclature is extremely confusing. I can follow instructions, but only if they are written in a manner that an intermediate user can understand. Is there a reference that explains this process step by step, hopefully with screenshots? I can't believe with all my looking around I haven't found this already, so I must not be looking up the relevant keywords.
For future reference, here is all the information you ever wanted about expiring certificates in ClickOnce deployments. It also shows you how to create a certificate and set the date range for which it is valid.
Use Xenos Certificate Generator, a free tool that will allow you to create a certificate with x number of days until expiration.
I'm going crazy! I'm trying to upload the binary of my first application but I have always the same error!
"The binary you uploaded was invalid. The signature was invalid, or it was not signed with an Apple submission certificate."
I did everything, EVERYTHING!!
I created the request for the certificate, used it for both developer and distribution certificate, created the provisioning profile (12 times!!!) always cleaning my keychain and my Xcode deleting the old certificates and profiles..
I reboot the machine, reboot Xcode, the log is correct, but... I can't upload my app!!!!
Checked if my iPhone is connected (i tried with iPhone disconneted too).
I checked the certificate in both my project settings "Distribuition" Configuration (duplicate of "Release" configuration) and in my target settings.
Reveal in finder, compress the app and sent the zip...
I tried with Application Loader and iTunes connect online..
but nothing! NOTHING!!
I've spent 8 hours! And again i can't have my app uploaded!!!
I'm really going crazy!
Can anyone help me pleeease?
Thx!
It seems like there are a LOT of causes for receiving this cryptic and mostly unhelpful email. Even after verifying the use of distribution certificates, cleaning & rebuilding my project, and checking with codesign from the command line (and following instructions from the email), no errors showed up—-but I'd get the "invalid signature" email right after uploading. All the solutions seem anecdotal and obviously depend on what secret error is causing the problem. I've spent the last week pulling my hair out, trying to figure it out for my app—-and finally got it successfully submitted today—so let me share my story and see if it's relevant to your situation.
In my case, I seemed to have a complex cause of having my Entitlement.plist set with an incorrect variable along with the holdover of an old provisioning profile (from a previous Xcode version?) buried deep in the project.pbxproj component of my Xcode project file.
The "aps-environment" variable in my Entitlements.plist was set to "distribution" instead of "production" (I swear I read somewhere in the developer docs that it was supposed to be "distribution"!) But fixing that alone wasn't enough to get my app through. (I must have submitted 100 different combinations of app configurations trying different variables!) Starting with the helpful suggestions from this post on another forum, I dug through the distribution profile and found duplicate entries for some variables. The duplicates had empty quotation marks (i.e. nothing set for the variable) or strange variables or old provisioning profiles which seemed to be causing problems (somehow). Cleaning this up and removing the duplicate lines with bad variables worked in my case. YMMV. But carefully examining the project files ("show contents" on the Xcode project file in finder) seems like a good idea for diagnostics. Good luck!
Been there - done that.
Make sure your certificate is in the "login" keychain, and that that i the default keychain (highlighted bold) in Keychain Access
Make sure you have both the private and public keys for your certificates and that they are valid. You will also need the Apple Worldwide Developer Relations Cert Authority installed.
I assume you have dragged the profile into xcode - easiest to drop them onto the xcode icon on the dock.
Make sure as Paul says, that the bundle identifiers all match up
You say you checked the certificate in the distribution configuration. Its not the certificate you need to concentrate on but the provisioning profile.
Select your Release config top left, click on the project under groups & files and do cmd I. Select build tab and then pick distribution in the top left. Then look at the Code Signing Identity. Pull down the dropdown list and make sure you have the right application identifier, the right profile and the right certificate. Don't use the Automatic Profile Selector.
Hope one of those steps helps!
I was getting the same error when I tried to submit a version update from the Organizer. What solved my issue was using the Application Loader found in the directory /Developer/Applications/Utilities. You'll need to compress your .app file and send the corresponding .zip file. I used this for my initial submission as well, I just thought I'd try the new way. What a pain! Go with Application Loader.
Best solution:
Revoke Distribution Certificate
Create new AppStore provisioning profile
This solved my problem. Spent 4hrs+ :( :)
I just had this problem. I resolved it, after hair-pulling, by going back into Keychain Access one more time and discovering the "Show Expired Certificates" menu item. When I did that, one more expired cert of the kind I had (so far, unsuccessfully) replaced showed up! I had deleted a couple of expired certs already, but this menu item caused another to show up, and after deleting it, my upload worked. I was previously aware that expired certs can get in the way of valid ones, and I STILL wasted a lot of time. Hopefully, this helps some people.
iTunes connect keeps rejecting my binary for an application update and it's driving me mad. Usually I can figure it out but I've tried everything I can think of. Maybe someone can lend a hand :)
The error I'm getting is:
The binary you uploaded was invalid. The signature was invalid, or it was not signed with an Apple submission certificate.
I am uploading an updated version of my app to the store. The current version is 1.0, this new one is 3.0. Here's what I've tried:
Zipped the app bundle with the
command line (I've heard the Finder
zip utility can be bad sometimes)
Checked my app is signed properly
with $> codesign -vv myApp (says
"Valid on disk)
Checked in the build
log for the correct provisioning junk
to be there
Made sure in my
Info.plist file the CFBundleVersion
and CFShortBundleVersion are
incremented from my current version
That's what I can think of to check so far, and everything looks good as far as I can tell.
Now I've read somewhere in the Portal that says you must sign updates with the same Distribution Cert as before, and I am (I think). However I have to sign with a new provisioning profile because the old one I used for App Store has expired (or something, I don't know it just won't work).
Things to know about my situation
This update is actually a complete re-write from a new template, BUT I've made sure I'm using the exact same App ID (wildcard) and bundle indentifier) so that shouldn't be a problem.
Also, I've switched machines since I last submitted to the App Store but I remembered to export everything (I think) from my old machine. I still have the old one here, with all the same data on it, if that's helpful. I don't think I've forgotten anything).
Thanks in advance for any help :)
Update
So I've decided to try uploading with the Application Loader to see if it will give me any new errors, and it has, it spewed this out into the console. Perhaps someone can find something meaningful there.
Also of note, the Portal Guide says Updates must be signed with the original Distribution Provisioning profile as was used to sign the original app. I've tried using that old one, but Xcode won't let me select it, as there's "No matching key pair" or whatever. Is there a way to remedy this? According to Keychain I've got my Distribution Cert and its private key, it all looks valid. I've made sure to try Repairing the Keychain in case, but no change.
This is always the fun part, isn't it?
Assuming you've double and triple checked the usual stuff (using the right cert, compiling for device, have a proper icon file, app ID, etc.)
One obscure reason I've run into was roughly the same as the one outlined here:
http://discussions.apple.com/message.jspa?messageID=9167082#9167082
To sum up, my project.pbxproj file somehow ended up with two different entries for PROVISIONING_PROFILE (even though the XCode interface only showed one). My file looked a bit different from the one posted in that discussion, but removing the extra entry fixed the problem for me.
It's simple! Just let Finder zip it.
Motivation — I had a new version of my Cocoa application ready that worked fine on all beta testers' machines. So I released it. Turns out that a crucial feature simply doesn't work on anybody else's computer. Yikes! Yes, read that again: I released software that didn't work.
Cause — Users who had used previous versions my app (read: all my loyal beta testers) already had a folder ~/Application Support/MyApp/ from an older version. Due to the critical bug in the new release, this folder was necessary for the software to work. And for everybody else, because the folder did not exist, it didn't work.
As you can imagine, this is extremely embarrassing, and I want this to never, ever, happen again.
Remedies? — The straight-forward way to ensure this, of course, is to actually download and install it on a "clean" machine just before you publish a new release. But this seems impractical, because in time I will run out of friends with a Mac who have never tried my app yet (eventually all will have ;-)), and because I'm not eager to "format c:" my Mac before every single release…
This is where I need your help:
How can I ensure that a user who has never used my software before will get the same results as someone who has?
Virtual machines (VMWare Workstation, etc.) can be useful for testing clean installs of applications. You can start up a new virtual OS, install your stuff, test it, then delete the VM when you're done. There are ways to automate the spinning-up of a VM as well, which can make your life even easier.
Another thing to do is to determine all the prerequisites your app requires, and add checks for these things at startup. If something is not setup right, you can either attempt to set it up within your code, or inform the user to do it.
A more lightweight approach might be using tools like AppZapper to get rid of everything — temporary files, preferences, cache, history, etc – related to the app to test.