Transition Technology: Ticket Query

#824: Analysis of the 2014 maintenance ticket time

chris — Wed, 07 Jan 2015 15:48:14 GMT

Ed has ask that I spend up to 2 hours on an analysis of the 2014 maintenance ticket time for our meeting tomorrow in Bristol.

#763: Server Backups

chris — Mon, 21 Jul 2014 17:09:21 GMT

Two weeks ago annesley asked:

what off-site data storage, file backup and quick setup do we have?

I answered:

The 3 virtual servers have their file system mounted off a BSD/NFS/ZFS file server and the whole file system is backed up and stored onto another BSD/ZFS server in the same data centre. We did have backups also being copied to a server in Manchester but this is currently off-line as the Manchester server needs a disk swapping and rebuilding as a BSD/ZFS server.

A problem with this is that it's only me and Alan that have access to these backups, so I'd like to suggest I set up a new account for backups on our backup server and sort out cron jobs to rsync data to this account and document how people can access these backups.

The result would be that everybody would have SFTP access to 60 days worth of snapshots of backups from all three servers whenever needed without any need for my or Alan's intervention.

I expect this would take abount an hour to set up and another hour to document and help people understand it.

There would be no additional cost to the TN because backup space is already paid for.

#806: IIRS pre-beta usability issues

chris — Mon, 10 Nov 2014 21:30:27 GMT

Ticket to track usability issues etc.

#757: Research and Design for TNv3

ed — Fri, 11 Jul 2014 13:36:54 GMT

R&D for TNv3

#655: Add social media icons with counters to blogs listings views

ed — Thu, 12 Dec 2013 13:03:11 GMT

Investigate with Rob how to add Social media icons with counters into the /blogs listings views and individual node views.

I suggest starting with just Rob's blogs (/rob-hopkins), separate context for 'Transition Culture section' and then roll it out over other blogs and maybe news content type once the /rob-hopkins has been trialled

Sam to talk with Rob

Also cc-ing Ben as design - theme guy

#661: Add button block to homepage RHS: Send us your news stories

ed — Tue, 17 Dec 2013 15:34:53 GMT

January:

Create button for TN homepage and /news and /blogs to encourage people to send in stories.

create button like the existing ones - e.g:

https://www.transitionnetwork.org/admin/build/block/configure/block/89?destination=newhome

add suitably pithy text

if in doubt about style, read Ben's style cheatsheet on google docs:

https://docs.google.com/document/d/1z6JYGiy8EJ6pqjm_WyNUS26fQgIClmIFg0a-8y-Mots/edit#heading=h.siua52eim2e9

this will need to be an email forwarder to send to Rob instead of a http link as per the other buttons, so you'll need to set one up on United's dashboard using the main 'jmcgeechan' account

cc-ing benj as he can be around to help with postitioning/button make if an issue - but can't do email forwarder set up - and don't forget sam - if you're too busy you can always farm it out to ben (although this is probably a bit easy for ben, he'll know about how to get blocks in the right order)

#738: Change 'ben' account to have Ben Jarlett as owner

ed — Tue, 10 Jun 2014 09:14:06 GMT

Chris: change the ‘ben’ account’s password Chris; change the ‘ben’ account to have 'emailme@…’ as the p.o.c. Chris? Ben?: change the ‘benj’ account to have ‘web project@…’ as the p.o.c. and Ed to forward anything vital if/when it comes up ALL to use only ‘ben’

#758: * Advisory ID: DRUPAL-SA-CORE-2014-003

paul — Wed, 16 Jul 2014 21:55:29 GMT

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

Advisory ID: DRUPAL-SA-CORE-2014-003
Project: Drupal core [1]
Version: 6.x, 7.x
Date: 2014-July-16
Security risk: Critical [2]
Exploitable from: Remote
Vulnerability: Multiple vulnerabilities

Multiple vulnerabilities were fixed in the supported Drupal core versions 6 and 7.

.... Denial of service with malicious HTTP Host header (Base system - Drupal 6 and 7 - Critical)

Drupal core's multisite feature dynamically determines which configuration file to use based on the HTTP Host header.

The HTTP Host header validation does not sufficiently check maliciously-crafted header values, thereby exposing a denial of service vulnerability.

.... Access bypass (File module - Drupal 7 - Critical)

The File module included in Drupal 7 core allows attaching files to pieces of content. The module doesn't sufficiently check permission to view the attached file when attaching a file that was previously uploaded. This could allow attackers to gain access to private files.

This vulnerability is mitigated by the fact that the attacker must have permission to create or edit content with a file field.

Note: The Drupal 6 FileField? [3] module is affected by a similar issue (see SA-CONTRIB-2014-071 - FileField? - Access bypass [4]) and requires an update to the current security release of Drupal 6 core in order for the fix released there to work correctly. However, Drupal 6 core itself is not directly affected.

.... Cross-site scripting (Form API option groups - Drupal 6 and 7 - Moderately critical)

