I've finished designing (and implementing) the very first experimental version of a new PLGX plugin file format for KeePass 2.x. This format will allow plugin developers packing their plugins in such a way that they are compatible with multiple versions of KeePass (i.e. no recompiling for each KeePass release is required anymore).
The file format is designed to be extensible. Advanced features like integrity checking and signing can be added later.
The latest 2.x development snapshot is available here: http://keepass.info/filepool/KeePass_090820c.zip
(big file, it contains some sample PLGX files; note that some of these sample plugins require .NET 3.5)
I am using KP that is not installed.
Look like there should be a folder called PluginCache somewhere.
And it's here:
C:\Users\Piotr\AppData\Roaming\KeePass\PluginCache
Now just a though - if we run KP from usb stickes?
Just thinking if there is a reason to have it in the same folder as exe.
But that would be a problem with installed KP.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For the first version I've chosen this directory in the user's application data directory, because it is always writable. Putting it into the application directory would be rather complicated (checking whether it is writable -- how do you solve switches between admin/non-admin?, checking free disk space, performance issues, ...), but I'll keep it in mind for a later feature.
Thanks and best regards
Dominik
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
How about the following feature similar to <ClearPluginCacheOnce>false</ClearPluginCacheOnce>
<InteligentClearPluginCache>
bool default to true
that would delate scan the cache dir and delete cached pluging that:
- are form older version of keepass
- haven't been used for some time - eg >2 months (last acess time)
The first part might couse problems if we run multiple keepass versions (however that is rare). And this feature might be dissables at Option or Plugins form.
Cheers,
Piotr J.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- mayby adding a DataTime.Now and presenting it on the pluging form as "packed date" or "date of creation"
- the plugin form shows from where the plugin has been loaded - in case of dll it point to the dll. When plgx it points to the cached dll - thought - mayby point to the plgx file and opitonaly add (cached form ...)
Cheers,
Piotr J.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Nice idea, I've implemented it! The option can be found in the plugins dialog and is enabled by default. Cached plugins older than 2 months are deleted (independent of version).
> mayby adding a DataTime.Now and presenting it on the pluging
> form as "packed date" or "date of creation"
I don't think showing the creation time of the PLGX file in the plugins dialog is useful (the version is already displayed), but have added a field in the PLGX file format for it anyway (maybe it's useful for something in the future). Additionally, I've added fields for the application name and version that generated the PLGX file.
> mayby point to the plgx file
Right, it should definitely point to the PLGX file. I've changed that.
I've added the ability to specify plugin prerequisites (minimum KeePass and .NET Framework version). If one of the plugin prerequisites isn't met, KeePass shows a detailed error message to the end-user (instead of a generic plugin incompatibility message).
I've now added the ability to specify the OS and pointer size (x86 vs. x64) as prerequisites. The new pre-build and post-build commands can be used to copy additional files.
I'm thinking of converting KeeICE (the KeePass plugin part of KeeFox) to this PLGX format. One upgrade path for KeeFox starts with an updated Firefox add-on and I currently dump the latest KeeICE.dll (and Ice.dll dependency) into the Plugins directory. This works but it's a bit clunky (user needs to have KeePass running first, then close it, then re-open it for the new plugin to be detected, after having just restarted Firefox).
1) Will an updated PLGX file be automatically detected by KeePass?
2) Are there any prospects for a neater solution (either in 2.09 or future versions)? Maybe dynamic PLGX re-compilation without a restart of KeePass?
Could I stream the contents of a new PLGX through an existing Firefox-KeePass connection and program the KeeICE plugin to request that KeePass re-compiles KeeICE using the new code? (either on-demand or at next KeePass start-up)
With the streamed PLGX idea, there is a theoretical security risk (plugin code is no longer protected by file system permissions). Is displaying an "are you sure?" dialog box to the user going to be sufficient to mitigate? Any other ideas for how this could be made safer?
Thinking more broadly, could this be the start of an internet "automatic update" facility which is provided to all plugins? Despite some potential drawbacks, the ability for plugin authors to quickly distribute updates might prove very useful one day if a plugin needs a security hole patched quickly (and with PLGX there isn't even the need to upgrade plugins with new versions of KeePass which could leave problems exposed for much longer).
Thanks,
Chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just my thought about trying to force users to have the latest plugin (uptodate) version.
1) If a user want's to check for KeePass updates also have a plugin check for it's (see commenst in
2) Set an expiry date on a plugin (for eg. in a 1 year time) - if someone want's he can recompile the plugin without that - and the rest will (probably) update after expiery.
> 1) Will an updated PLGX file be automatically detected by KeePass?
Yes, KeePass loads PLGX files each time it starts. When an existing PLGX file is replaced by an updated version, KeePass will detect this and automatically compile, cache and load the updated one.
> 2) Are there any prospects for a neater solution (either in 2.09 or future versions)? Maybe dynamic PLGX re-compilation without a restart of KeePass?
No, this isn't possible. Plugin assemblies are loaded into the KeePass AppDomain (otherwise plugins couldn't access KeePass classes and methods). When this happened, unloading the plugin assembly isn't possible anymore, see . So, when trying to load a second version of the plugin, this would fail due to name conflicts. Of course, separate AppDomains could be unloaded, but then plugins would be extremely limited. I prefer to allow plugins full access to KeePass.
Feel free to write some automatic update plugin (which other plugins could use); I'm not planning to add something like this to KeePass.
I have now converted KeeICE to use the PLGX format and it all seems to work well!
I have written an article that explains how one can .
I now understand why KeePass must be restarted and that is fine - thanks for explaining it. I may look into an automatic update plugin one day but it's not strictly necessary for KeeICE because of the way it is packaged as part of a Firefox add-on.
luckyrat, i think the auto-update feature can still work since the .plgx file isn't kept open by KeePass while it's running. it's just a matter of replacing the .plgx file and a way to trigger the cache rebuild, if the plgx replacement doesn't trigger it already.
that said, considering that plugins have full access to KeePass and that i'm still a bit paranoid about DNS poisoning issues, auto-updates isn't something i'd recommend. i think an update detection and notification feature would be a lot simpler and is more secure. of course, that won't prevent one from having a poisoned DNS server, but at least it allows the user take steps to confirm the validity of the download somehow prior to installation.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've finished designing (and implementing) the very first experimental version of a new PLGX plugin file format for KeePass 2.x. This format will allow plugin developers packing their plugins in such a way that they are compatible with multiple versions of KeePass (i.e. no recompiling for each KeePass release is required anymore).
A preliminary detailed documentation of the format is available here:
http://keepass.info/help/v2_dev/plg_index.html#plgx
The file format is designed to be extensible. Advanced features like integrity checking and signing can be added later.
The latest 2.x development snapshot is available here:
http://keepass.info/filepool/KeePass_090820c.zip
(big file, it contains some sample PLGX files; note that some of these sample plugins require .NET 3.5)
The latest source code is here:
http://keepass.info/filepool/KeePass_090820b.zip
Extensive testing and feedback on the PLGX design and implementation is very welcome :-)
Thanks and best regards
Dominik
Just some random thought:
I am using KP that is not installed.
Look like there should be a folder called PluginCache somewhere.
And it's here:
C:\Users\Piotr\AppData\Roaming\KeePass\PluginCache
Now just a though - if we run KP from usb stickes?
Just thinking if there is a reason to have it in the same folder as exe.
But that would be a problem with installed KP.
For the first version I've chosen this directory in the user's application data directory, because it is always writable. Putting it into the application directory would be rather complicated (checking whether it is writable -- how do you solve switches between admin/non-admin?, checking free disk space, performance issues, ...), but I'll keep it in mind for a later feature.
Thanks and best regards
Dominik
How about the following feature similar to <ClearPluginCacheOnce>false</ClearPluginCacheOnce>
<InteligentClearPluginCache>
bool default to true
that would delate scan the cache dir and delete cached pluging that:
- are form older version of keepass
- haven't been used for some time - eg >2 months (last acess time)
The first part might couse problems if we run multiple keepass versions (however that is rare). And this feature might be dissables at Option or Plugins form.
Cheers,
Piotr J.
Just some other thought:
- mayby adding a DataTime.Now and presenting it on the pluging form as "packed date" or "date of creation"
- the plugin form shows from where the plugin has been loaded - in case of dll it point to the dll. When plgx it points to the cached dll - thought - mayby point to the plgx file and opitonaly add (cached form ...)
Cheers,
Piotr J.
> haven't been used for some time - eg >2 months
Nice idea, I've implemented it! The option can be found in the plugins dialog and is enabled by default. Cached plugins older than 2 months are deleted (independent of version).
> mayby adding a DataTime.Now and presenting it on the pluging
> form as "packed date" or "date of creation"
I don't think showing the creation time of the PLGX file in the plugins dialog is useful (the version is already displayed), but have added a field in the PLGX file format for it anyway (maybe it's useful for something in the future). Additionally, I've added fields for the application name and version that generated the PLGX file.
> mayby point to the plgx file
Right, it should definitely point to the PLGX file. I've changed that.
The latest development snapshot for testing is available here:
http://keepass.info/filepool/KeePass_090824b.zip
Thanks for the suggestions, best regards
Dominik
I've added the ability to specify plugin prerequisites (minimum KeePass and .NET Framework version). If one of the plugin prerequisites isn't met, KeePass shows a detailed error message to the end-user (instead of a generic plugin incompatibility message).
Updated documentation:
http://keepass.info/help/v2_dev/plg_index.html
The latest development snapshot can be found here:
http://keepass.info/filepool/KeePass_090826.zip
Best regards
Dominik
Mayby also a prerequisites for OS (win, linux) etx. Not neccecerly x86, x64.
Some pluging might use OS dependent code. Or dll in c++.
And is there a way for including other files (dll, exe) that the plugin might use (writen in other languages the c# or vb).
Cheers,
Piotr J.
I've now added the ability to specify the OS and pointer size (x86 vs. x64) as prerequisites. The new pre-build and post-build commands can be used to copy additional files.
Detailed documentation is available here:
http://keepass.info/help/v2_dev/plg_index.html
The latest development snapshot for testing is available here:
http://keepass.info/filepool/KeePass_090830c.zip
Thanks and best regards
Dominik
And to use an extra file in the cache we would use:
KeePass.Plugins.PlgxCache.GetCacheDirectory
But where could we find the pwPluginUuid of the current plugin?
Piotr J.
To get the location of the generated assembly in the cache, use System.Reflection.Assembly.GetExecutingAssembly().Location
Best regards
Dominik
Plugins do not have acces to KeePass.Native.NativeMethods?
Cheers,
PJ
No, and they must not. If you need native methods, write your own NativeMethods class.
Best regards
Dominik
I'm thinking of converting KeeICE (the KeePass plugin part of KeeFox) to this PLGX format. One upgrade path for KeeFox starts with an updated Firefox add-on and I currently dump the latest KeeICE.dll (and Ice.dll dependency) into the Plugins directory. This works but it's a bit clunky (user needs to have KeePass running first, then close it, then re-open it for the new plugin to be detected, after having just restarted Firefox).
1) Will an updated PLGX file be automatically detected by KeePass?
2) Are there any prospects for a neater solution (either in 2.09 or future versions)? Maybe dynamic PLGX re-compilation without a restart of KeePass?
Could I stream the contents of a new PLGX through an existing Firefox-KeePass connection and program the KeeICE plugin to request that KeePass re-compiles KeeICE using the new code? (either on-demand or at next KeePass start-up)
With the streamed PLGX idea, there is a theoretical security risk (plugin code is no longer protected by file system permissions). Is displaying an "are you sure?" dialog box to the user going to be sufficient to mitigate? Any other ideas for how this could be made safer?
Thinking more broadly, could this be the start of an internet "automatic update" facility which is provided to all plugins? Despite some potential drawbacks, the ability for plugin authors to quickly distribute updates might prove very useful one day if a plugin needs a security hole patched quickly (and with PLGX there isn't even the need to upgrade plugins with new versions of KeePass which could leave problems exposed for much longer).
Thanks,
Chris
Chris,
Just my thought about trying to force users to have the latest plugin (uptodate) version.
1) If a user want's to check for KeePass updates also have a plugin check for it's (see commenst in
2) Set an expiry date on a plugin (for eg. in a 1 year time) - if someone want's he can recompile the plugin without that - and the rest will (probably) update after expiery.
Cheers,
Piotr J
: https://sourceforge.net/tracker/?func=detail&aid=2845859&group_id=95013&atid=609911
> 1) Will an updated PLGX file be automatically detected by KeePass?
Yes, KeePass loads PLGX files each time it starts. When an existing PLGX file is replaced by an updated version, KeePass will detect this and automatically compile, cache and load the updated one.
> 2) Are there any prospects for a neater solution (either in 2.09 or future versions)? Maybe dynamic PLGX re-compilation without a restart of KeePass?
No, this isn't possible. Plugin assemblies are loaded into the KeePass AppDomain (otherwise plugins couldn't access KeePass classes and methods). When this happened, unloading the plugin assembly isn't possible anymore, see . So, when trying to load a second version of the plugin, this would fail due to name conflicts. Of course, separate AppDomains could be unloaded, but then plugins would be extremely limited. I prefer to allow plugins full access to KeePass.
Feel free to write some automatic update plugin (which other plugins could use); I'm not planning to add something like this to KeePass.
Thanks and best regards,
Dominik
: http://blogs.msdn.com/jasonz/archive/2004/05/31/145105.aspx
Thanks for the replies.
I have now converted KeeICE to use the PLGX format and it all seems to work well!
I have written an article that explains how one can .
I now understand why KeePass must be restarted and that is fine - thanks for explaining it. I may look into an automatic update plugin one day but it's not strictly necessary for KeeICE because of the way it is packaged as part of a Firefox add-on.
Thanks,
Chris
: http://christomlinson.name/articles/keepass-plgx-build-automation
luckyrat, i think the auto-update feature can still work since the .plgx file isn't kept open by KeePass while it's running. it's just a matter of replacing the .plgx file and a way to trigger the cache rebuild, if the plgx replacement doesn't trigger it already.
that said, considering that plugins have full access to KeePass and that i'm still a bit paranoid about DNS poisoning issues, auto-updates isn't something i'd recommend. i think an update detection and notification feature would be a lot simpler and is more secure. of course, that won't prevent one from having a poisoned DNS server, but at least it allows the user take steps to confirm the validity of the download somehow prior to installation.