Desired behavior for untrusted plugin

I’ve implemented a check for new/modified plugins on startup
What is desired behavior in case user rejected plugin?
a) Don’t load factory at all (letting user to enable it again will require more effort)
b) Load plugin in disabled state


Regards,
Konstantin

On Tue, Nov 9, 2010 at 1:14 PM, Konstantin Tokarev annulen@yandex.ru wrote:

I’ve implemented a check for new/modified plugins on startup
What is desired behavior in case user rejected plugin?
a) Don’t load factory at all (letting user to enable it again will require more effort)
b) Load plugin in disabled state

Perhaps you can let the user decide? I’m not sure what you GUI looks
like, but I’m picturing a table with the name of the plugin and three
exclusive checkboxes: “Load”, “Load disabled”, “Do not load” or
similar.

Dave

09.11.2010, 22:31, “David Lonie” loniedavid@gmail.com:

On Tue, Nov 9, 2010 at 1:14 PM, Konstantin Tokarev annulen@yandex.ru; wrote:

I’ve implemented a check for new/modified plugins on startup
What is desired behavior in case user rejected plugin?
a) Don’t load factory at all (letting user to enable it again will require more effort)
b) Load plugin in disabled state

Perhaps you can let the user decide? I’m not sure what you GUI looks
like, but I’m picturing a table with the name of the plugin and three
exclusive checkboxes: “Load”, “Load disabled”, “Do not load” or
similar.

Right now it’s QMessageBox with question and “Yes” and “No” options :slight_smile:


Regards,
Konstantin

2010/11/9 Konstantin Tokarev annulen@yandex.ru:

09.11.2010, 22:31, “David Lonie” loniedavid@gmail.com:

On Tue, Nov 9, 2010 at 1:14 PM, Konstantin Tokarev annulen@yandex.ru; wrote:

I’ve implemented a check for new/modified plugins on startup
What is desired behavior in case user rejected plugin?
a) Don’t load factory at all (letting user to enable it again will require more effort)
b) Load plugin in disabled state

Perhaps you can let the user decide? I’m not sure what you GUI looks
like, but I’m picturing a table with the name of the plugin and three
exclusive checkboxes: “Load”, “Load disabled”, “Do not load” or
similar.

Right now it’s QMessageBox with question and “Yes” and “No” options :slight_smile:

Does a separate message box pop up for every new/changed extension?
This would be bad, most users will just click through them all without
really reading them.

Dave

Does a separate message box pop up for every new/changed extension?
This would be bad, most users will just click through them all without
really reading them.

OK, I will change it to table. It would be nice to display plugin descriptions
alongside with file names, but it is not secure to load untrusted factory


Regards,
Konstantin

Does a separate message box pop up for every new/changed extension?

Anyway, it will be disabled on Avogadro update when all plugins are modified


Regards,
Konstantin

10.11.2010, 00:20, “David Lonie” loniedavid@gmail.com:

2010/11/9 Konstantin Tokarev annulen@yandex.ru;:

09.11.2010, 22:31, “David Lonie” loniedavid@gmail.com;:

On Tue, Nov 9, 2010 at 1:14 PM, Konstantin Tokarev annulen@yandex.ru;; wrote:

I’ve implemented a check for new/modified plugins on startup
What is desired behavior in case user rejected plugin?
a) Don’t load factory at all (letting user to enable it again will require more effort)
b) Load plugin in disabled state
Perhaps you can let the user decide? I’m not sure what you GUI looks
like, but I’m picturing a table with the name of the plugin and three
exclusive checkboxes: “Load”, “Load disabled”, “Do not load” or
similar.
Right now it’s QMessageBox with question and “Yes” and “No” options :slight_smile:

Does a separate message box pop up for every new/changed extension?
This would be bad, most users will just click through them all without
really reading them.

Should dialog be created inside library or application?

Arguments for library:

  • implementation is more straightforward;
  • other client of libavogadro (e.g. Kalzium) can get this feature with minimal effort

Arguments for application:

  • client application may want to use their own GUI (or non-GUI) handling of this situation
  • currently there are no actual GUI components (except the GLWidget) in libavogadro

Any opinions?


Regards,
Konstantin

On Nov 16, 2010, at 2:05 PM, Konstantin Tokarev wrote:

  • other client of libavogadro (e.g. Kalzium) can get this feature with minimal effort

Other clients may strictly list plugins anyway and not allow dynamic loading.

