Re: Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
On 8/4/06, Nigel Tao <[EMAIL PROTECTED]> wrote: > Just a thought - one mechanism is to require two signatures, or > mandatory review. What exactly are you trying to stop again? I thought the point was to stop server cracking (note that many projects don't sign their source tarballs!). If this starts getting into reviewing code to check for evil, then this is something totally different and much harder. There's not much point in doing that, IMHO. Just give a bunch of trusted people access to the index file, and if somebody reports that a particular plugin has gone bad, yank it. thanks -mike ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
> You sign things with your own key and the server has a list of keys it > accepts things from. it removes your signature and signs your file > with it's own key. Afaik this is how Debian and etc manage package > uploads. Just a thought - one mechanism is to require two signatures, or mandatory review. Suppose that Raphael and I are on the small list of blessed "deskbar NewStuff gatekeepers" (and this list may differ from the "epiphany NewStuff gatekeepers", for example). I upload my signed copy of foo, and Raphael uploads his signed copy of foo. The server verifies the two signatures, and that the two copies of foo are equal, and then gives it the official seal. Two orthogonal questions: Does anyone already do this? Is this a good idea? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
On 8/2/06, Nigel Tao <[EMAIL PROTECTED]> wrote: > Also, there's the people-security issues of who has access (or how do > they get access) to the keys (and is that access revokable, and what > happens if somebody crucial gets hit by a bus), and what the final > master list URL is (which, as Shaun correctly mentions is part of the > API, just like the new D-Bus interface org.gnome.NewStuffManager), how > is this list hosted, and how is it updated. You sign things with your own key and the server has a list of keys it accepts things from. it removes your signature and signs your file with it's own key. Afaik this is how Debian and etc manage package uploads. -- Travis Watkins http://www.realistanew.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
> Is it really that hard to check a digital signature? I wouldn't think so, but the fact is that we haven't implemented it yet, and we're in all sorts of freezes by now. Also, there's the people-security issues of who has access (or how do they get access) to the keys (and is that access revokable, and what happens if somebody crucial gets hit by a bus), and what the final master list URL is (which, as Shaun correctly mentions is part of the API, just like the new D-Bus interface org.gnome.NewStuffManager), how is this list hosted, and how is it updated. There's just a lot of work to get from proof-of-concept code to slapping "stable" and "(not obviously in)secure" stickers on it, IMHO. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason D. Clinton wrote: > On Wed, 2006-08-02 at 18:31 +0100, Mike Hearn wrote: >> Is it really that hard to check a digital signature? I'd have thought >> there'd be APIs in Python/C/Mono that make this trivial by now. And that's >> all you have to do to protect against the "files are changed by evil >> people" case. > > gpg has well documented exit codes which can be suitably used for this. > It's not high performance to invoke lots of sub-processes if you have a > lot of files you are verifying, but it get's the job done. Seahorse CVS HEAD contains a modification to how detached signatures are verified in nautilus. The new program is called seahorse-tool, moving the functionality out of seahorse proper. It could be modified if it doesn't already return adequate exit codes. It might also be possible to add a VerifyFile D-Bus method that takes a URL and a buffer containing the detached signature and returns a flag code. Adam - -- Why isn't all of your email protected? http://gnupg.org http://enigmail.mozdev.org http://seahorse.sourceforge.net http://live.gnome.org/Seahorse -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE0PLMjU1oaHEI4wgRArZLAKDae3gPeyZiWs9mbSjnkbLvqcyurACgzj0c PwzJT3hBr30gQjISpG54qmM= =p0i4 -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
On Wed, 2006-08-02 at 18:31 +0100, Mike Hearn wrote: > Is it really that hard to check a digital signature? I'd have thought > there'd be APIs in Python/C/Mono that make this trivial by now. And that's > all you have to do to protect against the "files are changed by evil > people" case. gpg has well documented exit codes which can be suitably used for this. It's not high performance to invoke lots of sub-processes if you have a lot of files you are verifying, but it get's the job done. signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
On Wed, 02 Aug 2006 10:45:23 +1000, Nigel Tao wrote: > This code > looked good at the time it was added to the master list, but in the > mean time, the domain registration for some.web.site expired and a > villian has picked it up, and now serves up evil spyware versions of > the extension to our poor user. Bad. Is it really that hard to check a digital signature? I'd have thought there'd be APIs in Python/C/Mono that make this trivial by now. And that's all you have to do to protect against the "files are changed by evil people" case. thanks -mike ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
On Tue, 2006-08-01 at 20:36 +0200, Isak Savo wrote: > As such, I don't really see why this thing would be impose any > security issues that didn't exist earlier. Lots of applications > already have a plug-in system, and to my knowledge, they also allow > extra plugins to be installed in $HOME (i.e. without root access). The > only thing that's changed is that it's suddenly possible to install > them without manually downloading and copying files to hidden > directories. Related to this is something I was thinking about last night: some of the plugin systems aren't very nice for administrators to control. I was planning to file some bugs (after checking all the current apps), but it's related to this discussion. It would probably be good for apps with plugin systems to have a "don't allow per-user plugins" gconf key, so sysadmins can prevent users from running random code, and only use the allowed ones. Some applications (e.g. Gedit 2.14) have a single big "enabled plugins" key, which doesn't (afaik) give any options between "no admin control" and "no user control". It might be better to have separate keys for each plugin, like "plugins/$PLUGINNAME/enabled", which would allow admins to disallow (or make manditory, I guess) individual plugins, which allowing users to control those left unspecified. Cheers, James "Doc" Livingston -- "type in (cast) must be scalar; ANSI 3.3.4; page 39, lines 10-11 (I know you don't care, I'm just trying to annoy you)" -- MPW C error message ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
On Wed, 2006-08-02 at 10:45 +1000, Nigel Tao wrote: > On 8/2/06, Shaun McCance <[EMAIL PROTECTED]> wrote: > > With an automated listy-clicky thing, you don't get to see > > explicit files, and you have no way of checking against a > > checksum or a digital signature. > > Yeah, an example: suppose there's a hypothetical > intended-for-use-for-five-years distro that shipped this listy-clicky > thing (without some means of verification). One day, years down the > track, some user goes through the GUI, and picks up the master list > from http://raphael.slinckx.net/deskbar/repository/deskbar-repository.xml > [1], which links to > http://some.web.site/my-awesome-deskbar-extension.tar.bz2. This code > looked good at the time it was added to the master list, but in the > mean time, the domain registration for some.web.site expired and a > villian has picked it up, and now serves up evil spyware versions of > the extension to our poor user. Bad. > > [1] Really, if NewStuffManager is to be part of GNOME, a stable > version of NewStuffManager should only point to a master list hosted > somewhere under gnome.org, I reckon. This is something else I meant to mention. Once that URL is in a stable shipping product, it can (and should) be considered a stable API. We can never remove that URL without breaking existing installations of Gnome. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
On 7/31/06, Steve Frécinaux <[EMAIL PROTECTED]> wrote: > Nigel Tao wrote: > >> > You mean running untrusted code from the Web? > >> > >> Nigel said it would be possible to secure it a bit using GPG keys. > >> Maybe this kind of signing should be made a requirement. > > > > Well, should signing be necessary and/or sufficient, and who makes > > that decision? > > I'm not really aware of the gpg stuff, but I've heard of debian > developpers signing packages this way, relying on the thrust level of > the key. Someone to confirm/say I'm a big liar ? I assume you mean trust level, but yes, you are correct. It is called Secure Apt and the details of it can be seen here: http://wiki.debian.org/SecureApt Corey ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
On 8/1/06, Vincent Untz <[EMAIL PROTECTED]> wrote: > Would waiting for the 2.18 release cycle be an issue for desbkar? I don't think that there's any issues, but we'll discuss this on deskbar-applet-list. If we do punt to 2.18, will we just rebadge the latest 2.14 as 2.16.0? Leave d-a 2.14 as 2.14, but as part of 2.16? And should we backport as little as possible [1] from HEAD? [1] Well, apart from unbreak-the-build things like the patch to play nice with evolution-data-server 2.16. On 8/2/06, Shaun McCance <[EMAIL PROTECTED]> wrote: > With an automated listy-clicky thing, you don't get to see > explicit files, and you have no way of checking against a > checksum or a digital signature. Yeah, an example: suppose there's a hypothetical intended-for-use-for-five-years distro that shipped this listy-clicky thing (without some means of verification). One day, years down the track, some user goes through the GUI, and picks up the master list from http://raphael.slinckx.net/deskbar/repository/deskbar-repository.xml [1], which links to http://some.web.site/my-awesome-deskbar-extension.tar.bz2. This code looked good at the time it was added to the master list, but in the mean time, the domain registration for some.web.site expired and a villian has picked it up, and now serves up evil spyware versions of the extension to our poor user. Bad. [1] Really, if NewStuffManager is to be part of GNOME, a stable version of NewStuffManager should only point to a master list hosted somewhere under gnome.org, I reckon. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
On Tue, 2006-08-01 at 20:36 +0200, Isak Savo wrote:
> 2006/8/1, Vincent Untz <[EMAIL PROTECTED]>:
> > Hi,
> >
> > Le mardi 01 août 2006, à 11:42, Nigel Tao a écrit :
> > > > > You mean running untrusted code from the Web?
> >
> > > > Nigel said it would be possible to secure it a bit using GPG keys.
> > > > Maybe this kind of signing should be made a requirement.
> > >
> > > Well, should signing be necessary and/or sufficient, and who makes
> > > that decision?
> >
> > Here's my opinion:
> [...]
> > + I wouldn't want to see this active until we have a proper way to make
> >this "secure".
> >
> > I'm no expert in security, so I can't help that much. Would waiting for
> > the 2.18 release cycle be an issue for desbkar? It could leave us time
> > to properly handle the security/trust issue and to make other modules
> > use this.
>
> If I get this right, the NewStuffManager thingly is just an easier way
> to download and install plugins ("new stuff"), right?
>
> As such, I don't really see why this thing would be impose any
> security issues that didn't exist earlier. Lots of applications
> already have a plug-in system, and to my knowledge, they also allow
> extra plugins to be installed in $HOME (i.e. without root access). The
> only thing that's changed is that it's suddenly possible to install
> them without manually downloading and copying files to hidden
> directories.
>
> If plugins are a security issue, then don't provide a plugin
> architecture. Don't rely on the fact that it's hard to install plugins
> as a way to ensure the user's system is secure[1]. Things like social
> engineering will breach that wall sooner or later anyway...
That's not exactly the issue people are worried about. When
the plugins are provided on the web, there are steps people
can take to ensure their integrity. I can provide checksums
of all my tarballs (as we do on ftp.gnome.org) and the person
downloading them can manually check those.
It certainly isn't elegant, but at least people can protect
themselves from man-in-the-middle attacks, even if it means
extra manual work.
With an automated listy-clicky thing, you don't get to see
explicit files, and you have no way of checking against a
checksum or a digital signature. (Also, checksums aren't
all that useful for protecting yourself, since if somebody
is sitting between you and the server feeding you different
data, he's presumably competent enough to feed you another
checksum.)
--
Shaun
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
2006/8/1, Vincent Untz <[EMAIL PROTECTED]>:
> Hi,
>
> Le mardi 01 août 2006, à 11:42, Nigel Tao a écrit :
> > > > You mean running untrusted code from the Web?
>
> > > Nigel said it would be possible to secure it a bit using GPG keys.
> > > Maybe this kind of signing should be made a requirement.
> >
> > Well, should signing be necessary and/or sufficient, and who makes
> > that decision?
>
> Here's my opinion:
[...]
> + I wouldn't want to see this active until we have a proper way to make
>this "secure".
>
> I'm no expert in security, so I can't help that much. Would waiting for
> the 2.18 release cycle be an issue for desbkar? It could leave us time
> to properly handle the security/trust issue and to make other modules
> use this.
If I get this right, the NewStuffManager thingly is just an easier way
to download and install plugins ("new stuff"), right?
As such, I don't really see why this thing would be impose any
security issues that didn't exist earlier. Lots of applications
already have a plug-in system, and to my knowledge, they also allow
extra plugins to be installed in $HOME (i.e. without root access). The
only thing that's changed is that it's suddenly possible to install
them without manually downloading and copying files to hidden
directories.
If plugins are a security issue, then don't provide a plugin
architecture. Don't rely on the fact that it's hard to install plugins
as a way to ensure the user's system is secure[1]. Things like social
engineering will breach that wall sooner or later anyway...
Thanks,
Isak
[1] http://en.wikipedia.org/wiki/Security_through_obscurity
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
On 01/08/06, Jamie McCracken <[EMAIL PROTECTED]> wrote: > Cant python be sandboxed? > > not sure if it helps in this case or not as I bet you want the python > code to have full access to the system. Not in the sense that javascript can be sandboxed. Some of the developers are looking at restricted execution again, but it isn't a feature you can rely on in the current releases. You can still sandbox a Python program in the same way you'd sandbox a C program, but those methods aren't really appropriate for in-process plugins. James. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
Hi, Le mardi 01 août 2006, à 11:42, Nigel Tao a écrit : > > > You mean running untrusted code from the Web? > > > > Nigel said it would be possible to secure it a bit using GPG keys. > > Maybe this kind of signing should be made a requirement. > > Well, should signing be necessary and/or sufficient, and who makes > that decision? Here's my opinion: + this is great stuff + this shouldn't be limited to deskbar, but this should really be a module we have in the desktop to make this possible for all modules that can make use of it + I wouldn't want to see this active until we have a proper way to make this "secure". I'm no expert in security, so I can't help that much. Would waiting for the 2.18 release cycle be an issue for desbkar? It could leave us time to properly handle the security/trust issue and to make other modules use this. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
Nigel Tao wrote: >>> You mean running untrusted code from the Web? >> Nigel said it would be possible to secure it a bit using GPG keys. >> Maybe this kind of signing should be made a requirement. > > Well, should signing be necessary and/or sufficient, and who makes > that decision? > ___ Cant python be sandboxed? not sure if it helps in this case or not as I bet you want the python code to have full access to the system. -- Mr Jamie McCracken http://jamiemcc.livejournal.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
Nigel Tao wrote: >> > You mean running untrusted code from the Web? >> >> Nigel said it would be possible to secure it a bit using GPG keys. >> Maybe this kind of signing should be made a requirement. > > Well, should signing be necessary and/or sufficient, and who makes > that decision? I'm not really aware of the gpg stuff, but I've heard of debian developpers signing packages this way, relying on the thrust level of the key. Someone to confirm/say I'm a big liar ? I don't know if it's really possible or secure, but what about rating the thrustfulness of a plugin based on the amount of gnome people that signed its key ? This is just an idea, maybe I'm on crack ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
> > You mean running untrusted code from the Web? > > Nigel said it would be possible to secure it a bit using GPG keys. > Maybe this kind of signing should be made a requirement. Well, should signing be necessary and/or sufficient, and who makes that decision? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
> Am I correct in assuming that NewStuffManager could also be used to install > Epiphany (Python-)Extensions without too much trouble? Yeah, I think so. deskbar-applet-list would know more details. :-) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
Wouter Bolsterlee wrote: > You mean running untrusted code from the Web? Nigel said it would be possible to secure it a bit using GPG keys. Maybe this kind of signing should be made a requirement. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
På Mon, Jul 31, 2006 at 01:04:36PM +, Reinout van Schouwen skrev: > On Mon, 31 Jul 2006 11:39:58 +1000, Nigel Tao wrote: > > Deskbar is already part of GNOME, as of 2.14. NewStuffManager is in > > the Deskbar 2.16 codebase, so if there are no actions to the contrary, > > then this will become part of GNOME 2.16. > Am I correct in assuming that NewStuffManager could also be used to install > Epiphany (Python-)Extensions without too much trouble? > > That would be a great boon to Epiphany users... :) You mean running untrusted code from the Web? mvrgr, Wouter -- :wq mail [EMAIL PROTECTED] web http://uwstopia.nl this is dangerous :: open up your head feel the shell shock -- prodigy signature.asc Description: Digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
Nigel, On Mon, 31 Jul 2006 11:39:58 +1000, Nigel Tao wrote: > Deskbar is already part of GNOME, as of 2.14. NewStuffManager is in > the Deskbar 2.16 codebase, so if there are no actions to the contrary, > then this will become part of GNOME 2.16. Am I correct in assuming that NewStuffManager could also be used to install Epiphany (Python-)Extensions without too much trouble? That would be a great boon to Epiphany users... :) regards, -- Reinout van Schouwen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
> > thingy people have implemented, aiming for the 2.16 release timeframe. > > So are you asking for official inclusion of this for 2.16? Deskbar is already part of GNOME, as of 2.14. NewStuffManager is in the Deskbar 2.16 codebase, so if there are no actions to the contrary, then this will become part of GNOME 2.16. However, since being told that things like new dependencies should be announced on desktop-devel-list, the existence (and implied blessing) of NewStuffManager should at least be announced on d-d-l. But also, arguably, this is a new dependency of sorts, even if developed under the Deskbar umbrella rather than as a separate package. And there are these two questions of security and privacy - so it's a little more complicated then applying s/elementtree/NewStuffManager/ on the statement "NOTE: deskbar-applet has a tiny new dependency called elementtree". So I wrote this long e-mail to d-d-l in anticipation that the GNOME community would want to discuss this before we release (deskbar-applet + NewStuffManager) as part of 2.16. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
On Mon, 2006-07-31 at 01:06 +1000, Nigel Tao wrote: > thingy people have implemented, aiming for the 2.16 release timeframe. So are you asking for official inclusion of this for 2.16? signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
OK, I should have brought this up on d-d-l a month or two ago, at
least before we got all freezy, but I procrastinated. Corner me
sometime and ask for my lame excuses. Anyway, going with better late
than never...
The text below is probably best read at my blog:
http://blogs.gnome.org/view/nigeltao/2006/07/30/0 where it has
new-fangled technologies like screenshots and links, but it's
copy'n'pasted here in case the nitpickers amongst you want to quote
stuff in any ensuing argument^Wdiscussion. 'cos it's not like d-d-l
hasn't been controversial enough in the last few weeks... :-)
Short version: There's this new easily-install-new-deskbar-plugins
thingy people have implemented, aiming for the 2.16 release timeframe.
However, it's, like, easily-download-executables-from-the-internet,
which I don't think GNOME has done before, and so the GNOME community
should have a say in whether or not we push ahead with this.
Long version (really, just go straight to
http://blogs.gnome.org/view/nigeltao/2006/07/30/0 )
One of the things about the 2.14 deskbar-applet release was that,
although it supported third-party plug-ins, the GUI to manage them was
all-but-nonexistant. Basically, whilst you could enable and disable
installed plug-ins via the checkboxes in the preferences dialog, you
couldn't (a) find and install new plug-ins, and (b) update existing
plugins through the GUI -- both of which Firefox lets you do, for
example. Instead, you had to download a file (or download and unpack a
tarball) and copy that to a secret directory
(~/.gnome2/deskbar-applet/handlers/) -- i.e. one that you couldn't
find in nautilus.
In the last few months, Sebastian Pölsterl and the other deskbar
hackers have worked on being able to install new plug-ins through a
friendly GUI. The deskbar-applet-list mailing list discussion starts
in April, continues in May and there's also the PluginManager wiki
page. Here's the current state of play (no, this isn't finalized, yes
there are issues, which I'll touch upon at the end of the tour). First
off, there's a new Check For Updates button on the list of installed
plug-ins.
Clicking on that invokes the NewStuffManager a new (Python) program
that communicates with deskbar-applet via D-Bus. To be precise,
NewStuffManager provides the org.gnome.NewStuffManager service.
NewStuffManager is not deskbar-applet specific, and could provide any
app with update info. The app-specific part is another Python file,
deskbar-applet's spec is the only instance so far, and looks like
this:
OPTIONS = {
"repo": "http://raphael.slinckx.net/deskbar/repository/deskbar-repository.xml";,
"install-path": "~/.gnome2/deskbar-applet/handlers",
}
And note that it mentions
http://raphael.slinckx.net/deskbar/repository/deskbar-repository.xml,
which is the master list of plug-ins and their versions. The intention
is that distros can customize this URL, if they choose to. An example
snippet of that XML file looks like this:
yahoo.py
Yahoo! Search
Search Yahoo! as you type
Deskbar Team <[EMAIL PROTECTED]>
3.1.1
http://raphael.slinckx.net/deskbar/repository/yahoo.py
NewStuffManager will note that there is a new version of the Yahoo
handler, and the UI will show that it is updatable.
Clicking on Update will show a progress dialog box, and under the
hood, download the newer yahoo.py from
http://raphael.slinckx.net/deskbar/repository/, unpack the archive (if
necessary), and copy those files to the right place in the file
system: ~/.gnome2/deskbar-applet/handlers/. Note that this is the
user's installed plug-ins, not the globally-shared (and
only-writable-by-root) plug-ins at /usr/lib/deskbar-applet/handlers.
The other thing to notice is the New Extensions tab. Switching to this
tab will invoke NewStuffManager to check the master list for
installable plug-ins. It looks like this:
Again, the Install button will download and install the plug-in. There
really isn't much difference between updating existing plug-ins and
installing new ones, apart from that the user was (probably) aware of
an existing plug-in beforehand, and updating an existing plug-in might
involve an active existing plug-in.
That's what it looks like. It is indeed easier to find and install
plug-ins than before. And plug-ins rock, since they make users go, "I
rock". However, there are two very significant issues:
Security: We will be downloading arbitrary Python files, which could
be executed whenever the deskbar-applet initializes all of its
plug-ins. This could be a major security hole. Personally, it's not
that I don't trust Raphael or his web-site, or the third party
websites that he chooses to endorse, but I don't trust (the worst of)
the internet. We don't have digital signatures or other verification
mechanisms implemented yet (and GNOME 2.16 is due only a few months
from now). Auto-update (and auto--removal of obsolete files) is
another issue that should be considered - whilst it is frustrating as
a developer that users don't manually upgrade to th
