Discussion:
jQuery 1.2 is released
(too old to reply)
Johan Forngren
2007-09-11 08:57:59 UTC
Permalink
http://docs.jquery.com/Release:jQuery_1.2

--
Regards,
Johan Forngren :: http://johan.forngren.com/
Adrian Simmons
2007-09-11 10:00:19 UTC
Permalink
Johan Forngren wrote:
> http://docs.jquery.com/Release:jQuery_1.2

Indeed :) Anyone have tips on integrating this with Drupal 5.x? Can
jquery-update module handle it?

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...

--
Adrian Simmons (aka adrinux) <http://perlucida.com>
e-mail <mailto:***@perlucida.com>
Konstantin Käfer
2007-09-11 11:35:34 UTC
Permalink
> 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/
Moshe Weitzman
2007-09-11 11:54:16 UTC
Permalink
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 <***@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/
>
>
>
>
Guard][an
2007-09-11 12:11:38 UTC
Permalink
Konstantin Käfer wrote:
> 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.
>

isn't this the case already ? http://drupal.org/project/ui
Konstantin Käfer
2007-09-11 13:17:35 UTC
Permalink
> 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/
Fernando Silva
2007-09-11 16:54:06 UTC
Permalink
I complete agree.

In fact we already had the http://drupal.org/project/jquery that seems
to me much more wider and with better perspectives: a module where
jquery plugins can be installed.

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"!

Regards,
Fernando Silva

On 9/11/07, Konstantin Käfer <***@gmail.com> wrote:
>
> > 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/
adrian rossouw
2007-09-11 17:50:17 UTC
Permalink
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
2007-09-11 17:58:58 UTC
Permalink
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.
***@ngpsoftware.com
(202) 686-9330
http://www.ngpsoftware.com
Kevin Reynen
2007-09-11 18:19:34 UTC
Permalink
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 <***@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.
> ***@ngpsoftware.com
> (202) 686-9330
> http://www.ngpsoftware.com
>
Karoly Negyesi
2007-09-11 18:08:53 UTC
Permalink
> 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.
Johan Forngren
2007-09-11 18:28:58 UTC
Permalink
On 9/11/07, Karoly Negyesi <***@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/
Brandon Bergren
1970-01-01 00:00:00 UTC
Permalink
On Tue, 11 Sep 2007, Johan Forngren wrote:

> On 9/11/07, Karoly Negyesi <***@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.
>
>

The problem is that Drupal (or anything running as the webserver user)
must not have ACCESS to write to these
directories.


--
>From the mailer of
|_|0|_| B R A N D O N B E R G R E N
|_|_|0| T e c h n i c a l
|0|0|0| G e n e r a l i s t ( C S )
Derek Wright
2007-09-11 18:43:47 UTC
Permalink
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.
Fernando Silva
2007-09-11 20:52:45 UTC
Permalink
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

2. select high usage and high quality jquery plugins, that allows the
perfection of 50% of Drupal contrib modules, and make those plugins as
part of the standard "jquery" contrib download module package (ex.
jQuery UI, jQuery.Flash, etc)

3. more than look to this module as a "user" module, it should be an
"admin" module with high usage during Drupal install. The idea is
simplify the install, helping the admin with automatic download of
jQuery plugins from their respectively repositories (we all know why)

4. thinking about the user, with the Drupal module system all these
plugins would appear with a visible note that would identify them
clearly has jQuery plugins

5. all these plugins would probably be downloaded and installed on the
"public files folder" after obeying to package verification and
validation.

Cases:
1. module "X" includes a flash file and requires jQuery.flash.js
1.1 download module "X" from Drupal
1.2 the user install it
1.3 the module detects it needs jQuery.flash and its not installed
1.4 automatically it "asks" jquery module API to request that plugin
1.5 if allowed, it is downloaded and module "X" is installed

2. an user wants to have a WYSIWM editor. It just go to the jquery
module, searchs and install the correspondent plugin

Regards,
Fernando Silva

On 9/11/07, Derek Wright <***@dwwright.net> wrote:
>
> 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?
>
Boris Mann
2007-09-11 21:05:57 UTC
Permalink
On 9/11/07, Fernando Silva <***@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
Fernando Silva
2007-09-11 23:06:32 UTC
Permalink
On 9/11/07, Boris Mann <***@bryght.com> wrote:
> What is a recommended module? We don't currently have any other than core....

It's a thing already discussed but never implemented. Basically it
would be part of a list with contrib modules ordered by rating,
reviews and recommendations.

Anyway, I don't see this module inside core until D8 -- despite the
fact that jquery.js is already and core, and the code necessary to do
a real jquery module would be minimal.

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

I real would like to work on this. But I still don't have enough
experience to know how I would gather a team. Specially I have some
difficulties with my English to write a good document to catch people.

Do you want to participate, perhaps like a "mentor", and help me with
some directions, on how would be best approach to work on this?

Thanks,
Fernando
Johan Forngren
2007-09-12 07:27:55 UTC
Permalink
On 9/11/07, Boris Mann <***@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
2007-09-11 20:55:28 UTC
Permalink
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.

fingers crosses,
-tao

Adrian Simmons wrote:
> Johan Forngren wrote:
>> http://docs.jquery.com/Release:jQuery_1.2
>
> Indeed :) Anyone have tips on integrating this with Drupal 5.x? Can
> jquery-update module handle it?
>
> 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...
>
Earl Miles
2007-09-11 21:09:45 UTC
Permalink
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.
Tao Starbow
2007-09-12 01:50:17 UTC
Permalink
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
2007-09-12 02:08:43 UTC
Permalink
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
***@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
Neil Drumm
2007-09-12 05:38:09 UTC
Permalink
On 9/11/07, Larry Garfield <***@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?

