[wp-hackers] Upgrade sanity checks

Peter Westwood peter.westwood at ftwr.co.uk
Wed Feb 27 21:18:22 GMT 2008


On 27 Feb 2008, at 21:06, Matt Mullenweg wrote:

> Otto wrote:
>> One way would be to have it load some other file which is a list of
>> all the WordPress files, then check (and potentially hash) them  
>> all to
>> ensure that they are unchanged. Every time a new release occurred,
>> that file would need to be generated as part of the release process.
>> Of course, you would want a failure to not *stop* the upgrade, but to
>> get confirmation. The best user experience would be to put up a
>> warning message saying "These WordPress files don't appear to be the
>> correct versions: (list of files here). Proceed with upgrade anyway?
>> WARNING: Proceeding may cause unexpected results! Do not proceed
>> without knowing what you're doing. (Proceed / For the love of god
>> stop!)"
>
> I think that's a great idea.


I discussed the idea of exposing the hashs with matt last year.

When I looked into implementing something to be deployed on wp.org I  
found to my delight that svn gives us everything we need already!

peter at epia (wireless:S.4) trunk 0 0.21 s $ svn info wp-blog-header.php
...
Checksum: 9f85abee432181b0b8e8f28310cff11b

peter at epia (wireless:S.4) trunk 0 0.16 s $ curl http:// 
svn.automattic.com/wordpress/trunk/wp-blog-header.php --request PROPFIND
<?xml version="1.0" encoding="utf-8"?>
...
<lp2:md5-checksum>9f85abee432181b0b8e8f28310cff11b</lp2:md5-checksum>
...

peter at epia (wireless:S.4) trunk 0 0.19 s $ md5sum wp-blog-header.php
9f85abee432181b0b8e8f28310cff11b  wp-blog-header.php


So if we want to expose the info it is very easy to get at.

Anyone fancy writing something which uses the last one to validate an  
install based on the svn tag?

westi
-- 
Peter Westwood
http://blog.ftwr.co.uk | http://westi.wordpress.com
  C53C F8FC 8796 8508 88D6 C950 54F4 5DCD A834 01C5






More information about the wp-hackers mailing list