On Thu, Jun 11, 2009 at 03:23:26PM -0500, Shawn Walker wrote: > [F]or the same reasons you noted about the CA certificates, I think > the ability to override peer verification behaviour is necessary.
I'm still not convinced that it's a good idea to allow users to voluntarily use less security. In the cases where a cert is self-signed, or the client cannot verify the chain properly, I think we're better off having the users expicitly decide to trust a particular server. > And I absolutely hate that behaviour of modern browsers, such as > FireFox. I can't count how many websites Sun has up, or other > legitimate websites I've been to that I have to go through FireFox's > "your papers please!" page. But do note that FireFox does give you an > escape route, it lets you continue anyway if you explicitly tell it to > do so. For the same reasons, and more, I think we need to do the same > thing. In retrospect, using a web browser was a stupid example since it doesn't frame the problem in terms of our customers use cases. To configure a https repository, the client has to explicitly invoke set-publisher, which runs a test to make sure that it can connect to the requested publisher. If that fails, we get an error message that specifies what has gone wrong. If it's a trust issue, I think it's better to obtain the certificate that we want to trust, instead of flipping a switch and saying, "eh forget about it." Once we have the server's certificate, we can verify that it's the same one that we used last time. A failure would be analogous to the type of warning that OpenSSH generates when your the host key of the host you're trying to connect to doesn't match the stored key. Presumably, clients are using encryption and authentication to ensure that they're talking to someone they trust. If they don't care about this, then using https really seems like overkill. At least in our model. (We're not sending credit-card numbers over the wire or anything like that...) -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
