Remove MD5sum checking
jabapyth - October 2, 2008 - 01:20
| Project: | Plugin Manager |
| Version: | 6.x-1.x-dev |
| Component: | User interface |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
Description
so I figured out a way to get PM to check the md5sums through AJAX, but it requires patching d.o's project module. What is needed is an extra URL that gives md5sums in JSON format
e.g. where "drupal.org/node/231441" is a project release, "drupal.org/node/231441/checksum" would output:
drupal_checksum(231441, "c5e9e2f9ca2aa217968e40f80136fd32"); // <-- the md5sum for that releaseI'm in the process of making a patch that will accomplish this.
With this functionality in place, it would then be simple to have javascript harvest the hashes, completely eliminating that cumbersome step from the install process.
My question is: how likely is it that I will get that patch into "project", and if it is, how long till the change is live on drupal.org? Does anyone know?
#1
Whether this is safe or not...my understanding is that the AJAX to pull down that data will run inside of the site admin browser using the site admin's network (i.e. the site admin's DNS) to get the data. This separates it from the server getting the md5 which means that we should be OK. So, that part of it seems OK.
Getting it into project and getting it deployed can happen very quickly. In order to make it happen, you need to make sure that it is "secure" and that the performance of this lookup is good. Secure should be fairly easy: md5s of files are not exactly sensitive information so this could run inside of a custom script that uses a partial bootstrap to get the data. Hopefully it's just a query on a single table indexed by nid which should be really fast. If it could be cached by squid somehow then even better.
I still think that a visual confirmation on the part of the user would be good. If the iframe solution is maintained along with this then we can at least say "please confirm the md5 has been pulled in properly before continuing."
Those are my initial thoughts on this. Thanks for the effort to make this simple for users.
#2
Oh, my aspirations go far beyond merely filling in the form w/ ajax ;)
In my ideal world, installing plugins would be a 2-step process. An admin would first search for plugins, and then enter the FTP/SSH password. After that, they could sit back and watch as a sleek javascript progress bar details the current progress of installation, or more likely switch to another tab and get back to work. If this patch goes through, there will be no more barriers to me realizing this dream.
You were right that getting the md5sum would be no harder than a single sql request. I hope to finalize my patch within the next few days.
#3
disclaimer: I still haven't studied the plugin_manager code, so I'm not sure about anything on that side, and can't yet comment on the security of any of that.
some random thoughts:
a) yes, a reasonable patch that did this would go in and be deployed quickly. we already print the md5 hashes on the release nodes, so I have no problem providing this info.
b) I'm slightly confused why you need a separate AJAX handler for this -- the md5 hashes are already included in the XML files used by update.module to see if you're missing an update in the first place. I haven't thought about this closely yet, but it's not obvious why asking for the same data again is any more secure.
c) we'd like to move project_release away from the idea that it only has a single file with a single md5 checksum. :( See #179471: release file attachments should use drupal upload functionality. so, i don't think it's a good idea to commit a patch like this directly to project_release.module.
d) if it's still necessary at all, it seems trivial to provide this menu handler via the drupal.org customizations module. So, you can do something d.o-specific that assumes single-file-per-release without making more of those assumptions in project_release itself.
#4
@dww
a) awesome
b) see http://drupal.org/node/292920#comment-1009702 comments #8 and #9. In short, having both the server and client get the md5sum would be safer from DNS poisoning.
c&d) i didn't know about d.o specific customizations before, but is seems like a great solution. do I just make a patch directly from the cvs drupal code? or the cvs drupal 5 code?
#5
there are no branches of the drupalorg directory in CVS. just roll a patch against HEAD.
#6
Im really not sure what I need to do here. I have created a patch against the main source for the "project_release.module". Should I now create an issue in d.o customizations?
#7
Kind of. The patch should be against drupalorg.module if possible - http://drupal.org/project/issues/drupalorg
#8
Fixed in latest commit.
#9
@JoshuaRogers: "latest commit" to what branch of what module? ;) Please be more specific so people who care about this issue can figure out what's going on without a lot of extra work. Thanks.
#10
Revision 1.52.2.85 of the Drupal-6--1 branch.
#11
http://drupal.org/cvs?commit=259836
"#401616 by JoshuaRogers: Remove md5sum checking."
The diff looks like you just removed all the code related to this feature... I like your definition of "fixed". ;) *shrug*
#12
Yeah. I suppose I should have changed the title too. ;) Sorry. Probably should have created a new issue instead of trying to force one to fit.