Development News

PNWPHP 2017 CfP

PHP Announcements - Thu, 03/30/2017 - 07:49
We are happy to announce the dates for *Pacific Northwest PHP Conference (PNWPHP) 2017 are September 7-9, and will held at University of Washington in Seattle! The CFP site - http://cfp.pnwphp.com - has launched, where talk submissions will accepted through May 15th, 2017. The Pacific Northwest PHP Conference is a 3-day event in Seattle, Washington for PHP and Web developers. Our past conferences have included world renown speakers from the PHP community, about a wide range of topics — from APIs and CMS to unit testing and version control For more details, go to http://pnwphp.com
Categories: Development News, PHP, PHP News

Northeast PHP Conference CfP

PHP Announcements - Thu, 03/30/2017 - 07:40
The Northeast PHP conference returns once again in 2017 to Charlottetown, PEI Canada. The Call for Papers is open until April 15th. The conference will take place August 9-11, and Early Bird Tickets are now available.
Categories: Development News, PHP, PHP News

PHPKonf: Istanbul PHP Conference 2017

PHP Announcements - Mon, 03/27/2017 - 14:00
Istanbul PHP User Group is proud to announce that the PHPKonf 2017! We'll host some of the best speakers, awesome talk topics, latest technologies, and up to date news in PHP. Join us on 20th of May for a multi-track conference in ancient city Istanbul! We’ve something for every level of PHP developer with 1 keynotes, 14 talks. For call for papers and more information: http://phpkonf.org
Categories: Development News, PHP, PHP News

2017 Drupal Association at-large election winner announced

Drupal News - Mon, 03/27/2017 - 11:51

*/

2017 Election Results

The staff and board of the Drupal Association would like to congratulate our newest board member:

Ryan Szrama.

Thank you, Ryan, for stepping forward to serve the Drupal community. On behalf of the community I also want to thank the 13 candidates who put themselves out there in service of Drupal and nominated themselves. We are grateful that our community has so many brave and generous people willing to contribute this way.

Ryan's election to the board represents the sixth year of elections to a community-at-large seat on the Drupal Association board. Each year we've focused on improving the elections process, and this year was no different. We focused on two goals: 

  1. Improve the user experience of participating in the elections process. 
    • We added more in-line help materials throughout the elections process.
      • For candidates, we added information about the responsibilities of a board member to the nomination form, as well as a video message from the Executive Director.
      • For voters we improved the elections navigation, and provided more educational materials about the IRV voting process.
    • We implemented a drag and drop ballot, to make it easier for voters to rank candidates. 
  2. Make it easier to get to know the candidates.
    • We updated the candidate profile form, to ask more detailed questions to help voters get to know the candidates. 
    • Based on feedback from previous years, we eliminated the three virtual meet-the-candidates sessions, in favor of giving each candidate the option to post a statement-of-candidacy video.  In conjunction with the question and answer section on each candidate profile, we felt this gave the electorate the opportunity to get to know their candidates at their own pace and on their own terms. 

Our next steps will be to reach out to the candidates for their evaluation of the elections experience.

We also want to hear from the voters. Please tell us about your experience with the elections process in the comments below. Your feedback is important to us so that we can make the 2018 elections process even better. 

About the Elections Methodology: Instant Run-off Voting(IRV)

Elections for the Community-at-large positions on the Drupal Association board are conducted through Instant Run-off Voting. This means that voters can rank candidates according to their preference. When tabulating ballots, the voters' top-ranked choices are considered first. If no candidate has more than 50% of the vote, the candidate with the lowest votes is eliminated. Then the ballots are tabulated again, with all the ballots that had the eliminated candidate as their first rank now recalculated with their second rank choices. This process is repeated until only two candidates remain and a clear winner can be determined. This voting method helps to ensure that the candidate who is most preferred by the most number of voters is ultimately elected. You can learn more about IRV (also known as Alternative Vote) in this video.

Voting Results

There were 13 candidates in contention for the single vacancy among the two community-at-large seats on the Board. 1,240 voters cast their ballots out of a pool of 94,499 eligible voters (1.3%). Voters ranked an average of 3.6 candidates on their ballots. 

The bar charts below show the vote counts for each candidate in each round.
Place the mouse over a bar to see the number of votes.

  • Yellow — Votes carried over from the previous round.
  • Green — Votes received in this round.
  • Red — Votes transferred away in this round.

A candidate's votes in a round is the sum of the yellow and green bars.
Since the green and red bars represent votes being transferred, the sum of the
green and red bars is the same.

The exhausted bar represents votes where the voter did not indicate a next
preference and thus there were no candidates to transfer the vote to.

Round 1

(next)

Count of first choices.

Round 2

(prev)(next)

Count after eliminating gurubryan and transferring votes.

Round 3

(prev)(next)

Count after eliminating mehuls and transferring votes.

Round 4

(prev)(next)

Count after eliminating zet and transferring votes.

Round 5

(prev)(next)

Count after eliminating Rahul Seth and transferring votes.

Round 6

(prev)(next)

Count after eliminating redacted and transferring votes.

