we have not even released a beta yet. i think it is worth a try to submit a patch for this if someone can do it very very soon. On 9/11/07, Konstantin Käfer <kkaefer@gmail.com> wrote:

...

But more interestingly jQuery UI is coming on Sunday 16th, I suspect there'll be a lot of requests to have that added to core...

I seriously doubt that this will happen. It would be more promising to create a central "jQuery UI" module that is then required by other modules who need the library.

Konstantin Käfer -- http://kkaefer.com/

isn't this the case already ? http://drupal.org/project/ui

There you go. Moshe: I am not opposed to getting jQuery 1.2 into Drupal 6, I am opposed to including jQuery UI (something different) in Drupal. Konstantin Käfer -- http://kkaefer.com/

On 11 Sep 2007, at 6:54 PM, Fernando Silva wrote:

I add to it the thought that this module could provide a way to select, show and install jquery plugins from the oficial jquery plugins page and "install time"!

How useful it that jquery.com is running the project module then. Do we know if their cvs tags are using something that project can use? because you could probably extend/ use the code of update_status to do that for you. just have it ping a different server, with the extra function to install the module. This could actually be a cool solution to the tinymce problem too. If a module could initialize a download of the lib from it's .install,

There's also a problem of control. You're assuming that all releases are compatible with Drupal. In TinyMCE's case, not all of Moxiecode's releases have been "Drupal friendly" . You'd actually need a third server/service to ping the URL of the most recent approved releases of external code. This idea was floated during the "no third party code" discussion back in May (my summary of that discussion - http://groups.drupal.org/node/3364#comment-12473). Derek Wright did a great job of outlining the issues with this approach and was very clear that he was not going to write scripts to do this. ( http://lists.drupal.org/pipermail/development/2007-May/024045.html) ___ *Kevin Reynen* Integrated Media Coordinator Reynolds School of Journalism and Advanced Media Research University of Nevada, Reno On 9/11/07, Sean Robertson <seanr@ngpsoftware.com> wrote:

That's a very good idea from a usability standpoint, but a problem for security. Any such feature would need to show the user what was about to be downloaded with an appropriately stern warning and offer them the opportunity to kill it.

adrian rossouw wrote:

...

On 11 Sep 2007, at 6:54 PM, Fernando Silva wrote:

...

I add to it the thought that this module could provide a way to

select, show and install jquery plugins from the oficial jquery

plugins page and "install time"!

How useful it that jquery.com is running the project module then.

Do we know if their cvs tags are using something that project can use? because you could probably extend/ use the code of update_status to do that for you.

just have it ping a different server, with the extra function to install the module.

This could actually be a cool solution to the tinymce problem too. If a module could initialize a download of the lib from it's .install,

-- Sean Robertson Web Developer NGP Software, Inc. seanr@ngpsoftware.com (202) 686-9330 http://www.ngpsoftware.com

On 9/11/07, Karoly Negyesi <karoly@negyesi.net> wrote:

...

This could actually be a cool solution to the tinymce problem too. If a module could initialize a download of the lib from it's .install,

No, no and no. Drupal must. not. write. directories. that. can. run. php. code.

Well, maybe yes. Consider the following idea; tinymce is shipped with md5sums of 'ok' sources. The module asks user if to download files and if yes, downloads and verifies the md5. And no, I'm not volunteering nor trying to upset the drupal dragon. -- Regards, Johan Forngren :: http://johan.forngren.com/

On Sep 11, 2007, at 10:50 AM, adrian rossouw wrote:

Do we know if their cvs tags are using something that project can use?

They don't use CVS at all. The plugin source is usually hosted elsewhere, in fact. They just use project.module for the project/ release browsing and issue tracking, not CVS integration. In fact, some of the plugins aren't even hosted there, just pointers to their home pages elsewhere on the net.

because you could probably extend/ use the code of update_status to do that for you.

update_status doesn't know anything about CVS tags. If jQuery plugins shipped with .info files, and they configured and ran the script that generates the .xml files with the release history, the existing update_status code in contrib (5.x-2.0) and the update.module in core (6.x) could already tell you if your jQuery plugins were out of date. There's a special field in the .info files that the update(_status)? code looks for to find the URL to fetch the release history XML from -- if it's not there, it defaults to updates.drupal.org. I'm in touch with the person who setup project* for http://jquery.com/ plugins, so if folks are serious about this, I could contact him again and propose to help get all this working nicely... -Derek (dww) p.s. I just tried this on a local test site -- the only weird thing is that update_status assumes modules, and you need a .module file for something to be listed on the modules page, even though the .info file is the only thing actually loaded. So, you also need a bogus, empty .module file for each plugin, and to "enable" the plugin's "module" on the admin/build/modules page for update_status to know about it. Other than that, it all works great. ;) Not to toot our own horns, but I must say, Earl and I did a kick-ass job with this, such that it would all basically Just Work(tm) given a little extra server-side configuration on their end and *no* changes to the client code on our end. p.p.s. They could even enable the project_usage.module on their server and start collecting plugin-specific usage stats. ;) /me winks at drewish.

On 9/11/07, Fernando Silva <fsilva.pt@gmail.com> wrote:

Following my idea, when I talked about the already current http://drupal.org/project/jquery

I was thinking on something following these lines: 1. always maintain this module as a "contrib" module, but turn it a recommend module

What is a recommended module? We don't currently have any other than core.... <snip /> All good ideas. I would gather a team and collaborate on this around the jquery module. -- Boris Mann Office 604-682-2889 Skype borismann http://www.bryght.com

On 9/11/07, Boris Mann <boris@bryght.com> wrote:

All good ideas. I would gather a team and collaborate on this around the jquery module.

Please notify this list when the g.d.o. is up ;) -- Regards, Johan Forngren :: http://johan.forngren.com/

Tao Starbow wrote:

Having jQuery UI in core would be huge. I know there was general agreement that the interface plug-in was not up to snuff (too big, too clunky). Hopefully jQuery UI will be acceptable (seems likely since John Resig has been leading the development). Having a drag & drop library included Drupal 6 would catalyze a revolution in UI work.

While I don't see jquery UI in core, Views 2 is likely going to rely on it for its UI, which means it will see widespread use.

I'm not sure what Earl's plans are, but I can see a rather small contrib that does the following: - Provides a directory within it called "plugins", into which you place whatever jquery plugins you want. - Provides a page similar to admin/build/modules that lists the found plugins and lets the admin enable/disable them. - In hook_init(), adds the enabled plugins to the javascript queue. Alternatively we could allow them to be added to specific pages only, but in most cases I think the new jquery compressor would be more useful than selective addition. Tracking of plugins beyond just name (jquery.plugin.js, which is what jQuery recommends) would require .info files or similar from jquery.com. Of course, as Derick said project* is already close enough that it shouldn't be that hard for them to add them... Such a module shouldn't even be that hard. The only hard part would be the theming of the admin form. The rest is simple. :-) On Tuesday 11 September 2007, Tao Starbow wrote:

Hi Earl,

Are you going to wrap jQuery UI in a module and make Views 2 depend on it (ala the current approach for the Interface module), or include the plugin with the views module, or just provide instructions to the user on how to downloaded it (in keeping with the "no 3rd-party code in the cvs repository" policy)?

cheers, -tao

Earl Miles wrote:

...

Tao Starbow wrote:

...

Having jQuery UI in core would be huge. I know there was general agreement that the interface plug-in was not up to snuff (too big, too clunky). Hopefully jQuery UI will be acceptable (seems likely since John Resig has been leading the development). Having a drag & drop library included Drupal 6 would catalyze a revolution in UI work.

While I don't see jquery UI in core, Views 2 is likely going to rely on it for its UI, which means it will see widespread use.

-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson

On Wednesday 12 September 2007, Neil Drumm wrote:

On 9/11/07, Larry Garfield <larry@garfieldtech.com> wrote:

...

- Provides a page similar to admin/build/modules that lists the found plugins and lets the admin enable/disable them.

Why would you present those options to users when the modules know exactly what they need enabled already?

I suppose the modules could request a plugin by name via a hook. Hm... Although that wouldn't help custom themes that need a specific plugin (which I have written). But then, D6 has better support for JS-in-theme anyway... -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson

On Wed, 12 Sep 2007 07:28:05 -0400, Earnie Boyd <earnie@users.sourceforge.net> wrote:

Quoting Larry Garfield <larry@garfieldtech.com>:

...

I'm not sure what Earl's plans are, but I can see a rather small contrib that does the following:

- Provides a directory within it called "plugins", into which you place whatever jquery plugins you want.

- Provides a page similar to admin/build/modules that lists the found plugins and lets the admin enable/disable them.

- In hook_init(), adds the enabled plugins to the javascript queue.

Just a note, that's hook_init() in D6, which corresponds to the hook_menu $may_cache = FALSE semi-hack of D5. :-)

Excuse my ignorance but why wouldn't the module system we already have suffice? The .info file would allow for the enable/disable and each .module would add the enabled JS to the queue.

Because then you'd need a separate Drupal module, with some boilerplate PHP, for every JS plugin you want to install. I'm talking about a small framework module that lets you manage what 3rd party JS plugins are installed. The same PHP code in a half-dozen different modules is a very bad thing. :-) (insert usual commentary about duplicate code here) --Larry Garfield

I think that is where the misunderstanding is coming in. We need to decouple those terms in this case .. module being a Drupal module, plugin being a jQuery plugin. http://jquery.com/plugins/ currently lists 363 available jQuery plugins. What Larry seems to be talking about is having 1 single Drupal module to activate/deactive this plugins if they are available on the local system, rather than having 363 individual Drupal modules to active/deactive these plugins. It seems like a reasonable approach to me. Conflating module and plugin in this case is what is leading to the confusion, I think. William On 9/12/07, Earnie Boyd <earnie@users.sourceforge.net> wrote:

Quoting Larry Garfield <larry@garfieldtech.com>:

...

...

Excuse my ignorance but why wouldn't the module system we already have suffice? The .info file would allow for the enable/disable and each .module would add the enabled JS to the queue.

Because then you'd need a separate Drupal module, with some boilerplate PHP, for every JS plugin you want to install. I'm talking about a small framework module that lets you manage what 3rd party JS plugins are installed. The same PHP code in a half-dozen different modules is a very bad thing. :-) (insert usual commentary about duplicate code here)

The .info file will handle the administration of de/activating the JS plugin module. Sometimes using the same code is necessary but that is what my question was trying to prevent. I don't see why you want another method to control activation of the module (I envision plugin and module as synonyms).

Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/

Khalid Baheyeldin wrote:

jQuery 1.2 is in Drupal 6 now.

http://drupal.org/cvs?commit=81013

congratulations!

Yes, what William said. :-) A single Drupal module to act as a controller / central repository for jQuery plugins, so that we don't have a dozen Drupal modules with the 20 lines of PHP (or whatever) needed to bootstrap the module just to call drupal_add_js(). Better to have one Drupal module that is 30 lines (plus another 100 of page handling code in a page-split file <g>) and can handle all of them. The question is whether that loading should be admin-controlled or instigated by modules implementing a hook. (E.g., a _jquery() hook from which modules return the name of jquery plugins they need, and this central module then loads just those.) I guess this is something we should be talking to John Resig about, too. :-) --Larry Garfield On Wed, 12 Sep 2007 15:28:44 -0400, "William Smith" <william.darren@gmail.com> wrote:

