|Signing a deployed version (3.2.3 (build 2891.2932) Unsigned)||Marcel Trapman||4/6/12 7:11 AM|
I have signed a deployed version of 'Tunnelblick 3.2.3 (build 2891.2932) Unsigned'.
So far so good.
However, when running the app for the first time it wants to update to the same version (but I assume without a signature) immediately.
Is there a way to avoid this (remove all sparkle settings from Info.plist or add SUEnableAutomaticChecks and set it to false)?
Or is it better to just work unsigned but, if this is the case, what happens when users have GateKeeper enabled in 10.8?
|Re: Signing a deployed version (3.2.3 (build 2891.2932) Unsigned)||jkbull...gmail.com||4/6/12 10:32 AM|
It shouldn't be asking to update to the same (but unsigned) version.
One requirement is that you sign the application after you add the Deploy folder and make any other modifications to the application.
You should examine the Console Log the first time you run the application -- it should indicate why it is asking for an update.
There could be a bug, of course, but as long as Tunnelblick can verify that the signature is valid, it shouldn't be asking for an update to an unsigned version.
The commands to properly sign Tunnelblick are as follows:
codesign -s SigningReference "Tunnelblick.app/Contents/Resources/atsystemstart"
where "SigningReference" is the name of the signing identity in the login Keychain.
|Re: Signing a deployed version (3.2.3 (build 2891.2932) Unsigned)||jkbull...gmail.com||4/7/12 9:00 PM|
It looks like you've found a bug -- I looked at the code and Deployed versions of Tunnelblick are not checking for a signature properly. This will be fixed in the next release (in time for Mountain Lion).
|Re: Signing a deployed version (3.2.3 (build 2891.2932) Unsigned)||jkbull...gmail.com||4/8/12 4:38 AM|
I was wrong. It is more complicated than that; there isn't a bug to be fixed.
The problem is that, when a Deployed version is updated from the Tunnelblick website, the signature will become invalid. That happens because after updating Tunnelblick the Deploy folder is copied into the (new) copy of Tunnelblick, which invalidates the new copy's signature. That's the way that Deployed versions of Tunnelblick work -- the Deploy folder is always backed up, and if the application is updated, the Deploy folder is restored from backup. That restoration invalidates the signature.
So one solution is to not sign Deployed versions. Note, however, that in that case you have no way to update your users' configurations (i.e., their Deploy folder).
If you really want to sign a Deployed version (which, as you said, will be needed for Mountain Lion), you must also maintain your own update site, and when updating, always update with a full version that contains the Deploy folder and is signed.
An alternative, which gets around this problem, is not to use a Deployed version, but, instead, use a "Tunnelblick Configurations.bundle", which contains (among other things) a set of "Tunnelblick VPN Configurations" (.tblks). They allow the program and the set of configurations to be updated separately -- you can update the program using the official Tunnelblick website, and the configurations using your own website. There isn't any documentation about them, yet, but I hope to write some "soon".
In the meantime, you can either (A) use unsigned versions, or (B) maintain your own update site for Tunnelblick..
|Re: Signing a deployed version (3.2.3 (build 2891.2932) Unsigned)||Marcel Trapman||4/9/12 1:19 AM|
Thank you for your answers!
The app is frequently updated with new configurations so, based on your answer, I decided to bypass the issue and remove the update url for now (and disable automatic update checks).
Having said that I suppose that your suggestion to use "Tunnelblick VPN Configurations" (.tblks) is a better solution in the future.
I look forward to the documentation :)