Round 7

(prev)(next)

Count after eliminating MatthewS and transferring votes.

Round 8

(prev)(next)

Count after eliminating Riaan Burger and transferring votes.

Round 9

(prev)(next)

Count after eliminating johnkennedy and transferring votes.

Round 10

(prev)(next)

Count after eliminating jackniu and transferring votes.

Round 11

(prev)(next)

Count after eliminating ok_lyndsey and transferring votes.

Round 12

(prev)

Count after eliminating Prasad Shir and transferring votes. Candidate rszrama is elected.

Winners

Winner is rszrama.

Categories: Development News, Drupal

A Statement from the Executive Director

Drupal News - Thu, 03/23/2017 - 18:49

Drupal Association

We understand that there is uncertainty and concern in the Drupal community about project founder, Dries Buytaert, asking Larry Garfield to leave the Drupal community, and about the Drupal Association removing Larry's DrupalCon sessions and ending his term as track chair.

We want to be clear that the decision to remove Larry's DrupalCon session and track chair role was not because of his private life or personal beliefs. The Drupal Association stands by our values of inclusivity. Our decision was based on confidential information conveyed in private by many sources. Due to the confidential nature of the situation we cannot and will not disclose any information that may harm any members of our community, including Larry.

This decision followed our established process. As the Executive Director, charged with safekeeping the goodwill of the organization, I made this decision after considering input from various sources including the Community Working Group (CWG) and Drupal Project Lead, Dries Buytaert. Upon Larry’s request for an appeal, the full board reviewed the situation, all the evidence, and statements provided by Larry. After reviewing the entirety of the information available (including information not in the public view) the decision was upheld.

In order to protect everyone involved we cannot comment more, and trust that the community will be understanding.  

We do see that there are many feelings and questions around this DrupalCon decision and we empathize with those community members. We will continue to monitor comments. We are listening.

Update: 29 Mar 2017

Thank you for taking the time to share your thoughts, concerns, and questions. I wanted to reach back out and reaffirm that we are listening. In addition to watching the comments here, we are also listening in other places like the Drupal community Slack, IRC, and the community blog posts that have come to our attention. Your comments are being heard and they are helping us to be thoughtful about our next steps.

Categories: Development News, Drupal

Linkit - Moderately Critical - Access Bypass - DRUPAL-SA-CONTRIB-2017-033

Drupal Contributed Security - Wed, 03/22/2017 - 12:40
Description

Linkit provides an easy interface for internal and external linking with WYSIWYG editors by using an autocomplete field.

When searching for entities, this module doesn't always enforce the access restrictions and users may see information about entities they should not be able to access.

This is mitigated by the fact that a user must have access to a text format that uses Linkit.

CVE identifier(s) issued
  • A CVE identifier will be requested, and added upon issuance, in accordance with Drupal Security Team processes.
Versions affected
  • Linkit 8.x-4.x versions prior to 8.x-4.3.

Drupal core is not affected. If you do not use the contributed Linkit- Enriched linking experience module, there is nothing you need to do.

Solution

Install the latest version:

  • If you use the Linkit module for Drupal 8.x, upgrade to Linkit 8.x-4.3

Also see the Linkit- Enriched linking experience project page.

Reported by Fixed by Coordinated by Contact and More Information

The Drupal security team can be reached at security at drupal.org or via the contact form at https://www.drupal.org/contact.

Learn more about the Drupal Security team and their policies, writing secure code for Drupal, and securing your site.

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

Drupal version: 

Office Hours - Moderately Critical - Cross Site Scripting - DRUPAL-SA-CONTRIB-2017-032

Drupal Contributed Security - Wed, 03/22/2017 - 12:37
Description

This module enables you to show the office hours of a location to the public.

The module doesn't sufficiently filter user input for malicious Cross Site Scripting (xss).

This vulnerability is mitigated by the fact that an attacker must have a role with a permission to add fields to an entity.

CVE identifier(s) issued
  • A CVE identifier will be requested, and added upon issuance, in accordance with Drupal Security Team processes.
Versions affected
  • Office Hours 7.x-1.x versions prior to 7.x-1.6.

Drupal core is not affected. If you do not use the contributed Office Hours module, there is nothing you need to do.

Solution

Install the latest version:

Also see the Office Hours project page.

Reported by Fixed by Coordinated by Contact and More Information

The Drupal security team can be reached at security at drupal.org or via the contact form at https://www.drupal.org/contact.

Learn more about the Drupal Security team and their policies, writing secure code for Drupal, and securing your site.

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

Drupal version: 

How Drupal.org fights spam using Distil Networks

Drupal News - Wed, 03/22/2017 - 10:45

This case study was written as a collaboration between Drupal Association staff and Technology Supporting Partner Distil Networks.

Drupal.org is the home of one of the largest open source communities in the world. We've been online for more than 13 years and collectively we build the Drupal software, provide support, write documentation, share networking opportunities, and more. The open source spirit pushes the Drupal project forward, and new members are always welcome. It falls to us to maintain our community home and preserve the welcoming atmosphere that leads people to say,"Come for the code, stay for the community."  

