SSL security concern

[Ethan Blanton]

David Woolley spake unto us the following wisdom:
> Windows, although far from open source, tends to take a similar
> position by default, but does provide features like group policies
> to allow a management lock down. Windows SSL security implementation
> is also lousy, in your terms, because:

Windows is not a good example of ... basically anything.

> As a specific example of an area where Pidgin doesn't comply with
> management lock down wants is that every few months people ask how
> to disable all but one service, to which the standard answer, is you
> can disable protocols by removing the plugins, but the end user can
> just re-install them, so the correct solution is block at the
> firewall.  Of course, many people asking for this would want
> Facebook and Google blocked, but are using private XMPP servers, so
> share a common protocol.

This is not an accurate characterization.  We get people asking how to
disable all but one service *using the project-provided Windows
binaries*, and we state that there is no such way.  A user can readily
compile Pidgin without plugin loading and include a specific subset of
protocol plugins at compile time and achieve just this.  Just ... not
some clueless Windows sysadmin.

The point here, and the point for many such features, is that the
burden of supporting the option is larger than the perceived benefit,
from our point of view.  In the case of locking down protocols, the
primary concern I see is that, if you allow loadable plugins at all,
it seems likely that the user can find some way to defeat whatever
trivial machanism you put in place with a mediocum of effort.  A
nontrivial mechanism is a significant endeavor.

Ethan