* Advisory ID: DRUPAL-SA-CORE-2014-004

[paul]

View online: ​https://www.drupal.org/SA-CORE-2014-004

• Advisory ID: DRUPAL-SA-CORE-2014-004
• Project: Drupal core [1]
• Version: 6.x, 7.x
• Date: 2014-August-06
• Security risk: 13/25 ( Moderately Critical)

AC:None/A:None/CI:None/II:None/E:Proof/TD:100 [2]

• Exploitable from: Remote
• Vulnerability: Denial of service

---

---

Drupal 6 and Drupal 7 include an XML-RPC endpoint which is publicly available
(xmlrpc.php). The PHP XML parser used by this XML-RPC endpoint is vulnerable
to an XML entity expansion attack and other related XML payload attacks which
can cause CPU and memory exhaustion and the site's database to reach the
maximum number of open connections. Any of these may lead to the site
becoming unavailable or unresponsive (denial of service).

All Drupal sites are vulnerable to this attack whether XML-RPC is used or
not.

In addition, a similar vulnerability exists in the core OpenID module (for
sites that have this module enabled).

This is a joint release as the XML-RPC vulnerability also affects WordPress
(see the announcement [3]).

---

---

• /A CVE identifier [4] will be requested, and added upon issuance, in

accordance
with Drupal Security Team processes./

---

---

• Drupal core 7.x versions prior to 7.31.
• Drupal core 6.x versions prior to 6.33.

---

---

Install the latest version:

• If you use Drupal 7.x, upgrade to Drupal core 7.31 [5].
• If you use Drupal 6.x, upgrade to Drupal core 6.33 [6].

If you are unable to install the latest version of Drupal immediately, you
can alternatively remove the xmlrpc.php file from the root of Drupal core (or
add a rule to .htaccess to prevent access to xmlrpc.php) and disable the
OpenID module. These steps are sufficient to mitigate the vulnerability in
Drupal core if your site does not require the use of XML-RPC or OpenID
functionality. However, this mitigation will not be effective if you are
using a contributed module that exposes Drupal's XML-RPC API at a different
URL (for example, the Services module); updating Drupal core is therefore
strongly recommended.

Also see the Drupal core [7] project page.

---

---

• Willis Vandevanter [8]
• Nir Goldshlager [9]

---

---

• Andrew Nacin [10] of the WordPress Security Team
• Michael Adams [11] of the WordPress Security Team
• Frédéric Marand [12]
• David Rothstein [13] of the Drupal Security Team
• Damien Tournoud [14] of the Drupal Security Team
• Greg Knaddison [15] of the Drupal Security Team
• Stéphane Corlosquet [16] of the Drupal Security Team
• Dave Reid [17] of the Drupal Security Team

---

---

• The Drupal Security Team [18] and the WordPress [19] Security Team

---

---

The Drupal security team can be reached at security at drupal.org or via the
contact form at ​http://drupal.org/contact [20].

Learn more about the Drupal Security team and their policies [21], writing
secure code for Drupal [22], and securing your site [23].

[1] ​http://drupal.org/project/drupal
[2] ​http://drupal.org/security-team/risk-levels
[3] ​https://wordpress.org/news/2014/08/wordpress-3-9-2/
[4] ​http://cve.mitre.org/
[5] ​http://drupal.org/drupal-7.31-release-notes
[6] ​http://drupal.org/drupal-6.33-release-notes
[7] ​http://drupal.org/project/drupal
[8] ​https://www.drupal.org/user/1867894
[9] ​https://www.drupal.org/user/2891345
[10] ​http://profiles.wordpress.org/nacin
[11] ​http://profiles.wordpress.org/mdawaffe
[12] ​https://www.drupal.org/user/27985
[13] ​https://www.drupal.org/user/124982
[14] ​https://www.drupal.org/user/22211
[15] ​https://www.drupal.org/u/greggles
[16] ​https://www.drupal.org/user/52142
[17] ​https://www.drupal.org/user/53892
[18] ​http://drupal.org/security-team
[19] ​http://wordpress.org
[20] ​http://drupal.org/contact
[21] ​http://drupal.org/security-team
[22] ​http://drupal.org/writing-secure-code
[23] ​http://drupal.org/security/secure-configuration

