phive
phive copied to clipboard
phar-io
Add support for trusted keys in repositories.xml
- put key ID (or even the whole public key) into repositories.xml
- phive will automatically trust (=import) that key, so no user interaction is required (similar to the
--trust-gpg-keyoption)
This would be really nice, since we have serious problems with the sks-keyservers.net keyservers in the last days. Anyone else experiencing proxy errors or timeouts?
Some servers in the sks-keyservers pool seem to be every unreliable and caused build errors for us as well. That's why I already implemented a manual dns lookup to iterate over various servers, so the timeout problems should be getting less. Unless of course if you are unlucky and get a bunch of unavailable servers in a row...
Agreed, timeout errors are getting less. But the proxy errors are really annoying:
Phive 0.11.0 - Copyright (C) 2015-2018 by Arne Blankerts, Sebastian Heuer and Contributors
Downloading https://api.github.com/repos/FriendsOfPHP/PHP-CS-Fixer/releases
Downloading https://github.com/FriendsOfPHP/PHP-CS-Fixer/releases/download/v2.12.2/php-cs-fixer.phar
Downloading https://github.com/FriendsOfPHP/PHP-CS-Fixer/releases/download/v2.12.2/php-cs-fixer.phar.asc
Downloading key E82B2FB314E9906E
Trying hkps.pool.sks-keyservers.net (18.191.65.131)
Downloading https://hkps.pool.sks-keyservers.net/pks/lookup?search=0xE82B2FB314E9906E&op=get&options=mr
Successfully downloaded key
[ERROR] Failed to parse provided key info: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
[ERROR] <html><head>
[ERROR] <title>502 Proxy Error</title>
[ERROR] </head><body>
[ERROR] <h1>Proxy Error</h1>
[ERROR] <p>The proxy server received an invalid
[ERROR] response from an upstream server.<br />
[ERROR] The proxy server could not handle the request <em><a href="/pks/lookup">GET /pks/lookup</a></em>.<p>
[ERROR] Reason: <strong>Error reading from remote server</strong></p></p>
[ERROR] </body></html>
Any hints how to avoid this? I'm in a CI build, and I just hit retry for the tenth time to get my build...
Not of hand.
It looks a bit like we're not handling the 502 correctly actually.
Let me have a look.
Okay, pushed a potential fix in branch proxy-error-fix.
Can you build phive yourself from this branch and give it a try?
Looking good so far! Build completed 3 times without failure. Retry seems to work now:
Phive ___VERSION___ - Copyright (C) 2015-2018 by Arne Blankerts, Sebastian Heuer and Contributors
Downloading https://api.github.com/repos/maglnet/ComposerRequireChecker/releases
Downloading https://github.com/maglnet/ComposerRequireChecker/releases/download/1.0.0/composer-require-checker.phar
Downloading https://github.com/maglnet/ComposerRequireChecker/releases/download/1.0.0/composer-require-checker.phar.asc
Downloading key D2CCAC42F6295E7D
Trying hkps.pool.sks-keyservers.net (192.146.137.11)
Downloading https://hkps.pool.sks-keyservers.net/pks/lookup?search=0xD2CCAC42F6295E7D&op=index&options=mr
HTTP Request failed (28) - retrying in 2 seconds
HTTP Request failed (28) - retrying in 2 seconds
HTTP Request failed (28) - retrying in 2 seconds
HTTP Request failed (28) - retrying in 2 seconds
[WARNING] Failed with error code 28: Operation too slow. Less than 128 bytes/sec transferred the last 90 seconds (while requesting https://hkps.pool.sks-keyservers.net/pks/lookup?search=0xD2CCAC42F6295E7D&op=get&options=mr)
Trying hkps.pool.sks-keyservers.net (18.191.65.131)
Downloading https://hkps.pool.sks-keyservers.net/pks/lookup?search=0xD2CCAC42F6295E7D&op=index&options=mr
Downloading https://hkps.pool.sks-keyservers.net/pks/lookup?search=0xD2CCAC42F6295E7D&op=get&options=mr
Successfully downloaded key
For #134 there's a small part still missing and @belanur is working on #154. Both we want to have in the next release.
So, yes, release should be out soon.
Nice, thanks! #154 is something I wanted to mention, too, good that this is already in progress ;-)
I am not really happy about this as the default behavior. With that I clone some project (not my own) from GitHub and it automatically adds keys without my explicit consent. :-(
Nobody said that they will have to be imported without confirmation. Just the request to a keyserver would be saved.
@belanur did:
phive will automatically trust (=import) that key, so no user interaction is required (similar to the --trust-gpg-key option)
I read 'no user interaction' as fully automatic without confirmation. This is a good option for the CI, but not for contributor checkouts. So it should be an explicit option.
I would like to have that option for CI because it avoids the need to maintain the phive install call manually. The feature is nice, but not in development environments.
I know he wrote that when opening the ticket. We are/were considering that as a behavior, but it's not said it has to be fully automagic. That's what I meant with my reply.
We can (and probably should) either reuse the trust-gpg-keys switch or add some other switch for the import.
@sebastianheuer did you mean repositories.xml or phar.xml?
The latter one would make sense if your project has a vetting process in place before adding tools. But once you have them (committed in your repo), just go along with the keys we‘ve trusted, without having to remember all of them on the command line.
Actually, this issue was indeed about adding trusted public keys - as in the actual public key data - into our repositories.xml. That solves various (potential) issues:
-
We don't have to talk to any key server to find the actual key, leading to less 3rd party dependencies and networking
-
We don't have the initial trust problem: If your first install of a phar would get a fake key and since phive has no means to verify the correctness of the key, you might end up trusting the wrong key. Having the trusted key registered, we can at least warn that the key used for signing doesn't match the one that we know.
-
Initial trust problem 2: Theoretically, given that all keys are stored in the gnupg key ring, I could sign any phar, even for foreign projects. So if you install a phar from me, import my public key, it would work for any other phar that has never been installed before. While unlikely, it's still a potential problem. Registered keys in the
repositories.xmlcloses that vector - at least for all the projects that register with us. -
You could use a non-public key for internal use without uploading it to a keyserver and still use signed releases of your own stuff
-
And, last but not least, if there's a need, we could even allow multiple keys as valid for one source. Technically possible already, but cumbersome.
We do not have a phar.xml. But we do have a phars.xml in the ~phive directory, which is our "database". And we have the phive.xml, which is the file tracking the installed phars in the project.
I assume, you're referring to the later. Adding trusted keys here (basically, in this context it would be the key-id or fingerprint) is problematic: Trusted by whom? While it seems to makes a lot of sense for CI, if I checkout your open source project and you decided to trust certain keys, why do I have to (automagically) trust that decision on my system?
Maybe we can add the keyid and add a new cli switch "--auto-accept-trusted-keys" or something...? Not sure yet, if that's a good idea..
Yes, I meant phive.xml. And yes, you're right about trusting keys from some open source repo that I cloned.
My idea would be that you'd want to decide per-project (based on some policy, process, ...) which keys to trust and which not.
Probably a switch like --trust-keys-from-phive-xml would make sense. Also note that the key-IDs in phive.xml could be per-phar, so circumvent the problem with signing someone else's release that you mentioned above.
Probably a switch like
--trust-keys-from-phive-xmlwould make sense. Also note that the key-IDs inphive.xmlcould be per-phar, so circumvent the problem with signing someone else's release that you mentioned above.
It would only do so if the person adding it didn't install that very phar for the very first time ;) but yes, it would further reduce the attack surface.