Dave Brolley <brolley@xxxxxxxxxx> writes:
> [...]
> Frank and I talked a bit more about this and he correctly noted that,
> with this change, __pmSecureServerSetup() no longer contains a code
> path which returns anything other than 0. He has suggested changing it
> to return 'void'.
My preferred solution is still having __pmSecureServerSetup report its
own actual success/failure, and let the caller decide what to do then.
Then the payload part of commit b9d2adfa5ae7c would have consisted of
only:
--- a/src/pmcd/src/pmcd.c
+++ b/src/pmcd/src/pmcd.c
@@ -948,8 +948,7 @@ main(int argc, char *argv[])
DontStart();
}
- if (__pmSecureServerSetup(certdb, dbpassfile) < 0)
- DontStart();
+ (void) __pmSecureServerSetup(certdb, dbpassfile); /* ignore failure */
PrintAgentInfo(stderr);
__pmAccDumpLists(stderr);
> I believe that it is possible that someday, such an error path could
> once again exist (e.g. if we were to implement Frank's example of
> having a pmcd/pmproxy mode for which secure connections are
> required). In that case we would be removing the return code only to
> add it again later. [...]
At that future time, this single check wouldn't be enough anyway: we'd
probably have to do some checks at connection-establishment time too.
A SSL_SecurityStatus() inquiry after a connection could probably
subsume setup-time checks.
- FChE
|