Arne Blankerts

Nobody said that they will **have** to be imported without confirmation. Just the request to a keyserver would be saved.

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...

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...

> 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...

Interesting issue. This approach is indeed bound to fail since we use the `name` attribute as primary key, so the result is expected. I'm not sure yet as to what...

Okay, I believe I do understand. We'll have to discuss how to implement something like that.

Thank you for providing additional input to this. I still disagree though: Neither you nor the original poster need to install multiple versions of the same phar *at the same...

> I do also have this problem for the testing environment of [hollodotme/fast-cgi-client](https://github.com/hollodotme/fast-cgi-client) where I need 3 different versions of PHPUnit to run tests against all supported PHP versions. But...

Given that sks-keyservers flagged themselves as legacy and are about to die out, we probably should just remove their support and focus on explicitly supporting the newer API.

You lost me: What does sks-keyservers have to do with the API provided by keys.openpgp.org? > Temporarily we could use `keys.openpgp.org` What do you mean and why "temporarily"?