As stewards of Drupal.org, it's our responsibility to give the community a voice and welcome everyone who wants to participate in the project. At the same time, there are bad actors who would take advantage of our open community and platform for abusive purposes.

Drupal.org long-standing presence on the web has given it authority in the eyes of search engines. The site hosts millions of pages of content - all generated by our users. This combination of authority and open access for users to create content makes us a very high value target for phishers and spammers.

Spam is a nuisance to our existing community, devalues our project to the newcomers we are hoping to welcome, and left unchecked could degrade our search presence.

Challenges Spammers create bogus accounts to post their junk content

Only registered members can post content to the Drupal.org website, so there's a continuous onslaught of actors attempting to create accounts for the purpose of inserting link spam and other bad content onto the site. In the past, we've implemented a variety of strategies such as content analysis, behavioral analysis, social moderation, and rate limiting. And while these measures have been effective at reducing some of the spam we've seen, the onslaught continues.

The reason for that? Much of our attempted spam is not coming from bots. These are real people using tools to cloak their identity and manually creating accounts en masse. In many cases they may not even post junk content immediately. They will often sit on "sleeper" accounts waiting to be paid by somebody to promote malicious content.

It's too time consuming to manually remove spam content

Spam fighting is also a thankless task. All time spent fighting spam, whether by members of the engineering staff or our incredibly dedicated community volunteers, is time not spent on the project. Spam fighting has an opportunity cost that creates burn-out among staff and volunteers, and is not something we can afford to leave to manual moderation.

Especially when it comes to our community volunteers– they want to spend their time helping people with Drupal technical questions, not deleting spam.

Fake accounts and spam pollute the community engagement metrics

There are 1.9 million user accounts in the Drupal.org database, but using this data to measure community engagement is challenging because of the number of spammer accounts that have been registered over the years. When we have to work around so many illegitimate accounts, it's difficult to determine metrics for community health such as if our legitimate user growth is increasing or decreasing. We need cleaner user account data to give us more reliable community metrics, and help us make informed decisions.

The Solution

Before reaching out to Distil Networks, Drupal.org relied primarily on two modules to help us fight spam. Mollom is a Drupal stand-by—a content analysis tool that looks at what users are posting and compares them against known bad actor patterns. This content analysis helps us identify and block new waves of spam patterns, but it doesn't prevent these waves from being posted in the first place.

The second module we use is Honeypot, which uses a combination of honeypot and rate limiting methods to prevent bot spam. Honeypot does a good job in preventing mass spam attacks by bots, but when real people are creating the underlying accounts honeypot can't help us.

As we researched ways to prevent spam, we discovered that all of these bad actors we wanted to keep out had one thing in common—they are hiding their identities behind proxies. This prevents us from simply blacklisting certain ip addresses or ranges. So instead, we began researching ways to unmask the users behind these proxies and block them before they can even create an account.

Our research led us to Distil Networks. We now run the Drupal.org registration pages(and only the registration pages) through the Distil Cloud CDN. Distil's service gathers device fingerprints for the users trying to create the accounts, and we're able to leverage those fingerprints to block users who would otherwise generate dozens or hundreds of accounts by rotating through proxies. This fingerprinting process is limited to a hashed, unique identifier and only affects our registration process, to preserve the privacy of our legitimate users.

What the Distil data shows

After enabling Distil's service for our registration process we were able to capture fingerprints for about 20,000 account registrations over the course of nine months. We were immediately able to identify more than 10% of those account registrations as duplicate registrations by the same user, hiding behind a proxy. As we dug into the data further, we realized that thousands of the spam accounts that spammers are attempting to register are actually created by only 200-300 real individuals.

By blocking these 200-300 individuals by their Distil fingerprint, we can block thousands of account registrations, and tens of thousands of spam posts that would have been created had these 'sleeper accounts' been activated.

Results

Even with Distil's sophisticated profiling tool available to us, we knew that the spam fighting process would continue to have a manual component. In the first place, there are still thousands of 'sleeper' accounts registered before we implemented Distil that could be activated. And secondly, we know that we cannot simply rely on proxy detection and fingerprint collisions to identify spam accounts. Some of our users are in countries where a proxy is the only way to access a free and open internet. Other users are in environments that have identical device fingerprints and a shared IP, such as a classroom computer lab.

However, by taking advantage of the tools that Distil offers, we can now stop many of the account registrations at the source. In the same time that it once took us to moderate a single new user account that had just posted spam, we can now block a unique id that would have been used to create a dozen or even a hundred more accounts.

We've seen trends in our account registration logs that show that the new methods are working. As we block spammers in ways they can't circumvent through proxies, their ability to register multiple accounts diminishes. Without being able to mass register accounts to later activate when selling link spam, Drupal.org becomes a less viable target.

While some spam still gets through, whether from old sleeper accounts, or lucky new spammers that manage to slip by, the overall reduction in spam has been significant. This lets our volunteers and internal staff direct more of their efforts at moving the project forward, rather than fighting spam.  

