On Wed, Apr 06, 2005 at 11:24:18PM +0200, Roland Stigge wrote: > Hi, > > by default, upstream compiles in GNUTLS _and_ NSS. NSS is at least
I'm sorry, this is just wrong. I am upstream support, and you are substantially mistating what we do. we enable both IF AND ONLY IF both are present. the reason for this is because, absent package management, we really cannot trust *either* to be there for any period of time. For example, on slack, if you compile only with Mozilla NSS support, it is quite frenquently the case that gaim will "randomly stop working" because you upgraded mozilla (which will sometimes change the path to the nss/nspr includes). GnuTLS is our prefered option because it is less likely to move; more likely to work if present. secondly, we compile both because the checks are essentially simply positive checks. rather than attempting to write if/else if blocks, we simply wrote 2 if blocks. but ONLY ONE on of the two ssl plugins is ever in use, the first one that the directory read returns. > needed for the option nowadays called "old SSL", and GNUTLS doesn't > support SSL < v3. So I'm not sure if the current "consistent SSL library > choice" as documented in our changelog is the right approach. for the purposes of gaim, GnuTLS and nss/nspr provide equivalent support. while the raw capabilities of each are not and never have been equivalent, the subset that gaim uses is. I'd suggest you look at the code, not the changelog before you start assuming things about crytology. > > Adding libnss-dev to build dependencies and removing --disable-nss fixes > the problem for Debian (and instead adding --disable-gnutls completely > exchanges gnutls by libnss, but I didn't do many further checks besides > compiling and a bit of network sniffing). > > However, silently ignoring "failed" SSL is still an upstream security > issue. what error are we silently ignoring? that the ssl is not as strong as you would like? I'm sorry, that's not our problem, it is the protocol design that we follow, not your ideas on what constitutes security. Luke Schierer Gaim support. > > Thanks for considering. > > bye, > Roland > -- > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