I think that is where the misunderstanding is coming in. We need to decouple those terms in this case .. module being a Drupal module, plugin being a jQuery plugin.

http://jquery.com/plugins/ currently lists 363 available jQuery plugins. What Larry seems to be talking about is having 1 single Drupal module to activate/deactive this plugins if they are available on the local system, rather than having 363 individual Drupal modules to active/deactive these plugins.

It seems like a reasonable approach to me. Conflating module and plugin in this case is what is leading to the confusion, I think.

William

On 9/12/07, Earnie Boyd <earnie@users.sourceforge.net> wrote:

...

Quoting Larry Garfield <larry@garfieldtech.com>:

...

...

Excuse my ignorance but why wouldn't the module system we already

have

...

...

...

suffice? The .info file would allow for the enable/disable and each .module would add the enabled JS to the queue.

Because then you'd need a separate Drupal module, with some boilerplate PHP, for every JS plugin you want to install. I'm talking about a small framework module that lets you manage what 3rd party JS plugins are installed. The same PHP code in a half-dozen different modules is a very bad thing. :-) (insert usual commentary about duplicate code here)

The .info file will handle the administration of de/activating the JS plugin module. Sometimes using the same code is necessary but that is what my question was trying to prevent. I don't see why you want another method to control activation of the module (I envision plugin and module as synonyms).

Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/

On Wednesday 12 September 2007, Derek Wright wrote:

On Sep 12, 2007, at 2:17 PM, Larry Garfield wrote:

...

A single Drupal module to act as a controller / central repository for jQuery plugins, so that we don't have a dozen Drupal modules with the 20 lines of PHP (or whatever) needed to bootstrap the module just to call drupal_add_js().

Just to be clear, what I was proposing in the other thread about update(_status)? + jQuery plugins was that each jQuery plugin would have a .info file, and an *empty* .module file, only so that it showed up like a module with respect to update(_status)? and that the existing client code could check for newer versions of the plugins. My proposal wasn't at all concerned with the code to actually call drupal_add_js(), and I agree that a single plugin-manager would be better than a bunch of duplicated code for that.

That said, the single plugin manager might be able to handle the case that the empty .module files was meant to address, and populate the {system} table with some new records for each plugin, just so that update(_status)? knows they exist and can look for new releases...

Alternatively, we *could* modify the update(_status)? code to better handle this case, and, for example:

*snip* This sounds like something we'd want to talk over with John Resig and the jQuery folks. The ideal case would be a "plugins" directory that mirrors the way the modules directory works, complete with .info files that get loaded as needed by core/a core module/a contrib module that eventually moves to core. That would require some standardization and packaging on the jQuery side (since I don't think we want to be in the business of managing our own jQuery plugins. dww, are you going to be in Barcelona? If so, let's try and find some time to talk. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson

On 9/13/07, Earnie Boyd <earnie@users.sourceforge.net> wrote:

Thanks for the explanation. So we're saying that a jquery_plugins.module is needed to control the use of the jQuery plugin. Perhaps uploading the plugin via the file upload process and allowing the jQuery plugin to live in files/jquery/ or something like that? Then delete the plugin file from files/jquery/ to deactivate it?

Yeap. Is that! The jquery plugins folder could then be by default (and if chosen) a "drupal system path" (if writable) or degrade to be used the "files" folder instead. This would allow the install of (critical) plugins during drupal install, without fear to have them removed later.

Again forgive my ignorance on this matter. I just don't want users needing two different activate/deactivate menus and since jQuery is part of core; every user will eventually need to use it. Do any of those plugins create a need to modify a database? It will be worse if yes because then we definitely should provide a .install file just to do the un/install of the pieces and parts.

The plugins, could eventually appear at the "modules admin page" if this page would be refactored in another way. At this moment this page produces a long list and it is not suitable to show "plugins" that can be download and installed. Just think... a list with 300 jquery plugins ready to be downloaded and installed, would create a long list....

It's not executable code. It's jQuery javascript files. On 9/13/07, Peter Wolanin <pwolanin@gmail.com> wrote:

Um, perhaps you all have not seen previous threads about the hazards of allowing executable code in a writeable directory?

How would this module be different from uploading a .js file to the /files directory using upload module? On 13/09/2007, Jeff Eaton <jeff@viapositiva.net> wrote:

Please step back from your computer and wait while Rasmus roots your machine. Thank you!

;)

--Jeff

On Sep 13, 2007, at 8:45 AM, Fernando Silva wrote:

...

It's not executable code. It's jQuery javascript files.

On 9/13/07, Peter Wolanin <pwolanin@gmail.com> wrote:

...

Um, perhaps you all have not seen previous threads about the hazards of allowing executable code in a writeable directory?

-- Regards Steven Jones

But the javascript files were going in the /files directory, no? On 13/09/2007, Jeff Eaton <jeff@viapositiva.net> wrote:

It would be writing files that would, under many circumstances, be included in the browser's output to future visitors.

--Jeff

On Sep 13, 2007, at 9:21 AM, Steven Jones wrote:

...

How would this module be different from uploading a .js file to the /files directory using upload module?

On 13/09/2007, Jeff Eaton <jeff@viapositiva.net> wrote:

...

Please step back from your computer and wait while Rasmus roots your machine. Thank you!

;)

--Jeff

On Sep 13, 2007, at 8:45 AM, Fernando Silva wrote:

...

It's not executable code. It's jQuery javascript files.

