I am developing some freeware applications. Mostly they are written in Java to make them run on multiple systems. Meanwhile I have some thousand users and so it makes a lot of fun.
To make the Java apps easier to run under Windows, I also create executable wrappers using launch4j and installer applications using inno setup.
Now I have problem, because of Windows 8. In former Windows versions the OS just showed up a message by trying to start such an executable which was saying that the exe file comes from an "unknown" vendor. In Windows 8 they made it even harder. There is something like "Windows protected you from this dangerous application!".
So I am highly interested in signing my apps. But I am not willing to pay anything for this as I offer my software for free. Using Google I found the "CAcert" project that allows people to create free certificates. But I haven't found detailed information about the following questions:
can I create certificates to sign executables?
can I create certificates using my company name?
Is there anyone familiar with CAcert?
Or has anyone another hint to solve my problem?
thanks a lot...
Well, you can use use a CAcert certificate to sign your code, but it won't help you. That's because the OS doesn't install the CAcert root certificate.
If you want to stop your users seeing these messages you'll need to obtain a commercial certificate.
Related
I cross-compiled a simple software from linux to windows through Fyne.
The software is pretty easy and straightforward, it just creates QR codes from an input given by the user, nothing special.
It works flawlessly but Windows Defender wakes up and alerts me there's a trojan, and it eventually deletes the .exe.
For more context, I didn't sign the software while compiling it. But I don't really need to distribute it, it's just a utility I'm going to use privately.
Any of you guys has experienced this issue before? Could be related to the cross-compiling procedure? Or maybe a sign is mandatory? Can depend by the QR code library I'm using, since it's the unique non-standard library I included?
There have been many reports of Go applications triggering windows virus detection, this is a problem with more than just your cross-compiled app.
As we live in a “default virus” world the defender rules need to understand Go apps, which has not yet happened.
In the meantime the only way to resolve this is to sign your apps I think.
I am quite confused as to the proper way of distributing Bonjour as a part of a Windows application that would publish a service for a client iOS app.
No matter how much I google around, I cannot find a clear how-to guide. It would be great if someone could provide guidelines.
The main reasons of my confusion are:
Is it mandatory to distribute the entire bonjour Win SDK as a part of my Win application?
Since Apple provides source code to build mDNSResponder.exe, is it sufficient to only distribute such file along with dns-sd.dll?
What is the intended purpose of providing sources for mDNSResponder.exe otherwise?
What is the recommended way to handle the possibility of having Bonjour already installed on the system?
Also, where can I find the latest Bonjour SDK (3.x I guess?), I can only find 2.0.4. Is it only accessible if I am enrolled in the OSX developer program? (I am enrolled in iOS developer program for now.)
Many thanks.
This is information I gathered from various sources, including communications with official Apple support. I report it in the way I believe to be accurate, I hope it can be useful (no liability assumed!).
For Bonjour-enabled Windows application you have basically two main options:
Bundle the Bonjour Installer with your application (which is not the Bonjour SDK, the SDK if for your own developer use only).
If you choose to do so, the Bonjour installer must be called from your own installer during the installation process. The possibility of Bonjour being already installed in the system is totally handled by the Bonjour installer.
And here come some bad news: you must include de Bonjour Logo on your physical distribution medium (like a DVD cover sleeve) according to the Apple guidelines specified in the Windows Bundling Agreement, and you need Apple approval before distributing your product.
Do not bundle. I.e., do not distribute Bonjour with your application but simply use it if already present in the system. If you do not distribute Bonjour in any form the whole Windows Bundling Agreement simply does not apply. You application should search for the dnssd.dll and load it dynamically if found.
Consider that most of Windows users would have Bonjour already installed due to the fact that some popular apps use it (for example iTunes and Skype).
While the source code of Bonjour is released under an open-source library (Apache License, Version 2.0) this does not require Apple to do anything. In particular, they do not need to document how you'd use this license.
The license allows you to use and adapt Apple's source code, including its copyright, but not including its trademark "Bonjour(TM)". Since this is the standard Apache license, you don't have the requirement either to show the trademark.
So, to answer your questions:
No, you can build your own version of Bonjour from source and use that under the Apache license. You can't call it Bonjour, but why do you need a name in the first place? "mDNS" would be a reasonable choice, possibly prefixed with your trademark.
It seems sufficient to distribute the DLL and EXE. Arranging how they find each other might benefit from some tailoring, so your own build of Bonjour doesn't clash with Apple's.
(I won't speculate on Apple's motives)
The design problem here is that Bonjour acts as a system service, and services are inherently singletons. If you install it unmodified, Apple wouldn't be able to install its own build. That's not a legal problem, probably, but it is a bad customer experience. Installing your own build as a distinct service would avoid the clash, allowing both versions to co-exist.
(Resource request, off-topic)
I've been asked to redesign our build/sign/release processes. I'm pretty happy with Windows stuff and I've identified several networked-HSM products that will do what we need. They basically integrate directly with CryptoAPI so the people doing the signing can just use signtool.exe as normal.
We currently have a separate Mac team who do their own build/sign/release. This is all working fine on a couple of Mac Minis in one of our DCs. I'd like to protect our Mac software keys as well and so I'm trying to find out how to integrate a networked-HSM into our Mac signing process.
I can't find any good information about this anywhere! So I'm hoping someone in here has done this already and can lessen my pain.
The actual questions are;
1) Can I use a HSM with the standard Mac code-signing tools?
2) Can anyone recommend a vendor/product for the above?
3) Can anyone point me towards some good documentation on Mac code signing and the inner-workings of the Mac crypto infrastructure?
Cheers
BHB
I don't believe any of the major HSM vendors (nCipher, SafeNet, etc.) have any hooks into the Mac code signing tools, nor do I believe Apple exposes any. Your best bet would be to try and determine what the code signing mechanism looks like when performed by the Mac tools and then try and duplicate it yourself manually. However, off the top of my head, I don't recall seeing that the major vendors support OSX-based HSM clients out of the box. I know that SafeNet supports Java via a custom JCE provider. If there's a PKCS#11 interface you can hook into, then you may be able to leverage OpenSSL or another similar toolkit, but it will result in some work for you.
I am developing an application in Flex using Adobe Flash Builder 4.5 and I want to distribute this as an AIR package so that it will work on multiple Operating Systems. I am wanting to target the usual suspects :-
Windows [what I currently develop on]
Apple [As I understand I need an actual Mac in order to package it] ?
Blackberry Playbook. [Again I believe I need the actual Playbook etc] ?
I also want to eventually deploy the application to the Mobile platform. So that also means targetting Android. Now as far as I am aware, and all research indicates this, I can develop my single application in Flash Builder 4.5 and then deploy to all these platforms. Am I correct in this?
Now to my real question. Obviously I am aware that the application needs to be digitally signed, so can I purchase ONE digital certificate to sign for ALL Operating Systems? The reason I am confused on this is because I know there is something I need to purchase from Apple ($99 per year reacurring) but is that just to distribute via iTunes network or is that a certificate as well ? Presuming it is, can I use said certificate for all the above platforms ?
As you can tell I am probably getting everything all crossed up and confusing myself LOL, so some help would be greatly appreciated.Regards Anthoni
EDIT:- Found this link [url]http://codesigning.ksoftware.net/[/url]
Apparently it is a Comodo code signing certificate and it lists the platforms as both Adobe AIR AND Apple. Has anyone experiance with this code certificate ?
Comodo certificates do work on all of the platforms you mentioned.
I develop a desktop application for use on Windows, and was wondering how I can get my executables signed so they stop showing those horrible looking warning messages about being from an unknown publisher. I am somewhat familiar with signing binaries before releasing them. I have a Linux port of the same program which is distributed though it's own signed repository (apt-get).
The process for signing windows executables seems extremely complicated and I can't find a simple tutorial on what to do, rather thousands of webpages describing only parts of the process, or which go into way too much depth.
I just need a quick list of steps which are necessary to sign executables under windows. I believe it's called "authenticode".
Tools see MSFT Introduction to Code Signing
edit: you buy a certificate from a provider - most web registrars sell them.
Then simply sign the executable using the msft tools
see http://www.instantssl.com/code-signing/code-signing-process.html