Copy also up/down scripts from resources

[GoogleCodeExporter]

The new option to copy all .conf .crt .key files to ~/Library/openvpn is
great. I would also like to have all up and down scripts being copied (e.g.
.up and .down extension). Maybe it would be a good idea to define a
subfolder in resources that will be copied. That would be a great benefit
for me in order to customzie the package. And would get rid of changing the
code for every release (I used to replace the createDefaultConfig method).

Original issue reported on code.google.com by dbert...@gmail.com on 22 Oct 2009 at 3:16

[GoogleCodeExporter]

Glad you like the new feature.

I agree that scripts should be copied and like the idea of a separate subfolder 
of Resources for deployment files. Having 
thought a bit more about security implications of this, I don't want to copy 
arbitrary files without knowing what they are 
because their ownerships and permissions need to be set properly. So I plan to 
make changes as follows:

For all .key and .crt files in Resources/Deploy:
    * Set ownership to root:wheel and permissions to 0600 (only root can read or write them)
    * Copy to ~/Library/openvpn if they don't exist there already.

For all .sh and .conf files in Resources/Deploy:
    * Set ownership to root:wheel and permissions to 0744 (only root can write them, but anyone can read them)
    * Copy to ~/Library/openvpn (but don't copy the standard up/down scripts) if they don't exist there already.

This will only be done if permissions of any of these files (in either 
Resources/Deply or in ~/Library/openvpn) need to be 
changed, or if any of the files that are to be copied to ~/Library/openvpn 
don't exist there.

THIS WILL BE DONE AT A DIFFERENT TIME THAN BEFORE -- each time Tunnelblick is 
launched, before any auto-updates are 
done. (This avoids the situation where an auto-update with no deployment files 
overwrites the app containing deployment 
files before they can be copied. This way, auto-updates do not need to include 
the deployment files.)

There is a (pleasant) side effect: the user isn't asked for the admin 
username/password the first time a .conf file is used to 
make a connection, since it's ownership and permissions have already been set 
up properly.

Note: your up/down scripts must end in ".sh" to be copied.

**********************************************
 Why the files must be owned by root and have the permissions described above:

The .sh and .conf files must be owned and writable only by root because they 
will be interpreted/executed as root, and to 
allow anyone else to modify them would be a security problem.

The .key and.crt files must be readable by root, since OpenVPN runs as root and 
has to read them, so they must be either 
readable by everyone or owned and readable by root. Making them readable by 
everyone would allow impersonations, so 
they must be owned and readable only by root.

Of course, you can "fool" this mechanism and get world-readable .crt and .key 
files by giving them names ending in .sh. But 
the idea is to give deployers a secure mechanism if they want it.

I welcome any comments, corrections, etc.

Original comment by jkbull...@gmail.com on 23 Oct 2009 at 3:24

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

This is an interesting take on deployment. Not sure I agree with it though.

For our corporate deployment, we create a separate pkg file for our 
configuration and script which install into 
(config) ~/Library/openvpn/<name>.conf and (scripts) ~/Library/openvpn/<name>/

We then combine this pkg with another pkg that actually installs Tunnelblick 
into /Applications and distribute 
via dmg.

It just seems as though having Tunnelblick copy scripts and setting root 
permissions just is a whole big can of 
worms that shouldn't be messed with.

Now what would be cool is if Tunnelblick would look in /Library/openvpn also so 
we wouldn't have to install 
our vpn config pkg for every user on a machine.

Original comment by batman...@gmail.com on 23 Oct 2009 at 4:00

[GoogleCodeExporter]

The idea is to be able to make a deployment-ready Tunnelblick with minimal 
effort, just by copying some files, without 
all the pkg-ing.

In effect, it is putting the pkg-ing inside Tunnelblick. Tunnelblick already 
needs to set root permissions and has 
mechanisms to do so, making it relatively easy to do. Combined with using 
/Library/openvpn, it would keep the easy 
"just-drag-Tunnelblick-to-Applications" installation.

Putting things in /Library/openvpn is an interesting idea. It would be a nice 
option to have. Are there any security 
implications to doing that?

Original comment by jkbull...@gmail.com on 23 Oct 2009 at 5:05

[GoogleCodeExporter]

Point taken. I just thought I'd throw out my opinion on customizing deployment.

I guess one concern would be someone with admin privileges invoking an instance 
of a Tunnelblick copy that 
has been setup with a malicious deployment payload and not knowing? Maybe it'd 
be best to provide some 
sort feedback confirmation before actually performing the deployment steps?

As for putting things in /Library/openvpn, i really don't see it being any 
different with any additional security 
concerns. Sure everyone would be able to open the /Library/openvpn directory 
and see files (where as with 
~/Library/openvpn user 1 would not being able to see user 2's configs), but 
that's the point of it. Single 
configuration for everyone to use without having to duplicate configs to every 
user account.

Original comment by batman...@gmail.com on 23 Oct 2009 at 6:19

[GoogleCodeExporter]

Thanks for your ideas.

This will require an admin username/password, of course, just like it does now 
on first run. And no modifications can be made to 
Resources after that first run expect by an admin, so (as now) subsequent runs 
would just be to "repair" the setup.

Of course, a malicious copy can wreak havoc now, too -- as can anything that 
requires admin access to install.

I had been thinking that having to enter the admin username/password was 
enough, but maybe it would be better to prefix that with a 
confirmation dialog saying something like

"The installation of Tunnelblick requires a computer administrators' username 
and password so it can perform security-sensitive tasks. 
Please be sure that this copy of Tunnelblick came from a trusted source."

-- perhaps with a list of what will be done. It would be an extra click in the 
installation process, though.

To implement using /Library/openvpn as well as ~/Library/openvpn seems like a 
good idea, too. The installer would install the contents of 
/Resources/DeployToAll to /Library/openvpn, and the contents of 
/Resources/DeployToUser to ~/Library/openvpn. The rest of 
Tunnelblick would then present configurations from both folders.

That way the deployment creator could decide which to do: for an office VPN you 
could install to the user (so other users of the computer 
would _not_ have access to the VPN), and for a other purposes, you could 
install to all users (so all users _would_ have access to it).

There's a discussion about "openvpn-down-root.so" at
http://groups.google.com/group/tunnelblick-discuss/browse_thread/thread/63b272f1
e6253abe

If implemented in a deployment of Tunnelblick, that file would need to be 
copied just like the scripts. So maybe we copy _everything_ in 
the two folders, and give any .crt or .key files 0600 permissions, .sh files 
0744 permissions, and everything else 0644 permissions?

Original comment by jkbull...@gmail.com on 23 Oct 2009 at 7:30

[GoogleCodeExporter]

RE: openvpn-down-root.so

Why not just keep that in the resources folder of the app? It's actually 
something that comes from/related to the 
openvpn binary itself.

Think the only down-side is if the .app is moved, things break. If copied to 
the Library folder, any openvpn 
upgrades that requires the upgrading of the .so would require searching for all 
.so for replacement.

Original comment by batman...@gmail.com on 23 Oct 2009 at 8:09

[GoogleCodeExporter]

This discussion is very helpful, thanks for participating.

I would like to avoid problems if Tunnelblick moves (or is never put in 
/Applications in the first place), and that's why I wanted to copy it.

My other reason for copying the files was that, after the initial installation, 
upgrades would not need to have any of these files, so there 
could be a single upgrade file for all users, even if they have individual 
certs, keys, etc.

Upgrading the .so would be automatic, anyway, if it was included in a Deploy* 
folder: since the new .so file would be different from the 
one that is in the (~)/Library/openvpn folder, it would replace it. (When I 
said "if any of the files that are to be copied to 
~/Library/openvpn don't exist there", I should have said "if they don't exist 
there or exist but are different".)

This would allow upgrading of certificates, keys, and config files, too. But if 
none of them was being upgraded, none of them would have 
to be in the update.

For completeness, we would need a third folder, Resources/DeployRemove, with a 
bunch of files. Any files in (~)/Library/openvnp with 
names that match any of them would be removed. (The contents of the files would 
be ignored.) The removal would have to be done 
before the copying, so as to not delete something that was just installed, even 
though it would be a mistake to include a file in both 
folders.

Original comment by jkbull...@gmail.com on 23 Oct 2009 at 8:48

[GoogleCodeExporter]

Seems kludgy and nasty in my opinion.

How about including a patch to openvpn to accept a path (or list of paths) to 
search plugins for? This way the 
config file can just include the name of the plugin and openvpn can be passed 
the path to where the app bundle 
is located via openvpnstart.

I'll have to search the openvpn notes/mailing list to see if there is a reason 
why openvpn is currently not doing a 
search in a particular path or accepting search paths in the command-line.

Original comment by batman...@gmail.com on 23 Oct 2009 at 9:01

[GoogleCodeExporter]

How about this:

A Resources/Deploy folder could have the configs, certs, keys, scripts, and .so 
files -- everything. No need to copy 
anything; it is all there, self-contained. If Tunnelblick sees this folder, 
then instead of using ~/Library/openvpn, it uses 
Resources/Deploy (everywhere). In particular, it sends it to OpenVPN as the arg 
to the "--cd" option, so OpenVPN uses 
it for everything.

This means that updates would have to include everything, certs, keys, and all, 
but maybe that's a small price to pay for 
the simplicity and flexibility this approach gives us. For example, whoever 
installs Tunnelblick can put it in 
/Applications, and anyone who uses the computer can access the VPN. Or, for a 
more restricted situation, it can be kept 
somewhere in a user's home directory so it can be accessed only by that user. 
Very simple. And such a separate, one-
user-copy could coexist with another copy in /Applications, and still other 
copies without a Resources/Deploy folder, 
that would work the way things do currently, and even with other copies with a 
Resources/Deploy folder for a different 
set of VPNs.

And it would be easy for a "home" user to do the same thing: put configs, etc., 
in /Resources/Deploy, put the app in 
/Applications, and all users of the computer would have VPN access, saving them 
from having to configure each user.

The only broader impact in the code (aside from having the configs dir be 
something other than ~/Library/openvpn) is 
that the preferences might need to have names which include more than just the 
name of the config to identify them -- 
maybe they'd have to have the path to the config, which would mean they would 
break if the config moves. Arrgghh!

In any case, Tunnelblick should set the permissions on keys and certs, which 
should not be world-readable. Everything 
else should be OK the way it is -- owned by root:wheel with permissions 
(mostly) of 0744.

Original comment by jkbull...@gmail.com on 23 Oct 2009 at 11:24

[GoogleCodeExporter]

How about the following at Tunnelblick startup:

    If the app's permissions need to be changed // Which would always be the case when an update has been 
installed
    OR there is a Deploy folder {
        if there is a Deploy folder {
            if the Deploy folder is empty {
                copy the contents of /Library/Tunnelblick/Backups/ABCDE to the Deploy folder
            }
        }

        If necessary, fix the app's permissions (which will include any .crt, .key, .conf, or .ovpn folders in the 
Deploy folder)

    If there is a Deploy folder and we didn't just copy it from the Backups folder {
            copy the Deploy folder's contents to ~/Library/Tunnelblick/Backups/A/B/C/D/E...
        }
    }

where /A/B/C/D/E... is the full path to the Tunnelblick.app that is 
creating/retreiving the backup. For 
example, if Tunnelblick.app is located in /Applications/Utilities, then the 
contents would be copied to 
~/Library/Tunnelblick/Backup/Applications/Utilities.

Note that the backups are stored in /Library because it won't be a remote 
folder (which ~/Library might be).

This allows an update of a Tunnelblick that uses Deploy can be done with a copy 
of Tunnelblick that has an 
empty Deploy folder, and it will have the Deploy contents restored. It also 
means that there is a backup of the 
Deploy info; it doesn't just reside in the app itself.

This should also solve the problem batmanppc has of needing to use an absolute 
path to access openvpn-
down-root.so. It is always (assuming it is in Resources) one level up in the 
the filesystem hierarchy from 
Deploy, which is the working directory when OpenVPN and scripts are run. So it 
can be accessed relatively, as 
../openvpn-down-root.so.

(It is best if openvpn-down-root.so is stored in Resources, not in Deploy, 
since that allows Tunnelblick to be 
updated with a new version of openvpn-down-root.so, but an empty Deploy folder, 
which will trigger the 
recovery of the backup copy of the keys, certificates, and configurations. 
Also, if at some point Tunnelblick 
starts to include it in official releases, it would probably be stored in 
Resources.)

Original comment by jkbull...@gmail.com on 24 Oct 2009 at 6:15

[GoogleCodeExporter]

Two more changes to the scheme I outlined above, so deployers don't even need 
an empty Deploy folder (i.e., they can 
just use Tunnelblick's automatic updates):

1. Store the backups of the Deploy folder in /Library instead of ~/Library 
(with the rest of the path as described in my 
earlier comment). The backups are owned by root, with (mostly) permissions of 
644, so security shouldn't be a 
problem, and it makes them available to any user, but still works with 
multiple, different copies of Tunnelblick.app.

2. At startup, if there is no Deploy folder, but there is a backup (which would 
be the case for a "Deploy"-ed app that 
was just auto-updated with a version without the Deploy folder), ask the user 
(who will be an admin if this happens, 
because they will have just updated Tunnelblick, which only admins can do) if 
they want to restore Deploy from the 
backup. Remember that each copy of Tunnelblick.app that has had a Deploy folder 
that has been backed up will have 
it's own (distinct from other copies of Tunnelblick) backup of Deploy.

SUMMARY OF DEPLOY BEHAVIOR

At Tunnelblick startup:
1. If no Resources/Deploy folder exists, but a backup of it exists, ask the 
user if they wish to restore from the backup 
(and then do so if the user agrees);
2. Set ownership/permissions as usual, except .key and .crt files in Deploy 
would be set to 600 and .sh files in Deploy 
would be set to 744; and
3. If a Resources/Deploy folder exists, back it up.

And when running Tunnelblick, if a Resources/Deploy folder exists, use it as 
the folder containing configuration files. 
This means that (A) Deploy can contain all other files (.key, .crt, .sh) 
required for a distribution, and (B) any items in 
Resources can be accessed with paths of "../".

(The one minor security issue I see from this scheme is easily dealt with: If 
an admin moves or deletes Tunneblick.app -
- and only admins can do so -- the admin should also delete the Deploy backup 
for that copy of Tunnelblick.app. 
Otherwise a non-admin user could put a "fresh" copy of Tunnelblick in the same 
place in the file hierarchy, run it, 
restore Deploy from the backup, and have access to the VPN.)

----------------
Here's another possible enhancement: If the Deploy folder contains a 
"forced.plist" file, Tunnelblick will treat it as 
containing "read-only" preferences -- Tunnelblick will ignore normal 
preferences with names matching the items in the 
file, and use the values in the file (which is read-only) instead. This should 
give deployers the ability to lock down the 
VPN connection completely.

Original comment by jkbull...@gmail.com on 26 Oct 2009 at 12:57

[GoogleCodeExporter]

This discussion actually brings up another interesting idea...

What are your thoughts on configuration bundles. Something like "VPN.tblk" (or 
maybe ovpn?) which breaks down as:

VPN.tblk/
    VPN.conf
    Info.plist
    VPN/
        *.crt
        *.key
        *.sh

Register this bundle type with Tunnelblick.app so that double-clicking on the 
bundle initiates an install of the configuration.

Here we would need to decide how married we are to the ~/Library/openvpn 
scheme. Normally, OS X apps usually stick things into ~/Library/Application 
Support/<name>. We 
could have the install process be moving the bundle to a directory in this 
Application Support structure and set the proper permissions as previously 
outlined. Tunnelblick.app 
would show an entry for every valid bundle.

Original comment by batman...@gmail.com on 27 Oct 2009 at 5:17

[GoogleCodeExporter]

I actually like that bundle idea. We could even combine both ideas. If there is 
a
bundle file in the .dmg package, ask the user to install it.

Original comment by dbert...@gmail.com on 28 Oct 2009 at 10:59

[GoogleCodeExporter]

I just tried the new deployment feature. I think it's great. Right now, I 
deploy a
version without certificate file (.p12). The users have to add their 
certificate file
to the package manually. Would be cool if there could be an additional folder 
in the
user's directory that can contain non-deployable stuff such as certificates and
private keys.

Original comment by dbert...@gmail.com on 3 Nov 2009 at 8:40

[GoogleCodeExporter]

Sorry for the delay - I lost track of this thread and had some trouble finding 
it (I thought it was in the Discussion Group).

Per dbertolo's original comment in this thread -- you can (now) have your users 
put the certificate files into ~/Library/openvpn, and, as long as the Deploy 
folder contains only *.conf, *.oven, 
*.up.sh, *.down.sh, and forced-preferences.plist files, the configs can refer 
to the certificate files as "cert xxx.crt" and they will be taken from 
~/Library/openvpn.

Per batmanppc's comment (#6), we can (now) have location-independent invocation 
of openvpn-down-root.so as long as the down script is suitably named and the 
preference is set.

-----------

I, too, like the bundle idea, especially the part about securing the scripts -- 
as long as we also keep Tunnelblick's "drag and drop" installation. Maybe on 
first run Tunnelblick could look for the 
mounted disk image (in /Volumes/Tunnelblick*), and, if found and there it has 
bundle, install the bundle. You'd have to instruct users to leave the .dmg 
mounted when they first run Tunnelblick, 
but that seems pretty easy.

Installing the bundle to ~/Library/Application 
Support/Tunnelblick/Configurations (or something similar) makes sense. It would 
be very tricky (because of the way the program is written) having 
Tunnelblick deal with configs in more than one folder, so I think the program 
should NOT use ~/Library/openvpn if ~/Library/Application 
Support/Tunnelblick/Configurations exists. That would 
also avoid any name conflicts between configurations.

The other difficulty will be dealing with remote home folders. We can make 
"shadow" copies of the *.sh files the way we do for configuration files, but it 
will be messy.

I may not fully grasp the standard configuration of bundles, but it would be 
easier for the program to handle

VPN.tblk/
    Info.plist
    Contents/
        VPN1.conf
        VPN1.up.sh
        VPN1.down.sh
        VPN1.nomonitor.up.sh
        VPN1.nomoitor.down.sh

        VPN2.up.sh
        VPN2.down.sh
        VPN2.nomonitor.up.sh
        VPN2.nomoitor.down.sh

        *.crt
        *.key
        *.sh

where the .up.sh and .down.sh are optional. Putting them in 
~/Library/Application Support/Tunnelblick/Configurations and naming them that 
way would make it easy for the configs to refer to 
the .crt, .key, and .sh files, and for the system to automatically use the 
up/down scripts or nomonitor up/down scripts. 

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

I've made several changes to the deployment mechanism in the past couple of 
weeks. I've updated the Deploying Tunnelblick wiki at 
http://code.google.com/p/tunnelblick/wiki/DeployingTunnelblick to reflect these 
changes.

Here are excerpts from the change logs:

r271 on 2009-11-07:
Build 1271: ...(2) Always restore Resources/Deploy from backup if it does not 
exist and a backup of it
does -- user should not be asked about this (happens after an auto-update 
without the Deploy
folder)... (4) Monitor Resources/Deploy for changes to configuration files. (To 
deal
gracefully with admins adding or deleting configuration files while Tunnelblick 
is running). (5)
Added 'disableEditConfiguration' preference to disable the 'Edit configuration' 
button.

r275 on 2009-11-11:
Build 1275: More Deploy changes. (1) If Deploy contains only *.conf, *.oven, 
*.up.sh, *.down.sh, and forced-preferences.plist files, then the 
~/Library/openvpn folder will be used for all other files 
(including other scripts). (2) If 'Set nameserver' is checked, then if 
Deploy/<config-name>.up.sh exists, it will be used instead of 
Resources/client.up.osx.sh, and if Deploy/<config-
name>.down.sh exists, it will be used instead of Resources/client.down.osx.sh. 
(4) If 'Set nameserver' is checked, then if the 
'<config-name>-useDownRootPlugin' preference is true, then 
Resources/openvpn-down-root.so will be used as a plugin for OpenVPN.

r276 on 2009-11-15:
Build 1276: ...(4) New checkbox in the OpenVPN Log window: 'Monitor connection' 
(defaults to checked, and is a per-connection preference). This causes the new 
scripts 
'client.nomonitor.up.osx.sh' and 'client.nomonitor.down.osx.sh' to be executed 
instead of the usual 'client.up.osx.sh' and 'client.down.osx.sh'. The new 
scripts don't load leasewatch, so they work 
as the 3.0b10 scripts do except that they properly save and restore 
configurations and don't use files for temporary storage. This allows more 
users to use the latest version (some users couldn't 
because of repeated restarts caused by leasewatch). If 'Monitor connection' is 
checked and Deploy contains <config-name>.nomonitor.up.sh and/or 
<config-name>.nomonitor.down.sh, they will 
be used. So that .crt, and .key files can be in ~/Library/openvpn.

Original comment by jkbull...@gmail.com on 17 Nov 2009 at 5:48

• Changed state: Started

[GoogleCodeExporter]

>I may not fully grasp the standard configuration of bundles, but it would be 
easier 
for the program to handle
>
>VPN.tblk/
>    Info.plist
>    Contents/
>        VPN1.conf
>        VPN1.up.sh
>        VPN1.down.sh
>        VPN1.nomonitor.up.sh
>        VPN1.nomoitor.down.sh
>
>        VPN2.up.sh
>        VPN2.down.sh
>        VPN2.nomonitor.up.sh
>        VPN2.nomoitor.down.sh
>
>        *.crt
>        *.key
>        *.sh
>

One .tblk per configuration so for the above example you'd actually have:

VPN1.tblk and VPN2.tblk

Original comment by batman...@gmail.com on 17 Nov 2009 at 10:29

[GoogleCodeExporter]

I've been giving it some thought, and think the current (new) deploy mechanism 
is better than packages (I now 
know enough to not refer to them as bundles :)

(1) The main advantage is that it already exists (and thus avoids more 
complexity for the program and for 
people trying to deploy Tunnelblick).

(2) It's not more complicated for the user (possibly less) -- they just 
drag/drop the .app, enter admin 
username/password to install, and they're done. They don't have to do anything 
else (for example, decide what 
to do if a new package they are installing has a VPN that currently exists).

(3) It's not harder for the deployer -- they just put files into 
Tunnelblick.app/Contents/Resources/Deploy 
instead of xxx.pkg and distribute that.

(4) It is more flexible about controlling access to the VPNs -- the location of 
Tunnelblick.app controls who can 
access it -- all users of a computer (put it in /Applications), only a specific 
user (put it somewhere in their 
home folder), or any subset of users (put it somewhere accessible only to that 
subset of users).

(5) Controlling "sets" of VPNs isn't harder. If you are doing it via scripts 
there wouldn't be much difference. If 
you're doing it by hand it might be slightly more difficult to drag sets of 
files rather than folders. (And that 
slight difficulty could easily be alleviated by a very simple script that just 
pulled everything out of folders to 
the top Deploy level.)

The only two things I can think of that the current deploy mechanism doesn't do 
(and packages don't, either) 
are:

(A) Deal with different "versions" of VPN configurations.

(B) Allow easy per-user setup of Tunnelblick if the users have home folders on 
remote volumes. Tunnelblick 
must reside on a non-remote volume so its ownership/permissions can be set 
properly, so it couldn't be run 
from anywhere in the home folder. It would have to be put in some (new) folder 
accessible only by the desired 
user(s).

Thoughts?

Original comment by jkbull...@gmail.com on 18 Nov 2009 at 3:20

[GoogleCodeExporter]

Long day at work. Somewhat brain dead right now.

Only thing I can come up with right now is that the use of packages make the 
program 
work more like other OS X programs. Seems more clean cut and refined.

Original comment by batman...@gmail.com on 18 Nov 2009 at 11:00

[GoogleCodeExporter]

Please don't forget the file type *.p12 that can be put into ~/Library/openvpn. 
And
we do have another special case. We use a *.p12 file for the user's 
certificate. But
we still need to a *.pem file that contains the server certificate chain. So, I 
would
like to deploy a *.pem file in the Deploy folder (used by OpenVPN option 
"cacert")
and let the users put their *.p12 file in ~/Library/openvpn (used by OpenVPN 
option
"pkcs12"). Would be great if you could manage to handle this case.

Original comment by dbert...@gmail.com on 1 Dec 2009 at 3:38

[GoogleCodeExporter]

Part 1: .pem and .p12 files: After some more research, it looks to me as though 
files with all of the following 
extensions should be treated the same:
     .cer
     .crt
     .der
     .key
     .p12
     .p7b
     .p7c
     .pem
     .pfx

That is, they should be owned by root, with permissions of 600. (They need to 
be owned by root to be read by 
OpenVPN, which runs as root, and we don't want them read by anyone else.)

Currently, all but .crt and .key would be given the default permissions of 644.

Does that make sense? Any other candidates for similar permissions?

========
 .pem in Deploy and .p12 in ~/Library/openvpn -- I don't see a way to do that. OpenVPN will basically look in 
only one place (the folder specified by its --cd option) for files (except the 
configuration file, whose full path 
is specified at runtime by Tunnelblick). So the folder can either be Deploy or 
it can be ~/Library/openvpn, but 
not both. And .key, .pem, etc. files specified in the config file can only have 
full, absolute paths or just 
filenames and be in the --cd folder. If you have a .pem in Deploy, then Deploy 
will be the --cd folder, and 
you will not have a way to specify ~/Library/openvpn/xxx.p12 in the config file 
(because OpenVPN won't 
expand the "~").
So I think you have to put both files in ~/Library/openvpn. When Tunnelblick 
doesn't see the files in Deploy, it 
will use ~/Library/openvpn as the folder for the --cd option, and you can refer 
to those files in the config file 
with just the filenames (no path), since ~/Library/openvpn is the --cd folder.

Original comment by jkbull...@gmail.com on 2 Dec 2009 at 3:37

[GoogleCodeExporter]

In my opinion, this complexity can just be avoided by standardizing on the use 
of the 
.tblk bundle.

You would just copy the bundle to the appropriate place (you may still have to 
deal 
with permissions or reply on the person building the bundle to properly build 
it). The 
packager would make sure the bundle contains all the needed files/script/certs. 
At 
time of connect the --cd argument would be to the Contents (or now that I look 
at 
how other bundles are done - Resources) directory under the .tblk bundle.

I understand you want to be backwards compatible but you need to draw the line 
somewhere otherwise you really muddy the waters trying to handle too many cases 
and dealing with legacy logic. Bump up the major version number if needed.

Original comment by batman...@gmail.com on 2 Dec 2009 at 4:17

[GoogleCodeExporter]

It's late, so this is somewhat randomly ordered:

Why have the bundle copied anywhere? Why not just use it in place?

I don't think bundles solve either of the issues dbertolo brought up. They 
don't let him do what he wants with the 
.pem and .p12 files, and they don't simplify the permissions issue.

Not sure how to force preferences with bundles -- since bundles are 
per-configuration and many preferences 
affect all configurations.

That said, I like bundles because they separate the program from the 
configurations, although to me the 
"drag/drop Tunnelblick in Applications" is a simpler approach. That's not to 
say that the two are incompatible. I 
don't see anything in bundles that would not be backward compatible.

The idea with Deploy is to provide each user with a complete setup, including 
certs, keys, etc., all in one place 
(the Tunnelblick app itself) so the user only needs to do one thing: drag/drop 
the app into Applications. It's like 
putting the app and bundles together in one place.

Original comment by jkbull...@gmail.com on 2 Dec 2009 at 4:50

[GoogleCodeExporter]

Should we be thinking of a bundle like a document? Or like a .pkg to be 
installed? I've been thinking of it as a 
.pkg to be installed, hence the following comments (I'll post separately about 
it being a document, this is way 
too long already):

After I wrote the very long post below, I thought of an alternative:

Someone more familiar with PackageMaker than I am could develop a standard OS X 
.pkg (including scripts to 
do the permission setting and copying). A variation on the .pkg could also 
install Tunnelblick and set its 
permissions. Deployers would just customize the standard .pkg using 
PackageMaker, putting in their own 
files.

This would be a more standard Mac-like way of doing things (and easier for to 
implement in Tunnelblick, but 
harder for deployers).

One problem: how would it "find" the appropriate copy of Tunnelblick.app (if 
more than one copy exists) to 
manipulate files in "Deploy"?. I'm not sure that the .pkg structure can deal 
with that idea.

===============
LONG POST:
===============

How about having Tunnelblick use the bundle as "instructions" for installing? 
So a structure like

VPN.tblk/
    Info.plist
    Contents/
        Home/
           file1.extension
           file2.extension
           file3.extension
           .
           .
           .
        Deploy/
           file4.extension
           file5.extension
           file6.extension
           .
           .
           .
        Remove-Home/
           file7.extension
           file8.extension
           file9.extension
           .
           .
           .
        Remove-Deploy/
           file10.extension
           file11.extension
           file12.extension
           .
           .
           .

would tell Tunnelblick to:
    1. Remove file7.extension ... file9.extension from ~/Library/openvpn;
    2. Remove file10. extension ... file 12.extension from Contents/Resources/Deploy;
    3. Copy file1.extension ... file3.extension to ~/Library/Openvpn and set those files' permissions; and
    4. Copy file4.extension ... file6.extension to Resources/Deploy and set those files' permissions.

This mechanism, using "Home" and "Deploy", would tell Tunnelblick the intended 
destination for the file. It 
can install, uninstall, or update arbitrary files, including 
forced-preferences.plist, without disturbing other 
files.

This mechanism allows installing multiple configurations all once. The 
vagueness of "Home" would let us 
easily (and in a backwards-compatible way) start using ~/Library/Application 
Support/Tunnelblick instead of 
~/Library/openvpn if at some point in the future Tunnelblick can handle that 
(which is being discussed on 
Discussion Group thread at http://groups.google.com/group/tunnelblick-
discuss/browse_thread/thread/b3d13b7c5e3c1256).

This would give us the flexibility (within the structure of Tunnelblick's use 
of files) of an installer package 
without requiring the use of PackageMaker.app.

And it would not be too difficult to implement because we already do most of it.

Only problem I see is name conflicts. For example, two packages from different 
sources could each install 
over each other. (I have vague, troubling Windows memories of having Netscape 
and Internet Explorer each 
making itself the default browser upon launch not too long ago -- it might be 
like that!)

Info.plist could include options for the operations:
    * Set permissions on all of the files in "Home" (currently ~/Library/openvpn), not just the files being copied. 
This would let us secure existing installations easily.
    * Tell Tunnelblick how to deal with name conflicts. (Not sure how this would work or what the options 
would be.)

Another possibility: Maybe if Tunnelblick detects itself as being on a disk 
image it could install itself into 
/Applications. So you would make a .dmg with Tunnelblick.app and a bundle, and 
tell the user to just drag 
the bundle and drop it on Tunnelblick. Tunnelblick would see it was on a disk 
image, copy itself to 
/Applications, copy the bundle contents and set ownerships and permissions of 
everything appropriately, 
launch the new copy of Tunnelblick it just created in Applications, and close 
itself. Maybe with an option to 
put Tunnelblick into the Dock?

Original comment by jkbull...@gmail.com on 2 Dec 2009 at 1:05

[GoogleCodeExporter]

I'm off to work now but I just wanted to say that I was always referring to the 
tblk 
bundle as a document. Tunnelblick would not ever modify anything inside of it.

Original comment by batman...@gmail.com on 2 Dec 2009 at 2:06

[GoogleCodeExporter]

I've been thinking of the bundle as a .pkg, so I guess we've been talking past 
each other a little.

There is a security issue with the bundle as a document, and I don't see a way 
around it -- maybe you do.

Tunnelblick uses a setuid binary, openvpnstart, to start OpenVPN. The binary 
runs as root when it starts OpenVPN 
so OpenVPN can run as root and set routes, etc. openvpnstart's arguments are 
structured so as to pull config and 
other files only from two specific places: either Deploy or ~/Library/openvpn. 
If we allow the bundle (and thus the 
config and other files) to be in an arbitrary location, we'd have to give 
openvpnstart a path to those files. You 
could (from Terminal) run openvpnstart with a path to which you are not 
supposed to have access (another user's 
~/Library/openvpn, for example). Since openvpnstart runs as root, it would be 
able to use the file, so you could 
impersonate the other user.

Original comment by jkbull...@gmail.com on 2 Dec 2009 at 2:46

[GoogleCodeExporter]

r299 sets owner to root:wheel and permissions to 600 for .cer, .crt, .der,
.key, .p12, .p7b, .p7c, .pem, and .pfx files in the Deploy folder, as described 
in my first 12/01/09 comment 
above.

Original comment by jkbull...@gmail.com on 10 Dec 2009 at 5:53

[GoogleCodeExporter]

Original comment by jkbull...@gmail.com on 24 Dec 2009 at 7:02

• Changed state: Fixed