_
Security-news mailing list
Security-news@…
Unsubscribe at ​https://lists.drupal.org/mailman/listinfo/security-news

[paul]

@Annesley

Let me know if you need any help.

[chris]

Annesley this looks like it really needs to be done today, or if you are going to postpone updating Drupal core then you need to add Nginx config to deny access to xmlrpc.php. If you need help with the Nginx config let me know. This also affects WordPress, I'm going to look at the sites on ParrotServer now.

[chris]

Note that this issue affects all the Drupal sites on wiki:PuffinServer -- it appear to me that any development sites which are not password protected should also updated.

[annesley]

does anyone know what is the likelihood of TN.org being the victim of a DDOS or DOS attack?

because DDOS and DOS are not automated, they are individual hackers using it to gain access to banks etc. we are not a target. is this correct? so i put it at 0.00000000001% chance of it happening over the next 5 years.

how long would it take us (downtime) to solve it in the case of a DOS? 5 hours?
do our IP chains / firewall protect against this? (i think not in this case anyway)

if it did we could ignore all further DOS Drupal holes. worth installing IP chains burst protection? (excuse my lack of precise knowledge here but you get what i am saying)

we seem to have OpenID Module there, but not installed.
we are using Services_Links but not Services.

@chris: do we have a dedicated server or virtual? is there risk to the other sites that you host or from?

i am not against deleting the XMLRPC.php file however. i think we are not providing any XML based services anyway...? have i understood it's role correctly?

[paul]

@Annesley

We're not using Services or Open ID contrib modules.
On the stage servers I think we can just remove the xmlrpc.php files.

[annesley]

hmm... mind you, this sort of attack could certainly be very easily automated. even if it hasn't been. a script kiddy could achieve this XML entity expansion attack because it is so simply to do. it doesn't require multi-threaded requests or normal DOS procedures, it's just a recursive entity definition in the DTD of the XML RPC request.

we should delete XMLRPC.php today then. we have no need to expose Remote Procedure Calls anyway AFAIK. and no intention to do this.

[annesley]

@chris: could you handle the deletion of this file? is that within your role?

thanks :)

[annesley]

@Paul: we do have OpenID Module on the server though...
it's showing as "not installed" from drush

[annesley]

ok, it seems that removing XMLRPC.php removes the OpenID core module vulnerability as well. according to my understanding...

[paul]

The security team advice that the module just needs to be disabled on the server:

If you are unable to install the latest version of Drupal immediately, you
can alternatively remove the xmlrpc.php file from the root of Drupal core (or
add a rule to .htaccess to prevent access to xmlrpc.php) and disable the
OpenID module.

[chris]

The ​security advisory says:

The PHP XML parser used by this XML-RPC endpoint is vulnerable to an XML entity expansion attack and other related XML payload attacks which can cause CPU and memory exhaustion and the site's database to reach the maximum number of open connections. Any of these may lead to the site becoming unavailable or unresponsive (denial of service).

Since this also applies to WordPress it is bound to result in a lot of attention being devoted to any possible automated exploits so it would be sensible to take steps to mitigate the risk. I don't know what the exact potential is for "XML payload attacks" but it is worth noting that we were at the limit of max MySQL connections with the default BOA config until it was increased 6 weeks ago, see ticket:587#comment:17, currently we have 39 with a max of 50:

• ​https://penguin.transitionnetwork.org/munin/transitionnetwork.org/puffin.transitionnetwork.org/mysql_connections.html

There are 54 copies of xmlrpc.php on the server. We can't use .htaccess files because we are not using Apache.

It is a virtual server, see: wiki:PuffinServer#Puffin

[paul]

Replying to annesley:

ok, it seems that removing XMLRPC.php removes the OpenID core module vulnerability as well. according to my understanding...

There are two similar vulnerabilities that exists in XML-RPC and the core OpenID module. They probably have some shared code between them.

[paul]

@Annesley @Chris

I think we can just delete all of these xmlrpc.php files?

[chris]

Replying to paul:

I think we can just delete all of these xmlrpc.php files?

