Skip to content
This repository has been archived by the owner on Mar 15, 2020. It is now read-only.

Checking hasUpdate() should not require is_writable for phar file. #20

Open
jxn opened this issue Mar 7, 2017 · 6 comments
Open

Checking hasUpdate() should not require is_writable for phar file. #20

jxn opened this issue Mar 7, 2017 · 6 comments
Milestone

Comments

@jxn
Copy link

jxn commented Mar 7, 2017

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.

@aik099
Copy link
Contributor

aik099 commented Mar 8, 2017

What would be a use case for this?

@jxn
Copy link
Author

jxn commented Mar 8, 2017

This comes up often for me with scripts which are globally installed.

For instance, we deploy a phar automatically to /usr/bin/myscript which is used by users across the system. Most of the users use the phar, but only one should be allowed to update it. In the event of a failure when an unprivileged user uses the phar, she should be able to see if the phar is up to date, and request that the administrator update it.

Ideally, we would be able to institute a check when users run other commands, which would use phar-updater to check if the latest version is in use. Then, when a user ran myscript some:command, they would be warned that "myscript" is not up-to-date. Currently, that would throw an error and prevent all unprivileged users from running any command.

Additionally, we have scripts that do integrity checks on systems. These scripts should not be able to write to the system, but it would be nice if they could check if globally-installed phar files are up-to-date and report that to system administrators.

@jxn
Copy link
Author

jxn commented Mar 8, 2017

I have added this in PR #21

@aik099
Copy link
Contributor

aik099 commented Mar 8, 2017

In the event of a failure when an unprivileged user uses the phar, she should be able to see if the phar is up to date, and request that the administrator update it.

That's what I imagined myself. But on the other hand isn't it's administrator job to ensure all stuff is up to date and not forward that task on regular user 😄

Then, when a user ran myscript some:command, they would be warned that "myscript" is not up-to-date. Currently, that would throw an error and prevent all unprivileged users from running any command.

I'd like that, but again this could be an option because displaying your app is out of date message to user that can't really update it adds more confusion. In your case I admit it can be useful.

Can you please also attach an exception trace?

@padraic
Copy link
Collaborator

padraic commented Mar 29, 2017

I've been AWOL for a while, but I'll doing a round of PR reviews eventually. I see no harm in this change myself if it's useful.

@padraic padraic added this to the 1.1.0 milestone May 14, 2017
@tschach
Copy link

tschach commented Jul 11, 2018

Hi,
what is the status of this? I came across the issue using a third-party application that includes phar-updater. If someone could give me some pointers, I would be willing to help solving this issue.
Best, Tobias

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants