Updatable Configurations

[n9yty]

Wow, with the auto install feature introduced in beta30 and the Updatable Configurations in beta32, this is looking to be so much easier to administer for even my small group of users. And at a perfect time as I am about to roll out a new set of configs/keys. :)

But one question I have is that the initial install has the keys in the auto-installed configuration.  This is OK as we secure the disk image it is installed on, as well as using two-factor authentication to connect to the server.

So, in doing the Updatable Configuration via Sparkle, is it possible to do an update that only downloads the changed openvpn configuration file or parts of the .tblk bundle that need to change, or must the whole bundle be downloaded?  If the whole bundle, then this might be problematic as each user would need a separate full bundle with their keys in it.

Obviously, once again, I am perhaps just missing something important.  :)

Thanks for any clarifications.

[jkbull...gmail.com]

Comments below.

On Thursday, July 17, 2014 6:27:48 PM UTC-4, n9yty wrote:

Wow, with the auto install feature introduced in beta30 and the Updatable Configurations in beta32, this is looking to be so much easier to administer for even my small group of users. And at a perfect time as I am about to roll out a new set of configs/keys. :)

Glad you like the new features. Actually, the auto-install feature has been there for a long time, maybe even since the first .tblks.

But the beta30 changes do make it much easier to generate a .tblk with a bunch of configurations now, since you don't need to create actual .tblks. You can have a .tblk that contains a bunch of OpenVPN configuration files, certificate files, and key files (and maybe an Info.plist) -- it no longer needs to have each OpenVPN configuration in a separate .tblk.

But one question I have is that the initial install has the keys in the auto-installed configuration.  This is OK as we secure the disk image it is installed on, as well as using two-factor authentication to connect to the server.

So, in doing the Updatable Configuration via Sparkle, is it possible to do an update that only downloads the changed openvpn configuration file or parts of the .tblk bundle that need to change, or must the whole bundle be downloaded?  If the whole bundle, then this might be problematic as each user would need a separate full bundle with their keys in it.

Yes, the entire bundle is downloaded and replaced.

But I see your point -- I guess I didn't think this through. So maybe that has to change.

The basic idea is to distribute updated configurations that replace only _some_ files and leave others.

I think a simple addition to the Info.plist would make this possible:

Idea #1:

I could add a new Info.plist key: TBKeepExistingFile. The value would be the name of a file (possibly prefixed by one or more subfolders) that, although it would appear in the OpenVPN configuration file, would not be in the new configuration. Tunnelblick, when _replacing_ a configuration, would copy the existing file into the new configuration.

  

Idea #2:

I could add a new Info.plist key: TBKeepExistingFiles, as a boolean.

 

IF       the OpenVPN configuration file references a file that isn't in the new configuration

THEN IF  TBKeepExisting is true

          AND   this is a _replacement_ configuration

          AND   the file exists in the old configuration

          THEN copy the existing file from the old configuration to the new one

          ELSE complain as we do now and stop the installation.

Both ideas would only work for private configurations, because the keys for shared configurations are not readable by the user (the main part of the installer runs as the user).

#2 is simpler would be easier for me to implement (I think), and I think it is easier for configuration distributors, too, since you could just put the one key in the outer .tblk's Info.plist. It would be overridden by the same key in an inner .tblk (just like TBSharePackage and TBReplaceIdentical) so you could have it work selectively. Since #2 doesn't include filenames, it would be easier to set up, but also easier to screw up -- if you have TBKeepExistingFiles set and you accidentally leave out a file, Tunnelblick will happily use the old one, which may not be what you want.

 

Obviously, once again, I am perhaps just missing something important.  :)

I guess it was _me_ who missed something important!

So: comments, questions, suggestions? I would really like some input!

[n9yty]

On Thursday, July 17, 2014 6:50:41 PM UTC-5, jkbull...gmail.com wrote:

The basic idea is to distribute updated configurations that replace only _some_ files and leave others.

 At least for me this seems like how I would want/expect it to operate. But I understand that you wouldn't want to be leaving a lot of old files around.  For that reason, I think I do like your option two, which thankfully you said was likely easier for you anyway. :)

 

Idea #1:

I could add a new Info.plist key: TBKeepExistingFile. The value would be the name of a file (possibly prefixed by one or more subfolders) that, although it would appear in the OpenVPN configuration file, would not be in the new configuration. Tunnelblick, when _replacing_ a configuration, would copy the existing file into the new configuration.

 I guess this seems like perhaps more work because you would have to manage WHICH files to keep. That may not be a big problem, but it is one more thing to keep track of as you are crafting new update bundles.

 

Idea #2:

I could add a new Info.plist key: TBKeepExistingFiles, as a boolean.

IF       the OpenVPN configuration file references a file that isn't in the new configuration

THEN IF  TBKeepExisting is true

          AND   this is a _replacement_ configuration

          AND   the file exists in the old configuration

          THEN copy the existing file from the old configuration to the new one

          ELSE complain as we do now and stop the installation.

 I like this because it keeps any old unused things from lying around as you only keep things that are actually in use but are not being purposefully updated.

 

Both ideas would only work for private configurations, because the keys for shared configurations are not readable by the user (the main part of the installer runs as the user).

 While this may affect some users, at least for my installs I wouldn't have a pre-packaged key file in a public configuration. I assume this means the configurations that live in /Library/Application Support/Tunnelblick?

 

Since #2 doesn't include filenames, it would be easier to set up, but also easier to screw up -- if you have TBKeepExistingFiles set and you accidentally leave out a file, Tunnelblick will happily use the old one, which may not be what you want.

 This is true, but I suppose the same is true of case #1 if you forget to specifically mention a file you need to have kept and then have an incomplete configuration. Either way will require some care and testing of a new configuration update before you roll it out to the central server I would think.

 

So: comments, questions, suggestions? I would really like some input!

I think I like option #2, as it basically does what I was thinking in that you can send an update bundle out with an updated config file, and anything referenced in there either has to exist in the new bundle or, if missing, can be taken from the old bundle. This is just about how I would have expected it to work, so I would be very happy with this. :)

Thanks for thinking about the suggestion.

One other small point on the Sparkle appcast.rss file and the length="" field of the enclosure section... You say that this is the size of the .tblk, obtained via `stat -f %z configurations.tblk` or via the Finder "Get Info".  But they give different things....

 

 $ stat -f %z TEST.tblk

 102

 Finder: 65,762 bytes (82 KB on disk)

 Very different numbers. :)

 -Steve

[jkbull...gmail.com]

Thanks for your thoughts. I hope someone else chimes in, too. I address a couple of your points below.

On Thursday, July 17, 2014 8:18:08 PM UTC-4, n9yty wrote:

Both ideas would only work for private configurations, because the keys for shared configurations are not readable by the user (the main part of the installer runs as the user).

 While this may affect some users, at least for my installs I wouldn't have a pre-packaged key file in a public configuration. I assume this means the configurations that live in /Library/Application Support/Tunnelblick?

The private configurations (which this new key would work for) live in $HOME/Library/Application Support/Tunnelblick/Configurations. The user has complete access to them, including any keys, certs, etc.

The shared configurations (for which the new key would NOT work) are in /Library/Application Support/Tunnelblick/Shared. Only root can see the contents of those, except for the sanitized configuration file (all inline keys/certs removed).

One other small point on the Sparkle appcast.rss file and the length="" field of the enclosure section... You say that this is the size of the .tblk, obtained via `stat -f %z configurations.tblk` or via the Finder "Get Info".  But they give different things....

 

 $ stat -f %z TEST.tblk

 102

 Finder: 65,762 bytes (82 KB on disk)

 Very different numbers. :)

Oops, thanks for catching that. It was totally wrong. I guess writing from memory was a bad idea.

