Tunnelblick "documents"
jkbull...gmail.com
code.google.com/p/tunnelblick/issues/detail?id=122). I'd like to
discuss how they might work. Here's my proposal; what do you think?
* A Tunnelblick "document" would be an OS X bundle with an extension
of .tblk. The bundle would contain a mix of configuration files, keys,
certificates, and shell scripts -- the stuff that is usually in a
"Deploy" folder or in ~/Library/Application Support/Tunnelblick/
Configurations.
("Deploy" is described in http://code.google.com/p/tunnelblick/wiki/DeployingTunnelblick.)
* When a user double-clicks a Tunnelblick document, Tunnelblick is
launched (if it isn't already running), and Tunnelblick adds the
documents' configurations to the list of available configurations, as
if the contents were in Deploy or in ~/Library/Application Support/
Tunnelblick/Configurations. Tunnelblick automatically tries to connect
any configurations that have the "autoConnect" preference set.
* When Tunnelblick opens the document, it verifies and (if necessary)
sets the ownership/permissions of its contents in the same way that
the contents of Deploy are -- owned by root:wheel with various
permissions depending on what each item is. If necessary, the user is
asked for an admin username/password so that the ownership/permissions
can be set. This would usually only happen the first time the document
is opened by Tunnelblick. Since the ownership/permissions of the
document itself are not modified (only its contents), the user can
still delete, rename, etc. the document. (I think the user would need
admin permission to move the document, however.)
* Other than that, the document is used "as is", i.e., it isn't copied
anywhere or otherwise modified.
* In a deployed version of Tunnelblick, documents would only be opened
if there was a forced preference that specifically allows it.
* A document can contain a "preferences.plist". Preferences in it
would be copied to the user's normal preferences when the document is
opened (only copying preferences that don't exist yet), so they are
initialized but the user can modify them and they will be persistent.
* The CONFIGNAMEautoConnect preference would cause the configuration
to be connected when the document is opened.
The MAIN QUESTION (assuming the above, of course), is what to do about
name collisions.
If a document has a configuration with the same name as a
configuration in Deploy or in ~/Library...Configurations or in another
document that has already been opened, what do we do? (We're also
facing this issue if/when we allow aggregation of ~/Library.../
Configuration configs with Deploy configs.)
Keys in the Keychain that store passwords, for example, contain the
name of the configuration. And so do keys for preferences that are
specific to a configuration. We could include the full path to the
document as part of the key, but then if someone moves the document
they'd lose their saved passwords and preferences. And implementing it
would break existing stored passwords and preferences. (Or we'd have
to migrate them, and then there would be a problem if someone
downgraded Tunnelblick to an earlier version.)
Note that the "name" of a configuration can be more than the bare
filename-without-extension. If you have configs in subfolders of ~/
Library.../Configuration, the subfolder will be included in their
names. For example, if you have ~/Library.../Configuration/ABC/
config.ovpn and ~/Library.../Configuration/XYZ/config.ovpn, the two
configurations that Tunnelblick uses will have distinct names: ABC/
config and XYZ/config. In this case, there would not be a name
conflict, even though both files are named "config.ovpn".
My inclination is to simply refuse to open a document that would cause
such a name conflict. That's easy, and I don't think it causes an
undue hardship. But this needs more discussion.
What do YOU think?
Diego Rivera
This would facilitate deployment, behavior would be consistent with the rest of the user experience, etc. Perhaps even a dialog prior to opening the connection asking the user if they wish to add it permanently.
What do you think?
Director / System Operations
Roundbox Global : enterprise : technology : genius
------------------------------------------------------------------------------------------------------------------
Avenida 11 y Calle 7-9, Barrio Amón, San José, Costa Rica
tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506) 2258-3695
email: diego....@rbxglobal.com | www.rbxglobal.com
------------------------------------------------------------------------------------------------------------------
jkbull...gmail.com
launch Tunnelblick (without double-clicking the document)? That's what
I had in mind -- sorry I wasn't more clear.
Or do you mean it shouldn't go on the list you see when you click on
the Tunnelblick icon? That would cause a problem -- there'd be no way
to disconnect it or examine the log. (I guess you could close
Tunnelblick to disconnect it.)
Another clarification: Rather than refuse to open the document that
would cause a name conflict, don't add the configuration(s) that would
cause a conflict, but add all configurations that would NOT cause a
conflict. And warn the user about the configurations that were not
added.
A correction: Apparently you would be able to MOVE a document without
an admin username/password. You wouldn't be able to COPY it without
them, though. That may be another reason to refuse to allow
configurations that cause name conflicts.
I'm inclined to not give the user the ability to make the document
"permanent". The idea is to make it like a document -- double-click it
to open it. If you want it to be "permanent" you could copy it or move
it to ~/Library...Configurations. I suppose we notice a non-permanent
document when Tunnelblick is quit (like a "dirty" document in an
editor) and ask the user if they want to save it. But that means we'd
be asking every time the user logs out or the computer is shut down.
And if the user did want to make it permanent, we'd either have to (A)
move it to ~/Library...Configurations, (B) copy it to ~/
Library...Configurations, or (C) remember it. If (A), it would have to
be on the same volume as ~/Library...Configurations, and it disappears
from where the user had it, which might be an unpleasant surprise to
the user. If (B), it would require an admin username/password, and if
(C), it would get lost if the user moved the document.
On Mar 7, 3:17 pm, Diego Rivera <diego.riv...@rbxglobal.com> wrote:
> This sounds like a good plan. One suggestion would be regarding the adding of the document to the available (i.e. static) VPN list. I would suggest making it such that tunnelblick opens the "document" (connection), "executes it", etc, without making it permanent in such a way that making it permanent would require explicit action on the part of the user.
> This would facilitate deployment, behavior would be consistent with the rest of the user experience, etc. Perhaps even a dialog prior to opening the connection asking the user if they wish to add it permanently.
> What do you think?
> On 3/7/10 2:13 PM, jkbull...gmail.com wrote:Tunnelblick "packages" came up a while ago in an Issue (http://code.google.com/p/tunnelblick/issues/detail?id=122). I'd like to discuss how they might work. Here's my proposal; what do you think? * A Tunnelblick "document" would be an OS X bundle with an extension of .tblk. The bundle would contain a mix of configuration files, keys, certificates, and shell scripts -- the stuff that is usually in a "Deploy" folder or in ~/Library/Application Support/Tunnelblick/ Configurations. ("Deploy" is described inhttp://code.google.com/p/tunnelblick/wiki/DeployingTunnelblick.) * When a user double-clicks a Tunnelblick document, Tunnelblick is launched (if it isn't already running), and Tunnelblick adds the documents' configurations to the list of available configurations, as if the contents were in Deploy or in ~/Library/Application Support/ Tunnelblick/Configurations. Tunnelblick automatically tries to connect any configurations that have the "autoConnect" preference set. * When Tunnelblick opens the document, it verifies and (if necessary) sets the ownership/permissions of its contents in the same way that the contents of Deploy are -- owned by root:wheel with various permissions depending on what each item is. If necessary, the user is asked for an admin username/password so that the ownership/permissions can be set. This would usually only happen the first time the document is opened by Tunnelblick. Since the ownership/permissions of the document itself are not modified (only its contents), the user can still delete, rename, etc. the document. (I think the user would need admin permission to move the document, however.) * Other than that, the document is used "as is", i.e., it isn't copied anywhere or otherwise modified. * In a deployed version of Tunnelblick, documents would only be opened if there was a forced preference that specifically allows it. * A document can contain a "preferences.plist". Preferences in it would be copied to the user's normal preferences when the document is opened (only copying preferences that don't exist yet), so they are initialized but the user can modify them and they will be persistent. * The CONFIGNAMEautoConnect preference would cause the configuration to be connected when the document is opened. The MAIN QUESTION (assuming the above, of course), is what to do about name collisions. If a document has a configuration with the same name as a configuration in Deploy or in ~/Library...Configurations or in another document that has already been opened, what do we do? (We're also facing this issue if/when we allow aggregation of ~/Library.../ Configuration configs with Deploy configs.) Keys in the Keychain that store passwords, for example, contain the name of the configuration. And so do keys for preferences that are specific to a configuration. We could include the full path to the document as part of the key, but then if someone moves the document they'd lose their saved passwords and preferences. And implementing it would break existing stored passwords and preferences. (Or we'd have to migrate them, and then there would be a problem if someone downgraded Tunnelblick to an earlier version.) Note that the "name" of a configuration can be more than the bare filename-without-extension. If you have configs in subfolders of ~/ Library.../Configuration, the subfolder will be included in their names. For example, if you have ~/Library.../Configuration/ABC/ config.ovpn and ~/Library.../Configuration/XYZ/config.ovpn, the two configurations that Tunnelblick uses will have distinct names: ABC/ config and XYZ/config. In this case, there would not be a name conflict, even though both files are named "config.ovpn". My inclination is to simply refuse to open a document that would cause such a name conflict. That's easy, and I don't think it causes an undue hardship. But this needs more discussion. What do YOU think?--Diego Rivera
> Director / System Operations
> Roundbox Global :enterprise : technology : genius
> ------------------------------------------------------------------------------------------------------------------
> Avenida 11 y Calle 7-9, Barrio Amón, San José, Costa Rica
> tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506) 2258-3695
> email:diego....@rbxglobal.com|www.rbxglobal.com
> ------------------------------------------------------------------------------------------------------------------
>
>
>
> signature.asc
> < 1KViewDownload
Diego Rivera
I just think that it'd be better to make the user opt-in to making connections permanent. Also, I believe name conflicts should be an error outright and not be allowed - which "Connection X" am I connected to? The one from the document I just got? Or the one I had saved previously? If an admin needs to update a connection, perhaps the Deploy directory is a cleaner way of going about it - or perhaps we need a different mechanism to handle that case?
As for "not going into the list" not allowing disconnect - they can go in the list, just don't let them stay there automatically would be my suggestion.
Cheers.
jkbull...gmail.com
"*permanent* addition of administator-level configurations". The only
permanent thing that I'm proposing is that the ownership/permissions
of the document contents would be set. Do you mean you don't think
that the configurations should have ownership/permissions set? They
*have* to be set for config files because of security concerns (see
http://code.google.com/p/tunnelblick/wiki/FAQ#Why_does_Tunnelblick_change_the_ownership_of_the_configuration_f).
I think it advisable for the other files, too, as long as we're doing
the config files.
What do you mean by "making connections permanent"? The user would
have to double-click the package each time they want to use it. It
wouldn't show up anywhere unless they did that.
Or are you saying the user should have to enter an admin username/
password each time they use a document?
> On 3/7/10 2:56 PM, jkbull...gmail.com wrote:Thanks, Diego. Are you saying it shouldn't show up the next time you launch Tunnelblick (without double-clicking the document)? That's what I had in mind -- sorry I wasn't more clear. Or do you mean it shouldn't go on the list you see when you click on the Tunnelblick icon? That would cause a problem -- there'd be no way to disconnect it or examine the log. (I guess you could close Tunnelblick to disconnect it.) Another clarification: Rather than refuse to open the document that would cause a name conflict, don't add the configuration(s) that would cause a conflict, but add all configurations that would NOT cause a conflict. And warn the user about the configurations that were not added. A correction: Apparently you would be able to MOVE a document without an admin username/password. You wouldn't be able to COPY it without them, though. That may be another reason to refuse to allow configurations that cause name conflicts. I'm inclined to not give the user the ability to make the document "permanent". The idea is to make it like a document -- double-click it to open it. If you want it to be "permanent" you could copy it or move it to ~/Library...Configurations. I suppose we notice a non-permanent document when Tunnelblick is quit (like a "dirty" document in an editor) and ask the user if they want to save it. But that means we'd be asking every time the user logs out or the computer is shut down. And if the user did want to make it permanent, we'd either have to (A) move it to ~/Library...Configurations, (B) copy it to ~/ Library...Configurations, or (C) remember it. If (A), it would have to be on the same volume as ~/Library...Configurations, and it disappears from where the user had it, which might be an unpleasant surprise to the user. If (B), it would require an admin username/password, and if (C), it would get lost if the user moved the document. On Mar 7, 3:17 pm, Diego Rivera<diego.riv...@rbxglobal.com>wrote:This sounds like a good plan. One suggestion would be regarding the adding of the document to the available (i.e. static) VPN list. I would suggest making it such that tunnelblick opens the "document" (connection), "executes it", etc, without making it permanent in such a way that making it permanent would require explicit action on the part of the user. This would facilitate deployment, behavior would be consistent with the rest of the user experience, etc. Perhaps even a dialog prior to opening the connection asking the user if they wish to add it permanently. What do you think? On 3/7/10 2:13 PM, jkbull...gmail.com wrote:Tunnelblick "packages" came up a while ago in an Issue (http://code.google.com/p/tunnelblick/issues/detail?id=122). I'd like to discuss how they might work. Here's my proposal; what do you think? * A Tunnelblick "document" would be an OS X bundle with an extension of .tblk. The bundle would contain a mix of configuration files, keys, certificates, and shell scripts -- the stuff that is usually in a "Deploy" folder or in ~/Library/Application Support/Tunnelblick/ Configurations. ("Deploy" is described inhttp://code.google.com/p/tunnelblick/wiki/DeployingTunnelblick.) * When a user double-clicks a Tunnelblick document, Tunnelblick is launched (if it isn't already running), and Tunnelblick adds the documents' configurations to the list of available configurations, as if the contents were in Deploy or in ~/Library/Application Support/ T unnelblick/Configurations. Tunnelblick automatically tries to connect any configurations that have the "autoConnect" preference set. * When Tunnelblick opens the document, it verifies and (if necessary) sets the ownership/permissions of its contents in the same way that the contents of Deploy are -- owned by root:wheel with various permissions depending on what each item is. If necessary, the user is asked for an admin username/password so that the ownership/permissions can be set. This would usually only happen the first time the document is opened by Tunnelblick. Since the ownership/permissions of the document itself are not modified (only its contents), the user can still delete, rename, etc. the document. (I think the user would need admin permission to move the document, however.) * Other than that, the document is used "as is", i.e., it isn't copied anywhere or otherwise modified. * In a deployed version of Tunnelblick, documents would only be opened if there was a forc ed preference that specifically allows it. * A document can contain a "preferences.plist". Preferences in it would be copied to the user's normal preferences when the document is opened (only copying preferences that don't exist yet), so they are initialized but the user can modify them and they will be persistent. * The CONFIGNAMEautoConnect preference would cause the configuration to be connected when the document is opened. The MAIN QUESTION (assuming the above, of course), is what to do about name collisions. If a document has a configuration with the same name as a configuration in Deploy or in ~/Library...Configurations or in another document that has already been opened, what do we do? (We're also facing this issue if/when we allow aggregation of ~/Library.../ Configuration configs with Deploy configs.) Keys in the Keychain that store passwords, for example, contain the name of the configuration. And so do keys for preferences that are specific to a configuration. We c ould include the full path to the document as part of the key, but then if someone moves the document they'd lose their saved passwords and preferences. And implementing it would break existing stored passwords and preferences. (Or we'd have to migrate them, and then there would be a problem if someone downgraded Tunnelblick to an earlier version.) Note that the "name" of a configuration can be more than the bare filename-without-extension. If you have configs in subfolders of ~/ Library.../Configuration, the subfolder will be included in their names. For example, if you have ~/Library.../Configuration/ABC/ config.ovpn and ~/Library.../Configuration/XYZ/config.ovpn, the two configurations that Tunnelblick uses will have distinct names: ABC/ config and XYZ/config. In this case, there would not be a name conflict, even though both files are named "config.ovpn". My inclination is to simply refuse to open a document that would cause such a name conflict. That's easy, and I don't think it causes an undue hardship. But this needs more discussion. What do YOU think?--Diego Rivera Director / System Operations Roundbox Global :enterprise : technology : genius ------------------------------------------------------------------------------------------------------------------ Avenida 11 y Calle 7-9, Barrio Amón, San José, Costa Rica tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506) 2258-3695email:diego....@rbxglobal.com|www.rbxglobal.com------------------------------------------------------------------------------------------------------------------ signature.asc < 1KViewDownload--Diego Rivera
Diego Rivera
On 3/7/10 3:50 PM, jkbull...gmail.com wrote:
I'm sorry to be so dense, but I don't understand what you mean by "*permanent* addition of administator-level configurations". The only permanent thing that I'm proposing is that the ownership/permissions of the document contents would be set. Do you mean you don't think that the configurations should have ownership/permissions set? They *have* to be set for config files because of security concerns (see http://code.google.com/p/tunnelblick/wiki/FAQ#Why_does_Tunnelblick_change_the_ownership_of_the_configuration_f). I think it advisable for the other files, too, as long as we're doing the config files. What do you mean by "making connections permanent"? The user would have to double-click the package each time they want to use it. It wouldn't show up anywhere unless they did that.
Or are you saying the user should have to enter an admin username/ password each time they use a document?
jkbull...gmail.com
it didn't occur to me to clarify. There isn't really a "pool of
available connections" that Tunnelblick keeps track of -- Tunnelblick
just uses what is (A) in Deploy, or (B) in ~/Library...Configurations,
whichever is active.
And please don't "shut up"! It is *really* helpful to bounce ideas
around, and that helps clarify my thinking.
Regular users wouldn't be able to use a random Tunnelblick document
they come across, just as they can't use a random configuration file
they come across: an admin username/password is needed (once) to
change the ownership/permissions.
Anyone else want to chime in? Please do!
On Mar 7, 6:48 pm, Diego Rivera <diego.riv...@rbxglobal.com> wrote:
> See below
> On 3/7/10 3:50 PM, jkbull...gmail.com wrote:I'm sorry to be so dense, but I don't understand what you mean by "*permanent* addition of administator-level configurations". The only permanent thing that I'm proposing is that the ownership/permissions of the document contents would be set. Do you mean you don't think that the configurations should have ownership/permissions set? They *have* to be set for config files because of security concerns (seehttp://code.google.com/p/tunnelblick/wiki/FAQ#Why_does_Tunnelblick_change_the_ownership_of_the_configuration_f). I think it advisable for the other files, too, as long as we're doing the config files. What do you mean by "making connections permanent"? The user would have to double-click the package each time they want to use it. It wouldn't show up anywhere unless they did that.I might have misunderstood that Tunnelblick would "add" that connection permanenty to the pool of available connections. It appears this is not the case, so I'll just shut up now :)Or are you saying the user should have to enter an admin username/ password each time they use a document?No, this would be too cumbersome. Or, at least, it should be configurable - for instance, in large IT organizations it would be of the admin's interest to *NOT* allow people to just up and launch whatever Tunnelblick "document" they come across.On Mar 7, 4:20 pm, Diego Rivera<diego.riv...@rbxglobal.com>wrote:I guess what I dread is automatic, *permanent* addition of administator-level configurations. This could (in the wrong or incompetent hands) cause problems for end users. Instead, if logging is a concern, why not save a log with the same name as the document opened, in the same location the document was opened from (and accompanying warning if it's not writable)? I just think that it'd be better to make the user opt-in to making connections permanent. Also, I believe name conflicts should be an error outright and not be allowed - which "Connection X" am I connected to? The one from the document I just got? Or the one I had saved previously? If an admin needs to update a connection, perhaps the Deploy directory is a cleaner way of going about it - or perhaps we need a different mechanism to handle that case? As for "not going into the list" not allowing disconnect - they can go in the list, just don't let them stay there automatically would be my suggestion. Cheers. On 3/7/10 2:56 PM, jkbull...gmail.com wrote:Thanks, Diego. Are you saying it shouldn't show up the next time you launch Tunnelblick (without double-clicking the document)? That's what I had in mind -- sorry I wasn't more clear. Or do you mean it shouldn't go on the list you see when you click on the Tunnelblick icon? That would cause a problem -- there'd be no way to disconnect it or examine the log. (I guess you could close Tunnelblick to disconnect it.) Another clarification: Rather than refuse to open the document that would cause a name conflict, don't add the configuration(s) that would cause a conflict, but add all configurations that would NOT cause a conflict. And warn the user about the configurations that were not added. A correction: Apparently you would be able to MOVE a document without an admin username/password. You wouldn't be able to COPY it without them, though. That may be another reason to refuse to allow configurations that cause name conflicts. I'm incli ned to not give the user the ability to make the document "permanent". The idea is to make it like a document -- double-click it to open it. If you want it to be "permanent" you could copy it or move it to ~/Library...Configurations. I suppose we notice a non-permanent document when Tunnelblick is quit (like a "dirty" document in an editor) and ask the user if they want to save it. But that means we'd be asking every time the user logs out or the computer is shut down. And if the user did want to make it permanent, we'd either have to (A) move it to ~/Library...Configurations, (B) copy it to ~/ Library...Configurations, or (C) remember it. If (A), it would have to be on the same volume as ~/Library...Configurations, and it disappears from where the user had it, which might be an unpleasant surprise to the user. If (B), it would require an admin username/password, and if (C), it would get lost if the user moved the document. On Mar 7, 3:17 pm, Diego Rivera<diego.riv...@rbxglobal.com>wrote:This sounds like a good plan. One suggestion would be regarding the adding of the document to the available (i.e. static) VPN list. I would suggest making it such that tunnelblick opens the "document" (connection), "executes it", etc, without making it permanent in such a way that making it permanent would require explicit action on the part of the user. This would facilitate deployment, behavior would be consistent with the rest of the user experience, etc. Perhaps even a dialog prior to opening the connection asking the user if they wish to add it permanently. What do you think? On 3/7/10 2:13 PM, jkbull...gmail.com wrote:Tunnelblick "packages" came up a while ago in an Issue (http://code.google.com/p/tunnelblick/issues/detail?id=122). I'd like to discuss how they might work. Here's my proposal; what do you think? * A Tunnelblick "document" would be an OS X bundle with an extension of .tblk. The bundle would contain a mix of configuration files, keys, certificates, and shell scripts -- the stuff that is usually in a "Deploy" folder or in ~/Library/Application Support/Tunnelblick/ Configurations. ("Deploy" is described inhttp://code.google.com/p/tunnelblick/wiki/DeployingTunnelblick.) * When a user double-clicks a Tunnelblick document, Tunnelblick is launched (if it isn't already running), and Tunnelblick adds the documents' configurations to the list of available configurations, as if the contents were in Deploy or in ~/Library/Application Support/ T unnelblick/Configurations. Tunnelblick automatically tries to connect any configurations that have the "autoConnect" preference set. * When Tunnelblick opens the document, it verifies and (if necessary) sets the ownership/permissions of its contents in the same way that the conten ts of Deploy are -- owned by root:wheel with various permissions depending on what each item is. If necessary, the user is asked for an admin username/password so that the ownership/permissions can be set. This would usually only happen the first time the document is opened by Tunnelblick. Since the ownership/permissions of the document itself are not modified (only its contents), the user can still delete, rename, etc. the document. (I think the user would need admin permission to move the document, however.) * Other than that, the document is used "as is", i.e., it isn't copied anywhere or otherwise modified. * In a deployed version of Tunnelblick, documents would only be opened if there was a forc ed preference that specifically allows it. * A document can contain a "preferences.plist". Preferences in it would be copied to the user's normal preferences when the document is opened (only copying preferences that don't exist yet), so they are initialized but the user can modi fy them and they will be persistent. * The CONFIGNAMEautoConnect preference would cause the configuration to be connected when the document is opened. The MAIN QUESTION (assuming the above, of course), is what to do about name collisions. If a document has a configuration with the same name as a configuration in Deploy or in ~/Library...Configurations or in another document that has already been opened, what do we do? (We're also facing this issue if/when we allow aggregation of ~/Library.../ Configuration configs with Deploy configs.) Keys in the Keychain that store passwords, for example, contain the name of the configuration. And so do keys for preferences that are specific to a configuration. We c ould include the full path to the document as part of the key, but then if someone moves the document they'd lose their saved passwords and preferences. And implementing it would break existing stored passwords and preferences. (Or we'd have to migrate them, and then there would be a problem if someone downgraded Tunnelblick to an earlier version.) Note that the "name" of a configuration can be more than the bare filename-without-extension. If you have configs in subfolders of ~/ Library.../Configuration, the subfolder will be included in their names. For example, if you have ~/Library.../Configuration/ABC/ config.ovpn and ~/Library.../Configuration/XYZ/config.ovpn, the two configurations that Tunnelblick uses will have distinct names: ABC/ config and XYZ/config. In this case, there would not be a name conflict, even though both files are named "config.ovpn". My inclination is to simply refuse to open a document that would...
>
> read more »
>
> signature.asc
> < 1KViewDownload
Niels Peen
> * A Tunnelblick "document" would be an OS X bundle with an extension
> of .tblk. The bundle would contain a mix of configuration files, keys,
> certificates, and shell scripts -- the stuff that is usually in a
> "Deploy" folder or in ~/Library/Application Support/Tunnelblick/
> Configurations.
>
I prefer if Tunnelblick's "import" code is generic. E.g. If I double
click an ".ovpn" file anywhere on my filesystem it will offer me the
option to import it and look for certificates (and all other files
referenced) in the same folder it found the ".ovpn" file. The "package"
feature would simply be .tblk (expanded by Tunnelblick) or .zip
(expanded by OS/X) on top of that.
Niels
Niels Peen
> My inclination is to simply refuse to open a document that would cause
> such a name conflict. That's easy, and I don't think it causes an
> undue hardship. But this needs more discussion.
>
> What do YOU think?
>
"XYZ already exists, the profile will be imported as XYZ_2". With OK/Cancel.
Simply refusing the import will be a nightmare (for our support desk
anyway.) Many users will not read that it was refused in the first
place, and keep trying the old/wrong config. Others may see the error
but will have no clue how to resolve it.
Niels
Niels Peen
On 08/03/2010 4:56 AM, jkbull...gmail.com wrote:
> Another clarification: Rather than refuse to open the document that
> would cause a name conflict, don't add the configuration(s) that would
> cause a conflict, but add all configurations that would NOT cause a
> conflict. And warn the user about the configurations that were not
> added.
>
someone 20 configs, they won't remember which 5 failed. As the names
*do* exist in the Tunnelblick menu, how would they figure out afterwards
which failed?
A auto-renaming (be it sequential numbers or a date code) import has my
preference.
Niels
Diego Rivera
Does this make sense?
Cheers.
Niels Peen
Niels
Mohammad A. Haque
having it do anything else i think would introduce too much complexity as you guys have found in the discussion.
jkbull...gmail.com
can't be duplicated otherwise (anyone can make a package installer),
but it looks like everyone likes the idea that Tunnelblick should
"install" the .tblk package into ~/Library...Configurations. OK.
And if there is a .tblk in the .dmg, it should be installed
automatically when Tunnelblick itself is installed by double-clicking
Tunnelblick.app in the .dmg. (Maybe with a checkbox in the "Install
Tunnelblick?" dialog so the user can skip installing the .tblk.)
Name conflicts will still be a problem, though, even if files are auto-
renamed (by # or date or whatever). Because it is not just the configs
that could have name conflicts -- subfolders, keys, certificates,
shell files -- all of them could have conflicts and auto-naming any of
them breaks the config files that refer to them.
The crux of the problem is that the way Tunnelblick sets up OpenVPN,
the working directory is set to ~/Library...Configurations instead of
the folder that the config file is in. (For example, if the config and
keys are in ~/Library...Configurations/ABC, the config file refers to
the key files as "key ABC/xyz.key"). I don't want to change that
because it would break existing setups in ~/Library...Configurations.
I think I can solve the referring-to-key-files problem a different
way. How about copying the entire .tblk into ~/
Library...Configurations and have Tunnelblick set up the working
directory differently (to the folder containing the config file) for
configs contained in a .tblk? Auto-renaming the .tblks would not
interfere with references to key, etc. files because they could be
referred to in the config file relative to the config file itself. (It
wouldn't allow the use of common keys, certs, or scripts located in an
outer folder, because (I think) OpenVPN doesn't allow ".." in
references to the key files.)
I had been thinking that it would be easy if we just accepted a more-
or-less non-structured format for .tblk: A copy of Deploy, or of ~/
Library...Configurations would do. But if we impose a little bit of
structure, we can make things nicer for the user, which is (I think)
the most important thing. Assuming a .tblk package consists of folders
with one or more configs per folder, without doing anything special in
the program, the user would see config names like "tblkname.tblk/
foldername/configname". But maybe we could simplify that a bit:
* Drop the .tblk
* If there was only one config in a folder, drop the config name, so
the user would see "tblkname/foldername".
* If there was only one folder in a .tblk, drop the folder name, so
the user would see "tblkname/configname"
* If there was only one config in one folder in a .tblk, drop both the
folder and the config names, so the user would see "tblkname".
This would lead to ambiguity for the user with abc.tblk when there is
already an abc folder in ~/Library...Configurations, but I think the
program could notice that kind of problem and not apply the rules if
that were the case. (The program would always store preferences and
Keychain keys using "tblkname/foldername/configname".)
So what do we do about name conflicts with existing .tblk packages
already in ~/Library...Configurations? We could replace the existing
package, rename the new package (either by number or by date, although
I prefer by number), or give the user a choice. Or the .tblk could
contain preferences: "neverReplaceThis", "alwaysReplaceThis" in the
"existing" .tblk, and "doNotReplace", and "doReplace" in the new .tblk
could be used to give a lot of flexibility. If nothing was specified,
or there was a conflict, the user could be asked what to do.
About preferences in the .tblks: A "preferences.plist" in the .tblk
could be parsed upon installation of the .tblk, with configuration-
based preferences copied into the user's regular preferences,
adjusting for any renaming of the .tblk itself. Non-configuration-
based preferences would be ignored. (Or maybe set them if they don't
exist?)
===========
I am reluctant to register Tunnelblick to open .ovnp and .conf files
for a couple of reasons. (And in my mind it is a separate issue from
the .tblk implementation). First, I don't want to interfere with other
programs that might do something with them. (Other VPN software,
presumably). Second, it would mean people would have to double-click
once (on a .zip or a folder or something) to get to the .ovpn file,
and then would have to double-click the .ovpn file. Maybe there's
something I'm missing here?
Please keep these comments and ideas coming in!
jkbull...gmail.com
doesn't examine subfolders of Deploy the way that subfolders of ~/
Library...Configurations are examined, and it gives those subfolders
644 permissions, instead of 655 permissions. I'll probably fix that in
a patch sometime soon.
Mohammad A. Haque
Consider the following bundle structure (Resources could be different -- I am modeling after how I use Tunnelblick/openvpn):
VPN.tblk
VPN.tblk/Content
VPN.tblk/Content/Info.plist <-- contains bundle name, config version info and/or defaults for DNS/other Tunnelblick options
VPN.tblk/Content/Resources
VPN.tblk/Content/Resources/VPN.conf <-- opencpn confi file
VPN.tblk/Content/Resources/VPN/VPN.crt <-- crt file/ can be in same level as conf
VPN.tblk/Content/Resources/VPN/VPN.sh <-- crt file/ can be in same level as conf
VPN.tblk/Content/Resources/VPN/....
* Tunnelblick now instead of looking for *.conf, should now look for *.tblk in ~/L/AS/Tunnelblick/Configurations.
* openvpn is now passed --cd ~/L/AS/Tunnelblick/Configurations/VPN.tblk/Content/Resources (maybe even --chroot for security).
This offers the following:
* Tunnelblick is no longer dependent on conf filenames for connection display names (should be pulled from Info.plist or fall back to tblk name.
* Tunnelblick won't care about names of certs/scripts/etc if it needs to rename the tblk bundle in the case of a name collision
* Offers the ability of tblk maintainers to version control their configurations in depployments
- Tunnelblick can prompt user that this is a newer version of an existing config
I know you are very heavily concerned with backwards compatibility. Auto-converting existing configs may be an option. Quite frankly though, I'd say just bump the version number of Tunnelblick and state that tblk bundles are required. Such is the life cycle of software.
Thoughts?
> --
> You received this message because you are subscribed to the Google Groups "tunnelblick-discuss" group.
> To post to this group, send email to tunnelbli...@googlegroups.com.
> To unsubscribe from this group, send email to tunnelblick-dis...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/tunnelblick-discuss?hl=en.
>
jkbull...gmail.com
setup with a new one that needs any work on their part. Maybe the old
and new setups can coexist.
I like Mohammad's idea of including version numbers, but I don't think
it is a solution to name conflicts. Even with version numbers we still
would need to do something (probably ask the user if they want to
upgrade/downgrade/reinstall/auto-rename). As long as we're doing that
we can ask if they want to replace the existing (old style) config. If
they do, we would delete the config, but not the old certs, etc.
(because we don't know if they are used by other configs). Certs, etc.
take up almost no space, so I don't think that matters much. If they
don't want to replace the old-style config, we auto-rename the .tblk.
I'm not clear on some of the details of Mohammad's proposal:
* Why shouldn't we be "dependent on conf filenames for connection
display names"? We've got to be dependent on _something_.
* If the display name is the bundle name, under what circumstances do
we "fall back" to the .tblk name?
* It looks like you can only have one config file per .tblk -- is that
the idea?
jkbull...gmail.com
better than I did earlier, and I think it can coexist with the way ~/
Library/.../Configurations is used now.
The name of the .tblk (with the .tblk omitted) would be used as the
display name (also used to create per-configuration preferences and
Keychain keys).
The "Bundle identifier" (CFBundleIdentifier) in Info.plist would be
used to identify a configuration for the purposes of comparing two
configurations. (The .tblk name is NOT used for this purpose.)
"Opening" a .tblk would normally consist of copying it to ~/
Library/.../Configurations and setting permissions on the copy in the
same manner as permissions is /Resources/Deploy are set.
When opening the .tblk, if the CFBundleIdentifier matches one in an
existing .tblk in ~/Library/.../Configurations, the user would be
prompted to upgrade/downgrade/reinstall the .tblk (depending on the
CFBundleVersion in Info.plist) or cancel. They would NOT be given the
option of having two .tblks with the same CFBundleIdentifier. The name
of the new .tblk (in ~/Library/.../Configurations) would be changed,
if necessary, to match the name of the .tblk it is replacing. Since
the display name of the configuration will not change, preferences and
Keychain keys for the old version would be used for the new version.
Also, when opening the .tblk, if there is a .tblk display name
conflict (i.e., a conflict with an existing .tblk name or with an
existing .ovpn or .conf), the user would be given the option of auto-
renaming the .tblk, specifying a new name, deleting the
existing .ovpn, .conf, or .talk, or canceling. Deleting a .ovpn
or .conf might leave orphaned keys, certs, shell scripts, etc. around,
but I don't see that as a big problem.
The ../Resources folder could have contents arranged in any way, but
there must be one and only one config file somewhere in it.
Personally, I'd put everything at the top-most level of .../Resources,
but Tunnelblick wouldn't care where things are.
As Mohammad says, when connecting using a config file which resides in
a .tblk, Tunnelblick would pass "--cd ~/Library/.../Configurations/
ABC.tblk/Content/Resources} to OpenVPN. Otherwise, Tunnelblick would
pass "--cd..." as we do now.
Here's what would go in the Info.plist:
* "Bundle identifier" (CFBundleIdentifier) is a string of the form
com.abc.tbconfigs.config27A that uniquely identifies the configuration
for the purposes of the individual or organization distributing
the .talk.
* "Bundle version" (CFBundleVersion) is a string of the form #[.#[.#]]
-- this is the version number that is compared to determine later/
earlier versions.
* "Bundle versions string, short" (CFBundleShortVersionString) is the
string to display as the version (in Get Info, for example).
* Item(s) with names beginning with "TB-Preference" are preferences
for the configuration. If not already present (with any value), they
are copied to the user's regular preferences each time Tunnelblick
loads the .tblk (when Tunnelblick is launched or the .tblk is added to
the Configurations folder). When they are so copied, the "TB-
Preference" is replaced with the name of the .tblk.
I don't know if type and creator codes (CFBundlePackageType and
CFBundleSignature, respectively) are necessary in Info.plist, or what
they should be. But they wouldn't affect Tunnelblick's behavior, so I
don't think it matters. (As I understand it, we can "register" the
".tblk" extension to launch Tunnelblick, and don't need to specify the
type and creator codes.)
Reactions?
jkbull...gmail.com
owner/permissions set the way that they are for Deploy), but that
won't work if the home folder is on a remote volume (or in some other
situations in which files can't be secured).
The config file can be left unsecured -- the existing code that
creates a secure "shadow copy" of non-securable config files should
handle that (or can I modify it to do so).
Securing scripts the same way will be trickier, but I think doable.
Does anybody care about that? I assume so, because it is -- to me -- a
gaping security hole that an ordinary user can exploit to get root
access, but if not I can avoid a lot of work.
Thoughts? (Or is everybody too tired of this whole discussion
already? :)
> ...
>
> read more »
Michael Williams
way you leave the tblk file able to be moved around by the user for
organization, backup, etc. Then, when Tunnelblick exits, or maybe
even when it disconnects from that connection (by user interaction),
it deletes the shadow copy.
That way, we don't have to worry about running off network drives,
(unless the app itself is on a network drive, possibly), and that
seems like it would eliminate much of the concerns about security.
Though, you also (as the user) could edit the scripts before opening
the .tblk package in the first place, before it is secured.
jkbull...gmail.com
admin username/password. If is deleted, we would be asking for the
username/password every time you connect, or every time you connect
after relaunching Tunnelblick, depending on when we delete it. Right
now, you give the admin username/password only once, when the shadow
copy is created. After that, when you connect it just checks that the
shadow copy is identical to the original. If so, it is used. If not,
it prompts for an admin username/password and makes a new shadow copy
and uses that.
Making a shadow copy of the entire .tblk (or perhaps just its /
Resources folder) may be just as easy or easier than copying only the
config and scripts. We would have to replicate the directory structure
of the .tblk anyway, because we don't know how the config refers to
the keys, etc.
Or we could decree that the .tblks /Resource folder be flat (i.e.,
contain no folders itself -- everything would have to be directly
under /Resources. (Same way that the /Deploy folder must be flat.)
By the way, the _app_ can't be on a network drive (or, at least, not
on one that can't be secured). The app has to secure itself.
One can modify the app (including imbedded scripts) before it is
secured. But it can't be used before it is secured, and it takes an
admin username/password to secure it, so the idea is that the admin
knows that it hasn't been modified.
Mohammad A. Haque
> Thanks for your proposal, Mohammad. I think I understand it a little
> better than I did earlier, and I think it can coexist with the way ~/
> Library/.../Configurations is used now.
>
> The name of the .tblk (with the .tblk omitted) would be used as the
> display name (also used to create per-configuration preferences and
> Keychain keys).
You could go as far to say that there could be a special key in Info.plist that would define how the connection should be listed in the menu. This way you can have names with characters that are not normally allowed on the filesystem. Should this special key not exist, then the name of the tblk should be used.
Mohammad A. Haque
Move the tblk to the configuration directory and fix the permission on conf files, certs, script within the tblk. The tblk itself doesn't need anything done other than belonging to the user.
Is this in line with what you are saying?
jkbull...gmail.com
> in Info.plist that would define how the connection should be
> listed in the menu. This way you can have names with
> characters that are not normally allowed on the filesystem.
> Should this special key not exist, then the name of the tblk
> should be used.
Pardon my ignorance, but aren't filenames Unicode? Can't you have
filenames in Chinese, for example? I thought you could. Or are you
talking about the reserved characters not allowed in a filename, like
":"? If it is just a couple of characters, it may not be worth the
effort.
Assuming I'm wrong about filenames being Unicode, I like the idea.
The .tblk filename would have to be distinct, too, but I think that's
solved above. I think preferences and Keychain items would work with
arbitrary Unicode keys, but I'd want to check. The biggest problem
with it that I see right now is that there would be a disconnect
between the filename that the user sees and the connection name. There
might be a "hey, I installed abc.tblk, and it installed connection xyz
instead" reaction. But I suppose lots of times the user wouldn't even
see the filename (for example, with an automatic installation from
the .dmg when Tunnelblick itself is installed), so maybe that's OK.
> Move the tblk to the configuration directory and fix the
> permission on conf files, certs, script within the tblk.
> The tblk itself doesn't need anything done other than
> belonging to the user.
> Is this in line with what you are saying?
Yes, sorry I wasn't more clear. The .tblk itself would be owned by the
user (so they could delete it, for example). But everything inside it
would be owned by root, and have various permissions as appropriate
(although the user would not have write access to anything inside
the .tblk).
I think we should always copy, not move (we'd have to copy anyway if
it isn't on the volume with the home directory, for example, if it was
on a .dmg).