| 1 |
Hi, |
| 2 |
|
| 3 |
On 2019-02-25 17:09, Matthew Thode wrote: |
| 4 |
> How about we allow a setting for controling which keyserver to refresh |
| 5 |
> from. SKS has had problems, fedora has been better (and a coworker says |
| 6 |
> MIT is ok too). Aparently they have a max key size set or something to |
| 7 |
> work around keyserver 'brokenness'. |
| 8 |
> |
| 9 |
> Something similiar to this would be nice, but for keyservers. |
| 10 |
> |
| 11 |
> https://gist.github.com/robbat2/551fc8ea56408ee48e99909f9c26c13e |
| 12 |
|
| 13 |
I am still not sure which problem you are trying to solve: |
| 14 |
|
| 15 |
If you provide a way to disable key updates, you can also disable |
| 16 |
verification in general: Our threat model allows for compromised keys |
| 17 |
(just because you can't prevent that), so it is _essential_ that you |
| 18 |
verify that the key is still valid as part of _each_ validation. |
| 19 |
|
| 20 |
Fedora's keyserver are part of the normal SKS network. |
| 21 |
|
| 22 |
Yes, gnupg doesn't handle keyserver failures very well. I.e. no real |
| 23 |
timeout and switch to another server. But we enabled WKD a long time ago |
| 24 |
which fixed most problems for me because this will avoid normal |
| 25 |
keyservers in general. So I am wondering which problems do you have... |
| 26 |
|
| 27 |
|
| 28 |
-- |
| 29 |
Regards, |
| 30 |
Thomas Deutschmann / Gentoo Linux Developer |
| 31 |
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 |
Archives