On 9/13/07, Peter Wolanin <pwolanin@gmail.com> wrote:

...

Um, perhaps you all have not seen previous threads about the hazards of allowing executable code in a writeable directory?

-- Regards Steven Jones

-- Regards Steven Jones

Bingo. Larry's summary explains it. automatic downloading of jquery plugins is only useful if those files are automatically included in the output to clients. Which means that your web site has just become a one-stop reflector for JS-based exploits. --Jeff On Sep 13, 2007, at 11:24 AM, Larry Garfield wrote:

It doesn't matter where they live on the server. They're useless unless they get sent to the browser, where they are useless unless they execute. That means one PHP security hole, in any PHP script anywhere on the server, and a n'er-do-well can write to a Javascript file that will get sent to every visitor's browser, where it will open a new hidden browser window to youreh4x3d.com, which will download a malicious program to that visitor's computer that begins vocally espousing the wonders of Viagra to a few million email addresses.

Quoting Jeff Eaton <jeff@viapositiva.net>:

It would be writing files that would, under many circumstances, be included in the browser's output to future visitors.

How can this become an issue if only administrators have the privilege? Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/

I generally agree that we should try and come up with ways that are safer than just opening code trees up for modifications, and that some safer process (perhaps a handshake with a cron job that could run as a different user and pull plugins) would be a better approach. It's always bothered me a little that cron.php is an exposed unauthenticated admin process. But I also agree with the concept that jQuery plugins aren't the same as PHP code., cause they don't execute server side. Whether we like it or not, there is some precedent for writing "core files" into the system files path and letting clients download it from there. Not that I'm advocating this approach mind you, but the Theme Developer module writes tpl files and css files into the "files" path and then lets people execute code server side from that path, and even drupal core rewrites css files and image files into the systems files path. You could perhaps argue that these aren't code, but I just was sort of pointing out that that it does meet the definition of core files, even though it ain't code. Food for thought: Would we eliminate support for flash uploads because flash gets used for client side coding as well? Hmm... I also wanted to point that out so that we don't al get a false sense of security regarding code that uploads files. If I can get a module to upload code (through a bug) into the files path, then I can still leverage that code in really nasty ways. In other words just cause we're not uploading files to the modules directory doesn't mean we've protected ourselves from php file upload vulnerabilities. All code that contains the ability to update files on a server needs close scrutiny. Just trying to share a different perspective (I can argue both sides of any issue :) and do more often than not). On Sep 13, 2007, at 6:11 PM, Derek Wright wrote:

On Sep 13, 2007, at 5:34 PM, Earnie Boyd wrote:

...

How can this become an issue if only administrators have the privilege?

Various other people in this thread were proposing that the site could automatically download and install/activate jQuery plugins (either new plugins, or new releases of existing plugins). This would require the website having write access to its own jquery plugin folder. This is the giant security hole we've pointed out, and which you seem to understand.

The confusion is between people who sanely understand that the only safe solution to this problem is for the human admin to manually upload/install new jquery plugins outside of drupal (scp, ftp, rsync, whatever -- some process with write access to the drupal sources which is *NOT* initiated via httpd and php) and the people who think that the site could somehow upgrade itself.