--
Neil Drumm
http://delocalizedham.com
Larry Garfield
2007-09-12 06:15:03 UTC
Permalink
On Wednesday 12 September 2007, Neil Drumm wrote:
> On 9/11/07, Larry Garfield <***@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
***@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
Earnie Boyd
2007-09-12 11:28:05 UTC
Permalink
Quoting Larry Garfield <***@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.
>

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.

Earnie -- http://for-my-kids.com/
-- http://give-me-an-offer.com/
Larry Garfield
2007-09-12 15:07:37 UTC
Permalink
On Wed, 12 Sep 2007 07:28:05 -0400, Earnie Boyd <***@users.sourceforge.net> wrote:
> Quoting Larry Garfield <***@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
Earnie Boyd
2007-09-12 19:05:52 UTC
Permalink
Quoting Larry Garfield <***@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/
William Smith
2007-09-12 19:28:44 UTC
Permalink
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 <***@users.sourceforge.net> wrote:
>
> Quoting Larry Garfield <***@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
2007-09-12 20:31:21 UTC
Permalink
jQuery 1.2 is in Drupal 6 now.

http://drupal.org/cvs?commit=81013
Gregory 'guardian' Pakosz
2007-09-12 20:55:51 UTC
Permalink
Khalid Baheyeldin wrote:
> jQuery 1.2 is in Drupal 6 now.
>
> http://drupal.org/cvs?commit=81013

congratulations!
Steven Peck
2007-09-12 21:10:17 UTC
Permalink
On 9/12/07, Khalid Baheyeldin <***@2bits.com> wrote:
> jQuery 1.2 is in Drupal 6 now.
>
> http://drupal.org/cvs?commit=81013
>
Someone should roll a patch against the changelog.txt indicating JQuery 1.2

Steven Peck
Larry Garfield
2007-09-12 21:17:58 UTC
Permalink
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" <***@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 <***@users.sourceforge.net> wrote:
>>
>> Quoting Larry Garfield <***@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/
>>
>>
>
>
Derek Wright
2007-09-12 22:39:55 UTC
Permalink
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:

a) allow checking for updates on modules that are present on a site
but not enabled (i think there's already a feature request about
this, in fact)

b) allow it to find .info files directly, not just the .info files
associated with modules (and, in D6 update.module, themes), so that
*anything* with a well-formed .info file could be included in the
available updates report.

Cheers,
-Derek (dww)
Larry Garfield
2007-09-13 01:24:22 UTC
Permalink
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
***@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
Earnie Boyd
2007-09-13 12:33:06 UTC
Permalink
Quoting William Smith <***@gmail.com>:

