Re: Notes on extensions.gnome.org security
On 08/31/2011 11:16 PM, Jasper St. Pierre wrote: Right now you pass the plugin an URL to a manifest file, so it's not hardcoded to seek out the URL based on extensions.gnome.org. The idea here was that if we needed to offload the servers with the extension data to a CDN, we wouldn't have to make the users upgrade their distributions. It seems to me either you have to: a) limit extensions from downloading from a known encrypted source (extensions.gnome.org). This precludes putting parts of the extension on other locations like a CDN. b) cryptographically sign the extensions (and all data), this allows you to place the extension and its parts on CDNs. As Alan brought up, option b with keys not directly located on extensions.gnome.org also has a good security story when it comes to hacks on the web server. Cheers, Stef ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Notes on extensions.gnome.org security
I think sandboxinghttps://developer.mozilla.org/En/SpiderMonkey/JSAPI_User_Guide#Object-capabilities-based_securityis not the only option, Spidermonkey supports stack walkinghttps://developer.mozilla.org/En/SpiderMonkey/JSAPI_User_Guide#Fine-grained_security, so it would be possible to assign a set of permissions to each extension and enforce them at run-time. The same principle is used in Javahttp://www.cs.princeton.edu/sip/pub/oakland98.pdf, to allow applets to selectively access priviledged resources. It would of course take quite some work to maintain the permission sets (as is the case for SELinux). On the other hand, it would make the reviewers life a lot easier, as they can just read through the permission set and see if it contains anything bad/odd. If the extension would change its behavior once deployed, the stack traceing mechanism would block all bad/unexpected things. It would also take quite some work to design a good permission model: if you make it too fine grained, the permission sets become huge, if you make it too coarse, it is useless. But if security is really an issue, now is the time to implement it. On the other hand, I trust the crowd, if things go bad, someone will fix it, if not, I have the extensions source, so I can probably fix it myself,... Wouter On Wed, Aug 31, 2011 at 22:32, Owen Taylor otay...@redhat.com wrote: The idea of a GNOME Shell extension is to let the GNOME community build on top of the GNOME Shell code base, to tweak, to customize, and to prototype new GNOME features and behaviors. GNOME Shell extensions aren't sandboxed, and sandboxing them is fundamentally hard because shell extensions are defined as arbitrary tweaks to GNOME Shell. GNOME Shell is in the position to do such things as add global keybindings or read screen content, thus shell have the same capabilities. Of course, Linux users run unsandboxed code with arbitary capabilities every day - applications, for example. So the security question with GNOME Shell extensions is not how we can do the almost impossible job of sandboxing them, but how we can build up layers of social, user interface, and technical protections to make them not an attractive deployment mechanism for malware. For an average user, one of the most important thing that we can do is to make sure that it is actively hard to install extensions from untrusted sources. It shouldn't be possible to simply click on a web page link which downloads an extensions and then be prompted to install it. It's been well demonstrated that no form of confirmation dialog or warning text provides effective protection in such cases. By instead directing the user to extensions on extensions.gnome.org we achieve multiple things: we can have a review process for extensions, rankings and reviews will direct the user to heavily tested extensions and away from misbehaving extensions, we will make sure that we can update extensions, and even remove them if security problems pop up. The sweettooth plugin In general, having the interface to find and install extensions be a website is attractive: it is a very natural way to include social aspects like ratings and recommendations into the interface and allows the information/installation page for an extension to be directly linked to from an external web page. However, as noted above, simple approaches for installing extensions like a MIME-type handler can be dangerous since they could be used to provide a code download from an arbitrary location. The current approach taken is to provide a browser plugin that enforces an origin from extensions.gnome.org and provides the following methods to the website: listExtensions() getExtensionInfo() installExtension() setExtensionEnabled() getExtensionErrors() This allows embedding an interface for mananging extensions directly into the website. Threat model and mitigation === The basic danger that we want to avoid is that someone gets an extension installed onto their system that has malicious code in it. The most basic way that this would happen is that someone simply uploads an extension to the website that is malicious, and that it gets through the review process without anybody noticing. Mitigation: - Require code review for all updates of an extension not just the initial upload. - Provide clear code review guidelines, including that an extension with hard to understand or tricky code should be rejected. - Provide tools to let a reviewer see what has changed in an update of an extension to let them focus more attention on the changed part. - Use identity in the review process, so, e.g., it's very clear when an update to an extension is uploaded by someone other than the original author. - Make it very difficult to install an unreviewed extension; it should not be easy for a reviewer to try out an extension to
Re: Disliking gnome 3
Am 31.08.2011 20:03, schrieb Sriram Ramkrishna: On Wed, Aug 31, 2011 at 4:46 AM, Ralph Hofmann hofmann2...@arcor.de mailto:hofmann2...@arcor.de wrote: I like the idea of javascript based plugins like in Firefox. I think that could become the killer feature of Gnome3. Of course Gnome3 is far from ready now. But is has a lot of potential. Potential discoverable by the user. The killer feature is GObject and GObject introspection. We've had that for a number of years, but it is now front and center. sri Why GObject and GObject introspection? I look at it from a user's, you from a developer's perspective. Ralph ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Disliking gnome 3
On Thu, 2011-09-01 at 14:29 +0200, Ralph Hofmann wrote: Am 31.08.2011 20:03, schrieb Sriram Ramkrishna: The killer feature is GObject and GObject introspection. We've had that for a number of years, but it is now front and center. Why GObject and GObject introspection? I look at it from a user's, you from a developer's perspective. When you make things easier for developers, you pave the road for making things better for users. That's just how it flows. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Disliking gnome 3
On Wed, 2011-08-31 at 17:25 -0400, Jesse Hutton wrote: I thought this would naturally be the case, as well. However, I've recently read in #gnome-design two different *lead* designers claim to not use workspaces. Both instances were in the context of discussing issues people found, so maybe it these were off-hand comments as a basis to claim ignorance. Nonetheless, apparently you *don't* need to use workspaces to enjoy Gnome Shell. Certainly, and I don't see why Shell would be hard to use in a single workspace. When I'm out and about I typically use G3 in a single workspace, the improved window switching and activity overview makes many-windows-in-a-workspace much easier to use than under G2 ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Disliking gnome 3
Hiya, On G2 I almost always used 2 or 3 virtual desktops to keep tabs of everything, but with G3 I found that having more than 1 virtual desktop is difficult to keep tabs on if you'll excuse the pun.. instead it seems easier to use the alt tab for task switching, and the windows key to get to the application overview screen. The only frustration is that I cannot tell what I have running, other than what is onscreen, unless I go to the overview screen which means I am having to remember what I have running. In all other respects I am very happy with G3 now I have had time to really try it out.. the application search if using the windows key and first few char of app name is faster than the mouse based menu system G2 has, and G3 does seem to be at least as stable as G2 so yes, it *is* a work in progress but perfectly workable, with justy a few features missing, and far far more polished than the Unity interface. Regards Steve Sheldon Adam Tauno Williams awill...@whitemice.org 01/09/2011 13:52:15 On Wed, 2011-08-31 at 17:25 -0400, Jesse Hutton wrote: I thought this would naturally be the case, as well. However, I've recently read in #gnome-design two different *lead* designers claim to not use workspaces. Both instances were in the context of discussing issues people found, so maybe it these were off-hand comments as a basis to claim ignorance. Nonetheless, apparently you *don't* need to use workspaces to enjoy Gnome Shell. Certainly, and I don't see why Shell would be hard to use in a single workspace. When I'm out and about I typically use G3 in a single workspace, the improved window switching and activity overview makes many-windows-in-a-workspace much easier to use than under G2 ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list The information contained in this e-mail is privileged and confidential and is intended only for the use of the addressee. Unauthorised disclosure, copying or distribution of the contents is strictly prohibited. Please reply immediately if you receive this e-mail in error and then immediately delete it from your system. Photo-Me International does not authorise the creation of contracts on its behalf by e-mail. All attachments have been scanned for viruses using regularly updated programs. Photo-Me International cannot accept liability for any damage you incur as a result of virus infection. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Disliking gnome 3
I totally agree with you. Yes: G3 sets a new paradigm in User Experience, AND that's one of the great things about it. Of course it needs work, otherwise, as Jasper implied earlier, it would be perfect, and not being perfect (I've known little or no perfect thing in my lifetime) is fun for developers. Still, I think users with less reticence to change will find G3 as a great work on progress, perfectly usable for daily work. Those who find it annoying should simply switch to a different Desktop Environment (G2 or else). Best regards, -- Sw.E. D.H. Bahr Nova Desktop Development Leader CESOL (Free/Libre Software Centre) UCI (University of Informatics Sciences) Havana, Cuba El Thu, 01-09-2011 a las 14:12 +0100, Steve Sheldon escribió: Hiya, On G2 I almost always used 2 or 3 virtual desktops to keep tabs of everything, but with G3 I found that having more than 1 virtual desktop is difficult to keep tabs on if you'll excuse the pun.. instead it seems easier to use the alt tab for task switching, and the windows key to get to the application overview screen. The only frustration is that I cannot tell what I have running, other than what is onscreen, unless I go to the overview screen which means I am having to remember what I have running. In all other respects I am very happy with G3 now I have had time to really try it out.. the application search if using the windows key and first few char of app name is faster than the mouse based menu system G2 has, and G3 does seem to be at least as stable as G2 so yes, it *is* a work in progress but perfectly workable, with justy a few features missing, and far far more polished than the Unity interface. Regards Steve Sheldon Adam Tauno Williams awill...@whitemice.org 01/09/2011 13:52:15 On Wed, 2011-08-31 at 17:25 -0400, Jesse Hutton wrote: I thought this would naturally be the case, as well. However, I've recently read in #gnome-design two different *lead* designers claim to not use workspaces. Both instances were in the context of discussing issues people found, so maybe it these were off-hand comments as a basis to claim ignorance. Nonetheless, apparently you *don't* need to use workspaces to enjoy Gnome Shell. Certainly, and I don't see why Shell would be hard to use in a single workspace. When I'm out and about I typically use G3 in a single workspace, the improved window switching and activity overview makes many-windows-in-a-workspace much easier to use than under G2 ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list The information contained in this e-mail is privileged and confidential and is intended only for the use of the addressee. Unauthorised disclosure, copying or distribution of the contents is strictly prohibited. Please reply immediately if you receive this e-mail in error and then immediately delete it from your system. Photo-Me International does not authorise the creation of contracts on its behalf by e-mail. All attachments have been scanned for viruses using regularly updated programs. Photo-Me International cannot accept liability for any damage you incur as a result of virus infection. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Disliking gnome 3
On Thu, Sep 1, 2011 at 5:29 AM, Ralph Hofmann hofmann2...@arcor.de wrote: Am 31.08.2011 20:03, schrieb Sriram Ramkrishna: On Wed, Aug 31, 2011 at 4:46 AM, Ralph Hofmann hofmann2...@arcor.dewrote: I like the idea of javascript based plugins like in Firefox. I think that could become the killer feature of Gnome3. Of course Gnome3 is far from ready now. But is has a lot of potential. Potential discoverable by the user. The killer feature is GObject and GObject introspection. We've had that for a number of years, but it is now front and center. sri Why GObject and GObject introspection? I look at it from a user's, you from a developer's perspective. Well, plugin development is a developer feature that translates to cool plugins for users. But GObject provides the mechanism for that plugin development. If you have a library written in GObject it will be accessible from the extensions system. sri ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Disliking gnome 3
On Wed, Aug 31, 2011 at 9:46 PM, Jasper St. Pierre jstpie...@mecheye.net wrote: n Wed, Aug 31, 2011 at 2:27 PM, Pasha R pashar...@gmail.com wrote: On Tue, Aug 30, 2011 at 9:45 PM, Ben Greear gree...@candelatech.com wrote: I couldn't find a better place to voice my displeasure of Gnome 3, so I'm posting here. I really just want gnome-2 back. Fallback mode sort of works, but its still not as good as gnome 2 was. I do work on my computer, not just open one or two windows and browse the web. I want one-click to open new Terminals. I want to drag the Terminal icon into the top task bar to accomplish that. Right-click should work without having to press Alt. I want the bottom task dock or whatever it's called so I can easily select from the multitude of windows I have on my desktop. Please have a one-click (or very few clicks) option to get the old gnome-2 interface back. If you want to have a new way of doing things, that's fine too, but please don't break the old ways of doing things so badly. I'm downgrading to Fedora 14 for now..hope things clear up by F16 or F17. Thanks, Ben Welcome to the club. But, IMHO, complaining here won't help - developers repeatedly stated that they won't change anything, and probably will make things even worse. I'm staying with F14 while it is supported and looking at KDE and XFCE as a possible future replacement. If you find that GNOME3 doesn't work for you, feel free to change to another desktop environment. No offence taken. It's not for everyone, and GNOME 3.0 was a bit unstable and buggy. If it was perfect, I'd be out of a job :). We're making changes every day, hopefully to be a bit better. A somewhat overarching theme of GNOME 3.2, and GNOME3 in general is to recognize how online services influence how people use computers and provide conveniently integration with IM, email, and for now, Google Documents. Some might feel a bit offended or scared of better online integration. If you are, feel free to change to another desktop environment. And we are sort of venturing into the unexplored here for a desktop environment, and we may not make the best choices all the time, and we're not going to be perfect from day one. (I'm using the we pronoun to conveniently refer to the GNOME desktop environment and its developers, but this is my opinion) (and a PSA: if you have any specific doesn't work complaints: crashes, slow, instability, something happened that you have reasonable belief to expect wasn't normal, please file bugs: I get frustrated when someone points out a bug on reddit or on a blog, and I've never seen it reported, even though it's a bug that we probably would have fixed.) ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list -- Jasper No, my problem is not limited to bugs, that wouldn't stop me from using GNOME :) My problem is that shell is simply inconvenient to use and insulting attitude of developers that think that they know better what I should or shouldn't want to do with my computer. Extensions, at least in their current state, resolve my usability problems very poorly. With a lot of effort of hunting extensions all over the internet, I regain small part of the functionality I could setup with few mouse clicks with G2. The almost mindless action of launching new application now became a full-scale activity, and going there actually distracts me from my work. The list can go on and on, and in general, I think Linus summed it all up very well. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Notes on extensions.gnome.org security
On Wed, 2011-08-31 at 17:16 -0400, Jasper St. Pierre wrote: [...] On Wed, Aug 31, 2011 at 4:32 PM, Owen Taylor otay...@redhat.com wrote: The idea of a GNOME Shell extension is to let the GNOME community build on top of the GNOME Shell code base, to tweak, to customize, and to prototype new GNOME features and behaviors. GNOME Shell extensions aren't sandboxed, and sandboxing them is fundamentally hard because shell extensions are defined as arbitrary tweaks to GNOME Shell. GNOME Shell is in the position to do such things as add global keybindings or read screen content, thus shell have the same capabilities. I think that there should at least be some attempt to try and do limited, but important sandboxing like you cannot write to any files except in storage that the extension system has allocated for you, you are not allowed to spawn any applications, you are not allowed to open any sockets or you are not allowed to make gsettings tweaks except out of the schemas that I give you. Unfortunately, I doubt this is possible with the current state of gjs/gobject-introspection, but I think it's worth investigating. I'm not all that optimistic about this - on one hand, extensions do need to be able to do dangerous things - I'd consider an extension that modified or replaced the onscreen keyboard legitimate - and once you can act as the onscreen keyboard, you can type arbitrary stuff into a terminal. And on the other hand, the GNOME API's aren't designed to be protected against users with bad intent. E.g., in GTK+ if you change the widget hierarchy out of a ::paint signal, you'll crash GTK+. So I think it would be hard to make a truly bulletproof system - Java was designed for this from the start and there are still problems popping up. The one thing you might be able to achieve this way would be to make ill-intentioned extensions more obvious in code review; it might be worth exploring in this direction, but I don't see it as being an alternative to review of extension code. - Add some capability for self-healing to the extension update mechanism. There's not much we can do if an extension once run installs a back-door on the user's system, but we should be able to remove known bad extensions through the update process, even if the extension doesn't have proper update metadata. I'm unsure about this -- I don't think that an update or blacklist mechanism should touch anything that the user or a system administrator installed themselves. Of course, if we try to record which extensions got installed through the website, even with just a simple I like the simplicity of saying I have alternative-alt-tab 0.4 is there an update?, rather than having the possibility that you might have that extension installed, but from a different location, or with something funny in its metadata file. That would only apply to extensions installed in the user's directory, not systemwide, presumably. I don't feel strongly here, but I'd certainly vote in favor of simplicity and centralization. [..] If all that the plugin can do is say install plugin GUID x-y-z, whch that then triggers a download from https://extensions.gnome.org and shows a dialog, then any exploits along this line should at least be detectable to moderately sophisticated users, who will hopefully then report them so they can be fixed. Right now you pass the plugin an URL to a manifest file, so it's not hardcoded to seek out the URL based on extensions.gnome.org. The idea here was that if we needed to offload the servers with the extension data to a CDN, we wouldn't have to make the users upgrade their distributions. A hard requirement for me is that a HTML-injection problem on extensions.gnome.org can't make the plugin download and install random code from a random site. The two ways I can think of to address this are: A) Make the plugin only tell the downloader what to download and not to download it from. B) Sign extension dowloads with a gnome.org private key. A) is considerably simpler. B) offers some more flexibility. (You can still handle offload in the A) case by doing redirects.) - Owen ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Notes on extensions.gnome.org security
A) Make the plugin only tell the downloader what to download and not to download it from. You still need a key - even if the https:// authentication for gnome.org itself to prove the connection is to the correct site. B) Sign extension dowloads with a gnome.org private key. A) is considerably simpler. B) offers some more flexibility. (You can still handle offload in the A) case by doing redirects.) Another way to address B is to sign an index of locations of and hashes for the extensions rather than signing each extension individually. Might be easier to operate but with B you could use a heirarchy of keys (gnome-signer) which would let the installer see who (one or many) signed the package having reviewed it, and also allow revocations. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Disliking gnome 3
On Thu, 2011-09-01 at 18:16 +0300, Pasha R wrote: My problem is that shell is simply inconvenient to use and insulting attitude of developers I don't feel insulted at all. that think that they know better what I should or shouldn't want to do with my computer. This is *always* true; they have a vision and a goal. Good for them. small part of the functionality I could setup with few mouse clicks with G2. Such as? The almost mindless action of launching new application now became a full-scale activity, and going there actually distracts me from my work. Really? Meta,g,e,enter ... and there is gedit. I have no idea how that is distracting. The list can go on and on, and in general, I think Linus summed it all up very well. Ow, playing the Linus card. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Notes on extensions.gnome.org security
On Wed, 2011-08-31 at 22:35 +0100, Alan Cox wrote: Of course, Linux users run unsandboxed code with arbitary capabilities every day - applications, for example. So the security question with GNOME Shell extensions is not how we can do the almost impossible job of sandboxing them, but how we can build up layers of social, user interface, and technical protections to make them not an attractive deployment mechanism for malware. I would say the question is both that and how you sandbox them to some extent in the same way as you sandbox apps with SELinux. That requires sensible architecture decisions about isolation. An extension that wants to look at my ssh keys for example is detectable as anomalous behaviour. - Don't have automatic deployment for extensions.gnome.org changes but make it a manual process. - Restrict the set of users who can commit to the extensions.gnome.org code module. - Sign 'approved' extensions with keys which are not kept on a public system. Yes. In theory signatures can offer a layer of security that is independent of the security of the hosting of extensions. It's hard for me to wrap my head around a way to make that practical, if we want to be able to review and approve extensions through the web UI. Schemes I can come up end up with end up with something like: - Reviewers download and review extensions locally, then sign them with their GPG key. - An adminstrator takes the signed extensions, checks the reviewers signature and then adds the official GNOME signature. That would be very secure, but it also creates manual steps and points of failure that would likely make the system just not work in practice. We shouldn't forget either that our opinion about whether an extension is safe can change over time. A signature only means that that exact code base passed review at one point in time. But we later could discover problems with it. Another reason I tend to like centralization rather than only relying on embedded signatures. If all that the plugin can do is say install plugin GUID x-y-z, whch that then triggers a download from https://extensions.gnome.org and shows a dialog, then any exploits along this line should at least be detectable to moderately sophisticated users, who will hopefully then report them so they can be fixed. Are the existing mime type and helpers not sufficient ? In terms of these security goals, I think the mime type system could be adapted - that is, we could define a mime type text/x-gnome-shell-extensions-install-manifest, and when you clicked on it, the right things happen. The plugin mostly is about improving the UI beyond that - being able to mark extensions you alread have installed, be able to disable them from the web, etc. However, this does not correspond to our overall goals for extensions: we want a very clear distinction between extensions and applications, we want extension installation to be under the control of the user and not the system builder, and we want to encourage a community of extension creation that doesn't involve an extra layer of distribution specific packaging. In which case you probably do also want a system wide ability to turn off users adding extensons, especially unsigned ones, for business environments. It should be already possible to lock down the enabled-extensions gsettings, so the main thing would be adapting the UI to make it clear to the user that it was the case. - Owen ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Disliking gnome 3
On Thu, Sep 1, 2011 at 9:16 PM, Adam Tauno Williams awill...@whitemice.org wrote: On Thu, 2011-09-01 at 18:16 +0300, Pasha R wrote: My problem is that shell is simply inconvenient to use and insulting attitude of developers I don't feel insulted at all. Good for you. I find an attitude commonly expressed on this and some other lists we know better what you should want insulting. that think that they know better what I should or shouldn't want to do with my computer. This is *always* true; they have a vision and a goal. Good for them. It would be good for them if they did it for themselves. But they supposed to do it for other users, too, and failing to acknowledge that there are many different types of users with different needs and different personal preferences is one of the reasons people running away from G3. small part of the functionality I could setup with few mouse clicks with G2. Such as? Such as applets, custom shortcuts on panel, screensaver etc. The almost mindless action of launching new application now became a full-scale activity, and going there actually distracts me from my work. Really? Meta,g,e,enter ... and there is gedit. I have no idea how that is distracting. Well, I prefer to do these thing with mouse, and not with keyboard. Also, overview moves me to totally different view, which is distracting. The list can go on and on, and in general, I think Linus summed it all up very well. Ow, playing the Linus card. It has nothing to do with Linus card. If you really want, you can look in this list and fedora list archives what I said about G3 when F15 came out. It was way before Linus expressed his opinion. But since his view of subject is mostly similar to mine and well written I save my time and few electrons and refer to his opinion instead of repeating it in different words. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Notes looking at sweettooth-plugin
Some review comments reading the code to sweettooth-plugin: * I don't see any reason that this shouldn't just live in the gnome-shell tree - that would at least reduce the problem of the plugin and gnome-shell having incompatible versions. It would also avoid having packages with the sweettooth-plugin name; it's fine if the code deployed on extensions.gnome.org has a funky codename, but I don't want people listing software on a computer to have to know what sweettooth-plugin is. (Distributions can still have a gnome-shell-browser-plugin sub-package if they choose.) I think we would just stick npapi.h into the gnome-shell tree to avoid sticky build-time dependencies. * The 'funcs' variable should be static. * We should require the origin to be https://extensions.gnome.org * The origin checking code, as far as I can see, will consider http://extensions.gnome.org.mysite.com to be valid. It would be best if we can actually use an established URI parser to parse the URL. Could just link to libsoup and use soup-uri. * For extra safety, check that the null-terminated length of document.location.href matches the length in the NPString. * You should be checking the return value of funcs.getvalue, funcs.getproperty. I also think it's better not to g_assert() when checking for the right types, just fail cleanly. * It seems like there should be a callback if the shell restarts while the plugin is running to allow the webpage to react/restart. * The handling of G_DBUS_ERROR_NAME_HAS_NO_OWNER in NPP_New is leaky and not as intended. * Might be good to have a uuid-validation function that validates to characters that should be in a uuid and call that on all uuids. I don't see anything in the shell code that would obviously have problems with a uuid like '../../foo' but better to catch such things upfront. * I don't particularly like the use of g_return_if_fail() for checking for invalid plugin API use. While I think we can be confident that nobody is going to compile the plugin with -DG_DISABLE_ASSERT, g_return_if_fail() is stylistically supposed to be a debugging aid and not a reliable check. * plugin_object_get_property() doesn't properly propagate back errors from plugin_get_api_version/plugin_get_shell_version ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Concerning the javascript code location and extensions
Le mercredi 31 août 2011 à 10:01 -0400, D.H. Bahr a écrit : We would use this for changing the Information Architecture of the shell itself. Allow me to explain myself: our biggest client is the Public Sector which is instructed to migrate from privative to free software thus becoming our goal to provide a system that facilitates this process. That is why the previous versions of our system (Nova GNU/Linux) have a Windows-like look. For our next version, planned for release on February 2013, we would like to modify the shell so it looks as Windows-like as possible, but without removing the possibility of trying the shell itself as a GDM session. In short we need two separates GDM sessions: one for the original shell and another one for our Windows-like one. I'd rather keep your current Windows-like desktop as the default session, and provide the original GNOME Shell as an option in GDM. Transforming the Shell into a Windows desktop isn't going to be easy, as they are quite different. We are also concerned that the inclusion of many extensions might lower the overall system performance, since it is more javascript code that will be loaded. I don't think adding a few JS files would affect the performance, since the Shell already contains quite a few of them anyways. Currently we are looking at the Shell more as a platform for Desktop Development than as a Desktop itself. What Jasper said, but it doesn't quite make sense to me to rewrite something looking like Windows from the GNOME3 development platform... What would the advantages be, compared with your current implementation ? Regards ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Notes looking at sweettooth-plugin
On Thu, Sep 1, 2011 at 3:36 PM, Owen Taylor otay...@redhat.com wrote: Some review comments reading the code to sweettooth-plugin: * I don't see any reason that this shouldn't just live in the gnome-shell tree - that would at least reduce the problem of the plugin and gnome-shell having incompatible versions. It would also avoid having packages with the sweettooth-plugin name; it's fine if the code deployed on extensions.gnome.org has a funky codename, but I don't want people listing software on a computer to have to know what sweettooth-plugin is. (Distributions can still have a gnome-shell-browser-plugin sub-package if they choose.) Should I file a bug for gnome-shell? I think we would just stick npapi.h into the gnome-shell tree to avoid sticky build-time dependencies. Done. * The 'funcs' variable should be static. Done. * We should require the origin to be https://extensions.gnome.org I created a separate #define for it: ALLOW_INSECURE_HTTP. * The origin checking code, as far as I can see, will consider http://extensions.gnome.org.mysite.com to be valid. It would be best if we can actually use an established URI parser to parse the URL. Could just link to libsoup and use soup-uri. I chose to use the two properties window.location.hostname and window.location.protocol instead. * For extra safety, check that the null-terminated length of document.location.href matches the length in the NPString. Done. * You should be checking the return value of funcs.getvalue, funcs.getproperty. I also think it's better not to g_assert() when checking for the right types, just fail cleanly. Done. * It seems like there should be a callback if the shell restarts while the plugin is running to allow the webpage to react/restart. Do you mean what happens if the DBus name is lost? Relatively easy to do... (thanks davidz for gdbus!) * The handling of G_DBUS_ERROR_NAME_HAS_NO_OWNER in NPP_New is leaky and not as intended. I'm not sure exactly what you meant here, so... * Might be good to have a uuid-validation function that validates to characters that should be in a uuid and call that on all uuids. I don't see anything in the shell code that would obviously have problems with a uuid like '../../foo' but better to catch such things upfront. Done. , , , / and \\ are now considered invalid characters in a UUID. Besides that, they are required to be valid ASCII printable characters, ranging from 32-126 inclusive. * I don't particularly like the use of g_return_if_fail() for checking for invalid plugin API use. While I think we can be confident that nobody is going to compile the plugin with -DG_DISABLE_ASSERT, g_return_if_fail() is stylistically supposed to be a debugging aid and not a reliable check. I've replaced them with regular returns. * plugin_object_get_property() doesn't properly propagate back errors from plugin_get_api_version/plugin_get_shell_version Fixed. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list -- Jasper ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