To be extra clear, I should state: letting httpd or php write to the drupal sources *AT ALL* is a risk. Even if the only "legitimate" way that is coded into the system requires a special privilege, and access to admin/jquery/update, so long as the operating system *ever* allows httpd or php to write to those directories, there's a potential vulnerability. Any minor bug then could become a critical exploit. So, as a precaution, the operating system itself (not Drupal's code) should enforce that Drupal can never write to the files that Drupal is trying to execute (either php source or .js that's sent to the browser). That way, even when future Drupal bugs are discovered, at least the operating system can help prevent those bugs from being exploited to cause significant damage.

Hope that helps clarify, -Derek (dww)

p.s. If only shared hosting companies understood this. :( Sadly, most of them seem to run all of your httpd and php processes as the same user that owns all the files (presumably since that's easier and cheaper for them to manage, do accounting on, suspend your account when it uses "too many resources" etc). But, what's more profitable for the shared hosting provider is more dangerous for the customer. Ahh, the joys of capitalism.

That's a bit unfair. I was talking about the risk of compromising the site and operating system protection etc. I thought we were having a discussion about risk vs. benefit, and I was trying to make a point that compromised javascript code does not have the same risk factor as compromised php code. Particularly if you're talking about the ability to propagate from host to host, etc. Some in this thread seemed to be implying that this was the same level of risk. Javascript operates in a security sandbox. PHP doesn't. On Sep 14, 2007, at 9:02 AM, Earl Miles wrote:

David Metzler wrote:

...

But I also agree with the concept that jQuery plugins aren't the same as PHP code., cause they don't execute server side.

Right, because endangering your users is better than endangering your own site.

Why not include an MD5 hash in the DB? When you first download the javascript, it takes an MD5 hash of the file(s) and stores them in the database. Every cron, it checks. If they are not the same, it re-downloads. On 9/15/07, Earl Miles <merlin@logrus.com> wrote:

David Metzler wrote:

...

That's a bit unfair. I was talking about the risk of compromising the site and operating system protection etc. I thought we were having a discussion about risk vs. benefit, and I was trying to make a point that compromised javascript code does not have the same risk factor as compromised php code. Particularly if you're talking about the ability to propagate from host to host, etc. Some in this thread seemed to be implying that this was the same level of risk.

Javascript operates in a security sandbox. PHP doesn't.

Compromised javascript can do things like install invisible key loggers that send your keystrokes to some unknown location and steal whatever it is you enter into it.

Hope you don't visit your financial website and enter your password after visiting your harmless-but-compromised javascript site.

(Thanks to Rasmus for his presentation at OSCMS Summit for that tidbit.)

I don't understand how the DB can be compromized. Could you clarify? The way I was thinking was running md5_file on the newly downloaded files, and saving in to a table with md5 and filename. In hook_cron, it re-md5's the files, and checks against the DB. Maybe if it's not very expensive, we could even run it every few page loads to be even faster. Maybe provide a slider, security vs. speed? :D On 9/15/07, Earl Miles <merlin@logrus.com> wrote:

D G wrote:

...

Why not include an MD5 hash in the DB? When you first download the javascript, it takes an MD5 hash of the file(s) and stores them in the database. Every cron, it checks. If they are not the same, it re-downloads.

Interesting idea, that. It's a step, though the db can also be compromised, if the md5 is re-downloaded regularly that can be mitigated somewhat. That actually does have some merit to it (and it's pretty much why yum and apt-get are trustworthy).

On 9/16/07, Larry Garfield <larry@garfieldtech.com> wrote:

If you can get an exploit that allows arbitrary PHP execution, then all you'd need to do is write a new hacked javascript file and then update the database with a new md5sum. Voila, it won't be detected.

And having Drupal (or your OS, or browser, or anything else) auto-install files without asking you is a bad idea in general. The user/admin should always have to be notified of and pre-approve any changes to the installed software. To do otherwise is just begging for the system to auto-download its own crack.

And from a different perspective, what is this thread about? Automating jquery plugins install ? I smell the overengineering flux :-) - jquery UI has not been released yet, so it's hard to evaluate how to ship it with Drupal - other jquery plugins have been known to be a decentralized thing, and moving very fast (with api changes). Even if it's not the case with UI, it's too new to evaluate - we don't even know what Drupal will use from this jquery UI - we don't auto install Drupal modules why would we autoinstall jquery plugins ? Imho auto install of jquery plugin is not needed. Fine grained control of what is enabled or not is not very important. I think that someone thrusted from Drupal UI module could create an archive containing everything including UI widgets and images. This archive would be available ideally from the jquery website, as we can't put this stuff on d.o or eventually on a third party server. Admin can dowload this archive inside the UI module and be confident that it will work. Other modules would simply depend on UI module and add_js() what is required for them. As long as the js is added to the page only when requested, it doesn't matter if admin must upload a "big" archive inside Drupal UI module to make it work. my 0.02 Philippe

Derek Wright-2 wrote:

To be extra clear, I should state: letting httpd or php write to the drupal sources *AT ALL* is a risk. Even if the only "legitimate" way that is coded into the system requires a special privilege, and access to admin/jquery/update, so long as the operating system *ever* allows httpd or php to write to those directories, there's a potential vulnerability. Any minor bug then could become a critical exploit. So, as a precaution, the operating system itself (not Drupal's code) should enforce that Drupal can never write to the files that Drupal is trying to execute (either php source or .js that's sent to the browser).

That way, even when future Drupal bugs are discovered, at least the operating system can help prevent those bugs from being exploited to cause significant damage.

I agree of course. What makes me wonder, though, don't we in Drupal 6 already include a javascript file in every request which is written by Drupal to the filesystem via the Javascript aggregator/compressor? Isn't that exactly the same as allowing Drupal to save downloaded jQuery plugins in the file directory (not that I think this is good idea anyway)? regards, frando -- View this message in context: http://www.nabble.com/jQuery-1.2-is-released-tf4421190.html#a12673287 Sent from the Drupal - Dev mailing list archive at Nabble.com.

Quoting Jeff Eaton <jeff@viapositiva.net>:

On Sep 14, 2007, at 6:23 AM, Frando wrote:

...

I agree of course. What makes me wonder, though, don't we in Drupal 6 already include a javascript file in every request which is written by Drupal to the filesystem via the Javascript aggregator/compressor?

Isn't that exactly the same as allowing Drupal to save downloaded jQuery plugins in the file directory (not that I think this is good idea anyway)?

The difference is that the JS files that make up that aggregated JS file were all downloaded manually by an administrator and installed, not auto-downloaded from a remote server and installed by a 'smart' module.

Ok, I've gone back and reread parts of this thread. Let's put the argument against automating the jQuery plugin scripts behind us because it has been expressed and everyone understands that it is a bad idea. Now let us discuss: the administrator is given the option in the jquery_plugin module to upload his jQuery plugin. The jquery_plugin module writes the uploaded file to files/jquery/ directory. The jquery_plugin module then serves the client visiting the site those files. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/

Forgive me if these have already been spelled out and I missed it, but with Earnie's vision for a jquery_plugin module... Is the jquery_plugin module alerting users to updates of the JQuery plugins (that they would manually download (hopefully look at) and then upload)? Is there any automated connection between the jquery_plugin module and modules that require the plug-ins or are modules that require JQuery plugins expected to check to see if the plugin are in the files/jquery/ directory and alert the site's admin to use jquery_plugin to upload the plugin if it's not there? - Kevin On 9/14/07, Earnie Boyd <earnie@users.sourceforge.net> wrote:

Quoting Jeff Eaton <jeff@viapositiva.net>:

...

On Sep 14, 2007, at 6:23 AM, Frando wrote:

...

I agree of course. What makes me wonder, though, don't we in Drupal 6 already include a javascript file in every request which is written by Drupal to the filesystem via the Javascript aggregator/compressor?

Isn't that exactly the same as allowing Drupal to save downloaded jQuery plugins in the file directory (not that I think this is good idea anyway)?

The difference is that the JS files that make up that aggregated JS file were all downloaded manually by an administrator and installed, not auto-downloaded from a remote server and installed by a 'smart' module.

Ok, I've gone back and reread parts of this thread. Let's put the argument against automating the jQuery plugin scripts behind us because it has been expressed and everyone understands that it is a bad idea.

Now let us discuss: the administrator is given the option in the jquery_plugin module to upload his jQuery plugin. The jquery_plugin module writes the uploaded file to files/jquery/ directory. The jquery_plugin module then serves the client visiting the site those files.

Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/

I'm either not asking the second question clearly or I'm not understanding your answer about the connection between the jquery_plugin module and modules that require the JQuery plug-ins. I'm not asking about activating the plugin when the module is called (which I think 2 and 3 answer) or getting the JQuery plugins from jquery.com to the Drupal install, but simply getting a module with a JQuery plugin dependency installed. Let's say I've developed a module that requires a jquery plugin. You want to use the module, but don't have the required JQuery plugin. What happens? Obviously the module would have a dependency of jquery_update module, but how does a module with a jquery plugin dependency indicate to the site admin that an additional jquery plugin is required for the module to function? I'd love to see the process for installing modules that require two step installs standardized. - Kevin Reynen On 9/14/07, Larry Garfield <larry@garfieldtech.com> wrote:

In an earlier message, I had proposed two activation methods:

1) An admin form ~ admin/build/modules where the admin can toggle on or off a given plugin.

