Return self-update

[ErichHartmann]

2087 #2088 Removed self-update. I realize phive is another dog food pet project of yours, but after sometime I find phpunit is not being kept as current by me as in the past. We need fewer "yet another tool du jour", not more. This is a particular attention deficit hyperactivity disorder that plagues the javascript community and I don't think we need to subscribe to it.

I recommend if you want to support phive with the capability then so be it, but forcing what is already simply done with an https call is unnecessary for many of us.

[sebastianbergmann]

I am sorry that you do not agree with my decision but I will not revert it.

[ErichHartmann]

Well, a simple bash script fixes the issue for me. Your motivation for this action is transparent and don't serve you or phpunit well.

[sebastianbergmann]

My motivation is to make it easy and convenient for users to verify the code they download and execute by using GPG.

[theseer]

As one of the authors of phive I might be considered biased but let me add a few words anyhow:

The previously existing implementation of self-update was problematic and had already been in parts been modified based on my input. It was never completely secure though.

Let me explain why:

• It's far more than a simple wget if you want to do it right:

  • For a global installation, you are likely to require root privileges to overwrite the binary
  • Self-update doesn't make any sense on a composer or OS package install
    • that alone causes an inconsistent api
    • It would break OS package handling when it would be available there
  • Using HTTPS for the transport is good but doesn't say anything about the actual validity of the downloaded archive
  • Unless your installation would be on a per-project basis, replacing a shared copy may break other projects on the same system as there is no way to know their dependencies

• The Self-update did not verify the GPG signature of the release

• A tool should focus on doing its job. I personally do not understand why a tool would need to implement a means of updating itself - particularly if no verification is done and the concept of package management exists. I do realize the latter may be different on windows, but a tool should not fix the design flaws or shortcomings of the OS it may be executed in.

tl;dr: Whether the move is "transparent" or not, the previously existing implementation was lacking and not as secure as it should have been.

[ErichHartmann]

@theseer Let's assume all of your points are true for phpunit, despite me not being in full agreement. If all of that is true for phpunit, it is just as true for phive. Among other issues, if I went to look at phive, would I find a self-update command?

Given all that, phive isn't a stand-alone component or plugin that phpunit incorporates into its own code to add the benefit of updating via a secure best practice. If it were just such a component it would be sebastianbergmann's problem to maintain it, fix it, keep up with it.

You didn't go that route. Instead, it's standalone on my systems and it's my headache. Now I need to update phpunit AND I need update phive. I'll bet phive leaves all kinds of cache garbage laying around my systems' drives as well. You see what I am getting at here? phive doesn't solve a big enough problem to justify that kind of commitment and hassle.

Instead of just being helpful, phive apparently wants to be an eco system -- in other words a marketing gimmick.

It's an unnecessary dependency with all the potential problems that entails for little to no gain.

A few lines of bash script has me simply reinstalling phpunit from scratch without the mess. It was just more helpful when phpunit had the self-update command... you know, like composer.

[theseer]

@ErichHartmann

Let's assume all of your points are true for phpunit [...] If all of that is true for phpunit, it is just as true for phive.

Incorrect. Phive's purpose is to provide an easy and secure way of installing tools that are distributed as phar so to not clutter the vendor directory with pointless dependencies. I honestly fail to see how this would qualify as a marketing gimmick. Marketing for what and whom's benefit anyway?

Phive by default makes per-project installations, thus never messing with any tool installations other projects might require. All the security problems mentioned in my previous comment are being dealt with by using phive. You get the benefits of installing a tool with composer without all the down sides and with actual security.

if I went to look at phive, would I find a self-update command?

Sure you would, as it's phive purpose to manage phar installations there is no reason to not have it manage itself.

Given all that, phive isn't a stand-alone component or plugin that phpunit incorporates into its own code to add the benefit of updating via a secure best practice.

See phive issue #19.

If it were just such a component it would be sebastianbergmann's problem to maintain it, fix it, keep up with it.

I'm not sure I understand this statement.

Instead, it's standalone on my systems and it's my headache. Now I need to update phpunit AND I need update phive.

I'm not convinced it's a headache but for sake of the argument, yes, you would have to update phive every now and then. As well as PHP, your OS, and pretty much any other thing you have installed. Phive simply makes installing and updating phars easy. Nobody forces you to use it. It's just one of many possible ways to install PHPUnit.

I'll bet phive leaves all kinds of cache garbage laying around my systems' drives as well.

It has a keyring for the gpg keys and a folder for the phars in a central location. As it's a working directory, it doesn't technically qualify as cache.

You see what I am getting at here? phive doesn't solve a big enough problem to justify that kind of commitment and hassle.

Phive solves a lot of problems. Apart from providing actual security it also removes tool dependencies from composer, leading to a lot less clatter and conflicts: Why anyone ever considered it useful to combine runtime dependencies with tool dependencies and have them even potentially conflict, is beyond me. Why would anyone care if tool a needs library X in version 1, and tool b the same library in version 2? And why would that even cause a conflict?

Arguably, phive doesn't solve that. It simply helps avoiding the situation by providing an alternative and imho better way of installing tools. Whether or not that is enough [..] to justify [.. the] hassle is of course completely up to you.

Instead of just being helpful, phive apparently wants to be an eco system -- in other words a marketing gimmick.

You lost me here. Phive provides a means to automate the process of

• downloading a phar from say github's release page, without the need to know the exact url
• download the accompanying gpg signature
• providing a way to query key servers and import unknown keys
• verifying the integrity of the phar
  • making it executable

The only "ecosystemy"-thing might be the fact it keeps track of what it did to provide any easy way of cleaning up, updating and reinstalling. I really fail to see where this is in any way marketing?

A few lines of bash script has me simply reinstalling phpunit from scratch without the mess.

If that works for you, awesome. I presume your few lines of bash script do all the things i just wrote a few lines above? And of course it does that for every project individually with the matching version constraint, correct?

It was just more helpful when phpunit had the self-update command... you know, like composer.

It may have seemed convenient but was broken, limited and potentially dangerous.