> 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.
>

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?

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.

Earnie -- http://for-my-kids.com/
-- http://give-me-an-offer.com/
Fernando Silva
2007-09-13 13:14:02 UTC
Permalink
On 9/13/07, Earnie Boyd <***@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....
Peter Wolanin
2007-09-13 13:22:43 UTC
Permalink
Um, perhaps you all have not seen previous threads about the hazards
of allowing executable code in a writeable directory?

-Peter

On 9/13/07, Fernando Silva <***@gmail.com> wrote:
> On 9/13/07, Earnie Boyd <***@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....
>
Fernando Silva
2007-09-13 13:45:25 UTC
Permalink
It's not executable code. It's jQuery javascript files.

On 9/13/07, Peter Wolanin <***@gmail.com> wrote:
> Um, perhaps you all have not seen previous threads about the hazards
> of allowing executable code in a writeable directory?
Jeff Eaton
2007-09-13 14:03:16 UTC
Permalink
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 <***@gmail.com> wrote:
>> Um, perhaps you all have not seen previous threads about the hazards
>> of allowing executable code in a writeable directory?
Steven Jones
2007-09-13 14:21:27 UTC
Permalink
How would this module be different from uploading a .js file to the
/files directory using upload module?

On 13/09/2007, Jeff Eaton <***@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 <***@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
Jeff Eaton
2007-09-13 14:38:35 UTC
Permalink
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 <***@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 <***@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
Steven Jones
2007-09-13 15:41:18 UTC
Permalink
But the javascript files were going in the /files directory, no?

On 13/09/2007, Jeff Eaton <***@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 <***@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 <***@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
Larry Garfield
2007-09-13 16:24:16 UTC
Permalink
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.

My original proposal was that the admin would manually upload jquery.fancyplugin.js to sites/default/modules/jquery/plugins/, and it would then either:

1) Show up in an admin page at admin/build/plugins where they can be toggled on or off.

2) Be activated if any module that implements hook_jquery() returns array('fancyplugin');

Anything fancier than that (inter-plugin dependency, version control, etc.) would require some support from the jquery folks, which we'd need to talk to them about.

--Larry Garfield

On Thu, 13 Sep 2007 16:41:18 +0100, "Steven Jones" <***@gmail.com> wrote:
> But the javascript files were going in the /files directory, no?
>
> On 13/09/2007, Jeff Eaton <***@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 <***@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 <***@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
Jeff Eaton
2007-09-13 17:23:11 UTC
Permalink
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.
Gábor Hojtsy
2007-09-13 16:39:38 UTC
Permalink
On 9/13/07, Steven Jones <***@gmail.com> wrote:
> But the javascript files were going in the /files directory, no?

This was the question we replied to:

> 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.

This is not about the files directory.

Gabor
Earnie Boyd
2007-09-14 00:34:35 UTC
Permalink
Quoting Jeff Eaton <***@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/
Derek Wright
2007-09-14 01:11:29 UTC
Permalink
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.
David Metzler
2007-09-14 04:50:43 UTC
Permalink
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.
>
>
>
Earl Miles
2007-09-14 16:02:27 UTC
Permalink
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.
David Metzler
2007-09-15 01:30:32 UTC
Permalink
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.
Earl Miles
2007-09-15 07:05:16 UTC
Permalink
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.)
D G
2007-09-15 15:59:41 UTC
Permalink
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 <***@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.)
>
Earl Miles
2007-09-15 16:28:14 UTC
Permalink
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).
Dmitri G
2007-09-15 17:32:30 UTC
Permalink
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 <***@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).
>
Larry Garfield
2007-09-15 22:51:58 UTC
Permalink
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.

--Larry Garfield

On Sat, 15 Sep 2007 10:32:30 -0700, "Dmitri G" <***@gmail.com> wrote:
> 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 <***@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).
>>
>
>
Philippe Jadin
2007-09-16 08:05:30 UTC
Permalink
On 9/16/07, Larry Garfield <***@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
Dmitri G
2007-09-16 17:55:59 UTC
Permalink
On 9/16/07, Philippe Jadin <***@gmail.com> wrote:
>
> On 9/16/07, Larry Garfield <***@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 ?


