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 Mon, May 26, 2014 at 9:01 AM, Dodier-Lazaro, Steve 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
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
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. This effectively prevents making only the extensions' API's memory pages executable to extension-running threads, for instance. It also doesn't make sense to sandbox something which is expected to have such a central access to your system. 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, 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.? I wouldn't risk myself at it since I don't have much JS experience: I don't even know how one'd break a JS interpretor (and specifically GJS). From my (external, non-GNOME, non-authoritative) viewpoint anybody who doesn't know this either shouldn't be trusted with security reviews. Cheers, -- 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 From: gnome-shell-list on behalf of Carlos Soriano Sánchez Sent: 25 May 2014 21:31 To: Sriram Ramkrishna Cc: Albert; gnome-shell-list Subject: Re: Extensions review Florian, Drago, Even more, Gnome is moving to application containers, but we are allowing those things in extensions? Seems just against all the work and a hole of security/privacy/what-I-think-application-does-or-permission-to-acces-my-things on the user POV. But I'm the new here... so maybe I'm wrong. Florian, so are you still reviewing extensions? Maybe the situation was not that bad then... from the emails I though "nobody" was reviewing currently. Sriram, Right, still imho we should encourage to work together if possible (like seems it is currently working as drago advised). 2014-05-25 22:23 GMT+02:00 Sriram Ramkrishna mailto:s...@ramkrishna.me>>: On Sun, May 25, 2014 at 12:57 PM, drago01 mailto: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
Re: Extensions review
On Sun, 2014-05-25 at 23:07 +0100, Sam Bull wrote: > Yes, I intend to try this out in future, but on my laptop Boxes won't > work at all. Either an issue with Ubuntu, or with some settings or > something (because I retain my home partition between installs). Boxes before 3.12 was never able to virtualize GNOME on my machine, no matter what the host or guest distro. [1] [1] https://bugzilla.gnome.org/show_bug.cgi?id=726882 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
It's still very helpful to know what changes between gnome-shell versions (sure, not helpful for all extensions, but certainly helpful for many). To this effort I once (at 3.2) started documenting the JS side of gnome-shell [1] with the intention that whenever the version bumped I'd merge the documentation over to the next branch (e.g. from 3.2 to 3.4) and then change whatever needed to be changed. Unfortunately I wasn't able to keep up with gnome-shell versions - we're now at 3.12 and I still haven't finished the 3.2 documentation, so I abandoned it. If any of the mailing list want to contribute, they are most welcome (though at this point it might be better to start at 3.10 or so rather than persist with 3.2). I imagine once one full set of documentation is up it should (technically) not take as much time to document changes between versions as most of the documentation can (hopefully) be carried over. (The syntax is JSDoc though I suspect with all the changes in that package it will no longer compile; however in-code documentation will certainly do for now). [1]: https://bitbucket.org/mathematicalcoffee/gnome-shell-doc On 25 May 2014 23:34, Sam Bull wrote: > On Sat, May 24, 2014 at 10:14 AM, Carlos Soriano Sánchez > 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? > > ___ > 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 dim, 2014-05-25 at 22:55 +0100, Emmanuele Bassi wrote: > it's not for 3.12, but: if you want to test the current development > version of GNOME, you can download an image built by our continuous > integration. Yes, I intend to try this out in future, but on my laptop Boxes won't work at all. Either an issue with Ubuntu, or with some settings or something (because I retain my home partition between installs). I should have a desktop set up and running (with something other than Ubuntu) just before the 3.14 release, so hopefully will be able to keep up-to-date with future releases. 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 Sam; On 25 May 2014 22:29, Sam Bull wrote: > 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. it's not for 3.12, but: if you want to test the current development version of GNOME, you can download an image built by our continuous integration. you can download them from: http://build.gnome.org/continuous/buildmaster/images/current/ they should run out of the box with any version of gnome-boxes newer than 3.9. really, everyone with an extension should try and download a VM once we start releasing beta versions of GNOME, so that they can reliably test their extension, and give feedback. sadly, waiting for distributions to pick up the current stable release of GNOME will always lead to users being left out, and to extensions breaking well after we did a stable release. it is what happens with web browser extensions: developers can run a nightly release of Firefox, or the devel channel of Chrome; admittedly, running a VM *is* a bit more complicated than downloading a bleeding edge version of a web browser, but we're trying to make it simpler, and feedback on how to improve that is always appreciated. at the end of the day, we also want app developers to start using VMs to test their applications. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ 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
On Sun, May 25, 2014 at 10:31 PM, Carlos Soriano Sánchez wrote: > Florian, so are you still reviewing extensions? Yes, as time permits. I'd estimate that the last time I went through the list was three weeks ago, so "months without any reviews!!11!" is quite exaggerated. Still, *more* people doing reviews is clearly helpful, so welcome to the club! Cheers, Florian ___ 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 1:29 PM, Jasper St. Pierre wrote: > 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. > Great! Thanks for the clarification. sri ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Extensions review
Florian, Drago, Even more, Gnome is moving to application containers, but we are allowing those things in extensions? Seems just against all the work and a hole of security/privacy/what-I-think-application-does-or-permission-to-acces-my-things on the user POV. But I'm the new here... so maybe I'm wrong. Florian, so are you still reviewing extensions? Maybe the situation was not that bad then... from the emails I though "nobody" was reviewing currently. Sriram, Right, still imho we should encourage to work together if possible (like seems it is currently working as drago advised). 2014-05-25 22:23 GMT+02:00 Sriram Ramkrishna : > On Sun, May 25, 2014 at 12:57 PM, drago01 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
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 wrote: > On Sun, May 25, 2014 at 12:57 PM, drago01 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 Sun, May 25, 2014 at 12:57 PM, drago01 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
Re: Extensions review
On Sun, May 25, 2014 at 10:01 PM, Carlos Soriano Sánchez wrote: > Drago, > > What I'm trying to avoid is basically: > https://extensions.gnome.org/review/3806 > I don't think we want a lot of Main.Util.trySpawnCommandLine and more if you > want to do is try to spawn gtk applications or so. The problem there is less the trySpawnCommandLine part, but rather that the "extension" actually contains a full-blown application and an extension as the sole way to interact with it (rather than the usual .desktop file in DATA_DIR/applications etc). I admit that this particular code has been so mind-boggling that I couldn't get myself to review it (and from the looks of it, neither did any of the other reviewers) ... Cheers, Florian ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Extensions review
Drago, What I'm trying to avoid is basically: https://extensions.gnome.org/review/3806 I don't think we want a lot of Main.Util.trySpawnCommandLine and more if you want to do is try to spawn gtk applications or so. What do you think? 2014-05-25 21:57 GMT+02:00 drago01 : > On Sun, May 25, 2014 at 9:52 PM, Carlos Soriano Sánchez > 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
On Sun, May 25, 2014 at 9:52 PM, Carlos Soriano Sánchez 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
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 : > On Sun, May 25, 2014 at 6:34 AM, Sam Bull wrote: > > On Sat, May 24, 2014 at 10:14 AM, Carlos Soriano Sánchez > > 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 6:34 AM, Sam Bull wrote: > On Sat, May 24, 2014 at 10:14 AM, Carlos Soriano Sánchez > 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 Sat, May 24, 2014 at 10:14 AM, Carlos Soriano Sánchez 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
On Sat, May 24, 2014 at 10:14 AM, Carlos Soriano Sánchez wrote: > 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. > My request was more directed at Sindhu and not one of the core developers. What would happen is that towards the end of the release, she can speak with shell folks and get an idea what might have changed that would affect extensions. Eventually, I am hoping that would not be required and instead would know directly from git. So it's a path to learning how shell works and how extensions work. At that point, she would be able to write her own extensions. The task is open to anybody else that might be interested as well. I'm interested in seeing a smooth transition each release. Now that I think about it, another way to find out is to use GNOME continuous and find out which extensions break and map it backwards. It doesn't do full coverage but can document immediate breakage. I would love to see this automated on a web page so that we know what is broken. I will start a new thread for that, no need to clutter this one with that. sri > > 2014-05-24 17:44 GMT+02:00 Sriram Ramkrishna : > >> 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" 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 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
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 : > 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" 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
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" 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 12:20 PM, Carlos Soriano Sánchez 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
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
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 : > 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
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
Re: Extensions review
On Fri, May 23, 2014 at 2:40 PM, Sam Bull 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: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 1:56 PM, Albert 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