I can do that if you think it is safe to do so, note that some xmlrpc.php files will get recreated by things like the next BOA update, ticket:775

[chris]

Added Ed as a Cc.

[paul]

Good. Thanks Chris.

@Annesley

Maybe delete the xmlrpc.php file now and then follow up with building a new platform for production?

[paul]

Replying to paul:

Good. Thanks Chris.

@Annesley

Maybe delete the xmlrpc.php files now (with help from Chris) and then follow up with building a new platform for production?

[annesley]

let me run a few checks before we delete it.

i will delete it on staging first and have a browse of course. but also check for references in the codebase.

[annesley]

grep -rsi xmlrpc.php *
includes/common.inc: * ​http://www.example.com/xmlrpc.php
modules/blogapi/blogapi.module: $xmlrpc = $base_url .'/xmlrpc.php';
sites/all/modules/contrib/robotstxt/robots.txt:Disallow: /xmlrpc.php

blog api is "not installed"

so i'll go ahead and delete it from staging now.

[paul]

Building a new platform with latest version of core and then migrating the live site over will fix the problem for the live site and will probably not take more than 15 minutes. So we can have this problem resolved for stage / production within the half hour I would say?

[annesley]

@paul: ok

staging seems fine without it's xmlrpc.php of course. there are no links to it except from blogapi.

[paul]

Cool. Many drupal sites just delete the xmlrpc.php from the server if it's not being used.

[paul]

@Chris

I think these are the version of xmlrpc.php that are not automatically generated by Aegir:

puffin:~# find / -name xmlrpc.php
/data/disk/tn/static/transition-network-d6-s011/xmlrpc.php
/data/disk/tn/static/transition-network-d6-p010-booker/xmlrpc.php
/data/disk/tn/static/transition-network-d6-s009/xmlrpc.php
/data/disk/tn/static/transition-network-d6-s008/xmlrpc.php
/data/disk/tn/static/transition-network-d6-s012/xmlrpc.php
/data/disk/tn/static/transition-network-d6-p009/xmlrpc.php
/data/disk/tn/static/transition-network-d6-32-p001-booker/xmlrpc.php

/data/disk/tn/static/iirs-d006/xmlrpc.php
/data/disk/tn/static/iirs-d007/xmlrpc.php
/data/disk/tn/distro/007/drupal-7.30.1-prod/xmlrpc.php
/data/disk/tn/distro/007/openatrium-7.x-2.19-7.30.1/xmlrpc.php
/data/disk/tn/distro/006/drupal-7.28.1-prod/xmlrpc.php
/data/disk/tn/distro/006/openatrium-7.x-2.19-7.28.1/xmlrpc.php
/data/disk/tn/distro/005/drupal-7.27.1-prod/xmlrpc.php
/data/disk/tn/distro/005/openatrium-7.x-2.17-7.27.1/xmlrpc.php
/data/disk/tn/distro/004/openatrium-7.x-2.09-7.24.1/xmlrpc.php
/data/disk/tn/distro/004/drupal-7.24.1-prod/xmlrpc.php
...

Do you have any thoughts on dealing with the second block? I'll deal with the first block now ..

[chris]

Replying to paul:

/data/disk/tn/static/iirs-d006/xmlrpc.php
/data/disk/tn/static/iirs-d007/xmlrpc.php
/data/disk/tn/distro/007/drupal-7.30.1-prod/xmlrpc.php
/data/disk/tn/distro/007/openatrium-7.x-2.19-7.30.1/xmlrpc.php
/data/disk/tn/distro/006/drupal-7.28.1-prod/xmlrpc.php
/data/disk/tn/distro/006/openatrium-7.x-2.19-7.28.1/xmlrpc.php
/data/disk/tn/distro/005/drupal-7.27.1-prod/xmlrpc.php
/data/disk/tn/distro/005/openatrium-7.x-2.17-7.27.1/xmlrpc.php
/data/disk/tn/distro/004/openatrium-7.x-2.09-7.24.1/xmlrpc.php
/data/disk/tn/distro/004/drupal-7.24.1-prod/xmlrpc.php
...

Do you have any thoughts on dealing with the second block?

