On Fri, Feb 17, 2017 at 03:37:11PM +0100, Yuri D'Elia wrote: > When a CertificateFile is provided, do not trust the system store by > default, since this is not the expected behavior for X.509 certificates. > > SystemCertificates can still be explicitly allowed/disallowed to restore > the previous behavior. > i've been wondering whether the options make sense together at all, but there is a use case here: typically, you'd add a cert override after your provider failed to renew their cert. however, at some point, they likely will do the renewal, and it kind of makes sense when things just continue to work when that happens. i'll even argue that this use case is much more common than using a fixed cert specifically because you don't trust the CA chain.
so at this point i think a better approach would be just extending the manual by warning that system certs must be explicitly disabled for maximal security. it would also make sense to emit a notice when CertificateFile is specified, but none of the certs matches. also, the code should filter the file's contents and moan if there are non-host certificates in it. that will catch the common case of people erroneously specifying the system cert store in the option (which has no effect whatsoever except wasting time). ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ isync-devel mailing list isync-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/isync-devel
