For those Phar users out there Théo Fidry has written up a guide to help you create and deploy them securely with the help of a few tools and OpenSSL to sign the release to ensure integrity.

For those who are not familiar with it, PHAR (Php Archive) is analogous to the JAR file concept but for PHP. It allows you to package an application into a single file making it convenient to deploy or distribute.

[...] So what are PHARs useful for then? Well still the same thing: packaging applications. Although not many people may want to use this technique for web applications, it is still extremely useful for console applications.

The tutorial starts off by showing a few different methods for installing Phars and how to build them from your code. While they can be built manually, he suggests using the box project to help make it simpler. It also covers self-updating phars and shows how to update the box.json configuration to use a generated key to sign the release. Finally it covers a method for using Travis-CI to auto-build the phar and how to keep the OpenSSL key safe and out of the checked in code.

In this post to the bitExpert blog Stephan Hochdörfer shares some updates to his own opinions on the "require-dev gone wrong" problem he previously posted about. In this new post he points out that, while there is an issue here, it's not something that can't be resolved (or has been to some extent).

The gist of all this is that, yes, we do have a problem. Fortunately, there are already solutions out there - none of them perfect, but there's always room for improvement isn't there? Installing .phars with Composer is currently not supported out-of-the-box by Composer but there are 2 projects to help us deal with it: One is tooly-composer-script - a Composer plugin that manages to pull .phar files from a remote location. The other one is PHIVE - the PHAR Installation and Verification Environment.

He points out that, while these two packages help the situation, there's still another "require-dev" issue with tools that don't actually "touch" the code. This requires that a certain version of the tool be run against a certain version of your code, creating a dependency of a different kind. Fortunately there's also a tool to help some with this as well, the php-scoper project that makes it easier to isolate functionality through randomly generated namespaces.

Rob Allen has a new post to his site sharing the work he's done to get PHPUnit managed with Phive, an "installation and verification environment" that is used in the installation of Phar archives.

I recently came across the Phive project and have had a play with it. Phive is part of phar.io and is intended to manage development tools such as PHPUnit in preference to using Composer's dev dependencies. The main advantages of Phive are that it uses the phar file of the tool and only keeps one copy of each version rather than downloading a new copy into each project.

He starts off talking briefly about how the tool works and what it's doing behind the scenes to download the phar archives requested. He shows how to define a target directory, install for global use and explains how GPG signatures work into the installation process.

On the Sculpin blog Beau Simensen has posted an update about a change in how the project will be released in the future, most notably deprecating the phar release and switching to an embedded Composer installation.

If you are currently using a globally installed phar distribution for Sculpin you should migrate to a per-project Composer installed version of Sculpin as soon as you can. [...] Any plans for Sculpin 3 would have required reworking the phar build and distribution process

In typical programmer fashion, I let myself get bogged down in the details of eventually needing to deploy Sculpin 3 phar builds rather than working on Sculpin 3. What little time I had to spend on Sculpin last year was sunk on solving this problem. [...] The last officially available Sculpin phar is not compatible with PHP 7.

He talks about his earlier goals to make v3 of Sculpin PHP 7-only but, in the process of the work to get to that point, several roadblocks came up preventing it. He talks about self-updating phars and finally realizing that, for the good of the project, a move to the embedded Composer setup is the best method for keeping dependencies in sync. He ends the post with the steps you'll need to take to migrate from the phar release to the managed version and an example commit of how the Sculpin site itself was migrated.

Christian Weiske has a quick tip posted to his site for those using phar archives in PHP and how to remove the .phar extension and still have them execute correctly.

I'm shipping a new side project as .phar file, php-sqllint.phar. The phar stub has a shebang line so that I can call it without explicitly running PHP. [...] When making the file executable with chmod +x, you can simply execute it.

He wanted to remove the extension but was greeted with an error message when he tried to execute the result. He stumbled on the solution in this PHPUnit bug and corrected the problem with a call to the Phar::mapPhar method inside the phar archive file.

There's always been an issue with the creation of Phar packages in PHP and the security around them. There's been recommendations about creating signatures and only using secure connections for updates and rollbacks. Unfortunately there isn't an overly easy way to handle this yet. However, Matthew Weier O'Phinney has written up a post showing his workflow for doing these kinds of things, making use of the Box project to help with some of the more detailed parts.

For a variety of reasons, I've been working on a utility that is best distributed via PHAR file. As has been noted by others (archive.is link, due to lack of availability of original site), PHAR distribution, while useful, is not without security concerns, and I decided to investigate how to securely create, distribute, and update PHAR utilities as part of this exercise.

This is an account of my journey, as well as concrete steps you can take to secure your own PHAR downloads.

He starts by outlining the "roadmap" of the features he wants to include and the steps to take to create this more secure phar archive. It includes the use of both current, local tools and services (like Box and GitHub pages). He then walks through the steps in the full process:

• Create an OpenSSL Key
• Use Box to create the PHAR
• Generate a version file
• Create the gh-pages branch
• Write self-update/rollback commands
• Enable Travis-CI for the repository
• Create an SSH deploy key
• Archive and encrypt the secrets
• Write a deployment script
• Add the script to travis

While this seems like a lot of steps to just get a more secure phar set up, Matthew has done the hard work for you here and includes all of the commands, configuration examples and steps you'll need to take to fully set the process up. If all goes well, his example in his last "push and watch it work" section will go off without a hitch.

The ServerGrove blog has posted an introduction to the PHAR format, a built-in method to use PHP and create self-contained functional scripts as a single *.phar file making it much easier to transport.

In the last years there is a trend in the PHP community to release tools, especially command line utilities, as PHAR files, so you can package an entire PHP application into a single file for convenience. But, how PHAR files work? In this post we will try to explain it.

They cover a few of the basic topics first: what is a PHAR file and a few examples of them being provided by major PHP projects. They then get into the creation of an archive, showing how to make a super simple PHAR "Hello World" archive, created with just a bit of PHP. They then get into the structure behind the archive and get into detail on each section (stub, manifest, file contents and signature).

The SitePoint PHP blog has a new tutorial posted showing you how to easily package up your application with Box to make phar files without the extra hassle of building them yourself.

In this tutorial, we’ll use Box to package a PHP application into a Phar, in order to make it easily distributable and globally installable via Composer.

For his example he uses the PHP portion of the FolderBuilder project and makes a command-line executable that can return the information for a directory as JSON data. He starts by installing the "box" executable command on a local VM and defines the simple configuration file, a "box.json" with some basic settings. He then clones the FolderBuilder project, updates the configuration for the correct locations and files and executes the "build" command. The result is a phar file that contains the PHP script functionality. He also updates the configuration to make the result executable with a "chmod" setting, removing the need to call it with the PHP command line version. He ends the post showing how to test it out, taking the results and dropping them into FolderBuilder to make sure they're 100% correct.

Pádraic Brady has a new post to his site today talking about creating self-updating phars in PHP using his package created based on previous recommendations.

In all seriousness, phar-updater is my implementation of recommendations I made in a previous blog post around self-updating PHAR files. Those recommendations were, predictably for me, largely concerned with self-updating from a security perspective. Implementing it brought ease of use and flexible integration to the fore also. It can be surprising what a little extra work, testing and packaging can accomplish for reuse compared to throwing code into one file and calling it a day. It’s been integrated into Humbug with nary an issue.

The package makes it simple to integrate the self-update functionality into your existing phar package deployment including updating running versions, enforcement of TLS connections and allows for configuration of updates based on version numbers. You can see his own example in his Humbug package's "SelfUpdate" class.

The Three Devs & A Maybe podcast has posted their latest episode, #66 - Easy Like a Sunday Morning, with hosts Michael Budd, Fraser Hart, Lewis Cains and Edd Mann.

This week on a early Sunday morning recording, we start off podcast discussion with A/B testing and Google Analytics/Experiments. We then move on to touch upon distributing PHP console applications within PHAR's, application security and Google's recent IO conference. Following this we bring up a couple of small projects Edd is currently working on, relating to Morse Code and Colour detection algorithms. Finally, we wrap up the show by discussing the current Space Beer Cave competition that is still underway, and how one contestant is running away with the prize at this time.

Other topics mentioned include Box PHP, Ghostery and the missing mcrypt extension. You can listen to this latest episode either through the in-page audio player or by downloading the mp3. If you enjoy the show, be sure to subscribe to their feed or over in iTunes to get the latest shows as they're released.