I think the simplest and quickest thing would be to delete them. I don't know if they are available to the public and the Nginx config is really hard to follow so it would take a while to work out which, if any, are and then to add rules to deny access to the files and then any changes would probably be clobbered at some point...

[paul]

@Chris

Agreed. I'll do that shortly.

@TN

What I have done so far:

Deleted my earlier stage sites.
Built a new stage platform.
Migrated the latest version of the stage site over to the new platform.
Turned on the database log & checked the site is working.

The new production platform is now scheduled to be built. As soon as the platform is built I'll migrate the live site over to the new production platform...

[paul]

The live site is now migrated to the new production platform & seems to be working fine.

The only xmlrpc.php files that have not been updated or deleted are the aegir versions of the files.

puffin:~# find / -name xmlrpc.php
/data/disk/tn/static/transition-network-d6-33-p001-booker/xmlrpc.php
/data/disk/tn/static/transition-network-d6-33-s001-booker/xmlrpc.php
/data/disk/tn/aegir/distro/009/xmlrpc.php
/data/disk/tn/aegir/distro/011/xmlrpc.php
/data/disk/tn/aegir/distro/010/xmlrpc.php
/data/disk/tn/aegir/distro/008/xmlrpc.php
/data/disk/tn/platforms/transitionnetwork.org/xmlrpc.php
/data/all/000/core/pressflow-6.29.1/xmlrpc.php
/data/all/000/core/drupal-7.23.3/xmlrpc.php
/data/all/000/core/drupal-7.27.1/xmlrpc.php
/data/all/000/core/drupal-7.30.1/xmlrpc.php
/data/all/000/core/pressflow-6.32.2/xmlrpc.php
/data/all/000/core/drupal-7.28.1/xmlrpc.php
/data/all/000/core/drupal-7.24.1/xmlrpc.php
/data/all/000/core/pressflow-6.31.1/xmlrpc.php
/data/all/000/core/pressflow-6.31.2/xmlrpc.php
/data/all/000/core/pressflow-6.28.3/xmlrpc.php
/var/aegir/hostmaster-BOA-2.0.4/xmlrpc.php
/var/aegir/host_master/009/xmlrpc.php
/var/aegir/host_master/001/xmlrpc.php
/var/aegir/host_master/007/xmlrpc.php
/var/aegir/host_master/002/xmlrpc.php
/var/aegir/host_master/003/xmlrpc.php
/var/aegir/host_master/011/xmlrpc.php
/var/aegir/host_master/010/xmlrpc.php
/var/aegir/host_master/013/xmlrpc.php
/var/aegir/host_master/012/xmlrpc.php
/var/aegir/host_master/006/xmlrpc.php
/var/aegir/host_master/005/xmlrpc.php
/var/aegir/host_master/004/xmlrpc.php
/var/aegir/host_master/008/xmlrpc.php
/var/aegir/host_master/014/xmlrpc.php
/var/aegir/host_master/015/xmlrpc.php
/var/backups/trash/drupal-7.22.1/xmlrpc.php
/var/backups/codebases-cleanup/001/pressflow-6.26.2-dev/xmlrpc.php
/var/backups/codebases-cleanup/001/pressflow-6.26.2-stage/xmlrpc.php
/var/backups/codebases-cleanup/001/pressflow-6.26.2-prod/xmlrpc.php
/var/backups/codebases-cleanup/002/drupal-7.22.1-prod/xmlrpc.php
puffin:~#

[chris]

I think there might now be a few more due to the BOA update:

updatedb
locate xmlrpc.php
/data/all/000/core/drupal-7.23.3/xmlrpc.php
/data/all/000/core/drupal-7.24.1/xmlrpc.php
/data/all/000/core/drupal-7.27.1/xmlrpc.php
/data/all/000/core/drupal-7.28.1/xmlrpc.php
/data/all/000/core/drupal-7.30.1/xmlrpc.php
/data/all/000/core/drupal-7.31.1/xmlrpc.php
/data/all/000/core/pressflow-6.28.3/xmlrpc.php
/data/all/000/core/pressflow-6.29.1/xmlrpc.php
/data/all/000/core/pressflow-6.31.1/xmlrpc.php
/data/all/000/core/pressflow-6.31.2/xmlrpc.php
/data/all/000/core/pressflow-6.32.2/xmlrpc.php
/data/all/000/core/pressflow-6.33.1/xmlrpc.php
/data/disk/tn/aegir/distro/008/xmlrpc.php
/data/disk/tn/aegir/distro/009/xmlrpc.php
/data/disk/tn/aegir/distro/010/xmlrpc.php
/data/disk/tn/aegir/distro/011/xmlrpc.php
/data/disk/tn/aegir/distro/012/xmlrpc.php
/data/disk/tn/distro/008/drupal-7.31.1-prod/xmlrpc.php
/data/disk/tn/distro/008/openatrium-7.x-2.19-7.31.1/xmlrpc.php
/data/disk/tn/platforms/transitionnetwork.org/xmlrpc.php
/data/disk/tn/static/transition-network-d6-33-p001-booker/xmlrpc.php
/data/disk/tn/static/transition-network-d6-33-s001-booker/xmlrpc.php
/var/aegir/host_master/001/xmlrpc.php
/var/aegir/host_master/002/xmlrpc.php
/var/aegir/host_master/003/xmlrpc.php
/var/aegir/host_master/004/xmlrpc.php
/var/aegir/host_master/005/xmlrpc.php
/var/aegir/host_master/006/xmlrpc.php
/var/aegir/host_master/007/xmlrpc.php
/var/aegir/host_master/008/xmlrpc.php
/var/aegir/host_master/009/xmlrpc.php
/var/aegir/host_master/010/xmlrpc.php
/var/aegir/host_master/011/xmlrpc.php
/var/aegir/host_master/012/xmlrpc.php
/var/aegir/host_master/013/xmlrpc.php
/var/aegir/host_master/014/xmlrpc.php
/var/aegir/host_master/015/xmlrpc.php
/var/aegir/host_master/016/xmlrpc.php
/var/aegir/hostmaster-BOA-2.0.4/xmlrpc.php
/var/backups/codebases-cleanup/001/pressflow-6.26.2-dev/xmlrpc.php
/var/backups/codebases-cleanup/001/pressflow-6.26.2-prod/xmlrpc.php
/var/backups/codebases-cleanup/001/pressflow-6.26.2-stage/xmlrpc.php
/var/backups/codebases-cleanup/002/drupal-7.22.1-prod/xmlrpc.php
/var/backups/trash/drupal-7.22.1/xmlrpc.php

I don't know if any of these are available to the public?

[paul]

Thanks Chris. I'll investigate ..

[paul]

All the sites that are listed on Aegir have had their xmlrpc.php either removed or updated.

However, I had a look over all of the sites and noticed that we have three sites with public domains that are not being updated:

iirs-test.transitionnetwork.org Drupal 7.26
space.transitionnetwork.org Open Atrium 2.0.9 7.24.1 P.004 Drupal 7.24
news.transitionnetwork.org Drupal 6.29

Any thoughts on what should be done with these? Can any of these be deleted? The latest versions of Drupal are 6.33 & 7.31

I deleted the xmlrpc.php from this ghost platform:
/data/disk/tn/platforms/transitionnetwork.org/xmlrpc.php

I think all of the aegir files are just sitting on the server.

[chris]

Replying to paul:

we have three sites with public domains that are not being updated:

iirs-test.transitionnetwork.org Drupal 7.26
space.transitionnetwork.org Open Atrium 2.0.9 7.24.1 P.004 Drupal 7.24
news.transitionnetwork.org Drupal 6.29

Well spotted!

• ​http://news.transitionnetwork.org/ this is in use and as far as I'm aware should be updated, best check with Ed. The ticket on which it was migrated to PuffinServer is ticket:480, I would guess that it's code is in a git repo, perhaps use Drush to get a admin login to the site and check the status to start with?
• ​https://space.transitionnetwork.org/home this is a non-public site that Jim set up for Ed, I think it wasn't used, best check with Ed if it is needed. If it is then upgrading it should be straight forward as it shouldn't have many, (or any) plugins.
• ​http://iirs-test.transitionnetwork.org/ I don't know if Jim or Annesley set that up, best check with Ed and Annesley.

[paul]