OOH. Same idea here. I don't want auto-install them. But other people do.


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.


I was thinking that modules can define hook_jquery_plugins, which will
auto-register the filenames and check if they exist (admins will download UI
to sites/all/scripts). Then other modules could call jquery_include('ui',
'resizables') which would auto-include the resizables (from the UI module)
and everything it depends on.

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
>
Frando
2007-09-14 11:23:22 UTC
Permalink
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.
Jeff Eaton
2007-09-14 12:09:59 UTC
Permalink
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.

--Jeff
Earnie Boyd
2007-09-14 15:16:25 UTC
Permalink
Quoting Jeff Eaton <***@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/
Jeff Eaton
2007-09-14 15:21:29 UTC
Permalink
On Sep 14, 2007, at 10:16 AM, Earnie Boyd wrote:

> 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.

*THIS* sounds like an excellent idea. I have no problems with it. I
think it's awesome.

--Jeff
Kevin Reynen
2007-09-14 15:51:41 UTC
Permalink
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 <***@users.sourceforge.net> wrote:
>
> Quoting Jeff Eaton <***@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/
>
>
Larry Garfield
2007-09-14 16:55:26 UTC
Permalink
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" <***@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 <***@users.sourceforge.net> wrote:
>>
>> Quoting Jeff Eaton <***@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/
>>
>>
>
>
Kevin Reynen
2007-09-14 17:48:55 UTC
Permalink
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 <***@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" <***@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 <***@users.sourceforge.net> wrote:
> >>
> >> Quoting Jeff Eaton <***@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/
> >>
> >>
> >
> >
>
>
Earnie Boyd
2007-09-14 20:15:30 UTC
Permalink
Quoting Kevin Reynen <***@gmail.com>:

>
> 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?
>

The answer to this would be easy if we used the systems already in
place. What if we have a js/ directory for our jQuery modules
(plugins) and it becomes one of the directories that the module system
searches for .info files. Then your module would simply depend on the
js module. I know Larry didn't want to have to add to the package but
the controls already exist for .info files.

> 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?
>

If we go this route the jquery or jquery_plugin module would have to
provide a dependency check for the module system.

> I'd love to see the process for installing modules that require two step
> installs standardized.
>

That is the reason I entered this thread to begin with.

Earnie -- http://for-my-kids.com/
-- http://give-me-an-offer.com/
Frando
2007-09-14 12:25:50 UTC
Permalink
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.
Jeff Eaton
2007-09-14 12:32:53 UTC
Permalink
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.).
Fernando Silva
2007-09-14 13:01:07 UTC
Permalink
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 <***@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.
David Norman
2007-09-14 12:50:00 UTC
Permalink
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.).
>
Earl Miles
2007-09-14 16:04:27 UTC
Permalink
David Norman wrote:
> 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?

It's not about what's best for you, it's about what's best for the
product. The comparison to government censorship/nanny doesn't work.

Please don't conflate the two.
Earnie Boyd
2007-09-14 14:10:35 UTC
Permalink
Quoting Jeff Eaton <***@viapositiva.net>:

> 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.
>

It wasn't me and I missed the suggestion. This is different than
allowing the administrator to upload a file to the files/jquery
directory.

Earnie -- http://for-my-kids.com/
-- http://give-me-an-offer.com/
Earnie Boyd
2007-09-14 13:01:53 UTC
Permalink
Quoting Derek Wright <***@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/
adrian rossouw
2007-09-16 22:20:42 UTC
Permalink
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.
Dmitri G
2007-09-17 01:13:55 UTC
Permalink
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 <***@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.
>
>
Fernando Silva
2007-09-13 14:38:45 UTC
Permalink
Ok. You had your sarcastic point.

Could you now step back, and explain me something so I can learn
instead of just being mocked?

On 9/13/07, Jeff Eaton <***@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 <***@gmail.com> wrote:
> >> Um, perhaps you all have not seen previous threads about the hazards
> >> of allowing executable code in a writeable directory?
>
>
Daniel F. Kudwien
2007-09-13 15:23:45 UTC
Permalink
> 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
Gerhard Killesreiter
2007-09-13 14:33:20 UTC
Permalink
Daniel F. Kudwien schrieb:
>> 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.