2) A hook_jquery() that modules can implement to specify which they require. The jquery module can then auto-activate those that are requested, and do some sort of error reporting if it is not available. (This method does require a hard naming convention, which is probably OK since jQuery has an informal convention.)

3) Nobody expects the Spanish Inquisition! I guess there's no reason we couldn't do both, with hook-requested plugins always-on and the admin able to activate more at his leisure.

Plugins used only by a theme probably wouldn't need this, as they already have a scripts key in their info file. (Say, how come we didn't enable scripts and styles keywords for module .info files? Bah. Drupal 7.)

That would be a separate question from how the plugin gets on the server and where it lives (FTP, http upload, FTP-loopback routine, etc.).

--Larry Garfield

On Fri, 14 Sep 2007 08:51:41 -0700, "Kevin Reynen" <kreynen@gmail.com> wrote:

...

Forgive me if these have already been spelled out and I missed it, but with Earnie's vision for a jquery_plugin module...

Is the jquery_plugin module alerting users to updates of the JQuery plugins (that they would manually download (hopefully look at) and then upload)?

Is there any automated connection between the jquery_plugin module and modules that require the plug-ins or are modules that require JQuery plugins expected to check to see if the plugin are in the files/jquery/ directory and alert the site's admin to use jquery_plugin to upload the plugin if it's not there?

- Kevin

On 9/14/07, Earnie Boyd <earnie@users.sourceforge.net> wrote:

...

Quoting Jeff Eaton <jeff@viapositiva.net>:

...

On Sep 14, 2007, at 6:23 AM, Frando wrote:

...

I agree of course. What makes me wonder, though, don't we in Drupal

6

...

...

...

already include a javascript file in every request which is written by Drupal to the filesystem via the Javascript aggregator/compressor?

Isn't that exactly the same as allowing Drupal to save downloaded jQuery plugins in the file directory (not that I think this is good idea anyway)?

The difference is that the JS files that make up that aggregated JS file were all downloaded manually by an administrator and installed, not auto-downloaded from a remote server and installed by a 'smart' module.

Ok, I've gone back and reread parts of this thread. Let's put the argument against automating the jQuery plugin scripts behind us because it has been expressed and everyone understands that it is a bad idea.

Now let us discuss: the administrator is given the option in the jquery_plugin module to upload his jQuery plugin. The jquery_plugin module writes the uploaded file to files/jquery/ directory. The jquery_plugin module then serves the client visiting the site those files.

Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/

To clarify. When it comes to PHP code, everything is absolutely clear: Never allow Drupal to write its own code. Never. Ever. We really discussed this often enough. There might be possiblities by using an FTP layer, though. There's an issue for that somewhere. JavaScript is different, though. For someone to exploit a Drupal site by saving a modified, malicious JavaScript file at a path where it gets included in every request, he needs a major security hole in the site (one that allows him to save random files at random paths). Given that security hole, he most likely has already other ways to add random, malicious JavaScript to every page request (He could e.g. add a PHP block with no title and text to each page which then includes the malicious JavaScript. He could also add the JavaScript to the aggregated CSS file, which also lives in the writeable file directory. JavaScript in CSS files gets executed by most modern browsers.). So, allowing Drupal to write its JavaScript files (which we already do in Drupal 6 with the JavaScript aggregator) is not a security risk. If we would count this as a security risk, we would have to get rid of both the CSS and the JS aggregator. regards, Frando Frando wrote:

Derek Wright-2 wrote:

...

