Re: [Tikiwiki-devel] Announcing security fixes

[danny s. <da...@or...>]

On 15/07/06, Marc Laporte <ma...@ma...> wrote:
> Hi mose & all,
>
> "Kids are faster than web maintainers."
>
> This is certainly something we should try to address.
>
> I think with a little work, we can make great progress here. I see two
> avenues.
>
> #1 Making site admins aware they must upgrade
> For example, we could add in the admin control panel (tiki-admin.php) an
> RSS feed of our releases. And/or, a check which turns the panel to
> another color when the Tiki needs to be updated. Yellow when a normal
> upgrade is available. And red when a security fix is required.
>
> I think this would have a side effect of attracting more traffic to our
> *.tikiwiki.org sites and in turn more contributors.
>
> Another side effect, is that we could have some reliable stats on how
> many Tiki sites exist and which versions they are using. We could
> provide an option for them to turn this off.  We could even of them
> sharing info about which features are activated. It would be nice to
> know what % of Tiki sites are using which feature. This can be useful
> information when working on a feature.
>
> #2 Making it easier to upgrade.
> It is not obvious that to upgrade a Tiki, you need to go to tiki-install.php
>
> Perhaps, we could have a tiki-upgrade.php. Here only, the DB upgrade
> scripts would be offered. To be even nicer, we could have a check to see
> in DB needs updating or is already at last version. Here we could have
> clear, simple step-by-step instructions. I will write them if someone
> can help me with the coding. Something like:
>
> #1 click here to download
> #2 unzip the folder over your exisiting installation
> #3 delete x,y,z files (if necessary)
> #4 click here to upgrade your DB (if necessary)
> #5 click here to clear your Smarty cache (templates_c)
> #6 enjoy!
>
> I would also add links to documentation & strategies on how to modify
> Tiki and it still be easy to upgrade.
>
> I think this would also have a side effect of attracting more traffic to
> our *.tikiwiki.org sites and in turn more contributors. More people
> would take advantage of the enhancements and this will increase Tiki's
> Karma.
>
> Best regards,
>
> M ;-)
>

Okay, taking on board both Mose, and Marcus talk about upgrades, and I
definately understand the importance of gettign security updates, how
about a mechanism for making security only patches (a stream for these
hotfixes - which are backported for 3/4 versions of tiki to avoid
having to deal with content problems - which I personally *have*
experienced), and then having an admin panel tool that will not only
check for critical updates, but offer you the ability to download them
from tiki, and install them, with a few clicks. This would also
require signing,  and md5, so the update would include metadata like
an md5sum, who created it. Admins using this facility would then put a
set of patch author pgp keys into their tiki db, which would be used
to check and validate patches from tw.o. This would take some work,
but could really improve the stream of security fixes. Of course, this
is aimed at those using hosting, for Marcus, it would be a case of
using the same patch stream to create backports for the Distro
version.

Updating the whole of tiki, instead of just security fixes, takes a
whole saturday afternoon for me generally, as I have suffered before
by not fully testing and finding issues a week or two later while
vistors have been bounced from the site. I now have a fairly long test
script, which involves me creating a running instance of the whole of
my site on a secondary test site, testing everything first to make
sure no artefacts have crept in from this process, then installing the
upgrade, and then testing everything again. My script goes through
wiki, blog, articals, RSS, modules, plugins, mailout, forums and for
each component, reading, editing, adding new, renaming, removing etc.
For modules and plugins, I put the packaged ones, and my own through
their paces, to make sure they havent been broken by other changes and
that they still work. I also generally diff things like the default
tiki styles, and templates against the previous version to see if mine
need to be updated to accomodate new behaviour.

So having "critical only" patches to sort out a security flaw until I
have time to set aside the 4/5 hours it takes to safely update OR
without loosing any functionality would be really handy. This is also
another reason to spend time on getting mods really sorted. I would
love only to need to update certain mods and not the whole of tiki to
get new features. A similar signing method would be nice for those
too.

On related note, I am starting to think of turning some parts of my
testing into automated tests, and may look at how difficult it would
be to create unit tests for some component, which validate the output
HTML against what I expected. Only after my current raft of
plugins/mods/improvements I am working on. Take a look at
tikiwiki-enhanc on berlios.de
(http://developer.berlios.de/projects/tikiwiki-enhanc/).

Cheers,
Danny
-- 
Danny Staple MBCS
OrionRobots
http://orionrobots.co.uk/blogs/dannystaple
(Full contact details available through website)