A cross-site scripting vulnerability was found due to Drupal's form API failing to sanitize option group labels in select elements. This vulnerability affects Drupal 6 core directly, and likely affects Drupal 7 forms provided by contributed or custom modules.

This vulnerability is mitigated by the fact that it requires the "administer taxonomy" permission to exploit in Drupal 6 core, and there is no known exploit within Drupal 7 core itself.

.... Cross-site scripting (Ajax system - Drupal 7 - Moderately critical)

A reflected cross-site scripting vulnerability was found in certain forms containing a combination of an Ajax-enabled textfield (for example, an autocomplete field) and a file field.

This vulnerability is mitigated by the fact that an attacker can only trigger the attack in a limited set of circumstances, usually requiring custom or contributed modules.

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

accordance with Drupal Security Team processes./

Drupal core 6.x versions prior to 6.32.
Drupal core 7.x versions prior to 7.29.

Install the latest version:

If you use Drupal 6.x, upgrade to Drupal core 6.32. [6]
If you use Drupal 7.x, upgrade to Drupal core 7.29. [7]

Also see the Drupal core [8] project page.

The denial of service vulnerability using malicious HTTP Host headers was

reported by Régis Leroy [9].

The access bypass vulnerability in the File module was reported by Ivan

Ch [10].

The cross-site scripting vulnerability with Form API option groups was

reported by Károly Négyesi [11].

The cross-site scripting vulnerability in the Ajax system was reported by

mani22test [12].

The denial of service vulnerability using malicious HTTP Host headers was

fixed by Régis Leroy [13], and by Klaus Purer [14] of the Drupal Security Team.

The access bypass vulnerability in the File module was fixed by Nate Haug

[15] and Ivan Ch [16], and by Drupal Security Team members David Rothstein [17], Heine Deelstra [18] and David Snopek [19].

The cross-site scripting vulnerability with Form API option groups was

fixed by Greg Knaddison [20] of the Drupal Security Team.

The cross-site scripting vulnerability in the Ajax system was fixed by

Neil Drumm [21] of the Drupal Security Team.

The Drupal Security Team [22]

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

Learn more about the Drupal Security team and their policies [24], writing secure code for Drupal [25], and securing your site [26].

Follow the Drupal Security Team on Twitter at https://twitter.com/drupalsecurity [27]

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

#764: Policy decisions re-assessment on BOA and Drupal security updates

annesley — Tue, 22 Jul 2014 14:10:38 GMT

on-line meeting 5 / August @ 14:00 GMT: we are phasing out the current D6 / BOA system. the new system may not use either. The TN.org website is not attractive to high level hackers or DOS attacks.

what are the risks with cancelling all further Unix, BOA and Drupal updates completely that do not allow direct un-mitigated access to the backend via bad PHP code / SQL?

#865: synchronisation

annesley — Wed, 15 Jul 2015 13:26:48 GMT

ideas. please query them.

we are synchronising between different data structures: WordPress and Drupal and anything else the plugin is installed on. therefore standard *database level* distributed synchronisation management tools will not be appropriate. this is unfortunate because synchronisation is a big task. however, it is possible that there are some CRUD / REST based sync tools. so: we need an XML abstraction layer (partially done already) produced by the Drupal, Wordpress, etc. plugin that is standardised and can then be compared and synced via standard API calls.

Steps:

new Transition Town registration on server A notify server B that there is new data and send the GUID of this new data server B then requests only the new data from server A (incremental) using the GUID server B creates the new item in it's database with a new native ID using the abstraction layer in it's plugin / module

addtions to this universal data pool, e.g. a new Transition Town, will be propagated via a network sync request at point of addition. "listener servers" will then request the new data (incremental only) and, in turn push that out to all other listeners. each plugin will therefore extend and expose it's CRUD style synchronisation abstraction functions:

add-user add-local-group change-user etc.

many of these are already available as part of the framework-independent plugin / module

currently, i suggest that ALL plugins contain ALL the international user and Transition Town data. passwords and emails, contact info will be handled by a 3rd server, either Mozilla Persona or Open ID. user accounts will also be synchronised on to ALL plugins but without passwords as those are held on the 3rd server. thus far had already been agreed with Ed. but, ofc, can be changed :)

new plugin installations will receive a full complement of data at time of installation. check digits will be periodically shared to check that all data is in-line. all users will be able to register and edit their data on ANY website holding the plugin. TT and USER changes and registrations will then propagate via PUSH notifications across the entire network all native IDs will be different. i.e. TT Brixton will have a different ID on each server. thus, as always with synchronissation, all IDs will be transformed to GUIDs by the abstraction API and only GUIDs will be used to analyse the network of data and synchronisation. login to any website containing the plugin will be transparent (unlike the demo i set up) through the normal wordpress and drupal login screens. the plugin will intercept failed authentication and attempt to authenticate against the universal servers. new accounts created via universal registration on any server will have a framework specific configurable role and thus permissions on that server will be set by the administrator specific to that server.

#809: [Security-news] Drupal Core - Moderately Critical - Multiple Vulnerabilities - SA-CORE-2014-006