For ​http://news.transitionnetwork.org/ I just need to migrate it to the new production platform. I'll do that now ..

[paul]

I'll migrate to stage first ..

[paul]

​​http://news.transitionnetwork.org/ is now updated to the latest production platform & we now have a clone of this site on a stage platfrom. Looking now into ​https://space.transitionnetwork.org/ ..

[paul]

Theres appears to be nothing documented about openatrium on the wiki / trac.

The current version of the open atrium site is here:

puffin:/data/disk/tn/distro/004/openatrium-7.x-2.09-7.24.1# ls -la
total 592K
drwxr-xr-x 4 tn users 4.0K Aug 7 19:09 ./
drwx--x--x 5 tn users 4.0K Nov 30 2013 ../
lrwxrwxrwx 1 tn users 46 Nov 30 2013 authorize.php -> /data/all/000/core/drupal-7.24.1/authorize.php
drwxrwsr-x 2 tn.ftp www-data 4.0K Jan 13 2014 cache/
lrwxrwxrwx 1 tn users 41 Nov 30 2013 cron.php -> /data/all/000/core/drupal-7.24.1/cron.php
lrwxrwxrwx 1 tn users 48 Nov 30 2013 crossdomain.xml -> /data/all/000/core/drupal-7.24.1/crossdomain.xml
-r--r--r-- 1 tn users 573K Aug 7 23:13 drushrc.php
lrwxrwxrwx 1 tn users 42 Nov 30 2013 .htaccess -> /data/all/000/core/drupal-7.24.1/.htaccess
lrwxrwxrwx 1 tn users 41 Nov 30 2013 includes -> /data/all/000/core/drupal-7.24.1/includes/
lrwxrwxrwx 1 tn users 42 Nov 30 2013 index.php -> /data/all/000/core/drupal-7.24.1/index.php
lrwxrwxrwx 1 tn users 44 Nov 30 2013 install.php -> /data/all/000/core/drupal-7.24.1/install.php
lrwxrwxrwx 1 root root 39 May 1 16:25 js.php -> /data/all/005/o_contrib_seven/js/js.php
lrwxrwxrwx 1 tn users 37 Nov 30 2013 misc -> /data/all/000/core/drupal-7.24.1/misc/
lrwxrwxrwx 1 tn users 40 Nov 30 2013 modules -> /data/all/000/core/drupal-7.24.1/modules/
lrwxrwxrwx 1 tn users 49 Nov 30 2013 profiles -> /data/all/004/openatrium-7.x-2.09-7.24.1/profiles/
drwxr-x--x 5 tn users 4.0K Jan 12 2014 sites/
lrwxrwxrwx 1 tn users 39 Nov 30 2013 themes -> /data/all/000/core/drupal-7.24.1/themes/
lrwxrwxrwx 1 tn users 43 Nov 30 2013 update.php -> /data/all/000/core/drupal-7.24.1/update.php
lrwxrwxrwx 1 tn users 43 Nov 30 2013 web.config -> /data/all/000/core/drupal-7.24.1/web.config

We need to be using:

/data/disk/tn/distro/008/openatrium-7.x-2.19-7.31.

I'll see if I can build a new openatrium platform with Aegir ..

[paul]

This latest openatrium platform is automatically built by Aegir. I'll migrate the openatrium site to the new platform ..

[chris]

Replying to paul:

Theres appears to be nothing documented about openatrium on the wiki / trac.

There are a couple of tickets:

• ticket:560
• ticket:636

There might be some others.

Perhaps Jim didn't get around to documenting it further than this?

[paul]

Thanks Chris. I'll take a look a these shortly.

@TN

Openatium is now updated.

I'll take a look at IIRs shortly.

I'll also see what platforms can be deleted from Aegir - platforms that are no longer being used as the site(s) that once ran on them have been migrated to a more recent version of the platform

[paul]

The IIRs site is built manually without an external platform file, and outside of version control. It's currently running drupal 7.26 and collection of modules.

@ Annesley

I have put the site into maintenance mode for now as the site needs to be upgraded. Any thoughts on what to do next?

I have deleted platform / sites that are no longer needed - but have retained the previous version of the platform just in case we need to migrate back to the previous version of the site.

