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.

In a new post to his site Mattias Geniar looks at an old security issue in PHP, opcache information leakage and how to mitigating the issue.

A very old security vulnerability has been fixed in PHP regarding the way it handles its OPCaches in environments where a single master process shares multiple PHP-FPM pools. This is the most common way to run PHP nowadays and might affect you, too.

He starts by talking about the vulnerability itself, that the PHP process doesn't validate the userid when fetching cached bytecode. This could result in information from other operations/scripts being exposed to other processes in a PHP-FPM pool. His solution? Upgrade PHP (the bug is fixed back in PHP 5.6.5) and set a few additional opcache ini settings to enforce the validation. Besides 5.6.29, it was also corrected in the PHP 7 releases (7.0.14 and 7.1.0). The post then talks about the potential exploit - an indirect local privilege escalation to root where the shared memory is read and access to outside information is possible.

Sometimes finding that one spot in your code that's geting bloated and consuming at majority of your memory can be a bit difficult. Antony Dovgal has proposed one solution in a new post to his blog - the memtrack extension for from PECL.

We needed to locate where most of the memory is allocated in our scripts (as some of them became too memory hungry), so I've created memtrack extension. This extension helps us to see unusually big memory allocations in production code.

The extension logs memory usage information out to the standard error log file (however that'd defined on your system) and comes with a few configuration options. These let you control things like a "soft limit" at which to report the usage problems, the ability to ignore certain functions that you might know will cause a high load and and "vm_limit" setting that can help if your script is leaking memory at the end of its run.

On the SitePoint PHP blog today, Troels Knak-Nielsen has written up an article that talks about dependencies in your applications - those little interconnections your code relies on to do more with less.

In lack of better words, I'll call this compositional programming style. It's a style which is usually more prevalent with experienced programmers. [...] There is, however, a dark side to composition — dependencies.

He starts with a definition to bring everyone up to a level field then moves on to how their used (through a "global symbol" or directly passed in) and how they can "leak" if you're not careful.

To help protect you and your code from any kind of damage down the line, Troels suggests making a container to keep objects where they need to be. He even includes an example with namespace support to make things even easier down the road.

Christopher Jones talks today on his blog about a bug he's just corrected and integrated into the release of the Oracle Instant Client that lets PHP correctly take advantage of the temporary LOBS functionality.

When PHP is done with the temporary LOB, it needs to tell Oracle to destroy it. If this isn't done, then the temporary LOB will hang around using DB space until the connection is closed. I just merged a fix worked on by Krishna Mohan and myself for bug 43497.

Example code is included showing two instances of its use - a normal use that frees the memory correctly and the other showing how to create the temporary lob to hold the data as needed.

Paul Jones presents a problem he was having in a new post to his blog - the issue was with memory leaks in objects in a PHP5 application he was working on.

One of the nice things about using a scripting language is that it automates garbage collection for you. You don't have to worry about releasing memory when you’re done with your variables. [...] But there is at least one circumstance in which PHP will not free memory for you when you call unset(). Cf. http://bugs.php.net/bug.php?id=33595.

The problem is that, when trying to unset the parent object in a parent/child relationship, the memory space for the parent reference in the child isn't removed. The problem, left unchecked can cause a script to go over the memory limit pretty easily (especially with larger objects).

He suggests two solutions - one that the user can control (calling a destructor before unsetting the object) or a PHP internals method that involves fixing issues with the reference counts created with the objects.

Paul Jones presents a problem he was having in a new post to his blog - the issue was with memory leaks in objects in a PHP5 application he was working on.

One of the nice things about using a scripting language is that it automates garbage collection for you. You don't have to worry about releasing memory when you’re done with your variables. [...] But there is at least one circumstance in which PHP will not free memory for you when you call unset(). Cf. http://bugs.php.net/bug.php?id=33595.

The problem is that, when trying to unset the parent object in a parent/child relationship, the memory space for the parent reference in the child isn't removed. The problem, left unchecked can cause a script to go over the memory limit pretty easily (especially with larger objects).

He suggests two solutions - one that the user can control (calling a destructor before unsetting the object) or a PHP internals method that involves fixing issues with the reference counts created with the objects.

As many people noted in the past few days, there was a code leak over on Facebook.com. Some of the PHP code that runs the website was exposed as plain text to viewers. Unfortunately, several people are blaming PHP as the source of the issue including Nik Cubrilovic, a writer for TechCrunch:

I just posted on TC about the Facebook code leak. PHP has always been notorious for sometimes not processing requests poorly and sending back the source code for pages to the client. Because of the way mod_php works with apache, if mod_php fails in intercepting and processing the request, then apache will just serve it back to the client as an ordinary text file.

Of course, the PHP community is speaking back to the allegations including Clay Loveless in a new blog entry on his site:

I agree with Cubrilovic that the inadvertent delivery of source code instead of the result of that source code is certainly a horrific situation, with potentially serious ramifications for any company that experiences such a problem on a large scale basis. [...] Unfortunately, the updates appended to the article imply that PHP is somehow responsible for this leakage.

He supports some of the issues (a server misconfiguration could cause odd behavior) but refutes others (the "known issue" of PHP pushing out source code under high load).

As many people noted in the past few days, there was a code leak over on Facebook.com. Some of the PHP code that runs the website was exposed as plain text to viewers. Unfortunately, several people are blaming PHP as the source of the issue including Nik Cubrilovic, a writer for TechCrunch:

I just posted on TC about the Facebook code leak. PHP has always been notorious for sometimes not processing requests poorly and sending back the source code for pages to the client. Because of the way mod_php works with apache, if mod_php fails in intercepting and processing the request, then apache will just serve it back to the client as an ordinary text file.

Of course, the PHP community is speaking back to the allegations including Clay Loveless in a new blog entry on his site:

I agree with Cubrilovic that the inadvertent delivery of source code instead of the result of that source code is certainly a horrific situation, with potentially serious ramifications for any company that experiences such a problem on a large scale basis. [...] Unfortunately, the updates appended to the article imply that PHP is somehow responsible for this leakage.

He supports some of the issues (a server misconfiguration could cause odd behavior) but refutes others (the "known issue" of PHP pushing out source code under high load).

The SuSE linux group has released new packages, according to this post on the PHP Magazine site, to deal with the XSS and information leak issues found recently in PHP4 and PHP5.

It is strongly suggested that you upgrade your installation to prevent any issues/problems from arrising.