paul — Wed, 19 Nov 2014 21:35:25 GMT

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

Advisory ID: DRUPAL-SA-CORE-2014-006
Project: Drupal core [1]
Version: 6.x, 7.x
Date: 2014-November-19
Security risk: 14/25 ( Moderately Critical) AC:Basic/A:None/CI:Some/II:Some/E:Theoretical/TD:Uncommon [2]
Vulnerability: Multiple vulnerabilities

.... Session hijacking (Drupal 6 and 7)

A specially crafted request can give a user access to another user's session, allowing an attacker to hijack a random session.

This attack is known to be possible on certain Drupal 7 sites which serve both HTTP and HTTPS content ("mixed-mode" [3]), but it is possible there are other attack vectors for both Drupal 6 and Drupal 7.

.... Denial of service (Drupal 7 only)

Drupal 7 includes a password hashing API to ensure that user supplied passwords are not stored in plain text.

A vulnerability in this API allows an attacker to send specially crafted requests resulting in CPU and memory exhaustion. This may lead to the site becoming unavailable or unresponsive (denial of service).

This vulnerability can be exploited by anonymous users.

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

with Drupal Security Team processes./

Drupal core 6.x versions prior to 6.34.
Drupal core 7.x versions prior to 7.34.

Install the latest version:

If you use Drupal 6.x, upgrade to Drupal core 6.34. [5]
If you use Drupal 7.x, upgrade to Drupal core 7.34. [6]

If you have configured a custom password.inc file for your Drupal 7 site you also need to make sure that it is not prone to the same denial of service vulnerability. See also the similar security advisory for the Drupal 6 contributed Secure Password Hashes module: SA-CONTRIB-2014-113 [7]

Also see the Drupal core [8] project page.

Session hijacking:

Aaron Averill [9]

Denial of service:

Michael Cullum [10]
Javier Nieto [11]
Andrés Rojas Guerrero [12]

Session hijacking:

Klaus Purer [13] of the Drupal Security Team
David Rothstein [14] of the Drupal Security Team
Peter Wolanin [15] of the Drupal Security Team

Denial of service:

Klaus Purer [16] of the Drupal Security Team
Peter Wolanin [17] of the Drupal Security Team
Heine Deelstra [18] of the Drupal Security Team
Tom Phethean [19]

The Drupal Security Team

The Drupal security team can be reached at security at drupal.org or via the contact form at https://www.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].

Follow the Drupal Security Team on Twitter at https://twitter.com/drupalsecurity [24]

#727: Change background on block from orange to white

sam — Fri, 16 May 2014 10:02:17 GMT

Hi Ben

Rob wants a list of the themes presented in a block.

I did the block: https://www.transitionnetwork.org/admin/build/block/configure/block/97

But it appears with an orange background. The block is visible towards the bottom of the page (for logged in admins) here: https://www.transitionnetwork.org/blogs/rob-hopkins

If I put the block on other pages it appears with a white background.

I tried to hack it with some inline CSS but failed.

Could you take a look?

Thanks

Sam

#596: Captions issue

benj — Mon, 16 Sep 2013 16:58:04 GMT

basically captions are appearing on body inline images and featured images on STG but not PROD and I can't see where the difference is...

The following code addition to the bottom of template.php should be (but isn't) adding the caption class to images such as the one at the top of this page:

https://www.transitionnetwork.org/blogs/ed-mitchell/2013-06/test-blog-test-caption-and-featured-image

Any reason you can think of why not? Or do you know of another easy way of adding the class caption to featured image fields? (I guess the module https://drupal.org/project/semantic_cck - but maybe overkill...)

Adds caption css class to featured images */

function transition2_imagecache_formatter_featured_image_default($element) {

Inside a view $element may contain NULL data. In that case, just return. if (empty($element#item fid?)) {

return ;

}

Extract the preset name from the formatter name. $presetname = substr($element#formatter, 0, strrpos($element#formatter, '_')); $style = 'linked'; $style = 'default';

$item = $element#item; $itemdata?alt? = isset($itemdata?alt?) ? $itemdata?alt? : ; $itemdata?title? = isset($itemdata?title?) ? $itemdata?title? : NULL;

$class = "imagecache imagecache-$presetname imagecache-$style imagecache-{$element#formatter} caption"; return theme('imagecache', $presetname, $itemfilepath?, $itemdata?alt?, $itemdata?title?, array('class' => $class));

}

#731: Meetings in maintenance

chris — Fri, 23 May 2014 10:47:39 GMT

Ticket to record time spent on Skype call on 22nd May 2014.

#716: Heartbleed

chris — Wed, 09 Apr 2014 08:53:58 GMT

Following on from ticket:692#comment:18 we should undertake the steps Drupal have taken: https://drupal.org/news/2014-04-08-security-update

#676: Alternative to Skype for TTech Meetings

chris — Tue, 14 Jan 2014 13:33:51 GMT

Jim has pointed out that:

Skype costs us 15-30 minutes of grinding pain every time we do this!

So what are the alternatives and what are our requirements?