The humbug_get_contents() was improved a bit in later weeks but those changes need to be integrated with phar-updater. For now, I've limited the dependency version used.

If testing a phar configured to be updated from a signed phar, but unsigned for testing purposes only, phar-updater throws an exception due to missing pubkey. We can make testing easier by deferring the pubkey check to an actual self-update op.

the issue described in:
humbug/file_get_contents#4

causes the github strategy (on PHP < 5.6.0) to fail with:
file_get_contents(): Peer certificate CN=s3.amazonaws.com' did not match expected CN=github.com'

I still find the PHAR-Updater really backbone which leads to way too much boilertemplates for each project. A good example is the difference between PHP-Scoper and Infection self update commands. There is way too much boiler-templates, the usage is not clear enough.

IMO we should provide a Symfony bridge so that adding a self-update command would not be more than registering a command that might need a bit of configuration but not more. If too opinionated for some people, they could always do things their own way instead of using the default command.

It might be worth to check how other projects did it as well and go for a sane default. Even if very big BC breaks, 2.0 should be done right.

I would like unprivileged system users, who do not have the ability to run self-update commands, to be able to check if an update for the command is available. Currently, the following results in an exception:

        $updater = new Updater(null, false);

        $updater->getStrategy()->setPharUrl($updateDomain . '/app/current.phar');
        $updater->getStrategy()->setVersionUrl($updateDomain . '/app/current.version');

        try {
            $result = $updater->hasUpdate();
            if ($result) {
                echo "update available";
            } else {
                echo "update NOT available";
            }

Here's the exception of the local phar file is not writable:

[Humbug\SelfUpdate\Exception\FilesystemException]
The current phar file is not writeable and cannot be replaced: /usr/bin/bobafetch.

I think the new Updater() is checking for writability... but writing shouldn't be required to check for updates.

Implementation issue where we're not stashing the result of getCurrentRemoteVersion() in backend Strategy and can end up hitting Packagist more than once.

the updater should look after the common proxy environment variables and try to connect through the proxy if they are set.

NO_PROXY
HTTPS_PROXY
HTTP_PROXY

Appears on Travis and looks like:

2) Humbug\Test\SelfUpdate\UpdaterTest::testUpdatePhar
PharException: phar has a broken or unsupported signature

/home/padraic/projects/phar-updater/src/Updater.php:470
/home/padraic/projects/phar-updater/src/Updater.php:364
/home/padraic/projects/phar-updater/src/Updater.php:139
/home/padraic/projects/phar-updater/tests/Humbug/Test/SelfUpdate/UpdaterTest.php:145

From what I've been able to tell, this is probably a straight up incompatibility within HHVM, but figured I'd note it here anyway. It would likely then impact any openssl signed PHAR beyond this project. Someone else have other ideas, or has better familiarity with HHVM, so let me know.

Hi, is this project currently maintained or are you looking for maintainers?

https://github.com/composer/semver

Kind of silly to be rolling our own if there is a way to integrate this instead.

When rolling back to an older release (but there is none), the result message isn't an error, but it suggests a successful rollback anyway.

Edit: Actually there is a backup - the problem is that we're not deleting backups after failed downloads, so rollbacks always succeed in that event. The impact is harmless but should be avoided by cleaning up after download errors.

Minor cleanup but should be handled if created at original phar location.

Hello,
I have noticed an issue recently :
The package "padraic/phar-updater" requires "padraic/humbug_get_contents" version 1.0.4 but not newest version 1.1.2, which create failure in security check.

Are you going to update package "padraic/phar-updater" for solving this issue ?

Thanks in advance.

Symfony Security Check Report

// Checked file: /my_project/apache/volume/composer.lock

[ERROR] 1 packages have known vulnerabilities.

padraic/humbug_get_contents (1.0.4)

• CVE-2016-5385: HTTP Proxy header vulnerability
  https://github.com/humbug/file_get_contents/releases/tag/1.1.2

! [NOTE] This checker can only detect vulnerabilities that are referenced in
! the SensioLabs security advisories database. Execute this command
! regularly to check the newly discovered vulnerabilities.

Loaded config default from ".php_cs.dist".

PHP requirement is 5.6, there's no need for the transitional package at this point for earlier versions.

https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

"We hope that our practical attack against SHA-1 will finally convince the industry that it is urgent to move to safer alternatives such as SHA-256."

currently the strategy is using:
https://packagist.org/packages/vendor/package.json
which is a json representation of the package site and has a pretty long cache timer (1h),

while composer uses the actual API:
https://packagist.org/p/vendor/package.json
which has only 1m cache time

phar-updater should be using the sami API as composer here.

In certain scenarios, a version can be injected into PHARs which is of the form: 1.0.0-26-gh378sj7.

The first part is a recognisable version number. The second part is the number of commits that the referenced build is ahead of the 1.0.0 tag by. The third part, prefixed with a g is the current commit hash.

The current solution (see #34) is to simple strip out the metadata, i.e. you end up with 1.0.0 as the normalised version. Clearly, that is not the correct answer. The correct answer is that this is a pre-release version not even marked alpha (i.e. it's 26 commits ahead of the actual 1.0.0). This tends to show up where versions are automated via box.

Solutions?

1. Inject pre-release marker if not already present (we can easily check if a pre-release label, like alpha is already attached). Probably use -dev if none already present: 1.0.0-26-gh378sj7 becomes 1.0.0-dev.26-gh378sj7
2. Strip the commit hash as useless information: 1.0.0-dev.26-gh378sj7 becomes 1.0.0-dev.26
3. Check if the revised version can be evaluation by Composer\Semver, and properly compared.

Other solution?
Report to Composer? I'm really not feeling this as being their problem though. Under Semver, one would expect metadata to be attached using a + sign. It's not!

Report to Box? That's more realistic, but they may have entirely alternative reasons for why this is valid.

Thanks for this library - I am going to use it instead of the abandoned project https://github.com/kherge-abandoned/php-phar-update. One advantage that had was to grab available versions and SHA1 hashes from a single "manifest" file.

I've written a custom strategy to handle this for our project:
https://github.com/pjcdawkins/platformsh-cli/blob/replace-phar-update/src/SelfUpdate/ManifestStrategy.php

and here's what the manifest file looks like:
https://platform.sh/cli/manifest.json

It seems like this could be generalised for anyone, would you be interested if I made a PR?

When you try to setup a different backup path using the documented setBackupPath() it goes to great lengths to ensure it is a directory. However, if you try to update the phar it is assumed in getBackupPharFile() that the backup path is actually to a file. When you then try and run the command it fails on line 364 of Updater.php because you cannot copy a file to a directory in that way.