Re: Extensions review
On dim, 2014-05-25 at 21:55 -0500, Michael Catanzaro wrote: Boxes before 3.12 was never able to virtualize GNOME on my machine, no matter what the host or guest distro. [1] I think I have more serious problems. On previous Ubuntu versions, I could only get a Windows 8 ISO to work, no Linux distro would work. Zeeshan looked at it (at GUADEC), and was unable to work out the issue, and now the program just crashes immediately. signature.asc Description: This is a digitally signed message part ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Extensions review
On Mon, May 26, 2014 at 9:01 AM, Dodier-Lazaro, Steve s.dodier-lazaro...@ucl.ac.uk wrote: You're right, Carlos. In an environment where all apps are contained, Shell extensions would be a very very neat entry point for malware. Jasper probably is the authority on this but I have serious doubts that anything can be done to secure Shell extensions. From the fact that extensions shouldn't do sync I/O, I understand that their code runs in the same thread(s) as the rest of the shell. Yes that how extensions work they change any part of the shell's ui code through monkey patching, there isn't any much of a defined api. This effectively prevents making only the extensions' API's memory pages executable to extension-running threads, for instance. No you can't do that. It also doesn't make sense to sandbox something which is expected to have such a central access to your system. That's correct. In other words, extension code is very dangerous and reviews should be very thorough. The problem is when it comes to security, an extension won't be bad because it looks bad or code like myVariable = allUserData; update_to_evil_website(myVariable). It'll be funky pointer arithmetic and variable contents that nobody really understands, Well you can't really do pointer arithmetic in JS but any obfuscated code or code that the reviewer does not understand should not pass review. or shellcodes hidden inside an alleged Web API's application key, etc. It'll be subtle and you'll probably need to be very good at JS, know GJS very well and have good security credentials to spot it. Then beyond exploits within the code (of various degrees of clarity), you should look out for any processing of untrusted data: app windows, documents, absolutely anything coming from the Internet without authentication on an encrypted channel. How does it interact with the program? Are you absolutely certain that there is no bug or no quirky operation that could result in e.g. buffer overflows, strange operations on potentially-shellcode-containing variables, etc.? You cannot be absolutely certain that the code does not trigger a buffer overflow (or jump to an arbitrary heap address or whatever) you cannot prove security for non trivial cases you can only prove non security. Also why would you try to run shell code if you can simply eval() a JS string that you get from somewhere ... would be way easier. But anyway hidding in an extension in a way to not get noticed by a reviewer (i.e it has to look like legit code that does something useful) is not as trivial as you might think. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
RE: Extensions review
Hi, [...] You cannot be absolutely certain that the code does not trigger a buffer overflow (or jump to an arbitrary heap address or whatever) you cannot prove security for non trivial cases you can only prove non security. Well, I really don't know JS. I'm not sure exactly what you mean by non-trivial, surely it's hard to prove non-trivial properties such as program termination in a general way, but we could already specify a bit what it is that extensions are: - code written in the JavaScript language (obviously) - non-deterministic code, or is it?* Really, I can't stress how I don't know enough of JS to give any useful pointers, but I'm aware that there are a number of subsets to the language on which people can run verifiers. So surely there are certain security properties that can be proved on certain JS programs. I'd intuitively state that simple properties like non-interference (but between what and what? :) ) could be sometimes proved on some extensions. Maybe what subset of the Shell is exposed to clients and what subsets of JS are implemented in GJS can play a role for directed static analysis. Where it really hurts is that each extension is unique, and you may want to prove different things in each of them; and of course the proof is only valid modulo bugs in GJS. You could reframe or instrument the Shell to allow for some analysis methods, but you'd still need reviewers who took a language-based security/program analysis class to know what to do with the tools! * how are threads created? can extensions make threads? if so, what for? basic map-reduce like parallelism, or do they e.g. treat multiple clients depending on the order in which they reach a shared resource? do they actually have a non-deterministic behaviour or merely a non-deterministic implementation? Some people also manage to prove things on some non-det programs. Also why would you try to run shell code if you can simply eval() a JS string that you get from somewhere ... would be way easier. eval() might be a bit obvious :) Even I know that! I had in mind typing my previous email the charming people who write advanced persistent threat malwares. Shell extensions really have all the properties you'd expect from a backdoor, so they shouldn't be treated lightly... It's great that you have a code review in place, something which probably does not happen with many FOSS projects -- and that's what brings me to commenting on it in the first place: what can you improve to make sure that it delivers as much as you'd expect? But anyway hidding in an extension in a way to not get noticed by a reviewer (i.e it has to look like legit code that does something useful) is not as trivial as you might think. It's certainly not trivial for me :) -- Steve Dodier-Lazaro PhD student in Information Security University College London Dept. of Computer Science Malet Place Engineering, 6.07 Gower Street, London WC1E 6BT OpenPGP : 1B6B1670 ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Extensions review
On Sat, May 24, 2014 at 10:14 AM, Carlos Soriano Sánchez carlos.sorian...@gmail.com wrote: Sriram, Still, that's more work for developers, who already seems to be working on something else more important upstream. At the end, what we need is someone to go trough commits and make a list of important changes before a release. Not sure who be willing to do so, although Drago did it last release, I don't know how time consuming was to do it. Is this actually something that can be achieved for all extension developers? The way it can hack into the code surely means that any change could break an extension. For example, my extension, when updating to a new version, I've had most of the shell overlay change out from under me, and it took me days or weeks to hack back in to the new code to get my extension running. Another time, my extension only broke due to a single attribute in the shell being renamed to not have a preceding '_'. I've also had to copy and paste several full functions from the shell code so that I can change a line or add a couple of other lines, so if any of these functions change, I need to copy the new version. Maybe this is not the type of extension that is targeted by this effort, would these changes likely help other extension developers? signature.asc Description: This is a digitally signed message part ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Extensions review
Hi, With the mission of make review of extension simpler, I wrote some guidelines to accept or not an extension. My intention is also to allow less on extensions, going forward to more security and privacy, making the review work simpler and the extension ecosystem less messed. If we can agree on something like that, we will do this work more simple, so more community people can get in. Please give me feedback on that. It's just a draft to do the first step forward on that. So we can add, remove or modify those. https://wiki.gnome.org/CarlosSoriano/ExtensionsGuidelines Thanks! 2014-05-25 19:24 GMT+02:00 Sriram Ramkrishna s...@ramkrishna.me: On Sun, May 25, 2014 at 6:34 AM, Sam Bull sam.hack...@sent.com wrote: On Sat, May 24, 2014 at 10:14 AM, Carlos Soriano Sánchez carlos.sorian...@gmail.com wrote: Sriram, Still, that's more work for developers, who already seems to be working on something else more important upstream. At the end, what we need is someone to go trough commits and make a list of important changes before a release. Not sure who be willing to do so, although Drago did it last release, I don't know how time consuming was to do it. Is this actually something that can be achieved for all extension developers? The way it can hack into the code surely means that any change could break an extension. For example, my extension, when updating to a new version, I've had most of the shell overlay change out from under me, and it took me days or weeks to hack back in to the new code to get my extension running. Another time, my extension only broke due to a single attribute in the shell being renamed to not have a preceding '_'. It would be great to see shell interfaces stabilize, but I'm not sure if it will or not. As long as we continue to evolve the shell, I expect some breakages. Doing the exercise at least we know if the breakages are going up or down. If we have a downward trend then that would be awesome to know. :) Maybe this is not the type of extension that is targeted by this effort, would these changes likely help other extension developers? Well, I think it will, certainly if you know things like an attribute changing that would be good to know, right? sri ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Extensions review
On Sun, May 25, 2014 at 9:52 PM, Carlos Soriano Sánchez carlos.sorian...@gmail.com wrote: Hi, With the mission of make review of extension simpler, I wrote some guidelines to accept or not an extension. My intention is also to allow less on extensions, going forward to more security and privacy, making the review work simpler and the extension ecosystem less messed. If we can agree on something like that, we will do this work more simple, so more community people can get in. Please give me feedback on that. It's just a draft to do the first step forward on that. So we can add, remove or modify those. https://wiki.gnome.org/CarlosSoriano/ExtensionsGuidelines Thanks! 1) GTK: You can't really use GTK inside an extension other then for extension preferences (which is a valid case) 2) Duplicates: Yeah forgot to tell you about that in the last mail while doing a review check for dupes and if there is one don't approve it either get both authors to work together or if one gets abounded let the new user become the owner (i.e send mail wait two weeks if he does not respond transfer ownership). 3) Should probably add that sync I/O should be avoided because it blocks the whole compositor process. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Extensions review
This was more of a problem for the tens of put ___ in the top bar!! extensions we used to get, and several extensions that let you change the Activities text. For more complex widgets like docks, bottom panels, I'm fine with duplicates on the site. On Sun, May 25, 2014 at 4:23 PM, Sriram Ramkrishna s...@ramkrishna.mewrote: On Sun, May 25, 2014 at 12:57 PM, drago01 drag...@gmail.com wrote: 2) Duplicates: Yeah forgot to tell you about that in the last mail while doing a review check for dupes and if there is one don't approve it either get both authors to work together or if one gets abounded let the new user become the owner (i.e send mail wait two weeks if he does not respond transfer ownership). That would eliminate a lot of the dock extensions, no? We'll need to let people who such extensions explain what is different about the way they solve a dock as opposed to someone else. (applicable to any other duplicate extension as well) ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list -- Jasper ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Extensions review
On dim, 2014-05-25 at 10:24 -0700, Sriram Ramkrishna wrote: If we have a downward trend then that would be awesome to know. :) Well, for the record, it seems that my extension is working in 3.12 with no changes, which is a first. I've not been able to get 3.12 running on my system yet, but I started guiding a user through porting it, who is using 3.12, and it turned out that just updating the version number was enough. signature.asc Description: This is a digitally signed message part ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Extensions review
Hi, Jasper, what we should look at extensions to allow them in? If it is only to see if something is malicious and the connect, disconnect signals, maybe I can spare some time. I'm not that interested in extensions tbh, so I would willing to review currents ones to give feedback to that users that were not aware of Jasper not having time anymore. But I would put a warning in the website from now on, telling that we will no longer provide that service, if it is our intention. If our intention is to keep that service, I will put a warning anyway, telling that developers are needed to continue providing the service, requiring some background on upstream, like some patches or so. Maybe we have an opportunity here to bring some upstream developers too. 2014-05-24 0:28 GMT+02:00 Sam Bull sam.hack...@sent.com: On ven, 2014-05-23 at 14:48 -0700, Sriram Ramkrishna wrote: Since the reviews are the first defense of anything malicious, we will need to approve the body of people with a vote from the gnome-shell maintainers and/or long time submitters. Of course. I've submitted 3 extensions (one still relevant and maintained). I won't be at GUADEC this year, but a few GNOME developers have met me at the last GUADEC, including Stef Walter who mentored me for GSoC last year. I'm happy to discuss anything else necessary. This would be a good chance for me to contribute something to GNOME more consistently. My previous contributions have been quite sparse. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Extensions review
hi, all I am interested in tasks related to Shell extensions. I have not been able to write an extension so far but I've written a blog post about it [1]. How can I help? [1] sindhus.bitbucket.org/writing-shell-extensions-in-gnome.html ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Extensions review
On Sat, May 24, 2014 at 12:20 PM, Carlos Soriano Sánchez carlos.sorian...@gmail.com wrote: Hi, Hi, Jasper, what we should look at extensions to allow them in? If it is only to see if something is malicious and the connect, disconnect signals, maybe I can spare some time. Yeah and maybe a quick scan for obvious mistakes. I'm not that interested in extensions tbh, so I would willing to review currents ones to give feedback to that users that were not aware of Jasper not having time anymore. But I would put a warning in the website from now on, telling that we will no longer provide that service, if it is our intention. The thing is that we have way more submitters then reviewers (Jasper is not the only reviewer btw.) I think recruiting people from the pool of extension authors is the best way forward. Do you have admin / review access ? If not just tell me whats your username is and I will grant you that. As for why I do not do many reviews ... simply lack of time. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Extensions review
What might be interesting is to have a liaison who can help track changes in shell that needs to be communicated to extension authors so that there is less breakage every release. Maybe like a release porting guide that we can make as part of the shell release? This could also help you figure out more on the shell internals. What do you think? On May 24, 2014 3:55 AM, Sindhu S sind...@live.in wrote: hi, all I am interested in tasks related to Shell extensions. I have not been able to write an extension so far but I've written a blog post about it [1]. How can I help? [1] sindhus.bitbucket.org/writing-shell-extensions-in-gnome.html ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Extensions review
Drago, Ok. No, I don't have rights, my username is csoriano. Didn't know there were more extensions reviewers. I will help to the current queue so people not aware of the current situation will not be angry, but I think it would help to have a warning dialog or something in https://extensions.gnome.org/ that current review time is long and that we need developers to review extensions to maintain the service in a good way. Also I would do some guidelines for the recruitment of the help, maybe requiring some upstream patches or extensions?. What do you think? Also, don't we have the webpage code somewhere to do patches, do we? Sriram, Still, that's more work for developers, who already seems to be working on something else more important upstream. At the end, what we need is someone to go trough commits and make a list of important changes before a release. Not sure who be willing to do so, although Drago did it last release, I don't know how time consuming was to do it. 2014-05-24 17:44 GMT+02:00 Sriram Ramkrishna s...@ramkrishna.me: What might be interesting is to have a liaison who can help track changes in shell that needs to be communicated to extension authors so that there is less breakage every release. Maybe like a release porting guide that we can make as part of the shell release? This could also help you figure out more on the shell internals. What do you think? On May 24, 2014 3:55 AM, Sindhu S sind...@live.in wrote: hi, all I am interested in tasks related to Shell extensions. I have not been able to write an extension so far but I've written a blog post about it [1]. How can I help? [1] sindhus.bitbucket.org/writing-shell-extensions-in-gnome.html ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Extensions review
On Sat, May 24, 2014 at 7:14 PM, Carlos Soriano Sánchez carlos.sorian...@gmail.com wrote: Drago, Ok. No, I don't have rights, my username is csoriano. OK, you should have reviewing and admin powers now. Didn't know there were more extensions reviewers. I will help to the current queue so people not aware of the current situation will not be angry, but I think it would help to have a warning dialog or something in https://extensions.gnome.org/ that current review time is long and that we need developers to review extensions to maintain the service in a good way. Also I would do some guidelines for the recruitment of the help, maybe requiring some upstream patches or extensions?. What do you think? Also, don't we have the webpage code somewhere to do patches, do we? Sure we have https://git.gnome.org/browse/extensions-web/ ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Extensions review
Hi, There are a lot of extensions waiting for review since some weeks ago. I suppose this is done by volunteers and time is priceless, but there is cool stuff waiting to improve the shell. Regards, Albert ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Extensions review
On Fri, May 23, 2014 at 1:56 PM, Albert optimi...@gmail.com wrote: Hi, There are a lot of extensions waiting for review since some weeks ago. I suppose this is done by volunteers and time is priceless, but there is cool stuff waiting to improve the shell. Unfortunately, Jasper doesn't have time to look at them and is stepping back from the responsibilites of maintaiing the website. We will need to find a group of people who can do the code reviews. Is there some way that we can address this, folks? sri Regards, Albert ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Extensions review
On ven, 2014-05-23 at 14:08 -0700, Sriram Ramkrishna wrote: Unfortunately, Jasper doesn't have time to look at them and is stepping back from the responsibilites of maintaiing the website. We will need to find a group of people who can do the code reviews. Is there some way that we can address this, folks? I can't spare much time, but if others are willing to do the same, I'm willing to set aside perhaps 1 hour a week to review extensions. If a few other people are willing to do this, I'm sure we can get on top of this, and get the average review rate from a couple of months to no more than a couple of days. signature.asc Description: This is a digitally signed message part ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Extensions review
On Fri, May 23, 2014 at 2:40 PM, Sam Bull sam.hack...@sent.com wrote: On ven, 2014-05-23 at 14:08 -0700, Sriram Ramkrishna wrote: Unfortunately, Jasper doesn't have time to look at them and is stepping back from the responsibilites of maintaiing the website. We will need to find a group of people who can do the code reviews. Is there some way that we can address this, folks? I can't spare much time, but if others are willing to do the same, I'm willing to set aside perhaps 1 hour a week to review extensions. If a few other people are willing to do this, I'm sure we can get on top of this, and get the average review rate from a couple of months to no more than a couple of days. Since the reviews are the first defense of anything malicious, we will need to approve the body of people with a vote from the gnome-shell maintainers and/or long time submitters. sri ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Extensions review
On ven, 2014-05-23 at 14:48 -0700, Sriram Ramkrishna wrote: Since the reviews are the first defense of anything malicious, we will need to approve the body of people with a vote from the gnome-shell maintainers and/or long time submitters. Of course. I've submitted 3 extensions (one still relevant and maintained). I won't be at GUADEC this year, but a few GNOME developers have met me at the last GUADEC, including Stef Walter who mentored me for GSoC last year. I'm happy to discuss anything else necessary. This would be a good chance for me to contribute something to GNOME more consistently. My previous contributions have been quite sparse. signature.asc Description: This is a digitally signed message part ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