With fewer illegitimate account registrations, we're also able to improve the metrics we use to measure our community health and engagement, by lowering the noise-to-signal ratio in user activity.

Conclusion

We want to thank Distil Networks for joining the Drupal Association as a Premium Technology Supporter. The tools that Distil Networks provide enable us to better take care of the home of the community. Fighting spam is a never ending challenge: as long as there is a financial incentive to posting spam, bad actors will continue to evolve their methods, but with a partner like Distil Networks we are now equipped to stay one step ahead.

To learn more about how Drupal.org and Distil Networks partnered to tackle spam, and to learn how you could leverage a similar solution for your own site, please join us at our webinar on April 5th, at 10am Pacific.

Distil Networks will be joining us at DrupalCon Baltimore from April 24-28th. We invite the community to join us there and learn more about our partnership.

Categories: Development News, Drupal

Better DevOps (IT and Business Alignment) with MySQL (11 Apr 2017)

MySQL Web Seminars - Tue, 03/21/2017 - 16:43

DevOps is a movement to align IT with business needs. DevOps is about CAMS:

  • Culture
  • Automation
  • Measurement
  • Sharing

In MySQL we are constantly working to improve our products with these concepts and goals in mind. We are improving the monitoring MySQL Server by extending the depth of Performance_Schema and Sys_Schema with each new release, and adding new capabilities to MySQL Enterprise Monitor. We add new features to our tools to help with the deployment of Infrastructure-as-Code: the MySQL Shell and the adminAPI are examples of this. During this session, Fred will show you how to automate the deployment of a MySQL InnoDB Cluster with 3 nodes using Puppet. The Puppet recipe will use the new adminAPI to communicate with the nodes to create and/or join the cluster.



Date and Time: Tuesday, 11 Apr 2017, 09:00 US/Pacific
Categories: Development News, MySQL

Combining the Power of SQL and NoSQL Databases in MySQL (19 Apr 2017)

MySQL Web Seminars - Tue, 03/21/2017 - 16:38

SQL has served IT for 30 years now and is far from being obsolete. In recent years NoSQL databases have emerged due to different needs of the developer. While offering the benefit of storing different data structures, almost every NoSQL engine has adopted SQL or an SQL-like query language back into the engine. There are advantages on both sides but how can one combine the power of SQL and NoSQL into one database? That question is answered in MySQL with a set of features for storing unstructured data in JSON. Out of the box MySQL now supports a JSON data type, a set of functions for manipulating JSON data, and the ability to query JSON using the power of SQL. Indexing is also supported via the addition of generated columns. It is now possible to combine the benefits of the schema and schemaless NoSQL world, and this session will explain the benefits and use cases for each approach.



Date and Time: Wednesday, 19 Apr 2017, 09:00 US/Pacific
Categories: Development News, MySQL

Goodbye Project Applications, Hello Security Advisory Opt-in

Drupal News - Fri, 03/17/2017 - 18:12

Any user on Drupal.org who has accepted our Git usage policy may now create full projects with releases. This is a big change in policy for the Drupal project, representing an evolution of the contribution ecosystem in the past half a decade.

What was the Project Application Process?

Ever since the days when Drupal's code was hosted in CVS there has been some form of project application process in the Drupal Community. To prevent duplicate, low-quality, insecure, or otherwise undesirable projects from flooding Drupal, users would submit sandbox projects to an application queue to be reviewed by a group of volunteers.

After resolving any issues raised in this review process, the user would be given the git vetted role, allowing them to promote their sandbox to a full project, claim a namespace, and create releases. Once a user had been vetted for their first project, they would remain vetted and be able to promote any future projects on their own, without submitting an additional application.

The Problem

Unfortunately, though the project application process was created with the best of intentions, in the long term it proved not to be sustainable. Drupal grew too fast for a group of volunteer reviewers to keep up with reviewing new projects, and at times there were applications waiting in queue for 6 months to 1 year, or even more. That is much too slow in the world of software development.

This put Drupal in a difficult situation. After years of subjecting new projects and contributors to a rigorous standard of peer review, Drupal has a well-deserved reputation for code quality and security. Unlike many open source projects, we largely avoided the problem of having many duplicate modules that exist to serve the same purpose. We unified our community’s effort, and kept up a culture of collaboration and peer review. At the same time, many would-be contributors were unable or unwilling to navigate the application process and so simply chose not to contribute.

The question became, how could we preserve the emphasis on quality while at the same time removing the barrier to contribution that the application process had become?

Constraints on a solution

Opening the contribution gates while retaining strong signals about code quality and security was a tricky problem. We established three constraints on a solution:

  1. We need to welcome new contributors, and eliminate the walls that prevent contribution.
  2. We need to continue to send strong signals about security coverage to users evaluating whether to use modules from Drupal.org.
  3. We need to continue our strong emphasis on quality and collaboration through changes to project discovery that will provide new signals about code quality, and by providing incentives and credit for peer review.
The Solution

In collaboration with the community, the security team, members of the board, and staff we outlined a solution in four phases:

Phase 1: Send strong signals about security advisory coverage.
  • We updated project pages to include messaging and a shield icon to indicate whether a project received security advisory coverage from the security team.
  • We now serve security advisory coverage information in the Updates status information provided by Drupal.org, and we're working on a patch to display that information directly on the updates page of users' Drupal sites.

Here are some examples of what these security signals look like on project pages:

If a project is not opted in to security advisory coverage, this message will appear at the top of the project page:

Warning at the top of Project pages

And this one will appear near the download table:

Warning above download table

If a project has opted in, this message will appear near the download table:

Project opt in notice

And covered releases will show the coverage icon (note how the stable 7.x release has coverage and the 8.x release candidate does not):

Release coverage icon

Phase 2: Set up an opt-in process for security advisory coverage
  • Previously any project with a stable release would receive security advisory coverage from the security team. As we opened the gates for anyone to promote full projects, the security team needed an opt in process so that they could enforce an extra level of vetting on projects that wish to receive advisory coverage.
  • We agreed to repurpose the project application queue to be a queue for vetting users for the ability to opt their projects in to receive security advisory coverage. Now that this process has been decoupled from creating full projects, the security team may revise it in future–in collaboration with staff and the community.
  • Now a project maintainer must opt in their project to receive advisory coverage and make a stable release in order to receive security advisory coverage from the security team.

Once a maintainer has been vetted by the security advisory opt in process, they can edit their project and use this field set to opt-in:

Project opt-in field

Phase 3: Open the gate to allow users to create full projects with releases without project applications.

This is the milestone we've just reached!

Phase 4: Provide both automated code quality signals, as well as incentives for peer review of projects - and factor these into project discovery
  • We are working on this phase of the project in the issue queues, and we appreciate your feedback and ideas!
What is the new process?

So in the end - what is the new process if you want to make a contribution by hosting a project on Drupal.org?

  1. You must have a Drupal.org account, and you must accept the git terms of service.
  2. You can create a sandbox or a full project
  • Note: We still strongly recommend that project maintainers begin with sandbox projects, until they are sure they will be able to commit to supporting the project as a full project, and until the code is nearly ready for an initial release.
  • That said, you can promote a sandbox project to a full project at any time, to reserve your name space and begin making releases.

At this point, you will have a full project on Drupal.org, and will be able to make releases that anyone can use on their Drupal site. The project will not receive security advisory coverage, and a warning that the project is not covered will appear on the project page and in the updates information.

If you want to receive security advisory coverage for your project, you will need to take these additional steps:

  1. You must apply for vetted status in the security advisory coverage queue.
  2. Members of the security team or other volunteers will review your application - and may suggest changes to your project.
  3. Once feedback is resolved, you will be granted the vetted role and be able to opt in this project, and any future projects you create, to receive security advisory coverage.
    • Note: Only *stable* releases receive security advisory coverage, so even after opting your project in you will not receive the advisory coverage shield except on stable releases.
What comes next?

Now that the project application process is no more, the gates are open. We are already seeing an uptick in projects created on Drupal.org, and have seen some projects that had migrated to other places (like GitHub) migrate back to Drupal.org. We can expect to see contributions from some great developers who previously felt gate-kept out of the community. We will also see an uptick in contributions that need work, from new developers and others who are still learning Drupal best practices.

That is why our next focus will be on providing good code quality signals for projects on Drupal.org. We want to provide both automated signals of code quality, and new incentives for peer review from existing members of the community. We're outlining that plan in the issue queues, and we welcome your feedback and contributions.

We also still have work to do to communicate this well. This is a big change for the Drupal community and so we want to make people aware of this change in every channel that we can.

Finally, after such a significant change, we're going to need to monitor the contrib ecosystem closely. We're going to learn a lot about the project in the next several months, and it's likely there will be additional follow ups and other changes that we'll need to make.  

Special Thanks

There are many, many contributors on Drupal.org who have put in time and effort to help make the contribution process better for new contributors to Drupal - the deepest thanks to all of you for your insight and feedback. We'd also like to specifically thank those who participated in the Project Application Revamp, including:

Categories: Development News, Drupal

PHP 7.1.3 Released

PHP Announcements - Thu, 03/16/2017 - 11:34
The PHP development team announces the immediate availability of PHP 7.1.3. Several bugs have been fixed. All PHP 7.1 users are encouraged to upgrade to this version. For source downloads of PHP 7.1.3 please visit our downloads page, Windows source and binaries can be found on windows.php.net/download/. The list of changes is recorded in the ChangeLog.
Categories: Development News, PHP, PHP News

PHP 7.0.17 Released

PHP Announcements - Thu, 03/16/2017 - 08:00
The PHP development team announces the immediate availability of PHP 7.0.17. Several bugs have been fixed. All PHP 7.0 users are encouraged to upgrade to this version. For source downloads of PHP 7.0.17 please visit our downloads page, Windows source and binaries can be found on windows.php.net/download/. The list of changes is recorded in the ChangeLog.
Categories: Development News, PHP, PHP News

Drupal Core - Multiple Vulnerabilities - SA-CORE-2017-001