The stat -f %z is on the .zip or .dmg, just like the signature. (That's what the scripts that prepare Tunnelblick updates use.)

I could swear that Finder's Get Info used to give the same size, but it doesn't (on 3.4beta30.dmg, FInder says it is 12,779,997 bytes, stat says 12,778,327. Use the number from stat. (When testing this new feature, I thought I used the number from Get Info, though. So try both if you have to. Sparkle has terrible error messages that say basically "something went wrong", so it's hard to figure out problems with appcasts.)

I've fixed the wiki page.

Still hoping for input from others!

[jkbull...gmail.com]

Four things:

1. I expect to have a "snapshot" (pre-release version of Tunnelblick) with this new feature later today (US east coast time) and will post here when it is available.

2. Just to be clear, the installer log will indicate that the existing file was used, but no dialog window will be displayed.

3. After looking into the security implications of implementing this, there will be an additional restriction:

• The file must not be a ".sh" file. (Or, of course, a ".ovpn" or ".conf" file, but a valid config file can't contain a reference to one, so that's not really a problem.)

4. I decided (somewhat arbitrarily but I think it's the correct decision) to impose another restriction, too:

• The file reference in the configuration file must not be an absolute path or a path relative to the user's home folder (which is unusual but can be done).

So the new feature is now

IF       the OpenVPN configuration file references a file that does not exist

THEN IF  TBUseExistingFiles is true (the default is false)

          AND   the file does not have a ".sh" extension

          AND   the file reference in the configuration file does not have an absolute path or a path relative to the user's home folder 

          AND   the file exists in the unsecured copy of the old configuration (i.e., in ~/Library/Application Support/Tunnelblick/Configurations/...)

          THEN copy the existing file from the unsecured copy of the old configuration to the new one that is being installed

          ELSE complain as we do now and stop the installation.

The reason for restriction #3 is that Tunnelblick will use the unsecured copy of the file in the existing configuration. That is the only copy that the user has access to -- the secured copy (the alternate or shadow copy) of a key file (for example) is not readable by the user (see note below).

Using an unsecured copy of a key or certificate shouldn't be a problem; the worst that happens if a non-admin user modifies it is that an authentication will fail. But if we allow the use of an unsecured copy of a script file (which runs as root when the configuration is connected) that would be a big problem.

Maybe I'm being paranoid, but I don't want a user to be able to modify his private copy of a script file, then call over an administrator to install an updated configuration and have the administrator unknowingly cause the user's modified script file be copied into the updated (and secured) configuration.

Of course, a malicious user M could try to impersonate another user U (if M had U's private information) by modifying M's unsecured data to match U's and then tricking an administrator into installing an updated configuration. So the administrator should always check the log after an installation to see what was done.

I don't think this restriction is a major problem. If a script file needs to be tailored for the user, it could read data from a per-user ".key" file (that really isn't a cryptographic key) and modify its operation accordingly. But the script file and/or the administrator installing an updated .tblk must assume that such a ".key" file may be modified by a malicious user and act accordingly. For example, a "username.key" file could contain the VPN service's username, and the script could use that username. But the script must deal with the possibility that the username has been modified by a malicious user before asking an administrator to install the configuration.

-------------------------

Note: Tunnelblick could check that the secured and unsecured copies are identical (as it does before connecting a private configuration) but that could lead to a TOCTOU issue (Time Of Check - Time Of Use issue) because it is the unsecured copy that will be used.

When Tunnelblick uses this check before connecting, TOCTOU isn't a problem because it doesn't matter if the user modifies the insecure (private) copy after the check but before the file is used because it is the secure copy of the file that is being used, not the insecure (maliciously modified) copy.

In this case, we must use the insecure copy because that is the only one that we have read access to. I could use the secured copy by doing the installation as root, but I rejected that idea when I designed the installation process because it is too risky --  if there is a bug in the code, better to be running as the user than as root.

(Whew. It may have taken me longer to write this than it will to change the code! But I guess that's good.)

[Steve Palm]

On Jul 18, 2014, at 8:20 AM, jkbull...gmail.com <jkbu...@gmail.com> wrote:

3. After looking into the security implications of implementing this, there will be an additional restriction:

• The file must not be a ".sh" file. (Or, of course, a ".ovpn" or ".conf" file, but a valid config file can't contain a reference to one, so that's not really a problem.)

 This simply means that any custom up/down (are there other?) scripts would need to be included with any updated config that needs to use them. I don't think this would be a problem, at least in our case, because we don't have scripts that vary by user.  I wonder if anyone does? But I see you have thought of some provision for this below.

If you had a custom up/down script that, for example, for some users or groups of users, set DNS differently than for others, then I guess you would just push them out as different configs entirely and then you wouldn't have a problem. But this would require knowing you wanted to do this when you set up the initial configuration. So your idea of being able to have user-specific information available inside the config  is a very good one. And, I suppose, there is nothing that would prevent you, security issues being carefully considered, of having your custom shell script itself reference a file outside the .tblk package, anywhere on the system, which you could place there or update (and secure) via other remote administration tools.

I am happy to have this slight extra requirement in the name of improved security. Your example of allowing a user to modify a script and getting a non-vigilant admin to approve its use in an updated configuration should scare anyone. :)

I don't think this restriction is a major problem. If a script file needs to be tailored for the user, it could read data from a per-user ".key" file (that really isn't a cryptographic key) and modify its operation accordingly.

 I don't envision needing this right now, but who knows what next week will bring. {smile}

 Just to document it, how would you reference this .key file in the openvpn config file so that it wasn't really used but would still be copied over into a new config for reference by the script?

I appreciate your careful attention to security and for thinking this through. Since we have a fairly simple setup, it is hard to think through the wide variety of situations. I'm sure you have heard from many people with different setups, so it certainly makes sense that a solution tries to handle as many cases as possible.

[jkbull...gmail.com]

On Friday, July 18, 2014 9:52:27 AM UTC-4, n9yty wrote:

 Just to document it, how would you reference this .key file in the openvpn config file so that it wasn't really used but would still be copied over into a new config for reference by the script?

You wouldn't need to reference it in the OpenVPN configuration file. If a .tblk that is being installed contains "extra" files, they get copied into the final installed .tblk. I'm not sure that's documented anywhere; I will try to do so soon. The reason for this is that an "up" script (for example) could use other scripts that are in the .tblk. So the other scripts should be included. I do it for any file, not just for scripts, to make the code simple and to "allow for future expansion" (i.e., to allow for something I didn't think about when I designed it!). I guess such use of .key files would be such an expansion.

I appreciate your careful attention to security and for thinking this through. Since we have a fairly simple setup, it is hard to think through the wide variety of situations. I'm sure you have heard from many people with different setups, so it certainly makes sense that a solution tries to handle as many cases as possible.

On this subject, I haven't heard from anyone except you.

I rarely hear from people who use Tunnelblick or people who support people who use Tunnelblick. (That's a pet peeve of mine -- most discussions in this discussion group are configuration problems and I find almost all "bugs" in Tunnelblick myself.) So I try to be as paranoid as possible and design things to be as flexible as possible. (For example, the "TBPackageVersion" key exists and must be "1" because I want to have the possibility of a non-downward-compatible version "2", even though I doubt there will ever be one).

[Steve Palm]

On Jul 18, 2014, at 9:12 AM, jkbull...gmail.com <jkbu...@gmail.com> wrote:

On Friday, July 18, 2014 9:52:27 AM UTC-4, n9yty wrote:

 Just to document it, how would you reference this .key file in the openvpn config file so that it wasn't really used but would still be copied over into a new config for reference by the script?

You wouldn't need to reference it in the OpenVPN configuration file. If a .tblk that is being installed contains "extra" files, they get copied into the final installed .tblk. I'm not sure that's documented anywhere; I will try to do so soon.

 I meant if you had a .key file in an initial (perhaps manual/custom) configuration, then you wanted to do a update, it was my understanding you would not copy over any file from the original configuration that was not referenced in the new config file. Therefore, if you wanted to copy a .key file over from an old configuration into the new one that it would have to be referenced in the config file. Perhaps I misunderstood.

[jkbull...gmail.com]

Ah. My mistake. I didn't think of that. Part of my error was that, although I call them "updatable" configurations, they are actually "semi-automatically-installed new versions of configurations". That is, the original version of the configuration isn't really updated. Instead, a new version of it is installed, replacing it. Although this may seem like an academic distinction, what it really means is that we need to add to the options for "installing" a configuration -- the fact that the new version was downloaded semi-automatically is irrelevant.

I think we need to go back to my proposal #1, where the Info.plist entry has the filenames of files that should be propagated from the old configuration to the new one. To refine that proposal:

A new Info.plist key: TBKeepExistingFilesList. The value is be an array with the names (possibly prefixed by one or more subfolder names) of files that are to be copied from the old configuration to the new configuration. An error message would be displayed and the installation would be stopped if any of the files exist in the new configuration or do not exist in the old configuration.

There is a tricky catch to the new key, though: what to do about an inner .tblk TBKeepExistingFilesList overriding an outer .tblk one. We could (A) append the new array entries to the old ones while processing inside the inner .tblk or (B) replace the old array with the new one while inside the inner .tblk. Probably (B), but that needs more thought.

The alternative would be to first copy everything from the old config in the new config, and then do the normal processing (replacing old files that appear in the new config, but leaving old files that don't appear in the new config alone). The problem with that is that there isn't a way to "delete" a file -- once it is in a configuration, it will stay there and be propagated through updates forever. I don't like that.

 

This will be a bit more complicated to implement than I though, so it probably won't be done today {frown} (But soon, I hope.)

More input from anyone else (or you, Steve, of course) would be helpful.

On Friday, July 18, 2014 11:20:43 AM UTC-4, n9yty wrote:

[jkbull...gmail.com]

As an addendum to my description of TBKeepExistingFilesList:

The entries in the array could be either filenames (the name and extension only, without subfolder path info) or they could have a single * character somewhere, which would match any character in a filename. So

* would match any filename

abc* would match any filename which started with abc

abc*def.key would match any filename that starts with "abc" and ends with "def.key".

(There wouldn't be a way to escape the *, but you're not going to have a filename with a * in it anyway.)

So if you have key files with employee numbers named "com.example.user12345.key" you could match all of them with "com.example.user*.key".

I think this would remove most of the burden of having to list the files and make this way of doing it reasonably manageable.

[jkbull...gmail.com]

I have committed changes to the source code for TBKeepExistingFilesList and built a "snapshot" (pre-release version) of Tunnelblick which includes it.

Anyone can download the snapshot. For a link to do so, please email me privately at jkbullard at gmail. (Steve, I am emailing you a link separately.)

[n9yty]

Trying to test this, but not having much luck.

Rather than going into great details about what I have or have not set up, I thought I would first ask is there is any way to turn on some debugging information with regard to updating configurations?  I tried the "Copy Diagnostic info to Clipboard" but see noting there with regard to configuration updates. I have tried disconnecting/reconnecting the config in question, and even quitting/restarting Tunnelblick but I see nothing indicating an attempt to update.I don't even see the server reporting an attempt to read the appcast file, so where to start looking...

The very basic things I think were needed to get it to check were:

CONFIG.tblk/Contents/Info.plist:

 Key: CFBundleIdentifier

 Key: CFBundleVersion

 Key: TBBundleVersion

 Key: SUFeedURL

 Key: SUScheduledCheckInterval

So I have those keys set, have manually verified the SUFeedURL does return the appcast file, but yet Tunnelblick seems to not be checking for updates.

UPDATE:  I deleted and re-installed the config rather than editing it in place, seems to not have changed anything, but I'm doing more testing.  However, the info here:   https://code.google.com/p/tunnelblick/wiki/cUpdatableConfigurations    sees to be incorrect as it mentions a TBBundleVersion key which I think should be TBPackageVersion based on the errors I found during install of my config.

Okay, that put something new in the log:

SUScheduledCheckInterval in Contents/Info.plist is less than 60 seconds; using 60 minutes.

But the value in the plist should be 60 seconds:

       <key>SUScheduledCheckInterval</key>

       <string>60</string>

 

Should it be an <integer>60</integer> instead?

[jkbull...gmail.com]

(Minor point: you don't need to put stuff in a .tblk into Contents and/or Resources. That's how it is arranged after being installed, but the .tblk that you double-click can just have all the files directly in the .tblk folder.)

In general, anything to do with updatable.tblks will appear in the Console log. Nothing will show up in the log you see in the VPN Details window, and the updates have nothing to do with connecting or disconnecting configurations.

You can set a preference for debugging info (the info is more for me than for you, but it might be helpful) by pasting the following into Terminal:

defaults write net.tunnelblick.tunnelblick DB-UC -bool yes

The info will show up in the Console log.

Install the updatable .tblk by double-clicking it as usual. (Look in the Console log to see if there are any messages toward the end that refer to the updatable configuration.) Double-clicking the .tblk should install whatever configuration(s) are inside the .tblk as usual, and then it should also create a folder at

/Library/Application Support/Tunnelblick/Tblks/xxx.yyy.zzz.tblk

where "xxx.yyy.zzz" is the CFBundleIdentifier for the updatable .tblk. That folder is a "stub" .tblk and contains only a Contents folder which contains only a copy of the Info.plist for the updatable .tblk.

Make sure that the stub .tblk is there. If it isn't, look in the Console log for a clue as to why the configuration wasn't considered "updatable". If you still can't figure it out, send me a .zip of the CONFIG.tblk privately at jkbullard at gmail.

Assuming the stub .tblk is there, Tunnelblick should start checking the URL for updates. I can't remember if it starts checking for updates immediately upon being installed. It should, but that could be a bug. In any case, restart Tunnelblick and you should see it checking for updates. You should see something like:

7/21/14 10:56:14 PM Tunnelblick[68890] DB-UC: Copied updatable configuration 'com.example.config.001.tblk' to local user folder

7/21/14 10:56:14 PM Tunnelblick[68890] DB-UC: Delaying start of update check for configuration set com.example.config.001

7/21/14 10:56:14 PM Tunnelblick[68890] DEBUG: Updater: systemVersion 10.6.8 satisfies minimumSystemVersion 10.4.0

7/21/14 10:56:14 PM Tunnelblick[68890] DEBUG: Updater: systemVersion 10.6.8 satisfies minimumSystemVersion 10.4.0

7/21/14 10:56:15 PM Tunnelblick[68890] DB-UC: Starting update check without UI for configuration 'com.example.config.001'; URL = https://example.com/config.001/appcast.rss

The 3 DB-UC messages are about Updatable Configurations. The two DEBUG messages are from the application updater, which is separate and can be ignored. (But the configuration updater waits until the application updater has started checking before it starts checking.)

[n9yty]

On Monday, July 21, 2014 10:10:59 PM UTC-5, jkbull...gmail.com wrote:

Install the updatable .tblk by double-clicking it as usual. (Look in the Console log to see if there are any messages toward the end that refer to the updatable configuration.) Double-clicking the .tblk should install whatever configuration(s) are inside the .tblk as usual, and then it should also create a folder at

/Library/Application Support/Tunnelblick/Tblks/xxx.yyy.zzz.tblk

where "xxx.yyy.zzz" is the CFBundleIdentifier for the updatable .tblk. That folder is a "stub" .tblk and contains only a Contents folder which contains only a copy of the Info.plist for the updatable .tblk.

 This was there, and also it included the public DSA key I used to sign the update.  However, the version number in the plist is that of my original config, not the one that it would be updated to. Maybe that is OK, just mentioning it. Anyway, I wasn't signing them initially, but tried it since things weren't working.  Now I know that was because I was editing a Info.plist file inside an already installed confirmation instead of installing one with that intact. My mistake.

 

Make sure that the stub .tblk is there. If it isn't, look in the Console log for a clue as to why the configuration wasn't considered "updatable". If you still can't figure it out, send me a .zip of the CONFIG.tblk privately at jkbullard at gmail.

 Here I see nothing...

 DB-UC: Copied updatable configuration 'xxx.yyy.zzz.TEST.tblk' to local user folder

 DB-UC: Delaying start of update check for configuration set xxx.yyy.zzz.TEST

 DB-UC: Starting update check without UI for configuration 'xxx.yyy.zzz.TEST'; URL = https://xxx.yy.zzz/tblk/appcast.rss

 DB-UC: cfgUpdater 0x8a377b0: didFinishLoadingAppcast

 So maybe something is wrong in the appcast format so that Tunnelblick thinks it is not supposed to update it? It looks good.

 If I don't get this sorted tomorrow (giving up for tonight), I will email you some pieces privately to have a quick look-over.

 Thanks!

 

[jkbull...gmail.com]

Hi,

On Tuesday, July 22, 2014 12:40:45 AM UTC-4, n9yty wrote:

On Monday, July 21, 2014 10:10:59 PM UTC-5, jkbull...gmail.com wrote:

Install the updatable .tblk by double-clicking it as usual. (Look in the Console log to see if there are any messages toward the end that refer to the updatable configuration.) Double-clicking the .tblk should install whatever configuration(s) are inside the .tblk as usual, and then it should also create a folder at

/Library/Application Support/Tunnelblick/Tblks/xxx.yyy.zzz.tblk

where "xxx.yyy.zzz" is the CFBundleIdentifier for the updatable .tblk. That folder is a "stub" .tblk and contains only a Contents folder which contains only a copy of the Info.plist for the updatable .tblk.

 This was there, and also it included the public DSA key I used to sign the update.  However, the version number in the plist is that of my original config, not the one that it would be updated to. Maybe that is OK, just mentioning it. Anyway, I wasn't signing them initially, but tried it since things weren't working.  Now I know that was because I was editing a Info.plist file inside an already installed confirmation instead of installing one with that intact. My mistake.

Yes, that's correct. It should have the Info.plist from the _installed_ version (the Configuration that has not been updated yet). And I forgot to mention the public DSA key file, which should be there too (if there is one).

Make sure that the stub .tblk is there. If it isn't, look in the Console log for a clue as to why the configuration wasn't considered "updatable". If you still can't figure it out, send me a .zip of the CONFIG.tblk privately at jkbullard at gmail.

 Here I see nothing...

 DB-UC: Copied updatable configuration 'xxx.yyy.zzz.TEST.tblk' to local user folder

 DB-UC: Delaying start of update check for configuration set xxx.yyy.zzz.TEST

 DB-UC: Starting update check without UI for configuration 'xxx.yyy.zzz.TEST'; URL = https://xxx.yy.zzz/tblk/appcast.rss

 DB-UC: cfgUpdater 0x8a377b0: didFinishLoadingAppcast

That looks good. The "didFinishLoadingAppcast" means that it loaded the appcast.rss file properly from your website. If Sparkle didn't complain, then I think that means that the appcast has the same or lower version number compared to the installed configuration. (When I have an error in the appcast, I usually get a Console log entry from Sparkle that an error occurred, although the messages never say very clearly what is wrong.)

I think you may have been misled by a sentence in the wiki:

"This should be the same as the CFBundleVersion in the Info.plist in the updated Configuration."

Although the numbers must be the same, this is referring to the _updated_ Configuration, which must have a higher version number than the Configuration that is installed on your computer. If the version numbers for the "update" and the installed Configuration are the same, it won't be considered an update.

The way it works is that Sparkle compares the appcast's "sparkle:version" number (in the "enclosure" tag) with the CFBundleVersion in the local user copy of /Library/Application Support/Tunnelblick/Tblks/xxx.yyy.zzz.tblk. If the  "sparkle:version" number is the same or lower in the appcast, Sparkle does nothing. If the  "sparkle:version" number is higher, it shows a window to the user asking if the user wants to update.

So if it isn't putting up such a window, and it isn't showing anything in the Console log, is it possible that the version number in the appcast isn't higher?

In other words, to see an update, you need a lower-version-number Configuration installed on your Mac, and a higher-version-number in the appcast (and in the .zip or .dmg) on your website.

One other tip: you can force an update check at any time from the "Preferences" panel -- it will first do an update check for the application, then it will do an update check for each configuration. And those checks will specifically say if the configuration is up-to-date. So you'll get two windows, one saying that Tunnelblick up-to-date and one saying that the configuration is up-to-date or needs updating.

Note: I may be misremembering, but I think if an error occurs in the "initial" check (the "update check without UI" referred to in the log), Sparkle _ignores_ it and doesn't even put an entry in the Console log. If an error occurs in one of these "requested" checks (which is an update check with UI -- which stands for User Interface), then it _is_ put in the log.

I have added this info to the wiki.

 So maybe something is wrong in the appcast format so that Tunnelblick thinks it is not supposed to update it? It looks good.

 If I don't get this sorted tomorrow (giving up for tonight), I will email you some pieces privately to have a quick look-over.

That would be fine; I'd be glad to help. Sorry this is so hard. Being a pioneer is difficult! 

[n9yty]

A side issue...

When I delete the configuration it leaves the old /Library/Application Support/Tunnelblick/Tblks/xxx.yyy.zzz.TEST directory there, should it be deleting it when a config is deleted?   I re-imported a new config (same name) and when I force an update check it reports the OLD version number and says it is still the latest one.

Even stranger, though, is that I deleted those Tblks copies, in the /Library and my ~/Library, and it STILL reports the old version number, so clearly I am not finding something... :)  Where is this version stored or being pulled from?  I do not see it in the net.tunnelblick.tunnelblick.plist file, no copies of the configuration exist in /Library or ~/Library, no Tblks files... Yet when I re-add the configuration (CFBundleVersion set to 1), it reports the old version string.

[Steve Palm]

Now I am going mad... :)

After reporting to you that the old version was "stuck", I deleted everything again, and quit Tunnelblick, then when I relaunched and added the config it immediately prompted me to update! Yay! But....

7/22/14 10:46:09.137 AM Tunnelblick[4020]: DB-UC: cfgUpdater 0x68d1f0: didFinishLoadingAppcast
7/22/14 10:46:09.138 AM Tunnelblick[4020]: DB-UC: cfgUpdater 0x68d1f0: didFindValidUpdate
7/22/14 10:46:25.237 AM Tunnelblick[4020]: DB-UC: cfgUpdater 0x68d1f0: willInstallUpdate
7/22/14 10:46:32.470 AM Tunnelblick[4020]: Sparkle Error: An error occurred while installing the update. Please try again later.
7/22/14 10:46:32.471 AM Tunnelblick[4020]: Sparkle Error (continued): Couldn't find an appropriate update in the downloaded package.

This is the format of the zip file:

Archive: test_configurations.zip
testing: TEST.tblk/ OK
testing: TEST.tblk/Contents/ OK
testing: TEST.tblk/Contents/Info.plist OK
testing: TEST.tblk/Contents/Resources/ OK
testing: TEST.tblk/Contents/Resources/client.test.down.sh OK
testing: TEST.tblk/Contents/Resources/client.test.up.sh OK
testing: TEST.tblk/Contents/Resources/config.ovpn OK
testing: TEST.tblk/Contents/Resources/dsa_pub.pem OK
No errors detected in compressed data of sga_configurations.zip.

Is it supposed to be built from the TEST.tblk level or from inside of it (i.e. one layer down?)

-Steve

[jkbull...gmail.com]

Hi,

On Tuesday, July 22, 2014 11:44:54 AM UTC-4, n9yty wrote:

A side issue...

When I delete the configuration it leaves the old /Library/Application Support/Tunnelblick/Tblks/xxx.yyy.zzz.TEST directory there, should it be deleting it when a config is deleted?   I re-imported a new config (same name) and when I force an update check it reports the OLD version number and says it is still the latest one.

Deleting a configuration does not delete the updatable configuration which includes that configuration. The reason is that there may be other configurations inside the updatable configuration. (A .tblk, including an updatable one, can have within it any number of configurations.)

I'll have to think about this. Perhaps I can add code that, when you delete a configuration, it also deletes an updatable configuration with the same CFBundleIdentifier.

My original idea with updatable configurations was that they would be transparent for most users and that they would be set up to install and update a set of configurations, but I may have to add a GUI way to delete updatable configurations. I'm also thinking about notifying the user when an updatable configuration is installed (which would help with debugging updatable configurations) maybe with an Info.plist entry that could suppress the notification.

Even stranger, though, is that I deleted those Tblks copies, in the /Library and my ~/Library, and it STILL reports the old version number, so clearly I am not finding something... :)  Where is this version stored or being pulled from?  I do not see it in the net.tunnelblick.tunnelblick.plist file, no copies of the configuration exist in /Library or ~/Library, no Tblks files... Yet when I re-add the configuration (CFBundleVersion set to 1), it reports the old version string.

This is a bug. When you install an updatable .tblk, Tunnelblick sets/modifies the /Library stub .blk, but I may have forgotten to have it set/modify the ~/Library copy (the "local user copy"). That is that copy which is actually used in the update checks.

For now, quit Tunnelblick and relaunch it after installing an updatable .tblk. That should make sure that the local user copy is up-to-date until I can get a bugfix out (assuming I'm right that it doesn't update the local user copy when installing an updatable .tblk).

[jkbull...gmail.com]

Hi.

On Tuesday, July 22, 2014 11:51:30 AM UTC-4, n9yty wrote:

Now I am going mad...  :)

