On the Symfony blog the project has made an announcement about a new addition to the Symfony team to help handle security issues around the framework: Michael Cullum

Handling security issues responsibly and transparently is key to the success of any Open-Source project. Symfony is no exception. We documented the process of our security management policy a long time ago.

[...] Today, I'm very happy and proud to announce that we are getting to the next level. Michael Cullum accepted to join the Symfony Core Team to lead the security team. He will be responsible for managing the security process.

Michael is the secretary of the PHP-FIG group, represents the PHPBB project and is a heavy user of the Symfony framework. Having Michael on the team means that there will be a central point of contact and someone whose primary role is ensuring the safety and security of the overall project and framework.

In a new post to his site Nikola Poša looks at dependency injection containers and shares what he thinks is the right way to use them in your applications.

DIC stands for Dependency Injection Container, which is a tool that manages the construction and wiring up of application services. It closely relates to the letter "D" of a SOLID acronym - Dependency Inversion Principle and is employed to facilitate adhering to the principle.

By their nature, DI Containers are also Service Locator implementations, design pattern that is the exact opposite to Dependency Injection. Because of that, DI Container is a double-edged sword which can mislead you if not used wisely, and ironically bring your code into a state in which there is no dependency injection at all.

He starts off by talking about two kinds of code in an application: core versus assembly. In this case "core" code is the piece of the application that are then used by "assembly" code to make things happen. He suggests that the DIC shouldn't leak into the core and should be put behind a separation between the core code and assembly code. He includes some sample code illustrating what he means and the idea of splitting out the DIC configuration to help that layer clean.

The PHP Roundtable podcast, hosted by PHP community member Sammy Powers, has posted their latest episode - Episode 065: TestFest 2017 with guests Ben Ramsey, Rafael Dohms, Zoe Slattery and Cal Evans.

Adding tests to php-src is a great way to get involved with PHP internals. Don't know how to get started? You're in luck. TestFest 2017 is going to be a thing in September. User groups and individuals around the world are going to organize to learn how to add tests to PHP and become official internals contributors.

It has been 7 years since the last TestFest in 2010. We chat about how to get involved with TestFest 2017.

You can catch this latest episode either using the in-page audio or video player or by watching it directly on YouTube. If you enjoy the episode consider subscribing to their feed and following them on Twitter to get the latest updates when new shows are released.

On the Laravel News site there's a post about a new resource for learning more about Laravel and how the framework really works: Diving Laravel.

Mohamed Said, creator of the Laravel Forge SDK, Laravel Language Manager, and more has launched a new learning resource called Diving Laravel. [...] The site currently has the following topics, and more will be added in the future: The Exception Handler, The Task Scheduler, Package Auto Discovery, The Notifications System, and Diving Redis.

The site breaks each of the components down into "dives" with smaller tutorials covering different aspects in each. All of the content is free for anyone that wishes to get a more in-depth look at what happens under the covers when Laravel handles your code.

The Three Devs and a Maybe Podcast, with hosts Michael Budd, Fraser Hart, Lewis Cains and Edd Mann, has posted their latest episode with guest Joe Watkins. In this latest show Joe and the guys talk about handling signals and garbage collection in PHP.

In this weeks episode we have a long overdue catch-up with Joe Watkins. We start off discussion with progress on PHP 7.1 and work Joe has been doing to provide an interface to libui within PHP. We then move on to chat about a couple of interesting RFC’s that are currently under-discussion, followed by managing long-running PHP processes with Supervisor and Unix signaling. Finally, we highlight how Garbage collection works and how PHP implements the concept to help manage memory.

You can listen to this latest episode either through the in-page audio player or downloading the mp3 directly. If you enjoy the show, be sure to subscribe to their feed to get updates on future shows as they're released.

On the Three Devs and a Maybe podcast they've posted a new show where they're joined by Joe Watkins, a core developer on the PHP development team.

In this weeks episode we are lucky to be joined by Joe Watkins. We start off discussion around the development of PHP 7.1 and the recent initial alpha release. Following this, we give an update on a couple of previously mentioned RFC’s, along with how Joe’s ones are doing. This leads us on to highlight how some small proposed changes are paving the way to optimal machine-code and finally integration of a JIT compiler. Some of these proposed changes may result in backwards compatibility breaks, we discuss this topic and when it is deemed acceptable to permit this. Finally, we chat about memorisation, caching and how it is not really feasible to distill a standard caching interface that fits all requirements.

You can listen to this latest episode either using the in-page audio player or by downloading the mp3 of the show. If you enjoy it, be sure to also subscribe to their feed and get updates on the latest episodes as they're released.

On the SitePoint PHP blog Thomas Punt continues his series about how you can contribute back to the PHP language. In his previous post he talked about contributing to the PHP manual. In this latest part of the series he moves into something with a bit more complexity: contributing to the core of the language itself.

Previously, we covered contributing to PHP’s documentation. Now, we will be covering how to get involved with PHP’s core. To do this, we will be looking at the workflow for fixing a simple bug in the core.

Since submitting new features to PHP has already been explained pretty well, we will not be covering that here. Also, this article does not seek to teach PHP’s internals. For more information on that, please see my previous posts on adding features to PHP.

In this article he assumes you at least already have a working knowledge of the PHP source and how to locate/update code and execute it. He focuses instead on the bugfix process and workflow needed to:

• find a bug to fix
• create a test to reproduce the issue
• use a debugger to find the exact spot where the problem is
• and create a simple fix

In this case it's a pretty simple issue to correct, but there are much more complex things that would require more work than just a simple "if" check. This guide can help you get started on the correct workflow, however, and be sure you're handling things as the project expects.

The Check Point blog has posted the first part of a series from one of their vulnerability researchers about finding security vulnerabilities in the core WordPress code (and some of the results along with CVE numbers).

In this series of blog posts, Check Point vulnerability researcher Netanel Rubin tells a story in three acts – describing his long path of discovered flaws and vulnerabilities in core WordPress, leading him from a read-only ‘Subscriber’ user, through creating, editing and deleting posts, and all the way to performing SQL injection and persistent XSS attacks on 20% of the popular web.

In this first part he focuses on the concept of "identity" in a WordPress application. He focused on the "roles and capabilities" functionality to find bypass methods in operations like editing and adding new posts. As he works through his process, code is included from the WordPress core showing where the issue(s) lie and what would be needed to exploit the issue.

Evert Pot has shared some of his thoughts about why he has a problem with password_hash (and friends). His thoughts are initially about this particular feature but they're actually wider than that.

The initial introduction and rfc for these functions made me uneasy, and I felt like a lone voice against many in that I thought something bad was happening. I felt that they should not be added to the PHP engine. I think that we should not extend the PHP engine, when it's possible to write the same API in userland, or there are significant benefits to do it in PHP, such as performance. Since the heavy lifting of the password functions is done by underlying libraries that are already exposed to userland-PHP, it didn't make sense to me to expose it as well in the core.

He includes a list of things he sees as drawbacks for new C-based functionality in PHP including the fact that it extends the "PHP specification" and forces other projects to implement it (like HHVM). He does include a few positives, though, such as the increased visibility and legitimacy, but still thinks they don't outweigh the negatives.

The Voices of the ElePHPant podcast has posted their latest episode in their series of community interviews. This time host Cal Evans talks with Elizabeth Smith, a well-known PHP community member, speaker and core developer.

Cal and Elizabeth talk about her work contributing to the core of the PHP language and the PHP Mentoring organization she's currently involved with (and helped start).

You can listen to this latest episode either through the in-page audio player or by downloading the mp3 for listening at your leisure. If you enjoy the episode, be sure to subscribe to their feed.