Arguments for application:

  • client application may want to use their own GUI (or non-GUI) handling of this situation
  • currently there are no actual GUI components (except the GLWidget) in libavogadro

Application would be my preferred mechanism. I agree with your division about the GUI components not existing in libavogadro, and that client applications may have their own technique. Consider, for example, embedding libavogadro in a Python script from the command-line.

That’s my $0.02,
-Geoff

17.11.2010, 07:24, “Geoffrey Hutchison” geoff.hutchison@gmail.com:

On Nov 16, 2010, at 2:05 PM, Konstantin Tokarev wrote:

  • other client of libavogadro (e.g. Kalzium) can get this feature with minimal effort

Other clients may strictly list plugins anyway and not allow dynamic loading.

This code protects not only from new plugins, but also from their modification, so it
may be useful even when the list of plugins is fixed


Regards,
Konstantin

16.11.2010, 22:05, “Konstantin Tokarev” annulen@yandex.ru:

10.11.2010, 00:20, “David Lonie” loniedavid@gmail.com;:

2010/11/9 Konstantin Tokarev annulen@yandex.ru;;:

09.11.2010, 22:31, “David Lonie” loniedavid@gmail.com;;:

On Tue, Nov 9, 2010 at 1:14 PM, Konstantin Tokarev annulen@yandex.ru;;; wrote:

I’ve implemented a check for new/modified plugins on startup
What is desired behavior in case user rejected plugin?
a) Don’t load factory at all (letting user to enable it again will require more effort)
b) Load plugin in disabled state
Perhaps you can let the user decide? I’m not sure what you GUI looks
like, but I’m picturing a table with the name of the plugin and three
exclusive checkboxes: “Load”, “Load disabled”, “Do not load” or
similar.
Right now it’s QMessageBox with question and “Yes” and “No” options :slight_smile:
Does a separate message box pop up for every new/changed extension?
This would be bad, most users will just click through them all without
really reading them.

One more question on this topic: should it be submitted to 1.0 or master?
Right now I’m writing it on 1.0 branch

Arguments for 1.0:

  1. it fixes security vulnerability
  2. it does not modify ABI (I’ve put the most of new code in class PluginLoader
    which replaces QPluginLoader in PluginManager)

Arguments for master:

  1. it’s non-trivial change
  2. it adds new GUI (if it were not added it would not be user-friendly as David pointed previously)
  3. it adds new API functions (because of (2) it’s impossible to incapsulate everything inside
    PluginLoader)


Regards,
Konstantin

On Wednesday 17 November 2010 07:56:36 Konstantin Tokarev wrote:

16.11.2010, 22:05, “Konstantin Tokarev” annulen@yandex.ru:

10.11.2010, 00:20, “David Lonie” loniedavid@gmail.com;:

2010/11/9 Konstantin Tokarev annulen@yandex.ru;;:

09.11.2010, 22:31, “David Lonie” loniedavid@gmail.com;;:

On Tue, Nov 9, 2010 at 1:14 PM, Konstantin Tokarev
annulen@yandex.ru;;; wrote:

I’ve implemented a check for new/modified plugins on startup
What is desired behavior in case user rejected plugin?
a) Don’t load factory at all (letting user to enable it again will
require more effort) b) Load plugin in disabled state

Perhaps you can let the user decide? I’m not sure what you GUI looks
like, but I’m picturing a table with the name of the plugin and
three exclusive checkboxes: “Load”, “Load disabled”, “Do not load” or
similar.

Right now it’s QMessageBox with question and “Yes” and “No” options
:slight_smile:

Does a separate message box pop up for every new/changed extension?
This would be bad, most users will just click through them all without
really reading them.

One more question on this topic: should it be submitted to 1.0 or master?
Right now I’m writing it on 1.0 branch

Arguments for 1.0:

  1. it fixes security vulnerability
  2. it does not modify ABI (I’ve put the most of new code in class
    PluginLoader which replaces QPluginLoader in PluginManager)

Arguments for master:

  1. it’s non-trivial change
  2. it adds new GUI (if it were not added it would not be user-friendly as
    David pointed previously) 3) it adds new API functions (because of (2)
    it’s impossible to incapsulate everything inside PluginLoader)

I think it should go into master - we will release new versions of 1.1, and
1.0 should ideally be bug fixes - new features can, and often do, introduce
unintentional bugs.

Marcus