After reporting to you that the old version was "stuck", I deleted everything again, and quit Tunnelblick, then when I relaunched and added the config it immediately prompted me to update!  Yay!  But....

7/22/14 10:46:09.137 AM Tunnelblick[4020]: DB-UC: cfgUpdater 0x68d1f0: didFinishLoadingAppcast
7/22/14 10:46:09.138 AM Tunnelblick[4020]: DB-UC: cfgUpdater 0x68d1f0: didFindValidUpdate
7/22/14 10:46:25.237 AM Tunnelblick[4020]: DB-UC: cfgUpdater 0x68d1f0: willInstallUpdate
7/22/14 10:46:32.470 AM Tunnelblick[4020]: Sparkle Error: An error occurred while installing the update. Please try again later.
7/22/14 10:46:32.471 AM Tunnelblick[4020]: Sparkle Error (continued): Couldn't find an appropriate update in the downloaded package.

That's actually progress! (You see what I mean about Sparkle error messages being generally unhelpful?)

It might have to do with not finding (in the .zip) an Info.plist entry with the correct CFBundleIdentifier and CFBundleVersion, or something like that. The new CFBundleIdentifier (the one in the .zip) must match the one in the appcast and the one in the un-updated configuration (that is, all three must be identical) and I think the CFBundleVersion in the appcast must match the one in the new one.( Of course they won't match the un-updated one; that's the point!)