Drupal News - Wed, 03/15/2017 - 15:24

Drupal 8.2.7, a maintenance release which contains fixes for security vulnerabilities, is now available for download.

Update your existing Drupal 8 sites is strongly recommended. There are no new features nor non-security-related bug fixes in this release. See the 8.2.7 release notes for details on important changes and known issues affecting this release. Read on for details of the security vulnerabilities that were fixed in this release.

  • Advisory ID: DRUPAL-SA-CORE-2017-001
  • Project: Drupal core
  • Version: 8.x
  • Date: 2017-March-15
Description Editor module incorrectly checks access to inline private files - Drupal 8 - Access Bypass - Critical - CVE-2017-6377

When adding a private file via a configured text editor (like CKEditor), the editor will not correctly check access for the file being attached, resulting in an access bypass.

Some admin paths were not protected with a CSRF token - Drupal 8 - Cross Site Request Forgery - Moderately Critical - CVE-2017-6379

Some administrative paths did not include protection for CSRF. This would allow an attacker to disable some blocks on a site. This issue is mitigated by the fact that users would have to know the block ID.

Remote code execution - Drupal 8 - Remote code execution - Moderately Critical - CVE-2017-6381

A 3rd party development library including with Drupal 8 development dependencies is vulnerable to remote code execution.

This is mitigated by the default .htaccess protection against PHP execution, and the fact that Composer development dependencies aren't normal installed.

You might be vulnerable to this if you are running a version of Drupal before 8.2.2. To be sure you aren’t vulnerable, you can remove the /vendor/phpunit directory from the site root of your production deployments.

Solution

Update to Drupal 8.2.7

Reported by Editor module incorrectly checks access to inline private files - Drupal 8 - Access Bypass - Critical - CVE-2017-6377 Some admin paths were not protected with a CSRF token - Drupal 8 - Cross Site Request Forgery - Moderately Critical - CVE-2017-6379 Remote code execution - Drupal 8 - Remote code execution - Moderately Critical - CVE-2017-6381 Fixed by Editor module incorrectly checks access to inline private files - Drupal 8 - Access Bypass - Critical - CVE-2017-6377 Some admin paths were not protected with a CSRF token - Drupal 8 - Cross Site Request Forgery - Moderately Critical - CVE-2017-6379 Remote code execution - Drupal 8 - Remote code execution -Moderately Critical - CVE-2017-6381 Updates

Updated the above text to link to the correct update directions.

Contact and More Information

The Drupal security team can be reached at security at drupal.org or via the contact form at https://www.drupal.org/contact.

Learn more about the Drupal Security team and their policies, writing secure code for Drupal, and securing your site.

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

Categories: Development News, Drupal

Drupal Core - Multiple Vulnerabilities - SA-CORE-2017-001

Drupal Core Security - Wed, 03/15/2017 - 15:24

Drupal 8.2.7, a maintenance release which contains fixes for security vulnerabilities, is now available for download.

Update your existing Drupal 8 sites is strongly recommended. There are no new features nor non-security-related bug fixes in this release. See the 8.2.7 release notes for details on important changes and known issues affecting this release. Read on for details of the security vulnerabilities that were fixed in this release.

  • Advisory ID: DRUPAL-SA-CORE-2017-001
  • Project: Drupal core
  • Version: 8.x
  • Date: 2017-March-15
Description Editor module incorrectly checks access to inline private files - Drupal 8 - Access Bypass - Critical - CVE-2017-6377

When adding a private file via a configured text editor (like CKEditor), the editor will not correctly check access for the file being attached, resulting in an access bypass.

Some admin paths were not protected with a CSRF token - Drupal 8 - Cross Site Request Forgery - Moderately Critical - CVE-2017-6379

Some administrative paths did not include protection for CSRF. This would allow an attacker to disable some blocks on a site. This issue is mitigated by the fact that users would have to know the block ID.

Remote code execution - Drupal 8 - Remote code execution - Moderately Critical - CVE-2017-6381

A 3rd party development library including with Drupal 8 development dependencies is vulnerable to remote code execution.

This is mitigated by the default .htaccess protection against PHP execution, and the fact that Composer development dependencies aren't normal installed.

You might be vulnerable to this if you are running a version of Drupal before 8.2.2. To be sure you aren’t vulnerable, you can remove the /vendor/phpunit directory from the site root of your production deployments.

Solution

Update to Drupal 8.2.7

Reported by Editor module incorrectly checks access to inline private files - Drupal 8 - Access Bypass - Critical - CVE-2017-6377 Some admin paths were not protected with a CSRF token - Drupal 8 - Cross Site Request Forgery - Moderately Critical - CVE-2017-6379 Remote code execution - Drupal 8 - Remote code execution - Moderately Critical - CVE-2017-6381 Fixed by Editor module incorrectly checks access to inline private files - Drupal 8 - Access Bypass - Critical - CVE-2017-6377 Some admin paths were not protected with a CSRF token - Drupal 8 - Cross Site Request Forgery - Moderately Critical - CVE-2017-6379 Remote code execution - Drupal 8 - Remote code execution -Moderately Critical - CVE-2017-6381 Updates

