Allow insecure installation of phar files

[djmattyg007]

It would be nice to be able to use phive to manage the installation of any phar file, not just those that are signed with PGP keys.

[theseer]

That kind of defeats the purpose of phive, doesn't it?
It would reduce phive to be a glorified wget ;)

[djmattyg007]

I don't agree. Phive does a wonderful job of automating the process of updating and verifying phar files for those that are signed with PGP keys. However, I'm still going to use some phar files from vendors that I trust that aren't signed with PGP keys.

If Phive doesn't support this use case, I'm more likely to forgo Phive entirely and instead write a custom script to run wget to obtain all the phar files I need. This increases the chances of me getting the PGP signature verification wrong, as I also have to run those commands manually.

The point is that an all-or-nothing approach is not particularly helpful. Whether or not something supports installation by Phive isn't going to prevent someone from using that tool, so you're better off supporting more use cases so that the end user still benefits from the advantages brought by Phive at least a little bit.

[theseer]

Okay, point taken.

[djmattyg007]

I'd be happy to work on a PR for this functionality. Is there anything I shoukd know before I get to work?

[theseer]

Awesome! If you have any questions, do not hesitate to contact us by email or write in this ticket.

I don't think there's very much to know. The code should be pretty self-explanatory.

Though, I have a few thoughts/wishes/ideas:

• Maybe obvious: the default behavior of phive should be the secure mode
• Insecure installation must be requested by an additional cli option
• I'd prefer a naming for that option that makes it clear it's an undesired thing like --force-insecure rather than --ignore-errors
• We probably want to record that decision in the phive.xml
• When installing from phive.xml with insecure phars, the same option needs to be given or interactively confirmed. If no interaction is possible, we should probably abort the installation

[djmattyg007]

I've been playing around with it for the last week, and I have a few notes that I wanted to record here:

1. I think --allow-insecure is the best name for the flag, the reasons for which should become clear below.
2. For the sake of specificity, use of the --allow-insecure flag is not designed to allow downloads to occur over insecure HTTP.
3. If the user is installing a phar that has never been installed before and is not in the registry, even if the user passes the --allow-insecure flag, we should still attempt to verify the file. The --allow-insecure flag should simply permit verification to fail. This will hopefully protect the user in case they accidentally pass that flag unnecessarily.
4. I don't think that unverified phar files should be saved to the registry.
5. However, if they are saved to the registry, the fact that they were not verified will need to be recorded. In this case, installation of unverified phar files from the registry will require the --allow-insecure flag.

What are your thoughts?

[theseer]

For readability reasons, let me respond to each item of your list individually:

1. I'm not convinced we have the right name yet. We want it to express that it has (generally unwanted) security implications and only affects the gpg check, not the transfer.

2. I do fully agree. HTTPS is not negotiable and it should not be possible to disable it.

3. I'm unsure whether I understand this correctly. What do you mean by registry? Our local ~/.phive/phars.xml-storage? If it's there, it's there. We do not recheck things. We might consider providing a means to commit local phar files to that storage, but that's a different topic. "Allowing verification to fail" is fairly unspecific and the way I understand it feels wrong: If I do run a verification, it has to pass. We can argue - and that's what this ticket is probably about ;) - whether or not to attempt the verification in the first place.

4. Again, what's the registry here? The phars.xml or the phive.xml file. Either way, the user is in charge. If we allow non-checked phars to be used, it's the users responsibility to deal with the consequences. We might mark the installation as "tainted" to highlight that fact actually. Redownloading them every time kills the idea of phive, so we have to store them somehow. Also, if you want to be able commit the projects phive.xml, we need to have a full set of phars installed - not only the ones that got checked. So again, we need to store that somehow. So I guess, I disagree ;)

5. I currently would say the "tainted" flag merely gets moved along. Meaning, if we have a tainted flag or any other marking for the phar in the phars.xml, we should add the same mark to the phive.xml entry.

My answer to 5 opens up new questions:

• Do we silently accept insecure phars based on the flag when phive install is performed?
• What about phive update?
• What do we do with inconsistencies, e.g. a local phars.xml having an insecure entry for a phar that according to the phive.xml should have been checked?

[djmattyg007]

Sorry for not making it clearer about what the registry is. In the code, there is a class named PharRegistry that appears to be responsible for managing what's in ~/.phive. That would include phars.xml, and is what I was referring to. I'll do my best to avoid such confusion going forward :)

I think the name --allow-insecure is more appropriate than --force-insecure for a couple of reasons:

1. Someone may specify it for the phive install command even when no phar files are going to be downloaded and no phars in phive.xml are marked as insecure.
2. Someone may have incorrectly marked a phar that is definitely verifiable as insecure in phive.xml. If we still performed the verification in this case, it would succeed, and we wouldn't need to print a warning for the user.