Successful? My ass. Some stupid script kiddie managed to hack "my"
server because I let a friend run Joomla there and one of its components
allowed remote file uploads.

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.

Sadly, I still had to spend a night to cleanly set up the machine again.

> Could someone please direct me/us to some einlightening issues and/or
> threads? That would be greatly appreciated.

Isn't the fact that it has bit me once good enough? :p

Cheers,
Gerhard
Daniel F. Kudwien
2007-09-13 15:46:18 UTC
Permalink
> 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
Gábor Hojtsy
2007-09-13 15:36:46 UTC
Permalink
On 9/13/07, Daniel F. Kudwien <***@unleashedmind.com> 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.
>
> Could someone please direct me/us to some einlightening issues and/or
> threads? That would be greatly appreciated.

Consider this:

- a PHP script has write access to your module folders (where PHP
scripts reside)
-> if any small remote injection vulnerability is found in Drupal or
any module you use, anyone can plant arbitrary PHP scripts on your
site
-> even if your system is "100% secure", if you are on a shared host,
most of the time you get a PHP process which runs under the same user
name/permission for all sites... if there is any vulnerability in any
of the other sites, anyone can plant arbitrary PHP scripts on your
system
-> alternatively people whom you share your server with can write
targeted code to easily plant arbitrary PHP scripts in your webroot

In short: As long as PHP scripts are allowed to write directories,
where PHP scripts are stored, any PHP script running on the server can
write to that directory, either on purpose or by exploiting security
holes.

Gabor
Earl Miles
2007-09-13 15:38:31 UTC
Permalink
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.
Derek Wright
2007-09-13 16:47:28 UTC
Permalink
On Sep 13, 2007, at 8:38 AM, Earl Miles wrote:

> Ordinarily, code is not writeable by the webserver user

Argh, if only that were true. :(

http://www.lullabot.com/blog/
dreamhost_alternatives_drupal_developers#comment-2528

-Derek (dww)
Earnie Boyd
2007-09-14 00:26:54 UTC
Permalink
Quoting Earl Miles <***@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/
adrian rossouw
2007-09-16 22:09:59 UTC
Permalink
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.
Earnie Boyd
2007-09-17 12:34:38 UTC
Permalink
Quoting adrian rossouw <***@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/
Matt Farina
2007-09-11 13:23:17 UTC
Permalink
<HTML>
http://drupal.org/node/174708<br>
<br>
I think 1.2 will break some things but we need it.<br>
<br>
Matt<br>
<br>
<span style="font-weight: bold;">On Tue Sep 11 06:17 , Konstantin Käfer) <***@gmail.com> sent:<br>
</***@gmail.com></span><blockquote style="border-left: 2px solid rgb(245, 245, 245); margin-left: 5px; margin-right: 0px; padding-left: 5px; padding-right: 0px;">
<br>

<span style="color: red;">&gt; isn't this the case already ? <a href="parse.php?redirect=http%3A%2F%2Fdrupal.org%2Fproject%2Fui" target="_blank"><span style="color: red;">http://drupal.org/project/ui</span></a>
</span><br>


<br>

There you go.
<br>


<br>

Moshe: I am not opposed to getting jQuery 1.2 into Drupal 6, I am
<br>

opposed to including jQuery UI (something different) in Drupal.
<br>


<br>

Konstantin Käfer -- <a href="parse.php?redirect=http%3A%2F%2Fkkaefer.com%2F" target="_blank"><span style="color: red;">http://kkaefer.com/</span></a>
<br>


<br>


<br>


<br>

<br>

</blockquote><BR></HTML>
Karoly Negyesi
2007-09-11 18:40:39 UTC
Permalink
> 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!
Earl Miles
2007-09-11 18:48:31 UTC
Permalink
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.
Gerhard Killesreiter
2007-09-11 19:15:43 UTC
Permalink
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.

Unfortunately, as Derek pointed out, jQuery's plugins aren't as
centralized as our modules, so we should try to release with the latest
stable version.

Cheers,
Gerhard
Gábor Hojtsy
2007-09-11 19:38:08 UTC
Permalink
On 9/11/07, Gerhard Killesreiter <***@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
Continue reading on narkive:
Loading...