Updated the above text to link to the correct update directions.

Contact and More Information

The Drupal security team can be reached at security at drupal.org or via the contact form at https://www.drupal.org/contact.

Learn more about the Drupal Security team and their policies, writing secure code for Drupal, and securing your site.

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

Private - Critical - Access bypass - DRUPAL-SA-CONTRIB-2017-031

Drupal Contributed Security - Wed, 03/15/2017 - 14:15
Description

This module enables you to mark nodes as private so that they are only accessible to users that have been granted an extra permissions.

The module doesn't always enforce the access restrictions. In some cases a node that a site admin expects to be private is actually accessible as normal or nodes may be editable in ways a site admin may not expect.

CVE identifier(s) issued
  • A CVE identifier will be requested, and added upon issuance, in accordance with Drupal Security Team processes.
Versions affected
  • Private 7.x-1.x versions

Drupal core is not affected. If you do not use the contributed Private module, there is nothing you need to do.

Solution

Install the latest version:

  • If you use the Private module 7.x-1.x your site may be at risk. The only completely safe option is to take the website off-line. In most cases, disabling the module will not mitigate the vulnerabilities as that will expose even more private information.
  • A new maintainer has developed a beta secure version of the module using the 7.x-2.x branch. This is a partial rewrite and needs further testing. Please test it and provide bug reports and help developing patches.

Also see the Private project page.

Reported by

Fixed by Coordinated by Contact and More Information

The Drupal security team can be reached at security at drupal.org or via the contact form at https://www.drupal.org/contact.

Learn more about the Drupal Security team and their policies, writing secure code for Drupal, and securing your site.

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

Drupal version: 

PHP Unicorn Conference (Online)

PHP Announcements - Tue, 03/14/2017 - 22:45
The PHP Unicorn Conference is an online conference dedicated to the programming language PHP. You’ll see talks from some of the world’s more recognizable PHP experts; speaking talent so rare, we call them Unicorns. It is true there are many great PHP conferences happening around the world and you should go to as many as can, but if you have a hard time getting to one or can’t spare the time, why not let the conference come to you? The PHP Unicorn Conference comes streaming right to your computer, wherever in the world you might be. So, join us online on May 4, 2017 for an all-day, can’t miss PHP event and hang out with some PHP Unicorns!!! Call for Papers closes March 26th, 2017. The PHP Unicorn Conference offers speaker compensation of $500 USD per speaker. To submit a talk, please visit: https://www.papercall.io/phpunicorn.
Categories: Development News, PHP, PHP News

Making Drupal upgrades easy forever

Drupal News - Tue, 03/14/2017 - 12:16

Republished from buytaert.net, please post your comments there.

The promise of making Drupal upgrades easy

One of the key reasons that Drupal has been successful is because we always made big, forward-looking changes. As a result, Drupal is one of very few CMSes that has stayed relevant for 15+ years. The downside is that with every major release of Drupal, we've gone through a lot of pain adjusting to these changes. The learning curve and difficult upgrade path from one major version of Drupal to the next (e.g. from Drupal 7 to Drupal 8) has also held back Drupal's momentum. In an ideal world, we'd be able to innovate fast yet provide a smooth learning curve and upgrade path from Drupal 8 to Drupal 9. We believe we've found a way to do both!

Upgrading from Drupal 8.2 to Drupal 8.3

Before we can talk about the upgrade path to Drupal 9, it's important to understand how we do releases in Drupal 8. With the release of Drupal 8, we moved Drupal core to use a continuous innovation model. Rather than having to wait for years to get new features, users now get sizeable advances in functionality every six months. Furthermore, we committed to providing a smooth upgrade for modules, themes, and distributions from one six-month release to the next.

This new approach is starting to work really well. With the 8.1 and 8.2 updates behind us and 8.3 close to release, we have added some stable improvements like BigPipe and a new status report page, as well as experimental improvements for outside-in, workflowslayouts, and more. We also plan to add important media improvements in 8.4.

Most importantly, upgrading from 8.2 to 8.3 for these new features is not much more complicated than simply updating for a bugfix or security release.

Upgrading from Drupal 8 to Drupal 9

After a lot of discussion among the Drupal core committers and developers, and studying projects like Symfony, we believe that the advantages of Drupal's minor upgrade model (e.g. from Drupal 8.2 to Drupal 8.3) can be translated to major upgrades (e.g. from Drupal 8 to Drupal 9). We see a way to keep innovating while providing a smooth upgrade path and learning curve from Drupal 8 to Drupal 9.

Here is how we will accomplish this: we will continue to introduce new features and backwards-compatible changes in Drupal 8 releases. In the process, we sometimes have to deprecate the old systems. Instead of removing old systems, we will keep them in place and encourage module maintainers to update to the new systems. This means that modules and custom code will continue to work. The more we innovate, the more deprecated code there will be in Drupal 8. Over time, maintaining backwards compatibility will become increasingly complex. Eventually, we will reach a point where we simply have too much deprecated code in Drupal 8. At that point, we will choose to remove the deprecated systems and release that as Drupal 9.