​https://tn.puffin.webarch.net/hosting/sites
​https://tn.puffin.webarch.net/hosting/platforms

Everything we can do now -to keep our sites/server secure - has been done.

[annesley]

hi! iirs-test is nothing to do with me.

i am using an enabled IIRS Module on booker staging ​https://booker-stage-20140717.transitionnetwork.org/IIRS/registration/
which appears to have disappeared. but i am developing locally so can copy it back no problem.

[ed]

1. IIRS-test on D7 is Jim's old work and can be removed
2. Open Atrium was set up as a trial intranet, got picked up by the international team before we'd trialled it, I'm not sure how much it's being used now, finding out is on my agenda
3. news.transitionnetwork.org is a news feed aggregator which collects news feeds from TI sites and re-publishes teasers of them on that domain, and into the TI profile pages. It is one of the services that will be de-commissioned this autumn

[paul]

Replying to ed:

1. IIRS-test on D7 is Jim's old work and can be removed

I'll remove now ..

2. Open Atrium was set up as a trial intranet, got picked up by the international team before we'd trialled it, I'm not sure how much it's being used now, finding out is on my agenda

Maybe we could trial the software as a basecamp tool while bulding the IIRS?

3. news.transitionnetwork.org is a news feed aggregator which collects news feeds from TI sites and re-publishes teasers of them on that domain, and into the TI profile pages. It is one of the services that will be de-commissioned this autumn

Thanks

[ed]

1. Good
2. Interesting. The national hubs found it cumbersome and it looked like we'd need to do more work to really get it sorted. Staff are about to move to google apps lock stock and barrel I reckon (and now recommend). Tech: atm we're using the wiki pages and emails as agreed. I'm interested in using a use case based tool for TNv3, and not particularly ingterested in doing any dev work on OA.
3. Good.

[paul]

Replying to ed:

1. Good

The IIRS site and platform have now been deleted.

2. Interesting. The national hubs found it cumbersome and it looked like we'd need to do more work to really get it sorted. Staff are about to move to google apps lock stock and barrel I reckon (and now recommend). Tech: atm we're using the wiki pages and emails as agreed. I'm interested in using a use case based tool for TNv3, and not particularly ingterested in doing any dev work on OA.
3. Good.

[chris]

Replying to ed:

Staff are about to move to google apps lock stock and barrel I reckon (and now recommend).

Choosing to becoming dependant on one of the planets biggest imperial corporations [1] for internal communications and documentation, when there are Free/libre alternatives which can be self hosted, is not the way to be resilient and autonomous.

[1] ​https://www.wikileaks.org/Op-ed-The-Banality-of-Don-t-Be.html

[annesley]

@Chris: do you accept the cost-benefit-politics suggestion?
do you agree that we cannot be perfect politically? and that it's a matter of where we draw the line, not a binary decision?

so, to use an extreme to illustrate the point: if it cost £200,000 / year to avoid using Google and install Free/libre alternatives would you agree that we should use Google?

don't think that i am not with you. i am. i totally reject Capitalism, hierarchy, elites, consumption, etc. but i want you to join us in trying to calculate where to draw the line, instead of repeating this binary idea. Transition lives in Capitalism and it doesn't have endless money. decisions must be made. we cannot run our own copy of the Internet because the Cobolt used in the intermediate machines is mined in oppressive conditions for example.

i think the essential problem here is the fact is that IT software has massive economies of scale. so trying to implement things individually is always going to empty the pockets of the very organisations that are trying to defeat Capitalism.

how much does it cost to run these alternatives? and train people, and maintain them? give us an estimate for a year period.

[ed]

@Annesley and @Chris - conversations about TN's decisions around intranet software are out of scope here.

Please do not pursue this conversation on this ticket or on TN time. Please feel free to enjoy it down the pub however :)

[paul]

@TN

Sorry off topic ..

What libre alternatives were considered before choosing Google?

[ed]

@Paul happy to discuss this with you in your time at another time when I'm not doing other stuff

[ed]

Closing this ticket for now as before we got side tracked Paul said 'Everything we can do now - to keep our sites/server secure - has been done.'

​/trac/ticket/774#comment:38