Sammy Powers has a new post to his site today showing you how to find and patch a bug in php-src, the source of the PHP language itself.

While he does provide all of the details in the post he also has created a screencast that walks you through the whole process as well. He breaks up the process into the different steps of the process:

• Find the bug (his was with the JSON handling)
• Submit a bug report (on bugs.php.net)
• Make a patch
• Run GDB
• Make a test
• Submit a PR and update the bug

He includes code and descriptions along the way and finishes out with further suggestions about feedback on the PR and how his own situation finished out.

Jeff Madsen has a post on his Medium blog sharing some of his thoughts about immutable DateTime types, what the difference is between mutable and immutable and "why you should care".

I’m going to show you the difference between the two using two popular Php DateTime libraries? - Carbon and Chronos, and then demonstrate the danger of using the mutable one of those.

You have probably used Carbon? - ?it is a wonderful library put together by Brian Nesbitt that takes all the pain out of working with dates. It has got one “short-coming”, if you will?- ?it is built on top of the DateTime object.

He gives an example of why this is a problem with Carbon (mutable) and how it's handled differently in Chronos (immutable). He makes the point that, unless your date values are immutable, you don't have any idea of they've changed elsewhere in the processing. He gives a more real-world example of working with immutable objects with a "user" model class and the "name" properties attached to it.

On the Exakat GitHub account Damien Seguy has put together a pretty complete list of static analyzers you can use for your PHP applications.

The list is broken down into the types of scanners:

• Bugs finders
• Coding standards
• DIY
• Fixers
• Metrics
• SaaS
• Misc

Each section includes a good list of tools and links to each of them (usually just to other GitHub repositories but some go to actual project pages). There's a lot of them to look through but be careful to evaluate the current state of the project. Just because it's linked here doesn't mean it's a complete tool.

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.

In a post to his site Leonid Mamchenkov shares an interesting output bug he came across in his work developing cron jobs and how they handled his errors.

We came across this PHP bug at work today. But before you go and read it, let me show you a use case. See, if you can spot the problem. We had a cron job script which [ran a PHP script and echoed a string when complete].

[...] We use similar code snippets all over the place, and they work fine. This particular one was a new addition. So the cron job ran and “Updating products failed” part happened. Weird. The PHP script in question has plenty of logging in it, but nothing was logged.

After adding more and more logging to the process and PHP script, nothing obvious was standing out. Finally, they noticed that the filename was incorrect but normally that would cause an error in the PHP command line execution. The tricky part here was in how PHP handled its errors. Their error_log and display_errors settings were such that the PHP "missing file" error was being swallowed up and not displayed.

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.

In the wake of the announcement of the Heartbleed vulnerability in the widely used OpenSSL software, the PHPClasses blog has posted a look at how it relates to PHP applications and how you can see if your application is effected.

Just a few days ago it was publicly announced a serious security bug called Heartbleed that affects secure sites based on the OpenSSL library. Read this article to learn more about this security problem, how to test if your Web server or SSH server is vulnerable, how it may affect your PHP sites, what you should do to fix the problem.

They start with a look at the bug, what it is and why it's such a big problem. It talks about what kinds of applications are vulnerable (hint: it has nothing to do with the PHP) and how you can test to see if your server is secure. The rest of the post talks about how to resolve the issue and how it relates to OpenSSL connections to other servers and SSH.

Evert Pot has posted an update to a previous post around Composer's vulnerability around installing the wrong packages in the case of a conflict. In this latest post he points out, however, that the bug is now fixed.

As an update to my previous post, the composer security problem now appears fixed. Good to see that a quick response was possible after all.

The original issue was caused by the "replace" functionality, allowing the possibility for an incorrect package to be installed instead of the one requested. Other posts with more details include this one from Pádraic Brady and Nils Adermann. if you're a Composer user, it's highly suggested you update your currently installed version (run a "composer self-update").

Christian Weiske has posted information about a feature in the upcoming PHP 5.6 version of the language - large file upload support. This new feature allows files over 4GB to be uploaded correctly.

PHP version 5.6 brings support for file uploads larger than 2GiB. We can say "thank you" to Ralf Lang for the initial patch that fixes bug #44522 , which was open since 2008. During testing uploads of files with a size of 4 - 11GiB on my PHP-CGI setup, I noticed that files above 4GiB did not get uploaded correctly. Michael Wallner was quick to fix that bug, and now 5.6 has fully working support for big files.

PHP 5.6 is still in development and some other new features are slated to be added to it. You can find some of them listed in the RFC section of the PHP wiki.

Joshua Thijssen has put together a new post with details about garbage collection in PHP and a "nice bug/feature/whatsmathing" he found related to it and its performance.

I was playing around with writing a daemon and if you have any experience writing daemons (in any language), there are a few rules you have to live by. For instance, setting your effective uid and gid to a non-privileged user (in case you needed to do some privileged initialization, like opening a socket on a tcp port < 1024), setting the process as a group leader with posix_setsid(), and redirecting stdio file descriptions. And here something went wrong which took a while to find and fix..

He was creating a daemon and the script would just exit without a warning and not continue running. He narrowed down the issue to a few lines (with fopen and fclose) and went to debug it with strace to really see what was happening. He found some unexpected calls in the stack trace and, after some more digging, finally figured out it was a problem of both scope and cleanup that was resulting in the extra calls.