This means that Drupal 9.0 should be almost identical to the last Drupal 8 release, minus the deprecated code. It means that when modules take advantage of the latest Drupal 8 APIs and avoid using deprecated code, they should work on Drupal 9. Updating from Drupal 8's latest version to Drupal 9.0.0 should be as easy as updating between minor versions of Drupal 8. It also means that Drupal 9 gives us a clean slate to start innovating more rapidly again.

Why would you upgrade to Drupal 9 then? For the great new features in 9.1. No more features will be added to Drupal 8 after Drupal 9.0. Instead, they will go into Drupal 9.1, 9.2, and so on.

To get the most out of this new approach, we need to make two more improvements. We need to change core so that the exact same module can work with Drupal 8 and 9 if the module developer uses the latest APIs. We also need to provide full data migration from Drupal 6, 7 and 8 to any future release. So long as we make these changes before Drupal 9 and contributed or custom modules take advantage of the latest Drupal 8 APIs, up-to-date sites and modules may just begin using 9.0.0 the day it is is released.

What does this mean for Drupal 7 users?

If you are one of the more than a million sites successfully running on Drupal 7, you might only have one more big upgrade ahead of you.

If you are planning to migrate directly from Drupal 7 to Drupal 9, you should reconsider that approach. In this new model, it might be more beneficial to upgrade to Drupal 8. Once you’ve migrated your site to Drupal 8, subsequent upgrades will be much simpler.

We have more work to do to complete the Drupal 7 to Drupal 8 data migration, but the first Drupal 8 minor release that fully supports it could be 8.4.0, scheduled to be released in October 2017.

What does this mean for Drupal developers?

If you are a module or theme developer, you can continually update to the latest APIs each minor release. Avoid using deprecated code and your module will be compatible with Drupal 9 the day Drupal 9 is released. We have plans to make it easy for developers to identify and update deprecated code.

What does this mean for Drupal core contributors?

If you are a Drupal core contributor and want to introduce new improvements in Drupal core, Drupal 8 is the place to do it! With backwards compatibility layers, even pretty big changes are possible in Drupal 8.

When will Drupal 9 will be released?

We don't know yet, but it shouldn't matter as much either. Innovative Drupal 8 releases will go out on schedule every six months and upgrading to Drupal 9 should become easy. I don't believe we will release Drupal 9 any time soon; we have plenty of features in the works for Drupal 8. Once we know more, we'll follow up with more details.

Thank you

Special thanks to Alex Bronstein, Alex Pott, Gábor Hojtsy, Nathaniel Catchpole and Jess (xjm) for their contributions to this post.

Categories: Development News, Drupal

ZendCon 2017 CFP Started

PHP Announcements - Mon, 03/13/2017 - 20:00
We are happy to announce the CFP for ZendCon 2017 has launched at https://cfp.zendcon.com where we will accept talk submissions until April 14th, 2017. With over 250 million PHP applications driven by a global community of more than 5 million active developers and all enterprises adopting open source software, ZendCon 2017 brings you a curated selection of the best experts, training, and networking opportunities to embrace this vast ecosystem. Take advantage of unique opportunities to attend a wide variety of in-depth technical sessions, participate in exhibit hall activities, and connect with experts. Learn about the best in enterprise PHP and open source development, focusing on the latest for PHP 7, the evolution of frameworks and tools, API excellence, and innovation on many open source technologies related to the web. Experience web development with the very best to accelerate great PHP. Come and enjoy ZendCon 2017 at the Hard Rock Hotel & Casino in Las Vegas. Register Now at http://www.zendcon.com/register-now
Categories: Development News, PHP, PHP News

DrupalCon Baltimore: Learn how to delight your customers

Drupal News - Mon, 03/13/2017 - 10:24

Join us at DrupalCon Baltimore from April 24-28 for a week of inspiration, networking, and learning. Meet Drupal experts and industry leaders who will share new ways to create digital experiences that delight customers, citizens, students, patients, and more.

The event offers programming for decision makers (CIO/Director) as well as digital teams (developers, project managers, site builders, content strategists). Be sure to check out these suggested sessions for both audiences.

Top Five Reasons To Attend DrupalCon
  • Get inspired! Hear Dries Buytaert’s vision for digital transformation and Drupal.
  • Network with peers at 4 industry summits and case study sessions on Bluecross Blueshield, Cornell University, Mass.gov, NBA, Quicken, YMCA, and more.
  • Level up your team's skill with 10 trainings and 161 sessions taught by Drupal masters.
  • Find solution partners. Visit the exhibit hall to meet Drupal’s robust vendor ecosystem.
  • Be Amazed. Meet the open source community that powers Drupal.

Register today. Prices increase March 24th. Attendees can come for the week or just for a day. Plus, the Baltimore Convention Center is easy to reach - just 30 minutes from Baltimore Washington Airport and 15 minutes from the Amtrak Station.

We look forward to seeing you at DrupalCon Baltimore!

Categories: Development News, Drupal
Syndicate content