RE: Disliking gnome 3
I, on the other hand, tried it repeatedly over a month and thought it was a pain in the neck and change with no benefit. Regards, Tim -Original Message- From: Adam Tauno Williams Sent: 31/08/2011, 3:01 AM To: gnome-shell-list@gnome.org Subject: Re: Disliking gnome 3 On Wed, 2011-08-31 at 04:35 +0400, Sergey Zolotorev wrote: Hello Just try to use G3 about month. =) I had HATE it about two month after release (I even think to move to Xfce or other DEs...), but after this I found proper custom workflow to use this version and now I enjoy G3. So it is not so horrible as it seems. =) Agree, I didn't try G3 for a long time, I looked at it an thought they've gone mad!. I was wrong; GNOME 3 is great. It is different, practices have to be changed. http://www.whitemiceconsulting.com/2011/05/fortnight-with-gnome3.html I thought I couldn't live without a task bar - I was wrong - the task-bar is *USELESS* *USELESS* *USELESS*. Oh, my goodness, what on earth was I using that thing for all those years? Anyone adding the task-bar back to GNOME3/Shell needs medical help. ___ 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
SweetTooth.
When is the SweetTooth extension manager expected to be ready? This will add *huge* benefits for Gnome 3 users. -= Joe Pea =- ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Alt+F2 doesn't find scripts in ~/bin
Am 30.08.2011 14:21, schrieb Rui Tiago Cação Matos: On 30 August 2011 04:34, Ralph Hofmannhofmann2...@arcor.de wrote: @gnome-shell developers: I think there should be a way to setup the PATH for alt+F2. It works for me. You can check the $PATH that gnome-shell sees with $ strings /proc/`pidof gnome-shell`/environ | grep PATH If what you want is not there you just have to find what session initialization scripts your distro runs and put it there. FWIW, on Fedora, I put that kind of stuff in ~/.bashrc. Rui I read a little bit about /proc. $ cat /proc/`pidof gnome-shell`/cmdline tells me, that /usr/bin/gnome-shell is the command, that I have to make take ~/bin into account? How??? ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Disliking gnome 3
Am 30.08.2011 20:45, schrieb Ben Greear: 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 I had removed the use of the traditional gnome panels in my Gnome2 setup. So Gnome3 is on the right track in my personal opinion. 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. Ralph ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Concerning the javascript code location and extensions
Hello everyone! At Nova we have a service we call Customized OS: on which we create a GNU/Linux Distro molded for specific customer's needs. As from the arrival of G3 we have started thinking on adding to this service a Customized Desktop Environment, since GShell loads arbitrary javascript code it shouldn't be so hard, but the thing is it loads the code from a specific location. I know the customization of G3 could (and should) be done at extensions level, but it doesn't feel right to do so in this particular case: we want to develop a customized Desktop Environment, not a GShell patched to look different, and we certainly would rather avoid renaming the libraries so GShell and whatever we call the new environments could coexist on the repository. This brings me to the question in question: is it (could it be) possible to specify as an argument to gnome-shell to state where should the javascript code be loaded from?? Best regards, and keep with the great work, -- Sw.E. D.H. Bahr Nova Desktop Development Leader CESOL (Free/Libre Software Centre) UCI (University of Informatics Sciences) Havana, Cuba ___ 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
On Wed, Aug 31, 2011 at 5:29 AM, D.H. Bahr db...@uci.cu wrote: ** Hello everyone! At Nova we have a service we call Customized OS: on which we create a GNU/Linux Distro molded for specific customer's needs. As from the arrival of G3 we have started thinking on adding to this service a Customized Desktop Environment, since GShell loads arbitrary javascript code it shouldn't be so hard, but the thing is it loads the code from a specific location. I know the customization of G3 could (and should) be done at extensions level, but it doesn't feel right to do so in this particular case: we want to develop a customized Desktop Environment, not a GShell patched to look different, and we certainly would rather avoid renaming the libraries so GShell and whatever we call the new environments could coexist on the repository. This brings me to the question in question: is it (could it be) possible to specify as an argument to gnome-shell to state where should the javascript code be loaded from?? There is, but it's considered for internal and development use only. In my opinion, the extensions system is the only supported way of modifying the Shell. Of course, distros are free to patch the code directly. May I ask what kinds of chnages you want to make to the Shell to give you the best solution? If there are specific thing you'd like the extensions system to do, I'd gladly help you along with that. Best regards, and keep with the great work, -- Sw.E. D.H. Bahr *Nova Desktop* Development Leader CESOL (*Free/Libre Software Centre*) UCI (*University of Informatics Sciences*) Havana, Cuba ___ 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
Re: Concerning the javascript code location and extensions
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. 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. Currently we are looking at the Shell more as a platform for Desktop Development than as a Desktop itself. Best regards, and thanks for caring about this, -- Sw.E. D.H. Bahr Nova Desktop Development Leader CESOL (Free/Libre Software Centre) UCI (University of Informatics Sciences) Havana, Cuba El Wed, 31-08-2011 a las 09:44 -0400, Jasper St. Pierre escribió: On Wed, Aug 31, 2011 at 5:29 AM, D.H. Bahr db...@uci.cu wrote: Hello everyone! At Nova we have a service we call Customized OS: on which we create a GNU/Linux Distro molded for specific customer's needs. As from the arrival of G3 we have started thinking on adding to this service a Customized Desktop Environment, since GShell loads arbitrary javascript code it shouldn't be so hard, but the thing is it loads the code from a specific location. I know the customization of G3 could (and should) be done at extensions level, but it doesn't feel right to do so in this particular case: we want to develop a customized Desktop Environment, not a GShell patched to look different, and we certainly would rather avoid renaming the libraries so GShell and whatever we call the new environments could coexist on the repository. This brings me to the question in question: is it (could it be) possible to specify as an argument to gnome-shell to state where should the javascript code be loaded from?? There is, but it's considered for internal and development use only. In my opinion, the extensions system is the only supported way of modifying the Shell. Of course, distros are free to patch the code directly. May I ask what kinds of chnages you want to make to the Shell to give you the best solution? If there are specific thing you'd like the extensions system to do, I'd gladly help you along with that. Best regards, and keep with the great work, ___ 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
I understand your goal, but the Shell isn't really designed as a platform for WMs: it's an extensible WM. I think that the approach of taking the parts of the shell that make sense, like gjs, mutter, clutter and st/mx and creating another WM may be the better approach. If you want to pretend that the Shell is a platform to hack on top of, you can use the JS files, but this is at your own caution. The environment variables, designed to make the developer's lives easier and may not do what you want, are listed in the gnome-shell-jhbuild.in wrapper script in the source tree. On Wed, Aug 31, 2011 at 10:01 AM, D.H. Bahr db...@uci.cu wrote: ** 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. 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. Currently we are looking at the Shell more as a platform for Desktop Development than as a Desktop itself. Best regards, and thanks for caring about this, -- Sw.E. D.H. Bahr *Nova Desktop* Development Leader CESOL (*Free/Libre Software Centre*) UCI (*University of Informatics Sciences*) Havana, Cuba El Wed, 31-08-2011 a las 09:44 -0400, Jasper St. Pierre escribió: On Wed, Aug 31, 2011 at 5:29 AM, D.H. Bahr db...@uci.cu wrote: Hello everyone! At Nova we have a service we call Customized OS: on which we create a GNU/Linux Distro molded for specific customer's needs. As from the arrival of G3 we have started thinking on adding to this service a Customized Desktop Environment, since GShell loads arbitrary javascript code it shouldn't be so hard, but the thing is it loads the code from a specific location. I know the customization of G3 could (and should) be done at extensions level, but it doesn't feel right to do so in this particular case: we want to develop a customized Desktop Environment, not a GShell patched to look different, and we certainly would rather avoid renaming the libraries so GShell and whatever we call the new environments could coexist on the repository. This brings me to the question in question: is it (could it be) possible to specify as an argument to gnome-shell to state where should the javascript code be loaded from?? There is, but it's considered for internal and development use only. In my opinion, the extensions system is the only supported way of modifying the Shell. Of course, distros are free to patch the code directly. May I ask what kinds of chnages you want to make to the Shell to give you the best solution? If there are specific thing you'd like the extensions system to do, I'd gladly help you along with that. Best regards, and keep with the great work, -- Jasper ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Disliking gnome 3
On 08/30/2011 03:36 PM, John Stowers wrote: Out of curiosity, are there any links to this? I'm curious to see how folks actually use the new features productively. The videos on gnome3.org might be a start, perhaps a little simple. Anyway, speaking to *my* own workflow, slightly adapted from defaults, an iterative merging of G2/compiz/mac/all my past computer experience. Here's a desktop capture..normally I'd have even more windows open, but just rebooted recently and haven't re-logged in to all of the test systems I will eventually be using. This is my home system too...monitor at work is a good big larger (23 inches, I think). http://www.candelatech.com/~greearb/misc/Screenshot.png I have several code editor windows open, some editing local java files, the other editing files on a 32-bit build machine over nfs over the VPN. We make a client/server app, so normal use is editing/compiling on two different machines, and testing on at least a third (and often multiple systems). We have a 64-bit build machine that I use a lot as well. The terminals are used for ssh access to the test and build systems for testing, looking at logs, compiling, etc. A local terminal runs our GUI and I watch it's output for logging, exceptions, etc. I often cut and paste between terminals, editors, etc. IRC always in bottom left, just enough visible to see if someone has written something with a glance. I don't use the Applications Places pulldowns often, but I find them way more useful than the non-fallback gnome-3 thing that hides all other work on the desktop while you are looking at huge icons. It's enough to make me forget why I was looking there in the first place. I dearly miss the G2 system monitor applet that showed network, cpu, swap load etc. That was a quick help in finding run-away programs eating all the cpu, or watching network activity to have an idea of how much our GUI was communicating with the server. I find the task bar vital to switching between the various terminals. I'll rename their title when I get too many and they get scrunched in tight. And I'll also drag them around so that similar things are close together. I don't reboot often...hopefully only every month or two at most. This isn't a laptop, and never hibernates. I use a single work-space. I tried multiple before, but it just never worked out for me. On gnome-2, I could load a system from bare metal and use it with zero tweaks to gnome, aside from dragging a Terminal icon into the top bar, maybe adding a few applets. Thanks, Ben -- Ben Greear gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
GNOME Shell 3.1.90.1
Basically a fix-up release for a couple of critical small issues found in 3.1.90; also includes new support for asynchronous search providers. About GNOME Shell = GNOME Shell provides core user interface functions for the GNOME 3 desktop, like switching to windows and launching applications. GNOME Shell takes advantage of the capabilities of modern graphics hardware and introduces innovative user interface concepts to provide a visually attractive and easy to use experience. Tarball releases are provided largely for distributions to build packages. If you are interested in building GNOME Shell from source, we would recommend building from version control using the build script described at: http://live.gnome.org/GnomeShell Not only will that give you the very latest version of this rapidly changing project, it will be much easier than get GNOME Shell and its dependencies to build from tarballs. News * Fix typo that was breaking the Login Screen mode [Marc-Antoine] * Fix build with new gobject-introspection [Dan] * Use a better icon for removable devices [Cosimo; #657757] * Add support for asynchronous search providers [Philippe, Jasper, Seif; #655220] * Misc bug fixes [Alex, Guillaume, Jasper; #657657, #657696] * Misc build fixes [Adel; #657697] Contributors: Cosimo Cecchi, Guillaume Desmottes, Adel Gadllah, Alexander Larsson, Seif Lotfy, Philippe Normand, Marc-Antoine Perennou, Jasper St. Pierre, Dan Winship Translations: Jorge González, Daniel Mustieles [es], Stas Solovey [ru] Download http://download.gnome.org/sources/gnome-shell/3.1/gnome-shell-3.1.90.1.tar.xz (1002K) sha256sum: 710d5aeb32a22b7ecf53c3a74ab1f12ada64428ec23ff68ba1c96fe7a7f0cb4e http://download.gnome.org/sources/gnome-shell/3.1/gnome-shell-3.1.90.1.tar.bz2 (1.13M) sha256sum: 74c086796c5a306939a9d778a0feec0fe041ce2443cdb833a8a1627944488e04 ___ 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 4:46 AM, Ralph Hofmann 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 ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Disliking gnome 3
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. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Disliking gnome 3
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 ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Disliking gnome 3
On 08/31/2011 11:46 AM, Jasper St. Pierre wrote: n Wed, Aug 31, 2011 at 2:27 PM, Pasha Rpashar...@gmail.com wrote: On Tue, Aug 30, 2011 at 9:45 PM, Ben Greeargree...@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. You can obviously support the older look, because it works in fallback mode. As long as that remains functional, folks such as myself can probably continue to use gnome3. If you want to optimize the non-fallback mode for laptops and touchpads and cloud stuff and whatnot, that's fine by me. Just keep the old look functional too. I'm sure the vast majority of the gnome code is common to those two modes, so you still get the benefit of scale and bug reports... Thanks, Ben -- Ben Greear gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Notes on extensions.gnome.org security
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 see what it does before they look at the code. It should not be possible for a user to install an unreviewed extension from the website simply by confirming a warning dialog. Another possibility would be a system-level exploit of extensions.gnome.org allowing modification of the code or uploaded extensions. Other the general security measures we take for all gnome.org servers, there are not a lot of things we can do about this, a few ideas: - Make sure that it's explicit to the user when updates to extensions or new extensions are being installed. This doesn't do much to directly protect the vast majority of users, but should allow quick detection of funny business by the community in general. - 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. Somewhat similarly, there is a danger if a user with commit access to gnome.org introduces code into the extensions.gnome.org website that then gets deployed on the server. Obviously, this is something we also need to deal with for commits to general GNOME code, but the ability to immediately get things installed on user's systems makes the window to detect problems shorter
Re: Disliking gnome 3
I use a single work-space. I tried multiple before, but it just never worked out for me. While you only use a single workspace G3 is going to be hard for you. On gnome-2, I could load a system from bare metal and use it with zero tweaks to gnome, aside from dragging a Terminal icon into the top bar, maybe adding a few applets. Out of interest, which applets? John Thanks, Ben ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Disliking gnome 3
On 08/31/2011 01:53 PM, John Stowers wrote: On gnome-2, I could load a system from bare metal and use it with zero tweaks to gnome, aside from dragging a Terminal icon into the top bar, maybe adding a few applets. Out of interest, which applets? system monitor. Evidently you can find the thing for G3 as well, I haven't tried yet...maybe it will be part of the default install soon... Ben John Thanks, Ben -- Ben Greear gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com ___ 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
(Just a few comments on what's currently implemented) Obviously, this website and its goals have some parallels with the Mozila Addons site. I have been talking to their engineers and we both decided that doing our own thing would be best for both of us. I have been talking to them about how AMO works internally: I have some similar engineering decisions here, and precedent is always nice. 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. 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. This is something important, but I probably won't have time to do this. I might just steal Review Board's MyersDiff Python implementation. - 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. Currently, an extension has to be owned by its creator, and only he/she can upload new versions. - Make it very difficult to install an unreviewed extension; it should not be easy for a reviewer to try out an extension to see what it does before they look at the code. It should not be possible for a user to install an unreviewed extension from the website simply by
Re: Disliking gnome 3
On Wed, Aug 31, 2011 at 4:53 PM, John Stowers john.stowers.li...@gmail.comwrote: I use a single work-space. I tried multiple before, but it just never worked out for me. While you only use a single workspace G3 is going to be hard for you. 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. Jesse ___ 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
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. 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 ? 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. Alan ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