Or it may have to do with the following.

This is the format of the zip file:

Archive:  test_configurations.zip
   testing: TEST.tblk/                OK
   testing: TEST.tblk/Contents/       OK
   testing: TEST.tblk/Contents/Info.plist   OK
   testing: TEST.tblk/Contents/Resources/   OK
   testing: TEST.tblk/Contents/Resources/client.test.down.sh   OK
   testing: TEST.tblk/Contents/Resources/client.test.up.sh   OK
   testing: TEST.tblk/Contents/Resources/config.ovpn   OK
   testing: TEST.tblk/Contents/Resources/dsa_pub.pem   OK
No errors detected in compressed data of sga_configurations.zip.

Is it supposed to be built from the TEST.tblk level or from inside of it (i.e. one layer down?)

The .zip should expand into your TEST.tblk. So I think you have an extra layer -- if sga_configurations.zip contains a .zip, that's wrong.

Make an "outer" updatable .tblk. That "outer" .tblk can contain any number of

• OpenVPN configuration files (including .key, .crt, .sh, etc. files)

and/or

• "innner" .tblks (in outer.tblk/Contents/Resources).
  

(Note: There may only be the outer .tblk without inner .tblks if the outer .tblk contains OpenVPN configurations)

It looks like your "TEST.tblk" is exactly that, an "outer", updatable .tblk that contains OpenVPN configurations inside it.

So just .zip that, to get a TEST.tblk.zip, and put that on the website. Don't .zip the .zip!

[Steve Palm]

On Jul 22, 2014, at 8:08 AM, jkbull...gmail.com <jkbu...@gmail.com> wrote:

That looks good. The "didFinishLoadingAppcast" means that it loaded the appcast.rss file properly from your website. If Sparkle didn't complain, then I think that means that the appcast has the same or lower version number compared to the installed configuration. (When I have an error in the appcast, I usually get a Console log entry from Sparkle that an error occurred, although the messages never say very clearly what is wrong.)

Hmmm... Maybe my version numbers are too large for Sparkle?  I was trying to be simple and automate the deployment of updated configs, so I wrote a template Info.plist, appcast.rss and other bits and wrote some bash scripts to automate it.  To make it easy, I was using a version number based on date and a three digit (overkill) sequence number, so it would look like 20140721001.  Then, when a new config is "generated", it would see if the date was the same, if so, it increments the sequence to 20140721002.  If not, it starts a new sequence for the new date.  I suppose I could do the same kind of thing but break it out like 201407.21.001 if that helped Sparkle.  Or I need to find a different version scheme entirely, but this seemed simple.

My installed config in the Tblks folder you mentioned has the Info.plist and it shows version "20140721001".

The latest version on the server is version "20140721027", and that is what is in the appcast file, so it should be considered newer.

The way it works is that Sparkle compares the appcast's "sparkle:version" number (in the "enclosure" tag) with the CFBundleVersion in the local user copy of /Library/Application Support/Tunnelblick/Tblks/xxx.yyy.zzz.tblk. If the  "sparkle:version" number is the same or lower in the appcast, Sparkle does nothing. If the  "sparkle:version" number is higher, it shows a window to the user asking if the user wants to update.

 Hmmm...  So I would think this would have worked.

One other tip: you can force an update check at any time from the "Preferences" panel -- it will first do an update check for the application, then it will do an update check for each configuration. And those checks will specifically say if the configuration is up-to-date. So you'll get two windows, one saying that Tunnelblick up-to-date and one saying that the configuration is up-to-date or needs updating.

 I had tried that before I had a properly installed config (Info.plist in the installed version), and I hadn't thought to check it again afterwards.

 It thinks it is up to date, though:

  xxx.yyy.zzz.TEST 20140721001 is currently the newest version available.

 But the appcast clearly has a newer version:  

sparkle:version="20140721027"

That would be fine; I'd be glad to help. Sorry this is so hard. Being a pioneer is difficult! 

 I'm just glad to be able to help nail this down, you put the work into making it available, the least I can do is help test and work out the details.

 -Steve

[Steve Palm]

On Jul 22, 2014, at 11:47 AM, jkbull...gmail.com <jkbu...@gmail.com> wrote:

This is the format of the zip file:

Archive:  test_configurations.zip
   testing: TEST.tblk/                OK
   testing: TEST.tblk/Contents/       OK
   testing: TEST.tblk/Contents/Info.plist   OK
   testing: TEST.tblk/Contents/Resources/   OK
   testing: TEST.tblk/Contents/Resources/client.test.down.sh   OK
   testing: TEST.tblk/Contents/Resources/client.test.up.sh   OK
   testing: TEST.tblk/Contents/Resources/config.ovpn   OK
   testing: TEST.tblk/Contents/Resources/dsa_pub.pem   OK

No errors detected in compressed data of test_configurations.zip.

    My error, I was trying to obfuscate a piece of data and had renamed it as test above but not in the last line. There is only one zip, and it contains the top-level TEST.tblk as seen above.  I fixed it above to be how it should have been. :)

It looks like your "TEST.tblk" is exactly that, an "outer", updatable .tblk that contains OpenVPN configurations inside it.

 That is what I thought, and it is created from the command line zip tool on just the TEST.tblk directory, so it should be OK.  I did change the way I was creating version numbers, just to break them up a bit, but they should all now be consistent anyway....

It might have to do with not finding (in the .zip) an Info.plist entry with the correct CFBundleIdentifier and CFBundleVersion, or something like that. The new CFBundleIdentifier (the one in the .zip) must match the one in the appcast and the one in the un-updated configuration (that is, all three must be identical) and I think the CFBundleVersion in the appcast must match the one in the new one.( Of course they won't match the un-updated one; that's the point!)

The appcast.rss version number:

sparkle:version="201407.22.003"

The TEST.tblk/Contents/Info.plist version number:

