Release: 1.2.2
Description
At the moment, we block during connection for as long as connect() has us block. Once connected, we can block more or less forever. We need a configurable timeout to prevent this.
Description
Description
Event Timeline
Comment Actions
Looking at it.
One possible solution is simply for the gpg process to kill
the gpgkeys process. Portability may be a problem with that
solution. Also, since HKP is still part of gpg in stable,
we'd either need a different solution for HKP, no solution
for HKP, or to move HKP to gpgkeys_hkp
Comment Actions
I don't think that there is a need to fix it in 1.2.
We could either change http.c to use select everywhere or probably easier to use a SIGALARM to let gpgkeys_hkp commit suicide after some time without response.
Comment Actions
This is what I was thinking as well (the alarm solution). It is different for each keyserver type since LDAP does in fact have a notion of a timeout already. In the other cases, just calling alarm() will do nicely. Do you know how portable this is to windows?