phive
phive copied to clipboard
phpstan >= 0.12.3 installation error
Starting with version 0.12.3 of phpstan the developer (ondrejmirtes) is using a new gpg key. But the installation with phive also crashes when I accept the new key:
phive --no-progress install --trust-gpg-keys CF1A108D0E7AE720
Phive 0.13.2 - Copyright (C) 2015-2020 by Arne Blankerts, Sebastian Heuer and Contributors
Copying php-cs-fixer-2.16.1.phar to ./tools/php-cs-fixer
Downloading https://api.github.com/repos/phpstan/phpstan/releases
Downloading https://github.com/phpstan/phpstan/releases/download/0.12.5/phpstan.phar
Downloading https://github.com/phpstan/phpstan/releases/download/0.12.5/phpstan.phar.asc
Downloading key CF1A108D0E7AE720
Trying to connect to keys.openpgp.org (37.218.245.50)
Downloading https://keys.openpgp.org/pks/lookup?op=get&options=mr&search=0xCF1A108D0E7AE720
Successfully downloaded key.
[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: D326 80D5 957D C711 6BE2 9C14 CF1A 108D 0E7A E720
Ondrej Mirtes <[email protected]>
Created: 2019-12-09
[ERROR] Signature could not be verified
[ERROR] [GNUPG:] NEWSIG
[ERROR] [GNUPG:] ERRSIG CF1A108D0E7AE720 1 2 00 1578839480 9 -
[ERROR] [GNUPG:] NO_PUBKEY CF1A108D0E7AE720
Is this an issue with phive or should I open an issue within the phpstan project?
The manual import of the key works:
gpg --keyserver keys.openpgp.org --recv-keys CF1A108D0E7AE720
Interesting. I tried to reproduce this but so far didn't manage.
I'll check some more over the weekend.
Ah, I didn't see the trust-gpg-key
. That's an interesting edge case we probably don't handle: The fact the previous installation of that phar had a different key is not the same as phive
not knowing the new key.
Me too :) https://github.com/szepeviktor/phive-action-example/runs/1276410270
@szepeviktor The error your action has is actually not a phive problem but a key problem: It appears that the key CF1A108D0E7AE720
had been uploaded to keys.openpgp.org
but ownership has not been confirmed. The openpgp.org server strips all unconfirmed UIDs from the keys. While that may seem like it makes a lot of sense from their perspective, it practically renders the key retrieved from openpgp.org useless. Imho, they should not return anything if not at least one UID was confirmed.
Anyway, since the key cannot be found on either of the other keyservers either, phive is out of luck - and fails. I'm a bit confused as to what the output looks like, since I was under the assumption we handle the "no key found" situation better, but maybe that's just not recorded properly...
@ondrejmirtes Could you chime in and :) confirm that key?
Actually, it looks like the key I just downlaoded from that URL has a UID set.
Can you try running the github action again? This is rather strange ;) I had exactly that case before and I did get a key from keys.openpgp.org
that I couldn't even import manually because of the missing UIDs..
But this key (at least now?) does contain a UID.
This is not related to the actual topic of this issue though..
I never encountered this problem.
There are two problems at hand:
- the problem this issue is about, which seems to be related to the fact the key changed
- the problem @szepeviktor retrieved a key without a UID from a keyserver (or our parsing code is broken ;) )
I fail to reproduce the 2nd, unrelated problem as well.
For the first problem, we actually have to update phive to fetch more releases from the github api as for whatever reason the api requires paging but doesn't allow searching :-/. But I have to fetch a release older than 0.12.3, which is not on the first page anymore ;)
or our parsing code is broken ;)
🤯
Then the first point has to do with #274.
@lippok While the topic of this issue is not, indeed #274 blocks me from testing it with that very phar. I guess I could create a test-repo that has two releases with different keys but #274 still needs fixing :)