<key>CFBundleVersion</key>
<string>201407.22.003</string>

The TEST.tblk also has:

<key>CFBundleIdentifier</key>
<string>xx.yy.zz.TEST</string>

This matches the existing config.

Is there any way to prompt Sparkle to be a bit more verbose about why it doesn't like the update?

I will email you the appcast URL so you can download it and the zip of the configuration update and see if you see anything unusual. I'll also include the "old" installed config.  I'm sure that will be easier for you to look over than going back and forth here over which bits are set which way. :)

 -Steve

[jkbull...gmail.com]

Hi.

On Tuesday, July 22, 2014 1:01:07 PM UTC-4, n9yty wrote:

It might have to do with not finding (in the .zip) an Info.plist entry with the correct CFBundleIdentifier and CFBundleVersion, or something like that. The new CFBundleIdentifier (the one in the .zip) must match the one in the appcast and the one in the un-updated configuration (that is, all three must be identical) and I think the CFBundleVersion in the appcast must match the one in the new one.( Of course they won't match the un-updated one; that's the point!)

The appcast.rss version number:

sparkle:version="201407.22.003"

The TEST.tblk/Contents/Info.plist version number:

<key>CFBundleVersion</key>
<string>201407.22.003</string>

The TEST.tblk also has:

<key>CFBundleIdentifier</key>
<string>xx.yy.zz.TEST</string>

The appcast's "sparkle:version" must match "xx.yy.zz.TEST", too. All three must match.

 

Is there any way to prompt Sparkle to be a bit more verbose about why it doesn't like the update?

Not as far as I know :-(

I will email you the appcast URL so you can download it and the zip of the configuration update and see if you see anything unusual. I'll also include the "old" installed config.  I'm sure that will be easier for you to look over than going back and forth here over which bits are set which way. :)

OK. I will be AFK for a few hours starting now, though.

[Steve Palm]

On Jul 22, 2014, at 12:13 PM, jkbull...gmail.com <jkbu...@gmail.com> wrote:

On Tuesday, July 22, 2014 1:01:07 PM UTC-4, n9yty wrote:

It might have to do with not finding (in the .zip) an Info.plist entry with the correct CFBundleIdentifier and CFBundleVersion, or something like that. The new CFBundleIdentifier (the one in the .zip) must match the one in the appcast and the one in the un-updated configuration (that is, all three must be identical) and I think the CFBundleVersion in the appcast must match the one in the new one.( Of course they won't match the un-updated one; that's the point!)

The appcast.rss version number:

sparkle:version="201407.22.003"

The TEST.tblk/Contents/Info.plist version number:

<key>CFBundleVersion</key>
<string>201407.22.003</string>

The TEST.tblk also has:

<key>CFBundleIdentifier</key>
<string>xx.yy.zz.TEST</string>

The appcast's "sparkle:version" must match "xx.yy.zz.TEST", too. All three must match.

 Oh, wait...  I thought the "sparkle:version" was to match the "CFBundleVersion" which was just a version number.

 I thought CFBundleIdentifier was different, and was the config reverse-dns style name.  So all three have to match?

 I think I will go re-read your online notes about this, I may have gotten some pieces confused. :)

 Thanks for your patience!

  -Steve

[jkbull...gmail.com]

Oops. My mistake.

On Tuesday, July 22, 2014 1:15:28 PM UTC-4, n9yty wrote:

The appcast's "sparkle:version" must match "xx.yy.zz.TEST", too. All three must match.

 Oh, wait...  I thought the "sparkle:version" was to match the "CFBundleVersion" which was just a version number.

 I thought CFBundleIdentifier was different, and was the config reverse-dns style name.  So all three have to match?

You're correct. I was very confused. And I thought the appcast includes the bundle ID, but it doesn't. Sorry.

The only other thing I can think of is that the two decimal points are confusing it. My understanding is that they work, but maybe not. I know that a single decimal point works -- 123.456. How about trying to use "20140722.003"? (99999999 will fit in 28 bits, if that is indeed a problem.)

I will look at the stuff you emailed me later.

[Steve Palm]

On Jul 22, 2014, at 12:25 PM, jkbull...gmail.com <jkbu...@gmail.com> wrote:
> The only other thing I can think of is that the two decimal points are confusing it. My understanding is that they work, but maybe not. I know that a single decimal point works -- 123.456. How about trying to use "20140722.003"? (99999999 will fit in 28 bits, if that is indeed a problem.)

I dropped the century, as this will surely be obsolete before we hit 21... So I was left with 1407.22.003, and that also fails. I have found many references online that would indicate the three position format should work, but maybe because my INITIAL config only had a single digit it causes problems? Well, that turned out to not be the case, i changed my new version number to 2, the old was 1, and it doesn't work. Can't get much simpler than that. LoL

> I will look at the stuff you emailed me later.

No worries, this is not a crisis. It will be nice to have it solved so you can put it behind you and maybe it will help others in the future, but certainly no rush. :)

-Steve

[n9yty]

Still looking at this, but not making much progress.

I don't understand why Sparkle seems to think that there is no updatable bundle...

I verified the CFBundleIdentifier from the Tblks/ directory in both the /Library and ~Library paths.

I even found where Sparkle downloads the updates to in /var/folders/.... and saw that it creates a folder:

"${CFBundleIdentifier} X Update"  (where X updates on each download attempt, old ones seem to not go away... ?)

Inside there, I find the zip/dmg that was downloaded from the URL in the appcast file.

I also see that it has unpacked the zip file (in this case) and it has the proper bundle structure, and the CFBundleIdentifier matches the one in the Tblks/ folders, so I am not sure why Sparkle doesn't think it has an updatable bundle in the downloaded files. {sigh}

[jkbull...gmail.com]

Hi. Sorry I haven't gotten back to you sooner -- every time I fix a bug I find another one. I hope to have a new snapshot that fixes several later today, including a fix for the problem with "TBAlwaysSetPreferences".

After I make the new snapshot I should have time to look into the specific problem you are having.

[jkbull...gmail.com]

A new Tunnelblick snapshot (pre-release version) is available which (among other things) fixes several problems with updatable configurations, including a problem which mis-installed configurations so they did not contain Info.plist (reinstalling the configurations with this new version corrects the problem).

Snapshots may be downloaded from the Tunnelblick Snapshots page. Anyone may email me privately at jkbullard at gmail for a link.

[n9yty]

So, with the official release of 3.4, was this ever finished or was the feature dropped?  I hadn't heard anything in a long time so I was patiently waiting.  Is it going to be revisited in the future if it is not working yet?

Thanks!!

  -Steve

[jkbull...gmail.com]

I'm sorry for not keeping this thread up-to-date or informing you personally, Steve. I do appreciate the help you have given me on this feature.

The changes needed to make this feature really usable are not finished but it has not been dropped -- I still plan to do some major enhancements, hopefully some time in the next few weeks.

I wanted to release a "stable" version of Tunnelblick that has the latest (important) security updates, and the changes to complete this feature were too complex to be tested well enough to include in that release.

I will be in touch with you personally, Steve, when I am ready to test a new version with the enhancements. Thanks again for your patience.

[mjt...@gmail.com]

I wanted to report that I just got this working (with Tunnelblick 3.4.3 (build 4055.4198)) though I think there are some pieces of information that could do with being added to the docs!

Here are the "gotchas" I encountered:

1. This one's quite obvious, but it caught me out -- I tried to manually replicate Sparkle's digest logic using openssl manually -- but you absolutely _have_ to use /usr/bin/openssl.  I was simply using the openssl in my PATH and happened to have a /usr/local/bin/openssl (OpenSSL 1.0.1e 11 Feb 2013) which was overriding the system openssl binary (OpenSSL 0.9.8za 5 Jun 2014).  There are breaking differences between the 0.9.8 and 1.0.x series with openssl dsaparam which render 1.0.x incompatible with Sparkle. Symptoms include base64 fingerprints which are longer than expected and Sparkle complaining about the update being badly signed.  Using the scripts from the Sparkle distribution (which explicitly use /usr/bin/openssl) worked out fine first time.  Equally, ensuring that you're using /usr/bin/openssl works fine too. (As of Yosemite at least.)
2. I discovered that the file structure of the update zip file needs to be quite specific to convince Sparkle to work; specifically, the zip file must have <CFBundleIdentifier>.tblk at at the root. e.g., if your updateable CFBundleIdentifier is com.example.tunnelblick-configs.001 then you should have:

com.example.tunnelblick-configs.001.tblk/Contents/Info.plist

com.example.tunnelblick-configs.001.tblk/Contents/Resources/dsa_pub.pem

com.example.tunnelblick-configs.001.tblk/Contents/Resources/Config1.tblk/Info.plist

com.example.tunnelblick-configs.001.tblk/Contents/Resources/Config1.tblk/client.crt

com.example.tunnelblick-configs.001.tblk/Contents/Resources/Config1.tblk/client.key

com.example.tunnelblick-configs.001.tblk/Contents/Resources/Config1.tblk/ca.crt

com.example.tunnelblick-configs.001.tblk/Contents/Resources/Config1.tblk/client.ovpn

Without this, Sparkle always complained with "Sparkle Error (continued): Couldn't find an appropriate update in the downloaded package."

Hope this helps some others out.

Thanks for this functionality Jonathan, it should make things a lot easier for users.  While I'm at it, thanks to all of the Tunnelblick contributors!

Cheers,

Mark.

[n9yty]

Mark,

Thanks for your notes.

After a LONG break, I needed to get this working now due to the recent changes that will push IPv4 default routing. I need to be able to update configurations remotely now to handle these kinds of things.

Despite revisiting all my old notes, your notes, and the site notes, I still get the dreaded Sparkle error "Couldn't find an appropriate update in the download package".

Everything else looks right:

DB-UC: Started update checks without UI for configuration 'org.sga.tunnelblick.config.SGAMaster' (0); URL = https:/redacted
DB-UC: didFinishLoadingAppcast for 'SGAMaster.tblk' (org.sga.tunnelblick.config.SGAMaster 0)
DB-UC: didFindValidUpdate for 'SGAMaster.tblk' (org.sga.tunnelblick.config.SGAMaster 0)
DB-UC: willInstallUpdate for 'SGAMaster.tblk' (org.sga.tunnelblick.config.SGAMaster 0)