To be extra clear, I should state: letting httpd or php write to the drupal sources *AT ALL* is a risk. Even if the only "legitimate" way that is coded into the system requires a special privilege, and access to admin/jquery/update, so long as the operating system *ever* allows httpd or php to write to those directories, there's a potential vulnerability. Any minor bug then could become a critical exploit. So, as a precaution, the operating system itself (not Drupal's code) should enforce that Drupal can never write to the files that Drupal is trying to execute (either php source or .js that's sent to the browser).

That way, even when future Drupal bugs are discovered, at least the operating system can help prevent those bugs from being exploited to cause significant damage.

I agree of course. What makes me wonder, though, don't we in Drupal 6 already include a javascript file in every request which is written by Drupal to the filesystem via the Javascript aggregator/compressor?

Isn't that exactly the same as allowing Drupal to save downloaded jQuery plugins in the file directory (not that I think this is good idea anyway)?

regards, frando

-- View this message in context: http://www.nabble.com/jQuery-1.2-is-released-tf4421190.html#a12674266 Sent from the Drupal - Dev mailing list archive at Nabble.com.

just brainstorming... This is kind of sounding similar to the government deciding what's best for the people rather than the other way around. I agree it shouldn't automatically (read "by default"), but what about an option to turn on with a big, red warning label? How about a page from Microsoft's OSs: "Download updates automatically, ask permission before installing". On Sep 14, 2007, at 8:32 AM, Jeff Eaton wrote:

This is very true. The concern that sparked this discussion revolved around *automatically downloading* javascript files from a *remote server* and automatically including them in Drupal's output to end-users. Compromising remote servers in that scenario (as happened with Wordpress) could easily result in jillions of Drupal sites auto-downloading a compromised version of a js file and 'reflecting' it out to all of their users.

--Jeff

On Sep 14, 2007, at 7:25 AM, Frando wrote:

...

JavaScript is different, though. For someone to exploit a Drupal site by saving a modified, malicious JavaScript file at a path where it gets included in every request, he needs a major security hole in the site (one that allows him to save random files at random paths). Given that security hole, he most likely has already other ways to add random, malicious JavaScript to every page request (He could e.g. add a PHP block with no title and text to each page which then includes the malicious JavaScript. He could also add the JavaScript to the aggregated CSS file, which also lives in the writeable file directory. JavaScript in CSS files gets executed by most modern browsers.).

Finally you had time to be clear about that. You should had do that 18 responses before. Anyway and going back to the point itself, lets do another resume: 1. allowing jquery plugins to be installed by the user through Drupal, would have the same problems that we have today, allowing the user to upload anything he wants through Drupal. 2. allowing javascript to be installed at *install time* (in any some folder) by the administrator has the same problems that we have today when he installs Drupal. 3. automatically downloading a file ****at user/admin request**** (and ALWAYS with user/admin knowledge) from a *remote server* has the same problems has the user going to the remote server and downloading/installing the file itself. 4. already discussed was the option to create valid/authentic packages. With the upcoming functionality "update/version status", if Drupal server is compromised, you think it's a different situation from the one you are trying to create? So, it's time to start thinking about "signing" of Drupal core/contrib/(eventually)plugins packages! Regards, Fernando On 9/14/07, Jeff Eaton <jeff@viapositiva.net> wrote:

This is very true. The concern that sparked this discussion revolved around *automatically downloading* javascript files from a *remote server* and automatically including them in Drupal's output to end- users. Compromising remote servers in that scenario (as happened with Wordpress) could easily result in jillions of Drupal sites auto- downloading a compromised version of a js file and 'reflecting' it out to all of their users.

Quoting Derek Wright <drupal@dwwright.net>:

On Sep 13, 2007, at 5:34 PM, Earnie Boyd wrote:

...

How can this become an issue if only administrators have the privilege?

Various other people in this thread were proposing that the site could automatically download and install/activate jQuery plugins (either new plugins, or new releases of existing plugins). This would require the website having write access to its own jquery plugin folder. This is the giant security hole we've pointed out, and which you seem to understand.

Ah, I missed that. What I had proposed was the jquery_plugin module upload the files under administers control. Automated updating isn't something any sane administrator would want to do.

The confusion is between people who sanely understand that the only safe solution to this problem is for the human admin to manually upload/install new jquery plugins outside of drupal (scp, ftp, rsync, whatever -- some process with write access to the drupal sources which is *NOT* initiated via httpd and php) and the people who think that the site could somehow upgrade itself.

Drupal upload service could make use of extended PHP with ssh module[1] if available. We allow files to be uploaded now and since a jQuery plugin is client side JS and won't be executed on the server why not allow the administrator to upload it via the Drupal service? [1] http://us.php.net/manual/en/ref.ssh2.php

To be extra clear, I should state: letting httpd or php write to the drupal sources *AT ALL* is a risk. Even if the only "legitimate" way that is coded into the system requires a special privilege, and access to admin/jquery/update, so long as the operating system *ever* allows httpd or php to write to those directories, there's a potential vulnerability. Any minor bug then could become a critical exploit. So, as a precaution, the operating system itself (not Drupal's code) should enforce that Drupal can never write to the files that Drupal is trying to execute (either php source or .js that's sent to the browser). That way, even when future Drupal bugs are discovered, at least the operating system can help prevent those bugs from being exploited to cause significant damage.

I would be more concerned about image files that are binary in nature than I would about JS which is text. We allow ppl to upload images that could in fact execute code on the server side as well as the client side. All we can really do to prevent abuse is to make it as difficult as possible. But do we want to make it so difficult that it makes it nearly useless for some things? I do understand that allowing code executed from world open write directories to be executed on the server isn't something that we want to do. I don't understand why we wouldn't want to allow the administrator using the jquery_plugin module to upload the JS file via Drupal, activate it (something stored in the DB), change it to read only (only a minor precaution) and then use it to send to the client.

Hope that helps clarify,

Only somewhat. I've never been a cracker only a hacker. For me to fully understand I suppose I would need to involve myself with training in IT Security.

-Derek (dww)

p.s. If only shared hosting companies understood this. :( Sadly, most of them seem to run all of your httpd and php processes as the same user that owns all the files (presumably since that's easier and cheaper for them to manage, do accounting on, suspend your account when it uses "too many resources" etc). But, what's more profitable for the shared hosting provider is more dangerous for the customer. Ahh, the joys of capitalism.

Plus it makes it easier (requires fewer knowledgeable ppl) to deal with the ignorant public. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/

I think in Drupal 7 or so we should have standardized plugins. Modules are plugins, themes are plugins. jQuery plugins can become plugins. Maybe include an API for library or end-user plugins On 9/16/07, adrian rossouw <adrian@bryght.com> wrote:

On 14 Sep 2007, at 2:01 PM, Earnie Boyd wrote:

Drupal upload service could make use of extended PHP with ssh module[1] if available. We allow files to be uploaded now and since a jQuery plugin is client side JS and won't be executed on the server why not allow the administrator to upload it via the Drupal service?

there's a php implementation of ssh.

Um, perhaps you all have not seen previous threads about the hazards of allowing executable code in a writeable directory?

-Peter

By referencing to those 'obvious' discussions without any link or quote, I'm feeling quite stupid now. I've searched drupal.org, the development list archives and Google for the terms executable, code, writeable, directory(, drupal). Guess what? I did not find any thread containing useful, deep-insight information about why other systems like JOS/MOS are (more or less) successfully using writable directories for their modules [components] for quite some time now and Drupal is not. Could someone please direct me/us to some einlightening issues and/or threads? That would be greatly appreciated. sun

Luckily, the uploaded php script didn't work and my server did not become a spam sending zombie and I did not have spend weeks to get it out of blacklists again.

No question, I dealt with them, too. IIRC, wasn't that the cause for those nifty .htaccess files in files/ ? SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006 Options None Options +FollowSymLinks If there is no handler, what was able to be executed? Are those 'previous threads' fictive and just one of these walls the Drupal community is possibly able to break through by implementing innovative solutions? cheers, sun

Daniel F. Kudwien wrote:

...

Um, perhaps you all have not seen previous threads about the hazards of allowing executable code in a writeable directory?

-Peter

By referencing to those 'obvious' discussions without any link or quote, I'm feeling quite stupid now. I've searched drupal.org, the development list archives and Google for the terms executable, code, writeable, directory(, drupal). Guess what? I did not find any thread containing useful, deep-insight information about why other systems like JOS/MOS are (more or less) successfully using writable directories for their modules [components] for quite some time now and Drupal is not.

Here's the summary: By allowing uploaded files to be run as code, any minor bug in the server or site software, anywhere, that could allow the uploading of arbitrary files could then ovewrite code that is run; this could then allow a much larger hack that could totally take over the site. Ordinarily, code is not writeable by the webserver user, so any bug that allows the uploading of arbitrary files simply cannot overwrite code, and the impact is therefore minimized. The reality is that the script kiddies are everywhere and always on the look out for these bugs, too.

Quoting Earl Miles <merlin@logrus.com>:

By allowing uploaded files to be run as code, any minor bug in the server or site software, anywhere, that could allow the uploading of arbitrary files could then ovewrite code that is run; this could then allow a much larger hack that could totally take over the site.

Uhm, the only one able to write to the files/jquery directory would be Administrative types that want to install a jQuery plugin. Allowing others to do that would be ludicrous. If this is such a big security issue then the image modules better be careful!! This includes the avatar in the profile modules. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/

Quoting adrian rossouw <adrian@bryght.com>:

On 13 Sep 2007, at 2:14 PM, Fernando Silva wrote:

...

The plugins, could eventually appear at the "modules admin page" if this page would be refactored in another way. At this moment this page produces a long list and it is not suitable to show "plugins" that can be download and installed. Just think... a list with 300 jquery plugins ready to be downloaded and installed, would create a long list....

I've always felt that we need a separate 'library' package type, that doesn't need to be enabled / disabled .. just is used when requested.

You mean if the administrator installs to something like <drupal_root>/lib then it is available regardless of which module is using it? But what if the module needs it and it isn't available? Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/

Karoly Negyesi wrote:

...

http://docs.jquery.com/Release:jQuery_1.2

Great, let's throw away all the effort that went into making it possible to have a beta before DrupalCon and delay even more!

Yes, actually. I'd rather delay the beta than release Drupal 6 with a jquery library whose plugins will not see further development. IN Drupal 5, it started getting really hard to even FIND the plugins, as most authors had removed the versions for jquery 1.0 so they wouldn't have to deal with them. jquery 1.2 is expected to be a long term release. This is a very worthwhile delay, IMO.

On 9/11/07, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Earl Miles schrieb:

...

Karoly Negyesi wrote:

...

...

http://docs.jquery.com/Release:jQuery_1.2

Great, let's throw away all the effort that went into making it possible to have a beta before DrupalCon and delay even more!

Yes, actually. I'd rather delay the beta than release Drupal 6 with a jquery library whose plugins will not see further development. IN Drupal 5, it started getting really hard to even FIND the plugins, as most authors had removed the versions for jquery 1.0 so they wouldn't have to deal with them. jquery 1.2 is expected to be a long term release. This is a very worthwhile delay, IMO.

Yep, I fully agree.

Dries and I discussed releasing a beta (finally) around the end of this week. We discussed this before the jQuery 1.2 topic broke out, but now I see no reason not to do a beta 1 this week. If there is so strong an interest in jQuery 1.2 in D6 core, then a group of people can easily go and do it in the remaining 3-4 days. In the whole D6 relase cycle we have seen the latest jQuery fueling the buzz around here, and we committed stuff from updates to updates. I tried to look up where is it stated that 1.2 is going to stay with us any longer then the previous versions (jQuery has a pretty speedy development pace), but found nothing about it. Earl can probably show us, where is this stated. Do not misunderstand what I say: I love jQuery, used it in my own projects, but given previous experience, it is hard to believe it straight away, that this release is going to be stable for longer, so our users will easily use plugin modules and so on, without installing a "jquery updater" module again. Gabor