phive: Automatic key import fails

When calling

$ '/php74/tools/src/phive.phar' '--no-progress' 'install' '--copy' '--target' '/php74/tools/src/build/usr/bin' '--trust-gpg-keys' 'F4D32E2C9343B2AE' 'composer-unused'

with phive 0.14.2, it asks for permission (which I can’t give, since this is an automated build).

[WARNING] This is NOT a key that has been used to install previous versions of this PHAR.
           While this can be perfectly valid (maybe the maintainer switched to a new key),
           please make sure this key belongs to the maintainer of the PHAR you are going to install.

	Fingerprint: D969 E610 2643 4DFE 4D64 1764 F4D3 2E2C 9343 B2AE

	Andreas Frömer <blubb0r05+github@gmail.com>

	Created: 2020-02-16

Import this key? [y|N]

At first I thought this worked in phive 0.14, but looking at the WARNING I guess this is because of the key-change in https://github.com/composer-unused/composer-unused/issues/81?

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 25 (12 by maintainers)

Most upvoted comments

I am also still experiencing problems with automatic key import under some circumstances - mainly when a phar author has changed his gpg key, und I call update in a CI environment. Although I provide the --trust-gpg-keys XXX flag, phive asks for interactive confirmation. Which of course breaks in a CI environment.

Okay, I’m not sure how you ended up in this and whether or not it is still an issue. But I’ll try to explain some things 😉

Firstly, phive keeps a local log of the originally requested and then installed versions in .phive/phars.xml relative to the current work directory. The file (and directory) is created on an initial run of phive when no phive.xml is found in the current work directory.

While phive.xml was the original location and is mainly kept for compatibility, this way, we can also allow projects to have the general config in the root directory, as many projects prefer, but also support a more cleaned up “private” directory .phive where this and additional files can be kept without cluttering the root directory.

Having both is a problem and thus the warning you saw is shown. It should only happen if you manually install something without a phive.xml being present and then, later - for instance via git pull -, get a phive.xml anyhow via that update.

Having a phive.xml (or .phive/phars.xml - not both 😉) in your repository is of course fine and required for phive to be of use in CI.

Where ever phive is run, it will maintain its own state in .phive in the home directory of the current user (unless overwritten with --home). As you might see, if the current work directory and home directory are identical, this will cause a clash of directory names and is a design flaw we didn’t think of while changing the old behavior (see #289) - a fix is discussed in #290.

Any keys accepted when installing are imported into a phive private gpg keyring stored in ~/.phive/gpg. That store is not being commited to version control as it is system local only.

Key handling in general has two conflicting requirements: While I do not want others to make the decision whether I do trust a signature and have a key auto-imported without my confirmation on my system, I very much do want to automate the decision in CI. To address this, we opted for adding a list of trusted keys to the CLI. I’m currently considering to add the key id to the phive.xml / .phive/phars.xml, so to avoid having to specify all of them all the time and add a switch to tell phive to trust the IDs specified. But for the time being, the key list has to be passed along in CI.

The alternative is to manually import all the required public keys to phive’s keyring in ~/.phive/gpg be for running it. That way, phive would be happy to use and trust them.

So, to sum things up, this is how it should work, assuming you delete phive.xml as well as .phive from your project to basically start from scratch. The following steps are to be run on your machine:

  1. phive install tool-a tool-b tool-c@1.0.0-rc5
  2. `git add .phive && git commit -m “add tools”
  3. add phive install --trust-gpg-keys 0x12-key-of-tool-a,0x34-key-b,... to your build automation configuration
  4. git add {build-automation-config} && git commit -m "add phive to build" && git push

There is no need to run any other phive command on CI.

Hello,

I am getting this on my Jenkins box - any news on this?

[2KDownloading key CF1A108D0E7AE720
14:44:37  Trying to connect to keys.openpgp.org (37.218.245.50)
14:44:37  Downloading https://keys.openpgp.org/pks/lookup?op=get&options=mr&search=0xCF1A108D0E7AE720
14:44:37  
[2K ╰|>                                       | 0.00 KB / 3.07 KB -   0%
[2K ╰|========================================>| 3.07 KB / 3.07 KB - 100%
[2KSuccessfully downloaded key.
14:44:37  
14:44:37  	Fingerprint: D326 80D5 957D C711 6BE2 9C14 CF1A 108D 0E7A E720
14:44:37  
14:44:37  	Ondrej Mirtes <ondrej@mirtes.cz>
14:44:37  
14:44:37  	Created: 2019-12-09
14:44:37  
14:44:37  Import this key? [y|N] [ERROR]   Needs tty to be able to confirm
14:44:37  

However my command is slightly different:

phive --no-progress install --trust-gpg-keys php-cs-fixer phpcpd phpunit phpstan