Sparkle Error: An error occurred while installing the update. Please try again later.

Sparkle Error (continued): Couldn't find an appropriate update in the downloaded package.

The folder layout:

org.sga.tunnelblick.config.SGAMaster.tblk/
└── Contents
    ├── Info.plist
    └── Resources
        ├── SGA.tblk
        │   ├── Info.plist
        │   ├── client.sga.down.sh
        │   ├── client.sga.up.sh
        │   └── config.ovpn
        └── dsa_pub.pem

I can manually click on the outer config and/or the inner config and they update locally, just not when Sparkle tries to do it. {sigh}

The CFBundleIdentifier in the outer config matches the name of the folder in the top level of the zip archive.  The CFBundleIdentifier of the inner configuration is different.

I'm kind of stuck {again} at this point, but will keep hammering away at it.

[n9yty]

For the sake of completeness, along with the structure posted above, these are the bundle identifiers to match:

OUTER:
 <key>CFBundleIdentifier</key>
 <string>org.sga.tunnelblick.config.SGAMaster</string>


INNER:
 <key>CFBundleIdentifier</key>
 <string>org.sga.tunnelblick.config.SGA</string>

[jkbull...gmail.com]

These Sparkle problems are a real pain, especially because the Sparkle error messages aren't very helpful.

As I recall from my (many) problems with Sparkle, the "Couldn't find an appropriate update in the downloaded package" message means that there is some problem with the bundle ID or the name of the downloaded file, or possibly the name of the thing that it unzips to. See, for example, https://answers.launchpad.net/sparkle/+question/67595 and https://answers.launchpad.net/sparkle/+question/55190.