However I agree that it doesn't do a good enough job of communicating the fact that this is solely for signature verification. What about something verbose such as --force-allow-insecure-installations? This includes the word "installations", which is separate from "downloads". It also includes the word "force", which I would definitely like to include if possible (I do find that people tend to be a bit cautious with actions that require "forcing" something).

Also, having had time to reflect on what you wrote regarding expecting signature verification to succeed, I have changed my mind and agree with you. In fact I think you could make an argument that what I was suggesting is actually dangerous. I'm fine with saving unverified phars to phars.xml. I agree that we need to record the fact that verification did not happen, and do like the word "tainted" for this. What do you think about preventing insecure installations for phars that come from the phar.io repository though? We know ahead of time that these should always be signed.

To answer the questions at the end of your message:

1. I definitely think we should always print a warning when the insecure flag is passed.
2. phive update appears to make use of a lot of the same services as phive install, so I guess it will need the same flag.
3. I think the only suitable course of action in this case is to reject the request.
   1. If phars.xml says a phar is tainted and phive.xml isn't marked as allowing insecure installations for that phar (or the user is attempting to install it for the first time using phive install phar-identifier), the user will potentially get a tainted installation without realising it. We must reject it.
   2. If phars.xml says a phar is not tainted, then there is no need to force an insecure installation either from phive.xml or with phive install phar-identifier.

[theseer]

Sorry for the delay in replying, been a busy week.

What about something verbose such as --force-allow-insecure-installations?

The combination "Force allow" sounds weird. It's not really "allowing" either if it's forced. I like the verbose though ;)

Let's see how others do that:

• DNF (Fedora) and YUM (CentOS/RHEL) use --nogpgcheck
• Apt (Debian) has --allow-unauthenticated
• Zypper (SuSE) has --no-gpg-checks

I didn't find any pointers for Ubuntu.
I don't like either of these ;) but the general direction of obviously "disabling" something.

Long story short: How about: --disable-gpg-signature-check for us? Verbose and clear, maybe even without the gpg in case we support other means at some point.

While pondering whether that would be singular or plural (-checks), I came up with the question if we maybe want to explicitly require this to be singular? As in require to install insecure phars one by one, making it a deliberate decision for each?

What do you think about preventing insecure installations for phars that come from the phar.io repository though? We know ahead of time that these should always be signed.

Do we? Technically, there is no such thing as a phar.io repository. All we do is provide a list of aliases pointing to the location where to get the actual phar. Much like a nameserver in the DNS world does.
Even if I refuse to merge PRs against the repository list when the to be added alias does not point to signed phars, we do not have any influence whether or not later releases will be signed.

I otherwise agree with your conclusions :)

How do we proceed from here?

[ThomasWeinert]

--disable-gpg-signature-check sounds like you disable for all phars, even if they have a signature. But I think you still want to fail the installation if here is an invalid signature, only allow the installation for phars without any signature. Debians --allow-unauthenticated seems to be a better fit.

phive status should output an indicator if a phar was (not)verified.

[theseer]

I totally agree with phive status needing to show the verification state and thanks a lot for bringing that up.

I do not like the Debian "allow"-tonality as I want to make it explicit that something is taken away rather than enabled when the flag is specified.

I agree the --disable-gpg-signature-check may sound like it's for all phars but I don't see that as a problem per se: The switch should only be available when the install command is used in combination with a single phar alias or url, effectively forcing the user to explicitly disable security on a per phar basis when initially installing. Given that this decision is recorded in the phive.xml, any run with phive install would honor that decision - for example in a CI context. Same goes for phive update.

[ThomasWeinert]

If the phive.xml is committed into the repository the user that later calls phive install/update can be different. He/she did not make that decision yet. Rather then saving the decision, I would require it for each call.

How about --disable-signature-enforcement?

[theseer]

I spent some time thinking about this and I'm not sure what the best approach is.
Let me spill out some of my thoughts:

Once downloaded and possibly checked, we currently do not re-verify a phar. We simply symlink an existing matching version whenever possible. So unless we somewhere store that the file had been successfully verified, we will never know the difference. Showing the key id that was used to check the signature may be a pointer for the user but is too indirect for me.

If I'm to add a phar that does not come with a verifiable signature to a project and have means to commit the phive.xml, I'm inclined to say that decision is made on behalf of the project. It is an unlikely edge case that the verification will magically work on a different host than mine. So for that, I want that decision to be transparent - read: stored - and an easy means to install all entries from the phive.xml, yet showing the fact we skipped signature checking for one/some phar(s).

That of course leaves a logical loophole: Given that this way an unverified phar will be available for explicit installation (since it's in the local phar db) we need to make sure to enhance the install process to check whether or not the phar had been verified before and complain in case it's to be added to a new project unless the switch to disable the check has been passed.

I stick to my proposal of --disable-gpg-signature-check for that.