So I think (but I haven't worked with this for a long time) that if the file that is being downloaded for the update is a .zip of "org.sga.tunnelblick.config.SGAMaster.tblk", it should be named "org.sga.tunnelblick.config.SGAMaster.tblk.zip" and that is the file that should be referenced in the "url=" part of the "enclosure:" entry in the .rss file.

[n9yty]

On Monday, September 21, 2015 at 1:11:50 PM UTC-5, jkbull...gmail.com wrote:

So I think (but I haven't worked with this for a long time) that if the file that is being downloaded for the update is a .zip of "org.sga.tunnelblick.config.SGAMaster.tblk", it should be named "org.sga.tunnelblick.config.SGAMaster.tblk.zip" and that is the file that should be referenced in the "url=" part of the "enclosure:" entry in the .rss file.

 The name of the zip file made a huge difference.

But now a different set of errors:

DB-UC: Installing updated configurations at '/Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1/org.sga.tunnelblick.config.SGAMaster.tblk'

Created symlink to /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1/org.sga.tunnelblick.config.SGAMaster.tblk/Contents/Resources/SGA.tblk/client.sga.down.sh at /private/var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/Tunnelblick-dBpjoN/SGA.tblk/Contents/Resources/client.sga.down.sh

Created symlink to /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1/org.sga.tunnelblick.config.SGAMaster.tblk/Contents/Resources/SGA.tblk/client.sga.up.sh at /private/var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/Tunnelblick-dBpjoN/SGA.tblk/Contents/Resources/client.sga.up.sh

Created symlink to /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1/org.sga.tunnelblick.config.SGAMaster.tblk/Contents/Resources/SGA.tblk/config.ovpn at /private/var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/Tunnelblick-dBpjoN/SGA.tblk/Contents/Resources/config.ovpn

Created symlink to /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1/org.sga.tunnelblick.config.SGAMaster.tblk/Contents/Resources/SGA.tblk/Info.plist at /private/var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/Tunnelblick-dBpjoN/SGA.tblk/Contents/Info.plist

Error returned from createSymbolicLinkAtPath: /private/var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/Tunnelblick-dBpjoN/SGA.tblk/Contents/Resources/client.sga.down.sh withDestinationPath: /Users/n9yty/Library/Application Support/Tunnelblick/Configurations/SGA.tblk/Contents/Resources/client.sga.down.sh; Error was Error Domain=NSCocoaErrorDomain Code=516 "The file “client.sga.down.sh” couldn’t be saved in the folder “Resources” because a file with the same name already exists." UserInfo={NSFilePath=/private/var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/Tunnelblick-dBpjoN/SGA.tblk/Contents/Resources/client.sga.down.sh, NSUnderlyingError=0x21d4a60 {Error Domain=NSPOSIXErrorDomain Code=17 "File exists"}}

Failed to create symlink to /Users/n9yty/Library/Application Support/Tunnelblick/Configurations/SGA.tblk/Contents/Resources/client.sga.down.sh at /private/var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/Tunnelblick-dBpjoN/SGA.tblk/Contents/Resources/client.sga.down.sh

Also, when I remove a configuration that was set for auto-updating, it doesn't remove the file from /Library/Application Support/Tunnelblick/Tblks/ and so then thinks it must re-install it. At least it did when I was testing earlier today, I will test more when this is working.

As an aside, I see I now have two files in that folder...

$ ls -l /Library/Application\ Support/Tunnelblick/Tblks/
drwxr-xr-x+ 3 root  wheel  102 Sep 21 12:40 org.sga.tunnelblick.config.SGAMaster_0
drwxr-xr-x+ 3 root  wheel  102 Sep 21 13:17 org.sga.tunnelblick.config.SGAMaster_1

If that is related or not I can't tell...

Any thoughts on the "File Exists" problem?

[n9yty]

On Monday, September 21, 2015 at 1:27:02 PM UTC-5, n9yty wrote:

On Monday, September 21, 2015 at 1:11:50 PM UTC-5, jkbull...gmail.com wrote:

So I think (but I haven't worked with this for a long time) that if the file that is being downloaded for the update is a .zip of "org.sga.tunnelblick.config.SGAMaster.tblk", it should be named "org.sga.tunnelblick.config.SGAMaster.tblk.zip" and that is the file that should be referenced in the "url=" part of the "enclosure:" entry in the .rss file.

 The name of the zip file made a huge difference.

 Or not.  SIGH.  At least that wasn't ALL of my problems.

 I deleted my local config and started again and now I get the same errors. So there must be some difference between my initial installed config and the one it is trying to update with.  But if I manually update with the bundle I push up to the server, and THEN have it try to update I get the symlink error again.

[UPDATE: Sorry, "same errors" mean Sparkle errors about not finding a suitable configuration]

Also, I did a diff on the Info.plist files of the inner and outer configurations comparing my original installs and the one pushed to the server to update from and I don't see anything different in terms of bundle identifiers or such.

[n9yty]

This may have changed since my earlier attempts...

I just was re-reading the page on this and see that I have included files in the update that were in the original, but I had also listed them in the TBKeepExistingFilesList array.  I suspect this is the cause of my problems.

But now...  And I hope this is also just a problem of my not reading something properly. I hate that. :)

open on /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1/org.sga.tunnelblick.config.SGAMaster.tblk/Contents/Resources/dsa_pub.pem: Permission denied

Error returned from copyItemAtPath: /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1/org.sga.tunnelblick.config.SGAMaster.tblk/Contents/Resources/dsa_pub.pem toPath: /private/var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/Tunnelblick-qSP9Gs/Updatables/org.sga.tunnelblick.config.SGAMaster.tblk/Contents/Resources/dsa_pub.pem; Error was Error Domain=NSCocoaErrorDomain Code=513 "“dsa_pub.pem” couldn’t be copied because you don’t have permission to access “Resources”." UserInfo={NSSourceFilePathErrorKey=/Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1/org.sga.tunnelblick.config.SGAMaster.tblk/Contents/Resources/dsa_pub.pem, NSUserStringVariant=(
    Copy
), NSFilePath=/Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1/org.sga.tunnelblick.config.SGAMaster.tblk/Contents/Resources/dsa_pub.pem, NSDestinationFilePath=/private/var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/Tunnelblick-qSP9Gs/Updatables/org.sga.tunnelblick.config.SGAMaster.tblk/Contents/Resources/dsa_pub.pem, NSUnderlyingError=0xd308740 {Error Domain=NSPOSIXErrorDomain Code=13 "Permission denied"}}

[jkbull...gmail.com]

When did the "open on" message happen? Was this from Tunnelblick or did you try to use the command line to "open"? If it was from Tunnelblick it would be helpful to have the messages that led up to it.

Doing the updates in a secure way is tricky. The contents of the .tblks are, for the most part, NOT readable except by root (there may be keys that need to be protected, for example.)

BTW, I noticed that the process of moving to the new website messed up https://tunnelblick.net/cUpdatableConfigurations.html. I will fix that as soon as I can so it is a bit more readable.

Some free advice (and worth every penny : ) -- get basic updating of configs working first before trying to use advanced features like "TBKeepExistingFilesList". (Maybe you've done that; I kind of lost track.)

[Steve Palm]

On Sep 21, 2015, at 1:57 PM, jkbull...gmail.com <jkbu...@gmail.com> wrote:

When did the "open on" message happen? Was this from Tunnelblick or did you try to use the command line to "open"? If it was from Tunnelblick it would be helpful to have the messages that led up to it.

 Sorry, this happened when I took out the client up/down scripts from the array of file names that already existed. This is what allowed it to get past the symlink errors, but then the errors I posted happened.  This was an error on my part because the instructions do clearly state that the update bundle should NOT INCLUDE any files that are in this array, so the symlink error makes sense in that regard.

Some free advice (and worth every penny : ) -- get basic updating of configs working first before trying to use advanced features like "TBKeepExistingFilesList". (Maybe you've done that; I kind of lost track.)

 I understand what you are saying, but in this case the new error about the permissions on dsa_pub.pem shouldn't be related, I wouldn't think. But then again, I clearly don't know all of what is related to what.

 Also, the one thing that I need to exclude is the user key, and I really wouldn't want to be putting that out on the server anyway, so testing a version that includes it is not high on my list of things I want to try. I can put a fake one out there to test the update process I suppose...

So I again wiped out my existing configuration, and when I installed a fresh copy, and then check for updates, I get both a message that states that I am update to date (with the right version number), but then also the update dialog appears saying I have an out of date version (with the old version number).  I am trying to track down where it may be getting this from. I looked at the CFBundleVersion of both the inner and outer configurations and neither match the old version, so I don't know where it is coming from. If I delete the configuration and check for updates, I get nothing, so the shadow doesn't last forever. But reinstalling and checking for updates again gives the same behavior, an 'up to date' dialog along with a 'need to update' dialog.

 -Steve

[Steve Palm]

[Updated with a small additional note]

On Sep 21, 2015, at 1:57 PM, jkbull...gmail.com <jkbu...@gmail.com> wrote:

When did the "open on" message happen? Was this from Tunnelblick or did you try to use the command line to "open"? If it was from Tunnelblick it would be helpful to have the messages that led up to it.

 Sorry, this happened when I took out the client up/down scripts from the array of file names that already existed. This is what allowed it to get past the symlink errors, but then the errors I posted happened.  This was an error on my part because the instructions do clearly state that the update bundle should NOT INCLUDE any files that are in this array, so the symlink error makes sense in that regard.

 Also, Tunnelblick gave this in an error dialog when that happened:

Installation failed:

Updatable configuration 'org.sga.tunnelblick.config.SGAMaster' was not stored as updatable because '/Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_0/org.sga.tunnelblick.config.SGAMaster.tblk/Contents/Resources/dsa_pub.pem' could not be copied to '/private/var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/Tunnelblick-ZWXDkw/Updatables/org.sga.tunnelblick.config.SGAMaster.tblk/Contents/Resources/dsa_pub.pem'

 -Steve

[n9yty]

Must be some other leftover files... After I deleted my configuration, quit Tunnelblick, and launched it again I get this:

Installation failed:
Not replacing an existing configuration, so configuration '(null)' cannot use 'TBKeepExistingFilesList'

I hadn't asked it to install anything, must be leftover files from the failed update attempt. Quting again, re-launching, and I get the same message. If I remove the stub from /Library/Application Support/Tunnelblick/Tblks/ it goes away.

[n9yty]

Further, I simplified the configuration structure from what Mark had suggested above, and went to a more simple version I had used before and as you layout on your wiki page...  It still worked in that Sparkle was happy to try the update, although it still didn't work in that it doesn't install and I get the permissions error again.

Structure:

org.sga.tunnelblick.config.SGAMaster.tblk
├── Info.plist

├── SGA.tblk
│   ├── Info.plist
│   ├── client.sga.down.sh
│   ├── client.sga.up.sh
│   └── config.ovpn
└── dsa_pub.pem

And I get this similar error:

Installation failed:

Updatable configuration 'org.sga.tunnelblick.config.SGAMaster' was not stored as updatable because '/Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1/org.sga.tunnelblick.config.SGAMaster.tblk/dsa_pub.pem' could not be copied to '/private/var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/Tunnelblick-WsBOy7/Updatables/org.sga.tunnelblick.config.SGAMaster.tblk/Contents/Resources/dsa_pub.pem'

Unfortunately the folder in /private/var no longer exists after the attempt, so I can't look at permissions there to see what is going on.  The source, though, does exist as should be readable, or are the perms wrong?

-rwx------  1 root  wheel  2222 Jul 24  2014 /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1/org.sga.tunnelblick.config.SGAMaster.tblk/dsa_pub.pem

[n9yty]

Maybe it *is* the file in /Library/Application Support/Tunnelblick/Tblks that is the problem...  I ran opensnoop to look at all access attempts made duing a configuration update installation attempt.

opensnoop shows:

  UID    PID COMM          FD PATH                
  501   6469 Tunnelblick   30 /Applications/Tunnelblick.app/Contents/Frameworks/Sparkle.framework/Resources/SUStatus.nib
  501   6469 Tunnelblick   30 /Applications/Tunnelblick.app/Contents/Resources/tunnelblick.icns
  501   6469 Tunnelblick   30 /Library/Application Support/Tunnelblick/Tblks
  501   6469 Tunnelblick   30 /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_0
  501   6469 Tunnelblick   30 /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1
  501   6469 Tunnelblick   30 /Library/Application Support/Tunnelblick/Tblks
  501   6469 Tunnelblick   30 /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_0
  501   6469 Tunnelblick   30 /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1
  501   6469 Tunnelblick   30 /Users/n9yty/Library/Keychains/login.keychain
  501   6469 Tunnelblick   30 /Library/Keychains/System.keychain
  501   6469 Tunnelblick   37 /System/Library/Frameworks/AppKit.framework/Resources/English.lproj/NSAlertPanel.nib
  501   6469 Tunnelblick   37 /Applications/Tunnelblick.app/Contents/Resources/tunnelblick.icns
  501   6469 Tunnelblick   37 /Applications/Tunnelblick.app/Contents/Frameworks/Sparkle.framework/Resources/SUStatus.nib
  501   6469 Tunnelblick   -1 /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1/org.sga.tunnelblick.config.SGAMaster.tblk//Contents/PkgInfo
  501   6469 Tunnelblick   -1 /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1/org.sga.tunnelblick.config.SGAMaster.tblk//Contents/PkgInfo
  501   6469 Tunnelblick   39 /Applications/Tunnelblick.app/Contents/Frameworks/Sparkle.framework/Resources/en.lproj/SUUpdateAlert.nib
  501   6469 Tunnelblick   -1 /Library/Managed Preferences/n9yty/com.apple.familycontrols.contentfilter.plist
  501   6469 Tunnelblick   -1 /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1/org.sga.tunnelblick.config.SGAMaster.tblk//Contents/PkgInfo
  501   6469 Tunnelblick   -1 /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1/org.sga.tunnelblick.config.SGAMaster.tblk//Contents/PkgInfo
  501   6469 Tunnelblick   -1 /Library/Managed Preferences/n9yty/com.apple.familycontrols.contentfilter.plist
  501   6469 Tunnelblick   39 /Users/n9yty/Library/Preferences/com.apple.security.revocation.plist
  501   6469 Tunnelblick   39 /Users/n9yty/Library/Preferences/com.apple.security.revocation.plist
  501   6469 Tunnelblick   39 /System/Library/Keychains/SystemRootCertificates.keychain
  501   6469 Tunnelblick   39 /Applications/Tunnelblick.app/Contents/Frameworks/Sparkle.framework/Resources/SUStatus.nib
  501   6469 Tunnelblick   -1 /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1/org.sga.tunnelblick.config.SGAMaster.tblk//Contents/PkgInfo
  501   6469 Tunnelblick   -1 /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1/org.sga.tunnelblick.config.SGAMaster.tblk//Contents/PkgInfo
  501   6469 Tunnelblick   42 /var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/org.sga.tunnelblick.config.SGAMaster 1509.21.010 Update/org.sga.tunnelblick.config.SGAMaster.zip
  501   6469 Tunnelblick   -1 /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1/org.sga.tunnelblick.config.SGAMaster.tblk/Contents/Resources/dsa_pub.pem
  501   6469 Tunnelblick   42 /var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/org.sga.tunnelblick.config.SGAMaster 1509.21.010 Update/org.sga.tunnelblick.config.SGAMaster.zip
  501   6469 Tunnelblick   42 /private/var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/relaunch
  501   6469 Tunnelblick   42 /Applications/Tunnelblick.app/Contents/Frameworks/Sparkle.framework/Versions/A/Resources/relaunch
  501   6469 Tunnelblick   43 /private/var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/relaunch
  501   6469 Tunnelblick   -1 /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1/org.sga.tunnelblick.config.SGAMaster.tblk//Contents/PkgInfo
  501   6469 Tunnelblick   42 /private/var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/org.sga.tunnelblick.config.SGAMaster 1509.21.010 Update
  501   6469 Tunnelblick   42 /private/var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/org.sga.tunnelblick.config.SGAMaster 1509.21.010 Update/org.sga.tunnelblick.config.SGAMaster.tblk
  501   6469 Tunnelblick   42 /var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/tmp.PsTLiY
  501   7211 Tunnelblick    0 /dev/null            
  501   6469 Tunnelblick   42 /var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/tmp.eGWUWW
  501   7214 Tunnelblick    0 /dev/null            
  501   6469 Tunnelblick   42 /var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/tmp.Zg7mon
  501   7215 Tunnelblick    0 /dev/null            
  501   6469 Tunnelblick   42 /var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/tmp.2KT64x
  501   7216 Tunnelblick    0 /dev/null            
  501   6469 Tunnelblick   42 /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1/org.sga.tunnelblick.config.SGAMaster.tblk
  501   6469 Tunnelblick   42 /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1/org.sga.tunnelblick.config.SGAMaster.tblk/SGA.tblk
  501   6469 Tunnelblick   42 /var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/tmp.HouvMO
  501   7217 Tunnelblick    0 /dev/null            
  501   6469 Tunnelblick   42 .                    
  501   6469 Tunnelblick   42 /dev/null            
  501   6469 Tunnelblick   46 .                    
  501   6469 Tunnelblick   42 /var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/org.sga.tunnelblick.config.SGAMaster 1509.21.010 Update
  501   6469 Tunnelblick   42 /System/Library/CoreServices/SystemVersion.plist
  501   6469 Tunnelblick   43 /var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/.dat.nosync1945.YhU23n
  501   6469 Tunnelblick   42 /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1/org.sga.tunnelblick.config.SGAMaster.tblk
  501   6469 Tunnelblick   42 /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1/org.sga.tunnelblick.config.SGAMaster.tblk/SGA.tblk
  501   6469 Tunnelblick   42 /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1/org.sga.tunnelblick.config.SGAMaster.tblk
  501   6469 Tunnelblick   42 /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1/org.sga.tunnelblick.config.SGAMaster.tblk/SGA.tblk
  501   6469 Tunnelblick   42 /private/var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/Tunnelblick-rtQk4M
  501   6469 Tunnelblick   42 /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1/org.sga.tunnelblick.config.SGAMaster.tblk/Info.plist
  501   6469 Tunnelblick   42 /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1/org.sga.tunnelblick.config.SGAMaster.tblk/Info.plist
  501   6469 Tunnelblick   42 /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1/org.sga.tunnelblick.config.SGAMaster.tblk
  501   6469 Tunnelblick   42 /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1/org.sga.tunnelblick.config.SGAMaster.tblk/SGA.tblk
  501   6469 Tunnelblick   42 /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1/org.sga.tunnelblick.config.SGAMaster.tblk/SGA.tblk/Info.plist
  501   6469 Tunnelblick   42 /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1/org.sga.tunnelblick.config.SGAMaster.tblk/SGA.tblk
  501   6469 Tunnelblick   42 /Library/Application Support/Tunnelblick/Shared
  501   6469 Tunnelblick   42 /Users/n9yty/Library/Application Support/Tunnelblick/Configurations
  501   6469 Tunnelblick   42 /Users/n9yty/Library/Application Support/Tunnelblick/Configurations/SGA.tblk
  501   6469 Tunnelblick   42 /Users/n9yty/Library/Application Support/Tunnelblick/Configurations/SGA.tblk/Contents/Info.plist
  501   6469 Tunnelblick   42 /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1/org.sga.tunnelblick.config.SGAMaster.tblk/SGA.tblk
  501   6469 Tunnelblick   42 /Users/n9yty/Library/Application Support/Tunnelblick/Configurations/SGA.tblk/Contents/Resources
  501   6469 Tunnelblick   42 /Library/Application Support/Tunnelblick/Shared
  501   6469 Tunnelblick   42 /Users/n9yty/Library/Application Support/Tunnelblick/Configurations
  501   6469 Tunnelblick   42 /private/var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/Tunnelblick-rtQk4M/Updatables/org.sga.tunnelblick.config.SGAMaster.tblk/Contents/.dat.nosync1945.68tRun
  501   6469 Tunnelblick   42 /private/var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/Tunnelblick-rtQk4M/Updatables/org.sga.tunnelblick.config.SGAMaster.tblk/Contents/.dat.nosync1945.e46Q56
  501   6469 Tunnelblick   -1 /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1/org.sga.tunnelblick.config.SGAMaster.tblk/dsa_pub.pem
  501   6469 Tunnelblick   42 /Applications/Tunnelblick.app/Contents/Resources/AlertWindow.nib
  501   6469 Tunnelblick   42 /private/var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/Tunnelblick-rtQk4M
  501   6469 Tunnelblick   42 /private/var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/Tunnelblick-rtQk4M/SGA.tblk
  501   6469 Tunnelblick   42 /private/var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/Tunnelblick-rtQk4M/SGA.tblk/Contents
  501   6469 Tunnelblick   42 /private/var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/Tunnelblick-rtQk4M/SGA.tblk/Contents/Resources
  501   6469 Tunnelblick   42 /private/var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/Tunnelblick-rtQk4M/Updatables
  501   6469 Tunnelblick   42 /private/var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/Tunnelblick-rtQk4M/Updatables/org.sga.tunnelblick.config.SGAMaster.tblk
  501   6469 Tunnelblick   42 /private/var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/Tunnelblick-rtQk4M/Updatables/org.sga.tunnelblick.config.SGAMaster.tblk/Contents
  501   6469 Tunnelblick   42 /private/var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/Tunnelblick-rtQk4M/Updatables/org.sga.tunnelblick.config.SGAMaster.tblk/Contents/Resources

[jkbull...gmail.com]

Few people are using updatable configurations, so it is possible that there is a bug associated with them. My test updatable config doesn't have a dsa_pub.pem file, so as far as I can tell this hasn't been tested. I am away from my test machine and won't be able to get to it until sometime tomorrow.

If you are in a rush and can't wait for me to check this out (and fix it if it is a bug), you should consider imbedding the dsa_pub.pem info into the updatable config's Info.plist and not use the separate file. This is something that Tunnelblick's (old) version of Sparkle allows, using the SUPublicDSAKey tag with a string containing the contents of the dsa_pub.pem file. I don't know if Tunnelblick will allow that tag in an updatable .tblk's Info.plist, and I don't know if it will be implemented in future versions of Sparkle (or even the current version).

[jkbull...gmail.com]

This:

  501   6469 Tunnelblick   -1 /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1/org.sga.tunnelblick.config.SGAMaster.tblk//Contents/PkgInfo 

shows what looks like a bug in Tunnelblick: notice the double //, which should be a single /. I think Tunnelblick screwed up when it constructed the path. I don't know if OS X ignores the double slash, though, because it didn't seem to be complaining about that file.

Also, are "family controls" involved here? I'm a little hazy about them, but try turning them off and see if that helps.

...

[n9yty]

On Monday, September 21, 2015 at 6:21:19 PM UTC-5, jkbull...gmail.com wrote:

Few people are using updatable configurations, so it is possible that there is a bug associated with them. My test updatable config doesn't have a dsa_pub.pem file, so as far as I can tell this hasn't been tested. I am away from my test machine and won't be able to get to it until sometime tomorrow.

 I removed this, as I am using https:, although I would like to eventually put it back. It is recommended per the wiki after all. :)

 I guess I'll have to wait until you are back to debug it more, as it now throws different errors... Everything looks normal, even to the point of telling me it will update the configuration, but then gives an error that it has taken too long or failed... ?

DB-UC: willInstallUpdate for 'org.sga.tunnelblick.config.SGAMaster.tblk' (org.sga.tunnelblick.config.SGAMaster 0)
DB-UC: updaterShouldRelaunchApplication for 'org.sga.tunnelblick.config.SGAMaster.tblk' (org.sga.tunnelblick.config.SGAMaster 0)
DB-UC: Scheduling installation of updated configurations at '/Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_0/org.sga.tunnelblick.config.SGAMaster.tblk'
CoreAnimation: warning, deleted thread with uncommitted CATransaction; set CA_DEBUG_TRANSACTIONS=1 in environment to log backtraces.
DB-UC: Installing updated configurations at '/Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_0/org.sga.tunnelblick.config.SGAMaster.tblk'
Created symlink
  to /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_0/org.sga.tunnelblick.config.SGAMaster.tblk/SGA.tblk/client.sga.down.sh
  at /private/var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/Tunnelblick-VixoO2/SGA.tblk/Contents/Resources/client.sga.down.sh
Created symlink
  to /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_0/org.sga.tunnelblick.config.SGAMaster.tblk/SGA.tblk/client.sga.up.sh
  at /private/var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/Tunnelblick-VixoO2/SGA.tblk/Contents/Resources/client.sga.up.sh
Created symlink
  to /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_0/org.sga.tunnelblick.config.SGAMaster.tblk/SGA.tblk/config.ovpn
  at /private/var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/Tunnelblick-VixoO2/SGA.tblk/Contents/Resources/config.ovpn
Created symlink
  to /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_0/org.sga.tunnelblick.config.SGAMaster.tblk/SGA.tblk/Info.plist
  at /private/var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/Tunnelblick-VixoO2/SGA.tblk/Contents/Info.plist
Created symlink
  to /Users/n9yty/Library/Application Support/Tunnelblick/Configurations/SGA.tblk/Contents/Resources/user.p12
  at /private/var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/Tunnelblick-VixoO2/SGA.tblk/Contents/Resources/user.p12
Beginning installation or repair
executing /Applications/Tunnelblick.app/Contents/Resources/installer
installer reported failure: /Applications/Tunnelblick.app/Contents/Resources/installer: (
    1,
    "/Users/n9yty/Library/Application Support/Tunnelblick/Configurations/SGA.tblk",
    "/private/var/folders/7n/8c4nbqln0nnbqj9944ypb5xr0000gn/T/Tunnelblick-VixoO2/SGA.tblk"
)

So at this point I have no more real ideas, as I can't get much out of that failure code.

Let me know if you find anything when you are back at your machine.

 -Steve

[Steve Palm]

On Sep 21, 2015, at 6:28 PM, jkbull...gmail.com <jkbu...@gmail.com> wrote:

This:

  501   6469 Tunnelblick   -1 /Library/Application Support/Tunnelblick/Tblks/org.sga.tunnelblick.config.SGAMaster_1/org.sga.tunnelblick.config.SGAMaster.tblk//Contents/PkgInfo 

shows what looks like a bug in Tunnelblick: notice the double //, which should be a single /. I think Tunnelblick screwed up when it constructed the path. I don't know if OS X ignores the double slash, though, because it didn't seem to be complaining about that file.

 That file doesn't exist, so a -1 seems normal. I think that normal shell operations ignore a //, but I can't say what it does in all cases. Should there be a PkgInfo file in there?

Also, are "family controls" involved here? I'm a little hazy about them, but try turning them off and see if that helps.

 I don't have them enabled, I suspect it is looking to see if they exist? Anyway, not enabled as far as I can tell...

 I tried removing the SUPublicDSAKeyFile key from the configuration, and removed the corresponding bit from the appcast file, deleted all the configs and started over, but see my other post about the new error.

 -Steve

[jkbull...gmail.com]

I was unable to get my test to fail.

I have updated the updatable configurations documentation to include a working downloadable sample. You can compare it to yours to see what the problem might be.

On Monday, September 21, 2015 at 8:34:22 PM UTC-4, n9yty wrote:

[n9yty]

On Tuesday, September 22, 2015 at 4:29:29 PM UTC-5, Tunnelblick developer wrote:

I was unable to get my test to fail.

I have updated the updatable configurations documentation to include a working downloadable sample. You can compare it to yours to see what the problem might be.

Besdies the problem still not being fixed that prevents this from working in my case (due to the existence of a p12 cerfiticate file that has to be kept when the configuration is updated), it seems that you have, for security reasons, now mandated the use of the DSA signature. However, the wiki page still says it is optional and the sample configuration file does not include one.  Could this be updated?  And, could the problem with the .p12 file be fixed? :)

Thanks,

  Steve

[Tunnelblick developer]

Thanks for reminding me. I will look into these issues and report back to this thread.